QIPP Digital Technology - NHS Networks · 2012-03-29 · Quality, Innovation, Productivity and...

QIPP Digital Technology

© Crown Copyright 2012 of 71

Technical Approaches for Sharing Care Plans

Author: Adam Hatherly Date: 27

th March 2012

Version: 1.0

Technical Approaches for Sharing Care Plans V1.0


Amendment History:

Version Date Amendment History 0.1 06/03/2012 First draft for comment

0.2 15/03/2012 Updated with internal review comments

1.0 27/03/2012 Updated with external review comments

Contents

1. Purpose .............................................................................................................. 3 1.1. Scope .......................................................................................................... 3 1.2. Intended Audience ...................................................................................... 4 1.3. Document Conventions ............................................................................... 4 1.4. Disclaimer ................................................................................................... 5

2. Background ........................................................................................................ 6 2.1. Long Term Conditions Workstream ............................................................. 6 2.2. End of Life Care Workstream ...................................................................... 6 2.3. QIPP Digital Technology Team ................................................................... 7 2.4. Approach for the development of this guidance ........................................... 7

3. Summary ............................................................................................................ 8 4. Business Context ............................................................................................... 9

4.1. What is a Care Plan? .................................................................................. 9 4.2. Types of Care Plan ..................................................................................... 9 4.3. Care settings and Teams .......................................................................... 12 4.4. Care Plan Co-Ordination ........................................................................... 13 4.5. Supporting information .............................................................................. 14 4.6. Example Business Scenarios .................................................................... 18

5. Technical Interoperability Guidance ................................................................. 25 5.1. Overview ................................................................................................... 25 5.2. Summary Table ......................................................................................... 26 5.3. Architectural Patterns ................................................................................ 27 5.4. Existing Interoperability Toolkit (ITK) Specifications .................................. 40 5.5. Possible Future Interoperability Opportunities ........................................... 43 5.6. Implementation Considerations ................................................................. 44 5.7. Pattern Maturity ......................................................................................... 52

6. Mapping Patterns to Business Scenarios ......................................................... 53 6.1. GP Refers to a Community Team for Care Planning ................................. 53

7. Using the Interoperability Toolkit (ITK) ............................................................. 56 7.1. Introduction to ITK ..................................................................................... 56 7.2. What clinical domains are currently supported .......................................... 57 7.3. Accreditation ............................................................................................. 57 7.4. Technology Reference data Update Distribution (TRUD) .......................... 58 7.5. Implementation Support ............................................................................ 58

8. Wider Context and Supporting Resources ........................................................ 60 8.1. Clinical Content ......................................................................................... 60 8.2. International Standard ............................................................................... 61 8.3. National Year of Care Programme ............................................................ 61 8.4. Professional Guidance .............................................................................. 62 8.5. QIPP Support ............................................................................................ 63

9. Recommendations ........................................................................................... 65 9.1. Review Best Practice ................................................................................ 65 9.2. Business Requirements ............................................................................ 65 9.3. Technical Requirements ............................................................................ 65 9.4. Delivery ..................................................................................................... 65

10. References ................................................................................................... 66 11. Glossary of Terms ........................................................................................ 68 12. Appendix A – Example Rendered HSCI Integrated Care and Support Plan .. 69



1. Purpose The purpose of this document is to provide a high level “framework” to help local teams understand the various approaches for the electronic sharing of care plans. It will outline the business context for the ways that care plans are shared, and with whom. It will also explore the types of care plans, and the other supporting information that needs to be in place alongside care plans to allow health and care professionals, patients and carers to understand, develop and maintain care plans. It will then present a range of technical approaches or “patterns” that can be used to help shape an interoperability solution that fits with the business needs and desired business processes. It will show how this can be supported by existing and/or potential future interoperability toolkit (ITK) specifications. There is no single prescriptive solution for how care plans should be shared, but this document should help support teams in developing a local approach, and provide the relevant pointers to specifications and services that can support the delivery of that approach.

1.1. Scope

For any technology solution to be implemented within a healthcare setting, a wide range of areas need to be considered. This document is not intended to cover every aspect of the delivery of a solution. The below diagram gives a general overview of some of the areas you may need to consider – the areas that are addressed (at least in part) in this document are shown in green:

This document focuses on the general approaches for the electronic sharing of care plans, and therefore does not cover the actual content of care plans in any depth. There is however a brief discussion about content in section 8, “Wider Context”. A care plan is considered a part of the patient record, and is therefore subject to all the same information governance controls for access control, record retention, etc. These considerations are not specific to care plans, so will not be discussed in any depth in this document. The document focuses primarily on the scenarios relating to long term conditions and end of life care, although it is recognised that the sharing of care plans is also a requirement in other contexts (e.g. maternity services, children‟s services, etc).

Service

ManagementChange

ManagementClinical

Safety

Benefits

Realisation

Procurement /

Contract Mgmt

ImplementationProfessional

Guidance

Functional

Requirements

Non-Functional

Requirements

Information

GovernanceInfrastructure

Security

Accreditation /

Assurance

ISB

StandardsClinical Coding

/ Terminology



These other contexts are likely to being other considerations that have not been considered in the drafting of this document. The technical approaches are likely to be the same however, and could be applied in other contexts as longs as the relevant scenarios and associated considerations are identified and addressed.

1.2. Intended Audience

The first part of this document outlines the business context for the electronic sharing of care plans, and identifies the types of care plans that might need to be shared. This part of the document is likely to be of interest to a range of both technical and non-technical readers, and is aimed at shaping a common understanding between these groups. The latter sections of the document are more technical in nature, so will be primarily of interest to local technology/informatics teams, and also to suppliers supporting those teams to deliver local solutions. The final recommendations section 9 is relevant to all readers, and summarises the suggested steps for implementing the guidance in this document.

1.3. Document Conventions

In order to aid clarity, a number of conventions have been followed in this document. Where additional sources of information are referenced in the text, a reference number will be provided linking it with the appropriate entry in the references section 10 at the end of this document – e.g. [Ref:1]. Diagrams will be labeled with a figure number and name beneath the image – e.g.: Figure 1: Diagram Description

Business Scenarios will be shown in Green1 – e.g.:

Scenario Name

Description

Architectural Patterns will be shown in Blue – e.g.:

Pattern Name

Description

Implementation Considerations will be shown in Red – e.g.:

Implementation Consideration

Description

Existing Interoperability (ITK) Specifications will be shown in Yellow – e.g.:

Specification Name

Description

Potential Future Interoperabilty (ITK) Specifications will be shown in Grey/Purple – e.g.:

Specification Name

Description

1 Note: Colour is used for aesthetic purposes only.



1.4. Disclaimer

Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NHS Connecting for Health. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment. A correctly completed risk assessment enables an NHS organisation to demonstrate that a methodical process has been undertaken which can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes. This means that changes implemented following this guidance are done so at the implementers‟ risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer.



2. Background Quality, Innovation, Productivity and Prevention (QIPP) is a large scale transformational programme within the NHS, involving all NHS staff, clinicians, patients and the voluntary sector [Ref:1]. It will improve the quality of care the NHS delivers whilst making up to £20billion of efficiency savings by 2014-15, which will be reinvested in frontline care. At a regional and local level Strategic Health Authorities have been developing integrated QIPP plans that are supported by national QIPP workstreams which are producing tools and programmes to help local change leaders in successful implementation.

2.1. Long Term Conditions Workstream

The Long Term Conditions (LTC) workstream, led by Sir John Oldham, seeks to improve clinical outcomes and experience for patients with long term conditions in England by focusing on improving the quality and productivity of services for these patients and their carers so they can access higher quality, local, comprehensive community and primary care [Ref:2, Ref:3]. This will in turn, slow disease progression and reduce the need for unscheduled acute admissions by supporting people to understand and manage their own conditions. The workstream seeks to reduce unscheduled hospital admissions by 20%, reduce length of stay by 25% and maximise the number of people controlling their own health through the use of supported care planning. The workstream aims to replicate this performance nationally by 2013/14. There are three key drivers for achieving these objectives:

Risk Profiling

Integrated Neighbourhood Care Teams

Shared decision making and self care The above is underpinned by the relevant health and social care professionals and the patient themselves having access to relevant information about their condition and how it is being managed. The electronic sharing of “care plans” is a key piece of this, which this document addresses.

2.2. End of Life Care Workstream

The End of Life Care Work-stream [Ref:4], along with the National End of Life Care Programme [Ref:5], are both working to improve the care provided to patients who are approaching the end of their life. The majority of people, given the right care and support, would prefer to die at home, yet only around 20% of people die at home, with a further 17% dying in a care home. The Healthcare Commission estimates that half of all acute hospital complaints are related to end of life care. For people nearing the end of life, the National End of Life Programme and QIPP End of Life Workstream aim to reduce:

Emergency attendances to hospital

Subsequent bed days

Unwanted treatments

Complaints relating to end of life care A key enabler for the above goals is capturing and sharing a patient‟s end of life preferences. These preferences are generally captured in an end of life care plan



(see section 4.2 for an outline of the various types of care plan), and so this document is also relevant to the sharing of this type of care plan.

2.3. QIPP Digital Technology Team

QIPP Digital Technology has been established as a function under the QIPP programme to assist QIPP national workstreams and local teams to exploit digital technology in order to accelerate delivery of their QIPP priorities [Ref:6]. The function focuses on helping to overcome digital challenges and barriers, to accelerate delivery, to spread initiatives and to maximise the potential value from technology enabled healthcare delivery.

Figure 1: QIPP Digital Team Approach

A core principle of this operating model is to ensure that any work conducted or national enablers provided, have direct traceability back to key business drivers, and that work is only undertaken where there is a local „pull‟ for national assistance.

2.4. Approach for the development of this guidance

In late 2011, Sir John Oldham sent a letter to the local QIPP LTC teams, asking for expressions of interest in digital technology support [Ref:35]. Thirteen local teams responded to this letter, and the QIPP Digital Team had follow-up discussions with each of the teams to better understand the digital opportunities, and the support they required to help them overcome the technology barriers they faced. As a result of this consultation, a number of areas were identified as candidate digital technology “national enablers”. One of these enablers was guidance around ways of electronically sharing care plans between professionals, and also potentially with the patient themselves. The QIPP Digital team had some more detailed follow-up discussions with six of the local teams, to get a more detailed understanding from both a clinical and technical perspective of the guidance required. This more detailed consultation has informed the content of this report. The guidance is therefore focused on the specific needs of those teams, on the basis that they are a representative snapshot of the challenges being faced across the country by other LTC teams.

Business Drivers

Digital Opportunities

Alignment with Local/National

Informatics Activities

National Enablers

Engage with

National

Workstreams/

Sub-national teams on

key priority areas

Co-identify digital

opportunities to

support priority areas

Bridge digital

opportunities with local

informatics activities

and national servicesFocus on national

enablers to support

delivery by local teams



3. Summary This document summarises information gained through discussions with local QIPP LTC teams, as well as other national groups engaging in work on care planning and the sharing of care plans. The objective is to present a “framework” to help local teams understand the various approaches for the electronic sharing of care plans, and how existing interoperability standards can be used to implement solutions following these approaches. There is no standard definition of a “care plan” but it is accepted that a care plan relates to a single individual and supports future care for that patient. There are five high level types of care plan used today in local organisations:

Personalised Care Plan

Treatment Plan

Support Plan

End of Life Care Preferences

Escalation Plan A care plan cannot exist in isolation, and requires additional supporting information alongside it to support creating, reviewing and updating of the plan. This might typically include demographics, previous encounters, medications, diagnoses, etc. There are a number of approaches to designing a system architecture for the sharing of care plans, and these approaches can be broken down into three areas:

1. Discover / Locate Care Plans: In order to be able to review or update a care plan for a patient, you first need to establish whether a care plan exists, and where it is held.

2. Sharing / Accessing Care Plans: Once the location of any relevant care plans has been established, there are a number of approaches for gaining access to the care plans of a patient.

3. Managing Changes to Care Plans: Once a care plan has been shared, there are a number of approaches that can be taken for managing changes to the care plan.

A number of “architectural patterns” that can be applied for each of the three areas above are outlined in detail in this document (section 5.3), along with some associated implementation considerations (section 5.6) and examples of how the patterns might be implemented (section 6). The NHS Interoperability Toolkit (ITK) provides a set of specifications which can be used to support integration and electronic messaging between systems (section 5.4). This document provides some guidance on how these specifications might be used, and the support that is available for implementing these (section 7). A number of potential future ITK specifications are also proposed (section 5.5). The wider context around care planning also needs to be considered as part of a local roadmap – including considerations around standardising the clinical content and clinical coding within care plans, as well as the development of professional standards to support this content (section 8). The document concludes with a series of recommendations for how to take the guidance provided (section 9), and apply it to local developments and solutions. This includes reviewing existing best practice, mapping out the business requirements, understanding the technical requirements, and engaging relevant parties to support delivery.



4. Business Context

4.1. What is a Care Plan?

There are no standardised or agreed definitions for what a “care plan” actually is, but for the purposes of this document, we will define a care plan in broad terms as a document2 that has the following attributes:

It relates to a single individual

It supports future care for an individual

It aids decision making about future care

It may also record decisions made about care There are a number of things that a care plan is not:

An electronic patient record (although the care plan is part of the overall electronic patient record for a patient).

A record of all activities and encounters a patient has with services

A personal health budget

Detailed “measurements” (either manual or from a Telehealth device)

eConsultation (although care planning activities may be delivered over an electronic channel in some cases)

A care “pathway” Many of the above could be considered “supporting information”, required to create and maintain a care plan, but they are not a plan in themselves. There is more discussion of supporting information later in this document.

4.2. Types of Care Plan

Whilst this document does not focus on the specific content of the care plans being shared, it is useful to understand the various different types of “care plans” that are being used to support patients with long term conditions. There are no standardised or agreed definitions for the types of care plans, so we will start with a break-down of the types of plans that were identified by the local teams during our discussions. In some cases, teams use combinations of these types of plans together, for example the “personalised care plan” may in some cases incorporate a “treatment plan”.

Figure 2 - Types of Care Plan

These broad categories are a generalisation, and all these kinds of plans will often be of use in other care settings also. It is important for the integrated team managing the patient, as well as the patient‟s GP, to have a view of all plans relating to the patient.

2 The term document here relates to a collection of information for a specific purpose – it may

not necessarily exist as a single “document” in practice within the systems that hold it.



4.2.1. Personalised Care Plan

Variations / Also known as:

Integrated Care Plan

LTC Care Plan The Personalised Care Plan is the primary focus for most of the long term conditions teams, as it is a key component underpinning the work done by integrated neighbourhood teams3, as well as for informing the patient and supporting them in managing their condition. During discussions with the local teams, but also incorporating inputs from the long term conditions national workstream team members, a definition, or set of attributes, was formed of what a personalised care plan should be:

