September, 2005What IHE Delivers 1 IHE Changing the Way Healthcare Connects in COMMUNITIES HIMSS Interoperability Showcase February 2008 Keith Boone (GE), George Cole (Allscripts), John Donnelly, Lori Fourquet (eHealthsign), Tom Kuhn (ACP), John Moehrke (GE).

2 Requirements for an open RHIO/HIE(1) Bring trust and ease of use for healthcare professionals:  Care delivery organizations choose information to share: Based on patient situation Based on patient situation When they see fit (discharge, end of encounter, etc.) When they see fit (discharge, end of encounter, etc.) What information to share (pick relevant types of documents, and content elements). What information to share (pick relevant types of documents, and content elements).  Care delivery organizations access patient information through: their own EMR (if they have one), or their own EMR (if they have one), or through a shared portal otherwise. through a shared portal otherwise.  When accessing patient info: Find quickly if relevant information is available or not (single query). Find quickly if relevant information is available or not (single query). May select among relevant documents, which ones to see (may be done in background) May select among relevant documents, which ones to see (may be done in background) Among those of interest, chose to import in whole or part in its own EMR Chart (responsibility). Among those of interest, chose to import in whole or part in its own EMR Chart (responsibility).

3 Requirements for an open RHIO/HIE(2) Bring trust and privacy to patients:  Only authorized organizations and authenticated healthcare providers may transact in the HIE: Each node or IT system interfaced is strongly authenticated Each node or IT system interfaced is strongly authenticated Each user shall be authenticated on the edge system (where context is best known) Each user shall be authenticated on the edge system (where context is best known) All traffic trough the infrastructure is encrypted All traffic trough the infrastructure is encrypted  Shared Document Registry does not contain patient clinical data only generic information (minimum metadata + repository reference)  Patient consent needs multiple choices or levels Unless opt-in, no data about a specific patient may be shared Unless opt-in, no data about a specific patient may be shared Several data sharing policies offered to the patient consent Several data sharing policies offered to the patient consent Each shared document is assigned to specific policies (or not shared) at encounter time. Each shared document is assigned to specific policies (or not shared) at encounter time. Healthcare providers may only access documents compatible with their role. Healthcare providers may only access documents compatible with their role.

4 IHE - Connecting standards to care Care providers and IT professionals work with vendors to coordinate the implementation of standards to meet their needs  Care providers identify the key interoperability problems they face  Drive industry to develop and make available standards-based solutions  Implementers follow common guidelines in purchasing and integrating systems that deliver these solutions

5 Categories of Healthcare Communication Services Security Document Sharing Patient and Provider ID Mgt Dynamic Information Access Workflow Management Source persisted and attested health records Specific info snapshot provided on demand 2 or more entities synchronize a task e.g. access to last 6 months historical labs and encounter summaries e.g. order a lab test, track status and receive results e.g. get a current list of allergies or med list from a source Hospitals HIEs and RHIOs

6 Community or sub-network Clinical Encounter Clinical IT System Aggregate Patient Info 4-Patient data presented to Physician Sharing System Clinic Record Specialist Record Hospital Record 2-Reference to Records for Inquiry Introduced at HIMSS in 2005 : IHE-XDS 3-RecordsReturned 1-Reference to records Repository of Documents Index of patients records

7 Health Information Exchanges Interoperability: Cross-enterprise Document Sharing Cross-Enterprise Document Sharing simplifies clinical data management by defining interoperable infrastructure. Transparency = Ease of Evolution Patients have guaranteed portability and providers may share information without concerns of aggregation errors. Digital Documents = Patients and providers empowerment Supports both centralized and decentralized repository architectures. Ease of federation nationally. Flexible privacy, Flexibility of configurations Addresses the need for a longitudinal healthcare data (health records). Complements to interactive workflow or dynamic access to data.

8 Cross-Enterprise Document Sharing (XDS) Standards Used Healthcare Content Standards HL7 CDA header data Internet Standards HTML, HTTP, ISO, IETF … Electronic Business Standards ebXML Registry, SOAP, Web Services … Implemented world-wide by close to 100 vendors/open source. Adopted in several national & regional projects: Italy, Austria, Canada, USA, Japan, South Africa, France, etc.)

9 Why is IHE-XDS a breakthrough ? It based on an International Standards; ebXML registry: OASIS and ISO standard, Web Service/Soap/XML. Sharing of digital documents as “attested by the source”, meets the most urgent needs. A proven healthcare community data-sharing paradigm ( Message feeding a central web server hinders use of EHRs ). Efficient to support all types of Health IT Systems (IDNs, Hospitals, Ambulatory, Pharmacy, Diagnostics Centers, etc.) and all types of information (summaries, meds, images, lab reports, ECGs, etc.), structured and unstructured. Meets both the needs of push communication by info sources and on- demand pull in a variety of centralized or distributed architectures. Offer a consistent, standards-based and functional record sharing for EHRs, PHRs & other IT Systems

