IHE Workshop – June 2006What IHE Delivers 1 Nicholas Steblay Boston Scientific Implantable Device Cardiac Observations (IDCO) Profile

IHE Workshop – June Implantable Cardiac Devices Pacemakers – therapy for heart rate problems Defibrillators – therapy for life threatening heart rhythms Cardiac Resynchronization – therapy for congestive heart failure

IHE Workshop – June Device Interrogations Implant Clinic Home The act of retrieving data from implanted cardiac devices. Done at implant or during patient follow-ups. Information includes Patient and Device Observations, and Therapy Settings

IHE Workshop – June Clinical Process – Device Follow-up 3.1 Schedule Follow- ups 3.2 Exam Patient & Interrogate Device 3.3 Analyze Information   Schedule In Clinic Follow-ups   Schedule Remote Follow-ups   Exam Patient (Physical & Lab Tests If Needed)   Interrogate Device In Clinic   Interrogate Device Remote   Review Exam and Interrogation Information   Determine New or Adjusted Therapies 3.4 Adjust Therapy and Configure Device   Pharmalogical   Configure and Test Pulse Generator 3.5 Update Medical Record   Record and Follow-up Process and Outcomes   Record Pertinent Data Concerning Device and Pharmalogical   Sign-Off Procedure   Create Follow- up Summary (Referral Letter) for Following Physician 1.0 Diagnosis 2.0 Implant 3.0 Device Follow-up 4.0 Patient Follow-up 5.0 Acute Events Explants Level 0 Level 1 Level 2

IHE Workshop – June Implantable Cardiac Device Follow-up Problems and Opportunities Electrophysiologists follow patients with implantable cardiac devices from multiple vendors For each patient follow-up information that is stored in the implantable device is electronically collected by an “interrogating” device  In-Clinic – Programmer  Remote – Communicator / Data Collector Each “interrogating” device is vendor proprietary The follow-ups can occur in-clinic or remotely in the home healthcare environment Access to follow-up information often requires clinicians to use multiple vendor specific systems and interfaces, complicating efficiency and quality of workflows Aggregation of data into a central EMR or device clinic management systems requires manual and paper processes

IHE Workshop – June IDCO Value Proposition Enable management of follow-up information in a central system such as an Device Clinic Management System or EMR Improve efficiency and quality of related clinical processes  Single point of access for information  Automation of current manual processes for data collection, aggregation and analysis  Standardization of workflow processes  Enabling of analytics

IHE Workshop – June IDCO Profile Approach Rally domain vendors around a profile that defines a standard approach to integrating implantable cardiac device follow-up information into a receiving clinic system Enable the needed systems integration by profiling the use of standard, domain applicable messaging protocols, structures and data semantics  HL7 Therapeutic Device Domain – Implantable Device Cardiac messaging standards  ISO/IEEE Point of Care Medical Device Communication Standards nomenclature Define actors, transactions and constraints consistent with existing and evolving IHE profiles and contexts  Align with future EP Workflow and other related profiles Keep it simple for first year – trial implementation

IHE Workshop – June IDCO Profile Use Cases In-Clinic Implants or Follow-ups  Patients present themselves in-clinic for implantation or follow-ups  Information is collected using vendor specific “programmers”  Information is sent from interrogation system to a central Device Clinic Management System or EMR Remote Follow-ups  Patients devices are interrogated in the home health care environment  Information is collected using vendor specific communication devices and systems  Information is sent from interrogation system to a central Device Clinic Management System or EMR

IDCO Profile Systems Model

IHE Workshop – June IDCO Actors and Transaction

IHE Workshop – June IDCO Actors Observation Creator - A system that creates and transmits diagnostic or therapeutic observational data. Observation Processor and Repository – Systems that receive clinical observations and further process them or store them for retrieval and display. Grouped with PIX and PAM actors for patient identification and demographics management (not required first year).

IHE Workshop – June IDCO Actors Alternative Actor configuration HL7 Router - A system that receives HL7 messages, routes them to one or more configured actors, and handles transport level acknowledgements. Router will manage patient identification cross-referencing

IHE Workshop – June Potential Participants Observation Creator  Implantable Cardiac Device Vendors Observation Processor and Repository  EMR or Device Clinic Management System Vendors HL7 Router  Integration Engine Vendors Others (?)

IHE Workshop – June IDCO Transaction CARD-12  Unsolicited HL7 v2.5 ORU message  OBX contains XML payload based on HL7 v3 IDC message  XML payload coded using ISO/IEEE IDC nomenclature containing Device Observations, Patient Observations, Device Therapy Settings  Options for standard v2.5 OBX and embedded PDF report  Audit Trail and Node Authentication (ATNA) profile recommended for remote follow-ups across non-trusted networks

IHE Workshop – June Embedded XML Data Payload in OBX Based on v3 IDC RMIM

Option for Standard OBX Segment

IHE Workshop – June Observations Coded Using ISO/IEEE IDC Nomenclature

IHE Workshop – June Example Transaction Flow

IHE Workshop – June Potential Extended Actor Groupings Basic IDCO Report Display using Retrieve Information for Display Profile (RID) IDCO Data Incorporation into a Report using Displayable Reports Profile (DRPT) IDCO Discrete Data Storage using Evidence Documents Profile (ED) IDCO Submission to an EHR using Cross Domain Document Sharing Profile (XDS)

IHE Workshop – June What’s Next? PIX and PAM groupings required Waveforms Episodes Scheduling / Orders

IHE Workshop – June More info on Profile for trial implementation SDK (available July 1) containing  Schema for embedded XML payload  Example HL7 2.5 messages Wrappers Standard OBX  Example OBX XML payload based on v3 IDC message  Spreadsheet / XML, Schema, Style Sheets for ISO/IEEE Nomenclature

IHE Workshop – June Questions Questions for me? A few for you … To claim this profile you need to support OBX embedded XML data payload. How does this impact your ability to participate? Do potential participating vendors prefer a standard v2.5 ORU message OBX or one with an embedded v3 data payload? Why or why not? Comment soon! Nicholas Steblay Boston Scientific (651)

IHE Workshop – June