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

1. QIPP Digital Technology and ITKCare Co-Ordination: Interoperability WebEx1

2. WebEx • We will present the outputs from the recent workshops, and the proposed scope for ITK development. • There will then be time for questions and comments at the end. • During the WebEx all participants will be muted to avoid background noise • Discussion on this WebEx – either: • Use the “raise hand” and I will un-mute you so you can speak, or • Use the “chat” box to ask a question or make a comment • Please ensure you send it to “all” and not just the host! • The WebEx is being recorded, and a recording will be made available on the ITK NHS networks site after the session. http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk

3. After the WebEx • There is an online forum on the ITK NHS Networks site where you can ask questions or make comments • Please “join” the ITK network if you are interested in receiving notifications of future events, and see when new documents are published. You will also need to join to post to the forum http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk

4. 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!

5. Workshops • A series of five workshops were held, with a mix of attendees: • 30 NHS attendees from a range of NHS organisations: • CCG • GP • PCT • SHA • HIS • Hospice • Acute • Ambulance • 15 DH attendees, including: • Informatics • Data Standards • QIPP LTC workstream • QIPP EOL workstream • National EOL Progamme • 9 Supplier attendees from 8 different suppliers

6. Workshop Outputs • The slides and handouts from the workshops are available on the ITK NHS Networks site. • Primary topics that were discussed in the workshops were: • Notifications • Personalised Care Plans • End of Life Care Preferences • Managing Changes to Documents • A summary of the main points captured from the discussion in each of the workshops is available on the ITK NHS Networks site. • We are aiming to develop specifications and publish them as “release candidates” by Dec 2012 / Jan 2013 • We can’t incorporate everything – focusing on basic capabilities to add value, and plan to build on that in future iterations.

7. Notifications • The proposed content of the Notification was included in the handouts used in the workshops. • The proposal in the workshop was to define a generic “notification” message containing minimal information:

8. High-Level Scope: Notifications • In addition to that, the following scope is proposed for the message and supporting implementation guidance: • All recipients of the notification will be listed in the message • Recipient systems will be configurable to allow for different behaviours when a notification is received based on locally defined criteria. • Behaviours may include adding a flag, adding a note to a patient record, creating an item on a work list, or directly notifying a user. • The criteria used may include the event type, sender, or patient – allowing for notifications relating to different cohorts of patients to be treated differently. • An additional flag can be included in the message to indicate that the sender requires acknowledgement when a recipient has seen the notification. • This should only be used when absolutely necessary, and the exact criteria for this acknowledgement would need to be locally defined as there is insufficient clarity to define national requirements for this at this stage.

9. Out of Scope: Notifications • A number of other requirements were discussed, but will not be included in the scope for the first phase of development – these include: • These will be considered for subsequent iterations of the specification based on what is learnt from implementing the initial message in local systems. • Inclusion of a free-text paragraph summarising the event/care provided • The concern with this is that we could not control what was put into the field, which would make information governance very difficult. • Inclusion of a level of “urgency” as assessed by the sender • There was not a consensus on the need for this in the workshops • There is a risk that any priority from the sender would be ignored and the behaviour expected by the sender may not be not followed

10. Personalised Care Plans • There are currently no agreed clinical standards for this content • There are two current ITK solutions for this: • General “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 • “Integrated Care and Support Plan” specification • Defined within the Health and Social Care Integration (HSCI) pack • We do not plan to define a new constrained “care plan” message in this phase.

11. EOL Care Preferences • The proposed content of the EOL Care Preferences was included in the handouts used in the workshops. • Content based on fields defined in the ISB Standard (ISB1580)

12. High-Level Scope: EOL Care Preferences • In addition to that, the following scope is proposed for the message and supporting implementation guidance: • Clinical coding should be supported for as many fields as possible (proposing its use in around 6-7 fields in phase 1 – TBC) • The document will include patient consent details • The document will include formal and informal carers and their relationship with the patient • The document will contain details of who updated each section of the document, and the date the change was made (full detailed audit of previous versions will be viewable in the EPaCCS system) • Clinical systems can allow a new document to be pre-populated using information pulled from the local patient record • Individual coded items from a received document must not be incorporated directly into a local patient record without rigorous controls (likely to involve manual checks). These controls MUST have been locally assured as clinically safe.

13. Out of Scope : EOL Care Preferences • A number of other requirements were discussed, but will not be included in the scope for the first phase of development – these include: • Inclusion of additional items in the document, including: Summary sections for each clinical specialty, information pertinent to children’s end of life care, issues with communication or comprehension, equipment issued, domiciliary status, ethnicity, religion, pacemaker, donor register, anticipatory or crisis plan content, details about what is “normal” for the patient • The general consensus from the workshops was that the core content should remain minimal, aligned with the ISB standard. • Adding lots of other sections could make it take longer to complete and it could become a form-filling exercise • Free-text fields exist to capture “other pertinent information”, and any of these items could be captured there if required. • Inclusion of medication • This was excluded from the core information set during the ISB consultation due to concerns over how this would be managed and kept up to date. • Inclusion of detailed history and/or change log information • The general feeling was that this level of detail would not necessarily be required for direct provision of care, and if it were not available directly in the record that would be acceptable as long as it could be accessed in the EPaCCS system if required.

14. Managing Changes • A mechanism for electronically requesting a copy of a clinical document was proposed in the workshops. • Proposing a new “Get Document” specification in ITK • Support for a “click-through” mechanism was also proposed. • There was general agreement with the need for both mechanisms, with the following specific requirements proposed for this phase: • A clinical document can be electronically requested using an identifier received in a notification – the document returned should always be the latest version • It should be possible to “click-through” into the source system and make changes to the content (subject to IG controls) • A single-sign-on mechanism should be used to avoid the need for multiple login/passwords

15. Out of Scope: Managing Changes • There was also discussion of the possibility of a recipient updating a document that has been received, and sending back a new version to the original sender • The messages we will specify would support this – although implementing this in a way that is clinically safe may be challenging. • We are therefore not proposing to outline any specific guidance for this in this phase of development • The complexity of implementing this is very high, and there is a potential clinical risk of conflicting updates not being managed properly • Anyone wanting to change the content should click-through into the source system and make changes there

16. Main Deliverables Planned by End 2012 ITK Message Specifications • Notification message • EOL Care Co-Ordination Information and Preferences message • Get Document message Notification message guidance: Implementation Guidance • Notification Sender Requirements • Notification Receiver Requirements EOL Care Co-Ordination message guidance: • EOL Sender Requirements • EOL Receiver Requirements Get Document message guidance: • Document Provider Requirements • Document Requestor Requirements Other guidance: • EPaCCS System Requirements • Example Use-Cases

17. Example Use Case • A “use case” puts the specifications and requirements into a real-world context • Aid understanding and shows how the various pieces support a real scenario • An example would be a use case for the sending of End of Life care co-ordination information..

18. Example Use Case

19. Example Use Case (Contd)

20. Example Use Case (Contd)

21. What Happens Next?  12th October • Share the collated outputs from the workshops, along with the proposed high-level requirements identified (this slide deck).  17th October • WebEx: Discuss high level requirements with attendees, and discuss comments or concerns raised 19th October • Share agreed high level requirements • Share proposed lower-level requirements 25th October • WebEx: Discuss proposed lower-level requirements Nov • Follow-on WebEx sessions to discuss specific topics – full schedule of WebEx sessions to be shared asap. 3rdDec • First draft of ITK Message Specifications shared • Release Candidate ITK Message Specifications published • Implementation guidance published End Dec http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk