Il lavoro di armonizzazione. e HL7

Transcription

1 Il lavoro di armonizzazione tra CEN 13606, openehr e HL7 Dr Dipak Kalra Centre for Health Informatics and Multiprofessional Education (CHIME) University College London d.kalra@chime.ucl.ac.uk

2 Drivers for the EHR Manage increasingly complex clinical care Connect multiple locations of care delivery Support team-based care Deliver evidence-based health care Improve safety reduce errors and inequalities reduce duplication and delay Improve cost effectiveness of health services Underpin population health and research Empower and involve citizens Protect patient privacy

3 Clinical data life-cycle Point of care delivery Citizen in the community Teaching Research Clinical trials explicit consent Continuing care (within the institution) Education Research Epidemiology Data mining de-identified +/- consent implied consent Public health Health care management Clinical audit Long-term shared care (regional national, global) Governance requirements Faithfulness Completeness Medico-legal integrity Standards conformance Consistent semantics Privacy management Holistic requirements Empowering and respecting Educating Supporting diverse cultures and professions Capable of evolution

4 In a generated medical summary List of diagnoses and procedures Procedure Diagnosis Procedure Diagnosis Diagnosis Appendicectomy Meningococcal meningitis Termination of pregnancy Acute psychosis Schizophrenia Can we safely interpret a diagnosis without its context?

5 Clinical interpretation context Emergency Department Seen by junior doctor Reason for encounter Brought to ED by family Symptoms They are trying to kill me Junior doctor, emergency situation, a working hypothesis so schizophrenia is not a reliable diagnosis Mental state exam Hallucinations Delusions of persecution Disordered thoughts Diagnosis Schizophrenia Certainty Working hypothesis Management plan Admission etc...

6 The virtual EHR Clinical trials, functional genomics, public health databases EHR repositories Decision support, knowledge management and analysis components Date: Shared logical EHR Whittington Hospital Healthcare Record Personnel registers, security services John Smith Shared domain DoB: knowledge Mobile devices Clinical devices, instruments Clinical applications

7 The role of EHR interoperability standards Clinical trials, functional genomics, public health databases EHR repositories Decision support, knowledge management and analysis components openehr Date: Whittington Hospital Personnel registers, security services Healthcare Record ISO/EN John Smith DoB: EHR archetypes Mobile devices Clinical devices, instruments Clinical applications

8 Logical EHR architectural components Persistence services Logical EHR model Archetype and terminology services Audit services Access control and privilege management services Query and retrieval Data entry and validation Standards conformant interfaces (esp. ISO/EN 13606)

9 Links with other components: HISA EN12967 Learning resources Workflow, guidelines Comms & security Online knowledge Terminology Standard virtual EHR Interfaces Clinical applications Persons, resources Finance, billing

10 Research and interoperability standards EU and Australian R&D projects EHR quality and interoperability requirements EHR reference models Early archetype approach 1995 pre-standard 1999 pre-standard Richer EHR models Archetype formalism and tools Archetype authorship and governance Open source reference implementations ISO/EN implementation guide Ongoing evaluation & refinement

11 CEN/ISO EHR Communications Standard A means to exchange part or all of a patients EHR between heterogeneous systems within a federation of distributed EHR systems Meets published EHR requirements 15 years of R&D and 2 past CEN EHR standards Five part standard 1. information model 2. archetype model 3. term lists 4. security 5. service interfaces

12 Parts of ISO/EN Part 1: Reference Model comprehensive, generic model for communicating part or all of an EHR Part 2: Archetype Specification constraint-based approach for defining clinical business objects that are built from the Reference Model - adopted from openehr Part 3: Reference Archetypes and Term Lists initial set of archetypes mapping to other relevant standards vocabularies for the Part 1 model Part 4: Security measures to support access control, consent and auditability of EHR communications Part 5: Interface specification message and service interfaces to enable EHR and archetype communication

13 Contextual building blocks of the EHR EHR Extract Folders Compositions Sections Entries Clusters Elements Data values Part or all of the electronic health record for one person, being communicated High-level organisation of the EHR e.g. per episode, per clinical speciality Set of entries comprising a clinical care session or document e.g. test result, letter Headings reflecting the flow of information gathering, or organising data for readability Clinical statements about Observations, Evaluations, and Instructions Multipart entries, tables,time series, e.g. test batteries, blood pressure, blood count Element entries: leaf nodes with values e.g. reason for encounter, body weight Date types for instance values e.g. coded terms, measurements with units

