Lab order approaches

Implementation Integration
1

I’m involved in a couple of projects e.g @ehebel Fellowhip project, which are tackling the whole Lab order/ report cycle, including interim messages such as ‘specimen received’.

The plan is to use a template aligned to EHDS Lab Report to receive the messages (HL7v2/FHIR) but we have some choices for handling the Lab order / status events, where we will use the service_request INSTRUCTION and ACTION archetypes

  1. Use the EHDS Lab report composition to handle all of the events from the original order through to final report, essentially as a persistent composition and as an ‘incremental report’.

  2. Have a separate Lab request template , t ocarry the inital request/ status and again update this for each interim status message.

  3. As for 2 but record each Service event as a separate composition, and use AQL to knit the ‘current status’ together.

I know there are legitimate arguments for each but it would be good to understand if there is any overall majority preference, particularly if folks have changed in light of experience @chunlan.ma - your hospital infection system journey will be interesting.

If we can nail this down a bit, it will allow us to package up the whole order/report cycle with FHIRConnect mappings etc and provide another EHRSlice @Seref

2

Hi @ian.mcnicoll .

Multiprac Infection Control solution uses openEHR archetypes and templates to model all of the clinical data in this context, including the laboratory request and laboratory result.
Of your three options we are closest to 2, with one difference worth mentioning: each update is a new version of the same event composition, not an edit to a persistent one. So there is arguably a fourth option sitting between your 1 and 2.

In our system, lab requests and lab results are represented using separate openEHR templates, and they are linked through the lab order number. Each has its own independent version history: one VERSIONED_OBJECT per order for the request, and one per order for the result.

The LAB request template contains lab test INSTRUCTION archetype and lab test ACTION archetype. The report template contains the lab test ACTION archetype and OBSERVATION archetype. Specimen collected, received and processed are represented using the specimen CLUSTER archetype rather than as ISM careflow steps. Report status (interim, final, supplementary, corrected etc.) are represented in the lab test OBSERVATION archetype.

All HL7 messages sharing a lab order number commit to the same versioned composition. For example, the first message creates version 1 with an interim status, the second HL7 message creates version 2 with a final status. Because openEHR versions are immutable, nothing is overwritten. The earlier version stays available for inspection while the latest represents current clinical state.

We deliberately do not carry previous status transitions forward into the latest version. Each version holds the clinical state conveyed by that message. Where an application needs to show progression, it reads the version history and its timestamps. We treat that as application logic rather than something to be reconstructed from separate event compositions.

In our experience the great majority of application and clinical workflows need the current request or result, not the full sequence of historical states. Our infection control rules generally need the final result to fire correctly; interim results are received and stored, but many rules deliberately wait for the final. We have not needed AQL to reconstruct current state from a set of event compositions. The HL7 message is the source of the clinical information, so we retrieve the latest version of the relevant versioned object. If historical information is required, the earlier immutable versions remain available.

After around 20 years working with this type of clinical system, I haven’t seen many requirements where the application needs to reconstruct the laboratory state from every individual status event. There are certainly use cases where the event history is clinically important, so I wouldn’t suggest that one approach is universally correct, but where the primary requirement is current clinical state, openEHR versioning has given us a fairly natural way to get there without a composition per event.

Thanks,

Chunlan

3

Not only that, but the number of versions of a composition has been a constant pain on my backside from an analytics point of view. When you’re feeding an openEHR system from an external system that can raise clinical events (such as pathology), you are at the mercy of that external system: they’ll fire HL7 messages whenever they want to, so they set the granularity and scope of (versioning) semantics you’re accumulating on the openEHR side so to speak. I’ve seen compositions with 40+ versions with a strong likelihood that anybody that’s interested in it is only interested in the last version, but we end up keeping them all.

Having good versioning machinery is great, not being able to decide the semantics of version changes it not.

@chunlan.ma please correct me if I’m wrong here, I never got to work on this with you :slight_smile:

4

Hi everyone,

Is the conclusion of the lab result included in this modelling and in which way? Particularly for infectious disease lab results this information could be very useful for example for an immunity archetype/template (e.g. such as the result of a measles antigen test).

5

Absolutely agree with you. We don’t control the version semantics at all. The sending system decides when a message goes out, so it effectively decides what a version means on our side. Two consecutive versions may well hold the same clinical data.

On top of that there’s no guarantee the messages arrive in a sensible order (our experience). Earlier messages can turn up later, and we’ve had lab requests cancelled after we’d already received results against them. Our integration service has to cope with all of it.

We’ve chosen to keep the versions rather than filter at ingest. As a downstream system we can’t reliably tell at the time which differences will matter later, and a wrongly dropped message is a silent failure. But that’s a trade, not a solution. It just moves the problem to the analytics end, which is where you’re feeling it :grinning_face: .

6

