Stream: implementers
Topic: Multiple data types for same Observation.code
Paul Lynch (Jun 08 2021 at 16:47):
I am wondering if there any known problems with using the same Observation.code for both numeric (or quantity) and CodeableConcept values.
A group we are working with has data which, for the same code, will have values which are usually numeric, but sometimes will have things like "N/A". It might be theoretically possible (not sure) to map these values into dataAbsentReason, but given the amount of data they do not have the time to do that.
David Pyke (Jun 08 2021 at 16:50):
From what you've written, it sounds like you want to use Obs.code for the same things you used Obs.value. Can you clarify what situations would have a non LOINC(-ish) code for the type of observation?
Eric Haas (Jun 08 2021 at 17:05):
but sometimes will have things like "N/A". It might be theoretically possible (not sure) to map these values into dataAbsentReason, but given the amount of data they do not have the time to do that.
That was the intent of Observation.dataAbsentReason. Whether or not your system can filter results and map is a different matter. Nothing in FHIR prohibiting value[x] from changing datatypes, but I think it will shift the burden to the client side of things.
Paul Lynch (Jun 08 2021 at 17:43):
@David Pyke I am not sure what you're saying. As an example, for a given code that represents heart rate, one will usually have numeric values, but sometimes will have a string value, e.g. "Unable to measure".
@Eric Haas Yes, it does shift the burden to the client. I also don't know whether dataAbsentReason would semantically cover all such cases, though my guess it is that would cover most. My question here is whether having value[x] changing datatypes, as you put it, would cause other problems, but i am glad to hear you say FHIR is okay with it.
David Pyke (Jun 08 2021 at 17:52):
In the case you're describing, Obs.code will have the LOINC code for heart rate measurement and the result would be in Obs.value[x] which can hold many different types . Obs.code declares what the measurement is measuring. The actual measurement goes on Obs.value[x] which can have various datatypes values
Tilo Christ (Jun 08 2021 at 18:08):
Paul Lynch said:
Eric Haas Yes, it does shift the burden to the client. I also don't know whether dataAbsentReason would semantically cover all such cases, though my guess it is that would cover most. My question here is whether having value[x] changing datatypes, as you put it, would cause other problems, but i am glad to hear you say FHIR is okay with it.
I am wondering whether the "note" field might be the better place to put such human-readable, non-numerical info? dataAbsentReason does have a few subcategories for "unknown", but I guess one could simply always set it to the generic "unknown" code and put the reason into the "note" free-text.
I think pushing the spec to the limit with fancy handling of valueX might surprise clients and HL7v2 middle-boxes, and statistics packages, and ETL tools, and data scientists who years later want to curate the data, ...
Lloyd McKenzie (Jun 08 2021 at 19:28):
The base issue is that for a system converting data with no understanding, the result is that whatever's in the value element is going to get stuck in Observation.value - even if it might better live in dataAbsentReason, interpretation, comment or somewhere else. If you can migrate the value received to a more appropriate element, certainly that's better.
The only issue I can foresee would be if the Observation.code strongly indicated what data type the value should have and the values received don't always meet that expectation. In those cases, a recipient might complain (perhaps with justification). Certainly there's no rule that says that a single observation code must always have values of a single data type. ObservationDefinition.permittedDatatype is 0..*.
Last updated: Apr 12 2022 at 19:14 UTC
