An Integrated Care Record Service The Durham & Darlington Approach The Simulator

1. An Integrated Care Record ServiceThe Durham & Darlington Approach The Simulator

2. AGENDA The Simulator……… • Where did we come from and what did we learn? • Where are we now? • Architecture and the local domain • Demonstration of Simulator

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

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

5. How the project evolved Phase 1 – 09/00 – 09/01 Testing the theory Phase 2 – 09/02 – 06/02 The reality Phase 3 – 06/02 – present The way forward

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

7. 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 TextBase (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

8. Phase 2 - September 2001 – June 2002 • 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)

9. 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 DuDEHR project) position on informed consent and access to patient data - Requires architectural framework for data publication

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

11. Phase 3 – The Simulator Today Three core components: • Repository • Transaction Engine • Viewer

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

13. Phase 3 – The Repository • Here are 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

14. 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”

15. Phase 3 – The Messages • Universal message format includes “Envelope” and “Body • All messages are given a message number from the Certificate server

16. Phase 3 – The Messages • Envelope includes details about the message: • Source, • Destination(s), • Patient identity, • EHR storage flag, • Time sent • Certificate number • Associations with previous messages • Problem associations

17. Phase 3 – The Messages • Body contents are flexible, and incorporate all appropriate message types • Prescriptions, Publications, Results, Orders, Bookings, Discharges & Admissions etc • Simple structures, but appropriate functionality

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

19. Value of the Simulator • To complement the Animator in informing debate • To provide a sample model to assist in EHR procurement in D&D and nationally • To highlight multiple issues in EHR design, construction and operation

20. Introduction to demonstration (Mike Martin) • Demonstration • Questions