Stream: implementers
Topic: code.coding slicing and it's code in FHIR BodyTemp profile
Pauli Koskinen (Sep 27 2017 at 10:09):
BodyTemp profile http://hl7.org/fhir/bodytemp.html#10.1.19.32 has code.coding sliced with discriminator value:code and it is Open. Coding has cardinality of 0..*. It has one slide with fixed LOINC code 8310-5.
Loinc has multiple codes for temperature; https://r.details.loinc.org/LOINC/75965-4.html?sections=Comprehensive .
Specification says 'Other additional codes are allowed - e.g. more specific LOINC Codes'
One slice with fixed code prevents use of more specific LOINC code.
Obviously FHIR bodytemp profile can not be use directly to store specific codes in resources. How should it be used?
In our case we would like to make slice with code 8310-5 mandatory, and slice with specific code optional (for example oral temperature). Should we create an additional slice to our own profile, with cardinality 0..1 and no fixed code?
There is extensible valueset binding to fhir/valueset-observation-vitalsignresult in observation.code level, but we would like to have required binding to own valueset listing acceptable codes. Is this recommended way to handle more specific codes in our profile?
Lloyd McKenzie (Sep 27 2017 at 14:49):
I'd recommend submitting a change request. The body temperature profile should slice by both system and code. That way you can have alternate codes from other code systems. If you have a specific value set of additional codes, you can define a slice that has that required binding and the slicing should work.
Lloyd McKenzie (Sep 27 2017 at 14:49):
@Eric Haas Do you agree on not fixing to LOINC?
Eric Haas (Sep 27 2017 at 15:35):
Its sliced that way to allow other codes. The binding is extensible to allow other codes (LOINC, SNOMED, Local or whatever) as translations ( additional codings) The value set is not limited to a single code system and can be extended to other code systems. I am not sure what benefit is gained by slicing by system.
Eric Haas (Sep 27 2017 at 15:37):
The only collisions would occur in the unlikely event of identical codes from system a and system b
Eric Haas (Sep 27 2017 at 15:39):
and I'm not imagining a lot of translations typically 2 or 3. "magic value" LOINC, more specific LOINC or SNOMED, and local code
Lloyd McKenzie (Sep 27 2017 at 20:26):
Sorry. I had read that LOINC was a fixed value because you were only slicing by code, not system. You probably should specify both as the discriminator as there could be a need for multiple codes with the same value from different systems.
Eric Haas (Sep 27 2017 at 20:29):
I think that would be extremely rare but I will update for R4
Eric Haas (Sep 27 2017 at 20:33):
Chris Moesel (Sep 27 2017 at 22:54):
I've noticed that U.S. Core takes a slightly different approach. For example, consider their smokingstatus profile (http://hl7.org/fhir/us/core/StructureDefinition-us-core-smokingstatus.html). In this profile, rather than slicing on code.coding, they simply apply a patternCodeableConcept.
Is there a tangible difference here? Based on my understanding of pattern[x], it also allows for additional values -- so it seems like it is accomplishing the same goal. Is there a preferred approach? Are there use cases that would call for one and not the other?
Eric Haas (Sep 27 2017 at 23:29):
simple answer is that there were multiple profile authors and the profiles were created at different times as the discriminators and tooling was undergoing development. Hence the variations. Discriminator on code and system is the same a on pattern {"coding":[{"system":"[sytem]","code":"[code]"}]} However there is this little nugget from the pattern comments: "Mostly used for fixing values of CodeableConcept. At present, pattern[x] is not recommended as a basis for slicing while issues related to this are investigated during the STU period."
Eric Haas (Sep 27 2017 at 23:30):
@Lloyd McKenzie probably has some deeper understanding of some subtle differences.
Eric Haas (Sep 27 2017 at 23:32):
I prefer listing out each discriminator vs pattern
Lloyd McKenzie (Sep 28 2017 at 04:41):
Pattern was broken for a long time. It now seems to be fixed, though slicing by both system & code I think makes for slightly clearer documentation
Pauli Koskinen (Sep 28 2017 at 06:15):
In our case fixing to LOINC is ok and we have no need to use other code systems.
We try to build a profile that is quite strict. Meaning that the profile has so exact value bindings that profile based resource validation validates observation.code of the resource in resource server when storing the resource. We have on valueset that contains relevant bodytemperature LOINC codes picked from Rosetta temperature panel. Coding would have cardinality 1..2 and be sliced. First slice cardinality 1..1 and code fixed value 8310-5 (main temperature code). Other slice cardinality 0..1 and no fixed code value. Binding to that valueset in observation.code level and relates to both slices. Code is naturally mandatory in both slices.
Is that profile design possible based on FHIR bodytemperature profile?
The profile that I am talking about is https://simplifier.net/FinnishPHR/fiphr-bodytemperature-stu3 . That is not based on FHIR bodytemperature profile but fiphr-vitalsigns-stu3 which is based on Observation. With this structure we were able to build profile described above.
When using with HAPI resource server it gives error 'Element matches more than one slice'. I am not ble to say if it is a bug in HAPI or other problem. But due to that error our current profile in Simplifier has more slices, one for each specific temperature LOINC code with fixed code value.
Do you consider this profile design reasonable to include specific codes and profile based validate them strictly in resources? Are we FHIR vitalsigns and bodytemperature compatible with this design?
Lloyd McKenzie (Sep 28 2017 at 14:34):
That design is certainly possible. However, preventing other systems from sending you additional codes you don't care about (and could ignore) means you're forcing those systems to customize their interface just for your system, which is generally a bad idea. It'd be better to leave the cardinality of Coding 1..* and define the two slices that are "mustSupport" and then plan to ignore everything else. That way if a client needs to talk to your system plus someone else who requires a different code system, they can spit out the same instances to both of you and you can each pay attention to what you wish. It should certainly be possible to have a profile that meets the HL7 vital signs requirements and the Finish requirements.
Last updated: Apr 12 2022 at 19:14 UTC
