Stream: implementers
Topic: must-understand coding value
John Moehrke (Oct 30 2018 at 20:03):
Is there a need for an extension to Coding to tag a specific code value as must-understand? In the security label environment we have a need to assure that a recipient understands the 'handling obligations', as handling obligations can't be ignored... Is there a need beyond this?
Grahame Grieve (Oct 30 2018 at 20:19):
we would generally say that this is a definitional thing, not something on the coding itself?
Yunwei Wang (Oct 30 2018 at 20:24):
I thought all required bindings are must-understand.
Grahame Grieve (Oct 30 2018 at 20:27):
no, in fact.
John Moehrke (Oct 30 2018 at 20:34):
so you would say that it is sufficient that the vocabulary definition of that code is clear it must be understood? Which assumes that all implementers look through all possible vocabulary for these must-understand codes and puts special handling into their code to understand them?
Grahame Grieve (Oct 30 2018 at 20:39):
we've documented a few as must-understand in the narrative of the security labels page, and referenced that from the safety check list.
More generally, the way to do this to define a must-understand binding using http://build.fhir.org/extension-elementdefinition-minvalueset.html
Yunwei Wang (Oct 30 2018 at 20:43):
What is the difference from required binding? Required binding is "To be conformant, codes in this element SHALL be from the specified value set."
Grahame Grieve (Oct 30 2018 at 20:44):
the main binding: these are the codes that you can use
the min binding: these are the codes that you must understand
Yunwei Wang (Oct 30 2018 at 20:45):
Do you mean that no all codes from that required value set are used for binding?
Yunwei Wang (Oct 30 2018 at 20:47):
For example, 10 codes in the value set but only 5 are used for the binding so the min binding has 5.
Grahame Grieve (Oct 30 2018 at 20:48):
I'm not sure what 'used for binding' means here . Let's take an example: you are writing a medication management system, and you say "my system doesn't use or allow or support the medication request status 'cancelled'": are you conformant or not?
Grahame Grieve (Oct 30 2018 at 20:49):
since the main spec says nothing about whether you must support cancelled medications, you are clearly conformant. But an implementation guide might create a minValue set binding, and put cancelled on the list. In which case, you would not be conformant to that implementation guide
John Moehrke (Oct 30 2018 at 21:37):
in my security case, the must-understand is policy based. It might not be a thing that is defined in the vocabulary. Such as DELAU (Delete after use) might be informatively put onto a resource or bundle, but someone else might want to stress that the data shall not be accepted (error code should be returned) if the recipient can't guarantee that they will delete after use. Not sure this is proper.. just an example that comes to mind where the vocabulary binding can't be universally made, nor can the vocabulary meaning be universally made.
Yunwei Wang (Oct 30 2018 at 21:40):
@Grahame Grieve Your example is the same as what I meant. But how a system state "my system doesn't use or allow or support the medication request status 'cancelled'". I don't think there's way to do that in CapabilityStatement.
Grahame Grieve (Oct 30 2018 at 21:42):
no there's not. You could propose a new extension for non-supported-valueset to vocab, I don't think this notion exists anywhere else
Lloyd McKenzie (Oct 30 2018 at 21:47):
For a required binding on code, if you constrain to a value set that excludes "cancelled", you're asserting you won't accept that code
Yunwei Wang (Oct 31 2018 at 02:18):
@Lloyd McKenzie For example, in Claim resource, Claim.status has required binding to value set fm-status. If I want to say my server does NOT support cancelled status, can I create a value set, my-fm-status, which exclude cancelled status and then change the required binding of Claim.status to my-fm-status? I think that violate conformance rules.
Grahame Grieve (Oct 31 2018 at 02:29):
you can change the binding to be more restrictive - we only use some of the codes. You can't include codes that are not valid
Robert McClure (Nov 09 2018 at 16:54):
@Grahame Grieve >non-supported-valueset content is exactly what V2 does with specifying that certain codes in a code set are not allowed in a particular implementation guide. I don't know of any FHIR approach that aligns with this but it does make sense if we use MIN to mean "must understand and support."
Do we all agree (I would) that minValueSet defines a value set with concepts the implementer "must understand and support"? I'd like to better understand how this extension should be used/
Grahame Grieve (Nov 09 2018 at 20:36):
I agree that
minValueSet defines a value set with concepts the implementer "must understand and support"
That's the definition...
Mohammad Jafari (Nov 15 2018 at 00:59):
@John Moehrke: late to this thread but this seems to be a matter of authorization policy and orthogonal to the actual underlying FHIR data structure. The XSPA 2.0 draft defines attributes for declaring supported obligations and refrains by a requester; as part of the authorization, a server can take these attributes into account in determining whether or not –or to what extent– it would share the data with that requester . I think the new vectors of trust RFC can also be leveraged for implementing this type of policies.
Last updated: Apr 12 2022 at 19:14 UTC
