Stream: implementers
Topic: CS to code vs CodeableConcept
Vadim Peretokin (Jan 21 2017 at 12:29):
How do people tend to map CS? I have arguments running for both code and CodeableConcept running in my head
Lloyd McKenzie (Jan 21 2017 at 15:12):
Presume you're talking about extensions as how you map to core elements will be driven by what type the mapped-to element has in the resource. In the extension space we're a bit more tolerant of code than we are in core because extensions are often very narrow in purpose. If you're quite certain that the value set is going to be fixed forever and there's no value in people being able to communicate their local codes or needing to use different codes in different environments, then code can be fine. If you're not sure, stick with CodeableConcept. Typically elements that would be a CS in v3 will be a "code" in FHIR, but not always
Vadim Peretokin (Jan 23 2017 at 08:04):
Yep, sorry, indeed talking about extensions. Thanks for the input @Lloyd McKenzie !
Ewout Kramer (Jan 30 2017 at 15:11):
Another way to look at it: values in "codes" are often built into software as "case" or "if" statements because they trigger different behaviour, display etc. The same could be true for CodeableConcepts if the binding strength is "required".
Vadim Peretokin (Jan 30 2017 at 17:30):
Yeah definitely. I was just thinking about the improved readability for debugging of the resources vs increased payload size and things like that
Last updated: Apr 12 2022 at 19:14 UTC
