Qipp digital technology team epaccs informatics advisory and support group
1 / 12

QIPP Digital Technology Team EPaCCS Informatics Advisory and Support Group - PowerPoint PPT Presentation

  • Uploaded on

QIPP Digital Technology Team EPaCCS Informatics Advisory and Support Group. 27 th June 2012. V2. Agenda. Introduction / Objective of Meeting (AH) Brief review of any comments on the group Terms of Reference (All)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' QIPP Digital Technology Team EPaCCS Informatics Advisory and Support Group' - michon

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Qipp digital technology team epaccs informatics advisory and support group

QIPP Digital Technology TeamEPaCCS Informatics Advisory and Support Group

27th June 2012


  • 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

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

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”


Identify work packages and agree allocation for delivery

Work Package Delivery

Enabler Review

Published “Enablers”

Delivery and


Identify “First of Type” adopters

Support Implementation of Enabler

Capture Lessons Learned and Case Study

Case Studies / Best Practice












Care Co-OrdinationSystem





Palliative Care

Record Viewer

Shared Clinical System



Record Viewer





Record Viewer


Palliative Care
















GP Summary

(inc. EPaCCS)




Minor Injuries Unit



Palliative Care


Clinical Portal



EPR Data



All Clinicians


  • EPaCCS Candidate National Enablers


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.


ITK Spec: Notification with Pointer

ITK Spec: EPaCCS Core Record


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


“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


“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


“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


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.


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.


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”


  • Not specifically a technology enabler – raise with wider implementation support group?

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

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