Stream: implementers
Topic: Binding element with a choice of types
Richard Townley-O'Neill (Jan 21 2022 at 07:43):
The vital signs profile binds component.value to Vital Signs Units. The validator enforces this against valueQuantity. Nice.
But the validator does not enforce it against ValueCodeableConcept. Just as well, that would make the profile less useful.
Where in the docco does it say that a binding on an element with a choice of data types affects some of the data types and not others? The most relevant docco I could find was at Using Codes in Resources, but that does not cover this topic.
Does binding only affect the first listed data type?
Vadim Peretokin (Jan 21 2022 at 14:31):
How exactly does the validator enforce it?
Vadim Peretokin (Jan 21 2022 at 14:32):
I don't see why it should disallow other datatypes - all the profile says is that if it's a type that can take in a code, it should be a code from this valueset.
Gino Canessa (Jan 21 2022 at 16:42):
The general page you are looking for is Profiling, and I am guessing the exact part you are looking for is in Slicing or Discriminator.
Rob Hausam (Jan 21 2022 at 23:24):
@Richard Townley-O'Neill The required binding to the ucum-vitals-common value set is on Observation.component.value[x]. So the binding should apply to all of the data type slices (e.g., including both valueQuantity and valueCodeableConcept). If the Validator isn't enforcing that binding on valueCodeableConcept, then that is not what I would expect from the StructureDefinition - and I think it probably would indicate that there is actually an issue with the Validator. I think the reality is that the binding was done that way because there probably isn't any expected use of the Vital Signs profile with valueCodeableConcept, so it really might not matter much whether or not the validator does what is expected there. Probably, it might have made sense and would be more clear if the binding to ucum-vitals-common was made directly on the valueQuantity slice, which is where it logically applies. But, again, practically that may not matter too much in this case.
Richard Townley-O'Neill (Jan 24 2022 at 00:27):
Rob Hausam said:
I think the reality is that the binding was done that way because there probably isn't any expected use of the Vital Signs profile with valueCodeableConcept, so it really might not matter much whether or not the validator does what is expected there. Probably, it might have made sense and would be more clear if the binding to ucum-vitals-common was made directly on the valueQuantity slice, which is where it logically applies. But, again, practically that may not matter too much in this case.
That makes sense to me as history.
However, I suspect that the VitalSigns profiles are being extensively used as design patterns and so obscure mistakes like that will be reproduced frequently.
Suggestions
1 / On the terminologies page clarify that binding an element with multiple types applies to all bindable types,
2/ Revise the VitalSigns profile in R5 to put the binding in the correct place.
3/ Revise the validator to apply the binding test as documented.
Richard Townley-O'Neill (Jan 27 2022 at 07:21):
@Rob Hausam If the binding is a good idea on VitalSigns.component.valueQuantity, why not also have it on VitalSigns.valueQuantity?
Richard Townley-O'Neill (Jan 27 2022 at 07:26):
@Lloyd McKenzie should I create a Jira issue to request that the terminologies page clarify that binding an element with multiple types applies to all bindable types.
Richard Townley-O'Neill (Jan 27 2022 at 07:26):
@Grahame Grieve should I create a GitHub issue to revise the validator to apply the binding test as documented?
Grahame Grieve (Jan 27 2022 at 19:10):
sure create a test case that demonstrates the problem
Lloyd McKenzie (Jan 27 2022 at 21:39):
You could also submit a Git issue against the publisher asking for a warning if a polymorphic element has a binding. Best practice is generally to slice and put bindings on the slices.
Richard Townley-O'Neill (Jan 28 2022 at 04:33):
Jira issues:
- VitalSigns binding problem FHIR-35803
- Document binding to multi data type element: FHIR-35891
Richard Townley-O'Neill (Jan 28 2022 at 06:14):
@Grahame Grieve
Validator seems fine. It tests the binding on Quantity, CodeableConcept and string, and not on Range (which includes two Quantity elements, but is not mentioned as bindable on http://hl7.org/fhir/R4/terminologies.html)
Richard Townley-O'Neill (Jan 28 2022 at 06:16):
- GitHub request for validator warning #384
Rob Hausam (Jan 28 2022 at 15:12):
Agree with this and with handling VitalSigns.valueQuantity and VitalSigns.component.valueQuantity the same.
Last updated: Apr 12 2022 at 19:14 UTC
