Stream: terminology
Topic: Can you use code system directly w/o valueset in slice?
Yunwei Wang (Jan 19 2021 at 00:00):
While I am reviewing a ballot, I notice this:
In base FHIR spec, ValueSet.useContext.value[x] has an example binding. The profile I reviewed sliced ValueSet.useContext like this:
image.png
I am not sure if this is correct since there is no value set created using that specific code system
Richard Townley-O'Neill (Jan 19 2021 at 00:07):
I think that it is OK.
The slice definition does fix values for the elements, and that is all it is required to do. Slicing can work on elements that cannot be bound, such as integer.
Binding an element to a value set is independent.
Robert McClure (Jan 19 2021 at 15:54):
@Richard Townley-O'Neill I disagree. This is nothing like what is going on with using the integer datatype to clarify that a single integer is acceptable in a slice for an unbound element. @Yunwei Wang did you NEG comment this? Clearly they have a minimum expectation for certain required codes in that "example" binding. I don't think we have a good approach for this described. Perhaps there could be a MIN binding of some type, yet still example? @Grahame Grieve @Lloyd McKenzie
Lloyd McKenzie (Jan 19 2021 at 16:17):
There's no requirement to bind a value set to a coded element. It's completely fine to just set a fixed value for a slice. The only constraint is that if there is a binding on the element overall, all slices must adhere to the rules of that binding.
My main issue with this example is the fixed values declared for Coding.display. That's really bad practice.
Lloyd McKenzie (Jan 19 2021 at 16:17):
Also, you're constraining all coding repetitions, which is also bad practice. Much better to slice by pattern and declare just code and system.
Robert McClure (Jan 19 2021 at 16:50):
@Lloyd McKenzie
There's no requirement to bind a value set to a coded element. It's completely fine to just set a fixed value for a slice. The only constraint is that if there is a binding on the element overall, all slices must adhere to the rules of that binding.
That seems sloppy to me, but perhaps I'm confused about something. Is it true that if a slice fixes to a specific coding in this case a mustSupport, that implementers will have to make sure that whatever value set is implemented also includes any code that is in the slice? If that is correct, then we are hiding requirements that the IG author should make more specific.
BTW, I completely agree with your suggestion on how to specify the slice.
Yunwei Wang (Jan 19 2021 at 17:06):
@Lloyd McKenzie I would like to clarify this. The value[x] has an example binding in base profile. While slicing it, the author could ignore the binding and put any system/code in the slice since the binding strength is example?
Lloyd McKenzie (Jan 19 2021 at 17:26):
Technically, even if they defined a required binding, they wouldn't have to ensure the binding contained the code - however that would mean that when sending the fixed code they might have to send a translation that was in the value set as an additional coding. If the binding was looser, then there'd be less of an issue.
Example bindings are completely ignorable from an implementer perspective. They carry no weight in terms of implementation expectation - they're just to give an idea of the kinds of concepts that could potentially be used.
Rob Hausam (Jan 19 2021 at 17:27):
I was just going to say something similar with respect to the example binding.
Robert McClure (Jan 21 2021 at 23:41):
@Lloyd McKenzie You are just restating the party line on what each of these things means but you are missing the interdependency allowed by this (my word) - sloppy - capability to have a must support slice that requires a specific code in an element with an example binding. It's saying two different things that are yes, technically, not in conflict but is a hidden dependency that is very unclear. This is saying there is "there is no binding" but also "you must support this code." FHIR might think this makes sense but that element has implementation requirements that are hidden in the slice.
Lloyd McKenzie (Jan 21 2021 at 23:58):
What would you suggest? Forcing the example binding to include the code seems like unnecessary busy-work, especially for an example binding. Reality is implementers must look at both fixed values and bindings and invariants to understand what they have to worry about.
Robert McClure (Jan 22 2021 at 00:15):
I think at a minimum we need to clarify exactly what you just said if in fact it is how we want this capability controlled - through each of those levers independently.
Confirm for me: The approach taken is a known approach for communicating the requirement to implementers that they must include and understand the code in the slice with no requirement that the code be in the bound value set? If yes, then I think vocab needs to agree this is makes sense. We will also need to explain that the binding is only part of the requirements implementers have on values that must be implemented for that element. This is very different than any other product we have. And this sort of process should not just "be ok" based on FHIR-I, but an agreed upon approach that meets all user needs in a transparent way. TO be clear, I'm not saying this need is wrong. I'm saying it's sloppy communication. @Carol Macumber
Lloyd McKenzie (Jan 22 2021 at 00:24):
If a binding is applied to a repeating element, that binding applies to all repetitions. (I just submitted an issue indicating that we have a problem on some of our resource elements because of that - https://jira.hl7.org/browse/FHIR-30501.) However, example and preferred bindings are irrelevant from a conformance perspective. If there's a required binding, you could have an invariant or slice that forces something else as well, but that should be unusual. Most typical would be to force a fixed value/pattern for a high-level categorization and then a required binding to specify the detail.
Lloyd McKenzie (Jan 22 2021 at 00:24):
I can't see any rules we could make here that wouldn't have reasonable use-cases that would violate the rule.
Robert McClure (Jan 23 2021 at 00:40):
@Lloyd McKenzie Can you give a link that documents what you have said here? Where is this policy stated so that IG devs understand they can do this and implementers understand the implications of it?
Jean Duteau (Jan 23 2021 at 01:38):
@Robert McClure I don't think there is a policy anywhere but it makes total sense and has been how I've been building my IGs.
Jean Duteau (Jan 23 2021 at 01:39):
You have to remember that example bindings are basically no binding at all. Preferred bindings have more weight but don't actually impose any real constraints since I can use any code I want. Obviously Extensible and Required actually do impose a constraint.
Jean Duteau (Jan 23 2021 at 01:41):
So if I have a data element that has an example or preferred binding and I constrain that to have a fixed code, I don't need to bind it to a value set first just so I can fix the code. You could do that but I don't see the point to that. Just adds a level of indirection (maybe misdirection?) - "here is this value set you have to take one of your codes from, except that I have fixed it to just be this one code."
Lloyd McKenzie (Jan 23 2021 at 04:17):
Right. This isn't a "policy". It's just how the machinery works. Bindings exist, fixed values exist, patterns exist and invariants exist. We haven't declared any dependency amongst them, which means that no dependency exists. And there's no need for a dependency to exist. The only time you'd actually run into trouble is if you had an element of type 'code' or 'Coding' and specified both a fixed value or pattern and also a fixed binding that conflicted. Even then, I'm not sure if the publication machinery would catch it - it'd just be impossible to create an instance that satisfied the constraints.
Whether implementers understand this (or anything else) will vary. Fixed values and invariants are widely understood. Patterns, perhaps less so. And bindings less still. But declaring a 'policy' that just reflects current reality isn't likely to make that better.
Robert McClure (Jan 23 2021 at 16:09):
Folks, to be clear, I'm not disagreeing with the value of meeting different needs using the appropriate capability. What I'm pointing out is this is completely different than what we have done in other product families and explaining to designers and implementers the resulting functionality and dependencies is useful. And we need to make sure those of us who work explicitly with terminology understand how to communicate and teach the policy.
Whether implementers understand this (or anything else) will vary. Fixed values and invariants are widely understood. Patterns, perhaps less so. And bindings less still. But declaring a 'policy' that just reflects current reality isn't likely to make that better.
This is the part that I simply do not agree with. Why on earth would we not make this approach clear? This subtle blaming of users that they will not understand things if we make them clear, is not justifiable. In particular I want to be able to point to guidance that clarifies all the places in FHIR that must be reviewed to determine what values must be computably understood and may be exchanged for an element. Until this thread, I would have said it was solely determined by the binding. To blame me for misunderstanding because I am not fully FHIR developer-knowledgable is not a solution. I'll help, let's clarify.
Lloyd McKenzie (Jan 23 2021 at 16:15):
If you'd like to submit a change proposal with wording you feel makes things more clear, by all means do :)
Robert McClure (Jan 23 2021 at 16:35):
Given that I'm just learning of this, I'm not able to clarify what it means so I'll happily accept your assistance @Lloyd McKenzie
Bryn Rhodes (Jan 23 2021 at 16:41):
The slice on useContext there isn't intended to provide a configuration point, it's a fixed value constraint to indicate that the instance is for use in public health reporting. I would agree that it should only be a constraint on a single slice, and I agree the use of pattern on system and code only would be a better practice, but I also agree that this isn't a case where a value set binding would be necessary, it's just constraining to a single code. I'd also be happy to try to help provide language to clarify the capabilities, but where would that language go?
Rob Hausam (Jan 23 2021 at 16:42):
@Robert McClure I agree that it could be useful to document this, or reference the documentation for it, in a single place that we could point people to.
Lloyd McKenzie (Jan 23 2021 at 18:14):
The only thing I can think to say is that "The content of coded elements can be constrained by fixed values, patterns, bindings and constraints. Those can be declared as applying to all repetitions of the instance, individual repetitions (via slicing) or, in the case of CodeableConcept, on individual Coding slices within the CodeableConcept. Any combination is legal so long as it's possible to construct a valid instance. For example, it's possible to have a 'required' binding on Condition.code requiring a SNOMED code as well as a 'pattern' that forces the presence of a specific ICD10 code because it's possible to have multiple codings within Condition.code and thus satisfy both."
Lloyd McKenzie (Jan 23 2021 at 18:14):
If you like that text, you can figure out where you'd like it to appear :)
Rob Hausam (Jan 23 2021 at 18:17):
That's probably not too bad to start with.
Robert McClure (Jan 23 2021 at 18:56):
Proposed Modification:
The content of coded elements can be constrained by any combination of fixed values, patterns, bindings and constraints. One of these constraint can be declared as applying to all repetitions of the instance (via binding where appropriate) or individual repetitions (via slicing.) For an element using CodeableConcept, individual Coding slices within the CodeableConcept can independently constrain using any of these methods. For an element, any combination is legal so long as it's possible to construct a valid instance. This means that a summary of all allowed values can only be determined by assessing all the constrain options used for that element. For example, it's possible to have a 'required' binding on Condition.code requiring a SNOMED code as well as a 'pattern' that forces the presence of a specific ICD10 code because it's possible to have multiple codings within Condition.code and thus satisfy both.
Robert McClure (Jan 23 2021 at 19:02):
Help me with "patterns." Is that a specific thing we need to mention in a specific way?
Lloyd McKenzie (Jan 23 2021 at 20:15):
I don't want to call out 'binding' as special - it's not.
How about: "The content of coded elements can be constrained by any combination of fixed values, patterns, bindings and constraints. If specified at the element level, the constraint applies to all repetitions. If applied to slices, the constraints can be limited to a subset of repetitions for repeating elements and, for CodeableConcepts, it's also possible to define constraints for subsets of the codings. All constraint assertions are independent, but authors SHOULD ensure that constraints are not defined in a way that makes it impossible to satisfy all the constraints in a single instance. For example, if an element is of type code, it's not useful (though not strictly prohibited) to have a 'required' binding to SNOMED codes while also asserting a fixed value that's an ICD-10 code. The only way to satisfy both constraints would be to omit the element entirely. On the other hand, if the data type were a CodeableConcept, it'd be possible to have an instance with multiple codings, and thus satisfy both the binding and the fixed value."
Peter Jordan (Jan 23 2021 at 23:22):
Some of that advice is probably going to confuse 'authors' (presumably those creating profiles and IGs) and completely bamboozle those of us blessed with the task of developing working software. In particular, it makes no sense (to me anyway) to bind any element with a datatype of code to SNOMED CT as that code in insolation (i.e. without a code system uri or description) is meaningless when received in a resource. So far, just about every element of datatype code that I've used has been in a mandatory field with a required binding strength , exposed by the .NET Reference Library as an enumerated datatype and a member of a Value Set that contains meaningful codes (i.e. understandable by humans and machines ). For examples, take a look at the MedicationRequest resource.
Lloyd McKenzie (Jan 24 2021 at 00:00):
The point of the example is that it's possible to create constraints that are impossible to satisfy, but in most cases even if you have 'conflicting' constraints, you can still create an instance that satisfies all of them.
Peter Jordan (Jan 24 2021 at 02:06):
@Lloyd McKenzie Do you mean you can create an instance that satisfies all of the constraints or just one of them?
Lloyd McKenzie (Jan 24 2021 at 02:48):
Instances must satisfy all declared constraints
Lloyd McKenzie (Jan 24 2021 at 02:50):
So if there's a pattern saying "must have exactly this ICD-10 code" and a required value set drawing only from SNOMED, that can't be satisfied for 'code', but can be satisfied for CodeableConcept.
Peter Jordan (Jan 27 2021 at 03:34):
How about this gem from the extensible binding to patient.martialStatus - particularly the definition of the concept for UNK ('unknown')!
Lloyd McKenzie (Jan 27 2021 at 03:56):
Unknown isn't mutually exclusive with extensible. 'Other' is though. If you know the marital status and it's not equivalent to or a specialization of any of those listed, then extensible would be ok. The big problem is that the space is completely covered by the codes. Either you're married or you're unmarried. The intersection of those two concepts, by definition, covers the entire space, so any esoteric thing you could come up with would have to fall under one or the other. Unless somehow there's a state that somehow allows you to be simultaneously both? The reality is that the code system is total junk. Specialization relationships should exist that aren't there, and there's no recognition that you could be many of those things simultaneously - because multiple relationships could exist.
Lloyd McKenzie (Jan 27 2021 at 04:36):
@Brian Postlethwaite
Grahame Grieve (Feb 04 2021 at 22:04):
@Lloyd McKenzie the last proposed draft above could be improved by restructuring it to first talk about binding and then secondarily to talk about slices. As it is, it mixes the concepts and the slicing and introduces slicing on the sly
Last updated: Apr 12 2022 at 19:14 UTC
