New Standard Maps Medical Device Software Development Standard to Healthcare Software and Healthcare IT Cybersecurity | King and Spalding

0

The International Electrotechnical Commission (IEC) and the International Organization for Standardization (ISO) recently released a cybersecurity standard that has received limited press, but could have a significant impact on healthcare software vendors. , whether or not they are. The standard was published as IEC 81001-5-1:2021, and it is the first in what is expected to be a series of IEC 81001 healthcare software standards.

The scope of the standard is:

  • Software in a Medical Device (SiMD);
  • Software forming part of computer hardware specifically intended for health-related use;
  • Software as a Medical Device (SaMD); and
  • Software-only products for other health-related uses.

The most important feature of the new standard is that it uses IEC 62304:2006 + AMD1:2015 (Medical device software – software life cycle processes) as the basis for its activities and deliverables, and it integrates cybersecurity requirements into each IEC 62304 procedure. Although ubiquitous among medical device manufacturers, IEC 62304 may impose a set of lifecycle activities on non-device healthcare software vendors that companies may not have previously considered.

Although Annex A of IEC 81001-5-1:2021 states that compliance with IEC 62304 is not a requirement for compliance with IEC 81001-5-1:2021, in our opinion (and under -understood by the wording of the Annex) compliance with IEC 81001-5-1 can be problematic without also aligning with IEC 62304 (e.g. requirements for software of unknown provenance (SOUP), software architectural design, security risk management, problem resolution, and documented static reviews of requirements, architecture, and design).

Other notable provisions of the new standard include the following:

  • New Risk Considerations – Although it correlates to security risk management, risk in this standard addresses cybersecurity vulnerabilities and threats beyond those that have a security impact. This is in line with cybersecurity guidance from various sources (e.g. Association for the Advancement of Medical Instrumentation (AAMI) and National Institute for Standards and Technology (NIST) in the US, Medical Device Consortium Group (MDGC) in the EU, and Health Canada). It is, however, inconsistent with current US Food and Drug Administration (FDA) cybersecurity guidelines, which limit consideration of cybersecurity risks to security-related issues.
  • Threat modeling – The emphasis on threat modeling is consistent with that of the FDA and others, and the standard incorporates threat modeling into its discussion of the “Security Risk Management Process” in Sections 4.2, 7 and B.3. Threat modeling is discussed in depth in Appendix C, where the standard identifies several acceptable approaches. We also note that the standard instructs manufacturers to avoid the trap of simplistic threat mitigations and instead adopt a defense-in-depth architecture.
  • Training and assessment programs – Section 4.1.4 of the standard requires manufacturers to identify and provide safety training and evaluation programs that broadly align with the personnel sections of the US medical device regulations and on the ISO 13485:2016 quality system standard for medical devices. The requirement, however, goes beyond many other global cybersecurity guidance documents in this regard.
  • New classification of software – While the IEC 62304 medical device software lifecycle standard classifies software systems according to the severity of pre-mitigated security risks, IEC 81001-5-1 applies to all security classes and instead classifies software based on ownership of cybersecurity risk (i.e., “risk transference”). The risk transfer categories are “maintained”, “supported” or “required”. The manufacturer’s responsibilities for each of these classes are detailed in appendix A.3.
  • Software system check – Software system level testing (section 5.7 of the new standard) requires testing not only the security requirements in the overall software system requirements, but also the threat mitigation measures from the threat model, the vulnerability testing and penetration testing. For organizations that have not made threat models central to their cybersecurity risk management planning and design verification, these requirements likely represent a significant change from current practices.
  • Conflicts of interest – Section 5.7.5 of the standard focuses on managing conflicts of interest between testers and developers for a series of six types of design verification testing. We view producing objective evidence of compliance with this requirement as a potential challenge, especially for smaller software development companies.
  • Software BOMs – The recent focus on Software Bill of Materials (SBOMs) by the FDA is missing from this standard although they are mentioned in a note in Appendix E acknowledging SBOMs as a requirement of IEC 60601-4-5.
  • Vulnerability Monitoring/Security Update Checking – There is a lot of real estate in the maintenance section of the standard (section 6) dedicated to monitoring vulnerabilities and checking and releasing security updates. Disclosure of vulnerabilities (consistent with most other global guidance documents) is incorporated accordingly as a requirement in section 4.1.7.
  • Legacy software – Similar to the IEC 62304 provision for legacy software introduced in the 2015 update, IEC 81001-5-1 dedicates Annex F to “transitional healthcare software” and provides steps to build confidence in cybersecurity in systems not developed in accordance with the standard.

King & Spalding will observe how the FDA reacts to the publication of this standard in two respects: (1) how IEC 81001-5-1 aligns (or does not align) with the second version of the cybersecurity guidelines pre -FDA commercialization expected this year and (2) if and when FDA includes IEC 81001-5-1 in its list of recognized consensus standards. The company will also monitor potential changes to existing cybersecurity guidance from the MDCG, Health Canada, the Australian TGA and the International Medical Device Regulator’s Forum (IMDRF). Within the EU in particular, it is possible that IEC 81005-5-1 will be classified as a harmonized standard in the EU Medical Device Regulation (EU MDR) in the future.

We encourage companies across the healthcare software spectrum to obtain a copy of this standard and clearly understand any gaps from current practices.

Share.

Comments are closed.