Discuss mapping issues in harmonizing to FHIR from IEEE 11073-10207 and IEEE 11073-10207
Due to severe problems with the FreeConferenceCall.com conferencing service presumably due to coronavirus-related increases in usage, US participants Adilia Morales, Brian Reinhold, and John Rhoads were unable to hold connections for more than brief periods of time.
The participants who were able to participate fully were:
Stefan Karl (Philips)
Björn Andersen (Univ. Lübeck)
Stefan Schlichting (Ornet.org)
[Notes from Björn ]
Björn created an issue to have IEEE 11073-10207 included into the FHIR mapping to other standards list. The issue can be found in Jira and has been triaged but not assigned.
It may be a good idea to create similar tickets for -10201 and -20601 if so desired. We assume that once these will have been resolved, we can go to the workgroups responsible for the respective resources we want to map from (e.g. Patient) and ask them to include our informative mappings into their resource definitions.
We furthermore started discussing the mapping of the 10207
MeasurementValidity value set (see attachment, confidential). Kathrin and I made a proposal that can be found on the bottom of this page:
Whereas we all agree on the mappings to
dataAbsentReason and interpretation, the mapping to the resource security labels is still under discussion. On the pro side, this seems to be where FHIR people put similar information and the value sets seem to be an okay fit. Furthermore, it does not limit the usefulness of the resource as much as using a
modifierExtension would. On the con side, however, the original purpose of the security label has likely been something else more policy-related than validity modifiers. The only suitable alternative seems to be a
modifierExtension (with the limitations mentioned above) because (1) the
Observation.status has only a limited and quite useless
value set that is not fit for the purpose of expressing the validity and (2) the
Observation.interpretation represents a different dimension.
We agreed that this discussion should be continued next Monday if FCC allows.
Post-meeting note: see continuation of the discussion in 2020-03-23 DoF PoCD Subgroup meeting