Stream: conformance
Topic: must supports when min > 0
Eric Haas (Jul 29 2017 at 20:11):
I got some frowns from some NIST folks about making Min > 0 elements Must Support. When profiling, I typically make everything a must support since if it isn't I don't include in a diff. The documentation doesn't discourage its usage and I think its consistent with my definition of Must Support. Would like some other opinions.
Lloyd McKenzie (Jul 30 2017 at 03:39):
You don't have to make elements with a min > 0 mustSupport. If you don't, you're saying receivers are allowed to ignore them and senders are allowed to just send a fixed value but not have a capability for the user to set them or be able to store them, etc. Deciding that something HL7 has said is so important it must be present in every instance is appropriate to ignore is certainly not a decision to make lightly, but it's a decision you're allowed to make...
John Moehrke (Jul 30 2017 at 13:59):
I have wondered what the meaning of setting this true or false. I find that in standards language the word "support" is an ambiguous word. I never know what it means. It seems closest to the meaning one would get from a hangman's noose... which is not good.... I am still not clear what it means. Receivers are allowed to ignore, are you saying that by setting it true that I am forcing some specific action that receivers must do? Where is that behavior defined? I never get to define the behavior, all I get to do is set true/false... I am equally unclear on sender...
Lloyd McKenzie (Jul 30 2017 at 15:30):
It's only used in implementation guides or profiles and the requirement is that the implementation guide define exactly what "support" means - whether that's store, be able to display, consider as part of decision support, include in statistical analsysis, etc.
John Moehrke (Jul 31 2017 at 11:57):
so there is an expectation that the IG narrative contains clarification... Okay, I can work with that. I suspect we will need to evolve this into a set of well defined values. For example, it is common in profiles to need a flag to tell the sender actor that if they have the value, they shall send it (RE or R2). This kind of a flag to the sender is common. Recipients behavior is less common to encode into the message semantics.
Eric Haas (Jul 31 2017 at 15:42):
See US-Core for our definition - It borrows heavily from RE.
Alexander Henket (Aug 01 2017 at 13:07):
Am I correct in thinking that mustSupport=true resembles "required" in V3? If so then you could not create a derived profile without mustSupport=true right? So if my US core profile says mustSupport=true for SSN then this prohibits (derived) use of the profile on anonymous patients in research for example.
Alexander Henket (Aug 01 2017 at 13:12):
We are working on NL core and I tend to think that I do not want to limit derived use too much. So I'm left with the options
- to make everything in the differential mustSupport=true like US core,
- to make nothing mustSupport=true and instead add a notion that mention in the differential in itself suggests mustSupport or explain (comply or explain),
- to weigh at least every optional path for importance and potentially make every min > 0 path mustSupport=true (although that is sort of redundant)
Grahame Grieve (Aug 01 2017 at 19:59):
well, those are a good set of choices to consider...
Last updated: Apr 12 2022 at 19:14 UTC