It is the output of a collaborative “care planning” process, which aims to maximise the patient's capacity to self-care

All patients with one or more long term conditions should have one

There is only one per patient, and it is personalised and specific to that patient

It shows the overall plan for the care of that patient – all specialties and all support needs4

It is not just about clinical interventions, but also covers both clinical and personal goals

It should be structured around a minimum core set of information: o “Problems5” (e.g. Diabetes, COPD) – each with:

“Needs” (e.g. Blood Glucose Management) – each with:

“Goals” (e.g. Blood Glucose Normal) – these must be meaningful to the patient. These may be separated into “Clinical Goals” and “Personal Goals”.

“Activities” (e.g. Review Medication, Refer to Dietician) – may be linked to Goals

It should be created and updated in consultation with the patient

The patient (or carer) should have access to it, and be able to understand it

The patient should be able to add to and update aspects of the plan themselves

There may be other more detailed care plans held in other systems (e.g. An acute care plan in a hospital), but the personalised care plan should give the overall summary view of activities for managing the patient‟s condition(s).

There are other types of care plan listed below, which are not in themselves part of the personalised care plan, but may inform that plan, and may indeed be “linked” or “signposted” from the personalised care plan. The Diabetes “Year of Care” programme developed a diabetes care planning process, with associated care plan templates, which are an example of this type of care plan (albeit currently specific to a single condition). See section 8.3 for more details. In attempting to provide a complete holistic view of care for a patient, there is a danger that the plan ends up either unsuitable for the patient to use (i.e. it is too complicated), or unsuitable for staff (not detailed enough). Getting the right balance is

3 For a definition of “Integrated Neighbourhood teams” see the LTC Network Site [Ref:9]

4 Sometimes referred to as “Biopsychosocial”

5 Within ISO 13940 this is referred to as “Health Issue” rather than “Problem” – see section

8.2 for more details of the international standard.



important, and the ability to provide different “views” (or “filters”) of the care plan information targeted at different audiences is likely to be something that local teams will need to consider to overcome this.

4.2.2. Treatment Plan


Nursing Plan

Acute Care Plan

Intervention Plan This is a clinically driven plan, covering:

Prescribed procedure, therapy or medication for a certain condition

May include goals and actions, but these are generally clinical activities only Some aspects may be included in the personalised care plan if the patient will be carrying out treatments themselves.

4.2.3. Support Plan


Social Care Plan This is a plan created by social care teams, and is generally driven by the output of formal assessments as part of a common assessment framework. It is often linked to a personal budget that supports the individual‟s support needs. In the longer term it is important that this information is also incorporated in some form into the personalised care plan to ensure that this provides an overall view of care and support for the patient.

4.2.4. Escalation Plan


Anticipatory Care Plan

Exacerbation Plan

Crisis Plan

Emergency Care Plan These often overlap or are combined with the treatment plan and/or the end of life care preferences, and are intended to help support the patient in managing potential future events relating to their condition(s). It may cover:

What to do when the patient‟s condition deteriorates, and may include instructions for emergency care professionals (e.g. paramedics)

Symptoms to look out for, additional medication or actions to take to manage the exacerbation.

Treatment advice for the patient. For example, for Asthma it may give advice on when to increase inhalers, and for Diabetes it may give individual guidance regarding changing insulin doses depending on blood sugar reading/meal types and activity planned.

“Normal” values for patient readings (Pulse, Blood Pressure, etc)

Contact details for carers, next of kin, and emergency clinical contacts In some cases the “emergency care” elements may be separated from the general patient advice around possible exacerbations. There are some aspects of this kind of plan that may need to change rapidly if a patient starts to deteriorate, and it is important that unscheduled care services have up-to-date information to support any emergency situations.



4.2.5. End of Life Care Preferences


Advance Care Planning

Electronic Palliative Care Plan Captures details about a person‟s preferences regarding their care at the end of their life. An ISB standard exists [Ref:7] which covers the core clinical content of end of life care plans. Wherever possible, any system capturing end of life care plans should do so in accordance with the core content outlined in this standard. The core content detailed in the standard comprises information about:

The person

Those delivering care

End of life care preferences and choices

End of life care decisions. This plan may need to change rapidly if a patient starts to deteriorate, and it is important that unscheduled care services have up-to-date information to support any emergency situations. More generally, “Advanced Care Planning” is a voluntary process of discussion and review to help an individual who has capacity to anticipate how their condition may affect them in the future and, if they wish, set on record choices or decisions relating to their care and treatment so that these can then be referred to by their carers (whether professional or family carers) in the event that they lose capacity to decide once their illness progresses. Under the terms of the Mental Capacity Act 2005 [Ref:8] formalised outcomes of advance care planning might include one or more of the following:

Advance statements to inform subsequent best interests decisions;

Advance decisions to refuse treatment which are legally binding if valid and applicable to the circumstances at hand;

Appointment of Lasting Powers of Attorney („personal welfare‟ and/or „property and affairs‟).

4.3. Care settings and Teams

4.3.1. Integrated Neighbourhood Teams

The sharing of care plans is a key enabler for the creation of integrated neighbourhood teams. In many cases these teams already exist (or are being formed) and are having to rely on manual sharing of information. This is often achieved by physically coming together for a review meeting where the relevant information about the patients in their caseload is shared and reviewed. Whilst this works well, it does limit the amount of information that can be shared (i.e. it is only what the participants bring to the meeting), and the sharing is limited to the times when the group can come together. The participants/roles that typically make up an integrated team include:

GPs and Practice Nurses

Community Matrons

District Nurses

Specialist Nurses

Social Care Workers

Therapists



Hospice Staff In some cases, this extends into other areas – although these wider participants are often only involved as and when required:

Mental Health Teams

Consultants

Other Nursing and AHP teams

3rd Sector Teams

Other supporting areas such as Housing, Employment, Benefits, etc. The composition of the integrated teams will be driven by the needs of the local population, but should ideally include all the services required to provide for the care and support needs of patients. More guidance on integrated care teams, along with examples of approaches taken in various parts of the country can be found on the QIPP LTC NHS Networks site [Ref:9].

4.3.2. Unscheduled and Emergency Care

Others who are likely to have a need to access care plans for a patient are unscheduled / emergency care providers – e.g.:

A&E

Ambulance Services

Out of Hours GP Services This is especially pertinent for escalation plans and end of life care preferences, but having access to all the care plans for a patient is desirable in many cases to ensure the best information is available to support care.

4.3.3. Non-NHS Organisations

There are some other specific technical considerations when non-NHS organisations (e.g. Local Authorities and 3rd Sector organisations) are involved in the sharing of care plan information. This is likely to be a growing need, as more types of provider organisation are engaged to provide care for patients. There are examples of social enterprises outside the NHS taking on the provision of services to NHS patients in competition with existing services in Acute trusts, and this is likely to grow over time. Third sector organisations often provide services to support patient self-management activities, and there is a need to be able to share outcome information from these services which can feed back into care planning discussions, and to commissioners. A key consideration for such organisations is the identifier used for patients. NHS numbers are used within NHS services to identify patients, but there are technical challenges in using the NHS number outside NHS organisations. These issues are explored in more detail in the “Implementation Considerations” section 0 later in this document.

4.4. Care Plan Co-Ordination

4.4.1. Caseload Management

The caseload of the integrated teams is usually driven by GPs and other clinicians identifying patients who they feel are at high risk. Increasingly, this is being supported by the use of risk data about the local population, usually gathered though the use of risk profiling tools. Where such tools do not exist, these teams may rely on referrals from other care settings. Guidance on the use of risk profiling tools, along with examples of their use can be found on the QIPP LTC NHS Networks site [Ref:10].



The QIPP Digital Technology team has also published some detailed technical guidance that can help teams to understand the concepts involved in a risk stratification (or “predictive modelling”) solution, and gives advice on how to select (or build) an appropriate tool [Ref:6]. An approach that has been used very successfully in some teams is to have a “key worker” or primary contact for each patient on the integrated team‟s caseload. This provides a single point of contact for the patient, and can help act as an advocate for the patient and help them to understand the various services that are available to help them manage their condition. This does not necessarily have to be a clinician – indeed in Outer North East London, a specific non-clinical role of “Integrated Care Liaison Officer” has been created to provide this point of contact for patients. A job description for this role is available on the QIPP LTC NHS Networks site [Ref:11].

4.4.2. Management of Shared Care Plans

If care plans are to be shared amongst members of the integrated team, and also with other care and support providers, it is important to agree the basic principles around who will create, read, update, and potentially “archive” plans. In many cases it is preferable for all parties in the integrated team to be able to create, read and update plans. In other care settings (e.g. unscheduled and emergency care), read-only access to care plans may be sufficient. This may differ for different types of care plan – for example, it may be useful for an out of hours GP to be able to update an escalation plan, but maybe not a personalised care plan. These basic principles should be agreed locally to match the responsibilities of the various teams involved in patient care.

4.5. Supporting information

Care Plans cannot exist in a vacuum – reviewing or updating a care plan needs to be informed by supporting patient information. Many local teams are looking to use a clinical and/or patient “portal” to achieve this, and to provide a single shared “record”, which generally incorporates a variety of patient information “pulled” from clinical systems, or “pushed” via regular extracts. In some cases where a single clinical system is already used across a number of care settings, teams are looking at using this existing clinical system as the primary “shared record” to support care planning.



Figure 3 - Shared Records to Support Care Planning

In some cases other supporting information such as demographics, or contact details for people involved in the care of the patient are also included in the care plans. This is often necessary if there are no other mechanisms for the sharing of this supporting information with the wider care team (and the patient). Where it is possible, bringing this supporting information together in some form of shared record (e.g. a “portal”) is preferable, as it allows changes to that information to be managed separately from updates to care plans. In most cases the supporting information is already held in clinical systems, to incorporate this into care plans would mean replicating the information, which increases the risk that it could become out of date (which could pose potential clinical safety risks). Generally, access to a view of the patient‟s record (or at least a summary of it as described above) is essential in ensuring the care planning process is able to function effectively.

4.5.1. Demographics

A key piece of information about a patient is the patient‟s demographics. The authoritative source of demographic information in the NHS is the national Personal Demographics Service (PDS) [Ref:12], but there are a number of approaches that can be taken for getting accurate demographic information for patients. In many cases, data in the shared record will come from clinical systems which are already integrated with PDS, so demographic details from those source systems can generally be used directly. In order to guarantee up-to-date demographics are used in the shared record, data from PDS can be retrieved electronically using a standard messaging API over the “Spine” [Ref:13]. Suppliers wishing to use these interfaces would need to be assured under the Common Assurance Process (CAP) [Ref:14], which can be a time consuming process. Another service which can be used is the Demographics Batch Service (DBS) [Ref:15]. This allows for a batch of patient information to be submitted, which is

Patient View (Patient Portal)

Personalised Care PlanSupporting Information• Demographics• Medications• Allergies• Adverse Reactions• Test Results• Diagnoses• Activity (ADTs)• Telehealth Data• People Involved in Care• Etc.

Treatment Plan

Support Plan

Shared Record (Clinical Portal)

Escalation Plan

End of Life Plan



matched against the data in PDS, and where possible NHS numbers (and updated demographics) are returned. In addition to the above, the Interoperability Toolkit (ITK) team [Ref:17] are developing a “Spine Mini-Service” for PDS which will provide some limited capabilities to match patients against PDS and return NHS numbers with Spine connectivity simplified by use of a pre-accredited intermediary “Spine Mini Service Provider”. Use of Mini Services is currently restricted to NHS Organisations Only for initial piloting, However they might well also have a role to play in allowing access to NHS numbers for social care in future. The demographic team in Connecting for Health can advise on approaches for obtaining demographics information.

Key Contact Details Connecting For Health Demographics Team: [email protected]

4.5.2. Medications, Allergies and Adverse Reactions

Details of a patient‟s medications, allergies and adverse reactions that are known to the patient‟s GP will be held in the GP system. The patient may also be receiving medication that is prescribed outside the GP practice (e.g. a hospital consultant, OOH, A&E), but in many cases the GP will also be made aware of this through a discharge summary from those care settings. One approach for bringing this into a shared record system is therefore to extract it from the GP system (or provide a “view” directly on the data in the GP system). For GP data there is currently no centralised data source, although the General Practice Extraction Service (GPES) may be able to provide this in the near future. Therefore GP data needs to be sourced from individual GP systems. This can either be achieved through using GP system proprietary interfaces or by using MIQUEST [Ref:36]. MIQUEST provides a single interface to all GP systems that allows you to formulate data queries in Health Query Language (HQL) to retrieve specific patient medical data. Another source for this information is the national Summary Care Record (SCR) [Ref:16]. The SCR contains key medical information that is available to authorised healthcare staff providing care in an urgent or emergency care situation. A person can choose whether to have an SCR or not. It is being rolled out across England with around 12.3 million people having an SCR (as of March 2012) and it is being used in a number of care settings to support care. There are a couple of ways that information can be obtained from the Summary Care Record. Data from the summary care record can be retrieved electronically using a standard messaging API over the “Spine” [Ref:13]. Suppliers wishing to use these interfaces would need to be assured under the Common Assurance Process (CAP) [Ref:14]. A number of suppliers have been through the CAP process to enable integrated SCR viewing, but for those suppliers who are not currently accredited, this route is likely to be time-consuming to complete. There is also a web portal available to all clinicians (with appropriate Smartcard roles) called the Summary Care Record Application (SCRa). This also includes a capability known as “1-Click” which can allow an existing system to “Click-Through” into the SCRa from a local patient‟s record, and to display the summary care record for that patient. There are a number of limitations of this approach however – a major consideration is that there is currently no way of knowing in advance whether a patient has a summary care record. If clinicians repeatedly try to access the SCRa to

mailto:[email protected]



view patient records and find that the patients do not have a record on the SCR this could quickly discourage them from using this in future. The SCR team in Connecting for Health can advise on approaches for integrating with the Summary Care Record.

Key Contact Details Connecting For Health SCR Team: [email protected]

4.5.3. Activity (Episodes / Encounters)

Data relating to different types of encounters can be sourced from centralised data sources which have collected data from individual providers. For In-Patient, Out-Patient and A&E data, the Secondary Uses Service (SUS) provides such a centralised data source which could be used. The data from SUS is only currently provided monthly, so in many cases it may be preferable to source this directly as data feeds from clinical systems. Many acute trusts have trust “integration engines” that share activity information between systems in the acute sector, so it may be possible to use these integration engines to provide real-time activity data. Activity data is normally sent in the form of HL7 “ADT” messages (Admission, Discharge, Transfer). These can be used directly, but they tend to be tailored to the needs of the local systems rather than being in a standard format. There are some specifications within the Interoperability Toolkit (ITK) [Ref:17] which can facilitate a standardised approach to sharing of ADT information, so this is an option that could be explored with the ITK team in Connecting for Health.

Key Contact Details Connecting For Health ITK Team: [email protected]

