2014-03-10 Design Forum

Agenda

• Moravian/Merck Project (30 min)

• REST API for Orders in the encountertransaction resource in the EMR API module (15 min)

• https://tickets.openmrs.org/browse/EA-1

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

• https://docs.google.com/a/openmrs.org/document/d/1t6Rph8GeSPo3VeatNtsMPvehXzyecfxcl0beulgFyGY/edit

• Disease representation

• OpenMRS 2.0 approach (not widely adopted yet): "Visit Diagnoses" concept set generating "Coded Diagnosis" observation with coded diagnoses

• http://www.maternalconceptlab.com/search.php?q=id:159947&source=openmrs

• 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)

• http://www.maternalconceptlab.com/search.php?q=id:6042&source=openmrs

• Suggested Design Ideas

• Leverage the Reporting Module framework

• https://openmrs.atlassian.net/wiki/x/BgFYAQ (Reporting Module)

• 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)

• Consider asking implementations (implementers@openmrs.org) for what aggregate report(s) would be most helpful.

• Create a project page (add a page under the "Active Projects" wiki page: https://openmrs.atlassian.net/wiki/x/-8JTAQ )

• Examples of Project Pages

• Human Resources Module: https://openmrs.atlassian.net/wiki/x/_xRUAQ

• Advanced Concept Management: https://openmrs.atlassian.net/wiki/x/iedTAQ

• You can take a few minutes to browse some of the active projects and mimic whatever looks best to you

Discussion on EA-1

• https://tickets.openmrs.org/browse/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