@shashikanth could you give us a sense of what is left to be done, in the various components of the tech stack, to support both the recording of medications and diagnoses? We need to assess asap if it is worth getting into a sprint to nail this down, or find a workaround.
When we built Connect, we had more of CHW (community health workers) in mind. The CHWs are most of the time not qualified doctors, and they wouldn’t do a “provisional” diagnosis and in cases aren’t even allowed to.
Some cases they do something similar to diagnosis (provisional) - like - diarrhoea, common cold (Acute nasopharyngitis) etc. But it was decided that the CHWs wouldn’t be allowed to capture as “provisional diagnosis” anyway, and they will capture it as an observation.
So question for you, do you have Doctors doing the diagnosis, then I guess we can think of supporting diagnosis on Connect.
Btw, @mksrom, how did you even get the diagnosis tab appear on Connect? Maybe you copied the same config, actually you are supposed to have a different config for Connect, and place under the same server in a different directory.
Absolutely yes. And so coming back to my initial question, it is quite important (and pressing) for us to get a sense of the scope of work involved to enable recording medications and diagnoses.
Could you run us through what should be done? Layer by layer of the tech stack involved.
Yes that’s right. I did not provide custom config files for Connect in order to try out all the features and then remove only the ones that are not supported.
(btw in Bahmni Connect demo all tabs and Apps appear as well)
We had planned to try to keep the scope of Bahmni Connect somewhat limited (e.g. for community health workers, not doctors), largely because it already consumed a very large amount of resources to build and we hoped to invest future resources into the Hub and Spoke project instead. That doesn’t mean things need to stay this way, but I share it as a historical comment.
I’ve heard from some medical informatics folks that it’s not desirable to do e-prescribing (or order entry generally) in an offline application, because this means you’re placing orders against a stale view of the patient, and when you synchronize these at some future point they will trigger actions based on stale data with delayed upload (where even more data may have been captured). It’s “safe” to do this for observations, because you’re only observing, but this can actually cause patient harm in the case where the orders because these trigger direct real-world actions.
So, I would view entering diagnoses in connect as a mainly technical problem (which would cause some scope creep, but I could live with that), whereas entering medication prescriptions would require more discussion.
This would be an incredibly valuable piece of documentation, e.g. “step by step guide to adding another piece of data to Bahmni Connect”. Perhaps @shashikanth could provide the raw data for this, and @mksd/@mksrom can help put it into a wiki page in the developer’s guide?
As you (may) know we are only using Connect here as a workaround to hub & spoke. We are dealing with a mobile clinic and this means that the whole medication order and dispense happens right there. In fact the device will follow the patient through the mobile clinic, as simple as that. The person delivering the prescription will do so by reading the information provided by his/her colleague that was entered on the same device moments ago (that’s the workaround…) And yes, EMR-wise, there will then be a single provider.
I guess you understand better now why we are so keen on hub & spoke…
Yes, happy to document the development. We are having a call tomorrow morning CEST with @sumanmaity112 and @shashikanth to assess the scope of work and feasibility in the course of our project altogether. Keep in mind though that this might just not happen.
yes @angshuonline, offline-config is not being copied to bahmni_config folder with bahmni-connect installation, even though a separate offline folder available in default-config repo. This needs to be fixed. Created this JIRA card for the same.
@mksd Curious, what is the patient load in the mobile clinic where you are implementing this?
I am wondering if the device follows the patient (basically meaning single threaded process! ), wouldn’t this slow down the whole workflow. How will registration, consultation, and so on happen when the device is travelling to other persons?
At least in the mobile clinic (outreach clinic) that we had rolled out this wasn’t acceptable.
And so we had to contend with providing benefit to only one user (Registration) with the current single device solution. Was planning to provide doctors another read only device for seeing past data but haven’t done that yet as we have been facing intermittent issues with registration itself.
The hope was to have hub & spoke sooner than later which would be the ideal solution for setups like these, like you mention.
Had described the experience in this bahmni blog here.
@arjun the load was about 40 patients/day with 1 registrar and 2 doctors and 4 tablets, registrar must keep a list of which tablet each patient is on in case they return. Families are all entered on same tablet as they are seen by the same doctor. In periods when the registrar is waiting and has a free tablet, could enter several patients on it, as long as doctor is informed.
Unfortunately we are still facing challenges with Vitals and Diagnoses sync (we use a non-standard setup to enable Diagnosis entry), this is the issue: