Stream: IG creation
Topic: Using IG Publisher to publish V2+
Michael Faughn (Oct 08 2021 at 19:02):
There is an ongoing effort to transition v2 from MS Word to a computable standard. Thus far, I've extracted the content of the Word documents and distributed them to (a lot of) resource instances. I'm quit sure that much of what I (we) have done would make some people cringe. Aspects of it make me cringe. I won't get into the details unless someone asks. Part of the stated intention of V2MGMT is to be able to use IG Publisher to produce the v2+ web publication. The ballot for comment version that was on the January ballot was not created using IG publisher. I used tooling that I built and consumed the aforementioned FHIR resources to produce what, to a large degree, looks like the HTML that is produced by IG Publisher.
Now that I've had some time to work with things and get to know the problem set I find myself wondering if IG Publisher really is (or can be) a good fit for publishing v2+. It seems that there is a fundamental difference between v2 and FHIR with respect to the classification. It may be somewhat incorrect of me to do so but I'll liken every FHIR resource that is defined using a StructureDefinition instance as being, more or less, a classifier. StructureDefinitions define types and typically have a super-type. All types (or almost all) ultimately trace back to Resource. This doesn't work easily for v2. If, for example, we think of all of the segment definitions in v2 as representing different types (i.e. something you want to define and be able to instantiate instances of) that all conform to some meta-type that defines the structure of all segment definitions. The only way I can think of doing this in FHIR is to create a StructureDef for SegmentDefinition and then to profile it for every type of segment. This seems unwieldy at best. At worst it may be quite terrible. I suspect that it doesn't magically solve all of our problems either.
Of course we could just eschew the definition of any meta-types that governed the structure of segment definitions, message structures, and other v2 elements. I think that information is important and useful though and that it would be a mistake to not have it.
What I'm wondering is if I'm generally correct about there being a fundamental impedance mismatch that makes using representing v2 using FHIR difficult. Am I missing something. Is there some other way to use FHIR that would facilitate the expression of v2 using FHIR? This isn't the only difficult aspect of using IG publisher to publish v2 but I think it is the most critical one. We're at a point where we need to make some firm decisions about how we proceed. Any insight from the wizards of FHIR would be rather welcome.
Note: If you're reading this and thinking that anyone is trying to create FHIR resources for v2 that would interoperate with any of the normal FHIR resources...rest assured, that is not at all what we are proposing. We're simply interested in using FHIR methodology and tooling to express another standard. Any expression of v2 as FHIR would be completely segregated from the rest of FHIR.
Lloyd McKenzie (Oct 08 2021 at 19:55):
@Michael Faughn I don't think the intention was to treat segments as 'profiles'. I think the intention was to treat each segment as its own logical model. The type hierarchy would be completely flat - no ancestors, all segments as flat 'children'. You definitely wouldn't inherit from Resource. (I suppose if you wished, you could have an abstract 'interface' pattern similar to "CanonicalResource" that might help in grouping the segments as distinct from the data types as distinct from the message structures.)
The profiling of v2 (if there is any) would be equivalent to the artifacts produced using the conformance mechanisms defined in chapter 2.
@Grahame Grieve?
Michael Faughn (Oct 08 2021 at 21:07):
I'm not suggesting that we have treated segment definitions as profiles, just that that was the way I thought FHIR could be used to both define individual segment definition types while retaining some definition that described the constraints on and properties of all segment definitions. I'm not at all enamored of using profiles to do that, even though I think you might be able to. What I wanted to do was closer to having the flat field that you describe. That has its drawbacks as well.
I think it would be quite valuable to have some computable definition of "how you build a segment definition". And for that definition to inform / constrain / guide the definition of all segment types. In fact, we created StructureDefinitions for SegmentDefinition, MessageStrucuture, etc. and, thus far, have represented each actual segment definition and message structure definition as an instance of SegmentDefinition and MessageDefinition, respectively. I wasn't in favor of that approach but that is what we did. There isn't a whole lot you can do with a pile of instances of SegmentDefinition. What I'm stuck on is wanting StructureDefs for each type of segment. But also something that constrains those StructureDefs. A MetaStructureDef? Arghh.
Our StructureDefinitions for SegmentDefinition and MessageDefinition have baseDefinition valued as something that eventually does trace back to Resource. Is there some reason why we wouldn't do that?
Ideally, I don't think a SegmentDefinition type would be a supertype for, e.g., MSH, OBX, etc., but would be more akin to being a metamodel element. Using a CanonicalResource-like interface pattern might getting us some of what we want simply by treating it as a tagging interface but would be a bit of a weak kludge. We want to do things like build widgets for editing segment definitions and message definitions. The StructureDefs we have now for SegmentDefinition and MessageStructure are things that could drive that. Of course that specification of "what is a segment definition" doesn't have to have a relationship with the any of the definitions for actual segment types but it sure would be nice. It seems less useful to have, e.g., a StructureDef for the MSH Segment that doesn't "know" it is or otherwise can't be identified as a SegmentDefintion.
Lloyd McKenzie (Oct 08 2021 at 23:37):
I don't know that you want to inherit the stuff Resource has - like 'meta', 'language' or 'id'. You could certainly have profiles on StructureDefinition that set expectations for what 'segment' instances look like as opposed to 'data type' instances.
Grahame Grieve (Oct 21 2021 at 02:25):
@Michael Faughn getting to this - sorry it took so long.
I certainly expected that you'd have a structure definition for each segment / data type / message structure as a StructureDefinition, in the way Lloyd described. And I anticipated that they'd inherit of Base, not Resource, (see Base in R5) because you wouldn't want all the overhead from extensions / etc.
You could, as you say, define a single structure for 'segment' and then profile it. But I would say, that's going to be a very difficult way to go about things. What would doing that give you ? There is ways to do a 'meta-segment', but which way to do it would depend on what you wanted to achieve by doing it
Last updated: Apr 12 2022 at 19:14 UTC
