Difference between revisions of "PCD MEM 2012-08-06 Webex"

From IHE Wiki
Jump to navigation Jump to search
m (fmt)
(new)
Line 1: Line 1:
−
<p><strong>IHE PCD MEM – Medical  Device IT Management Working Group</strong><br />
+
'''Minutes of PCD MEM meeting 2012-08-06'''
−
  This document summarizes the discussion during the <u>2012-07-12</u> and <u>2012-07-18</u> 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. <br />
 
−
  A total of 15 people from industry and provider  organizations participated and provided input during the two calls.<br />
 
−
  Notes compiled by Dan Trainor (Philips), John Rhoads  (Philips), Axe Wirth (Symantec).<br />
 
−
  This document summarizes the discussion on the call; it is  not intended to reflect any final decisions regarding priority or content of  the project.</p>
 
−
<p><strong>Summary:</strong><br />
 
−
  General Discussion:</p>
 
−
<ul>
 
−
  <li>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).<br />
 
−
    Details see here:
 
  
−
http://www.medicalimaging.org/policy-and-positions/joint-security-and-privacy-committee-2/
+
Reference material:
  
  
−
</li>
+
 
−
  <li>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. </li>
+
1. Reviewed submission proposal for AAMI 2013 conference. Axel Wirth will send to MEM core team and PCD leadership for review.
−
  <li>Emphasize relevance of healthcare compliance issues  – e.g. violation of FDA regulations is a criminal offense.</li>
+
 
−
  <li>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?</li>
+
2. John Rhoads will update MEM Wiki to include minutes from last few calls as well as summary notes from MEM prioritization calls; send Wiki link to MEM distribution list.
−
</ul>
+
 
−
<p>Definition and Architecture</p>
+
3. Reviewed outcome of prioritization calls (see summary notes in separate document) and decided to proceed as follows:
−
<ul>
+
 
−
  <li>Some corrections  – Masimo should be  Maximo, better examples may be MediMizer or St.  Croix</li>
+
- Team to start working on strategic, high-level topics, i.e. the ones which would affect the other sections: Architecture, Compliance, Risk Management, etc.
−
  <li>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.</li>
+
 
−
  <li>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).</li>
+
- Following are defined as high priority and it is suggested that we start to look for volunteers to start tackling those: a) patch management, b) configuration management, c) maintenance management (those 3 fall under the umbrella of lifecycle or interdependency management), d) cyber security. Axel volunteered for the security topic, others to be discussed.
−
  <li>Many challenges of joining together  functionality from IT and Clinical Engineering equipment management databases.</li>
+
 
−
  <ul>
+
- The topics could be assigned to individuals or teams of two and should initially focus on researching the topic (status quo and sources) and outlining the section. After review and alignment with the other sections we will proceed to drafting.
−
    <li>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.</li>
+
 
−
    <li>Some CMMS systems offer separate modules for CE  and IT, with selective DB views crossing the CE-IT boundary.</li>
+
- Specific considerations will apply to the following: wireless devices; management systems (CMDB, CMMS, especially in consideration of in use legacy systems); and PHI-based risk management.
−
    <li>Much interest in unifying but existing legacy  systems may have a particular strength (e.g. &quot;Heat&quot; system strong on  dispatching) but be weak elsewhere.</li>
 
−
    <li>This could be a potential project – could this  be a profile we may want to create and address the requirements around this  &lsquo;new thing&rsquo;.</li>
 
−
  </ul>
 
−
</ul>
 
−
<p>Risk Management </p>
 
−
<ul>
 
−
  <li>Clarify difference between generic VLAN  architecture and the specific MDPP (VLAN-based) architecture developed by the  VA specific for their medical device networks).</li>
 
−
  <li>The two lines between &ldquo;patch level&rdquo; and &ldquo;resources&rdquo;  don&rsquo;t make sense to some.  Could be  categorized better.   More structure  would benefit the understanding.</li>
 
−
  <li>Patch Level is HIGH Priority.  </li>
 
