Overview of GEHR Dr Peter Schloeffel open EHR Foundation

1. The Good Electronic Health Record Overview of GEHR Dr Peter Schloeffel openEHR Foundation

2. EHR definition • “… a repository of information in computer readable format regarding the health of a subject of care” Committee for European Normalisation (CEN) • “… an electronic longitudinal collection of personal health information, based on an individual or family, and entered or accepted by healthcare professionals. [It] can be distributed over a number of sites or aggregated at a particular source including a hand-held device. The information is organised primarily to support continuing, efficient, and quality healthcare.” Australian National EHR Taskforce

3. Purpose of the health record • Primary purpose • to benefit the patient through support of current and future healthcare needs • Secondary purpose • to provide a medico-legal record of the care provided and hence support and demonstrate the competence of clinicians • Tertiary purpose • education, research, public health, health service planning & management • NB: must be legitimate (involve consent) and can never be allowed to compromise the primary or secondary purpose

4. EHR systems • An EHR system is the set of components that form the mechanism by which patient records are created, used, stored, and retrieved. • It includes: • people • data • rules and procedures • processing and storage devices • communications and support facilities US National Academy of Sciences, Institute of Medicine,1991

5. Design of EHR systems • EHR systems need to be optimized to suit the primary purpose of the EHR • Traditionally, EHR systems have been optimized to suit the needs of finance and administration ie tertiary purposes

6. What are we trying to achieve? • Interoperability - communication • Safety and security • Comprehensiveness • Portability • Evolution - “future proof”

7. The current situation • Rival medical software programs • Closed systems • Little or no interoperability • Fragmented data

8. Vertical silos Vast fragmentation of healthcare computing systems • All or nothing from one supplier • More than required • Limited range • Results in Fragmented data Supplier A Supplier B data data comms comms platform platform

9. Appl icat ions P l a t f o rm Standard Electronic Health Record Standard communications platform Standard hardware & operating system platform The new model

10. EHR standardisation What aspect of the EHR should be standardised? • Nothing? – the extremist messaging view • The data contained in the EHR? • The EHR system? • The EHR architecture?

11. What is an EHR architecture? • “The [EHR] Architecture is 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.” • “The Architecture does not prescribe or dictate what anyone stores in their healthcare records. Nor does it prescribe or dictate how any electronic healthcare record system is implemented. …[It] places no restrictions on the types of data which can appear in the record, including those which have no counterpart in paper records. … Details like ‘field sizes’, coming from the world of physical databases, are not relevant to the electronic healthcare record Architecture.” Proceedings, 2nd EU-CEN Workshop on the Electronic Healthcare Record, 1997

12. Architecture vs Format Documents Healthcare Records Logical Architecture (Organizing principles) De facto standard . Documents . Chapters . Paragraphs . Sentences . Words GEHR standard . Electronic Health Records . Transactions . Item Complexes . Items . Attributes” Formats (based on the architecture) Proprietary Electronic Formats WORDâFormat (.doc) HEALTH.oneâ Format (.h1b) StandardElectronic Formats XML Health record standard ?(.ghr)

13. Strategies for interoperability Record transfer Design investment Application communication EHR architecture eg GEHR Common interface architecture eg CORBAmed Messaging eg HL7 File communication Implementation cost

14. Requirements for an EHR architecture What are we trying to achieve? • Interoperability - communication • Safety and security • Comprehensiveness • Portability • Evolution - “future proof”

15. United Kingdom Belgium Health Data Management Partners ERIM Federation des Association Medecins Generalistes de Bruxelles Insitut D’Hygiene et d’Epidemiologie St Bartholomew’s Hospital Medical College The Royal Hospitals NHS Trust City & East London FHSA The Royal Marsden Hospital University of Hull Germany SmithKline Beecham Zentralinstitut fur die Kassenarztliche Versorgung France Croix Rouge Francaise Luxembourg C2V Association des Medecins et Medecins Dentistes Kalamazoo S.A. France Telecom Microdata SARL Centre de Recherche Public Henri Tudor Portugal Greece Instituto Clinica Geral Zona Norte Spain University of Athens Clinica Puerta de Hierro The GEHR project

