1 / 14

Monroe Pattillo Practical Health Interoperability, LLC 4/8/2013

IHE PCD Interoperability Mini-Showcase at AAMI 2013 Long Beach, CA CMMS New Directions Demonstrations. Monroe Pattillo Practical Health Interoperability, LLC 4/8/2013. Scope. This is likely too broad to be demonstrated in its entirety at the AAMI event – pick & choose

eagan
Download Presentation

Monroe Pattillo Practical Health Interoperability, LLC 4/8/2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IHE PCD Interoperability Mini-Showcase at AAMI 2013 Long Beach, CACMMS New Directions Demonstrations Monroe Pattillo Practical Health Interoperability, LLC 4/8/2013

  2. Scope • This is likely too broad to be demonstrated in its entirety at the AAMI event – pick & choose • It is likely too little and too fast for proper IHE PCD WG profile development – profile development should proceed asynchronously to the AAMI New Directions demonstration event • While the individual slides should not be thought of as the actual posters for the AAMI demonstration event some of the slide content may be useful in the development of the posters • This is meant as an accelerator to meet the AAMI event demonstration deadline and as an information collective for proper IHE PCD WG profile development

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

  4. 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 • Medical Devices - Infusion Pumps, Patient Monitoring • Patient Specific Information is ignored (HIPAA) • Equipment identification is significant • Equipment location is significant

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

  6. Medical Devices to CMMS for ReportingHL7 v2 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-8 Security = Empty • MSH-9 Message Type Identification – ORU^xxx^ORU_xxx (R01 Observation, R40 Alarm, R43 Event) • MSH-10Message Control – message ID #, MSH-11 Processing ID = “P”, MSH-12 HL7 Version ID = “2.6” • MSH-13 Sequence Number – for transport error retransmission, MSH-14 Continuation Pointer = Empty • MSH-15 Accept Acknowledgement Type = “NE”, MSH-16 Application Acknowledgement Type = “AL” • MSH-17 Country Code = Empty, MSH-18 Character Set – either Empty or “ASCII” • MSH-19 Principal Language – either Empty or “EN^English^ISO639”, MSH-20 Alternate Character Set = Empty • 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

  7. Medical Devices to CMMS for ReportingHL7 v2 Acknowledgement 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 # • MSH-14,15,16,17,18,19,20,21 = Empty • 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

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

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

  10. Medical Devices as ACM AR to AM to AC for Staff NotificationsIHE PCD-04 (HL7 v2) 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-8 Security = Empty • 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-13 Sequence Number – for transport error retransmission, MSH-14 Continuation Pointer = Empty • MSH-15 Accept Acknowledgement Type = “NE”, MSH-16 Application Acknowledgement Type = “AL” • MSH-17 Country Code = Empty, MSH-18 Character Set – either Empty or “ASCII” • MSH-19 Principal Language – either Empty or “EN^English^ISO639”, MSH-20 Alternate Character Set = Empty • 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

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

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

  13. CMMS as ACM AR to AM to AC for Staff NotificationsIHE PCD-04 (HL7 v2) 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-8 Security = Empty • 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-13 Sequence Number – for transport error retransmission, MSH-14 Continuation Pointer = Empty • MSH-15 Accept Acknowledgement Type = “NE”, MSH-16 Application Acknowledgement Type = “AL” • MSH-17 Country Code = Empty, MSH-18 Character Set – either Empty or “ASCII” • MSH-19 Principal Language – either Empty or “EN^English^ISO639”, MSH-20 Alternate Character Set = Empty • 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

  14. CMMS as ACM AR to AM to AC for Staff NotificationsHL7 v2 Acknowledgement 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 applicaiton, 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 # • MSH-14,15,16,17,18,19,20,21 = Empty • 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

More Related