Stream: implementers
Topic: How should valueset bindings be profiled in codeableConcept?
Eeva Turkka (Feb 16 2017 at 13:19):
We'veve developed our own valueset for a subset of loinc codes. This subset specifies a list of observation codes accepted by our application and we plan to enforce the use of values from that value set in those observations. We have made observation profiles that require use of our valueset with Forge to create profiles. The version of Forge we are using is version 14.7 just now. The value sets and profiles can be in Simplifier in the FinnishPHR project, check the latest ones as we've been fixing them
We have not found clear instructions where to set valueset binding in profiles. Forge allows configuring the valueset binding in observation.code level, observation.code.coding level, observation.code.coding.code level and observation.code.coding.system element. In which element of the StructureDefinition should the uri of our valueset be set? Which elements should be left empty? What should the resulting profile look like?
If all of the options above are correct, what is the semantic difference between them?
Our valueset is based on Loinc. Should http://loinc.org/ be also set somehwere in the profile in the codeableConcept, or should it be only in the ValueSet at valueset.compose.import?
We haven't been able to try and test this, because we have some issues with HAPI dstu2 validation features and using other than the value sets supplied with the standard, but anyhow we should figure out the correct way to express the valueset.
The value sets are
https://simplifier.net/FinnishPHR/fiphr-vs-vitalsigns
https://simplifier.net/FinnishPHR/fiphr-vs-observationmethod
The profiles are
https://simplifier.net/FinnishPHR/fiphr-vitalsigns
https://simplifier.net/FinnishPHR/fiphr-bodyweight
Lloyd McKenzie (Feb 16 2017 at 14:43):
Generally you want it at the Observation.code level - that lets you say that "there must be one coding that matches this value set" - which is generally what's required. If you slice and go to the Observation.code.coding level, you could assert multiple bindings. I.e. Need one code from value set 1, one code from value set 2, one code from value set 3, etc. Binding to Observation.code.coding.code doesn't make sense as that won't control the code system. Binding Observation.code.coding.system would let you say "The code system must be one of these URLs" but that would be a weird way to constrain terminology.
Yunwei Wang (Feb 17 2017 at 00:13):
Agree. Observation.code is the correct place to do the binding
Eeva Turkka (Feb 17 2017 at 07:04):
Thank you for the answer, that's what we'd figured we'd want to do, but as there seemed to be so many options on how to do that we wanted to check that we have the profiles correct first and then check that our validation against the profiles and valuesets works properly. This clears the bindings up nicely!
Last updated: Apr 12 2022 at 19:14 UTC
