2014-03-26 Design Forum

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