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

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

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

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

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

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

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

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

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

10. 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^ ^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

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

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

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

14. 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^ ^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

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

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

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

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

19. For More Information, or to Join Our Efforts
To participate or ask questions please contact Manny Furst Please include: Name, Title, Company and Postal Addresses Phone(s)