OHF Bridge

OHF Bridge Alpha Release

An early preview of OHF Bridge's API has been released. This allows a PHP EMR application to search patients and retrieve documents from a healthcare repository.

Please view the API first to learn more about OHF Bridge:
API Documentation

Next, take a look at the sample PHP application that demonstrates the implementation of OHF Bridge:
Sample Application
(Alternatively, a command line version of the same application is here: Test.php)

A zip package that includes everything mentioned above can be downloaded here:
OHF Bridge Package

Please post any questions or concerns on the OHF newsgroup at:
news://news.eclipse.org/eclipse.technology.ohf

OHF in Action

A demonstration of OHF's capabilities are now being shown at the following link:

http://ibmod235.dal-ebis.ihost.com:8080/ohf/demo/index.php

The demonstration shows the full pipeline from a PDQ query, which returns matches based on the demographic information provided about a patient, to the retrieval of a document through XDS for a specific patient. To best demonstrate the functions that exist at the current time, please follow the instructions below.

===

1. Choose "Wisconsin" as the state of residence for the patient for whom you are searching
2. Click the "Search" button, and you should see a list of patients at the bottom of the page
3. You'll notice that one of the patients is named Joyce Murphy. Click on the "Search for Documents" link under her information
4. A list of documents that are linked to Joyce Murphy are displayed. Currently only Patient Generated Medical History can be retrieved and displayed. Click on any of the files that are labeled as Patient Generated Medical History.
5. Congratulations! You have queried for a patient using PDQ and retrieved a patient document through XDS

While the demo is still in its early stages, it does show that the capability to connect healthcare players from corporations to local hospitals is a reality and not just a dream. Currently there is both limited data and limited functionality. While these shortcomings are being ironed out, the principal of connectivity in healthcare is still being demonstrated.

The WSDL files off of which the web services are generated can be found at the following links:

• http://ibmod235.dal-ebis.ihost.com:8090/bridge/services/ohf-pdq-bridge?wsdl
• http://ibmod235.dal-ebis.ihost.com:8090/bridge/services/ohf-xds-bridge?wsdl

OHF Bridge CVS

The OHF Bridge Eclipse/OSGi projects are stored in the Eclipse Technology CVS repository. The projects are:

OHF Bridge Adapters (org.eclipse.ohf.bridge)

The OHF Bridge Adapters takes incoming requests from the web service, marshalls the request object to message query object and calls the Eclipse OHF plugin which will handle the repository access.

OHF Bridge Web Services (org.eclipse.ohf.bridge.ws)

The OHF Bridge Web Services reside in a SOAP Engine such as Apache Axis. They acquire SOAP envelopes from EMR applications and call a series of internal methods provided by the Adapters.

OHF Bridge PHP Client (org.eclipse.ohf.bridge.client)

The OHF Bridge PHP Client contains all the PHP source code of a sample application that implements the OHF Bridge API.

OHF Architecture

API Implementation Inside EMR Applications

OHF Bridge provides a simple API consisting of methods that allow an EMR application to search patients with demographic information, and then create, retrieve and save patient documents. The API is initially developed for the LAMP environment, and will be extended to other platforms such as Java and .NET. Once an EMR application accesses a method to request a call to the interoperability stack, the call is packaged into a SOAP envelope and then sent to the OHF Web Service.

OHF Bridge Web Services

The OHF Web Services resides inside the AXIS SOAP Engine, which has been ported to an OSGi bundle inside Tomcat. Once the Web Services acquires the SOAP envelope from the EMR application, it calls a series of internal methods provided by the Adapters. These internal methods are designed to cast the received call object to OHF objects recognizable by the PDQ, PIX, and XDS plug-ins. Once the casting is done, the OHF objects are passed onto the plug-ins.

Eclipse OHF Plug-ins

The OHF Plug-ins includes three distinct mechanisms (PDQ, PIX, and XDS), each consists of two components: the component that retrieves files (the consumer component) and another component that creates files (the source component). The PDQ plug-in handles the search of patient with demographic information including patient ID, full name, address, gender, date of birth, and contact information and returns a list of possible matches. Next, the PIX plug-in handle the cross-reference and comparison of patient metadata. Lastly, the XDS plug-in finds a list of documents for the matching patient and retrieves the full content of a selected document.

Interoperability Stack

The Interoperability Stack is a physical datacenter that hosts patient medical documents. It conforms fully to the HL7 international healthcare standard. It has two separate components: the registry that hosts the metadata for patient and document search, and the repository that stores the contents of medical documents. In the event of patient search, the search is done in the registry; a list of matching patient is then returned. In the event of document retrieval, the registry accesses the repository, pulls the document and returns it. If the EMR application requests a creation, change or deletion of a document, the repository will first take the appropriate action and update the document, and then it will request a change in the metadata within the registry. A security component lies on top of both the repository and the registry and performs the permission handling.