ihe workshop – june 2006what ihe delivers 1 nicholas steblay boston scientific implantable device...

1IHE Workshop – June 2006 What IHE Delivers

Nicholas SteblayNicholas Steblay

Boston ScientificBoston Scientific

Implantable Device Cardiac Implantable Device Cardiac Observations (IDCO) ProfileObservations (IDCO) Profile

2IHE Workshop – June 2006IHE Workshop – June 2006

Implantable Cardiac DevicesImplantable Cardiac Devices

Pacemakers – therapy for heart rate problems

Defibrillators – therapy for life threatening heart rhythms

Cardiac Resynchronization – therapy for congestive heart failure


Device InterrogationsDevice Interrogations

Implant

Clinic

Home

The act of retrieving data from The act of retrieving data from implanted cardiac devices. implanted cardiac devices. Done at implant or during Done at implant or during patient follow-ups.patient follow-ups.

Information includes Patient and Information includes Patient and Device Observations, andDevice Observations, andTherapy SettingsTherapy Settings


Clinical Process – Device Follow-upClinical Process – Device Follow-up

3.1 Schedule Follow-ups

3.2 Exam Patient & Interrogate Device

3.3 Analyze Information

3.1.1 Schedule In Clinic Follow-ups

3.1.2 Schedule Remote Follow-ups

3.2.1 Exam Patient (Physical & Lab Tests If Needed)

3.2.2 Interrogate Device In Clinic

3.2.3 Interrogate Device Remote

3.3.1 Review Exam and Interrogation Information

Determine New or Adjusted Therapies

3.4 Adjust Therapy and Configure Device

3.3.1 Pharmalogical3.3.2 Configure and

Test Pulse Generator

3.5 Update Medical Record

3.5.1 Record and Follow-up Process and Outcomes

3.5.2 Record Pertinent Data Concerning Device and Pharmalogical

3.5.4 Sign-Off Procedure

3.5.5 Create Follow-up Summary (Referral Letter) for Following Physician

1.0 Diagnosis

2.0 Implant

3.0 Device Follow-up

4.0Patient Follow-up

5.0 Acute Events

Explants

Level 0

Level 1

Level 2


Implantable Cardiac Device Follow-up Implantable Cardiac Device Follow-up Problems and OpportunitiesProblems 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


IDCO Value PropositionIDCO 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


IDCO Profile ApproachIDCO 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 11073 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 profilesKeep it simple for first year – trial implementation


IDCO Profile Use CasesIDCO 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 ProfileIDCO ProfileSystems ModelSystems Model

Home Healthcare Environment

Inductive or RF Interrogation

In-Clinic Healthcare Environment

Inductive or RF Interrogation

IHE

TR

AN

SA

CT

ION

IHE TRANSACTION

IHE

TR

AN

SA

CT

ION

Programmer

Device Vendor Environment

IHE TRANSACTION

SecuredNetwork

Transmissions

SecuredNetwork

Transmissions

Another ClinicSecuredNetwork

Transmissions

EHR or DeviceManagement System

Vendo

r Dat

a Tra

nsfe

r

Device Data Information Management System

InterrogationDevice


IDCO Actors and TransactionIDCO Actors and Transaction

Observation Processor

Observation Repository

Send Observation[CARD - 12]


PIX Consumer

ObservationCreator

PIX Consumer

Patient Demographics

Consumer


IDCO ActorsIDCO Actors





PIX Consumer

ObservationCreator

PIX Consumer


Consumer

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


IDCO ActorsIDCO 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




ObservationCreator


Consumer

HL7 RouterSend Observation

[CARD - 12]


PIX Consumer


Potential ParticipantsPotential Participants

Observation Creator Implantable Cardiac Device Vendors

Observation Processor and Repository EMR or Device Clinic Management System

Vendors

HL7 Router Integration Engine Vendors

Others (?)


IDCO TransactionIDCO Transaction





PIX Consumer

ObservationCreator

PIX Consumer


Consumer

CARD-12

Unsolicited HL7 v2.5 ORU message OBX contains XML payload based on HL7 v3 IDC message XML payload coded using ISO/IEEE 11073.1.1.3 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


Embedded XML Data Payload in OBXEmbedded XML Data Payload in OBXBased on v3 IDC RMIMBased on v3 IDC RMIM

Implantable Cardiac Device Summary(POTD_RM000001)

Description: Implantable Cardiac Device Summary report.This report contains a subset of current programmed settingsand device observations

ObservationclassCode*: <= OBSmoodCode*: <= EVNid*: SET<II> [1..*]code*: CD CWE [1..1] <=DeviceInterrogation (The capturing or reading out of datastored in the medical device)statusCode: CS CNE [0..1] <=ActStatuseffectiveTime*: TS [1..1]

