Stream: terminology
Topic: How does cardinality and binding interact
Eric Haas (Feb 09 2017 at 21:58):
What does a required binding to a repeating CodeableConcept element mean? For example if Observation.category had a required binding to ObservationCategoryCodes? Does it mean any of the codings in any of the repeats must have the code from the valuesets or each of the codeableconcepts repeats must contain a code from the valueset? Same question for Extensible bindings
Grahame Grieve (Feb 09 2017 at 21:59):
each of the codeableconcepts repeats must contain a code from the valueset
Eric Haas (Feb 09 2017 at 22:02):
I looked and did not see that documented. Think it would nice to mention. Gforge?
Grahame Grieve (Feb 09 2017 at 22:16):
y
Rob Hausam (Feb 11 2017 at 17:49):
agree
Alexander Henket (Feb 12 2017 at 04:45):
How would you then ever be able to slice and add a second CodeableConcept with a translation to your local set? Observation.category happens to have an example binding, so I'm hoping Eric is talking about a profile here.
But even if it is a profile: once I say Observation.category required SNOMED CT, I can then no longer legally create a derived profile that says SNOMED CT + LOINC?
Grahame Grieve (Feb 12 2017 at 09:14):
I don't think it's sensible to do this - what's a use case?
Alexander Henket (Feb 13 2017 at 12:14):
We define functional Clinical Building Blocks for use at national level. You might call them DCMs. We translate those to FHIR profiles. The CBBs or ZIBs as we refer to them, have a preference for SNOMED CT and LOINC bindings. In primary care however no one uses SNOMED CT/LOINC at all and only the National GP association codes are used. As per the usual these primary care codes do not have a 1-to-1 relationship to SNOMED CT/LOINC.
.
For primary care/primary care communication it makes sense to send the appropriate GP code along with the preferred SNOMED CT/LOINC term.
.
Example: we have a PHR sending 7-point glucose results (see other discussion in implementers) using FHIR Observations from the patient to the GP. The GP codes contain pre-coordinated concepts for these results, but both SNOMED CT and LOINC do not. The FHIR Observations need conversion into Edifact MEDLAB before the GP is able to receive them at all.
.
For interpretation of what the result is, it makes no sense to try and educate the conversion with complicated post-coordinated contextual mapping based on SNOMED CT/LOINC + Observation timing to hopefully reach the same conclusion as you would reach by just taking the GP-code.
.
If however you would send them same glucose observation to secondary care, they would have no use for the GP code, but only for the SNOMED CT/LOINC code.
Hope that covers your question?
Eric Haas (Feb 13 2017 at 23:02):
profile them separately and slice them by valuesets accordingly, not sure why the secondary care can't just use the codes that they need and ignore the translation.
Last updated: Apr 12 2022 at 19:14 UTC