Generic CDA
Domain Message Specification

Version: 2.2; Status: Final

Models

NHS HSCIC Constrained CDA Models

There are currently two constrained models used to constrain the structure of NHS HSCIC CDA instances. These are detailed below : For the correct usage of these artefacts refer to the latest version of "Technical Guidance for Implementation of Templated CDA Domains" this document will be under the associated specification tab in the baseline Domain Message Specification.

 

RMIMMif Schema
NPfIT CDA RMIM (POCD_MT000001UK04)
This model was originally developed for the NPfIT programme to constrain the structure of NHS HSCIC CDA documents flowing over TMS and/or stored in PSIS. Localisation has been applied to the model and to the schema to support the NHS HSCIC templating approach. Templated models specified in each domain may further constrain CDA documents for that domain. The NPfIT CDA generic model is a constrained version of the Balloted CDA model with localisation applied to the model and schema.
 View View View
NHS CDA RMIM (POCD_MT000002UK01)
This model has been developed to allow a more flexible approach to CDA when implemented using ITK or point to point on TMS for new post NPfIT message flows. This model is the balloted CDA model in CDA 2006 Release 2. Localisation has been applied to the schema to support the NHS HSCIC templating approach. Templated models specified in each domain may further constrain CDA documents for that domain. The NHS CDA generic model is a copy of the Balloted CDA model but has NHS HSCIC localisation applied to the schema only .
 View View View

Comparison of the Two NHS HSCIC Constrained CDA Models

This section details the most important differences between the two models and identifies the classes involved.
Class(es) NPfIT CDA RMIM - POCD_MT000001UK04 NHS CDA RMIM - POCD_MT000002UK01
Consent Removed Present View
NonXMLBody Removed Present View
Section.Subject Removed Present View
RegionOfInterest Removed Present View
ObservationMedia Removed Present View
ExternalObservation Removed Present View
ExternalProcedure Removed Present View
ExternalDocument Removed Present View

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 it is not possible to provide a replacement or if a document must be withdrawn then the document must be nullified.  A "nullify document" document should be used: further details of this type of replacement is contained in the Nullification Domain Specification, and illustrations are provided in the section below.

Recipient and Originator Responsibilities

The recipient and sender responsibilities stated this section are additional to the standard CDA recipient and originator responsibilities.

Recipient Responsibilities

Responsibility Details
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.
A stylesheet is included within the Domain message specification. Use of this stylesheet 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 (i.e. containing CDA entries it is unable to parse and interpret) it may choose to only render the document.
A recipient of a CDA document must be able to process the body of a CDA document sufficiently to be able to render it.
A recipient of a CDA document must render the structured body, and the label of each section as conveyed in the Section.title.
A recipient of a CDA document is only required to process CDA entries in that document which are applicable to the receiving system's conformance level: this may not be the complete set of CDA entries contained within the CDA body.
A recipient of a CDA document containing templates it is able to parse and interpret is required to validate the document against referenced templates.
A recipient of a CDA document containing CDA entries it is unable to parse and interpret is not required to process those CDA entries and should render the textual representation only.

Error handling

Error Example Scenario Example Error Resolution
An incorrect or invalid document is received. Document relating to John Smith is received with NHS Number for Jane Smith due to incorrect NHS Number being used by originator.

A recipient 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 when implemented over TMS or the relevant ITK specification when implemented over ITK.

Or:

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

Report received by GP; in the next consultation with patient GP discusses report and patient denies he had the care. This could occur where someone is treated in ED but uses someone else's identity.
Note - Application Acknowledgements are sent by the receiving application to originating systems for either notification of success or failure handling.

 

Originator Responsibilities

Responsibility Details
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 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.
Properly construct CDA structured Body The label of each section must be conveyed in the Section.title component.
An originator of a CDA document is only required to encode CDA entries applicable to the sending system's conformance level: the complete narrative might not be fully encoded in CDA entries.

 

Error handling

Error Resolution
An Originating system receives a "Nullify Document" document for a document it has sent. Originating system must Nullify the invalid document using the "Nullify Document" document. It should also nullify any local cache / copy as necessary.
An Originating system receives an Application Acknowledgement containing an error code from the code list for the domain given in the relevant External Interface Specification.

Originating system must:

Replace the invalid document with a new correct version.

Or:

Nullify 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.

 

Conformance and Development Tools

HSCIC provides some conformance and development tools in order to transform and check the validity of examples generated.

These are now downloadable from TRUD in the "Interoperability Specifications Tooling Pack"

TRUD can be accessed at http://www.uktcregistration.nss.cfh.nhs.uk/trud3/user/guest/group/0/home 

 .