We specialize in software security assessments, FDA cyber-security and HIPAA compliance for medical device vendors in Israel.
The first question that every medical device vendor CEO asks us is “What is the fastest and cheapest way for us to be HIPAA-compliant”?
So 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 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.
