Launch HN: Delve (YC W24) – HIPAA compliance as a service
HIPAA is a US federal law passed back in 1996 that sets standards for protecting sensitive health information. Here’s an article that breaks it down pretty simply: https://www.getdelve.com/blog/quick-guide-to-hipaa.
Most companies that process health information in the US need to become HIPAA compliant, a process that can be long and expensive. At our previous health tech company, we spent 6 weeks (and tens of thousands of dollars) on getting compliant. We had to complete a lot of manual work, even after purchasing an industry-standard compliance solution, and felt like we were hitting checkboxes with little confidence in our security. We realized that many parts of the compliance process could be streamlined and simplified, which led us to building Delve.
To get HIPAA compliant, you need (1) secure infrastructure, (2) legal policies, and (3) logging/monitoring. At Delve, we help startups with all three. We provide 1-click HIPAA compliant infrastructure deployed in your cloud and a CI/CD pipeline to update infrastructure from git push (think Heroku but HIPAA compliant). Then, we provide legal policies, paperwork, and a complete task list customized to your infrastructure setup. Finally, we have a real-time monitoring dashboard to help oversee compliance, track system activity, and review logs.
One thing we noticed the first time we ever got HIPAA compliant was that we had to use many tools along the way. We bought an industry-standard HIPAA compliance solution, hired a HIPAA DevOps contractor to help configure secure infrastructure, and worked with lawyers to adapt the boilerplate legal policies that our compliance solution had provided. When building Delve, we worked hard to give you everything you need in one place, reducing the hassle and cost.
We currently charge on an annual flat-fee basis. However, we’re still exploring our pricing model (flat-fee vs. usage-based vs. combination of both), and if you have any thoughts to share on that, we’d love to hear them.
We’re really excited about making it easier to build in healthcare and removing compliance bottlenecks. Thrilled to share this with you and hear your comments!
115 comments
[ 3.7 ms ] story [ 230 ms ] threadThink of us like Aptible + Vanta. Because you deploy your application through us, we can give you deep insights into your security and compliance. For example, we give you legal policies that have already been customized to your infrastructure setup. Similarly, we provide a logging/monitoring dashboard that is designed to meet what auditors look for in your infrastructure setup. Putting all your compliance solutions in one place lets us streamline the path to compliance.
Aptible has a built-in Security & Compliance Dashboard [0] that supports compliance automation and reporting (PDF and API exports) for HIPAA, HITRUST and other security frameworks. You can see a demo of the entire platform, including this Dashboard, in our "Aptible in 10 Minutes" video. [1]
You can also integrate Aptible with Vanta, Drata or another compliance automation tool, if you're running the self-hosted version of Aptible that runs in your own AWS account. If you do, you can expect fully passing tests for HIPAA and SOC 2 in Vanta or Drata with zero additional configuration. Most Aptible customers find our built-in dashboard sufficient, and don't feel the need to buy Vanta/Drata separately to ensure HIPAA compliance.
[0] https://www.aptible.com/docs/intro-compliance-dashboard [1] https://www.youtube.com/watch?v=mhNzGO9KbWY
We're also building out a small network of 3rd party vendors that we work closely with to help our customers get BAAs signed quick and offer discounts to those 3rd parties' services.
If you are using Vanta or Drata at early staging and opt for HIPAA framework, you do get the list of controls that you have to implement that also include cloud specific configuration changes that you need to do. And these changes are one time thing, continuously monitored by the framework.
My argument is that, the target market you trying sell - early stage HIPAA compliance market is not difficult anymore.
I hope this feedback helps you to foresee possible problems.
We provide a lot of active elements, such as our infrastructure logging/monitoring dashboard, email alerts, and code vulnerability scans every time you git push, so that we aren't just a one-time purchase. We help you be proactive about preventing breaches instead of just integrating with your AWS API and passively monitoring. One of the biggest things about HIPAA is that it isn't just your initial setup that matters, it's how you manage compliance on an ongoing basis that's important for maintaining security and privacy.
We're also growing with our customers and moving upstream, and keeping in mind exactly what you said about preventing SaaS churn. As we do this, we're following the core thesis that compliance should bridge legal, DevOps, and cybersecurity, and when you combine all these you can get much deeper insights into security and can integrate deeper within an organization to provide more proactive measures.
Would be more happy if you prove me wrong.
1. You're limiting your TAM to just healthcare startups. Why? 2. After not that long, it doesn't make financial sense for your customers to stick with you. I speak from experience on this one having moved some number of customers off of Aptible in the past. Aptible was charging 10X AWS for a pretty thin wrapper around AWS. At any kind of scale beyond a handful of machines it makes sense to just bite the bullet and hire a devsecops person, who in the end will do more for you.
My advice here is to think bigger. Think about what value the GRC/Security/DevOps teams of bigger orgs are delivering and how you could displace (some) of them.
Our end goal isn't to work with startups to automate compliance - we're using this as a launchpad to going upstream in the GRC space.
As a founder, I'll ask you why not start with the actually value proposition or goal you want to achieve right away. Why are you making your jouney very convoluted?
It's been an effective entry point into the market for us -- establishing a foundation with companies that need to become compliant for the first time and building out core compliance features is a great stepping stone. Lets you work with additional customers while building out your larger product visions.
We deploy all on your own AWS cloud so you're not paying any marked up fees or being faced with surprise bills.
If you have any thoughts on this would love to hear them!
But over the years, with the enactment of the Privacy Rule, Security Rule, HITECH Act, Omnibus Rule, etc., HIPAA's implications have been shaped quite a bit.
So that's why suddenly every nurse wants to talk to you, check your blood pressure, and a different nurse wants your blood oxygenation… and that guy that walked by who greeted the doctor seeing you, and talked about how much the 49ers sucked last weekend, and flirted with the nurse? Bill's in the mail.
There are avenues for billing via consult (eg doc to doc conversations), but what you claim is very far from the truth.
We provide a similar compliance checklist/preparation tool to Tugboat, as well as HIPAA-compliant infrastructure and technical configurations. We’ll set up your application on compliant infrastructure deployed in your cloud, integrate CI/CD pipelines, and provide real-time logging/monitoring. Providing the technical piece that's compliant out of the box lets you save weeks of manual work configuring it yourself.
By covering you not only on an administrative/compliance front, but also on a technical/cybersecurity front, we help you actively enforce good security and monitor compliance comprehensively.
I haven't done healthcare stuff in GCP or Azure so I can't compare, but AWS is _not_ a blocker for HIPAA.
My understanding is that Google will not agree to any of the liability provisions inherent to a BAA, no matter how large your size.
> Google will enter into Business Associate Agreements with customers as necessary under HIPAA.
Huh! That's a pleasant surprise.
One of the main reasons why healthcare players were moving onto Azure was for in-built HIPAA compliant OpenAI access. We've been able to help our customers directly sign BAAs with OpenAI so this wasn't a concern.
Sorry but what?
Because of the close partnership with Microsoft and OpenAI, Azure makes it easy to get HIPAA compliant access to certain OpenAI models without having to go through OpenAI directly. This is why a lot of AI healthcare companies were building on Azure at first. Hope this clarifies!
Nothing could be further from the truth.
Another POV is that the compliance companies sell the holistic social experience of compliance. The people for whom this matters need checkboxes and don’t mind paying for consulting disguised as a CSA. In fact they may even prefer it.
Completely get where you’re coming from w.r.t. organizations looking to check a box. If we wanted to sell to those organizations, we would stop short of architecting their infrastructure and implementing best practices. A checkbox is never enough, and a point in time review can be easily gamed.
We're (now only partially) on Azure for reasons stated upthread: desire from the industry. We've partially moved since, and the experience as a whole has soured me on Azure as a reliable cloud provider (I've had to engage with support far more often). Their support, in particular, is terrible¹, and a lot of their offerings IME are less stable or harder to work with than AWS. I'm now moderately experienced with GCP, and I think GCP has them beat, too.
¹missed SLAs, a huge desire to close tickets prematurely, failures to address things asked of them, really bad communication skills, constantly divorcing replies into new threads, dredging up asked & answered stuff, repeatedly asking questions covered in the original ticket's opening set of answers, asking the customer for stuff they should know, etc.
Regulatory is where a country in which we do business has requirements for how we run our infrastructure. Luxembourg is notorious for being the most demanding.
The website is too thin, it looks like you're really heavily relying on meetings to get customers rather than the product itself. I think you should dedicate some resources to fleshing out the website A LOT with more information because it actually looks like a potentially useful product, but I'm not going to commit to a presentation just for more info. This is a red flag, as in my experience companies with little public info and who want to share everything in demos/meetings have a lot of warts they try to hide by a highly curated meeting experience.
Cancel the blog portion, it's 2024 and no one cares about company blogs. No one ever DID, but they were popular for a hot minute anyway, and that minute is gone. Don't blog and take that time to flesh out the website dramatically. Right now your sole blog post is a 2 minute intro to HIPAA. Anyone who doesn't know what HIPAA is will not be a customer, so this post isn't helping you at all. I think your #1 priority this week should be flooding the website with information about the product. How-To guides, detailed descriptions of features, videos, even an interactive demo would be great.
I'm not sure if your product is narrow and focused on helping code compliant apps, or if you're a general compliance checklist suite. The latter is WAY more useful than the former. If you're the former, I'd suggest expanding your scope to get more business. when I thought this was an enhanced HIPAA compliance suite, I was ready to get more info, now that I see it may be focused on app development only, I don't care about it, as honestly getting computers compliant is a lot easier than getting humans and processes compliant. If you're not just focused on development, this reinforces the website problem.
Kill your FAQ: "How is Delve different?" Please flesh this out to about 1,000-1,500 words on another page and go into more detail. "Has Delve been reviewed by HIPAA auditors?" Don't tell me, link me to your PDF compliance reports. "How do I know your infrastructure is secure?" Combine this with the question above and link me to your PDF compliance reports. Then make it it's own page like with the question above. "How can I show my customers that I’m HIPAA compliant?" Again, it's 2024, no one cares about badges, they want BAAs and compliance reports. People understand today that a little badge on a webpage means nothing. This isn't even a question you should be answering, actually. Only your customers can answer that through knowledge of their customer base.
You look like a promising startup, I hope you accept this critique from a decision maker in your target audience in the spirit it's offered. It's not meant to say you're bad or dumb, you just need to spend some real time on the website and information shared with potential clients. Right now you look interesting, but not enough for me to reach out yet. A more detailed website would change that a lot.
Similarly, we provide a compliance checklist like Vanta, along with HIPAA-compliant technical infrastructure and technical configurations. We’ll set up your application on compliant infrastructure deployed in your cloud, furnish CI/CD pipelines, and provide real-time logging/monitoring.
We do a lot of active work to prevent attacks, route your traffic through our protective firewalls, and automate DevOps/delay your need to hire a DevOps team. These are tasks you'd have to complete manually if you were to go with Vanta. By automating them, we save you weeks of work.
Same situation. I was just about to write this exact comment. I don't need a platform, AWS already has plenty of services that when set up correctly are fine. And AWS already has the checklist they're showing as the main demo implemented. You can security scan your services and get exactly this checklist.
Basic technical compliance is not the hard part! It's everything else. Like the nice doctor who sends an image by email to investigate a scan after work who ends up being a problem. Or people who share passwords because they can't be bothered to get everyone signed up for a resource. Or someone making a bad decision about what is or isn't PHI because they don't understand the rules clearly. Or the creepy person who searches for their neighbour's medical records, etc.
> "How can I show my customers that I’m HIPAA compliant?" Again, it's 2024, no one cares about badges, they want BAAs and compliance reports.
In my experience no customers will ever ask if you're HIPAA compliant. This is something that comes up in a lawsuit or when a regulator visits. If anything, security stuff scares people away, best to say nothing.
> A more detailed website would change that a lot.
Agreed, the idea that HIPAA will be one click away and we never have to think about it again is silly. Because the website is so thin it comes across as written by someone who has never dealt with HIPAA.
It's also not clear to me how this whole setup works with legal. You cannot outsource compliance. When the state comes knocking one day with a big fine because there's a breach or mistake in whatever Delve is doing, we can't throw up our arms and say, well we have this dashboard that says everything is fine.
We totally agree. And to clarify, we don't just provide the technical compliance checklist (AWS Audit Manager already has all that), we provide the comprehensive list of tasks and policies that you need to put in place to be prepared for a complete audit. This spans terraform for technical infra setup all the way to 20+ legal policies (BC/DR Policies, Asset Management Policies, Access Control Policies, etc.)
> In my experience no customers will ever ask if you're HIPAA compliant.
For startups and earlier companies, being HIPAA compliant (whether it's a compliance badge on the footer of your website or a compliance report that you send to customers) is immensely helpful in the sales process. It signals credibility and trust. Sometimes this can be the difference between getting a sales call vs. not.
> A more detailed website would change that a lot.
We completely agree. We're rolling out a new version of the website taking to heart all the feedback you've given and will reply here in the coming days once we've pushed the updates.
> It's also not clear to me how this whole setup works with legal.
We're not replacing your legal counsel nor are we guaranteeing compliance. We're giving you the tools to be compliant that we've revised and refined with the help of auditors. At the end of the day, if you intentionally deploy an application that posts people's medical data to Twitter or you leave your computer unlocked on a subway, we can't take liability for that :)
1. We'll certainly update our website to be more comprehensive about our exact infrastructure setup and security best practices. We're releasing a security page that specifically details this. This should address your comments on adding more product information.
2. Interesting insights on removing the blog. We've actually received positive feedback on our 2-minute quick guide to HIPAA and some of our current customers found us exclusively through that blog post. We're also soon to roll out a small collection of blogs featuring auditors/CISOs/etc. and particularly for startup founders new to HIPAA, we've found that these can be helpful educational tools.
3. Clarifying our product, we're focused on both deploying apps on compliant infrastructure and providing a general compliance checklist suite. We help get computers, humans, and processes compliant - it's all in one. We're not just limited to computers.
4. We're fleshing out our FAQ and will move info around as mentioned in point 1.
5. We provide a compliant report to companies that work with us, not just a badge. Here's an example: https://app.getdelve.com/blandai
Thanks again for the thorough breakdown and feedback here! We're taking it all to heart and will reply to this comment once we've rolled out an updated version.
But I immediately had a few questions and am hesitant to book a demo (I'm quite time poor):
1. What clouds do you support? 2. What does the infrastructure look like, what services does it use? 3. Do I get locked into a particular orchestration or deployment setup? We prefer k8s for example.
1) We’ve made the conscious decision to start with AWS support, as our ICP is primarily on AWS (80%+). We plan to roll out GCP and Azure once we have sufficient coverage on AWS services.
(2) When you’re onboarded, we deploy a series of base resources (IBNLT networking resources, notification services, logging services). You can then select from a library of supported resources for your application-specific environment.
(3) To directly answer your question — no you are not locked in and can change as you see fit. Also, because we deploy infrastructure in your own cloud, you're able to go in anytime and make custom modifications to your infrastructure.
Under the hood, we define infrastructure using Terraform to explicitly define logical relationships between resources, easily enforce deny by default behavior, and spin up resources with granular access logging by default. We then expose a subset of toggles that users can adjust (compute resources, service connections, silo’d application deployment). Some toggles that may have a business need, but would prove to carry excess risk (such as blanket public exposure of data store’s), are explicitly disallowed. This is a decision that we’ve made and feel offers the ideal balance between flexibility and compliance enforcement.
Are you Delve , or Microsoft Delve?
https://support.microsoft.com/en-us/office/what-is-delve-131...
Aside that, neat idea.
Eg, Tracking on medical sites let Meta go to town -- https://www.theverge.com/2022/8/2/23288612/meta-hosptials-su...
Eg, Patient data brokers: "Currently, under HIPAA there is no law prohibiting the use of healthcare data shared via marketing practices." -- https://www.beckershospitalreview.com/healthcare-information...
Do you provide any technical solutions to help your customers control these trackers in accordance with HIPAA and privacy laws, or do you refer your customers to third-party privacy solutions to accomplish this?
You expressed disdain for "hitting checkboxes," yet your solutions to this specific problem appear to be more checkboxes.
Asking customers to remove a tool from their site or request tool vendors to sign a contract is helpful, but it forces customers to make tough decisions: Do I lose revenue by completely removing a tool? Can I trust a vendor to follow their BAA?
Technical compliance solutions can remove this source of uncertainty by directly controlling tracker behavior on a fine-grained level.
[1] https://compliancy-group.com/what-is-a-hipaa-certification/
HIPAA compliance can be boiled down to “implement best security practices, record every request & transaction, and enforce zero trust to the truest exist possible.” Once you've done your due diligence with this, you can self attest compliance.
My favorite example is a clown who decided when I was on vacation that we should “voluntarily comply” with IRS 1075 guidelines, in a context that had absolutely nothing to do with the IRS.
The motivation was to literally reuse work done for another, unrelated client and protect.
HITRUST was initially developed as the answer to HIPAA compliance, although the framework has now been rebranded as industry-agnostic. Hence, there is a good amount of overlap as you mentioned.
I am interested in this and will be someone could be pitching this to many others, but I want it with cpanel cloud hosting not aws/git/whatever.
I’ve only seen and personally used CPanel for on-prem management (paired with WHMCS for billing), which is not something I’ve come across so far here. Happy to talk about this more though if you have time.
I appreciated what Delve is doing for these kind of companies but what about non-tech small companies & individual therapists that process health data? We enlist the services of multiple behavioral / mental health providers and most of them use personal devices / SMS / GMail for transmitting PHI[1]. I understand this may not be the target audience for Delve but getting these kind of companies HIPAA-compliant is a real need.
[1] https://www.hhs.gov/answers/hipaa/what-is-phi/index.html
For more context, HIPAA breaks companies into two categories: (1) Covered Entities, which are healthcare providers, health plans, and healthcare clearinghouses, and (2) Business Associates, which are companies that process PHI on behalf of Covered Entities.
Behavioral/mental health providers fall into the Covered Entity category, and their requirements under HIPAA are different than those of Business Associates. Our services are currently focused on supporting Business Associate needs.
If doctor etc is a Covered Entity then that doctor is most likely a Provider, but is every doctor providing healthcare a really CE?
I wouldn’t have said no but I don’t track it ultra closely so I’m curious what’s the latest? My first three results matched my expectation but they could easily be out of date…
https://www.epatientdave.com/2020/02/03/hipaa-you-arent-a-co...
https://www.stevenslee.com/health-law-observer-blog/is-a-cas...
https://www.americares.org/wp-content/uploads/globalassets/_...
Anyway re the parent, my fourth result uses therapist as the example of uncovered providers, which would have been my guess
https://www.consumerreports.org/health/health-privacy/guess-...
For example, you could be a medical app that processes pages and pages of medical data from an individual, but if you're not doing it on behalf of a Covered Entity, then you won't be subject to HIPAA.
In cases like these, as well as certain therapist examples and other scenarios described in the final article you provided, HIPAA is not applicable. It's still good practice to have proper security measures in place, since there could be other governing bodies regulating you (e.g. the FTC, https://www.ftc.gov/news-events/news/press-releases/2018/10/...), but you're not regulated under HIPAA.
If you're using another platform to manage the infrastructure/hosting, you'd be able to integrate with us to complete the remaining parts necessary to get HIPAA compliant (i.e. the legal policies, compliance task list, risk assessments, vendor reviews, etc.).
That being said, a lot of our customers prefer migrating over to our infrastructure because many hosting services charge high usage-based fees for HIPAA compliance and it ends up being cheaper to deploy straight onto AWS, where they can use their AWS credits, for their infrastructure management.
They are all preludes, however, to agreeing to liability amounts/indemnification in the actual contract.
This is why, as an example, most healthcare orgs end up moving away from Google. Google (to my knowledge, which includes large deals at F50 level), will not contractually agree to any kind of financial or legal liability for data breaches, hacks etc.
Microsoft (and to a lesser extent Amazon) will agree to such terms if you're a big enough account, and generally already have some kind of framework in place with your procurement dept likely that simply needs to be amended.
This is also why larger healthcare orgs are reticent to work with smaller, less well capitalized startups in the ecosystem. The liability alone should something go wrong would potentially vaporize your company, and would definitely lead to uncomfortable conversations with your investors (who maybe, might also have large holdings in the larger healthcare orgs and be incented to not do stupid things that would create massive liabilities!).
While this sounds very dramatic, aren't the "less well capitalized startups" in your scenario the ones responsible for their own HIPAA violations, and not the larger healthcare orgs?
> Yes! HIPAA auditors have reviewed Delve to ensure that we cover HIPAA requirements.
To me, the word 'review' is doing a bit of heavy lifting. There's a lot of self-attestation in the HIPAA world, a lot of policies and processes - but to my understanding (and forgive me if it is flawed), any actual auditing is on specific implementation, not generalized.
I think your statement is accurate, to be clear - but I think the concern I had was that someone less nuanced or experienced might read something that isn't there into it - i.e. "our tooling has been audited". (Mind you, I also think that someone "less nuanced or experienced" probably shouldn't be heading up a PHI solution, so maybe self-selecting).
Also:
> Our infrastructure has been vetted by cybersecurity and DevOps experts from AWS, Google Cloud, and more.
Similarly, this heavily implies that AWS has done some attestation on your product, which I doubt. For one, in my experience they only partner with compliance partners, and will only attest to their products (and not even all of them).
Regarding your first point, we've partnered with auditors at Insight Assurance. We've worked with them to map our compliance workflow, infra setup, and controls list with their auditing controls list. This lets us ensure that our compliance tool meets the standards necessary for a HIPAA audit as well as general security best practices.
Regarding your second point, we've put our infrastructure configuration through multiple rounds of review with AWS architects that we are working with through YC, with an exited DevOps engineer/founder that we've hired onto our own team, and with our own technical background from MIT. Of course, we have no official attestation from AWS. We've done a lot of due diligence in battle-hardening our infra setup (one of our clients receives 3M+ postgres requests an hour, which we are able to support).
https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final