DataIntegrity Module


Image:Gsoc2009logo.gif

Contents

Overview

Any electronic medical record system is only as reliable as the integrity of its data. The quality of patient care and the validity of reports to funding organizations depend upon the accuracy of the system's patient data. Over time there is an increased possibility that data entry error, programming error, and database administration error will erode the integrity of patient data and affect the overall usefulness and dependability of the EMR.

The Data Integrity Module will be a generalized module that can be used by any OpenMRS implementation to perform various audits on the data module and reporting tools. The module has a customizable user interface that gives the auditor the ability to add/edit/delete items from a list of integrity checks. The auditor is able to select one or more or all tests to run and is able to view which tests have passed and which tests have failed - similar to what a developer might see when running a JUnit test. Tests that fail are linked to a page that will assist the auditor to resolve the data integrity failure. This page will also allow the auditor to rerun the test to see if the failures could be resolved.

Some of the integrity checks that are supported can be listed as follows:

  • Patients with no preferred identifier.
  • Patients with more than one preferred identifier.
  • Patients with no name.
  • Patient Identifiers with an incorrect check-digit.
  • Unused Concepts in the Concept Dictionary
  • Unused Field Objects for Forms.
  • Duplicate Field Objects for Forms.
  • Unused Locations
  • Encounters having no Observations.
  • Pregnant, male patients.
  • Patients who have a wrong encounter type (e.g.: A pediatric patient with an adult encounter type or form).

Requirements

The core requirement is an OpenMRS module which compiles and runs on existing OpenMRS implementations (1.4 and up). The main requirements of the module can be listed as follows.

Phase 1

  • Adding an admin page which lists actions that a user can take
  • Creating integrity checks for several cases:
    • Patients with no preferred identifier.
    • Patients with more than one preferred identifier.
    • Patients with no name.
    • Patient Identifiers with an incorrect check-digit.
    • Unused Concepts in the Concept Dictionary.
  • Adding a page which lists all integrity checks that can be run
  • Allow the user to customize the tests that needed to be run
  • Allow the user to fix errors which constitute to failed tests and re run the tests after the fixes are done

Phase 2

  • Extending the support for more integrity checks
    • Unused Field Objects for Forms.
    • Duplicate Field Objects for Forms.
    • Unused Locations
    • Encounters having no Observations.
    • Pregnant, male patients.
    • Patients who have a wrong encounter type
  • Implementing complex integrity tests
  • Adding a page which allows the user to run all tests at a stretch

Example Usage

Download

Resources

Project Documents

Blogs

Developers

Nimantha Baranasuriya