Enterprise Master Patient Identification

OpenEMR Development
#1

Given that we are well on the way towards interoperability with other EHR systems we need to consider how we interact with patient information coming (and going) from (and to) these systems.

Currently PID is essentially just an auto-incrementing number. This has many obvious pitfalls and we should likely begin to consider more globally unique IDs (Call it UUID, GUID, or “system-that-gives-you-a-relatively-safe-alphanumeric”)

My suggestion is a standard V4 UUID PID that allows patient data to travel freely around the ecosystem. @sunsetsystems has pointed out providers often write down this ID as a reference and a UUID obviously would not work. The solution is to break out the pubpid to be more user friendly (while still being uinque). There’s plenty of ways we can do this and we could even likely create an interface that allows the end user to create a solution to fit their specific needs.

@sunsetsystems also pointed out another concern. We need a way to handle external patient identifiers. There was a suggestion on a related PR to do something like this:

CREATE TABLE patient_alias (pid, external_system_id, external_patient_id), 
PRIMARY KEY (pid, external_system_id, external_patient_id), 
KEY (external_system_id, external_patient_id) );

I find this solution simple and elegant is initially seems to really solve a big interoperability issue but we definitely need to have a conversation about it.

1 Like
#2

I certainly will give this closer thought. Especially since, I believe, the FHIR standard requires patient identifiers be alphanumeric.

#3

Currently there are at least 4 fields in the patient_data table that exist for the purpose of unique identification:

  • id is the primary key, an auto_increment integer. It's used very little if at all.
  • pid is the universally referenced internal identifier, also an integer.
  • pubpid is a character field whose value defaults to pid, but may be assigned by the clinic to something else. It's commonly used to match chart numbers from a prior system, paper or electronic, but can be used for other purposes.
  • ss is optional and uniqueness is not enforced. It's for a "national ID", or SSN in the U.S.

As Robert noted above, I suggested a cross-reference table to address the problem of coordinating with other systems or databases. In that way a patient can have an arbitrary number of alias identifiers regardless of whether they come from OpenEMR.

There will always be a need for a short locally unique identifier, if for no other reason than people like to write things down. Since we already have that with pid and it’s used virtually everywhere, might as well leave it alone.

My suggestions are:

  1. Get rid of id and substitute pid as the primary key.
  2. Implement a cross reference table. We might or might not go ahead and put pubpid and ss in there. Each entry would also indicate the source of the identifier, and the sources can some from a list in the list_options table.
  3. If a UUID is deemed useful, put it in the cross reference table as well.
1 Like
#4

I’ve been away from the codebase for a while taking care of school and a lot of admin tasks but I want to clean up some hanging issues. This is one we can get done. I’m gonna revive this thread to make sure everybody is on the same page.

I’m good with the alias table as it solves external data. I think we swap out the id field for the UUID V4, keeping the pid as it. @sjpadgett any recommendations for FHIR that’ll make things easier?

1 Like
#5

I agree we need to have a one stop for a patient UUID and is needed in FHIR and CCDA. If we are going to start pulling/moving from patient data I vote we start setting up true relational tables. On large data sets, queries are killing us and getting slower on every release. So while this would be nice, I would rather see us start taking performance more serious. Hope i’m not being preachy.:slight_smile:

#6

Reviving this topic again. At this point, we are on version 5.0.2(1) and UUID has not been implemented in the system. (Just a prolog preface statement of the obvious)

I have a project on the table that is requiring the implementation of UUID’s. I am going to use @sunsetsystems advice and create a patient_alias table. Like @robert.down said, its simple solution to the problem. @APerez

#7

hi @juggernautsei, uuid mechanism that could be used for people was brought in to 5.0.2 in this commit

#8

Noted and in the application that is a foot, we are tasked with tracking patients across multiple facility so the UUID must follow the patient from facility to facility.

#9

Hi Guys,
Couldn’t help but ask a question here. Are these facilities a part of the same practice? Too me, this would mean any lookup (say FHIR) by this uuid would have to also include a facility target. Also, is it common for a patient to be in more than one facility at a time? I suppose your applications intent would dictate how patient id is managed although, this would give me pause.

#10

@sjpadgett

The clinics are all separate locations around the island. The purpose it to be able to track a patient that may go to different facilities on the island. So, we are developing the UUID to store in a central hub. The UUID will be created at facility A after checking to see if the UUID exists at central and uploaded to central. If patient goes to facility B and is not on record as being a patient there, the idea is to generate the UUID, check central to see if that UUID exists. If it does, update central with the new facility the patient is being seen and still store that UUID locally. The UUID will be a hash of the patients identification information that will make the hash unique to that person.

