Skip to main content

Admit Discharge Transfer (ADT) Admit Patient (P/H)

This page describes the steps required to create a simple synchronous interaction between a sender and receiver.

Page contents

Admit Discharge Transfer (ADT) Admit Patient – Pipe and Hat format – Synchronous

ITK API simple synchronous interaction between sender and receiver

Overview

The scenario shows a simple synchronous interaction between sender and receiver, as previously described in the Spine mini-service provider (SMSP) examples. This example is drawn out to show how the ITK Reference Implementation manages the transmission of messages in non-xml format. In this case an HL7v2 ADT message in traditional “pipe and hat” format is packaged up and sent over the wire with no implications for the sending application and very little configuration. Although not shown here, the implications for the receiver are similarly simple.

Sender view

The Sender builds a SimpleMessage using a String containing the p/h ADT message. Configuration of the service tells the R.I. that this messages requires base64 encoding so the RI performs the encoding and builds the DistributionEnvelope with the appropriate tagging

Receiver view

The Receiver consumes the Simple Object Access Protocol (SOAP) message. This validates the SOAP headers and then extracts the payload. The SOAP payload is then split further into Distribution Envelope and business payload. The Distribution Envelope is validated and extracted into MessageProperties. The R.I. then looks up the service properties from the configuration and – in this case – as the payload is in base64 form it is decoded before being packaged up as a SimpleMessage and passed onto the Application Message Handler.

Request message

[code lang=”xml”]

<soap:Envelope xmlns:itk="urn:nhs-itk:ns:201005" … >

<soap:Header> … </soap:Header>

<soap:Body>

<itk:DistributionEnvelope … >

<itk:header service="urn:nhs-itk:services:201005:admitPatientPH-v1-0" …>

…

</itk:header>

<itk:payloads count="1">

<itk:payload id="…">TVNIfF5+X … 4MTIzNHwNCg== </itk:payload>

</itk:payloads>

</itk:DistributionEnvelope>

</soap:Body>

</soap:Envelope>

[/code]

Response message

[code lang=”xml”]

<soap:Envelope xmlns:itk="urn:nhs-itk:ns:201005" …

<soap:Header>

<wsa:MessageID>21BE8367-ADE7-4CD3-BB6A-0378AC9C2A91</wsa:MessageID>

<wsa:Action>urn:nhs-itk:services:201005:admitPatientPH-v1-0Response</wsa:Action>

<wsa:To/>

</soap:Header>

<soap:Body>

<itk:SimpleMessageResponse>OK</itk:SimpleMessageResponse>

</soap:Body>

</soap:Envelope>

[/code]

How it all happens - Step 1

The scenario shows a simple synchronous interaction between sender and receiver, as previously described in the SMSP examples. This example is drawn out to show how the ITK Reference Implementation manages the transmission of messages in non-xml format. In this case an HL7v2 ADT message in traditional “pipe and hat” format is packaged up and sent over the wire with no implications for the sending application and very little configuration. Although not shown here, the implications for the receiver are similarly simple.

[code lang=”xml”]

// Create the message

ITKMessage msg = new SimpleMessage();

msg.setBusinessPayload(phMessage);

…

mp.setServiceId("urn:nhs-itk:services:201005:admitPatientPH-v1-0");

…

// Send this message synchronously.

ITKMessage responseMsg = sender.sendSync(msg);[/code]

Step 2

A raw HL7v2 message in p/h format would not be valid data if just wrapped up in XML, so the ITK R.I. needs to know that this message is p/h so that it can construct the on-the-wire message accordingly. The R.I. uses a service.properties file to contain service configurations such as this.

[code lang=”xml”]

urn\:nhs-itk\:services\:201005\:admitPatientPH-v1-0.isBase64=Y

urn\:nhs-itk\:services\:201005\:admitPatientPH-v1-0.mimeType=text/plain

[/code]

Step 3

The Reference Implementation uses the service configuration to encode the message using core java language conversions.

[code lang=”java”]

if(service.isBase64()){

String b64DocText = javax.xml.bind.DatatypeConverter.

printBase64Binary(request.getBusinessPayload().getBytes());

request.setBusinessPayload(b64DocText);

}

message = new DEWrappedMessage(service, request, true);

[/code]

Step 4

Now the R.I. sets the mime type, base64 encoding to the appropriate values and embeds the encoded message as the payload.

[code lang=”xml”]

<itk:manifest count="1">

<itk:manifestitem base64="true"

id="uuid_6e9306ba-9a09-4479-a719-fcc23234b9ec"

mimetype="text/plain" profileid="ITKv1.0"/>

</itk:manifest>

<itk:senderAddress uri="urn:nhs-uk:addressing:ods:TESTORGS:ORGA"/>

</itk:header>

<itk:payloads count="1">

<itk:payload id="uuid_6e9306ba-9a09-4479-a719-fcc23234b9ec">TVNIfF5+XCZ8…

….HwNCg==</itk:payload>

</itk:payloads>



[/code]

Last edited: 12 August 2021 10:41 am