I wanted to demonstrate two working examples that I think highlight where some of the potential “traps” and compromises exist. Anyone who actively works with the system, or is clinically practicing, please scrutinize this!! Apologies in advance if some of these examples are nonsensical in terms of what functions each clinic performs, etc.. they are just meant to be examples. After our week in Kenya, I feel we understand the workflow constraints and requirements, but this is your opportunity to tell us where something won’t work. ☺

First, a couple facts about the new MRNs for those who’d like a reminder:

• They all have three components: a number, a location "suffix", and a check-digit, which is a calculated number that ensures substantial data integrity. IE, 1453TU-3
• All data for a given patient is entered by this number. If it’s incorrect, then the data won’t be useful to you later from both a clinical and a research perspective. For example, if a CBC was entered using the wrong medical record number, it won’t show up next visit on a clinical abstract, or it won’t be available when patient cohorts are selected based on a set of MRNs.
• If a patient has an old style MRN of any type other than what’s listed above, we’d like you to assign a new MRN as soon as we implement them at a given clinic. That should be used from here on out to insure integrity, consistency, etc.

Scenario 1: New patient to the AMRS..

John Doe is a new patient to Turbo Clinic. He gets a Turbo MRN on that first visit, and then after a year of three visits to Turbo, Ziwa clinic opens for patients. He’d prefer to attend that clinic, so he becomes a patient there. However, after two visits at that clinic, his family then moves back to the vicinity of Turbo clinic.

This example is just a simple example of how migrating patients can cause some interesting problems with the way we build and assign MRNs. There is a strong need to have site-specific MRNs, from a clinical workflow standpoint, so we’ve instituted the ability for a patient to have a single MRN for each clinic that he or she visits. We will build the infrastructure to help tie all of these MRNs to a single patient record, but most of the “glue” that will make this work is very dependent on manpower. For example, it is easy enough to assign John Doe a new MRN at Turbo, but what happens if he in fact has been seen in the past at MTRH? If he gets a new MRN, and the system is unaware that John has previous data in the system, that old data will be “orphaned” in the system. All subsequent data for John lives separately in the system. The same can be said for when he goes to Ziwa clinic. If there’s not a conscious effort to inform data entry that this unique person is getting another MRN “label”, then the patient’s record breaks, because it is up to a human to inform the AMRS of this relationship. To assist in this communication, we envision something very similar to this happening:

• The current encounter forms need a change. I’m referring to the forms that the data entry department ultimately uses to enter data from. At the top of the first page of this form, there needs to be a new section that allows the clinic to communicate information about a patient’s identifier to data entry. There would be a place for the MRN, of course, and then next to it, a flag to denote that it’s newly assigned. There needs to also be a yes or no that denotes whether the person has been seen within the system. This is important, because people at the point of care might not have access to anything more than this, but it’s crucial to let the data enterers know that at a minimum: “John has a high likelihood of having data in the system, and you need to scrutinize the database until you find him”. There also needs to be space for the clerks to list as much demographic information as they have access to. Needless to say, having the other MRNs listed there would be extremely helpful.
• When a patient checks in, one of the first questions a clerk should ask if there’s not a known MRN available for that clinic, is whether they’ve been seen in the IU system. They should always be extra diligent about this step, and fill out the new section of the form.
• The clinician should be a “checks and balances” to this process. If a patient is unfamiliar to you docs, and this section of the form is not filled out, ask questions, and ensure that the linkage, if it’s necessary, is clearly written!
• Once this form makes it to the data enterers, the top section should be the very first thing reviewed. No new MRNs should be entered into the system unless this check has been performed. If “New MRN” is not represented on the form, then don’t enter one. If there’s questions, seek resolution from the clinic or Erica. At least initially, we’d strongly suggest giving enterers levity with holding back on entry unless they’re absolutely sure that they have all the info they need to make an informed entry. This will give people like Erica an opportunity to closely watch the enterers.

Those principles in place, there is a robust ability to have multiple MRNs refer to a single patient record. Data can be entered under any of the assigned medical record numbers for that patient, and the system we build will be graceful enough to ensure that data corresponds to the right patient.

There needs to once again be special care to not assign multiple medical record numbers unless absolutely clinically necessary. Every new number is a new chance for error to be introduced into the system. Having dealt with the Regenstrief System, I can attest to the deep problems mistakenly assigned numbers can present. There are examples of it in the current Kenyan system, and we’re hopeful that a dedicated section on the form can prevent the miscommunication that is likely occurring.

Scenario 2: Previous patient to the older AMRS..

Jane Doe has been seen at Mosoriot, and has a MRN of 9999-4. She comes back to Mosoriot after the new MRNs are in place, so she gets a new number. She then becomes a patient at Burnt Forest once this clinic opens up. She remains there as a patient for the rest of her life.

The purpose of this scenario is to highlight what is done with old patients. As soon as it’s possible, that person should get a new number. In the case of Mosoriot, and hopefully of all clinics eventually (this is still in discussion), they will not only need a new MRN, but also a new number on their blue card. Whether this is done through a new sticker, or a new card altogether, this switch will need to take place. We haven’t thought through the logistics of this, but we think it’d be nice if the label printing program had a way to identify all the numbers a given patient might have. Does this seem possible to those knowledgeable of that piece of work? Once they move to Burnt Forest, they’ll need a new BF MRN as described above.