Content

Change History

1 Overview

"Summary Care Record Phase 4 Implementation" includes Emergency Department Report and the associated communications between PSIS, secondary care and primary care. Patients may arrive in the Emergency Department by a number of means (for example: by ambulance, by referral from primary care, or by self referral). Their care needs are assessed and then they receive appropriate care provision, from one or a variety of clinicians within the ED. At the end of this, a decision is made as to their disposition, either by admission to a Secondary Care unit (attached to the ED or disparate) or they are discharged to primary care. At this point, a record of the care given by the ED is made, and communicated both to the patient’s GP and to the patient’s central health record (PSIS).

The CDA document definitions within this Implementation manual support the following care communications:

Emergency Department Report

Some types of information require the use of CRE-types whereas others prohibit the use of CRE-types - refer to the Implementation Guidance for Suppliers or PSIS Integration Strategy documents for the recommended use of CRE-types.

The CRE Section holds a list of ID's which are associated with the coded entries. The coded entries have a <reference> to the <content> in a text section which allows linking therefore enabling indirect association with a CRE-type. Refer to the latest version of "NPFIT-ELIBR-AREL-P1R2-0178 Technical Guidance for Implementation of Templated CDA Domains" for further information on how sections and entries are linked with text.

1.1 Domain Compliancy Statement

This CDA domain document utilised within this domain complies with the conformance statement from "HL7 Clinical Document Architecture, Release 2.0" (2006 Normative Edition), namely :

"A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains."

This CDA specifications described in this domain makes use of a templating mechanism that supports both entry-level and section-level templating. NHS CFH have implemented the HL7 guidelines for CDA and have included localisations to aid the navigation of the CDA document.

In the absence of any other machine enforceable templating constraint mechanism the NHS CFH approach is being pre-adopted.

1.2 Error Correction using CDA replacement

If a document is sent in error, then the sending system should send a replacement document with the correct information using CDA replacement update semantics.

Where this is not possible to use the above mechanism because no correcting document is available then the previous document is required to be nullified. A ‘nullify document’ document should be used and further details of this type of replacement is contained in the infrastructure domain.

Documents can also be withdrawn by a receiving system see section 6.1 for further details.

1.3 Use of templates

This domain uses templates, for further information on templates refer to the latest version of "NPFIT-ELIBR-AREL-P1R2-0178 Technical Guidance for Implementation of Templated CDA Domains"

2 Storyboards

This domain contains one storyboards:

Sally - Adult visiting emergency department

This may be found in the business documentation here.

3 Application Roles

The applications involved in the Emergency Department Report processes play specific roles. These, along with the interactions associated with each role, are identified below.

3.1 Emergency Department Report Originating System - POCD_AR160001UK02

The Emergency Department Report Originating System is responsible for sending the following Emergency Department interactions:

MUST always issue a 'PSIS Emergency Department Report ', with PSIS as a Primary Recipient.
MUST issue a 'Primary Recipient Emergency Department Report' to a recipient (or recipients) where the report contains an implied action for that recipient.
MAY issue a 'Copy Emergency Department Report' to a recipient where the report is for information or does not contain an implied action. The recipient should be a copy-to (tracker) recipient in this case

Primary Recipient Emergency Department Report

PSIS Emergency Department Report

Copy Emergency Department Report

The Emergency Department Report Originating System receives responses to the above interactions from the Receiving System.

3.2 Emergency Department Report Primary Receiving System - POCD_AR160002UK02

The Emergency Department Primary Report Receiving System receives and should indicate to the user that recommendations are contained in the document of the following Emergency Department interaction:

Primary Recipient Emergency Department Report

The Emergency Department Report Primary Receiving System receives and MUST act on the following Emergency Department interaction:

Nullify Emergency Department Report

Emergency Department Report Primary Receiving System initiates responses for the above interactions to the Emergency Department Report Originating System.

3.3 Emergency Department Report Receiving System (PSIS) - POCD_AR160003UK02

The Emergency Department Report Receiving System (PSIS) receives processes and stores the following Emergency Department interactions:

PSIS Emergency Department Report

The Emergency Department Report Receiving System (PSIS) receives and MUST act on the following Emergency Department interactions:

Nullify Emergency Department Report

The Emergency Department Report Receiving System (PSIS) initiates responses for the above interactions to the Emergency Department Report Originating System.

3.4 Emergency Department Report Copy Recipient - POCD_AR160004UK02

The Emergency Department Report Copy Recipient receives the following Emergency Department interaction:

Copy Emergency Department Report

The Emergency Department Report Copy Recipient receives and MUST act on the following Emergency Department interaction:

