Stream: shorthand
Topic: double coding
John Moehrke (Jun 04 2021 at 14:38):
I have run across a problem with sushi. I say problem, you might say I am using the tool wrong.
Given a Profile on Observation includes this constraint
* category 1..1
* category = http://terminology.hl7.org/CodeSystem/observation-category#vital-signs
And an example using that Profile includes this
* category = http://terminology.hl7.org/CodeSystem/observation-category#vital-signs
When I run sushi
Then I get an example json object with
"category" : [
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/observation-category",
"code" : "vital-signs"
}
]
},
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/observation-category",
"code" : "vital-signs"
}
]
}
],
John Moehrke (Jun 04 2021 at 14:43):
I get that I should not need to put the category in my examples, but it feels like the right thing to do for explicitness. Why would sushi presume this -second- category should be automatically promoted to category[+]?
Chris Moesel (Jun 04 2021 at 14:44):
I agree, that doesn't seem right. In fact, I'm surprised, because I thought SUSHI did something different here. We recently fixed a bug in some code tangentially related to this -- I might try this with our not-yet-released version to see if it is still an issue.
Chris Moesel (Jun 04 2021 at 14:48):
Actually, when I run that with the latest released version of SUSHI (1.3.2) on FSH Online, I'm not seeing the duplicate category: https://fshschool.org/FSHOnline/#/share/3gfr23M
John Moehrke (Jun 04 2021 at 14:53):
scary... I just checked... whew.. I have fresh sushi...
John Moehrke (Jun 04 2021 at 14:54):
the profile in my above is also a profile off of core vitalsigns
Parent: http://hl7.org/fhir/StructureDefinition/vitalsigns
Chris Moesel (Jun 04 2021 at 15:22):
Ah, yes. That is the difference.
I think this is because the parent profile fixes the category by slicing code.coding and then specifying a coding slice with the system and code each independently fixed to separate values. Your profile, however, takes an entirely different approach by using a patternCodeableConcept at the code level to specify a single pattern to apply (that holds the coding system and code in it).
Those two are basically trying to accomplish the same thing, but doing it in very different ways. SUSHI knows how to handle both ways, but doesn't recognize them as equivalent -- so it applies the required slice and its child fixed values from the parent and also applies the pattern from your profile. TBH, this would probably be fairly tricky to detect and resolve in a robust way.
The intent of profiling is usually to describe what is different from the thing you are profiling. In this case, I think you will be better off and cause less confusion for our tool (and probably others) if you don't double-define that fixed category in the profile. If your approach to it was the same as the parent's approach to it, it might just work out -- but trouble comes in because your duplicated constraint is constraining using an entirely different mechanism than the parent.
John Moehrke (Jun 04 2021 at 15:26):
that is what I feared
John Moehrke (Jun 04 2021 at 15:26):
My profile is specifically mandating 1..1
John Moehrke (Jun 04 2021 at 15:27):
I can remove the second line mandating the code.. with precognition by human (not computable) that it is the same.
John Moehrke (Jun 04 2021 at 15:27):
so much for 'profiles are great because they are computable'
John Moehrke (Jun 04 2021 at 15:29):
this means my profiles need to be different pattern when they are based on core vitalsigns, vs when they are deviating for some business reason.
John Moehrke (Jun 04 2021 at 15:36):
I can confirm that removing that from my profile did fix the problem.
Chris Moesel (Jun 04 2021 at 15:49):
John Moehrke said:
this means my profiles need to be different pattern when they are based on core vitalsigns, vs when they are deviating for some business reason.
Well, by declaring another profile (outside of your control) as a parent, you are already introducing approaches that may not be consistent w/ your own approaches. You can't remove the inherited slicing logic from the parent, so you're kind of stuck with it. IMO, it's better to let it be than to layer on another constraint using a different approach that says the same thing.
Your other option would be to declare your own vital-signs profile with similar constraints such that any instance that conforms to your profile also conforms to the official vital-signs profile (even though there is not a formal relationship). But creating duplicate profiles that are semantically the same is also generally discouraged... :-/
John Moehrke (Jun 04 2021 at 15:53):
agreed. and I understand why vitalsigns core is that way. They don't want to forbid other category codes in addtion to vitalsigns
John Moehrke (Jun 04 2021 at 15:53):
my profile simply needs to say 1..1... so, i have
John Moehrke (Jun 04 2021 at 15:55):
note that the other places where I did this... a few months ago.. I learned thru the build errors that it was a bad idea.. so those already had this line commented out with a reason for the comment. But clearly I am too old to remember this lesson, so I learned it again.
Gino Canessa (Jun 04 2021 at 15:56):
I like to add counters to comments like that, so that I can see how many times it takes for me to actually learn it =)
John Moehrke (Jun 04 2021 at 16:05):
it is 4 for me
Gino Canessa (Jun 04 2021 at 16:08):
It is 4 for you... so far :-P
Chris Moesel (Jun 04 2021 at 16:10):
John Moehrke said:
agreed. and I understand why vitalsigns core is that way. They don't want to forbid other category codes in addtion to vitalsigns
This is true of their approach, but it is also true of patterns. If a pattern contains an array, it allows for other values in the array as well. The pattern just indicates the minumum requirements for the array. But I don't think patterns were used or understood much back when the vital-signs profiles were created.
Elliot Silver (Jun 04 2021 at 16:17):
John Moehrke said:
scary... I just checked... whew.. I have fresh sushi...
Thank goodness. That three-day old, mall sushi is scary.
John Moehrke (Jun 04 2021 at 16:38):
especially in the midwest... vs Vancouver.
Jean Duteau (Jun 04 2021 at 16:49):
Elliot Silver said:
John Moehrke said:
scary... I just checked... whew.. I have fresh sushi...
Thank goodness. That three-day old, mall sushi is scary.
Yumm...stale dry rice with shrimp that has shrivelled up a bit. That's really the most adventurous sushi!
David Pyke (Jun 04 2021 at 16:49):
I avoid that by only buying from the gas station on the corner. That's fresh every day or two.
Elliot Silver (Jun 04 2021 at 17:52):
David Pyke said:
I avoid that by only buying from the gas station on the corner. That's fresh every day or two.
Sorry, no gas station sushi for me. If I'm looking to be killed by my sushi, I'm going with nothing less than fugu.
Last updated: Apr 12 2022 at 19:14 UTC
