How big of a PITA is HIPAA compliance for a web-based app?

Discussions
#1

A potential client wants me to build a custom EMR in the form of a SaaS app with the intent to resell it to his colleagues within the same medical specialty. My research suggests that true HIPAA compliance is near impossible in a web-based app but that doesn’t seem to be stopping a growing number of EMR providers.

If you have experience in this area, what advice would you offer someone with regards to building a HIPAA compliant SaaS app?

2 Likes
#2

It’s all kind of fuzzy from what I can tell, with lots of stuff meant to check off check boxes, as well as CYA type solutions. I’ve been working on something along these lines and would be happy to let you know what I know via private email.

#3

Thanks @davidw, I just sent you an email. Please consider posting any bits you’re comfortable sharing here as well so that more people can benefit.

#4

Is there an official @patio11 bat signal for this forum?
I think he can throw in some experience here.

#5

Appointment Reminder sells HIPAA-compliant accounts on a very limited basis, and I hope to make them publicly available in a lower-touch fashion within the next few months.

Short version: HIPAA-compliant SaaS is possible if you have approximately 2 to 6 weeks of engineering/founder time and about $10,000 to throw at the problem. You can do it quicker/cheaper but that’s about what it takes to do it right

Longer version:

There are about 100 individual checkboxes that you’ll need to hit to be HIPAA compliant. You’re responsible for them yourself, and by default nobody will check unless complaints are made against you and you are subjected to an audit. If you are audited, you need to both a) be compliant and b) be able to point to documents providing you are compliant.

Approximately 90% of the requirements can be satisfied by having good engineering/risk management practices and documenting them. For example, one requirement is that you need to have a formal policy on use of patient information. You can bang this out in 20 minutes, save it to Google documents, and then print a copy and sign in to document that you’ve done so in the case that this is ever questioned. HIPAA doesn’t require any particular level of detail in the policy – I think mine is literally three paragraphs long.

A preview of coming attractions for bullet points which are going to actually cause you too do a bit of work:

  • You will likely have patient data saved on a cloud provider somewhere, for example on a Rackspace VPS. You will need to talk to their sales team and get a Business Associates Agreement from them. Most of your cloud providers will be used to hearing this request. Some may not be amenable to signing a BAA, in which case you need to either a) move, b) remove their ability to access the data, or c) talk to your legal representative about documenting “X has access to the data but falls under an exception to requiring BAAs.” Every time we had that happen we explicitly documented multiple parallel reasons why we thought that information was an exception or not a significant risk. e.g. Lets hypothetically say Twilio gets client phone numbers in the ordinary course of the use of Appointment Reminder. That is explicitly documented, with notes like "We believe Twilio’s possession of these telephone numbers qualifies under the communications provider exemption in $CITATION. In the alternative, we believe that Twilio’s possession of these phone numbers incurs no marginal risk to patient privacy versus general industry practices such as making phone calls to cell phones, which has equivalent-or-worse risk of disclosure. In the alternative, we believe that Twilio’s substantial investments in security (see $CITATION and our discussion of counterparty risks below) are sufficient to mitigate the small risk of disclosure, especially considering that Twilio does not possess other data about patients which would make the disclosure especially severe.
  • You will want to have a BAA written for your own service. You will get a signed copy of this BAA from every client of your HIPAA-compliant services. DHS has a template policy which you can use as a base. Get yours (and your ToS for your service) reviewed by a lawyer, but don’t have them scratch-write it – this will save you several thousand bucks.
  • Not actually a HIPAA requirement, but you should get an errors and omissions insurance policy with a data breach rider. Mine cost about $3k a year for AR at AR’s current level of sales. That’s close to the floor cost, but in principle, they scale up with revenue.
  • You need to do a risk assessment for your application. For AR this was me basically sitting down and writing for two days about the architecture/use of the application and things which could possibly go wrong. Next to each thing that could go wrong, I listed things we had done to mitigate the problem and reasons we thought our current level of security was sufficient. Some of the things line up directly with HIPAA requirements, some don’t. This was in an Excel file. I have 3 versions of it: one to share with hospitals under NDA only, one to share with the government if audited, and one for internal use. Example follows below.
  • You need to enforce minimum password lengths and a policy to rotate them occasionally. This is one of the very few actual code changes AR required.
  • HTTPS everywhere. If you move PII between servers, for example between the web tier and database, that connection should be encrypted as well but for smaller deployments you can sort of handwave it.
  • Think carefully about your use of email. No PII should be going out in email.
  • There exists a product which can encrypt e.g. partitions on Linux systems, which you might think of using for your MySQL database.

I will be happy to share some details of the Appointment Reminder risk assessment privately, for obvious reasons.

7 Likes
HIPAA Compliance
#6

Holy spitballs! Thank you so much!

Did any part of all this involve hiring a 3rd party to “certify” you and/or AR as being HIPAA Compliant? I’m having trouble determining if this process is an elaborate and expensive exercise in hoop jumping or if it is actually beneficial at a substantial level.

#7

