PCD MEM Summary of July 2012 Provider Meetings

IHE PCD MEM – Medical Device IT Management Working Group
This document summarizes the discussion during the 2012-07-12 and 2012-07-18 public status review and prioritization calls. In addition we are including the highlight form a few one-on-one calls with interested parties who were not able to attend the calls.
A total of 15 people from industry and provider organizations participated and provided input during the two calls.
Notes compiled by Dan Trainor (Philips), John Rhoads (Philips), Axe Wirth (Symantec).
This document summarizes the discussion on the call; it is not intended to reflect any final decisions regarding priority or content of the project.

Summary:
General Discussion:

• As we move forward we need to be conscious of duplications and utilize similar efforts provided through other standards or organizations, e.g. DICOM, NEMA, COCIR (European Coordination Committee of the Radiological, Electromedical and Healthcare IT Industry), JIRA (Japan Medical Imaging and Radiological Systems Industries Association).
  Details see here: http://www.medicalimaging.org/policy-and-positions/joint-security-and-privacy-committee-2/
• Security and Privacy – Differentiate between mechanisms and policy. For example, SPC has whitepapers on mechanics: patching, certificate management, patching, and privacy rules. Asset tracking good example of Policies and Standards.
• Emphasize relevance of healthcare compliance issues – e.g. violation of FDA regulations is a criminal offense.
• What can be done in smaller institutions with lesser capability for control and testing? Different than large providers with high degree of complexity, but have capability. How can we scale our architecture to address both ends of the spectrum? Example could be development of standard contracts, key policies – is this possible here, too?

Definition and Architecture

• Some corrections  – Masimo should be  Maximo, better examples may be MediMizer or St. Croix
• Wireless has unique architecture requirements, may warrant a separate section to cover specific considerations. This will not be a spectrum discussion, but discuss what is unique to a wireless medical device infrastructure. Existing work in ISO, IEEE, or similar? E.g. ISO TC215 WG 7.
• Legacy systems – could warrant discussion of legacy Operating Systems (initially, this was intended to discuss legacy CMMS, but this point is well taken as a broader discussion of the legacy topic could be beneficial).
• Many challenges of joining together functionality from IT and Clinical Engineering equipment management databases.
• IT databases more automated, readily gather information about IT equipment but typically lack depth of information required for medical equipment and may not be easily extended for it.
• Some CMMS systems offer separate modules for CE and IT, with selective DB views crossing the CE-IT boundary.
• Much interest in unifying but existing legacy systems may have a particular strength (e.g. "Heat" system strong on dispatching) but be weak elsewhere.
• This could be a potential project – could this be a profile we may want to create and address the requirements around this ‘new thing’.

Risk Management

• Clarify difference between generic VLAN architecture and the specific MDPP (VLAN-based) architecture developed by the VA specific for their medical device networks).
• The two lines between “patch level” and “resources” don’t make sense to some.  Could be categorized better.   More structure would benefit the understanding.
• Patch Level is HIGH Priority. 
• NEMA and SPC (Security & Privacy Committee) are working 80001  - SPC writing an annex for how to describe your products Security capabilities. Another reference could be MDS2, update is in the works.
• Today, providers develop their own capabilities lists.
• Important step in risk management is identification of which devices do and do not have PHI and whether the PHI is persistent.
• Procurement process – Provider RFP requirements, vendor IT features.
• Risk Assessment approach – do we need separation of Risk, Threat and Vulnerability for this document?
• In-house risk management is very important, but vendors often do not make sufficient detailed information for this to be done well, particularly in the area of residual risk, where vendors may be hesitant to be forthright for competitive or legal reasons.
• Emphasize relationship between general best practices and risk.

CE/IT Management
Life Cycle Management

• Administrative actions – LOW priority or even OUT OF SCOPE
• Once you have Automatic Configuration, repair looks like mostly policy driven.
• Importance of revision testing in-house before deploying.
• Change management where one system affects another, for example, patient monitor and electronic medical record (EMR).
• Thorough checking of software version compatibility across systems with multiple interacting subsystems, or "systems of systems" with independently managed components potentially from different vendors.
• Importance of suppressing unwanted patch installation by mass computer upgrades by IT: there needs to be a "safe medical zone" protected from this happening since such upgrades can cause life-critical systems to malfunction
• Is there the need for an IHE profile to define auto-configuration, configuration assessment, or performance test, e.g. alarms, thresholds?

Patch Management

• Higher priority than Life Cycle, some see it as most important.
• Many problems around patch and version upgrade management.
• Clear up the meaning of version to install / interdependencies / preconditions – maybe call this “Interdependency management”; i.e. sets of Software configurations that are approved, there may be several sets, but only configuration in line with one set is allowed.
• Approved device configuration may conflict with IT policy (e.g. device may require lower patch level).

Auto Configuration

• Add new use case: device swap (e.g. spare or loaner)
• Is care-setting-dependent threshold relevant? This is common and needs to be addressed. E.g. device location or use case specific.
• Diagnostic access – e.g. motor currents, thresholds – to do predictive maintained -  maybe move into log management section?
• This section does not include antivirus version levels, signature files. This is addressed in a later section, but maybe needs to be references here.
• Suggestion to add related security configuration. E.g. Firewall version or status?  - Configuration, or Event reporting.
• Comment on Port Status – part of security?
• Be aware of unintentional configuration changes, e.g. device sent for repair or loaner introduced into environment. Is this a separate “swap” use case?

Key Management
Authentication, Encryption

• Password management should be part of this, similar issues as with keys, often used together.

Device Authentication

• Authentication, see previous note about password.
• Device authentication – mention it, but don’t spend time on it – this is not where the issue is.

Event Communication

• Monitoring and Logging look at existing standards, e.g ATNA profile.

Priority Check:

• Patch Management
• Auto Configuration

• Hard to know which is higher…
• Security is reported by many as a pain point
• Automatic configuration to provide provider swap.  Critical but needed for this group?
• Managing batteries – big deal – important.
• Automatic calibration of diagnostic quality parameters, for example as done with displays under DICOM
• Asset Tracking LOW Priority – Small potential.

 

PCD Home