PCD Brief Profile Proposal 2008 MEM WP

From IHE Wiki
Revision as of 09:09, 11 December 2008 by Stevemerritt (talk | contribs) (→‎3.4.1)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

1. 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 previous profile proposal: PCD_Profile_MEM_Proposal_Brief

2. The Problem

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

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.

3. Key Use Case

3.1 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.
  • 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)

3.2 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
  • Where is the device
  • Where has it been (location tracking / trending)
  • Notification when it crosses a boundary or is out of defined areas

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

3.4 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.
  • 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 / ...

3.5 Software 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.
  • Pending software version / "patch"
  • Patch history w/ version, date, version, company source, etc.

3.6 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.
  • Processing of event logs, which could include key strokes, alarm events, power on/off cycles, etc.
  • Archiving event logs

3.7 Remote-Maintenance Service Profile

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

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

4. Proposed Topics / Outline

Note: This is highly subject to change!

  • Overview (problem statement)
  • Scope (incl. WP objectives)
  • Use Case Organization
  • Document Organization
Coordination with Other IHE Profiles
  • PCD Profiles: DEC & DPI & TFv3
  • ITI Profiles
  • Other Domains
Device Configuration Management
  • Software and hardware configuration information
  • Software upgrade management
Device Location & Status Tracking
  • Location tracking services
  • Battery Management
  • Usage / Activity Tracking
Remote Device Maintenance
  • Event Log Retrieval
  • Forensic Investigation Support
  • Remote Service Support
Risk Management
  • Support for IEC 80001 Risk Management File components
MEM Profile Roadmap
  • Proposed profiles to be developed
  • Phasing of profile development
  • Coordination with other IHE profile development activities

5. Discussion

  • RTLS - is this a profile that should be addressed within PCD or should this be joint with other IHE working groups?