−
  <li>NEMA and SPC (Security &amp; 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.</li>
 
−
  <li>Today, providers develop their own capabilities  lists.</li>
 
−
  <li>Important step in risk management is  identification of which devices do and do not have PHI and whether the PHI is  persistent.</li>
 
−
  <li>Procurement process – Provider RFP requirements,  vendor IT features.</li>
 
−
  <li>Risk Assessment approach – do we need separation  of Risk, Threat and Vulnerability for this document?</li>
 
−
  <li>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.</li>
 
−
  <li>Emphasize relationship between general best  practices and risk.</li>
 
−
</ul>
 
−
<p>CE/IT Management<br />
 
−
  Life Cycle  Management</p>
 
−
<ul>
 
−
  <li>Administrative actions – LOW priority or even OUT  OF SCOPE</li>
 
−
  <li>Once you have Automatic Configuration, repair  looks like mostly policy driven.</li>
 
−
  <li>Importance of revision testing in-house before  deploying. </li>
 
−
  <li>Change management where one system affects  another, for example, patient monitor and electronic medical record (EMR).</li>
 
−
  <li>Thorough checking of software version  compatibility across systems with multiple interacting subsystems, or  &quot;systems of systems&quot; with independently managed components  potentially from different vendors.</li>
 
−
  <li>Importance of suppressing unwanted patch  installation by mass computer upgrades by IT: there needs to be a &quot;safe  medical zone&quot; protected from this happening since such upgrades can cause  life-critical systems to malfunction</li>
 
−
  <li>Is there the need for an IHE profile to define  auto-configuration, configuration assessment, or performance test, e.g. alarms,  thresholds?</li>
 
−
</ul>
 
−
<p>Patch Management</p>
 
−
<ul>
 
−
  <li>Higher priority than Life Cycle, some see it as  most important.</li>
 
−
  <li>Many problems around patch and version upgrade  management.</li>
 
−
  <li>Clear up the meaning of version to install / interdependencies  / preconditions – maybe call this &ldquo;Interdependency management&rdquo;; i.e. sets of  Software configurations that are approved, there may be several sets, but only  configuration in line with one set is allowed.</li>
 
−
  <li>Approved device configuration may conflict with  IT policy (e.g. device may require lower patch level).</li>
 
−
</ul>
 
−
<p>Auto Configuration</p>
 
−
<ul>
 
−
  <li>Add new use case: device swap (e.g. spare or  loaner)</li>
 
−
  <li>Is care-setting-dependent threshold relevant?  This is common and needs to be addressed. E.g. device location or use case  specific.</li>
 
−
  <li>Diagnostic access – e.g. motor currents,  thresholds – to do predictive maintained -   maybe move into log management section?</li>
 
−
  <li>This section does not include antivirus version  levels, signature files. This is addressed in a later section, but maybe needs  to be references here.</li>
 
−
  <li>Suggestion to add related security  configuration. E.g. Firewall version or status?   - Configuration, or Event reporting.</li>
 
−
  <li>Comment on Port Status – part of security?</li>
 
−
  <li>Be aware of unintentional configuration changes,  e.g. device sent for repair or loaner introduced into environment. Is this a  separate &ldquo;swap&rdquo; use case?</li>
 
−
</ul>
 
−
<p>Key Management<br />
 
−
  Authentication, Encryption</p>
 
−
<ul>
 
−
  <li>Password management should be part of this,  similar issues as with keys, often used together.</li>
 
−
</ul>
 
−
<p>Device  Authentication</p>
 
−
<ul>
 
−
  <li>Authentication, see previous note about  password.</li>
 
−
  <li>Device authentication – mention it, but don&rsquo;t  spend time on it – this is not where the issue is.</li>
 
−
</ul>
 
−
<p>Event Communication</p>
 
−
<ul>
 
−
  <li>Monitoring and Logging look at existing  standards, e.g ATNA profile.</li>
 
−
</ul>
 
−
<p>Priority Check: </p>
 
−
<ul>
 
−
  <li>Patch Management </li>
 
−
  <li>Auto Configuration</li>
 
−
</ul>
 
−
<ul>
 
−
  <li>Hard to know which is higher…</li>
 
−
  <li>Security is reported by many as a pain point</li>
 
−
  <li>Automatic configuration to provide provider  swap.  Critical but needed for this  group?</li>
 
−
  <li>Managing batteries – big deal – important.</li>
 
−
  <li>Automatic calibration of diagnostic quality  parameters, for example as done with displays under DICOM</li>
 
−
  <li>Asset Tracking LOW Priority – Small potential.</li>
 
−
</ul>
 
−
<p>&nbsp;</p>
 

Revision as of 14:04, 7 August 2012

Minutes of PCD MEM meeting 2012-08-06

Reference material:


1. Reviewed submission proposal for AAMI 2013 conference. Axel Wirth will send to MEM core team and PCD leadership for review.

2. John Rhoads will update MEM Wiki to include minutes from last few calls as well as summary notes from MEM prioritization calls; send Wiki link to MEM distribution list.

3. Reviewed outcome of prioritization calls (see summary notes in separate document) and decided to proceed as follows:

- Team to start working on strategic, high-level topics, i.e. the ones which would affect the other sections: Architecture, Compliance, Risk Management, etc.

- Following are defined as high priority and it is suggested that we start to look for volunteers to start tackling those: a) patch management, b) configuration management, c) maintenance management (those 3 fall under the umbrella of lifecycle or interdependency management), d) cyber security. Axel volunteered for the security topic, others to be discussed.

- The topics could be assigned to individuals or teams of two and should initially focus on researching the topic (status quo and sources) and outlining the section. After review and alignment with the other sections we will proceed to drafting.

- Specific considerations will apply to the following: wireless devices; management systems (CMDB, CMMS, especially in consideration of in use legacy systems); and PHI-based risk management.

Retrieved from "http://wiki.ihe.net/index.php?title=PCD_MEM_2012-08-06_Webex&oldid=62235"