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

Background  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

Workshop Outputs  The slides and handouts from the workshops are available on the ITK NHS Networks site.slideshandouts  Primary topics that were discussed in the workshops were:  Notifications  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.summary of the main points captured from the discussion  NOTE: This slide deck will be used in the WebEx on the 17 th October.

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

Main Deliverables Planned by End 2012 ITK Message Specifications 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  EPaCCS System Requirements Other guidance:  Notification message  EOL Care Co-Ordination Information and Preferences message  Get Document message

High-Level Scope: Notifications  The proposed content of the Notification was included in the handouts used in the workshops.handouts  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.

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:  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

High-Level Scope: EOL Care Preferences  The proposed content of the EOL Care Preferences was included in the handouts used in the workshops. handouts  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.

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

Managing Changes  A mechanism for electronically requesting a copy of a clinical document was proposed in the workshops.  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  In this phase of development the following will not be in scope  Updating a document that has been received, and sending back a new version to the original sender  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