Yes, it’s included. The generic laboratory test OBSERVATION we use (openEHR-EHR-OBSERVATION.lab_test.v1) provides a couple of ways to represent this.

The Result element is 0..* and supports a wide range of data types, including Text, coded Text, Quantity, Count, Interval, and so on. So a narrative conclusion, such as a microbiology report comment, can be represented as a Text result alongside the coded analyte results.

There is also an Overall interpretation element, which is intended for a conclusion or interpretation across the report as a whole rather than a result in its own right.

Which one is more appropriate depends on how the sending laboratory represents the information. If the conclusion is received as an individual OBX/result, representing it as a Result preserves the information as received and also allows it to be coded if it needs to be computable. If it is an interpretation or summary across several results, Overall interpretation is more natural.

In our case, the messages we receive contain laboratory comments rather than a separately coded clinical conclusion, and we represent that information in the Overall interpretation.

For your immunity example, I would distinguish the laboratory result from the clinical statement “immune” or “not immune”. The latter could be a derived clinical statement based on the laboratory result, rather than part of the laboratory report itself. In openEHR, I would model that as a separate EVALUATION that could be linked back to the source result. This keeps the information received from the laboratory distinct from the clinical inference, and also means the derivation can be revisited if the interpretation rules change.

That’s how we’ve approached this in a production openEHR system for hospital infection control. Whether the same approach is appropriate for your project would depend on the specific requirements.

Happy to have a chat at EHRCon26 next week.

7

Thank you so much @chunlan.ma - I think that gives a clear, workable, preferred pattern, and thanks too to @Seref for the heads-up on the need ot think carefully about whether all interim lab order status messages need really need to be recorded in the CDR.

@loesjaspers - for context this is part of some work I am doing with @Miguel_Angel_Esteve and a freshEhr customer, looking at how to use the EHDS Laboratory report (as an openEHR template) to capture lab results but we also need a Lab order template,as this is not really defined in EHDS.

The early drafts are here EHDS-Diagnostics

The EHDS Lab report template was the one used by @Ian_Bennett for his Fellowhip project and has already been used to create FHIRConnect mappings. This uses a set of Laboratory Test and Laboratory analyte clusters that are bit newer than the one @chunlan.ma mentioned but have the same basic pattern.

But ultimately at least 2 templates one for the original Order and at least some interim status messages, then the Lab Results template once actual results partial/full come back.

If anyone else has practical experience they can share, this would be really helpful - one thing missing is ‘reflex-testing’ where the lab overrules or adds to the originally requested tests. This was always pretty messy in HL7v2 but is explicitly handled in FHIR-R6

8

and I agree with Chunlan’s suggestion that immune_status is best handled differently perhaps
Infectious disease summary, Draft archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2026-09-14]

9

Interesting debate! In general, clear guidance on using INSTRUCTION and ACTION together would be useful IMO - same template vs different template and approach for linking. @ian.mcnicoll - in the templates in your repo, ServiceRequest is in both templates. Depending on the approach, would you remove it from one of the templates? If so, which one?
For IPS repo that is being worked on, one template is used… would this also change?

10

@Ian_Bennett - that is a very good question!!

If we are creating an EHDS lab Report extract, the service Request data should appear.

If we have the original serviceRequest in the Lab order template , it is probably not necessary to replicate it in the Report, but that might not always be the case.

That’s ok - the purpose of this exercise is partly to expose these as real challenges and accept that we might only be able suggest a small number of variants, depending on the exact data flows.

11

I am currently in the process of designing the concept/approach for laboratory in our HIS. Currently, my plan is to have three templates:

  1. Lab order (request) - INSTRUCTION.service_request + ACTION.service + CLUSTER.specimen (+ some more CLUSTERs)
  2. Collection (encounter) - ACTION.procedure (+ CLUSTER.specimen + some more CLUSTERs)
  3. Result report (report-result) - ACTION.service + OBSERVATION.laboratory_test_result + CLUSTER.laboratory_test_analyte (+ some more CLUSTERs)

The biggest difficulty for me currently is how to model the different types of the status (initial request, collection, overall test, single tests) and how they are connected. Right now my idea is:

  • Workflow status in ACTION.ism_transition, written only from the request (planned → request sent) and the report (completed), both linked via instruction_details
  • Result status in the OBSERVATION - Overall test status for the test, Result status per analyte
  • Collection stays out of the state machine. So “was it collected?” is answered by the existence of a collection composition for that specimen ID
12

IPS is tricky because the lab section is really a very cut-down ‘take’ of Diagnostic lab report. I donlt think wecan use the same approach as we did with e.g Allergies, where we can reuse a Section template in both the IPS summary template and the Allergies template.

We probably have to hardwire the IPS lab section, and populate via AQL.

13

That makes sense to me and pretty well what I was intending. The addition of Specimen collection as a seperate process is helpful - I’ll put that into the use-case