Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

Primary mentor

Cosmin Ioan

Backup mentor

Michael Seaton

Assigned to

Stephen Po-Chedley


Electronic medical records (EMR) systems are critical to evaluating and providing feedback to clinical programs, to monitoring the evolution and overall success of medical programs, and ensuring that patient data and operational reports are easily accessed. Thousands of programs use an open-source medical records system called OpenMRS throughout the world to help advance the quality of care provided. Like all electronic medical records systems, the ability to use OpenMRS is limited by the quality of data entered into the EMR. OpenMRS deployments have used a variety of external data checks to ensure that data from the EMR system is reliable relative to paper systems, but there has been no consistent tool and this data is not always retained in a systematic way.

This Google Summer of Code Project develops a Encounter Audit Module for OpenMRS that can be used both by the broader OpenMRS community. The basic module is meant to extract encounter information based on user-selected criteria (e.g. for a specific form, date range, etc.) and prompt the user to re-enter the information. Once the user enters the data, differences between the original record are highlighted and the user is prompted to confirm the differences and will have the option of providing notes about the inconsistencies.

Project Champions


Module Status

Encounter Audit Module is an open source module for OpenMRS that is meant to assess the quality of encounters entered into OpenMRS. The module relies on having a copy of the encounter that can be re-entered into the EMR. The module will then store the original record and the new audit record for comparison. This comparison is then used to determine the data quality of various encounters in OpenMRS.

This module is still be developed for release, but here is a summary of the current status.

  • Ability to sample encounters by parameters including creator, date range, encounter type, and location
  • Functionality to specify the number of encounters to audit
  • Saving projects by project name, description, and recording project parameters
  • Organization of audit encounters into a sortable table
  • Selecting an audit record brings up an htmlform specific to the type of encounter
  • Ability to re-enter the encounter (based off original paper record)
  • Built in comparison of existing encounter and the audit encounter
    • Differences highlighted and brought to the user's attention
    • User can view differences and either cancel the audit, update the audit or submit the audit
  • Capability to save and recall previously sampled encounters (from saved project information)
  • Capability to store the original encounter observations and the audited encounter observations
  • Ability to correct original observations/encounters based on audit information
  • Capability to classify differences (e.g. missing, value mismatch, not on paper, etc.)
  • Classifying and flagging audit project and encounter statuses
    • Ability to automatically sample based on project type (e.g. to select an appropriate random population for a given confidence interval or to produce a lot quality assurance assessment)
  • Capability to add/delete encounters from projects
  • Ability to generate projects based on project type
  • Basic reporting capabilities
    • Quality of data by user
    • Types of errors (e.g. user left record blank, user filled in data missing from paper record, user entered in a value with insufficient precision, paper record was difficult to read or changed, impossible to represent accurately in EMR, etc.)
    • Quality of data based on location
    • Quality of data for a user defined project, program, or encounter type
    • Quality of data based on observation
    • Statistical calculations for confidence intervals, sensitivity, LQAS, etc.


The module repository is stored at:


The module wiki is located at:





  • No labels


  1. Cosmin Ioan, I'd like to work on this project for the GSoC 2014. What is the convinient way that I could contact you to get more information about this project?


    1. Hi Madawa, thank you for your interest in this project. You could email me at or you could reach me on openmrs irc channel. My username is cioan. Thanks, Cosmin

      1. Thanks Cosmin. I'll do a background research about the project and reach you.

  2. Are there any resources from where I can know more about the project?

  3. Hi Cosmin - I'd be very interested in working on this project. Based on my experience much of the data quality review is done via paper or Excel or MySQL exports. These advanced features could be useful in a range of contexts.

    One example of this (though this was not in an EMR) was: Admon, A.J. (2013): "Assessing and improving data quality from community health workers: a successful intervention in Neno, Malawi," Public Health Action 3(1) 56 - 59. 

    1. Hi Stephen, thanks for your interest and for the paper reference. I would like to add it to the project resources. Do you know if we could get access to the full copy of this paper? 

      I have received similar feedback from other OpenMRS implementation sites in Rwanda and Haiti. 
  4. I want to work on this project. I will reach out to you after doing a research on the project.