CMET: (PAT) R_Patient

[identified/confirmable](COCT_MT050002)

0..1 roleName 1..1 patient *

typeCode*: <= RCTcontextControlCode: CS CNE [0..1] <= "OP"

recordTarget

DeviceTherapySettingclassCode*: <= OBSmoodCode*: <= EVNcode*: CE CWE [1..1] <= ImplantedCardiacDeviceControlVariable (Externally defined subset of IEEE 1073 vocabulary)text: ED [0..1]value: ANY [0..1]

1..* assignedEntity

typeCode*: <= AUTtime*: TS [1..1]signatureCode: CE CNE [0..1] <= XsignatureText: ED [0..1]

author

0..* assignedEntity

typeCode*: <= PRFperformer

CMET: (ASSIGNED) R_AssignedEntity

[identified/confirmable](COCT_MT090002)

0..1 roleName

0..1 externalCardiacInterrogationDevice

typeCode*: <= RDVreusableDevice

0..1 assignedInterrogationDevice

ExternalCardiacInterrogationDeviceclassCode*: <= ASSIGNEDid: II [0..1]code: CE CWE [0..1] <= DedicatedServiceDeliveryLocationRoleType

InterrogationDeviceclassCode*: <= DEVdeterminerCode*: <= INSTANCEid: II [0..1] (e.g. Serial Number)desc: ED [0..1]manufacturerModelName: SC CWE [0..1] <= ManufacturerModelNamesoftwareName: SC CWE [0..1] <= SoftwareName

OrganizerclassCode*: <= ORGANIZERmoodCode*: <= EVN

CMET: (ASSIGNED) R_AssignedDevice

[universal](COCT_MT090300)

0..1 roleName

Note:Participant who assists inperforming the interrogationof the implanted device

Note:Implantable CardiacDevice or identified lead

1..1 assignedDevice *

typeCode*: <= SBJcontextControlCode: CS CNE [0..1] <= "OP"

subject

PatientObservationclassCode*: <= OBSmoodCode*: <= EVNid: II [0..1]code*: CD CWE [1..1] <= CardiacDevicePatientObservationTypetext: ED [0..1]effectiveTime: IVL<TS> [0..1]value: ANY [0..1]interpretationCode: CE CNE [0..1] <= ObservationInterpretationNormality

1..1 patient

typeCode*: <= SBJcontextControlCode: CS CNE [0..1] <= OP "ContextControlOverriding"

subject

MedicalDeviceActclassCode*: <= ACTmoodCode*: <= EVNid: SET<II> [0..*]code*: CD CWE [1..1] <= MedicalDeviceActtext: ED [0..1]effectiveTime: TS [0..1]

0..* medicalDeviceAct

typeCode*: <= SUBJcontextControlCode: CS CNE [1..1] <= "ON"contextConductionInd: BL [0..1] "true"

subject

0..* deviceTherapySetting

typeCode*: <= CTRLVcontextControlCode: CS CNE [0..1] <= "AN"contextConductionInd: BL [0..1] "false"

controlVariable

1..1 assignedDevice

typeCode*: <= PPRFcontextControlCode: CS CNE [0..1] <= "OP"

primaryPerformer

0..* organizer

typeCode*: <= COMPcontextControlCode: CS CNE [0..1] <= "AN"contextConductionInd: BL [0..1] "true"

component1

DeviceTherapyclassCode*: <= PROCmoodCode*: <= EVNid: II [0..1]code*: CE CWE [1..1] <= ImplantedCardiacDeviceTherapy (IEEE 1073)text: ED [0..1]activityTime: TS [0..1]

DeviceObservationclassCode*: <= OBSmoodCode*: <= EVNcode*: CD CWE [1..1] <= CardiacDeviceSelfObservationType (IEEE1073)text: ED [0..1]effectiveTime: IVL<TS> [0..1]value: ANY [0..1]interpretationCode: CE CNE [0..1] <= ObservationInterpretationNormalitymethodCode: CE CWE [0..1] <= ObservationMethod (IEEE 1073)

0..* deviceObservation

typeCode*: <= COMPcontextControlCode: CS CNE [0..1] <= "ON"contextConductionInd: BL [0..1] "true"

component

0..* patientObservation


component2

0..* deviceTherapy


component3

Note:E.g.: Brady SettingsPacing Output SettingsAtrial Tachy SettingsVentricular Tachy Settings

OrganizationclassCode*: <= ORGdeterminerCode*: <= INSTANCEid: SET<II> [0..*]name: BAG<EN> [0..*]

Note:This ACT changes thesubject from patient tothe device.

