Stream: implementers
Topic: data-absent-reason for unknown identifier system
Frank McKinney (Mar 11 2021 at 21:40):
This is probably a basic question...
I'm working on a scenario where we're populating a US Core Patient and would like to include a medical record number received in an related exchange. We can't ensure that we'll have a system for that MRN... and the US Core Patient requires identifier.system.
Is it kosher to use identifier.type to characterize the identifier as an MRN, and use a data-absent-reason in place of the system? Like...
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
"display": "Medical record number"
}
]
},
"_system": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
"value": "30455"
}
]
Thanks in advance
Lloyd McKenzie (Mar 11 2021 at 21:48):
I guess that's sort of what US Core pushes you into. You might submit a change request to them and suggest that they make system 'mustSupport' rather than mandatory. You can also use Identifier.text to convey more detail. E.g. "text":"Hospital XYZ MRN" (if you have at least that) so that a system can use that for human display.
Frank McKinney (Mar 11 2021 at 21:49):
Thanks Lloyd. I think we'll have something we could put into text... I hadn't thought of that
Michele Mottini (Mar 11 2021 at 22:59):
Just create a system
Michele Mottini (Mar 11 2021 at 23:00):
Based on what you know of that MRN
Lloyd McKenzie (Mar 11 2021 at 23:10):
If it's your MRN, sure. If it's someone else's, creating your own 'system' for it is problematic
Frank McKinney (Mar 12 2021 at 16:09):
It will be the situation that Lloyd mentions... the MRN will be owned by the sender of a previous message--in a data standard that doesn't include a system qualifier for the MRN value. It just comes across as "patient's MRN".
One thought we had was to use the data-absent-reason in the identifier.system element and also include another extension with a fixed value that indicates the element in the transaction it came from (the NCPDP new prescription message's Patient MRN field).
The goal is to enable those that implement the profile to use the value systematically with confidence that it's the one supplied in the earlier message.
What do you think of that idea?
Michele Mottini (Mar 12 2021 at 17:03):
We create our own systems - combining a root URL specific to our system + a segment specific to the origin
Vassil Peytchev (Mar 12 2021 at 17:34):
It will be the situation that Lloyd mentions... the MRN will be owned by the sender of a previous message--in a data standard that doesn't include a system qualifier for the MRN value. It just comes across as "patient's MRN".
One thought we had was to use the data-absent-reason in the identifier.system element and also include another extension with a fixed value that indicates the element in the transaction it came from (the NCPDP new prescription message's Patient MRN field).
If you resolve the provider from the NCPDP message to a known organization, you could indirectly determine the identifier system. I had no idea until now that NCPDP does not have a proper patient identifier structure in their specifications.
Frank McKinney (Mar 12 2021 at 19:14):
That's right... you can have a valid electronic prescription with just patient demographics and no patient identifier.
Frank McKinney (Mar 12 2021 at 19:20):
And the prescriber's practice location is also optional... so you might just receive their name and individual NPI. For most prescriptions in the US, there will also be a proprietary routing ID assigned by the prescribing network that represents the prescriber+practice+system, but that isn't guaranteed to be fixed over time.
Frank McKinney (Mar 12 2021 at 19:30):
The routing ID received in the prescription can be used to route a response through the network, though.
Last updated: Apr 12 2022 at 19:14 UTC
