| Tip |
|---|
Bahmni (and OpenMRS) REST API swagger can be accessed on a running Bahmni instance on this url:
For instance on the Bahmni Demo server, the URL will be: REST API (Demo Server).
|
...
| Tip |
|---|
To see sample code on how to call Bahmni REST APIs, you can refer to the Bahmni Performance Tests written using Gatling (Scala DSL) here: https://github.com/Bahmni/performance-test/blob/masterold-framework/src/test/scala/org/bahmni/gatling/HttpRequests.scala |
Some ideas based on how our API would look like if it is designed them from its user’s point of view and not from how the data is organised in the system. I haven’t thought through everything in minutest details yet, but following is the outline.
Resources
Some of the following are sub-resources, i.e. they can be contained inside another resource. For example - treatments can be accessed directly or they get embedded inside an encounter.
Patient Profiles
Visits
This doesn't contain the encounters. It would be good to have references to encounters inside it. Is OpenMRS resource sufficient for this?
Clinical Encounters
It should de-normalize the visit dates on the encounter. Probably an href to the visit.
Diagnoses
Lab Investigations
It contains lab order, sample accession and lab result. If we find this resource to be too big then we would break it down into further sub-resources. Right now we do not know how exactly it would pan out when we do the OpenELIS replace work.
Procedures
Observations
It is only a subset of OpenMRS observations excluding procedures, lab-results, or anything which its own resource. This filtering should be done by the server endpoint. The API should also handle different classes differently making it easier for the consumer to consume it. The observation classes which Bahmni supports right now are "Qualified with Duration", "Qualified with Normality", "Multiple Coded" (better names are welcome).
Treatments
Drug order and treatment related observations. Also supports a special operation called "active".
Clinical Images
A sub-resource and not an attribute because of performance reasons.
Enrolled Programs
We would be using programs for chronic patients. Contains href for encounters inside it.
...
Examples
/patient-profiles/<patient-id>
/diagnoses?patient-id=<patient-id>
/observations?observation-type=vitals
/treatments?patient-id=<patient-id>&for=last-visit
/encounters?for=current
/encounters?for=current-visit
/visits
Links
http://pages.apigee.com/rs/apigee/images/api-design-ebook-2012-03.pdf
Notes from meeting
How to handle concept-answers vs. answers coming from different concept set. Concept answers can be returned along with observation type group resource. When the answers in a different concept-set we probably just need to perform a search on it, need not expose the complete list via the api.
...