hckrnws

So what you may have already discovered, is HIPAA compliance, HiTrust certification, BAAs, etc are table stakes for servicing covered entities in the healthcare space.

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!).

Completely agreed. Trust and credibility are harder to prove for startups trying to contract to large health organizations, which is why a HIPAA compliance report or active monitoring from a 3rd party can be really helpful. Some large hospitals even turn away calls from startups for this exact reason. Compliance is table stakes. It's important to address HIPAA early and be able to attest to your compliance and security.

> 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

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?

There's also the business risk that a company you depend on goes poof and you're left scrambling (scrambling doesn't work well in healthcare IT, so much of it is bespoke and barely working... projects that look like they should work routinely fail years later in at integration setting everything back three years... it's a mess).

Every org that starts out with an compliance oriented SaaS in my experience ends up migrating out of it eventually because when they grow - they have more capital to build their own infrastructure as hire more engineers who do not want to deal with kinks of a SaaS abstraction.

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.

Thanks for the transparency and thoughts on this!

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.

I'd say your offering seems to fill a void for nonprofit agencies like mine, and possibly public entities (like counties) who don't have the internal staffing/expertise to spin up and monitor HIPAA-compliant infrastructure, and are responsible for integrating health data from disparate sources.

Solutions like this wont work in large orgs that have lead to huge ACVs.

Would be more happy if you prove me wrong.

No you're right for sure. Aptible is mentioned a few commends down, and is/was basically the same business (compliance focused hosting for small startups). Now Aptible has seemingly pivoted away from that focus and are now trying to compete in the PaaS space. There are a couple of obvious reasons here.

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.

We absolutely agree. HIPAA compliance for startups is only the beginning for us. We're rolling out SOC2 soon and then will use these as a foundation to moving upmarket.

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.

I have an opinion about that too. It is super competitive and very democratised. Last I checked there platforms that would charge just $2500 per year for their GRC platform. That's pretty low in my opinion.

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?

You bet. We get an interesting mix offering Heroku-like deployment with Vanta-style compliance preparation. We're not just an annual subscription-based GRC checklist that passively monitors, we're an active tool that enforces security on a technical front and runs checks every time an engineer git pushes. We also don't charge usage-based fees, so no one is charged an additional 10x of their AWS usage cost, which any large organization would with good reason want to churn.

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 have investor pressure to use specific cloud providers. This is the Healthcare version of Walmart not letting their partners use AWS. Due to their (Amazon, Google) vertical integration slowly moving in on healthcare turf, many healthcare partners/payers/investors are adding contractual pressure to exit AWS or GCP and move to Azure specifically. Wondering how your cloud support in general looks. Your previews are all AWS-centric

We currently support AWS but use terraform for deployment, which is pretty cloud agnostic. So far, we haven't gotten any major requests for expanding to other cloud providers and most of our incoming customers are already on AWS anyways.

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.

> We currently support AWS but use terraform for deployment, which is pretty cloud agnostic.

Nothing could be further from the truth.

You’re right but the kind of people who buy this service buy into the perception that Terraform is cloud agnostic, and perception is reality.

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.

At the end of the day, whether its AWS S3, GCP Buckets, Azure Blob Storage, or EKS, AKS, GKE — there are services to serve as drop in replacements for their competitors. The principles of deployment will remain the same as it pertains to access and compute allocation, but obviously the resource definitions, and the definition syntax, is unique. We’re solely focused on building out our AWS support (a function of market pull), and plan to use the same architecture design for additional cloud providers when it comes time to make that jump.

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.

While you're right about the access to AI models on Azure, I wouldn't tie my infrastructure to Azure just for that. Sure, you might have to use them for that service, but ship the queries in & the results back to a cloud of choice; especially LLMs in most uses cases won't represent a huge amount of data; the costs of egress < the costs of dealing with Azure.

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.

Sorry to hear that your experience with Azure has been sub-par. I know there was a sizable wave of people that migrated over to Azure for the AI models but haven't heard too much from them since. Interesting to hear about your experience...

> for in-built HIPAA compliant OpenAI access

Sorry but what?

A lot of healthcare companies are wanting to use GPT4, Whisper, and other LLMs from OpenAI, but these aren't HIPAA compliant out of the box. You still have to sign a BAA with OpenAI and get on their zero data retention (ZDR) plan.

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!

