IHE PCD Interoperability Mini-Showcase at AAMI 2013 Long Beach, CA CMMS New Directions Demonstrations Monroe Pattillo Practical Health Interoperability,

Slides:



Advertisements
Similar presentations
IHE An Introduction for Source Atlantic. IHE PCD: Simplify Specs!
Advertisements

PCD Infusion Pump WG Containment / Mode / Status Discussion (rev. 2) Updated: Monday.
Integrating the Healthcare Enterprise (IHE) Patient Care Devices Domain (PCD) Alarm Communication Management (ACM) 2010 Change Request Efforts IHE PCD.
Integrating the Healthcare Enterprise (IHE) Patient Care Devices Domain (PCD) Alarm Communication Management (ACM) IHE PCD 2011 Fall Face-to-Face Kansas.
Alarm Communication Management
Philips PCCI EPIS, Boca Raton, FL, USA IHE Patient Care Devices Domain
PCD Infusion Pump WG Containment / Mode / Status Discussion (rev. 3) Updated: Wednesday.
March 7, 2011 COMPARATIVE ANALYSIS HL7 V2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR (US REALM)
Integrating the Healthcare Enterprise (IHE) Patient Care Devices Domain (PCD) Alarm Communication Management (ACM) Requirements for AM – AC Interoperability.
IHE PCD MEM-DMC CMMS & RTLS Vendor Perspective
IHE Integrating the Healthcare Enterprise PATIENT CARE DEVICE Overview of PCD DEC Profile Presented by Monroe Pattillo – PHI, LLC (PCD PC)
S&I Framework Testing HL7 V2 Lab Results Interface and RI Pilot Robert Snelick National Institute of Standards and Technology June 23 rd, 2011 Contact:
FHIR Without the smoke. FHIR Experience In the last 4 weeks, we have been busy. We … Prototyped a Device Data Aggregator/Reporter using FHIR resources.
Us Case 5 Delivery Event Requiring Newborn Monitoring and Alarm Management in NICU Care Theme: Maternal and Newborn Health Use Case 2 Interoperability.
1 IHE PCD F2F IHE PCD Quick Updates IHE PCD Face-to-Face, Cleveland, Ohio Tuesday Q1 and Q2, April 1, 2014 Paul Schluter, GE Healthcare Q1:
CCNA – Network Fundamentals
Result Status Relationships
Cross-Jurisdictional Immunization Data Exchange Project Updated 4/29/14.
Recommendations from the EHR-S Functional Requirements IG: Lab Results Interface Error Handling 7/10/2014.
EHR-S Functional Requirements IG: Lab Results Interface Error Handling 7/7/2014.
1 Cardinality Specification and Testing Recommendations LOI and LRI MU Certification September 9 th, 2013 Draft
Error Checking continued. Network Layers in Action Each layer in the OSI Model will add header information that pertains to that specific protocol. On.
Sponsored by. Wouldn’t it be great if all your equipment, software and devices worked together, right out of the box? thinks so, too.
LRI Validation Suite Meeting November 1st, Agenda Review of LIS Test Plan Template CLIA Testing EHR testing (Juror Document)—Inspection Testing.
2013 PCD Domain Update Monroe Pattillo Practical Health Interoperability, LLC IHE PCD Planning Committee Co-Chair.
Primary Goal: To demonstrate the ability to provide efficient and accurate transitional care, from the hospital OR suite, to the radiology department and.
DICOM WG13 22/04/2009 Update, IHE-J Endoscopy Committee Activity 22/04/2009 IHE Japan Endoscopy Committee.
The University of New Hampshire InterOperability Laboratory Serial ATA (SATA) Protocol Chapter 10 – Transport Layer.
Software and Systems Division “IHE-PCD F2F Meeting” (NIST Testing Tool Status) National Institute of Standards and Technology (NIST) John Garguilo, Sandra.
February 7-10, 2005IHE Interoperability Workshop 1 Established Profile for connectathon 2005: Laboratory Scheduled WorkFlow Francois Macary GWI Medica.
Benefits of IHE PCD Standards-Based Interoperability June 1, 2014 | 8:30 AM Jeff McGeath – Iatric Systems, Inc. John Garguilo – NIST Monroe Pattillo –
Sandy Lum University of Toronto Candidate MHSc in Clinical Engineering The Totally Integrated Electronic Patient Record (EPR)
Toolkit for Planning an EHR-based Surveillance Program | HL7 Version 2 Messages An Introduction.
Invitation to Send, Interface, and/or Receive DMC and LS Data by Manny Furst, Improvement Technologies and Monroe Pattillo, Managing Member, Practical.
CUG Request from 2010 and 2011 User Group Meetings Cortex User Group Meeting Portland, OR – 2012.
Sponsored by. Wouldn’t it be great if all your equipment, software and devices worked together, right out of the box? thinks so, too.
Us Case 5 ICU Event with Pharmacy and Pt Monitoring and Follow-up Care by PCP Care Theme: Transitions of Care, Medical Device Integration Use Case 15 Interoperability.
Internet Protocols (chapter 18) CSE 3213 Fall 2011.
Sponsored by. Wouldn’t it be great if all your equipment, software and devices worked together, right out of the box? thinks so, too.
IHE PCD MEM-DMC CMMS & RTLS User Perspective Monroe Pattillo Practical Health Interoperability, LLC 6/21/2013.
IHE Workshop – June 2007What IHE Delivers 1 Nicholas Steblay Boston Scientific Implantable Device Cardiac Observations (IDCO) Profile.
Feb , 2005IHE Europe Workshop 1 Integrating the Healthcare Enterprise – Radiology – Introduction to the New IHE Integration Profiles: Dr. Nikolaus.
Integrating the Healthcare Enterprise (IHE) Patient Care Devices Domain (PCD) Alarm Communication Management (ACM) Opportunities Manny Furst, Technical.
EHR-S Functional Requirements IG: Lab Results Interface Error Handling 6/30/2014.
ACCE Clinical Engineering Symposium Overview of IHE PCD Exhibit at AAMI Y2010.
PCD User Handbook 2010 Purpose The Handbook is designed to help healthcare professionals implement IHE on a new clinical system purchase or upgrade an.
IHE Workshop – June 2006What IHE Delivers 1 Nicholas Steblay Boston Scientific Implantable Device Cardiac Observations (IDCO) Profile.
20/11/2009 DICOM WG13 Atsushi Amano Medical Imaging Systems Committee Japanese Association of Healthcare Information Systems Industry (JAHIS) 1 JAHIS /
IHE Cardiology Displayable Report (DRPT) Profile Harry Solomon, Tom Dolan February 16, 2005 Rev 0.3.
Cardinality Behaviors and MSH Overview November 7, 2013.
Case Study: HL7 Conformance in VA Imaging Mike Henderson Principal Consultant Eastern Informatics, Inc.
IHE PCD 2016 Spring F2F Profile PC and TC Updates ACM, MEMDMC, MEMLS
Practical Health Interoperability, LLC IHE Patient Care Devices Domain
How is Data Quality Defined?
IHE PCD 2015 Fall F2F Profile PC and TC Updates ACM, MEMDMC, MEMLS
Care Coordination and Interoperable Health IT Systems
IHE PCD F2F San Diego, America’s Finest City
Point-of-Care Identity Management
IHE PCD 2016 Fall F2F Profile PC and TC Updates ACM, MEM: DMC, LS, RDC
Philips PCCI EPIS, Boca Raton, FL, USA IHE Patient Care Devices Domain
Wouldn’t it be great if all your equipment, software and devices worked together, right out of the box? thinks so, too.
Integrating the Healthcare Enterprise (IHE) Patient Care Device Domain (PCD) FDA UDI Considerations IHE PCD 2013 Fall F2F, Boca Raton, FL Monroe Pattillo.
IHE Eye Care “Charge Posting”
HL7 Messages per ACM, ECM and WCM profiles Device Specific graphics
IHE PCD 2015 Spring F2F Profile Updates ACM, MEMDMC, MEMLS
ACM Across Domains and the Enterprise
What is Data Quality? Accurate Data Complete Data Timely Data
Anonymized HL7 message, which would be sent from an LIS to an HIS
Error Checking continued
Presentation transcript:

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

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 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 Medical Device CMMS Report HL7 v2 ORU^ R01, R40, R43 HL7 v2 ACK Alarm or Event Receipt Acknowledgement

Medical Devices to CMMS for Reporting HL7 v2 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-8 Security = Empty MSH-9 Message Type Identification – ORU^xxx^ORU_xxx (R01 Observation, R40 Alarm, R43 Event) 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^ ^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 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 # 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

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 Medical Device as ACM AR ACM AM ACM AC IHE PCD-07 WCTP Implementation Specific Alarm or Event Receipt Acknowledgement IHE PCD-04 HL7 v2 ORU^R40 HL7 v2 ACK IHE PCD-06 WCTP Disseminate Notification Status Updates (delivery, read) & Replies (accept, reject)

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

CMMS as ACM AR to AM to AC for Staff Notifications IHE 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^ ^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 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