1. September, 2005What IHE Delivers 1 Displayable Reports (DRPT) ACCA IHE Workshop 2007 Harry Solomon, GE Healthcare IHE-Cardiology Technical & Planning Committees

2. 2 Typical Cardiology Reports

3. 3 Typical Report Supported by EMR History: 35 yo white female with a history of inappropriate sinus tachycardia presents for sinus node modification. Mrs. Edmonds has had a history of a rapid heart rate for the past three to four years which is usally initiated by activity/exercise. These episodes of rapid heart rate have occassionally been associated with presyncope/dizzy spells. The patient has not suffered any injuries from these episodes. She has previously been evaluated by Dr. Schutzman with the Care Group - who has attempted control of her heart rate with multiple medical regiments including beta-blockers and calcium channel blockers. The patient could not tolerate either of the classes of medications. The patient had a normal ECHO and an unremarkable Holter Monitor. She subsequently had a an Event Monitor which showed several episodes of sinus tachycardia up to rate of 150 bpm. She then underwent a Tilt Table Test on October 3, 2006 to differentiate between inappropriate sinus tachycardia and postural tachycardia syndrome. Her Tilt was postive for NCS without any evidence of POTS. Past medical history significant for gallbladder and thyroid surgery - not on synthroid currently. Informed consent detailing risks and benefits of the procedure was obtained from the patient and witnessed on the day of the procedure. Physical: Normal cardiovascular exam, without evidence of congestive heart failure. Normal jugular venous pressure and carotids, regular rhythm with no murmur, no gallop. Normal symmetrical pulses, no edema. Lab Data: No significant abnormalities. Procedure: After prepping and draping and effecting local anesthesia with lidocaine, catheters were inserted as follows: A 5F quadripolar catheter was advanced from the left femoral vein (TriPort) to the high right atrium. A 6F deflectable quadripolar catheter was advance from the left femoral vein (TriPort) to the A-V junction (His bundle). A 5F quadripolar catheter was advanced from the left femoral vein (TriPort) to the right ventricular apex. A 7F deflectable decapolar catheter was placed from the right femoral vein to the coronary sinus. A 7F EPT ablation catheter was advanced from the right femoral vein for mapping and ablation. A 4F sheath was placed into the left femoral artery for blood pressure monitoring. Twelve surface ECG leads and intracardiac electrograms from the above locations were recorded during the study. Medications administered: propofol, total 1341 mg IV fentanyl, total 100 mcg IV promethazine, total 25 mg IV isoproterenol, up to 2.5 mcg/min infusion At the end of the study, the catheters were removed and hemostasis achieved using direct pressure. Results: The spontaneous rhythm was sinus with ventricular cycle length 968 ms. The P wave duration was 79 ms (nl <100), with no atrial abnormality; the PR interval was 151 ms (nl 120-200); the QRS duration was 71 ms (nl, 80-120), showing no conduction disturbance with an axis of 45° and QT interval 368 ms (nl, 390-440); the corrected QT [Bazett’s formula] was 374 ms. There was no evidence of a previous MI or delta waves.

4. 4 How do we cross the chasm between the graphically rich cardiology reports and the limited capabilities of EMR systems? How do we bring electronic reports to environments that do not yet support them at all?

5. 5 DRPT Premises PDF is a prevalent output format for reporting applications Design must support independent reporting apps We can control (more or less) what happens in the department Provide a variety of mechanisms for integration to systems outside the department (since we can’t control them)

6. 6 Displayable Reports Profile Transaction Diagram Encapsulated Report Report Repository Report Manager Enterprise Report Repository Encapsulated Report Query Encapsulated Report Retrieve Report Reader Report Creator Encapsulated Report Storage Commitment Retrieve Document for Display Information Source Report Reference Web Display Patient Demographics Source Patient Identity Feed Patient Demographics Consumer Dept Scheduler / Order Filler Encapsulated Report or Report Completion Notify

