Scientific Advisory Committee Digital Health Technologies (SAC-DHT) November 23, 2018 Record of Proceedings
- Core committee members present: Joseph Cafazzo (Chair), Aviv Gladman, Kim Hanson, Trevor Jamieson, Kumanan Wilson
- Ad hoc committee members present: Agoh Josué Béké, Laura Elan, Jason Jaskolka, Jared Perry, Chris Simotas
- Regrets: Kendall Ho, Chris Kamel
- Stakeholder presenters: Stefan Feix, Dana O’Born, David Bissessar (by teleconference), Brian Courtney (by teleconference), Graeme Moffat (by teleconference), Jim Waters (by teleconference), Alex Kent (by teleconference), Colin Morgan (by teleconference)
- Health Canada presenters: Marc Lamoureux, Patrick Fandja, Ursula Polack
- Health Canada observers: Patrick Assouad, David Boudreau, Tyler Dumouchel, Michelle El-Hage, Ian Glasgow, Reeham Hammouda, Karin Hay, Janet Hendry, Shawn Hopewell, Catherine Milley, Despina Miteva, Justin Peterson, John Patrick Stewart, Ying Wang, Daniel Yoon
- Other observers: Cory Clark (Communications Security Establishment), Di Jiang (National Research Council), Sally Prawdzik (Johnson & Johnson)
Welcome and opening remarks (John Patrick Stewart)
The Director General of the Therapeutic Products Directorate (TPD) welcomed the scientific advisory committee members. He provided context for the meeting, that is, to discuss questions relating to digital health and cybersecurity with respect to medical devices.
He explained the process to be used for the meeting, and once again thanked the committee for their time and for providing advice to Health Canada. He then handed the meeting over to the Chair of the committee.
Chair’s remarks (Joseph Cafazzo)
The Chair thanked members for participating in this meeting. He confirmed acceptance of the agenda for the meeting. He then led the panel members in a verbal update of declarations of affiliations and interests from those initially declared. No declarations required any restrictions on members’ participation.
Presentations 1 - 5:
Presentation: Stefan Feix, MEDEC
The presentation provided an overview of MEDEC’s position on digital health and cybersecurity. Patient safety should be the primary concern for any policy and regulatory decisions by Health Canada and be distinct from security issues. Cybersecurity is a shared responsibility between users and manufacturers. MEDEC recommended that policies and fixes should have no unique Canadian requirements and use international standards to ensure the fastest deployment and the least burden. Any new regulations would also need to consider the impact on legacy devices.
Presentation: Dana O’Born, David Bissessar, Graeme Moffat, Brian Courtney, Jim Waters, Council of Canadian Innovators (CCI)
The presentation gave the perspective of CCI on the direction of digital health and how Health Canada should focus their efforts.
Presentation: Alex Kent, Medtronic
The presentation provided an overview on Medtronic’s activities related to cybersecurity.
Presentation: Colin Morgan, Johnson & Johnson (J&J)
The presentation provided an overview of J&J’s activities related to cybersecurity.
Presentation: Marc Lamoureux, TPD; Patrick Fandja, Marketed Health Products Directorate; Ursula Polack, Regulatory Operations and Regions Branch
The presentation provided an overview of Health Canada’s regulatory framework for medical devices and the responsibilities for each component of the Medical Devices Program: Pre-market licensing, post-market surveillance, and regulatory compliance and enforcement.
Deliberations on the questions posed to the committee (all members)
Issues raised by the committee, in questioning the presenters and in discussion, included, but were not limited to:
- What international standards should be followed for cybersecurity?
- Have any patients been harmed from a malicious attack?
- Is the overall approach taken by the United States Food and Drug Administration (US FDA) sufficient?
- What should post-market standards look like?
- Would a mechanism for Health Canada to force a recall or patch a vulnerability be supported?
- Hospitals cannot provision medical devices endpoints because they do not comply with standards associated with provisioning devices. Would industry support standards around how devices are provisioned within a network?
- Thoughts on the US FDA Precertification Program?
- Would industry support making certain devices available to the security research community for testing or utilizing a “bug bounty” program?
- How would industry define “patient safety”? What is risk tolerance for cybersecurity?
- How can industry ensure that personal information collected by the device is used only for its intended purpose?
- Is two-factor authentication realistic for citizen consumers (as opposed to enterprise organizations)?
- How can the regulator evaluate complex datasets that would ideally require experts from multiple and diverse specializations?
- What are the roles and responsibilities of manufacturers and patients with respect to patient data?
The above list is by no means exhaustive and is intended only to give a sense of the type of issues discussed by the panel.
Remarks from Diabetes Canada (Kim Hanson)
The member outlined the need to balance device security and patient safety with the ability of the patient to access their own data captured by medical devices. Some diabetes patients have been forced to modify their devices to create a closed loop system and send their data to the cloud for accessibility. The following statements were made for consideration:
- Patient safety needs to consider the value the device brings to patients
- Any regulations that do not support rapid innovation may exacerbate patient cybersecurity risk
- It must be determined if risks are specific to the device and software as opposed to the condition itself
- A recognition that views are continuously changing on risk tolerance, the need for information, and privacy definitions
- Data should be democratized and owned by patients. Regulations intending to protect patients may unintentionally limit access to their own data and create some risk.
In response to the questions posed by Health Canada, the committee provided the following recommendations:
What do you believe are the most pressing emerging trend(s) in Digital Health? What do you believe will be the largest challenge facing Health Canada in regulating medical devices related to Digital Health as it carries out its mandate in helping the people of Canada maintain and improve their health?
Some of the trends that are emerging or have emerged are the following:
- Connectivity, compatibility, and interoperability between software and hardware of various forms.
- Electronic health records (EHRs) may need to be regulated in the future as they become more integrated with devices and/or provide advanced decision support.
- Self-management and ownership of data by patients, rather than through a clinician.
- Devices and sensors integrated into daily products such as home environments, wearables, and clothing.
- Democratization of innovation is emerging and is not restricted to manufacturers anymore.
Some of the challenges are the following:
- What happens when a device is put into a larger ecosystem? Will regulations capture activity of the ecosystem when looking at the device in isolation?
- Keeping up to date on technologies, creating framework and regulations that are more dynamic and agile than what currently exists, alignment with international partners and changes over time.
- Interaction between EHRs and devices create new systems. Regulating integrated/connected EHRs may be required in the future.
- The pace and volume of innovation of devices/apps and the interactions they create in a dynamic healthcare system.
- The separation between the device and its environment.
- Ensuring that regulation does not stifle innovation.
- Legacy devices will likely not meet newly created standards for security controls.
- Ensuring that digital health apps/devices are brought to market expeditiously so consumers do not seek them from other jurisdictions.
The committee also recommended that patient and citizen input must be strengthened and maintained as the regulatory environment is developed. Patients will eventually have ownership of their own data and will be impacted more by regulatory decisions than manufacturers themselves.
The Digital Health landscape is evolving with technologies not easily regulated under the current regulatory framework. An example of this is machine learning algorithms which mask some of the software’s behaviour. How can Health Canada facilitate the market emergence of innovative medical device software, such as machine learning algorithms, while ensuring that it remains safe and effective for the people of Canada?
It is important to understand the data on which the machine has been trained as part of assessing the value of the algorithm. The inclusion criteria for AI algorithms are the characteristics of the dataset on which it was trained, which differs from traditional inclusion criteria based on patient profiles. Algorithms have been shown to become unreliable when presented with data that is outside the parameters of the training values. Likewise, for algorithms that utilize reinforcement learning, the source of the data becomes a key aspect of whether the system continues to work. There is a risk in approving machine or deep learning systems if the data used to train the devices is not representative of the Canadian population.
It is easy to mask the supporting evidence used to make claims and it may not be possible to accurately assess datasets as they may require expertise in several diverse specializations. Developing a system that can leverage data and utilize real world data is key.
Risk mitigation is also important and will be dependent on the program. For example, algorithms that require human involvement will be easier to risk manage than an autonomous algorithm that requires more post-market evaluation.
Conditional licensing and continuous reporting as a product develops, indications expand, and sensitivity/specificity improves are potential schemes that were discussed by the International Medical Device Regulators Forum (IMDRF) and the US FDA Precertification Program that Health Canada could adopt.
What cybersecurity measures are already in place in healthcare facilities and what additional steps could be taken to fill any gaps in these cybersecurity measures for medical devices? Is a hospital local area network (LAN) considered safer than a home network or a direct connection to the internet?
Yes. Variability exists between hospitals but in general, annual reviews of network security are required. White hat testing and intrusion detection are some of the tests performed. However, legacy devices, software, and operating systems are susceptible to malicious attacks through phishing and the use of external USB keys.
Provincial privacy legislation is pushing facilities in the right direction but no international standards are currently required. Additionally, password requirements designed to protect systems may be contributing to weaker security as users write – and lose – paper notes containing their passwords. Multi-factor authentication would be a better approach, although this can be cumbersome for users if not executed well. Advanced biometrics, well executed, could be a future solution and should be encouraged.
A device’s interaction with data on the LAN may also pose risk. It is not possible for hospitals to secure or provision individual medical devices and they must rely on manufacturers. Segmentation and proper configuration are methods of mitigating risk. There has been discussion amongst hospitals about assisting smaller clinics with their security burden since those clinics are an entry vector into hospital networks and could potentially be used to compromise them.
What level of information about identified cybersecurity issues should be provided to potentially affected users? Do the benefits of fully informing users about known issues outweigh the potential risks of malicious use of the broadly exposed issues?
Clinicians may not be the most appropriate people to inform users of data security breaches unless the breach affects clinical care. Malicious actors likely already know of the vulnerabilities so there is no real risk in exposing broad issues.
In the security community, standards exist for the coordinated disclosure of vulnerabilities. The US FDA is also starting to enforce coordinated disclosure and Health Canada should consider coordinating Canadian-specific disclosures through a Canadian body rather than an American organization. Disclosure requirements should be strong enough to require manufacturers to remediate or mitigate vulnerabilities in addition to disclosing them.
Data breaches are mostly dealt with through privacy legislation. For patient safety disclosure, the onus to inform should be on everyone who knows of the issue and different levels of notifications can occur: Public and media attention to spur the manufacturer to action; clinician/hospital awareness to configure the device to mitigate risk; and patient awareness if something can directly harm them. More can be done though to establish timelines for the different levels of notifications to mitigate or address vulnerabilities. The current definition of controlled risk is too soft. The regulator should ensure that vulnerabilities are mitigated or fixed. Patients must understand the relative risks when being informed of the vulnerabilities and what they can do to mitigate risks in the short-term, for example turning off the wireless capabilities of their device.
Vulnerabilities in a device may expose vulnerabilities in other devices marketed by different manufacturers that use the same software. This may result in manufacturers being reluctant to disclose anything or attempting to downplay any risk.
What are the best cybersecurity risk mitigation practices for various intended use environments (e.g. home use, clinic use) for medical devices? Are there fundamental differences between the different use environments that should be considered in terms of cybersecurity? If so, what are the fundamental differences?
Hospitals are in a controlled, isolated environment for outbound data compared to a home or clinic setting. Some devices are configured to be in constant communication with the outside, which is not permitted in hospitals.
Security should be designed for the lowest common denominator, i.e. the widest usage, and the manufacturer should be responsible for mitigating as much risk as possible. There cannot be an assumption that an environment is safe. Additionally, there needs to be a minimum framework and updating mechanism in place as encryption is effective for a certain time period before it can be decrypted by more powerful computers.
Designing devices with a “zero trust” environment develops a model that captures threats and future-proofs the devices. At the same time, context is important and should not create barriers to entry for new manufacturers. This may require different levels of security assurance. This must also be augmented by a regulatory environment that tests for the ability to respond.
Decrypting systems compromise the confidentiality and integrity of the device and its data. Control of proprietary data should be a separate regulatory discussion.
The FDA recommended premarket submission documentation, which includes a summary describing controls in place to ensure integrity from the point of origin to point when the device leaves the manufacturer. Should manufacturers demonstrate controls in the cybersecurity of their own computing infrastructure at their site, or can we assume this is captured by International Organization for Standardization (ISO) 13485:2016 compliance?
ISO 13485 is not security-specific and there are more appropriate ISO standards such as ISO 27001. A combination of this framework with other standards would be useful. Looking beyond the supply chain and software and analyzing hardware and the whole lifecycle management process would be necessary.
In Canada a recall of a medical device is defined in the Medical Devices Regulations as:
any action taken by the manufacturer, importer or distributor of the device to recall or correct the device, or to notify its owners and users of its defectiveness or potential defectiveness, after becoming aware that the device
- may be hazardous to health;
- may fail to conform to any claim made by the manufacturer or importer relating to its effectiveness, benefits, performance characteristics or safety; or
- may not meet the requirements of the Act or these Regulations.
Additionally, Section 34 of the Medical Devices Regulations outlines that a device licence amendment is required for any significant change to a Class III or IV device. A “Significant Change” means a change that could reasonably be expected to affect the safety or effectiveness of a medical device including, among other things, the design of the device, including its performance characteristics, principles of operation and specifications of materials, energy source, software or accessories.
In order to balance pre-market safety with post-market agility in deploying rapid corrections, Health Canada would like to consider how to best handle recalls and licence amendment authorizations in cases of certain patches, updates, or fixes in response to a cybersecurity issues.
- What would be the manufacturer's expected timeline to deploy a fix?
- Is there a delay that would be simply too long from a risk perspective?
- What should Health Canada consider when determining if a cybersecurity fix is a recall or a pre-market licence amendment application?
- Should Health Canada consider adopting the US FDA’s concept of “Controlled vs. Uncontrolled Risk of patient harm” as the basis for reporting issues to the regulator?
The timeline to deploy a fix should depend on the benefit-adjusted risk of the significant change and other factors such the effects to patient safety (e.g. whether the vulnerability is a health hazard versus conforming to regulations). Most organizations require the vendor to have a fix before disclosure, and thus disclosure is ultimately a forcing function to get the fixes. The security community typically gives 30 - 90 days for issues to be fixed before disclosing the vulnerability. There are exceptions to the program where the community will work with manufacturers if there is evidence that the manufacturer is resolving the vulnerability. Manufacturers are recommended to have a fix before disclosure, however it is acknowledged that there could be a case where disclosure is important but a fix is not ready.
Further context is needed to adequately address b). Determining whether a delay is “too long” depends on a number of factors such as the size of the market and the number of people who are exposed. Different levels of risk would require different timelines. Manufacturers would know timelines best. Standards exist for classifying vulnerabilities and in other industries, manufacturers tend to manipulate the classification at a lower level to avoid certain issues and allow more time to fix the issue. Although PHI (personal health information) is governed provincially, should it be in scope at the federal level?
Health Canada clarified the question by asking what considerations should be made when identifying a defective product versus routine maintenance/patching?
It is unknown if a cybersecurity issue could render a device defective. Once a vulnerability is disclosed, Health Canada should perform an impact analysis to determine if a recall or any other action is required. Changing the medical function or intended use should require an amendment whereas a security-only issue should be covered by a recall. Even in urgent cases, validation and integrity checks must still be carried out by both regulator and manufacturer to prevent “bricking” the device.
Some kind of framework and classification system is needed and future language should be strengthened to ensure that the assessment is not made only by the manufacturer.
Should the responsibility be put on the manufacturer to monitor post-market cybersecurity issues (e.g., built-in software to detect any abnormalities). If so, what are the best practices that are currently in place to monitor for cybersecurity issues that manufacturers should adopt? Should Health Canada request periodic reports from manufacturers documenting information concerning cybersecurity vulnerabilities?
Manufacturers should make their devices more accessible to security researchers for testing and refrain from legal prosecution for the disclosure of vulnerabilities. An industry best practice that is emerging is the use of “bug bounty” programs that crowd-source security researchers to test for vulnerabilities in their spare time.
Vulnerability reporting should be coordinated by people who have the expertise to assess them. There are several bodies in the US that utilize this. Responsibility in Canada currently rests with the Cybersecurity Centre. A similar model that can triage risk and disclosure could be looked at. Manufacturers should be expected to report to Health Canada on the best practices they are employing to stay current on cybersecurity. This reporting could be incorporated as a metric of ISO 13485.
Closing remarks / Adjournment (Chair)
The Chair and Health Canada thanked the members for their participation. The meeting was adjourned.
Report a problem or mistake on this page
- Date modified: