Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

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

Projects

Page tree
Skip to end of metadata
Go to start of metadata
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

 

 

 

 

 

  • No labels

5 Comments

  1. Darius Jazayeri I'm good with Java but never worked with J2EE or JSPs before , but guess this will not be hard to brush up before coding starts with tutorials online. I don't know if I'll be a good fit to submit my proposal on this given I have no prior J2EE experience.

    1. Nyah Check, you will want to do the standard things discussed on the Google Summer of Code (GSOC) page.

      For this project, having past experience with J2EE isn't necessary, but demonstrating an ability to write OpenMRS code, and work with remote REST resources, is something we'd look at in the application.

  2. Darius Jazayeri:Hi I have already fixed 8 bugs on JIRA. I think I have a good understanding about the project. I would like to further discuss about the proposal with you. How can I contact you?

  3. OpenHIE expressed interest in this project and may be a good project champion or additional "customer" for this project... not to mention that they have experience in this area that could be very helpful to you.

    I don't see it stated explicitly in the objectives, but I assume that one of the objectives will be to make this functionality configurable – i.e., OpenMRS registration would not depend on an external MPI out of the box and would function independently as it does now by default, but this work would  allow it to be easily configured to work with an external MPI.

    1. Burke Mamlin, yes, the whole point is that this is optional functionality, and also that we'll have a mechanism to choose an MPI "connector" class, e.g. so we're not tightly coupled to OpenEMPI.