Closed chrmey closed 3 years ago
I suggest to set the cardinality of value[x] in all VitalSigns to 0..1, given a DataAbsentReason is provided when value[x] is missing.
Agree, should be uniformly 0..1 on value[x].
Only problem is, value[x] is already 1..1 in the underlying MII definition here: https://www.medizininformatik-initiative.de/fhir/core/modul-labor/StructureDefinition/ObservationLab
If i get the FHIR Profiling Guide right, this cannot be overwritten, right? For use in a research environment this change would improve data quality and lead to an easier implementation. Right now if no value is provided, no resource would be send and noone would know, what happened with this data item.
If i get the FHIR Profiling Guide right, this cannot be overwritten, right?
Right, we can't just change it back because it's derived from MII. Will be fixed next release of the Lab module.
Short-term solution is to use the data-absent-reason extension on Observation.value[x]:valueQuantity.value
.
"valueQuantity": {
"_value": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
Thanks!
Looking at the items of the category "VitalSigns" this issue came up where the cardinality of value[x] differs in the various VitalSign-Profiles. For example in PaCO2, value[x] has the cardinality 1..1. In HeartRate the cardinality for value[x] is 0..1. Both profiles suggest to use DataAbsentReason if the value is unknown. However with a cardinality of 1..1, the value has to be provided each time, leading to validation errors when the value is omitted, even when a dataAbesentReason is provided.
Is this on purpose? I suggest to set the cardinality of value[x] in all VitalSigns to 0..1, given a DataAbsentReason is provided when value[x] is missing.