Transcript Slide 1
HealthBase enterprise architecture Interoperability Reference Architecture: Making it easier to share information… Presentation to GPNZ and RNZCGP, August 2011 Dr David Hay (HL7 NZ) HealthBase enterprise architecture • • • • • • – 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 HealthBase enterprise architecture 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 HealthBase enterprise architecture 3 4 What’s it look like now? After Hours Hospital GP 5 1 GP PHR 2 6 GP Hospital 7 It’s all very complicated! (and just a bit messy) We’ll come back to this… HealthBase enterprise architecture • • • 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 HealthBase enterprise architecture Il; Reference Interoperability Architecture HealthBase enterprise architecture 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 HealthBase enterprise architecture 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 HealthBase enterprise architecture National IT Plan HealthBase enterprise architecture 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 HealthBase enterprise architecture • 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 Semantic interoperability Functional Interoperability - message structure - eg HL7 v2, CDA Semantic Interoperability - meaning - eg SNOMED, LOINC HealthBase enterprise architecture 1. 2. 3. 4. 5. 6. 7. 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 HealthBase enterprise architecture 1. Common exchange model – We speak the same language 2. Common payload for exchange – How the information is packaged 3. Utility Services – The supporting infrastructure 3 core blocks HealthBase enterprise architecture y 1. Common Content Model “Speaking the same language” HealthBase enterprise architecture Content Model – (i) HealthBase enterprise architecture Content Model (ii) CORE Model Extensions: ??? (Based on ASTM Continuity of Care (CCR)) Extended Model (e.g. Maternity) (Based on Core Model) Core Information text Core Static Model Extended Static Model Core Detailed Clinical Model (DCM) Extended Detailed Clinical Model Core Meta-Data Extended Meta-Data (DCM) Extension: Maternity Care Extension: Palliative Care Extension: Cancer Registry HealthBase enterprise architecture Content Model - Archetypes METEoR for concepts Archetypes for structure HealthBase enterprise architecture Standards HealthBase enterprise architecture Adapting Standards HealthBase enterprise architecture Between facilities Facility 2 Facility 1 App1 App5 App1 App2 Local Reference Model App4 Shared Reference Model Local Reference Model App3 The common model is for exchange between facilities not inside facilities 20 HealthBase enterprise architecture 2. Common payload “How the information is packaged” HealthBase enterprise architecture 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 HealthBase enterprise architecture Where is CDA being used? http://www.google.com/maps/ms?ie=UTF8&oe=UTF8&source=embed&msa=0&msid=110535847732151766411.00047b0b46314e91435c9 HealthBase enterprise architecture 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 HealthBase enterprise architecture Structured Documents Document Header Author Demographics … Body • HL7 Clinical Document Architecture (CDA) • Context, wholeness, persistence Section Clinical Information Section Clinical Information Section Clinical Information Entry Entry • Incremental interoperability HealthBase enterprise architecture CDA R-MIM HealthBase enterprise architecture 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> HealthBase enterprise architecture 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 HealthBase enterprise architecture Utility 3.Utility Services “The underlying and supporting infrastructure” HealthBase enterprise architecture National Utility Services Health Information Exchange Regional Utility Services Identity (NHI) Registry Laboratory IS Logs Repository HIE Adapter PIX Health Information Exchange (HIE) Regional Services PDQ Registry Repository Audit Utility Service Layer Identity Resolution (example) Entity Service Layer Document Sharing (example) Get Patient LHR (example) Task Service Layer HIE Adapter Integrated Family Health System HIE Adapter Pharmacy Dispensing System Maternity Shared Care System HIE Adapter Provider Services and Personal Services GP PMS Hospital PAS Immunization Register Integrating Healthcare Enterprise (IHE) HealthBase enterprise architecture • 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 31 HealthBase enterprise architecture Finding information - XDS XDS: Cross Enterprise Document Sharing HealthBase enterprise architecture Finding information - Lab Registry Lab HealthBase enterprise architecture Finding information - EDS Registry Hospital EDS HealthBase enterprise architecture Finding information - Rad Registry Rslt Img HealthBase enterprise architecture Finding information - simplified Registry HealthBase enterprise architecture 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 HealthBase enterprise architecture 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 HealthBase enterprise architecture Util;ity Back to our scenario… HealthBase enterprise architecture In the (regional) cloud GP After Hours Common Model Hospital Common Payload Patient Access PHR Utility Services Pharmacy HealthBase enterprise architecture A bit more detail After Hours GP Hospital GP PHR Patient Health Information Exchange (services + orchestration) Private Regional National Admin Lab Meds Identity Notes Rad Notes imms Other Services Decision Support Pathways Workflow All the shared information is in the same place! HealthBase enterprise architecture • 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! HealthBase enterprise architecture 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 HealthBase enterprise architecture Plus Business and Care continuity… Christchurch, 2011 HealthBase enterprise architecture 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! HealthBase enterprise architecture 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 HealthBase enterprise architecture 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! HealthBase enterprise architecture t Thank you! Any questions?