FHIR Chat · Binding a CodeableConcept to two valuesets · shorthand

Stream: shorthand

Topic: Binding a CodeableConcept to two valuesets


view this post on Zulip Josh Mandel (Apr 08 2021 at 16:01):

I'm likely trying to do this wrong -- would love advice about 1) how to narrowly fix the specific example here, and 2) what I should be doing instead ;-)

I want to describe a CodeableConcept profile that says "I must contain a Coding from VS1 and a Coding from VS2" (technically I want something even narrower: "I must contain the specific coding X and the specific coding Y", but I'm papering over this by defining two ValueSets each with a single concept). I'm naively writing:

Profile: C19ServiceCodeableConcept
Parent: CodeableConcept
Id: c19-service-codeable-concept
* . from VS1
* . from VS2

... but I can't use . in this way to refer to the CodeableConcept ("error Cannot bind value set to ; "). Is there something like $this or self that I can write instead, or is my idea just wrong, or is this a rational goal that just isn't supported by syntax today? (Writing * coding from VS1 doesn't express my intended meaning, because I don't want all codings bound.)

view this post on Zulip Lloyd McKenzie (Apr 08 2021 at 17:09):

StructureDefinition itself doesn't allow multiple bindings. If you want multiple bindings, you need to slice coding and define different bindings per slice.

view this post on Zulip Josh Mandel (Apr 08 2021 at 17:11):

Thanks @Lloyd McKenzie . I'll do this (I'm already using slicing at the level of the resource that contains this CodeableConcept in an array, but I think I need it in both places).

view this post on Zulip Josh Mandel (Apr 08 2021 at 17:24):

Here's what I put together, then: https://fshschool.org/FSHOnline/#/share/39Vr4Lx

I'd love feedback on whether this is a valid way (and if so: the preferred way?) to say "serviceType[] needs to include at least one CodeableConcept that includes at least these two specific Codings".

view this post on Zulip Josh Mandel (Apr 08 2021 at 17:25):

(FYI @Michael O'Keefe this relates to #smart/scheduling-links; figured I'd use it as an excuse to learn a bit more FSH before just asking you to add this to the profiles.)

view this post on Zulip Lloyd McKenzie (Apr 08 2021 at 17:29):

I don't see anything 'wrong' - but you're not actually specifying multiple bindings?

view this post on Zulip Josh Mandel (Apr 08 2021 at 17:29):

Actually for my discriminator path, I realize this isn't being validated by sushi at all, so I may be doing it wrong:

Profile: C19ServiceCodeableConcept
Parent: CodeableConcept
Id: c19-service-codeable-concept
* coding ^slicing.discriminator.type = #pattern
* coding ^slicing.discriminator.path = "."

Is "." the right way to say it? Or should it be "$this", or something else? (If I change "." to "NO#$$BAD!", sushi happily passes this through to its output, which made me lose confidence.)

view this post on Zulip Josh Mandel (Apr 08 2021 at 17:30):

    immunizationAppointment 1..1 and
    c19ImmunizationAppointment 1..1

This requires that both required codings are present... I hope?

view this post on Zulip Josh Mandel (Apr 08 2021 at 17:30):

(If I needed to bind to two value sets, I could do that with additional lines... but since the codings are directly specified, binding to a valueset would be superfluous, right @Lloyd McKenzie ?)

view this post on Zulip Lloyd McKenzie (Apr 08 2021 at 17:41):

Specifying codings directly is fine. You had just asked about multiple bindings, so I was a bit confused when you weren't actually doing that :)

view this post on Zulip Josh Mandel (Apr 08 2021 at 18:47):

(Sorry, I had updated my initial question to explain this nuance!)

