Hi all (and apologies in advance for the long post)
I would like to brainstorm and get input about a new feature that we would love to add to Bahmni Connect.
Currently Bahmni Connect seems to be a ‘one device only’ offline tool, and I was wondering if we could not envision to get out of this limitation a little bit.
The new feature that I have in mind could be temporarily called ‘Quick registration and automerging’. I would be grateful if you could take the time to read below and share your thoughts.
####Background
We are implementing Bahmni at a clinic that does pretty much 100% of its work away from its headquarters, meaning that everything happens in an outreach care setup. Teams of 2/3/4 clinicians leave to operate for a few days at a remote location, and then come back.
Once out there, they setup an actual clinic with “departments”: registration desk, OPD, dental, … etc ; and each department runs Bahmni Connect on its own device (a tablet actually).
####Objective
We would like to aim at a situation where data collection can always happen, even when none of the devices can connect to the OpenMRS backend. Let’s look at a basic workflow.
The registration clerk proceeds to registering new patients, and in particular provides them with a pre-generated identifier - say POUM1001 for an example patient.
With no connectivity at all to the OpenMRS backend, there is no way for the OPD nurse to fetch patient POUM1001 moments after it has been registered, nor can she visualize the registration data and biometrics that have been recorded. We understand that limitation, however the worst part is that the OPD nurse cannot even encode any data for patient POUM1001. The only workaround would be to register the patient again under another identifier and for someone, later on, to identify these cases and merge them. That is a daunting task.
####Proposed idea
We would like to introduce this: let the OPD nurse do a ‘quick registration’ of an empty patient by just providing an identifier string, so POUM1001 here. At least this way she could continue collecting visit data for POUM1001 by attaching all visits/encounters/obs to this ‘quick patient’. And so could do any further care providers in other departments (so using yet other devices) that meet this patient, they would also ‘quick register’ patient POUM1001 and attach their data to it.
Eventually when all devices come back online, an automerge should take place based on a perfect match of all patients objects carrying the identifier POUM1001, hence consolidating all the data that was ever collected on various devices for that patient.
It certainly makes sense for the situation you have.
You realize that this solves the matching problem but you still would have to merge data from the different tablets, and there may still be overlapping or conflicting data that has to be resolved. For example, there could be two different entries for birthdate or address. Also, if it turns out that the patient already exists in the backbone, then you still need to do a patient matching algorithm there.
But as long as you recognize this, it sounds like it would make it much easier for several non-connected workers to work with the same patient. You may want to include at least the patient’s name in the quick registration (even though you may have to merge multiple make entries later) to make it easier to find the patient if someone loses track of the arbitrary registration number.
Thanks for your input.[quote=“jteich, post:2, topic:11552”]
there may still be overlapping or conflicting data that has to be resolved. For example, there could be two different entries for birthdate or address. Also, if it turns out that the patient already exists in the backbone, then you still need to do a patient matching algorithm there.
[/quote]
There would not be any collision regarding registration information (such as birthdate… etc) since the ‘quick registration’ would not allow to provide any of this. This quick registration would only enable to create a temporary empty shell patient to attach visits/encounters/obs to it in waiting for a subsequent merge into the actual patient when the connectivity resumes. By actual patient I mean the one that was properly registered through another device (or within vanilla Bahmni).
Of course a merging algorithm will be needed. It will happen that separate devices start an OPD visit for the same patient with conflicting start date/time for instance, in which case one should assume that the earliest date/time represents the actual start date/time of the OPD visit. Another case would be that, within that OPD visit, encounters of the same type may overlap coming from different devices… etc.
If the identifier string that was used for the empty shell patient matches a patient existing in the backend, then that is fine, the collected data should be attached to that existing patient. I would assume that this is the base case scenario.
However if the patient was never registered properly anywhere else, then there will be a pending patient (with no name, no birthdate… etc) awaiting proper registration.
Bahmni team was working on hub and spoke model which would have suited your use-case to the tee but unfortunately, the work on that piece is stopped.
Your model makes a case for itself, however, creating shell patients and later ensuring that the shell patient matches them with the correct (existing) patient will be a complicated task. Since we have to rely only on patient IDs and names (as we do not have any other patient data in the shell patient), we cannot afford any spelling mistakes and this poses a risk which is difficult to mitigate.
If I may suggest another work around, how about carrying a laptop to the outreach clinic which serves as the local server and set up a Wi-Fi LAN through which the tablets can connect to this laptop/server and you should be able to use Bahmni with all its features.
I wouldn’t want to even key in a name for the shell patients, just one identifier string. Those shell patients should really be special instances, only identified by a unique string (the identifier), solely existing to be merged into the real patient - the one that was created through an actual registration process, with Bahmni Connect or with Bahmni itself. They would never be saved on the backend side as such and for that reason may bypass the usual validators (such as the one requiring a patient to have a name).
Would you see any blocker with the above scenario?
This clinic will use Bahmni over the Cloud, and they send several teams at the same time in various villages to run those mobile clinics for a few days. There is no way that they could simultaneously run local Bahmni instances out of laptops… etc, all this would have to be merged altogether. I see your point if there was just one team, but that’s not the case.
The product team working on Connect thus far has been trying to limit the scope of what use cases it covers, because Hub and Spoke approach mentioned here is a better solution for some of these in the long run, and we don’t want to be supporting too many ways of doing the same thing.
But @mksd your limited use case is very interesting, and it does sound like a possibly-feasible way to add business value (a) without massive dev effort, and (b) without violating the principle that we can’t have p2p sync between offline devices.
Hopefully someone who has worked directly on the Connect codebase can give a quick estimate of the effort/feasibility of
a special “create shell patient” workflow that can only be enabled on Connect
it should sets a new person_attribute like shellPatient=true
this reminds me of the “register unknown patient” feature in the OpenMRS Reference Application
introducing an automatic merge step on the server side that finds corresponding the real patient records corresponding to shell patients and merges these
enhanced visit/encounter merging algorithm to handle the case where “separate devices start an OPD visit for the same patient with conflicting start date/time”
screen for viewing the status of these shell patient (e.g. how many are waiting around unmerged?)
documentation!
(Actually only the first and last bullet points require specific knowledge of Connect.)
@mksd does your team have some dev cycles to contribute to this?
Dimitri, I’m a bit confused about what information you will use for the later patient matching:
If you assign an arbitrary identifier such as POUM1001 to the patient in the field, and don’t capture name, birthdate or other typical matching information, then when you have full connectivity again, how will you know which (if any) patient in the main database is a match?
@jteich I think @mksd’s workflow is that the registration clerk gives the patient an id card, and they can’t be seen by a clinician until they have this card. So the assumption is that any patient who was seen by a clinician will surely have already been seen by the registration clerk and therefore you’ll never have a shell patient from the clinical tablet without a corresponding full patient record created on the registration table with the same ID.
But @mksd I think it’s unsafe to assume that this will happen with 100% consistency. I can guarantee that at some point a registration clerk or clinician mistypes an identifier, and at some point the registration tablet is lost or broken before it can sync.
If we’re going to make this a product feature then I’d push strongly for requiring the shell record to have a name. With a name + a visit date + location they’d at least have a shot at recovering the information. (Also, OpenMRS requires a gender for all patient records, so we’d need that too.)
Agree on the name + other attribute through which search can be done.
Some Context:
Connect: generates a temporary UUID, against which observation details can be captured. Patient gets allocated an Identifier when the system comes online and syncs with the server.
In one implementation: the client actually enters an identifier manually. They have this mechanism that in the central hospital they advance the Identifier sequence in the future (say starting from 500), while the subcenter uses from 100, 200, 300 etc (each having 100 identifiers). When they run out of identifiers at the subcenters, they again call up the server where they advance the sequence again! a very manual and troublesome way, but they seem to have gotten the hang of it!
Obviously, you can be little smart about the identifier (eg. Each centers having node IDs that can get appended as part of the identifier) and use that for merging.
I want to however raise the seriousness of auto-merging based on purely such identifier. Since this is purely driven by user entering identifier, we have to assume there will be mistakes! e.g 2 persons from 2 different centers entering same id, and hence chance of the observations getting tagged with another person altogether. The merge strategy needs be resolute enough (through configuration) that we can restrict when to merge (even if identifier matches) or not. Example, if done from connected hospital, the merge should not happen.
This also will require bit of work at Connect side, since connect does all association by patient UUID and not identifier. Discard the shell patient info when resolved, taking care of sync order (the data from the registration side must be synced first for the OPD data to be accepted), retry for the above cases etc.
So that needs to change, again based on configuration, since we do want to have the single user usage intact as it exists.
@mksd, I’ve added this to the “roadmap inbox” on the trello board here: Trello
Your feature proposal seems like a nice addition to the product, and the general approach seems workable. If your team is in a position to work on this, then let’s have a Bahmni Product Architecture Team call for some high-bandwidth discussion.
FYI the idgen module can be used to automate this workflow. If this ends up being a common scenario, hopefully some implementation project can build some idgen-based tooling around it.
I speculate it’s better usability and easier to code if we let the devices be synchronized in any order. So we’d allow shell patients to live in the main DB temporarily, and we’d handle this as a standard patient merge, though triggered by an automated job, rather than doing something connect-specific.
I speculate that if you’re never able to do the automatic merge, it’s better for a shell record to live forever in the main DB (marked as “temporary” in the UI) instead of having the data be stuck on a single tablet forever. But I’d want to test this assumption.
Yes @darius you are correct, teams get out with batches of blank patient cards, except for an identifier that is pre-printed on them. Those cards contain blank fields for the patient name that is filled upon registration, subsequent care providers would then rely on the pre-printed identifier string during the OPD visit.
Actually, this is yet another development that we would have to set in the pipeline (at least ours): the ability to pre-print batches of patient cards with guarantees that the same batch would never be printed twice. But this is another subject, let’s assume for now that this process is in place.
Developing the ‘shell patient & autosync’ feature will also mean developing a new Bahmni screen to manage problematic items that could not be synced for whatever reasons, with controls to take various actions.
Thanks for the Trello card.
We are not yet in a position to work on this. I wished for this thread to be a place to brainstorm on an initial idea and see if it was feasible given what Bahmni Connect currently design is. I am confident now that there is a technological way forward and I will start advocating for this item to be added to our list of activities in the context of a specific grant.
We are about to request a funding extension to develop the feature that has been discussed in this thread. Roughly:
(front-end) Ability to attach obs to ‘shell patients’.
(front-end) Ability to fast print a patient visit.
That’s to produce disposable pieces of paper that can be shared between care providers in offline mode. We would like to use thermal printers or equivalent.
(back-end) End points and routines to sync or queue shell patients data.
(front-end) Basic admin screen to manage queued shell patients data.
Feel free to add/comment. Also feel free to suggest any other route than this enhancement to Bahmni Connect. For instance @darius, I know that you went to this ODK event recently, have you heard of something that would fill the multiple devices offline gap and that could be proposed instead of the above?
The resources will be constrained, it goes without saying…
Looking forward to reading your thoughts about it.
Thank you!
@mksd I just verified that ODK (1 or 2) does not have support for peer-to-peer sync, so that’s not going to be a better alternative than just enhancing Bahmni Connect.
This seems like a perfect opportunity to (re)introduce Bahmni Product Architecture Team calls. Look for a separate post from me in the next 24 hours with a doodle poll.