2014-03-10 Design Forum

Owned by Burke Mamlin
Mar 10, 2014
Agenda
  • Moravian/Merck Project (30 min)
  • REST API for Orders in the encountertransaction resource in the EMR API module (15 min)
Notes
Moravian/Merck Project
  • Proposal for new module
  • In Summer 2014, working as a class, simulating a "small code shop".
  • Merck is supporting the class
  • Idea is to create an aggregate summary of disease class burden and to allow this to be shared on the OpenMRS Atlas
  • Disease representation
  • OpenMRS 2.0 approach (not widely adopted yet): "Visit Diagnoses" concept set generating "Coded Diagnosis" observation with coded diagnoses
  • OpenMRS 1.x approach: "Problem Added" + "Problem Removed" observations (former recorded to add a diagnosis for the patient and the latter to cancel that diagnosis)
  • Suggested Design Ideas
  • Leverage the Reporting Module framework
  • Provide mechanism to generate report from either/both approaches for diagnosis capture or program data
  • Start with simple approach
  • Add an easy way to share the report (initial may be a simple export, eventually could allow "add to Atlas marker" option)
  • Examples of Project Pages
  • You can take a few minutes to browse some of the active projects and mimic whatever looks best to you
Discussion on EA-1
  • Darius's preferred option is to switch to having top-level property called "orders" which is a list. Each item must have a "type" property (in addition to careSetting, action, etc as before) and you'd switch on this type (an OrderType) to decide how to handle the item.
  • If we go with different top-level elements for "drugOrders" and "testOrders":
  • avoid having too many of those (e.g. we shouldn't have serologyTestOrders, radiologyTestOrders, etc.
  • we still have to switch on OrderType to take care of this
  • TRUNK-4287 is key for this