Implementation and Use of ISO EN 13606 and openEHR


Published on

This was the prezo for the EMBC 2013 tutorial in Osaka, Japan. Intended for an introduction to the standards and technicalities and implementation of openEHR - which is the original formalism.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I was trained as a medical doctor with PhD in Information Systems and a Fellow of the Australasian College of Health Informatics. My main research interests are clinical information modelling, interoperability standards and software maintainability. I lead the openEHR Localisation Program, sit in HL7 New Zealand Board and Executive Committee of Health Informatics Association (HINZ).Based at the University of Auckland, I am using openEHR Archetypes to create computable clinical information models. I have co-authored the national Interoperability Reference Architecture (HISO 10040) underpinned by openEHR I lead the technical evaluation and procurement of major health IT projects and advise the government and industry.
  • New Zealand is a small nation but with very good profile in healthcare. Health IT has been an important enabler, and key factors for success are: a single tier of government; strongclinical leadership and collaboration amongst stakeholders; and the role played by national leadership groups like the National Health IT Board. New Zealand was among the first countries in the world to establish an unique health identifier for all citizens which gives us the ability to link our health information easily and safely.New Zealand is focusing on clinically-led innovative models of care; greater involvement of patients and consumers in designing future health services; and greater integration of investment in IT, workforce and infrastructure – all supported by health IT.
  • It is generally accepted that the following types of interoperability exist: First one is the technical interop. which simply means that systems can exchange data. ISO, the..., calls this type of interop. as Fxn... Second type of interop. is SI - which means that not only can systems exchange information but also the meaning of that information is to be faithfully preserved in the receiving end and processed accordingly The third one is the Proc. Interop which is related with how well the business processes and clinical workflows are supported and continued in different systems. This also involves agreeing on essential information to enable seamless execution of workflows: such as definition of actors, user roles etc.
  • We can now write portable queries in terms of semantic elements rather than only in terms of underlying data modelQueries can be built by domain users, not IT people
  • Archetypes support multiple languages and terminology bindings
  • What standards do we need to reach the 2014 goal?Of these, HISO 10040 is an interim standard (awaiting trial implementation)NIHI is currently reviewing 10041 suite of main clinical information types based on the content model
  • These are the three building blocks – or pillars – of the HISO 10040 series that embodies the central ideas of the Reference Architecture for Interoperability10040.1 is about regional CDRs and transport10040.2 is about a content model for information exchange, shaped by the generic information model provided by CCR, with SNOMED as the default terminology, and openEHR archetypes as the chief means of representation10040.3 is about CDA structured documents as the common currency of exchange – not every single transaction type, but the patient information-laden ones
  • Published by HISO (2012); Part of the Reference Architecture for Interoperability“To create a uniform model of health information to be reused by different eHealth Projects involving HIE”Consistent, Extensible, Interoperable and Future-Proof DataWe will work with Australia and share their Archetype repository as health systems and culture is very similar.
  • Content is ‘clinician’s stuff’ – not techy; yet most existing standards are meaningless for clinicians and vice versa for techiesopenEHR Archetypes are in ‘clinical’ space – easily understood and authored by themArchetypes can be transformed into numerous formats – including CDAArchetypes are ‘maximal datasets’ e.g. They are much more granular than other models when needed. Support more use cases – indeed almost anything to do with EHR (including some workflow). Scope not limited to HIE but whole EHR.One agreed way of expressing clinical concepts – as opposed to multiple ways of doing it with HL7 CDA (CCDA is a good first step though)ECM invest in information fulfilled completely – future proof technology today with ECM for tomorrow’s implementation technology (e.g. FHIR etc., distributed workflows etc.)
  • Definition of health information in each use case (different CDA documents or using Web services based exchange) comes from the same library.With Archetype specialisation all data collected using definitions of different granularities are semantically compatible.For example a query retrieving all Lab Tests (not specifically HbA1c) will also fetch all specialised versions of Lab Tests.
  • CDA definitions for messaging is not a starting point but an end point.The source of truth for health information definition is with the Content ModelIt is possible to create CDA definitions based on specific use cases using automatic or semi-automatic XSL transforms.
  • A significant opportunity arises for secondary use in this scheme by the use of a data repository that can natively persist and query standardised datasets. Since all health information in transit in various formats (e.g. HL7) within a standard message (payload) conforms to the Content Model, all data persisted in this repository can safely be linked, aggregated and analysed.
  • NIHI’s big data initiative in healthcare.It is an information infrastructure (or infostructure) to enable collection, validation, storage, querying, linking, reporting of health data from multiple sources in a secure manner. It will enable secondary use of healthcare data and foster public health, health research and educationProof of Concept in progress
  • One important feature of PMS is that there are standard interfaces so that add-on applications can be added.This is the most commonly used CVD risk assessment and management tool – PREDICT housed at the University of Auckland/NIHI.If the patient meets inclusion criteria, PREDICT is invoked at the end of the GP encounter which prepopulates data from PMS and allows for GP to enter additional data. Using the Framingham based algorithm 5 year risk of CVD events are calculated together with clinician and patient advice. A management plan is printed and given to the patient.Underlying data is aggregated at NIHI and used for research. We can link this rich cohort to national collections, pharmacy dispensing and lab tests.
  • Implementation and Use of ISO EN 13606 and openEHR

    1. 1. Implementation and Use of ISO EN 13606 and openEHR Koray Atalag MD, PhD, FACHI
    2. 2. About National Institute for Health Innovation (NIHI) The University of Auckland Private Bag 92019, Auckland New Zealand Koray Atalag, MD, PhD, FACHI Medical Doctor, PhD Information Systems Fellow of Australasian College of Health Informatics Chair openEHR New Zealand openEHR Localisation Program Leader HL7 New Zealand Board Member Health Informatics New Zealand Executive Member ISO TC215 Working Group Member
    3. 3. New Zealand Quick Facts • Population: 4.5million – (~20% Maori & Pacific) – <30 million sheep >60 million cattle! • GDP (PPP) per Capita: USD 28,800 • Good healthcare, low cost • High IT adoption, good integration • Single health identifier ~20 years • National eHealth strategy and plan – National Health IT Board
    4. 4. 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 1980 1984 1988 1992 1996 2000 2004 2008 US ($8,233) NOR ($5,388) SWIZ ($5,270) NETH ($5,056) DEN ($4,464) CAN ($4,445) GER ($4,338) FR ($3,974) SWE ($3,758) AUS ($3,670)* UK ($3,433) JPN ($3,035)* NZ ($3,022) Source: OECD Health Data 2012. Average Health Care Spending per Capita, 1980–2010 Adjusted for Differences in Cost of Living 4 Dollars ($US) THE COMMONWEALTH FUND* 2009
    5. 5. 5 99 97 97 96 95 94 72 46 68 37 98 98 97 97 92 88 82 69 67 56 41 0 20 40 60 80 100 NETH NOR NZ UK AUS SWE GER US FR CAN SWIZ 2009 2012 Source: 2009 and 2012 Commonwealth Fund International Health Policy Survey of Primary Care Physicians. Percent GPs Use of Electronic Medical Records in Their Practice, 2009 and 2012
    6. 6. Types of Interoperability  Technical Interoperability: systems can send and receive data successfully. (ISO: Functional/Data Interoperability)  Semantic Interoperability: information sent and received between systems is unaltered in its meaning. It is understood in exactly the same way by both the sender and receiver.  Process Interoperability: the degree to which the integrity of workflow processes can be maintained between systems. (This includes maintaining/conveying information such as user roles between systems) (HL7 Inc.)
    7. 7. Read The Standards Solar System HL7 V3V2 SNOMED ICD10 IHE UML openEHR ISO Data Types UMLS ASTM DICOM HISA CEN TC251 EN13606 ICD9CM CDA CCR
    8. 8. ISO EN 13606 & openEHR • 13606 is a subset of openEHR specification – Snapshot ~2008-2010 – Update in progress (sync w/ openEHR) • Not a full EHR standard – for health summary exchange • Main divergence – Reference Model
    9. 9.  Open source specs & software for representing health information and person-centric records – Based on 18+ years of international implementation experience including Good European Health Record Project – Superset of ISO/CEN 13606 EHR standard  Not-for-profit organisation - established in 2001  Extensively used in research  Separation of clinical and technical worlds • Big international community
    10. 10. Key Innovations “Multi-level Modelling” – separation of software model into distinct layers: 1) Technical information model (generic) 2) Concept models: Archetypes (domain-specific) 3) Terminology/Ontology (SNOMED etc.) Software code is based on only the first layer Driven by Archetypes in run-time High level semantics delegated to terminology
    11. 11. Multi-Level Modelling
    12. 12. Logical building blocks of EHR Compositions Set of entries comprising a clinical care session or document e.g. test result, letter EHR The electronic health record for one person Folders High-level organisation of the EHR e.g. per episode, per clinical speciality Sections Clinical headings reflecting the workflow and consultation/reasoning process Clusters Compound entries, test batteries e.g. blood pressure, full blood count Elements Element entries: leaf nodes with values e.g. reason for encounter, body weight Data values Date types for instance values e.g. coded terms, measurements with units Entries Clinical “statements” about Observations, Evaluations, and Instructions
    13. 13. openEHR Reference Model
    14. 14. Example: DV_TEXT Data Type
    15. 15. Healthcare Specific Aspects of RM
    16. 16. Top Level Organisation of EHR
    17. 17. Unit of Contributions to EHR
    18. 18. Anatomy of an Archetype
    19. 19. Archetype Definition Language (ADL) OCL + DDL
    20. 20. Archetype based Queries • Path-based – not brute-force like SQL • Archetypes provide ‘map’ to data items • Use ‘clinical-speak’ rather than ‘tables/fields’ etc. openEHR EHR
    21. 21. Archetype Query Language (AQL) SELECT o/data[at0001]/events[at0002]/time, o/data[at0001]/ev ents[at0002]/data[at0003]/items[at0013.1]/value FROM Ehr[uid=@EhrUid] CONTAINS Composition c[openEHR- EHR-COMPOSITION.encounter.v1] CONTAINS Observation o[openEHR-EHR-OBSERVATION.laboratory- lipids.v1]
    22. 22. Localisation Content definition is language independent
    23. 23. State of the world • US: advanced provider-centric systems but little inter- connectivity (HL7 v2/CDA) • Canada: CHI providing leadership & standards (v2/v3/CDA) • UK: bootstrapping from CfH disaster, focus on high value/established systems (HL7/13606) • Nordic: well established, (↑13606 / HL7 v2/CDA) • EU: very patchy – HL7/↑13606/openEHR • Asia: patchy -propriety / HL7 / little 13606/openEHR • Brazil/Paraguay: mainly openEHR & HL7 v2/CDA • Australia: Nehta/PCEHR, v2/v3/CDA & openEHR
    24. 24. Towards EHR in New Zealand • Core health information available electronically by 2014 – no EHR speak ;) • National planning, regional implementations • Shared Care and PrimarySecondary – Shared care projects: long term conditions, maternity, well child etc. • Clinical Data Repository (CDR) as enabler – GP2GP, Transfer of Care – ePrescribing & medicines reconciliation – Others: NZULM, new NHI/HPI • Good emphasis & support for standards
    25. 25. HISO 10040 Health Information Exchange 10040.1 R-CDRs XDS 10040.2 CCR SNOMED CT Archetypes 10040.3 Documents CDA
    26. 26. The Principles 1. Align to national strategy: as per national and regional plans 2. Invest in information: use a technology agnostic common content model, and use standard terminologies 3. Use single content model: information for exchange will be defined and represented in a single consistent way 4. Align to business needs: prioritise the Reference Architecture in line with regional and national programmes 5. Work with sector: respect the needs of all stakeholders 6. Use proven standards: adopt suitable and consistent national and international standards wherever they exist (in preference to inventing new specifications) 7. Use a services approach: move the sector from a messaging style of interaction to one based on web services
    27. 27. What is ECM? • IT IS A REFERENCE LIBRARY - for enabling consistency in HIE Payload • Superset of all clinical dataset definitions – normalised using a standard EHR record organisation (openEHR) – Expressed as reusable and computable models – Archetypes • Top level organisation follows CCR • Further detail provided by: – Existing relevant sources (CCDA, Nehta, epSoS, HL7 FHIR etc.) – Extensions (of above) and new Archetypes (NZ specific) • Each HIE payload (CDA) will correspond to a subset (and conform)
    28. 28. Usage of the Content Model
    29. 29. Creating CDA Payload
    30. 30. Exploiting Content Model for Secondary Use Single Content Model CDA FHIR HL7 v2/3 EHR Extract UML XSD/XMI PDF Mindmap PAYLOAD System A Data Source A Map To Content Model System B Data Source B Native openEHR Repository Secondary Use Map To Content Model Automated Transforms No Mapping
    31. 31. Shared Health Information Platform (SHIP)
    32. 32. Implementation Examples • PREDICT CVD Risk Prediction and Management System (NZ) – Primary care Decision Support System – Secondary use: research database • NZ Cardiac Events Registry – Extending PREDICT to hospitals – Also secondary use like PREDICT • GastrOS Endoscopy Reporting System (NZ) – Clinical Information System
    33. 33. PREDICT & Cardiac Registry • Fully fledged CDSS + research database + clinical QI – Extending to secondary (acute Predict) – Improving risk prediction models – Creating a variation map/atlas of NZ • Data linkages to: – National Mortality Register, – National Minimum Dataset (public and private hospital discharges) – National Pharmaceutical Collection (drugs dispensed from community pharmacies with government subsidy) – National PHO Enrolment Collection – Regional CVD-relevant laboratory data
    34. 34. PREDICT CVD Decision Support System
    35. 35. PREDICT Dataset Definitions
    36. 36. Current PREDICT Model
    37. 37. Results  Archetype based content model can faithfully represent PREDICT dataset • Modelling: – two new archetypes‘Lifestyle Management’ and ‘Diabetic Glycaemic Control’ checklists – NZ extensions for demographics (DHB catchment, meshblock/domicile, geocode NZDep) • Difficulty: overlap between openEHR and NEHTA repositories – different archetypes for tobacco use, laboratory results and diagnosis which we reused – Considering both repositories are evolving separately it is challenging to make definitive modelling decisions.
    38. 38. PREDICT extensions  ECM
    39. 39. NZ Cardiac Registry (ANZACS-QI)
    40. 40. GastrOS – Endoscopy Reporting Atalag K, Yang HY, Tempero E, Warren J. Model Driven Development of Clinical Information Systems using openEHR. Stud Health Technol Inform. 2011;169:849–53.
    41. 41. Study Context • Maintaining software in healthcare is hard! – Real world experience: endoscopy reporting application – Almost entirely driven by MST – standard domain terminology (Minimal Standard Terminology for Digestive Endoscopy – version 2) • Essence of problem: – Biomedical ‘stuff’ is volatile – hardcoding domain knowledge into sofware (code + DB) • New Model Driven Development – using openEHR – Archetype modelling + Defined GUI directives – Extended openEHR.NET library (Ocean Informatics) – Formal comparative evaluation of the ‘old’ and ‘new’ system – ALL Open Source 
    42. 42. Maintenance of HIS • Constitutes the majority of development costs • Degrades overall quality / longevity / satisfaction • Source of problem change in domain related requirements (mostly functional) • How? – Incomplete / wrong req. at outset – New / no longer valid requirements • Why? – Essential + handover – Volatility of domain concepts & processes
    43. 43. An Important “bottleneck” • Cognitive friction /limits to human communication • Unknown requirements • Wrong requirements Changing requirements?
    44. 44. Research Questions • Is openEHR implementable at all? Feasible? (for our specific requirements) • How to create usable GUI? • Is it bad to hardcode domain knowledge into software (code + DB) • Can software evolve without (significant) techy intervention? To what extent? • Any other challenges?
    45. 45. Research Domain • Gastroenterologic Endoscopy – A small and manageable (niche) domain – Visualisation of the gastrointestinal tract for both diagnostic and therapeutic purposes – Quite invasive procedure  results need to be reliable, complete and unambiguous – Good level of common medical language – Worldwide accepted terminology
    46. 46. Minimal Standard Terminology for Digestive Endoscopy (MST) – Initiated by the European Society for Gastrointestinal Endoscopy (ESGE) in 1990 – Joined by the Japanese endoscopy association – Now official terminology for World Society of Gastro- intestinal Endoscopy (OMED) – A "minimal" list of terms for use in computer system used to record the results of a gastrointestinal endoscopy – Validation in EU project – GASTER and an US project – Already integrated with the NLM’s Unified Medical Language System (UMLS) – Eleven language translations (inc. Japanese)
    47. 47. MST Organization
    48. 48. Endoscopic Observation / Procedure Heading Term Attribute Value Site MST Findings for Duodenum MST Hierarchy MST Structure
    49. 49. Implementation Methodology • GastrOS: Windows forms app using .Net/C# • A basic ‘Wrapper’ + SDE component • openEHR.Net: Release 1.0.1 RM & AOM • Templates with GUI Directivesoperational templates (XML) • Creates GUI automatically, validates and persists user entered data • Also extended model beyond MST to include vitals & adverse reactions – hard stuff!
    50. 50. GUI Directives • Archetypes & Templates only to do with structure + semantics of health information • Need to define presentation aspects • Majority thinks a separate model for that • We don’t: – hard to separate at times – Archetypes expected to change rapidly so maintaining a separate model might be hard – Perhaps with good tooling might work • We exploited Template Annotations
    51. 51. SDE Parser OPT Reference Model Skeleton Instance (ENTRY types, CLUSTERS) GUI Form: Widgets+Leaf nodes(ELEMENT) SDE GUI Generator AOM Representation
    52. 52. Conclusions • Is openEHR implementable at all? Feasible? (for our specific requirements)  YES • How to create usable GUI?  Described • Is it bad to hardcode domain knowledge into software (code + DB)  DEFINITELY • Can software evolve without (significant) techy intervention? To what extent?  Cautious Yes • Any other challenges?  need more time!!!
    53. 53. Maintainability Assessment – Maintenance vs. maintainability – ISO/IEC 9216 and 25000 Software Quality std. – External QualityMaintainability characteristic; Changeability Subcharacteristic – Two metrics: (mainly look at maintenance tasks) • Change cycle efficiency (CCE)time from initial request to resolution of the problem • Modification complexity (MC)sum of time spent on each change per size of software change divided by total number of changes – 10 CR – real ones from GST usage – SVN + JIRA tools for documentation + measure
    54. 54. Maintainability Assessment No Type Description Time (min) Changed LOC GST GastrOS GST GastrOS 1 Fix MST: Anatomic site (colon): add site anal canal 3 10 1 83 2 Ext MST: Findings (stomach): add term rapid urease test | add attribute result | add attribute values positive and negative 30 5 45 37 3 Fix MST: Findings (stomach and colon>protruding lesions>tumor/mass): add attribute: Diameter | change attribute value diameter in mm.  in mm. 50 13 92 2 4 Ext MST: Findings (colon>protruding lesions>hemorrhoids): add new attribute type and add attribute values Internal and External 30 7 46 23 5 Fix MST: Therapeutic procedures (Sphincterotomy>Precut): add attribute value No 6 5 1 4 6 Ext MST: Therapeutic procedures (Thermal therapy>Device): add attribute value Heat- probe 11 5 1 4 7 Ext MST: Diagnoses (stomach): add main diagnoses Antral superficial, Pangastritis, Atrophic, Alkaline reflux and Somatitis 6 8 4 20 8 Ext MST: Diagnoses: Add free text description for each organ 50 10 60 20 9 New Other: Split lower gastrointestinal examination type into colonoscopy and rectoscopy. Bind both types to Findings for colon 30 10 6 2 10 New Other: Localise MST Findings for Stomach form to English 1116 70 722 499 TOTAL 1332 143 978 694 Metric GST GastrOS CCE 133.20 14.30 MC 0.14 0.02 CCE 9 times less effort overall to modify GastrOS MCthe changes were on average 7 times less complex
    55. 55. Questions?
    56. 56. Automatic Production of CDA R2 using openEHR Archetypes and Templates openEHR Standarised Semantic Environment Client Data Client Schema Validates Client Systems Archetypes Templates Implementation Standardised XML Environment Template Data Schema Generate from Tools Template Data Document Validates Continued…
    57. 57. CDA (CCD) CDA R2 ValidatesopenEHR CEN 13606 Archetype based standard XSL Transform Template Data Document Standard Transform for CCD openEHR Display
    58. 58. Challenges for Implementing CDA R2 messaging HealthServicesVendorSystems HL7 V2 Messaging HealthServicesVendorSystems • Well understood • Lots of expertise • Many tools for V2 integration • Many systems natively support V2 messaging at some level
    59. 59. Challenges for Implementing CDA R2 messaging HealthServicesVendorSystems CDA R2 Messaging HealthServicesVendorSystems • Less well known/understood • Highly abstract schema – complex to express semantics • Little expertise • Few tools • Expensive to re-engineer systems to natively support CDA
    60. 60. A practical first step HealthServicesVendorSystems CDA R2 HealthServicesVendorSystems • XML is well understood • XML expertise is common • XML Tools are widely available • Able to be automated • CDA messages conform to an agreed standardised schema and reduce the need for ‘pre-negotiation’ Translation layer using standardised XML transforms Translation layer using standardised XML transforms Highly abstract schema
    61. 61. Bottom Line openEHR is the only means to capture clinical requirements and turn them into computable artefacts Modelling with Archetypes is ‘standards agnostic’ – no commitment for openEHR implementation pathway A full blown international standard (13606) Clinical content can be transformed HL7openEHR/13606 Makes terminology WORK!
    62. 62. Recommended Steps for National eHealth Programs • 1) Develop a set of clinical models in a formalism that is international and computable - openEHR is really the only candidate here. The initial models may only be for those 10 or 20 top pieces of clinical information that need to be shared. • 2) These models can be used without requiring a commitment to openEHR everywhere by publishing XML schemas that are derived from template based use cases; i.e. GP notes, discharge summary etc. • 3) XML schemas can be used by vendors without a commitment to openEHR. Data instances that conform to the schemas can be transformed into HL7 messages or openEHR instances. • 4) These messages can either be consumed by message based systems or converted back into XML data instances that conform to the schemas. This enables everyone to be compliant with only XML skills. There is still a large role for HL7 to in transport related space; not only messaging but also terminology service, identifiers, etc.