Patientendossier - europäische Konzepte, PhD, FACMI, FACHI, FHL7 Head,,, Germany Past-Chair HL7 Germany Past-Chair, IMIA Working Group Standards in Health Care Informatics Chair, EFMI Working Groups EHR and Security, Safety and Ethics Chair, CEN/ISSS ehealth Standardization Focus Group Chair, German Health Informatics Standards Committee Head of the German Delegation to ISO and CEN Past-Chair, GMDS Working Groups Standards for Interoperability and EHR Co-Chair,GMDS Working Group Data Protection in Health Information Systems Chair, GDD Working Group Security and Privacy in Health and Welfare
Interoperability Challenge
HP or HCE Action Patient Observation Data Consent Knowledge Interpretation Information Diagnosis Therapy Action
Interoperability Levels Interoperability Level Technical interoperability Structural interoperability Syntactic interoperability Semantic interoperability Organizations/Service interoperability Instances Technical plug&play, signal- & protocol compatibility Simple EDI, envelopes Messages, clinical documents, agreed vocabulary Advanced messaging, common information models and terminology Common business process
Requirements for Achieving Interoperability and Harmonization Openness, scalability, flexibility, portability Distribution at Internet level Standard conformance Service-oriented / semantic interoperability Consideration of timing aspects of data and information exchanged Lawfulness User acceptance Appropriate security and privacy services Model-Driven Architecture
Model A model is a partial representation of reality. It is restricted to attributes the modeller is interested in. Defining the pragmatic aspect of a model, the interest is depending on the addressed audience, the reason and the purpose of modelling the reality and using the resulting model for a certain purpose and for a certain time instead of the original. Therefore, the model as a result of an interpretation must be interpreted itself.
Electronic Health Records
Definitions (according to ISO TR 20514 Health informatics - Electronic health record Definition, scope and context ) (1/2) EHR A repository of information regarding the health status of a subject of care, in computer processable form. An EHR provides the ability to share patient health information between authorized users of the EHR and the primary role of the EHR in supporting continuing, efficient and quality integrated health care. EHR system The set of components that form the mechanism by which electronic health records are created, used, stored, and retrieved. It includes people, data, rules and procedures, processing and storage devices, and communication and support facilities.
Definitions (according to ISO TR 20514 Health informatics - Electronic health record Definition, scope and context ) (2/2) EHR architecture A model of the generic features necessary in any electronic healthcare record in order that the record may be communicable, complete, a useful and effective ethico-legal record of care, and may retain integrity across systems, countries, and time. In general, a system s architecture defines its components, their functionalities and relationships.
EHR Types Organization-centric EHR Personally moderated EHR Personal Health Record (PHR) Legal EHR Centralized EHR Distributed EHR
Requirements the EHR must meet: ISO 18308 after Kalra The EHR shall preserve any explicitly defined relationships between different parts of the record, such as links between treatments and subsequent complications and The outcomes. EHR shall preserve the original data values within an EHR entry including code systems and measurement units used at the The time EHR the shall data be were able originally to include the committed values of reference to an EHR ranges system. used to interpret particular data values. The EHR shall be able to represent or reference the calculations, and/or formula(e) by which data have been derived. The EHR architecture shall enable the retrieval of part or all of the information in the EHR that was present at any particular historic date and time. The EHR shall enable the maintenance of an audit trail of the creation of, amendment of, and access to health record entries.
Currently, three streams for specifying and implementing advanced EHR architectures, which partially have their roots in existing systems, in traditional thoughts and methodologies as well as in specific domain-languages and modelling languages: Data approach (data representation) Concept approach (concept/knowledge representation) Process/service approach (business process / service representation)
An alternative structure of current approaches with analogue methodologies and modelling languages under implementation focus is: Communication focus (message) Document focus (clinical document) Business process focus (application) According to the time dimension, following structure can be proposed: Episode focus (EHR extract) Life-long record focus (EHR service) Because of their rational roots and driving factors, all those approaches have their right to exist at least temporarily. Therefore, they exist also practically in co-existence or concurrency. The three approaches develop continuously, thereby showing some convergence.
Direct vs. Indirect EHR Access Model National (regional) switchpoint E.g. Netherlands, Greece Requires central client (patient), provider, and organizational registries Query/response paradigm used to retrieve discrete data versus Central respository(ies) E.g. (Canadian/UK/Finland) Requires central registries as above Discrete results uploaded to central/regional registries Centralized legal record in Finland 16 August 2007 14
EHR Approaches
EHR Approaches after HIMSS Wales Germany England The Netherlands Denmark Canada New Zealand
EHR Projects and Standards ISO TC 215 TS 18308, TR 20514 CEN EN 12967 Health Information System Architecture CEN EN 13606 EHR Communication openehr GEHR IHE RID: Retrieve Information for Display IHE XDS: Cross-enterprise Clinical Document Sharing G-CPR ASTM CCR HL7 RIM & CDA, EHR-S Functional Model, EHR-S Interoperability Model, CCD HARP DICOM SR: Structured Reporting WADO: Web Access to DICOM Persistent Objects EuroRec, ProRec Centers MML: The Medical Mark-up Language
Archetype Object Model 1.5 (after Beale)
ADL Archetype Structure (after Beale)
class CIMI Core Reference Model CIMI Core Reference Model (after CIMI) PATHABLE LINK + meaning :TEXT + target :EHR_URI + type :TEXT +links *..* LOCATABLE + name :TEXT + uid :UID_BASED_ID [0..1] + archetype_node_id :String +archetype_details 0..1 ARCHETYPED + archetype_id :ARCHETYPE_ID + template_id :TEMPLATE_ID [0..1] + rm_version :String COMPOSITION + category :CODED_TEXT + language :CODE_PHRASE + territory :CODE_PHRASE +content *..* CONTENT_ITEM *..* +items 1..1 +composer +performer 1..1 PARTY_PROXY 0..1 +provider PARTY_SELF +subject 1..1 SECTION +participations * PARTICIPATION + function :TEXT + mode :CODED_TEXT + time :DATE_TIME [0..1] +other_participation 0..* ENTRY + language :CODE_PHRASE 1 +data 1..* ITEM + null_flavor :CODED_TEXT [0..1] +items 1..* +value 0..1 DATA_VALUE CLUSTER + structure_type :CODE_PHRASE [0..1] ELEMENT
CIMI Hierarchical Representation (after CIMI) CLUSTER Name: Problem Diagnosis Meaning: 243796009 Situation with explicit context CLUSTER Name: Associated Problem Diagnosis Meaning: 404684003 Clinical finding Parent-child-link: 246090004 Associated finding ELEMENT Name: Problem Diagnosis Name Meaning: 404684003 Clinical finding Parent-child-link: 246090004 Associated finding Value: ϵ ProbDiag_RefSet CLUSTER Name: Location Details Meaning: 123037004 Body structure Parent-child-link: 363698007 Finding site ELEMENT Name: Body Site Meaning: 123037004 Body structure Parent-child-link: 363698007 Finding site Value: ϵ BodyStructure_RefSet ELEMENT Name: Laterality Meaning: 182353008 Side Parent-child-link: 272741003 Laterality Value: ϵ Side_RefSet ELEMENT Name: Severity Meaning: 272141004 Severities Parent-child-link: 246112005 Severity Value: ϵ Severity_RefSet ELEMENT Name: Finding Context Meaning: 410514004 Finding context value Parent-child-link: 408729009 Finding context Value: ϵ FindingContext_RefSet
The CDA Header & Body (after Heitmann) Header Document Information Encounter Service Actors Service Targets CDA Document Body Structured (Narrrative) Text, Coded Entries
General layout Medical Logic Modules (after HL7) maintenance: slotname: slotbody;; slotname: slotbody;; library: slotname: slotbody;; knowledge: slotname: slotbody;; end:
Overview on the CIMI Project (after CIMI)
National EHR Approaches
Strategy Some countries start with an infrastructure project (Germany, Austria, partially the Netherlands) Some countries focus on the record/repository (Austria) Some countries focus on a solutions architecture (Canada, Germany)
National EHR Strategy Examples England: National Programme for IT (NPfIT) Australia: HealthConnect, NEHTA Canada: Infoway, EHRS Blueprint USA: National Health Information Infrastructure (NHII), EHRVA Germany: bit4health, egk, ega Taiwan: National Health Information Exchange Platform France: DMP (Dossier Medical Personnel) The Netherlands: AORTA Wales: IHR/LLR within the Informing Healthcare Program (IHC) and probably 60+ other countries
International Programs and Budgets Examples Health Infoway ( Canada) By 2007, the government of Canada had invested $1.6 billion CAD in Infoway. By March, 2008, Infoway had committed nearly than $1.5 billion CAD in co-investment within the jurisdictions. 50% pop. have EMR Health Connect (Australia) NEHTA has received $160 AUD million in funding. All pts have EMR anytime Ctr. for Interoperable EHR (Korea ) 1.1 bill. USD by 2010 for universal EMR
International Programs and Budgets Examples National Program for IT ( UK) The National Programme for IT (NPfIT) was initiated in 2003 and was originally budgeted to be 6.0 billion over 10 years, but the National Audit Office estimates the figure to be 12.4bn over 10 years and other officials have been recently quoted in papers as estimating the figure to be close to 20.0 billion. Objective: IT infrastructure for safe and efficient health information transfer National Health Information Infrastructure ( USA) 86.5 mill. USD 2005, 125mill. USD 2006 for universal EMR. Within ARRA, more 40 billion US $ will be spent to provide a PHR to every American.
ELGA Project (after Sauermann, changed) Medical reports to be designed in CDA format: Discharge summary laboratory and radiology reports data segments for medication CDA level 2, partly 3 First trials in 2008 International standards mandated Approach: Preparation of a process choreography, accompanying measures, preparation of test beds Picking up all involved parties for realizing a joint, coordinated process
(after Hyppönen)
(after Hyppönen)
VISION ehealth and ewelfare space 2020 Audit LPWR Users Primary users Secondary users - context - purpose person Use control Legislation Regulations - Need to know - Restrictions - Rights - Permissions - Obligations - Confidentiality - consent - opt-out -. Requirements (dynamic, context aware) after Pekka Ruotsaleinen 33
Secondary user Environment, context, need to know, permission to access, role Information source 1 Granular context, purpose, security policy, semantics at time of creation At granular Primary requester Patientendossier - europäische Konzepte Environment, Request context, need to know, Context, purpose, permission to objects to access access, role LPWR Access and Disclose management E T H I C S R E G U L A Y I O N S output Information source n Granular context, purpose, security policy, semantics at time of creation 18. Oktober after Pekka 2012, Ruotsaleinen Olten, Schweiz 34 Subject of information Dynamic context aware permission opt-out in this context and for requested purpose Personal security policy Event log
Requirements for the LPWR Available general models: -Information models -Inf. system models after Pekka Ruotsaleinen Model: - Information model for the LPWR - Infrastructure model - Model for trusted use Requirements for infrastructure Health care specific models: -Information models -inf. system models 35
EHRS Blueprint Key Definitions: EHR Solution The EHR Solution is a combination of people, organizational entities, business processes, systems, technology and standards that interact and exchange clinical data to provide high quality and effective healthcare. 36
EHRS Blueprint Key Definitions: EHR Infostructure The EHR Infostructure is a collection of common and reusable components in the support of a diverse set of health information management applications. It consists of software solutions for the EHR, data definitions for the EHR and messaging standards for the EHR. 37
Key EHRS Architecture Concepts EHR SOLUTION (EHRS) EHR INFOSTRUCTURE (EHRi) EHRS Locator Ancillary Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services Health Information Access Layer Point of Service Application Point of Service Application EHR Viewer
EHR Infostructure: Conceptual Architecture JURISDICTIONAL INFOSTRUCTURE Registries Data & Services Ancillary Data & Services EHR Data & Services Data Warehouse Client Registry Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory Health Information Provider Registry Location Registry Business Rules EHR Index Message Structures Normalization Rules Terminology Registry Longitudinal Record Services Security Mgmt Data Privacy Data Configuration HIAL Common Services Communication Bus Public Health Services Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer ehealth Competence Public Health Center POINT University OF SERVICE Hospital Provider Regensburg Pharmacist Radiologist Lab Clinician Physician/ Physician/ Provider Provider Physician/ Provider
EHR Infostructure: EHRS Locator Data CROSS-JURISDICTIONAL INFOSTRUCTURE EHRS Locator EHRi Client ID (resolved ECID) CR instance ID (OID root) EHRi instance ID (which instance of an EHRi) EHRi URI (the URI to access the HIAL) Optimized for performance Information type (drug, lab, DI) (derived from HL7 act classes) First created date Last updated date JURISDICTIONAL INFOSTRUCTURE EHR SOLUTION (EHRS) EHR INFOSTRUCTURE (EHRi) EHR SOLUTION (EHRS) EHR INFOSTRUCTURE (EHRi) Ancillary Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Ancillary Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Longitudinal Record Services Longitudinal Record Services Health Information Access Layer Health Information Access Layer Point of Service Application POINT University OF SERVICE Hospital Regensburg Point of Service Application EHR Viewer Point of Service Application Point of Service Application EHR Viewer
English EHR Architecture England s EHR - the Spine - acts as a central Summary Record (CDAbased, ebxml) consists of the Spine Directory, Demographics Services, the Summary Care Record and adapters and is not an EHR. It contains only a small percentage of the information held in primary and secondary care systems. The English envisioned EHR contains a new network infrastructure as well as national applications that will utilize the EHR (e.g., electronic transfer of prescriptions, electronic outpatient scheduling). The EHR portion (the Care Record Service) includes three components: Personal Demographics Service (PDS), Summary Care Record (patient's clinical information, such as allergies and adverse reactions to medicine), Secondary Uses Service (SUS), which uses data from patient records to provide anonymised and pseudonymised business reports and statistics for research, planning and public health delivery.
English EHR Architecture (after Department of Health) The NHS turns between detailed information models on the one hand and extended terminology to include information models. The result is the Logical Record Architecture (LRA) for Health and Social Care in England. A generic model designed to work with the SNOMED CT terminology Domain models, derived directly from the Generic Model and terminology, designed to meet specified uses A catalogue of the requirements/uses for data, whether for direct care of patients or secondary uses, including analysis
LRA Modelling (after Department of Health) LRA Knowledge Modelling Domain and Analysis Scoping Review and Establish Requirements, Determine Information and Process Concepts Output Requirements Catalogue Stakeholder Information View Stakeholder Business Model Logical Analysis Modelling, Detailed Definitions, and Traceability of Requirements, Pathways, and Information Concepts Output Information Analysis Model Use Case Model Business Process Model LRA Technical Modelling LRA Analysis Identify Existing and/or New Requirements for Data Element Definitions, Queries, and Data Aggregation Models Output Information Descriptions Query Functionality Candidate Data Element Definitions Technical Model Artefact Development Select existing or model new SNOMED CT terminology bound ELEMENTs and (terminology neutral) ENTRYs to satisfy Candidate Data Element Definitions and Information Descriptions Output ELEMENTS ENTRYs LRA Repository Interface Artefact Model Development Select existing or create new Data Element Definition and Refined Technical Model constraints of ELEMENTs and ENTRYs; select existing or create new Query Specifications. Output Data Element Definitions Refined Technical Model Query Specifications
The record structure
LRA Core Components (after Department of Health) SNOMED CT terminology Description Logic BS/ISO/EN13606 Electronic Health Record for Communications object model HL7 Data Types (draft ISO) UCUM Units of Measure
The LRA Base Elements (after Department of Health) Element Observation Activity Relationship Property Finding Investigation Substance Activity General Activity
The 5 Layers for Analysis of Care Records Business focused Requirements Current Data Dictionary Human focused Business Rules Classification / Grouping Rules (logic) Query (constraint ) Specifications Current Data Model Logical Care Record Model
LRA Requirements (after Department of Health) Metrics Other dataset developments Pathways Logical Record Architecture Social care
Implementation cycle Standards Development cycle Patientendossier - europäische Konzepte LRA Content Development (after Department of Health) Use case Purpose & scope Library Requirement Elaboration Elaboration Design Metadata Registry Design Construction Construction
Local National Use case Purpose & scope Library Requirement Elaboration Elaboration Design Metadata Registry Design Construction Construction Templates and forms Terminology and archetypes
DMP: a French national ehealth record DMP (Dossier Médical Personnel) will be: a private medical file digitalised aimed at favouring coordination, quality and continuity of care; a file shared by Healthcare professionals (HCP) but under the holder's control (i.e. The patient manages its access, the holder can hide documents...) not a substitute for professional files of HCP in ambulatory care or in Hospital accessed through : Web Portal for holder's Only through professional application for Healthcare professionals to maximize ergonomy and avoid time-consuming change of application consisting of data (structured or not) signed by the author (at first only by the HCP)
DMP: A health record needing adequate protection As a health record, the DMP needs to be: Available Opens 7/24 Availability 99,9% (total amount of interruption of 8 hours a year) Protective of data integrity and confidentiality Protected communications (SSL) Restrictive access to a DMP (esafe, HCP rights defined by law) Separation of trusted services (authentication) and data housing * Caisse des Dépôts et Consignations is a state-owned financial institution that performs public-interest missions on behalf of France s central, regional and local governments. Good level authentication
DMP: A record used by numerous actors
Dutch Design of the Architecture, Basic Infrastructure, for Healthcare after NICTIZ, 2002
Dutch ehealth Activities Scheme after NICTIZ, 2004
Turkey National EHR Approach Development of an Adaptor for automatically transforming National Health Information System (NHIS)of Turkey Transmission Schema instances to HL7 CDA R2 conformant EHRs Development of a Terminology Server based architecture enabling automatic mappingof the local coded terms that appear in the NHIS Transmission Schema instancesto international counterparts Development of an Adaptor for automatically transforming CDA conformant NHIS Transmission Schema instances to CEN EN 13606 conformant EHRs
The Architecture of the Transformation Environment for National Health Information System (NHIS) of Turkey after Assuman, 2008
Healthcare System Vison for Croatia after Blazona, 2007
German Approach There are two streams in the German EHR approach: An architecture-centric, intelligent, adaptive solution specifications based on international standards and partially borrowed from the Cnadian EHR-S Blueprint, launched by the Federal Ministry for Economy and realized by the An set of pilots more or less independent from international standards and international experiences, launched by the Federal Ministry for Health and realized by different hospital trusts, Fraunhofer Institutes and others
German EHR Architecture Registries Common Services EHR System Health Data Warehouse Longitudinal Record Services Communication Bus Common Services Resource Locator Service Connector Connector Connector Connector Application 1 Application 2 EHR Viewer
ehealth Components (Logical View) Knowledge Services Application Services Policy Services ID CA Services Client Services EHR Systeme PKI PMI ACA Services Ontology Services Terminology Services Audit Services Dir./Reg. Services Gesundheitskarte Name Zeile 1 Name Zeile 2 Name der Krankenkasse 123456789 A123456789 Kassennummer Versichertennummer
Thank you for your attention! Prof. Dr. rer. nat. habil University of Regensburg Medical Center Franz-Josef-Strauss-Allee 11 D-93042 Regensburg, Germany Email: bernd.blobel@klinik.uni-regensburg.de Phone: +49-941-944 6769 Fax: +49-941-944 6766 http://www.ehealth-cc.de