Software in Medical Devices, by MD101 Consulting - Tag - CybersecurityBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2018-12-18T19:04:03+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearCybersecurity - Part 5 Templatesurn:md5:f02ee9fa74fee8034a42fb26e99e32132018-10-15T14:58:00+02:002018-10-15T14:58:00+02:00MitchTemplatesCybersecurityrisk managementTemplate<p>Hi there! Long time no see once again. I dig up our series of <a href="https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations">posts on cybersecurity</a>.<br />
In this post I publish two new templates for cybersecurity risk management.</p> <p>The list of standards and guidances dealing with cybersecurity in medical devices has evolved a lot for the last two years:</p>
<ul>
<li>At first we had the FDA guidances on cybersecurity published in 2014-2016,</li>
<li>Then AAMI TIR 57 was released in 2016, it describes a security risk management process comparable to the safety risk management process of ISO 14971,</li>
<li>And in 2017, ANSI/UL 2900-1, and ANSI/UL 2900-2-x were released, they list requirements (sometimes very specific) to design and maintain a secure medical device.</li>
</ul>
<p>Note that a traceability exists between UL 2900-x standards and FDA guidances on cybersecurity. I think though, it's unofficial, I let you find it on the web.<br />
<br />
All these guidances and standards represent a good source of information to implement a cybersecurity risk management process. However, if we extend the scope to other industries, the risk management process described in ISO 27005 is also a good start.<br />
<br />
This is the approach I had in the past few years, begin with ISO 27005 process and add specific medical devices provisions based on recommendations from AAMI TIR 57 and requirements from ISO 14971.<br />
This risk management process is then fed with guidances found in informative part of ISO 27005, AAMI TIR 57, as well as provisions found in UL 2900-x.<br />
<br />
The two templates are based on this approach:</p>
<ul>
<li><a href="https://blog.cm-dm.com/public/Templates/security-risk-management-plan-template-2018.doc">Security Risk Management Plan template</a>,</li>
<li><a href="https://blog.cm-dm.com/public/Templates/security-risk-assessment-report-template-2018.doc">Security Risk Assessment Template template</a>.</li>
</ul>
<p>You will also find them in <a href="https://blog.cm-dm.com/pages/Software-Development-Process-templates">the templates repository page</a>.<br />
<br />
I share this template with the conditions of <a href="https://blog.cm-dm.com/post/2011/11/04/License">CC-BY-NC-ND license</a>.</p>
<br />
<br />
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/fr/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/fr/">Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License</a>.
https://blog.cm-dm.com/post/2018/10/15/Cybersecurity-Part-5-Templates#comment-formhttps://blog.cm-dm.com/feed/atom/comments/217Cybersecurity in medical devices - Part 4 Impact on Software Development Processurn:md5:4ce8779c8fd7a433adba8829fa2750f92017-07-03T14:06:00+02:002017-07-04T21:34:52+02:00MitchRegulationsCybersecuritydevelopment process<p>We continue this series of posts on cybersecurity with some comments on impacts of cybersecurity on the software development documentation.</p> <h4>IEC 62304 class A software vs cybersecurity</h4>
<p>IEC 62304 defines a rather light set of constraints for class A software. Many connected objects or back-office servers processing medical data are low risk devices (when they’re qualified of medical devices). If we put apart the case of devices used for close-loop, or remote monitoring (or the like), most of standalone software in back-office (services) or used remotely (standalone web apps or mobile apps) will present failures with negligible consequences for the patient. As such, most of standalone software will be in class A (a conclusion that I verified empirically).<br /></p>
<h3>Cybersecurity documentation requirements</h3>
<p>For class A software, it’s usual to do the bare minimum to be compliant: software requirements, functional tests, a bit of risk assessment with acceptable risk prior to mitigation actions, a bit of SOUP management, and voilà! It won’t be enough to prove that standalone medical device software is secure.<br />
Thus, cybersecurity requires to bring additional documentation: security risk assessment, mitigation actions, and evidence of their effective implementation. Where are we going to find these evidences?<br />
In software requirements, of course, but also in architectural design, possibly in detailed design, and in unit/integration/verification tests. This sounds more like class B than class A.</p>
<h3>Special tests for cybersecurity</h3>
<p>More, we can mimic the section 5.5.4 of IEC 62304, applicable to class C only, by including additional cybersecurity tests requirements like application of <a href="https://www.owasp.org/index.php/Top_10_2013-Top_10">OWASP 13 Top-10</a> to verify good coding practices. For this kind of tests, tools like static analyzers or methods like peer code reviews are usually implemented. These tools and methods are more frequent for class C software development, than for class B and A.<br /></p>
<h4>Summary</h4>
<p>To sum-up, we have the following cases:</p>
<table style="text-align:center">
<tr style="background-color: #25ABA3">
<td>Type</td>
<td>SW embedded in MD (contributes to essential performance)</td>
<td>Standalone SW (diagnosis / treatment intended use)</td>
<td>SW embedded in MD (doesn't contribute to essential performance)</td>
<td>Standalone SW (no diagnosis / treatment intended use)</td>
</tr>
<tr>
<td>Usual SW safety class</td>
<td>C or B</td>
<td>C or B</td>
<td>A</td>
<td>A</td>
</tr>
<tr>
<td>Connected?</td>
<td>Usually no, but BTLE is appealing!</td>
<td>Usually yes, on PC or mobile connected to HCP or public network</td>
<td>Yes with BTLE or Wifi connected to HCP or public network</td>
<td>Usually yes, on PC or mobile connected to HCP or public network</td>
</tr>
<tr>
<td>Cybersecurity overhead</td>
<td>Null if not connected (beware of USB). Very high if connected, to prove that security breach won’t result in the degradation of essential performance.</td>
<td>Limited. Security breach will mostly result in data loss, rarely in non-serious harm (i.e. significant delay in diagnosis)</td>
<td>Null if not connected. Important if connected (data loss only, but class A documentation is not detailed enough)</td>
<td>Important if connected (data loss only, but class A documentation is not detailed enough)</td>
</tr>
</table>
<p>This comparison of different cases shows that we have a paradox:</p>
<ul>
<li>High safety risk devices will require a limited cybersecurity overhead. If essential performance relies on software, device connectivity will be limited. The cybersecurity documentation will represent a limited amount of work, compared to device safety documentation.</li>
<li>Low safety risk devices will require a significant cybersecurity overhead. Software safety documentation is poor, thus the cybersecurity overhead will represent a significant amount of work, compared to device safety documentation.</li>
</ul>
<p>This comparison is not valid for high-risk devices designed for connectivity, like an hypothetical close-loop system, which loop goes through a remote server. It's the worst case, reserved to manufacturers with enough resources to support the design and maintenance of such device.</p>
<h4>Conclusion</h4>
<p>Connecting a medical device to a network is not trivial, especially if that network is not a controlled network, like public or home network. The cybersecurity requirements established by the FDA guidances in the US, and in the new Medical Device Regulation in the EU have significant consequences on the cost of documentation to bring evidences of compliance.<br />
The cost is significant for IEC 62304 class A software, which requires documentation closer to class B than class A.</p>https://blog.cm-dm.com/post/2017/07/03/Cybersecurity-in-medical-devices-Part-4-Impact-on-Software-Development-Process#comment-formhttps://blog.cm-dm.com/feed/atom/comments/206Cybersecurity in medical devices - Part 3 AAMI TIR57:2016urn:md5:5adc4afffd7a08b5f11355939d648e6d2017-05-16T21:53:00+02:002017-05-16T22:46:46+02:00MitchStandardsCybersecurityGuidance<p>After a long pause, we continue this series about cybersecurity in medical devices with a discussion on AAMI TIR57:2016 Principles for medical device security — Risk management.</p> <p>This TIR is the one and only document available in the corpus on medical device-related standards and guidances, dealing with the application of cybersecurity principles and their impact on ISO 14971 risk management process. Yet, FDA guidances exist, but they’re not as direct as this TIR to show the impact of cybersecurity management process on risk management process.</p>
<h4>Structure of AAMI TIR57:2016</h4>
<p>The structure of sections 3 to 9 of this document is copied from ISO 14971 standard. It shows how the security risk management process can be modeled in a manner similar to the safety risk management process.<br />
If you’re at ease with ISO 14971, you’ll be at ease with AAMI TIR57. Your effort of understanding will be focused on security risk management concepts, not the process (risk identification, evaluation, mitigation and so on…) that you already know.<br />
We can bless the working group in charge of this TIR for this effort of presentation. The diagram below, extracted from the TIR, shows the analogy between both processes.</p>
<p><img src="https://blog.cm-dm.com/public/Cybersecurity/security-risk-safety-risk.png" alt="Relationships between the security risk and safety risk management processes" style="display:table; margin:0 auto;" title="Relationships between the security risk and safety risk management processes, May 2017" />
<br />
You've probably already seen this diagram elsewhere. And I bet that many articles or newsletters dealing cybersecurity in medical devices are going to reproduce it as well!</p>
<h4>Separation of processes</h4>
<p>The TIR recommends to separate the security and safety risk management processes. This looks as a good recommendation, as people involved in both processes are not all the same. Data security and clinical safety concepts are not managed by the same persons with the same qualifications.</p>
<h5>Cons</h5>
<p>This separation is going to remain very theoretical for most of small businesses. Practically, big companies can afford maintaining two processes and the needed qualified persons, but small businesses don’t.<br />
Small businesses will require the help of security experts to manage security risks. But they will be most probably hired as consultants. People who currently manage ISO 14971 process will manage both processes, without clear separation on a day to day basis.</p>
<h5>Pros</h5>
<p>The separation of processes is a good way to monitor efficiently security risk management. Keeping a security risk management file separated form the safety risk management file allows to document the outputs of the process without mixing concepts of security risk management (threats, vulnerabilities, assets, adverse impacts), with concepts of safety risk management (hazardous phenomenon, hazardous situation, hazard, harm).</p>
<h4>Annexes of AMMI TIR:57:2016</h4>
<p>The annexes found after section 9 are another wealth of information. They contain practical methods to implement a security risk management process. There is even a list of questions that can be used to identify medical device security characteristics, like the annex C of ISO 14971 for safety risks!<br />
The TIR ends with an example based on a fictional medical device: the kidneato system, with everything that a manufacturer shouldn’t do: an implanted part, a part connected to the public network, and a server storing medical data. Delicatessen for hackers!</p>
<h4>Multiplication of risk management files</h4>
<p>With the ongoing implementation of ISO 13485:2016 by medical device manufacturers, another consequence of security risk management is the multiplication of risk management files:</p>
<ul>
<li>QMS Process risk management,</li>
<li>Safety risk management,</li>
<li>Security risk management, and</li>
<li>Risk / opportunities management, for the fans of ISO 9001:2015.</li>
</ul>
<p>We can even try to draw a table of interactions between these processes (I skip ISO 9001:2015, but don’t conclude I’m not a fan :-))</p>
<table style="text-align:center">
<tr style="background-color: #25ABA3">
<td>&nbsp;</td><td>Affects</td><td rowspan="2">Safety</td><td rowspan="2">QMS Process</td><td rowspan="2">Security</td>
</tr>
<tr>
<td>Risks</td><td>&nbsp;</td>
</tr>
<tr>
<td colspan="2">Safety</td><td style="background-color: #dddddd">X</td><td>Safety risk mitigations implemented in QMS processes</td><td>Safety risks with potential impact on security. Safety controls affecting security</td>
</tr>
<tr>
<td colspan="2">QMS Process</td><td>Hazardous situations in QMS processes with impact on safety. QMS process controls affecting safety</td><td style="background-color: #dddddd">X</td><td>QMS process risk controls affecting security. Threats, vulnerabilities, assets found in processes to assess in security risk management</td>
</tr>
<tr>
<td colspan="2">Security</td><td>Security risks with impact on safety, Security controls affecting safety</td><td>Security risks with impacts on QMS processes (and possibly safety). Security controls affecting QMS processes</td><td style="background-color: #dddddd">X</td>
</tr>
</table>
<h4>Conclusion</h4>
<p>AAMI TIR75:2016 is an excellent source of information for newbies in security risk management. A must-read for people not qualified in security risk management, who need to manage the process, and anticipate its impact on other processes.<br />
<br />
In the next article, we’ll see the consequence of cybersecurity management on software development and maintenance processes.</p>https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016#comment-formhttps://blog.cm-dm.com/feed/atom/comments/204Final FDA Guidance on Postmarket Management of Cybersecurity in Medical Devices - Final version releasedurn:md5:a2c6398cc0958aea47e330959db3a5202017-02-10T14:20:00+01:002017-02-11T16:32:05+01:00MitchRegulationsCybersecurityFDAGuidance<p>This article is a follow-up of the previous article on the <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">Draft guidance on Postmarket Management of Cybersecurity in Medical Devices</a>.</p> <h4>Postmarket Management of Cybersecurity in Medical Devices</h4>
<p>The FDA released the final version of this guidance in December 2016. Let's see what changes the FDA made, compared to the draft version.<br />
This guidance underwent many changes, compared to the draft version. One of the most prominent is in the scope:</p>
<blockquote><p>This guidance applies to any marketed and distributed medical device including: 1) medical devices that contain software (including firmware) or programmable logic; and 2) software that is a medical device, including mobile medical applications. In addition, this guidance applies to medical devices that are considered part of an interoperable system and to “legacy devices,” i.e., devices that are already on the market or in use.</p></blockquote>
<p>Argh! Legacy devices! Good luck...<br />
Well, this scope was updated to cover any type of medical device with software or with data transmission functions (i.e. the presence of interoperable device) and to make it as articulate as possible.</p>
<h4>Essential Clinical Performance replaced by Patient Harm</h4>
<p>In the Definitions section, the essential clinical performance disappeared and was replaced by Patient Harm.
The concept of “essential clinical performance”, which was developed in the draft guidance, was removed in the final version.<br />
The definition of patient harm is fairly long and won't be copy-pasted here. It is aligned with the definition of patient harm in ISO 14971. The guidance stresses out the risk-based assessment of cybersecurity vulnerabilities, which can lead by a sequence of events to patient harm.<br />
<br />
Interestingly, the guidance excludes vulnerabilities compromising confidential data. It only recommends to protect devices from such situations, and refers to other regulations like HIPAA.</p>
<h4>Postmarket Considerations</h4>
<p>The posmarket considerations were updated to remove to recommendation to "Clearly [define] essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk". It was replaced by (emphasis added):</p>
<blockquote><p>Using threat modeling to clearly define how to maintain <ins>safety and essential performance</ins> of a device by developing mitigations that protect, respond and recover from the cybersecurity risk.</p></blockquote>
<p>The postmarket considerations were also augmented with the recommendation:</p>
<blockquote><p>Maintaining robust software lifecycle processes that include mechanisms for:<br />
o monitoring third party software components for new vulnerabilities throughout the device’s total product lifecycle;<br />
o design verification and validation for software updates and patches that are used to remediate vulnerabilities, including those related to Off-the-shelf software<br /></p></blockquote>
<p>We retrieve somewhat here the requirements on software maintenance of section 6 of IEC 62304, read through the lens of cybersecurity management.<br />
<br />
Talking about standards, the guidance mentions that the FDA has recognized <em>ISO/IEC 30111:2013: Information Technology – Security Techniques – Vulnerability Handling Processes</em>, and <em>ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure</em>, which the FDA thinks may be useful for manufacturers.</p>
<h4>Maintaining Safety and Essential Performance</h4>
<p>In relation with the removal of essential clinical performance, the section on "Defining Essential Clinical Performance" was removed and replaced by "Maintaining Safety and Essential Performance".<br />
This section draws the link between cybersecurity risk management, safety and essential performance, threat modeling, and remediations (in cybersecurity vocabulary) / mitigation actions.</p>
<h4>Evaluation and control of risk patient harm</h4>
<p>Likewise, the section on "Evaluation of Risk to Essential Clinical Performance" was replaced by "Evaluation of Risk of Patient Harm", and the section on "Control of Risk to Essential Clinical Performance" was replaced by "Control of Risk of Patient Harm" <br />
The body text of both sections was almost left untouched, with a direct search-and-replace of essential clinical performance by patient harm. It makes their wording more in line with what QA/RA people have the habit to read: risk management addresses patient harm.<br />
These sections were also slightly updated, with recommendations on adopting a vulnerability disclosure policy, and recognizing that changes (mitigations / remediations) may have an impact on the performance of a medical device. In other words, a risk resulting of the mitigation action.</p>
<h4>Criteria for defining active participation by a manufacturer in an ISAO</h4>
<p>ISAO: Information Sharing Analysis Organization - see <a href="https://www.dhs.gov/isao-faq">ISAO FAQ</a> to better understand the purpose of these organizations.<br />.
This is a new section in the final guidance. It emphasizes the participation of manufacturers in an ISAO. Reading between the lines, this is the kind of recommendation, which can become a compulsory practice.</p>
<h4>Elements of an effective postmarket cybersecurity program</h4>
<p>To finish with this quick scan of the guidance, this appendix hasn't changed that much. We retrieve the direct search-and-replace of essential clinical performance by patient harm, along with small changes to the body text.</p>
<h4>Conclusion</h4>
<p>Compared to the draft guidance, this final guidance contains only small fixes and a clarification of management of cybersecurity vs patient harm. It doesn't reduce nor increase the burden of cybersecurity management. While reducing the burden could have been an expectation of some manufacturers, it is not feasible. Fortunately, it hasn't increased between the draft and the final guidance.<br />
<br />
With this final guidance on Postmarket Management of Cybersecurity in Medical Devices, and the <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices</a>, we now have a full set of recommendations for cybersecurity management over the medical device software lifecycle.<br />
<br />
We now have GCyP: Good Cybersecurity Practices.</p>https://blog.cm-dm.com/post/2017/02/10/FDA-Guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices-Final-version-released#comment-formhttps://blog.cm-dm.com/feed/atom/comments/202Final FDA Guidance on Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Typesurn:md5:367a465c647625aa1580d359f67c34d82017-02-10T14:19:00+01:002017-02-10T14:19:00+01:00MitchRegulationsCybersecurityFDAGuidance<p>This article is a follow-up of the article on the <a href="https://blog.cm-dm.com/post/2015/03/20/When-the-FDA-releases-guidances-in-burst-mode">Draft guidance on Medical Device Accessories: Defining Accessories and Classification Pathway for New Accessory Types</a>.</p> <p>The FDA released the final version of two guidances in December 2016 (yes, I know, I'm a bit late. But you see, this blog is still alive...). One on the medical devices accessories and one on postmarket management of cybersecurity in medical devices.<br />
Let's see what changes the FDA made to the medical devices accessories guidance, compared to the draft version.</p>
<h4>Medical Device Accessories</h4>
<p>This guidance didn't suffer many changes. The guidance describes what the FDA considers an accessory to a medical device and how it regulates them. Accessories with risk profile different from their parent devices may fall within a different class than the device with which they're intended to be used.<br />
<br />
The truly interesting changes are those clarifying the status of software as a medical device:</p>
<blockquote><p>FDA intends for the risk- and regulatory control-based classification paradigm discussed in this guidance to apply to all software products that meet the definition of an accessory, including those that may also meet the definition of “Software as a Medical Device (SaMD).”</p></blockquote>
<p>Thus SaMD intended to support, supplement, and/or augment the performance of one or more parent devices are medical devices accessories and may fall within a class different from their parent devices. This actually opens the door to the De Novo clearance process for SaMD with no "easy" predicate.<br />
<br />
Another truly interesting change, compared to the draft version, is the examples on articles used in conjunction with the device, which do not fall in the definition of accessories:</p>
<blockquote><p>FDA would generally not consider a mobile phone that is used as a general platform for applications that include mobile medical applications that are medical devices or an off-the-shelf computer monitor used to display medical data as accessories unless they are specifically intended for use with such medical devices.</p></blockquote>
<p>Likewise:</p>
<blockquote><p>non-device-specific off-the-shelf replacement parts (e.g., batteries, USB cables, computer mouse, etc.) may be used with a medical device, but FDA does not intend to consider these products to be accessories or medical devices.</p></blockquote>
<p>These two examples are welcome. How many times newcomers in the world of SaMD have asked if these types of articles are medical devices. It's way better written in back and white.</p>
<h4>Conclusion</h4>
<p>Not so much new things compared to the draft guidance. The FDA confirms their approach on medical devices accessories, allowing to place accessories in a class different from their parent devices, and opening the gate to the De Novo process.<br />
Besides that, the examples found in this guidance about off-the-shelf hardware are very helpful to determine if such articles are accessories of software medical device or not.
<br />
<br />
The <a href="https://blog.cm-dm.com/post/2017/02/10/FDA-Guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices-Final-version-released">next article</a> is on postmarket management of cybersecurity in medical devices.</p>https://blog.cm-dm.com/post/2017/02/10/Final-FDA-Guidance-on-Medical-Device-Accessories%3A-Defining-Accessories-and-Classification-Pathway-for-New-Accessory-Types#comment-formhttps://blog.cm-dm.com/feed/atom/comments/201Cybersecurity in medical devices - Part 2 Stakeholdersurn:md5:fca5a3cf09fa3ba201eb625510e86f262016-12-20T12:51:00+01:002017-05-23T16:19:07+02:00MitchMiscCybersecurity<p>After a long interruption, we continue this <a href="https://blog.cm-dm.com/post/2016/11/01/IEC-82304-1%3A2016-Health-software-Part-1%3A-General-requirements-for-product-safety">series on cybersecurity</a> in medical devices with a review of stakeholders involved or concerned by cybersecurity requirements, and the consequences on architectural choices.</p> <p>The main characteristic of connected medical devices is to be ... connected. They can't fulfill their intended use alone and need a technical environment to work. This technical environment is never provided by the manufacturer alone. Thus several stakeholders are involved in the fulfillment of the intended use, directly or indirectly.</p>
<h4>Interested parties</h4>
<p>Borrowing the vocabulary of ISO 9001:2015, stakeholders are interested parties, and we have to <em>understand the needs and expectations of interested parties</em> (quote of 4.2 of ISO 9001:2015).<br />
<img src="https://blog.cm-dm.com/public/Cybersecurity/.cybersecurity_stakeholders_m.png" alt="cybersecurity_stakeholders.png" style="display:table; margin:0 auto;" title="cybersecurity_stakeholders.png, Dec 2016" /></p>
<h5>Cybercriminals</h5>
<p>The goal of cybercriminals is to break the security measures to steal medical or financial data (welcome to the depths of the internet), or to injure people (mostly in movies).<br />
<br />
<ins>Cybercriminals:</ins></p>
<ul>
<li>Needs: to have a better living whatsoever,</li>
<li>Expectations: to find devices and IT infrastructures with vulnerabilities.</li>
</ul>
<h5>Medical device manufacturers</h5>
<p>The goal of MD manufacturers is to design and place on the market secure devices, without vulnerabilities. To be more specific, without <em>known</em> vulnerabilities.<br />
<br />
<ins>Manufacturers:</ins></p>
<ul>
<li>Needs: to have the capabilities to design and maintain devices without vulnerabilities,</li>
<li>Expectations: to place connected devices on the market, compliant to regulations, safe and secure.</li>
</ul>
<h5>IT infrastructure providers</h5>
<p>We have two types of infrastructure providers: those who are aware of medical devices (MD) and health data (HD) regulations and standards, and the others who are not aware or deliberately won't set a foot in the constraints of e-health. The former usually build an offer of services compliant to MD and HD regulations, the latter don't or won't.<br />
For example, some cloud storage providers currently sell services compliant to HIPAA regulation in the US, and will sell services compliant to GDPR in Europe. Others are for example telco companies or general cloud service providers.<br />
<br />
<ins>MD and HD compliant service providers:</ins></p>
<ul>
<li>Needs: to have the capabilities to design and maintain IT platforms without vulnerabilities,</li>
<li>Expectations: to sell services compliant to MD and HD regulations.</li>
</ul>
<p><ins>Other IT service providers:</ins></p>
<ul>
<li>Needs: to have the capabilities to design and maintain IT platforms without vulnerabilities,</li>
<li>Expectations: to sell services while staying out of MD and HD regulations.</li>
</ul>
<h5>Governmental organizations</h5>
<p>These organizations have the mission to enforce regulations and to watch the market. We find organizations of the MD and HD world, like the FDA or the Department of Health &amp; Human Services in the US, and like national authorities of member states in Europe.<br />
Specific to cybersecurity, we can also quote the Information Sharing and Analysis Organizations (ISAO) cited <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">in the FDA guidance on postmarket management of cybersecurity</a>.<br />
<br />
<ins>Governmental organizations:</ins></p>
<ul>
<li>Needs: to have a clear understanding of what other stakeholders do,</li>
<li>Expectations: to have devices and IT infrastructures compliant to regulations throughout their lifecycle.</li>
</ul>
<p>Additionally, we can quote the <a href="https://www.dhs.gov/topic/cybersecurity">US Department of Homeland Security</a> and <a href="https://www.gov.uk/government/policies/cyber-security">equivalent agencies</a> in other countries. But this is a bit out of the scope of this blog!</p>
<h5>End-Users</h5>
<p>We have here several type of end-users:</p>
<ul>
<li>Patients,</li>
<li>Medical and paramedical personnel,</li>
<li>Hospitals, healthcare centres.</li>
</ul>
<p>They have similar but not identical needs and expectations.<br />
<br />
<ins>Patients:</ins></p>
<ul>
<li>Needs: to have a better health or quality of life,</li>
<li>Expectations: secured devices/services, which are not labyrinthine systems.</li>
</ul>
<p><ins>Medical and paramedical personnel:</ins></p>
<ul>
<li>Needs: to cure or take care of patients,</li>
<li>Expectations: secured devices/services, which help them in their daily work.</li>
</ul>
<p><ins>Hospitals, healthcare centres:</ins></p>
<ul>
<li>Needs: to provide connected devices to their personnel (even if they're reluctant :-)),</li>
<li>Expectations: to buy secured devices/services.</li>
</ul>
<p><br />
End-users (patients and caregivers) have in common to be passive regarding cybersecurity. It is not their problem. When it becomes their problem, it is usually too late, data have already leaked.<br />
While it is preferable to have security by design, training of end-users is part of the measures of protection. It is difficult to make end-users actors of the cybersecurity but it is a mandatory and endless task.
<br /></p>
<h4>Architectural choices and constraints</h4>
<p>Coming back to technical considerations, we can see that the more the architecture of a connected object is complex, the more we have stakeholders involved in cybersecurity.<br />
Let's see an example, with a connected object used at home, which transfers data for monitoring/processing by medical personnel.<br />
<img src="https://blog.cm-dm.com/public/Cybersecurity/cybersecurity_medical_device_architecture_example.png" alt="cybersecurity_medical_device_architecture_example.png" style="display:table; margin:0 auto;" title="cybersecurity_medical_device_architecture_example.png, Dec 2016" /></p>
<h5>MD manufacturer</h5>
<p>In this case, the MD manufacturer has to build a technical and organizational solution, which is able to meet its expectations: a safe and secure connected medical device architecture.<br />
This is its responsibility. The implementation can be delegated to subcontractors. But the responsibility of the manufacturer cannot be "subcontracted".<br />
<br />
In the example of the schema above, the goal is to use patient data acquired by connected objects to help the caregivers in their work:</p>
<ol>
<li>Raw medical data of the connected medical devices are transferred to a gateway,</li>
<li>The gateway preprocesses data, like filtering or compression and send them to the application server,</li>
<li>Data are routed to the application server through the telco modem and the internet,</li>
<li>The application server stores health data in a database and processes data (syntheses, comparison to encyclopedic data...),</li>
<li>The medical/paramedical personnel can consult and assess data by the means of a care management interface.</li>
</ol>
<p>We consider here that the connected weight scale, blood pressure monitor, software on the application server, and care management interface belong to the same manufacturer. The gateway, the database, and the application server infrastructure (a server in a datacenter) are subcontracted.<br />
<br />
Let's see how the outsourced parts will have consequences on cybersecurity and on the constraints applied to the manufacturer.</p>
<h5>Database service providers</h5>
<p>In this example, the provider of the database storage service is a MD/HD compliant service provider. The provider is certified for storage of health data.<br />
Its goal is to ensure that the manufacturer won't compromise its own infrastructure. Thus it will add contraints in its service contract (and probably also in the technical solution and/or available APIs) to ensure that the security of its service remains at a validated level of security.<br />
<br />
As a consequence, the manufacturer won't have a lot of choices of technical implementation for its own solution, as the health data storage service providers are not so many on the market. It means also an effort of selection of the provider, to match the technical needs of the manufacturer with the capabilities of the platform of the provider.<br /></p>
<h5>Gateway service provider</h5>
<p>Let's assume in this example that the gateway is part of a MD/HD compliant service. The gateway is rented by its manufacturer, and is capable of managing secured wireless health data transfer over bluetooth and wifi.<br />
Likewise, the gateway service provider will add constraints to ensure that its device will remain safe and secure. As a consequence, the manufacturer will have to adapt the data protocols and interfaces on its connected objects and on the application server.</p>
<h5>Telco service providers</h5>
<p>Even if some telco firms begin to provide health data transportation and storage services, let's assume that we use a generic data transportation service. Their goal is to avoid any involvement in the management of health data. As a consequence, the manufacturer shall identify and implement technical measures ensuring a safe and secure data transfer over their infrastructure. While the telco providers already implement cybersecurity measures on their network, the manufacturer will probably have to ensure that the data transfer remains compliant with MD/HD regulations.</p>
<h5>Application server hardware provider</h5>
<p>Most application servers are now hosted in datacenters. Let's assume that the application server runs on a cloud server different from the database server. This cloud server is managed by a provider without compliance to MD/HD regulations.<br />
On the HD regulation side, the manufacturer shall ensure that health data will never be stored in the application server. They can be cached in memory during data processing but data are stored on the compliant database.<br />
On the cybersecurity side, the application server shall be secure, as well as its interfaces with the database server, the gateway and the care management interface. The server will be hosted in a secured datacenter, thus physical/hardware security measures will be implemented by the server hosting provider. But the manufacturer will have to implement software security measures.</p>
<h4>Risk management</h4>
<p>The message behind this example is the necessity to perform a risk management oriented to cybersecurity hazards. The manufacturer shall do this risk assessment, and identify the mitigation actions, which depend on the subcontractors.<br />
And the mitigation actions can heavily depend on qualified subcontractors.<br />
<br />
This is a bit new in the domain of software, as software MD manufacturers don't have the habit to outsource their critical processes when software is in production.<br />
This is also a bit new, as many cybersecurity risks and mitigation actions are "located" in the deployment, production and decommissioning phases of the software lifecycle.<br />
<br />
We can make a comparison with manufacturers of physical medical devices, which need to mitigate risks related to devices in contact with the patient, like biocompatibility. They depend a lot on specialized subcontractors for production processes like manufacturing, cleaning and sterilization.<br />
Likewise, manufacturers of connected objects or software on the cloud will more and more depend on qualified subcontractors to mitigate risks related to cybersecurity.<br />
<br />
<br />
The medical device business is changing with more complex and smarter devices, more stakeholders, new regulations brought by health data processing, and more work for the manufacturers to place compliant and secure devices on the market.<br />
<br />
<br />
<a href="https://blog.cm-dm.com/post/2017/05/16/Cybersecurity-in-medical-devices-Part-3-AAMI-TIR57%3A2016">Next time</a>, we will actually see risk management and cybersecurity.</p>https://blog.cm-dm.com/post/2016/12/20/Cybersecurity-in-medical-devices-Part-2-Stakeholders#comment-formhttps://blog.cm-dm.com/feed/atom/comments/197Cybersecurity in medical devices - Part 1 Regulationsurn:md5:5a4ae48b2cdba6f6b1831c276ba061d02016-10-24T16:50:00+02:002016-10-24T16:50:00+02:00MitchRegulationsCybersecurity<p>We begin today a series of posts on cybersecurity in medical devices. Cybersecurity was not a subject before the advent of computerized medical devices. Now that every manufacturer wants its connected medical device, cybersecurity matters!<br />
Let's start with the regulations.</p> <h4>Medical devices, e-health and personal data</h4>
<p>The main characteristic of connected medical devices is their ability to communicate health data. Though some devices may only communicate data on their status, which are not personal data, connected devices communicate above all personal data. Such data can be used for diagnosis or for historical purposes.<br />
Thus regulations applicable to connected devices include the regulations on medical devices but also on personal data, without forgetting regulations on data networks.</p>
<h4>Regulations on cybersecurity</h4>
<p>Following the short discussion above, regulations on cybersecurity cover medical devices, personal data and data networks. Let's see which regulations are applicable in Europe and in the USA.<br />
<br />
<img src="https://blog.cm-dm.com/public/Cybersecurity/.Cybersecurity_Regulations_m.png" alt="Cybersecurity_Regulations.png" style="display:table; margin:0 auto;" title="Cybersecurity_Regulations.png, Oct 2016" /></p>
<h4>USA</h4>
<p>In the USA, the context is simple (compared to Europe :-)). We two main regulations:</p>
<ul>
<li>The 21 CFR, mainly part 820 but also part 806 or part 803, on medical device lifecycle,</li>
<li>HIPAA/HITECH rules on electronic personal health information (e-phi) management</li>
</ul>
<p>The interpretation by the FDA on the implementation of cybersecurity for regulated medical devices can be found <a href="https://blog.cm-dm.com/post/2014/11/21/Analysis-of-the-FDA-Cybersecurity-Guidance">in the guidance on the content of premarket submission files about cybersecurity</a> and <a href="https://blog.cm-dm.com/post/2016/01/29/FDA-draft-guidance-on-Postmarket-Management-of-Cybersecurity-in-Medical-Devices">the guidance on postmarket management of cybersecurity</a>.<br />
These guidances mainly recommend (require?) that:</p>
<ul>
<li>Medical device safety and data privacy shall be addressed during design and development,</li>
<li>Post-market surveillance of medical devices shall include cybersecurity risks.</li>
</ul>
<p><br />
The HIPAA rules can be found <a href="http://www.hhs.gov/hipaa/for-professionals/index.html">here (have a look at the Combined Regulation Text)</a>. These rules are applicable to <a href="http://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html">covered entities and business associates</a>. Depending on the services provided with their medical devices, manufacturers or their subcontractors can be in the scope of business associates. E.g. if the device is used within a health plan. Manufacturers are indirectly impacted by the physical and technical safeguards of the HIPAA (see link to Combined Regulation Text above). These safeguards affect the design of medical devices with rules like:</p>
<ul>
<li>Unique user identification,</li>
<li>Automatic logoff,</li>
<li>Backup and restore,</li>
<li>Export of a copy of health data of a person.</li>
</ul>
<p><br />
Additional useful information on HIPAA is present on <a href="http://hipaacow.org">the HIPAA COW website (funny name but serious website)</a>.<br /></p>
<h4>European Union - present</h4>
<p>There are currently two regulations applicable in the European Union:</p>
<ul>
<li>the 93/42/EC directive on medical devices,</li>
<li>the 95/46/EC directive on data protection.</li>
</ul>
<p>The medical device directive is mute on cybersecurity. And there is no MEDDEV guidance on cybersecurity either.<br />
The data protection directive contains requirements on confidentiality and security of data processing, but not as precise as those of HIPAA.<br />
But these two directives are close to their end of life and will be replaced by new regulations.</p>
<h4>European Union - close future</h4>
<p>The new regulations, which will replace the current directives are:</p>
<ul>
<li>the Medical Device Regulation (MDR), it should be fully applicable in 2020,</li>
<li>the <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AL%3A2016%3A119%3ATOC">2016/679 General Data Protection Regulation</a> (GDPR), it will be fully applicable in May 2018.</li>
</ul>
<p>As seen before <a href="https://blog.cm-dm.com/post/2016/09/02/EU-Medical-Device-Regulation-changes-for-software">in this article</a>, the new MDR raises the bar on cybersecurity for medical device software.<br />
<br />
The GDPR is more stringent on personal data, with lots of requirements, and especially requirements for personal health data, like:</p>
<ul>
<li>the right of an individual to easily access to personal data, to rectify data, 'to be forgotten',</li>
<li>the obligation to conduct a data protection impact assessment (PIA),</li>
<li>the obligation to ensure data protection by design.</li>
</ul>
<p>This new regulation adds a considerable burden to agents manipulating personal data. See <a href="https://medicaldeviceslegal.com/2016/05/29/the-new-general-data-protection-regulation-impact-on-medical-devices-industry/">this excellent article on this blog</a> on how to set a plan to be compliant to this new regulation.<br />
<br />
A third regulation impacts very indirectly the medical devices manufacturers: the <a href="https://ec.europa.eu/digital-single-market/en/network-and-information-security-nis-directive (NIS Directive)">Directive on security of network and information systems</a>. This directive <q>provides legal measures to boost the overall level of cybersecurity in the EU</q>.<br />
Basically, member states shall identify vital IT networks and protect them against threats. Some healthcare networks can be considered vital and thus are in the scope of this directive. As a consequence, stringent cybersecurity measures are required on such networks. Since some connected medical devices can be found on these networks, they will be subject to the cybersecurity measures, that manufacturers will have to implement or follow.</p>
<h4>To sum-up</h4>
<p>Regulations on medical devices and health data are applicable to connected medical devices manipulating health data. Cybersecurity is a concept anterior to connected medical devices, but it is now included in the criteria of compliance to regulations pertaining to medical devices and personal health data.<br />
These regulations bring additional requirements, which affect the design and the post-market surveillance of medical devices. We will see in this series of posts how to implement processes to bring evidence of compliance to cybersecurity requirements.<br />
<br />
<br />
The next article will be on the stakeholders interested in cybersecurity.</p>https://blog.cm-dm.com/post/2016/10/24/Cybersecurity-in-medical-devices-Part-1-Regulations#comment-formhttps://blog.cm-dm.com/feed/atom/comments/196