Displayable Reports (DRPT)

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

2. Typical Cardiology Reports

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. 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. 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. Displayable Reports ProfileTransaction Diagram Report Creator Encapsulated Report Encapsulated Report or Enterprise Report Repository Report Manager Dept Scheduler / Order Filler Report Completion Notify Report Reference Encapsulated Report Storage Commitment Report Repository Patient Identity Feed Patient Demographics Source Patient Demographics Consumer Information Source Web Display Retrieve Document for Display Encapsulated Report Query Encapsulated Report Retrieve Report Reader

7. Displayable Reports ProfileActors • 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. 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 HL7 MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^… OBX|1|RP|11528-7^LN… http://serv.hosp.org/app?requestType=DOCUMENT&documentUID=”1.2.3”&preferredContentType=”application/pdf” MSH|^~\$|… PID|1|0123456‑1||R… OBR|1|X89‑1501^… OBX|1|ED|11528-7^LN… HTTP DICOM (0008,0005) IR_100 (0008,0012) 20061113 (0008,0013) 1109 (0008,0016) 1.2.8401008.… Displayable Reports ProfileStandards Used Report Creator Encapsulated Report Encapsulated Report or Enterprise Report Repository Report Manager Dept Scheduler / Order Filler Report Completion Notif Report Reference Encapsulated Report Storage Commitment Report Repository Patient Demographics Source Patient Identity Feed Patient Demographics Consumer Information Source Web Display Retrieve Document for Display Encapsulated Report Query Encapsulated Report Retrieve Report Reader

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. Implications for RFPs • Reporting apps – • Department info systems – • Cardiology PACS – • Imaging workstations – • EMR and clinical workstations –

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. The Enterprise Silo Problem Regional Health Information Organization (RHIO) Long Term Care Acute Care (Inpatient) Other Specialized Careor Diagnostics Services PCPs and Clinics (Ambulatory)

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. 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 2005Adopted as primary foundation for HITSP Interoperability Specifications in 2006

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

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

18. 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)

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

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

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

22. EHR System ED Application Physician Office XDS Document Repository PACS XDSDocument Repository EHR System PACS Lab Info. System Teaching Hospital Community Clinic ATNA Audit record repository CT Time server XDS Affinity Domain (NHIN sub-network) XDS Scenario with use of ATNA & CT PMS XDS Document Registry Query Document Register Document Secured Messaging Retrieve Document Provide & Register Docs Maintain Time Maintain Time Record Audit Event Maintain Time Record Audit Event Record Audit Event

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

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

26. The US Federal Landscape for Health Information TechnologyONCHIT, HITSP, CCHIT ACCA IHE Workshop 2007 Harry Solomon, GE Healthcare IHE-Cardiology Technical & Planning Committees

27. 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 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)

28. The Certification Commission for Healthcare Information Technology (CCHIT) Healthcare Information Technology Standards Panel (HITSP) American Health Information Community The Health Information Security and Privacy Collaboration (HISPC) Nationwide Health Information Network Architecture Projects(NHIN) 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.

29. 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)

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

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

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

33. CCHIT within HHS Health IT Strategy American Health Information CommunityChaired by HHS Secretary Mike Leavitt Office of the National CoordinatorProject Officers Strategic Direction +Breakthrough Use Cases StandardsHarmonizationContractor HarmonizedStandards CCHIT:ComplianceCertificationContractor CertificationCriteria +Inspection Processfor EHRsand Networks Accelerated adoption of robust, interoperable, privacy-enhancing Health IT NetworkArchitecture NHINPrototypeContractors PrivacyPolicies Privacy/SecuritySolutionsContractor Governance and Consensus Process EngagingPublic and Private Sector Stakeholders

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

35. 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!