Contents

 

Change History   

1    Overview

"Summary Care Record Phase 4 Implementation" includes discharge and the associated communications between PSIS, secondary care and primary care. The  CDA document definitions within this Implementation manual support the following care communications:

 

• Discharge 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.

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

 

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.

 

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 two storyboards:

• Mary - Maternity Discharge

• John - PICU Discharge

Both of these may be found in the business documentation here.

---

3    Application Roles

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

3.1    Discharge Report Originating System - POCD_AR150001UK02

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

• MUST always issue a 'PSIS Discharge Report', with PSIS as a Primary Recipient.

• MUST issue a 'Primary Recipient Discharge Report' to a recipient (or recipients) where the report contains an implied action for that recipient.

• MAY issue a 'Copy Discharge 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 Discharge Report    

PSIS Discharge Report       

Copy Discharge Report       

 

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

3.2    Discharge Report Primary Receiving System - POCD_AR150002UK02

 

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

 

Primary Recipient Discharge Report    

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

Nullify Discharge Report     

 

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

3.3    Discharge Report Receiving System (PSIS) - POCD_AR150003UK02

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

 

PSIS Discharge Report       

 

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

 

Nullify Discharge Report     

 

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

 

3.4    Discharge Report Copy Recipient - POCD_AR150004UK02

The Discharge Report Copy Recipient receives the following Discharge interaction:

 

Copy Discharge Report       

 

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

 

Nullify Discharge Report     

 

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

 

4    Trigger Events

4.1    Discharge Report - POCD_TE150001UK01

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

4.2    Discharge Report Nullify By Replacement - POCD_TE150002UK01

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

 

---

 

5    Interaction Diagrams

5.1    Discharge 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.

or

• 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

 or

• 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 Discharge Report - POCD_IN150001UK06

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

 

Sending Role	Discharge Report Originating System	POCD_AR150001UK02
Receiving Role	Discharge Report Receiving System	POCD_AR150002UK02
Trigger Event	Discharge Report	POCD_TE150001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Discharge Report	POCD_MT150001UK06

 

 

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 Discharge Report - POCD_IN150002UK06

Communicates a Discharge Report to PSIS for processing and storage.
 

Sending Role	Discharge Report Originating System	POCD_AR150001UK02
Receiving Role	Discharge Report Receiving System (PSIS)	POCD_AR150003UK02
Trigger Event	Discharge Report	POCD_TE150001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Discharge Report	POCD_MT150001UK06

 

 

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 Discharge Report - POCD_IN150003UK06

Communicates a Discharge 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	Discharge Report Originating System	POCD_AR150001UK02
Receiving Role	Discharge Report Copy Recipient	POCD_AR150004UK02
Trigger Event	Discharge Report	POCD_TE150001UK01
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Trigger Event Control Act	MCAI_MT040101UK03
Message Type	Discharge Report	POCD_MT150001UK06

 

 

 

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 Discharge Report - POCD_IN150004UK06

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

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

 

 

Sending Role	Discharge Report Originating System	POCD_AR150001UK02
Receiving Role	Discharge Report Primary Receiving System	POCD_AR150002UK02
Receiving Role	Discharge Report Receiving System (PSIS)	POCD_AR150003UK02
Receiving Role	Discharge Report Copy Recipient	POCD_AR150004UK02
Trigger Event	Discharge Report Withdrawal	POCD_TE150002UK01
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    Discharge Report - POCD_MT150001UK06

The Discharge 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    Examples for Scenario Mary - Maternity Discharge     

Mary's Discharge report        

 

7.1.2    Examples for Scenario John - PICU Discharge        

John's Discharge report        

 

"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 CareTrust, 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