Ask HN: Working within constraints of hospital IT?

I'm currently working on a cloud-based healthcare idea also. My team and I have been wrangling with the compliant systems and services out there for handling this problem too. The crux really lies in the logistics of the HIPAA standard as every healthcare service storing or transmitting patient information must comply with _at least_ these regulations. Each hospital is liable to run their own EHR system which makes it extremely hard to integrate directly with them in a single broad stroke.

> Am I right to assume that it's nearly impossible to set up a cloud database that is accessed directly from, say, the OR of a hospital?

It depends on you, the employees, and the hospital. HIPAA basically focuses on 3 factors for securing and storing sensitive data: (1) Physical data security, (2) Security of data in transit, and (3) Training of personnel with access to the data. Amazon has HIPAA services that handle (1), 3rd party services like you mentioned above or you can handle yourself for (2), and also 3rd party services or yourself can handle (3). Assuming you have (1) and (2) squared away, and assuming the employees in the OR have the proper training, there should be no compliance violation.

Thanks for the helpful response. There are a bunch of great resources out there for achieving HIPAA compliance and given those, I'm confident that we can achieve it. What is unclear to me is, if we build such a solution, and then go into the OR, open a browser and type in http://<ourwebapp>.com, I'd expect the odds of us actually reaching that web page are low (e.g. will be blocked by a firewall). Is making sure that channel works just a matter of reassuring and negotiating with the hospital IT so that they ensure such access?

IMO you are thinking too far down the rabbit hole. If you are at the point of being implemented by a hospital or healthcare system implies you have already negotiated your product, licenses, etc and have the green light for all facets of what you offer (ie. access in the OR) by the boss(es). Hospital IT will listen to whatever said boss tells them to do, such as allowing access to your app if necessary.

This is true. Once buy-in is achieved then IT will generally do what they need.

I used to work in a hospital IT department :)

> I know from experience that every hospital is different ... my gut tells me the application will actually need a local database in each center, within the hospital network, which periodically replicates up to central cloud database

What data are you trying to store? Pretty much every EMR/EHR system nowadays speaks HL7; if your goal is to integrate with those EMR systems, then your own application could circumvent a lot of issues by speaking HL7 as well. Of course, this only covers certain use cases, hence the question.

> their IT departments range from strict to extremely strict

Eeyup :)

> I am also aware of the HIPAA-compliant PAAS services out there and we may end up using one of those.

You definitely should. Else, be prepared to deploy your own physical servers and provide similar assurances of HIPAA/HITECH compliance. Hospitals already tend to be wary of anything pertaining to patient data living beyond their own networks.

> There's been a lot of talk about healthcare moving to the cloud

For some small clinics, yes, this is somewhat attractive. Once you move into medium and large healthcare organizations, hospitals, etc., however, the desire is almost universally for things to be as self-hosted as possible if they involve PII. Most EMR vendors prioritize local/onsite deployments IIRC (with one notable exception in my experience: CPSI, or "say-pay-ess-eye", as it's more commonly known).

> Am I right to assume that it's nearly impossible to set up a cloud database that is accessed directly from, say, the OR of a hospital?

Not impossible. Just excruciatingly difficult, with difficulty scaling exponentially with the size of the hospital. :)

Super helpful response. Thank you!

> What data are you trying to store?

A couple of fields could be imported by integrating with existing EMR/EHR through HL7, but at this early stage I don't envision any integration and these fields will be input manually. The MVP works this way, for example (and has been used in a few hospitals).

> You definitely should. Else, be prepared to deploy your own physical servers

Does this mean you've seen off-site hosted apps using these HIPAA PAAS providers being used by hospitals "in production" (so to speak)?

> Not impossible. Just excruciatingly difficult, with difficulty scaling exponentially with the size of the hospital. :)

Is this regardless of using a HIPAA-compliant PAAS, or only in the case where we don't? I'm already dreading the answer ;)

> A couple of fields could be imported by integrating with existing EMR/EHR through HL7, but at this early stage I don't envision any integration and these fields will be input manually. The MVP works this way, for example (and has been used in a few hospitals).

In that case, yeah, hospitals will tend to differ very significantly; once you go beyond the HL7 world, any hope of a standardized interface goes out the window. Expect hospitals to run their own copies of your database in that case, and expect them to be very strict about what access you get.

> Does this mean you've seen off-site hosted apps using these HIPAA PAAS providers being used by hospitals "in production" (so to speak)?

I've yet to see a HIPAA-complaint PaaS vendor in use by an actual hospital, but it's worth mentioning that at least one such vendor - Catalyze - claims Blue Shield and the VA hospitals as customers.

