Non-unique values in Patient.identifier?

Is it ever appropriate to put a value in Patient.identifier which you know is probably not a unique identifier for that real person? For example, some payers (insurers) assign a single subscriber number to everyone in a nuclear family and then also assign separate unique member numbers to each of those people. Would it be right to put that same subscriber number (along with other identifiers) in Patient.identifier for each of the family members?

I know there are cases where multiple Patient resources will contain duplicate identifiers due to data entry errors or missing links. I’m just looking for general FHIR best practices guidance on how to handle identifiers which we know aren’t likely to be unique.

1 Like

Hey NIck, I posted a similar comment in Zulip here…https://chat.fhir.org/#narrow/stream/4-implementers/topic/Use.20of.20identifier

1 Like

I’d lean heavily towards making that identifier unique, whenever possible. Particularly shy away from using an Identifier you (your system) is/are not the authority for – like an insurance member id. Insurance Ids, like you mention, are problematic for lots of reasons but you point out a good one.

If you are the source system, you’d be using the unique identifier you have for that patient; with perhaps family members qualified with an extension on that identifier.

You also might want to think of a either generating a unique identifier (UUID/GUID, long or shortened, perhaps) that you could ‘correlate’ with your patient should you ever get that identifier sent back to you for re-identification. Or, generate (and store if possible) a hash on some element(s) you own that contains enough entropy to be unique ‘enough’ for your population. Bonus points if those elements are fairly static/immutable over time in your system and thus repeatable.

In short, make an effort to us a unique identifier for resources you are publishing. And finally: I hatez payer identifiers. Always trouble :wink:

Apologies for droning on.