2014-03-26 Design Forum
TOPICS:
Order types and classes in rest
Requires: proposal on how different order types should be represented
Goal: agree on how different order types should be represented in the RESTWS module
https://tickets.openmrs.org/browse/EA-1 - Add support for placing, discontinuing and revising orders via REST
Requires: proposed JSON format
Goal: Agree on the JSON format for orders in an encounter transaction
Review mockups for a throwaway UI to test the Order Entry API
Requires: straw man mockups
Goal: Have concensus on a straw man of a very simple UI for exercising the order entry API – i.e., exposing the API functionality via a web page – to be made in a "throwaway" module for the sake of SMEs to exercise the order entry API.
Notes
Order Types within REST
REST uses "t" as param to filter to specific types of resources.
https://..../rest/ws/patient/1234/orders?patient=abc123&careSetting=INPATIENT&orderType=test
The clinical use case would be to filter by order type. If "t" is used for some technical "subtype" thing specific to REST webervices module, then it probably would not be appropriate for filtering to order types.
https://..../rest/ws/patient/1234/orders?javaClass=org.openmrs.order.TestOrder
EA-1
Ordering Mockups:
https://tickets.openmrs.org/browse/TRUNK-4218
https://tickets.openmrs.org/browse/TRUNK-4219
https://tickets.openmrs.org/browse/TRUNK-4220
https://tickets.openmrs.org/browse/TRUNK-4221
TRUNK-4218, 4219, 4220, 4221?
No editing concept, caresetting and drug for drugorders