What’s Really Killing Digital Health Startups

A friend of mine works for a digital health startup, and the majority of the RFP's they receive automatically disqualify them if they have anything hosted in the "cloud", so they are forced to buy and maintain all of their own servers.

In addition to these costs (which could already be considered prohibitively expensive) they have to use enterprise versions of proven ETL and BI tools for the perceived added security benefits (i.e. they can't use open source).

Agreed 110%.

> Having prices so high that only insurers can pay them means only insurers DO pay them and since hospitals and clinics know this they can charge whatever they want.

I've explained this in more detail on another recent HN thread, but basically: prices are 'so high that only insurers can pay them' by design, but it's not for the reason most people think.

It is generally illegal for providers (hospitals/doctors/etc.) to charge different rates to different patients based on their insurance status[0]. However, it is not illegal for providers to negotiate standard rates for specific payers. Combine this with the fact that providers lose money on their publicly-insured patients[1], and it becomes clear that they have to overcharge the rest in order to end up in the black.

So what they do is set absurdly high sticker prices, knowing that the private insurers will negotiate those down (usually this is done in multiples of what Medicare pays - e.g., Aetna will say, 'We'll pay you 150% of the Medicare price for billing code 99481 this year'.

Uninsured patients are stuck with huge bills as a result, though this is basically an unintentional side-effect of the fact that hospitals can't give them lower bills initially. It's also the reason that hospitals are almost always willing to negotiate with uninsured patients. If they know to ask, they can almost always get that down to 10% of the original rate. That bill isn't meant for individuals, they don't really expect individuals to pay, and they'd much rather negotiate a discount and have it paid in full immediately than have a patient default, which has negative repercussions for their bad debt ratio.

Privately insured patients end up having higher premiums as a result, because their insurers are paying higher rates to subsidize other patients who are not paying any premiums at all (publicly insured patients)[2].

[0] There's a little nuance to this, but that's the general idea.

[1] Medicare reimburses less than the actual costs of services provided per-patient, before accounting for any overhead

[2] This subsidy happens at the claims level, so it counts towards the insurer's requisite MLR.

Hospitals don't even know what a given service costs, so this statement seems to need a little more equivocation around it.

I work on a SOA team for a large healthcare organization, so I'm well aware of the issues. The problem comes down to the usual case of entrenched vendors working to protect and expand their turf. EHR vendors are notorious for being terrible for interop—some are better than others, but they all see integrations as competing with their own offerings. Non-trendy methods of exposing data—SOAP, custom MUMPS code, direct SQL access—are the norm. That's not a problem, except that documentation is often incorrect or nonexistent (while being restricted to direct customers, of course), and the vendors really don't care about APIs. They see interop as a necessary bullet point on a sales sheet, but they'd rather not have those APIs be used in place of their (usually crappy) complementary apps that they're trying to upsell.

Interop is a HUGE win for patients. Without it, we lose one of the main advantages of EHRs—the ability to access our own information when we need it, and allowing the information to be fluidly shared between providers. Of course, privacy is paramount—but in my experience, interop is not the attack vector I'm most concerned about.