Difference between revisions of "Internal GCAPI"

From GrandCare Systems
Jump to navigation Jump to search
m
 
(50 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Introduction ==
GCAPI gives developers access to the core tools provided by a GCManage server and como systems. A variety of tasks can be performed by making simple web service calls.
To access the Como API you first need the passcodes to they system via [[GCManage API]].


If you're on the same network as the GrandCare system, you can call directly to it's IP address. If not, you'll need to get the public URL from the [[GCManage API]] [[GCManage API#remotelogin|remotelogin]] service.
= Calling GCAPI =
A basic call to GCAPI looks like this:
  http://[como-URL]/api/[api-subsystem].php?passcode=[my-passcode]&op=[operation]&encoding=[json|xml]


This URL (whether private IP or public address) will be referenced as '''$SystemAddress''' in the rest of the documentation.
The como URL and passcode are from the results of a [[Internal GCManage API]] remote login call. The como URL is what GCManage determines is the path to the como system. This can either be proxied or the direct IP of the system. passcode is the authentication mechanism used by GCAPI -- it is a code generated every 24 hours by a system and reported to GCManage. subsystem names the subsystem you want to work on and operation defines the actual operation to perform. Each operation can have a number of other parameters that will be passed via other parameters in the URL.


'''$SystemAddress Examples'''
= Local Application Authentication =
http://gcmanage.grandcare.com:21000/
Applications may also want to call the API without an associated GCManage account. GrandCare will provide each application an "application key" that allows for a simple way to fetch the required passcodes. To do this, call the API via "localhost" using the following URL:
  http://192.168.0.5/
  http://[como-URL]/api/system.php?op=getpasscodes&appkey=[gc-provided-app-key]
http://10.100.1.5/


=== History ===
This will return the required passcodes for making authenticated calls to the API. See the section on the [[#System API|System API]] Subsystem for more information about the [[#getpasscodes|getpasscodes]] API call.
* URL: $SystemAddress/api/history.php
 
* Global Parameters
= Results From GCAPI =
** '''op''': API Operation (see list below)
The response from GCAPI will either be encoded in JSON or XML, depending on the requested encoding. By default the response will be encoded in XML.
** '''encoding''' ("json" or "xml")
 
** '''passcode''': System passcode from GCManage API
== XML Results ==
==== bp (Blood Pressure) ====
By default, GCAPI responds to commands by returning an XML document. Here is the most basic success result:
 
<gcapi>
    <result>SUCCESS</result>
</gcapi>
 
The root XML element for all GCAPI results is gcapi. The other always present element is result, which contains either SUCCESS or FAILURE, depending on whether the call succeeded or not. A failure response also contains the fail-message element, which gives the reasons for the failure. For example:
 
<gcapi>
    <result>FAILURE</result>
    <fail-message>Invalid credentials for API call</fail-message>
</gcapi>
 
This result would occur if invalid credentials were supplied during the GCAPI call.
 
== JSON Results ==
GCAPI can also respond by returning a JSON object. Here is the most basic success result:


''' Results '''
$ curl "http://10.100.1.2/api/history.php?op=bp&encoding=json&passcode=YkdrYUpUOEVVRDhMZFQ4SlB6OC9kdz09"
  {
  {
     "gcapi": {
     "gcapi": {
         "result": "SUCCESS",
         "result": "SUCCESS"
        "bp": [
            {
                "timestamp": "07/31/12 08:15:57",
                "deviceId": "1001",
                "residentId": "cf6ff892-3124-41ef-8c77-e729f0f66fc5",
                "systolic": "134",
                "diastolic": "95",
                "pulse": "54",
                "mean-ap": "117"
            },
            {
                "timestamp": "07/28/12 07:51:16",
                "deviceId": "1001",
                "residentId": "cf6ff892-3124-41ef-8c77-e729f0f66fc5",
                "systolic": "134",
                "diastolic": "89",
                "pulse": "51",
                "mean-ap": "104"
            }
        ],
        "totalEntries": "2"
     }
     }
  }
  }


==== weight ====
A failure encoded in JSON looks like:


''' Results '''
$ curl "http://10.100.1.2/api/history.php?op=weight&encoding=json&passcode=YkdrYUpUOEVVRDhMZFQ4SlB6OC9kdz09"
  {
  {
     "gcapi": {
     "gcapi": {
         "result": "SUCCESS",
         "result": "FAILURE",
         "weight": [
         "fail-message": "Invalid credentials for API call"
            {
                "timestamp": "07/31/12 08:14:45",
                "deviceId": "1000",
                "residentId": "cf6ff892-3124-41ef-8c77-e729f0f66fc5",
                "value": "176.6"
            },
            {
                "timestamp": "07/28/12 07:49:32",
                "deviceId": "1000",
                "residentId": "cf6ff892-3124-41ef-8c77-e729f0f66fc5",
                "value": "176.2"
            }
        ],
        "totalEntries": "2"
     }
     }
  }
  }


==== temp (Indoor Temperature) ====
= API Subsystems =
''' Results '''
== History API ==
$ curl "http://10.100.1.2/api/history.php?op=temp&encoding=json&passcode=YkdrYUpUOEVVRDhMZFQ4SlB6OC9kdz09"
The [[InternalHistory API Subsystem|History subsystem]] allows you to fetch ADL and wellness data from a system. Most of the operations take the same parameters and return different data.
{
 
    "gcapi": {
See [[Internal History API Subsystem|documentation]] for details or click an specific History operation below
        "result": "SUCCESS",
=== [[Internal History API Subsystem#bp|Blood Pressure]] ===
        "temp": [
Fetches blood pressure sensor history from the system
            {
=== [[Internal History API Subsystem#weight|Weight Scale]] ===
                "timestamp": "07/20/12 12:06:18",
Fetches scale history from the system
                "deviceId": "103",
=== [[Internal History API Subsystem#temp|Temperature Sensor]] ===
                "value": "73"
Fetches temperature sensor history from the system
            },
=== [[Internal History API Subsystem#bed|Bed Sensor]] ===
            {
Fetches bed sensor history from the system
                "timestamp": "07/20/12 11:53:14",
=== [[Internal History API Subsystem#oxi|Oximeter]] ===
                "deviceId": "103",
Fetches oximeter history from the system
                "value": "74"
=== [[Internal History API Subsystem#motion|Motion]] ===
            }
Fetches motion sensor history from the system
        ],
=== [[Internal History API Subsystem#gluc|Glucometer]] ===
        "totalEntries": "2"
Fetches glucometer history from the system
    }
=== [[Internal History API Subsystem#door|Door Sensor]] ===
}
Fetches door sensor history from the system
=== [[Internal History API Subsystem#cid|Caller ID]] ===
Fetches caller ID history from the system
 
== Assign API ==
The [[Internal Assign API Subsystem|Assign subsystem]] allows you to assign and delete wellness readings from a system.
 
See [[Internal Assign API Subsystem|documentation]] for details or click an specific Assign operation below
=== [[Internal Assign API Subsystem#assign|Assign Reading]] ===
Assigns a wellness reading to a resident
=== [[Internal Assign API Subsystem#delete|Delete Reading]] ===
Marks a wellness reading as deleted
 
== Caregiver API ==
The [[Internal Caregiver API Subsystem|Caregiver subsystem]] allows you to create, read, update, and delete caregivers from a system.
 
See [[Internal Caregiver API Subsystem|documentation]] for details or click an specific Caregiver operation below
=== [[Internal Caregiver API Subsystem#create|Create]] ===
Create a caregiver
=== [[Internal Caregiver API Subsystem#read|Read]] ===
Reads a single caregiver or all caregivers
=== [[Internal Caregiver API Subsystem#update|Update]] ===
Updates an existing caregiver
=== [[Internal Caregiver API Subsystem#delete|Delete]] ===
Deletes an existing caregiver
 
== Medication API ==
The [[Internal Medication API Subsystem|Medication subsystem]] allows you to manage medication and schedules from a system.
 
See [[Internal Medication API Subsystem|documentation]] for details or click an specific Medication operation below
=== [[Internal Medication API Subsystem#createPrescription|Create Prescription]] ===
Create a prescription
=== [[Internal Medication API Subsystem#readPrescription|Read Prescription]] ===
Reads a single prescription or all prescriptions
=== [[Internal Medication API Subsystem#updatePrescription|Update]] ===
Updates an existing prescription
=== [[Internal Medication API Subsystem#deletePrescription|Delete]] ===
Deletes an existing prescription
=== [[Internal Medication API Subsystem#storePrescriptionPic|Store Picture]] ===
Stores a picture for a prescription
 
=== [[Internal Medication API Subsystem#createSchedule|Create Prescription Schedule]] ===
Create a prescription schedule
=== [[Internal Medication API Subsystem#readSchedule|Read Prescription Schedule]] ===
Reads a single prescription schedule or all prescription schedules
=== [[Internal Medication API Subsystem#updateSchedule|Update Prescription Schedule]] ===
Updates an existing prescription schedule
=== [[Internal Medication API Subsystem#deleteSchedule|Delete Prescription Schedule]] ===
Deletes an existing prescription schedule
=== [[Internal Medication API Subsystem#setCompliance|Set Compliance]] ===
Set compliance on an existing prescription schedule
=== [[Internal Medication API Subsystem#checkCompliance|Check Compliance]] ===
Check compliance on an existing prescription schedule
=== [[Internal Medication API Subsystem#backfillCompliance|Backfill Compliance]] ===
Backfill compliance on an existing prescription schedule
=== [[Internal Medication API Subsystem#RxLookup|Lookup Rx]] ===
Finds Rx via FDA NDC Directory
 
== ActivityLog API ==
The [[Internal ActivityLog API Subsystem|Activity Log subsystem]] allows you to view a log of touchscreen events
=== [[Internal ActivityLog API Subsystem#read|Read]] ===
Read entries out of the log
=== [[Internal ActivityLog API Subsystem#add|Add]] ===
Add entries to the log
 
== TODO ==
* <strike>assign api</strike>
* <strike>caregiver api</strike>
* carenote api
* configure api
* device api
* <strike>history api</strike>
* log api
* media api
* medication api
* message api
* pin api
* resident api
* rule api
* system api
* activitylog api
* notification api
* calendar api
* letters api
 
= Other Resources =
* [https://github.com/ngharo/gc-javascript-api Experimental JavaScript library]

Latest revision as of 22:00, 19 July 2017

GCAPI gives developers access to the core tools provided by a GCManage server and como systems. A variety of tasks can be performed by making simple web service calls.

Calling GCAPI

A basic call to GCAPI looks like this:

http://[como-URL]/api/[api-subsystem].php?passcode=[my-passcode]&op=[operation]&encoding=[json|xml]

The como URL and passcode are from the results of a Internal GCManage API remote login call. The como URL is what GCManage determines is the path to the como system. This can either be proxied or the direct IP of the system. passcode is the authentication mechanism used by GCAPI -- it is a code generated every 24 hours by a system and reported to GCManage. subsystem names the subsystem you want to work on and operation defines the actual operation to perform. Each operation can have a number of other parameters that will be passed via other parameters in the URL.

Local Application Authentication

Applications may also want to call the API without an associated GCManage account. GrandCare will provide each application an "application key" that allows for a simple way to fetch the required passcodes. To do this, call the API via "localhost" using the following URL:

http://[como-URL]/api/system.php?op=getpasscodes&appkey=[gc-provided-app-key]

This will return the required passcodes for making authenticated calls to the API. See the section on the System API Subsystem for more information about the getpasscodes API call.

Results From GCAPI

The response from GCAPI will either be encoded in JSON or XML, depending on the requested encoding. By default the response will be encoded in XML.

XML Results

By default, GCAPI responds to commands by returning an XML document. Here is the most basic success result:

<gcapi>
   <result>SUCCESS</result>
</gcapi>

The root XML element for all GCAPI results is gcapi. The other always present element is result, which contains either SUCCESS or FAILURE, depending on whether the call succeeded or not. A failure response also contains the fail-message element, which gives the reasons for the failure. For example:

<gcapi>
   <result>FAILURE</result>
   <fail-message>Invalid credentials for API call</fail-message>
</gcapi>

This result would occur if invalid credentials were supplied during the GCAPI call.

JSON Results

GCAPI can also respond by returning a JSON object. Here is the most basic success result:

{
   "gcapi": {
       "result": "SUCCESS"
   }
}

A failure encoded in JSON looks like:

{
   "gcapi": {
       "result": "FAILURE",
       "fail-message": "Invalid credentials for API call"
   }
}

API Subsystems

History API

The History subsystem allows you to fetch ADL and wellness data from a system. Most of the operations take the same parameters and return different data.

See documentation for details or click an specific History operation below

Blood Pressure

Fetches blood pressure sensor history from the system

Weight Scale

Fetches scale history from the system

Temperature Sensor

Fetches temperature sensor history from the system

Bed Sensor

Fetches bed sensor history from the system

Oximeter

Fetches oximeter history from the system

Motion

Fetches motion sensor history from the system

Glucometer

Fetches glucometer history from the system

Door Sensor

Fetches door sensor history from the system

Caller ID

Fetches caller ID history from the system

Assign API

The Assign subsystem allows you to assign and delete wellness readings from a system.

See documentation for details or click an specific Assign operation below

Assign Reading

Assigns a wellness reading to a resident

Delete Reading

Marks a wellness reading as deleted

Caregiver API

The Caregiver subsystem allows you to create, read, update, and delete caregivers from a system.

See documentation for details or click an specific Caregiver operation below

Create

Create a caregiver

Read

Reads a single caregiver or all caregivers

Update

Updates an existing caregiver

Delete

Deletes an existing caregiver

Medication API

The Medication subsystem allows you to manage medication and schedules from a system.

See documentation for details or click an specific Medication operation below

Create Prescription

Create a prescription

Read Prescription

Reads a single prescription or all prescriptions

Update

Updates an existing prescription

Delete

Deletes an existing prescription

Store Picture

Stores a picture for a prescription

Create Prescription Schedule

Create a prescription schedule

Read Prescription Schedule

Reads a single prescription schedule or all prescription schedules

Update Prescription Schedule

Updates an existing prescription schedule

Delete Prescription Schedule

Deletes an existing prescription schedule

Set Compliance

Set compliance on an existing prescription schedule

Check Compliance

Check compliance on an existing prescription schedule

Backfill Compliance

Backfill compliance on an existing prescription schedule

Lookup Rx

Finds Rx via FDA NDC Directory

ActivityLog API

The Activity Log subsystem allows you to view a log of touchscreen events

Read

Read entries out of the log

Add

Add entries to the log

TODO

  • assign api
  • caregiver api
  • carenote api
  • configure api
  • device api
  • history api
  • log api
  • media api
  • medication api
  • message api
  • pin api
  • resident api
  • rule api
  • system api
  • activitylog api
  • notification api
  • calendar api
  • letters api

Other Resources