Infrastructure Implementation Manual
	Programme	NPFIT	DOCUMENT NUMBER
	Sub-Prog/Project	Comms & Messaging	National Prog	Org	Prog/Proj	Doc Type	Seq
	Prog. Director	Tim Jones	NPFIT	NDA	COM	TZ	0167
	Sub-Prog/Proj Mgr	Margaret Baldock
	Author	Core Technical Team	Version No.		3.7
	NPO/PSO Contact	Sarah King	Status		Issued

 

 

Contents

 

 

 

Change History

In Version	Author	Date	Amendment Details
0.1	Core Technical Team	26/10/2003	First draft version
0.2	Core Technical Team	25/11/2003	Final draft before issue
1.0	Core Technical Team	28/11/2003	Issued
2.0	Core Technical Team	14/02/2004	New messages defined, messages renamed, modifications made, interactions introduced.
2.1	Core Technical Team	23/03/04	Includes interaction schemas and tabular view modification for PDS.
3.0	Core Technical Team	10/05/04	Change request DACM-CT-2, new control act, cosmetic modifications.
3.1	Core Technical Team	25/06/04	Vocabularies constrained to CV datatype in QUQI_MT020101UK11.
3.2	Core Technical Team	20/08/04	Repaired Hyperlinks
3.3	Core Technical Team	03/09/04	New generic Control Act wrapper and generic Query Acknowledgement Response wrapper.
3.4	Core Technical Team	17/09/04	Removal of deprecated interactions and messages.
3.5	Core Technical Team	29/10/04	Changes to Send Message Payload & Application Acknowledgement to include intended recipient. Changes to Application Acknowledgement,  Control Act and Query Acknowledgement Response to enable consistent issue/error reporting. See change log for details.
3.6	Core Technical Team	06/12/04	Added NHS number to Notify Message Withdrawal. Minor changes to wrapper RMIMs to support consistent issue/error reporting. Additional guidance on issue error reporting. New section containing interaction examples.
3.7	Core Technical Team	14/01/05	Changed lowercase characters in example UUIDs to uppercase.

 

 

1    Overview

The Infrastructure Domain defines message profiles for use in all NPfIT HL7 messaging.

 

Development of profiles

The HL7 v3 Infrastructure messages have a large amount of optionality. For wrappers it is clearly useful to limit optionality and only specify features for which there is a clear requirement. These profiles are designed to meet these objectives.

 

Routing

This  set of messages are intended for a conventional HL7 v3 routing infrastructure, with Sender and Receiver logical addresses allowing the usual HL7 v3 capability for special routing on any of the communication paths which messages need to traverse from Sender to Receiver.

 

Send Message Payload, Control Act, Query and message contents

Send Message Payload, Control Act and Query have no stand-alone role and are used as wrappers to be integrated with domain messages. Integration occurs at the schema level and NPfIT messages are being issued with full integration of the schemas already in place.

 

 

2    Application Roles

2.1    Request/Notification Message Receiver - MCCI_AR010000UK01

The Request/Notification Message Receiver receives HL7 composite message payloads and sends application acknowledgements.

 

2.2    Request/Notification Message Sender - MCCI_AR020000UK01

The Request/Notification Message Sender sends HL7 composite message payloads and receives application acknowledgements.

 

2.3    Query Fulfiller - QUQI_AR010000UK01

A query role that responds to HL7 version 3 queries that have been specified using the query by parameter mechanism.

 

2.4    Query Placer - QUQI_AR020000UK01

A query role that places HL7 version 3 queries using the query by parameter query specification mechanism.

 

 

 

3    Trigger Events

3.1    Send Application Acknowledgement - MCCI_TE010000UK01

Description:

 

The sending of an application acknowledgement occurs in response to the receipt of an HL7 composite message payload.

 

3.2    Query Failed - QUQI_TE010000UK01

Description:

 

The sending of a query failed response occurs in response to the receipt of a failed query from a query placer.

 

 

4    Interactions

4.1    Exception Handling Guidance

4.1.1    Overview

 

The purpose of this guidance is to describe the approach taken by NPfIT to enable consistent exception handling across all domains. This approach was originally defined in MIM v3.1.07 and has been expanded in MIM v3.1.08.

 

Issues/errors can be identified at two levels, messaging and business:

• Messaging issues are those related to the communication and delivery of the message or its structure. 

• Business issues are defined as being those related to the information conveyed by the message, evaluated in context by the processing application.

