300 likes | 317 Views
Learn about InterSystems Software for Connected Healthcare and its solutions for developing secure electronic health record systems on a regional and national level.
E N D
HL7 Roadshow 2009Connected Healthcare Jon Payne, March 2009
InterSystems Software for Connected Healthcare HealthShare – for developing secure electronic health record systems on a regional and national level Regional / National EHR TrakCare – an advanced Web-based healthcare information system that rapidly delivers patient-centric data and Electronic Patient Record benefits Institutional / Community EPR Ensemble - #1 interface engine in healthcare (KLAS 2006, 2007, 2008) Application Level Caché - #1 database used in clinical applications worldwide
InterSystems Caché High-performancelinks to all major ODBC JDBC Industry-standard relational access SOAP Java XML COM EJB .Net C++ Perl Web 2.0 CachéObjects CachéSQL Single Definition Multi-DimensionalStorage Manager
Kaiser Permanente and EPIC Systems • World’s largest civilian EHR • 8.7 Million patients supported in Outpatients setting • 2 Million active Personal Health Record users • 10 hospitals live with Inpatients • >11,000 Physicians
The NICTIZ Project • « NICTIZ » is an organization of the Dutch government, in charge of ICT-enabling the healthcare sector at a national level(« AORTA » program) • See www.nictiz.nl (mostly in Dutch, some English) • In 2005, NICTIZ publishes a tender for building a national infrastructure for medial information exchange: the « LSP » (« Landelijk SchakelPunt » or « National switchboard ») • CSC and InterSystems bid together and are selected by the end of 2005
General Principles of the Project • The general goal is patient data interchange • Complete data, except (for now) imaging, and limited only by privacy laws • Includes medical and administrative data • Patient data are not stored at a central location! • The central system records the localization of the information, not the information itself • It is hence a « meta-index », not a « repository » • Users of the system: GPs, hospitals, clinics, pharmacists nationwide
Technological Orientations (Prerequisites) • All exchanges are based on HL7 version 3 • « New » version of the HL7 standard, based on XML • Standard HL7v3 is not finalized: « Dutch variant » • Communications use SOAP technology on a HTTP/S communications channel • Should become one of the largest SOA infrastructures in the country! • Security is based on SSL/TLS and X509 certificates (established industrial standards) • The LSP was developed 100% on Ensemble
Mechanisms of LSP DCN DCN DCN GBZ (Goed Beheerd ZorgSysteem): only certified clients are allowed to communicate directly with the ZIM GBZ DCN (Data Communication Network): all communications transit through certified networks GBZ In general, a “GBZ” provides services for several institutions and/or GPs LSP The central “hub” of the LSP is named the « ZIM » (Zorg Informatie Makelaar) The communications infrastructure between the final client and the GBZ can be anything GBZ Communication with the LSP uses HL7v3 and SOAP on HTTP/S exclusively GBZ A hospital , a clinic, even a GP can be their own « GBZ »
Mechanisms of LSP GBZ 2. The lab report is transmitted to the LSP; among other things, it indicates an allergy to penicillin GBZ LSP 3. The ZIM records that a lab report exists for Mrs Brantjes at Reinaert clinic in Maastricht – but it doesn’t record the lab report itself! GBZ 1. Mrs Brantjes visits Reinaert clinic in Maastricht for some medical exams GBZ
Mechanisms of LSP 1. Mrs Brantjes, while visiting Amsterdam, sees a GP for a rash on the leg that worries her GBZ 6. The ZIM aggregates and sends the file back to the requester.The GP notices the allergy to penicillin and adapts the treatment accordingly GBZ 2. As the GP doesn’t know Mrs Brantjes, he asks the LSP for her medical file LSP 3. The ZIM checks its index for a list of GBZ that can provide information relevant to the request 5. Naturally, other GBZ can be involved in answering the request GBZ 4. The ZIM gets the lab results from Reinaert clinic as well as all relevant information from sources connected to the same GBZ as Reinaert clinic GBZ
Volumes and phasing • Volumes expected at full deployment: • 20 000 direct clients for >16 million patients • 4,312 billion XML messages (30KB each) yearly, that is: • ~20TB message volume, 4 TB logs • 200 msgs/second average, 671 msgs/second in peak • Requirement maximum response time: 5 seconds • Currently: • 40 msgs/second average, 130 msgs/second in peak • 1000 concurrent sessions • Response times under 3 seconds • Availability 99.982%
Volumes and phasing • 3 planned phases: • Phase 1: 5% of final volume, 5Ko average message size, no redundancy • Phase 2: the same, with 20% of the final volume • Phase 3: complete deployment with very high availability and 30 KB average HL7v3 messages • The system was recently upgraded to phase « 2++ » level: • Phase 2 • + very high availability • + 30KB average HL7v3 messages
Brazil – Federal region of Brazilia NIC NIG NIP CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS USP USP USP USP USP PSR PSR PSR PSR NIBz NIS CS CS CS PSU PSU PSU PSU PSU PSU PSU PSU PSU PSU PSU PSU CS CS CS SARAH CS CS CS CS CS CS PSR PSR PSR PSR PSR PSR PSR PSR PSR PSR PSR PSR CBMDF PSR PSR NILN CS CS CS CS CS CS LRC LRC HFA CRT CRT CS CS CS NICr HUB CS CS CS CS CS CS PSU PSU PSU PSU PSR PSR PSR PSR PSR PSR Hemocentro LRGu CS CS CS LRGu LACEN NILS CS CS CS CS CS CS CS CS CS CS CS CS CS CS CS PSR PSR CS CS CS NIPr CS CS PSR CS PSR CS CS CS DISAT ISM CS CS CS NIBsB NICd CS CS CS U M U M PSR CS CS 1 1 2 2 1 3 3 1 3 1 1 2 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 1 1 1 4 CS 1 1 U M 2 2 1 10 2 2 NITS NISM NIRF NIGu NITN NISa PSU PSU Hosp. Apoio NINB COMPP HSVP PSR PSR PSR PSR PSR PSR PSR PSR PSR PSR PSR PSR CS PSR CS CS PSR PSR Regional Hospital • Regional Project: • 17 Hospitals • 134 Health Clinics • 3 Diagnostic Laboratories • 20 Emergency Units • 3 Specialist Diagnostic Units • Home Care • More than 5000 health professionals using just one Electronic Health Record PSR Regional Hospital Regional Hospital HRC FEPECS Regional Hospital CS CS CS Central Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital Regional Hospital
USA – Rhode Island • Having a useful, usable and used interconnected health information system that: • Puts the right information into the hands of clinicians and their patients when and where it is needed • Allows for population health information to be analyzed and used for surveillance, health policy, and research • Using InterSystemsHealthShare for state-wide master patient index and clinical data exchange • Connecting 14 healthcare organizations across the state (85%+ of all lab and medication data) • A total of 1.1Million Residents 3,000 GP’s • Governor has an “Anytime, Anywhere Healthcare” agenda
USA – LIPIX • Long Island Patient Information Exchange • 5.2Million Residents 8,000 GP’s (Assoc with NS-LIJ Health System) • Using InterSystems HealthShare for master patient index and clinical data exchange. • Connecting 15 healthcare organizations on New York’s Long Island • Initial LIPIX Deployment • 4 Hospitals • 2 Physician Practices • Home Care Agency • Municipal Health Center • EMS Organization • Reference Laboratory • Long Term Care Facility • Public Health Department
Sweden National Patient Overview • Population 9 million • 21 healthcare regions • National EHR • Carelink is Government appointed group to manage the project. • InterSystems in partnership with TietoEnator.
Sweden National Patient Overview (NPÖ) Users Users County Integration Users Existing Care Systems County Integration NPO Users County Integration EN13606 SOAP/SSL Users National Security and Integration Framework
Central, Federated, Virtual? Access GP 1 Viewer RAD Identity Point of Care LAB Consent GP 2 Hospital PAS GP 3 OPR Clinic A & E Repository I C U Clinical Repository
End-to-End Performance, Scalability and Flexibility • Database • Data source systems / EPRs • Intermediate Data cache • EHR repositories • Applications • Authentication, Identification & Consent • Aggregation, Access & Presentation • Read-only “view” evolving to “transactional” application • Messaging & Integration • HL7 / XML • Security / Encryption HTTPS, SSL • Data capture / Adapters • Orchestration / Workflow • Transformation / Translation / Rules • Audit & Governance / Message Persistence • Resilience / Availability / Recovery
Patient Identity Management • Identity Policy and Service most commonly centralised • Use of (existing) national numbers (Social Security Number / NHS number) • Identity Hub as clinical record locator • Scale – large numbers of patients, records, indexes, pointers to clinical data, network transactions, queries. • Interaction with User Access and Consent services • End-to-end performance and scalability • Response times • Availability / Manageability
User Provisioning & Consent • User Access and Consent policy and service is typically centralised • Access/Consent policy not typically defined / controlled by those who need to use the systems • Clinicians may perform different roles at different times in different facilities. • Time-based nature of “legitimate user relationship” & “consent” • Integration of Smartcards and biometrics • Requirement for tamper-proof audit and governance databases / message archives • Policy may drive an unusable architecture
Data Aggregation / Normalisation • Variable quality of data source systems • Data Capture – push/pull • Structured & Unstructured data • Coded / Non-Coded data – differing coding regimes & purposes • Numerous (converging) Standards for Normalisation • CCR, CDA, CCD • Consume, Expose, Exchange, Act? • Underlying technology • Capture, Parse, Persist, Manipulate, Transport, Query • Scalability, Performance • Reliability, Manageability, Recoverability
IHE and HealthShare • Cross Community Information Exchange • A variety of IHE profiles certified at Connectathons • XCA Initiating Gateway • XCA Responding Gateway • XDSa Repository • PIXv3 Consumer • PIXv3 Manager (Vienna) • PDQv3 Consumer • PDQv3 Supplier (Vienna) • ATNA Secure application • ATNA Repository
The Trust Integration Engine CSC selects InterSystems for trust integration 10 Sep 2008 Computer Sciences Corporation is to use InterSystems Ensemble for the integration of all new applications it provides to existing trust systems. CSC, the local service provider for the North East and Midlands regionsin England’s NHS National Programme for IT, has selected Ensemble as the standard trust integration engine (TIE).
CSC Data Message Architecture TIE TIE TIE TIE TIE TIE TIE Spine Messages Data Message Hub Central Trust DB
CSC Data Message Architecture Ensemble Ensemble Ensemble Ensemble Ensemble Ensemble Ensemble TIE TIE TIE TIE TIE TIE TIE Spine Messages Data Message Hub Central Trust DB Ensemble
Ensemble TIE Ensemble now available from CSC as the standard Trust Integration Engine (TIE) • Centrally-defined, standard solution for existing systems integration. • Available to all NHS Trusts scheduled to deploy CSC NPfIT solutions • Ensemble TIE Licence and annual maintenance is free to Trusts • Enables connectivity between Trust-side applications and the CSC NPfIT solutions • Library of standard departmental systems interfaces • Trusts can upgrade to a full Ensemble licence • Trust Integration Forum (TIF) comprises Trusts, CfH, CSC and ISC
Plymouth Hospitals NHS Trust Ensemble
Questions? Questions?? • Jon.Payne@InterSystems.com • www.intersystems.co.uk/TIE