One resource you may find useful for this is http://www.amazon.com/HIPAA-Roadmap-Business-Associates-step-/dp/1484067010/ref=sr_1_1?ie=UTF8&qid=1384826897&sr=8-1&keywords=hipaa+compliance+business+associates . It’s a small book which has customizable versions of all the documents you need to be HIPAA compliant, along with some explanations of the process of becoming compliant.

Even though you probably still want to run this by a lawyer and think carefully about how the security and privacy issues involved line up with your application, having pre-written versions of everything from internal policies to employee training makes the process much less daunting.

3 Likes
#8

Check out https://www.truevault.com/ for HIPAA compliance as a service.

(Not involved with this company in any way, just a YCombinator company I find interesting and can be useful info for OP.)

#9

Citations? I don’t think this is true.

I’d upgrade this “might” to a “must” if you are doing any sort of product which requires any sort of searching. HIPPA requires all PHI data “at rest” be encrypted.

If you don’t encrypt the entire disk you’ll have to store encrypted strings. So “NicheDiver” becomes SDFS*(0(*&ELKJLSJDFSD.

So now try and SELECT * FROM table WHERE LastName like ‘Niche%’. Its just not going to work. :wink:

Also there are some challenges with recording who viewed what data. Lets say you load a grid of information. You should store what PHI was on that grid and who viewed it. A grid of 100 entries becomes 100 inserts. Something to consider.

I’d increase patio11’s estimate to 12 weeks to get the basics of an EMR right. Whereas appointreminder has very limited PHI you’d be literally swimming in it. You shouldn’t underestimate how much of a BFD it is for somebody to hint the print key on a patients full medical record.

I’d certify so that if a data breach occurs you can show you made every attempt to verify you did everything right. There are different levels of fines for being ignorant vs being stupid and it behooves you to try and be ignorant.

Now all this being said I wouldn’t touch a full on EMR product without significant up-front money. Worked with HIPPAA twice now as a technologist, once as a bootstrapper and probably wouldn’t touch a EMR like product without the chance of a big upside. If you’re friends colleagues aren’t willing to write 5 figure checks up front for this EMR I’d pass.

#10

I solved this by creating an encrypted index thing that gets updated when data goes in or out of the table I’m interested in searching. It’s kind of hacky in some ways, but it means the data spends more time encrypted. The most frustrating thing about it: I was pleased with myself when it all came together and started functioning. Management (this is for my consulting job), on the other hand were like “oh, now search and sort finally work - it was about time”.

#11

I have been doing contract development for a software company that sells 2 different EMRs (acquisition nonsense) that together own over 30% of their market. Both products were started by practicing physicians that wanted a product better suited for their specialty.

In my view HIPAA is not your biggest concern.

From a cost to build standpoint you are likely to spend a lot of time on Meaningful Use certification, ICD9/10 support, and the nightmarish integration scenarios with 3rd party lab providers, electronic prescription services and drug databases. There are answers to all these things, but if you come from a technology background other than healthcare you might be in for a shock at just how dated some of the “industry standard” solutions are.

It’s also not a one person effort. An EMR system is much more than an appointment/contact manager on steroids. It’s not the kind of thing you can build on top of WordPress and get 2/3 of the way there. Just the work involved to feed the billing system is noteworthy. Add in the fact that software mistakes in critical areas can kill someone (ex: drug interactions) it’s really important to get some parts perfect - zero tolerance for bugs.

All that said, it can be both lucrative and rewarding. If the doctor is willing to stay engaged and fund it for a few years, it could be the opportunity of a lifetime.

One other note, if you talk to 10 different doctors you’ll yet 10 different versions of how everyone does it. Make sure your test group includes more than just the sponsor’s practice and more than just doctors. The biggest EMR users are nurses and office support staff.

Have fun!

#12

Patrick,
Great answer.

We are trying to avoid HiPPA by not storing or using the user’s full name.
First name and email address. We have been told by someone-who-should-know at the Veterans Administration that this is fine.

Any thoughts?

(And for now, MoreSpeech.com is primarily targeted at Home users. If we get request for Hippa compliant and the above does not satisfy them it I think we’ll offer a much more expensive Hippa compliant version)

#13

You mean … the Pat Signal?

2 Likes
#14

Well based on my conversations with a different somehow-who-should-know at the VA email is almost certainly a identifiable field these days. You get somebody using firstname.lastname@gmail.com and there you go…

1 Like
#15

Very good point.
Sounds like if a hospital wants to subscribe and wants those HIPPA features they’ll need to get our PRO version, which allows you to create an account with a User Name instead of an email address. (And if we have to I guess we’ll spend $10K worth of effort on filling out paperwork and such.)

What about encrypting the PID (personally Identifiable Information) (whenever it is “at rest”) : (for us that’s Email as you pointed out).?
(So the only time you’d see the PID in “cleartext” is in the browser via https. It would be encrypted in the Database.

My bigger concern is SHOWING that we are HIPPA compliant

#16

Patrick,

I’m reposting my suggestion above:

What if you just encrypt the PID (name, email, phone #, address) when the data is “at rest” (not in an https// window) ?

And then limit access to the decryption. (Essentially the encrypted PID becomes the focus of the HIPPA rules).