QIPP Digital Technology Team EPaCCS Informatics Advisory and Support Group

1. QIPP Digital Technology TeamEPaCCS Informatics Advisory and Support Group 27th June 2012 V2

2. Agenda • Introduction / Objective of Meeting (AH) • Brief review of any comments on the group Terms of Reference (All) • Brief summary of the local approaches for EPaCCS implementation in local teams (AH) • Review of Candidate “National Enablers” requested by local teams – comments from group (All) • Agree next steps

3. EPaCCS Informatics Advisory and Support Group • Key Responsibilities of the Group: • Governance for the Development of National Enablers • Details on subsequent slides • Ongoing Implementation Support • Discussing key issues or concerns raised by local teams • Reviewing Update to ISB on Implementation of ISB Standard

4. Group Members Member list as at 20th June 2012: • An invitation to suppliers to join the group has been sent out through Intellect, so there may be more suppliers joining the group in addition to the above

5. Progress To-Date Engagement and Discovery 27th June WebEx • Local Roadmaps (as at 27th June 2012): • South West: Roadmap Produced • Bedfordshire: Roadmap Produced • Birmingham: Roadmap Produced • South East Essex: Call held • Salford: Call held • London: Roadmap Produced • Leeds: Call held • Candidate enablers identified – outlined in subsequent slides. EPaCCS Survey Evaluate Responses Follow-Up Discussions with Local Teams Potential National Enablers Scored and Prioritised    QIPP Digital Technology Initiatives Register Draft High-Level Local “Roadmaps” Prioritised “National Enablers” Development Identify work packages and agree allocation for delivery Work Package Delivery Enabler Review Published “Enablers” Delivery and Support Identify “First of Type” adopters Support Implementation of Enabler Capture Lessons Learned and Case Study Case Studies / Best Practice

6. High-Level Local Approaches EPR EPR EPR EPR EPR EPR EPR EPR EPR A&E GP Care Co-OrdinationSystem EPaCCS OOH Community Ambulance Palliative Care Record Viewer Shared Clinical System A&E GP Record Viewer EPR OOH EPaCCS Community Record Viewer Ambulance Palliative Care

7. High-Level Local Approaches (Contd.) EPR EPR EPR EPR EPR EPR EPR EPR EPR EPR EPR EPR SCR Community A&E GP Summary (inc. EPaCCS) GP OOH GP Minor Injuries Unit Community Ambulance Palliative Care Ambulance Clinical Portal A&E EPaCCS EPR Data OOH Ambulance All Clinicians Patient

8. EPaCCS Candidate National Enablers Description Requested Enabler QIPP DT Team: Potential Work Packages / Comments It would be desirable to allow the EPaCCS record to be shared electronically with clinical systems, and kept in sync. This would allow clinicians to use their own systems and avoid re-keying. H ITK Spec: Notification with Pointer ITK Spec: EPaCCS Core Record Click-Through Interoperability Standards “Essential rather than desirable” “avoids duplication” “Separate message content from synchronisation approaches” Many local teams have build custom “forms” within their clinical systems to capture end of life care preferences. There would be benefit in sharing this to avoid re-work in other teams. Standard Templates in Clinical Systems M “shares good practice” “there is too much time spent reinventing the wheel” • Share existing templates on NHS networks site? [Link] There is some high level advice in the implementation guidance document on the use of SCR, but there is a need to provide more detailed guidance to support teams considering this. Guidance on the use of SCR for EoLC M “essential to be using the most compatible system” “won’t work if controlled by GP system” • Build on existing guidance on SCR pages of CFH web site? [Link] There is a need to clarify the details of the consent requirements and other IG issues relating to the end of life care co-ordination process. Guidance On Consent for EPaCCS M “why would there be a need for explicit consent for EPaCCS?” “explicit consent is not gained for other specific registers” IG Guidance on Consent for EoLC The use of a consistent SSO mechanism is an important enabler for EPaCCS. There are concerns over infection control with current smartcard readers. • Provide contacts in identity management team, and give overview of hardware options and timescales for new smartcard functionality L Proximity Smartcards “agree with the need for consistent SSO mechanism” To support any interoperability specifications that are developed, there is a need to clarify how coded information can be conveyed in the messaging across systems safely. H EPaCCS Diagnosis Subset & Cross-Maps EPaCCS Coded Entry Cross-map Guidance Support for Coding and Cross-Maps “standardised readcodes will reduce clinical risk” “crucial for areas such as EoL diagnoses, disabilities, allergies” Many of the teams involved in providing end of life care need to be mobile, so there is a need to provide guidance on how EPaCCS solutions can use mobile technology. H Guidance around options for mobile working “crucial for DN teams and GP OOH services” • Build on existing guidance in mobile working resource centre? [Link] Standard model for quality and outcome marker capture and modelling Local teams have built various models for capturing and tracking outcomes for patients on an end of life care pathway, but this could benefit from being standardised. “guidance needed but local teams will have good models” “could be more sharing from teams who have done work on this” M • Not specifically a technology enabler – raise with wider implementation support group?

