24 th September 2012 (Redditch) 27 th September 2012 (Leeds) 4 th October 2012 (London) 10 th October 2012 (London) QIPP Digital Technology and ITK Care Co-Ordination: Interoperability Workshop

Agenda 13:00Background Welcome and Introductions QIPP DT and ITK Overview How Might Electronic Sharing Work? 13:10Notifications Overview Breakout Group Discussion 1 13:55Care Plans and Preferences Personalised Care Plans and Clinical Documents End of Life Care Preferences Breakout Group Discussion 2 14:45Coffee Break 14:55Viewing and Updating Plans/Preferences Viewing Care Plans/Preferences Managing Changes Breakout Group Discussion 3 15:45Conclusion A Pragmatic Approach Questions and Next Steps 16:00Close

Background  QIPP Digital Technology Team QIPP Digital Technology has been established as a function under the QIPP programme to assist QIPP national work-streams and local teams to use digital technology in order to accelerate delivery of their QIPP priorities Integrated Neighbourhood Teams Long Term Conditions End of Life Care National Drivers Electronic Palliative Care Co-Ordination Systems (EPaCCS) Electronic Palliative Care Co-Ordination Systems (EPaCCS) Local Challenges Electronic Sharing of Care Plans Double-Entry of EOL Care Preferences

Current Landscape  Challenges:  Multiple “silos” of information  No single national solution likely  No electronic exchange between systems – relies on double-entry  Differing boundaries make electronic sharing in a standard way a necessity LTC Care Co- Ordination System GP Ambulance Trust LTC Care Co- Ordination System EPaCCS System Community Trust GP Acute Trust Hospice

Interoperability Toolkit  The Interoperability Toolkit (ITK) is:  National standards  Frameworks  Implementation guides  Supports interoperability within local orgs and across local health communities.  Supporting a move away from bespoke interfaces towards unified national specifications – reducing complexity and therefore expenditure within the NHS.  By publishing a series of common specifications and then by assuring the deployment of those specifications through the ITK accreditation scheme, the ITK will bring a level of standardisation to the market.  The ITK is not a piece of software

Care Preferences How Might Electronic Sharing Work?  This is a simple example of how electronic sharing might work: John GP GP SystemCommunity SystemAmbulance SystemEPaCCS System DN John Care Preferences Clinician John  Note: This is only an example!

Notifications  There is a need to notify others caring for the patient when key events occur  Generic mechanism for notifying others of a patient “event” Potential Uses:  Notifying creation/update of an LTC care plan  Notifying creation/update of an EPaCCS record  Notifying of A&E attendance  Notifying change of address  Death notification? Potential Uses:  Notifying creation/update of an LTC care plan  Notifying creation/update of an EPaCCS record  Notifying of A&E attendance  Notifying change of address  Death notification?

Notifications (Contd)  Assumptions we have made:  Should be “FYI” – not an alert!  There is no expectation of action from the recipient  It is NOT a referral!  Content will be limited to very basic details of the event (see handouts)  When a notification is received, there are a number of behaviours that could then be considered:  Add a “flag” to the patient record (e.g. to indicate that the patient has an EPaCCS record)  Prompt a user immediately, or add an item in a “work” queue  Show notifications within a patient record the next time it is viewed.

Break-Out Discussion 1 Notifications  Discuss the Content and Potential Uses – How could I use this?  Questions: Is there a risk if a notification is not received? Who should notifications be sent to and what would they do with them? How would you identify who the notification should be sent to? Should there be a validity period or expiry date for a notification? Other approaches for identifying that a document was created/updated? Are there scenarios where you would filter or ignore notifications?

Personalised Care Plans and Clinical Documents  A central part of care for LTC patients is a personalised care plan  This typically captures needs, goals and activities agreed with the patient  There are currently no agreed clinical standards for this content  this is unlikely to change in the short term.  Guidance already published by QIPP DT team outlines the approaches that can be used for sharing care plans  Similarly, there is a need to share other clinical documents to support care  Current ITK solution for this: “clinical correspondence” specifications  Allows the content to be defined locally  Still provides national standardisation for the common parts – i.e:  The technical mechanism for sending the message  Identification of the patient, clinicians, encounter  Allows other content to be “attached” as Word, PDF, or structured XML

EPaCCS Record  A national information standard was published in March 2012  Covers core clinical content of an EPaCCS record  This forms the basis for a new ITK specification  Content will be based on the information standard (see handouts)  Assumes every locality has a designated EPaCCS system

