Hey everyone, I'm Chas, one of the founders of Aptible. Frank (fancyremarker) and I have been working on this for a while. We're excited to see what you think.
We have a development tier (read: not HIPAA-compliant) for playing around with[0]. Fair warning, we do require a credit card.
We will be hanging out here for a few hours, answering questions and chatting.
tel mentioned this, but Amazon allows organizations to store protected health information (PHI) provided they use dedicated machines in their own VPC. I recently had to migrate our company into this model to get our BAA signed.
I like what you've built, but I think you might be missing the real pain point. I agree that it's a hassle to setup a compliant infrastructure on Amazon. But, this is a one-time process. Most serious healthcare IT companies (and startups) will undertake this responsibility themselves to have tight control over their infrastructure.
The real challenge is maintaing the system and providing access control as the system grows. We handle upwards of 50K clinical notes a day. When we encounter an issue we have to be able to track which note caused the problem and get access to it all within the confines of our system.
Our access policy requires:
1. Connection to the dedicated VPC
2. SSH access to specific instances
Here's what I regard as the real problem ---> Once you're SSH'd onto the instance, you can do basically anything. There's no front-end for manipulating PHI. I could scp every PHI document onto my laptop.
We completely agree that the biggest challenge is in maintaining the system.
We help customers control access to systems storing ePHI by tying SSH and database access to the same role-based access controls used for administering the web dashboard. We also log and audit all actions taken by these authenticated users once they've established an SSH session or database connection, so identifying or disconfirming a potential breach becomes much easier.
Thanks for having a bug bounty program, far too infrequent in healthIT.
Can you expand more on "generate all of the documentation, audit logs, and explanatory materials you need to demonstrate compliance with every aspect of HIPAA."?
Also, with QSM requirements for the vast majority of other healthcare regulations, you need to explicitly address them in documentation to be compliant. Does Aptible address this, or only HIPAA?
Re: documentation, a major part of our platform is our compliance dashboard, where we track your compliance status in real time, as both a high-level status report (think Travis CI for HIPAA), and as more formal (custom) documentation which you can use for sales purposes, or in case of an audit.
As for QSM requirements (and other regulatory/compliance requirements in general), we're focused on covering 100% of HIPAA's requirements, but our technology and our compliance backend support a wide array of frameworks. We can help customers with all of these specific needs. Please let me know if I can provide a more specific answer!
Chas was kind enough to call me and not only explain their product, but also to educate me on HIPAA compliance in general from a legal standpoint (his background) – answering all my questions until I had a really good grasp on it and pointing me in the right direction to learn more.
(I'm working on a product that may eventually use this – left my email on their website and Chas got in touch and we ended up on a Skype call)
Great idea - a matter of execution wizardy to seize the huge opportunity.
A couple of questions - mostly about performance. While heroku offers fantastic start for early and small size startups, one of the issues off late are it's performance issues when you reach certain growth stage. I realize that you are not working directly off AWS instances but using docker. How are heroku dynos different from aptible containers?
Good question! Aptible's Docker containers are fundamentally similar to Heroku's dynos in terms of the Linux kernel features on which both are built.
Most of the performance advantage comes from 2 facts:
1. An Aptible production customer shares NO resources with other customers, from the load balancing layer down to the app container layer. So, performance is never going to be degraded as a result of resource contention from other customers.
2. Container CPU and RAM constraints are flexible on Aptible. While we set defaults for both of these container constraints, we can adjust them for specific customer applications that may be more CPU- or RAM-intensive.
Wow, cool idea. Though $3,499/month is WAY above what a small company like mine can afford. We're considering paying a one-time cost of ~$10,000 for a consultation to get us there and won't have to do another one for (hopefully) quite a while.
Great question! Our customers think of it in terms of how many employees they'd have to hire to get the same functionality. They say we replace at least one engineer and at least one compliance manager. So $42k/yr for that is a good deal, according to them. We are adding a customer page soon so you can meet the companies using Aptible and hear how they made those decisions.
The other thing I'll add is that there are no hidden costs and no gotcha fees. A Prod account gets you all of the help, training, and extra time from us you need to be successful. We don't consult and we never bill for our time.
I'm curious to this as well. One project I'm working on is software that helps small assisted living facilities (think a house in a neighborhood with under 16 residents) maintain compliance with their state regulations. That price point puts them way outside of my budget. EHRs for nursing homes and hospitals? I might have missed it, but a detailed explanation of why their service is necessary would help convince that I need them, or at least who their target market is. Otherwise, I really like the idea.
> Though $3,499/month is WAY above what a small company like mine can afford.
In order to host a HIPAA-compliant application on Amazon, there is a $1,500/month per-zone fee. This does not even count the actual server or storage costs, let alone the costs of building (and then maintaining) a complaint server application plus managing the documentation for it.
You also have to pay this fee again if you want to host the application in a second region (e.g. for failover/redundancy).
So, an extra $2000/month to forget about all of those is a signficant cost, but still a reasonable price.
Love that you guys are addressing more than just the security rule - we found the technical parts of HIPAA the simplest to address. Are you planning on having employee training modules and customizable policies and procedures? How do you help guide companies through the Privacy components?
Yes, we agree. Most of what turns HIPAA compliance into a murky time-suck is in the administrative requirements and documentation.
We'll have a separate page on the site explaining this next week, but we break compliance management down into 5 main areas:
- Risk Assessment
- Policies and Procedures
- Training
- Ops
- Incident Response
Conceptually, they form a cycle. Each area feeds the next, with ops/incident response feeding back into risk analysis.
We have a suite of tools to help with each stage of the cycle. Each step requires a different mix of:
1. Automation
2. Manual work on our part, and
3. Manual work by our customers
Our overall goal is to drastically reduce #3 while helping our customers run amazing compliance programs that reduce risk and give everyone involved (devs, management, their customers, federal regulators) insight into what is going on inside their organization.
This is what I'm most curious about. The technical/security side is only 1/3 of HIPAA, how do you turnkey the remainder? How do you scale/automate preforming repeat RAs, etc, across different clients?
Just a simple but potentially powerful sales Idea for you.
Most of the replies are from people who "need" to be hipaa compliant. And their arguments are sound in that scenario. However, there are many situations where projects want to be compliant but don't need to be. Technically at least. Let me give you an example. I worked at at a pharma marketing company where our clients where pharma brands. We built stuff for them, apps, sites etc. These did not always have to be hippa compliant, but the pharma legal team forced them to be anyway. The point is there is a market there for you. Essentially, your targets would be the creative agencies that build digital stuff for pharma cos.
I'm an ehealth / mhealth scientist / developer in The Netherlands. My biggest headaches come from infrastructure issues / security, so a product like Aptible would be great for me and my associates.
Seeing as I live in The Netherlands, and my end users (patients) will be Dutch, I'm bound by Dutch law. I'm no attorney, but I think it will be problematic to store electronic health records in the US.
Seeing as scientists / developers in The Netherlands are at the forefront of ehealth / mhealth development, are The Dutch somewhere on your list Chasb?
Different scenario: me and my Dutch associates would like to launch an ehealth / mhealth product in the US. In the eyes of US law, are we allowed to do this?
The EU's data sovereignty laws present a special set of restrictions, and specific countries like the Netherlands add more. But challenging problems can be valuable problems to solve, so yes, the Dutch are on our list.
At the moment, however, our entire focus is on HIPAA compliance. I tell people this: I am a lawyer, but I am not your lawyer and this is not legal advice. You would certainly want to consult a US attorney, and perhaps form a US subsidiary, but it is possible for a foreign organization to do business in healthcare in the United States. The example at the front of my mind is Royal Phillips and their new partnership with Salesforce[0].
When you state HIPPA compliance, are you saying that you've addressed NIST 800-66 with a 3rd party certification? As I'm sure you know, the word "compliance" is sort of funny and subject to interpretation.
Great question! We audit customers against an adapted version of HHS's pilot audit protocol for covered entities[0], tailored for cloud-based software business associates. HHS is starting the permanent audit program and we expect them to publish an audit protocol specifically for business associates this fall.
NIST Special Publications are great resources, and we use them where appropriate, but as I'm sure you know, they're not specific enough to just audit against a single publication and call it a day.
For example, NIST SP 800-66 Revision 1[1]:
1. Only covers the Security Rule
2. Consists of mostly pointers to the other, substantive NIST SPs, and
3. Isn't as detailed as the audit protocol from HHS, which is the entity that will ultimately judge your compliance
Again, all of that said, we love NIST(!) and use their methodologies and guidance (including SP 800-66 Rev 1) extensively.
Really cool idea, I have a general question about the healthcare app space -- how many of these apps are written ad-hoc for each medical practice? I.E., should I expect my dentist to run a totally different software stack from my general practitioner, and do they usually run custom software or more general solutions?
Also, how much of the existing stuff is written on .NET? I have a feeling that's a pretty popular stack for a lot of small business/enterprise companies, but is harder to support via open source software.
If you're referring to what the providers use for patient documentation, billing etc, there's a slew of apps out there that unfortunately don't talk to each other in much of a meaningful way without a lot of work. Beyond the big EMR companies (Epic, Cerner, Allscripts, Siemens, etc -- what you'll see at academic centers and medium-large hospitals), there are tons of companies that have come out with medical record software for individual clinics (i.e. a couple dicots in a practice not owned by or affiliated with a major medical center) and much of it is often marketed in a niche way
I'm Travis, one of the co-founders of Catalyze - https://catalyze.io. We also offer a HIPAA-compliant platform-as-a-service (PaaS). Our compliant PaaS starts at $500/mo and includes dedicated, encrypted logging, monitoring, backup, disaster recovery, and encryption (at rest and in-transit). We've been through 3 3rd party audits + penetration testing (most recent audit we were 100% in compliance). We're very transparent about HIPAA and open our audits up to customers to use as part of their sales collateral. You can see how we interpret and address HIPAA requirements here - https://catalyze.io/hipaa/ - and you can see our policies here - https://catalyze.io/policy/ (we're open sourcing these in the next couple weeks).
We don't provide policies or risk assessments as a service, but Accountable (http://accountablehq.com/) does a great job with those. Using Catalyze + Accountable starts at $600/mo, about 1/6th of the starting price on the Aptible site; we also offer 60 days to terminate so don't lock you into annual contracts to get that pricing.
We've got some great production customers, with testimonials and use cases on our site, that love our service and support, and have moved over from hosting providers like AWS, Firehost, and Blue Box. I'm happy to answer questions about Catalyze and the compliant cloud space in general.
Dude, you shouldn't shill on someones product launch especially since you're not providing meaningful feedback on how your product differentiates itself from Aptible.
We're up[0]. CloudFront requires a browser that supports SNI indication for SSL, which may not work if you're on Windows XP. We'll spring for the dedicated option soon.
It's our own setup, similar in its external-facing product, but implemented a bit differently on the backend than other PaaSes like Heroku, Flynn or Deis. Specifically, we support many isolated-tenancy stacks behind a common central platform interface.
Other than Docker and AWS, there are a bunch of pieces that make the whole thing work, but most of them are custom.
[+] [-] chasb|11 years ago|reply
We have a development tier (read: not HIPAA-compliant) for playing around with[0]. Fair warning, we do require a credit card.
We will be hanging out here for a few hours, answering questions and chatting.
[0] https://dashboard.aptible.com/signup?plan=development
[+] [-] jMyles|11 years ago|reply
[+] [-] aabajian|11 years ago|reply
tel mentioned this, but Amazon allows organizations to store protected health information (PHI) provided they use dedicated machines in their own VPC. I recently had to migrate our company into this model to get our BAA signed.
I like what you've built, but I think you might be missing the real pain point. I agree that it's a hassle to setup a compliant infrastructure on Amazon. But, this is a one-time process. Most serious healthcare IT companies (and startups) will undertake this responsibility themselves to have tight control over their infrastructure.
The real challenge is maintaing the system and providing access control as the system grows. We handle upwards of 50K clinical notes a day. When we encounter an issue we have to be able to track which note caused the problem and get access to it all within the confines of our system.
Our access policy requires:
1. Connection to the dedicated VPC 2. SSH access to specific instances
Here's what I regard as the real problem ---> Once you're SSH'd onto the instance, you can do basically anything. There's no front-end for manipulating PHI. I could scp every PHI document onto my laptop.
I could elaborate some more if you like.
[+] [-] fancyremarker|11 years ago|reply
We help customers control access to systems storing ePHI by tying SSH and database access to the same role-based access controls used for administering the web dashboard. We also log and audit all actions taken by these authenticated users once they've established an SSH session or database connection, so identifying or disconfirming a potential breach becomes much easier.
[+] [-] laurenstill|11 years ago|reply
Can you expand more on "generate all of the documentation, audit logs, and explanatory materials you need to demonstrate compliance with every aspect of HIPAA."?
Also, with QSM requirements for the vast majority of other healthcare regulations, you need to explicitly address them in documentation to be compliant. Does Aptible address this, or only HIPAA?
[+] [-] foundry|11 years ago|reply
Re: documentation, a major part of our platform is our compliance dashboard, where we track your compliance status in real time, as both a high-level status report (think Travis CI for HIPAA), and as more formal (custom) documentation which you can use for sales purposes, or in case of an audit.
As for QSM requirements (and other regulatory/compliance requirements in general), we're focused on covering 100% of HIPAA's requirements, but our technology and our compliance backend support a wide array of frameworks. We can help customers with all of these specific needs. Please let me know if I can provide a more specific answer!
[+] [-] chasb|11 years ago|reply
We're focused on HIPAA only right now, but are built to support other frameworks and reporting standards.
[+] [-] wefarrell|11 years ago|reply
[+] [-] Plasmoid|11 years ago|reply
[+] [-] ceejayoz|11 years ago|reply
[+] [-] fancyremarker|11 years ago|reply
[+] [-] metabren|11 years ago|reply
(I'm working on a product that may eventually use this – left my email on their website and Chas got in touch and we ended up on a Skype call)
[+] [-] kirankgollu|11 years ago|reply
A couple of questions - mostly about performance. While heroku offers fantastic start for early and small size startups, one of the issues off late are it's performance issues when you reach certain growth stage. I realize that you are not working directly off AWS instances but using docker. How are heroku dynos different from aptible containers?
[+] [-] fancyremarker|11 years ago|reply
Most of the performance advantage comes from 2 facts:
1. An Aptible production customer shares NO resources with other customers, from the load balancing layer down to the app container layer. So, performance is never going to be degraded as a result of resource contention from other customers.
2. Container CPU and RAM constraints are flexible on Aptible. While we set defaults for both of these container constraints, we can adjust them for specific customer applications that may be more CPU- or RAM-intensive.
[+] [-] RVijay007|11 years ago|reply
[+] [-] ceejayoz|11 years ago|reply
[+] [-] aik|11 years ago|reply
What size/type of company is the target market?
[+] [-] chasb|11 years ago|reply
The other thing I'll add is that there are no hidden costs and no gotcha fees. A Prod account gets you all of the help, training, and extra time from us you need to be successful. We don't consult and we never bill for our time.
[+] [-] richardbrevig|11 years ago|reply
[+] [-] chimeracoder|11 years ago|reply
In order to host a HIPAA-compliant application on Amazon, there is a $1,500/month per-zone fee. This does not even count the actual server or storage costs, let alone the costs of building (and then maintaining) a complaint server application plus managing the documentation for it.
You also have to pay this fee again if you want to host the application in a second region (e.g. for failover/redundancy).
So, an extra $2000/month to forget about all of those is a signficant cost, but still a reasonable price.
[+] [-] timjschwartz|11 years ago|reply
[+] [-] chasb|11 years ago|reply
We'll have a separate page on the site explaining this next week, but we break compliance management down into 5 main areas:
- Risk Assessment
- Policies and Procedures
- Training
- Ops
- Incident Response
Conceptually, they form a cycle. Each area feeds the next, with ops/incident response feeding back into risk analysis.
We have a suite of tools to help with each stage of the cycle. Each step requires a different mix of:
1. Automation
2. Manual work on our part, and
3. Manual work by our customers
Our overall goal is to drastically reduce #3 while helping our customers run amazing compliance programs that reduce risk and give everyone involved (devs, management, their customers, federal regulators) insight into what is going on inside their organization.
[+] [-] laurenstill|11 years ago|reply
[+] [-] Votetocracy|11 years ago|reply
[+] [-] matthijs_|11 years ago|reply
Seeing as I live in The Netherlands, and my end users (patients) will be Dutch, I'm bound by Dutch law. I'm no attorney, but I think it will be problematic to store electronic health records in the US.
Seeing as scientists / developers in The Netherlands are at the forefront of ehealth / mhealth development, are The Dutch somewhere on your list Chasb?
Different scenario: me and my Dutch associates would like to launch an ehealth / mhealth product in the US. In the eyes of US law, are we allowed to do this?
[+] [-] chasb|11 years ago|reply
The EU's data sovereignty laws present a special set of restrictions, and specific countries like the Netherlands add more. But challenging problems can be valuable problems to solve, so yes, the Dutch are on our list.
At the moment, however, our entire focus is on HIPAA compliance. I tell people this: I am a lawyer, but I am not your lawyer and this is not legal advice. You would certainly want to consult a US attorney, and perhaps form a US subsidiary, but it is possible for a foreign organization to do business in healthcare in the United States. The example at the front of my mind is Royal Phillips and their new partnership with Salesforce[0].
Feel free to email me if you'd like to chat more!
[0] http://www.salesforce.com/company/news-press/press-releases/...
[+] [-] cnkeller|11 years ago|reply
Disclaimer: I work in a similar space.
[+] [-] chasb|11 years ago|reply
NIST Special Publications are great resources, and we use them where appropriate, but as I'm sure you know, they're not specific enough to just audit against a single publication and call it a day.
For example, NIST SP 800-66 Revision 1[1]:
1. Only covers the Security Rule 2. Consists of mostly pointers to the other, substantive NIST SPs, and 3. Isn't as detailed as the audit protocol from HHS, which is the entity that will ultimately judge your compliance
Again, all of that said, we love NIST(!) and use their methodologies and guidance (including SP 800-66 Rev 1) extensively.
[0] http://www.hhs.gov/ocr/privacy/hipaa/enforcement/audit/
[1] http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-80...
[+] [-] nrubin|11 years ago|reply
Also, how much of the existing stuff is written on .NET? I have a feeling that's a pretty popular stack for a lot of small business/enterprise companies, but is harder to support via open source software.
[+] [-] tgokh|11 years ago|reply
[+] [-] ylhert|11 years ago|reply
[+] [-] travisjgood|11 years ago|reply
I'm Travis, one of the co-founders of Catalyze - https://catalyze.io. We also offer a HIPAA-compliant platform-as-a-service (PaaS). Our compliant PaaS starts at $500/mo and includes dedicated, encrypted logging, monitoring, backup, disaster recovery, and encryption (at rest and in-transit). We've been through 3 3rd party audits + penetration testing (most recent audit we were 100% in compliance). We're very transparent about HIPAA and open our audits up to customers to use as part of their sales collateral. You can see how we interpret and address HIPAA requirements here - https://catalyze.io/hipaa/ - and you can see our policies here - https://catalyze.io/policy/ (we're open sourcing these in the next couple weeks).
We don't provide policies or risk assessments as a service, but Accountable (http://accountablehq.com/) does a great job with those. Using Catalyze + Accountable starts at $600/mo, about 1/6th of the starting price on the Aptible site; we also offer 60 days to terminate so don't lock you into annual contracts to get that pricing.
We've got some great production customers, with testimonials and use cases on our site, that love our service and support, and have moved over from hosting providers like AWS, Firehost, and Blue Box. I'm happy to answer questions about Catalyze and the compliant cloud space in general.
[+] [-] error54|11 years ago|reply
[+] [-] dalacv|11 years ago|reply
[+] [-] yellowapple|11 years ago|reply
[+] [-] chasb|11 years ago|reply
Our current operational status is available at http://status.aptible.com/
[0] http://www.downforeveryoneorjustme.com/aptible.com
[+] [-] dubcanada|11 years ago|reply
[+] [-] fancyremarker|11 years ago|reply
Other than Docker and AWS, there are a bunch of pieces that make the whole thing work, but most of them are custom.