I don't quite see the reason for this with the cloud. Amazon has a whitepaper on AWS with HIPAA and I've seen some startups give presentations about their implementation in the AWS conference.
There's some misinformation on your website, "HIPAA compliance is costly and hard to get right" It's not. It's almost cheaper to sign an EA with Microsoft and use Azure (who by the way also sign a BAA) than your pricing. I also couldn't find any mention of what redundancy you use or any mention of uptime.
HIPAA compliance is basically encryption + access control + logs + redundancy with a few other simple features. All of which are easily accomplished with AWS or Azure. BAAs between you and your hosting provider are not necessary unless you have access to the PHI (Amazon doesn't, Azure does).
The biggest red flag to me is that this doesn't (as one might assume) absolve the developer from liability / responsibility. If it were to come to light that your business is (I don't think any of these things about you) corrupt/poorly run/hacked/breached/etc. the developer is then liable to immediately remedy the situation which may include being required to move elsewhere. That would be a huge disruption to any service as they would have to build a system from scratch while somehow still operating. This would be the only reason I would switch my apps from AWS to your service but unfortunately this is not the case. The fact also remains any HIPAA violation would be more likely in the implementation of the webapp (i.e. allowing images to be cached) and not in the storage of it. Leaks of encrypted PHI aren't even an issue with HIPAA.
You have the issue of being new and without a reputation while I can still be liable for your mistakes. While you have insurance it's not really feasible to sue someone as a startup. Anyone not a startup would find your pricing way too expensive.
TL;DR: BAAs do not remove liability, HIPAA compliance isn't nearly as complex as other regulatory bs, AWS and Azure are both easily made HIPAA compliant.
We think of ourselves as Parse for healthcare sites/apps/devices.
One can absolutely build their own Parse to power their own stack, but it may not be time/resource effective. Behind the scene, among other things, we provide unique object encryption and automatic object re-key and re-encryption -- mechanisms one would have to be custom build for a homegrown HIPAA environment (event on AWS).
We make sure the Protected Health Information our customers collect is always in compliance with HIPAA despite the ever changing healthcare regulatory landscape.
But you are absolutely right. We do not absolve the developers/covered entities from all HIPPA liabilities and responsibilities. We just take care of one aspect of HIPAA so they can focus on other things.
It's important to keep in mind that Amazon's HIPAA whitepaper is horribly out-of-date in light of the new Omnibus rules that were passed earlier this year:
The new regulations require you to sign a BAA with Amazon if you are storing PHI on their servers.
Having gone through the process of building a "HIPAA-compliant" product, I wouldn't underestimate the extra work that HIPAA requires. The encryption requirements really limit the third parties you can work with, so you often have to end up building a lot of your own infrastructure and software.
TrueVault is in the process of being audited by a third-party auditor. We will soon be verified to be HIPAA compliant for the HIPAA technical safeguards. TrueVault will go through PCI Service Provider Level 1 certification soon thereafter. Feel free to contact us for details.
Hi - Yes, TrueVault does sign a BAA. We also carry a comprehensive cyber liability insurance that covers any post-breach costs and regulator fines (hopefully it'll never come to that).
Thanks, that's certainly worth noting, I think self-audits are a non-starter for HIPAA and PCI service vendors. If I were to recommend this to clients or implement as a storage option in one of our solutions, it would also be nice to have access to their SSAE16 docs.
They should know and expect that. It's a pretty standard request from enterprises' IT and/or Compliance depts when signing deals that involve storing data outside the firewall.
HIPAA, unlike many other compliance standards, cannot be "certified." This can lead to certain levels of open interpretation, but best practices are generally agreed upon.
Products like TrueVault provide excellent value, but security awareness training is the golden key to improve an organization's information security posture.
For an example of what I mean, consider the following scenario:
- Patient data (called Protected Health Information, or PHI) is stored securely in a TrueVault database. This database is accessible only from the hospital, and TrueVault has signed a BAA with the covered entity.
- A surgeon is prepping a kidney transplant for patient John Smith. The surgery is tomorrow morning, and Dr. Goofböl wants to make sure he's familiar with the patient's medical history.
- Dr. Goofböl, an authorized viewer of this patient's PHI, accesses the data and begins to take notes. A new batch of PHI is now being created, as it contains medical information as well as identifying information of the patient (say, his name).
- Dr. Goofböl emails this document to himself (whether his work or personal email address--it doesn't really matter), and goes home for the night.
- Dr. Goofböl stops at a nice coffee shop on his way home, and his personal laptop (without full-disk encryption) is stolen. The data is lost, and cannot be accounted for.
My company provides HIPAA Security Risk Assessments, and I've seen this exact scenario play out many times, albeit with other "HIPAA compliant storage" solutions, rather than TrueVault. There is absolutely a place for secure products like this, but security awareness training and the true gravity of identity theft and information loss needs to be ingrained in the medical industry.
"Security" for a hospital used to mean protecting doctors and patients from intruders (or mentally unstable patients). It used to involve burly men in white clothes; they're not used to thinking about where their information is traveling. Furthermore, the government is mandating that electronic health information be available to patients through web-based patient portals, which introduces a whole different level of potential vulnerabilities.
I truly believe that the healthcare technology industry is going to be one of the most booming sectors of the next decade, but there are major changes that need to occur to facilitate that. Hospitals need better IT infrastructures, more attention needs to be paid to security, and better tech personnel need to be brought into these environments. Only then can the next generation of healthcare technology truly succeed.
In your theoretical scenario, the doctor himself violated HIPAA when he emailed himself the document. He exposed the document to his email provider and all those along the transport path of the email. So, to agree, technology can only do so much, you have to use it correctly.
If the email server was provided by his workplace, then it was likely secured and HIPAA compliant. Most hospital email services are. Once the file is on his hard drive, most hospitals will require that the user uses some kind of encryption if it contains PHI. They enforce this by training and recertification procedures every year or so.
>Hospitals need better IT infrastructures, more attention needs to be paid to security, and better tech personnel need to be brought into these environments.
The only thing Hospitals/Healthcare needs is better leadership. Healthcare is lead exclusively by doctors who know next to nothing about information technology. Doctors find it very difficult to be advised by non-doctors. Take it for what you will but my opinion is based on 15 years in the industry and personally knowing/working with dozens and dozens of doctors in different specialties.
I've been suspicious of the value of Data Loss Prevention systems in other contexts, but do you think "endpoint" DLP could help reduce the Dr. Goofböl issue you describe? The surgeon has likely been made aware of the dangers of sensitive data in email. For whatever reason, this user is unable to comply with proper procedure. Can such a user really complain when placed in a DLP jail?
IMHO no technical solution can eliminate the proposed example of Dr. Goofböl, so it's pointless to attempt to do so - in any case he can scribble down the name+protected info+some notes on a paper napkin, lose it, and the result would be the same.
So training / social solution is needed anyways, but that's a worry for other industries, not tech.
...no technical solution can eliminate... so it's pointless to attempt to do so...
The premise of this proposition is correct, but not the conclusion. If a technical solution can alleviate a problem (and isn't dominated by some other, better technical solution) then it should be implemented to whatever extent is cost-effective. I don't imagine that no one has a slim jim that can open locked car doors, so that isn't the reason I lock mine. I lock them because the vast majority of people either can't or don't open locked doors they don't own. On the other hand, I know more people (who) are happy to duck into an unlocked car for a moment to quickly rummage the various nooks and crannies for small valuable items.
Most physicians want what's best for their patients, including Dr. Goofböl. It isn't the responsibility of a patient records system to regulate the tiny minority who don't. If the system can help physicians who are struggling in particular areas, by not making it easier to do the wrong thing than the right thing, that would be a benefit.
...some notes on a paper napkin, lose it, and the result would be the same.
These results ain't even in the same ballpark. I'm not particularly worried about the threat posed by my physician's maid.
As I said, however, I have yet to see DLP, especially endpoint DLP, be of particular value, so I'm genuinely curious as to David Shaw's opinion on this.
I agree, saying something is HIPAA compliant is meaningless. I am aware of HITRUST[1] and believe it's the closest thing to certification, do you have any experience with it, or are there others?
I think there are pros and cons of HITRUST certification.
On one hand, it does indeed have documented standards, and provides something for organizations to work towards and be audited against. On the other hand, especially for covered entities, an OCR audit (or actual breach) would not distinguish between whether the organization is HITRUST certified or not.
Said another way, it couldn't hurt, but we generally don't recommend it to clients who aren't otherwise interested in it. The last thing that we want to suggest is something that might provide a false sense of security.
Frankly, while certainly not trying to bite the hand that feeds, I think compliance standards are sort of a racket. Every year at conferences like DEF CON, there are presentations like "completely owning a PCI compliance network!" Even following each rule, if the purpose of security is to pass an audit instead of to genuinely secure information, there will be problems. HIPAA, for its lack of actual certification, at least is generic enough to request real security controls be put in place.
I'd rather have my information at an organization that cares about security instead of one trying to pass compliance standards.
Yes, good points. On the other hand, it makes things easier to point to a standard in lieu of answering security surveys with hundreds of questions, not always the same, from different prospective clients on a weekly basis. A certified standard would streamline this process. But, maybe that's why organizations each have their own survey in order to really gauge how well the org cares about security.
But if I understand correctly it is a data backend, right? So if there is any sort of web-based dashboard to accompany the app, and the PHI data has to be passed on to a server to display the dashboard then that server will have to be HIPAA compliant too, which brings the developer back to square one?
Hello - We are developing a library of JavaScript UI controls our customers place on their site to display protected content that's pulled directly from our server. We'll have display widgets as well as input widgets/forms like sign-in, sign-up, etc.
They are very much like Stripe's checkout JS form.
HIPAA compliance is a hugely important issue when it comes to developing medical applications. I think it's important to point out here that Box is now also apparently HIPAA compliant and signs BAA.
Still, there's room for a product that's easy to use and focuses purely on maintaining compliance.
Given how important this is, however, I would think the creators of the product would put some information about themselves and their backgrounds up on their site. It seems that's not done as much anymore with startups, but given they are a new company offering security of healthcare data, I think potential users would like to know.
There's legal red tape that can matter, for one thing. Any third party you use for this sort of thing potentially needs to sign a Business Associates Agreement with you that ties them in responsibility to your commitment to HIPAA compliance with your users... So there's at least some value to add in being willing to take on that level of legal responsibility.
There's also some value in a service run by folks who know the ins-and-outs and can help abstract or educate users. I meet lots of folks who want to write apps for healthcare but are terrified to wade into the murky regulatory waters. I've no experience with this particular service, but I do think there's room for vendors like this.
[background: developer in healthcare for 10+ years]
The service itself is not a big deal. The contracts that they're willing to sign are a very big deal. I've never had to do it before but my understanding is that getting vendors to sign those BAA contracts and get the indemnity insurance they offer is not trivial.
I don't think it's a big deal necessarily. First, "HIPAA Compliant" is mostly a marketing term as there is no certification, like for things like PCI. The main point of HIPAA is having policies in place that help prevent the unauthorized disclosure of PHI and track/trace authorized disclosure for auditing purposes. To make these policies effective you often need a BAA signed with vendors that can receive/store PHI, and many/most SaaS/PaaS companies are unable to do this.
Hint: As with PCI compliance (for credit card data), the hard thing with HIPAA compliance isn't the code but all the non-technical stuff. Legal stuff with regulations, validations, insurance, audits...
It's a few more lines of code more complicated that that :)
In all seriousness, we can give a talk on software security, encryption algorithms and network security with the setup we've created. To do it right, every system in our platform is segregated where one system doesn't see another -through software and network level security. Plus every piece of data is uniquely encrypted with rotating keys (that's kept isolated from the encrypted data). The level of security is like the Secret Service vs. Paul Blart the mall cop.
We are in the middle of writing a blog post about how we harden our platform. Stay tuned.
There is actually a lot more to HIPAA compliance than what you see on the back end of your application. You have to do Risk Assessments annually, assign a Privacy Officer, have policies & procedures in place, implement employee training, and execute Business Associate Agreements with anyone you share PHI with.
These administrative parts are frequently forgotten when implementing a HIPAA compliance program.
I always find it funny how more money is spent on audit tools like this, and yet people get no training in HIPAA, so they e-mail spreadsheets of social security #s and medical records to 3rd parties, to say nothing of dropbox and pastebin. Most people would shit themselves if they knew all the violations that go unreported.
WHAT!?! I'm a physician, and to my lament I have to do HIPAA training over and over and over and over... Just like everyone else everywhere I've ever worked. Yes, we get plenty of HIPAA training. There are still breaches, of course, but your statement is just plain wrong.
Okay, perhaps they just blatantly ignore their training? In which case they probably need to fix the training, or something. Are you sure all the personnel that work for the hospital system (or private practice) gets HIPAA training? There's plenty that work with sensitive data that aren't physicians.
Yes, everyone that touches protected data gets the training. I'm sure there are some hospitals/offices that don't but that's got to be pretty rare. I imagine most of the breaches are not due to overt ignorance, but due to poor application like not understanding the level of security provided by some means of transmission, or knowing but doing it anyway because it's convenient.
It depends on where you are, and if your hospital has ever been sued before. There are still pockets that don't have adequate training. I also assume that a lot of private practices don't get a lot of good data-handling training on the subject.
Does anyone know of a HIPAA compliant PaaS (other than building it yourself)? I'd like to run stuff for work on Heroku, but they don't claim and compliance last I checked.
I'd love to learn more about HIPAA compliance and web applications. Any good resources out there? From from a developer's standpoint HIPAA feels like a lot of grey area.
HIPAA is more about policy than it is about any specific technology or standard. And most of it is good practice for many applications, from a privacy and security perspective, not just healthcare.
Thanks for these links. I'm curently building a network to connect several medical facilities together and, while I don't think I have to be too concerned w/ HIPAA, this stuff is good to know. I've bookmarked those pages and will be reading through all of them over the weekend.
hmmm, It made me realize that I may be on the verge of breaching the HIPAA laws. I'm developing an app on Google App Engine (which afaict won't sign a BAA), this app will help users with storing and interpreting their data (some of which may be considered health data: like all the biometric data). Anyone knows if I have to comply to HIPAA in spite of not being an health provider myself?
The definition of who needs to comply with HIPAA has more to do with who has contact with protected health information and less about who the company is (e.g., a hospital or not).
This document has some bullshit example: Identifying users by zipcode and gender? huh?
"Imagine that a covered entity is considering sharing the information in the table to the left in Figure 3. This table is devoid of explicit identifiers, such as personal names and Social Security Numbers. The information in this table is distinguishing, such that each row is unique on the combination of demographics (i.e., Age, ZIP Code, and Gender). Beyond this data, there exists a voter registration data source, which contains personal names, as well as demographics (i.e., Birthdate, ZIP Code, and Gender), which are also distinguishing. Linkage between the records in the tables is possible through the demographics. Notice, however, that the first record in the covered entity’s table is not linked because the patient is not yet old enough to vote."
It's not bullshit. Here's the paper from 2000: http://dataprivacylab.org/projects/identifiability/paper1.pd... From the abstract: 87% (216 million of 248 million) of the population in the United States had reported characteristics that likely made them unique based only on {5-digit ZIP, gender, date of birth}.
"HIPAA defines a covered entity as 1) a health care provider that conducts certain standard administrative and financial transactions in electronic form; 2) a health care clearinghouse; or 3) a health plan"
which is explained by the flowchart in the document I linked in my other comment. So as long hippaway app doesn't take payments for health services (which you can't do unless you are a certified health provider), I guess she is fine. Yes?
If the data is stored on their device and you have zero access to it, I do not see any problem. Individuals have the right to do as they see fit with their own PHI.
Background: I paid insurance claims for over five years. Thus, I received HIPAA training annually. Feel free to email me.
I understand your concern, but these days, cloud or no cloud isn't what's important, just that you use a data store in a HIPAA compliant fashion and that the provider will sign a BAA. Health tech startups these days are using AWS, Azure, and Rackspace, all of which will sign BAA's.
Companies like TrueVault can pretty much forget about expanding outside the US after the NSA scandal.
Their target market is already writing the policies and protocols to ensure that in the for the next few decades no bit of data ends up anywhere near US jurisdiction.
I've probably shoveled more fuel on HN's NSA fire than most, but how do you think health records are related to anyone's NSA threat model? Are there health conditions that will prompt a visit from the black-bag squad?
They aren't any more related to their threat model than anything else they're vacuuming up but that doesn't mean they don't want them. All it takes is one known terrorist with a known illness / rare treatment and "wouldn't it be nice to have this access" becomes "we need this access NOW" becomes "we will take the access, now and forever into the future, and there's nothing you can do about it."
Also, perhaps terrorist networks target people with terminal illnesses and nothing to lose? Or perhaps the FBI is worried that someone who has been denied treatment in the US will turn terrorist all on their own. We have a large population that has been wronged by the system and has nothing to lose, I think the FBI wants to keep an eye on them. I know, FBI!=NSA, but the whole "parallel construction" deal shows exactly what they think about separation of powers: at least a few of them see it as an obstacle to overcome, not as a safeguard against abuse. And a few people is enough to do all the damage in the world.
Also, let's not forget there's a heavy financial incentive for individuals with access to such a database to sell the info to insurance companies. It follows that such individuals then have a motive to push for the establishment of such a database. They could launder the info into some "proprietary liability metric" which they would be able to sell for loads of money. I don't know what internal checks they put in place after Snowden but they can't be perfect. Any shadow copy of your health records increases your exposure and provides an opportunity to the unscrupulous if the records can be accessed in aggregate.
I have to admit that these are plausible scenarios. However, most regular citizens (I know, lots of horrible arguments start out with that phrase) would be harmed more by the spooks turning communications about legal gray areas over to prosecutors than to anyone in the government knowing about their gout or depression or whatever. (Sure some people are worried about "Obama's Death Panels" but if such ever appear I'm pretty sure they'll have access to your health records anyway.)
In your last scenario, the "bad" agents only win if they can sell the service, but keep secret the inputs to that service. I'm sure they can do that in the short term, but it's quite likely that eventually a salesweasel will speak a bit too freely in a semi-public forum and the whole scheme will unravel. After all, other government agents would be pissed off, if only out of jealousy.
I'm pretty sure I've read a story about a psychiatrist who found out that some government agency (not sure if it was NSA) was illicitly browsing his patients' records and particularly their prescription histories without any kind of consent (as would be the case for a security-clearance audit). Their excuse was that some conditions might affect people's ability to perform in security-sensitive roles. It's also not unlikely that they might use the threat of disclosing someone's medical/psychological status to coerce keys out of them. So yeah, NSA might well want that information enough to "suggest" adding a back door.
The SF86[0] (the form you'll be filling out if applying for any type of clearance) is extremely "intrusive" with regard to your medical history. Excluding information isn't an option, either.
Some medications or treatments are indicative of life's events. NSA may be interested in why this person of interest (because, it would definitely be a person of interest and not some random individual - snark) is suddenly taking anti-anxiety meds or having some plastic surgery.
There's some misinformation on your website, "HIPAA compliance is costly and hard to get right" It's not. It's almost cheaper to sign an EA with Microsoft and use Azure (who by the way also sign a BAA) than your pricing. I also couldn't find any mention of what redundancy you use or any mention of uptime.
HIPAA compliance is basically encryption + access control + logs + redundancy with a few other simple features. All of which are easily accomplished with AWS or Azure. BAAs between you and your hosting provider are not necessary unless you have access to the PHI (Amazon doesn't, Azure does).
The biggest red flag to me is that this doesn't (as one might assume) absolve the developer from liability / responsibility. If it were to come to light that your business is (I don't think any of these things about you) corrupt/poorly run/hacked/breached/etc. the developer is then liable to immediately remedy the situation which may include being required to move elsewhere. That would be a huge disruption to any service as they would have to build a system from scratch while somehow still operating. This would be the only reason I would switch my apps from AWS to your service but unfortunately this is not the case. The fact also remains any HIPAA violation would be more likely in the implementation of the webapp (i.e. allowing images to be cached) and not in the storage of it. Leaks of encrypted PHI aren't even an issue with HIPAA.
You have the issue of being new and without a reputation while I can still be liable for your mistakes. While you have insurance it's not really feasible to sue someone as a startup. Anyone not a startup would find your pricing way too expensive.
Amazon whitepaper: https://aws.amazon.com/about-aws/whats-new/2009/04/06/whitep... re:Invent presentation: http://www.slideshare.net/ControlGroup/aws-reinvent
TL;DR: BAAs do not remove liability, HIPAA compliance isn't nearly as complex as other regulatory bs, AWS and Azure are both easily made HIPAA compliant.