HIPAA-Compliant Meteor Deployments for Healthcare Applications


#1

Has anyone successfully deployed a scalable Meteor application in a HIPAA-compliant environment for their healthcare applications?

I’m curious about the feasibility of deploying Meteor into a HIPAA-compliant PaaS - such as one offered by Catalyze.io - where the provider takes care of infrastructure provisioning and various HIPAA related tasks such as executing business associate agreements (BAAs), data retention policies, and audit logs among other things.

Much of the technical challenges revolve around Meteor’s architecture - in particular sticky session requirements, which are incompatible with many load balancing solutions like Amazon’s ELB. Recent work done by @arunoda and others over at MeteorHacks on clustering Meteor with Meteor itself looks encouraging, as it would obviate the need to use the infrastructure provider’s load balancing solution, but it’s not clear to me whether one could still include appropriate SSL encryption throughout the chain while maintaining HIPAA end-to-end encryption standards.

Any thoughts or discussion on this topic would be welcome!


#2

I suggest reaching out to @awatson1978 - she appears to have a lot of Meteor experience in this area. Check out https://github.com/awatson1978/meteor-cookbook


#3

You might want to reach out to https://github.com/Urigo I’m pretty sure he has done a meteor app in the medical space.


#4

Contact @awatson1978 !
Look her clinical examples, seem she has a lot of work with HIPAA and Meteorjs.

Any updates on your projects please share it :smiley:
This is a great topic


#5

Thanks all… will do. Hope I can encourage them to contribute thoughts here as well.


#6

Thanks for the shout-out @robfallows and @cottz! :slight_smile:

I actually wrote down a few notes on HIPAA compliant applications and datacenters, pulled from a presentation at the Philadelphia Meteor Meetup and various emails I get about this from time to time. Here’s the link…

https://github.com/awatson1978/meteor-cookbook/blob/master/cookbook/healthcare/hipaa.md


#7

I’ve used TrueVault, which worked nicely with Meteor. Check out - https://atmospherejs.com/woody/truevault


#8

If you need to do any of your own encryption for data at rest, I’ve had good success with this package: https://atmospherejs.com/jparker/crypto-aes.


#10

@awatson1978 Thank you for writing that cookbook! I wish to clarify. If we do the following:

  1. Force SSL for data in transit (I’m assuming use some kind of FIPS-standard algorithm like AES)
  2. Have a user accounts system that requires relatively strong passwords (so that accounts aren’t easily broken into)
  3. Have an audit-able log

Then we can claim HIPAA compliance? (let’s assume it’s a web-app and is using best practices as well as keeping any systems / software patched)

Also, one of the things that I’m running into when reading about HIPAA compliance is that data must be encrypted at rest. Is this just something people say to get people to use their service? Because even mongoDB is saying it (they’re recommending Vormetric and IBM Guardium.), and services such as TrueVault and Catalyze are relying on it. If so, then would using something like crypto-aes suffice, as mattjmorris suggested?

Lastly, can you chime in on the BAA’s? Is it necessary to sign BAA’s with our PAAS/IAAS (say, for example Modulus and Compose.IO, when using their AWS datacenters)? Do we even need to sign BAA’s with anyone?

Thank you!


#11
  1. You will need a BAA with any service you depend on - Modulus, AWS, etc
  2. All PHI must be encrypted in transit and at rest
  3. HIPAA compliance is much more than software functionality - you will also need the appropriate processes and controls in place at your business
  4. Most healthcare providers have security requirements that go well beyond HIPAA - being HIPAA compliant will not get you very far

#12

@woody, what was your stack when you were using TrueVault?


#13

We used Modulus Enterprise services for HIPAA-compliant app hosting and all PHI was stored with TrueVault.


#14

Woody…thank you for chiming in…a few questions:

  1. Did you load balance Meteor in any way to provide additional scalability? If so, how did you wind up terminating SSL connections? Does your Meteor solution support WebSockets or did you have to disable it?
  2. Why did you choose TrueVault? Did you consider having Modulus provide an encrypted-at-rest HA setup for MongoDB (or using that exclusively if already provisioned)?
  3. What attracted you to Modulus in general?

Thank you for your insight.


#15

We didn’t set up any special load balancing, however modulus enterprise gives you control with regard to load balancing. We supported websockets. We chose TrueVault because of the ease of use and sweeping simplifications it gave us. Modulus just makes deploying a Meteor app really easy: modulus deploy


#16

@larry - Yeah, those three items that are the minimum items necessary. Key word is minimum. After those three items, it gets into issues of risk-management.

