So you are getting ready to run medical device clinical trials with your mobile medical app or a medical appliance that is connected to the Internet via Wifi in the patient’s home network.
How do you secure your device and your cloud systems and how do you comply with the HIPAA Security Rule that is a requirement when you work with hospitals and exchange clinical data inside the United States.
Security starts with understanding network connectivity and clinical data flows.
The common denominator of all mobile medical devices in clinical trials is that you have a medical device with Internet connectivity that is being used to transmit clinical data to 2 systems in the cloud:
#1 – A cloud service operated by the mobile medical device vendor collects PRO and device log data.
# 2 – A cloud EDC system (Clincapture, Medidata, Medrio, iMednet, IBM Clinical Development to name a few) is operated by a CRO or the sponsor themselves who buys a cloud EDC subscrption for SaaS (software as a service).
The EDC system receives a subset of PRO data and device log data and interfaces that data at some point in time to a ECRF. I say at at some point in time – since most EDC systems including the big ones like Medidata do not have real-time API’s that can receive transactions or streaming data from a mobile medical device. The point in time may vary from real-time (as in the Clear Clinica systems) to far down the road, where the PRO data is merged with the ECRF data at the end of the study. Like they say – YMMV – your mileage may vary.
EDC vendors support a file upload or Web service operational model that can receive a batch of data to post to a CRF (after the subject and study events have already been entered). Indeed, batch processing of clinical data from mobile medical devices into a CRF can create significant timing and patient compliance and monitoring issues that are generally unacceptable to the mobile medical device vendor who is accustomed to living in a real time world. But that is a topic for a separate post.
Where does the HIPAA Security Rule figure into this setup? Do I need to comply with HIPAA or not?
First of all, the HIPAA Security Rule is the operationalization of the HIPAA Privacy Rule – translating the Privacy requirements into a set of standard physical, administrative and technical security countermeasures.
The HIPAA Privacy Rule establishes the conditions under which protected health information may be used or disclosed by covered entities for research purposes. Research is defined in the Privacy Rule as, “a systematic investigation, including research development, testing, and evaluation, designed to develop or contribute to generalizable knowledge.” See 45 CFR 164.501. A covered entity may always use or disclose for research purposes health information which has been de-identified (in accordance with 45 CFR 164.502(d), and 164.514(a)-(c) of the Rule) without regard to the provisions below.
The Privacy Rule also defines the means by which individuals will be informed of uses and disclosures of their medical information for research purposes, and their rights to access information about them held by covered entities. Where research is concerned, the Privacy Rule protects the privacy of individually identifiable health information, while at the same time ensuring that researchers continue to have access to medical information necessary to conduct vital research.
Informed consent forms protect the researcher but who protects PRO and medical device data in the cloud?
A cloud instance (or set of cloud services ) is operated by the mobile medical device vendor. This is part of the business model of mobile medical devices.
The business model of most mobile medical device vendors is to collect patient data in order to monetize it further down the road (most mobile medical device vendors don’t know exactly what they will do with the data or how they will exactly monetize it in the future, but since they are not alone in drinking the big data Kool-Aid – they have a blind belief that by accumulating lots of patient data in the cloud – somehow they will discover gold in the future.
However – if you are collecting patient data from people who live in the EU, you will have to comply with the GDPR but that is a topic for a separate essay.
So regardless of your EDC system, you (the mobile medical device vendor) have exposure to security and privacy vulnerabilities since you are storing (at the very minimum) clinical data generated by your device and possibly personally identifiable information (PII) like phone numbers and email.
After this lengthy introduction we get to point of this article: how does a mobile medical device vendor achieve security and privacy compliance.
Here are the top 5 things a medical device vendor should do in order to achieve HIPAA compliance:
1. Don’t store EPHI
If you can, do not store EPHI in your system at all. That way you can side-step the entire HIPAA compliance process. (This is not to say that you don’t have to satisfy FDA cyber-security requirements or have strong software security in general but that is a separate issue).
What is EPHI? EPHI (electronic protected health information) is any combination of PII (personally identifiable information and any clinical data. OK – you ask so what is the definition of PII from the perspective of HIPAA? Basically – PII is any combination of data that can be used to steal someone’s identity – in a more formal sense – here is a list of PHI identifiers:
– A name
– An address. The kind that FedEx or USPS understands
– Birth dates – age does not count.
– Phone numbers including (especially) mobile phone
– Email addresses
– Usernames of online services
– Social Security numbers
– Medical record numbers
– Health plan beneficiary number
– Account numbers
– Certificate/license numbers – any number that identifies the individual. A certificate on winning a spelling bee in Junior High doesn’t count.
– Vehicle identifiers and serial numbers, including license plate numbers;
– Device identifiers and serial numbers that can be tied back to a person
-URLs – that can be tied back to a person using DNS lookups
– IP address – for example the IP address of a home router that can be used to lookup an identify a person
– Biometric identifiers, including finger and voice prints;
– Full face pictures
2. If you store EPHI do a threat analysis of your medical device
The HIPAA Security Rule and the FDA cyber security guidance are very clear on this point. You can learn more about threat modeling and analysis here, here and here. Regarding encryption and medical device security, read this.
3. Implement software configuration management and deployment tools
The best single and cheapest piece of advice I can give a medical device vendor is to use Git. If you use Azure or are a Microsoft shop (our condolences – read here and here why Windows is a bad choice for medical devices) then TFS is a great solution that is integrated nicely in Azure. Note that Azure is a great cloud solution for Linux as well. Don’t get me wrong – Microsoft does a lot of things right. But using Windows for medical devices is a really bad idea.
4. Implement log monitoring
Monitoring your logs for peaks in CPU, memory or disk usage is a great way to know if you’re being attacked. But – if you have medical device logs and no one is home to answer the phone then it’s a waste of time.
5. Make sure the lights are on and some one is home
You’ve done a great job on your medical device software. You did Verification and Validation and you implemented threat modeling in your development process and you have logs. Just make sure that it’s someone knows that it’s their job to keep on eye on security events. If you get a notice from a customer or a ping from your log manager, or an email from your cloud provider that they’re gonna reboot your services because of VENOM – just make sure the lights are on and some one is home.
In summary
Robust security for your medical is not fortune telling but neither is it an organizational construct. The best way to think about your medical devices is to think about something you would give a child (or a soldier on the battle field). It has to totally reliable and safe for the patient even under the most adverse conditions.
