Live data from Hacker News

What’s Really Killing Digital Health Startups

techcrunch.com

101–110 of 159 posts

Re: What’s Really Killing Digital Health Startups

#101
post #58

Earlier quoted context omitted.

Certainly you can make money at integration, vast amounts of money are made. But as one friend in the business really did tell me once "your job is taking one piece of crap and another piece of crap, get them to talk to each other and so turn them into a third larger piece of crap". Integration "works" but overall often makes the problem worse or at best allows you to run place. Imagine when something else has to tal…

> For good or ill, The start-up ideal is generally to solve problems broadly, to disrupt an entire industry rather than build one more extension to that industry. But which start-up has ever done that? Not even Google or Facebook did disrupt an entire industry – they just built one more extension to an existing industry.

Meh,

Come-on, look at my context. Of course, disruption is never a fundamental up-end, just a streamlining towards a simpler and more productive approach - Uber and airBnB being the classics (whatever their social value or lack there-of).

The start-up approach (or disruption, the most archetypical part of it) is aiming for more streamlining at the end of the process - rather than aiming to be one more orifice slurping up money from one of the vast streams of money that already exist. Contrast AirBnB with a company that might "let you reserve rooms with ten of the largest hotel chains in the world" - sure, both change things, neither absolutely change the world but AirBnB is still a more fundamental change (again, in values-free terms).

Re: What’s Really Killing Digital Health Startups

#102

Earlier quoted context omitted.

What you say is true. I solved the problem by flipping it around. I'm going to give away the secret sauce I created for our backend. "Traditional" EMRs imagine an idealized data model and then write ETLs to import to that model. The jargon we used was "adjudicating the single best record (SBR)" or "source of truth". My system slurped up all data, stored mostly as-is, and then used information retrieval strategies (th…

Did you ever make it to a 510(k)? I can see Lucene making their head explode too...to say nothing of validation without checks on overwriting patient info, etc

I plead ignorance about 510(k). Scanning the wikipedia article, it might have come into play if our "patient portal" (think Microsoft HealthVault, Google Health) ever got traction. Because our brilliant notion was to store patient collected data (heart, glucose), to be shared with care providers. Another complete non-starter.

We did have live data feeds to the CDC. If there was a hoop, I assume we jumped thru it.

validation without checks on overwriting patient info

Our data store was write-only. In SQL parlance, no UPDATEs, just INSERTs (and SELECTs).

One hard requirement was to be able to show what was known when about a patient. "Traditional" data store solutions have "live" tables, separate history tables (recording changes), and maybe audit logs. My solution just had the log. Queries used a date range. Made QA/test trivial.

Re: What’s Really Killing Digital Health Startups

#103

I'm in the Health IT space but we took a different approach. Early on we realized most Health IT companies are really pharmaceuticals but they don't realize it. What I mean by this is, you need to have the budget of a pharmaceutical to play in this space: 1 - you need to spend millions to win over consumers and 2 - you need to have an existing network of connections into doctor's offices to convince them of your solu…

From what you've described, it sounds like the majority of target customers tend to be large companies? It would make sense with the longer cycles and probably less of an urgency to take a risk on new technology.

FWIW:

The study on physician practice arrangements found that six in 10 doctors were in small practices of 10 or fewer physicians in 2014, a number that's unchanged since 2012.

http://www.uhc.com/bmtn-categories/bmtn-news/2015/07/14/majo...

Re: What’s Really Killing Digital Health Startups

#104
post #62
post #45

Earlier quoted context omitted.

