Library

Browse and search developer information

Care Co-Ordination Interoperability

Adam Hatherly | 17 March 2013

What is electronic care co-ordination?

Care planning is a collaborative process carried out between a patient with complex or long-term care and support needs, and the professionals supporting them in managing those needs. It is an important part of the management of care for patients with long term conditions, and those approaching the end of their life. The electronic sharing of patient-centred care plans and preferences between care management systems used by an integrated neighbourhood team, and with the patient, provides an effective, efficient and economic way of delivering integrated care planning.

How can the NHS Interoperability Framework support care co-ordination?

The Interoperability Toolkit (ITK) is as set of national specifications, frameworks and implementation guides developed by Connecting for Health. See here for more details about ITK, including examples of how it can be implemented in systems.

There are also some specific ITK messages that have been developed to support care co-ordination:

Notifications

When a care plan or care preferences are recorded or updated in a system, there is a need to notify others involved in the care of the patient of this. This allows the receiving system to add a flag against their local patient record and support subsequent click-through or electronic retrieval of the actual content where this has been standardised.

As a general principle it is expected that ITK notifications will be sent “for information” to augment existing information flows, rather than replace existing clinical communications. There would generally be no explicit expectation of specific actions being carried out by the recipient of a notification, and this mechanism should not be used to transfer care, or to act as a referral to another care setting.

The notification message defined in ITK has been kept deliberately light-weight and is intended to inform other systems or individuals that an event has occurred of a specific type, and provide a means to request additional information if required. The specification includes the following pieces of information:

  • Date/Time of Event
  • Details of the Patient the event relates to
  • The type of event that has occurred (e.g. Care Plan Updated)
  • Details of the Organisation where the event occurred
  • Contact details of a person who has information about the event
  • Where the event relates to a document, an identifier and/or URL for the document
  • Details of who the notification has been sent to (where relevant)

Document Retrieval

Once a system has been made aware that a care plan or care preferences have been recorded in another system (i.e. because they have received a notification), it may want to retrieve the actual content to display locally, and potentially to update the local patient record. A “Get Document” message has been developed to facilitate this. This message is also applicable to a range of clinical documents, so is not limited to the exchange of care plans.

This message allows a system to use the identifier provided within a notification (see above) to request a copy of a document from a remote system. So, if a system was notified that a care plan had been updated, this message could then be used to retrieve the updated version of the plan.

Integrated Care and Support Plan

As part of the work done in the Health and Social Care Integration programme, a standard was developed for an Integrated Care and Support Plan. This is a standard CDA (Clinical Document Architecture) format document, which includes a range of information about a patients care, including:

  • Care Plan Summary
  • Care Plan Goals
  • Actions
  • Person Co-ordinating Care Plan
  • Care Plan Review Date
  • Individual Care Preferences
  • Individual Strengths
  • Situations that might lead to a deterioration
  • Individuals agreement for access to care plan
  • Crisis Plan
  • Additional Information

End of Life Care Preferences

The national end of life care programme have created an ISB standard for end of life care co-ordination, and are championing the development of Electronic Palliative Care Co-Ordination Systems (EPaCCS) for sharing end of life care preferences. Because the standard clearly defines the core data set for an EPaCCS record, this has been developed as a new ITK specification to allow this core content to be sent in a standard CDA (Clinical Document Architecture) format.

The data items in this message are taken from the ISB standard, with some additional information to allow for the recording of “provenance” for many of the key items (e.g. who recorded specific items and when).

How might these be used to co-ordinate care?

Lets take the example of EPaCCS (Electronic Palliative Care Co-Ordination) to show how these message interactions might support better co-ordination of care. This is only one example of how the messaging could be used, and there are other patterns which can also be considered.

Important Note: There is another article here which outlines other patterns which you could consider for this scenario (the below is referred to as the “Store and Notify” pattern in that article).

The EPaCCS will hold the end of life care information and preferences for patients within a locality. Whenever records are created, updated, or removed, a notification will be sent to other systems used by services providing care to patients in the locality. The identifier passed in this notification can then be used by a recipient system to issue an electronic document retrieval request for the document to the EPaCCS. The EPaCCS would then return the core content in an End of Life Care document. This is shown in the below sequence diagram: Send EPaCCS Document On Request

Supporting Information

  • You can find more details about these interoperability specifications here. This page contains more detailed requirements for the use of these messages, as well as recordings of the various WebEx meetings where the development of the specifications was discussed.
  • The actual specifications are available from TRUD here (at the time of writing they are listed in the “Specifications For Consultation or Draft Status” section).
  • Work is also ongoing on a simple Java library to help make working with these new messages easier. This library will allow you to populate the information into a simple set of Java objects, and the library will deal with converting this into the relevant HL7v3 payload. It can then also convert received payloads back into Java objects. At the time of writing the notification, document retrieval, end of life care and non-coded CDA messages are supported, with more coming soon. You can find more details here and get the code itself here.
  • In order to help with the actual sending and receiving of ITK payloads, a Java reference implementation has been created, which includes a fully working set of examples for various types of messages using ITK web services. There is also detailed documentation to support this – get started here.