I'm in banking and we have similar pressure to leave AWS, but for different reasons. Simply too many banking services are already on AWS, and if a single could goes down it mustn't take most of banking infrastructure of a country.

I work at a mega bank and I haven't heard this angle yet. We are pushing lots to cloud. We have "yes, we're serious" resiliency and regulatory requirements though.

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.

https://dantheengineer.com/bank-of-england-worried-about-con...

I figured most of the big banks still use AS400s. Have they finally shed those?

Surely mainframes?

Interesting, haven't heard of this. Always figured aws and gcp were ahead of azure in terms of Healthcare

They are, so I want to smash my face in once a month or so when this boogeyman is dragged up out of hell during executive calls

AWS is fine for building out HIPAA services. They have a decent portal at https://aws.amazon.com/compliance/hipaa-compliance/ explaining their compliance, which services you can use, and how to get them to sign a Business Associate Agreement (BAA).

I haven't done healthcare stuff in GCP or Azure so I can't compare, but AWS is _not_ a blocker for HIPAA.

> I haven't done healthcare stuff in GCP

My understanding is that Google will not agree to any of the liability provisions inherent to a BAA, no matter how large your size.

Someone else linked to https://cloud.google.com/security/compliance/hipaa which says:

> Google will enter into Business Associate Agreements with customers as necessary under HIPAA.

Huh! That's a pleasant surprise.

I've heard that that page is outdated and instead if you sign into G Suite as an admin, go to the admin console (admin.google.com/ac/companyprofile/legal) and then go to "Security and Privacy Additional Terms" you can review sign a BAA.

They're ahead technically, but, for example, Microsoft has its claws in a lot of the NHS in the UK.

Sort of related: it seems like compliant providers and services are carrying the burden of patient privacy in good faith, securing the front door. Meanwhile, there are open tent flaps on the sides and back. It's hard to do the right thing while there are minimal regs and enforcement on the rest of the ecosystem.

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...

Yes, you’re correct in your assertion that infrastructure policies are just one part of the puzzle. In conjunction with our preconfigured deployments, we provide customers a set of legal policies we’ve worked with former US Attorneys to closely align with the spirit of HIPAA enforcement. We’ve all seen the countless byteDance and Meta cookie data leakage headlines on insurance and healthcare portals, and provide customers with notice to remove trackers, or sign BAAs with user metrics companies where possible.

> [we] provide customers with notice to remove trackers, or sign BAAs with user metrics companies where possible

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.

Good question, these trackers typically come in the form of developer installed pixels / trackers, making this situation a function of human choice. During onboarding, we conduct a supply chain vendor risk assessment, identify which vendors we can help facilitate a BAA agreement with, and which vendors (if any) need to be removed from a deployment. From there we provide the resources to initiate a communication channel with the associated vendor.

Point-in-time supply chain vendor risk assessments are nice, but they cannot control realtime website behavior. Customers may want more configurability in this area so that they they can remove certain dataflows instead of only being able to bluntly remove whole vendors.

That's valid, and it varies on a case-by-case basis. You might want to track user behavior on your landing page but not on your provider-facing internal application. Flexibility, configurability, and proper risk assessment is key here.

> Most companies that process health information in the US need to become HIPAA compliant

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

It's an interesting point you raise. You're correct in that our current target audience primarily covers the companies that provide services to healthcare providers instead of actual healthcare providers.

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.

> … providers fall into the Covered Entity category …

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-...

Yup! Not every provider is classified as a Covered Entity and not every healthcare business is classified as a Business Associate. It's where the nuances of HIPAA law come into play.

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.

My 5 second reaction having managed a large organization in a compliance/regulatory driven environment is that these regulations need to be part of the orgs DNA or long term you’ll be buried by an audit. It’s not something you bolt on.

Yes, exactly. This is a similar battle IT folks face with implementing best practices with it comes to cyber hygiene, and the sooner it’s solidified, the better (shift left approach). That's been our current approach with helping early stage health tech startups, and will be a tough but rewarding battle as we move towards organizations with established practices (be it good or bad). Curious to talk more with you about this if you have time.

Sure. My email is in profile.

As someone who has been in healthcare IT for maybe 10 years, comfortable with HIPAA HITECH, SAS70, etc., one thing I took a pause at was:

