Table of Contents
Login
Current Implementation
Logs in a user in the system. This operation generates a security token that is mandatory in any subsequent API call. The security token identifies a User-Device association. Same user registered in multiple devices will have multiple security tokens.
The login operation also returns some meta-data about the user. For example: organization and facility information, list of active devices for the current user and permissions of the current user.
The currently supported validation scenarios are:
- A valid User Pin is provided.
- A valid User Id and Password are provided.
- A valid User Email and Password are provided.
- A temporal security token (with a life-span of 5 minutes) is requested.
Parameters
Base URL: /validateAccount
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
| pin | String | Only if 'email' and 'userId' are omitted (Or 'temporal' parameter is provided). | The pin used to identify a user. If this parameter is provided, 'email' and 'userId' parameters are discarded. |
| userId | String | Only if neither 'pin' nor 'email' are provided (Or 'temporal' parameter is provided). | The id of a user. If this parameter is provided, a valid 'password' must also be provided. |
| String | Only if neither 'pin' nor 'userId' are provided (Or 'temporal' parameter is provided). | The email of a user. If this parameter is provided, a valid 'password' must also be provided. | |
| password | String | Only if 'userId' or 'email' are provided (Or 'temporal' parameter is provided). | The password of the user. |
| deviceId | String | Yes (Unless 'temporal' parameter is provided). | The id of the device where the user is being logged in. |
| temporal | String | No | Indicates that we want to create a temporal security token. If this parameter is provided, all the other parameters are discarded. |
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/validateAccount?pin=poda&deviceId=596a1d880a22eb32&_=1395133673252' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
List Form Templates
Current Implementation
The application reads the list of form templates from the server right after the user is logged in. The list of forms is then cached until the next successful login.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/getForms?formType=formLibrary&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673253' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
List Patients
Current Implementation
When the user logs in, a list of all the patients the user can 'see' is retrieved from PS. The idea is to have a local cache so we don't need to retrieve patient information from PS any more. Latest changes in the way patients and users are assigned to each others made the creation of this cache obsolete. A similar cache is being used now containing only the associated patients of the user that is logged in into the device.
This cache is going to be removed in the future.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/getPatients?userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673254' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
Register Device
Current Implementation
A device is registered to a user depending on the type of usage the user decided at login time: Normal usage or Guest usage. In the case of Normal usage, the device-user relation is always registered in the server.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/registerDevice?deviceId=596a1d880a22eb32&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673256' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
Inbox
Current Implementation
Retrieves the messages from user's Inbox.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/getMessages?type=Alert&location=INBOX&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673255' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
Patients Assignment
Current Implementation
A patient can be currently assigned to a user by selecting it from the drop down present in Patients Assignment view, or via NFC or bar code scanning. The association between a patient and a user is used to determine the potential receivers of an alert that is generated for a patient.
Forms can only be submitted for currently assigned patients. This restriction is not enforced in PS but in the client application.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/associatePatientToProvider?patientId=000000003f59c2aa013f6898a5470043&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673258' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
Patient Admission Form [View]
Current Implementation
This form is not retrieved from the local forms cache. Every time this form is opened, its definition is retrieved from PS. The reason behind this is that the current value for ChartId question is filled on demand based on the current information present in Patient table.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/getForms?patientId=000000003f59c2aa013f6898a5470043&formType=patientDetail&userId=sigal&token=de8301d3-4b43-4bd9-9b90-a294e2296066&_=1395133673275' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
New line/Infection/Mental Health Forms [View]
Current Implementation
The information for these forms is retrieved and cached upon login.
API Sample
None
Maintenance Form [View]
Current Implementation
The structure of this form is currently being retrieved from the forms cache created upon login. The problem here is that one of the questions ('Open Lines') needs to retrieve data from the server side.
API Sample
For the 'Open Lines' question options:
curl 'http://192.168.2.102:8080/PresentationServices/getFormDetails?surveyId=2&patientId=000000003f59c2aa013f6898a5470043&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673261' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
Human Breast Milk Forms [View]
Current Implementation
This form is not being currently retrieved from the local forms cache. The reason is that this form contains some questions that might need to be hidden based on previously submitted forms. Instead of going through the 'getFormDetails' mechanism (as Maintenance Form does) the whole form definition is re-read from the server each time this form is displayed.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/getForms?patientId=000000003f59c2aa013f6898a5470043&surveyId=4&formType=formLibrary&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb&_=1395133673262' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' --compressed
Forms Submission
Current Implementation
Server-side validations
Some of the validations of a form's answers are currently being performed by PS (actually is survey-agent) in server-side. Some of these validations include: checking whether a patient has open lines or not or checking whether the Chart Id selected for a patient is already in use.
This kind of validation require server-side data in order to work.
Entities state modification
Te submission of a form is currently being persisted in Survey and SurveyAnswer database tables.
Most of the surveys only impact on those 2 tables. But there are special situation where a form submission could also impact in the state of exiting entities in the system, such as the Patient entity. This modifications are being performed by PS when a form is submitted.
Alert generation
When a form is submitted, a set of rules are being evaluated by survey-agent in order to determine whether alerts must be generated. When an alert is generated for a patient, all of the associated users receive a copy of it. All of the devices where the associated users are logged in also receive a notification.
API Sample
curl 'http://192.168.2.102:8080/PresentationServices/setForm' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Origin: file://' -H 'User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' --data 'surveyId=4&patientId=000000003f59c2aa013f6898a5470043&action=Submit&q001a=&q001=2014-03-18&q002a=&q002=No&q003=No&q004=No&q005=No&q006=No&q008=No&q009=1200.000&q010=No&q011=&q012=&q007=&userId=poda&token=d2360c39-637b-41da-988d-f031db5affbb' --compressed
0 Comments