10 IHE-XDS Infrastructure Components Audit Record Repository (ATNA) – Receive audit records from other actors and securely store for audit purposes. ATNA also authenticates peer-nodes and encrypt communications. Time Server (CT) – Provides consistent definition of date/time enabling time synchronization across multiple systems. Enables events associated with patients to be sorted reliably in chronological order. Document Registry (XDS) – Queryable index of metadata and references to all documents shared within a connected community (XDS Affinity Domain) Document Repository (XDS) – Supports storage and retrieval of clinical information (as documents). May be centralized or distributed. Patient Identifier Cross Reference Manager (PIX) – Reconciles information on patients from multiple domains to a single, cross referenced set of IDs for each given patient. Patient Demographics Supplier (PDQ) – Returns demographic information and identifiers for patients based on specified demographic criteria.

11 Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System XDS Scenario + use of ATNA & CT PMS Retrieve Document Register Document Query Document XDS Document Registry ATNA Audit record repository CT Time server Record Audit Event MaintainTime MaintainTime Event Maintain Time Provide & Register Docs Record Audit Event XDS Document Repository Secured Messaging

12 Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System XDS Scenario + use of PIX & PDQ A87631 PACS L-716 Affinity Domain Patient Identity Source M Retrieve Document Provide & Register Docs Register (using Pt ID)Query Document (using Pt Id) Patient Identity Feed Document Registry M L-716 A87631 Patient Identity Feed PIX Query PIX Query Patient Identity Feed Patient Identity XRef Mgr Patient Identity Feed PDQ Query to Acquire Affinity Domain Patient ID M A87631 L-716 M XDS Document Repository XDS Document Repository ATNA Audit record repository CT Time server

13 IHE-XDS is part of a family of profiles Regional, national, local or disease centric networks need a consistent set of Integration Profiles Eight Integration Profiles completed and tested, plus ten ready to implement = Standards-based interoperability building blocks for  Rich Document Content for end-to-end application interoperability.  Patient identification management  Security and privacy  Notification and data capture IHE-XDS + related IHE Integration profiles provide a complete interoperability solution

14 IHE Integration Profiles for Health Info Nets What is available and has been added in 2007 Emergency Referrals Format of the Document Content and associated coded vocabulary PHR Extracts/Updates Format of the Document Content and associated coded vocabulary ECG Report Document Format of the Document Content and associated coded vocabulary Lab Results Document Content Format of the Document Content and associated coded vocabulary Scanned Documents Format of the Document Content Imaging Information Format of the Document Content and associated coded vocabulary Medical Summary ( Meds, Allergies, Pbs) Format of the Document Content and associated coded vocabulary Clinical and PHR Content Health Data Exchange Patient Demographics Query Patient Identifier Cross-referencing Map patient identifiers across independent identification domains Notification of Document Availability Notification of a remote provider/ health enterprise Request Form for Data Capture External form with custom import/export scripting Patient ID Mgmt Other Final Text Approved Trial Implementation-2007 – Final Txt 2008 Cross-Enterprise Document Sharing Registration, distribution and access across health enterprises of clinical documents forming a longitudinal record Cross-Enterprise Document Pt-Pt Reliable Interchange Cross-Enterprise Document Media Interchange Cross-Community Access Security & Privacy Consistent Time Coordinate time across networked systems Audit Trail & Node Authentication Centralized privacy audit trail and node to node authentication to create a secured domain. Basic Patients Privacy Consents Establish Consents & Enable Access Control Document Digital Signature Attesting “true-copy and origin Cross-Enterprise User Attestation User Attributes fro Access Control

15 Combining IHE Profiles Document Content & Modes of Document Exchange Document Exchange Integration Profiles Document Sharing XDS Sharing XDS Media Interchange XDM Reliable Pt-Pt Interchange XDR Doc Content Profiles (Semantics content) Scanned Doc XDS-SD LaboratoryXD*-Lab PHR Exchange XPHR Discharge & Referrals XDS-MS ImagingXDS-I ConsentBPPCEmergencyEDR Pre- Surgery PPHP Functional Status Assesment FSA

16 XDS-MS and XPHR enable both semantic interoperability & simple viewing ! S S t t r r u u c c t t u u r r e e d d C C o o n n t t e e n n t t w w i i t t h h c c o o d d e e d d s s e e c c t t i i o o n n s s : :  Reason for Referral     Vital Signs     M M e e d d i i c c a a t t i i o o n n  Studies     A A l l l l e e r r g g i i e e s s  Social History     P P r r o o b b l l e e m m s s  Care Plan XDS-MS Medical Summary or PHR Extract Exchange Profile based on HL7 CDA Rel 2 and ASTM/HL7 CCD Structured and Coded Header Patient, Author, Authenticator, Institution, Time of Service, etc. Header always structured and coded Title-coded sections with non-structured nor coded content (text, lists, tables).  Simple Viewing (XML Style sheet) Level 1 Level 2 Text Structure Entry Text Structure Entry Med, Problems and Allergies as highly structured text.  Text easy to import/parse Text Structure Entry Level 3 CCHIT 08 Med Problems and Allergies have a fine-grain structure with optional coding. Coding Scheme explicitly identified. Coded Section Entry Coded Section Entry Coded Section Entry Level 3 CCHIT 09

