Ebola Treatment Unit EMR

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.