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
This is a very complex problem. There are a few basic approaches you could
tweak:
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.
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.
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
···
On Thu, Oct 13, 2011 at 12:24 PM, Ray B wrote:
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
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
···
On Thu, Oct 13, 2011 at 11:20 PM, Jonathan Jackson wrote:
Hi Ray -
This is a very complex problem. There are a few basic approaches you could
tweak:
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.
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.
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
On Thu, Oct 13, 2011 at 12:24 PM, Ray B ray@tula.org wrote:
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
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.
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
···
On Wed, Oct 19, 2011 at 7:10 PM, Ray B wrote:
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.
The CommCare/MoTeCH integration sounds great, and I look forward to hearing
more about it later.
Thanks for the feedback, Ray
···
On Wednesday, 19 October 2011 13:08:12 UTC-4, Jonathan Jackson wrote:
>
> 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
>
>
> On Wed, Oct 19, 2011 at 7:10 PM, Ray B wrote:
>
>> 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
>>
>
>