Message types in IPF XDS/XCA/XCF/RAD Components

IPF XDS/XCA Components support both the “raw” ebXML format prescribed by the IHE specification as well as simplified data representation. See corresponding sections below for details.

ebXML data model

According to the IHE specification, XDS/XCA/XCF/RAD transactions use ebXML 3.0 data models for incoming and outgoing messages. IPF XDS/XCA components use Java stub classes instead of plain XML payload. All conversions are performed automatically when needed.

Data types for the request message of the supported transactions are listed in the table below:

Transaction	Request Message Type (`org.openehealth.ipf.commons.ihe.xds.core...`)
ITI-18,38,51,63; PHARM-1	`.stub.ebrs30.query.AdhocQueryRequest`
ITI-39,43	`.ebxml.ebxml30.RetrieveDocumentSetRequestType`
ITI-41,80	`.ebxml.ebxml30.ProvideAndRegisterDocumentSetRequestType`
ITI-42,57,61,92	`.stub.ebrs30.lcm.SubmitObjectsRequest`
ITI-62	`.stub.ebrs30.lcm.RemoveObjectsRequest`
ITI-86	`.ebxml.ebxml30.RemoveDocumentsRequestType`
RAD-69,75	`.ebxml.ebxml30.RetrieveImagingDocumentSetRequestType`

Data types for the response message of the supported transactions are listed in the table below:

Transaction	Response Message Type (`org.openehealth.ipf.commons.ihe.xds.core...`)
ITI-18,38,51,63; PHARM-1	`.stub.ebrs30.query.AdhocQueryResponse`
ITI-39,43; RAD-69,75	`.ebxml.ebxml30.RetrieveDocumentSetResponseType`
ITI-41,42,57,61,62,80,86,92	`.stub.ebrs30.rs.RegistryResponseType`

Simplified Data Model

Besides the support of raw ebXML messages, the IPF offers a model that abstracts from the ebXML representation of the data and is preferable for the user due to its close relation to the application domain.

Data types for the request message of the supported transactions are listed in the table below:

Transaction	Request Message Type (`org.openehealth.ipf.commons.ihe.xds.core.requests...`)
ITI-42,57,61,92	`.RegisterDocumentSet`
ITI-41,80	`.ProvideAndRegisterDocumentSet`
ITI-18,38,51,63; PHARM-1	`.QueryRegistry`
ITI-39,43	`.RetrieveDocumentSet`
ITI-62	`.RemoveMetadata`
ITI-86	`.RemoveDocuments`
RAD-69,75	`.RetrieveImagingDocumentSet`

Data types for the response message of the supported transactions are listed in the table below:

Transaction	Response Message Type (`org.openehealth.ipf.commons.ihe.xds.core.responses...`)
ITI-41,42,57,61,62,80,86,92	`.Response`
ITI-18,38,51,63; PHARM-1	`.QueryResponse`
ITI-39,43; RAD-69,75	`.RetrievedDocumentSet`

Some XDS model classes from the package org.openehealth.ipf.commons.ihe.xds.core.metadata wrap HAPI objects:

Class Name	HL7 v2 data holder type
Address	XAD
AssigningAuthority	Holder<HD>
Code	CE
Identifiable	CX
Organization	XON
Person	XCN
ReferenceId	CX
Telecom	XTN
XcnName	XCN
XpnName	XPN

These classes have constructors which take HAPI objects as parameters, thus providing the possibility to create XDS objects directly from HL7v2 ones. The wrapped HAPI objects can be accessed via .getHapiObject() methods of the XDS model class instances (for AssigningAuthority: .getHapiObject().getInternal()).

The static methods render(object) and rawRender(object) of the class org.openehealth.ipf.commons.ihe.xds.core.metadata.Hl7v2Based can be used for getting an HL7v2 string representation of the given XDS model object. render(object) considers all IHE rules regarding unwanted components (see ITI TF Volume 3 Section 4.1), and, for example, omits display name in CE codes. rawRender(object) renders all components, even if they do not have any meaning in XDS context.

The static method parse() performs the opposite conversion — from an Hl7 v2 string to an XDS simplified object model.

The classes XcnName and XpnName both implement the interface Name, are compatible in regard to the method .equals() and fully interchangeable in all situations.

Transformation between the models

Transformation between the ebXML and the simplified data models can be performed by means of Camel type converters provided by the IPF, as outlined in the following example.

Type converters are applied by either using the convertBodyTo(Class) processor, or by converting the message body on the fly, e.g. using exchange.getIn().getBody(Class).

Although the route below is written in Groovy, type conversion does not require the Groovy programming language.

    import static org.openehealth.ipf.commons.ihe.xds.core.responses.Status.*

    import org.apache.camel.spring.SpringRouteBuilder
    import org.openehealth.ipf.commons.ihe.xds.core.requests.QueryRegistry
    import org.openehealth.ipf.commons.ihe.xds.core.requests.query.FindDocumentsQuery
    import org.openehealth.ipf.commons.ihe.xds.core.responses.QueryResponse
    import org.openehealth.ipf.commons.ihe.xds.core.metadata.ObjectReference
    import org.openehealth.ipf.platform.camel.core.util.Exchanges

    class RouteBuilder extends SpringRouteBuilder {
    
        @Override
        void configure() throws Exception {
            from("xds-iti18:myIti18Service")
                .convertBodyTo(QueryRegistry.class)
                .choice()
                    // Return an object reference for a find documents query
                    .when { it.in.body.query instanceof FindDocumentsQuery }
                        .transform {
                            def response = new QueryResponse(SUCCESS)
                            response.references.add(new ObjectReference('document01'))
                            response
                        }
                    // Any other query else is a failure
                    .otherwise()
                        .transform { new QueryResponse(FAILURE) }
        }
    }