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

Browser not supported