Integrate Registration Module with a Master Patient Index

Primary mentorDarius Jazayeri
Backup mentorMike Seaton
GSoC studentRoman Zayats

 

Abstract

Often a single organization (a government, an NGO, or a hospital with satellite clinics) wants to run local OpenMRS installations at many individual facilities. But the organization wants to avoid creating duplicate patient records when the same patient population shows up at those different facilities.

The solution to this problem is to have an enterprise-wide master patient index which maintains a central registry of the unique patients that have attended any of the facilities, so that if any of those patients shows up at a new facility, their record may be imported and linked.

OpenMRS 2.x includes a Registration app that is used to create patient records when those patients arrive at the facility. The goal of this project is to extend the Registration app so that while the registration clerk is creating a new patient record, we can query a master patient index and see if that patient already exists.

There are multiple implementations of master patient indexes, both free and commercial, (for example OpenEMPI), and they use a variety of mechanisms to communicate, including standards such as PIX/PDQ, custom query formats, and maybe upcoming standards based on FHIR. We don't want to tie OpenMRS to a specific MPI solution, or even just one specific query standard. In this project we will introduce a general interface for querying a remote server, and implement an example that can query a specific MPI with a specific query standard.

Requirements

  • Good Java skills
  • Familiarity with OpenMRS technologies (demonstrated by contributions to OpenMRS issues)
  • Familiarity with working with RESTful web services, or with PIX/PDQ messages.

Project Champions

  • TBD

Objectives

Support for querying a remote server

  • Introduce an interface in the Registration Core module that represents the idea of querying a remote server for patients matching the demographics entered so far, and get back a list of potential results
  • Introduce a step in the UI of the Registration app to show these query results at the correct point of the workflow
  • Choose an existing MPI solution that we can build our queries against.
  • Implement our remote query interface to be able to query an existing MPI, either using a standard format (PIX/PDQ or FHIR) or else a proprietary query format.

Support for populating a remote server

  • Introduce an interface for sending newly-created patients to a remote server
  • Introduce an interface for sending data about edited patients to a remote server
  • Introduce an interface for sending data about merged patient records to a remote server
  • Implement these interfaces against our demonstration MPI solution

Extra credit

  • TBD

Resources