...
- Some resources, like Person, don't have the GET all call
- TODO: GET /ws/rest/v1/person is inaccurate docs ... needs to be fixed
- 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
- 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
- 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
- all of the REST calls for clinical work are covered by existing OpenMRS resources
...
- ConceptClass
...
- Observation
...
- Drug
...
- Encounter
...
- Form, FormField, FieldAnswer, Field
- 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
...
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