Stream: conformance
Topic: must-support when re-profiling
Morten Ernebjerg (Oct 01 2020 at 15:59):
I am currently working on a IG and want to base it IPS. Accordingly, I would base most of the profiles on the IPS profiles, i.e. do re-profiling. Now suppose I mark further elements as must-support in one of my profiles. Then profiles may contain must-support elements originating from both IPS and from my IG. However, my own IG might have a different definition of what must-support means than IPS. So the question is: which definition holds for the must-support elements in my profiles?
I would suppose the answer is my definition, i.e. that the definition in the IG now applies to all must-support flags, regardless of origin. But is that actually captured anywhere in the spec? And is there an (informal) expectation that must-support definitions in derived IG can somehow not be less restrictive than the underlying definition (similar to how profiling cannot loosen cardinalities)? It may be a bit theoretical, but I am wondering if it could still lead to issues if one introduces an extremely weak definition of must-support in the derived IG, causing systems to handle the data in ways that are not permissible per IPS.
Richard Townley-O'Neill (Oct 01 2020 at 21:19):
Must support can mean different things for different elements, as long as you say so. That only answers part of the question.
Frank Oemig (Oct 02 2020 at 06:52):
Conformance is currently working on an extension to formalize what mustSupport means. A derived profile cannot weaken requirements.
Morten Ernebjerg (Oct 02 2020 at 18:42):
@Frank Oemig sounds interesting, is there a preview somewhere?
Frank Oemig (Oct 27 2020 at 12:25):
https://confluence.hl7.org/display/CONF/FHIR+US+Conformance%3A+Specification+Outline
Frank Oemig (Oct 27 2020 at 12:26):
https://confluence.hl7.org/pages/viewpage.action?pageId=91991374
Lloyd McKenzie (Oct 27 2020 at 13:05):
Note that none of this is approved methodology - and some is in conflict with approved FHIR methodology
Morten Ernebjerg (Oct 27 2020 at 14:23):
OK, thanks!
Frank Oemig (Oct 27 2020 at 16:50):
We are still analyzing. Why would specific extensions be in conflict then?
Lloyd McKenzie (Oct 27 2020 at 16:58):
Extensions can't be used to convey information (or override) information that already has a formal place in the spec.
Frank Oemig (Jan 13 2021 at 08:33):
The details conveyed "behind" mustSupport in IGs can be reduced to the following three aspects:
- direction
- functionality
- expected data (null values or additional values)
or a combination of the three.
I have added that to a PPT slide deck: https://confluence.hl7.org/pages/viewpage.action?pageId=91991374&focusedCommentId=97476766&refresh=1610526678860#comment-97476766
Lloyd McKenzie (Jan 13 2021 at 16:59):
'Direction' might have made sense in v2 when there was a presumption of only 2 exchange partners (sender and receiver), but that's not a safe assumption in the FHIR space. While there is the notion of 'client systems' and 'server systems', one can't presume that the expectations for all clients will always be the same, or event that all server expectations will be the same. For example, you might have clients that are decision support systems and other clients that are rendering apps. If an IG defines expectations for both, the notion of 'direction' won't help. The way 'direction' is handled in FHIR, when it's relevant (i.e. different expectations for different systems in an exchange) is by having distinct profiles for each type of participant system. This approach is necessary because it's not just mustSupport expectations that might vary by system type - cardinality, invariants and even just descriptive guidance might all vary depending on the type of system.
As discussed previously, the notion of 'expected data' also doesn't make much sense in FHIR. FHIR has no concept of 'null'. Simple elements can have a value or not. And they can have extensions or not. They must have at least an extension or a value. However, extensions don't necessarily indicate null. The extension might be a reference, might be text, might be an alternate encoding, might be a formula, or might be a whole lot of other things. So there's no simple boolean flag that can be used to talk about 'expected data'. And even if there were, it wouldn't be handled as part of mustSupport because mustSupport doesn't deal with the types of value present - that's not its scope.
The only aspect of mustSupport that could potentially be coded is 'functionality' - i.e. is the expectation the element must be captured in a UI, displayed in a UI, retained in persistent store, transmitted to downstream systems, considered as part of decision support logic, etc. If this was captured via code, it would need to be 0..* because multiple functions could be required. It would also have to be extensible because there's no chance we could ever come up with standard codes covering all possibilities. The question then would be "what's the benefit of having this information exposed in computable form" (as opposed to text, which is what we expect now). This far, I haven't heard an answer to that question.
Frank Oemig (Jan 13 2021 at 20:58):
For direction, if sender/receiver is misleading, what about creator/consumer. A client be both. That should be described in an IG.
Frank Oemig (Jan 13 2021 at 21:01):
I know that there is no null flavor in FHIR. But in each IG there is a specific extension that is used for that purpose. And it is not boolean but a Codesystem to express that. I would also expect that is refined in each IG individually so that it can be adapted to formalize the needs.
Frank Oemig (Jan 13 2021 at 21:02):
And functionality can repeat exactly for the purpose you describe.
Frank Oemig (Jan 13 2021 at 21:02):
Those can be used alone or in combination.
Frank Oemig (Jan 13 2021 at 21:04):
So I do not see any contradiction. On the contrary, the proposal supports all your requirements and help to formalize IGs.
John Moehrke (Jan 13 2021 at 21:05):
there are flavors of creator too... Create-New, Update... might be flavors of Update
John Moehrke (Jan 13 2021 at 21:05):
there are flavors of consumer too... view only, consume, import, etc
Frank Oemig (Jan 13 2021 at 21:08):
This is functionality: display as consumer, create with original data only/no extension/null, support as creator only, ..
Frank Oemig (Jan 13 2021 at 21:09):
Or disallow extension for the whole instance, or only a specific attribute,..
Frank Oemig (Jan 13 2021 at 21:09):
So it expresses what folks are doing with IGs...
Lloyd McKenzie (Jan 13 2021 at 22:08):
It's not a question of creator/consumer. You might have two different consumers with different mustSupport rules. So the way you describe it is a separate profile for each participant - if the rules are different depending on participant type. (Because any of the rules might be different, not just mustSupport.)
Lloyd McKenzie (Jan 13 2021 at 22:09):
In each IG there IS NOT a specific extension that is used for that purpose. Some don't list any extensions, some might list one, some might list more than one. Even if not listed, in most cases implementers are free to make up their own extensions and use those too instead/in addition.
Lloyd McKenzie (Jan 13 2021 at 22:10):
More importantly, what types of extensions are used is orthogonal to the notion of mustSupport. So a solution that tries to munge this into mustSupport isn't going to fly.
Frank Oemig (Jan 13 2021 at 22:19):
For that reason they should be combined , if necessary.
Depending on the Codesystem for referring to Extensions that can be adapted. It is not defined per se, but allows to formalize what is described in an IG. It is replacing natural language sentences into codes.
Therefore it is additional.
Frank Oemig (Jan 13 2021 at 22:32):
The idea behind those extensions is to translate the natural language requirements into something that is computable. As a first step, the IG should drive the codes. In a subsequent step the instances should be analysed whether we can find commonalities. Probably it is not explained good enough so far.
Lloyd McKenzie (Jan 13 2021 at 23:19):
They can't (and won't) be combined. 'null' is not a special concept in FHIR. There's "has a value" and "doesn't have a value". "Doesn't have a value" can cover numerous possibilities. There is no notion of 'null'. And there is no chance of all IGs having a common approach to what extensions are allowed.
Lloyd McKenzie (Jan 13 2021 at 23:20):
What sort of computation would you expect to happen on the codes?
Peter Jordan (Jan 13 2021 at 23:28):
Null Flavor - RIP... except http://hl7.org/fhir/json.html#null
Lloyd McKenzie (Jan 14 2021 at 01:14):
Right - and that's not conveying null, just handling the fact that value and extensions are conveyed in different places
Frank Oemig (Jan 14 2021 at 08:20):
I have never said that there is a null flavor. On the contrary, but there is a recognition that something comparable is necessary. As you said, this is the reason why IG writers have designed a special extension for that. This named differently. It may cover different values. And there may be more than in a single IG.
May proposal should use a Codesystem to identify that. Therefore it can and most probably will be different in every IG. Is this a problem - no.
But such an individual Codesystem would identify all natural language requirements.
One can use that alone or combined with others. Just as necessary.
Frank Oemig (Jan 14 2021 at 08:22):
To replace natural language requirements this extensions must be combined, at least it must be possible. If this is necessary depends on the requirement.
So, you may use that on resource/ profile level to say, that xyz and abc are the only extensions allowed.
Frank Oemig (Jan 14 2021 at 08:23):
For Germany, such a possibility would be great because in our specifications the awareness of what FHIR allows is low.
Frank Oemig (Jan 14 2021 at 08:25):
Again, from my perspective, everything that is currently done can be represented. Of course, it needs a better and more complete explanation. And it is not a SHALL. If writers don't want to use it, fine. But if, it could and certainly will be helpful.
Frank Oemig (Jan 14 2021 at 08:26):
On the other hand, we were said to come with a proposal. I am astonished about this pushback.
Grahame Grieve (Jan 14 2021 at 17:32):
you shouldn't be astonished about that - everything generates pushback.
Grahame Grieve (Jan 14 2021 at 17:32):
Shouldn't the discussion about "direction" actually be about actors? Different actors have different expectations...
John Moehrke (Jan 14 2021 at 18:03):
yes, the expectations should be on the actor interacting with the profile (transaction). This is how IHE has done it for years.
Lloyd McKenzie (Jan 14 2021 at 19:09):
The comparable thing to v2's notion of 'null' is PATCH - that allows you to say "changing some things, but not other things". There is no way to do that in a regular FHIR Update (and, at this point, it's safe to say there won't be). The notion of 'null' in v3 is different in FHIR too - and there's no intention to ever have anything directly the same. IG authors create extensions for all sorts of things - and they don't necessarily neatly overlap with v3's notion of 'Null flavor'.
In any event, the notion of 'null flavor' does not belong in MustSupport - it's a different concept and is orthogonal. You could place constraints on what extensions are allowed for elements that don't need to be supported; and you can have elements that are silent on the use of 'null-like' extensions but are marked as mustSupport.
So combining the notions of 'what must be supported' vs. 'are null-like extensions allowed' vs. 'who do these rules apply to' is simply not appropriate. In FHIR, "Who do these rules apply to" is covered by the CapabilityStatement. If the rules are the same for multiple participants, they'll all point to the same profile. If the rules differ for different participants, then each participant will have it's own profile - and those profiles will have different values for mustSupport, cardinality, invariants, descriptions and any other elements in the profile.
Replacing natural language with computable content is not something that "must be possible". It's something we could choose to do. But it's only something we should choose to do if there are clear use-cases for what could be done computably with a statement of "must display" vs. "must store" vs. "must allow capture on data entry", etc. You haven't shared that yet.
Note that saying xyz and abc are the only extensions allowed is, generally, really bad practice. It interferes with re-use as well as future evolution and generally increases costs for the community.
Jose Costa Teixeira (Feb 21 2021 at 11:18):
Here's a crazy idea: what about formalizing some of these rules in the form of Permissions?
Jose Costa Teixeira (Feb 21 2021 at 11:19):
("This entity can read but not write to this part" is what Permission is supposed to do)
Lloyd McKenzie (Feb 21 2021 at 13:58):
Permission is about what you're allowed to do. MustSupport is about what you must be able to do. Not really the same thing...
John Moehrke (Jan 29 2022 at 15:10):
In IHE we use Must-Support like we have used "R2" or "RE" in the past. Required If known, but not mandatory. Used to force populating an element when the data are available, but recognizing that many times the data are not available. The problem we have run into is that a Profile derived off a minimal Profile, where the minimal Profile used Must-Support widely, the derived profile that has stricter mandatory elements ends up with an element marked both Must-Support and Mandatory. This is a conflict as an element can't logically be both mandatory and required if known. One solution would be to allow the Must-Support flag to be removed when the minimal cardinality is increased. As it stands today that is not possible (unless I don't know a trick) . So the best I can do is to define Must-Support in a more complex way, indicating that Must-Support means nothing when minimal cardinality is not zero but otherwise means required if known (R2).
John Moehrke (Jan 29 2022 at 15:12):
I understand that others use Must-Support very differently.. but the rules of Must-Support tell me I can use it any way my IG wants. And IHE find this R2 concept very important, and use Must-Support for it.
Lloyd McKenzie (Jan 29 2022 at 16:07):
mustSupport + mandatory are not conflicts. It's possible to be mandatory with mustSupport=false. I.e. "There has to be a value here, but it's fine if you send a hard-coded fixed value, don't store it, don't expose it on your UIs and don't pay any attention to it." If that's not your expectation for a mandatory element, then you need 'required' too. Mandatory, by itself, is not enough.
John Moehrke (Jan 29 2022 at 18:16):
@Lloyd McKenzie in my definition of Must-Support, which I am allowed to define... R2 is not logical for a mandatory element. You keep applying YOUR definition of must-support to others when your definition is not the only definition.
Lloyd McKenzie (Jan 29 2022 at 18:26):
You can't redefine mustSupport in that way. mustSupport can't reflect anything about cardinality in the instance. It can only reflect what system is expected to do with the element (display, capture, store, consider in logic, etc.). If you have a concept that integrates notions of both "what must be supported" and "what must be sent", then in FHIR, that'll have to be represented as two distinct elements.
John Moehrke (Jan 29 2022 at 19:08):
Where is this stated?
It can only reflect what system is expected to do with the element (display, capture, store, consider in logic, etc.).
I am not expressing cardinality with Must-Support, i am expressing which elements are fully optional to populate, from those that must be populated if the data are available (R2).
Lloyd McKenzie (Jan 30 2022 at 02:38):
Population is governed by cardinality and invariants alone. The profiling page makes clear that mustSupport is separate from cardinality.
If you want data to be populated if it exists, mark it as mustSupport=true. If you want it to be fully optional mark it as mustSupport=false. If the element is mandatory, you still need mustSupport if you want the system to actually 'support' the element and, as a sender, not just hardcode a fixed value or, as a receiver, completely ignore the element. (That's what it means if the element is mandatory and mustSupport=false - there's no requirement to 'support' the element as a receiver at all, and the only support required of a sender is to ensure a value is there - even if there's no slot in any data base, UI, or anything else for it.)
René Spronk (Jan 30 2022 at 08:45):
The IHE R2 concept is a nice fit with MustSupport, and R2 is not about cardinality. I don't see any problems, 'mandatory' is a different dimension.
Grahame Grieve (Jan 30 2022 at 23:29):
you could create a problem if you define it to be a problem, but it doesn't seem like there's any reason you must define it to be a problem
John Moehrke (Jan 31 2022 at 14:01):
my problem is that as the second and more strict profile is derived off of the first profile. The second profile can increase the cardinality to mandatory, but can't remove the Must-Support flag. I want a way to remove the must-support flag.
David Pyke (Jan 31 2022 at 14:20):
That would be loosening the constraints, which is specifically against how profiles can be defined.
John Moehrke (Jan 31 2022 at 14:23):
right... because of an assumption about what an IG might define for must-support. In my case my definition of must-support only applies if the element is not optional cardinality.
David Pyke (Jan 31 2022 at 14:25):
So, if it's mandatory, you don't have to support it?
David Pyke (Jan 31 2022 at 14:26):
I would update your definition to handle the mandatory use case
John Moehrke (Jan 31 2022 at 14:27):
yes, that is the misunderstanding that comes about... a clearly mandatory (cardinality) with a flag that says "required if known".
John Moehrke (Jan 31 2022 at 14:28):
Yes, the definition will likely need to be augmented... but I think the need is broader, and thus needs to be considered in the context of future evolution of must-support.
Lloyd McKenzie (Jan 31 2022 at 15:13):
Mandatory with mustSupport = false means "don't need to display, store, or consider". Is that what you want? Because if not, then you need mustSupport=true as well. Cardinality never says anything about what the system must do with the data - that's always handled with mustSupport.
John Moehrke (Jan 31 2022 at 15:51):
Lloyd, that is YOUR definition of must-support. that is not a universal definition of must-support
John Moehrke (Jan 31 2022 at 15:54):
so how do YOU convey to a sender the "Required if Known" concept?
David Pyke (Jan 31 2022 at 15:55):
Verbally, in the comment
John Moehrke (Jan 31 2022 at 15:56):
so then every optional element is considered Required if Known? Which includes all extensions every defined?
David Pyke (Jan 31 2022 at 15:57):
If you define Optional in the prose of the IG/Profile, then yes.
John Moehrke (Jan 31 2022 at 16:02):
I do define Optional as ... optional... a sender does not have any obligation to send optional elements.
Mareike Przysucha (Jan 31 2022 at 16:04):
@John Moehrke:
Is it a requirement to derive from the profile with the MustSupport flags? If not, could you copy-paste the differential and then delete the MustSupports you don't need?
And I agree with you about MustSupport flags. The spec says:
Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
For this reason, the specification itself never labels any elements as MustSupport. This is done in StructureDefinitions, where the profile labels an element as mustSupport=true. When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc.
(https://www.hl7.org/fhir/conformance-rules.html).
Therefore, if you define it differently than Lloyd, it's alright, as long as you state, how you define it.
Elliot Silver (Jan 31 2022 at 16:47):
Mareike Przysucha said:
Is it a requirement to derive from the profile with the MustSupport flags? If not, could you copy-paste the differential and then delete the MustSupports you don't need?
This is what we've done on the Canadian IPS variant--the actual IPS MS flags are too restrictive, so rather than derived profile of IPS, we've developed parallel profiles that let you conform to IPS but don't require it.
As for R2 or required-if-known, we've made or left elements optional (min cardinality 0), flagged them as MS, and made the definition of MS "senders shall populate if they have a value".
I'm a little confused about how to apply the MS definitions of a parent IG to elements that I flag as MS in my IG, and how my definition of MS applies to elements in parent IGs, but I think that's mostly a separate issue from how to indicate R2.
Lloyd McKenzie (Jan 31 2022 at 18:07):
You can make the definition of mustSupport conditional on cardinality if you like. You can say that mustSupport says "must be capable of sending and must transmit if known (and consent and other business rules permit)". If an element is mandatory, then that automatically means the 'if' must be true.
Lloyd McKenzie (Jan 31 2022 at 18:08):
Cardinality, by itself, has no meaning around mustSupport other than "must be a value on the wire". You can't enforce that it has meaning other than that. We specifically split off all meaning around "what systems must do" behavior-wise into the mustSupport element.
Peter Jordan (Jan 31 2022 at 20:02):
My 2CW is that MS is an instruction to designers, whereas cardinality is a mandate for implementers (enforced by the reference libraries) and certainly isn't restricted to 'the wire' as FHIR is increasingly used in the business and persistence layers of applications.
Lloyd McKenzie (Jan 31 2022 at 21:09):
If the purpose of a profile is defined as "what must be persisted", then I guess mandatory would apply to that. But insofar as a profile defines an interface for exchange, if there's no expectation for support, then you can't make any assumptions about UI, persistence, consideration in logic, or subsequent propagation
Peter Jordan (Jan 31 2022 at 22:49):
Well, generally speaking, Profiles don't exist in isolation and therefore the encompassing IG(s) may have something to say about these concerns.
Lloyd McKenzie (Jan 31 2022 at 22:54):
IGs can do all sorts of things. They can say "every element whose name starts with an 'a' or 'q' must be persisted in its own relational database table" if they really want to. But in terms of using elements as they're defined to be used, "cardinality" is about "must this element be present in the instance" and "mustSupport" is about "what is the system expected to do with respect to the capture, display, storage, use, re-transmission, etc. of the element". An element being mandatory in the core spec sets no expectations around capture/display/storage/use/etc. Interpreting cardinality to mean things that are meant to be communicated by mustSupport is going to cause grief - especially when it comes to dealing with HL7 core elements that are mandatory and with the ability to leverage profiles defined by others.
John Moehrke (Jan 31 2022 at 22:55):
@Lloyd McKenzie you keep saying that, but that is NOT what the spec says.
John Moehrke (Jan 31 2022 at 22:57):
If we want to change must-support to the definition that Lloyd wants it to be defined as.. Fine, then give me a mecahnism to do what R2/RE has been used in Interoperability Implementation Guides for decades. I am writing Interoperability Implementation Guides. I am not writing systems design and user experience documents (SDD, UXDD).
Grahame Grieve (Jan 31 2022 at 23:08):
how is it different to what the spec says?
John Moehrke (Jan 31 2022 at 23:55):
Lloyd said
"mustSupport" is about "what is the system expected to do with respect to the capture, display, storage, use, re-transmission, etc. of the element"
Yet there is no mention of "capture, display, storage, use, or re-transmission" in the must-support text.
https://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.mustSupport
all the spec says about mustSupport is that "Something useful"
"Something useful" is context dependent and impossible to describe in the base FHIR specification. For this reason, tue mustSupport flag is never set to true by the FHIR specification itself - it is only set to true in profiles. A profile on a type can always make musSupport = true if it is false in the base type but cannot make mustSupport = false if it is true in the base type. This is done in Resource Profiles, where the profile labels an element as mustSupport=true. When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this can mean many things. Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.
Grahame Grieve (Jan 31 2022 at 23:58):
Lloyd is just filling out 'something useful' with a set of possibly useful things. I don't think that his particular examples made any difference to the underlying fact here, which is that there's a clear and sometimes important difference between must-support = true and false for elements with minimum cardinality = 1
Grahame Grieve (Jan 31 2022 at 23:59):
I completely don't understand your stated problem here on this subject.
Lloyd McKenzie (Feb 01 2022 at 00:00):
Key point - minOccurs>=1, mustSupport=false == element must be present, but neither sender nor receiver need to do anything useful with it.
John Moehrke (Feb 01 2022 at 00:08):
I will try one more time. For example in MHD I have a profile on DocumentReference for "minimal" metadata, it has many elements as optional, but they are marked with MustSupport. Where MustSupport is "required if known". I then have a "comprehensive" profile that is derived off of that minimal metadata and changes some elements to mandatory (for example, because XDS requires them). These elements happen to have been MustSupport in the minimal metadata profile that this comprehensive profile is derived off of. Thus the comprehensive profile has some elements that are cardionality 0.. with MustSupport (no problem), but also some elements that have cardionality 1.. with MustSupport. It is these second category that are manditory because of the comprhensive profile, but still have MustSupport from the minimal metadata profile.
- One solution is to define MustSupport as "Please ignore MustSupport if the element is cardionality 1.., otherwise the indicated element must be populated if the sender knows a data value for the element". I can define MustSupport this way, it is just really messed up.
- I could just NOT derive comprehensive DocumentReference off of minimal DocumentReference. but this sure makes keeping everything nicely defined and aligned harder.
Just seems to me that decades of experience by HL7, DICOM, and IHE to use "Required if Known", would have something like it ready for use in FHIR. I thought that MustSupport could be that.
John Moehrke (Feb 01 2022 at 00:08):
Lloyd McKenzie said:
Key point - minOccurs>=1, mustSupport=false == element must be present, but neither sender nor receiver need to do anything useful with it.
I do NOT have a receive side problem. I have a need to specify sender (Interoperability) requirements
Grahame Grieve (Feb 01 2022 at 00:09):
so I just don't see at all what needs solving. You seem to think it's somehow bad to say that the minimum cardinality is 1, and that it's also must support. Why?
Grahame Grieve (Feb 01 2022 at 00:10):
my solution is: leave things as they are
Elliot Silver (Feb 01 2022 at 00:10):
I don't see a problem with deriving the comprehensive profile from the minimal one. The minimal one says send these elements if you have them; the comprehensive says you'd better have content for some of those if you want to send it.
John Moehrke (Feb 01 2022 at 00:10):
so, I have had an implementer read that as ... oh, that manditory item does not need to be sent if I don't have a value to put there.
Elliot Silver (Feb 01 2022 at 00:11):
MS text doesn't override cardinality.
Grahame Grieve (Feb 01 2022 at 00:11):
ummm.... that's insane. doubly so because that would be a possible interpretation of a 1..1 element not marked as RE
John Moehrke (Feb 01 2022 at 00:11):
aka. they saw that MustSupport is more powerful than cardionality 1..
Grahame Grieve (Feb 01 2022 at 00:11):
so you do want 1..1 marked as must-support
John Moehrke (Feb 01 2022 at 00:11):
I do NOT mark 1..1 as must-support
Elliot Silver (Feb 01 2022 at 00:11):
I think he wants MS to go away if its marked as 1..
Grahame Grieve (Feb 01 2022 at 00:12):
so that the wrong interpretation is less insane?
John Moehrke (Feb 01 2022 at 00:12):
because my definition of must-support is "Required if known". So clearly that is NOT something to be used with 1..
Grahame Grieve (Feb 01 2022 at 00:12):
why not?
Grahame Grieve (Feb 01 2022 at 00:12):
it's not incompatible. just possible redundant
Lloyd McKenzie (Feb 01 2022 at 00:12):
Required if known and "must be sent" aren't mutually exclusive. Mandatory says "must be known".
John Moehrke (Feb 01 2022 at 00:13):
the person interprets 1..1 with MS as... Optional.
Elliot Silver (Feb 01 2022 at 00:13):
They are wrong then.
John Moehrke (Feb 01 2022 at 00:13):
exactly
John Moehrke (Feb 01 2022 at 00:13):
of course they are wrong
Lloyd McKenzie (Feb 01 2022 at 00:13):
Ok. So if the person is wrong, then add some additional guidance that makes it clear they're wrong, don't try to change the methodology...
Elliot Silver (Feb 01 2022 at 00:13):
You could beef up your definition of MS to clarify that ...
Elliot Silver (Feb 01 2022 at 00:13):
exactly.
John Moehrke (Feb 01 2022 at 00:14):
but they are representative of some reader community... so I would prefer to not confuse others... I would rather remove the MS flag when I upgrade the cardionality to 1..
John Moehrke (Feb 01 2022 at 00:14):
Elliot Silver said:
You could beef up your definition of MS to clarify that ...
read above.. I said that was an option.. but it sure is ugly
Grahame Grieve (Feb 01 2022 at 00:14):
you'll just confuse others
Richard Townley-O'Neill (Feb 01 2022 at 00:14):
If they make that mistake, how many others do they make?
Lloyd McKenzie (Feb 01 2022 at 00:14):
Removing the MS flag says "it's fine to have no concept of this in your system - hard-code with something and you're fine".
Grahame Grieve (Feb 01 2022 at 00:15):
"Please ignore MustSupport if the element is cardionality 1.., otherwise the indicated element must be populated if the sender knows a data value for the element".
That's a purposefully bad definition. You could instead say:
John Moehrke (Feb 01 2022 at 00:15):
Lloyd McKenzie said:
Removing the MS flag says "it's fine to have no concept of this in your system - hard-code with something and you're fine".
I don't follow you... there are indeed some 1..1 that are hardcoded for a given IG and use-case.
Lloyd McKenzie (Feb 01 2022 at 00:15):
That, presumably, isn't what you want. ibid - keep MS and make clear that MS + min>0 means "Definitely NOT optional"
John Moehrke (Feb 01 2022 at 00:15):
really, really, not optional
John Moehrke (Feb 01 2022 at 00:16):
like I said... I can document my way out of this.
Grahame Grieve (Feb 01 2022 at 00:16):
"Some elements marked as must-support have a minimum cardinality of 1, so that they must be sent. This combination indicates that other variants of the same profile, they are marked as RE, but this label in addition to a minimum cardinality of 1 makes it explicitly clear that the value in the element SHALL come from a stored value, not some aribitrarily added fixed value to meet the cardinality requirements"
John Moehrke (Feb 01 2022 at 00:17):
but how many others really need R2/RE... just want this on the stack of iprovement opportunities for next generation beyond mustsupport
Grahame Grieve (Feb 01 2022 at 00:17):
because I have absolutely seen engineers hack fixed values into minimum cardinality elements, and then claim that there's nothing to say that they can't. Clinical Safety be damned.
John Moehrke (Feb 01 2022 at 00:18):
well, as I said.. there are some hardcoded 1..1... take a look at BloodPressure, that hard codes a specific LOINC code
Lloyd McKenzie (Feb 01 2022 at 00:18):
As an example, I have some profiles where I'll have min=1, mustSupport=false on MedicationRequest.intent. The context is "this is always a prescription, it must always be a prescription". Therefore, it's totally fine if the system can't capture, display, store, or do anything useful with MedicationRequest.intent. Profile sets a fixed value for it. All the normal rules that go with "mustSupport" don't apply to that element. So it's meaningful to say mustSupport=false there. However, MedicationRequest.medication is also 1..1. And that's definitely mustSupport=true. Which means there are expectations around actually supporting the concept in their system, letting users capture it, see it, etc.
John Moehrke (Feb 01 2022 at 00:19):
I get that your definition of MustSupport fits you well.. and overall I like it... but I need R2/RE concept, and your MustSupport does not help with that need.
Lloyd McKenzie (Feb 01 2022 at 00:20):
It works just fine. "must send if have" works fine with "must have". If you've got no requirements about display, capture, store - so be it.
Richard Townley-O'Neill (Feb 01 2022 at 00:21):
John Moehrke said:
aka. they saw that MustSupport is more powerful than cardionality 1..
I expect they will always choose the more convenient rule as the more powerful.
Elliot Silver (Feb 01 2022 at 00:23):
John Moehrke said:
well, as I said.. there are some hardcoded 1..1... take a look at BloodPressure, that hard codes a specific LOINC code
Right, MS and 1..1, and the presence of that code is what identifies the resource as meeting the BP profile, so it makes perfect sense to have it both hard-coded and MS.
Richard Townley-O'Neill (Feb 01 2022 at 00:35):
Put a table in the docco like
image.png
| min card = 0 | min card > 0 | |
|---|---|---|
| MS=false | not needed, not processed | supply, not processed |
| MS=true | supply if available, is processed | supply, is processed |
Vassil Peytchev (Feb 13 2022 at 02:21):
I would change the first row as:
| MS != True | not required, may not be processed | supply, may not be processed |
It is up to the consumer to decide if they want to process it.
Richard Townley-O'Neill (Feb 13 2022 at 22:59):
Better to say "need not be processed" as "may not be processed" is the form of a command to not process
Last updated: Apr 12 2022 at 19:14 UTC
