190 likes | 329 Views
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
E N D
IHE PCD MEM-DMCCMMS & RTLSVendor 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 ReportingOverview (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 ReportingMessage Flow Alarm or Event HL7 v2 ORU^ R01, R40, R43 Report Medical Device CMMS HL7 v2 ACK Receipt Acknowledgement
Medical Devices to CMMS for ReportingHL7 v2 Basic Message Content as seen by CMMS • MSH-3Sending Application – identifies sending application, MSH-4Sending 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-3Patient 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 ReportingHL7 v2 Acknowledgement Basic Content as Sent by CMMS • MSH-3 Sending Application – identifies CMMS as sender, MSH-4Sending 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 NotificationsOverview (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 NotificationsMessage 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 IHE PCD-07 WCTP HL7 v2 ACK Implementation Specific Receipt Acknowledgement Status Updates (delivery, read) & Replies (accept, reject)
Medical Devices as ACM AR to AM to AC for Staff NotificationsIHE 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 NotificationsOverview (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 NotificationsMessage 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 IHE PCD-07 WCTP HL7 v2 ACK Implementation Specific Receipt Acknowledgement Status Updates (delivery, read) & Replies (accept, reject)
CMMS as ACM AR to AM to AC for Staff NotificationsIHE 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 NotificationsHL7 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 questionsplease contact Manny Furst EFurst@Imp-Tech.com Please include: Name, Title, Company Email and Postal Addresses Phone(s)