4.5.4. Test Results

Generally speaking, all test results will be shared with a patient‟s GP, so in many cases this data can be sourced from the GP systems. There may however be a delay in the results getting to the GP, and in some cases they are shared in a format that cannot be extracted or used directlt (e.g. scanned paper results forms), so more direct feeds from pathology or departmental systems within acute trusts could be looked into. There may be a need to incorporate some de-duplication functionality where feeds are being taken from multiple systems – otherwise it is possible that the same set of results may appear more than once (i.e. the results may be fed through from both the departmental system and the GP system). There is also some work that has been done on standardisation of pathology reporting via the creation of the National Laboratory Medicine Catalogue (NLMC) [Ref:38]. This will support a consistent, standardised way of reporting pathology test results across the country. A lot of work was done as part of the National Year of Care Programme around how results letters for Diabetes should be generated from GP systems and presented to patients, and how that should fit into the care planning process. Further details about the Year of Care Programme can be found in section 8.3.





4.6. Example Business Scenarios

Some typical business scenarios identified during discussion with local teams are outlined below. These deliberately omit any details about any technology solutions that might support the scenario – the subsequent technology guidance in this document will show how the business scenarios could be supported by technical interoperability approaches. These are not meant to be complete business process flows, rather individual pieces of a process, which could be combined in different ways to build up an overall process. Given the nature of the differing conditions that fall under the “long term conditions” banner, it is likely that there would not generally be a single prescriptive process that is followed for any given patient. The process is likely to be tailored to the needs of the patient, and the clinical pathways relevant to their condition(s). The care planning process generally incorporates a series of stages including assessing the patient, appraising their needs, agreeing goals and activities and then reviewing these periodically. This process for care planning as a whole is discussed in section 8, the scenarios below focus purely on the scenarios for the sharing of care plans.

IMPORTANT NOTE: Understanding the sharing scenarios for your local organisation is critical in ensuring that the correct approaches are applied to support the business needs. Time should be taken to capture the scenarios for your organisation in some detail before assessing technical approaches to apply.



4.6.1. Regular Scheduled Care

Regular scheduled care for patients with long term conditions is generally managed jointly by the patient‟s GP and some form of integrated neighbourhood care team. Some examples of typical business scenarios for the sharing of care plan information between these participants are shown below.

4.6.1.1. GP Shares Care Plan with Integrated Team

Variations: It is also quite possible that the patient would meet with a community team or specialist nurse without a GP referral. In which case the plan could be created by that team and subsequently shared with the GP.

4.6.1.2. GP Refers to a Community Team for Care Planning

A patient who has been diagnosed with one or more long term

conditions visits their GP or Practice Nurse, and together they create a personalised care plan to help the patient manage their condition.

The GP/Nurse

shares the personalised care

plan with the rest of

the integrated team.

Care Plan

The GP/Nurse then makes the plan available to

the patient so they can review and update it themselves as they manage their condition.

1

2

3

GP /

Practice

Nurse

Community

Teams

Acute Care

Teams

2

A patient who has been diagnosed

with a long term condition visits their GP or Practice Nurse.

The GP/Nurse decides that

a Community Matron in the integrated team should

work with the patient to

develop a care plan, and so refers the patient to the

community team.

Care Plan

The community team works with

the patient to create a care plan, and makes it available to the

patient so they can review and

update it themselves as they manage their condition.

The care plan

is shared with the GP

1

2

3

4

GP /

Practice

Nurse

Community

Team

Acute Care

Teams

The care plan may

also be shared with acute care teams

5



4.6.1.3. GP Initiates Care Planning Based on Risk Data

Variations: In many cases, the GP may pass data about the high risk patients to an integrated team so that they can get in touch with the patient and create a care plan.

4.6.1.4. Capturing End of Life Care Preferences

Variations: It may be another clinician caring for the patient who captures the preferences rather than the GP – e.g. a district nurse or a nurse in a care home or hospice.

As each of the patients visits the GP or

Practice Nurse, they create a care plan together to help them manage their condition

1

The GP practice look at the

risk stratification outputs, and selects a cohort of high-risk

patients to discuss their

condition with, and invites them to attend the surgery.

Care Plan

2

Risk Stratif ication

Tool

GP /

Practice

Nurse

A patient is identified as being in the last 12 months of

their life. They visit their GP or Practice Nurse to discuss their preferences for their ongoing care. The GP/Practice

Nurse captured the patients end of life preferences.

The GP/Nurse shares

the preferences with the rest of the

integrated team, and

also with unscheduled /

emergency care providers

End of Life Care

Preferences

The GP/Nurse then makes the care preferences

available to the patient so they can review it and retain it in case of future emergencies.

1

2

3

GP /

Practice

Nurse

Community

Teams

Acute Care

Teams

2

OOH A&E Ambulance

2 2 2



4.6.1.5. Regular Care Plan Review

Variations: Regular reviews are a standard part of managing some conditions (e.g. Diabetes), but may not necessarily form part of the management of other LTCs. In some cases, the review may be done by other clinicians in the integrated team rather than the GP.

4.6.2. Social Care and 3rd Sector

There are a number of potential differences in the scenarios around sharing with social care services – primarily because the support plans produced by social care teams are quite different in their content and focus to the care plans produced in NHS care settings. Another key difference is the issues around N3 connectivity, use of Smartcards, and the use of NHS numbers – these are explored in more detail in sections 4.3.3 and 5.6.9. For these reasons it may be helpful to treat these scenarios separately when planning local approaches and roadmaps. Some localities have formed joint health and social care organisations (Care Trusts) which can help overcome these issues. Note: In many cases an integrated team may incorporate team members from social care services. In the longer term most teams have said that they would like to see a combined personalised health and support plan. Such a combined plan would probably follow the patterns outlined above for regular scheduled care, but none of the teams spoken to have managed to fully integrate these different types of plans. The role of social care teams is often different from role of third sector organisations. Third sector organisations are generally more likely to be delivering services to support self management rather than the complex „social support‟ offered by social care teams. These differing roles and information needs should be considered when capturing local sharing scenarios.

The patient goes for a regular review of their condition, and takes along some

recent test results, which feed into a discussion with the GP or Practice Nurse as part of reviewing their care plan. The patient and GP/Nurse discuss the results

and agree some new and updated actions/needs, which the GP/Nurse updates

in the patient‟s care plan.

3

1Care PlanGP / Practice

Nurse

The GP/Nurse then makes the updated plan

available to the patient so they can review and update it themselves as they manage their condition.

The GP/Nurse

shares the updated care plan with the

rest of the

integrated team.

2

Community

Teams

Acute Care

Teams

2



4.6.2.1. Sharing Care Plan with Social Services

4.6.2.2. Sharing Support Plan with NHS Services

4.6.3. Unscheduled / Emergency Care

Certain types of care plans (End of Life Preferences and Escalation Plans) are especially relevant for unscheduled care providers to be aware of and have access to. It is generally less likely that unscheduled care professionals would want to update the care plans, but in some cases (e.g. Out of Hours GPs) it may be desirable to allow updates to be made.

The patient visits their GP or Practice Nurse, and

together they create a care plan to help the patient manage their condition.

The patient

contacts social services to

discuss their

support needs. A support plan

is created/ updated.

The patient confirms that

they are receiving social care support and gives

their consent to share their

care plan, so the GP/Nurse shares the care plan with

the social care team.

Care Plan

1

2

3

Care Plan

4

The social worker

shares a copy of the patients support plan

with the GP.

GP /

Practice

Nurse

Social

Care

Support

Plan

Support

Plan

The patient visits the GP or Practice Nurse, who

discusses the associated health needs, and creates a care plan with the patient – referring to

the support plan as required to inform the

discussion with the patient.

2

The patient is receiving social

care, and a member of the social care team creates a

support plan which requires

some clinical support. The patient gives their consent for

their support plan to be shared.

Support

Plan

3

The patient is then referred to

their GP/Nurse to review their health needs. The support plan

is shared with the GP.

Care Plan

1

GP /

Practice

Nurse

Social

Care

Support

Plan



4.6.3.1. Sharing of Care Plans with Unscheduled / Emergency Care Services

4.6.4. Self-Care / Self-Management

Supporting patient to self-care and manage their own condition is a key objective of the long term conditions teams, so some specific scenarios supporting this should be considered.

4.6.4.1. Patient Initiates Care Planning and Discusses with GP

6

6 It may not be practical in many cases for the patient to create a care plan themselves initially

as the creation of a plan should ideally be a shared process between the patient and the care professionals involved in their care. The patient may however do preparatory work for the care planning consultation – e.g. identifying some possible goals and activities as well as some questions they want to raise with the care team during the consultation.

A patient who has been diagnosed with a

long term condition visits their GP or Practice Nurse. Together they create a care plan to

manage the condition.

1

The GP/Nurse

shares the care plan with unscheduled

care providers (A&E,

OOH, Ambulance)

Care Plan

2 2 2

A&E OOH Ambulance

GP /

Practice

Nurse

3

The patient has an accident

and has to be taken to A&E for emergency care. The A&E

team are able to refer to the

patient‟s care plan to ensure the care they provide is in line

with the patient‟s personal health goals and preferences.

They are aware of the support

being provided to the patient, which helps facilitate a rapid

discharge.

A patient researches their

condition(s), and decides to create a self-care plan

with their personal goals

and activities for managing their condition.

The patient visits their GP or

Practice Nurse, discusses their condition(s), and mentions that they

have created a care plan, which

they share with the GP/Nurse.

The GP/Nurse and patient discuss

the care plan, and agree some other services which might help the

patient with their condition. Some

additional goals and activities are added to the plan, which is then

shared with the patient.1

2

3

GP /

Practice

Nurse

Care PlanCare Plan



4.6.4.2. Tailoring the Plan to Support Patient Self-Management

The above scenarios are examples, and local teams should identify the sharing scenarios that apply for them.

The patient visits their GP or Practice Nurse to review and

update their care plan, and the GP/Nurse suggests that there are some training courses that the patient may want

to attend, and some online learning resources that they

might want to look at.

1

The patient agrees, and the GP/Nurse

adds the activities to their care plan, which is shared with the patient

Care Plan Care PlanGP /

Practice

Nurse

2

The patient reviews

the plan, and completes an online

training course, or a

group education programme (e.g.

DESMOND)

3

4

The care plan is updated to indicate that

an activity has been completed, and this is shared with the GP/Nurse.

Learning

Resource



5. Technical Interoperability Guidance

5.1. Overview

The guidance in this document revolves around a set of “architectural patterns”. These patterns are approaches for solving a particular aspect of the sharing of care plans. They are broken down into three distinct categories:

Discover / Locate Care Plans: In order to be able to review or update a care plan for a patient, you first need to establish whether a care plan exists, and where it is held. These patterns cover various approaches for “discovering” and “locating” care plans.

Sharing / Accessing Care Plans: Once the location of any relevant care plans has been established, there are a number of approaches for gaining access to the care plans of a patient.

Managing Changes to Care Plans: Once a care plan has been shared, there are a number of approaches that can be taken for managing changes to the care plan.

It is likely that there will not be a single “architectural pattern” outlined in this document which can easily be applied now to meet all the business scenarios for a given local implementation. It is more likely, at least initially, that some patterns will fit better for some scenarios than others. It is also likely that local organisations will want to put in place some of the simpler patterns initially, with a roadmap to develop a richer and more feature-rich integration solution over time. Where existing interoperability specifications exist that could be used to support implementation of a pattern, this will be highlighted in the description of the pattern. The specifications themselves are outlined in more detail in the “Existing Interoperability Toolkit (ITK) Specifications” section 5.4. Some of the more advanced patterns do not currently have ITK specifications to support them, so additional specifications would need to be developed to support these (see section 0 for more details). It is also possible that different approaches to interoperability may be taken for different types of care plans within a locality. This may be as a result of different initiatives around specific types of plan (e.g. End of Life Care Preferences). Local organisations should understand and map out the approaches being used for each type of care plan and each care setting so that a consistent and well understood process can be implemented. This is likely to be very important in ensuring that clear messages and guidance are communicated out to local health and social care professionals. Some of the architectural patterns outlined in this document come with specific considerations around how they might be implemented locally, and where a specific consideration is especially pertinent to an architectural pattern this is highlighted. There are a number of other implementation considerations outlined later in this document, many of which apply regardless of which architectural patterns are used.



5.2. Summary Table

The below table summarises the business scenarios, architectural patterns, interoperability specifications and implementation considerations outlined in this document. The patterns, specifications and implementation considerations will be explained in detail in the following sections.

Business Scenarios

Regular Scheduled Care:

Unscheduled / Emergency Care

Self Care / Self Management

Social Care and 3rd

Sector

GP Shares Care Plan with Integrated Team

Sharing of Care Plans with Unscheduled / Emergency Care Services

Patient Initiates Care Planning and Discusses with GP

Sharing Care Plan with Social Services

GP Refers to a Community Team for Care Planning

Tailoring the Plan to Support Patient Self-Management

Sharing Support Plan with NHS Services

GP Initiates Care Planning Based on Risk Data

Regular Care Plan Review

Architectural Patterns

Discover / Locate Care Plans:

Sharing / Accessing Care Plans

Managing Changes to Care Plans

Local Agreement View In-Situ: Single Shared System

Manual / Ad-Hoc

Lookup List Push: Send Copy

Single Owner

Notification with Pointer Pull: Retrieve From Shared Repository

Synchronisation with Central Repository

Local Registry Synchronisation with

Multiple Repositories

Federated Local Registries

National Registry / Repository

Interoperability Specifications

Existing Specifications

Generic Payload over ITK

Non-Coded CDA

HSCI Integrated Care and Support Plan

Possible Future Specifications

Notification Message

Care Plan CDA Profile

End Of Life Care Preferences CDA Profile

Registry / Repository Interactions

Implementation Considerations

Patient Access Content and Clinical Coding

Information Governance

Sharing or Updating of Partial Plans

Reporting and monitoring of outcomes

Content becoming out of sync

Workflow & Collaborative Authoring

Patients moving between localities

Identifying Recipients

Integration with Non-NHS Organisations

Transport Mechanisms Historical View

Click-Through and Context Management

Reviewing and Applying Changes to the Plan



5.3. Architectural Patterns

This section outlines a number of architectural patterns that can be applied to support the technical sharing of care plans. There are many combinations of these patterns that can be used together, and the document will not attempt to cover every permutation or combination of patterns for any given business scenario. There is however a high level maturity model in section 5.7 and an example of how specific patterns at different levels of maturity can be applied to a business scenario in section 6.

5.3.1. Discover / Locate Care Plans

5.3.1.1. Local Agreement

Description One solution within a local health community is for the relevant provider organisations to simply agree between themselves where care plans will be held. This may differ for different types of care plans (for example, end of life care preferences may be held in a different system to personalised care plans), but as long as the relevant organisations are aware of which systems hold the care plans, they can build this into their processes.