16. Current EHR standards activity • Europe: • CEN TC/251 – prENV13606 1-4 • United States • ASTM, HL7/CDA, CORBAmed, CPRI • New Zealand • Standards NZ SC606 WG3 • Australia • Standards Australia IT/14/9 • National EHR Taskforce • International • ISO/TC 215 WG1

17. Successful standards For any standard to succeed in the ‘marketplace’ must have dual thrust of formal standards development and commercial standards-based product availability. A continuing positive feedback loop between implementation experience and formal standards development is essential for success.

18. The need for health IT standards “In conventional sectors of industry, standards are well known for increasing companies’ market opportunities and for lowering the cost of equipment and services to users. The same arguments hold for the field of healthcare informatics, where European industry currently supplies to a fragmented market, products which have a short life cycle and are over-customised and therefore expensive to develop, to buy, and to maintain. Agreement on common requirements will reduce the cost of healthcare information systems and open up the market.” • Directory of the European Standardisation Requirements for Healthcare Informatics and Telematics: Program for the Development of Standards. European Committee for Standardisation, CEN/TC 251, 1996.

19. Benefits to software vendors • Greater certainty for planning • Lower development costs • Can concentrate on added-value end-user applications rather than middleware • Promotes modular application development • Lower maintenance costs • Longer product cycles

20. GEHR in Australia • IBM GPCS Consultancy report - Aug 1997 • recommends GEHR adoption for Australian General Practice • Ocean GEHR kernel commenced - Feb 1998 • Standards Australia EHR WG formed - Jul 1999 • National EHR Task Force established - Nov 1999 • Federally funded GPCG GEHR project - Feb 2000 • HINA report - Jul 2000 • GEHR favored as architecture for national EHR

21. The “new” GEHR architecture • Good Electronic Health Record • Extended “Oz” GEHR model developed 1998 • Major breakthrough for implementation • Two level model • Concrete model – GEHR object model (GOM) • Meta-model – Archetypes for clinical content

22. Archetypes and Lego designs • GOM is a generic knowledge representation model • The components (objects) of the GOM are like Lego bricks • Archetypes express knowledge in a particular domain • Archetypes are like the designs for Lego structures • Designs constrain use of Lego pieces to meaningful structures • Concrete model can be standardised independent of archetypes

23. Public domain “Oz-GEHR” deliverables • Technical requirements document • Architecture description document • Archetype description document • Implementation guidelines • A generated diagrammatic (UML) expression of the model • Various exchange specifications (XML) • COM API • Provisional set of archetypes (diabetes, patient summary) • The core Ocean kernel with Open Source licence • Located on www.gehr.org

24. The “Ocean” GEHR kernel Application COM CORBA Session manager GEHR model CoreKernel Archetypes Persistence interface Binding Exchange formats Database

25. The GPCG GEHR project • Funded by Australian Federal Government • Ocean GEHR kernel • 3 GP clinical systems adapted to GEHR • Standard application interface: COM • Generic GEHR transaction viewer • Archetypes for diabetes management and patient summary

26. What next? • Further software development • Clinical archetype development • Education and training • Advocacy and promotion • Implementation trials • Multi-discipline and multi-sector

27. Areas for GEHR R&D • Kernel development • Archetype software tools • Archetype development • APIs • Database bindings • Clinical modelling review and development • Standards convergence • Exchange formats and data transformation • XML, HL7, Translation wrappers for legacy systems

28. Future Australian GEHR trials • Hospital non-GEHR to GEHR translation • HL7 to GEHR translation • Series of multi-sector implementation trials • Hospital – GP • GP – medical specialists • GP – community-based allied health • Hospital/GP – home • NGI Quality of Service for GEHR-based apps. • eg remote consultations, home tele-monitoring • Australia (ANP), US (Internet2), ?UK

29. Data Sources Courtesy of DSTC

30. Translating between EHRs Courtesy of DSTC

31. Questions and discussion