Devices that treat the patient must protect the patient

The US Food and Drug Administration (FDA) has long mandated the use of quality systems to ensure that medical devices are safe and effective for their intended purpose for both the patient and the operator of the device. As Jay Thomas of LDRA Technology highlights, that safety and effectiveness also relies on security in the increasingly connected medical environment.

Today’s medical devices must not only comply with FDA requirements for safety and effectiveness, it is also imperative that they be secure from unauthorised access and hacking, both for patient and operator safety as well as privacy, as mandated by laws such as HIPAA. If the devices are not secure, they cannot be considered safe or reliable. Thus the requirements for safety, reliability and security are inseparable and interdependent, and must be designed-in from the ground up, not as an afterthought.
Implementing security involves a number of aggregating strategies including the use of secure booting and firmware upgrades, encryption, password protection, recognition technologies and device, firmware and software authentication. Secure transfer protocols such as transport layer security (TSL), which is an improvement over the secure sockets layer (SSL), and the secure file transfer protocol (SFTP) are now widely used but are often acquired from outside the organisation. However, using these (by either importing them or writing them from scratch) can also introduce flaws that result in security vulnerabilities. This raises new concerns around software of unknown pedigree (SOUP). In fact the FDA has published a set of guidelines for hazard analysis and mitigation in off-the-shelf software, which can be of value for evaluating SOUP code. Even code that is considered safe and reliable, especially if it is third party code, must be suspect.

Read more: Electronic Specifier