For EoLC: Is there a need for additional information beyond the core ISB data set? Break-Out Discussion 2 Sharing of Care Plans and Preferences  Discuss Potential Approaches  Questions: Is there a need to allow local teams to add information specific to their area? How much of the information needs to be clinically coded? What kinds of information do you think needs to be shared to support effective care co-ordination? At what points should information be shared and with whom?

 Simpler to implement: recipient doesn’t have to understand the document  Simplifies making changes – information is not duplicated  Simpler to implement: recipient doesn’t have to understand the document  Simplifies making changes – information is not duplicated Viewing Care Plans / Preferences  If a notification pertaining to a clinical document (e.g. a care plan) is received, there are two behaviours that could then be considered: 1)View the document in the original system directly  Referred to as “Click Through”  Information is not integrated into the local record  Different “look and feel”  Potential difficulties with multiple logins, etc  Information is not integrated into the local record  Different “look and feel”  Potential difficulties with multiple logins, etc Potential Use:  Providing access to an EPaCCS record from an Ambulance CAD Potential Use:  Providing access to an EPaCCS record from an Ambulance CAD

Viewing Care Plans / Preferences (contd) 2)Pull the document into your own system  A new “Get Document” specification  Relies on having a notification with a document “identifier”  being able to “query” for a document would be a later phase of development.  Better integration with the local record  Once stored it is always available – no reliance on other systems  Easier for new users to learn – all in one system  Better integration with the local record  Once stored it is always available – no reliance on other systems  Easier for new users to learn – all in one system  More complex to implement  Duplication of information – requires additional controls to ensure content does not become out of date  More complex to implement  Duplication of information – requires additional controls to ensure content does not become out of date Potential Use:  Incorporating EPaCCS record content into a patient’s GP record Potential Use:  Incorporating EPaCCS record content into a patient’s GP record

Managing Changes  A clinical document (e.g. an EPaCCS record) will need to be updated over time:  In the originating system  In systems that have received copies of the document  Whenever information is sent electronically there is a need to ensure it is kept up to date, and that changes are propagated to others.  Assumptions:  A clinical document is treated as a complete document that has been written and signed-off by a responsible carer  This means that any changes require a new document (or version) to be created, again signed-off as a whole  General principle:  There should be a single system (or repository) responsible for ensuring notifications are sent out, and document versions are managed.

Break-Out Discussion 3 Viewing and Updating  Questions: Under what circumstances would it be useful to incorporate the document into the local record rather than “viewing” it in the original system? Are there reasons why you would not want to incorporate the document into the local record in some circumstances? Are there certain care settings where a read-only copy would be adequate? Are there scenarios where a clinician would only be interested in viewing and updating “parts” of a document? Are there scenarios where multiple people would want to update the same document at the same time? Will it always be possible to identify a single system as the “master” copy, and for all updates and notifications to flow from there?

A Pragmatic Approach  You don’t have to solve it all at once!  We need an approach that allows for small incremental steps  This can support a local “roadmap” towards fully interoperable solutions  For example:  Send electronic notifications to all providers  Provide click-through into care co-ordination system  Send electronic notifications to all providers  Provide click-through into care co-ordination system  Add capability to retrieve document electronically into GP and Community systems  Add capability for GPs and Community teams to make changes to documents and send updated versions to the care co-ordination system.  Add capability for GP and Community teams to record initial care preferences and send to care co-ordination system Phase 1 Phase 3 Phase 2 Phase 4

Next Steps  Four workshops being held (including this one) to discuss requirements  Summarised requirements and scenarios will be shared on NHS Networks  A series of follow-up meetings will be held via WebEx  The first of which will be to discuss the outputs from workshops  Subsequent WebEx’s will start to dig down into more details  Draft ITK message specifications will then be presented for discussion  Once we have completed the consultation on the requirements and draft message specifications, they will be published as “release candidate” specifications on TRUD  Current target: December 2012  At that point suppliers can begin developing solutions against these specifications.

Contacts  ITK Team:  QIPP DT Team:  NHS Networks Sites:  ITK:  QIPP DT:  EPaCCS:  LTCs:  Web Sites:  ITK:  QIPP DT:  NEoLCP:

APPENDIX A End to End Example

Example End-to-end Scenario John attends a regular appointment with his GP to review the management of his long term condition. 1 John GP

Example End-to-end Scenario The GP realises that John’s condition has deteriorated, and that he would benefit from moving to an end of life care pathway. 2 John GP

Example End-to-end Scenario The GP explains this to John, and asks if he would like to be put onto a local EPaCCS register so that his care preferences can be shared with those providing his care. 3 John GP

Example End-to-end Scenario John agrees, and the GP records some initial preferences from John relating to his formal carers, preferred place of care, etc. These are recorded within the GP’s system. 4 John GP Care Preferences GP System

Example End-to-end Scenario John The GP confirms on the system that John should have an EPaCCS record, and the core end of life care information is sent in an electronic message to the EPaCCS system covering John’s area. 5 GP Care Preferences GP SystemEPaCCS System Care Preferences

