Stream: Orders and Observation WG
Topic: valueString vs valueCodeableConcept.text
Bob Milius (Aug 21 2018 at 16:45):
When is observation.valueString preferred over observation.valueCodeableConcept.text?
Seems like the latter can be used instead of the former. Can someone show me an example where the former is preferred?
from https://www.hl7.org/fhir/observation.html#valuex
When the data element is usually coded or the type associated with the code element defines a coded value, use valueCodeableConcept even if there is no appropriate code and only un-coded text is available. For example using text only, the valueCodeableConcept element would be:
"valueCodeableConcept": {
"text": "uncoded free text result"
}
Eric Haas (Aug 21 2018 at 18:26):
An example would Observation.code was a LOINC with property scale = narrative then only text is anticipated. Then valueString is appropriate. Certainly is technically appropriate to use observation.valueCodeableConcept.text but from an implementation stand point the simpler valueString may be preferred if only expecting text. @Rob Hausam ?
Bob Milius (Aug 21 2018 at 18:48):
Thanks! The guidance I quoted above says "when the data element is usually coded..."
When developing an IG, would it be appropriate to constrain the valueX to CodeableConcept even if the majority of the time only a string value is expected, to allow for local code systems for values? Or should both valueString and valueCodeableConcept be allowed? Seems there would be a benefit to constrain it to just one of these in an IG.
Eric Haas (Aug 21 2018 at 18:55):
I agree
Rob Hausam (Aug 21 2018 at 19:07):
I think that basically I agree. If the value may be coded, even if it isn't most of the time, I think CodeableConcept is appropriate. If the intent is that the value is always text (narrative) then you should use string. There is probably not a lot of reason (if any) to have a choice of valueString and valueCodeableConcept, although I don't think it would be wrong in any way to do that.
Last updated: Apr 12 2022 at 19:14 UTC