Advantages / Disadvantages

It could potentially be quick to establish such an agreement within a local health community, and does not require any specific technology support. This is an approach currently used by many local teams.

This approach does not scale beyond the local area. It can also become difficult to manage and administer if there are several types of care plans being held in different systems.

It can be problematic for services that have differing geographical boundaries (e.g. ambulance trusts cover a much larger area than many other providers).

Any changes to where care plans are held (e.g. if a new system is procured) could require changes to multiple systems or local processes.

Simply agreeing in advance where care plans will be held does not actually help in establishing whether a specific patient has a care plan, which could result in clinicians continually having to check a different system only to find that there is no plan for that patient.

Potential ITK Specifications / Solutions None

Implementation Considerations7


Local agreements only cover patients within that region, so consideration may be needed for the process for patients who move in or out of the area, or who require emergency care when they are away from home (e.g. on holiday).

7 See section 5.6 for a more detailed break-down of each of the implementation

considerations mentioned.



5.3.1.2. Lookup List

Description Where a system holds care plans for the patients in that region, one approach for ensuring other care providers know which patients have a plan in that system is to produce a regular extract listing the patients who have a care plan. This can then be sent to other providers so that they can query the list whenever they have an encounter with a patient. If the list indicates that the patient does indeed have a care plan, the clinician can then access the relevant system to view the plan. The lookup list could also potentially include a “pointer” to which system holds the plan – this could then allow for separate lists to be produced from multiple care planning systems that can then be brought together into a consolidated list to send to providers.


Sending out a list of patients who have a care plan helps to identify in advance whether a clinician or system should retrieve it from the relevant system/repository.

This approach does not scale beyond the local area. If multiple lookup lists need to be aggregated this is an additional capability that would need to be developed and supported.

