I’m wondering how implementers are sending/committing COMPOSITIONs to their openEHR EHR implementations.
A little context about what I’m doing right now:
I’ve implemented an openEHR Service-Oriented (REST) repo that accepts commits of COMPOSITIONS in XML
I use flat archetypes to define those COMPO’s (i.e. one archetype with all slots resolved, so it’s auto-contained)
Now I’m changing the flat archetypes for OPT support, yay!
The XML accepted by the EHRServer have “version” as the root node (VERSION contains one COMPOSITION).
The commit is composed by an EHR_ID and an array of VERSION.
I was thinking of adding more info to the commit so the EHRServer can keep a better log of the messages received and the sending applications, something like the MSH in HL7v2.x or like the Transmission Infrastructure Domain Model of HL7 v3 (basically info about sending and receiving apps/devices and facilities, info about the protocol e.g. the ACK mode, id of the message, date, …).
What information do you send in your commits?
Do you send more info for tracking & logging?
Did anyone mix the commit with HL7-like communication info?
It would be very nice to know your thoughts, thank you!
I was thinking of adding more info to the commit so the EHRServer can
keep a better log of the messages received and the sending applications,
something like the MSH in HL7v2.x or like the Transmission
Infrastructure Domain Model of HL7 v3 (basically info about sending and
receiving apps/devices and facilities, info about the protocol e.g. the
ACK mode, id of the message, date, ...).
Not sure if there is a need to include this type of data within the structure that bears the COMPOSITION as it is irrelevant to its content.
You can still keep track of those data at server side by examining sources such as protocol headers and store those to entities that are in place specifically for monitoring.
Hi Pablo,
I may be wrong, but I’m getting the impression that you are considering the extra data you’re talking about as something that is outside the composition. It can certainly be processed that way, but the openEHR spec has significant consideration for this type of information. The context, composer, setting fields of your composition would let you keep a lot of information. We keep sender system ids etc in these fields regularly. If this is what you meant, then you may consider asking more specific openEHR modelling questions, as in, ‘how do I represent this hl7 id in a composition?’ etc. If you’re talking about some out of openEHR mechanism, you may not need it, keeping things within openEHR would help you make them available to queries in a more consistent way plus all the other benefits where you’d like to have interoperability.
There is a limit to what you can model within openEHR of course, and if you start talking about logging etc, then you would probably like to consider mechanisms which are not necessarily specified in the specs. My personal opinion is that there is always some non openEHR functionality an implementer would have to support: audit, some demographics, terminology services etc. You have to set priorities though as an implementer, add these things on top of your EHR related functionality as use cases arise. If you try to develop in advance for everything you can think of you’ll have a loooong journey ahead
I agree with the comments so far questioning whether you really need
to store this within the openEHR composition but if you did need to do
so, you should have a look at the feeder_audit attribute available to
any LOCATABLE node, including the root node of any archetyped data.
There is also a lot of information in the 'common' specification document.
I suspect you know all this already but others lurking might find it useful!
My question is not about what to put IN the COMPOSITION, is more about the COMMIT itself. I need to know how others do things to try to be closer as possible to current implementations.
Inspecting lower layer protocols, means that the system might need to have and maintain a mapping between systems (application level concept) and IP/port/User-Agent and other HTTP headers (comm level concepts).
I think the idea from HL7 was to have information at the application layer and not rely on lower layer protocols, because in the middle you can have several components that can change the original IP/port/headers, etc.
Yep, is not about data IN the composition but WITH the composition in the commit transaction.
What I really need is to know, from real world implementations, if they needed more info besides ehrId and composition versions while committing data to the EHR.
Also, as you mentioned, it would be nice to know, if for that data, they used (or abused) the openEHR model to carry other kinds of data (communication related, logging related, audit, traceability, etc), or they just extended the model to carry that data (the model or just the XML schema).
E.g. anyone use a transaction/message ID to keep track of commits? (in HL7 that’s part of the message).