14 EN Reference Model

15 EN Reference Model

16 Harmonisation with HL7 and IHE HL7 Meets the Infrastructure requirements of the EHR Functional Model An conformant R-MIM has been designed Detailed cross-mapping to Clinical Document Architecture Collaboration on archetype and template specifications Contributed to the Clinical Statement model design An HL Implementation Guide is being developed IHE XDS specification contributed to architecture and metadata mapping to registry metadata So XDS can store and share EHR Extract data

17 R-MIM (draft)

18 : Potential users of EHR data Clinical governance Clinical team Teaching team Healthcare organisation the patient Research team Date: Health service Whittington Hospital Healthcare Record John Smith DoB: Research funder Publisher, the press family & carers Public health Commercial organisation The public Professional organisation

19 Policies for EHR access need to specify: Which institutions should normally have access If certain teams or specialities should have privileged access If particular users should be excluded, or given wide access If consent has been granted for teaching, specific research or generic research EHR communication needs to ensure that such consent specifications are represented and communicated in a standardised way

20 : Communicating EHR access consent ACCESS_POLICY policy_id [1]: II author [1]: II date_committed [1]: TS previous_version [0..1]: II effective_start [0..1]: TS effective_end [0..1]: TS policy_attestation EHR_target 1..* ATTESTATION time [1]: TS performer [1]: II proof [0..1]: ED function [0..1]: CV 0..* TARGET access_rules request_characteristics rc_ids [0..1]: SET<II> archetype_ids [0..1]: SET<II> time_period [0..1]: IVL<TS> other_criteria [0..1] SET<String> 1 MAX_SENSITIVITY_CONSTRAINTS access [1]: INT write [0..1]: INT modify [0..1]: INT communicate [0..1]: INT version_history [1]: BL other_constraints [0..1]: SET<String> NOTE: The INT value corresponds to one of the values of CS_SENSITIVITY and matches the values of the sensitivity attribute of RECORD_COMPONENT 0..* NOTE: If no target criteria are specified this policy applies to the whole EHR_EXTRACT REQUEST functional_roles [0..1]: SET<CS_FUNC_ROLE> structural_roles [0..1]: SET<CV> functional_responsibilities [0..1]: SET<CV> clinical_settings [0..1]: SET<CS_SETTING> specialities [0..1]: SET<CV> parties [0..1]: SET<II> other_characteristics [0..1]: SET<String> NOTE: If no requestor characteristics are specified this policy applies to all requests

21 : Who has been looking at my record?

22 Towards consistency of meaning The EHR Reference Model standardises the way of representing and sharing the clinical and medico-legal contexts helps to ensure that EHR data can be interpreted longitudinally and internationally BUT......Part 1 cannot on its own ensure the consistency or completeness of the clinical content, or define how terminology is used Part 2 standardises Archetypes for this purpose

23 What is an openehr/13606 Archetype? A formal sharable model of a clinical domain concept e.g. blood pressure, discharge summary, fundoscopy Uses classes defined in an EHR Reference Model allows data quality constraints to be placed on the organisation and content of record entries Can be published and shared within a clinical community, or globally May be mapped to the specific information in each clinical (EHR) system Defines a systematic EHR target for decision support queries

24 openehr / Archetypes: a shared library of clinical data structures

25 openehr / Archetypes: a shared library of clinical data structures

26 Ocean Informatics Archetype Editor

27 University of Linköping Archetype Editor

28 Ocean Informatics Archetype Finder

29 University of Manchester MoST plugin to bind archetype nodes to SNOMED CT

30 Ocean Informatics Template Composer

31 UCL archetype-driven clinical applications and portal

32 A growing library of archetypes

33 Next challenges for archetypes Clinical communities need to be fostered to contribute domain expertise into the design of archetypes to champion professional consensus on organising EHRs EHR Archetypes need to be quality assured since they will direct the ways in which clinical data is captured, processed and communicated EuroRec is partnering the openehr Foundation in developing governance practices for archetype development quality criteria and editorial policies by which certified libraries of EHR Archetypes can be recognised

34 Conclusion: the EHR Communications standard defines a logical model for the core EHR supporting interoperability between heterogeneous systems providing a common view across message paradigms meets published EHR requirements draws on 15 years of significant R&D including multi-national implementation experience draws on two generations of CEN EHR standard is being translated into an HL7 v3 RMIM incorporates openehr archetypes for sharing semantic structures offers a framework for sharing disclosure consent and access control information