Cybersecurity: New Area for Mobile Medical App Compliance, Part 2

Cybersecurity New Area for Mobile Medical App Compliance, Part 2The following is a guest contributed post from AirStrip’s Vice President of Quality Assurance and Regulatory Affairs, Andy Miller.

The trap many developers – from software architects to programmers to designers – fall into is thinking they know enough about cybersecurity to adequately identify and address the risks, while falsely relying on the underlying OS for protection.

It is important to remember, cyber criminals are professionals diligently working on new ways to exploit networks, mobile phones and applications. Anything connected to the Internet must be assumed to be actively under attack, and even more so if the information within these devices is considered valuable. Reuters reported in 2014 that patient health credentials are 10 to 20 times more valuable than credit card numbers. The reality is that any network connection enabled by an app may introduce new risk.

Assuming otherwise technically competent development teams have the acumen to defend medical devices can be a serious gamble. Unless actual security professionals are part of the engineering staff, software companies are potentially putting the security profile of medical devices at risk.

Cybersecurity is not a casual concern; it is a serious matter. Both the FDA and the Department of Homeland Security have issued warnings that hospital medical devices can be easily hacked. Further, U.S. HIPAA/HITECH regulations require that manufacturers of medical devices that transmit and/or store protected health information have a company security program in place.

Frustratingly, the FDA can only regulate the medical devices it knows about. Remember the wide swath of essentially unregulated devices, which the FDA deemed not to pose an immediate risk to patient safety? Since these devices are not regulated, there is no requirement for the device makers to comply with the agency’s minimal cybersecurity guidance. These devices, in many cases, connect directly to patient health records and/or present clinical data to their user. The vulnerability here should be obvious.

So, what can be done?

The first step to all recovery is admitting there is a problem and that help is needed. Someone on every software-containing medical device manufacturer’s staff should be an information-security professional. If not, one should be hired or developed internally, or consulting assets should be leveraged. There are several professional designations to look for – Certified Information Security Manager (CISM) being the most applicable. These professionals have been trained to take a comprehensive look at a company’s security posture, identify and prioritize risks and track their remediation.

Next, manufacturers should stop looking at cybersecurity as a technical issue. Cybersecurity is not a bug. Mitigations to many cybersecurity risks are technical in nature, but the best answer is to institute a comprehensive compliance and security program, which encompasses all aspects of corporate operations and has executive sponsorship. Many corporations allow compliance programs to become paperwork exercises. They do this at their peril.

Finally, there is no need to reinvent the wheel. All compliance programs should follow an established standard, and information security has several to choose from. Internationally, the obvious choice is ISO 27001. Domestically, the HHS website cites the National Institute of Standards and Technology (NIST) Cybersecurity Framework for security compliance. NIST is a federal agency that sets security standards for the federal government. Whichever one is chosen depends largely on where the product is marketed. While the two have similarities, apps marketed in the U.S. – especially to the government – should follow the NIST Framework.

It is important to remember that simple regulatory compliance is only the first part of a successful mobile health application. When it comes to cybersecurity, it is vital to be proactive instead of reactive, especially when the system being secured can potentially leave a patient exposed to harm.

This post was written by:

- who has written 2086 posts on mHealthWatch.


Contact the author

0 comments
Advert