We are analysing the work involved in implementing Mobile Medical Unit / Satellite Clinic.
A patient can be created in parent server as well as in child server and synced across the servers. Servers can be offline and need not be connected to the parent server when a patient is created.
We would need some mechanism to ensure that the identifier created in a server is unique across all the servers.
We would like to hear some thoughts on how we should go about this.
Hi @preethi_s,
Good question - this is definitely something we have faced and dealt with in different ways thus far. A couple options that we’ve used:
Use identifier pools and/or remote identifier sources. In this model, you would designate a single server as the identifier source for a particular type of identifier for your entire network. This single source could be set up as a sequential identifier generator on the parent server. It could also be implemented entirely independently of OpenMRS or owned and operated by an independent entity (eg. an MoH service). One the child servers, you would create an identifier pool and then populate it with identifiers that have been generated from this master source. There is some functionality built into the idgen module to try to support refilling these pools automatically via a remote identifier source once the pool falls below some threshold, but obviously this would only work if there is some internet connection periodically that it can use. Functionality is also available to fill the pool with identifiers via a simple file upload.
Use a custom identifier validator to ensure identifiers are unique by decorating them appropriately with a value that is unique to the server. This is what is done by the patient registration module used in Rwanda. Each server is the network is configured with a location prefix (as a global property), and when the identifier is generated this prefix is appended to the beginning of the identifier. I think this might be a bit of a misuse of the Identifier Validator, but it works for them.
I’d be interested to do more brainstorming around alternative techniques that we might use to support this requirement in simpler and more reliable ways.
Cheers, Mike
In Bahmni Hub and Spoke… the idea is that Bahmni HUB is Parent Server and spokes / satellites are Child servers.
Scenario: A single person may go to Satellite Clinic 1, and then walk over next day to Clinic 2 (some distance away). Both Clinics might register the same person with IDs generated from their own location. In such a case, no one really knows this is the same patient. Once data from both Clinics reaches the HUB, both will have their own IDs. Later data for each location might also get synced separately to each location, so both locations will never really see the other entry. Only the Hub will see both the entries.
If Bahmni has in place a good mechanism to detect potential duplicates, then maybe the Hub can show these two entries as duplicates. It needs to be complimented with a good mechanism to “merge” patients, which Bahmni team is already working on.
Any thoughts/ideas?
My hope is that for starters (MVP) in Hub & Spoke architecture of Bahmni, we don’t do anything complex for ID management. We do something simple, and provide instead ways for graceful error handling and easy patient merging.
Even though patients may be registered at the spokes, we’re talking about a single patient population that is managed at the hub.
One approach is to have a single ID scheme, and these IDs can be assigned at any node. (This requires something like what Mike describes about using the idgen module so that each node can have pools of available identifiers to give out.) In this case, if the same patient has a duplicate record registered at a second facility, the records will need to be merged later, and one of the spokes needs to be told that the primary ID number for that patient record has changed.
Another approach is that each spoke assigns local IDs (e.g. each spoke uses a unique prefix) but when the patient records is pushed to the hub it gets a global ID assigned (which is also pushed back out to the spoke). Ideally you’d have a chance to merge records at this point, but this is a nice-to-have. The benefit here is that each spoke can file paper records under its own ID, and doesn’t have to refile paper charts based on patient merges that happen at the hub.
Which of these approaches is better depends on the deployment scenario, e.g. are the spokes fixed subcenters? are they mobile clinics that don’t have their own paper filing system? how often do patients move between spoke nodes and can you predict this ahead of time?
+1 to this. Basically the Hub & Spoke architecture should do simple and predictable things given the IDs that are generated/entered so that there’s nothing hub-and-spoke-specific about ID generation, and we support multiple approaches depending on the implementations.