(technically I want something even narrower: "I must contain the specific coding X and the specific coding Y", but I'm papering over this by defining two ValueSets each with a single concept).

view this post on Zulip Chris Moesel (Apr 08 2021 at 20:30):

Hey @Josh Mandel -- glad to see you giving FSH a try! I think you're pretty close to what you want to do. You do want to use $this as your discriminator path.

Re this:

* serviceType[c19Service] ^type.profile = "http://example.org/StructureDefinition/c19-service-codeable-concept"

you asked:

Is there a way to infer "This IG's prefix"?

and the answer is yes. You can use the Canonical function to do that:

* serviceType[c19Service] ^type.profile = Canonical(C19ServiceCodeableConcept)

But actually there is an even simpler way to accomplish what you are trying to do:

* serviceType[c19Service] only C19ServiceCodeableConcept

https://fshschool.org/FSHOnline/#/share/3uANN7w

I'll also confirm, SUSHI does not attempt to validate slicing parameters or individual slices. That's a level of complexity we did not want to take on and feel pretty ok about that since the IG Publisher will do that validation for you when you build it there.

view this post on Zulip Josh Mandel (Apr 08 2021 at 20:32):

Thanks @Chris Moesel for the encouragement, and for answering the questions I knew how to ask, and for answering the questions I didn't know how to ask!

view this post on Zulip Chris Moesel (Apr 08 2021 at 20:44):

Yep, you can use only to narrow a choice to a smaller subset of choices (or a single item) - but you can also use only to narrow a type to a profile (or a set of profiles).

All that said, I probably should have mentioned: sometimes the validator gets cranky when you slice an array and then slice a sub-property within that array's items. So... although I think what you're doing is technically valid, you might want to double-check that the validator handles it OK. You can do that by creating an example of the VaccineSchedule and seeing if the IG Publisher reports any validation errors on it due to nested slicing. Hopefully not! (BTW -- I created the simplest of examples here: https://fshschool.org/FSHOnline/#/share/2QciCAs).

view this post on Zulip Josh Mandel (Apr 08 2021 at 20:45):

but you can also use only to narrow a type to a profile (or a set of profiles).

I was just reading http://hl7.org/fhir/uv/shorthand/reference.html#type-rules -- it wasn't clear to me that you can refer to profiels this way. is this implied by "<element> only {datatype}" ?

view this post on Zulip Josh Mandel (Apr 08 2021 at 20:47):

You can do that by creating an example of the VaccineSchedule and seeing if the IG Publisher reports any validation errors on it due to nested slicing.

Yeah, it's never clear to me what the existing tools will support, and where they might break. Any thoughts on how to incorporate this kind of "try and see" validation functionality into FSH Online?

view this post on Zulip Josh Mandel (Apr 08 2021 at 20:49):

I guess the challenge would be generating positive and negative examples, and making sure the validator deals with both.

view this post on Zulip Chris Moesel (Apr 08 2021 at 20:52):

Yes, I think <element> only {datatype} covers that use case, but also covers the use case of restricting a choice to a single type. We could probably make that more clear. There is also some narrative in the spec that addresses it:

Following standard profiling rules established in FHIR, the data type(s) in a type rule MUST always be more restrictive than the original data type. For example, if the parent data type is Quantity, it can be replaced by SimpleQuantity, since SimpleQuantity is a profile on Quantity (hence more restrictive than Quantity itself), but cannot be replaced with Ratio, because Ratio is not a type of Quantity.

view this post on Zulip Chris Moesel (Apr 08 2021 at 20:56):

As for FSH Online, "try and see" w/ the Java validator is a little tricky because FSH Online is a fully client-side web application. It is hosted on GitHub pages and has no backend API/database/server -- only the standard GH Pages HTTP server. So... we can't run Java on the backend, and we can't run Java on the frontend, so... the only way it would work is if there was some other service we could post the FHIR definitions to for validation.

view this post on Zulip Chris Moesel (Apr 08 2021 at 20:57):

And for a variety of reasons we've been intentionally avoiding having to acquire and maintain a real backend server (hence the use of GitHub pages).

view this post on Zulip Josh Mandel (Apr 08 2021 at 21:04):

the only way it would work is if there was some other service we could post the FHIR definitions to for validation.

And for a variety of reasons we've been intentionally avoiding having to acquire and maintain a real backend server (hence the use of GitHub pages).

Yeah. I get it. Sounds like writing a from-scratch validator in typescript (+ terminology packs) is the only thing for it ;-)

view this post on Zulip Josh Mandel (Apr 08 2021 at 21:05):

A near-term QoL step might be "click here to download a bash script that downloads your profiles from fshonline, loads them into the FHIR jar validator, and invokes it"

view this post on Zulip Josh Mandel (Apr 08 2021 at 21:06):

Love your use of bitly for state management BTW ;-)

view this post on Zulip Chris Moesel (Apr 09 2021 at 02:31):

Ha. Yeah, without a backend server we had to get creative for having some way to store and recall state. Just don't try to type too much information in there. ;-)

view this post on Zulip Chris Moesel (Apr 09 2021 at 02:34):

My idea for an "upgrade" is to support a GitHub integration so users can auth against GitHub and use gists for storing/retrieving longer FSH snippets.


Last updated: Apr 12 2022 at 19:14 UTC