2012-06-15 REST Discussion

Owned by Nathan Leiby (Unlicensed)
Last updated: Jun 15, 2012Version comment

Login/Logout (session resource)

Person

  • Issue: cant post attributes while making a person
  • Every resouce now has a version.
    • new resources from 1.9 are labeled as 1.9
    • needs to be supported by the client side
  • Create Patient
    • Needs Identifier
    • automatically generated <-- use this as preferred identifier (will set field "preferred": true)
  • -Every patient needs to have a "preferred identifier"; default is that the first identifier in the list becomes the preferred identifier. If multiple identifiers, we need to make a call to set the preferred ID manually

Resources, subresources that help specify a Patient

  • "identifier" is a subresource...
  • patient/<uuid>/identifer .. gets all identifiers linked with that UUID
  • Search
    • Can search in patients by name, and find representation (uuid, display, identification)
    • You can also search for patients using the identifier: ws/rest/v1/patient?q=100-8 <-- this is not searching on attributes
  • "identifierType" is a full resource (you can search on them directly)
    • patientIdentifierType ... sucessfully does GET all and returns the types.
    • patientIdentifierType?q=Old ... results aren't appearing <-- TODO: File a bug for this
    • -needs to be a store that will handle these to prevent duplicates
  • "personAttributeType"

Method: GET, URL: /ws/rest/v1/personAttributeType/
Headers: defaults
Body:
{
"attributeType":
"value":
}

  • hint: when you query for an attribute, write the name as plural? @Saptarshi: Could you please clarify this? This is where FreeConf dropped everyone.

Catalog

  • ws/rest/v1/catalog
  • Generates markup corresponding to all possible REST calls

Modules Raxa uses from OpenMRS

  • Logic Module
  • Patient Image
  • Rest Web Services 1.9 Extension
  • Rest Web Services
    • need to set "REST Web Services URI Prefix" in order to enable REST web services
    • can set max # of results to return, too
    • TODO: this needs to be added to our setup wizard. http://localhost:8080/openmrs
  • RaxaEMR Core

Rest Web Services Settings in OpenMRS

  • "absolute max result size"
  • concept?v=full returns 25mb of data ... far too much, though seems decently fast on localhost
  • overrides limit parameter, even if passed in REST call args
  • "default result size"
  • "REST Web Services URI Prefix", as described above

HATEOAS

  • http://en.wikipedia.org/wiki/HATEOAS
  • OpenMRS doesn't follow this philosophy, unlike Twitter or SunCloud API (more "restful" than OpenMRS)
  • Idea is that application doesn't need any other information besides links, however OpenMRS requires additional information

Demo of Resources

  • Some resources, like Person, don't have the GET all call
    • Concept
    • Patient List
  • NEVER use "purge" directly. Instead, use "!purge"
    • "!purge" retires or voids
    • "purge" actually deletes
  • Extension Resources from 1.9: "OpenMRS 1.9 Extension REST Resources"
    • History of providers
      • previously in OpenMRS 1.8, had to search several role names in order to find a provider
      • now there is >= 1 provider per encounter
      • 1.9.0 assumed that providers may not be a "person" existing in the system
      • 1.9.1 allows providers to be "person", so that they can have relations to others
        • In fact, person is now a required field for providers
  • New resources
    • location
    • provider
    • providerAttribute
  • Get all providers
    • /provider?v=full
    • /providerAttributeType
  • Screener Module
    • Not all providers in OpenMRS instance will be in OPD rooms. We want to show only providers that are in OPD, Surgery, etc
    • Can now set attributes, such as "name":"Duty Location" (a new attribute type), in order to specify doctor location
  • Create a provider (@Saptarshi, could you please clarify the calls needed here?)
    • POST /provider/<provider uuid>/
    • Post an attribute for that provider

UPDATE /provider/

{

"uuid":<uuid for "duty location" attribute>

"value":"OPD1"

}

    • Recommends pulling list of all doctors, doing a client side search for only those doctors who have an OPD attribute on them, and show those in the screener list
  • Suggested Uses of Provider Attributes
    • duty location - useful for screener,
    • job profile - head pharmacist, heart surgeon, other specialty
    • outreach? - CHW have other roles that might be described via provider attribute
  • JobProfile
    • can create a new attributeType called "head of department" or "manager"
    • can link it to a location attribute type, e.g. pharmacy (encounters also are linked to a location)

Searching Resources

  • When we add our concept dictionary, we should code the UUID's for our concepts into our Raxa code
    • ETAG search ...Check if UUID value has not changed, if not, then use value in local storage
  • Patient List
    • generally dynamically, not persisted. only useful for adhoc creation of patient list
    • to do saved call on patient list,
    • to share list across modules: save list in localstorage, assign it an ID

REST Status for Various Modules

  • REST calls for OPD
    • all of the REST calls for clinical work are covered by existing OpenMRS resources
      • ConceptClass
      • Observation
      • Drug
      • Encounter
      • Form, FormField, FieldAnswer, Field
        • allow customizability of forms (for specific walkthroughs)
        • use these as often as possible ... avoid complexity, better than using observations, encounters, etc
        • multiple fields in form, post it all together instead of individual observations
  • REST calls for Lab
    • DrugOrder subclass of Order
    • -added by Roger, part of lab module
    • LabOrder subclass of Order
    • -added by Roger, part of lab module
  • REST calls for Pharmacy
    • iDart port from Barry to support REST calls?
    • need service layer, first, to create REST layer
    • need design discussion, how are they importing iDart services into OpenMRS services

 

 

QUESTIONS


Q: Can you use nested calls, e.g. patient/<patient uuid>/identifier/<identifier uuid>/identifierType

POST name(s)

POST ob(s)

use plural to post multiple

can GET by chaining the URL


Q: Are there other REST resources we still need to work on, or other Java/back-end work we need? Or is our main path forward to become familiar with all the existing rest resources,

 

TODOS / TICKETS
Nathan ... Start Assigning TODOS, ticking them off

Nathan ... Tell Vikas that Shivam is doing Screener list, which is quite similar to the work being done for OPD list

Nathan ... get Barry's team working in JIRA

Saptarshi Purkayastha (Unlicensed): Understand iDart plan, guide them in REST

 

TODO: GET /ws/rest/v1/person is inaccurate docs ... needs to be fixed

TODO: for resouce "personattributeType" .. need to create our own concepts in a dictionary, not use the demo list. Should name them similarly. Also have Hindi versions of the name.
TODO: Need to set "REST Web Services URI Prefix" in order to enable REST web services. This needs to be added to our setup wizard. http://localhost:8080/openmrs
TODO: Create concept dictionary asap. TO get started, deploy the millenium villages concept dictionary. Then, create our own.
TODO: Add resource version to the Patient List (should be 1.0)
TODO: Explore how we can match client and server if they are different versions ... server should fail gracefully if server doesnt understand call [@John]

TODO: need design discussion on Pharmacy REST and how they are importing iDart services into OpenMRS services