PCD Detailed Profile Proposal 2009 MEM WP

Proposed Workitem: White Paper - Medical Equipment Management (MEM)

• Proposal Editor: Todd Cooper, Manny Furst
• Editor: Steve Merritt
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: PCD

NOTE: This white paper proposal is based on the brief profile proposal: PCD_Brief_Profile_Proposal_2008_MEM_WP

Introduction

Overview (problem statement)

• This white paper discusses the general topic of MEM, focusing in on key activity areas and problems, identifying the use cases and requirements that should be addressed in future PCD profile development.
• Most healthcare delivery organizations (HDO) must manage 10,000's of medical devices representing 1,000's of make/model combinations. Managing these devices runs from simply having a consistent unique identification method, to determination of the device's location, operational status, battery level and charging profile, software / hardware configuration (incl. serial numbers), pending upgrades or software updates, etc.
• The problem is that there are no common standards-based technologies for supporting these device management & maintenance activies. These technology profiles should address both the actors and transactions that are required to perform management activites, as well as the basic content that is needed to perform specific tasks (e.g., device identification, or representation of battery charge status).

Scope

• Scope

• Limited to the management of regulated medical devices
• Stakeholders: Clinical Engineers, CMMS vendors, medical device vendors, SDO's

• Objective

• Call attention to the need for a framework to create a standardized management capability
• Detail key use cases that show existing problems that need to be solved
• Propose technical solutions
• Evaluate feasible implementation timelines for a MEM profile
• Identify required coordination efforts between SDO's, implementators, other IHE domains or profiles

Use Case Organization

• Current problem is stated
• Proposed future state with interoperability
• Required topics or data elements to solve the problem

Key Use Case

Device Configuration Management

• Increasing medical device complexity has led to an increasing number of recalls. The absence of Unique Device Identification (UDI) means hospitals often must use manual and imprecise systems to find recalled devices. Implementing UDI in combination with device tracking would increase patient safety and decrease the work load and cost to address recalls.

• Medical Devices often require reconfiguration when used in different clinical context. When an IV pump is used in the NICU it may require different libraries, different alarm settings, and control parameters than when the same IV pump is used in the OR. Such devices should have user-configurable profiles that are aware of their use-context.

Topics

• Unique Device Identification (EUI-64, GS1, GMDN, GHTF/FDA UDI, etc.)
• Hardware Configuration (serial numbers, etc.)
• Software Configuration
• Sub-component Configuration
• Discovery - What devices exist?
• User Configuration Profiles (e.g., Peds ICU vs. ... Role Based configurations)

Location Tracking Services

• Finding Patient Care Devices when and where clinicians need them is crucial to patient care. Tracking devices would enable usage modeling, provide the ability for clinicians or service personnel to find equipment when they need it, and provide alarms when devices cross boundaries

Topics

• Where is the device
• Where has it been (location tracking / trending)
• Notifications or alarms when it crosses a boundary or is out of defined areas

Battery Management

• Mobile Patient Care Devices are often submitted for service due to batty problems, are put on regular maintenance schedules for periodic battery replacement, or batteries fail prematurely interrupting patient care. Patient Care Devices using batteries should send periodic power status messages containing information such as current battery charge level, battery type and installation date, estimated battery life remaining, and current power source status (i.e. currently running on A/C or D/C).

• On A/C or D/C?
• Charge level (% of full)/Est. operating time left.
• Charging / Discharging history
• Battery type and installation date
• Est. battery life (if manuf. can use charge/discharge data to est. hours or days remaining)

Operational Status Monitoring and Maintanence

• Current state: ventilators are PM'd every 6 months and as needed because its not necessarily known when a PM is required. This sometimes comes too late after a problem occurs or too soon when maintenance is not really needed resulting in extra cost to the organization. Future state: the ventilator sends periodic data back to a CMMS reporting device usage parameters, event logs, and other information required to predict preventative maintenance. The system would have also have the ability to analyze the data streams to predict calibration problems. The CMMS generates work orders automatically based on a defined algorithm of the actual use and event logs. The ventilator also sends aperiodic data as it occurs of equipment technical alarm conditions such as loss of A/C power loss, low battery, loss of gas.

Topics

• In use? Usage history?
• Alarm - which are active, what are trigger levels, if device is active, has the alarm been off for an extended period; active meaning signals are received thus the device is on the patient, etc.
• Day/time of last self check and its result, date/time of last error message sent to maintainer.
• Periodic Maintanence

• Last P/M
• Next P/M Schedule (predictive ... based on device history / status?)
• Last repair time/date.
• Event log review
• Regulatory status (e.g., eMAR's, recalls, etc.)
• Warranty periods / licensing / ...

Patch Management

• Many Patient Care Devices integrate off-the-shelf (OTS) software such as Linux/Windows/Oracle. The management of devices containing OTS requires periodic installation of patches. Many manufacturers provide field-installable software updates to fix bugs or address recalls. Devices should have the ability to report current software revisions and dates, the source of software, installed patches.

Topics

• Pending software version / "patch"
• Patch history reporting w/ version, date, version, company source, etc.
• Patch history query

Event Log Management

• When devices fail it’s often a cumbersome process to determine root cause of failures. Devices should have the ability to send periodic or aperiodic history to a repository. This would include device event logs, change logs, alarm events, power/boot-up statistics. There should be a distinction of severity levels of alarm status such as critical calibration errors versus warnings such poor power quality. The reporting should be user configurable such as only report warnings ASAP versus send all events once per day.

Topics

• Processing of event logs, which could include key strokes, alarm events, power on/off cycles, etc.
• Archiving event logs

Remote-Maintenance Service Profile

• Would be pretty broad in its focus, include security - might become a separate profile

Risk Management Support

• IEC 80001 requires a life cycle risk management process for networked medical devices that includes not only pre-deployment risk analysis (incl. network configuration documentation) but also dynamic / periodic assessment of network performance and functioning of risk controls. Any set of MEM profiles should provide the information and services needed to support all 80001 activities and documentation artifacts (e.g., that would become part of the HDO's risk management file).

Topics

• Risk analysis
• Risk evaluation
• Verification of risk control measures
• Residual risks

5. Coordination

• Coordination with other IHE profile development activities

• PCD Profiles: DEC & DPI & TFv3
• ITI Profiles
• Other Domains

6. Roadmap

• Proposed profile(s) or supplements to be developed
• Phasing of profile or supplement development