TrueVault – HIPAA compliant data storage
truevault.com
truevault.com
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.
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.
http://www.hhs.gov/ocr/privacy/hipaa/administrative/omnibus/...
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.
HIPAA & PCI
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.
Also, do they sign BAAs?
If not, it's not really worth the paper it's printed on for your clients.
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.
So training / social solution is needed anyways, but that's a worry for other industries, not tech.
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.
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.
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.
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?
They are very much like Stripe's checkout JS form.
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.
Isn't this just a thin encryption layer on top of Mongo? I feel like I could replicate this in ~100 lines of Node.
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]
More details: http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2003.h...
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.
(genuinely curious)
These administrative parts are frequently forgotten when implementing a HIPAA compliance program.
Disclosure: my startup, Accountable, automates this process. http://www.accountablehq.com
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.
If you know your hospital staff lacks HIPAA training, it's probably time to find a new doctor at a different hospital.
Start here: http://www.hhs.gov/ocr/privacy/hipaa/understanding/covereden...
Then this: http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/i... and this: http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary...
As long as you don't accept payments you should be fine... But talk to your laywer? (Yeah I know...)
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).
"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"
"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."
Background: I paid insurance claims for over five years. Thus, I received HIPAA training annually. Feel free to email me.
The box with logos makes me feel uncomfortable from a trademark perspective, btw.
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.
and
http://en.wikipedia.org/wiki/Infection_control#Isolation
especially if "terrorists" are anywhere within the many small-networks lurking in all that data (http://en.wikipedia.org/wiki/Small-world_networks)
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.
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.