IHE PCD MEM-DMC CMMS & RTLS Vendor Perspective Monroe Pattillo Practical Health Interoperability, LLC 6/13/2013

What We’re Attempting to Accomplish Improve patient safety and healthcare operational efficiencies and effectiveness We accomplish this through the use of IHE PCD profiles Standards based , documented use cases, transactions, with agreed common content IHE PCD uses HL7 v2.6

The General Need Electronically record information (to EMR, CIS, CMMS)… That would otherwise have to be entered manually Record it so as to meet requirements (FDA, JC, etc.) Communicate the information to systems that can use the information to… Improve patient safety Improve efficiencies and effectiveness of… Devices, Systems Staff (clinicians, biomeds, CEs, etc.) through notifications

The Specific Need Tracking Equipment Utilization To improve cost effectiveness of that equipment To improve equipment state awareness To provide increased ROI on supplied systems Tracking Equipment and People Locations To improve cost effectiveness of equipment To identify location of patient at the time of an alert To identify location of staff at the time of an alert To pass location events & information to staff To associated staff to patients (longer term)

The Specific Need Alerting Those Responsible and Documenting the Alert Improve equipment quality and availability while improving staff productivity Provide clinical and technical staff the ability to respond to malfunctions that affect patient care Documenting Conditions That Do Not Require Intervention Improve productivity, e.g., “self-test passed” reduces the need for hands on examination Hardware, software, patch versions

Overview of IHE Process Steps Document , ballot, and approve Brief Proposal for Profile Detailed Proposal for Profile Trial Implementation for Profile using a Working Group Verify it at IHE Pre-Connectathon & Connectathon Demonstrate it at HIMSS Interoperability Showcase Demonstrate it at AAMI IHE PCD Interoperability Demonstration Produce an IHE Integration Statement Produce a commercial implementation

Some Use Cases CMMS reports (generated reports, not msgs to wireless/mobile devices) UC #1 Device utilization by patient association by events when patient associated UC #2 Device issues management battery not maintaining charge malfunction Staff notification of device alarms & events (not by CMMS) UC #3 Notify clinicians of issues when device is associated with patient Leads off, pump flow issues, bag empty UC #4 Notify Biomeds of issues when device is not associated with patient Battery not maintaining charge Staff notifications of CMMS alerts & events (by CMMS use of ACM AM) UC #5 Device management cleaning, calibration, recalls, lease return UC # 6 Device issue resolution repair, S/W updates

