Stream: implementers
Topic: DataAbsentReason Vs NullFlavor
Ankita Srivastava (Feb 25 2022 at 13:36):
Hello All,
I am working on Encounter resource (US Core profile) from EMR data. However, there is no Encounter.type information available. As Encounter.type is mandatory, hence, in that case, what is recommended - use of null flavor (v3) or dataAbsentReason extension for the required element.
Kindly suggest.
Thanks
Ankita
Ankita Srivastava (Feb 25 2022 at 13:57):
Got the resolution, it is defined in US Core general guidance -> Missing Data section link
-> Use dataAbsentReason extension for non coded elements
-> Use dataAbsentReason codes for coded elements (except required binding)
Lloyd McKenzie (Feb 25 2022 at 14:57):
I would also submit a change request against US Core asking for the cardinality to be looser. In general, cardinality shouldn't be tighter than what systems can meet.
Josh Mandel (Feb 25 2022 at 15:20):
It's also an extensible binding; you could presumably just populate it with an CodeableConcept that has display text for what you do know, or even a coded value for "unknown". It's already a very loose requirement, and some code is better than nothing. What EMR has no information about encounter type?
Lloyd McKenzie (Feb 25 2022 at 15:34):
I'd reframe it as "Can you usefully do anything with an Encounter where the type is unknown?" - and the answer to that is definitively 'yes'. You could well know that there was an counter, when it was, even whether it was virtual or in person and not have a specific 'type' for it and still be able to do useful things with the record.
Lloyd McKenzie (Feb 25 2022 at 15:34):
Min=1 says "You must have this to satisfy our use-case." I don't see how that's true here.
Josh Mandel (Feb 25 2022 at 15:56):
That sounds like good framing for the core resource design (0.. cardinality) but doesn't sound like the right framing for national profiles. National profiles are intended to document conformance requirements for participating vendors.
Ankita Srivastava (Feb 25 2022 at 16:12):
Thank you @Lloyd McKenzie & @Josh Mandel for the valuable suggestion. I am facing this issue with historical encounters and already have details for the latest ones. Hence, as @Lloyd McKenzie suggested, we do have such use cases for historical data.
John Silva (Feb 25 2022 at 16:32):
(yeh, many times I play the 'trick' of only populating the display parameter of a required parameter, e.g. of a reference parameter -- though this is typically for test data not for real data; though this 'trick' can be useful.)
Yunwei Wang (Feb 25 2022 at 16:41):
US Core has a clear instruction
For coded data elements:
example, preferred, or extensible binding strengths (CodeableConcept datatypes):
if the source systems has text but no coded data, only the text element is used.
if there is neither text or coded data:
use the appropriate “unknown” concept code from the value set if available
if the value set does not have the appropriate “unknown” concept code, use unknown from the DataAbsentReason Code System.
Last updated: Apr 12 2022 at 19:14 UTC
