Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
OHF Bridge
Contents
Project Notice
The IHE Profile and Bridge implementations are currently transitioning from the Eclipse OHF Project to the Open Health Tools IHE Profiles Project. New support for 2008-2009 IHE Profiles, builds, documentation, etc. are coming soon and may be found on the OHT web site: http://iheprofiles.projects.openhealthtools.org/
Summary
The OHF Bridge is an OHF subproject which supplies SOAP access to the OHF plugins. The plugins that are directly invoked on the first release of the bridge are the OHF IHE Client plugins. These plugins calls other OHF plugins to get facilities for HL7 stack, security and auditing.
The OHF Bridge is based on the OSGi on Server project in order to load the OHF plugins into the server environment.
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:
OHF Bridge Documentation
Please post any questions or concerns on the OHF newsgroup at:
news://news.eclipse.org/eclipse.technology.ohf
Some overview
The OHF addresses part of a need to improve the levels of interoperability between applications and systems within and across healthcare organizations - corporate and regions. The project implements extensible frameworks, exemplary tools, and key health informatics standards wrapped as plugins. The project supports objectives of many government health departments to encourage the use of interoperable open source infrastructure to lower integration barriers. Independent Software Vendors (ISVs) may use the framework, components and tools created by this project to build desktop, gateways and server applications running on healthcare IT infrastructure.
OHF On the client
Many of the OHF components are implementations of Healthcare related standard protocols, data structures, encryption & security tools etc. The conventional way of using OHF is to create an Eclipse RCP application with user interface and workflow logic that use the OHF components.
The typical healthcare applications one would build with OHF components are Electronic Medical Record (EMR) or Patient Health Record (PHR). These products run at either a clinic or a patient’s home. Naturally, healthcare applications are deployed in many other environments, though in most of these environments client/server is the preferred architecture.
On the server side
The problem
Most OHF Plug-ins are designed to be used as components in a workflow typically executed by a healthcare application. We see two main problems with embedding them only in the traditional Eclipse RCP application model. The first problem is that as soon as the application targets more than one user, the market demands a client/server solution. Many healthcare applications deployed in clinics and hospitals have web interfaces to their back end to facilitate this need.
The second problem is that most existing healthcare applications run in a .NET, LAMP, or MUMPS environment. Very few of them use the Java environment and hardly any of them use the Eclipse RCP environment. We anticipate that it will take several years before Eclipse RCP applications appear in this domain. This situation poses a problem to the OHF community. We wish to be relevant to existing healthcare applications today regardless of their runtime environment. If OHF does not meet market demands soon enough then we will see similar projects duplicating the OHF efforts in other environments. The OHF goal is to create a community that provides implementations of the healthcare standards for interoperability built on a standard (Eclipse) framework. A multitude of non-standard projects for interoperability (even if open source) will not provide convergence around a common set of open standards. Moreover, as in most open source projects, if there is no community around a single common project, the individual projects (without any users) will slowly wither away.
Solution
Our solution is to use Server-Side Eclipse and Axis[10] to expose the functionalities of OHF components via web services. This is the OHF Bridge subproject of OHF. The OHF Bridge is an “OSGi on Server” runtime that embeds OHF Plug-ins and exposes a subset of their functionalities as web services. Using the OHF Bridge, applications residing in a SOAP-enabled environment (namely PHP and .NET solutions) may take advantage of OHF and its list of healthcare applications.
OHF on the Server Side overview
The OHF Bridge uses OSGi on Server and Axis to run the OHF Plug-ins within the Tomcat web container. The web container may be any container (e.g. Jetty), and it may be embedded in an application server (e.g. Geronimo). Inside the web container, the bridge runs the ‘OSGi on Server’ servlet. The OSGi environment contains the runtime plug-ins along with the OHF Plug-ins and the Axis engine. The Axis engine has a web service that accepts SOAP calls and translates them to the relevant API that the OHF Plug-ins exposes.
Using an adoption layer, the OHF Bridge simplifies transactions that may require several calls and translate workflows into one SOAP[11] call. Another role of the adoption layer is to translate the Eclipse Modeling Framework (EMF) models we use into simpler SOAP messages. The XML representation of the EMF modules that describes the healthcare standard document schemas are complex and not all environments can parse them easily. The intent is to enable even the simplest SOAP libraries (e.g. PHP SOAP) to work with the OHF data models.
Code Branches
An offical code branch for the IHE Plugins and OHF Bridge was made in April 2007. This branch (tagged OHF_IHE_2007_BRANCH) contains OHF code that was used successfuly in the 2007 North American Connectathon and 2007 European Union Connectathon. The API in this branch is frozen and only maintainance bug fixes will occur on the code. Details regarding the OHF_IHE_2007_BRANCH can be found on the following site:
The main trunk in CVS is the development branch. This code is being perpared and tested for the 2008 North American Connectathon. Details regarding the main trunk, as well as documentation regarding changes from previous branches can be found on the following site:
Beta 2 release notes
Code is available on the Eclipse CVS of both the bridge (java) and portal (php). Released on October 25 2006
For more information and to see what we are working on next see the OHF Bridge Documentation page.
OHF Bridge Web Services
Available at the same server. Go here to view the WSDL of the services. No API changed introduced in this version.
Known issues
- No Audit service available yet
- Can't update configuration in real time
- Not connected to the LDAP server for configurations (using only local file configuration mode)
- Replace document functionality not available
OHF Bridge lightweight portal
Available at the same place. It is using the new version of the bridge.
Known issues
- Do not have the replace document form yet
- Do not have the search document by codes/date yet (functionality available in the bridge) Thanks Matt for adding this functionality!
- The portal was tested with http://sfx-images.mozilla.org/affiliates/Buttons/firefox2/firefox-spread-btn-1b.png but should work with any browser
- If you see bugs, please | submit to the bugzilla.
Other issues
The bridge has three RHIOs configured.
- The two IBM RHIOs can't receive new documents since they are not compatible with the 2006 CPs. New version should be out soon, for now only the NIST servers support document upload.
- The NIST RHIO does not have a PIX server. To relieve a patient ID see Allocating new Patient IDs for Testing.
- You can't just use any facility name and other codes you wish, the Bridge takes care of the codes and names for you for the configured RHIOs. Codes and names are available here. If you wish, you can override the default names and code. If you wish to use the default, don't submit the facility name etc.
- For more info see the OHF FAQ page
OHF in Action
A demonstration of OHF's capabilities are now being shown at the following link:
http://healthcare.almaden.ibm.com/demo/
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.
- use test and test123 as username and password
- Choose the ibmod235-all RHIO
- Choose "Wisconsin" as the state of residence for the patient for whom you are searching
- Click the "Search" button, and you should see a list of patients at the bottom of the page
- You'll notice that one of the patients is named Joyce Murphy. Click on the "Search for Documents" link under her information
- 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.
- 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:
OHF Bridge in the CVS
For general instractions for the OHF CVS take a look at this page.
Eclipse/OSGi
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
Overall Architecture Design
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.
Bridge Install Steps
The bridge installation from scratch is a long process, but as soon as we'll have binaries on the web it will be much more simple. Slowly and surely we're adding scripts that can help with the process.
For a full description of the process please visit the Bridge Install Steps page.
Bridge PHP Sample Client
To demonstrate how easy it is to access the IHE world through OHF, we made a PHP web application that does that .The full source code of the application is located in the OHF CVS at org.eclipse.ohf.bridge.client
See the OHF Bridge PHP Sample Client page for instructions of how to install the web application.