Stream: implementers
Topic: Use of identifier
Jim Indelicato (May 10 2018 at 15:47):
Hi all. I am brand new to FHIR and have what I hope is a simple question or two. To provide some scope I am modeling and creating an entirely new database using the FHIR spec. So I am essentially trying to persist this spec. We will be getting data in HL7 format and at some point will also get and send data in FHIR format. So the group felt FHIR was good since it is flexible and should make it easier for future data feeds.
I know that 1 patient resource can have many identifiers (SSN, MRN, etc). Each will tie back to that 1 patient resource. Can the same patient be in the patient resource more than once? If so then I guess the identifier could tie back to more than 1 patient resource right?
My other question is that since an observation can be related to a patient, it looks like observation.subject is how to relate back to the patient. That seems clear to me. But what about also using observation.identifer? In other words does it make sense to include MRN as an identifier within observation resource even though it isn't unique to the specific observation? Or would this MRN identifier only be in the patient.identifer
Any feedback is greatly appreciated!
Jose Costa Teixeira (May 10 2018 at 16:07):
I know that 1 patient resource can have many identifiers (SSN, MRN, etc). Each will tie back to that 1 patient resource. Can the same patient be in the patient resource more than once? If so then I guess the identifier could tie back to more than 1 patient resource right?
I don't understand the question: Can the same patient be in the same patient resource? What are you trying to achieve. (Or perhaps it is a typo?)
Jose Costa Teixeira (May 10 2018 at 16:09):
My other question is that since an observation can be related to a patient, it looks like observation.subject is how to relate back to the patient. That seems clear to me. But what about also using observation.identifer? In other words does it make sense to include MRN as an identifier within observation resource even though it isn't unique to the specific observation? Or would this MRN identifier only be in the patient.identifer
A resource Identifier identifies that specific resource. An observatin Identifier is an identifier for an observation. So if you are asking "can we put the patient identifier as an identifier for the observation" i don't see how that would work.
Lloyd McKenzie (May 10 2018 at 16:21):
The same identifier can appear on the same Patient in a few cases:
- data entry error (wrong identifier on wrong patient, accidental duplicate patient)
- deliberate duplication (separate records for different departments, separate records for 'legacy' patients vs. current patients)
- deliberate use of the same identifier by multiple patients (e.g. sharing of social security numbers in the US)
Lloyd McKenzie (May 10 2018 at 16:22):
It can happen for practitioners too - different practitioner records for different hospitals or multi-licensed practitioners. FHIR doesn't require that, but it may come about due to data sources and/or business decisions
Jim Indelicato (May 10 2018 at 16:31):
In regards to 1 patient being in the patient resource more than once...lets say that data for patient Jim I is sent on 5/10. This data is stored in my FHIR like tables. Then on 5/11 data is sent for the same Jim I patient. I am trying to understand if it makes sense to create a new patient record and use Patient.link to replace old record or just update the old record?
Jose Costa Teixeira (May 10 2018 at 16:34):
if by "patient data" you mean "information about the patient" (and not any procedures or observations), then from the FHIR perspective these are two different versions of the same resource
Michel Rutten (May 10 2018 at 16:47):
Hi @Jim Indelicato, Typically, an application would only be required to send a patient resource to a server in order to create a new patient resource or to mutate an existing patient resource. However when the intent is to exchange e.g. clinical information about a certain patient, the application would send resources that refer to an existing patient resource, by means of a resource reference. The application might retrieve an existing patient resource (selected by the user), but there would be no need to the patient resource itself back to the server.
Jim Indelicato (May 10 2018 at 16:53):
Thanks @Jose Costa Teixeira Yes I mean information/attributes at the patient level (not observation, etc). So I think I am following. Since it is a different version of the same resource then I definitely shouldn't create a new resource and use patient.link. I should instead version that patient resource
Lloyd McKenzie (May 10 2018 at 17:07):
Versioning in FHIR is handled with "update"
Jim Indelicato (May 10 2018 at 17:10):
My other question is that since an observation can be related to a patient, it looks like observation.subject is how to relate back to the patient. That seems clear to me. But what about also using observation.identifer? In other words does it make sense to include MRN as an identifier within observation resource even though it isn't unique to the specific observation? Or would this MRN identifier only be in the patient.identifer
A resource Identifier identifies that specific resource. An observatin Identifier is an identifier for an observation. So if you are asking "can we put the patient identifier as an identifier for the observation" i don't see how that would work.
Let me ask my question like this...if I was to receive observation data in FHIR format and they included MRN, would I see MRN in observation.identifier or extension?
You guys are great! I am glad I joined
Jean Duteau (May 10 2018 at 17:15):
You shouldn't see MRN in the Observation.identifier because it isn't an identifier for the observation. It would be an identifier of the patient so should be found on the Patient resource that the Observation references. If you needed to include it on the Observation resource, then it would have to go in an extension.
Jim Indelicato (May 10 2018 at 17:40):
In my case there is no 1 col/attribute that uniquely defines an observation (in the HL7 observation feed). But the combination of MRN and observationDateTime would uniquely identify an observation. That is why I am wondering it both MRN and observationDateTime would belong in observation.identifier or if both would still belong in an extension.
Eric Haas (May 10 2018 at 17:48):
your Identifier would be MRN+datetime
Jose Costa Teixeira (May 10 2018 at 17:50):
do you actually need an identifier for the observation?
Jose Costa Teixeira (May 10 2018 at 17:51):
the _id could be sufficient.
Jim Indelicato (May 10 2018 at 18:02):
In the HL7 feed I am not receiving the FHIR _id. I need a way to determine if the observation already exists in my database. If I make the identifier MRN+datetime does that mean it would need to be concatenated into a single identifer
Jose Costa Teixeira (May 10 2018 at 18:49):
the id is always there for a fhir resource
Thomas Gutteridge (May 11 2018 at 00:02):
If a resource has an "identifier" element, is the system/value pair supposed to be unique across all resources of that type. Or is it possible that two resources could be considered equivalent according to one system (but not another)?
David Hay (May 11 2018 at 05:56):
well, almost always :) . - not in a 'create' operation...http://hl7.org/fhir/resource.html#id
Lloyd McKenzie (May 11 2018 at 12:49):
I think Thomas is talking about .identifier, not .id.
Lloyd McKenzie (May 11 2018 at 12:49):
The answer for .identifier is "it depends" :)
Lloyd McKenzie (May 11 2018 at 12:52):
Servers are certainly free to enforce that certain identifier types are unique, but there are all sorts of reasons why they wouldn't be. Examples include multiple versions of value sets, code systems and other resources with a ".version" element; multiple records for the same individual/device due to business practice (or data entry error); Deliberate re-use of identifiers; Cycling through an identifier namespace again after a period of time has passed (not good practice and there should be a distinct validity period for the identifier, but good practice isn't always followed)
Thomas Gutteridge (May 15 2018 at 01:07):
Thanks Lloyd. That helps. I think what I was thinking of doing woudl have been effectively using multiple .identifiers to store custom attributes of resources. And I think that probably would have been an abuse of the elements.
Lloyd McKenzie (May 15 2018 at 11:14):
For custom attributes, you're much better off with extensions
Eric Haas (May 15 2018 at 16:17):
back to the notion that identifiers should/must be unique. FHIR does not prohibited that an identifier can repeat within an environment, but where does an identifier start becoming a grouper - a way of connecting resources. The use case I have in mind is a member Id for insurance.
Me and my kids are all have the same member ID 1234. To me this seems is a legitimate identifier, its just not unique to me and a shortcut for instead of supporting Coverage with a proper reference to the patient.
Does the spec say more about handling business identifiers if there is no guarantee they are not unique (e.g. when referencing them by a business identifier) ?
Lloyd McKenzie (May 15 2018 at 18:40):
There is no expectation of a general guarantee of uniqueness. Systems can choose to enforce specific identifiers they feel should be unique in their particular context.
Eric Haas (May 15 2018 at 18:46):
what happens if Observation.subject uses Reference.identifier and points to three Patients? Is that documented?
Lloyd McKenzie (May 15 2018 at 18:50):
Systems could choose to treat that as an error - assuming they even tried to resolve
Jim Indelicato (May 16 2018 at 22:45):
If I am understanding correctly, in the example member id for insurance...the member id of the main holder would be stored in the identifier for the main holder since it uniquely identifies him/her. But it sounds like their member id should not be in the kids identifier attribute. Instead the most appropriate place would be in the extension. Am i correct?
Eric Haas (May 16 2018 at 22:47):
what extension? I think we are saying you could have 3 patients with the same identfier of type member id. Is up to the system
Michael Donnelly (May 21 2018 at 18:59):
Is there a reason not to have a separate resource to represent the coverage and either have the Patient resources point at it or it points at them?
Cooper Thompson (Oct 03 2018 at 18:39):
@Lloyd McKenzie @Eric Haas regarding the comments on this topic back in May. You seem to indicate that identifiers do not need to be unique within the context of a specific system. However the current spec for the identifier data type says that they should be. Was there an update to the spec between May and now that required value to be unique within a system?
Cooper Thompson (Oct 03 2018 at 18:40):
And if so, I'm kinda stuck on how to handle stuff like SSN, where the value very likely will not be unique due to data entry errors.
Cooper Thompson (Oct 03 2018 at 18:55):
And if it isn't unique, then how does that work with the Reference data type. I normally think of a property with a type of Reference as something that will resolve to a single record. And if identifiers aren't unique per system, then a reference property could resolve to multiple records.
Michel Rutten (Oct 03 2018 at 19:42):
FHIR rules about canonical urls require Reference.reference to resolve uniquely.
However for Reference.identifier to resolve uniquely, the implementer has to make sure the system does not assign/contain duplicate business identifiers.
Grahame Grieve (Oct 03 2018 at 20:11):
You seem to indicate that identifiers do not need to be unique within the context of a specific system. However the current spec for the identifier data type says that they should be
should be unique = do not need to be
Lloyd McKenzie (Oct 03 2018 at 20:25):
Identifiers should be unique. But there are various business reasons why they won't be - duplicate records, resource granularity is different than identifier granularity, errors, fraud, multiple versions with different resource instances
Vassil Peytchev (Oct 03 2018 at 22:38):
The value SHALL be unique within the defined system and have a consistent meaning wherever it appears.
Pasted from the link below....
Vassil Peytchev (Oct 03 2018 at 22:39):
http://build.fhir.org/datatypes.html#Identifier
Lloyd McKenzie (Oct 04 2018 at 01:46):
Right. But that doesn't mean that it'll be unique in the server. Only that it uniquely corresponds to a particular concept. For example, US Social Security Number might still be associated with multiple Patient records.
Jenni Syed (Oct 04 2018 at 19:46):
And the US SSN also re-assigns the SSN to different people, so the system may be an accurate representation of reality
Jenni Syed (Oct 04 2018 at 19:47):
it's that "SHALL" I think that is tripping us up (vs. should with no qualifiers about real world issues)
Grahame Grieve (Oct 04 2018 at 20:21):
it's subtle but important:
- value SHALL be unique in the system
- it SHOULD only be associated with one thing
Karl M. Davis (Oct 04 2018 at 20:33):
Isn't that a contradiction, though, Grahame? What does "unique within the system" actually mean if the second point means that it's cool for the same identifier to appear on more than one resource in a server?
Michel Rutten (Oct 04 2018 at 20:34):
Frankly, I'm confused too...
Grahame Grieve (Oct 04 2018 at 20:41):
I do not think it's a contradiction
Grahame Grieve (Oct 04 2018 at 20:43):
if you have a system, then the value SHALL be unique. That is, the issuer(s) of values within the systems must not ever issue the same value to identify to different things
Grahame Grieve (Oct 04 2018 at 20:46):
e.g: if there's a system issuing driver's license numbers, it should never issue the same number more than once (to identify different people)
Jenni Syed (Oct 04 2018 at 20:49):
So, the US SSN doesn't follow that rule
Jenni Syed (Oct 04 2018 at 20:49):
Or so I've been told... :)
Grahame Grieve (Oct 04 2018 at 20:49):
but when systems associate driver's license numbers with patient records, there's a few valid reasons why a single driver's license might actually end up correctly associated with more than one patient record
Grahame Grieve (Oct 04 2018 at 20:51):
the principle reason for this is the workflow between primary issuers of an identifier and secondary users
Michel Rutten (Oct 04 2018 at 20:51):
@Jenni Syed https://www.ssa.gov/history/hfaq.html
Q20: Are Social Security numbers reused after a person dies?
A: No. [...]
Jenni Syed (Oct 04 2018 at 20:52):
Michel Rutten (Oct 04 2018 at 20:52):
Interesting...
Jenni Syed (Oct 04 2018 at 20:52):
yeah :)
Grahame Grieve (Oct 04 2018 at 20:52):
as for US SSN: I believe, from previous investigation of this, that it is in fact true that a few SSNs have been reused, and so, if we are to be pedantic, SSN is not a proper identifier. However I believe that these are considered an administrative mistake
Cooper Thompson (Oct 04 2018 at 20:57):
Grahame's comment above about primary vs. secondary users is a good one. For example for MRNs, they would almost definitely be unique per system (ignoring active vs. historical in unmerge scenarios) when you are talking to the issuing system. But if you are talking to a partner organization across the street that receives the MRNs via paper requisitions and has staff manually enter them, you might have duplicates. So different systems may have different uniqueness confidence for the same identifier system.
Grahame Grieve (Oct 04 2018 at 21:42):
in V3, we introduced an actual attribute for this. No one ever used it, but it does exist as an extension in FHIR if anyone really wants it
Ivan Dubrov (Oct 05 2018 at 18:30):
Which attribute are you talking about?
Grahame Grieve (Oct 05 2018 at 21:05):
II.reliability
Last updated: Apr 12 2022 at 19:14 UTC
