Medical Record Number Specification v0.1

1. Rationale

In an ideal medical record system, there would be a single electronic “central authority” which distributes individual medical record numbers to any patient which comes in contact with its health care network. That way, all subsequent data for each patient would be stored under one identifying number. However, given the constraints that currently exist within our system (unstable electronic communications between each health care site, patients which potentially move between facilities, etc), we are forced to build an alternative which maintains uniqueness and is also mindful of our long term goal of making a workable single central authority.

To describe the state of affairs as we saw them in Kenya:

Each clinic functions autonomously when it comes to its data Each clinic has the ability to assign medical record numbers (ie, each clinic can potentially have its own central authority) There is a potential that patients will receive multiple medical record numbers if they forget their MRN or are misidentified by the clinic Patients will potentially move between clinical locations

Burke and I see the following as the two critical ingredients in building a robust patient identification process:

Within our medical record system (ie, across clinics), all medical record numbers should be unique to avoid two people receiving the exact same number. While we can afford for the inevitability of having two separate numbers represent one person, the converse is very problematic. All identifiers must have a check digit. This digit, which is derived from the medical record number, avoids a large majority of data entry errors.

II. Specification

Given these considerations, here’s how we plan to implement medical record numbers. To quickly illustrate, here’s an example:

999MS-7

We would like all of you to focus less on the particulars of this example (the fact that it’s only three digits, two characters, etc), and more upon the three major components:

The identifying number. This number is any integer between 1 and infinity. For ease of creation, these numbers will likely be sequentially assigned so that uniqueness can be maintained / tracked. The clinical location. This text code suffix is unique to the clinical location where the MRN is created. The purpose for this is simple. Seeing as how individual clinical locations are not currently setup to communicate electronically in real time, there is a potential for identifying numbers to be repeated within two or more clinical settings. If each clinical location assigns itself a single central authority which assigns medical record numbers, this location code further assures MRN uniqueness. We will take special care to avoid using letters which are potentially misconstrued as numbers (0 and O, 1 and I, etc.) A check digit. This final integer, which is separated by a dash, is calculated using a basic mod10 algorithm and is derived from the product of the identifying number and the clinical location code. This check digit is a way of preventing a large majority of typographical errors. When patient data is entered into the medical record, each MRN’s check digit will be compared to the recalculation of this value to ensure that there are no mistypes.

All future medical record numbers will be built using these criteria, and these components are ordered this way intentionally. By building MRNs in this order, we maintain the greatest flexibility for different use scenarios. For example, some clinicians and clinical settings prefer fixed-width identifying numbers to assist in making sure numbers are not missed (ie, 0000999MS-7 and 0999999MS-0 vs. 999MS-7 and 999999MS-0). Having the clinical location code as a suffix allows the check digit for 999MS-7 and 0000999MS-7 to be equivalent as the mod10 algorithm ignores leading zeroes.

III. Implementation

To implement this specification, Burke and I need a few things. We first need a list of clinical locations so that we can build unique clinic location codes for each. Then we need to assess the individual capabilities of each clinical location. We envision two probable use cases given the attributes of each clinical location:

Clinics with computerized central authorities. In this preferred scenario, each clinic will have a single location where all patients will check into the clinic and be assigned a unique number. In an even more ideal setting, once this number is assigned, the patient would be given some permanent record of this number to keep safe (ie, the blue card given to Mosoriot patients). This mechanism gives the clinic flexibility to assign new MRNs at their convenience, and is less manpower intensive. Some thought should be given to mechanisms of assigning new medical record numbers when power is lost or the computer is malfunctioning. Perhaps a certain series of numbers, assigned by the clinic electronic central authority, can be kept in escrow on paper? Clinics without a computer central authority. Given the conditions in Kenya, it’s quite likely that some clinical locations will be incapable of having computer support (lack of power, resources, etc.). In such a case, we can place humans in the place of this computer system. Someone in medical record maintenance (myself, Burke, Terry) would be tasked with creating a large list of unique medical record numbers which could then be given to a single person within each clinical location. This “human central authority” would have the responsibility of assigning numbers from this list to new patients. When the list is exhausted, a new batch of numbers will be given to the clinic. More time and resource intensive, and more prone to error, but certainly a workable solution. It is quite critical that a single person has the sole responsibility of this task within each clinic

Once we’ve 1) gotten the list of sites, 2) determined the best central authority mechanism for each site, and 3) assigned human central authorities where necessary, we will begin delivering either the electronic tools or actual lists of numbers so that you can get started. Eventually, we may retrospectively generate new MRNs for all of the patients that have already gotten checkdigit-less identifiers in order to transition to an all-checkdigit system. Also, we’ll eventually need tools to facilitate merging data for patients that inadvertently receive multiple MRNs.

We want to reiterate again, that the absolute worst mistake would be issuing the same MRN twice to two different people. MRNs can be skipped or left unused with little to no bother.. but two patients on the same MRN will be a royal mess. :-)