Скачать презентацию An Integrated Care Record Service The Durham Скачать презентацию An Integrated Care Record Service The Durham

da8e7c009151db7ce19dd5f95693fb8a.ppt

  • Количество слайдов: 21

An Integrated Care Record Service The Durham & Darlington Approach The Simulator THE HEALTH An Integrated Care Record Service The Durham & Darlington Approach The Simulator THE HEALTH i. NNOVATOR 1 www. isoftplc. com

AGENDA The Simulator……… n Where did we come from and what did we learn? AGENDA The Simulator……… n Where did we come from and what did we learn? n Where are we now? n Architecture and the local domain n Demonstration of Simulator THE HEALTH i. NNOVATOR 2 2 www. isoftplc. com

The D&D EHR Simulator In parallel with the development of the EHR organisational architectural The D&D EHR Simulator In parallel with the development of the EHR organisational architectural models by the SCHIN group involved in the Durham and Darlington EHR Project, which are designed to illustrate (via an Animator tool) the ethical and security framework for Electronic Health Record operations, the EHR Simulator is being developed. The Simulator is to provide a mechanism for the deployment of those concepts using sample data in a test system which can be reviewed by stakeholder representatives. THE HEALTH i. NNOVATOR 3 3 www. isoftplc. com

Original EHR Philosophy Step 1 - Identify the Patients Step 2 - Populate the Original EHR Philosophy Step 1 - Identify the Patients Step 2 - Populate the base with history Step 3 - Update with new data Step 4 - Provide user access THE HEALTH i. NNOVATOR 4 4 www. isoftplc. com

How the project evolved Phase 1 – 09/00 – 09/01 Testing theory Phase 2 How the project evolved Phase 1 – 09/00 – 09/01 Testing theory Phase 2 – 09/02 – 06/02 The reality Phase 3 – 06/02 – present The way forward THE HEALTH i. NNOVATOR 5 5 www. isoftplc. com

Phase 1 – The first year Utilise a selection of established health care based Phase 1 – The first year Utilise a selection of established health care based software products to build the 4 elements: Identify - a health community patient index Populate - a data repository containing historical data extracted from primary and secondary care systems Update - a series of updates based upon patient contacts with various institutions Access - a number of web-based views of the repository for different user types THE HEALTH i. NNOVATOR 6 6 www. isoftplc. com

Phase 1 – Key Lessons Learnt Community Index Patient Identification concept viable using standard Phase 1 – Key Lessons Learnt Community Index Patient Identification concept viable using standard tools BUT………Need for ‘real time’ NSTS for maintenance Patient Details - Concept viable using Text. Base (structured) records Web Access - Search, retrieve and display concepts viable using standard tools Repository - EPR schema insufficiently flexible to accomodate primary care and wider community data HENCE………Build bespoke EHR repository THE HEALTH i. NNOVATOR 7 7 www. isoftplc. com

Phase 2 - September 2001 – June 2002 n Proceed with original philosophy using Phase 2 - September 2001 – June 2002 n Proceed with original philosophy using bespoke components: – a new SQL repository based on an EHR schema – REAL GP and acute hospital system records (anonymised) to populate repository – update transactions based upon a fictitious patient (to mirror animator) THE HEALTH i. NNOVATOR 8 8 www. isoftplc. com

Phase 2 – Key Lessons Learnt Historical Data - High variability in quantity, quality Phase 2 – Key Lessons Learnt Historical Data - High variability in quantity, quality and categorisation of data from source systems - Requires standardisation and consistency e. g. fully implemented EPRs and data transfer capability (records and transactions) Confidentiality - Evolving national (and Du. DEHR project) position on informed consent and access to patient data - Requires architectural framework for data publication THE HEALTH i. NNOVATOR 9 9 www. isoftplc. com

