O3 Labs & Tests

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 Status

Nothing

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

None; lab-specific results

Future