Mapping/Modelling the sending application (i.e. MSH.3 in HL7 v2) as a composition context

Integration
1

Hi there,

we have the use case, that for integrated data a user might want to filter all data sent from a certain application.

For this, I’m looking for best practices on how to model the sending application of a message (in v2 that would be the content of MSH.3, in FHIR most likely in the meta.source field).

The first idea was to put it into the RM of the context of a composition (EHR Information Model).
However, the only path available there seems to be to define an archetype and make sure to have it in the “other_context” of every mapped composition.

Now my questions are: Did I miss a good (standardized) option to persist the sending application of integrated data?
Has anyone found an elegant way to do this already?

2

Would that not be exactly what

FEEDER_AUDIT. originating_system_audit. system_id is for (Common Information Model )

A FEEDER_AUDIT can be attached to every LOCATABLE (Common Information Model)

3 Likes
3

Hi Annika,

There are 2 options.

  1. Do what you are suggesting and create a Cluster archetype which captures the MSH header in a structured format

In our lab mappings, we only took in /ORU_R01/MSH/MSH.3/HD.1/text() as COMPOSITION.composer.

  1. Use FEEDER_AUDIT (probably the ‘correct’ approach).

Every archetype node has an optional feeder_audit attribute that can be populated at runtime with this kind of low-level background technical info, including an ability to just capture part or all of the original message. It is queryable via AQL.

You can pull out key data like identifiers, time, and organisation info into the feeer_audit structure as queryable items then just put the whole snippet of message under original_content.

2 Likes
4

@annika.merkt realise I mis-read and was thinking you wanted the whole MSH object - I completely agree with @stefanspiska

5

@stefanspiska and @ian.mcnicoll Thank you both very much for swiftly curing my bad case of “need to read the docs” :see_no_evil:
(and directly inside the locatable - shame on me and thank you again!)

6

Donl’t worry , we have all ‘been there’!!

One of the great ideas in openEHR is that it hides low-level obscure aspects…
One of the bad ideas in openEHR is that it hides low-level obscure aspects…

LOCATABLE is actually the key class from which most of the archetyping magic happens and where obscure but useful things like LINK, FEEDER_AUDIT and .name appear.

1 Like