Medical Devices to CMMS for Reporting Overview (UC # 1 & 2) Medical equipment sends messages to CMMS Patient Association/De-association Utilization by patient – Start, Pause, Stop/End Equipment management events – Battery management, Self-Test Passed/Failed Medical Devices - Infusion Pumps, Patient Monitoring Patient Specific Information is ignored (HIPAA) Equipment identification is significant Equipment location is significant

Medical Devices to CMMS for Reporting Message Flow Alarm or Event HL7 v2 ORU^ R01, R40, R43 Report Medical Device CMMS HL7 v2 ACK Receipt Acknowledgement

Medical Devices to CMMS for Reporting HL7 v2 Basic Message Content as seen by CMMS MSH-3 Sending Application – identifies sending application, MSH-4 Sending Facility – identifies instance of application, MSH-5 – identifies CMMS as application, MSH-6 – identifies instance of CMMS MSH-7 Timestamp – when message was sent (yyyymmddhhmmss±zzzz) MSH-9 Message Type Identification – ORU^xxx^ORU_xxx (R01 Observation, R40 Alarm, R43 Event) MSH-21 Message Profile Identifier – for alarms = “IHE_PCD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.4.1^ISO” PID Segment Patient Identification (ignored – HIPAA) – may be useful for traceability, i.e. which patients have been associated with defective, out of rev, or out of calibration equipment PV1-3 Patient Location – ADT Assigned Patient Location – Unit^Room^Bed, alternative in case RTLS not supported OBR Event or Alarm Indication – OBR-3 Unique status update ID on event or alarm, OBR-4 Identifies the observation, OBR-29 Parent ID for multiple update notifications OBX Segment, multiple occurrences – pertinent parameters relating to alarm or event OBX-3 Observation Identifier, OBX-4 Sub-ID FACET, OBX-5 Observation value, OBX-6 Units of Measurement, OBX-7 Range, OBX-8 Flags (priority & class for alarms) Source MDS/VMDS/Chan OBX-14 Observation timestamp (yyyymmddhhmmss±zzzz) OBX-18 Equipment identification (event or alarm source, not the application/gateway that sent it) How will equipment location (RTLS) be passed – OBX-5 when OBX-4 Sub ID FACET = 6 per ACM TI 2012

Medical Devices to CMMS for Reporting HL7 v2 Acknowledgement Basic Content as Sent by CMMS MSH-3 Sending Application – identifies CMMS as sender, MSH-4 Sending Facility – identifies instance of CMMS, MSH-5 Receiving Application, from original message, MSH-6 Receiving Facility, from original message MSH-7 Timestamp – when acknowledgement was sent, MSH-8 Security = Empty MSH-9 Message Type Identification – ACK^xxx^ACK (R01 Observation, R40 Alarm, R43 Event) MSH-10 Message Control – message ID # MSA-1 Acknowledgement Code – “AA”=Ok, “AR”=Retransmit, “AE”=Error MSA-2 Message ID of message being acknowledged MSA-4 Expected Sequence Number, for transport error retransmission ERR Segment – used to indicate specifics of an error - ERR-2 Error Location, ERR-3 Error Code, ERR-4 Severity, ERR-5 Application Error Code

Medical Devices as ACM AR to AM to AC for Staff Notifications Overview (UC # 3 & 4) Medical equipment sends messages as ACM AR to ACM AM to ACM AC for delivery to staff (clinician/biomed) Device in need of assistance (door, syringe, paper out) Workflow – dose end, bag empty, bag near empty, leads off Equipment management events – Battery management Medical Devices – Infusion Pumps, Patient Monitoring Patient Specific Information is Ignored (HIPAA) Equipment identification is significant Equipment location is significant

Medical Devices as ACM AR to AM to AC for Staff Notifications Message Flow Alarm or Event Disseminate Notification IHE PCD-04 HL7 v2 ORU^R40 IHE PCD-06 WCTP Medical Device as ACM AR ACM AM ACM AC HL7 v2 ACK IHE PCD-07 WCTP Implementation Specific Receipt Acknowledgement Status Updates (delivery, read) & Replies (accept, reject)

Medical Devices as ACM AR to AM to AC for Staff Notifications IHE PCD-04 (HL7 v2) Basic Message Content sent by AR MSH-3 Sending Application – identifies sending application, MSH-4 Sending Facility – identifies instance of application, MSH-5 – identifies receiving ACM AM application, MSH-6 – identifies receiving ACM AM instance MSH-7 Timestamp – when message was sent (yyyymmddhhmmss±zzzz) MSH-9 Message Type Identification – ORU^R40^ORU_R40 (alarm or alert) MSH-15 Accept Acknowledgement Type = “NE”, MSH-16 Application Acknowledgement Type = “AL” MSH-21 Message Profile Identifier – for alarms = “IHE_PCD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.4.1^ISO” PID Segment Patient Identification (ignored – HIPAA) – may be useful for traceability, i.e. which patients have been associated with defective, out of rev, or out of calibration equipment PV1-3 Patient Location – ADT Assigned Patient Location – Unit^Room^Bed, alternative in case RTLS not supported OBR Event or Alarm Indication – OBR-3 Unique status update ID on event or alarm, OBR-4 = “ALARM^ALARM”, OBR-29 Parent ID for multiple update notifications OBX Segment, multiple occurrences – pertinent parameters relating to alarm or event OBX-3 Observation Identifier, OBX-4 Sub-ID FACET, OBX-5 Observation value, OBX-6 Units of Measurement, OBX-7 Range, OBX-8 Flags (priority & class for alarms) Source MDS/VMDS/Chan OBX-14 Observation timestamp (yyyymmddhhmmss±zzzz) OBX-18 Equipment identification (event or alarm source, not the application/gateway that sent it) How will equipment location (RTLS) be passed – OBX-5 when OBX-4 Sub ID FACET = 6 per ACM TI 2012

CMMS as ACM AR to AM to AC for Staff Notifications Overview (UC # 5 & 6) CMMS sends messages as ACM AR to ACM AM to ACM AC for delivery to staff (clinician/biomed) Device in need of forced maintenance – Outside utilization limit Periodic workflow – Used and needs cleaning, Time for calibration Equipment management – Replace battery, Needs S/W Update Medical Devices – Infusion Pumps, Patient Monitoring Equipment identification is significant Equipment location is significant

CMMS as ACM AR to AM to AC for Staff Notifications Message Flow Alarm or Event Disseminate Notification IHE PCD-04 HL7 v2 ORU^R40 IHE PCD-06 WCTP CMMS as ACM AR ACM AM ACM AC HL7 v2 ACK IHE PCD-07 WCTP Implementation Specific Receipt Acknowledgement Status Updates (delivery, read) & Replies (accept, reject)

CMMS as ACM AR to AM to AC for Staff Notifications IHE PCD-04 (HL7 v2) Basic Message Content sent by CMMS MSH-3 Sending Application – identifies CMMS application, MSH-4 Sending Facility – identifies instance of CMMS, MSH-5 – identifies receiving application, MSH-6 – identifies receiving application instance MSH-7 Timestamp – when message was sent (yyyymmddhhmmss±zzzz) MSH-9 Message Type Identification – ORU^R40^ORU_R40 alarm or alert MSH-10 Message Control – message ID #, MSH-11 Processing ID = “P”, MSH-12 HL7 Version ID = “2.6” MSH-15 Accept Acknowledgement Type = “NE”, MSH-16 Application Acknowledgement Type = “AL” MSH-21 Message Profile Identifier – for alarms = “IHE_PCD_ACM_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.4.1^ISO” PID Segment Patient Identification (ignored – HIPAA) – may be useful for traceability, i.e. which patients have been associated with defective, out of rev, or out of calibration equipment PV1-3 Patient Location – ADT Assigned Patient Location – Unit^Room^Bed, alternative in case RTLS not supported OBR Event or Alarm Indication – OBR-3 Unique status update ID on event or alarm, OBR-4 = “ALARM^ALARM”, OBR-29 Parent ID for multiple update notifications OBX Segment, multiple occurrences – pertinent parameters relating to alarm or event OBX-3 Observation Identifier, OBX-4 Sub-ID FACET, OBX-5 Observation value, OBX-6 Units of Measurement, OBX-7 Range, OBX-8 Flags (priority & class for alarms) Source MDS/VMDS/Chan OBX-14 Observation timestamp (yyyymmddhhmmss±zzzz) OBX-18 Equipment identification (event or alarm source, not the application/gateway that sent it) How will equipment location (RTLS) be passed – OBX-5 when OBX-4 Sub ID FACET = 6 per ACM TI 2012

CMMS as ACM AR to AM to AC for Staff Notifications HL7 v2 Acknowledgement Basic Content Received by CMMS MSH-3 Sending Application – identifies ACM AM application, MSH-4 Receiving Facility – identifies ACM AM application instance, MSH-5 Receiving Application – identifies CMMS application, MSH-6 Receiving Facility – identifies CMMS application instance MSH-7 Timestamp – when acknowledgement was sent, MSH-8 Security = Empty MSH-9 Message Type Identification – ACK^xxx^ACK (R01 Observation, R40 Alarm, R43 Event) MSH-10 Message Control – message ID # MSA-1 Acknowledgement Code – “AA”=Ok, “AR”=Retransmit, “AE”=Error MSA-2 Message ID of message being acknowledged MSA-4 Expected Sequence Number, for transport error retransmission ERR Segment – used to indicate specifics of an error - ERR-2 Error Location, ERR-3 Error Code, ERR-4 Severity, ERR-5 Application Error Code

For More Information, or to Join Our Efforts To participate or ask questions please contact Manny Furst EFurst@Imp-Tech.com Please include: Name, Title, Company Email and Postal Addresses Phone(s)