Stream: IG creation
Topic: where is Must-Support
John Moehrke (Sep 28 2021 at 21:22):
Is there a well known place in an HL7 IG for a reader to find the definition of Must-Support? Should there be? Are there some good candidates?
Lloyd McKenzie (Sep 29 2021 at 01:01):
There's currently no rules. HRex does theirs here. US-core does this, so some similarity there.
John Moehrke (Sep 29 2021 at 12:15):
so those samples show a dedicated, at similar level and navigation as security considerations. I like that. Don't like the name of the page, as I can see some people focusing only on that page as by the name of the page it clearly holds all the conformance criteria.
John Moehrke (Sep 29 2021 at 12:27):
I think I could come to like "Conformance Expectations"... Ill try it out.
Jose Costa Teixeira (Sep 29 2021 at 16:45):
The issue with MS being a narrative definition (we really should have the option to have a ValueSet) is that when you reuse things across IGs users will lose track.
Elliot Silver (Sep 29 2021 at 16:57):
Well, if we have a fixed location like "Conformance expectations," we could at least have the publisher auto-generate links to the conformance expectations for guides you are dependent on.
Jose Costa Teixeira (Sep 29 2021 at 17:47):
true if we have a fixed url. I presume that would be a convention, not enforced...?
Jose Costa Teixeira (Sep 29 2021 at 17:48):
and I think we should do better than say "here's all the narratives, go and figure out if one layer is consistent with the other"
Jose Costa Teixeira (Sep 29 2021 at 17:49):
(I presume that is what you implied, @Elliot Silver ?. I think it's a good step, but I think we really should have a structured, coded definition for MS)
Elliot Silver (Sep 29 2021 at 18:01):
I’m not convinced a coded representation is the problem.
And actually, the more I think about MS, the more it generally scares me. As I’m understanding it now, I think all MS requirements in any IG you implement (or is a dependency of one you implement) apply to any MS element in any profile you implement. It’s like the FHIR equivalent of the GPL open source license—sounds like a good idea, but it infects everything. I hope I’m misunderstanding.
I also have problems with MS because, unlike all the other profiling controls, I can’t validate an instance against it. We pretend it is computable and flag elements as MS (and coding it would take us further in that direction) but in the end, with anything less than an infinite vocabulary, it comes down to interpreting a narrative that applies to the systems, not to the instances.
/end rant.
Lloyd McKenzie (Sep 29 2021 at 23:26):
MS doesn't affect downstream 'new' artifacts (unless you declare that your mustSupport rules are the same as an ancestor IG's), but they do affect all derived profiles.
MS has nothing to do with the instance. It has to do with the behavior of the systems that produce and/or consume the instance. We're not pretending it's computable. mustSupport=true is just a flag that says "there are rules for what you must be able to do in your system with this element".
We could have an optional IG property that indicates the URL of the location where the default mustSupport rules for the IG are set and set the MS flag to link to that. The tricky bit is that if those are overridden by a particular profile, then you'd want to jump to the text in the profile instead.
John Moehrke (Sep 30 2021 at 12:50):
I was not looking to solve the problem, just make an incremental improvement. Conformance Expectations is not great, but an attempt to try to get IGs to use a consistent narrative is an incremental improvement. -- which leads me to, increment beyond this would be an element in the IG that is markdown and expresses what must-support means in that IG. IG build magic to have that rendered in the human narrative where the IG author wants it rendered.
John Moehrke (Sep 30 2021 at 12:51):
I see no hope of MS being computable. If anyone was using it for a computable purpose, then we would have a strict functionality like cardinality, or binding, etc. The use of MS is explicitly not computable rule, but one which the IG could impose..
John Moehrke (Sep 30 2021 at 12:53):
I am a fan of us coming up with something more than binary. I would like a vocabulary, I think we know some MS patterns that we could snap into a vocabulary. Like "R2/RE", or "shall be implemented"... We now have some experience, we should be able to come up with some vocabulary, with IG defined codes for things not in that extensible vocabulary.
Jose Costa Teixeira (Sep 30 2021 at 14:27):
strawman: can we add an extension to mustSupport that includes a codeableconcept - and if we want, a (relative) url?
Jose Costa Teixeira (Sep 30 2021 at 14:29):
without looking into computable MS, I'd look at whether the differences in MS levels are computable (hence a vocabulary like @John Moehrke mentions)
John Moehrke (Sep 30 2021 at 14:30):
a url or codeing could hold a canonical/vocabulary or locally defined thing.
Lloyd McKenzie (Sep 30 2021 at 14:30):
Do you need full-blown CodeableConcept? My leaning would have been 0..* Coding|string. Looking at the language in current IGs, I think you'll be hard-pressed to come up with anything computable. (And I'm not sure what processes would actually try to compute on it?)
John Moehrke (Sep 30 2021 at 14:34):
my "where is Must-Support" is not trying to make it computable, but trying to make it definitively findable definition. I think there is some interest in having more than a binary, thus flavors of MS. Even these flavors don't appear to be trying to make them computable (yet). Just findable definitions for each flavor. an IG defined url seems like a reasonable firs step off of binary.
John Moehrke (Sep 30 2021 at 14:37):
@Jose Costa Teixeira so your idea would be that the binary MS would still flag simplistically the way it is done today, but an extension in that element could indicate flavors?
Jose Costa Teixeira (Sep 30 2021 at 14:40):
Right. I don't know if we can change the mustSupport element. But in any case starting with an extension would allow that.
Jose Costa Teixeira (Sep 30 2021 at 14:40):
Possibly with an invariant that says that a flavour can only be filled in if the flag is true
Jose Costa Teixeira (Sep 30 2021 at 14:50):
Lloyd McKenzie said:
Do you need full-blown CodeableConcept? My leaning would have been 0..* Coding|string. Looking at the language in current IGs, I think you'll be hard-pressed to come up with anything computable. (And I'm not sure what processes would actually try to compute on it?)
- 0..* ?
- if we do value[x] which can be Coding | string, is it not better just to have CodeableConcept?
John Moehrke (Sep 30 2021 at 14:53):
so what would string or CodableConcept.text alone mean? Would that be just a markdown description of THAT instance of MS use? That seems very unfriendly. I am looking for a few vectors, not infinite vectors.
Elliot Silver (Sep 30 2021 at 16:14):
How does an extension on a particular MS flag sync with the idea that MS requirements are not element specific?
Lloyd McKenzie (Sep 30 2021 at 17:05):
The notion of 0..* Coding is that there might be multiple types of support defined "must capture", "must store", "must display", etc. You can't send those as multiple codings within a CodeableConcept.
Lloyd McKenzie (Sep 30 2021 at 17:06):
@Elliot Silver MS requirements can be element-specific, profile-specific or IG-specific. Agree that repeating the requirements on every single element is going to be a maintenance nightmare...
Frank Oemig (Sep 30 2021 at 18:06):
My apologies, but my proposal addresses exactly that. It would come as an extension with IG-specific codes. So it is to the IG author to collect the requirements and to sort them a little bit. As a first step not too difficult.
Lloyd McKenzie (Sep 30 2021 at 18:59):
IG-specific codes creates no consistency. Codes would only have value if they could be consistent across IGs
John Moehrke (Sep 30 2021 at 19:03):
I think both are needed. Some commonly agreed to codes (RE/R2, MustImplement, etc), and also IG specific codes.
John Moehrke (Sep 30 2021 at 19:04):
to say that IG specific codes create no consistency is to argue that MS should never be used today in the current form.
Lloyd McKenzie (Sep 30 2021 at 19:08):
"mustimplement" isn't meaningful, it's just a synonym for mustSupport - if we're going to have codes, they'd need to define what needs to be implemented (storage, display, capture, etc.). RE doesn't make sense in FHIR because it's combining mustSupport and cardinality. mustSupport codes (if we have them) can't speak to cardinality at all, only to behavior within the sender or receiver.
John Moehrke (Sep 30 2021 at 19:09):
it is a synonym only in your view. As discussed yesterday that interpretation is not universal.
John Moehrke (Sep 30 2021 at 19:10):
I also think your statement regarding RE is also not universal.
Lloyd McKenzie (Sep 30 2021 at 19:20):
"Required but may be empty" is absolutely talking about cardinality. (As all of the v2 conformance codes do, to one extent or other). If we're going to introduce codes, they ought to have specific meaning that makes clear what needs to be implemented. The notion of flagging something as "implementer-relevant" would be distinct from mustSupport because it will appear on elements where mustSupport is not set.
John Moehrke (Sep 30 2021 at 19:26):
well, I am using MS this way.
Lloyd McKenzie (Sep 30 2021 at 19:27):
So you'd put a MS=true on an element that was 0..0?
Frank Oemig (Sep 30 2021 at 19:27):
Did I say RE?
Lloyd McKenzie (Sep 30 2021 at 19:27):
Nope - John did :)
Frank Oemig (Sep 30 2021 at 19:29):
Great. My idea is to have codes for different aspects, ie. axes. As a starting point, select those from IGs, as-is. In a next step one could start with harmonizing.
Frank Oemig (Sep 30 2021 at 19:31):
I still cannot see why this should be a bad or unacceptable approach?
John Moehrke (Sep 30 2021 at 19:32):
Yes, I mark optional elements with MS to indicate "RE"
John Moehrke (Sep 30 2021 at 19:32):
that is ALL that I use MS for
Jean Duteau (Sep 30 2021 at 19:39):
I use MS for all of the attributes in a resource that we are expecting to exchange. For 1..x fields, that is somewhat obvious since we've said that it always has to be there. For 0..x fields, it is totally akin to RE since the field is marked as optional, thus the 0 min cardinality, but it is required to send if you have or you should expect to receive it if the server has it.
John Moehrke (Sep 30 2021 at 19:45):
the distinction I make is that I do still expect recipients to expect to receive all core Resource structure. i don't use MS=false to tell them which items they will not receive.
Lloyd McKenzie (Sep 30 2021 at 19:47):
It's possible to have 1..x with MS=false. (I.e. IG requirements to capture, display, store, etc. don't apply - because there's a fixed value, for example.)
Lloyd McKenzie (Sep 30 2021 at 19:48):
MS isn't about what they might or might not receive, it's about what they must actually do something useful with - as opposed to being allowed to throw the data away and do nothing with it.
Jean Duteau (Sep 30 2021 at 20:09):
Lloyd McKenzie said:
MS isn't about what they might or might not receive, it's about what they must actually do something useful with - as opposed to being allowed to throw the data away and do nothing with it.
Here is an interesting conundrum because that's how you are defining it, but I'm defining MS in my guides as what you can expect to specifically receive with the profiles defined in my guides. For instance, I might define Organization.identifier, name, address, and telecom as MS because those are the elements that want to receive and that I will be sending back when queried. A client can obviously send the other things in the resource, but my profile says that only those four elements are important to the use cases in my guide.
Lloyd McKenzie (Sep 30 2021 at 20:20):
But you're not marking everything else 0..0 (which is good), and that means that, in theory, they could receive anything. What you're specifically saying is "this is the information the sender must be able to expose" and, maybe "this is the information the receiver must be able to consume". (It's possible to define mustSupport in a US Core-like way where the receiver is free to do what they like.)
John Moehrke (Oct 01 2021 at 00:55):
yup
Frank Oemig (Oct 01 2021 at 06:49):
@John Moehrke in v2+ we have a mapping table for v2 conformance concepts to FHIR. IMO, "RE" must be represented as MS + minCard=0. So, using RE as a precoordinated term for this combination is fine with me, but I know that this is not supported be everyone.
Frank Oemig (Oct 01 2021 at 06:51):
A side remark that does not support this thread: The problem with v2 is that it that the conformance concepts and technical details are not 100% equivalent with FHIR. My intent with v2+ is to get this closer, ie. moving v2 with its technical representation.
Frank Oemig (Oct 01 2021 at 07:02):
For me it is interesting to see, that you guys are always use good examples what MS means (in a certain IG). All those statements comprise the same elements/aspects. I wonder that we should not be able to extract those. One is action. Store, print and display are always brought forward. Direction is another, ie. sender/receiver. So, why not adding action=print + direction=receiver (as a MS extension) to a specific element to say, that exactly this element/attribute must be printed by the receiver. I know that one can do that by a specific profile for the receiver to denote print elements, but this is overkill from a management perspective. For computation, one can use this management information to generate appropriate technical profiles.
John Moehrke (Oct 01 2021 at 14:29):
note that this is how IHE treats Document Content, and has named options for each of these that a Document Consumer would declare (display, persist, decompose, etc). As in a Document Content profile there is little declared infrastructure, the interop layer would tend to be one of the Document Sharing profiles (XDS, XDR, XCA, XDM, MHD, etc). And a Document Content profile can be used in a larger IG where workflows can be triggered and specific processing defined. Some workflows or processing requirements may call upon one of the named options from the Document Content IG. This is highly modular approach. The specific mechanism is the ability to have sub-behaviors that can be explicitly named (named options) and invoked by higher level need (systems design or another IG). - https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol1.pdf
Lloyd McKenzie (Oct 01 2021 at 18:07):
@Frank Oemig The challenge is that those generic 'theoretical' concepts then hit the real world and you end up with the rather elaborate mustSupport rules described in places like US Core. (And which they revise almost every release based on feedback.)
Frank Oemig (Oct 01 2021 at 19:08):
Ok, so we table this discussion again. .
Jose Costa Teixeira (Oct 01 2021 at 19:10):
I think there are 2 discussions:
- do we need coded MS
- what are the codes
Jose Costa Teixeira (Oct 01 2021 at 19:10):
I think the first one should be had asap otherwise the second will always be difficult
Frank Oemig (Oct 01 2021 at 19:10):
Ad 1: yes
Ad 2: let's start
Grahame Grieve (Oct 01 2021 at 19:47):
I'm ambivant on this. I think that the most useful aspect of being more specific about must-support is allowing the IG publisher to make a reference to a section in an IG somewhere that explains what must support means for this particular element. I think that if US IG had a way to do different must-support for different elements, things might be a little simpler, because must-support means different things for different elements So I'll certainly support doing something in the IG publisher if we can get enough consensus to come up with some kind of extension.
I'm less confident that we'll come up with something that has real semantic meaning. Consider the definition of RE from v2.7:
The element may be missing from the message, but should be sent by the sending application if there is relevant data. A conforming sending application should be capable of populating all "RE" elements. A conforming sending application that knows the required values for the element, should send that element. A conforming sending application that does not know the required values, shall omit the element.
Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element, but should be able to successfully process the message if the element is omitted (no error message should be generated because the element is missing).
this is all should (not SHOULD!). And all so qualified. "if there is relevant data? By whose decision? And what is the impact of security and privacy?
And receiving applications will be expected to do something, or not? What else could they do than something, or not?
As far as I'm concerned, this definition is as meaningless as anything we've come up with, and I've never understood why anyone would bother with it (long before I started on FHIR)
Grahame Grieve (Oct 01 2021 at 19:48):
one other note: it's clear that Lloyd has a very stylised way of using must-support that is totally coherent and self-contained (and maybe even to be recommended) but is based on some assumptions that are not explicitly stated in the specification, and I'm pretty sure that not all of us would agree to them
Lloyd McKenzie (Oct 02 2021 at 01:29):
If you're going to define codes, I'd encourage starting with a set of 5-6 diverse IGs and see how they've defined mustSupport for their IGs and how you might code that - and then think about what benefits you'd get from representing that information in a coded way.
Frank Oemig (Oct 04 2021 at 10:42):
Thx, @Lloyd McKenzie , this is what I have asked for.
Frank Oemig (Oct 04 2021 at 10:43):
Regarding security, this is something one should leave out from any discussion, because we are talking about capabilities.
Grahame Grieve (Oct 04 2021 at 11:06):
it should be mentioned, so that there's clarity: if a system declines to populate a field because of security concerns, does it meet the RE requirement?
Frank Oemig (Oct 08 2021 at 13:35):
I would separate that. In a testing environment there shouldn't be security concerns to properly validate. In real life if you want to validate covering security aspects one has to create appropriate profiles.
Grahame Grieve (Oct 08 2021 at 18:17):
of course you want to test security. All I'm saying is, we should be clear about our expectations
Frank Oemig (Oct 10 2021 at 14:40):
That is not what I have said. Of course you have to test security to see it is working. But you cannot expect to validate against a profile requiring a name and immediately test with security on saying not to send names.
If you want to do that you have to work with different profiles...
Lloyd McKenzie (Oct 10 2021 at 16:47):
mustSupport isn't "requiring" anything in terms of the instance. It'll be common for mustSupport to make allowance for business agreements, patient consent, regulation and other restrictions on populating the element.
Last updated: Apr 12 2022 at 19:14 UTC
