Stream: shorthand
Topic: Adding a value type to value[x]
Max Körlinge (Mar 23 2021 at 10:26):
Hi! I am trying to add a value type to a value[x] field. I am not sure whether to use slicing or an extension for this, I have tried both and not succeeded. I am looking to add a value type to item.answer.value[x] in QuestionnaireResponse called "valueTriggerCode" which refers to a valueset/codesystem I've defined, so users of the profile can still choose to use any of the other value types possible, but also be able to use the additional one (valueTriggerCode). Is this possible with shorthand and how? Thanks =)
ryan moehrke (Mar 23 2021 at 15:24):
you probably want to restrict value[x] to CodeableConcept and then bind that CodeableConcept to your valueset. I don't think there's a valid way to define your own datatype
https://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#type-rules
https://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#binding-rules
so it would look something like
- path.value[x] only CodeableConcept
- path.value[x] from TriggerCode
Chris Moesel (Mar 23 2021 at 15:49):
As @ryan moehrke indicated, you cannot define a new concrete type (like TriggerCode) or add an additional type to an existing choice element. You can only constrain what is already there.
I think Ryan's suggestion to use a value set is right, but since you said that you wanted other values to be allowed too, you probably do not want the only rule. With that in mind, you might want something like this:
* item.answer.valueCoding from TriggerCodes (preferred)
where TriggerCodes is a value set. (BTW, using the path item.answer.valueCoding will automatically create a type slice on the choice so the binding only applies to the Coding). The strength of the binding (example, preferred, extensible, or required) will depend on if you want to allow other codes (not in TriggerCodes) as answers too.
But... note also that the above is operating on all items in the QuestionnaireResponse. I expect that maybe you really only want to constrain to TriggerCodes for specific items. To do that, you would need to use slicing to create a slice based on the linkId for the items that TriggerCodes applies to. But that starts to get a little more complex, so I won't elaborate further unless you indicate you need the help. ;-)
Max Körlinge (Mar 23 2021 at 18:29):
Thank you both, helpful as always! I think the simplest option for me right now (.. under time pressure ;) ) is to set TriggerCode as example and indicate in the documentation when that would be a good option. Slicing as you suggest would probably be a more complete and constraining way to define it but that might need to wait until a v2 of the profile. Thanks!
Max Körlinge (Mar 23 2021 at 20:04):
Hm maybe I misunderstood you @Chris Moesel , but using your suggestion (* item.answer.valueCoding from TriggerCodes (example)) seems to give me a closed slice which only includes valueCoding and not the other types. What I was looking for was for the profile to allow valueString, valueBoolean etc. as well, and just sort of.. point out the fact that a TriggerCode will be useful in many cases (but not all). Maybe I'm just not using this the way it is intended?
Chris Moesel (Mar 23 2021 at 20:37):
Hi @Max Körlinge -- I don't think you misunderstood. My suggestion was intended to allow multiple types. When I try this in FSHOnline (link), this is the only thing it renders in the differential:
"differential": {
"element": [
{
"id": "QuestionnaireResponse.item.answer.valueCoding",
"path": "QuestionnaireResponse.item.answer.valueCoding",
"min": 0,
"max": "1",
"type": [
{
"code": "Coding"
}
],
"binding": {
"strength": "example",
"valueSet": "http://example.org/ValueSet/TriggerCodes"
}
}
]
}
Note that SUSHI does not actually creating the slicing; the IG Publisher does that during snapshot generation. Based on firely's excellent Type Slicing in FHIR R4 article, the above should only apply to the Coding choice without disallowing other types. If you're seeing different behavior, it may be an issue with the IG Publisher?
Max Körlinge (Mar 23 2021 at 20:49):
Hmm okay. I get the same differential actually but I was expecting to see the other value types in the Snapshot. Probably I just don't understand the information in the snapshot hehe. This is how it looks in the generated IG
Skärmavbild-2021-03-23-kl.-21.49.16.png
Does this look right to you?
Chris Moesel (Mar 23 2021 at 20:55):
To be honest, I'm not sure. I also would have expected to see the types enumerated -- and I don't know if a closed type slice means no other types are allowed (but if it does, that's not what we want). This might be a question for @Grahame Grieve or @Lloyd McKenzie.
ryan moehrke (Mar 23 2021 at 20:57):
you may just be able to do * item.answer.value[x] from TriggerCodes (preferred) and it may format similar to the base spec's example binding
Chris Moesel (Mar 23 2021 at 21:01):
I was thinking that the spec said somewhere you could only apply the binding to the type-specific element (not the [x] element) -- but I can't find that now, so I am probably wrong. I think @ryan moehrke may be on to something!
Chris Moesel (Mar 23 2021 at 21:03):
But I did find this confirmation that using the type specific path should not constrain out the other types. From 2.30.0.4.2 Constraining elements with a choice of Type:
The inclusion of a type specific path (such as "Patient.deceasedBoolean") SHALL NOT be interpreted as constraining allowed types, but instead, it constrains the use of a particular type
So... using valueCoding should be OK too -- but if applying the binding directly to value[x] works, that may be the best option for now.
Lloyd McKenzie (Mar 23 2021 at 21:08):
Closed does indeed mean that no other types are allowed.
Lloyd McKenzie (Mar 23 2021 at 21:09):
What I'd expect to see is a path of item.answer.value and an id of item.answer.value:valueCoding
Chris Moesel (Mar 24 2021 at 00:39):
@Lloyd McKenzie -- It's my understanding that the choice type renaming syntax is valid in the id and path in the differential (but only in the differential). I see it used like that in FHIR core profiles like BP, US Core profiles like Smoking Status, and many other IGs -- so I'm pretty sure it's valid. In the snapshot, however, the full slicing syntax needs to be used (no shortcuts/renaming allowed).
Chris Moesel (Mar 24 2021 at 00:40):
But if closed slicing does indeed mean that no other types are allowed then I think there is a bug in snapshot generation -- as it should be generating the above with an open slicing then. But I'll post to #conformance to get confirmation that my understanding on that is correct.
Lloyd McKenzie (Mar 24 2021 at 00:48):
My understanding is that if the differential shows valueCodeableConcept, that means that's the only thing that's allowed
Chris Moesel (Mar 24 2021 at 00:49):
That's how it worked in DSTU2 and STU3, but they changed it in R4. See 2.30.0.4.2 Constraining elements with a choice of Type:
The inclusion of a type specific path (such as "Patient.deceasedBoolean") SHALL NOT be interpreted as constraining allowed types, but instead, it constrains the use of a particular type
Chris Moesel (Mar 24 2021 at 00:50):
Firely did a whole blog outlining that change (otherwise I would have missed it too).
Lloyd McKenzie (Mar 24 2021 at 01:21):
Then it appears there's a bug...
Chris Moesel (Mar 24 2021 at 01:23):
Yeah, I think so. I posted over in conformance (here) to get a few more eyes on it. Thanks, Lloyd!
Max Körlinge (Mar 24 2021 at 08:40):
Thanks for going to the bottom with this. Applying the binding to value[x] works well for me right now
Last updated: Apr 12 2022 at 19:14 UTC