4.1.2    Messaging Issues/Errors

 

Messaging issues and errors are carried in the Application Acknowledgement wrapper in the AcknowledgementDetail class. A single code system managed externally by BT Syntegra and referenced in the MIM will define all codes that identify messaging issues and errors. Each code shall be further classified by the AcknowledgementDetail.typeCode which contains a severity indicator who’s purpose is  to indicate the severity of the error.

 

The MHS codes will be documented in the BT External Interface Specification.  As these codes are generic to MHS implementations (i.e. not specific to the BT MHS implementation) other MHS implementers shall have the ability to add codes to the MHS error namespace.  To get new codes added to the MHS namespace the implementer should contact BT through the Authority Spine liaison point.

4.1.3    Business Issues/Errors

Business issues and errors are carried in the Trigger Event Control Act and Query Acknowledgement Response wrappers in the DetectedIssueEvent class; with the option of supporting details being carried in the response payload.

 

The code identifying a business issue or error should no longer be carried in the domain response payload.

 

In MIM V3.1.08, codes carried in PDS response payloads and LR response payloads have been removed.

 

PDS Response messages no longer explicitly carry a code and value indicating success. A successful confirmation is implicit from the presence of the response payload; an indication of a failed confirmation or additional information relating to the confirmation (such as an indication that sensitivity conditions apply to the information) is provided in the DetectedIssueEvent class.

 

The ability to carry codes in ETP and GP2GP response payloads has been retained but made optional to enable backwards compatibility. However, it is recommended that from MIM V3.1.08, all issue and error codes be carried in the Trigger Event Control Act and Query Acknowledgement Response wrappers DetectedIssueEventClass.

 

Where necessary, detail supporting an issue or error shall be carried in a response payload.

The ActDetectedIssueCode vocabulary page identifies a code system for each business domain. In all cases, except ETP, there is a single code system per domain. Where a code system is managed externally, the contents can only be obtained from the code system custodian. If a pertinent code does not exist in the relevant code system, its inclusion can be managed by the code system custodian.

The error codes for the following domains are documented in the BT External Interface Specification:

• PDS

• Medication Management (except error codes generated by the PPA).

• PSIS

• ACF (LRs)

For additional information on these code namespaces, contact BT through the Authority Spine Liaison point.

4.2    Application Acknowledgement - MCCI_IN010000UK13

An application acknowledgement on receipt of a request or notification. Note: This interaction is invoked, where appropriate, as a receiver responsibility.

This interaction can also be invoked by an intermediary, such as the TMS, when a messaging error occurs. In these circumstances, the sender identifier will identify the intermediary using the standard SDS identifier as described in the message documentation. 

 

Sending Role	Request/Notification Message receiver	MCCI_AR010000UK01
Receiving Role	Request/Notification Message sender	MCCI_AR020000UK01
Trigger Event	Send Application Acknowledgement	MCCI_TE010000UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03

 

 

4.3    Query Act Failed - QUQI_IN010000UK14

A Query Act Failed interaction contains status information on an identified query that has failed and does not contain any query results.

 

Sending Role	Query Fulfiller	QUQI_AR010000UK01
Receiving Role	Query Placer	QUQI_AR020000UK01
Trigger Event	Query Failed	QUQI_TE010000UK01
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgement Response	QUQI_MT030101UK03

 

 

 

5    Message Definitions

5.1    Send Message Payload - MCCI_MT010101UK12

This message is the outer transport wrapper for all NPfIT domain messages with the exception of specific business response interactions which use an application acknowledgement wrapper. It identifies the sender and recipient of the message and contains the “controlled act” that is being sent.

 

               

 

5.2    Application Acknowledgement - MCCI_MT020101UK12

The application acknowledgement wrapper enables a response indicating either successful receipt of the message or that the message has been received containing issues or errors. 

 

                 

 

5.3    Trigger Event Control Act – MCAI_MT040101UK03

This control act is designed for use by all domains. It provides audit functionality by carrying the identity of the person and/or system responsible for initiating the message and enables the optional reporting of detected issues/errors.

 

                 

 

5.4    Query Acknowledgement Response – QUQI_MT030101UK03

The Query Acknowledgement Response defines the control act used in all query responses. It contains an optional domain response and an option to report issues/errors.

 

                 

 

5.5    Notify Message Withdrawal – UKCI_MT010101UK02

This message is used to notify the recipient that the identified message which the recipient has already received should not have been sent.

 

                

---