Phase 3 – Transaction Oriented EHR n Use GP/patient ‘mutual informed consent’ as initiator Phase 3 – Transaction Oriented EHR n Use GP/patient ‘mutual informed consent’ as initiator of individual EHRs n Move from repository oriented to transaction oriented design n Focus on ‘data publishing’, ‘transaction certification’ and provenance. The Simulator to illustrate what we need. . . . ………………………. . . ………not what we have THE HEALTH i. NNOVATOR 10 10 www. isoftplc. com

Phase 3 – The Simulator Today Three core components: § Repository § Transaction Engine Phase 3 – The Simulator Today Three core components: § Repository § Transaction Engine § Viewer THE HEALTH i. NNOVATOR 11 11 www. isoftplc. com

Phase 3 – The Simulator Today Three core components: 1 Repository – extension of Phase 3 – The Simulator Today Three core components: 1 Repository – extension of previous model – Previous version reflected what could be done with existing data – Now includes greater provenance support, strict attribution of all data and relationships between items – Based on how a transaction-based EHR could work, rather than what an EHR would have available today THE HEALTH i. NNOVATOR 12 12 www. isoftplc. com

Phase 3 – The Repository • Here a few of the 30 tables • Phase 3 – The Repository • Here a few of the 30 tables • Despite trying to maximise simplicity, the repository is still a maze of relationships • This enforces provenance tracking and maximise useful connections for the user THE HEALTH i. NNOVATOR 13 13 www. isoftplc. com

Phase 3 – The Simulator Today Three core components: 2 Transaction Engine – based Phase 3 – The Simulator Today Three core components: 2 Transaction Engine – based upon the Edward Jones story in the Animator - Official messages still evolving nationally - Unofficial formats have been defined for the Simulator, reflecting what we need - XML based (e-GIF compliant) - Support provenance and transactions through references between messages - All messages are “certified” THE HEALTH i. NNOVATOR 14 14 www. isoftplc. com

Phase 3 – The Messages n Universal message format includes “Envelope” and “Body n Phase 3 – The Messages n Universal message format includes “Envelope” and “Body n All messages are given a message number from the Certificate server THE HEALTH i. NNOVATOR 15 15 www. isoftplc. com

Phase 3 – The Messages n Envelope includes details about the message: – – Phase 3 – The Messages n Envelope includes details about the message: – – – – Source, Destination(s), Patient identity, EHR storage flag, Time sent Certificate number Associations with previous messages Problem associations THE HEALTH i. NNOVATOR 16 16 www. isoftplc. com

Phase 3 – The Messages n Body contents are flexible, and incorporate all appropriate Phase 3 – The Messages n Body contents are flexible, and incorporate all appropriate message types – Prescriptions, Publications, Results, Orders, Bookings, Discharges & Admissions etc n Simple structures, but appropriate functionality THE HEALTH i. NNOVATOR 17 17 www. isoftplc. com

Phase 3 – The Simulator Today Three core components: 3 Viewer – refine appearance Phase 3 – The Simulator Today Three core components: 3 Viewer – refine appearance and enhance functionality - Enables provenance viewing Connects associated data items Allows for selection of items by problem or event Delivers benefits of message based system to the end user THE HEALTH i. NNOVATOR 18 18 www. isoftplc. com

Value of the Simulator n To complement the Animator in informing debate n To Value of the Simulator n To complement the Animator in informing debate n To provide a sample model to assist in EHR procurement in D&D and nationally n To highlight multiple issues in EHR design, construction and operation THE HEALTH i. NNOVATOR 19 19 www. isoftplc. com

n Introduction to demonstration (Mike Martin) n Demonstration n Questions THE HEALTH i. NNOVATOR n Introduction to demonstration (Mike Martin) n Demonstration n Questions THE HEALTH i. NNOVATOR 20 20 www. isoftplc. com

THE HEALTH i. NNOVATOR 21 21 www. isoftplc. com THE HEALTH i. NNOVATOR 21 21 www. isoftplc. com