GP2GP Implementation Manual
Programme	NPFIT	DOCUMENT NUMBER
Sub-Prog/Project	Comms & Messaging	National Prog	Org	Prog/Proj	Doc Type	Seq
Prog. Director	Tim Jones	NPFIT	FNT	TO	DPM	0101.01
Sub-Prog/Proj Mgr	Margaret Baldock
Author	Core Technical Team	Version No.		1.7
NPO/PSO Contact	Sarah King	Status		Issued

Contents

Change History

In Version	Author	Date	Amendment Details
1.0	Core Technical Team	10/05/2004	First Issue
1.1	Core Technical Team	25/06/2004	Updated for documentation issues
1.2	Core Technical Team	16/07/2004	Fixed broken hyperlinks
1.3	Core Technical Team	03/09/2004	Includes new generic Control Act Wrapper, new SDS OIDs and updated Agent SDS CMETs.
1.4	Core Technical Team	08/09/2004	Fixed broken hyperlinks and corrected message version numbers
1.5	Core Technical Team	29/10/2004	Updated to new versions of Infrastructure Artefacts.
1.6	Core Technical Team	06/12/2004	Updated to new versions of Infrastructure Artefacts. Change Request MIM-CR-0272 - details of these changes are given in Section 9. Removed previous section 8 - Interaction Index.
1.7	Core Technical Team	07/01/2005	Change requests MIM-CR-0146, 0235, 0274, 0296 and DACM-CR-54. Full details of changes given in section 9.

1 Overview

The message definitions accessible from within this document have been defined to support transfers of Electronic Healthcare Records (EHR or Ehr) between GP Practices.

Assumptions

The following assumptions have been made with regard to this message pack:

Anonymity of the requesting GP Practice does not need to be preserved;
The requesting GP system is able to retrieve adequate information from both PDS and SDS in order to route a request message to the correct GP Practice where the patient's Electronic Healthcare Record is held;
Manual processes are required at the GP Practice where the patient's Electronic Healthcare Record is held before a request is acknowledged or actioned;
The SDS stores adequate information about a device (software system supplier, system and version etc) such that only a SDS device ID is needed in the EHR Extract message as identification for the device;
External documents that form part of the Electronic Healthcare Record but which are not stored by the clinical system can be transferred between GP Practices via TMS, either as separate MIME-type attachments or in-line inside the EHR Extract message.

Changes since NHS GP2GP Project

The number of messages thought to be required to support the electronic record transfer process has reduced to the three documented here.
The EhrExtract message has been modified in a number of ways. The main reasons for making changes are:

o Alignment with clinical statement work;

o Alignment with more recently balloted HL7 material;

o Inclusion of Snomed CT coding;

o Resolution of previously outstanding issues;

o Error corrections.

2 Storyboards

2.1 Successful EHR Transfer Request and Responses

Eve Everywoman has moved out from her parent’s house in Edinburgh to a new apartment in London and soon after visits a local GP Practice, Dr Smith and Partners, to register for services. Upon registration at the new GP Practice, the GP system queries the PDS for her pre-existing GP Practice registration. It also queries the SDS for information about whether the GP system at her old GP Practice, Dr McDonald and Partners, has a NCRS compliant system. The response to this latter query is positive, enabling the GP system at Dr Smith and Partners to send an EHR Request message to the GP system at Dr McDonald and Partners.

Upon receipt of the EHR Request message, Dr McDonald indicates to his GP system that that the EHR extract will be sent within 24 hours, and the system duly sends an EHR Request Acknowledgement message indicating that back to the GP system at Dr Smith and Partners.

Within 24 hours, Dr McDonald's GP system duly sends an EHR Extract message to the GP system at Dr Smith and Partners.

3 Application Roles

The applications involved in the business processes listed above play specific roles. These, along with a description of the interactions associated with each role, are identified below.

3.1 Electronic Healthcare Record Requester - RCMR_AR010000UK01

The Electronic Healthcare Record Requester is the initiator of a request for a patient's Electronic Healthcare Record.

3.2 Electronic Healthcare Record Request Fulfiller - RCMR_AR020000UK01

The Electronic Healthcare Record Request Fulfiller is receiver of an Electronic Healthcare Record Request and provider of a patient's Electronic Healthcare Record where possible.

4 Trigger Events

The trigger events which cause each interaction to be initiated are identified below.

4.1 Electronic Healthcare Record Request Started - RCMR_TE010000UK01

The Electronic Healthcare Record Request Started trigger event signals that a request to provide the patient's Electronic Healthcare Record has been made.

4.2 Electronic Healthcare Record Request Acknowledged - RCMR_TE020000UK01

The Electronic Healthcare Record Request Acknowledged trigger event signals that a request to provide the patient's Electronic Healthcare Record has been received and is being actioned where possible.

4.3 Electronic Healthcare Record Request Completed - RCMR_TE030000UK01

The Electronic Healthcare Record Request Completed trigger event signals that a request to provide the patient's Electronic Healthcare Record is being fulfilled by the provision of the Electronic Healthcare Record.

