Stream: v2 to FHIR
Topic: v2 Profiles
Grahame Grieve (Oct 11 2019 at 09:22):
I'm a little out of touch with v2 methodology. what's the best way to describe a set of OBX segments in an ORU message, and what they look like. in other words, an equivalent to FHIR profiles. It's still chapter 2.something, right? the conformance thing that's proposed to move to it's own chapter? (@Frank Oemig). What kind of tooling is there that supports this format?
John Silva (Oct 11 2019 at 10:50):
@Grahame Grieve - yes, Chapter 2, section "Conformance using Message Profiles" http://www.hl7.org/implement/standards/product_brief.cfm?product_id=191 (see http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185 for all the V2 document artefacts -- including Implementation Guides for how to 'do V2 Message Profiling'. ) At one point there was also a registry of (public) conformance profiles too, similar to FHIR. See also: https://wiki.hl7.org/Conformance_Profile
Grahame Grieve (Oct 11 2019 at 11:12):
So my memory is faulty here - it’s a while that I played with that, but can I specify a set of segments but not a whole message?
John Silva (Oct 11 2019 at 12:54):
@Grahame Grieve - I also don't remember the specifics but I believe the idea was to specify a whole message (actually a set of messages as part of a 'dynamic profile' or message exchange). I believe segments or segment groups were not profiled individually though tooling (like MWB) would allow you to reuse these as part of multiple profiles. There was also a V2 Conformance ProfileRegistry that HL7 maintained (not sure if it still lives) but that was (I believe) only for complete message profiles (static and dynamic together).
René Spronk (Oct 11 2019 at 14:45):
v2 chapter 2B. The public registry is mostly empty, bar a few test profiles. The XML format specified in 2B is supported by multiple tools. MWB, probably the NIST v2 tools, and some commercial tools as well.
Grahame Grieve (Oct 11 2019 at 16:40):
I recall that MWB allowed you to profile segments or segment groups. I recall too that the format was MWB Special. But I don't want to profile either of those, I want to profile set of segments that isn't a formal segment group
Craig Newman (Oct 11 2019 at 17:17):
Recent v2 IGs have all included message level profiles, not just segments or segment groups (although they include those as well). the NIST IGAMT tool (https://hl7v2.igamt.nist.gov/igamt/) is what I've seen used lately. I've never tried to use it to profile outside of a message so I don't know if you can do it. That tools does support "co-constraints" tables which allow you to specify constraints on the OBX segment based on the OBX-3 value (OBX-2/OBX-5 data type, value sets for coded concepts, etc) if that's what you need to do.
John Silva (Oct 11 2019 at 17:49):
MWB had its own 'internal format' but it supported exporting to the HL7 Conformance specified XML format; that was how folks originally created profiles to upload to the HL7 V2 Conformance Registry. I believe NIST took over this function at some point but I have lost track of where it stands now.
Frank Oemig (Oct 12 2019 at 09:08):
NIST ist providing IGAMT as an authoring tool. It also allows for defining profile components, and providing it as a library (@rsnelick).
IGAMT further developed the profile XML format originally untroduced with MWB.
Grahame Grieve (Oct 13 2019 at 03:17):
but it's not standard?
John Silva (Oct 13 2019 at 11:50):
@Grahame Grieve It appears that the XML profile format is Normative, from what is written in HL7 V2.5 (what I had handy) in Chapter 2.19:
"The message profile DTD and schema are both included here. The message profile schema is normative in order to express the rules by which the registry will validate."
The XML Schema and DTD are defined in 2.19.1 and 2.19.2 respectively.
Frank Oemig (Oct 14 2019 at 10:45):
The format is part of the standard. We are currently working on separating it out so that it is applicable to all versions.
Well, it already is, but there is some perception that it version specific. We want to get rid of that.
Grahame Grieve (Oct 15 2019 at 08:27):
so there's no way to have a profile that describes a set of OBX segments without describing a message?
Rob Snelick (Oct 15 2019 at 15:28):
@Grahame Grieve The v2 conformance methodology is now a separate (independent) specification and applies to any v2 version. That is, you use this methodology for profiling regardless of the version of your message. This was submitted in the September 2019 ballot (a normative ballot is planned for January 2020). Many new profiling features have been added including co-constraints which allows you profile a group of OBX segments and dependencies among elements. NIST IGAMT supports this construct in the context of a message profile (although it should be straight-forward to peel off). A second generation of IGAMT (IGAMT-2) will support independent co-constraints (meaning that they can be profiled, exported, and validated “on their own”). The construct will also have a richer set of capabilities that include setting a trigger at a higher level (e.g. OBR-4), groups, usage and cardinality of the segment instance tied to content, etc.—things like “if I see this OBX segment with this LOINC code then I require these two OBX segments in this OBX group with these characteristics”.) This update is a few months away. The goal is to support at minimum the Message Mapping Guides (excel) developed by the CDC Case Notifications team. IGAMT is following the XML schema in the balloted specification (that maintains backwards compatibility).
Vassil Peytchev (Oct 15 2019 at 19:30):
If this related to a v2 to FHIR mapping, it is very likely that you will need the whole message to accurately map OBX fields to the corresponding resources.
Grahame Grieve (Oct 15 2019 at 20:59):
actually, it's not. It's related to the reverse
Grahame Grieve (Oct 15 2019 at 22:20):
it sounds like I really need to IGAMT thing but maybe I can make do with out in the short term
Grahame Grieve (Oct 15 2019 at 22:20):
thanks
Frank Oemig (Oct 17 2019 at 08:34):
In Germany we habe insurance profile components described to be used with all ADT messages, independent of message structures and events.
You identify its inclusion in MSH.21.
Last updated: Apr 12 2022 at 19:14 UTC
