Stream: implementers
Topic: Use of Must Support in US Core
Mark Kramer (May 20 2019 at 19:41):
I'm developing an IG for USA, and the expectation by business leaders is that it should be comply with US Core. However, the must support (MS) markings in US Core are more extensive than those required by the use case. We are also trying to use the Genomics IG, where _virtually everything_ is plastered with MS markings, and 90% of it is irrelevant to my use case (for example, see http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/diagnosticreport). Do you think it right for an IG to specify MS in the absence of a specific use case? It seems to me that the MS should only be specified with respect to a specific, concrete use case. Comments?
Dave deBronkart (May 20 2019 at 19:49):
My limited experience in another industry was:
- Yes, this is a valid issue
- But it gets wildly uncontrollable if people start deciding "I don't need this so-called 'must' thing" because others downstream will, sure as you're born, someday assume that everyone has of course done all the musts
- Ergo, it's infinitely better to formally create a well thought out subset, which you can declare.
But that was another industry so maybe not appropriate here.
(Is it possible for an implementer to declare "I ignore the following musts"? I can imagine the shrieks on conference calls if that were proposed out loud... among other things, "So what should I assume are your values for those things?")
Lloyd McKenzie (May 20 2019 at 19:51):
The challenge we face is that US Core and Genomics IG do have specific use-cases. (Meaningful use EHR capabilities and lab reporting of genomic data, respectively). However, other IGs that might wish to leverage the same content may have use-cases that don't require the same degree of support. We don't want to split the existing IGs into two (which adds complexity for both readers and maintainers. And we don't want to loosen the requirements - the elements are indeed intended to be 'mustSupport' in the context the IGs were created for.
In Montreal, we discussed the notion of being able to depend on IGs, but have a flag in the dependency that says that they do not inherit mustSupport elements of other IGs. However, we didn't have consensus on this and more discussion is necessary.
Hans Buitendijk (May 20 2019 at 20:28):
For any IG to be testable, the test tools must reflect what the conditions/constraints of the implementation guides are. It cannot constrain more, or less, as then it effectively is creating a new implementation guide. Applying that consideration to US Core, at the top it should be as open, least constraint that fit any possible use case for the US, so specific use cases can then constrain further. For example, as not all HIT needs to support Implantable, or more generally UDI Devices, the Device profile at the top should not have a MUST SUPPORT on those elements that are only relevant for fully UDI device support (mostly implantables in the US at this time, but expected to expand rapidly). So unfortunately, either some have to be loosened so they can be constrained by subsequent IGs, or alternative profiles are created that specific use cases/IGs can clearly specify which one(s) are to be conformed to. Without such stratification, we are only pushing the issue down to the test tools, which then have to declare which use cases they support, thus are creating an IG. And further, specificity will have to go down to the data type component level as everything optional will yield otherwise different, incompatible choices where it actually matters. Note that this is of particular importance where the test tools are used in certification testing where MUST SUPPORTs will be tested and may force systems to build support for components that are not relevant to them.
Grahame Grieve (May 20 2019 at 21:42):
We don't want to split the existing IGs into two (which adds complexity for both readers and maintainers)
is there a view problem here? Maybe we should split Must-support out of the profiles and push it into a use-case analysis. I could imagine an IG including a table of must-support for different use cases
Hans Buitendijk (May 20 2019 at 21:46):
If we can stratify profiles and put in views based on use case which profile(s) apply, that would be very helpful. And not be worried about that the number of profiles will increase. That's o.k.
Lloyd McKenzie (May 20 2019 at 22:18):
IGs are created for a particular use-case. mustSupport is part of that. If you want your instances to comply with that IG, but not to impose the same support requirements, you're going to want a distinct IG, but deriving from the base IG (less mustSupport expectations) is the correct solution. It will create a great deal of confusion if IGs created for one purpose have to include documentation about a bunch of other (and non-relevant to the authors) use-cases.
Ewout Kramer (May 21 2019 at 08:39):
We don't want to split the existing IGs into two (which adds complexity for both readers and maintainers)
is there a view problem here? Maybe we should split Must-support out of the profiles and push it into a use-case analysis. I could imagine an IG including a table of must-support for different use cases
We did discuss this option in Montreal - as there is a clear usecase where people want to reuse the data definition part of a profile within their IG for their usecase, but not necessarily the conformance part that came with the profile (and that came from conformance demands in the original IG the profile is used in). Interesting to see that US Core is an immediate example of this. It seems clear to me that we need to separate the conformance part from StructureDefinition. However, as Lloyd stated, there was no consensus in Montreal on how to achieve this goal.
Lloyd McKenzie (May 21 2019 at 08:44):
The how is pretty easy - add an extension to the "depends on" relationship that indicates that behavior. What we didn't have consensus on was "should we?"
Ewout Kramer (May 21 2019 at 08:53):
No, it's not that easy. It's not "depends on". It's about moving mustSupport information out of StructureDefinition - that was one of the options we discussed at least.
Grahame Grieve (May 21 2019 at 09:44):
actually, there's a 3rd option - leave it where it is, and allow it be used, but also create a special kind of profile that does not change the structure, just sets must-support expectations, and links to an ExampleScenario
Grahame Grieve (May 21 2019 at 09:45):
that can get appropriate representations .... so it doesn't weigh on the use of the profile. but if the profile still wants to set must-support (which is normative, after all) it still can
Eric Haas (May 21 2019 at 13:46):
What does 0..1 mean in a profile then. The are zero expectations around it. I wish I could have made that quarter at montreal. But maybe to must support def should be in the ig cap statement for that actor.
Eric Haas (May 21 2019 at 13:47):
We
Eric Haas (May 21 2019 at 13:48):
It clear to me that there is need for A v2 RE. In an ig and otherwise there is only mandatory and optional
Brett Marquard (May 21 2019 at 16:10):
However, the must support (MS) markings in US Core are more extensive than those required by the use case.
@Mark Kramer Do you mind listing a few examples of where US Core is too extensive? I am not surprised it is in a few places but Must Support is intended to allow systems to not send if they don't have -- and we did our best to be careful on where we added.
Lloyd McKenzie (May 21 2019 at 16:41):
ExampleScenario wouldn't make a whole lot of sense - it's just an example of possible flow. And certainly we wouldn't want US Core to have to define their mustSupports separately from the rest of their profile. When you view the profile, you want to see the mustSupports along with everything else (and you want to maintain it that way)
Lloyd McKenzie (May 21 2019 at 16:43):
The issue with mustSupport is that there's an expectation about "must send if you do know it/must be able to receive if sent" and there are systems that want to use US Core as a base for interoperability purposes where the same requirements don't hold (because they're not trying to do full patient record sharing)
Mark Kramer (May 21 2019 at 18:19):
@Brett Marquard Here is an abbreviated list of attributes we do NOT require support for in mCODE: Patient.birthsex, Patient.name, Patient.address (we only need postalCode), Patient.communication, Condition.verificationStatus, MedicationStatement.dateAsserted, MedicationStatement.derivedFrom, DiagnosticReport.encounter, DiagnosticReport.category, DiagnosticReport.presentedForm.
Mark Kramer (May 21 2019 at 18:33):
My analogy is going to the grocery store to get ingredients for tacos. The ingredients are already sitting on the shelf and you pick and choose the ones you need for your recipe (your use case). Many taco ingredients, like beans and ground beef, have uses beyond tacos. By analogy, I think it makes sense to separate structural definitions of profiles (the ingredients) from MS markings (the recipe). Otherwise you will end up needing a huge grocery store that carries "ground beef for tacos", "ground beef for meatloaf" and "ground beef for hamburgers". An IG should be able to pick and choose from existing structures, and apply the MS markings that make sense for its particular use case. In other words, I am supporting separation of MS markings from structural profiles.
Lloyd McKenzie (May 21 2019 at 18:50):
In that case, your issues wouldn't be limited to mustSupport, but also to what's mandatory - and that's not something we've discussed softening. If it's mandatory in the base profile, it has to be mandatory in all derived profiles. If you don't want the mandatory, you can't have a derivation relationship between the profiles.
Mark Kramer (May 21 2019 at 19:23):
Lloyd, I don't see any big problems with required elements; they are usually the minimal set that is needed to make sense of the resource. Eliminate a required element, you usually get nonsense.
Eric Haas (May 21 2019 at 19:49):
Besides doubling everyones time and effort, splitting the profiles defeats the purpose of using a common set of base profiles which is to normalize a set of elements that are likely to be present. Maybe a better understanding the rationale for the decision to use US Core as the base is needed or reconsidering that decision.
Mark Kramer (May 21 2019 at 19:52):
@Eric Haas Despite the label I put on this topic, this is NOT a US Core problem. It is reusing any IG. There are MS labels all over the Genomics IG that we don't need... although DO we want to use the Genomics structures. And, I don't think doing things this way doubles the work. It is the same amount of work, but a different delivery mechanism that puts the MS into a different bucket than the structures.
Lloyd McKenzie (May 21 2019 at 19:58):
I think it's reasonable to want to use the Genomics structures without the Genomics MS declarations. I don't think the Genomics IG should separate its constraint structures and other documentation from MS support declarations (in either the authoring or publication process).
Lloyd McKenzie (May 21 2019 at 19:59):
Though in practice, there will often be lots of descriptive documentation that includes usage rules (which may include SHALLs and SHOULDs) that other IGs might also not want to inherit.
Josh Mandel (May 21 2019 at 22:15):
I'm coming to this discussion late, but I think there's a strong need for use-case-specific "must support" requirements, even though the data profiles (vocabularies, extensions, etc) are shared. Grahame's Australian base (https://build.fhir.org/ig/hl7au/au-fhir-base/) provides an example without (I think) must-support -- but creating a whole separate IG for each use case is beyond what most authors are going to consider tolerable.
Josh Mandel (May 21 2019 at 22:15):
Just in terms of the authoring, publication, and consumption process. Too many URIs, too many files, etc.
Grahame Grieve (May 21 2019 at 22:17):
so I'm still hearing that my idea of profiles that just set implementation expectations on an existing structure make sense
Josh Mandel (May 21 2019 at 22:18):
Yes, as long as
1. the expectation is computably expressed as a MUST
2. there can be several use cases with different MUSTs for a single resource
3. all these can be packaged into a single IG
Grahame Grieve (May 21 2019 at 22:18):
yes though #1 is proving a real challenge on it's own anyway
Lloyd McKenzie (May 21 2019 at 22:18):
4. They can be authored together by IG creators and they can be viewed together by consumers of the original IG
ksrc murthy (May 21 2019 at 22:19):
I'm new to hapi fhir, can I use this in my application and share with clients. Please give response
Lloyd McKenzie (May 21 2019 at 22:21):
@ksrc murthy We're suggesting that you subscribe to the #hapi stream and raise your question there. (Right now you're asking your question in the middle of a thread talking about something else.)
Lloyd McKenzie (May 21 2019 at 22:22):
Just click on the #hapi link and press the "subscribe" button and create a new conversation with an appropriate title for the conversation you want to have.
Grahame Grieve (May 23 2019 at 00:50):
getting back to this
ExampleScenario wouldn't make a whole lot of sense - it's just an example of possible flow
digging into it: no, it doesn't. Do we need a resource to formally describe a use case?
Lloyd McKenzie (May 23 2019 at 00:56):
What would the purpose be of making it more computable than the text pages currently in an IG?
Grahame Grieve (May 23 2019 at 00:57):
at the least, linking sets of conformance resources together to the same use case (even if the use case wasn't formally described)
Lloyd McKenzie (May 23 2019 at 02:49):
They're generally already linked through CapabilityStatements . A set of CapabilityStatements together represent the different actors in a use case. We don't have anything that groups together a set of CapabilityStatements within an IG beyond how they're organized on a page, but I'm not sure they need to be...
Grahame Grieve (May 23 2019 at 03:11):
My experience with IGs is that the linkage between capability statements and profiles is only partially reflected in the stated links
Eric Haas (May 23 2019 at 03:33):
I suggest adding the Must Support definition to the CapabilityStatement /per actor/possibly per resource So in US Core we have a certified EHR/ Server vs Server using as a Base US resource. ( where the must support is pretty light weight - like if you store this element then blah blah blah....)
Lloyd McKenzie (May 23 2019 at 05:00):
You don't want to maintain (or publish) the mustSupports separate from the profile itself. When someone who needs to adhere to must supports looks at a profile, they want to see everything together - element, cardinality, data type, definition and mustSupport - it's all relevant for implementation. And when you're authoring a profile for a specific use-case, you want to maintain the information together too. Separating it is too likely to result in errors.
Grahame Grieve (May 23 2019 at 05:04):
... but: not separating is also a cause of errors. And right now, you can't share structures across different use cases that only differ in must-support obligations. Which is what is actually driving this discussion
Lloyd McKenzie (May 23 2019 at 05:10):
I haven't seen a situation where not separating is causing errors. Implementation Guides that want to re-use have problems, but that's not the same as errors. We can define the content together and still allow it to be stripped off for inheritance purposes.
Jean Duteau (May 23 2019 at 05:47):
We can define the content together and still allow it to be stripped off for inheritance purposes.
Could we just make mustSupport not be inherited by profiles? i.e. each profile must specify the mustSupport separately?
Grahame Grieve (May 23 2019 at 06:36):
we could but that seems like throwing the baby out with the bathwater
Lloyd McKenzie (May 23 2019 at 14:43):
There are some situations where you want mustSupport inherited and other situations where you don't. The referencing profile should be able to chose which it wants based on whether the use-case is a refinement or something different that should just be "compatible".
Jean Duteau (May 23 2019 at 16:11):
Okay, so a flag on the inherited profile on whether you are inheriting mustSupport? As a start, the flag would have your fields of 'refinement' which inherits everything or 'compatible' which only inherits the structure, extensions, and bindings.
Lloyd McKenzie (May 23 2019 at 16:13):
Inheriting descriptive elements (short and long descriptions, usage notes, etc.) is going to be messy. Inheriting constraints would be required.
Mark Kramer (May 23 2019 at 16:59):
A flag indicating whether an inheriting profile is fully compliant (including MS) or only structurally compliant seems like a reasonable and implementable solution
Jose Costa Teixeira (May 23 2019 at 18:32):
getting back to this
ExampleScenario wouldn't make a whole lot of sense - it's just an example of possible flow
digging into it: no, it doesn't. Do we need a resource to formally describe a use case?
Not exampleScenario. We are working to define conformance in sequence of actions (IHE transactions) to explain that in a given exchange or exchange sequence between two defined actors, some constraints (StructureDefs) apply.
Jose Costa Teixeira (May 23 2019 at 18:32):
For that we use plandefinition
Jose Costa Teixeira (May 23 2019 at 18:33):
The inheritance of constraints is also a must-have for ihe
Eric Haas (May 23 2019 at 22:18):
I think these are the issues with not inheriting msut supports:
Eric Haas (May 23 2019 at 22:19):
- how do you validate - does it still validate? I think yes
Eric Haas (May 23 2019 at 22:20):
- how do you test or certify a derived profile? ?? they would need to essentially duplicate the elements they must support and mark as must support. So there is no real benefit there because you can't just inherit.
Eric Haas (May 23 2019 at 22:20):
- what are the expectation for min=0 element? MAY? how do we document this element is here cause we think you should really really use if you need just like this.
Eric Haas (May 23 2019 at 22:21):
- there is no way to way to say anything derived from profile A inherits the must support, but anything not inherited does not. I still think this is wacky because its really hard to say we use case 1 inherit these 5 elements, use case 3 these 6 and use case 4 these 4 elements. And I don't think that is better that building from scratch each time.
Lloyd McKenzie (May 23 2019 at 22:27):
mustSupport never impacts validation - mustSupport always deals with behavior outside the instance.
You would need to list the elements you want to mark as mustSupport, but you wouldn't need to list any of the constraints
min=0 with mustSupport=false/stripped means it's ignorable. min=0 with mustSupport=true means you're expected to support it in whatever manner the profile/IG defines. If you're stripping mustSupport on derivation, you're saying the opinion of the parent IG that "we think you should really really use it" isn't relevant in the derived IG - presumably because your scope of use is quite different.
Not clear on your last bullet. If you're deriving, you can only derive from one profile (and you derive based on the snapshot of that profile - so everything it was based on too). You'll either get the MS flags or you won't. It will mean more work for those who don't want to inherit the MS flags in that they'll have to go through and flag everything they want. But it's still less work than defining a completely independent profile including all the constraints and then trying to keep the constraints in sync with the 'base' profile that doesn't have any formal computable relationship.
Eric Haas (May 23 2019 at 22:28):
- finally if a profile has 3 mandatory and 6 must supports that are stripped of the must supports. There at most 6+5+4+3+2+1 combinations of how use in a derived profile and no way to say which combination you are using implicitly. Is that better or more interoperable? Then say profile B is derived from Profile A (with the must supports stripped) and then comes profile C which derives from Profile B what is profile C inheriting from From A?
Eric Haas (May 23 2019 at 22:29):
(deleted)
Eric Haas (May 23 2019 at 22:35):
ty Lloyd for the responses
Eric Haas (May 23 2019 at 22:39):
(IMO putting a naked min=0 element in a profile is just like a preferred binding - utterly meaningless to a developer trying to meet a deadline.)
Lloyd McKenzie (May 23 2019 at 23:20):
If you put a naked min=0 element in a profile, agree it's meaningless. However, if you add a comment that provides context around the use of that element should an implementer choose to support it. That's still a useful thing to do.
Brett Marquard (May 24 2019 at 15:07):
mustSupport never impacts validation - mustSupport always deals with behavior outside the instance.
In US market Must Support coupled with ONC providing test data does impact validation.
Lloyd McKenzie (May 24 2019 at 16:48):
It might impact testing, but it shouldn't ever impact validation - validation is checking within the scope of an instance only and mustSupport never applies to the instance, it applies to application behavior around the instance.
Eric Haas (May 28 2019 at 23:07):
In a very simple view of an IG we have:
Eric Haas (May 28 2019 at 23:08):
- use cases
- FHIR artifacts
- business rules.
Eric Haas (May 28 2019 at 23:09):
for the sake of argument:
- validation deals with FHIR artifacts
- Must support and things like search requiriments etc deal with business for the use case,
Eric Haas (May 28 2019 at 23:10):
We have a couple of options in my opinion ( as we are dealing with this right now for US Core)...
Eric Haas (May 28 2019 at 23:16):
1) Invent a way to be inherit all the business rules and FHIR Artifacts or only the FHIR Artifacts.
- if you inherit only the FHIR Artifacts you get only the blueprint and if you want to support an "optional" you need to specify in the derived profile in a conformant manner ( e.g. mark and define your own Must Support, or change min from 0 ro 1)
Eric Haas (May 28 2019 at 23:21):
2) Make a naked sibling IG that strips all the business rules off the fully defined IG. And downstream profiles can choose what they want as their starting point.
- For example US Core R4 for ONC Certification and Naked US Core Sturctures for reuse by US Implementers. QI Core may choose the former and Mark the latter.
- when using the naked IG you still need to specify in the derived profile in a conformant manner ( e.g. mark and define your own Must Support, or change min from 0 ro 1)
Patrick Werner (Sep 13 2019 at 17:44):
+1 for Option 1)
Currently the MI Initiative in Germany creates profiles similar to the IPS ones, one of the problems which prohibited direct inheritance from IPS were must-supports.
Last updated: Apr 12 2022 at 19:14 UTC
