PCD Profile MEM Proposal Brief

From IHE Wiki
Jump to navigation Jump to search

1. Proposed Workitem: Medical Equipment Management

  • Proposal Editor: Todd Cooper, Manny Furst
  • Editor: Todd Cooper (temp)
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Patient Care Device

2. The Problem

Most health care enterprises 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 determining 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).

3. Key Use Cases

3.1 Device Configuration Management

  • 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., PICU vs. ... Role Based configurations)

3.2 Location Tracking Services

  • 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

  • On A/C or D/C?
  • Charge Level / Estimated battery life
  • Charging / Discharging history
  • Battery type and installation date

3.4 Operational Status Monitoring

  • In use? Usage history?
  • Alarm - active, history, ...

3.5 Periodic Maintenance

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

3.6 Software Patch Management

  • Pending software version / "patch"

3.7 Event Log Management

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

3.8 Remote-Maintenance Service Profile

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

4. Standards & Systems

HL7 (v2.x & v3)

ISO/IEEE 11073-10201 Information Model

  • This includes an EventLog object w/ associated services (use case 3.7 above)


5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>
<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>
<What are some of the risks or open issues to be addressed?>
  1. Base Profile vs. Multiple Options or Multiple Profiles? Looking at the use cases listed above, clearly there are many that could be viewed as standalone profiles. With this scheme, location services would be MEM-RTLS. Is this the way we want to go with this?