Approaches for generating patient identifiers

[Ray B]

I am hoping that others on this list can share information about how they are handling patient identifiers in a CommCare application.

Our current approach, not yet based on CommCare, involves having each CHW manually generating a 5 digits patient identifier.  The first two digits of the identifier is the year (ie. '11') and the last three digits are a monotonically increasing number between 0 and 999 that the CHW enters.  The CHW is responsible for tracking patient identifier information independent of the application (e.g. in their paper notebook).  I'm aware of other projects, like MoTeCH that pre-generate patient identifiers and provide CHWs with cards and stickers, along with some form of centralized patient identify management system.

Deficiencies with our current approach include:

• Our current set of patient identifiers are not unique across CHWs
• Our current set of patient identifiers are not associated with other identifiers that may be used elsewhere in the health system.  Note: most people do not have a public health card and, in cases where a card/number is used, it is not reliable
• Our current application does not detect and block common errors, such as duplicate patient identifier usage

While having a unique nationally available patient identifier would be ideal, this is not really feasible at this point.  So, I'm looking for an alternative solution supported by CCHQ.  Ideally, here is what I would like to see in the short term:

• I would like my CommCare application to automatically provide a patient identifier when needed, so manual/local generation is no longer required
• I would like generated patient identifiers to be unique across all of my CHWs
• I would like generated patient identifiers to be relatively short and easy to remember outside of the application

Any and all suggestions appreciated.

Thanks, Ray

[Jonathan Jackson]

Hi Ray - 

This is a very complex problem.  There are a few basic approaches you could tweak:

1.  Have CommCare generate a totally random number:  This (almost) guarantees non-collisions but will require a long alphanumeric string that will be prone to transcription errors in the future.

2.  Give each person / thing capable of creating an id a unique prefix, and make sure anything capable of generated an ID is kept in sync.  So, if you give each CHW a prefix 001-999, then you can monotonically increase the second part of the prefix and "guarantee" uniqueness as long as everything is monotonically increasing all the time.  You need to centrally assign 001-999 the prefix to avoid duplication, though.  And if anything breaks/resets in the second part, you will start assigning duplicate ids.

3.  Centrally distribute the entire number, so each CHW is given a stack of 100 IDs to use, they through them away after entering them into CommCare and can't register until they get more. You are counting on them to not duplicating use them.  You could resolve that they did server side, but if the patient is gone, you are still stuck.

on top of any of these, you could assign a check-digit to help with future transcription errors.

Cheers,
J

[Clayton Sims]

Ray,

Can you share a bit about the goal for using the identifiers outside of CommCare? Our experience is that without a strong external forcing function for identifiers it is very, very difficult to manage any scheme without error from the users.

Internally, CommCare assigns unique identifiers to all registered users, so any data collected with CommCare after selecting a case on the phone will be uniquely tied to a unique entity, regardless of any ID's entered by the user so that errors in ID # usage do not damage the data long-term. 

There is limited support on the phone for double-checking id numbers, so if you followed Jon's approach (2) you could in theory get IDs which would be hard to create duplicates for, but if the primary concern is data integrity from the phone, CommCare can support that even if the ids have collisions as long as the CHW's collect names or other information to differentiate or disambiguate the ids.

-Clayton

[Ray B]

Hi Clayton,

Re: "Can you share a bit about the goal for using the identifiers outside of CommCare?"

While we don't have an immediate need to use identifiers outside of CommCare, I have been thinking about two potential/future scenarios.

Scenario #1: Associating patient data submitted to CCHQ by CWHs with patient data maintained by the local health center or state/national EHR

In our case, the CHW is the most often the first point of contact with the patient and will register basic demographic and clinical data via CommCare.  However, the public health system also has mobile health teams that visit communities monthly.  The mobile health teams include a trained doctor and nurse who are likely to visit the same patient and gather very similar information.  While I have been thinking about ways to generate paper reports from CommCare that the health teams could carry with them on their month community visits, I would like to have a common/unique identifier in place to reliably associate clinical data.

In this scenario, a long term solution will require an external patient identifier management solution, owned and managed by the public health system, that provides the CHWs with access to reliable/unique/accessible patient identifiers.  I don't see a long term role for the CHWs or CommCare in this scenario.

However, until such a system in place, which is not going to happen anytime soon, it would at least be a good idea to make sure CommCare entered patient identifiers are unique across all communities --- to avoid potential confusion for health teams that are visiting many communities.

Scenario #2: Using the patient identifier as a key for pregnant women to access personalized educational content using a call-in system

In this case, I'm thinking about deploying a system like MoTeCH in the future that would enable pregnant women to call into a central/automated system to listen to personalized audio recordings.  The patient identifier would likely be the key value entered by the patient and would need to be shared across CommCare and this system.

By the way, I thought I heard something about a potential/future integration between CommCare and MoTeCH.  Am I right and, if so, any more info about this?

---

In the near term I suspect we will either stick with our current solution or move to #2 or #3 from Jonathan.  We may also consider going with something more like MoTeCH uses (ie. numbered health cards), although I want to keep things simple, and worry about things like privacy and change management if we try to introduce a physical health card.

No further feedback required at this point, unless you have insights into a future integration between CommCare and MoTeCH that could impact things.

Thanks, Ray

[Jonathan Jackson]

Hi Ray, 

CommCare and MoTeCH have a planned integration in India that will go live in q1/q2 of next year.  We'll have more information on that coming out shortly but its roughly CommCare's mobile handset + HQ as an integration point to MoTeCH + MoTeCH for SMS and IVR outreach to patients and CHWs.  It won't help your patient id use case at all though unless you want to do something like call/sms in to a central system to get a new id.  

-J

[Ray B]

Hi Jonathan,

The CommCare/MoTeCH integration sounds great, and I look forward to hearing more about it later.

Thanks for the feedback, Ray