It can be problematic for services that have differing geographical boundaries (e.g. ambulance trusts cover a much larger area than many other providers.

Assuming that the lookup lists are generated daily, there is up to a day‟s delay before other services are made aware that plans exist.

Potential ITK Specifications / Solutions


Although it is not the intended purpose, either the general ITK distribution envelope specifications, or potentially the non-coded CDA specifications could be used to carry locally defined content, including lookup lists.

Non-Coded CDA



Lists extracted and shared locally only cover patients within that region, so consideration may be needed for the process for patients who move in or out of the area, or who require emergency care when they are away from home (e.g. on holiday).

Transport Mechanisms

If ITK specifications are used, an appropriate transport mechanism needs to be agreed to support this.

It is possible that a solution based on lookup-lists could potentially be scaled nationally if the lookup-list was published as a single national list (e.g. via TRUD8). For example, a list could be compiled linking lists of GP practices to the local system holding care plans for those practices. Any clinician could then establish who their patient‟s registered GP is, and refer to this list to establish which system holds the care plan for the patient. The publishing of this national list would need to be co-ordinated by a central team, but no such provision exists currently, and there are no plans to develop such a capability.

8 See section 7.4 for more discussion of what TRUD is.



5.3.1.3. Notification with Pointer

Description When a care plan is created or updated, a notification could be automatically triggered. This could be sent to the relevant systems in the other provider organisations in the region. If the care planning system has a list of the other parties involved in the care for the patient the notifications could be targeted at those organisations, otherwise they may have to go to a predetermined list of recipients. This notification would need to identify the patient, the type of care plan, and include a pointer to the system that holds the care plan. The receiving system could then add a flag against the patient‟s record to indicate that a care plan exists. When a clinician in one of the other services encounters a patient, their system could then notify them that a care plan exists, and where it is located. To work effectively, there would need to be an agreement that there is one “master” version of the care plan, with other systems using the pointer to locate that “master” care plan.


The sending of a notification allows other systems to be updated in real-time.

By sending a pointer, which also identifies the type of plan, the solution can scale to cover many types of plans held in different systems.

It can be problematic for services that have differing geographical boundaries (e.g. ambulance trusts cover a much larger area than many other providers.

The solution does not scale beyond a local community – it would not be feasible to send notifications to all services across the country.



Although it is not the intended purpose, either the general ITK distribution envelope specifications, or potentially the non-coded CDA specifications could be used to carry locally defined content, including a notification message.

Non-Coded CDA

Notification Message

A more specific notification message specification could be developed to support this.



Because the notifications will only be going to the providers in the local area, they will only cover patients within that region, so consideration may be needed for the process for patients who move in or out of the area, or who require emergency care when they are away from home (e.g. on holiday).




In order to send notifications there needs to be a way of identifying which individuals (and systems) the notifications should be sent to.



5.3.1.4. Local Registry

Description Where a number of local systems exist that hold care plans, there may be a need for a better mechanism for managing these within the region. One way to approach this is to create a central “registry” for the region which contains a list of patients that have care plans, with pointers to whichever local system (aka “repository”) holds the care plan for that patient. Anyone encountering a patient can then query this registry to establish whether the patient has a care plan, what types of care plan exist, and where each is held. This pattern aligns with an existing standard developed for Cross-Enterprise Document Sharing by IHE (Integrating the Healthcare Enterprise), called XDS [Ref:18].


A local registry can help to bring together a range of local repositories in a very flexible way, allowing plans to reside across a number of systems, whilst still providing a single consolidated view to clinicians.

A local registry would not scale nationally, unless it is federated (see Federated Local Registries pattern: section 5.3.1.5).

There are no existing ITK specifications to support this approach.



ITK specifications could be developed to support a registry/repository model. This could be based on the XDS standard, or a simplified version of that standard.



Because the local registry will only be used by providers in the local area, they will only cover patients within that region, so consideration may be needed for the process for patients who move in or out of the area, or who require emergency care when they are away from home (e.g. on holiday).



It is possible that a local registry solution could be enhanced by mapping the local registries to known geographical or patient population boundaries (e.g. SHA region or GP practices). These boundaries could then be shared more widely as a lookup list, or by general agreement (e.g. the care plan registry for the Yorkshire and the Humber region is held in system X). This could be considered a simple form of “federated” registry – see the “Federated Local Registries” pattern below.



5.3.1.5. Federated Local Registries

Description In order to scale a local registry solution so that it can be used nationally, there is a need to allow local registries to be “federated”. A federated registry acts like a single “logical” national repository – it achieves this by the local registries working together in a co-ordinated way to process any requests that they receive, such that they can present a single logical view of any relevant data held across all the local registries. The exact technical mechanisms for how this is achieved are beyond the scope of this document.


The approaches for federating multiple registries are likely to be complex, and there is a risk that a federated solution may not perform well when scaled nationally.

Such a solution has never been attempted on this scale in the UK.

Specifications would need to be defined nationally and implemented consistently in all local registries for such a solution to work.

Information governance and data sharing agreements for federated solutions can become complex as information is shared across a wider area and a wider range of clinical systems.



ITK specifications could be developed to support a registry/repository model. This could be based on the XDS standard, or a simplified version of that standard. These specifications could include the messaging required for federating of local registries.






5.3.1.6. National Registry / Repository

Description It is unlikely that any new national solutions will be put in place specifically to support the sharing of care plans, but there is an existing national solution – the Summary Care Record [Ref:16] – which could potentially be used in this way. The SCR contains key medical information that is available to authorised healthcare staff providing care in an urgent or emergency care situation. A person can choose whether to have an SCR or not. It is being rolled out across England with around 12.3 million people having an SCR (as of March 2012) and it is being used in a number of care settings to support care. It is possible to include additional information, beyond the core data set of medications, allergies and adverse reactions, in a person‟s SCR. This can only be done with the explicit consent of the individual. Any coded data item and its associated free text can be included in this manner [Ref:19]. The Summary Care Record programme team has already done some work on ways in which the SCR could be used to support end of life care planning, and there is an example video on the SCR training web page [Ref:20] entitled “End to end demonstration” which shows how this could work in practice. Generally speaking there are a couple of ways in which the SCR could be used to support the sharing of care plan information:

SCR as a shared repository: The actual care plan content could potentially be held in the summary care record itself. This would then be available to any clinician, either via their clinical system (if it supports directly querying the SCR), or via the SCR web portal (SCRa). Some local teams are planning to use this approach for the sharing of end of life preferences, but it is not limited to this type of care plan.

SCR as a shared registry: Rather than storing the actual content, the SCR could hold a “pointer” to any relevant care plans held in local systems or repositories. This would then in effect be a national registry for end of life care plans.

If you are considering using the SCR in this way you should first discuss this with the SCR team within Connecting for Health [Ref:16].


Provides a single place to discover and locate care plans for patients nationally.

Builds on existing capabilities – no requirement to build new services for the discovery / locating of care plans.

Many systems are already able to integrate with the SCR

There are no reporting services provided as part of the SCR, so some alternative reporting mechanism would need to be developed if this was required (most likely this would require a separate data feed from the GP system)

Only the registered GP Practice is able to update the SCR, which may cause a delay in updating the record if changes need to be made out of hours.

SCR rollouts are continuing, however, whilst it is still being rolled out, not every person will have an SCR. Therefore, a local health community may not be able to offer an SCR solution to everybody if it has not been fully rolled out in their area.

If using a national repository to hold care plans centrally, there would need to be significant effort to standardise on the content and gain national agreement, and also the relevant IG controls for allowing national sharing of that content.





The ITK could be used to provide standard messaging interactions around the use of SCR as a national registry, and also for retrieving content from local repositories.

Implementation Considerations None

5.3.2. Sharing / Accessing Care Plans

5.3.2.1. View In-Situ: Single Shared System

Description A simple solution which can be effective where many services already share a single clinical system is to allow all the relevant providers to view the care plans directly within that system. This may require specific “viewers” or read-only access to be granted to individuals outside the organisations that usually use the clinical system. Another approach might be to create or procure a new shared system that can hold care plans. This may take the form of a shared care planning system (possibly fronted by a clinical portal), which all clinicians caring for patients with long term conditions can log into.


All create, read, update and delete operations take place within a single shared system, alleviating many of the issues around synchronisation.

Not integrating with the clinical systems that are used by clinicians may hamper uptake, and if those clinical systems already capture some of the information that might form part of a care plan there may be a need for re-keying of information into the single shared system.

All users needing access to care plans would need access to the shared system, which may have licensing, capacity, performance or IG implications.

Such a solution would not scale beyond a local community as it would only be available for users who are explicitly granted access to the shared system.



Click-Through and Context

Management

Once a care plan has been located, a local system could offer a “click-through” capability to redirect the user to the system holding the plan.



5.3.2.2. Push: Send Copy

Description A very simple solution for sharing of a care plan is simply to send a copy of it to another system or care professional involved in the care of the patient. This could be as simple as a copy of the care plan attached to an email and sent over NHSMail, or it could be an electronic message between systems using DTS or Web Services.


Can be achieved relatively simply using existing infrastructure (e.g. NHSMail/DTS), or using existing ITK specifications.

Can be triggered in real-time, providing rapid access to plans for other teams.

Results in multiple copies of care plans existing across multiple systems (potentially resulting in complex many-to-many sharing scenarios). Depending on the approach used for managing updates, this could cause issues with content becoming out of sync, or out of date.



Either the general ITK distribution envelope specifications or the non-coded CDA specifications could be used to carry locally defined content, including various types of care plans. Non-Coded CDA

HSCI Integrated Care and Support

Plan

The integrated care and support plan provides a more structured message definition, which can also include some coded information if required.





In order to push out copies of a care plan, there needs to be a way of identifying which individuals (and systems) the copies should be sent to.



5.3.2.3. Pull: Retrieve From Shared Repository

Description Where plans are held in a system (or “repository”), this system can provide a messaging interface to allow other systems to retrieve care plans on request. Anyone wanting to view a care plan of a specific type for a specific patient can issue a request to the repository, which can return the care plan. If no care plan of the requested type exists for the patient in the local repository, a suitable error response would be returned.


Allows plans to reside in a repository, which would generally act as the “master” copy of the plan. Other systems can retrieve plans on request when required.

Does not rely on multiple copies of plans being replicated across multiple systems (which may never be needed in those systems).

IG controls would need to be considered, to control who was allowed to retrieve each type of care plan from the repository.



Either the general ITK distribution envelope specifications or the non-coded CDA specifications could be used to carry locally defined content, including various types of care plans. Non-Coded CDA

HSCI Integrated Care and Support

Plan

The integrated care and support plan provides a more structured message definition, which can also include some coded information if required.


The messages to request a copy of a care plan, and to return the document, are likely to form part of a wider set of registry / repository interactions.

A suitable request-response mechanism would need to be agreed within the ITK specifications. This is likely to require some discussions with the ITK team in order to ensure a suitable solution is agreed upon.






5.3.3. Managing Changes to Care Plans

5.3.3.1. Manual / Ad-Hoc

Description Often it is desirable for all participants to be able to update the plan. Co-ordinating updates from multiple participants can be difficult, and often a manual or ad-hoc approach is used to avoid building additional complexity into systems. Often this relies on individuals in the team reviewing updates from other team members and checking that they do not conflict with their own updates. Common approaches to aid this are the use of version numbers, and keeping a history of versions. In this way, an individual reviewing a plan can see which version is the latest, and what has changed since the last version. If they receive another plan with the same version number, but different changes, they can manually reconcile the changes across the two versions to create a new consolidated version. If keeping a history of changes is not important (unlikely), and any recent information is likely to supersede any previous changes, then a simple “latest version wins” approach could be used.


Relies heavily on individuals checking care plans, and ensuring any conflicting updates are merged.

The merging of conflicts may require specialist knowledge, or discussions between professionals and/or the patient.

Any mistake in managing updates in this way could lead to information being lost, which could present a clinical risk.




If information is updated by multiple participants without proper co-ordination, this could result in multiple conflicting updates. Mechanisms would need to be put in place to allow this to be resolved in a consistent and robust way.



5.3.3.2. Single Owner

Description By only allowing a single named individual or team to update a care plan, the issues around conflicting updates can be avoided. All other participants would have read-only access to the information in the care plan. Any changes that needed to be made would have to be communicated back to the owner, so that they could update the plan accordingly. This is the same model as is used for the “GP Summary” within the national Summary Care Record (which can only be updated by the registered GP) – updates from other care settings are returned to the GP in the form of “discharge summaries” or other mechanisms (e.g. email, telephone).


Removes the risk of the information becoming “out of sync” as there is only one person/team that can make updates.

May add a delay in making updates to the plan. If changes have to be communicated back to the owner, they may not be applied until the owner is available and can review and update the plan accordingly.

There is a risk that some information may be “lost in translation” if the owner does not fully understand the changes they have been asked to make.


Implementation Considerations None



5.3.3.3. Synchronisation with Central Repository

Description Another option is to allow each clinical system to retain a copy of the care plan, but to require that it be regularly synchronised with a central repository. This is the model used by PDS for demographics. Typically, before displaying a care plan the system would check whether the version it has is the latest. If not, it will retrieve an updated version from the central repository. When an update is made to the care plan, the version number is incremented, and the updated version is sent back to the central repository to be updated there. In the scenario where two systems independently try to update the central repository at the same time, some form of manual reconciliation would be required. This pattern may be more appropriate in cases where, due to the analysis of the business process, conflicts will be rare. Conflicts become more likely when communication errors occur and local systems are unable to synchronise with the central repository for a period of time. It is also possible that different “central repositories” could be used for different types of care plans, or even different groups of patients. This would rely on a robust way of identifying which was the “master” repository for a given patient and/or care plan type (see the “Discover / Locate Care Plans” patterns for ways of achieving this, section 5.3.1).


Allows for updates to be made in any system, but with a robust mechanism for ensuring that changes are disseminated to all systems as required.

Does not remove the possibility of conflicting updates, but makes this much less likely than in an ad-hoc or manual solution.

Already used in PDS and many other systems.

Would not scale beyond a local community unless the central repository became a national shared repository.

Could potentially hamper system performance as a result of having to query a remote system whenever a care plan is accessed.



The ITK could be used to provide standard messaging interactions for querying repositories and returning documents held in them.



The potential for updates to be made in multiple places simultaneously still exists in such a solution (although less likely). Mechanisms would need to be put in place to allow this to be resolved in a consistent and robust way.



5.3.3.4. Synchronisation with Multiple Repositories

Description Where there are multiple systems holding care plans, and there cannot be a single system designated as the “central” repository for any given type of plan, there may be a need to allow replication of changes across multiple repositories. Such solutions are generally very complex to create and manage, so should only be considered if there is a strong reason for pursuing this approach. One approach for such a solution is to have a central “controller” that co-ordinates updates and ensures that they are propagated to the relevant repositories. If consistency of the data across repositories is critical, then a “multi-phase commit” model can be used to ensure that an update is only considered successful once it has been applied in all repositories. Another approach that could be considered is an “eventual consistency” model [Ref:21]. This approach is used in some modern NoSQL database technologies, and allows updates to be applied in one or more repositories, and for these updates to gradually propagate to other repositories. This approach brings greater risks of conflicting updates, and therefore would require robust mechanisms for manually reconciling conflicts. A detailed description of approaches for synchronisation across multiple repositories is beyond the scope of this document.


Potentially very complex to implement in a robust way.

Does not remove the possibility of conflicting updates, but makes this much less likely than in an ad-hoc or manual solution.

Could potentially offer either a significantly worse or significantly better level of performance than other patterns depending on the specific technical solution used.



The ITK could be used to provide standard messaging interactions for querying repositories and returning documents held in them.

The wider messaging for co-ordinating updates across multiple repositories require the development of additional specifications.



The potential for updates to be made in multiple places simultaneously still exists in such a solution. If an eventual consistency model was used, this risk could be significantly higher. Mechanisms would need to be put in place to allow this to be resolved in a consistent and robust way.



5.4. Existing Interoperability Toolkit (ITK) Specifications

There is a general introduction to ITK later in this document (section 7.1), but this section will highlight some existing ITK specifications that could be used to support the architectural patterns outlined above.

5.4.1. Generic Payload over ITK9

Within the “Core” ITK specifications, the basic requirements for “wrapping” content, and sending it from one system to another are detailed (this is referred to as the “Distribution Envelope” in the ITK specifications). This distribution envelope contains:

Name of the Service Being Requested

Tracking ID (useful for tracking transmission, for example its route to a destination)

Address List (list of recipients for the message)

Audit Entry (auditable reference for the sender. e.g. smart-card authentication etc.)

Manifest (contains details about the payload(s))

Sender Address (address of sender)

Handling Specifications (a list of instructions for the recipient, e.g. send an acknowledgement on receipt)

This is supported by a number of definitions of pre-defined payloads which can be used – referred to as “Domains”. It is also possible however to use a locally defined payload which could take any form required. It could for example be a word or PDF document, or a locally defined XML fragment. This allows for any type of content to be defined locally, and the ITK specifications used to provide standard ways of getting the content between systems, and linking to the relevant patient record in the receiving system (these aspects are held in the “Distribution Envelope”). The draw-back of this approach is that there is no control over the structure of the content that is shared – it is treated as a “black-box” as far as the message specification is concerned.

9 This is sometimes referred to as “Common Correspondence” messaging.



5.4.2. Non-Coded CDA

In order to allow for a more structured care plan message to be sent over ITK, a “Non-Coded CDA” message can be used. This still uses the standard ITK distribution envelope, but uses a “CDA” document as it‟s payload. Clinical Document Architecture (CDA) is a HL7 [Ref:22] standard for the representation and machine processing of clinical documents in a way which makes the documents both human readable and machine processable and guarantees preservation of the content by using the eXtensible Markup Language (XML) standard. As the name suggests, the Non-Coded CDA domain does not included any clinical coding, but it does provide a more structured way of sending content. It has predefined sections (many of which are optional) within the message for things such as:

The Recipient (organisation, team or individual)

Data Enterer (the person who entered the information in the document)

Authenticator (the person who has overall responsibility for the document)

Author (author of the document)

Patient (patient to which the document relates)

Custodian (this is the organisation legally responsible for the document)

Informant (people or organisations who contributed content to the document)

Participant (other people or organisations associated with the document)

Related Documents

Encompassing Encounter (details the overall encounter that is being documented) There is then a “Body” section, which can contain a structured set of text “Sections” each of which can have a title and/or text within them. These can be nested up to six levels deep to build up a structured document which is defined and agreed locally. It is also technically possible to use non-XML content for the “Body” – e.g. a PDF or Word Document. Once a local structure has been defined for the “body” for a care plan, this could then become a candidate for becoming a new ITK specification, which would then become a standard structure for others to use. Using a CDA document structure provides a very flexible but well defined format for sharing of clinical documents, and provides a consistent approach to document metadata. It also allows for a standard approach to rendering any CDA document for human consumption (any system can easily render a CDA document without having to “understand” any of the content. It also provides a level of future-proofing by giving the ability to extend the document with clinical coding if needed in future. The CDA document format is relatively complex, and there are some services and tools offered by Connecting for Health and others which may help local teams in implementing solutions using CDA. See sections 7.5 for more details. NOTE: It is also possible to send any CDA document over ITK in a similar way (referred to as “Generic CDA” in the ITK specifications). This could be used to begin adding coded entries into messages. This still uses the ITK distribution envelope but does not constrain the content of the CDA document in the same way as the Non-Coded CDA domain does.



5.4.3. HSCI Integrated Care and Support Plan

The HSCI Integrated Care and Support Plan is an example of a more detailed structured CDA “payload” that can be sent using ITK. It includes the usual ITK distribution envelope, and also contains the same basic CDA sections as the Non-Coded CDA document (e.g. recipient, author, patient, etc), but adds a more structured “Body”. This body also comprises of “Sections” with titles and text, but it also provides some predefined sections that can be used to standardise the content. These include sections such as:

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 This document is also able to carry coded information, and could potentially include codes relating to diagnoses, medications, or anything else which can be coded. The coding system should usually be SNOMED CT®, although it is possible to specify other coding systems or even a locally defined coding scheme (although SNOMED CT® should be used unless there is a strong reason preventing it). There is an example of the type of content that can be carried in the integrated care and support plan in an appendix at the end of this document.



5.5. Possible Future Interoperability Opportunities

Much of the messaging that would be required to implement the patterns in this document could be achieved using locally defined content carried in a general ITK distribution envelope or non-coded CDA message. It may however be preferable to standardise the content to support these patterns so that it can be used consistently across any systems that implement the specification. This could help allow local solutions to scale or change to cover different geographies more easily, and could help make procuring solutions easier (assuming a number of suppliers adopt such a standard in their products).

5.5.1. Notification Message

Some of the patterns outlined in this document rely on being able to electronically “notify” others that a care plan has been created or updated. If a specific notification message were to be defined within ITK, it could support the notifications around care plans, but it could also be used for other notifications, for example to notify a central care planning system that an activity on a care plan has been completed, or to notify a clinician that a patient-entered reading is outside the allowable tolerance and may require follow-up.

5.5.2. Care Plan CDA Profile

Although the existing HSCI Integrated Care and Support Plan specification does provide a structured message which can be used for sharing care plans, it is possible that this may not fit with what local teams decide needs to be included in the care plan. It may therefore be preferable to work with the ITK team and the Data Standards team within Connecting for Health to define a more appropriate CDA message definition for care plans. This may be generic and cover various types of care plans, or it may be that specific messages should be defined for specific types of care plan. This discussion would need to form part of wider work on developing standardised content, coding and professional standards (see section 8 for more on this).

5.5.3. End of Life Care Preferences CDA Profile

The clinical content that needs to be captured around end of life care preferences is already well defined in the ISB standard. It may therefore make sense that a standard ITK specification be developed to support sharing this information between systems.

5.5.4. Registry / Repository Interactions

Some of the architectural patterns outlined in this document introduce the concept of a “registry” holding details of where plans are held, and one or more “repositories” that hold the plans themselves. There are a number of message interactions that would be required to support this, and these could also be developed as ITK specifications so that they are consistent across implementations. These could be based on the existing XDS standards, or they may be a simplified set of interactions. The ITK team are currently investigating the possibility of developing some new specifications for this.



5.6. Implementation Considerations

There are obviously a very wide range of other considerations that a local team would need to take into account when developing a solution for the sharing of care plan information (see the section 1.1 at the start of this document for some examples). Many considerations are beyond the scope of this document, but there are a number of other technical considerations that are worth specifically highlighting here alongside the architectural patterns. Many of these are areas where there is no prescribed solution. Where existing guidance or other sources of information exist they will be mentioned here.

5.6.1. Patients moving between localities

Many local teams are developing solutions for sharing care plans within their local health community. This often involves the various providers knowing where care plans are held for the patients in their region, which is generally achieved through local agreements between those providers. Whilst this may be appropriate in some scenarios, the drawback is that patients sometimes move around, either temporarily (holiday) or permanently (moving house). In these cases, thought needs to be given to what happens to the patient‟s care plans, and how these can remain accessible to all the clinicians that need them.

5.6.1.1. Moving House

In the scenario of a patient who moves house, any care plans should ideally be sent electronically to the new care professionals taking on care for the patient. If this is not possible, it may be acceptable to manage this locally as part of the registration process with a new GP. The patient could be asked to provide hard-copies of their care plans, or if the care plan is held in the clinical system of their old GP, this may be transferred over as part of the GP2GP record transfer. Alternatively, it may be necessary for the new GP to contact the relevant team in the old locality and request that an up-to-date care plan be emailed over a secure email system such as NHS Mail. This would then need to be manually re-entered into the relevant system in the new locality.

5.6.1.2. Going on Holiday

For patients who are on holiday, the primary concern is likely to be over the exacerbation plan and end of life care preferences. If a patient was to fall ill while away from home, and be picked up by an ambulance, the crew would ideally need to know that these plans existed and be able to get access to them. Again, it may be that this scenario could be managed manually, by asking patients to ensure that they carry paper copies of their care plans with them when they are away from home, but an electronic solution is preferable where possible.



5.6.2. Patient Access

Many local teams want to provide some level of access to care plans (and supporting information) directly to patients.

5.6.2.1. Content and Presentation

In most cases, this is likely to take the form of a patient “portal” which pulls relevant information from the relevant clinical systems and/or shared care planning systems. It is likely that this would need to be presented in a very different way than in the clinical systems, to ensure that the patient is able to understand it. It is also likely that such a solution would want to incorporate some high level details about pathways relevant to the patient‟s condition. It is also likely to provide links to relevant self-care, eLearning and structured education resources, as well as a directory of local services.

5.6.2.2. GP System Patient Access

Many GP system suppliers now offer some form of patient access solution to allow patients to access their GP record via a secure web portal. If the GP system holds the care plans, using this solution to give access to patients may be an option worth exploring. It is likely that patients would need to be given some guidance on the use of such solutions, as they are likely to expose much more detailed clinical record information than a solution focused primarily around care plans.

5.6.2.3. Patient Registration and Identification

In order to allow patients to access any clinical information that is held on them, there is a need to have robust access control mechanisms to ensure that the information is available only to the patient to whom it relates. This needs to include a robust process for verifying the identity of the patient when they register for access to the online service. The QIPP Digital Technology team has developed some guidance around this, which is available from our NHS networks page [Ref:6]. Local teams looking to develop patient access solutions should review this guidance to ensure that their solution is robust and aligned to national IG policies.

5.6.3. Sharing or Updating of Partial Plans

In this document we have generally referred to a “care plan” as a single entity. This does not necessarily have to be the case however. The patterns outlined could also apply equally well to a section or component of a plan, rather than a complete plan. This may be useful if different parts of a plan are managed or owned by different participants. For example, a plan may include personal goals and activities that are owned by the patient alongside clinical goals and activities owned by the patient‟s GP. These two aspects can still be brought together to form a single shared “plan”, but different owners (or even different patterns) could be used for the different parts of the plan as long as any systems that display the plans are able to display a combined view of the various parts.



5.6.4. Transport Mechanisms

The core concept in ITK is separation of content from transport. This supports the interoperability and extensibility aims and allows business functional specialists to concentrate on information content, flows and events. It allows a consistent infrastructure to be supported that is capable of evolving rather than requiring disruptive change. This means therefore, that local teams wanting to implement ITK solutions will need to decide on what “transport” mechanism to use to carry the messages. There are currently two standard options that could be considered:

SOAP 1.1 over HTTP/TLS

DTS (the NHS Data Transfer Service) In the future, there is an intention for TMS (Transaction Messaging Service for the national Spine infrastructure) to be a transport mechanism also, and other transports could be considered and discussed with the ITK team if desired. Whichever transport is chosen, the specific implementation of that transport (e.g. establishing relevant middleware for routing SOAP requests, etc.) would need to be identified and established locally. Some ITK accredited middleware solutions exist which could be procured (see ITK web site for list of accredited systems). Also, a locally developed or open source solution could be considered. The ITK specifications include a standard mechanism for “addressing” messages so they can be routed, but the local mapping of these addresses to end-points (e.g. URLs for the SOAP calls) would also need to be locally defined and agreed.

5.6.5. Workflow & Collaborative Authoring

Depending on the approach taken for managing updates, thought may need to be given to the processes for authoring and reviewing care plans. This is especially important if there is no single “master” copy of the plan held in a designated repository. If this is the case, then a local process or workflow may be required to ensure that updates are co-ordinated properly. This may require the use of a workflow management tool or capability within the various systems used in the care planning process. If different parts or aspects of a care plan need to be authored by different participants, this may also drive a need for a workflow to manage the co-ordination and bringing together of these parts into a single agreed plan. The ITK specifications do not provide any specific workflow support, and this would need to be considered and developed locally if it is required.

5.6.6. Historical View

One of the advantages of maintaining patient information in a clinical system is the ability to see the history of changes over time. If clinical systems hold “pointers” out to other systems holding certain information (e.g. care plans), the historical view of this information can be lost. The ability to see a history if changes within whatever system is holding the care plan should be considered, and this may require the ability to request previous versions via any messaging interfaces that are developed.



5.6.7. Content and Clinical Coding

This document primarily focuses on the mechanisms for sharing care plans, rather than the actual content within them. In order to begin standardising content, and potentially allow content from care plans to be re-used, aspects such as clinical coding need to be considered. Whilst much of the content in a personalised care plan may be free-text, there is often some content which is captured and held in clinical systems in a coded form. An example may be medications or diagnoses, which may be held as READ2 or CTV3 coded entries within GP systems. Many of the existing ITK specifications allow for coded content to be included within messages, and the CDA specifications allow for both a coded and textual version of information to be transmitted. In this way, any system which is unable to interpret the coded content can simply render the textual content for a human to interpret. In the longer term, there is also the potential for allowing machines to act more intelligently on coded content within care plans. HL7 Arden [Ref:] is an example of a syntax for applying artificial intelligence to process clinical content and make decisions (e.g. generating alerts or diagnoses) based on a predefined “Medical Logic Module”. It is possible to use any coding system for coded content (including locally defined codes), although the preference from a strategic perspective is SNOMED CT®. The use of SNOMED CT® has been endorsed by the ISB [Ref:24], and there is an intention to stop maintaining many other coding systems in the future in favour of SNOMED CT®. There is more discussion of content and coding later in this document.

5.6.8. Reporting and monitoring of outcomes

A key objective of sharing care plans is to support improvements to patient care and outcomes. In order to achieve this it is important that good measurements can be made of improvements in outcomes. It is also important that any gaps or unmet needs that are identified as part of the care planning process can be identified. These issues all rely on being able to provide good quality reporting using the data captured within the care plan, and as part of the care planning process itself. Details of this reporting are beyond the scope of this document, but local teams should consider their information and reporting needs as part of developing care planning capabilities to ensure that they are able to produce the outputs required. A major challenge in this is that a personalised care plan should be driven by a patient, and ideally not constrained to a predetermined “pick-list” of coded items. A balance needs to be reached that allows the various goals and activities in a care plan to map to coded values wherever possible (even if only at a generic “category” level – e.g. “Activities of Daily Living”), to facilitate subsequent reporting and analysis.



5.6.9. Integration with Non-NHS Organisations

There are a number of additional challenges when approaching integration with non-NHS organisations (e.g. Local Authorities, 3rd Sector Organisations). This is not an exhaustive guide, but some key points are outlined below.

5.6.9.1. IG Statement of Compliance

Any organisation wanting to store or process patient information needs to adhere to a number of important security and information governance principles. There is a IG accreditation process that organisations must go through to ensure they meet these minimum standards. This is known as an IG Statement of Compliance (IGSoC) [Ref:25]. This is also a prerequisite for connecting to the N3 network.

5.6.9.2. N3 Connectivity

In order to share patient identifiable information in a secure way, it is generally necessary to be connected to the N3 network. This is generally done in one of two ways:

Purchase a dedicated N3 Link from BT

Local authorities can look to use a GCSX-N3 gateway to allow their network to connect to N3 [Ref:26]

5.6.9.3. Use of NHS Numbers

All clinical systems must allow the use of NHS numbers as an identifier for patients, so this is a logical identifier to use for identifying which patient a care plan relates to. Unfortunately, most non-NHS organisations are unable to record (or more importantly verify) NHS numbers, as these are held within the Personal Demographics Service (PDS) which is not easily accessible outside the NHS. Once an organisation has gone through IGSoC and has connectivity to N3, there are a couple of options for getting NHS numbers linked to local records:

Demographics Batch Service (DBS) [Ref: 15]: This is a batch service that can be used to submit a list of patient demographics, and receive back up-to-date demographics and NHS numbers for those patients that were matched with PDS.

Personal Demographics Service (PDS) [Ref: 12]: Alternatively, your local systems supplier could build in functionality to integrate directly with PDS. This would require development of the Spine interfaces, and the supplier would need to take their product through the Common Assurance Process (CAP). This generally takes significantly longer, but allows for richer integration capabilities (such as being able to update the record on PDS).

5.6.9.4. NHS Business Partners Team

There is a dedicated team within Connecting for Health who can provide support to non-NHS organisations wanting to access NHS services (such as PDS). They also provide a useful “mini-guide” document on their website outlining the various challenges in more detail [Ref:27].



5.6.10. Information Governance

A full discussion of the information governance requirements for the sharing of care plan information is beyond the scope of this document, but some specific aspects are presented here for consideration. Specific IG considerations around the use of ITK specifications are detailed in the “trust operating model” that is distributed with the specifications (see the ITK Implementation support section 7.5 for more details).

5.6.10.1. Single Sign On (SSO)

Where care planning information is spread across multiple systems or local repositories, having a consistent access control mechanism for clinicians is important. If a clinician has to remember multiple usernames and passwords this is likely to hamper uptake. Within the NHS there is already a robust SSO mechanism in place using Smartcards, so this should be used in all cases. Access for non-NHS users (e.g. local authority) may be more problematic – see sections 4.3.3 and 5.6.9 for a discussion of considerations for these other settings.

5.6.10.2. Role Based Access Control (RBAC)

It is important when mapping out the various parties who will participate in the sharing of care plans to understand the role each will play, and therefore the access rights they need to have within systems that are sharing care plans. There is a national role based access control solution in place within the NHS linked to Smartcards and administered by Registration Agents (RAs). This should be used wherever possible, but in cases where users without smartcards need to access information (e.g. patients), a suitable set of controls will need to be implemented. This is a key requirement in line with the NHS care record guarantee [Ref:28]:

“Show only those parts of your record needed for your care”

5.6.10.3. Legitimate Relationships

Another key obligation under the care record guarantee is: “Allow only those involved in your care to have access to records about you from which you can be identified, unless you give your permission or the law allows”

Most clinical systems include a mechanism for ensuring that only individuals involved in the care of a patient can access clinical details about that patient. Similar controls would need to be in place for any system sharing or displaying care plans.

5.6.10.4. Consent

Before sharing a patient‟s care plan details with anyone else, it is important to ensure that the patient has given their informed consent for this information to be shared to support their care. The details and mechanisms for this are beyond the scope of this document, but would need to be considered in the same was as for sharing any other type of clinical information about a patient.

5.6.10.5. Data Sharing

As this document focuses on the sharing of care plans, it is very likely that this will involve sensitive personal data being shared between different organisations. Such sharing may necessitate a data sharing agreement to be agreed between those organisations. Such data sharing agreements should cover the details of what is being shared, and the specific purpose of sharing the information. The QIPP digital technology team has produced some specific guidance about data sharing for risk stratification [Ref:6], much of which would apply equally well to the sharing of care plans.



5.6.11. Content Becoming Out of Sync

Wherever more than one copy of a care plan exists, and updates can be made to the content of care plans in more than one location, there is always a risk that content could become out of sync. There is a need therefore to incorporate mechanisms for dealing with this when it occurs. Thought needs to be given to ensuring anyone who has a copy of a care plan is notified whenever it changes, and potentially also for an updated version to be sent to them to avoid some copies of the plan becoming out of date. In some cases, updates may be made to a care plan in more than one place, in which case there is a need to incorporate a manual reconciliation process to “merge” the conflicting versions or updates. An example of this is the side-by-side comparison screen in systems that link to PDS. Where a local update has been made that may conflict with an update made elsewhere the comparison screen allows a clinician to see both versions of the information in PDS so they can select which are the correct values for each field. A similar approach is used within version control tools, which typically offer some form of “diff” tool to show the differences between conflicting updates to a file. In some cases it may be enough to allow a clinician to pick which overall plan update is the correct one rather than merging individual pieces of each update (this should be carefully considered however to ensure important data is not lost). Where copies of care plans are sent between recipients, there is also the consideration of the implications of “onward sharing” of this information with other recipients. The original sender of a document may not be aware that it has been shared with others, and will therefore not inform them of any updates that have been made. Any onward sharing would need to be considered therefore, and controlled within systems.

5.6.12. Identifying Recipients

When pushing out messages (e.g. notifications or copies of care plans) to relevant recipients, there is a need to agree a way of identifying who those recipients are, and what systems they are using, to ensure messages are routed accordingly. This may be a simple local agreement that defines the members of an integrated team, who then receive all care plan messages. A more likely scenario however is that the individuals involved in the care of the patient would be captured in the system that holds the care plan (they may actually be held in the care plan itself), and this is the list that is used to identify the recipients for messages relevant to that plan. Another more general approach is to create a publish/subscribe model, where clinicians can “subscribe” to updates for a patient or group of patients. Any updates are then published to the list of “subscribers”. This would require that the system holding the plans (or some other system – perhaps a middleware component) is able to hold and maintain the list of subscribers and route messages accordingly. Another approach is to “broadcast” updates to all recipients who are able to receive them, and let the recipient system decide whether it is of interest or not. The ITK specifications support both direct sending and broadcasting of documents.



5.6.13. Click-Through and Context Management

Although it is generally preferable where possible to share information electronically so that it can be presented in a consistent way in clinical or portal systems, sometimes this is not possible or practical. In such cases a useful compromise may be to allow a user to “click-through” from one system into another, within the context of a specific patient. For example, if a GP is using their clinical system to review a patient‟s record and comes across a flag indicating that the patient has a care plan, they could click on a “link” which would transfer them to the system holding the care plan, and display the plan for that patient. This requires that some “context” be passed between systems (e.g. NHS number of patient, identity of user clicking-through, etc). It also raises questions about whether the system “context” needs to remain synchronised when the GP switches to a different patient record – i.e. should the care plan in the other system automatically close, or should it automatically switch to a view for the new patient. There is an existing standard for the sharing of context across applications called CCOW (Clinical Context Object Workgroup) [Ref:23].

5.6.14. Reviewing and Applying Changes to the Plan

Regardless of which approach is taken for the sharing of care plans, there will still always be a need for human judgement in reviewing any changes to plans that have been shared. This is especially acute when the pattern chosen for managing changes is “Manual / Ad-Hoc”, but it does also apply in the other patterns (although it is generally easier to manage). If there is a single owner who applies updates, that owner will need to review any updates other clinicians have requested be added to the plan, and decide what and how to apply the changes. Similarly, when synchronising with one or more repositories, any differences between the new information being added and the information previously held in the repository/repositories will need to be assessed. The problem is exacerbated when content becomes out of sync (see section 5.6.11 for a discussion of this).



5.7. Pattern Maturity

Generally speaking, any of the architectural patterns outlined in this document could be used to support any of the business scenarios, but the below table attempts to show a potential progression from a short-term basic integration, up to some patterns that could be applied in the longer term as local system capabilities (and national ITK specifications) mature. This should in no way be considered prescriptive in the patterns that should be used at different stages in the development of local solutions.

Maturity Architectural Patterns

Discover / Locate Care Plans:

Sharing / Accessing Care Plans

Managing Changes to Care Plans

Low (Short Term)

Local Agreement Push: Send Copy

Manual / Ad-Hoc

Lookup List View In-Situ: Single Shared System

Single Owner





Federated Local / Regional Registries


Medium (Medium Term)


Manual / Ad-Hoc


Single Owner







High (Long Term)


Manual / Ad-Hoc


Single Owner









6. Mapping Patterns to Business Scenarios It is important to understand how the various architectural patterns outlined in this document could map to the various business scenarios for sharing care plans. The below examples show how the patterns could be applied – these are not prescriptive, but should serve to demonstrate possible options for the various scenarios.

6.1. GP Refers to a Community Team for Care Planning

6.1.1. Short Term Example

Architectural Patterns Used in this Example:

Discover / Locate:

A Local Agreement

In this example, care plans are held by the community team in their clinical system, and this is agreed between the various providers in the region.

Sharing / Accessing Care Plans:

B Push: Send Copy A copy of the full care plan is sent electronically to the GP and specialist teams.

Version Control / Synchronisation

C Manual / Ad-Hoc

Because the care plans are held within the community team‟s clinical system, only the community team can create or update care plans. Any updates made by other care professionals would be made in their “copy” of the plan, and a manual process followed to ensure the changes are reflected in the plan held by the community team, who would then push out an updated version.

The patient visits their GP or practice nurse

to discuss the management of their long term condition(s)


the patient should discuss how best to manage their

condition(s) with a specialist

nurse, so refers them to the specialist community team.

Care Plan

1

23

4

GP / Practice

Nurse

Community

Team

A copy of the care

plan is then sent to the GP/Nurse for

their information.

The community team

works with the patient to create a care plan, and

makes it available to the

patient so they can review and update it themselves

as they manage their condition.

Acute Care

Teams

The care plan is also

sent to acute care teams

5

B, C

B, C

A

Care Plan

Care Plan



6.1.2. Medium Term Example


Discover / Locate:

A Notification With

Pointer

In this example the care plans are all held in the community system, and whenever a plan is created or updated a notification is sent out to the other systems involved (GP and Acute systems), with a pointer back to the care plan in the community system.


B View In-Situ:

Single Shared System

The GP and acute systems don‟t hold a copy of the care plan itself, but they may hold a “flag” against the patient record to indicate that a plan exists. They would then use the “pointer” to direct the user to the community system to view the plan (possibly using a “click-through” mechanism). This could be fronted by a clinical portal to facilitate access for other team members.


C Single Owner

In this example only the community team are able to update the care plans, with others having read-only access. This relies on a business process that revolves around the community team being involved in and aware of all the care for the patient, and it is likely that this would only work in tightly integrated local teams. In some cases, the GP may be better placed to be the “single owner” and maintain the care plans.

The patient visits their GP or Practice Nurse to discuss

the management of their long term condition(s)



condition(s) with a specialist


Care Plan

1

2

3

4

GP /

Practice

Nurse

Community

TeamA notification is

sent to the GP system, with a

pointer to the care

plan held within the community system

The community team

works with the patient to create a

care plan, and

makes it available to the patient so they

can review and update it themselves

as they manage their

condition.

Acute Care

Teams

A notification and pointer is

also send to the acute care teams.

5

A

A

Pointer to

Care Plan

5

When the GP /

Nurse next sees the patient, they

can see that a

plan exists, and log in to the

community system to view it

Pointer to

Care Plan



6.1.3. Long Term Example


Discover / Locate:

A Federated Local

Registries

A registry has been created for the local region, which maintains an index of all patients who have care plans (and the type of plans held). Each entry includes a pointer to the repository that holds the plan. This registry is federated with other registries to allow a single logical view across all local registries nationally.


B Pull:

Retrieve From Shared Repository

The patient‟s care plan is being held in the community system, which is acting as a “repository” and exposes the relevant interface to allow systems to retrieve care plan documents on demand, and send updates back to be stored.


C Synchronisation with

Central Repository

As each care setting encounters the patient, they query the registry to locate the plan, and access the repository holding the plan to synchronise it with their local system. Any changes that are made are then updated back into the repository.

The patient visits their GP or Practice Nurse

to discuss the management of their long term condition(s)



condition with a specialist


Care Plan

1

2

3

4

GP / Practice

Nurse

Community

Team

An entry is added to the local

registry, with a pointer to the plan in the community system

The community team

works with the patient to create a

care plan, and

makes it available to the patient so they

can review and update it themselves

as they manage their

condition.

Acute Care

TeamsWhen the acute team next

see the patient, their system queries the registry

and identifies the

community system as the repository holding the plan.

8

B

A

Pointer to

Care Plan

When the GP /

Nurse next sees the patient, their system

queries the registry

and finds that the community system

is the repository holding the plan for

the patient

Registry

5

6

The plan is

synchronised with the GP system

Care Plan

The plan is synchronised

with the acute system

7

Care Plan

Links with

other registries

C

C



7. Using the Interoperability Toolkit (ITK)

7.1. Introduction to ITK

Interoperability within the NHS is becoming an increasingly important topic. Improving interoperability is one of a number of changes which has the potential to improve efficiency while also improving patient experience and healthcare outcomes. One technique that could radically improve interoperability would be the wider adoption of a smaller set of integration methods and the NHS Interoperability Toolkit (ITK) initiated by the Department of Health is one major activity aimed at achieving this. The ITK provides a set of specifications for all Healthcare ICT implementations to adopt with the intention of eventually producing an NHS in which connectivity is easy and in which new, creative and previously impossible uses of NHS data can be achieved. There are a number of resources available to support local organisations and suppliers in developing and accrediting ITK-compliant solutions. A summary of the resources, and the relevant contact details for the ITK team is their web site [Ref:17], including a catalogue of the suppliers and systems already accredited against the various ITK specifications.

7.1.1. Benefits of the ITK

ITK reduces the cost of interoperability by creating standard interfaces between your systems

Benefits to your organisation o Immediate benefits within your organisation

A carefully designed set of standards ready to go “One better” than standard SOA transformation

o Benefits will increase over time As more organisations utilise the ITK you will benefit from

additional pluggable functionality

Benefits to the NHS o Economies of scale o More joined up / patient centric services

7.1.2. Building on Existing Standards

The ITK uses currently existing standards such as WS-Addressing and HL7. It defines how these standards should be used and over what transport mechanisms they can flow. As such the ITK can change and adopt new standards where they introduce abilities not yet available in the ITK set.

7.1.3. What actually makes up the ITK?

As a standard the ITK contains three sets of specifications:

The transport specifications

The payload specifications

The trust operating model

7.1.3.1. The transport specifications

The ITK transport specifications describe the minimum data that should be carried in any ITK message in order to identify and route it. They include descriptions of a header and explanations of the common ITK patterns. They describe the responsibilities of a sender and receiver of a message.



7.1.3.2. The payload specifications

Once a system can send an ITK message it is useful to agree what particular messages might look like. The ITK describes such payloads using „Domain Message Specifications‟. These documents describe what a particular payload, such as a discharge or urgent care message, should look like. They include XML message schema and descriptions of allowable SNOMED code sets.

7.1.3.3. The trust operating model

For trusts that are looking to purchase or build an ITK compliant system the trust operating model provides guidance on what checks should be made to ensure a safe implementation. It covers high level architectural considerations, Information Governance and Clinical safety. It provides suggested text for including in a procurement contract and a checklist of items a trust should consider. In fact most of the guidance in this document is probably useful and applicable to any healthcare integration scenario.

7.2. What clinical domains are currently supported

In theory it is quite allowable for an organisation to implement the ITK transport specification and carry their own defined payloads (see section 5.4.1). In addition, the Non-Coded CDA domain messages within the correspondence package are capable of carrying many types of information and binary attachments in a manner that still usefully identifies the author and the patient (see section 5.4.2). The content can still be defined by the local implementation. However, specific content has also been created for certain domains. The following diagram summarises the document set provided by ITK and also shows the domains in which further more specific messages have been developed.

Figure 4 - ITK Specifications and Domains

7.3. Accreditation

Like any standard, healthcare organisations and suppliers are able to use the ITK specifications independently. However, even greater value is gained when products undergo ITK accreditation. Users of such products can be assured of a minimum



level of tested interoperability and conformance with the ITK specifications and this minimises the additional work that might be required to plug in an ITK interface.

7.4. Technology Reference data Update Distribution (TRUD)

All the published ITK specifications are available from TRUD [Ref:29], either directly from the web site, or via a TRUD FTP site. The content on TRUD is divided into sections covering the various specifications and data sets that are available. You will need to register for access to TRUD, and depending on which sections you request access to you may have to agree to terms of use or license restrictions. At the time of writing, the “NHS Interoperability Toolkit (ITK)” section on TRUD contains the following “sub-packs” that can be downloaded:

NHS Interoperability Toolkit Core

NHS Interoperability Toolkit Accreditation

NHS Interoperability Toolkit CDA Functional Requirements

NHS Interoperability Toolkit Correspondence

NHS Interoperability Toolkit Dashboards

NHS Interoperability Toolkit Health and Social Care Integration Domain Message

NHS Interoperability Toolkit HL7v2

NHS Interoperability Toolkit Specifications Reference Pack

NHS Interoperability Toolkit Spine Mini Services The “Core” sub-pack is a common framework on which all ITK functional sub packs rely. It includes details of interaction patterns, acknowledgements, error handling, audit trail and security. This includes the transport specifications and the trust operating model. The “Correspondence” sub-pack contains the domain message specifications for the various correspondence domains. This includes the “Non-Coded CDA” domain referred to earlier in this document. The “Health and Social Care Integration Domain Message” sub-pack contains the HSCI domain messages, including the “Integrated Care and Support Plan” message mentioned earlier in this document.

7.5. Implementation Support

In addition to the resources on TRUD, there are a number of other ways that local teams and/or suppliers can get support in the development of ITK implementations. The Interoperability Toolkit team can help to arrange access to the below resources, so the first step would be to get in contact with the ITK team via the contact form on their website [Ref:17].

7.5.1. ITK Roadmaps

The ITK team are able to meet with local teams (either in person or over a conference call), and produce a high level “roadmap” to summarise the local systems landscape and identify possible interoperability opportunities. This can help to inform local teams of what specifications exist and how they can be applied to local interoperability needs.

7.5.2. HL7 Courses

There are courses available which cover the basic HL7 concepts in more detail, which may be of use for developers wanting to develop messaging that incorporates CDA documents. These are commercial courses, so there is a cost implication for this.



7.5.3. Workshops with Interoperability Team

The interoperability team within Connecting for Health are able to offer workshops with suppliers to walk them through the ITK specifications and the relevant CDA domains.

7.5.4. NICA walkthroughs and development workshops

The “National Integration Centre and Assurance” team are responsible for accrediting ITK implementations, and are able to offer a more detailed workshop with developers, and can even help with some hands-on development work as part of that workshop.

7.5.5. Green CDA

Because the “on the wire” representation of CDA messages is relatively complex, and much of the content is standard across all implementations, a simplified “green” CDA format has recently been developed. A message created in this simplified format can then be transformed using XSLT into a full CDA format for transmission. The relevant XSL files to translate to/from “green” CDA for the Non-Coded CDA message domain are included in the files available from TRUD.

7.5.6. Open Source CDA Libraries

There are also libraries and tools available both commercially and from the open source community, which can help in the construction of CDA documents. A good source of open source tools relating to ITK is the eHealthOpenSource site [Ref:30], although many other resources exist. The ITK team in Connecting for Health may be able to help advise what tools may be available.



8. Wider Context and Supporting Resources This document focuses on the approaches for sharing of care plans, and how the existing ITK specifications can allow information to flow between systems. There are of course other important wider considerations in relation to care planning, including the actual content of plans, clinical coding, and the associated professional standards around that content.

Figure 5: Overview of the care planning process incorporating the key record update points

8.1. Clinical Content

There are a number of drivers for standardising the clinical content within care plans, not least the growing need to support complex patient pathways across multiple care providers. It is also a key enabler for delivering meaningful and consistent metrics and outcome measures to support commissioning standards. In the case of end of life preferences, there is an information standard that defines the core clinical content [Ref:7], but no such standards exist for other types of care plan.

8.1.1. Clinical Coding

In order for the information within a care plan to be incorporated into clinical records, reported upon, and potentially re-used it needs to be machine-readable. In order for



the content to be machine readable some form of machine readable clinical terminology needs to be used to ensure consistent definitions apply to the information so that it can be interpreted safely. Most clinical systems support some form of clinical coding, with GP systems typically using either READ2 or CTV3, and some other systems using SNOMED CT®. The strategic option for clinical coding in the NHS is SNOMED CT®, which is a much richer and more expressive coding system than READ2 and CTV3, and has been agreed as an ISB standard under ISN0034 [Ref:24]. As SNOMED CT® is an international standard, its use also helps to open up opportunities for wider sharing of data, but also for use of products and services from suppliers outside the UK.

8.1.2. Existing Content / Coding Capabilities

There is a team within the Data Standards and Products area in Connecting for Health who have been developing some standards for the content of care plans. They have produced a document entitled “Care Planning Content Technical Guidance”, which is available from TRUD [Ref:29] in the “NHS Care Planning” package. This document provides technical guidance to support the implementation of care planning content in clinical systems, and the use of SNOMED CT® in care planning functionality. There is a set of SNOMED CT® coded content already available from TRUD, which includes some pre-determined and clinically validated “templates” as well as collections of coded “activity bundles” that can be used within care plans for predetermined combinations of “Needs”, “Goals” and “Activities”. These have been primarily developed to support treatment plans used in an acute setting, but much of the content could be re-used within a personalised care plan, and more activity bundles could easily be developed to cover any areas not already covered.

Any organisation implementing this content should have access to experienced clinical, technical and terminological input to any project team. Contact the Knowledge and Strategic Alignment team at NHS Connecting for Health for assistance.

Key Contact Details

Knowledge & Strategic Alignment: [email protected]

8.2. International Standard

The content standards being created by the Data Standards and Products team are being developed alongside an international standard covering the basic concepts of care planning called ContSys (ISO 13940). This is not aiming to standardise the detailed coded entries that would form part of a care plan, but rather to agree standard definitions for the basic concepts within care planning. The Data Standards and Products team are involved in the drafting of the standard, and its content will inform future versions of the NHS Data Dictionary as well as future iterations of the clinical content guidance.

8.3. National Year of Care Programme

The Year of Care Programme [Ref:31] set out to demonstrate how routine care can be redesigned and commissioned to provide a personalised approach for people with




long term conditions and has successfully learned how to do this using diabetes as an exemplar. The Team previously housed by Diabetes UK and supported by NHS Diabetes is now hosted by Northumbria Healthcare Foundation Trust as „Year of Care Partnerships'. A three year Pilot Programme across three diverse health communities worked to demonstrate how to make routine consultations between clinicians and people with diabetes and other LTCs truly collaborative via care planning, and then to describe how local services people need to support them are identified and made available through commissioning of NHS services as well as commissioning non-traditional providers to support self-management (via a guide entitles “Thanks for the Petunias” available from their web site). Care planning is now the norm for people with diabetes and other LTCs in pilot sites. This approach has multiple benefits for people with diabetes and other LTCs, clinicians and commissioners. The key aspects that enable this change are:

Sending out test results with a short explanation and agenda setting prompts in easily understood language ahead of the annual care planning review (this allows people to sit down and think about their condition, talk it through with their family and carers and decide what their specific goals are for the coming months).

A patient centred consultation delivered by the health care professional committed to partnership working, which explores and discusses agendas and helps individuals develop their own goals and actions.

Goal follow up. The YOC team has been asked by the National QIPP LTC Workstream to provide the grass roots training and support for the self management support driver of the National LTC QIPP agenda. Care planning (citing the YOC approach) is one of 13 National Quality Standards for Adults with Diabetes published by NICE to support the work of the National Commissioning Board. The YOC approach has also been tested in COPD, health checks, and cardiovascular disease in primary care. A yearlong project funded by NHS Northeast also tested the applicability of the approach to other LTCs within 12 practices across the North of England.

Key Contact Details

Year of Care Programme: [email protected]

8.4. Professional Guidance

The “Year of Care” care planning approach was adopted by the Royal College of General Practitioners (RCGP) council in early 2011 as the basis for professional training of GPs. A clinical lead for care planning is leading this work on behalf of the College and is working closely with the YOC Programme to ensure that the resources and support that clinical teams need to enable them to adopt this new way of working are available. The Clinical Innovation and Research Centre within the RCGP has produced some professional guidance on care planning based on the Year of Care approach, which is available from their web page [Ref:32].




The RCGP has also produced some Shared Record Professional Guidance, which includes some useful guidance on shared records [Ref:37]. It is likely that as work progresses on standardising the content and coding standards for care planning, further professional guidance may be required to support its safe implementation into clinical practice.

8.5. QIPP Support

8.5.1. Long Term Conditions Workstream

The QIPP long term conditions workstream have a collection of useful resources relating to the three key drivers (risk stratification, integrated neighbourhood teams and systematising self-care and self-management) on their NHS Networks site [Ref:3]. This includes example artefacts and best practice from local teams across the country. In addition, the LTC workstream are hosting a series of regional workshops as part of a regional commissioning development programme, to discuss the key drivers and how they are being addressed in each region. There is a timeline of these events available from the NHS networks page [Ref:33].

Key Contact Details

Long Term Conditions Work-stream: http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/contact-us

8.5.2. End of Life Workstream

The QIPP End of Life workstream has been merged into the National End of Life Care Programme, and there are a range of resources available from their website [Ref:5]. A key deliverable recently produced by the end of life care programme is the ISB standard for the core clinical content to support end of life care co-ordination [Ref:7].

Key Contact Details

National End of Life Care Programme: [email protected]

8.5.3. Digital Technology Team

The QIPP Digital Technology team is working with the national QIPP workstreams and local teams to develop “National Enablers” (including this document) to support local delivery technology solutions in support of QIPP drivers.

Key Contact Details

QIPP Digital Technology Team: [email protected]

8.5.3.1. NHS Networks

The resources developed by this team are available from the Digital Technology and Vision NHS Networks site [Ref:6].

8.5.3.2. Initiatives Register

Also on this site is an “initiatives register” which is a list of local digital technology initiatives. The aim of this register is to share best practice from across the NHS on the use of technology, and the content of this register will develop over time as we work with more local teams.

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/contact-us

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/contact-us





8.5.3.3. Discussion Forum

There is an online discussion forum hosted on LinkedIn [Ref:34], which will include a discussion thread for each enabler. This will allow individuals to discuss the content and ways that they have used the guidance to implement local solutions.



9. Recommendations Below is a recommended set of steps to take the guidance in this document and apply it to a local project:

9.1. Review Best Practice

Before attempting to map out your requirements, review best practices and approaches used elsewhere to see if there are opportunities to re-use work or join forces with other teams.

Review this guidance document in full, along with any other relevant “enablers” published on the QIPP Digital Technology and Vision site.

Review the Initiatives Register on the QIPP Digital Technology and Vision site to see what other teams are developing (or have developed) in relation to care planning.

Review the online discussion forum on LinkedIn to get tips or advice on using the guidance in this document.

Review the content published by the QIPP LTC Workstream on their NHS Networks site, as well as the Year of Care and RCGP guidance documents.

9.2. Business Requirements

Map out the local participants who will be involved in the sharing of care plans. This should include organisations and teams involved, and IT systems used.

Identify the types of care plans you want to share, what their content should be, and who should have access to create, read and update plans.

Identify the business scenarios for sharing of care plans between teams.

9.3. Technical Requirements

Identifying an appropriate set of architectural patterns (based on those outlined in this document) for:

o Discovering / Locating Care Plans o Sharing Care Plans o Managing Updates to Care Plans

Identify other implementation considerations (e.g. IG), and agree how each should be approached.

Build a roadmap for the development of the architectural patterns and capabilities – this should include immediate plans as well as longer term objectives/patterns.

Decide on the clinical coding scheme that will be used to represent coded content, and ensure all systems are able to use any coded data safely.

9.4. Delivery

Engage suppliers or in-house developers to deliver the required capabilities. Ensure that funding is in place to develop the required integration capabilities

in-line with the requirements and roadmap developed above. Ensure suppliers are bought-in to using a standards-based approach, and are

willing to work with the ITK team to develop solutions, and ideally go through the ITK accreditation process. Note: The ITK specifications available from TRUD include some recommended content for supplier contracts around the use of ITK.

Engage with the ITK team: o Discuss any planned use of existing ITK specifications, and cover any

support that may be needed from the ITK team. o Discuss the potential for developing new ITK specifications to support

the local development roadmap.



10. References

These resources will provide additional information, and are referenced in the relevant sections in this document. Ref no Title Location

1 DH: QIPP Page http://www.dh.gov.uk/en/Healthcare/Qualityandproductivity/QIPP/index.htm

2 DH: QIPP LTC Workstream Page http://www.dh.gov.uk/en/Healthcare/Qualityandproductivity/QIPPworkstreams/DH_115448

3 NHS Networks: QIPP LTC Workstream

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/about-us

4 DH: End of Life Care Workstream Page

http://www.dh.gov.uk/en/Healthcare/Qualityandproductivity/QIPPworkstreams/DH_115469

5 National End of Life Care Programme

http://www.endoflifecareforadults.nhs.uk/

6 NHS Networks: QIPP Digital Technology and Vision

http://www.networks.nhs.uk/nhs-networks/qipp-digital-technology-and-vision

7 ISB Standard: End of Life Care Co-ordination, Core Content

http://www.isb.nhs.uk/library/standard/236

8 Mental Capacity Act 2005 http://www.justice.gov.uk/guidance/protecting-the-vulnerable/mental-capacity-act/index.htm

9 NHS Networks: QIPP LTC Workstream, Integrated Teams Page

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/integrated-neighbourhood-care-teams

10 NHS Networks: QIPP LTC Workstream, Risk Profiling

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/risk-profiling

11 NHS Networks: QIPP LTC Workstream, Integrated Care Liaison Officer Job Description

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/resources-from-the-ignition-phase/onel-integrated-care-documents/Draft_IC_JD_WF.pdf/view

12 Personal Demographics Service (PDS)

http://www.connectingforhealth.nhs.uk/industry/docs/files/pds/index.html

13 Connecting for Health: Spine http://www.connectingforhealth.nhs.uk/systemsandservices/spine

14 Common Assurance Process (CAP)

http://www.connectingforhealth.nhs.uk/industry/compliance/cap

15 Demographics Batch Service (DBS)

http://www.connectingforhealth.nhs.uk/industry/docs/files/dbs/index.html

16 Connecting for Health: Summary Care Record

http://www.connectingforhealth.nhs.uk/systemsandservices/scr

17 NHS Interoperability Toolkit Web Site

http://www.connectingforhealth.nhs.uk/systemsandservices/interop

18 IHE Web Site: Cross-Enterprise Document Sharing (XDS)

http://wiki.ihe.net/index.php?title=Cross-Enterprise_Document_Sharing

19 Additional information in the Summary Care Record

http://www.connectingforhealth.nhs.uk/systemsandservices/scr/staff/impguidpm/createscrs/additional

20 Summary Care Record Training Page

http://www.connectingforhealth.nhs.uk/systemsandservices/scr/staff/impguidpm/training

21 Wikipedia: Eventual Consistency http://en.wikipedia.org/wiki/Eventual_consistency

22 HL7 UK http://www.hl7.org.uk/

23 Wikipedia: Clinical Context Object Workgroup (CCOW)

http://en.wikipedia.org/wiki/CCOW

24 ISB Standard 0034: SNOMED CT http://www.isb.nhs.uk/documents/isb-0034/amd-26-2006/index_html

25 IG Statement of Compliance http://www.connectingforhealth.nhs.uk/systemsan

http://www.dh.gov.uk/en/Healthcare/Qualityandproductivity/QIPP/index.htm

http://www.dh.gov.uk/en/Healthcare/Qualityandproductivity/QIPP/index.htm








http://www.endoflifecareforadults.nhs.uk/



http://www.isb.nhs.uk/library/standard/236

http://www.justice.gov.uk/guidance/protecting-the-vulnerable/mental-capacity-act/index.htm

http://www.justice.gov.uk/guidance/protecting-the-vulnerable/mental-capacity-act/index.htm














http://www.connectingforhealth.nhs.uk/systemsandservices/spine

http://www.connectingforhealth.nhs.uk/systemsandservices/spine
















http://en.wikipedia.org/wiki/Eventual_consistency

http://www.hl7.org.uk/

http://en.wikipedia.org/wiki/CCOW

http://www.isb.nhs.uk/documents/isb-0034/amd-26-2006/index_html

http://www.isb.nhs.uk/documents/isb-0034/amd-26-2006/index_html

http://www.connectingforhealth.nhs.uk/systemsandservices/infogov/igsoc



(IGSoC) dservices/infogov/igsoc

26 Buying Solutions: GCSX-N3 Interconnect

http://www.buyingsolutions.gov.uk/services/Communications/GSi/GSiCommunities/GCSX-N3/

27 NHS Business Partners Team http://www.connectingforhealth.nhs.uk/systemsandservices/businesspartners

28 NHS Care Record Guarantee http://www.nigb.nhs.uk/guarantee

29 Technology Reference data Update Distribution (TRUD)

http://www.uktcregistration.nss.cfh.nhs.uk/trud3/user/guest/group/0/home

30 eHealth Open Source Web Site http://forge.tactix4.net/gf/

31 National Year of Care http://www.diabetes.nhs.uk/year_of_care/

32 Care Planning: Improving the Lives of Patients with Long Term Conditions

http://www.rcgp.org.uk/clinical_and_research/circ/year_of_care.aspx

33 NHS Networks: QIPP LTC Workstream, Commissioning Development Programme Event Timeline

http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions/resources-from-the-ignition-phase/Timeline%20for%20events%202012.pdf/view

34 LinkedIn Group http://www.linkedin.com/groups?home=&gid=4338574

35 Expressions of Interest Letter http://www.dh.gov.uk/en/Publicationsandstatistics/Lettersandcirculars/Dearcolleagueletters/DH_130394

36 Connecting for Health: MIQUEST http://www.connectingforhealth.nhs.uk/systemsandservices/data/miquest

37 RCGP: Shared Record Professional Guidance

http://www.rcgp.org.uk/pdf/Health_Informatics_SRPG_final_ref_report.pdf

38 Connecting for Health: National Laboratory Medicine Catalogue (NLMC)

http://www.connectingforhealth.nhs.uk/systemsandservices/pathology/projects/nlmc

39 Wikipedia: HL7 Arden http://en.wikipedia.org/wiki/Health_Level_7#Arden_syntax



http://www.connectingforhealth.nhs.uk/systemsandservices/businesspartners

http://www.connectingforhealth.nhs.uk/systemsandservices/businesspartners

http://www.nigb.nhs.uk/guarantee



http://forge.tactix4.net/gf/

http://www.diabetes.nhs.uk/year_of_care/








http://www.linkedin.com/groups?home=&gid=4338574

http://www.linkedin.com/groups?home=&gid=4338574

http://www.dh.gov.uk/en/Publicationsandstatistics/Lettersandcirculars/Dearcolleagueletters/DH_130394



http://www.connectingforhealth.nhs.uk/systemsandservices/data/miquest

http://www.connectingforhealth.nhs.uk/systemsandservices/data/miquest





http://en.wikipedia.org/wiki/Health_Level_7#Arden_syntax

http://en.wikipedia.org/wiki/Health_Level_7#Arden_syntax



11. Glossary of Terms

The below list defines the various terms used in this document.

Term Definition

A&E Accident and Emergency

ADT Admission, Discharge, Transfer

AHP Allied Health Professionals

API Application Programming Interface

CAP Common Assurance Process

CDA Clinical Document Architecture

CFH Connecting for Health

CONTSYS System of concepts to support continuity of care

COPD Chronic obstructive pulmonary disease

CTV3 Clinical Terms Version 3

DBS Demographics Batch Service

DHID Department of Health Informatics Directorate

DTS Data Transfer Service

GCSX Government Connect Secure Extranet

GP General Practitioner

GPES General Practice Extraction Service

HL7 Health Level 7

HQL Health Query Language

HSCI Health and Social Care Integration

HTTP Hypertext Transfer Protocol

IG Information Governance

IHE Integrating the Healthcare Enterprise

ISB Information Standards Board

ISN Information Standards Notice

ISO International Standards Organisation

ITK Interoperability Toolkit

LTC Long Term Conditions

N3 National Network for the NHS

NICE National Institute for Clinical Excellence

ODS Organisation Data Service

OOH Out of Hours

PDF Portable Document Format

PDS Personal Demographics Service

QIPP Quality, Innovation, Productivity and Prevention

RA Registration Agents

RBAC Role Based Access Control

RCGP Royal College of General Practitioners

READ2 Clinical Coding System

SCR Summary Care Record

SCRa Summary Care Record Application

SHA Strategic Health Authority

SNOMED CT® Systematized Nomenclature of Medicine Clinical Terms

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SSO Single Sign On

SUS Secondary Uses Service

TLS Transport Layer Security

TMS Transaction Messaging Service (Spine)

TRUD Technology Reference data Update Distribution

URL Uniform Resource Locator

WS Web Service

XDS Cross-Enterprise Document Sharing

XML eXtensible Markup Language

XSL eXtensible Stylesheet Language

XSLT eXtensible Stylesheet Language Transformations

YOC Year of Care



12. Appendix A – Example Rendered HSCI Integrated Care and Support Plan

NHS No. 941 394 6000

Document

Created 19-Aug-2007

Document

Owner Hebburn Council

Authored

by Sharon Adamson - Social Care Manager, Hebburn Council on 19-Aug-2007, 11:20

Integrated Care and Support Plan

Encounter Type Consultation

Encounter Time 19-Aug-2007

Care Setting Type client's or patient's home

Person Co-ordinating Plan: Sharon Adamson, Social Worker, Hebburn Council, tel 0208 321 1212

Support Plan Review Date: 03-Sep-2007

Has a copy of the support plan been provided to the person? Yes Date Provided: 19-Aug-2007

Support plan signed? Yes

Support Plan Summary Mr Jones will be helped to look after himself independently and to improve his mobility both indoors and out of doors. He will be referred to the falls clinic so that they can help identify how

falls could be avoided in future. He will also be referred for support in managing his finances and to consider work options available.

Support Plan Goals Goals are to improve Mr Jones' independence and mobility and to help him to find employment and manage his finances better.



Action Plan Target

Outcome

General Area

of Need

Specific

Area of

Need

Individual Issue Goal Service / Required Action Responsibility Provider Start

Date

Planned

End Date

Information Support

Improved

personal

dignity and

autonomy

Activities of

Daily Living

Can't independently

shower, wash and

dress and maintain

personal self care

without support

Independent and

safe within 3

months

Referral to Community

Rehabilitation Service for daily

visits to practice washing, dressing

and using the shower (1 hour )

Provision of :

2x18" grab rails

27.5" slatted shower board

Adjustable height commode

Referral to Social care OT for

consideration of major adaptations

Claudette Pendry-

King Senior OT

Hebburn

PCT

17-

Aug-

2007

17-Nov-

2007

Leaflet on easier to wear clothing.

Improved

personal

dignity and

autonomy

Mobility Lacks confidence,

affecting mobility

indoors and

preventing him from

going out.

Independent and

safe indoors in 3

months and some

outdoor mobility in

6 months

Referral to Community

Physiotherapyfor weekly visits to

practice walking and re-

assessment of equipment /

provision of equipment if required, including wheelchair for outdoor

mobility

Nick Cotterell-

Chapman, Ward

Physiotherapist

Hebburn

Hospital

Trust

13-

Aug-

2007

13-Feb-

2008

Improved

personal

dignity and

autonomy

Mobility Falls Recent fall at home Reduce Falls risk Referral to Falls Clinic Claudette Pendry-

King Senior OT

Hebburn

PCT

13-

Aug-

2007

Making a

positive

contribution

Access

education

training and

employment

Not able to participate

in paid work

Available options to

have been

discussed within

one month

Referral to Disabled Access Worker

at local Job Centre to offer

consultation

Sharon Adamson 15-

Aug-

2007

15-Sep-

2007

Economic well

being

My finances Needs advice

regarding financial

management

Finances to be

assessed within 8

weeks

Referral to Community Links Sharon Adamson 15-

Aug-

2007

15-Oct-

2007

Improved

personal dignity and

autonomy

Activities of

Daily Living

Managing day to day

tasks

Exercises as detailed in

Community Rehabilitation exercise programme

Barry Jones (Self

Care)

03-

Sep-2007



Crisis Plan In emergency contact Sharon Adamson during office hours on 0208 321 1212 or call Emergency Duty Team out of hours 0208 321 0000

Individual Strengths Mr Jones feels his strengths are his determination and good humour.

Document ID 7D5E5B00-AE1A-11DB-9699-B18E1E0994CD Version 1

Primary Recipient NATIONAL CARE RECORDS SERVICE SPINE

Copy Recipients Claire Osmund - OT Admin, HEBBURN PCT

Natalie Atkinson - GP, PARK VIEW SURGERY

QIPP Digital Technology - NHS Networks · 2012-03-29 · Quality, Innovation, Productivity and...

Documents

Transcript of QIPP Digital Technology - NHS Networks · 2012-03-29 · Quality, Innovation, Productivity and...