O3 Labs & Tests

Historic Links:

Meeting Notes

Squad for Labs v2: Call Oct 24 2023

Attendees: Wamz, Grace, Casey, Gilbert, David, Pius, Eudson

  • Reached consensus on designs for a new "Orders" page in the O3 RefApp; Wamz has updated the designs based on the Squad's feedback from last week (see the updated version here) and Pius has begun work implementing this. 
  • Wamz & Casey agreed to become co-leads of this Feature Squad (smile)  This squad will meet weekly on Tuesdays at 2pm UTC (5pm EAT / 7:30pm IST / 10am EDT / 7am PDT). Added to OMRS community calendar; co-leads to make calendar changes as needed. 
  • All agreed to use the OMRS Jira Labs Epic to track this work here:
    Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • Wamz to move relevant docs into OMRS wiki. 

Squad for Labs v2: Kick-Off Call Oct 16 2023

Attendees: Brandon, Burke, Casey, David, Eudson, Gilbert, Grace, Michael B

Link to Wamz's demo on Oct 12th Squad call: https://iu.mediaspace.kaltura.com/media/t/1_2b8r9rf1?st=1810

AreaNow: What we have now (as of Oct 16th)Where we want to go: Next PrioritiesNotes
Order Labs/Tests
  • Lab Order form in Order Basket
  • Test Search
  • Lab Order number is generated but only in the Angular Form Order component ("Lab order(s) generated 1 : Haemoglobin : ORD-441)
  • Bug: Drug concepts should not be showing up (_____)
  • Remove "Lab reference number" in the order form. Usually exists on a pre-printed form. Aka Accession # or Specimen #. 
  • Order number needs to end up in the FHIR request (___)
  • Order Form should be driven by a form made in / editable in the Form Builder
    • Start an Order in an Encounter via a Form
      • Ang Form Engine link into Order Basket (Brandon/Mekom)
      • React Form Engine link into Order Basket (________)
    • Form Engine Powered Built-in Forms: Render Forms elsewhere in O3 (eg in Lab Order app) - Reference a particular form within an app's o3 config (e.g. change triage / lab form UID for your distro); built in forms would be stored the same way we store form engine forms

Implementation: Options are from all concepts called "Test"

Lower priority: Provider's "Favorites" (_____)

Ideally, any order generated in OpenMRS would be automatically assigned a unique and human-friendly (not a UUID) order number (stored in orders.order_number ). This is true for all orders (not just labs). This order number would be included when orders are sent to ancillary systems (e.g., a separate lab system) and ideally returned within any lab results resulting from the order. This order number is how we make the potentially 1-to-many connection between lab results coming back from another lab system and the original order request (i.e., we would populate obs.order_id  with a link to the order with the corresponding order number).

Per Patient: Order Status and Lab StatusNothing
  • See any pending Lab Order
  • Flag "done and critical"

Order status, lab status, and lab result interpretation are different things

  • Order status reflects the status of the request. This aligns with FHIR's ServiceRequest.status, which may have values as described by the RequestStatus valueset (e.g., active, completed).
  • Lab status reflects the status of the specimen(s). This aligns with FHIR's Observation.status, which may have values as described by the ObservationStatus valueset (e.g., preliminary, final, cancelled).
  • Lab result interpretation reflects whether results are normal or abnormal. This aligns with FHIR's Observation.interpretation, which would have values that are concepts similar to the examples in the Observation Interpretation valueset (e.g., normal, high, low, critically high, critically low).

Given the above, "critically high" is a lab interpretation, not an order status or lab status. If we want to create a dashboard showing 

We need to figure out how to handle exceptions (e.g., insufficient specimen) in a way that aligns us with FHIR. In HL7 v2, the observation's status would be set to "X" and the reason for exception (e.g., "Insufficient specimen") would be placed in the observation comment. FHIR documentation implies the observation status be set to cancelled and the Observation..dataAbsentReason be used; however, the values for data absent don't have obvious choices for "insufficient specimen." It would help to have an "official" recommendation of best practice in FHIR on how to use observations to report exceptional lab results (specimen not received, inadequate specimen, etc.).

One challenge when working with an external lab system, will be knowing when to mark an order as completed. For example, a provider orders "FULL HEMOGRAM" and it is assigned order number #123. We sent this order to the lab (including the order number). Over the next 8 hours, we receive to lab results that reference order number #123: one is HEMOGLOBIN and the other is PLATELET COUNT. Do we consider the FULL HEMOGRAM order complete? Or will more results come later? The answer may be known by the lab system, but we may not be able to reliably get this information from the lab system, so we may need to come up with a business rule as a compromise (e.g., LabSet with any result received & 24 hours after order placed is considered completed).

Phlebotomy Status: Drawn? Label Printing?

Where someone needs to add #'s like Reference #, Sample #, Accession #? In general, humans shouldn't have to transcribe these (they should be auto-generated and sent between systems). When there are paper-based workflows, humans may need to transcribe them from a paper requisition into the system.

Status page: rejections of samples by lab. Critical results, alert worthy? Certainly on the status page, but do you want to bug the ordering doc as well? I just wanted to add this so I don’t forget when we run out of time.

All Patients: Order Status 
  • Flag critical results
  • Rejection Workflow - sample not good enough; alert Phlebotomy to re-do
(In Lieu of a bigger Lab Info System; similar to Dispensing App)
Results Entry
  • Via manually-built Form with ConceptIDs for Lab tests
  • Add Results from the Status page

Results Viewing
  • Fix Tree hardcoding - should be driven by LabSets / ConvSets
  • Tree View Logic: Decision - do we want to allow multiple levels? ______

No Order relationship yet...

"Orderable" vs "Viewable": Filter to exclude stuff you don't need to see in the Order view,  (want to see "Blood Cultures" in orders, but not the sub-tests for each strain of resistance), PIH has driven through "Orderable Labs ConvSet" that tend to be different per country

Result Alerts InboxNone; lab-specific resultsFuture

Peoples' Needs:

  • UCSF: 4-week Sprint starts tomorrow; want something w/ labs
  • PIH: Not a top priority for MCOE project but want to be involved
  • MSF: Critical for first pilot in a few months from now; want to align requirements
  • DIGI: OpenELIS-OMRS fhir-based connection for O3 for Cote d'Ivoire; currently just for VL but want for all lab tests (interested in statuses)
  • General Support: (assisted by Mekom/Brown (Brandon/Ian)): Implemented Lab Order form in Order Basket; Test Search functionality. Next: 
  • Major Overlaps: Status; Requirements