1 / 12

Telehealth: PHMR Development Review

Telehealth: PHMR Development Review. Richard Trusson NHS Technology Office DH Informatics Directorate. Agenda. Why do we need Interoperability? Previous work: Whole System Demonstrator (WSD) and the 9 use cases Recent work: PHMR Specification Development Lessons learned What’s next?

teague
Download Presentation

Telehealth: PHMR Development Review

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Telehealth: PHMR Development Review Richard Trusson NHS Technology Office DH Informatics Directorate

  2. Agenda • Why do we need Interoperability? • Previous work: Whole System Demonstrator (WSD) and the 9 use cases • Recent work: PHMR Specification Development • Lessons learned • What’s next? • Draft specifications for others • PHMR early adopters

  3. Why Do We Need Interoperability? Telehealth • Records • NHS • Housing • Social Care • Personal Health Cholesterol Monitor Care Professionals Blood Pressure Cuff Out of Hours Telecare Glucose Meter Service Hub Pedometer Home Automation Sensor Networks Home Hub Tele-carer Elderly Living Independently Lights, Doors, Windows, Motion, etc. Carer response service Friends and Family Emergency services Limited Offerings Increasing Integration Complexity No integration Increased Offerings Integration required

  4. Previous work: WSD and the 9 use cases • DH wanted investigation into the shared information needs for supporting patient care under telehealth Cross and Multi-Service Working Business / Service Requirement Information Requirement Effective Sharing of Information Value of Information Integration High Quality Supporting Information Ease of Access Ease of Consumption and Use

  5. Previous work: WSD and the 9 use cases • Working with clinicians, GPs, Nurses, etc., patients and the industry we investigated what they needed. This lead to 9 use cases.

  6. Previous work: WSD and the 9 use cases Clinician agreement Import effort • We also identified user concerns and issues Clarity of purpose Clarity of addressee Volume of data Action acceptance Medication record Messaging Assurance Prioritisation Right information, right quality Easy to consume & use Data overlap Ownership of patient record Speed of comprehension Professional liability Easily accessed Update frequency Audit trail of changes/ messages Speed of access Clinical autonomy Linked to right patient Linked to relevant clinician Key Red – most important Blue - important

  7. Previous work: WSD and the 9 use cases • From • Understanding the business needs • Defining the use cases • Identifying the user concerns…the PHMR technical demonstrator message specification was prioritised • This sent vital signs information from the telehealth system (Philips Motiva) to the GP system (EMIS Web) and addressed many of the identified user concerns, • right information, known quality, controlled amounts, easily accessed, easy to use.

  8. Recent work: PHMR Specification Development • In early 2012 we ran a workshop at Intellect to revisit and verify the use cases. • We identified an additional case – click through • Set message priorities. Top three were: • Personal Health Monitoring Report • Clinician Response Message • Referral Message • Initiated a program of work to develop the PHMR – as a result of the technical demonstrator this was the most advanced.

  9. Recent work: PHMR The PHMR sends vital signs information from a telehealth service provider to a system with a legitimate interest – i.e. a GP system. The frequency of updates and range of vital signs reported on can be defined by the receiver. • Working with the ITK team a series of WebEx meetings were run to review, verify and update the requirements. • A draft message specification was released for comment. • In August 2012 this was re-released, with updates, as a Release Candidate message ready for early adopters to start developing against. All work for this is posted on the ITK NHS Networks site.http://www.networks.nhs.uk/nhs-networks/interoperability-toolkit-itk

  10. Lessons Learned • The engagement and development model, overall, worked. • Using WebEx • Using NHS Networks website • Gathering feedback • Reaching agreements • Challenges: • Gathering feedback was harder than expected at times • Compressed time lines • Personal emails were better than generic ones • Would we do anything differently next time? • Have longer timelines • Publish dates for all meetings at the start, if possible • Look to ‘public’ events for mid term discussion, if possible • Shared development environment

  11. What’s Next? • PHMR: Continue to work with NHS and Industry early adopters to support implementation of the PHMR (vital signs) message. To date there are seven organisations, 2 GP system providers and the rest telehealth service providers, signed up. • Clinician Response Message and Referral Message: use outputs from the Workshops this afternoon to inform message development and drive towards early adoption in first half of 2013. • Work with the NHS, Industry, 3millionlives, dallas and others to support the adoption of telehealth and the implementation of interoperability standards across the board.

  12. Questions? Richard.Trusson@nhs.net

More Related