For security reasons, I will not divulge the identification information that will be hashed.
We will be utilizing the installation unique identifier to manage records. Thanks for that being there!

#11

@juggernautsei ,

check out this issue here for some initial uuid thoughts:
Create patient uuid mechanism · Issue #2277 · openemr/openemr · GitHub

And then check out this PR for more concrete thoughts/code and big picture plans:
https://github.com/openemr/openemr/pull/2360

And then can see uuid done here to support a openemr instance uuid:
Add a unique id for the installation by bradymiller · Pull Request #2573 · openemr/openemr · GitHub

Couple things to note:

  1. Might as well just stick the uuid in the patient_data table (ie. no need for an alias table) since the end goal is for tables to be indexed by an uuid rather than an id (this would then allow offsite support).
  2. The standard for uuid version 4 (and the one we plan to use) is randomly generated, so no need to take a hash from patient id info to create it (in fact, then it wouldn’t be a uuid anymore :slight_smile: ).

-brady

#12

@brady.miller

Thanks for the feedback but not really the driver here. I am just the coder.
But the completely random generated code would be difficult to track patients from facility to facility within a network. If each time a patient was registered at a facility they have not been to before. The person would have multiple identifiers within the network. So, a randomly generated number would defeat the purpose. The UUID needs to be like a SS# or a drivers license# for the application we are building. I have coded the preliminary structure to save the UUID based on selected criteria. What I was thinking was in the globals, give an option on how the UUID would be generated. I took the table structure that was given and applied symfony-doctrine classes to save the data.

#13

hi @juggernautsei ,
To clarify from your post above:
“The UUID will be created at facility A after checking to see if the UUID exists at central and uploaded to central.”
If this is the case, then why can’t you create random UUID? (ie. you will create the random UUID, see if it exists at central and then upload it to central; then this will be that patient’s forever UUID with that organization)

#14

To follow up on my above post.
Sounds like maybe the group wishes to use a deterministic hash from a combination of unchangeable personal data elements so they can identify when the patient is at another facility (since the hash will be the same as long as the unchangeable elements are correct), which then makes it seem more reasonable. Then my argument may be what if the “unchangeable” elements do change, or there’s a typo in them, etc? Seems like it would be more robust to search the central server for those “unchangeable” elements directly to see if the patient’s already in central with a uuid. And then in that case might as well make the uuid randomly :slight_smile:

1 Like
#15

We went down that rabbit hole and know that there will be human error that cannot be programmed out. We are going to have to settle on an acceptable margin of error duplication within the system. There is no way around that.

#16

Hi Sherwin,
I have to agree with Brady here. Your UUID’s should be random and unique to the world. I’d leave any necessary uniqueness to current EMR instances (pid, facility etc) because however you look at it, the generated UUID will be an external identifier. This is true because you’re tracking patient across multiple resources, EMR in this case.
If I read this right, you’ll have a master repository to track patient throughout a practice group. Allowing a snapshot of whom is providing care within the group so in essence, the patient is a member of a group where the UUID should be unique to the group but shared across the group as an external identifier. Depending what type of history your master is going to track, facilities will still need to check in to master.

Seems to me trying to track a patient across multiple facilities where each facility patient reference has a different UUID is/could become a logistics problem over time.
In the FHIR/CCDA world for say, a transfer of care, that master UUID would most likely become the external identifier for the patient within the patients new home EMR or at least a reference for the transfer of care or referral even.

My view of UUID is that they are world facing and not useful to an EMR for anything more than external references. There are many cases where a UUID could be temporary for use in conical references depending on transaction say, a reference to a specific encounter. Anyway, that’s deviating from this thread.

I may have this wrong for intent but, my typing skills are improving :slight_smile:

1 Like
#17

Hi Jerry,
Hope your are healing well.
“Should be” is correct. And I do agree in the common thinking of UUID. It should be a totally random record identifier. Unfortunately we are not dealing with transfer of care. It is more the lines of tracking how patients can abuse the healthcare system by seeing multiple provides with the providers being unaware.
I was just told today the master record has been done away with in the project and the BI will just be gathering reports. We still need a standardized digital identifier for that patient (SDID). We concluded that the term UUID was not the right term for what we needed in this project. Which is different than a UUID. Just finished up the code to create this SDID. Still used the same table and added a few more columns.

#18

Where does this stand? I am using IBM FHIR server which for a create generates a FHIR ID for the patient. If I want to update an OpenEMR record or create a new one if the patient doesn’t exist, how would that be handled? Is it stored into patient_data_table? Thanks! @brady.miller

#19

hi @jgnoonan1961, there’s been quite a bit built, please see the readme