Registering patients offline

Continuing the discussion from OpenMRS Mobile Interface:

Are you giving people a patient identifier while offline? Or is the patient identifier only generated when the data reach the central server?

Only when it reaches online. The UUID is null when offline.

But what about the patient identifier (the human readable one required for hospital references)? Do you assign it upfront or do you wait till the collected patient information is submitted to the server? If you wait how do you make sure the registered patient gets the identifier once assigned? If you do provide, how do you make sure the assigned identifier is not offered multiple times? Also how do you know the patient is not already in the system?

We do this:

Until network is available we do not allot identifiers, instead we just save the Patient data to the local database using a synced=false flag. As soon as network is available we create requests from the database, obtain identifiers and uuids and put them in the relevant DB columns, thereby making those patients synced with the server.

It sounds like you’re collecting all data related to an individual being registered offline in one unidentified payload and then performing the actual registration when the data reach the MPI (i.e., master patient index), which is the central server. If that’s true, are there any scenarios where data might be missing or additional data needed beyond the delivered payload (e.g., clarification of a demographic like address or name spelling, additional data needed to distinguish this new patient from a previously registered patient, or invalid values for demographics)?

When multiple payload may be generated offline – e.g., registration and data collection using separate forms or data collected over time before the patient has been registered – then a remotely generated internal identifier may be useful. This is, in fact, one of the primary benefits of UUIDs: when done properly they can be generated autonomously (offline) without the risk of duplicates. This would allow, for example, registration data to be collected and associated with a remotely generated person UUID. Additional data collected remotely before registration (medical record number assignment) is done can be linked through that person UUID. When registration does happen (preferably within 24 hours or less), the central server can either adopt the remotely generated person UUID (for a new person) or, if the person already exists centrally (i.e., a patient is registered offline and when the data are eventually sent online you discover the patient has previously been registered), associate the remotely generated person UUID (e.g., as a person attribute).

1 Like