> 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).

Glad you pointed these out!

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).

Looks great, and I wish this existed 2 years ago when I started building a HIPAA compliant product!

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.

Thanks for the question!

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.

Many thanks for the answers. In reply to 3, can you clarify the details of what deployment snd orchestration tools you set up for your customers? And if we are able to make modifications to the underlying infra, is there some kind of process that prevents changes that break HIPAA compliance?

Sure thing!

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.

It does more than just protecting sensitive health information, it also governs how billing works, so if you've ever wondered why some Dr. you never met is sending you bills in the thousands of dollars; HIPAA is where you can find out why!

Spoiler: Anyone who touches the patient, anyone who has a conversation with the patient, anyone who measures stuff of the patient, doctors consulted by doctors also get to charge.

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.

No, that is not at all why.

There are avenues for billing via consult (eg doc to doc conversations), but what you claim is very far from the truth.

Yes! HIPAA was initially rolled out for the portability and continuity of health insurance coverage.

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.

Excellent! Do you have any plans to support NIST SP 800 171 in future too?

https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final

Thanks! No plans for NIST at the moment but potentially down the line.

Healthcare CIO/VP here. Some thoughts to help you improve your communication to potential customers, AKA what I look for when I am evaluating a platform for healthcare use:

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.

> 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.

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.

> Basic technical compliance is not the hard part! It's everything else.

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 :)

Thank you for these insights! We're in the midst of revamping our website so your feedback was very well timed. We will let you know when we release the updated version of our website. In the meantime, summarizing some of your points:

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.

Good luck! We need more competitors in this space, and healthcare IT is a decade or mode behind everyone.

If it's only compliance then, why not go with the other vendors like Vanta etc?

Good question. Vanta offers a compliance checklist and integrates with your service providers (such as AWS, Github, etc.) to continuously monitor your system settings and highlight potential issues.

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.

No idea.

I remember early in Google Cloud I was working with a Google PM on health-related projects (Google Cloud Genomics). The PM was our ostensible expert on HIPAA, and explained many details (such as BAA). The one funny thing they said is "there is no such thing as HIPAA compliance, that term is meaningless". And I don't really understand what they meant, but I think they must have been wrong (even though they were supposed to be the subject matter expert).

Your PM was probably referencing the fact there is no audit requirement — HIPAA is self attestation.

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.

It's a weird topic. I always laugh about how "difficult" HIPAA compliance is often portrayed as in online forums. It's a reminder to me of how important due diligence is. Of the various regulatory regimes, HIPAA is not particularly challenging, and if it is, I'd be concerned with doing business with the entity in other contexts.

What I laugh about is that more than once I have had to explain HIPAA to my corp lawyer. I've had actual discussions where the lawyers proposed an immense amount of work, followed by me explaining that our work doesn't fall into the scope of HIPAA and therefore we do not need to comply with it or get any certification or sign a BAA at all. "But... .but .... we should comply anyway just to be on the safe side!".

Few things are more annoying than a lazy attorney prioritizing personal CYA vs representing the client or employer.

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.

We totally understand! We value complete transparency at Delve. If a startup doesn't need compliance (i.e. they fall under the Safe Harbor Provision or are a consuming-facing without connection to a Covered Entity), we'll tell them upfront. We value building honest relationships with founders.

You PM is right. Unlike SOC2, you dont get a certification. More details here [1]

[1] https://compliancy-group.com/what-is-a-hipaa-certification/

However, if you want to do business with any reasonable size of healthcare org, you're eventually gonna have to get a HITRUST report.

That's true. Curious what your experience has been with HITRUST

Layoffs caught me before we finished the audit so I can’t say with full confidence. However, if you have a SOC 2 type 2 report, you’re probably 90% of the way there. They’re not perfect overlaps but it’s more like a circle viewed with astigmatism than the Mastercard logo.

Maybe. But Google Cloud has adopted the compliance terminology: https://cloud.google.com/security/compliance/hipaa

This looks really Great!!! Quick Question: How are the features and services different from what is offered by Drata and Secureframe?

Thank you - we really appreciate it!

Drata and Secureframe provide a compliance checklist and integrate with some of your vendors (i.e. AWS, Github, etc.) to passively monitor your configurations and flag concerns.