0..1 encounter *

typeCode*: <= COMPcontextControlCode: CS CNE [1..1] <= "OP"contextConductionInd: BL [1..1] "false"

componentOf CMET: (ENC) A_Encounter

[universal](COCT_MT010000)

component

0..* deviceObservation

typeCode*: <= COMPcontextControlCode: CS CNE [1..1] <= ContextControlPropagating "AP"contextConductionInd: BL [0..1]sequenceNumber: INT [0..1]priorityNumber: INT [0..1]

component

0..* patientObservation


component

0..* deviceTherapySetting


Option for Standard OBX SegmentOption for Standard OBX SegmentELEMENT NAME SEQ COMP DT LEN USAGE CARD TBL# ITEM # Fixed Ex. Values

Set ID - OBX 1 SI 4 R [1..1] 00569 1

Value Type 2 ID 2 R [1..1] 0125 00570 DTM

Observation Identifier 3 CE 250 R [1..1] 00571

Identifier 1 ST 80 R [1..1] MDC_IDC_DEVICE_IMPLANT_DATE

Text 2 ST 256 R [1..1] The implant date of the device

Name of Coding System 3 ST 20 R [1..1] IEEE P10731.1.3

Observation Sub-ID 4 ST 20 C [1..1] 00572 3.1

Observation Value 5 varies * RE [0..1] 00573 20060317

Units 6 CE 250 RE [0..1]

Observation Result Status 11 ID 1 R [1..1] 0085 00579 Y F

Date/Time of the Observation 14 TS 26 RE [0..1] 00582

20060317170000+0006

Observation Method 17 CE 250 00936

Identifier 1 ST 80 R [1..1] MDC_IDC_SESSION_TYPE

Text 2 ST 256 R [1..1] In Clinic

Name of Coding System 3 ST 20 R [1..1] IEEE P10731.1.3

Equipment Instance Identifier 18 EI 256 O [0..*] 01479 Programmer XXXX


Observations Coded UsingObservations Coded UsingISO/IEEE 11073 IDC NomenclatureISO/IEEE 11073 IDC Nomenclature

IEEE 1073.1.1.3 IDC terms - nomenclatureDevice ObservationsPatient ObservationsDevice Therapy SettingsDevice TherapiesData TypesUnitsEnumerated Value TablesDiscriminators

Device Observations - [top]

Automatic Manual

1 Device Type MDC_IDC_DEVICE_TYPE The type of device

2 Device Manufacturer MDC_IDC_DEVICE_MANUFACTURER MDC_IDC_DEVICE_TYPE The manufacturer of the device

3 Device Name MDC_IDC_DEVICE_NAME MDC_IDC_DEVICE_TYPE The marketing name given to a device by the manufacturer

4 Device Model MDC_IDC_DEVICE_MODEL MDC_IDC_DEVICE_TYPE The model of a device

6 Device Serial Number MDC_IDC_DEVICE_SERIAL_NUMBER MDC_IDC_DEVICE_TYPE The serial number for a device

7 Device Implant Date MDC_IDC_DEVICE_IMPLANT_DATE MDC_IDC_DEVICE_TYPE The implant date of the device

8 Device Explant Date MDC_IDC_DEVICE_EXPLANT_DATE MDC_IDC_DEVICE_TYPE The explant date of the device

9 Device Abandon Date MDC_IDC_DEVICE_ABANDON_DATE MDC_IDC_DEVICE_TYPE The date the device was abandoned (still implanted but not functioning)

10 System Status MDC_IDC_SYSTEM_STATUS Overall status of the system

17 Lead State MDC_IDC_LEAD_STATE The state of lead

18 Lead Polarity Type MDC_IDC_LEAD_POLARITY_TYPE The type of lead polarity

20 Lead Heart Anatomy Location Modifier MDC_IDC_LEAD_ANOTOMICAL_LOCATION_MODIFIER

MDC_IDC_LEAD_ANOTOMICAL_LOCATION The site within the heart anatomy where the lead is fixated

26 Lead Pace Threshold at Implant Amplitude MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT_AMPLITUDE

MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT 1 The minimum Chamber Pulse Amplitude needed for capture

27 Lead Pace Threshold at Implant Pulse Width MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT_PULSE_WIDTH

MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT 2 The minimum Pulse Width needed for capture

29 Lead DFT at Implant MDC_IDC_LEAD_DFT_IMPLANT For each high voltage lead, the measured defibrillation threshold (DFT) at implant.

31 Date/Time of Communication Session MDC_IDC_SESSION_DATE_TIME Date of the current in-clinic or remote interrogation.