Nullify Emergency Department Report

The Emergency Department Report Copy Recipient initiates responses for the above interactions to the Emergency Department Report Originating System.

4 Trigger Events

4.1 Emergency Department Report - POCD_TE160001UK01

A Emergency Department Report trigger event indicates that a Emergency Department Report is ready to send from the originating system.

4.2 Emergency Department Report Nullify By Replacement - POCD_TE160002UK01

For the Emergency Department Report document to be nullified the trigger event is the realisation that the Emergency Department Report document was sent in error, in that it contained an error and should never have been sent and that no correct Emergency Department Report is available to send.

5 Interaction Diagrams

5.1 Emergency Department Report Interactions

Note - Application Acknowledgements are sent to originating systems for notification of successful or failure handling by the receiving application.

6 Interactions

Note:- For CDA domains the interactions are bound to the "NPfIT CDA generic model" and use the "NPfIT CDA generic schema" instead of the "NPfIT Domain CDA model schema".
The CDA Domain models are used for conformance checking of NPfIT templates after transforming the "Generic NPfIT CDA" instance to "NPfIT Domain CDA" instance.

The recipient and sender responsibilities stated in section 6.2 onwards are additional to the standard CDA recipient and originator responsibilities.

An NPfIT perspective of the standard CDA responsibilities are detailed within this section.

6.1 Recipient responsibilities

Assume default values where they are defined in this specification, and where the instance does not contain a value :

Where CDA defines default values, the recipient must assume these values in the event that no value is contained in a CDA instance.

Parse and interpret the complete CDA header :

A recipient of a CDA document must be able to parse and interpret the complete CDA header.
Because applications may choose to display demographic and other CDA header data drawn from a central master directory, the rendering of the CDA document header is at the discretion of the recipient.
An NPfIT style sheet is included within the MIM .Use of this style sheets is at the discretion of the recipient.

Parse and interpret the CDA body sufficiently to be able to render it :

Where a system receives a document outside of its conformance level it may chose to only render the document
A recipient of a CDA document must be able to parse and interpret the body of a CDA document sufficiently to be able to render it, using the following rendering rules:
The CDA structured Body, the label of a section, as conveyed in the Section.title component, must be rendered.
A recipient of a CDA document is not required to parse and interpret the complete set of CDA entries contained within the CDA body only those applicable to the receiving systems conformance level.
A recipient of a CDA document on receipt of a document equal to or less than it's conformance level is required to validate a CDA document against referenced templates.
A recipient of a CDA document on receipt of a document with templates higher than it's conformance is not required process those coded entries and should render the textual representation only.

Error handling

Possible Scenario

The GP recognises that reports sent to him about his patient is not actually his patient.

Example 1
Incorrect NHS number used by originator. Document arrives saying this is for John Smith, NHS #, DOB etc. Where the NHS# the GP system is for Jane Smith etc.

Example 2
Report arrives at GP, in the next consultation with patient GP discuss report with patient, who denies he had the care. How this could occur, if someone turns up to AE and uses someone else name, address, DOB etc.

A recipient on receipt of such a invalid / incorrect document may deal with errors by either

Sending an Application Acknowledgement to the originating system stating the error type using one of the error codes from the code list for the domain contained in the relevant External Interface Specification.

The receiving system may nullify the document using a "nullify document" document which MUST be sent to all recipients and the originating system.

Note - Application Acknowledgements are sent to originating systems for notification of successful or failure handling by the receiving application.

6.2 Originator Responsibilities

Properly construct CDA Narrative Blocks :

An originator of a CDA document must ensure that the attested portion of the document body is structured such that a recipient, adhering to the recipient responsibilities above, will correctly render the document.

The CDA structured Body:

The label of a section must be conveyed in the Section.title component.
The attested narrative contents of a section must be placed in the Section.text field, regardless of whether information is also conveyed in CDA entries. Attested multimedia referenced by URL in the narrative must not be carried in the document sent to PSIS.
An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body only those applicable to the sending systems conformance level.

Error handling

An Originating system on receipt of an Application Acknowledgement containing the one of the error codes from the code list for the domain contained in the relevant External Interface Specification should initiate a work stream to rectify any error by either

Replacing the invalid document with a new correct version

by nullifying the invalid document using the "Nullify Document" document which MUST be sent to all recipients.
It should also nullify any local cache / copy as necessary.

An Originating system on receipt of a "Nullify Document" document for any document it has sent, should initiate a work stream to rectify any error including nullifying any local cache / copy as necessary.

6.3 Primary Recipient Emergency Department Report - POCD_IN160001UK06

