Skip to end of metadata
Go to start of metadata

Remote FormEntry is able to work through intermittent (e.g., once or twice weekly) USB key transfers because data only travel in one direction.  More specifically, patient data (demographics, encounter, observations) only flow from the AMPATH Centre to the remote sites (overwriting whatever is at the remote site) and encounter forms only flow from the remote site to the AMPATH Centre.  This works well while we await broadband internet connections between sites; however, there is a problem when remote sites need to change patient demographics (e.g., adding a new patient or adding an HCT ID to an existing patient).  Our solution is to store all known demographics into every encounter form (many of these data are not visible to the user filling out an encounter form).  Whenever the AMPATH Centre receives an encounter form via Remote FormEntry, it can see if any of the patient demographics have changed and even create a patient for initial encounter, because all of the needed information is passed in the encounter form data.

(warning) If demographics are changed/added AFTER the encounter form is opened, then they will not have a chance to make it into the encounter form and, therefore, will not be persisted because the encounter form is the only way data are transmitted to the AMPATH Centre.  To avoid this problem, it is absolutely critical that all data assistants understand that demographics (e.g., adding an HCT ID) must be done BEFORE opening the encounter form.

In general, Remote FormEntry should work like this:

  1. Remote data assistant finds or creates the patient in the web application
  2. Any new identifiers or other demographic changes are made in the web application
  3. The appropriate form is opened in InfoPath, encounter data entered, and submitted (submitted forms are held in a queue at the remote site)
  4. On the day that someone is traveling to the remote site, they pick up a USB key from Chris Simiyu at the AMPATH Centre with the latest copy of patient data for the remote site.
  5. The USB key arrives from the AMPATH Centre and data are transferred
    1. All encounter forms submitted since the last USB key visit are downloaded onto the key
    2. Patient data (demographics, encounter, observations) from the AMPATH Centre are used to update the remote site with the latest data from AMPATH.
  6. The USB key travels to the AMPATH Centre and remotely entered encounter forms are loaded into the central database
  7. The cycle continues

There are some side effects to having such a disconnected system with infrequent updates.  Without confusing folks with more detail, remote changes to patient data (demographics, identifiers, etc.) will not reliably be persisted remotely until two (2) USB exchanges occur.  That is, if you transfer data via USB once a week, changes made to patient demographics remotely should be reliably available within two weeks of entry.  For technical reasons, these remote changes may "disappear" from the remote system between the next USB exchange and the subsequent one.  So, if you want reliable patient data within one week of entry at a remote site, you need to perform USB exchanges twice a week.