DOCSEARCHbyAlgolia
Submit Docs

Open eHealth Integration Platform (IPF)

repository·master·Indexed 41 days ago

https://github.com/oehf/ipf

A specialized extension of Apache Camel for healthcare integration. It provides domain-specific languages (DSLs) and building blocks to implement healthcare standards, including IHE profiles (XDS, PIX, PDQ, XCPD) and HL7v2/HL7v3 (CDA and CCD) messages.

Tokens
7.1K
Snippets
14
Records
28
Agent score
52%

What's inside IPF

  1. Overview of the Open eHealth Integration Platform (IPF)

    master

    The Open eHealth Integration Platform (IPF) is an extension of the Apache Camel routing and mediation engine. It is designed specifically for the healthcare sector to facilitate message processing and the connection of information systems.

    Key features include:

    • Domain-Specific Languages (DSLs): IPF uses Java and Groovy to implement Enterprise Integration Patterns (EIPs) and allows for the design of project-specific DSLs.
    • IHE Profile Support: Provides high-level building blocks for implementing IHE profiles such as XDS, PIX, PDQ, and XCPD.
    • HL7 Support: Includes DSLs for the creation, parsing, rendering, navigation, and modification of HL7v2 and HL7v3 (including CDA and CCD) messages.

  2. Overview of CDA Schema with SDTC extensions

    master
    This package provides CDA (Clinical Document Architecture) Schema definitions supplemented with SDTC (Standardized Data Types and Constraints) extensions. These extensions have been approved by the HL7 SDWG (Standardized Data Types and Constraints Working Group) and are intended to supplement the published CDA R2 base standard with updated, more precise schema definitions.

  3. Overview of HITSP C32 v2.4 Schematron Package

    master

    The HITSP C32 v2.4 Schematron package provides rules for validating XML documents against specifications defined by HITSP C32, HITSP C80, IHE PCC (Patient Care Coordination), and CDA4CDT.

    Important Limitation: These schematron files check for conformance only against the specific HITSP/IHE profiles mentioned above. They do not validate against the base Clinical Document Architecture Release 2 (CDA R2) or Continuity of Care (CCD) specifications. To perform full CDA R2 or CCD validation, you must obtain the Schematron for CCD from the HL7 Wiki.

    Package Structure:

    • HITSP_C32.sch: The primary Schematron file for HITSP/C32 (OID: 2.16.840.1.113883.3.88.11.32.1).
    • templates/: Directory containing .ent (entity) files imported by the main Schematron file.
    • cdar2c32/: Directory containing the HL7 CDA R2 schema modified with HITSP extensions.
    • example/: Directory containing sample HITSP/C32 documents for testing.

  4. Use IHE QRPH Schematron rules for XML validation

    master

    This package provides Schematron rules specifically for validating XML documents against the guidelines defined by the IHE Quality, Research and Public Health (QRPH) Technical Framework.

    Important Limitations:

    • These files check for conformance against IHE QRPH rules only.
    • They do not validate against Clinical Document Architecture Release 2 (CDA R2), Continuity of Care (CCD), or CDA For Common Document Types (CDA4CDT) rules. If your QRPH specification requires those rules, you must obtain the corresponding Schematron files from the HL7 Wiki.

    Package Structure:

    • crd.sch: The Schematron file for IHE QRPH Clinical Research Data Capture (CRD). Note that this is for the CCD Option Only.
    • templates/: A directory containing all entity files imported by the main .sch files.

  5. Use the HITSP C32 v2.5 Schematron package for XML validation

    master

    This package provides Schematron rules to validate XML documents against the HITSP/C32 guidelines (HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component v2.5).

    Important Validation Scope

    • What it checks: Conformance against HITSP and IHE PCC rules only.
    • What it does NOT check: It does not check against Clinical Document Architecture Release 2 (CDA R2) or Continuity of Care (CCD) rules that HITSP/IHE specifications might require. For full CDA R2 or CDA4CDT validation, you must use Schematron files from the HL7 Wiki.

    Package Components

    • HITSP_C32.sch: The primary Schematron file for HITSP/C32 validation.
    • templates/: A directory containing all entity files imported by the main .sch file.
    • cdar2c32: A modified CDA R2 schema that allows for additions specified in HITSP/C83.

    Dependencies

    The HITSP_C32.sch file imports rules and value set definitions from:

    • HITSP/C83 CDA Content Modules Component v2.0
    • HITSP/C80 Clinical Document and Message Terminology Component v2.0

  6. Configure hardened XML processing

    master

    XML processing in IPF 6.0 is hardened against XXE and SSRF. The org.openehealth.ipf.commons.xml.XmlSecurity component applies countermeasures to JAXP and Saxon components including XsdValidator, XsltTransmogrifier, SchematronTransmogrifier, XqjTransmogrifier, and CDAR2Parser.

    Constraints:

    • External entities and DTDs are no longer resolved.
    • Schema compilation is restricted to file and jar protocols. Remote xs:import or xs:include via HTTP is not permitted.
    • Instance validation, XSLT, Schematron, and XQuery processing permit no external access.
    • Action Required: Any logic relying on resolving external entities, remote xs:import, or the document() function over HTTP must be updated to provide these resources locally.

  7. Update MHD implementation for version 4.2.4

    master

    MHD support has been updated to version 4.2.4. Key changes include:

    • MhdVersion is now an enum: Use enum MhdVersion { v320, v423, v424 }. The marker interfaces Mhd423, Pdqm320, and Pixm310 have been removed.
    • Profile Validation: Validation against MHD 3.2.0 is no longer possible as the v320 implementation guide resources are no longer shipped. MhdValidator.packagePathFor(MhdVersion.v320) will throw an IllegalArgumentException.
    • Identifier Types: entryUUID and uniqueId are now distinguished by the MhdIdentifierType enum via Identifier.type rather than Identifier.use.

    Recommended way to access identifiers in new code:

    MhdIdentifierType.ENTRY_UUID.find(documentReference.getIdentifier())
    .map(Identifier::getValue)
    .ifPresent(entryUuid -> ...);

  9. The Schematron validation pipeline stages

    master

    Schematron validation is implemented as a multi-stage XSLT pipeline. Depending on the complexity of your schema, you may need to run all or some of the following stages:

    1. Include Expansion: Use iso_dsdl_include.xsl to assemble a schema from various parts. Skip if your schema is a single file.
    2. Abstract Pattern Expansion: Use iso_abstract_expand.xsl to convert abstract patterns into real patterns. Skip if your schema does not use abstract patterns.
    3. Compilation: Compile the processed schema into an XSLT script. This typically uses iso_svrl_for_xslt1.xsl or iso_svrl_for_xslt2.xsl (which invoke skeleton styles like iso_schematron_skeleton_for_xslt1.xsl or iso_schematron_skeleton_for_saxon.xsl). If your schema uses Schematron phases, supply them as parameters during this stage.
    4. Validation: Run the generated XSLT script against your target XML document. If using an SVRL script, the output will be an XML document. If your schema uses Schematron parameters, supply them as parameters during this stage.

  10. Localize Schematron diagnostic messages

    master

    The XSLT2 skeleton includes diagnostic messages in English, located in sch-messages-en.xhtml. You can use this file as a template to create localized versions of the skeleton's error messages.

    Note: Most programming errors in Schematron are actually XPath errors; these require localized messages from the underlying XSLT engine itself, rather than the Schematron layer.

  11. Migrate to IPF 6.0 Stack (Jakarta EE 11 and Spring Boot 4.1)

    master

    IPF 6.0 upgrades the underlying technology stack. If you are upgrading from IPF 5.3, note the following dependency changes:

    • Spring Boot: Upgraded from 3.5 to 4.1.
    • Apache Camel: Upgraded from 4.18 to 4.22.
    • Apache CXF: Upgraded from 4.1 to 4.2.
    • Jackson: Upgraded from 2.22 to 3.1. Critical: The databind API has moved from com.fasterxml.jackson.* to tools.jackson.*. Do not manually override jackson-version to a version higher than what Spring Boot manages, as Jackson 3.2.x rejects certain type-id/bean-property name collisions required by the XDS metadata model.
    • Kotlin: Upgraded from 2.2 to 2.4.
    • HAPI FHIR: Upgraded from 8.10 to 8.12.

    Java Requirement: Java 17 is the minimum required version (tested against 21 and 25).

    | Feature         | IPF 5.3.0 | IPF 6.0.0 |
|-----------------|-----------|-----------|
| Spring Boot     | 3.5       | 4.1       |
| Apache Camel    | 4.18      | 4.22      |
| Apache CXF      | 4.1       | 4.2       |
| Jackson         | 2.22      | 3.1       |
| Kotlin          | 2.2       | 2.4       |
| HAPI FHIR       | 8.10      | 8.12      |

  12. Join the IPF Mailing Lists

    master

    For development discussions or user support, you can join the following Google Groups mailing lists:

    • ipf-dev: For developer-related discussions and core project development.
    • ipf-user: For general user questions, support, and usage discussions.