I have been consistently surprised that Zapier hasn't taken off like a rocket. Can anyone explain this? Zapier integrates an amazingly high number of SaaS's. And aside from the annoying lag due to their frontend being done as a SPA (which doesn't effect their API at all), they seem to be well-built. I do wonder a bit at their pricing, but it's not outrageously overpriced (and underpriced compared to many competitors)…

Zapier is great when you're dealing with REST (or even SOAP) calls. Problem is, most medical applications don't use REST or SOAP. Chances are they use one of many different variants of HL7, which usually operates through an ETL/data warehousing process. HL7 is one of those data standards that's only widespread because it's barely even a standard -- you'd have to write a different parser for every product or combinati…

> HL7 is one of those data standards that's only widespread because it's barely even a standard -- you'd have to write a different parser for every product or combination of products you integrated with.

I beg to differ, my past six months have been in the trenches with HL7 and while it's not perfect it's nowhere near as bad as you are making it out to be.

I work for a medical billing company, and a huge initiative we have had is to start getting demographics from hospitals we bill for in real-time instead of the daily batches we have historically dealt with, all through HL7.

We spent a lot of time implementing this, we have a "standard" mapping for HL7 messages that extracts all the demographic details we need from the standard segments, along with the ability to write a per-feed override to handle edge-cases where a specific EMR does something odd.

To date, the majority of the edge-cases we have had to write are finding insurance policy ID's in weird places at the end of IN1 segments. There's been a few others, but the amount of customization we've had to do on a per-site basis has been extremely minimal.

Re: What’s Really Killing Digital Health Startups

#105
post #77

Saying these companies could just open their APIs is probably wrong. None of the legacy EMRs has a good underlying data model and what they have tends to be customized per site. There might be some minor functionality you could get to work consistently across sites with such an open API but chances are it wouldn't cover everything your innovative startup needs. In summary I don't think it's only lack of willingness;…

What you say is true. I solved the problem by flipping it around. I'm going to give away the secret sauce I created for our backend. "Traditional" EMRs imagine an idealized data model and then write ETLs to import to that model. The jargon we used was "adjudicating the single best record (SBR)" or "source of truth". My system slurped up all data, stored mostly as-is, and then used information retrieval strategies (th…

Better search is definitely needed and seems like something the EPICs and Cerners of the world could easily do if they just assigned a couple smart people and left them alone. Instead they'll probably form vast teams of search stakeholders.

But search is only one need. You say EMRs imagine an idealized model. Maybe. They certainly never develop one. And that's what you need to reach the potential of medical data analytics. The software needs to "understand" what the data means without constant human intervention

Re: What’s Really Killing Digital Health Startups

#106

At drchrono (#1 iPad EHR on the Market, YC W'2011) we are building a very open API that has an open door policy to our customers and other digital health startups. If anyone is working in the digital healthcare space we'd love to work with you. You can get access to and build on our JSON API in 1-2 days. Sign up here: https://drchrono.com/api Here is a youtube video we shot with a startup that built on our API: https…

My dad's practice uses drchrono. It looks like the API usage is still in it's infancy. Can't wait to see more companies take advantage of it!

Re: What’s Really Killing Digital Health Startups

#107

Earlier quoted context omitted.

This comment and the OP mirror my own experience(s). Additionally, data interchange between competitors is a non-starter. Possible solutions (work-arounds) will be single payer or continued market consolidation (hospitals merging and then implementing one of the big systems like EPIC). Not mentioned is that continued churn like HL7 v3, ICD-10, meaningful use, etc. are hugely onerous while adding zero value. A cynic m…

You don't think HL7 v3 being somewhat of a markup language was an improvement?

It's a massive step backwards.

Bad has HL7 v2 is, it was a known evil.

With HL7 v3, there's so many more places to stuff data. And when it wasn't clear what goes where, partners created novel solutions. Just like with v2, but now with XML syntax.

We participated in an early NHIN competition (shoot out). The official WSDL only worked with one tool stack (Visual Studio?). I finally gave up and just screen scrapped the good bits. Used xpath to pull out the useful bits. Used SoupUI to create prototyped requests, manually massaged them to work, then turned them into Velocity templates.

We captured "official" requests and responses, stored them in source control. When something broke, we'd use diff to find the mutation. Turn-around was a few hours. Our two person team ran circles around our partner's teams with dozens.

I still use the fake it strategy for anything XML or web related.

Re: What’s Really Killing Digital Health Startups

#108
post #68

EHRs are starting to open up more. EPIC (largest EHR vendor in the US by market share) just opened an API for some types of medical data. AllScripts and Athena also have open-ish APIs. 5 years ago none, and I mean literally zero, of the EHRs had APIs.

Open Epic is a joke

Re: What’s Really Killing Digital Health Startups

#109
post #71

Earlier quoted context omitted.

FHIR is gross and overdesigned, like everything else in this moribund industry.

Can you be specific? I'm a skeptic but just now learning about it.

So, link is here for people playing the home game: https://www.hl7.org/fhir/ .

First, it specifies 3 different formats: JSON, XML, RDF. It should only pick one, preferably JSON, because that's the lingua-franca of the web.

Second, the datatypes are handled oddly ( https://www.hl7.org/fhir/datatypes.html ). Numbers, for example are supposed to handle arbitrary precision, but they pick the wrong datatype for it in things like JSON (should arguably be a string, or a properly-formatted Number).

Third, things like ContactPoints ( https://www.hl7.org/fhir/datatypes.html#contactpoint ) are left too open-ended. You run into things like "Well, this is not structured, some um I guess you should chase a URL to figure out how to deal with it". The point of a standard should be to standardize these fields...leave remediation to the people hired to do implementation and assume it is done correctly.

Fourth, time is still not quite handled correctly ( https://www.hl7.org/fhir/datatypes.html#period ). Period, for example, doesn't say what time zone the contents are in--a simple note "Hey, this should be in UTC" would have sufficed.

There are other issues around things like letting users bundle in embeddings of HL7 and other things, basically saying "this data can have arbitrary structure". It's a punt, and leads to things like having to infer (if you can) what a value means from it's "type" or "system" ( https://www.hl7.org/fhir/datatypes.html#codeableconcept ).

Re: What’s Really Killing Digital Health Startups

#110
I think it's interesting that this article is being written in a time when more Digital Health startups are surviving than ever before. It doesn't take being an insider to succeed in healthcare anymore; there's better options for hosting and information is no longer hidden or sold on how to integrate with EHRs and payors.

As someone who has spent the majority of my career working in Digital Health (née Health IT) and helping people get data in and out of EHRs, I think any assertions that we're about to enter a new era of magical integration efforts are usually off base. There's no magic bullet to solve digital health integrations. It takes:

- Defining the value proposition of integrations for your market (Meets regulatory concerns, reduces double documentation, saves time and money)

- Knowing what the playbook for integrations looks like for your industry. What does it mean to be an integrated telehealth vendor? An integrated cancer analytics platform?

- Having a team that know how to operate in the space. EHR and HL7 vets are hard to find, recruit and retain. I think this is particularly true in the Bay Area. Expertise here is crucial.

I know alot about this and this is what our team at Catalyze has focused on solving NOW, not whenever the magic solution arrives. Looking for help on keeping your Digital Health startup alive? Let me know. I’d love to help you out. Email me -> mark catalyze.io

Post reply on HN