Stream: v2 to FHIR
Topic: Mapping v2 to FHIR
shouvik das (Sep 06 2021 at 12:50):
hello is there a way to convert FHIR resource back to hl7V2?
Lloyd McKenzie (Sep 06 2021 at 15:56):
@shouvik das Please start a new 'thread' when you're starting a conversation. For example, this thread name was "Mapping CX to Identifier". I'm renaming your part of it with admin powers to avoid confusion for others, but it's best if you pick an appropriate name at the start.
Lloyd McKenzie (Sep 06 2021 at 15:58):
First, take a look at the v2 to FHIR IG. Then do a search here. Short answer is there'll be a starting point, but you'll have to write code that's specific to your particular v2 implementation because v2 implementations vary so much.
Craig Newman (Sep 07 2021 at 12:34):
And the v2-to-FHIR project is focused on that direction (v2 to FHIR). Some of the mappings may be useful for going from a set of FHIR resources to a v2 message, but it hasn't been a goal of the project, so there may be some gaps.
Brian Postlethwaite (Nov 17 2021 at 21:01):
We've seen quite a few requests for new extensions coming in for v2 concepts that aren't in FHIR as yet and wondering if for some concepts that we don't think are in use, but need a bucket for these, should we just create a generic v2 "forward port" extension format?
E.g. fhir#31501 is talking about a living will indicator, instead of creating a new standard extension for this, use a specific format - and what information would you need to have in that? event+message+field (as some fields have slightly different meanings - complete set, or partial, or set applicable in specific context) as that could then change how it is then used in the FHIR space.
(This all being said, I do think we should be considering the properties as we have been, and creating new standard extensions where the meaning/intension/actual usage is clear)
René Spronk (Nov 18 2021 at 08:37):
So when should we define a 'standard extension' vs. when should we leave this to a project to define their own extensions? Clearly if we (as the HL7 community) don't recognize this as a [frequently used] scenario it probably shouldn't become a standard extension.
Lloyd McKenzie (Nov 18 2021 at 14:18):
Another consideration is how well understood/consistent we expect the value to be. If we can't count on the meaning, having an extension seems of limited use unless our objective is to have FHIR be an intermediary between two v2 interfaces (is anyone doing that??)
Hans Buitendijk (Dec 06 2021 at 14:45):
There are three approaches we are pursuing:
1) worthy of a core attribute as it was forgotten or just had not come up yet in FHIR based use cases - core addition - Example may be the observation-specimen relationship where cardinality has to be addressed in the core unless it gets too clunky.
2) it is a minority use case, but within that use case it needs to be done consistently - standard extension. Example may be the living will indicator are student indicators that have limited use, but when used have to be consistent. Another example is to maintain original meaning where FHIR opted to go to a required code, whereas v2 has more granular capabilities with CWEs.
3) it is very unique to v2 construct that you would never use in FHIR - IG extension Example: OBX-4 needs to be preserved in FHIR as the mapper may not have enough knowledge about OBX-4 syntax to know how to structure the relationships (the true destination does).
I'm not aware of anybody using FHIR as an immediate intermediary for v2 to v2 messages, but you never know what somebody does when they use v2 to FHIR, persist it is some form, and then include the data again in a v2 message. All bets are off on that one.
But with the above, it is clear that every gap between what is actually used in v2 (keep in mind, we are not mapping just the full standard, only those elements that are known to be used in production somewhere) needs to go through the above triage and then worked out with the resource owner whether it is worthy of 1), 2), or 3).
Last updated: Apr 12 2022 at 19:14 UTC
