FHIR Chat · Restrict Observation category

Stream: shorthand

Topic: Restrict Observation category

Christian Nau (Apr 22 2021 at 08:01):

Hello,
I would like to specify that a specific category coding (system=http://terminology.hl7.org/CodeSystem/observation-category code=laboratory) is present in the array of codeable concepts of Observation.category. Other codings should be allowed too and other codeableconcepts should be allowed. But the one I want to check needs to be present.

I tried the following:

Alias: ObsCategory = http://terminology.hl7.org/CodeSystem/observation-category

* category 1.. MS SU
* category = ObsCategory#laboratory

But this allowed category to only one codings of another system.

I also tried some slicing on category, but wasn't able to get to what I want. Here is what I tried:

* category 1..
* category ^slicing.discriminator.type = #pattern
* category ^slicing.discriminator.path = "coding"
* category ^slicing.rules = #open
* category ^slicing.description = "Slice based on category.code pattern"
* category contains labCategory  1..1 MS
* category[labCategory] = ObsCategory#laboratory

When trying to validate against the profile containing this slice, I'm getting the following error:
Internal error: Could not match discriminator ([coding]) for slice Observation.category:labCategory in profile https://.../lab-value - the discriminator [coding] does not have fixed value, binding or existence assertions

Any tips on how to accomplish my task?
Thank you.

Christian Nau (Apr 22 2021 at 09:09):

@Patrick Werner I saw a similar category slicing here https://github.com/HL7/genomics-reporting/blob/master/input/fsh/CGGeneral.fsh and was wondering how this worked for your team there?

Patrick Werner (Apr 22 2021 at 09:15):

the difference is the last row:
* category[labCategory].coding = ObsCat#laboratory
if you slice on coding, you have to set the pattern on coding as well

Christian Nau (Apr 22 2021 at 09:26):

Thank you @Patrick Werner! This shows me one mor time that men are no computers. I compared my implementation to the other one several times and could not find any differences.

Anyways, the problem is still not solved. Now I get a new error when trying to validate against the profile:
Failed to call access method: java.lang.Error: Error in profile at Observation.category: Base isSummary = false, derived isSummary = true

Chris Moesel (Apr 22 2021 at 13:03):

Are you doing something with isSummary or is that error coming out of the blue?

Christian Nau (Apr 22 2021 at 13:08):

@Chris Moesel No, I'm not setting any SU flag anywhere in this Profile.

Chris Moesel (Apr 22 2021 at 13:13):

Then that error seems... odd. Without seeing it, however, I can't tell if SUSHI is exporting something wrong in the SD JSON or if the IG Publisher is just doing something wacky on its own. Is this publicly available somewhere?

Christian Nau (Apr 22 2021 at 13:25):

I just pushed the structuredefinition resource to my HAPI(SmileCDR) backend and then tried to validate a new instance using the {baseUrl}/Observation/$validate endpoint. The structure definition is created using sushi compile for this fsh code:
https://fshschool.org/FSHOnline/#/share/2Qnas92

Christian Nau (Apr 22 2021 at 13:28):

Strange, I tested it again now and validation succeeded. Maybe SmileCDR needed some time to "see" the updated profile? I have no clue what is going on. Thanks @Chris Moesel for having a look.

Chris Moesel (Apr 22 2021 at 13:30):

Ha. OK. I just started to look at it, but I'll stand down!

Chris Moesel (Apr 22 2021 at 13:34):

While I'm looking, though... a few thoughts... Re:

// Check category
* category 1..
* category ^slicing.discriminator.type = #pattern
* category ^slicing.discriminator.path = "coding"
* category ^slicing.rules = #open
* category ^slicing.description = "Slice based on category.code pattern"
* category contains labCategory  1..1 MS
* category[labCategory].coding = ObsCat#laboratory

This approach is fine and works. I think you also could have done this:

// Check category
* category 1..
* category ^slicing.discriminator.type = #pattern
* category ^slicing.discriminator.path = "$this"
* category ^slicing.rules = #open
* category ^slicing.description = "Slice based on category pattern"
* category contains labCategory  1..1 MS
* category[labCategory] = ObsCat#laboratory

To me the latter feels a little more natural, but I expect it is a matter of preference.

Christian Nau (Apr 22 2021 at 13:39):

This is great @Chris Moesel ! I just tested if my profile allowed other (additional) category codings or codeable-concept. It didn't, but using your approach it does! (And that's what I wanted) Thank you

Chris Moesel (Apr 22 2021 at 13:42):

And regarding this:

// Check presence of LOINC code
* code.coding ^slicing.discriminator.type = #pattern
* code.coding ^slicing.discriminator.path = "system"
* code.coding ^slicing.rules = #open
* code.coding ^slicing.description = "Slice based on coding system"
* code.coding contains loincCode 1..1 MS
* code.coding[loincCode].system = LNC

If you really just want to ensure that a LOINC code is used in the code, then I think you could avoid the slicing and just use a value set:

* code from http://loinc.org/vs (required)

http://loinc.org/vs represents the value set of all LOINC codes (doc) and a value set binding only requires that at least one of the codings matches the value set (doc). So I think this says the same thing without needing to slice. But again, both work, so it's a matter of preference.

Chris Moesel (Apr 22 2021 at 13:43):

Christian Nau said:

This is great Chris Moesel ! I just tested if my profile allowed other (additional) category codings or codeable-concept. It didn't, but using your approach it does! (And that's what I wanted) Thank you

@Christian Nau -- I'm surprised. I really did think your original approach should work too. But I'm glad that my suggestion seems to work better (even if I don't understand why).

Christian Nau (Apr 22 2021 at 13:43):

Just for my understanding: I thought that ^slicing.rules = #open allows other values for codings. So why didn't my approach work?

Christian Nau (Apr 22 2021 at 13:44):

Ok, so I'm not the only one suprised :)

Chris Moesel (Apr 22 2021 at 13:44):

I don't know. That's why I said I was surprised. I would have expected it to work just fine since your rules are #open.

Christian Nau (Apr 22 2021 at 13:58):

Chris Moesel said:

If you really just want to ensure that a LOINC code is used in the code, then I think you could avoid the slicing and just use a value set:

Another very appreciated suggestion! I already had a value-set for my lab-value-profile (containing LOINC codes) but forgot to use it here. Thanks!

Patrick Werner (Apr 22 2021 at 14:42):

Christian Nau said:

Just for my understanding: I thought that ^slicing.rules = #open allows other values for codings. So why didn't my approach work?

your approach only checked if the system equals the LOINC System string.
VS binding tells the validator to also check if the value is a valid value

Christian Nau (Apr 22 2021 at 14:46):

@Patrick Werner The confusion was about the category slicing, not the one for coding.

Patrick Werner (Apr 22 2021 at 14:49):

a i miss-quoted, my comment was about the difference between fixed systems and VS bindings

Patrick Werner (Apr 22 2021 at 14:50):

open slicing allows other slices of course

Christian Nau (Apr 22 2021 at 14:51):

Ah ok. Yes that's a good point. I already updated the profile to use value-set binding like @Chris Moesel suggested.

Christian Nau (Apr 22 2021 at 14:52):

Patrick Werner said: