Download - 27 th June 2012 QIPP Digital Technology Team EPaCCS Informatics Advisory and Support Group 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
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
Group Members
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
Team Name Org/Role MemberQIPP LTC Workstream Sharon Lee LTC National Coach MLSP (NMEPfIT, LPfIT) Richard McEwan Technical Architect MSHA/PCT Cluster ICT Paul Westerman Leeds M
Julia Riley London MStephen Burrows Salford MJulian Abel South West MTracy Davis North East M
Alison Chan Yorkshire and the Humber TBCSummary Care Record Adam Cooper Technical Architect MQIPP Digital Technology Adam Hatherly (Chair) Technical Architect M Andrew Williams Programme Manager MGPSoC Mike Curtis Technical Architect MInteroperability Joe Waller Technical Architect TBC
Michael Odling-Smee Technical Architect TBC Richard Kavanagh Interoperability Development Manager MJGPITC Libby Morris M
Leo Fogarty MQIPP EOLC Workstream Rob Benson MSuppliers Simon Wren Advanced Health and Care TBC
Sue Grey iSoft TBCPhil Russell EMIS MSarah Griffin TPP MChris Pratt CSE Healthcare TBCMichael Thick McKesson MJames Leeming Graphnet MSimon Fanthorpe In Practice Systems TBCPaul Cooper IMS Maxims MIan Moody PCTI Solutions M
Gemma Daley Clinical Solutions MPatient Engagement Jayne Taylor Patient and Public Partnerships Group MClinical Teams Lesley Boler Director of Nursing and Education M
Julie Mountain Community Matron and Clinical Lead for Long Term Conditions M Steve Plenderleith Hampshire (previously Birmingham) M
Member list as at 20th June 2012:
27th June WebEx
Progress To-Date
Engagement and Discovery
EPaCCS Survey
Evaluate Responses
Follow-Up Discussions with Local
Teams
Potential National Enablers Scored and Prioritised
Work Package Delivery
Draft High-Level Local “Roadmaps”
Identify work packages and agree allocation for
delivery
QIPP Digital Technology Initiatives Register
Development
Published “Enablers”
Prioritised “National Enablers”
Delivery andSupport
Identify “First of Type” adopters
Support Implementation
of Enabler
Capture Lessons
Learned and Case Study
Case Studies / Best
Practice
Enabler Review
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.
High-Level Local Approaches
Shared Clinical System
In some localities, an existing centrally hosted clinical system is already in place and is used across a number of care settings, giving read-write access to EPaCCS records.Other care settings can use a record viewer, which provides a read-only view of the record. Updates to other EPRs would be manual, and any updates to EPaCCS records would need to be fed back to a team with full access to the shared clinical system (this is sometimes handled by a central co-ordination centre).
GPShared Clinical
System
EPaCCSCommunity
Palliative Care
A&E
Record Viewer
OOH
Record Viewer
Ambulance
Record Viewer
EPR
EPR
EPR
EPR
Dedicated Care Planning System
In some cases, local teams have procured a new shared solution specifically for holding end of life care preferences. This is made available to all care settings, who can view/update as per their role in the care planning process.A separate process (often manual) is sometimes used to “flag” within the various clinical systems that a care plan exists in the care planning system, so clinicians know to look there for care preferences.
Care Co-OrdinationSystem
EPaCCS
A&E
OOH
Ambulance
EPR
EPR
EPR
GP
Community
Palliative Care
EPR
EPR
EPR
High-Level Local Approaches (Contd.)
Ambulance
SCR as EPaCCS
In some cases, local teams who have a good uptake of SCR have used an enhanced GP Summary to provide their EPaCCS by storing the patient’s end of life care preferences directly in the GP summary. Any changes would need to be fed to the GP to be incorporated into their records, and fed up to the SCR. Other teams could then view the records in the SCR either in their system (if it supports SCR viewing), or using the Summary Care Record Application.
SCR
GP Summary(inc. EPaCCS)
Community
EPR
EPR
EPR
GP
Palliative Care
A&E
OOH
Ambulance
EPR
EPR
EPR
Clinical Portal
In some cases, local teams have are developing clinical portals to bring together key information from the various EPRs in clinical systems, and consolidate into a single view. End of Life preferences can then be a combination of data pulled from clinical systems, but can also be augmented directly in the portal if required to add additional information not currently held in clinical systems.The level of information exchange between clinical systems and the portal generally varies, with some one-way feeds and other more tightly integrated. In some cases a patient may also have access.
Clinical Portal
A&E
OOH
Ambulance
EPR
EPR
EPR
GP
Community
Minor Injuries Unit
EPR
EPR
EPR
EPR Data
EPaCCS
All Clinicians Patient
EPaCCS Candidate National Enablers
Standard Templates in Clinical Systems
ITK Spec: EPaCCS Core
Record
ITK Spec: Notification with Pointer
EPaCCS Coded Entry Cross-map Guidance
EPaCCS Diagnosis Subset & Cross-Maps
Click-Through
Guidance on the use of SCR for EoLC
IG Guidance on Consent for EoLC
Interoperability Standards
Proximity Smartcards
Support for Coding and Cross-Maps
Guidance around options for mobile
working
Standard model for quality and outcome marker capture and
modelling
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.
Requested Enabler Description QIPP DT Team: Potential Work Packages / Comments
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.
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.
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.
Share existing templates on NHS networks site? [Link]
Build on existing guidance on SCR pages of CFH web site? [Link]
Guidance On Consent for EPaCCS
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
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.
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.
Build on existing guidance in mobile working resource centre? [Link]
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.
Not specifically a technology enabler – raise with wider implementation support group?
H
H
H
“Essential rather than desirable” “avoids duplication”“Separate message content from synchronisation approaches”
“standardised readcodes will reduce clinical risk”“crucial for areas such as EoL diagnoses, disabilities, allergies”
“crucial for DN teams and GP OOH services”
L“agree with the need for consistent SSO mechanism”
M
M
M
M
“shares good practice”“there is too much time spent reinventing the wheel”
“essential to be using the most compatible system”“won’t work if controlled by GP system”
“why would there be a need for explicit consent for EPaCCS?”“explicit consent is not gained for other specific registers”
“guidance needed but local teams will have good models”“could be more sharing from teams who have done work on this”
Summary of outputs from the WebEx
Team Name Org/RoleLSP (NMEPfIT, LPfIT) Richard McEwan Technical ArchitectSHA/PCT Cluster ICT Libby Hough London
Stephen Burrows SalfordJulian Abel South West
Tracy Davis North EastQIPP Digital Technology Adam Hatherly (Chair) Technical Architect
Andrew Williams Programme Manager Mike Kelly Technical ArchitectGPSoC Mike Curtis Technical ArchitectInteroperability Joe Waller Technical Architect Richard Kavanagh Interoperability Development ManagerQIPP EOLC Workstream Rob Benson QIPP End of Life Digital LeadSuppliers Simon Wren Advanced Health and Care
Ewan Jones CSC (iSoft)SusanKieran Vaughan TPPPaul Cooper IMS Maxims
Ian Moody PCTI SolutionsClinical Teams Steve Plenderleith Hampshire (previously Birmingham)
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.
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.