Point of Care + Retrospective Entry - Advice, Experiences and Best Practices

html-form-entry
poc
Tags: #<Tag:0x00007f23d9823468> #<Tag:0x00007f23d9823288>

(Stephen Senkomago Musoke) #1

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

  1. How was the mapping of patient workflows done - registration, triage, service points?

  2. @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

  3. Workflow routing of patients through the clinic - what can be used to manage this?

  4. Queue management - how to manage the queues at the different service points?

  5. Notification - if lab results are ready for example, how is the doctor/reception notified?

  6. Role based access - how to restrict data to relevant areas and users: demographics to triage/reception, clinical data to doctors, counseling etc

  7. Custom dashboards - is the clinical facing dashboard sufficient, or do we need to have “service area” specific dashboards?

  8. @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?

  9. I would also like to hear on what not to do

cc @slubwama1 @jmpango


Propose a Design Forum Topic
Design Forum 2018-07-30: Ampath Form Builder technology and lesson learned
(Nicholas Ingosi) #2

Hi @ssmusoke

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.

Thanks


(Stephen Senkomago Musoke) #3

@ningosi We are totally looking forward, start here and we see how far down the rabbit hole we go…


(Mark Goodrich) #4

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:

  1. We also have need for patient workflows, but no solution designed for that yet.

  2. 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.)

  3. & 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…

  4. 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):

https://wiki.openmrs.org/display/docs/Context-Specific+Dashboards

That’s a bit of a brain dump from me for now. We are definitely interested in continuing this discussion.

Take care, Mark


(David DeSimone) #5

Stephen,

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.


(Darius Jazayeri) #6

Not sure there’s a quick answer to that question!

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:

image


(Stephen Senkomago Musoke) #8

Thank you all for the engagement, additional ideas and thoughts:

  1. @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?

  2. @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

  3. The patient queues - I am thinking that maybe the reporting module can be used to abstract the interface to build the queues

  4. 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.

  5. @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

  6. 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 …


(Mark Goodrich) #9

@ssmusoke

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.

Take care, Mark


(Valerio Joao) #10

@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.


(Stephen Senkomago Musoke) #11

@valvijo Tank you for the input

  1. what is the schema for the JSON being used to configure the apps?

  2. Forms:

  • How do you configure the different forms to be able to capture data?
  • What form builder technology are you using?
  • How are you approaching the form building
  • Is the POC for outpatient and inpatient? How do you manage encounters across POC and RDE?
  1. What would you do different if you had to start all over again? What pitfalls do u suggest we watch out for?

(Valerio Joao) #12

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.


(Stephen Senkomago Musoke) #13

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


(Jan Flowers) #14

I’m interested! Might have some crossover with the POC system that was built on the RefApp in Haiti.


(Ellen Ball) #15

Would love to join this conversation. We have a RefApp POC system in multiple locations and clinical programs in Haiti. Suggest some date/times.

Ellen Ball Partners In Health


(Cynthia Antwi) #16

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


(Mark Goodrich) #17

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.

Take care, Mark


(Stephen Senkomago Musoke) #18

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.


(Mark Goodrich) #19

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).

Take care, Mark


(Cynthia Antwi) #20

Hi Stephen

I can be available on the 25th


(Stephen Senkomago Musoke) #21

Unfortunately this discussion will have to wait until Cynthia can get an open slot - 25th is taken up by OpenMRS 3.0