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
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
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.