Regarding encrypted data at rest; it’s not specifically spelled out in the HIPAA Act, and that’s the area where there’s a lot of fear and marketing hype. Network security professionals and datacenters keen on differentiating themselves will fearmonger about the risk of data breaches from hackers and/or disgruntled employees. Or even authorized employees simply looking at files they shouldn’t be.

But keep in mind that HIPAA was enacted in the days of DOS. Most modern operating systems… Linux, MacOSX, Windows NT, will offer operating-system level encryption for data at rest. All modern databases, including Mongo, offer an additional layer of password security. If you have a password policy to actually rotate the operating system and database passwords, you can make a reasonable claim in court that you were actively using the operating system and database level encryption, and that the data was encrypted at rest.

So then it becomes an issue of risk-management around discarded server disks and backup tapes, how those are managed, and whether a hacker or disgruntled employee would try to steal the disks, mount them on a rogue server, access and then sell that data. That’s an exceedingly rare event, with potentially disastrous consequences. How do you manage exceedingly rare catastrophic risks? It’s the same issue as asking how to manage the risk of a natural disaster. What do people do to prepare for an earthquake? Or a flood? Or nuclear meltdown? Or simply a fire in the building? You can either use a technical solution or a financial solution. Add smoke detectors and fire extinguishers and concrete walls as insurance for the risk of fire. Or purchase homeowner’s insurance from your local insurance company.

What are the technical and financial equivalents for data? Well, there’s packages like crypto-aes, or providers like TrueVault. So those technical solutions are the data equivalent of having a smoke detector or fire extinguisher. If you already have a house built of concrete, a fire extinguisher may not be needed. If not, they may be invaluable. Is the risk of avoiding a hypothetical data breach from discarded server drives and backup tapes sufficient to take the time to implement crypto-aes and possibly miss market opportunities? Maybe yes, maybe no. For a hospital it may be more important. For a personal health record or research group, maybe not. Maybe it can be put off until a hospital does becomes a client.

Regarding a BAA, keep in mind that it’s specifically care providers who have to comply with HIPAA. If your client is an actual clinic or hospital that accepts payment for primary care services, then they will be obligated to collect a BAA from you; but an application developer is not strictly speaking the one obligated to comply with HIPAA. It’s a subtle distinction, but in practice it means that you can let the client take the lead. If they want a formal BAA, sign it. If you want to sell to a hospital, prepare for something in depth. If you’re doing a project with an independent MD who’s acting as primary investigator, they might not even ask for one and substitute a series of emails instead.

BAAs are a good practice any which way. They will obligate you to certain behaviors and practices, and are a sign of good will and good faith and get everybody on the same page as to how they should be handling data. Sign your BAAs.

Anyhow, @chafey is correct… HIPAA is much more than simply software functionality. That’s why there’s only a few real technical requirements… SSL, user accounts, passwords, audit log. It’s a lot more about business process, controls, and risk management.

Long story short… sign BAAs when asked of you, use SSL, use user accounts and passwords at operating system, database, and application levels, have audit logs, have a risk management policy, and if you put all that together you’ll have the basics of a HIPAA compliance policy. When in doubt, if you’re not comfortable interpreting and enforcing HIPAA yourself, go with TrueVault or some other vendor advertising HIPAA compliance.


#17

What is about the absence of database transaction, less data integrity with denormalization and other mongodb issues? Can this be a HIPAA barrier?


#18

HIPAA isn’t really concerned with missing data. It’s primary concern is preventing inappropriately accessed data (i.e. maintaining patient privacy). So data integrity isn’t that much of an issue. If it’s corrupt or inaccessible, it can’t be inappropriately accessed! You might have other problems, but HIPAA violations won’t be one of them.

Denormalizing presents a possible concern if you have a master-detail relationship between schemas that might clone sensitive data somewhere that’s not tracked. In that case you’ll simply want to design your data schemas well.

But otherwise, the absence of database transactions is pretty much a non-issue. In practice, the audit log that HIPAA requires winds up acting as an application-level transaction log. Or it should, at any rate.


#19

Thank you very much for your detailed reply Abigail!


#20

If Modulus Enterprise gives you HIPAA compliance with their hosted MongoDB, and you’re paying the premium for it, why use TrueVault?


#21

The ultimate decision to use TrueVault came down to client specific factors. However, as far as developer happiness, ease of integration, documentation, and customer service I thought it’s well worth using. TrueVault takes a lot of the little things you have to worry about and completely abstract it away from you. It felt like a “meteor way” of doing things. (No surprise Meteor and TrueVault both graduated from Y-Combinator).