Interoperability Reference Architecture: Making it easier to share information…

1. Interoperability Reference Architecture:Making it easier to share information… Presentation to GPNZ and RNZCGP, August 2011 Dr David Hay (HL7 NZ)

2. About Me • 1981 Graduated Auckland Medical School • 1984-87 GP in Palmerston North • 1987-01 Developed GP PMS – GPDat • 2001-04 Solutions Architect at EDS • 2004-11 Enterprise Architect at healthAlliance • Currently: • Co-author National Interoperability Reference Architecture (draft) • Chair HL7 New Zealand • Product Strategist Orion Health

3. What’s the Objective • Highest possible quality of care to patients • Actually to people – not just patients! • Involve patients in their own care • Empower/Inform them • Give them choices • Moving towards a ‘patient centered’ approach • Clinically Driven • Cost effective • Population health • Research

4. What’s it look like now? After Hours GP 3 5 PHR GP 2 1 GP Hospital 7 6 Hospital 4 It’s all very complicated! (and just a bit messy) We’ll come back to this…

5. What’s the problem? • Information is all over the place • Kept at place of collection, plus copied • Each system is an Island • Relies on messaging to share information • Interoperability is hard! • Quality: Data not consistently represented or coded • Auckland labtests example • GP2GP development • No single ‘source of truth’ • What medications has a patient been taking • Patient can’t access all information • Or know who has accessed their record • Each system user responsible for system management • Backup, update, audit, disaster recovery (DR) Fundamentally, the systems are not designed to share Designed and built when sharing was the exception We need a common architecture, and common standards

6. Il; Reference Interoperability Architecture

7. Timelines • 2010 National Health IT Plan • Dec 1010 Sector Architects Group (SAG) formed Interoperability TWG, with core team of Dr David Hay, Alastair Kenworthy, Alan Le Maitre and Dr Koray Atalag to develop draft RA. • Feb 2011 work started • May 2011 1st draft out for peer consultation at http://www.hive.org.nz/ • Significant international feedback • Most comments were on modelling techniques and reference information models • Most criticism was of alphabet soup • Peer reviewed draft due July 2011 • Summarised as 3 ‘building blocks’ • Formal proposal to HISO August/September 2011

8. Scope of Reference Architecture • Vision: from the Health IT Plan, a patient focused, integrated healthcare model, enabling shared care between all providers involved in the patient’s care • Scope: Create a future state interoperability architecture to facilitate inter-system and inter-facility exchange of health information to support the Health IT Plan • This approach will enable the working interoperability to support the eHealth vision • To achieve high quality healthcare and improve patient safety, by 2014 New Zealanders will have a core set of personal health information available electronically to them and their treatment providers regardless of the setting as they access health services

9. National IT Plan

10. Shared Care Record Regional CDRs are a key part of working interoperability Working interoperability is an enabler for shared care records as described by the IT Plan

