Ask HN: Working within constraints of hospital IT?
I am currently planning a project that would involve a centralized cloud database, which gathers data from several hospitals. I know from experience that every hospital is different and that their IT departments range from strict to extremely strict (and we have to assume the worst here). With my little knowledge/experience in this area, 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. There is no immediate need for those databases to be consistent over a short period of time. We may also anonymise the data as it moves outside of the hospital. I am also aware of the HIPAA-compliant PAAS services out there and we may end up using one of those.
There's been a lot of talk about healthcare moving to the cloud, that I'm hoping there are some HN'ers with experience in this area. 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? Please provide any personal experience or resources that may help me make more informed decisions. Thanks in advance.
16 comments
[ 286 ms ] story [ 115 ms ] threadI 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.
http://www.hipaasurvivalguide.com/hitech-act-summary.php
> 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.
> 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. :)
> 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 ;)
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.
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 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.
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 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!