Stream: IG creation
Topic: Must-Support --> IG-specific flags?
Josh Mandel (Apr 30 2021 at 00:58):
Wanted to see if FHIR-32021 holds interest for IG authors. Premise is just: Allow for IG-specific flags instead of a single "Must Support" flag with unspecified semantics that every IG overrides differently. For example, an IG might define and use three distinct flags, marking some elements as Must-Produce, some overlapping set as Must-Display and a special few as Good-With-Mustard.
Lloyd McKenzie (Apr 30 2021 at 01:33):
Actually, I've been noodling on the notion of moving 'mustSupport' out of profiles and into CapabilityStatements - a CapabilityStatement could have a list of elements and the associated 'functional' behavior that was expected for a system with respect to those elements. To a certain extent, that would be closer to what's actually needed. CapabilityStatement is about defining system behavior. Multiple CapabilityStatements might reference the same profile (and in some cases, reference the same profile in different contexts). It could however make for long lists of elements. Thoughts?
Grahame Grieve (Apr 30 2021 at 05:13):
I think that's not something that should be in CapabilityStatement. What I've been meaning to do is to support the idea of a profile that defines structure - and not expectations, and then vice versa, and build summary views that show sets of expectation profiles in tabular form
Peter Jordan (Apr 30 2021 at 05:23):
Can't see this working at the CapabilityStatement layer either - what if a server supports multiple profiles and IGs with differing 'must support' settings for the same element. Much depends on whether the setting is used for conformance or best practice purposes. The IPS IG interpretation of 'must support if available' certainly resonates with implementers here in NZ as a best practice. Testing against structures is far easier than defining and assessing conformance against expectations (with or without mustard :) )
Jose Costa Teixeira (Apr 30 2021 at 05:53):
three's another discussion (or a few actually) about bringing a) more flexibility and b) better determined behaviour for MustSupport.
Jose Costa Teixeira (Apr 30 2021 at 05:55):
I think I recall suggesting a codeableconcept with an extensible binding to an HL7-defined valueset.
Jose Costa Teixeira (Apr 30 2021 at 05:57):
(if I'm recalling wrong and didn't suggest it there, I'm bringing it up now)
Jose Costa Teixeira (Apr 30 2021 at 05:59):
I don't know @Josh Mandel if when you say a few flags you are actually also referring to a 0..* codeableconcept
Frank Oemig (Apr 30 2021 at 08:39):
Well, there is a discussion about it: https://confluence.hl7.org/pages/viewpage.action?pageId=91991374
please see the presentation
Frank Oemig (Apr 30 2021 at 08:40):
In principle, there are different perspectives that can be described by different extensions...
Lloyd McKenzie (Apr 30 2021 at 13:19):
@Peter Jordan If there were different mustSupport expectations for the same element, the system would need to support all of them (and would declare that).
Josh Mandel (Apr 30 2021 at 13:27):
I don't know Josh Mandel if when you say a few flags you are actually also referring to a 0..* codeableconcept
I don't know either, but something like that. Or a 0..* Coding.
Jose Costa Teixeira (Apr 30 2021 at 14:00):
could (some of) those codes originate some invariants? To let the computers do (some of) the verification.
Grahame Grieve (May 03 2021 at 23:36):
I prefer Coding over CodeableConcept in this specific location. Or even a URL instead of a coding
Josh Mandel (May 04 2021 at 00:23):
Yes, URL is a great idea
Last updated: Apr 12 2022 at 19:14 UTC