I have, however, seen off-site EMRs in use by hospitals, particularly (as I mentioned previously) CPSI (though the hospital I worked for - which was, at the time, apparently CPSI's largest customer - eventually strongarmed them into providing support for an onsite server). Such EMRs are typically hosted on hardware owned and operated by the vendor.

Most hospital districts, multi-facility providers, etc. will opt for a single installation of an EMR throughout all their locations. Usually this will be facilitated using a provider-wide VPN, so that'll probably help your particular usecase somewhat. In most cases, this is as close as you're going to get to "off-site" once you get to larger providers, though - again - deviations from this are not entirely unheard of.

> Is this regardless of using a HIPAA-compliant PAAS, or only in the case where we don't? I'm already dreading the answer ;)

HIPAA-compliant PaaS products are pretty new, so this answer will undoubtedly change over time, but currently, such a PaaS will only flatten that expontential curve to maybe a linear one. Small hospitals and clinics will certainly be interested, since many of them dread having to manage any sort of IT infrastructure, to the point of even contracting out to their competitors in some cases (as I witnessed firsthand) instead of trying to do anything themselves. Once they've gone forward with their own IT department, however, the chances of even a HIPAA-compliant PaaS being deemed suitable starts to dwindle, and emphasis on self-hosted solutions grows stronger and stronger.

A number of companies are hosted on Aptible that are not only in production, but doing well. The same goes for Catalyze.

In general, though, yes, whether or not the solutions will suffice comes down to the arbitrary decision of an administrator who probably doesn't understand the underlying tech issues. That will start changing soon though.

I'd suggest working with one hospital to demo and test the idea first in their local environment. Getting buy in from multiple hospitals to try an idea out on an infrastructure you have not yet created is unlikely to be successful, unless there is a very clear ROI that you can model for them.

I would recommend Aptible for a simple HIPAA compliant app dev environment. They are fast and professional.

If you need integration-as-a-service and have some kind of budget, I would call Catalyze or my company, Fleet.

Thank you for the PAAS recommendations.

I agree one hospital and then upward would be the way to start, but we've got a bit of a different scenario.

We're coming into a project where the non-technical founders out-sourced the MVP (basic CRUD app) and it has been running in a hospital already (locally hosted within hospital). They now apparently have the go-ahead and buy-in to try this out in a dozen hospitals and need an app that can handle that deployment. Of course we will initially deploy in one hospital, but we've got the business buy-in to deploy in multiple centres. Same CRUD functionality, but with data eventually being pooled in a central cloud-based DB.

I guess one would say they need to find a team that has been there done that, but based on how scarce it would seem such solutions are, that doesn't seem easy, and of course I would like to rise to the challenge. It's just that there doesn't seem to be much information out there (beyond working with the hospitals themselves, and we have some experience there). The information in this thread has been super helpful. I've learned a lot and it has also confirmed that most of my assumptions (which err on the side of caution) are not too far off from other people's experiences.

We provide API integration solutions along the lines of other companies. We have not been around as long as Catalyze (which does a very good job) but are experts in FHIR, and have an infrastructure that may be more multi-party friendly.

We have a pretty cool multi-tenant database solution that hospital parties could pool data into with highly granular authentication, access control, and auditability at both the db and API levels. No one else offers this yet, but it also may be more robust than the hospitals understand enough to care about.

Happy to discuss if you are interested at the commercial site listed in my profile. Also happy just to share our experiences in similar situations, or make recommendations for other more simple solutions on your own stack. Good luck!

We offer a SAAS solution to hospitals that can be hosted by us or internally by hospitals (sort of like GitHub/GitHub Enterprise). What we have seen is a mix of both - some wanting to keep everything on their own permise and some wanting our cloud offering. Moving data out is a strict No-No for ones that need stuff inside their network - so unless you have a very compelling reason to move things to cloud you will find resistance at such places.

Thank you. This at least indicates that my gut feeling isn't too far off. Do you feel comfortable plugging your company? If not, feel free to ping me at the address in my profile.

Some hospitals are moving to cloud based EHR systems, so its probably not impossible. And most hospitals now have at least one relationship with an HIE that is normally not self-hosted, so IT groups have experience with data exchange. As long as all the HIPAA stuff is in order, I think hospital IT groups are more open to cloud based services today than 5 years ago.

I agree that things are moving in the right direction. The trouble is that when building a solution that should be expandable to more centers as the customer base grows, you almost have to build it for the lowest common denominator (in other words, the most restrictive hospital IT department). I have my doubts (but not a lot of experience) that a strict hospital would allow access to an external cloud web app / database that records PHI in the OR (without some lengthy re-assurances and testing).

I suppose this should be treated as an enterprise solution and there's no getting around the fact that the sales and deployment cycle will be long and costly (time and resources). Each hospital will have different requirements. I'm mostly curious as to whether we can get away with the app being completely based in the cloud and being accessed from the hospital, or whether we need a middle layer that resides in each medical center.

There's also the HITECH act, with provisions for handling data and reporting breaches.

http://www.hipaasurvivalguide.com/hitech-act-summary.php