The Open eHealth Integration Platform (IPF) provides interfaces for health-care related integration solutions. An prominent example of an healthcare-related use case of IPF is the implementation of interfaces for transactions specified in Integrating the Healthcare Enterprise (IHE) profiles.
IPF can be easily embedded into any Java application and additionally supports deployments inside OSGi environments.
IPF is built upon and extends the Apache Camel routing and mediation engine. It has an application programming layer based on the Groovy programming language and comes with comprehensive support for message processing and connecting systems in the eHealth domain. IPF provides domain-specific languages (DSLs) for implementing Enterprise Integration Patterns in general-purpose as well as healthcare-specific integration solutions.
IPF uses Maven as build tool. Depending on your project needs you might want to define dependencies to various IPF artifacts. For example, the following statements will include all dependencies needed to work with IPF interfaces for MLLP-based HL7v2 IHE transactions:
<dependency> <groupId>org.openehealth.ipf.platform-camel</groupId> <artifactId>ipf-platform-camel-ihe-mllp</artifactId> <version>3.2.0</version> </dependency>
Even better, you can import the IPF bom in the dependency management section. Then you don’t have to provide version numbers for the major dependencies anymore.
<dependencyManagement> <dependency> <groupId>org.openehealth.ipf</groupId> <artifactId>ipf-dependencies</artifactId> <version>3.2.0</version> <type>pom</type> <scope>import</scope> </dependency> ... <dependencyManagement> <dependencies> <dependency> <groupId>org.openehealth.ipf.platform-camel</groupId> <artifactId>ipf-platform-camel-ihe-mllp</artifactId> </dependency> ... </dependencies>
Now you can expose or consume IHE-compliant MLLP-based transaction endpoints, e.g. receiving and validating PIX Feed requests:
import static org.openehealth.ipf.platform.camel.ihe.mllp.PixPdqCamelValidators.*; import org.apache.camel.builder.RouteBuilder; from("pix-iti8://0.0.0.0:8777?audit=true&secure=true") .process(itiValidator()) // validate incoming request .process(myProcessor); // process the incoming request and create a response
The following table summarizes the IPF features related to the eHealth domain:
|Support for eHealth integration profiles||A set of components for creating actor interfaces as specified in IHE and Continua integration profiles. IPF currently supports creation of actor interfaces for the IHE profiles XDS.a, XDS.b, PIX, PDQ, PIXv3, PDQv3, PIXm, PDQm, MHD, QED, XCPD, XCA, XCA-I, XCF, XPID, PCD, as well as for Continua profiles HRN and WAN.|
|HL7 Message processing||Basis for HL7 message processing is the HL7v2 DSL. These provides the basis for implementing HL7 Message processing Camel routes.|
|HL7 Message translation||Translation utilities for translating between HL7v3 and HL7v2 messages for correspdoning IHE transactions|
|CDA Support||Wrapping a number of CDA-related libraries, providing the basis for implementing CDA processing Camel routes.|
|FHIR Support||FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – is a next generation standards framework created by HL7 leveraging the latest web standards and applying a tight focus on implementability.|
Other IPF features provide part of the underlying foundation or supporting functionality:
|Core Features||Domain-neutral message processors and DSL extensions usable for general-purpose message processing.|
|Code System Mapping||A simplistic mechanism for mapping code values between code systems|
|Dynamic Feature Registration||Aids in building up modular integration solutions where each module contributes routes, services etc. to the overall application|
IPF is prepared to run in OSGi environments as well:
|OSGi Support||Enables the deployment of IPF modules (bundles) to OSGi platforms. IPF service bundles register platform services at the OSGi service registry for consumption by IPF applications|
IPF 3.2 deprecates the modules listed below. They will likely be removed from the main IPF project in the next major release.
- ipf-commons-flow and ipf-platform-camel-flow
- ipf-modules-hl7-dsl (note that the HL7 DSL is part of ipf-modules-hl7)
- ipf-osgi (i.e. all OSGi support)
Tutorials and Examples
|HL7 Support tutorial||How to integration HL7 message processing into Camel|
|XDS tutorial||A Groovy based implementation of an XDS repository|
|Dynamic extension tutorial||How to have IPF-based application modules contributing to an application|
|IHE Client Example||Some examples how to use IPF producer endpoints|
|[OSGi tutorial]||OSGi Tutorial|
|Recoverability||Recoverability means that a system can recover from crashes or service failures without losing messages or data|
|Performance Monitoring||Monitor performance and throughput of routes|
If you are using previous versions of IPF and want to update:
- IPF 3.2.x comes with some changes that must be considered when upgrading from IPF 3.1.x to IPF 3.2.x Read the 3.2 Update Instructions for how to update from IPF 3.1.x
- IPF 3.1.x introduces a few minor incompatibilities compared to IPF 3.0.x due to having less mandatory dependencies on the Spring framework. Read the 3.1 Update Instructions for how to update from IPF 3.0.x
- IPF 3.0.x is not backwards-compatible with IPF 2.x. Read the Migration Instructions for how to migrate a IPF 2.x-based integration solution.
IPF code is Open Source and licensed under Apache license.