UgandaEMR is looking to add a point of care module within our implementation which will be used side-by-side with the current retrospective data entry tools that have been built with HTML Form Entry. Architecturally we are “dogmatic”, in that the core functionality and workflows need to belong in OpenMRS & Reference Application modules - to guarantee long term sustainability of our implementation with as little custom code, and more configuration.
This is going to be a journey, so we would like to start and iterate through the process.
The purpose of this post is to ask for experience, pit falls, challenges, found with implementing POC within OpenMRS, and also what we need to do to have this successful, off the top of my head additional questions/areas of thought
How was the mapping of patient workflows done - registration, triage, service points?
@mogoodrich I remember you demoed how PIH uses multiple forms per encounter, is there any documentation on the approach that you can share? We still want to maintain the single large forms and have a bunch of smaller forms
Workflow routing of patients through the clinic - what can be used to manage this?
Queue management - how to manage the queues at the different service points?
Notification - if lab results are ready for example, how is the doctor/reception notified?
Role based access - how to restrict data to relevant areas and users: demographics to triage/reception, clinical data to doctors, counseling etc
Custom dashboards - is the clinical facing dashboard sufficient, or do we need to have “service area” specific dashboards?
@valvijo would love to get the eSaude experience on this, @ningosi KenyaEMR too, @darius do you see any quick wins in harvesting from the work done by Bahmni?
I will be honoured to share the experience both from eSaude and KenyaEMR, is this going to happen on a call or contributions will be on this thread. Allow me to tag @wanyee for experienced advice.
Lots of good points @ssmusoke… we have been using the PIH EMR, which is more or less the Ref App with several additional modules/features, at POC for around 5 years now with success.
We are currently at a bit of inflection point now as we figure out how to move forward. Long-term the idea would be to shift away from the UI Framework to more a client-side model with OWAs interacting with OpenMRS services RESTfully. However, we certainly aren’t going to immediately refactor everything we are doing, so hopefully we can get there incrementally.
To answer some of your specific questions:
We also have need for patient workflows, but no solution designed for that yet.
Multiple forms per encounter is generally implemented by our Visit Note functionality that we’ve build out in the PIH Core module (https://github.com/PIH/openmrs-module-pihcore/blob/master/omod/src/main/webapp/resources/scripts/visit/visit.js)… unfortunately this is not documented, and I don’t know if it will be documented since long-term we will probably be reworking this significantly. The general insight we had though was that you can break a large Html Form into multiple forms and as long as you open each of the small forms in the context of the same encounter you can have all those forms feed into the same encounter. (Tangentially, another question is what role with Html Forms play, if any, in a new OWA/RESTful model.)
& 4. Are things we are working on right now. There is interest in one of our sites on a mobile/tablet approach, so we are prototyping a progressive web app written in Ionic and Angular 2+ to handle this…
We have started to build out “program-specific” dashboards for our programs, though it’s a relatively new for us so I don’t know if have specific advice and to what works and doesn’t work in that context. For what it’s worth, we created functionality to allow context-specific dashboard and we did document that (thought note that is in the old UI Framework paradigm):
This is exciting and there will likely be lots of opportunities to collaborate with PIH on these efforts. Some additional thoughts to what @mogoodrich said…
At 2 small clinics in Haiti, we’ve implemented poc systems using patient queues at certain stations. We built queues based on the list of patients we expect at the vitals station and the consultation (with a doctor) station based on simple logic. e.g. patients who have checked in go on the vitals queue. After they have their vitals, they go on the consult queue.
Also at our hospital in Mirebalais, Haiti we have been using OpenMRS at poc for 5 years now. Instead of patient queues, the patients are identified with ID cards with barcodes that are scanned at each station. Though for the new systems we are building now (for clinics in Liberia and Malawi), we will probably go with patient lists and/or fingerprint identification instead of id cards.
We are proceeding towards having one “general” clinician-facing dashboard, with specific views for services (HIV, NCD etc…). @ball has posted a mockups of an HIV dashboard here and solicited feedback from the community.
As far as what NOT to do… I think we’ve learned not to simply replicate paper forms for electronic poc entry. It’s worth it to take the time to reduce the amount of data needed on each form to the minimum needed. It is better to add fields later on than to have the clinicians frustrated with the amount of time electronic entry takes. Also, smart UI design can help.
As you know, Bahmni was built from the beginning for POC usage, so I do recommend that you closely at how we’ve done things.
One specific thing I’d point out is that Bahmni built a different REST endpoint (in the emrapi module, so it’s in the refapp too), that allows you to post data and it intelligently decides whether to create a new encounter, or to append it to a new one (e.g. same provider, same location, same patient, within X minutes, it goes in the same encounter). I think having something like this is important for POC (though we really ought to add the idea of “encounter transactions” to openmrs-core to let this be done properly).
Bahmni has “queues” (which are not really queues, but configurable-by-SQL patient lists) which are a helpful way to cheaply implement “workflows”.
Basically you need to write some perhaps-very-complex SQL behind the scenes, but the application then configurably shows you which patients are at different stages of a workflow:
Thank you all for the engagement, additional ideas and thoughts:
@mogoodrich - role of HTML forms in a Restful world, an interesting one, maybe its time to talk about REST enabled form builders from Bhamni and AMPATH and bring them home into the fold. The question lies how to create/edit observations using probably HTML tags that can map to concepts etc @jdick?
@darius the emrapi properties REST interface what are the ideas to make it more intelligent, or pass it more information so that there are fewer false positives especially in a case of outpatient encounters where these are all expected to occur on the same day
The patient queues - I am thinking that maybe the reporting module can be used to abstract the interface to build the queues
Since in our case this would be built from the ground up - does a POC module seem to be the place to do this? providing the UI components and brining them together.
@ddesimone Oh yes not replicating the paper forms looks like a good place to start, an interesting challenge will be to ensure that the data can also be captured retrospectively so the two need to be in sync
Leads me to a new question - how to keep retrospective entry forms and Point of care data entry in sync/aligned as our health care systems are not yet ready to go paperless …
We definitely should think about alternative form entry technologies. One issue for use is that we have a heavy investment in Html Forms, so that will weigh into the discussion of using a new form entry technology vs bring Html Forms into the OWA world. (and it doesn’t necessarily need to be one or the other)
As for POC module, I don’t know if that’s the right level of extraction. Although some widgets can be optimized for POC, I don’t think there’s necessarily a clean distinct between widgets, etc used point of care and those used elsewhere. I would tend to think that reusable widgets would go into one module/package and then the UI can be broken up into packages by functional areas (Registration, Order Entry, etc). Hopefully by using the standardized widgets, this would standardize the look and feel across functions.
@ssmusoke in Mozambique we have designed the POC with very flexibility and little automation of patient workflow, and this is because patient workflows are not completely standardized across facilities, depending on the size, number of patients and number services. But there is the basic workflow automation to, for example, make sure that consultation proceeds registration and checkin, prescriptions prior to pharmacy and lab, etc. This is all defined in our custom UI application in angularjs.
In Mozambique the consultation is scheduled during encounters, for example the clinician tells the next consultation date and the pharmacist the next pickup date, and the system captures that information. We then created cohort queries using openmrs reporting module to produce patient queues.
Like in your case we also have to maintain both POC and RDE, and sync those two was challenging because RDE forms were designed based on paper forms so you can find the the same encounter the info for vitals, diagnosis, prescriptions, etc but we needed to break those in POC to comply with the workflow. That required to put in place a lot of configurability in our POC UI application see an example here, and I’m not sure how that can be accomplished in Reference Application but I’m happy to know the additions that are being done in Ref App toward POC as @mogoodrich mentioned.
We’re not describing config JSON files with JSON schema as those files are rarely modified from initial setup, but we have in our work plan to have it all documented.
The first version of RDE forms we used were built with infopath and then replaced by html form entry with the same old schema. To align between POC and RDE we have built POC forms based on existing infopath schemas and redefined the layout in POC configs (see here). This is still not the ideal solution as modifications in infopath form schema are not automatically reflected in corresponding html forms as they are in POC. We’re considering and analyzing other options like the angular library for openmrs formentry from AMPATH.
POC is currently for outpatient but in the future also inpatient will be supported as this is the MoH vision.
I’ll pass on the technical pitfalls to @yassin and @edrisse but a very important best practice I would recommend, and you’re probably aware of, is to engage the right people (specially end users) from the very begging of your POC design, as this is key for success.
Happy New year everyone, just wondering if there is anyone with interest in POC for the next 3-6 months, as the UgandaEMR team is ramping up the design and implementation for this and would love to share resources, thinking and approaches with other implementations.
Looking to have a design call in 2-3 weeks to share our thoughts and potential approaches
I am interested as well. We are in the process of establishing the Requirements, Design and Product architecture committees and your project would be a great start to test the groups and put them through their paces.
As always do let me know if you need any support from my end
I’m interested in being involved as well, particularly in any way we might leverage openmrs-react-components as part of this… as I’m learning more about React I’m developing an ever-increasing list of this in openmrs-react-components of things that could/should be refactored/improved.
Hello All, how is the Design call on Monday February 25, 2019? I see that it is currently unassigned, and would provide the right impetus for us to get started.
I will be travelling on the 25th and so unfortunately could not make that call. (However, feel free to go ahead and have the call if it works for others).
