New work on Lab Orders

Dear Community,

tl;dr: We are in the process of exploring how to improve Lab Orders. What features and functionality would you like to see? Do you know any end-users we could interview?

As shown on the OpenMRS Roadmap, UCSF is leading a next-generation 3.x iteration of Lab Orders, with input from Ampath and PIH. Team members from all 3 orgs came together yesterday to layout a first draft of prioritized requirements. The goal is an approach that works well with the large OHRI project (“OpenMRS HIV Reference Implementation”) by building this on the OpenMRS 3.x framework (i.e. applies the new frontend framework and UX conventions).

We are looking for:

  • Users from the field who would be interested in User Testing designs
  • Organizations interested in joining us and contributing resources in this work
  • Feedback on our requirements

Details and ongoing requirements documented here: Lab & Diagnostics Ordering - Projects - OpenMRS Wiki

A big thanks to @wamz, @Mwariri, @eudson, @alaboso, @Nirupa, @ddesimone, and @jdick for spearheading this important work.


Thanks @grace for this update. Wonderful! We would definitely be interested in helping look at requirements and decisions around architecture, to make sure it is aligned with the FHIR2 module LIS-EMR exchange workflows, the testable OpenHIE LIS-EMR FHIR IG that we are conforming to, and of course, thinking through any implications for orders-resulting in a real world implementation with a system like iSantePlus and OpenELIS that already do this type of exchange. Tagging some of my team here to get them included to help: @pmanko @caseynth2 @ccwhite23 @mozzy @gcliff

Thanks @janflowers. Can you point us to the documentation on the FHIR2 API resources available for Lab Orders?

I think this is a bit out of date, but here’s the workflow:

which was based on this:

And the LIS-EMR FHIR IG that we are working with OpenHIE to publish as the standard to conform to: LABORATORY.WORKFLOWS.IG\Artifacts Summary - FHIR v4.0.1

@pmanko Can you update on this?

There are multiple different types of orders we will want to support over time beyond tests & meds, including referrals, nursing orders, durable medical equipment, diet, activity, call orders, etc. While we can introduce these over time and we may always want ways to focus on specific order types in certain contexts (especially medications), we will eventually need to support generic ordering across all order types. Two primary use cases are (1) providing users a single order field from which they can place orders of any type and (2) support for order sets that contain orders of many different types.

We will be much better served to take a unified model for ordering and then, if needed, create features that constrain that process to specific order type(s), rather than approaching each order typing independently and then trying to unify them later.


@grace can you update us on how to get involved?