7. 7 Displayable Reports Profile Actors Report Creator – A system that generates and transmits clinical reports (the reporting app). Report Manager – A system that manages the status of reporting, and distributes reports to report repositories (the department info system). Report Repository – A departmental system that receives reports and stores them for long-term access (may leverage the PACS. Enterprise Report Repository – A system that receives reports and/or references (pointers) to reports, and stores them for access throughout the healthcare enterprise (the EMR). Report Reader – A system that can query/retrieve and view reports encoded as DICOM objects (an imaging workstation).

8. 8 Displayable Reports Profile Standards Used Encapsulated Report Report Repository Report Manager Enterprise Report Repository Encapsulated Report Query Encapsulated Report Retrieve Report Reader Report Creator Encapsulated Report Storage Commitment Retrieve Document for Display Information Source Report Reference Web Display Patient Demographics Source Patient Identity Feed Patient Demographics Consumer Dept Scheduler / Order Filler Encapsulated Report or Report Completion Notif MSH|^~\$|… PID|1|0123456 ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED|11528-7^LN… MSH|^~\$|… PID|1|0123456 ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED|11528-7^LN… HL7 MSH|^~\$|… PID|1|0123456 ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|ED|11528-7^LN… MSH|^~\$|… PID|1|0123456 ‑ 1||R… OBR|1|X89 ‑ 1501^… OBX|1|RP|11528-7^LN… http://serv.hosp.org/app?req uestType=DOCUMENT&d ocumentUID=”1.2.3”&pref erredContentType=”applicat ion/pdf” HL7 (0008,0005) IR_100 (0008,0012) 20061113 (0008,0013) 1109 (0008,0016) 1.2.8401008.… DICOM HTTP

9. 9 Profile Status Demonstrated in 2006 Currently being reworked to use most recent HL7 message definitions Re-release for trial implementation in June 2007

10. 10 Implications for RFPs Reporting apps – Department info systems – Cardiology PACS – Imaging workstations – EMR and clinical workstations –

11. 11

12. September, 2005What IHE Delivers 12 IHE for Regional Health Information Networks – XDS and Related Profiles ACCA IHE Workshop 2007 Harry Solomon, GE Healthcare IHE-Cardiology Technical & Planning Committees

13. 13 Acute Care (Inpatient) PCPs and Clinics (Ambulatory) Long Term Care Other Specialized Care or Diagnostics Services Regional Health Information Organization (RHIO) The Enterprise Silo Problem

14. 14 RHIOs – an emerging trend 85+% of healthcare encounters in local home area Regional markets often limited to 2-5 major IDNs, facilitating agreement among all players Social factors favor regional business agreements Regional markets may be assisted by state initiatives Regional Health Information Organizations (RHIOs) recognized as the preferred model for EHR data sharing by US Dept. of Health and Human Services

15. 15 IHE’s approach for RHIOs Common technical specification for local, regional, disease- specific, or national health information exchange Enable document-based search and exchange between EHR systems, ancillary IT systems (lab, pharmacy, payers), and personal health record systems Incrementally build on (do not replace) existing healthcare business models, including models of “data custodianship” Avoid the pitfalls of “rampant featurism” – keep it simple IHE Cross-Enterprise Document Sharing (XDS) introduced in 2005 Adopted as primary foundation for HITSP Interoperability Specifications in 2006

16. 16 Clinical Encounter Clinical IT System Index of patients records (Document-level) Aggregate Patient Info 4-Patient data presented to Physician Sharing System Clinic Record Specialist Record Hospital Record 2-Reference to Records for Inquiry 3-RecordsReturned 1-Reference to records Repository of Documents XDS – How it works

17. 17 Cross-Enterprise Document Sharing Benefits Sharing of Documents minimizes clinical data management by the infrastructure. Transparency = Ease of Evolution Supports both centralized and decentralized repository architectures; ease of federation and evolution. Flexibility of configurations = Supports multiple business models Avoids replication/aggregation of data in sharing infrastructure. No false assertion of consolidated “truth” about patient Patients have guaranteed portability of data among RHIO- participating providers. Digital Documents = Patient and providers empowerment

18. 18 Cross-Enterprise Document Sharing (XDS) Standards Used Two “categories” of standards used XDS Infrastructure (Document sources, consumers, registries, repositories) ebXML Electronic Business Standards XDS Doc Content Medical Summaries (HL7 CDA/CRS+V3) Imaging (DICOM) ECG Reports (PDF+) …

19. 19 Why is IHE-XDS a breakthrough ? It based on an International Standard - 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 aligned with existing models of data custodianship. 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 point-to-point push communication 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

20. 20 IHE-XDS family of profiles Security and privacy Patient identification management Notification of document availability Multi-point sharing (RHIO) and direct point-to-point exchange models Rich Document Content for end-to-end application interoperability  Specific structured document templates IHE-XDS + related IHE profiles provide a complete interoperability solution

21. 21 XD* Content Profiles Medical Summary – encounter notes, discharge summary Imaging – exchange of image links Emergency Department Referral Pre-procedure History and Physical Scanned Documents Personal Health Records Basic Patient Privacy Consents Laboratory Reports All from Patient Care Coordination Domain, except Imaging (Radiology) and Laboratory (Laboratory Domain)

22. 22 Structured Content with Coded Entries  Reason for Referral     Vital Signs     Studies  Social History  Care Plan XDS-MS Medical Summary Structured and Coded Header Patient, Author, Authenticator, Institution, Time of Service, etc. Header always structured and coded Title-coded sections with non-structured non-coded content (text, lists, tables).  Simple Viewing (XML Style sheet) Level 1 Level 2 Text Structure Entry Text Structure Entry Meds, Problems and Allergies required as highly structured text.  Text easy to import/parse Text Structure Entry Level 3 Meds, Problems and Allergies have a required fine-grain structure with optional coding. Coding Scheme not standardized, but explicitly identified. Coded Section Entry Coded Section Entry Coded Section Entry Level 3 XDS-MS enables both semantic interoperability and simple viewing ! Medications  Allergies  Problems

23. 23 Use of XDS infrastructure to access Images and Imaging Reports (XDS-I) Hospital Imaging Center Physician Practice PACS Y PACS Z PACS -to- PACS PACS -to- Office Same XDS Infrastructure for medical summaries and imaging information !

24. 24 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.

25. 25 XDS Affinity Domain (NHIN sub-network) Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System XDS Scenario with 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

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

27. 27 Basic Patient Privacy Consents An XDS Affinity Domain can  Develop privacy policies,  Implement them with role-based or other access control mechanisms supported by EHR systems. A patient can  Be made aware of an institutions privacy policies.  Have an opportunity to selectively control access to their healthcare information. The BPPC document  Records the patient privacy consent(s),  Is human readable and machine processable,  Can capture scanned signatures and digital signatures,  Is exchanged using XDS mechanisms.

28. 28 Implications for RFPs Department info systems – Cardiology PACS – EMR and clinical workstations –

29. 29

30. September, 2005What IHE Delivers 30 The US Federal Landscape for Health Information Technology ONCHIT, HITSP, CCHIT ACCA IHE Workshop 2007 Harry Solomon, GE Healthcare IHE-Cardiology Technical & Planning Committees

31. 31 The current initiative Executive Order 13,335 (2004)  Most Americans to have an EHR by 2014  Establish DHHS Office of National Coordinator for Health IT American Health Information Community (2005)  Make policy recommendations to HHS Secretary  Identify ‘early breakthrough’ priorities: Initial set: Biosurveillance, Consumer Empowerment, EHRs, Chronic DiseaseInitial set: Biosurveillance, Consumer Empowerment, EHRs, Chronic Disease ONCHIT contracts in four programmatic areas (2005)  Standards harmonization (HITSP)  Security and privacy policy (HISPC)  System certification (CCHIT)  Prototype National Health Information Networks (NHIN)

32. 32 American Health Information Community Healthcare Information Technology Standards Panel (HITSP) Nationwide Health Information Network Architecture Projects (NHIN) The Health Information Security and Privacy Collaboration (HISPC) The Certification Commission for Healthcare Information Technology (CCHIT) American Health Information Community The Community is a federally- chartered commission that provides input and recommendations to HHS on how to make health records digital and interoperable, and how to assure that the privacy and security of those records are protected, in a smooth, market-led way. The public-private Community serves as the focal point for US health information concerns and drives opportunities for increasing interoperability.

33. 33 Federal HIT Projects HITSP delivers first set of Interoperability Specifications (2006)  Based on three AHIC breakthrough priorities  Using IHE Profiles for 80% of technical content CCHIT completes first round of certifications (2006)  Ambulatory EMR systems Four NHIN contractors begin implementation of 12 prototype RHIOs  9 of 12 are based on IHE Profiles HISPC to deliver report (April 2007)  Recommendations on security and privacy regulations (federal and state)

34. 34 HITSP Technical Committees Focus on AHIC Breakthrough Areas Biosurveillance -- Transmit essential ambulatory care and emergency department visit, utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized public health agencies with less than one day lag time. Consumer Empowerment -- Deploy to targeted populations a pre- populated, consumer-directed and secure electronic registration summary. Deploy a widely available pre-populated medication history linked to the registration summary. Electronic Health Records -- Deploy standardized, widely available, secure solutions for accessing laboratory results and interpretations in a patient- centric manner for clinical care by authorized parties. Chronic Care – Ensure that widespread use of secure messaging, as appropriate, is fostered as a means of communication between clinicians and patients about care delivery

35. 35 HITSP Framework Use Case / Modification Request Interoperability Specification Transaction 1… n components or composite standards Component 1...n base standards or composite standard Base Standard #1 Base Standard #2 Base Standard #3 Transaction Package 1…n transactions or composite standards Package (Composite) Standard Component (Composite) Standard Transaction (Composite) Standard P o t e n t i a l f o r R e u s e i n O t h e r C o n t e x t D e f i n e s a n d N a r r o w s C o n t e x t Policy Makers and Industry Base Standard #4 HITSP Base Standard #6 Base Standard #7 Base Standard #8 Base Standard #9 Base Standard #5 S t a n d a r d s O r g a n i z a t i o n s

36. 36 IHE and HITSP Interoperability Specifications HITSP Interoperability Specifications for 3 use cases use 8 IHE profiles EHR - Access to Lab results  Historical Results: XDS + NAV + XDS-Lab + PIX + PDQ  Lab to Ordering Provider: HL7 V2.5 msg with some differences with Lab-3 transaction from LSWF. Consumer Empowerment  Doc Sharing: XDS + PIX + PDQ  Reg/Med History: Not finalized but will be CDA/CCD. XPHR-TI version to be aligned on CCD when final is on the HITSP path. Biosurveillance  Doc Sharing track: XDS, XDS-Lab, XDS-I, XDS-MS  Anonimization: PIX + PDQ (with extensions)  Capture: RFD  Messaging track, no use of IHE profiles

37. 37 HITSP Goals and IHE HITSP goals with respect to testing activities  Ensure 'fitness for use' of HITSP Interoperability Specifications  Relationship with IHE to help overall collaborative testing activities for IHE profiles used in HITSP ISs HITSP collaboration with IHE  8 IHE Profiles are contained in HITSP ISs  IHE Connectathon/HIMSS Showcase provide opportunity for collaboration to meet mutual goals To access HITSP Interoperability Specifications: http://www.ansi.org/standards_activities/standards_boards _panels/hisb/hitsp.aspx?menuid=3

38. 38 CCHIT within HHS Health IT Strategy Standards Harmonization Contractor CCHIT: Compliance Certification Contractor Privacy/Security Solutions Contractor Office of the National Coordinator Project Officers American Health Information Community Chaired by HHS Secretary Mike Leavitt NHIN Prototype Contractors Harmonized Standards Network Architecture Privacy Policies Governance and Consensus Process Engaging Public and Private Sector Stakeholders Certification Criteria + Inspection Process for EHRs and Networks Strategic Direction + Breakthrough Use Cases Accelerated adoption of robust, interoperable, privacy-enhancing Health IT

39. 39 Scope of Work Under HHS Contract Phase I (Oct 05 – Sep 06)  Develop, pilot test, and assess certification of EHR products for ambulatory care settings Phase II (Oct 06 – Sep 07)  Develop, pilot test, and assess certification of EHR products for inpatient care settings Phase III (Oct 07 – Sep 08)  Develop, pilot test, and assess certification of infrastructure or network components through which EHRs interoperate Scope Expansion (effective Oct 06)  Address specialized EHR needs This will include cardiology As defined by HITSP Interop Specs (80% IHE)

40. 40 Implications of Certification Likely requirement (2009-10) for all health IT purchased with federal funds to be certified by CCHIT under HITSP Interoperability Specs  How far will that go regarding HIT used in treatment of CMS patients? HITSP Interoperability Specs are IHE!

41. 41