Skip to main content

Social care DMS - additional messaging guidance

This guidance covers assessment, discharge and withdrawal notices between hospitals and social services.

Introduction

Purpose

The purpose of this document is to provide additional guidance to support the implementation of the HL7 FHIR message specifications that have been developed for Assessment, Discharge and Withdrawal (ADW) Notices.

The document should be read in conjunction with the Social Care Domain Message Specification (DMS)1 and the SCCI2075 – Assessment, Discharge and Withdrawal Notices between Hospitals and Social Services Information Standard.

The document provides supplementary information covering the implementation and use of the ADW FHIR messages and also describes a number of divergences from the ADW Information Standard. It is anticipated that the document will evolve based on feedback received from implementers.

Background

Currently hospitals must determine when it is safe to discharge a patient. Part of that decision making process requires hospital staff to determine whether a care and support assessment is required before the patient leaves hospital care (so appropriate social care can be put in place to support the citizen on exit from hospital). If hospital staff believe that an assessment is required, they must notify the local authority’s social services team.

The Care Act 20143 specifies a minimum data set for inclusion in that notification process, requiring hospitals to use:

  • ssessment notices - this informs the social services team that an assessment will be required, with expected discharge date, if known
  • discharge notices - confirms discharge date to social services
  • withdrawal notices - to withdraw either or both of the above

The purpose of the Notices is to ensure a timely care and support assessment is triggered, and that information required by the social services team is received to facilitate this.

The ADW Information Standard defines the minimum data set that must be used for each type of notice. It also defines a Notice Receipt/Response data set that must be used to send an acknowledgement of a received notice from the social services team to the hospital.

Each type of ADW Notice is defined as a separate FHIR message specification. There are also separate message specifications for each ADW Notice Response type. For each type of notice there is one version for accept responses and one version for reject responses. 

The full list of supported messages is as follows:

  • assessment notice
  • assessment notice accept response
  • assessment notice reject response
  • discharge notice
  • discharge notice accept response
  • discharge notice reject response
  • withdrawal notice
  • withdrawal notice accept response
  • withdrawal notice reject response

Implementation notes

ADW Information Standard Compliance

Section 4 of the ADW Information Standard Requirements Specification4 defines the minimum data set that must be supported to comply with the standard. Data items that are defined as ‘Optional’ or ‘Required’ in the standard must still be implemented but may be optionally provided when the data sets are used.

Additional data items may be added locally to the data sets defined in the Information Standard, subject to agreement between the relevant organisations. However the data items defined in the Information Standard must not be omitted, nor their attributes (such as whether the data item is mandatory or how it is formatted) be changed. Doing so will render the data set non-compliant with the Information Standard.

CareConnect Profiles

The ADW FHIR specification uses several generic profiles, defined as part of the CareConnect initiative. These profiles contain a number of optional data elements and associated valuesets that are not required to be implemented to comply with the ADW Information Standard.

ADW Information Standard / FHIR Element Mapping

The ADW FHIR specification includes a mapping between the ADW information standard data set and the corresponding messages. The mapping is included in the ‘Bundle’ resource definition for each message. The ADW information standard data items are listed in the ‘REQUIRED DATA FIELD’ column and the corresponding message elements are in the ‘FHIR PROFILE ELEMENT’ column. For example, this is an extract of the mapping for the Assessment Notice message:

An extract of the mapping for the Assessment Notice message

General cardinality rules

Unless specified in this guidance document, implementers should apply the cardinality rules defined in Section 4 of the ADW Information Standard Requirements Specification.

Addresses – Cardinality Divergence

The ADW Information Standard specifies that in Patient Address, line 2 is mandatory and all other address lines are optional:

Image of how address fields should look
In the ADW FHIR specification, all address lines are specified as optional. Local systems should include validation to ensure that a minimum of Address Line 1 or Address Line 2 is provided. In line with standard FHIR rules, empty address lines (e.g. <line value=""/>) are not permitted.

ODS Codes – Cardinality Divergence

The ADW Information Standard specifies that the following data items are optional:

  • Hospital Organisation Site Code (all Notices)
  • Local Authority Organisation Code (all Notices)

In the ADW FHIR specification, the equivalent data elements are used to represent the source and destination endpoints within the MessageHeader resource and are therefore defined as mandatory.

Interpreter Required – Code Value Divergence

The ADW Information Standard specifies that the following code values must be used for the Interpreter Required Indicator (Assessment Notice):

  • N (no)
  • Y (yes)

This data item is implemented in the ADW FHIR specification using Patient.nhsCommunication.extension which supports the following Boolean code values:

  • false (no)
  • true (yes)

Where required, implementers should adopt appropriate rules to map between the two sets of values i.e. where a message-based ADW system interacts with a non message-based system or process. 

Withdrawal Type – Code Value Divergence

The ADW Information Standard specifies that the following code values must be used for Withdrawal Type (Withdrawal Notice):

  • 1 (Assessment Notice)
  • 2 (Discharge Notice)
  • 3 (Assessment Notice and Discharge Notice)

This data item is implemented in the ADW FHIR specification using MessageHeader.event.code which supports the following code values:

  • 1078011000000107 (Withdraw Assessment Notice Only under the Care Act 2014 Schedule 3)
  • 975851000000104 (Withdraw Discharge Notice Only under the Care Act 2014 Schedule 3)
  • 975841000000102 (Withdraw All Notices under the Care Act 2014 Schedule 3)

Where required, implementers should adopt appropriate rules to map between the two sets of values i.e. where a message-based ADW system interacts with a non message-based system or process.

Additional Data Items

The following data items are not included in the ADW Information Standard but have been added to the ADW FHIR specification to provide additional flexibility. All of the data items allow the entry of free text and are included in the Assessment Notice:

  • Safeguarding Concerns (Details) – QuestionnaireResponse.group.question.answer
  • Reason For Referral – ReferralRequest.reason
  • Additional Details – ReferralRequest.description

DocumentReference.content.attachment.title

The ADW FHIR specification supports the ability to embed supporting documents (e.g. binary encoded PDF files) to notices using the DocumentReference FHIR resource. Within the context of ADW, the DocumentReference.content.attachment.title data item is used to carry the physical file name of the embedded document. This is a non-standard use of this data element.

Linking Associated Notices

The ADW FHIR specification supports the ability to link associated notices using the methods described below.

Linking a Set of Related ADW Notices

To link a set of related ADW Notices, ReferralRequest.identifier should be set initially for the Assessment Notice and the same value should then be carried forward into the subsequent Discharge Notice and Withdrawal Notice (if applicable). For example:

Assessment Notice:

Image of assessment notice for linking a set of related ADW notices

Discharge Notice:

Image of a discharge notice

Linking a Notice Response to the Originating Notice

To link a Notice Response to the originating notice, MessageHeader.id in the original notice should be used to populate MessageHeader.response.identifier in the Notice Response message. For example:

Assessment Notice:

Image of assessment notice for linking a notice response to the originating notice

Assessment Notice Accept Response:

Image of assessment notice accept response

To minimise the risk of duplicate identifiers occurring, it is recommended that globally unique identifiers such as UUIDs are used to link associated notices.

Download

Last edited: 5 April 2019 8:25 am