The Paths to Healthcare PLG (Part 1)

or How I Burned My Retinas Reading Up On HIPAA

Special thanks to Brendan Keeler, Jay Rughani, Samir Unni, Matt Fisher, Aaron Maguregui, Alex Zhang, Dan Witte, Adam Steinle, Neha Katyal, Dave Bour, Paulius Mui, Blake Madden, Sage Khanuja for feedback, inspiration, legal review, or general perspectives that led to this post. This was a particularly challenging post to write due to the legal complexity, so really grateful for all the help. None of the below is endorsed by anyone listed; simply my thoughts.

TL;DR:

• The promise of product-led distribution to end users in healthcare has been largely unfulfilled.

• This is primarily due to HIPAA’s restrictions around PHI exchange, driving Covered Entity organizations towards arduous review cycles.

• There are 5 currently established methods with which one could go direct-to-end-user. Product-Led Excitement; Non-PHI Workflows; Cash Pay Transactions; End User Represents Covered Entity; Patient Authorizations

---

PLG Has Stalled In Healthcare

Over the past few years, with product-led-growth (PLG) proving its viability across other industries, there’s been optimistic musing about the potential of the motion within the healthcare space. To provide a quick definition: product-led growth (aka bottoms-up aka B2C2B aka Direct-To-Clinician/End User in the healthcare context) focuses on offering end users of enterprises a self-service version of the overall offering with the ultimate goal of driving enterprise sales - Notion, Slack, Datadog, Calendly, Airtable are all common examples.

Against some of the core problems that plague the industry, PLG seemed to offer a path forward:

• centering distribution around the end user mitigates the principal / agent problem

• historically maligned UX would be met by the iteration pace seen only in consumer-focus companies

• in overly saturated enterprise SaaS markets, high end user utilization metrics from a successful PLG approach drive leverage while avoiding pilot feature bloat common to B2B

• Lower CAC / efficient growth at scale compared to sales-led peers

With the stranglehold that incumbent distribution has on deployment of novel solutions (AI-enabled or not), tightly aligning with end users can also give new entrants opportunities to build brand, buy time, and stay closest to true problems. This is valuable in arenas where advantages are hard to come by and disappearing by the day.

The uptake of the motion companies has been steady for companies that face patients, scientists, developers, and employees. Organizations here have begun to successfully reach maturity or at least prove out the motion. Some examples (Jay Rughani’s post here for further reading):

• Maven or Noom’s initial distribution to patients followed by an employer focus.

• Benchling to scientists and academics

• Many of the healthcare tech stack for developers

• Bold for health plan members

However, for other end users in healthcare (and clinicians in particular), progress has been more stagnant, despite the evident advantages (further outlined in Morgan Cheatham’s great post on Direct-To-Clinician).

Title II of HIPAA (the Privacy Rule) has been the primary point of friction. For any organization creating products for Covered Entities (providers, pharmacists, payers, labs), if they process PHI, they will need to sign a BAA with the authorized executives of their Covered Entity clients. The enterprise stakeholder leapfrogging the end user in priority drastically reduces the potency of any product-led approach. Brendan Keeler said it best here:

Tweet Source Link

So then, in what ways are end user distribution currently viable in healthcare? Where can you utilize such a motion, and how?

Not being a compliance expert, I dove head first into the murky waters of PHI regulation. I can’t say I came out unscathed. Strictly speaking, none of the below is legal advice (if it isn’t evident, I am not a lawyer) but perhaps interesting potential paths to explore in more depth.

Me combing through this post to make sure I didn’t spell it “HIPPA”

This is a two-parter:

1. Paths that you might be able to take to go direct to Covered Entity end users

2. How LLMs might further unlock these paths (and make a new one) for new entrants

---

Paths to Healthcare PLG

Within the constraints set by the Privacy Rule lie a few paths forward:

1. Product-Led Excitement

2. Non-PHI Workflows

3. Cash Pay Transactions

4. End User Represents Covered Entity

5. Patient Authorizations

Product-Led Excitement

We start with the simplest path: providing end users access to varying layers of visibility and control of the product in non-production settings. Product videos, demo environments (perhaps populated with synthetic data) and similar collateral can serve as end user facing product marketing - do this well, and this “product-led excitement” might trickle up to the relevant stakeholders and move the needle. You might optimize this further by targeting communities of end users.

This approach has a safe but low ceiling. Without utilizing in live environments, users will have limited understanding of product capabilities, and no true adoption is occurring.

Non-PHI Workflows

To go past HIPAA’s restrictions, why not avoid PHI entirely? This has been the dominant way forward for companies taking on the motion, including many from the below market map from Bessemer.

Source

If Covered Entities consist your target market, you have a few ways to directly reach your end user.

Non-PHI Primary Product: Product domains that avoid PHI entirely lean towards the more operational elements of Covered Entity organizations. Administrative (ex. Headway) and financial (Nitra) organizations can build entire product suites; if there’s a sensible wedge towards a self-service offering, it’s relatively smooth sailing here. Many developer-facing products for healthcare tech orgs will fall under this category as well.

PHI Adjacent Product: Naturally, the closer your product is to day-to-day PHI-handling workflow, the more HIPAA will come into consideration. It’s possible to still reside purely in the non-PHI domain (for ex. many reference tools above) - and maximizing value here will create end user stickiness - but deepening value for enterprise clients may mean crossing over into PHI-handling features. This is a sensible point to feature gate, and trigger enterprise sales conversations.

Butterfly Network serves as a great example.

