QIPP Digital Technology and ITK Care Co-Ordination: Interoperability Workshop

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

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

3. 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 Local Challenges National Drivers Integrated Neighbourhood Teams Electronic Sharing of Care Plans Long Term Conditions Electronic Palliative Care Co-Ordination Systems (EPaCCS) Double-Entry of EOL Care Preferences End of Life Care

4. Current Landscape Acute Trust EPaCCS System GP GP GP GP GP GP GP GP LTC Care Co-Ordination System LTC Care Co-Ordination System GP GP GP GP GP GP GP Community Trust Hospice Ambulance Trust • 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

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

6. How Might Electronic Sharing Work? • This is a simple example of how electronic sharing might work: GP System Community System Ambulance System EPaCCS System GP Care Preferences Care Preferences Care Preferences Clinician DN John John John • Note: This is only an example!

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

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

9. 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?

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

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

12. Break-Out Discussion 2 • Sharing of Care Plans and Preferences • Discuss Potential Approaches • Questions: • 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? • For EoLC: Is there a need for additional information beyond the core ISB data set? • 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?

13. 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: • View the document in the original system directly • Referred to as “Click Through” • Simpler to implement: recipient doesn’t have to understand the document • Simplifies making changes – information is not duplicated • 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

14. Viewing Care Plans / Preferences (contd) • 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 • 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

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

16. Break-Out Discussion 3 • Viewing and Updating • Questions: • 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? • 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?

17. 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 Phase 1 • Add capability for GP and Community teams to record initial care preferences and send to care co-ordination system Phase 2 • Add capability to retrieve document electronically into GP and Community systems Phase 3 • Add capability for GPs and Community teams to make changes to documents and send updated versions to the care co-ordination system. Phase 4

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

19. Contacts • ITK Team: toolkit.enquiries@nhs.net • QIPP DT Team: qippdt@nhs.net • NHS Networks Sites: • ITK: http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk • QIPP DT: http://www.networks.nhs.uk/nhs-networks/qipp-digital-technology-and-vision • EPaCCS: http://www.networks.nhs.uk/nhs-networks/locality-registers • LTCs: http://www.networks.nhs.uk/nhs-networks/commissioning-for-long-term-conditions • Web Sites: • ITK: http://www.connectingforhealth.nhs.uk/systemsandservices/interop • QIPP DT: http://www.connectingforhealth.nhs.uk/systemsandservices/qipp • NEoLCP: http://www.endoflifecareforadults.nhs.uk/

20. APPENDIX A • End to End Example

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

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

23. Example End-to-end Scenario GP • 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. John 3

24. Example End-to-end Scenario GP System GP Care Preferences • 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. John 4

25. Example End-to-end Scenario GP System EPaCCS System GP Care Preferences Care Preferences • 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. John 5

26. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System GP Care Preferences Care Preferences • The EPaCCS system receives the record, creates a new record for John, and issues an electronic notification to other providers in the locality. John 6

27. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences DN • 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). John 7

28. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences DN • 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. John 8

29. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V2.0 DN • 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

30. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V2.0 PCN • 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. John 10

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

32. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 PCN • 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 John 12

33. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 PCN • 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. John 13

34. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 • 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. John 14

35. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 • 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. John 15

36. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 • 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. John 16

37. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 Nurse • 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. John 17

38. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 Nurse • 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. John 18

39. Example End-to-end Scenario GP System EPaCCS System Community System Ambulance System Acute System OOH System Care Preferences Care Preferences V3.0 Care Preferences V3.0 DN • 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. John 19