We provide the same compliance checklist that Drata and Secureframe does, and also give you HIPAA compliant technical configurations. We'll deploy your application with infrastructure that's compliant out of the box, provide CI/CD pipelines, and a real-time monitoring/logging solution. We do a lot of work on our end to block attacks, proxy you through our firewalls, and automate your DevOps/delay your need to hire a DevOps team. These are all things you'd have to manually configure on Drata and Secureframe. By automating this, we save you weeks of work.

How do you beat https://www.aptible.com/?

Great question! Aptible is great for deploying HIPAA-compliant applications, but you still have to purchase another solution for completing the legal policies and compliance checklist, such as Vanta.

Think 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.

Hi! Aptible founder here. I wanted to make an important correction here.

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

Thanks for sharing this! The demo is very neat and it's great to see other companies also prioritizing security and compliance.

I didn't see the mention of BAAs anywhere. Do you handle getting that signed with vendors like AWS?

Yes! We outline BAA requirements in our compliance checklist (i.e. we'll provide the exact steps of how to get a BAA with AWS and remind you to get BAAs with other 3rd parties).

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.

Do you enter into a BAA with all of your customers?

Yes, we sign sub-BAAs with our customers.

Great take! However, I wonder how you differentiate from platforms like Vanta? They already provide the monitoring and compliance framework you'll need anyway at some point. Frankly (and I don't want to sound too negative here) I doubt that a "one click compliant infrastructure" can work without knowing anything about the use case / application / dependencies of a company. Remember, it's not just about your system, its also about the stack you're building with, so it's quite a complex problem to solve.

Thanks for that! And good question. Vanta offers a compliance checklist and integrates with your service providers (such as AWS, Github, etc.) to continuously monitor your system settings and flag potential vulnerabilities.

We provide a similar compliance checklist to Vanta, 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 and having Vanta's API integration/AWS audit manager check it.

We use terraform to automate the infrastructure deployment process in a modular fashion. When you deploy with us, we take a dockerfile and basic information about your infrastructure setup, such as your availability region, RDS configs, instance sizes, etc. to deploy your application. This lets us support a variety of use cases and needs.

So this is for AWS style hosting, and there is no pricing info.

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.

You’re correct, we are putting our engineering focus into designing an enjoyable experience with AWS as our launch pad, and broadening our supported cloud providers as we continue to build out.

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.

Does this relate to HITRUST as well? I know the pain of those audits as I worked for healthcare companies that had them and a lot of the rules are similar.

It's slightly similar but HITRUST is still more comprehensive and is built on the CSF framework.

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.

theres a number of dead bodies in this space. it sounds like a great idea but once companies get big theyll diy. so your only market will be early startups for 1-3 years max and then theyll churn bf they ever get big enough to pay you what it's worth to get them on your platform in rhe first place. look at aptible and datica.

Thanks for sharing that insight. It's a stepping stone and it's critical to move quick.

What if I want to use the service but keep my already hipaa compliant hosting platform?

Nice question.

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.

I wish a solution like this for ITAR compliance

If we're being honest ITAR is quite far from HIPAA - can't promise that we'll get to it anytime soon :)

How does this compare to OneTrust and Tugboat?

Of course! Tugboat by OneTrust provides compliance checklist and preparation tools (i.e. InfoSec policies, audit management, controls mappings).

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.

Congratulations on Launch! Would you be plan to expand to Salesforce platform ? I am Salesforce partner would love to connect if you looking for implementation partners.

Happy to chat further and learn more about what you were thinking, our Calendly is always open: https://calendly.com/getdelve/demo

Very cool! Is there an equivalent for SOC2, GDPR, etc...?

We're rolling out SOC2 in a month! GDPR, HITRUST, etc. are down the line.

is there pricing information?

I'd also like to see pricing info available.

We charge a fixed annual fee — zero usage-based costs.

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!

Can you provide any numerical information regarding the pricing of your service? e.g. Variable pricing thresholds, target ICP budget, and service tiers are all relevant information here.

Well that'll be a fun name change.

Are you Delve , or Microsoft Delve?

https://support.microsoft.com/en-us/office/what-is-delve-131...

Aside that, neat idea.

Ah, we're the other Delve - the one that doesn't come with an Office subscription but makes your office HIPAA compliant.

[dead]