9. Summary of outputs from the WebEx • 19 attendees joined • the WebEx: • No concerns were raised over the group terms of reference. • In general, the group were in agreement with the initial relative priorities of the proposed enablers (previous slide). • One additional enabler was proposed around reporting. • The following slides capture key points raised and actions.

10. Key Points Raised during WebEx Discussion • There are some quick wins that could be done now: • Guidance on use of SCR. Maybe including a case study from teams using it now. • Sharing of EPaCCS templates already built and in use in local systems. • Summary of smartcards, SSO and proximity cards. • Sharing of best practice around reporting and outcomes measures. • Share position on consent – debunk some of the myths. • Interoperability • Maybe implementing some of the more advanced patterns now (such as the registry/repository pattern) require less work from ITK? • Supplier engagement and funding • Developing interoperability requires work from suppliers, which comes at a cost. • Concern is that local health teams do not want to fund this in many cases. • Would be interesting to hear how many local teams who are asking for this to be developed could support that with funding. • There is a suggestion that the QIPP should facilitate finding the funding. Even if national team cannot fund it, they could work with multiple local teams to agree joint local or regional funding to fund supplier development against ITK specs. • Can’t have a full EPaCCS solution with only one supplier on-board. • Some suppliers have said that they won’t develop this until it is a “national requirement”. • Local solutions and best practice • Would be good to get comparisons of the various local solutions published to help show where solutions do and do not meet requirements. • ITK accreditation is a good way of seeing which solutions provide national interoperability standards. • Rob Benson is maintaining an NHS networks site to share best practice, and the QIPP Digital team have an initiatives register which should be published online soon also. • Rob is also creating a survey to capture a baseline of EPaCCS activity across the country. • Consent: There is a need for some simple advice on consent to overturn some myths about consent – e.g. That there needs to be a physical signature (this is not required). • Compliance with ISB standard is Dec 2013 – confusion over what this really means. Clarification was that any systems that are in place or new systems created to capture EPaCCS data need to do so in line with the standard. This does not require that EPaCCS is in place, or that data is shared electronically. • Challenge is not capturing the data, rather it is the extraction and sharing of it. There is more that is needed beyond the ISB standard. • Concern that people should not use the lack of interoperability as an excuse not to put an EPaCCS in place, as it can bring real benefits. • Reporting • An important part of understanding what needs to be captured and shared is to understand what reporting, metrics and outcomes information need to be produced by the solution. • There could be a quick win to share good work already done by local teams who have developed rich reporting solutions. • Work has been done in North East to capture reports and outcomes, and provide comparators across a region. This is also the case in other areas. • This is essential to allow for continual improvement of end of life care to provide clinicians with data about how well they are doing compared to other areas, and how the work they are doing improves outcomes over time. • Who is hosting the register can also cause issues with how the data is shared. • End of Life Diagnoses: What is the likelihood of a subset being defined nationally? • This is on the log for the implementation group, and it is being discussed with the terminology team, so hopefully can be agreed and shared.

11. Actions

12. Items for escalation to EPaCCS Implementation Group