Skip to end of metadata
Go to start of metadata

Statement of Current Issue

The Primary Health Care program is currently faced with influx of electronic patient registrations and corrections to the demographic details of existing patients. These revisions of demographic data and requests for patient registration constituted approximately 60% of all forms submitted by CHVs in Kosirai, an area that had been previously canvassed with paper form registrations in Household Encounter visits on more than one occasion.  

Proposed Pilot Project Assessing CHV Patient Registration on Phones

While AMPATH Informatics is currently in broader discussions regarding the best approach to patient matching across clinics and devices (see for example the Universal Identifier page, and the Unique Identifier Strategy drafted by lori siddall), we will implement a small patient matching pilot with the PHC CHV Android Phones within the highly limited context of the Saving Lives at Birth grant in Kosirai. We intend this to be a very low risk trial for AMPATH, where we will document all issues related to workflow, as well as the unexpected hurdles we may come across.  We hope that these practical, direct from the field stories may help inform future and more robust solutions that AMPATH IT may design and develop.  

In the meantime, we welcome all feedback, criticism, and suggestions for improvement!  Please leave a comment below, or email to share your thoughts!  I will also try to keep a running discussion on this page in order to document the feedback we receive from emails, the CHVs and the community below.

Initial Assumptions:

  • Registration needs to available at all times in all places (including CHV phones) and that ability to register someone must be designed for asynchronous communication (i.e. it is possible to register someone even when the internet is down)
  • Registration needs to be managed centrally, through a well-tested algorithm or through manual patient lookup by a trained data manager with access to AMRS. CHVs have neither the necessary connectivity nor the appropriate training to perform accurate patient matching.
  • There is no currently available software to provide an elegant solution to this problem of asynchronous patient matching between AMRS and Android phones at present. Many possibilities exist, but we will implement one as a trial in Kosirai.

Proposed Intervention:

Phase I:

  • Add a Temporary_Registration_UUID (free_text value) to AMRS Concept Dictionary as a temporary workaround to ensure patient resolution on the phones in immediate term

  • (Pilot Android software programming in Kosirai already complete)

Implementation of "Temporary_Registration_UUID" :

The most appropriate way to persist a Temporary_Registration_UUID in the database is with a new patient_identifier_type.  We will be working towards this as a solution

  1. A Temporary_Registration_UUID is not an attribute value because attributes are essentially static variables, and we need to build in the possibility that many different providers and many different devices could potentially register the same person prior to syncing their respective data with the central database. This may happen, for example, during a massive network outage, among multiple CHVs who cross-cover patients in areas with poor network connectivity, or among CHVs who cover migrant workers or other transitional populations.
  2. Temporary_Registration_UUID is not a patient_identifier, because there could potentially be many of these cropping up in the database, from each and every device.  If AMPATH wants CHVs to register patients, that could result in a lot of different identifier types!
  3. Temporary_Registration_UUID should be a concept and recorded in the obs table because it is really not an identifier at all, it is simply a value indicating that a certain CHV saw a certain person at a certain time…  just like an obs value. The Temporary_Registration_UUID is a throw-away, one-time-use value, which is far more similar to a single observation than a global identifier.  

How the Software Works:

  1. The phone attempts to register patient (in future versions, it could also potentially search AMRS first if there were connectivity), but defaults to a self-assigned Temporary_Registration_UUID.
  2. The phone software adds the patient to the database, even though the patient lacks an AMPATH ID.  The user may note that the patient does not have an ID, as the ID field is left blank.
  3. The data is sent to AMRS as xml (Xforms), but does not enter the database until it is reconciled: 
    1. At this stage, a Data Assistant or Data Manager searches the database and reconciles whether this is a new or existing patient.  If a new patient, they manually add the patient to AMRS. They then process the Mobile Patient Registration Form by adding the now existing Patient ID into the form.
    2. The Temporary_Registration_UUID is added as an obs text_value into the patient record
    3. In other words, there is no change to the current Data Assistant workflow, except that they read electronic forms instead of paper forms.
    4. In the future, and with a well-tested algorithm, this of course could be automated.
  4. On the next synchronization with the Android phone, the Temporary_Registration_UUID is sent back to the providers Android phone as an obs value associated with an existing patient. 
  5. The Android phone software reconciles the Temporary_Registration_UUID with its own database, and the two patients are merged.  I have already programmed and tested this on the phones we have already launched in Kosirai.  So far, so good.
  6. The Android phone provider now sees the patient that they registered (who once had a blank ID), is now associated with an AMPATH ID.  
  7. All subsequent forms filled for this person will now be submitted with the corresponding AMPATH ID.
  8. At the next visit, and if AMPATH would like to pursue this route, the CHV could then fill out a paper registration card (I guess it would have to not be laminated though!) with the proper AMRS ID number and registration info, since it will be coming from and identical to whatever is current in the AMRS database.
  9. The CHV has now reconciled their patient registration form with an existing patient in AMRS, the patient has a registration card, and the AMRS database has been properly updated and patients have been resolved by a trained Data Assistant working at AMPATH.

Initial Benefits:

  1. There is no change to anyone's workflow, except a Data Manager will now have to to read electronic forms as well as paper forms.  For the pilot, Saving Lives at Birth will absorb this small change in workflow by conducting the Data Entry within the context of our ongoing phone research in Kosirai.  We hope to document the hurdles and best practices that we find during this period.
  2. CHVs can register a person, continue to conduct follow-up observations with the person, and continue to submit forms to AMRS even prior to the patient being registered within AMRS, simply by using the same Temporary_Registration_UUID.  
  3. There is an incentive for Data Managers to register new patients quickly, as you would have to reconcile any additional forms (as submitted in 2 above) as well as the initial patient registration form if you wait.
  4. It does not require a change to the data model
  5. It does not require any change to any existing software on the server
  6. The software has been programmed on the phones in Kosirai
  7. Louis has already tested it, and it has worked in all tests on Test Server thus far.
  8. There is no cost to AMPATH (outside the time of adding a concept to the concept dictionary)
  9. The patient has an easy mechanism for obtaining a proper AMRS ID card within their community.  While the cards may not be laminated and may therefore have a shorter life span, it does mean that there is an individual who can easily replace any lost or damaged cards within the community at almost no cost to AMPATH.
  10. It can be implemented in the field as early as today!

AMPATH, CHV and Community Feedback

AMPATH Feedback

CHV Feedback

Community Feedback


  • No labels