Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OHF Bridge"

(Bridge Install Steps)
 
(46 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== OHF Bridge Alpha Release ==
+
[[OHF|Back to the OHF Wiki]]
 +
==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/ 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 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 [http://www.eclipse.org/equinox/incubator/server/ OSGi on Server] project in order to load the OHF plugins into teh server environment.
+
The OHF Bridge is based on the [http://www.eclipse.org/equinox/incubator/server/ OSGi on Server] project in order to load the OHF plugins into the server environment.
 
+
<br/>
+
 
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.
 
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.
<br/>
+
Please view the API first to learn more about OHF Bridge: <br/>[[OHF Bridge Documentation]]
Please view the API first to learn more about OHF Bridge: <br/>[[Media:OHF_Bridge.pdf | OHF Bridge Documentation]]
+
  
Next, take a look at the sample PHP application that demonstrates the implementation of OHF Bridge:<br/>[http://ibmod235.dal-ebis.ihost.com:8080/ohf/release/sample_app/ Sample Application]<br/>
 
(Alternatively, a command line version of the same application is here: [http://ibmod235.dal-ebis.ihost.com:8080/ohf/release/test.phps Test.php])<br/><br/>
 
A zip package that includes everything mentioned above can be downloaded here: <br/>
 
[http://ibmod235.dal-ebis.ihost.com:8080/ohf/release/ OHF Bridge Package]
 
<br/><br/>
 
 
Please post any questions or concerns on the [news://news.eclipse.org/eclipse.technology.ohf OHF newsgroup] at: <br/>
 
Please post any questions or concerns on the [news://news.eclipse.org/eclipse.technology.ohf OHF newsgroup] at: <br/>
 
news://news.eclipse.org/eclipse.technology.ohf
 
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.
 +
 +
[[Image:EMR on RCP.jpg]]
 +
 +
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.
 +
 +
[[Image:bridge architecture.jpg]]
 +
 +
===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.
 +
 +
[[Image:bridge core2.jpg]]
 +
 +
== 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:
 +
* [[OHF IHE 2007 BRANCH | '''OHF IHE 2007 BRANCH''']]
 +
 +
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:
 +
* [[OHF IHE MAIN BRANCH | '''OHF IHE MAIN BRANCH''']]
 +
 +
=== 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 [http://healthcare.almaden.ibm.com:8080/bridge/services/ohf-bridge?wsdl 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 [http://healthcare.almaden.ibm.com/demo/ 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 Bugs to OHF || 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 [[IHE Connectathon 2007#Allocating new Patient IDs for Testing | 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. [http://lswin10.dfw.ibm.com:9080/IBMIHII/serverInfoIHE_ConnectathonHIMSS2007.htm 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 ==
 
== OHF in Action ==
 
A demonstration of [[OHF]]'s capabilities are now being shown at the following link:
 
A demonstration of [[OHF]]'s capabilities are now being shown at the following link:
 
<br/><br/>  
 
<br/><br/>  
[http://ibmod235.dal-ebis.ihost.com:8080/ohf/demo/index.php http://ibmod235.dal-ebis.ihost.com:8080/ohf/demo/index.php]
+
[http://healthcare.almaden.ibm.com/demo/ http://healthcare.almaden.ibm.com/demo/]
<br/><br/>
+
<br/>
 
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.
 
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.
 
<ol>
 
<ol>
 +
<li>use test and test123 as username and password</li>
 +
<li>Choose the ibmod235-all RHIO</li>
 
<li>Choose "Wisconsin" as the state of residence for the patient for whom you are searching</li>
 
<li>Choose "Wisconsin" as the state of residence for the patient for whom you are searching</li>
 
<li>Click the "Search" button, and you should see a list of patients at the bottom of the page</li>
 
<li>Click the "Search" button, and you should see a list of patients at the bottom of the page</li>
Line 34: Line 101:
 
The WSDL files off of which the web services are generated can be found at the following links:
 
The WSDL files off of which the web services are generated can be found at the following links:
 
<ul>
 
<ul>
<li>[http://ibmod235.dal-ebis.ihost.com:8090/bridge/services/ohf-pdq-bridge?wsdl http://ibmod235.dal-ebis.ihost.com:8090/bridge/services/ohf-pdq-bridge?wsdl]</li>
+
<li>[http://healthcare.almaden.ibm.com:8080/bridge/services/ohf-bridge?wsdl http://healthcare.almaden.ibm.com:8080/bridge/services/ohf-bridge?wsdl]</li>
<li>[http://ibmod235.dal-ebis.ihost.com:8090/bridge/services/ohf-xds-bridge?wsdl http://ibmod235.dal-ebis.ihost.com:8090/bridge/services/ohf-xds-bridge?wsdl]</li>
+
 
</ul>
 
</ul>
  
Line 72: Line 138:
  
 
== Bridge Install Steps ==
 
== 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.
  
===Pieces to obtain===
+
For a full description of the process please visit the '''[[Bridge Install Steps]] page'''.
*Eclipse 3.2
+
*Java 5
+
*Tomcat 5.5.17
+
*Eclipse Equinox OSGi-on-Server deployable WAR (bridge.war)
+
 
+
===Tomcat Setup===
+
# Install Tomcat from source or binary into a directory of your choice
+
# Launch Tomcat from a command prompt by executing the catalina script or loading the bootstrap.jar directly.
+
# Go to http://localhost/manager and login with the manager username/password
+
# Deploy Equinox/OSGi-On-Server Servlet using Tomcat's deployment mechanism
+
# Kill Tomcat by using Control-C from the command prompt or exit from osgi> prompt
+
# Copy the following JARs from your Eclipse install's plugins directory to your Tomcat installation's '''webapps/bridge/WEB-INF/platform/plugins''' directory:
+
    org.eclipse.core.runtime_*.jar
+
    org.eclipes.core.jobs_*.jar
+
    org.eclipse.equinox.preferences_*.jar
+
    org.eclipse.core.contenttype_*.jar
+
    org.eclipse.emf.ecore_*.jar
+
    org.eclipse.emf.common_*.jar
+
    org.eclipse.emf.ecore.xmi_*.jar
+
    And copy directory: org.junit_3.8.1/
+
 
+
''Relaunch Tomcat from a command prompt by executing the catalina script''
+
 
+
===Eclipse OHF Build Process===
+
# Obtain all packages from the /technology/org.eclipse.ohf/plugins folder in Eclipse CVS
+
# Link org.eclipse.ohf.ihe.xds.soap with the external jar activation.jar (obtained from Sun's download site)
+
# Make the following modifications to the various Projects:
+
#:'''org.eclipse.ohf.ihe.xds.consumer'''
+
#:Change build.properties to fix Java  build
+
#:'''org.eclipse.ohf.ihe.xds.soap'''
+
#:Link with activation.jar from an External Library
+
#:'''org.eclipse.ohf.bridge.pdq.PDQbridge.java'''
+
#:Change paths to HL7 profiles on lines 86 and 87
+
#:'''org.eclipse.ohf.bridge.pix.PIXConsumerBridge.java'''
+
#:Change paths to HL7 profiles on lines 75 and 76
+
# Modify the Axis Distribution and make the following changes:
+
#:Add activation.jar to the Project and Project Build Path
+
#:Add activation.jar to the build.properties file
+
#:''Modifications to MANIFEST.MF''
+
#:Add activation.jar to Bundle-ClassPath
+
#:Add javax.activation to Export-Package
+
#:Add org.apache.commons to Require-Bundle
+
#:Add javax.servlet, javax.servlet.http to Import-Package  '''[Eishay] Check it out... poblems export the plugin this way'''
+
# In the org.eclipse.ohf.hl7v2.core.definitions.model.NamedDefn.java change the getName() method to:
+
      public String getName() {
+
            int lastSep = getPath().lastIndexOf(PATH_SEPARATOR);
+
            return getPath().substring(lastSep+1);
+
      }
+
      ''' Yes! Its a hack due to a pending bug. When the bug will be fixed we'll remove this instruction '''
+
 
+
===== IMPORTANT NOTE ON EXPORT ORDER =====
+
Before exporting all plug-ins, it MUST be verified that ''org.eclipse.ohf.ihe.xds.soap''
+
is linked with '''activation.jar''' and exporting properly.  IF NOT ALL CLASS FILES FROM
+
THIS PROJECT EXPORT PROPERLY, IT WILL CAUSE ''org.eclipse.ohf.ihe.xds.consumer'' TO BREAK AND
+
NOT EXPORT PROPERLY.  IT IS ABSOLUTELY ESSENTIAL THAT YOU VERIFY THAT ''org.eclipse.ohf.ihe.xds.soap''
+
IS PROPERLY LINKING AND EXPORTING.  IF YOU RECEIVE AN '''InvocationTargetException''' when running
+
the bridge for the first time, THIS IS YOUR PROBLEM AND IT MUST FIRST BE RESOLVED.
+
 
+
=== Plugin Installation===
+
# Export all OHF Projects from Eclipse using the Deployable Plug-Ins and Fragments options.
+
# After export, please see next section on how to properly create an org.apache.axis jar that will work with the bridge.
+
# Load Plugins into Tomcat using the OSGi command prompt or copy plugins to the Tomcat webapps/bridge/WEB-INF/platforms/plugins folder
+
# Copy server-config.wsdd file from org.eclipse.ohf.bridge/resources folder in your project workspace to the Tomcat webapps/bridge/WEB-INF folder.
+
# Restart Tomcat
+
# To test the install, go to http://localhost:8080/bridge/AxisServlet.  If you receive a list of web services, then the install was successful.
+
 
+
=== Creation of an Axis jar that will work with the Bridge ===
+
The following steps are to compose a suitable bundle of Apache Axis for use with Eclipse OHF and the OHF Bridge components.  Please note that some steps are performed outside of the Eclipse IDE to avoid several very complicated intermediary steps.  This process requires direct manipulation
+
of a Java Archive (JAR).  You may use any tool of your choice to do this.
+
 
+
In our example, we will use the jar program included with the Java SDK.
+
 
+
If you have any questions, please contact the Eclipse OHF mailing list or newsgroup. We will try to automate the process.
+
 
+
==== The following steps are to be performed within the Eclipse IDE ====
+
 
+
# Obtain the org.apache.axis project from the Eclipse OHF CVS Repository. See:  ''dev.eclipse.org:/cvsroot/technology/org.eclipse.ohf/plugins/org.apache.axis''
+
 
+
# Export the org.apache.axis project by right clicking on the project name in Eclipse, select "Export" and then pick "Plug-in Development" -> "Deployable Plug-ins and Fragments"
+
# Export to a directory of choosing. For example, C:\ohf
+
 
+
==== The following steps are to be performed outside of the Eclipse IDE====
+
You may use an application of your choosing to manipulate JAR files. We will use the ''jar'' program included with the Sun Java SDK for simplicity sake.
+
 
+
* Open a command prompt and navigate to the directory in which you exported the org.apache.axis bundle (cd C:\ohf\plugins)
+
* Unpack the org.apache.axis bundle using the following command:
+
jar -xvf org.apache.axis_1.0.0.jar
+
* Create a new file called ''plugin.xml'' in the directory you just unpacked the Axis JAR. Add the following contents to ''plugin.xml'':
+
    <?xml version="1.0" encoding="UTF-8"?>
+
    <?eclipse version="3.2"?>
+
    <plugin>
+
      <extension point="org.eclipse.equinox.http.registry.servlets">
+
        <servlet alias="/AxisServlet" class="org.apache.axis.transport.http.AxisServlet"/>
+
      </extension>
+
      <extension point="org.eclipse.equinox.http.registry.servlets">
+
        <servlet alias="/services" class="org.apache.axis.transport.http.AxisServlet"/>
+
      </extension>
+
    </plugin>
+
 
+
* The Xias implementation we use API does not provide an implementation of the javax.acitvation.DataHandler nor the javax.mail.internet.MimeMultipart packages needed for compilation and SOAP with attachment support. Java Mail 1.3.3 (mailapi.jar) and Java Activation
+
Framework 1.0.2 (activation.jar) must be downloaded separately. Take note of exact versions of these jars. These jars can be found at [http://java.sun.com/products/archive/javabeans/jaf102.html JAF v1.0.2] and [http://java.sun.com/products/javamail/javamail-1_3_3.htmlResources JAVA MAIL v1.3.3].
+
  
After downloading the respective packages, unzip each and move their principal JAR file (activation.jar from JAF, mail.jar from Java Mail) to the directory in which you unpacked the Axis jar.
+
== 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'''
  
=====Make the following changes to the file ''META-INF/MANIFEST.MF''=====
+
See the [[OHF Bridge PHP Sample Client]] page for instructions of how to install the web application.
* Bundle-SymbolicName:  Make the package a singleton instance (required for extending against the Equinox framework).
+
Bundle-SymbolicName: org.apache.axis; singleton=true
+
* Bundle-ClassPath:  Add ''activation.jar'' and ''mail.jar'' tothe existing list of JAR files in the classpath.
+
* Export-Package:  Force the export of packages provided by ''activation.jar'' and ''mail.jar''.  Add the following packages to the list:
+
javax.activation,
+
javax.mail,
+
javax.mail.internet
+
* Require-Bundle:  Because Apache Axis runs through its own servlet, it needs to be able to see the packages it's invoking (e.g. bridge). Add the following bundles to the Require-Bundle list:
+
org.eclipse.ohf.bridge,
+
org.eclipse.ohf.bridge.ws
+
* Import-Package:  For Axis's internal engine to work, it needs to have the Java Servlet API exposed to it.  This is provided natively by your application server's web container. Add the following line to the end of your manifest:
+
Import-Package: javax.servlet, javax.servlet.http
+
* Be sure to leave a blank line as the last line in your ''MANIFEST.MF'' file
+
* Delete the old org.apache.axis_1.0.0.jar file from the directory ''C:\ohf\plugins''.
+
* Recreate the ''org.apache.axis'' JAR while in the ''C:\ohf\plugins'' directory using the following command:     
+
jar -cvfmM org.apache.axis_1.0.0.jar META-INF/MANIFEST.MF .
+
  
You are now ready to start using Apache Axis in the Equinox server-side bridge and the Eclipse Open Healthcare Framework. Copy the ''org.apache.axis_1.0.0.jar'' file to the directory where the rest of your OHF plugins exist.
+
== Resources ==
 +
* [http://www.eclipse.org/ohf/components/bridge/index.php OHF Bridge Website]
 +
* [[OHF Bridge FAQ]]
 +
* [[OHF Glossary]]
 +
* [[IHE Connectathon 2008]]
 +
* [news://news.eclipse.org/eclipse.technology.ohf OHF Newsgroup].

Latest revision as of 20:55, 17 September 2008

Back to the OHF Wiki

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.

EMR on RCP.jpg

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.

Bridge architecture.jpg

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.

Bridge core2.jpg

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

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.

  1. use test and test123 as username and password
  2. Choose the ibmod235-all RHIO
  3. Choose "Wisconsin" as the state of residence for the patient for whom you are searching
  4. Click the "Search" button, and you should see a list of patients at the bottom of the page
  5. You'll notice that one of the patients is named Joyce Murphy. Click on the "Search for Documents" link under her information
  6. 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.
  7. 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

Bridge-architecture.png

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.

Resources

Back to the top