Durham and Darlington Electronic Health Record

Durham & Darlington ERDIP Demonstrator Project EHR Simulator Version Final - 20th June 2001Proposed Pilot Environment (EHR Simulator)20/06/01Version: FinalAuthors: SCHIN Team and Eclypsis2 EHR Simulator Version 1 - 20th June 2001Contents1 Executive Summary2 Background to Simulator2.1 Objectives2.2 Definition3 Approach3.1 Architecture3.2 Functional Capabilities4 Issues, Risks and 5 Identified ProblemsAppendices1 Data Mapping2 Electronic Health Record Headings3 Hardware Architecture4 SoftwareContents EHR Simulator Version Final1 - 20th June 20014 EHR Simulator Versiuon 1 - 20th June 20011 Executive SummaryIn 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 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 key components of the Simulator are the specification of 'content' (what is in the EHR) and 'presentation' (who can access the content and how). Additionally, the communications traffic and system tools to build and maintain the content and access elements are to be explored. EHR ContentThere are two elements to EHR content. Firstly the structure of the record and secondly the patient data itself.Regarding structure, we have made significant progress. Appendix 2 lists the major data categories and sub-headings by which we intend to structure the record. This is largely derived form the 'Headings Project' work, which provides a de facto standard in this area. Obtaining data to populate the record has proven to be much more problematic.Our original thoughts as to the content of the Electronic Health Record where based on the assumption that we would be able to gain access to authentic patient data that was held in both an acute facility and a sample of three GP practices using 3 different practice systems. We would then anonymise it and use the data to populate the Simulator. Originally we were considering using approximately 2000 records. We have been forced to change our ideas for a number of reasons:-1 We made approaches to the major GP suppliers to try and obtain their data dictionaries and data maps, to find what data could be collected and in what format this would be. They were not very willing to share this information with what they thought of as a possible competitor, therefore the information received was very patchy in depth and volume. We then visited 2 practices in the locality. The first practice was using IPS and PathLink (so all lab data was being entered into the system). All the radiology text results were keyed in manually. We were able, by using multiple screen prints, to map the data they collected against what could be stored in the proposed central repository (the Clinical Data Repository (CDR) from the Eclipsys Sunrise Clinical Manager (SCM) application). The second practice used EMIS to a very minimal level. They appeared to input no clinical details and, essentially, the system was merely populatedContents EHR Simulator Version Final1 - 20th June 2001 with demographic data. They also have been unable (due to workload) to send us any screen prints. Thus, to date, we have been unable to map EMIS data.This highlighted the fact the data existing in different practices differed hugely – varying from a very complete record to one that was virtually non-existent. An illustration of data mapping work to date, is provided in Appendix 1.2 As a result of this research we also found that currently, it is not the practice to electronically download or transfer patient information e.g. in the circumstance of a patient moving from one practice to another, even though the receiving practice is using the same system. A hard copy of the electronic record is usually printed and sent with the patients paper record. The receiving practice then makes the decision to either key in all, part, or none of the data into their system. This again highlights the differing quality and depth of data that is held within each Practice. On further investigation we found that none of the GP suppliers offer a straightforward method of performing an electronic transfer of data, which has major implications as to how we move forward with populating and maintaining the EHR. 3 Minimal research has been carried out as to the structure and content of Social Services records. There are 2 major suppliers - OMS and Sheridan. Neither system has the facility to electronically export data and they do not use HL7 messaging. The content of the data is very different to that seen in NHS systems, as they primarily collect data that links clients into family groups. 4 It became apparent that we had a number of issues concerning data protection and confidentiality. The whole concept of the Data Protection Act and the adoption of BS7799, as they apply to the NHS, is still being developed and defined. A number of details have to be considered:- What is ‘informed consent’ for the access to a person’s medical record and how should it be sought? Work is currently being carried out by SCHIN to develop an acceptable consent form to be used when we are seeking genuine medical records to populate the simulator.  What level of anonymisation will we have to go to satisfy the Data Protection Officer and local Caldicott Guardians?  Will it be acceptable for a commercial organisation (e.g. Eclipsys) to hold and have access to both consented non-anonymised patient data and anonymised patient data (consented or not)?  How will we be able to use Social Services records? Will we be able to have access to registers such as “at risk” data concerning a minor, which is heavily protected. To try to address the above it has been decided that to allow the configuration of the first Simulator in the time frame allowed, we need to go with artificial data that is correct in content and format. Therefore, for the first iteration of the Simulator, approximately 30 acute and GP style records will be built to populate the database, that can be used to demonstrate the workflow and functionality that would be possible should we be able to use genuine patient data. Executive Summary 6 EHR Simulator Version Final1 - 20th June 2001EHR PresentationWork on presentation aspects will be commencing in July.Executive Summary 7 EHR Simulator Versiuon 1 - 20th June 20012 Background to Simulator2.1 ObjectivesThe Simulator will provide an experimental environment to explore the potential of the EHR concept housed within an ethical framework. To implement an EHR simulator environment, on the basis of artificial content but with the potential for increasing realism of both content and operation. To verify the ethical and security models and also the proposed operational characteristics of the EHR service through experiments and evaluation exercises involving representatives of all the stake holders. To identify critical technical issues, constraints and opportunities which arise in developing the simulator which have an impact on any aspect of the architecture and to reflect these back into the architectural process.The simulator will contain and present a sufficient quantity of realistic data to provide a experimental environment to test the proposed architecture and concepts inherent within the EHR. The data to be used will be based on artificially generated material. This will provide the ‘corpus’ and will be responsible for all aspects of traffic simulation and evaluation.This experimental environment will be populated with some data, which has potential to become more and more realistic as the overall EHR project matures, and will be instrumented to provide the means of observing and demonstrating structure and behaviour.A framework for conducting tests and evaluations from both the technical and the user perspectives will be defined and refined through experiments and evaluation exercises.2.2 Definition – What are the aims of the Simulator ?Contents EHR Simulator Version Final1 - 20th June 2001 To specify the EHR concept in technical terms  To generate an implementation reference model of the system and its interfaces required for working with other organisations  To facilitate the possible design and technical specification requirements of an EHR model.3 Approach3.1 ArchitectureThe proposed Simulator architecture is illustrated below in figures 1 and 2, showing the proposed data feeds and user access:Demographics TextBase Data Collection GP Interface PAS EngineAcute Resolved Database Identity Demographics Population Database Resolution Identified Accumulation Histories of Data Demographics Medical History TextBase Interface Data CollectionEngine GPLabs Interface PASGP Identifier External Engine Repository DB Reference Index Acute Resolved Database Social Identity Demographics Population Database Resolution Identified Accumulation Histories of DataMedical History Interface Engine LabsGP Identifier External Repository DB Reference IndexSocial Background 9 EHR Simulator Version Final1 - 20th June 2001Figure 1 – Data feeds to the EHRUser AccessWeb Server User TerminalDB Queries Database Views HTML Web BrowserSecurity Security Client ResolutionLogRepositoryAuditingFigure 2 – Stakeholder acces to the EHR3.2 Functional CapabilitiesWhat will be delivered and how it will work?Rationalising demographic information fed from acute, community, Mental Health and Social Services EPRs.Overcoming the patient identification problem will be one of the first issues that the Simulator will have to address. Existing patients will have multiple identifiers on multiple systems. The simulator will demonstrate a method of rationalising multiple identifiers fed from two sources by using an externalised master person index. Simulation of batch feeds to an external index from two representative systems, North Durham acute EPR and sample GP system data, will be used to populate the demographic component of the Simulator . Data for the GP systems will be provided as flat files supplied by SCHIN in an agreed format and containing sufficient content information to support the EHR concepts described Section 2. The nature of the GP flat file will be derived from the Background 10 EHR Simulator Version Final1 - 20th June 2001 existing ‘TextBase’ project, using artificial data. It is anticipated that up to 30 ‘artificial’ GP patient records containing both demographic and non-demographic data will be used. Using such data will ensure avoidance of data protection and confidentiality issues relating to the use of ‘real’ patient data. The EPR data will be supplied as a batch file.Similarly, we will use artificial data representing that available from the North Durham EPR, mirroring the GP data supplied from SCHIN.The GP file and EPR file will rationalised using the Eclipsys’ Enterprise Person Index (EPI) tool. The inbound demographic data will be cross-referenced against an EPI database containing all possible identifiers for the same patient. An external reference dataset containing validated ‘quality’ identifiers (NSTS, Exeter) can be cross-referenced by the EPI. The EPI will resolve the inbound data to produce ‘clean’ and consistent resolved demographic data to be stored in the EHR data repository (figure 1).Clinical DataData from other sources (Acute Labs, GP, Community, Mental Health) will be needed to fully complete the content model. The originating systems (Acute Lab, GP, Community) will be represented by a realistic sample of data presented in the form of batch files. Individual data records may contain different identifiers to those held within the repository. The Simulator will demonstrate the process involved in resolving identifiers contained within non-demographic data. The batch files will be processed by the EPI resolving application to ensure that the appropriate patient identifier is matched with the non-demographic data required to be fed into the EHR repository. The result of the EPI processing will be a batch-file representing the ‘cleansed’ data. Simulation of transfer of these documents from originating systems to EHR.‘Clean’ data resolved by the EPI application will contain data in a variety of message formats. An EHR will need to be able to adequately handle such data and transform data into suitable formats as required to be stored within the EHR. The actual data content will be supplied by SCHIN and will be sufficient to address the underlying EHR concepts. This will be based upon information from existing systems so as to provide maximum value and correspondence to a “real world” view and thus applicability. Definition of data content types will be supplied using the work already done on Headings. Appendix 2 refers to the Headings to be used within the Simulator data sets. The superset of content data will contain in overall the following headings; Background 11 EHR Simulator Version Final1 - 20th June 2001Demographics, Alerts, Visit Summary, Results, Diagnostic Imaging, Documents (Physician, Nursing, Social Services, Rehab Services, Nutritional Services, health Visitor, Patient Education), and Vaccination Record. The Simulator will demonstrate the transformation of data from different message formats into a format suitable for transfer into the EHR database. For the simulation, data will be transformed into an international standard message format (HL7 2.3) using an integration engine (Eclipsys’ eConnect). Transformation to alternate message formats (XML, EDI) can also be achieved but for this particular Simulator HL7 will be used as it is a widely used and widely supported Health Message format and can adequately demonstrate the processes involved in transferring data and documents from originating systems into the EHR.The integration engine will take the files output generated by EPI resolution and transform the inbound message format into HL7 2.3 message format in the presentation of a batch file. The Simulator will then demonstrate the ‘feeding’ of transformed data into the data repository. This will achieved using an interface message feeding application (the InterfacesLite component of the Sunrise Clinical Manager toolset). The batch file with the ‘resolved identifiers’ and transformed data can be viewed via InterfacesLite (for illustration purposes) and then sent straight through into the EHR repository.Data RepositoryThe repository will contain summarised clinical data. The repository will receive feeds from the identified data originating sources. The database will be refreshed after each simulation for consistent repeatable demonstration of the underling processes involved in the transfer of data from ‘originator’ to ‘storage’ repository. This will provide an experimental platform that can used repeatedly to demonstrate the concepts related to cleansing, transforming and transferring data from source to repository.The actual data repository will be provided from Eclipsys’ SCM. Using an existing flexible schema, designed to support clinical data structures, with inbuilt features for maintaining and refreshing the database, will provide a simpler administrative workload for the purposes of demonstrating the simulator than building a sample repository using generic database tools. Configuration of the repository will be done based on content information supplied by SCHIN working group. Inherent in the configuration will be details on the security models to from the EHR Demonstrator, based on the done by other collaborators in the Durham and Darlington and Tees projects. Security modelsThe security concepts to be tested by the EHR will be incorporated within the configuration of the database and reflected in the database schema content.Background 12 EHR Simulator Version Final1 - 20th June 2001The Simulator will also demonstrate some of the technical issues related to ‘security’ in a wider context. Database security – The Database will be located on dedicated database server with secure login. User information is encrypted within the database. Access to sensitive patient data will be via the ‘integration toolkit’. User and password details to the database are encased within business logic code, which is compiled as binary executables. User authentication – EHR simulator will demonstrate some of the issues involved in securing patient data. The simulator will provide access via controlled identification of users using a ‘sign-on’ methodology. Each of the simulated Stakeholder groups will be able to logon on via a web browser. The sign-on application to be used in the simulator will be Eclipsys’ eCompose. This ‘single- sign-on’ application supports biometric and non-biometric (card based) identification approaches and authentication is achieved via logon with user name and password. For the purposes of the Simulator, authentication via logon will be used initially. A separate secure database is used to store ‘user’ logon credentials. The data held is encrypted and all intercommunication transfer of logon data is encrypted. Logon audit details is fully tracked and user/stakeholder access to front-end application is managed by the sign-on application .For the purposes of the simulator eCompose will be used to verify and audit logon of the stakeholders and, allow access to pre-defined sub-sections of the front-end application presented as specific ‘views’ of the EHR repository data.Presentation - Views into the EHR The EHR simulator environment will present consistent and appropriate interfaces to the different sorts of stakeholder involved in working with personal medical records. The Simulator will demonstrate a variety of pre-agreed views of the EHR data which can be used to demonstrate possible presentation configurations. Issues such as Stakeholder access availability and breadth of data access can be tested. The views will also provide a reference point to test the acceptability of visual presentation format, content and functionality.The simulator will allow Stakeholders to access the EHR via a web browser hosted on a client machine (Figure 2). The user will have to negotiate secure login prior to accessing the browser-hosted views. The views will be standard HTML templates referencing data pulled from the EHR repository. To tie the HTML templates and data together in a secure and efficient way a middleware application will be used (eCompose). The application will process requests from users sent from the browser and pull relevant EHR data out of the repository which will then be sent back to the browser for presentation to the user. The middleware is designed to create integrated web applications with full support for encryption (RAS 3DES Diffie Hullman keys) and support for Digital Certificates. Reference to third-party encryption tool kits is fully supported for developing a PKI infrastructure.Background 13 EHR Simulator Version Final1 - 20th June 2001For the purposes of the Simulator the Stakeholders will be presented with a set number of pre-agreed views (GP, A&E, and Social Services). Depending on the agreed access and defined rights of the stakeholder group different subsets of the EHR data will be presented. The user will be able to navigate through the different views of data. Background 14 EHR Simulator Versiuon 1 - 20th June 20014 Issues, Risks and Identified ProblemsIn the research leading to this plan for the EHR Demonstrator architecture, a number of problems have been highlighted. These include: GP information systems suppliers are unable or unwilling to export information from their systems in electronic form. As a result, the batch input data will not be in one of the proprietary formats used in GP surgeries, but in the TextBase format. Efforts will be made to ensure a reflection of the variety of the GP system formats within the sample data. It may be possible within a future EHR project requiring real data to circumvent these data extraction problems by converting data designed for printouts into a useable format, but a more practical long term solution is needed using more open GP software or mandated interchange standards. Even if data could be extracted from the GP systems for incorporation into an EHR system, many practices record incomplete data electronically e.g. only demographics. For an EHR to become useful, a large-scale change in attitudes to the use of systems in GP surgeries will be required. Similarly, transfer of data from one practise to another requires generating and re- entering a hard copy of the patients’ details. This can lead to incomplete digital patient records.  The nature of the “informed consent” required for centralised data storage is currently unclear or impractical. Although the project circumvents these problems using artificial but realistic data, the next stage of EHR development must find a way to resolve these issues. The IT systems of Social Services are even less advanced than those of GPs. As yet no information has been gathered on the data that Community Health, Social Services or Mental Health will contribute on the project. Although the data should be secure against unauthorised users (i.e. validated users with no rights to access particular data) due to encryption and view restrictions, no method for identification beyond passwords has been discussed (i.e. how to determine if the user is who they claim to be).Problems EHR Simulator Versiuon 1 - 20th June 2001Appendix 1 – Data MappingExeter EMIS In Practice SCMSurname Family Name Surname Surname Previous surname Previous Last Previous Surname ??? Changes?? Name Forename Forename Forname 1 Forename Other forenames Calling Name Forname 2 Other forenames Extra Name ? Other forenames Title Title Title Not there Sex Sex Sex Gender Marital Status Marital status RaceReligion Patient number identifier Address 1 Address House name Can build multiple address Address 2 Address Number & Road Address 3 Address Locality address 4 Address Town County Post code Post code Post code Zip code Address type Address type Telephone Contact Phone Type Number numbers(multiple) Email address Location Type Age Age Age Date of birth Date of Birth Date of Birth Birth date New NHS number NHS number NHS number Client ID Organisation identifier Institute Code Facility Code? Deduction reason /Reason for movement??Match code ???? type of match??? Date of transaction Related Date Date fields Source of transaction ?Encounter Type Type of transaction ?Registration ?Registration ?relevant Type Status Record type ?Activity Type Registration Status Current GP code GP id Provider IDAppendices EHR Simulator Version Final1 - 20th June 2001GP Surname Reg GP Care Provider GP initials GP Address line 1 ?contact type GP GP Address line 2 GP Address line 3 GP Address line 4 GP Post code GP responsible HA Health Authority ?comment field GP start date Registration Date Effective Date GP end date Expiration Date End reason GP Partnership name GP Partner local code Date added Transport Comment field Arrangements Referal Urgency Comment field Language Primary Language Requirements Referral Reason Health issues? Funding Arrangement Problems All Problems Health issues Currently Relevant Health issues Consultations Examination, ?Flow sheet including results,entered by,dateDiagnosis, Health issues including clinical note, entered by,date Recalls Date Pre admit visit Reason Operator Medical History Date Flow sheet ? Put Problems-Medical in one Clinical note N.B Looks like a longitudanal consult record Operater initial Therapy Course Number Issue number Medication Code Drug name One Generic item in catalogue and a form Appendices 17 EHR Simulator Version Final1 - 20th June 2001 with all these data elements Dosage Dosage Instructions Quantity Amount supplied Prescribing ID Prescribing Initial Date Issued Authorising Person Prescription Type Mixture Contents Lifestyle Text comment re ?comment field smoking Text comment re alcohol Examination Findings Date Operator Initials Flow sheet Text clinical notes Flow sheet Weight Weight BMI Flow sheet Height Height Diastolic With Flow sheet recall note Systolic With Flow sheet recall note Test Results Biochemistry ? Unload University (routine) Hosp catalogue plus dictionaries Biochemistry (Other) Haematology Microbiology Serology & Immunology Biochemistry (hormone) Diagnostic tests Other Pathology tests HP Interventions Date Documents Operater initial Text heath education notes Elderly Housing text Flowsheet commentAppendices 18 EHR Simulator Version Final1 - 20th June 2001Relation e.g. Spouse Carer's details Risk Factors Annual Test include diabetes Hearing exam State of mind Geriatric Health Exam Drug Therapy Bladder Bowels Clinician Name Further Care Referral Disease Registers Note of which Flowsheet register Date Placed on it Operater initial Immunisations Date given Flowsheet Date Booster due Immunisation name Operater initial Diabetes Date Flowsheet DM Screen, text DM monitoring status test DM monitoring admin text Diabetic Concerns text CV or Hypertension Cardiac Disease Monitoring Clinician Name Diagnostic Imaging Text report University item catalogue Epilepsy Epilepsy Register Flowsheet Y/N Managed by text Last Fit date Fit details textAppendices 19 EHR Simulator Version Final1 - 20th June 2001DVLC informed Y/N Asthma History text Management text Consultation, height,PF current Smoking Treatment Broncodilators,Inh aled steroids, cromoglycates Allergy Date of recording Clinician Name Read Term for allergy Drug? Allergen? Read term for reaction Reaction type Severity certainty Maternity Pregnancy Detail Flowsheet Blood Group LMP EDD Antenatal Consultation Date Clinician Name Read Term Seen By Weeks Gestation Notes text entry Weight Blood Pressure Haemaglobin Investigations Blood Group Haemoglobin Iron studies Rubella Pregnancy Outcomes Delivery Details Gestation at birth Stages of LabourAppendices 20 EHR Simulator Version Final1 - 20th June 2001Outcome Placenta Episiotomy Perineal Tear Sutures Infant details Apgar score Post natal Consultation Postnatal Visit Postnatal Exam Postnatal Symptoms Weight Blood Pressure Maternal breast exam Maternal pelvic exam Contraception CS claim due date Pap due date Cervical cytology Comment? Previous GP code GP National code GP Surname (Prev) GP initials (prev) GP Address line 1prev GP Address line 2 prev GP Address line 3 prev GP Address line 4 prev GP Post code prev GP responsible HA prev GP start date prev GP end date prev End reason prev GP Partnership name prev GP Partner local code prev Date added prevAppendices 21 EHR Simulator Version Final1 - 20th June 2001Appendix 2 – EHR HeadingsDemographics Name, full & aliases  Gender including change  Religion  Primary Language & others? Contact for translation? (e.g. relative – contact details?)  Date of Birth  NHS Number  Telephone Number &/or contact method?  Marital Status/social circumstances  Name and address of contact person/next of kin  Employment?  Height/Weight??  Social WorkerAlerts Allergies  Known problems/Health Issues  Medication History  Family History  Date of next PAP Smear  Date of next Mammogram  Over the counter drug usage  Alcohol Usage  Smoking History  Patient instructions, preferences  Organ donationVisit Summary Reason for visit/ Problem & referral source (self, family, SW, CN, etc)  Consultation Note  Vital signs/Observations  Physical Examination  Investigations – carried out, ordered – matching results? Where ordered from?  Referral  Medication Prescribed/Active medications?  Preliminary Diagnosis  Date of visit/inpatient Stay  Type of visit e.g. GP, OPD, Inpatient etc  Service  Summary of Care/medication/surgery etc  Final DiagnosisAppendices 22 EHR Simulator Version Final1 - 20th June 2001Results Laboratory  Haematology  Biochemistry  Microbiology  Serology  Anatomic Pathology  Other?Diagnostic Imaging X-Ray and Fluoroscopy  CT & MRI  Nuclear Medicine  Ultrasound  Other ProceduresDocumentsPhysician Assessments  Notes  Consultations  Discharge Summary  Operative Notes Nursing Assessments  NotesSocial Services Assessments  Notes  Discharge PlanRehab Services Physical Therapy  Occupational Therapy  Speech TherapyAppendices 23 EHR Simulator Version Final1 - 20th June 2001Nutritional Services Dietary Assessment  Dietary AdviceHealth Visitor Developmental Screening  AssessmentPatient Education Post Operative Instructions  Home Care InstructionsVaccination Record Name of Vaccine  Name of person who administered it.  Date /Dose given  Adverse reactions/severity  Date Booster dueAppendices 24 EHR Simulator Version Final1 - 20th June 2001Appendix 3 – Hardware ArchitectureServers sufficient to support the proposed configuration and permit a simulator capable of maintaining a sufficient quantity of data and transactions to provide a realistic assessment of future needs. Provisional estimate based upon twin IBM NetFinity 3000 servers with dual processors.EthernetClientSCM & Associated EPI Webserver Fire wall ? Software eLink eSign Associated SoftwareThe fire wall is required if the system is to be perminatly connected the the internet. Should the client be directly connected the fire wall is optional.Appendices 25 EHR Simulator Version Final1 - 20th June 2001Appendix 4. SoftwareThe following Eclipsys application software products will be deployed:- Sunrise Enterprise Patient Index- Sunrise eWebIT suite, comprising: eConnect (eLink Integration engine) eCompose (eView Web integration toolset) eConfirm (eSign composite application security toolset)- Sunrise Clinical Manager Data RepositoryAppendices 26

Durham and Darlington Electronic Health Record

Details

Download

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

Support