Stream: conformance
Topic: coded elements
David Hay (Apr 03 2017 at 21:34):
If I wanted to indicate in a profile that a coded element should come from a given codesystem (eg Condition.code should come from SNOMED), I have a couple of options:
- I could create a new ValueSet and bind it to the element (but unless I made the binding 'required' they can always choose another)
- I could create a slice on Condition.code, discriminator = coding.system, adding a slice with snomed as the system. That way (at least) one of the codes must be SNOMED
correct?
Eric Haas (Apr 03 2017 at 22:11):
Also:
- create and extensible binding value set to given code system
- create a best practice invarient. like I did here
- the Slicing option is no better than a code binding. Went through this way back with USLab profiles.
David Hay (Apr 03 2017 at 23:00):
so 2 'preferred' options then:
- ValueSet binding
- Invariant
Lloyd McKenzie (Apr 03 2017 at 23:11):
Bindings are more visible and navigable than invariants, so I'd say that binding at the top level or binding to a slice would be preferred over an invariant
Michael Lawley (Apr 04 2017 at 23:16):
Also for binding, this ties in better with FHIR terminology services; ValueSet/$expand can take a context parameter that points at the profiled element which then identifies the valueset to use. Also, for a binding to "any" SNOMED code, you don't need to define a new one because there are already pre-defined implicit valuesets - eg http://snomed.info/sct?fhir_vs for "All of SNOMED"
Grahame Grieve (Apr 05 2017 at 23:32):
this works for invariants too, if the terminology server understands them
Last updated: Apr 12 2022 at 19:14 UTC