5 Interaction Diagrams

This section provides diagrammatic representation of which interactions are related to which application roles.

6 Interactions

6.1 Electronic Healthcare Record Request Started - RCMR_IN010000UK03

Sending Role	Electronic Healthcare Record Requester	RCMR_AR010000UK01
Receiving Role	Electronic Healthcare Record Request Fulfiller	RCMR_AR020000UK01
Trigger Event	Electronic Healthcare Record Request Started	RCMR_TE010000UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act - Action	MCAI_MT040101UK0 3
Message Type	EHR Request	RCMR_MT010101UK02

Receiver Responsibilities

Reason

Interaction

Request received

Electronic Healthcare Record Request Acknowledged:

RCMR_IN020000UK03

Request received and EHR extract available for sending

Electronic Healthcare Record Request Completed:

RCMR_IN030000UK05

6.2 Electronic Healthcare Record Request Acknowledged - RCMR_IN020000UK03

Sending Role	Electronic Healthcare Record Request Fulfiller	RCMR_AR020000UK01
Receiving Role	Electronic Healthcare Record Requester	RCMR_AR010000UK01
Trigger Event	Electronic Healthcare Record Request Acknowledged	RCMR_TE020000UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	EHR Request Acknowledgement	RCMR_MT020101UK03

6.3 Electronic Healthcare Record Request Completed - RCMR_IN030000UK05

Sending Role	Electronic Healthcare Record Request Fulfiller	RCMR_AR020000UK01
Receiving Role	Electronic Healthcare Record Requester	RCMR_AR010000UK01
Trigger Event	Electronic Healthcare Record Request Completed	RCMR_TE030000UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	EHR Extract	RCMR_MT030101UK03

7 Message Definitions

This section describes each of the message types used amongst the various interactions. For each message type, links are provided to detailed documentation:

A diagrammatic representation of the message model;
A table view of each data field used within the message containing detailed guidance on how each field is populated together with examples;
The schema for the message type;
One or more example messages conforming to the schema and guidance.

7.1 EHR Request - RCMR_MT010101UK02

A message to convey a request for a patient's Electronic Healthcare Record. The request is made by a GP Practice when a patient registers with that Practice, and is sent to the GP Practice registered on the PDS for the patient at the time the new registration is made.

7.2 EHR Request Acknowledgement - RCMR_MT020101UK03

A message conveying an acknowledgement of receipt of a request for a patient's Electronic Healthcare Record. This message is intended to inform the requesting GP Practice that the request is being actioned where possible.

7.3 EHR Extract - RCMR_MT030101UK03

A message to convey a patient's Electronic Healthcare Record.

Additional detailed guidance on implementing this message is available. Click here to view.

8 Glossary of Terms

Data type	The structural format of the data carried in an attribute.
Data type flavour	A subdivision of a particular data type.
EHR	Electronic Healthcare Record
NCRS	NHS Care Record Service
OID	Object Identifier, a unique identifier e.g. used to identify coding systems.
PCT	Primary Care Trust, responsible for primary and community health services within a geographical boundary.
PDS	Patient Demographic Service
SDS	Spine Directory Services
Service User	A person who is registered on the PDS
DCE UUID	Universally Unique Identifier

9 Changes for V1.7

9.1 Changes to Specific Interactions

9.1.1 Electronic Healthcare Record Request Completed

The artefact identifier has changed from RCMR_IN030000UK04 to RCMR_IN030000UK05 due to changes to the payload.

9.2 Changes to Specific Messages

9.2.1 EHR Request

MIM-CR-0296: The tabular view text relating to Patient.id has changed such that the same OID is used to identify both Temporary NHS numbers and old format NHS numbers (as applied to PDS messages, relating to change request MIM-CR-0059). [Note that the artefact identifier is unchanged as no changes have been made to the message model.]

9.2.2 EHR Extract

MIM-CR-0146: The GP2GP specific AgentRole CMET has been returned to its original artefact identifier (i.e. changed from RCCT_MT120100UK01 to RCCT_MT120101UK01) to realign with the convention for message type naming used within the MIM.
MIM-CR-0235: The Author CMETs at Extract and Folder levels have been changed from Devices only to Agents.
MIM-CR-0274: Digital signatures for the Authors at Extract, Folder and Composition levels are not required to be carried and are no longer supported in the message.
MIM-CR-0296: The tabular view text relating to Patient.id has changed such that the same OID is used to identify both Temporary NHS numbers and old format NHS numbers (as applied to PDS messages, relating to change request MIM-CR-0059).
DACM-CR-54: Vocabularies which required mapping to SNOMED codes whenever other coding schemes were used no longer require this mapping (see the Message Vocabulary Index for details of the affected vocabularies).
The artefact identifier has changed from RCMR_MT030101UK02 to RCMR_MT030101UK03 to reflect changes to the model.
The 'EHR Request Acknowledgement - RCMR_MT020101UK03' example message has been changed to reference an upper case UUID.