This paper is an exploration of what could be a subset of data integrity, with added dimensions -cybersecurity. Cybersecurity is a growing concern for all, whether you work in the legal, financial or consumer industries. It could affect you personally.
Cybersecurity is a recent concern for the medical products industries, a result of their increased reliance on networked electronic software, records and signatures. Initially there were regulations such as 21 CFR Part 11 in the U.S. and Annex 11 in Europe. But more must be done to ensure the integrity of CGMP documents / records. Cybersecurity is an issue that will only increase over time, as records become more electronic, and communications are more networked or accessible.
As a result, the US FDA has issued the following Guidances for Industry:
- “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software Document”, issued on: January 14, 2005; and
- “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, issued on: October 2, 2014; and
- “Postmarket Management of Cybersecurity in Medical Devices” -- Draft Guidance, issued on: January 22, 2016
As the titles above indicate, the focus is on medical devices. But the principles can and should be applied to a company’s computerized systems as well. In this article, we will also focus on devices, but will also draw attention to company computerized systems where appropriate, to flag related potential problems with an e-records based QMS, computer-facilitated production and/or test / lab equipment / systems.
Of necessity, cybersecurity in the medical products industries is coming under increased regulatory review. Regulatory agencies leave the "how" of cybersecurity compliance up to the manufacturer, as long as the principles in the guidances are met in the resulting product and/or system. Related issues are primarily addressed by the CGMPs, specifically design control (21 CFR 820.30) for devices, and post-production by the CAPA system, among others.
Cybersecurity – Why?
FDA and news media have emphasized the prevalence of cybersecurity issues, such as data / identity theft, and hacking which pose hazards to many activities and businesses / industries. Our, and the FDA’s and EU’s concern, is with medical products’ users.
Further adding to the problem is the industrial growth of BYOD – “Bring Your Own Device” (laptop, tablet, smart phone, or similar “smart” device) – in the workplace. This growing trend poses a problem to cybersecurity, including unintentional and intentional malware introduction.
The increasing use of cloud (Internet)-based software to accomplish CGMP tasks, store / retrieve data (data warehousing) and similar uses poses another two-fold concern. In many cases, the updates, upgrades, new revisions / releases, service packs, and similar are automatically uploaded to a company’s systems, which can pose:
- Security risks, with the potential for introduction of compromised code, retrieval of confidential data, data integrity issues (discussed in our previous article), and similar; and
- Render previous computer systems’ verification and validations worthless (no change control / “line drawn in the sand”).
Such issues are troubling because ensuring data integrity / cybersecurity is an important component of industry’s responsibility to ensure the safety, efficacy, and quality of medical products, the records documenting their manufacture and use, and consequently, of FDA’s ability to protect the public health.
A growing number of medical devices are designed to be connected to computer networks, or facilitate the use of removable storage, such as flash or thumb drives. Such “networked” medical devices incorporate use software (off-the-shelf or custom) that is vulnerable to cybersecurity threats, such as viruses and worms, phishing, and similar unauthorized or unknown intrusions.
Such vulnerabilities pose a risk to the safe and effective operation of such medical devices. This mandates an ongoing maintenance effort throughout the product life cycle to assure an adequate degree of protection. FDA issued their Cybersecurity Guidance to clarify how existing regulations, including the Quality System (QS) Regulation, 21 CFR 820 (medical device CGMPs), 21 CFR Part 11, Electronic Records / Electronic Signatures, apply to such cybersecurity maintenance activities. It discusses the basic principles the FDA expects of companies producing products containing networked software / firmware. Though geared to medical devices, the principles apply to all regulated industries with networked and/or portable memory accessible software / firmware (e.g., flash / thumb drives, BYOD access) computerized systems – records maintenance, production and test equipment and similar.
However, the Cybersecurity Guidance specifically targets devices that incorporate off-the-shelf (OTS) software. Therefore, it primarily applies to device manufacturers who incorporate OTS software in their medical devices. The QS Regulation, 21 CFR Part 820, applies to software maintenance actions. This is in addition to the other guidance documents the Agency has issued in the past on software. Companies using SOUP (software of unknown pedigree) in their products (or systems) should also be aware of and address similar concerns.
The FDA recommends that medical device manufacturers consider the “NIST Framework for Improving Critical Infrastructure Cybersecurity” framework core functions to guide their cybersecurity activities:
- Respond; and
Identify and Protect
Medical devices capable of connecting (wirelessly or hard-wired) to another device, to the Internet or other network, or to portable media (e.g. USB or CD) are more vulnerable to cybersecurity threats than devices that are not connected. However, never assume invulnerability, verify to challenge vulnerability, and document such verification.
The extent to which security controls are needed will depend on the following:
- The device’s / systems intended use;
- The presence and intent of its electronic data interfaces;
- Its intended environment of use;
- The type of cybersecurity vulnerabilities present;
- The likelihood the vulnerability will be exploited (either intentionally or unintentionally); and
- The probable risk of patient harm due to a cybersecurity breach.
Manufacturers should also carefully consider the balance between cybersecurity safeguards and the usability of the device in its intended environment of use. See also the newly revised standard IEC 62366-1 (2015) and -2 (2016), Usability Engineering, for such a process.
Ensure Trusted Content
Restrict software or firmware updates to authenticated code. One authentication method manufacturers may consider is code signature verification. Use systematic procedures for authorized users to download version-identifiable software and firmware from the manufacturer. Ensure capability of secure data transfer to and from the device, and when appropriate, use methods for encryption.
Detect, Respond, Recover
Implement features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use. Develop and provide information to the end user concerning appropriate actions to take upon detection of a cybersecurity event. Implement device features that protect critical functionality, even when the device’s cybersecurity has been compromised. Provide methods for retention and recovery of device configuration by an authenticated privileged user.
Vulnerabilities and Risk
FDA states that a cybersecurity vulnerability exists whenever the software provides the opportunity for unauthorized access to the network or the medical device. Cybersecurity vulnerabilities open the door to unwanted software changes that may have an effect on the safety and effectiveness of the medical device. Failure to properly address these vulnerabilities could result in an adverse effect on public health. A major concern with OTS software is the need for timely software patches to correct newly discovered vulnerabilities in the software.
The FDA recommends that the manufacturer conduct a vulnerability analysis, both initially (premarket) and ongoing (post-market). The approach should appropriately address the following elements:
- Identification of assets, threats, and vulnerabilities;
- Assessment of the impact of threats and vulnerabilities on device functionality and end users / patients;
- Assessment of the likelihood of a threat and of a vulnerability being exploited;
- Determination of risk levels and suitable mitigation strategies; and
- Assessment of residual risk and risk acceptance criteria.
As mentioned above, and especially software / firmware, initial design and subsequent continuous improvement activities must consider hazards / risk, per ISO 14971. Such risk is focused on the end user – patient and/or clinician. The hazard analysis should address both “normal" as well as “fault” risks, i.e., not just failure mode risk, the most prevalent approach, but also risk posed by the proper function of the product. In such an analysis, the manufacturer must also consider cybersecurity as part of this regular hazard analysis. Exposure to the web, as in the networked devices focused on in this guidance, increases such cybersecurity risks to the patient / clinician. Hazard / risk analysis’ goal is risk mitigation, documented in the Risk Management File and Report (ISO 14971), as well as in the Design History File (21 CFR 820.30). Consider system boundaries and connections to the external environment. In all such analysis, software must be considered with its associated hardware.
The above is to be supplemented by on-going monitoring of actual and potential vulnerabilities, consistent with the Quality System Regulation (21 CFR part 820), including complaint handling, internal quality audits, CAPA (corrective and preventive action), software validation and risk analysis, and servicing. Such programs should emphasize addressing vulnerabilities which may permit the unauthorized access, modification, misuse or denial of use, or the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient, and may impact patient safety.
The Agency defines critical components of such a program to include:
- Monitoring cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk;
- Understanding, assessing and detecting presence and impact of a vulnerability;
- Establishing and communicating processes for vulnerability intake and handling;
- Clearly defining essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk;
- Adopting a coordinated vulnerability disclosure policy and practice; and
- Deploying mitigations that address cybersecurity risk early and prior to exploitation.
Postmarket cybersecurity information may originate from an array of sources including a company’s own CAPA / warranty / complaint system, independent security researchers, in-house testing, suppliers of software or hardware technology, health care facilities, and information sharing and analysis organizations. To manage postmarket cybersecurity risks for medical devices, a company should have a structured and systematic approach to risk management and quality management systems consistent with the CGMPs.
Per the guidance, it is the device manufacturer who incorporates software in their medical device, that bears the primary responsibility for the continued safe and effective performance of the medical device / system, including the performance of the software that is part of the device / system. This is instead of the user or a contract programmer / software developer. FDA recommends that purchasers and users of medical devices who may be subject to a cybersecurity vulnerability contact the manufacturer with their concerns. Even when there are times when it is appropriate for the user to become involved, the user should not attempt to make changes without seeking the manufacturer’s advice and recommendations.
Software patches that address cybersecurity vulnerabilities are addressed in general in the CGMPs. For example, the need to be vigilant and responsive to cybersecurity vulnerabilities is part of a company’s obligation under CAPA. The preamble to the QS Regulation explains that actions taken should “be appropriate to the magnitude of the problem and commensurate with the risks encountered”, i.e., “risk-based.” Design validation requires that devices conform to defined user needs and functional requirements, including an obligation to perform software validation and hazard / risk analysis, where appropriate.
Software changes to address cybersecurity vulnerabilities are design changes, and thus must be verified / validated before approval and issuance. However, FDA premarket review is not usually required prior to implementation of a software patch to address a purely cybersecurity vulnerability for a previously cleared / approved device.
In general, FDA review is necessary when a change or modification could significantly affect the safety or effectiveness of the medical device (see also FDA Memorandum K 97-1, and their two recent draft guidances on changes to a device having a 510(k), one specifically addressing software). This is to allow an FDA review of any issue that affects a risk to health posed by the device, and should be the key determinant in making such a decision on the need for an new regulatory review.
Thus, it is possible, but unlikely, that a software patch will need a new 510(k) submission. And the more robust the V&V of the patch / change, the less likely the requirement for a new submission would be. As with all changes made to devices, a company must document the basis of its decisions in the Design History File (DHF) and/or related CGMP documentation.
However, for medical devices approved under Premarket Approval Application (PMA) (21 CFR Part 814), a PMA supplement is required for a software patch, if the patch:
- Results in a change to the approved indications for use; or
- Is deemed by the manufacturer to have an adverse effect on the safety and effectiveness of the approved medical device.
Note: The two points above are also “red flags” for changes to devices covered by a 510(k) that would probably also require a new 510(k).
Otherwise, the company should report its decision to apply a software patch to its PMA device to the FDA in its annual reports.
In all cases, validation of software changes made to address cybersecurity vulnerabilities is required. All software design changes must be verified / regression tested / validated, including those computer software changes to address cybersecurity vulnerabilities. This would be in accordance with an established protocol, before approval and issuance. However, for most software changes intended to address cybersecurity vulnerabilities, analysis, inspection, and testing – documented -- should be adequate and clinical validation should not be necessary.
The manufacturer should always maintain formal business relationships with their OTS software vendors to ensure timely receipt of information concerning quality problems and recommended corrective and preventive actions – perhaps by means of the contract or a Quality Agreement. Because of the frequency of cybersecurity patches, the FDA’s Guidance recommends that the company develop a single cybersecurity maintenance plan to address compliance with the QS Regulation and the issues discussed in the guidance document.
Although the guidance recommends that the medical device manufacturer to perform these software maintenance activities, there may be situations in which it is appropriate for the user facility, OTS vendor, or a third party to be involved. The software maintenance plan should provide a mechanism for the manufacturer to exercise overall responsibility while delegating specific tasks to such other parties. The vast majority of healthcare organizations will lack detailed design information and technical resources to assume primary maintenance responsibility for medical device software and will have to rely on the manufacturer to assume the primary maintenance responsibility.
Lifecycle considerations require that the expected growing knowledge of the science of the product and its manufacturing process / equipment translate into manufacturing improvements, and reduction in variation, consistency / homogeneity within lots, and consistency / homogeneity between lots, improved product quality, all reflected in subsequent V&V activities. See FDA’s Guidance on Process Validation.
The training of personnel in detecting data integrity issues is also required as part of a routine CGMP training program. Training personnel to detect data integrity issues is viewed as consistent with the personnel requirements discussed in the CGMPs.
As stated at the outset, Cybersecurity is a relatively new term for the CGMP community. As hacking of networked electronic systems has become more prevalent, cybersecurity requirements are also being added. Increasingly, manufacturers and users will have to demonstrate their ability to provide for cybersecurity to achieve full CGMP compliance when such vulnerabilities exist in their systems. This is the expectation and demand of all such systems / records stakeholders, not just regulatory agencies.
# # #
CAPA Corrective and Preventive Action (see 21 CFR 820.100)
CDRH U.S. FDA’s Center for Devices and Radiological Health
CGMPs Current Good Manufacturing Practices (for devices it is 21 CFR Par 820,
Quality System Regulations)
CFR The U.S. Code of Federal Regulation
FDA The United States’ Food and Drug Administration
ISO International Standards Organization
NIST U.S. National Institute of Science and Technology
OTS Off-the-shelf [software]
QA Quality Assurance
QC Quality Control
QMS Quality Management System
QS Quality System
R&D Research and Development
SOP Standard Operating Procedure
V&V Or V[T]&V; Verification [Testing] and Validation. Per the FDA, in computer science, validation refers to ensuring that software meets its specifications. However, this may not meet the definition of process validation as found in guidance for industry Process Validation: General Principles and Practices: “The collection and evaluation of data … which establishes scientific evidence that a process is capable of consistently delivering quality products.” See also ICH guidance for industry Q7A Good Manufacturing Practice Guide for Active Pharmaceutical Ingredients, which defines validation as providing assurance that a specific process, method, or system will consistently produce a result meeting predetermined acceptance criteria.
John E. Lincoln, principal consultant, J. E. Lincoln and Associates LLC, assists companies in the design and implementation of complete 21 CFR 111, 210, 211, 820 and ISO 13485 quality management systems, fully CGMP-compliant, and which have passed FDA audits. He compiles 510(k) submissions, new and changed, product Risk Management Files / Reports per ISO 14971, Design History Files, Technical Files, and Design Dossiers. He assists companies in remediation / FDA responses, SOP writing, audits, validations, including software. His work is described in peer-reviewed technical articles and workshops, world wide. John has also managed pilot production, regulatory affairs, product development / design control projects. He has over 35 years of experience, 21 as a full time consultant, primarily with medical devices – working with start-ups to Fortune 100 companies. He is a graduate of UCLA. John can be reached at firstname.lastname@example.org