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.5.1</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.5.1</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 corresponding IHE transactions
|Wrapping a number of CDA-related libraries, providing the basis for implementing CDA processing Camel routes.
|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.
|DICOM Audit Support
|Support for constructing, serializing and sending DICOM audit messages
Other IPF features provide part of the underlying foundation or supporting functionality:
|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 comes with some Spring Boot Starters that support running eHealth applications in the Spring Boot runtime environment.
- As XDS.a transactions have been retired by IHE, all functionality related with ITI-14, ITI-15, ITI-16 and ITI-17 have been removed. This includes the ebXML/ebRS 2.x model classes.
IPF 3.5.1 added the modules listed below:
IPF 3.5.1 deprecates the following modules:
These modules will be removed as soon as FHIR r4 support has been included.
The javadocs can be obtained here.
Tutorials and Examples
|HL7 Support tutorial
|How to integration HL7 message processing into Camel
|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
If you are using previous versions of IPF and want to update:
- IPF 3.5.x comes with some changes that must be considered when upgrading from IPF 3.4.x. Read the 3.5 Update Instructions for how to update from IPF 3.4.x
- IPF 3.4.x comes with some changes that must be considered when upgrading from IPF 3.2.x or IPF 3.3.x to IPF 3.4.x Read the 3.4 Update Instructions for how to update from IPF 3.1.x
- 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.