Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • Ebola Treatment Unit EMR
Skip to end of metadata
Go to start of metadata

Background

ETU Scenario

Multiple groups (MoHs, NGOs, US and UK government, etc) are setting up Ebola Treatment Units (ETUs) in urban and rural areas of Ebola-affected countries. These health facilities are organized to quarantine infected patients during their treatment, and suspects while they are being evaluated. These ETUs generally feature multiple tents with beds, and zones divided by fences. Infected patients are in the "red zone", and any materials that enter that zone may not be brought out (to the "green zone"), and must be incinerated. Healthcare workers rounding on patients in the red zone are wearing Personal Protective Equipment (PPE) including triple gloves and goggles, and are only allowed to spend a limited amount of time in one round through the red zone.

Vision & OpenMRS Role

OpenMRS is ideally suited to be the foundation of an ETU EMR system, that captures and consolidates clinical data, and automates key ETU workflows. OpenMRS's existing functionalities, combined with its modular architecture, mean that we can quickly build a minimal system for initial deployment, and iteratively add more sophisticated features and workflows.

We don't know who will end up using OpenMRS to manage, but we know there is interest from many angles.

Our role as the OpenMRS Community is to channel community efforts to build an example ETU EMR system that (1) demonstrates best practices, and (2) produces useful building blocks. We do not have to build a complete comprehensive system, or design exact forms, in order to have a big impact.

Actual implementations might choose to take what we build and extend it, they may take specific building blocks, or just copy design patterns. All of these would be good outcomes of OpenMRS community effort.

Dev Approach

ETU EMR Distribution

Our example ETU EMR distribution should be based on the the just-released OpenMRS 2.1, plus new versions of a few modules. On top of that, we will add an "Ebola Example" module that provides metadata, specific functionality, and configuration.

Just Ebola (for now)

One of the benefits of using OpenMRS in an ETU is that it can be the foundation of a long-term general-purpose EMR even after the immediate Ebola emergency has subsided. However for now our focus is to package OpenMRS with just the necessary Ebola-related functionality, and nothing else. E.g. we might hide the standard Find Patient app and replace it with a custom one that directs to an Ebola Overview instead of the default patient dashboard.

Features and Requirements

At present, we can only make educated guesses at what an ETU EMR system needs to look like. Over time, by learning from on the ground partners, we'll have a better idea. But our initial guesses still provide us a good starting point. Further, we can already identify key gaps in OpenMRS 2.1 that we can preemptively address before they become blockers for actual implementations.

A guess at things we need to do:

  • Basic Ebola EMR
    • Register Patient in Ebola Program
    • Ebola Intake Form(s)
    • Ebola Clinical Followup Form(s) (e.g. when rounding on patients in the red zone, or under observation)
    • Ebola Outcome / Treatment Completion Forms
    • Ebola Patient Overview (interactive)
    • Ebola Clinical Summary (read-only)
  • Specific Forms
    • Volunteers can build specific forms based on the CIEL dictionary so that MoH or partners can just take these
  • Labs
    • Order Lab Tests
    • Enter Lab Results (from patient overview +/- in bulk)
    • Display Lab Results in Overview/Summary
  • Patient Flow
    • Admin Tool to manage sub-locations in the facility (e.g. Observation and Red Zone tents)
    • Record admissions, transfers, and discharges
    • Overview of ward assignments
  • Program Management and Evaluation
    • Summary Reports
    • Exports
  • Contacts
    • Basic listing of contacts
  • Missing core functionality
    • User Account management
    • Drug Order Entry UI (minimal)
  • "Red Zone Rounds" Workflow
    • Create work list of patients to round on (in regular application)
    • Custom tablet-optimized UI aimed at doctors wearing PPE:
      • Checklist of patients to see, organized by assigned location
      • Minimal clinical summary
      • Simplified data recording (e.g. question-per-screen with big friendly buttons)
  • Interoperability
    • Automated submission of data to DHIS2
    • Export lists of contacts to a mobile system for contact tracing.

 

 

  • No labels

4 Comments

  1. Thanks Darius very useful summary.

    Can you clarify what aspects of User Accounts management needs to be added to OpenMRS 2.1?

    Generating and using the unique patient ID will be important particularly in interacting with other systems in the lab, pharmacy and maybe mHealth based contact tracing applications etc. Ideally this would be linked to a bar coded patient bracelet.Prined bar code IDs may not be useful given infection risks but bar coded lab forms might be useful.

     

    1. OpenMRS 2.1 does not have User Account management. You have to go to the old UI to do it. (The problem with the old UI for this is that you have to do a tedious process of creating a User one place, and creating a Provider record somewhere else. We really want a unified experience to do these together.)

      The reference application automatically creates a unique "OpenMRS ID", and we could have manually-entered national IDs too. Would we want more than that?

      I think it's probably easier to continue this discussion at https://talk.openmrs.org/t/openmrs-ebola-treatment-unit-distribution/717 (since having conversations in wiki comment threads is annoying).

  2. Once these ideas are more solid, we need to great specific tickets and prioritize. There are several developers, including myself, that are ready to help but we need specific tasks to work on. We can also organize a hackathon around the tickets once we have them.

  3. Also, once we have tickets, I can try to engage the IUPUI developer community to see if they would like to help.