Versions Compared

Old Version 2

changes.mady.by.user Darius Jazayeri

Saved on

compared with

New Version 3

changes.mady.by.user Darius Jazayeri

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Primary mentor

?~janflowers / ~jsibley

Backup mentor

Bill Lober

Assigned to

TBD

Background

ExcerptFor OpenMRS allows you to store and access patient-level medical data in a flexible and configurable way. But a true, large-scale electronic medical record requires multiple software applications, all interoperating together. A large hospital might use OpenMRS for the clinical patient record, and a separate Laboratory Information System to store detailed information about specimens and samples. Or a national-scale medical record might have OpenMRS running as a centralized database-of-record, with multiple mobile applications connecting to it.

What these situations have in common is that when systems interoperate, one typically behaves as a ?Master Patient Index, allowing others to query it to find patient records.
At the MEDINFO 2010 conference, we wanted to demonstrate demonstrated the potential for interoperability between OpenMRS and OpenELIS (an open-source laboratory information systemLaboratory Information System). We wanted to describe and show a scenario where OpenMRS would be providing the master patient index and OpenELIS would be able to access patient demographic information from the OpenMRS database to avoid the necessity for dual data entry of that information into both systems. As the framework for this interoperability, we decided to implement the standards developed by the Integrating the Healthcare Enterprise (IHE) initiative. Some development was completed, but only enough to create We successfully created a working demonstration of the concept., but more work is needed to make this interoperability link suitable for production use.Purpose

Excerpt

The purpose of this project is to complete the work started on developing the Patient Demographics Query (PDQ) Supplier module for OpenMRS. The PDQ Supplier module should be able to receive queries from external applications, parse those queries and perform searches against the patient tables in the database and finally, return demographic content for patients matching the search query criteria.

...

  • Strong Java development skills
  • Knowledge of HL/7 a plus

Objectives

...

  1. Fully parse and handle all types of query parameters (name, gender, address, wildcards, etc.).
  2. Use dynamic/configurable values instead of hard-coded ones for the required message segments.
  3. Handle the case of multiple patient matches.
  4. Consider using OpenMRS's current HL/7 receiver code/module for receiving the query messages instead of the current method (HTTP POST).

Extra Credit

  1. Handle PDQ continuation queries ("give me results 11-20", etc.).

...