Enterprise Master Patient Identification

infrastructure

#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.


#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.