We knew [enterprise health system’s] concerns around security and governance and integration, and so we built a software package for that. That then created the right dynamic, where we actually had a product to sell, which had higher recurring SaaS dollars attached to it. It was a win-win from that perspective: we could solve the clinicians problem of wanting to use it in the hospital, and then we’re driving increased subscription revenue and deepening our tentacles in terms of the integration into the organization and spanning across the organization to do more. - Bill Porter, Butterfly Network

PHI Agnostic Product: To draw the small distinction between this category and the previous: the core build workflow of a PHI agnostic product remains the same when handling PHI vs. not handling PHI; meanwhile, PHI adjacent products reside primarily outside of the PHI domain but likely require net-new product expansions to penetrate into PHI workflows.

An example here would be Awell - task automation can fully function to drive some live results for organizational end users without interfacing with PHI - and they did this to drive a bottoms-up sale.

Ultimately, I think the keys with this approach might be either:

• Finding non-PHI wedges that themselves possess high TAM

• Finding non-PHI wedges that might be lower TAM or conversion probability but can generate traction, combined with agility in expanding into PHI workflows that increase TAM

Cash Pay Transactions and DPC

HHS Source

Fun little quirk - HIPAA strictly applies to electronic transactions of specific information) between parties. An example: a provider organization becomes a Covered Entity upon electronically exchanging PHI with a health insurance company. These transactions are:

1. Health claims or equivalent encounter information.

2. Health care payment and remittance advice.

3. Coordination of benefits.

4. Health care claim status.

5. Enrollment and disenrollment in a health plan.

6. Eligibility for a health plan.

7. Health plan premium payments.

8. Referral certification and authorization.

9. First report of injury.

10. Health claims attachments

For providers that don’t exchange information electronically with insurance (i.e. practices that are strictly cash pay or strictly direct primary care), there exist ways to work around HIPAA restrictions, and BAAs are not required to be signed.

While interesting to note, it’s not yet a compelling area for building. The TAM is low (1762 total DPC practices in the US), and standard HIPAA restrictions will start to apply as soon as you enable third party electronic exchange for the above transactions (essentially all of which are mission critical interactions).

End User Represents Covered Entity

Legally binding BAAs must be signed by legal representatives of the Covered Entity - for ex., at larger provider organizations, CEOs, CISOs, Head of IT. To compress the BAA process, one can look to distribute to organizations where end users are themselves the legal representative, or very close to them. Essentially, sole practitioners and SMBs.

To these individuals, one could provide a simple flow with a standardized BAA, and enable immediate product utilization. Healthie has a version of this currently.

The most notable headwind in this motion is the currently shrinking market (in providers at least) - physician consolidation is steadily increasing, with roughly 7 of 10 physicians employed by hospitals or corporate entities. Moreover, the smaller complexity of problems in outpatient care compared to inpatient makes moving upmarket a formidable task that few have achieved.

However, as tensions rise between physicians and health systems, physician independence is increasingly championed. There’s a case to be made for intentionally targeting this overlooked market, making beautiful tools that alleviate specific burdens for these end users, and finding ways to seize outsized value. This could be tying into patient capture and accelerating it, or innovating within recent primary-care-centric alternative payment models (Making Care Primary; Primary Care First).

Source

Patient Authorizations

Covered Entities can disclose PHI if the patient (or representative of patient) provides a written authorization. This agreement can be drawn up by the third party for signage by the patient. The Covered Entity is no longer liable for the PHI release, and third parties (naturally) can work with PHI-containing data.

In the healthcare tech wild, DTC flows and Meaningful Use Patient Access APIs have been the primary adoption methods of this path, but I’m not sure if there’s been meaningful use (ha!) on the side of CE-facing software, for understandable reasons. In an era of heightening privacy anxiety and suspicion of third party data use (WSJ’s account of Amazon Clinic’s utilization of this path here), there will need to be extra precautions taken to quell both patient and Covered Entity wariness. The slight uncertainty in obtaining authorization could lead to adoption friction, and organizations have instead opted for the tried and truth path of enterprise BAAs. Lastly, the size of universe of realtime workflow products for clinicians that are easy enough to build yet have reasonable TAM has been relatively limited (until now).

However, if you can present the patient authorization flow in thoughtful ways within the workflow of the end user, strive for security in data obtained, and the tool dramatically improves the end user’s working experience, I think this path has potential. It seems that Upheal is utilizing this at time of writing. It’s not hard to imagine a world where clinicians are evangelists of tools that relieve burdens, and patients can buy into experiences that help their clinicians deliver them better care.

A wrinkle to consider here is the obtaining of patient contact information to initiate the patient authorization process. Covered Entity end users cannot directly provide third party software with email, phone numbers, etc. as that is by definition a PHI exchange. As such, the end user will have to facilitate the connection between your product and the patient:

1. Provide a path for the patient to access your product and create an account

2. Provide a patient authorization form with your product as the recipient

Finding ways to streamline this workflow would be key. One interesting example from the more patient-facing side: Ciitizen tapped into trusted patient advocacy organizations as a large node for patients, and was able to obtain patient authorizations through this as well.

Patient Side Value

Further, patient authorization flows can be part of overall patient-facing experiences, which might drive growth loops. Although they don’t utilize their patient apps to unlock clinician side workflows (to my knowledge), Abridge and Elaborate are great examples of orgs that have patient-facing feature sets that can drive patient-clinician word-of-mouth; GoodRx is similar, though more patient-centered as a product. In particular if you’re building for Method 1 described above, creating value props for the patient might be critical to success.

---

Read Part 2 next week for how LLMs can de-risk these paths for the product organization, and unlock a potential new one.

Thanks for reading, and I’d love to hear your thoughts on any and all of this considering all the fuzzy / gray areas it covers. Feel free to reach out in the comments or at my email | Twitter | LinkedIn.