|
|
| Line 1: |
Line 1: |
| | This page will try to supply missing documentation problems occurring due to the frequent updates and new requirements we receive from the [[IHE Connectathon 2007]] tests. | | This page will try to supply missing documentation problems occurring due to the frequent updates and new requirements we receive from the [[IHE Connectathon 2007]] tests. |
| − |
| |
| − | ==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]]
| |
This page will try to supply missing documentation problems occurring due to the frequent updates and new requirements we receive from the IHE Connectathon 2007 tests.