17 Use of a shared XDS infrastructure to access Radiology Reports and Images (XDS-I) Hospital Imaging Center Physician Practice Between Radiology and : Between Radiology and : I maging specialistsI maging specialists Non-imaging cliniciansNon-imaging clinicians PACS Y PACS Z Radiology -to- Radiology Radiology -to- Physicians Same XDS Infrastructure (Registry and Repositories) for medical summaries and imaging information !

18 Community Network A Document Registry Practice Clinic Hospitals Hospital Diag Test Other Practice Hospital Community Network C Document Registry Practice Clinic Hospitals HIMSS NHIN: Network of networks The largest multi-vendor HIE Prototype ever built ! 3 infrastructure 7 local systems 3 infrastructure systems Community Network B Document Registry Practice Clinic Hospitals Diag Test Community Network D Document Registry Practice Clinic Hospitals 6 infrastructure 9 local systems 3 infrastructure 9 local systems 2 infrastructure 4 local systems

19 IHE, global standards-based profiles adopted by several national & regional projects Quebec, Toronto, Alberta, British Columbia Canada Infoway Denmark (Funen) Italy (Veneto) Spain (Aragon) THINC- New York NCHICA – N. Carolina Italy (Conto Corrente Salute) Boston Medical Center - MA France DMP UK CfH (Radiology WF) Philadelphia HIE CHINA-MoH Lab results sharing CPHIC – Pennsylvania CHINA-Shanghai Imaging Info Sharing JAPAN-Nagaya Imaging Info Sharing South Africa Malaysia VITL-Vermont CareSpark – TN & VA Netherland Amsterdam Lower Austria

20 Leverage IHE for your RHIO/HIE ! EMR from most vendors have/plan support “two way” IHE interface. Choice of Infrastructure Vendors. ( EHR Vendor Association Interoperability Roadmap) Thin and efficient Infrastructure for Health Info Exchange  Solid content-independent “Thin” Infrastructure Profiles: XDS, PIX, PDQ, ATNA, CT, BPPC  Broad Choice of Content Profiles: XDS-MS & XPHR(Chart), XDS- SD(Scan doc), XDS-I(Imaging), XD*-Lab, ECG, etc. Leverage investments and experience world-wide  Choose either (or mix) a federated or a centralized HIE  Get both an HIE with portal data access and two way data exchange  Public domain architecture and specifications, simplify RFP process and implementation for both vendors and HIE.

21 IHE–Based – Health Info Exchange IHE supports these requirements:  To meet the needs of the various stakeholders  With a wide array of standards to reduce cost and accelerate deployment of HIEs  With flexibility to accommodate a wide range of architectures and business models across the world  No rip and replace of edge systems, different levels of interoperability  Ensure reuse of implementations, sharing of experience  Forward looking way to enable interconnection of HIEs into a National Health Information Network  Allowing increasingly sophisticated security and privacy protections Several Exchanges being built in 2008 across the USA

2222 IHE Profiles are consistent with HHS Accepted Standards (HITSP Interoperability Specifications)

HIMSS Interoperability Showcase

24 As a Provider or Vendor Contributor Offer Clinical Use Case Input to Drive IHE Profile Development Become a member of relevant domain’s Planning or Technical Committees Become a member of relevant Regional/National Committees Help to shape IHE’s future direction As a Vendor Participant Respond to Public Comments of Domain Supplements Attend the June Educational Workshop Participate in Connect-a-thons and Demonstrations As a Provider/Consultant Participant Respond to Public Comments of Domain Supplements Attend the June Educational Workshop Attend Demonstrations and include IHE Integration Profiles in your RFPs and Integration Projects. How can I participate?

25 What can you do? Attend the IHE Domain specific sessions in these Theaters during HIMSS 2007 (Orange sessions) Learn about IHE, Insist on relevant IHE profiles compliance in your RFPs and contract documents:  Select Integration Profiles, and Appropriate Actor(s)  Ask vendors for their products “IHE Integration Statements”. Need more interoperability ?  Contribute to IHE Committees

26 IHE Web site: Frequently Asked Questions Integration Profiles in Technical Frameworks: See Volume 1 of each TF for Use cases  Cardiology  Eye Care  IT Infrastructure  Laboratory  Patient Care Coordination  Patient Care Devices  Pathology  Quality  Radiation Oncology  Radiology Connectathon Result: Vendor Products Integration Statements

September, 2005What IHE Delivers 27