Stream: v2 to FHIR
Topic: v2 version in a FHIR resource
Craig Newman (Mar 11 2019 at 14:11):
When converting a v2 message to a FHIR message bundle, is it helpful to retain the v2 version (eg v2.5.1) somewhere in MessageHeader? If so, is MessageHeader.implicitRules the best place? The definition of implicitRules is "A set of rules under which this content was created" which is true about the content of the original v2 message but may be confusing in the context of a FHIR message.
If this is the best place, what should the uri look like? Something like "hl7.messageVersion.v2.2" or just a pointer to the HL7 product brief (https://www.hl7.org/implement/standards/product_brief.cfm?product_id=139) or do we create a value set and bind it to implicitRules?
We've created a gForge ticket (20523) to track this question.Thanks
René Spronk (Mar 11 2019 at 15:14):
Provenance would be a better way to capture this information. The 2.x message would itself be subject to a set of (unidentified, implied) messaging rules. A FHIR resource being sourced from v2.4 or v2.7 wouldn't tell me anything. The rules used to create the contents of that v2 message, the context of the sender of the v2 message, now that would be of interest. But most of that is provenance.
John Silva (Mar 11 2019 at 19:20):
Hm, that sounds like the V2 Conformance Identifier, i.e. MSH-21 (Message Profile Identifier) ?
Grahame Grieve (Mar 13 2019 at 20:53):
MSH-21 maps to resource.meta.profile. if version really mattered, it would be the same - something like http://hl7.org/fhir/v2/StructureDefinition/ADT-A01|2.5
Hans Buitendijk (Mar 18 2019 at 14:57):
Agreed that message profile (MSH-21) is not Provenance, rather resource.meta.profile. But version could be considered the most basic message profile (albeit it wildly flexible and variable as pretty much any base standard version that is open to interpretation), so why would that not then be communicated in the same place and consolidate that? Note I don't have a firm opinion either way.
René Spronk (Mar 18 2019 at 16:13):
Mmm. The fact that a v2 message complies with profile/IG X, doesn't mean its FHIR transformation complies with profile/IG X. The transformation agent may have done all sorts of things, both constraining the data present as well as enriching it in all sorts of ways.
One could define a profile for "the v2.5 to FHIR message mapping as done by transformation agent XYZ using its mapping definition ABC" - but then those details are typically something captured in Provenance.
Hans Buitendijk (Mar 18 2019 at 16:49):
I can see the need for a "was mapped according to V2-to-FHIR Profile XYZ" in addition to a statement that preserves the original V2 message having been mapped to "message profile ABC", but still don't understand why the original v2 message would be through Provenance. Shouldn't resource.meta.profile then be on Provenance rather than on MessageHeader as well? What do you see as deciding that? Not sure what attribute would be used on Provenance otherwise.
Hans Buitendijk (Mar 18 2019 at 17:19):
As a related question to @Grahame Grieve on use of resource.meta.profile, should that then be valued on every resource in the message bundle (or whatever it is transformed into)?
Grahame Grieve (Mar 18 2019 at 21:53):
don't know. I think Rene is fundamentally right; the fact that the source was in some particular v2 version is properly stated on the provenance, it's not a fact about the resource itself.
Hans Buitendijk (Mar 18 2019 at 23:50):
Question is then where on Provenance? meta.profile would need seem right as that is about the Provenance resource, not about what the Provenance is about. And it would have to reference all resources reflecting that message. Starts to sound like an extension to be used when a v2 message is transformed.
Grahame Grieve (Mar 19 2019 at 02:05):
it's further information about Provenance.entity.what - is it necessary? why is it necessary? It's not enough just to reference the source so interested parties can go find it if they want?
Hans Buitendijk (Mar 19 2019 at 15:45):
Not sure what resource would represent the v2 source. entity.role would be clear "derivation", but what would you put in entity.what? Regarding why it would be necessary would be two-fold:
- documentation purposes only.
- identify the message format for any application level acknowledgement that needs to travel back.
Neither are very strong reasons, hence at most an extension, certainly not core. It would be best to do that in entity, but since entity.what is required, that would not work.
Note that wherever we decide not to map (yet), we just put in "Who is using this?" so as soon as somebody has a clear use case (in this case, they need to have a way to understand what version of v2 to use on a return acknowledgement for example) that then we move forward. Still, it then would be good to already know where/what.
John Moehrke (Mar 19 2019 at 15:49):
I am jumping in late, so might not have the whole scenario understood... What you are looking for is a place to save the 'how' data was transformed? That would be Provenance.policy. You might have a structureDefinition at the end of the URI, but it is a URI so can be placed in to .policy.
John Moehrke (Mar 19 2019 at 15:52):
This is how it is used in IHE where a document (might be CDA or anything) is decomposed into various FHIR Resources. Thus the policy indicates this.
John Moehrke (Mar 19 2019 at 15:53):
note that there is also a recommendation that the software used for decomposition be described in an .agent. Likely just as a Device resource. But by describing it detail with version and such.. one can tell which derivations might be faulty if that software is found faulty.
John Moehrke (Mar 19 2019 at 15:55):
https://github.com/IHE/fhir/blob/master/StructureDefinition/IHE_QEDm_Provenance.xml
Hans Buitendijk (Mar 19 2019 at 16:00):
Nope. Looking for a spot to have express MSH-12. MSH-21 is fine. When we get to SFT (what was used to transform along the way) surely we'll look at agent and entity for that. But this topic is about maintaining what the version of the v2 message was that was in play to create the FHIR resources. So really about maintaining information about the format (MSH-12 plus MSH-21 ultimately) to traceability and understanding.
John Moehrke (Mar 19 2019 at 17:57):
so you don't want to just stuff the received v2 message in a Binary, and reference that in .entity.what? possibly needing a DocumentReference to express minimal metadata to make that binary understandable? Or using DocumentReference with the message inline?
John Moehrke (Mar 19 2019 at 17:58):
hence what is documented http://build.fhir.org/provenance.html#6.3.4.5
Hans Buitendijk (Mar 19 2019 at 18:00):
Interesting thought. I'll run that by, but that was not the original idea. Not sure we need to go to that "extreme", but there may be a use case that may need that, so will certainly hold on to the link. We were just thinking simple version of the source message.
Grahame Grieve (Mar 19 2019 at 19:12):
just stuff the received v2 message in a Binary, and reference that in .entity.what
yes, except that I would not actually do the stuffing, just imply that it had happened in entity.what
Hans Buitendijk (Mar 19 2019 at 19:16):
How would you "imply" that, as mostly that would be sufficient? What resource would hold the "implication"? Conceptually with you, but not sure what to use to express that.
Iryna Roy (Mar 22 2019 at 18:20):
Dear V2 implementers, I probably have a similar question: I have a FHIR based middleware component that connects either FHIR or HL7 V2 based source systems to (again) FHIR or HL7 V2 target systems. I need to send HL7 V2 message somehow inside FHIR resource (without V2 transformation) - what resource would you recommend? Provenance? MessageStructure? Just Bundle? anything else? I can parse / populate FHIR anything but I need to preserve the actual V2 in the message somehow - ideas?
Hans Buitendijk (Mar 22 2019 at 18:45):
@Grahame Grieve Can you clarify how you would express "v2.5.1" in entity.what?
Hans Buitendijk (Mar 22 2019 at 18:47):
Regarding Iryna's question, if we want to get the V2 message across as-is using FHIR as the vehicle, I'm wondering whether using MessageHeader and DocumentReference would be sufficient, if not just DocumentReference. Curious about @John Moehrke 's reaction. It would in this case not be Provenance as we're not trying to indicate the origin/source of the FHIR construct.
Grahame Grieve (Mar 22 2019 at 20:59):
why is the v2 message there? is this just for audit purposes? or is it the focus?
Grahame Grieve (Mar 22 2019 at 21:00):
I would just refer to the source message in entity.what. You'd have to go look at the source message to see what version it was. Why else would you need to know?
Hans Buitendijk (Mar 22 2019 at 21:12):
Since we are mixing two purposes here, holding on to the v2 version of the source v2 message that was used to construct the FHIR resources (starting point of this thread) vs. the v2 message being the payload of a FHIR based exchange as the focus (Iryna's addition). Perhaps we should split that conversation.
So to Grahame's question as to why to hold on to the v2 version in Provenace would be on the return trip to understand what format to respond. One could argue that at the time of that transformation the two parties have an agreement, so no need to really track it, for that purpose. Fair argument. But for audit purposes it is still helpful documentation as the original may have already been purged given the life time of a message. Sending a binary of the original v2 message, as John Moehrke suggested, may be overkill, but still helpful to indicate how to do if you really want to, while having to look up a potentially purged message is not that great either. So simple text string with the value would be fine. I'm not arguing for an addition in the core necessarily. But if entity.what is required adding an extension without valueing entity.what would not work either (unless we create the extension outside of entity.
Grahame Grieve (Mar 22 2019 at 21:20):
in order to construct a proper v2 response, you'd need information that isn't in the FHIR response, I think. I would expect to the have the v2 request around at the same time as converting the response
Grahame Grieve (Mar 22 2019 at 21:20):
and I would not expect the provenance to echo back with the response. So I don't think it's a solution at all
Iryna Roy (Mar 22 2019 at 21:22):
In our solution we may auto-generate the ACK once the V2 message is received by an adapter. An adapter then creates a FHIR resource with the V2 inside. Our V2 messages are notifications only. The source system does not expect the processing result. We may specify the source system in a fhir resource.
Iryna Roy (Mar 22 2019 at 21:23):
I tried to read the Provenance description in the specification and got totally lost :)
John Moehrke (Mar 22 2019 at 21:26):
I think both preseving and non-preserving are useful. I was just describing how preserving links back through Provenance.entity... but I could also understand just using the timestamp as an indicator of the inbound message.
Hans Buitendijk (Mar 25 2019 at 16:04):
I'll put back into the v2-to-FHIR team:
create a Provenance instance where Provenance.target(MessageHeader) references the message header at hand; when the transformer of v2-to-FHIR holds on to the original v2 message that they maintain a link between the MessageHeader.identifier and MSH-10/etc. for any return messaging; when the transformer does not hold or the return may go through a different party, then put the binary representation of the v2 source message into Provenance.entity.what(Binary); don't bother with the putting MSH-12 value into a dedicated Provenance attribute.
Does that sum it up?
David Hay (Mar 25 2019 at 18:03):
btw - do you have a page where you're documenting all this stuff?
Hans Buitendijk (Mar 25 2019 at 18:40):
This will go to the MSH page that is connected to this overall project page: https://confluence.hl7.org/display/OO/2-To-FHIR+Project. Go to Segments/Fields, then MSH. I did not copy it yet though........:)
Last updated: Apr 12 2022 at 19:14 UTC