Example End-to-end Scenario John The EPaCCS system receives the record, creates a new record for John, and issues an electronic notification to other providers in the locality. 6 GP Care Preferences GP SystemEPaCCS System Care Preferences Community SystemAmbulance SystemAcute SystemOOH System

Example End-to-end Scenario John The GP refers John to a district nurse, who comes to visit John the next day to discuss his preferences in more detail. The district nurse then records some additional details about John’s carers (including his daughter who has agreed to visit regularly and support John’s care). 7 Care Preferences GP SystemEPaCCS System Care Preferences Community SystemAmbulance SystemAcute System DN OOH System

Example End-to-end Scenario John The district nurse recommends that John see a specialist palliative care nurse to review his pain medication, and John agrees, so the District Nurse arranges for the palliative care nurse to visit John later in the week. 8 Care Preferences GP SystemEPaCCS System Care Preferences Community SystemAmbulance SystemAcute System DN OOH System

Example End-to-end Scenario Later that day the district nurse logs into the EPaCCS system and adds these details to John’s EPaCCS record. Another notification is sent out notifying others that changes have been made. 9 Care Preferences GP SystemEPaCCS System Care Preferences V2.0 Community SystemAmbulance SystemAcute System DN OOH System

Example End-to-end Scenario The palliative care nurse visits John, and confirms that he is happy for his EPaCCS record to be viewed. Using a mobile device, the palliative care nurse registers John in the Acute EPR. This enables John’s full EPaCCS record to be requested. 10 Care Preferences GP SystemEPaCCS System Care Preferences V2.0 Community SystemAmbulance SystemAcute System John PCN OOH System

Example End-to-end Scenario The Acute system issues an electronic request to the local EPaCCS system for John’s EPaCCS record, and his record is returned. 11 Care Preferences GP SystemEPaCCS System Care Preferences V2.0 Community SystemAmbulance SystemAcute System John PCN Care Preferences V2.0 OOH System

Example End-to-end Scenario The palliative care nurse reviews the record and discusses some anticipatory medication that John can have and store at home in case he needs it. John agrees and the details are added to his record, along with the location where they will be stored in John’s house. Once the changes are made, an updated set of preferences are sent electronically to the local EPaCCS system 12 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John PCN Care Preferences V3.0 OOH System

Example End-to-end Scenario The EPaCCS system receives the updated record and updates the local record with the new information. An electronic notification is then sent to other providers in the region. 13 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John PCN Care Preferences V3.0 OOH System

Example End-to-end Scenario Later, John’s condition deteriorates further, and his daughter calls 999 asking for an ambulance because she thinks her father is dying and that he is in a lot of pain. The GP had visited earlier that day and told her that it wouldn’t be long until the end and that he would visit the next day. 14 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John Care Preferences V3.0 OOH System

Example End-to-end Scenario The call handler takes some details, including an address The fact that an EPaCCS record exists for someone at that address triggers a notification on the call handler’s screen, informing them that an end of life care record exists for someone called John at the address. The call handler takes some details, including an address The fact that an EPaCCS record exists for someone at that address triggers a notification on the call handler’s screen, informing them that an end of life care record exists for someone called John at the address. 15 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John Care Preferences V3.0 OOH System

Example End-to-end Scenario The call handler asks John’s daughter if John has previously discussed his care preferences, and she confirms that he has and that he is happy for her to discuss it on his behalf. 16 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John Care Preferences V3.0 OOH System

Example End-to-end Scenario The call is transferred to a specialist nurse, who is then able to click-through into a web-based view of John’s EPaCCS record, and the nurse explains to John’s daughter that the symptoms are caused by his illness, and that John had said that he wanted to be cared for at home at the end. 17 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John Care Preferences V3.0 OOH System Nurse

Example End-to-end Scenario The specialist nurse then explains that emergency medicine has been provided to John to help him manage his pain, and that it is kept in John’s fridge. She also advises that a district nurse is identified in John’s record as a formal carer and as the key worker who is able to visit, to assess and help administer the medication, and John’s daughter agrees to this. 18 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John Care Preferences V3.0 OOH System Nurse

Example End-to-end Scenario The district nurse arrives shortly after and administers the medicine and offers to stay with them. After a while John is very comfortable and John settles that evening. The district nurse leaves but reassures the daughter that she is contactable should she require any further support. John dies peacefully at home the following morning. The district nurse arrives shortly after and administers the medicine and offers to stay with them. After a while John is very comfortable and John settles that evening. The district nurse leaves but reassures the daughter that she is contactable should she require any further support. John dies peacefully at home the following morning. 19 Care Preferences GP SystemEPaCCS System Care Preferences V3.0 Community SystemAmbulance SystemAcute System John Care Preferences V3.0 OOH System DN