|
|
| Line 1: |
Line 1: |
| This Wiki page is provided for the development of the DMC White Paper. After the original WP is issued and if another is contemplated this one may be archived.
| | page not used |
| | |
| Whitepaper
| |
| Device Management and Communication (DMC)
| |
| Organization – Integrating the Healthcare Enterprise (IHE)
| |
| Domain – Patient Care Devices (PCD)
| |
| Working Group – Medical Equipment Management (MEM)
| |
| Project – Device Management and Communication (DMC)
| |
| Lead – Monroe Pattillo (IHE PCD PC co-chair) – Practical Health Interoperability, LLC
| |
| Date – 26 Jul 2013
| |
| Purpose
| |
| The purpose of the Working Group activity was to identify a means of communicating the detailed identification of the device (manufacturer, model, serial number, H/W version, and S/W version), power status (on mains or on battery), and battery detailed identification (manufacturer, model, serial number, H/W version, and S/W version), battery status (charging, available capacity or duration) of more than one battery per device and the conditions under which it is sent in an unsolicited manner (startup, upon destination actor configuration, upon self-test pass or fail, or upon error when in operation or association with a patient) .
| |
| Goals
| |
| The primary goal is communication of the detailed identification of an object in an HL7 v2.6 message. An object can be equipment, implemented in a mix of hardware and software or purely in software.
| |
| Non-Goals
| |
| Creating a normative standard for communication of detailed identification information is not a goal of the effort.
| |
| Use Cases
| |
| The following are the defined use cases for the working group effort. The means of communicating identification, status, and error observations is the same data set across the listed use cases.
| |
| • Use Case #1 – Device initialization (when the equipment or software is powered up, starts, or is reset)
| |
| • Use Case #2 – Device actor destination configuration
| |
| • Use Case #3 – Upon completion of self-test whether the result is pass or fail whether the test is self-initiated or manually initiated
| |
| • Use Case #4 – Upon detected equipment or battery error condition
| |
| Scope
| |
| For the IHE development cycle the scope is narrowed to achieve an initial end result of pre-qualification testing over the Internet either virtually using interactive systems or through the exchange of message texts with the anticipated end result being an IHE PCD New Directions demonstration at HIMSS’14 within the HIMSS IHE North America Interoperability Showcase.
| |
| Not in Scope
| |
| This effort knowingly does not handle configuration management, such as medical device profiles and modes.
| |
| Constraints
| |
| Compromises are required to achieve a New Directions demonstration in a limited time frame, without the development of new IHE profiles or actors, and with limited modification of existing equipment hardware and software implementation. Avoid the constrained implementation as being identified as normative (industry standards approved).
| |
| Deliverables
| |
| The following are the deliverables of this effort.
| |
| • This whitepaper on project definition and use of PCD messaging to communicate the information
| |
| • Sample HL7 v2.6 message content capable of being used as these observations in PCD profile messages
| |
| Definitions
| |
| These are only the definitions outside the normal IHE and IHE PCD set of definitions
| |
| CMMS – Computerized Maintenance Management System
| |
| DMIC – Device Management Information Consumer actor
| |
| DMIO – Device Management Information Observation transaction
| |
| DMIR – Device Management Information Reporter actor
| |
| References
| |
| None.
| |
| IHE Profiles
| |
| The existing listed IHE PCD profiles were utilized.
| |
| • Device to Enterprise Communication (DEC)
| |
| • Alert Communication Management (ACM)
| |
| • Point of care Infusion Verification (PIV)
| |
| • Infusion Pump Event Communication (IPEC)
| |
| IHE Profile Actors
| |
| The existing listed IHE PCD profile actors were utilized.
| |
| • Device Observation Reporter (DOR)
| |
| • Device Observation Consumer (DOC)
| |
| • Alert Reporter (AR)
| |
| • Alert Manager (AM)
| |
| • Alert Communicator (AC)
| |
| • Infusion Order Programmer (IOP)
| |
| • Infusion Order Consumer (IOC)
| |
| The following new actors were identified for use in this document and for possible inclusion in a future profile. They were defined for cross IHE Profile use in this document without identifying all possible PCD actors at each reference to the function of the actor. The names and acronyms have not been validated for IHE-wide uniqueness.
| |
| • Device Management Information Reporter (DMIR) refers to IHE actors DOR, AR, and IOC
| |
| • Device Management Information Consumer (DMIC) refers to IHE actors DOC, AM, and IOP
| |
| IHE PCD Transactions
| |
| The existing listed IHE PCD transactions were utilized.
| |
| • PCD-01 – Device Observation (DMIR to DMIC)
| |
| • PCD-03 – Infusion Order (DMIR to DMIC)
| |
| • PCD-04 – Report Alert (DMIR to DMIC)
| |
| • PCD-10 – Infusion Event (DMIR to DMIC)
| |
| The following new transactions were identified for use in this document and for possible inclusion in a future profile. It was defined for cross IHE Profile use in this document without identifying all possible PCD transactions at each reference to the function of the actor. The name and acronym have not been validated for IHE-wide uniqueness.
| |
| • Device Management Information Observation (DMIO) (DMIR to DMIC)
| |
| Security
| |
| Given that this makes use of existing PCD profiles, connectivity authentication and data transfer security are as per the PCD Technical Framework (TF) understanding between the IHE ITI and the IHE PCD domains.
| |
| Where practicable this effort makes use of IEEE 11073 prior efforts.
| |
| What we have
| |
| Existing messaging to which we can add configuration and status related information for the device, its power status, its battery identification, battery status, and test status.
| |
| What we need
| |
| We need a means of communication of the identification and status information in a manner common to all PCD messaging (OBX and other segment field and format for all the information).
| |
| Equipment and Battery Sub-Component Reporting Cardinality
| |
| A single communication of an equipment identification or status observation may include the information for multiple sub-components or batteries within a single piece of equipment.
| |
| Reporting Message Content for Observation of Equipment Identification
| |
| It is assumed that a single IEEE 11073 DIM MDS object is the source for communication of the observation information and that it can be traced back to one unique serial number identification. Therefore in a single report of equipment information there is at most one reported piece of equipment per message.
| |
|
| |
| Protocol – HL7 version 2.6
| |
| | |
| Definitions and requirements – Definition and requirements indications for common HL7 message fields and components are documented in the HL7 standard, the shared IHE PCD Technical Framework, or a specifically utilized IHE PCD Profile are not listed here. What are listed here are the fields and components specific to equipment and status reporting.
| |
| | |
| Segment – OBX
| |
| | |
| The HL7 Observation segment shall be the segment used to report the identification and status of a piece of equipment (a device). There shall be at most one piece of equipment observation per piece of equipment for which the identification or status observation is being reported. As there can be multiple observations (OBR collections of OBX segments) per HL7 message there can be multiple equipment identification and status reports per message, but they must be under individual OBR groupings.
| |
| Table 1 - HL7 OBX Segment Attribute Table for Equipment Identification or Status Observation
| |
| SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
| |
| 2 2 ID C 0125 00570 Value Type
| |
| 3 250 CWE R 00571 Observation Identifier
| |
| 4 20 ST RE 00572 Observation Sub-ID
| |
| 5 99999 Varies C Y/2 00573 Observation Value
| |
| 11 1 ID R 0085 00579 Observation Result Status
| |
| 14 26 TS CE Observation Date/Time
| |
| 18 22 EI CE Y 01479 Equipment Instance Identifier
| |
| | |
| OBX-2 Value Type
| |
|
| |
| Table 3 - HL7 Sub-Component Table - EI - Entity Identifier
| |
| SEQ LEN DT OPT TBL# SUBCOMPONENT NAME
| |
| 1 199 ST CWE Entity Identifier
| |
| 2 20 IS CWE 0363 Namespace ID
| |
| 3 199 ST CWE Universal ID
| |
| 4 6 ID CWE 0301 Universal ID Type
| |
| | |
| xxxx
| |
| Sub-component 1 Entity Identifier (ST)
| |
| xxxx
| |
| Sub-component 2 Namespace ID (IS)
| |
| xxxx
| |
| Sub-component 3 Universal ID (ST)
| |
| This sub-component contains a world unique value that identifies the producer of the Namespace ID value. In the world of IHE PCD this would be the EUI-64 value that identifies the equipment or software vendor.
| |
| For more information on world unique identification by EUI-64 value please see the IHE PCD Technical Framework.
| |
| Sub-component 4 Universal ID Type (ID)
| |
| This sub-component contains the type of the value in sub-component 3 Universal ID. At this time the use of EUI-64 cataloged values is strongly recommended by the IHE PCD Technical Framework and so the value of this sub-component would be EUI-64.
| |
| OBX-3 Observation Identifier (CWE)
| |
| This field contains the MDC code identifying the identification or status observation as for a piece of equipment.
| |
| The syntax template is
| |
| <MDC code>,<MDC string>,MDC
| |
| The field value for XXXX observation for a piece of equipment is
| |
| 0,MDC_ATTR_XXXX_XXXX_XXXX,MDC
| |
| | |
| OBX-4 Observation Sub-ID (ST)
| |
| The content of this field is as per the IHE PCD Technical Framework and is typically referred to as the containment hierarchy dot notation. It is used to identify the hierarchical source of an observation value within a medical device system.
| |
| OBX-5 Observation Value (PL)
| |
| This field contains the value of the observed equipment identification or status.
| |
| Syntax Template and Value Examples
| |
| OBX-5 Value for xxxx observations.
| |
| Syntax
| |
| <xxxx>,<xxxx>,<xxxx>
| |
| Example
| |
| xxxx,xxxx,xxxx
| |
| OBX-11 Observation Result Status (ID)
| |
| The conveyed observation value is not subject to later review or correction. If the value changes it is conveyed through additional observation reports. The value of this field is therefore always indicated as Final using an ID of F.
| |
| OBX-14 Observation Date/Time (DTM)
| |
| The field contains the date and time stamp in 24-hour clock notation as of the time of the hardware or software capture of the equipment or status information for conveying as a report.
| |
| The field syntax template for the data type is
| |
| YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]
| |
| A value example for 12/31/2013 at 10:15:27 PM GMT would be
| |
| 20131231221527-0000
| |
| For more information on the HL7 DTM Date/Time data format see HL7 2.6 2.A.22 DTM – date/time.
| |
| OBX-18 Equipment Instance Identifier (EI)
| |
| The value of this field identifies the equipment for which the identification or status is being reported.
| |
| HL7 Message Examples
| |
| MSH
| |
| PID
| |
| PV1
| |
| OBR
| |
| OBX
| |
| OBX
| |
| | |
| Futures
| |
| In the future it is possible to develop profile(s) for request/response interactions (including possible new actors) and adding data for NIST verification (RTMMS, MDC/11073, HL7, etc.).
| |
| Future efforts are left to evaluate the use of standards other than EUI-64 for identification of equipment.
| |