32 Previous Session Date MDC_IDC_PREVIOUS_SESSION_DATE_TIME Date of most recent in-clinic or remote interrogation.

33 Session Type MDC_IDC_SESSION_TYPE The type of device interaction that generated the current data set. If the specific cause of a remote data transmission is unknown, use the "Remote" value. If the specific cause is known, use the values of Remote-Scheduled, Remote-Patient Initiatied or Remote-Device Initiated.

# Display Name Reference ID Parent ID SeqNr Discriminator Description

19 Lead Heart Anatomy Location MDC_IDC_LEAD_ANOTOMICAL_LOCATION MDC_IDC_discriminator_LeadLocationType The heart anatomy where the lead is located

21 Lead Intrinsic Amplitude at Implant MDC_IDC_LEAD_INTRINSIC_AMPLITUDE_IMPLANT MDC_IDC_discriminator_HowMeasured Intrinsic Amplitude (P-Wave) measured during an Intrinsic Amplitude Test at implant

22 Lead Intrinsic Amplitude Configuration at Implant MDC_IDC_LEAD_INTRINSIC_AMPLITUDE_CONFIGURATION_IMPLANT

MDC_IDC_discriminator_ElectrodeType For each low voltage lead, the sensing configuration used during implant to measure the intrinsic amplitude

23 Lead Pace Impedance at Implant MDC_IDC_LEAD_PACE_IMPEDANCE_IMPLANT MDC_IDC_discriminator_HowMeasured Lead Impedance measured during a Lead Impedance Test at implant

24 Lead Pace Impedance Configuration at Implant MDC_IDC_LEAD_PACE_IMPEDANCE_CONFIGURATION_IMPLANT

MDC_IDC_discriminator_ElectrodeType For each low voltage lead, the pacing configuration used during implant to measure the lead impedance

25 Lead Pace Threshold at Implant Amplitude @ Pulse Width

MDC_IDC_LEAD_PACE_THRESHOLD_IMPLANT MDC_IDC_discriminator_HowMeasured The minimum electrical stimulation (pacemaker output pulse) required to consistently initiate chamber depolarization and cardiac contraction, as determined by a clinician-interpreted threshold test at implant.

28 Lead Pace Threshold Configuration at Implant MDC_IDC_LEAD_PACE_THRESHOLD_CONFIGURATION_IMPLANT

MDC_IDC_discriminator_ElectrodeType For each low voltage lead, the pacing configuration used during implant to measure the capture threshold

30 Lead DFT Configuration at Implant MDC_IDC_LEAD_DFT_CONFIGURATION_IMPLANT MDC_IDC_discriminator_ElectrodeType For each high voltage lead, the shock configuration used during defibrillation threshold (DFT) measurement at implant.


Example Transaction FlowExample Transaction FlowDevice Interrogator Observation Creator Observation Processor Observation Repository

Query Device (1)

Send Interrogation

Send Interrogation (2)

Validate and Review (3)

Translate Information (4)

Send Observation [CARD-12] (5)

Process Observation (7)

Send Observation [CARD-12] (8)

Store Observation (10)

PIX Manager

PIX Query [ITI-9] (6)

PIX Query [ITI-9] (9)


Potential Extended Actor GroupingsPotential Extended Actor Groupings

ObservationRepository

Information Source

Display

Retrieve Document for Display [ITI - 12]

Retrieve Specific Info for Display [ITI - 11]

ObservationProcessor

ReportCreator

Report Manager

Encapsulated Report Submission [CARD - 7]


EvidenceCreator

Image Manager

Storage Committment [CARD - 3]

Modality Images/Evidence Stored [CARD - 2]

Store Evidence Documents [RAD - 43]

Storage Committment [CARD - 7]


Document Source

Document Repository

Provide and Register Document Set [ITI - 15]

Basic IDCO Report Display using Retrieve Information for Display Profile (RID)Basic IDCO Report Display using Retrieve Information for Display Profile (RID)

IDCO Data Incorporation into a Report using Displayable Reports Profile (DRPT)IDCO Data Incorporation into a Report using Displayable Reports Profile (DRPT)

IDCO Discrete Data Storage using Evidence Documents Profile (ED)IDCO Discrete Data Storage using Evidence Documents Profile (ED)

IDCO Submission to an EHR using Cross Domain Document Sharing Profile (XDS)IDCO Submission to an EHR using Cross Domain Document Sharing Profile (XDS)


What’s Next?What’s Next?

PIX and PAM groupings required

Waveforms

Episodes

Scheduling / Orders


More info on www.ihe.netMore info on www.ihe.net

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 11073.1.1.3 Nomenclature


QuestionsQuestions

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 SteblayBoston [email protected](651) 582-7316