11. Functionalinteroperability Semanticinteroperability Interoperability • “Ability of two or more systems or components to exchange information and to use the information that has been exchanged” • [IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Functional Interoperability - message structure - eg HL7 v2, CDA Semantic Interoperability - meaning - eg SNOMED, LOINC

12. RA Principles • Align to national strategy • Be business needs focussed • Work with sector • Use proven standards • Invest in information • Adopt services approach • Develop single content model for exchange

13. 3 core blocks • Common exchange model • We speak the same language • Common payload for exchange • How the information is packaged • Utility Services • The supporting infrastructure

14. y Common Content Model “Speaking the same language”

15. Content Model – (i)

16. Content Model (ii)

17. Content Model - Archetypes METEoR for concepts Archetypes for structure

18. Standards

19. Adapting Standards

20. Between facilities Facility 2 Facility 1 App1 App1 Shared Reference Model App5 App2 Local Reference Model Local Reference Model App3 App4 The common model is for exchange between facilities not inside facilities

21. 2. Common payload “How the information is packaged”

22. Payload Standards • The standard payload will be an HL7 v3 CDA (Clinical Document Architecture) R2 document • Emerging standards: • CDA R3 • HL7 v3 messaging • Contained standards • HL7 v2.x – use in specified domains and settings (e.g. lab, intra-facility) • DICOM • No business advantage to change • New projects will use CDA

23. Where is CDA being used? http://www.google.com/maps/ms?ie=UTF8&oe=UTF8&source=embed&msa=0&msid=110535847732151766411.00047b0b46314e91435c9

24. What is CDA? • A document that a human can read • Wholeness, Context and other document attributes • Computer can understand • Contains clinical content • ‘Incremental Interoperability’ • XML • “Architecture” – a way to control it’s contents

25. Structured Documents Document • HL7 Clinical Document Architecture (CDA) • Context, wholeness, persistence • Incremental interoperability Header Author Demographics … Body Section Clinical Information Section Clinical Information Section Clinical Information Entry Entry

26. CDA R-MIM

27. Coded Drug <entry> <substanceAdministration classCode="SBADM" moodCode="EVN"> <id root="2.16.840.1.113883.2.18.10" extension="1613.9149803"/> <text>Take ONE tablet on alternate days as directed</text> <!-- Instructions --> <!-- Period over which the medication is valid - 1/1/2010 until 1/4/2010--> <effectiveTime xsi:type="IVL_TS"> <low value="20100101"/> <high value="20100401"/> </effectiveTime> <consumable> <manufacturedProduct> <manufacturedMaterial> <code codeSystem="2.16.840.1.113883.2.18.4" codeSystemName="NZ Pharmac" code="250295" displayName="ELTROXIN 100mcg Tablets"> <originalText>Thyroxine sodium</originalText> </code> <name>ELTROXIN</name> </manufacturedMaterial> </manufacturedProduct> </consumable> </substanceAdministration> </entry>

28. CDA Template Library • Each document type has a collection of sections that must/may be present • Eg eReferrals, EDS, ePrescribing • Envisage a national ‘library’ of recognised document types (eReferral, eDischarge, ePrescription) and sections/entries (allergies, medications, problems) • Re-use not re-invent • Embrace/extend international profiles where possible • Effective governance essential! • Must be seen as facilitating projects, not hindering them

29. Utility 3.Utility Services “The underlying and supporting infrastructure”

30. Health Information Exchange

31. Integrating Healthcare Enterprise (IHE) • A common framework for harmonizing and implementing multiple standards • Defines ‘profiles’ of real-world use, the actors and transactions involved and the standards required • Enables seamless health information movement within and between enterprises, regions, nations • Promotes unbiased selection and coordinated use of established healthcare and IT standards to address specific clinical needs For more information: www.ihe.net

32. Finding information - XDS XDS: Cross Enterprise Document Sharing

33. Finding information - Lab Registry Lab

34. Finding information - EDS Registry Hospital EDS

35. Finding information - Rad Registry Rslt Img

36. Finding information - simplified Registry

37. Current Projects • National Identity System • Re-platforming the NHI, HPI • GP2GP • Moving a patients records between PMS systems • ePrescribing • Electronic transmission of prescription • EDS • Electronic Discharge Summary – Transfer of care

38. GP2GP Toolkit • GP2GP toolkit enables PMS to read and write CDA documents CDA • Value in toolkit means being used in the other projects • Re-use! ToolKit (.net dll) Sender Recipient

39. Util;ity Back to our scenario…

40. In the (regional) cloud Common Payload GP After Hours Patient Access PHR Common Model Utility Services Hospital Pharmacy

41. A bit more detail GP Hospital GP PHR Patient After Hours Health Information Exchange (services + orchestration) Private National Other Services Regional Admin Lab Meds Identity Decision Support Pathways Notes Rad Notes imms Workflow All the shared information is in the same place!

42. What’s the Difference? • Core information sits in shared repositories behind standardized services. • Data: • Medications, Allergies, Laboratory, Radiology, • Reduced duplication, enhanced sharing • Other services • Immunisation • All systems (including GP PMS) access as required • only data locally is cache • Systems management is performed by the hosting service • Not the GP! • Reduced risk • Allow sophisticated Privacy, Audit & Security • This is how other sectors with distributed requirements are built (banking, intelligence, airline) • Need to think of health information as a single sector with multiple independant participants, rather than aggregation of separate systems • We’re special – but not THAT special!

43. What’s the advantage • Improved Clinical Safety • Patient information is available from anywhere (including mobile), to any authorised person • Reduce duplication • Enable different business models • Software as a Service (SAAS) • Fully mobile solution • Allow vendors to innovate on UX and extras rather than core functionality • Patient participation enabled • Cost savings – individual and sector • Consolidation of systems and services • Possible new services e.g. centralized schedules & billing • Reduce duplication of tests • The GP practice does less • Process and Risk of IT management moved to specialized companies - not GP

44. Plus Business and Care continuity… Christchurch, 2011

45. That’s my business you’re talking about! • No, it’s only the clinical information supporting your business and supporting services (like test ordering, referrals, decision support) • Which is about the patient • It’s empowering your real business: • Delivering healthcare, and your relationship with the patient • Business related information (like financials and transaction summaries) is not included • Though similar architectures might be useful • Security and privacy concerns (for everyone) will need to be thought through carefully – and gradually!

46. Information stewardship • ‘looking after’ the information, not ‘owning’ it • This should be the sector focus – not the deployment considerations • Things to think about: • Access requirements • Within system, fully mobile, web based portal • Regional / National access • What goes where? • Access Control (including patient) • Access based on relationship to patient • The patient, the GP, ‘treating’ clinician etc • Break Glass • Auditing rules and notifications

47. In Conclusion • The Reference Architecture provides a high level strategy for improving healthCare interoperability in New Zealand. • Individual projects create Solutions Architectures guided by and conformant with the RA. • It is built on National and International best practice and experience • Its intent is to support the national IT Strategy and its goal of improving healthCare delivery • Please read and comment on the Building Blocks!

48. t Thank you! Any questions?