prn:CIM-OnCall — Managing Clinical Demographic Data

It has been far longer than expected since the last post.  prn:CIM-OnCall has not languished–a few irons needed to be removed from the fire.  Posts should be more consistent going forward.

Recording a person’s name, birthdate, gender, and other common demographic elements should be an easy, no-brainer design issue.  In and of themselves, none of these data elements presents any complexity.    However, in clinical applications, these seemingly simple data elements can present significant data management challenges.  I have designed websites that allow registration and, aside from basic security issues and preventing duplicate usernames, few problems have arisen.  I wish that could be said for clinical applications.   There are two main issues with patient authentication: duplicate identifiers and authenticating patients to the wrong record.  Both are hard to prevent. 

While thinking about prn:CIM-OnCall classes, all the painful memories of managing demographics came rushing back.   I actually sat there, staring at the wall for a while, trying to figure out why managing clinical demographic data was so much more troublesome.   Then it hit me: For most software, the user identifies him/herself by presenting a standard set of credentials.   

For non-clinical applications—even financial systems— just a username/email address, password, and maybe a security question are required to authenticate a user.   Obviously, users know who they are.  However, for clinical applications, the situation is inverted.  A person (user) other than the patient has to authenticate the patient to the software.  So the issue at login/registration goes from: “Prove you are person X by providing information only person X should know.” to “How reliably does the information entered into the system identify the person who is presenting for services?”. 

When the patient is NOT the person performing the authentication, mistakes can occur in a number of ways.   Even in environments that have master patient index capability, patients may slip through the cracks—patients with multiple medical record numbers are not unusual.   I once came across a patient with eight—yes, eight— medical record numbers. 

One might think that social security numbers are the answer since each should be unique.  In theory, SSNs should work.  The problem is that everyone who shows up for treatment might not have an SSN (e.g., non-citizen) or be able to provide one (e.g., forgot, unconscious, mentally impaired).  Thus, having a requirement that no clinical care is delivered without an SSN is unworkable.  In addition, since many people do not carry SSN cards with them, they may simply give an incorrect number.   In any case, SSNs are not a panacea. 

Gender also can pose problems. Since gender can change, simply recording M or F can lead to clinical care mishaps.   Clinicians have to be aware of gender issues because they may impact care decisions.  For instance, a person who identifies as a woman, but was born male might still have a prostate gland.  Conversely, someone identifying as a man who has a family history of ovarian cancer might continue to be at risk.   Clinical applications need the ability to track patients across all possible clinical states.

Name confusion is another demographic pitfall.  John Smith Sr. John Smith, Jr. mix-ups happen easily.  Send both to a lab where the tech does not know there are two people with basically the same name, and confusion is possible.  In an emergency (or simply when distracted), hurriedly choosing the wrong name from a list of duplicates is an easy mistake.

Clinical apps must be able to prevent typical patient identification/authentication errors. Doing so requires multiple strategies.  Here are general principles I have found useful:

Names
–Use middle names.  If no middle name exists, make that explicit.
–Record nicknames as searchable fields and allow for more than one.

Gender
–Explicitly record birth gender and allow for gender change while retaining both.

Logs
–Keep demographic histories (i.e., track old addresses, phone numbers, etc.).
–Allow name histories. Enable tracking for every type of name changes (e.g., marriage, divorce, adoption), and link former names to current name.

Validation
–For every patient encounter, search for the complete name and validate the patient against birthdate, gender, all name components, and any other info available.
–Return all duplicate names with additional authentication fields (e.g., birthdate, gender, nicknames).

I wonder what role self-authentication (i.e., have the patient log-in to an EHR and confirm ID) might serve in reducing duplicate identifiers or authentication to the wrong record? Is there a role for mobile apps?  This question is beyond the scope of prn:CIM-OnCall because it is intended for use in small practices where patients are well-known to practice personnel.  But, in other settings, it might prevent misidentification.  Of course, fraud raises another entire set of issues.  Identity theft and attempts to obtain care using another’s credentials happen all the time.  In both instances, incorrect data will find its way into a record.

For Version 1.0 of prn:CIM-OnCall, my goal is to provide a robust set of validation routines and enough flexibility to assure that patients can be correctly identified over time.  Practically, that means including functionality that encompasses the principles listed above.    Both registration of a new patient and authentication of an existing patient are subject to many exceptions, and few absolute rules can be applied in every single case.  If you are creating a medical app after having developed in another domain—be careful.  Clinical demographic data management is much harder than it looks.

Facebooktwittergoogle_plusredditpinterestlinkedinmail