Communicates a Emergency Department Report to a primary recipient where the recipient is recommended to act upon information carried in the document.

Sending Role	Emergency Department Report Originating System	POCD_AR160001UK02
Receiving Role	Emergency Department Report Receiving System	POCD_AR160002UK02
Trigger Event	Emergency Department Report	POCD_TE160001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Emergency Department Report	POCD_MT160001UK06

Receiver Responsibilities

Reason

Interaction

On receipt of document

Application Acknowledgement

MCCI_IN010000UK13

The receiving system should replace any copy of the document stored or cached on the system on receiving a new version of a document.

6.4 PSIS Emergency Department Report - POCD_IN160002UK06

Communicates a Emergency Department Report to PSIS for processing and storage.

Sending Role	Emergency Department Report Originating System	POCD_AR160001UK02
Receiving Role	Emergency Department Report Receiving System (PSIS)	POCD_AR160003UK02
Trigger Event	Emergency Department Report	POCD_TE160001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Emergency Department Report	POCD_MT160001UK06

Receiver Responsibilities

Reason

Interaction

On receipt of document

Application Acknowledgement

MCCI_IN010000UK13

The receiving system should replace any copy of the document stored or cached on the system on receiving a new version of a document.

6.5 Copy Emergency Department Report - POCD_IN160003UK06

Communicates a Emergency Department Report to a copy recipient where the document is for information only and NO system action is defined.

Note :- if the receiving system does store , process or act on information contained in this document in any way, then it must process any replacement document received in a suitable manner.

Sending Role	Emergency Department Report Originating System	POCD_AR160001UK02
Receiving Role	Emergency Department Report Copy Recipient	POCD_AR160004UK02
Trigger Event	Emergency Department Report	POCD_TE160001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Trigger Event Control Act	MCAI_MT040101UK03
Message Type	Emergency Department Report	POCD_MT160001UK06

Receiver Responsibilities

Reason

Interaction

On receipt of document

Application Acknowledgement

MCCI_IN010000UK13

The receiving system should replace any copy of the document stored or cached on the system on receiving a new version of a document.

6.6 Nullify Emergency Department Report - POCD_IN160004UK06

Communicates the nullification (by replacement) of any Emergency Department Report sent to any recipient.

Must be sent to all information recipients (including trackers ).

Sending Role	Emergency Department Report Originating System	POCD_AR160001UK02
Receiving Role	Emergency Department Report Primary Receiving System	POCD_AR160002UK02
Receiving Role	Emergency Department Report Receiving System (PSIS)	POCD_AR160003UK02
Receiving Role	Emergency Department Report Copy Recipient	POCD_AR160004UK02
Trigger Event	Emergency Department Report Withdrawal	POCD_TE160002UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Trigger Event Control Act	MCAI_MT040101UK03
Message Type	Nullification Document	POCD_MT130001UK05

Receiver Responsibilities

Reason

Interaction

On receipt of document

Application Acknowledgement

MCCI_IN010000UK13

The receiving system must also nullify any copy of the document stored or cached on the system.

7 Message Definitions

7.1 Emergency Department Report - POCD_MT160001UK06

The Emergency Department Report informs the recipient that responsibility for the service user has been transferred and contains a summary of care events and care data.

7.1.1 Example for Scenario Sally (Adult visiting Emergency Department)

"The Information Examples and Example Messages published in this MiM have been validated both clinically and technically. An extended set of examples, produced in collaboration with suppliers and including rendering rules for all templates, will be published separately from this MiM."

8 Glossary of Terms

Application Acknowledgement	A response from one application to another indicating that a message has been received and is valid.
Application Role	The role played by the application in a particular interaction.
Data type	The structural format of the data carried in an attribute
Data Type Flavour	A subdivision of a particular data type
DCE UUID	Universally Unique Identifier
ED	Emergency Department. Previously known as Accident & Emergency
EHR	Electronic Healthcare Record
Legitimate Relationship	A Legitimate Relationship is a relationship between a clinician (or NHS organisation work group) and a patient, that gives the clinician, or workgroup member, certain levels of entitlement to access that patient’s health record maintained on National Systems.
NHS CRS	NHS Care Record Service
OID	Object Identifier, a unique identifier e.g. used to identify coding systems
Provider	An alternative term for a fulfiller
PCT	Primary Care Trust, responsible for primary and community health services within a geographical boundary.
PDS	Patient Demographic Service
PSIS	Personal Spine Information Service.
Requestor	The HCP responsible for the request
SDS	Spine Directory Service
Service User	A person who is registered on the PDS