Live data from Hacker News

What’s Really Killing Digital Health Startups

techcrunch.com

151–159 of 159 posts

Re: What’s Really Killing Digital Health Startups

#151
post #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

Care to elaborate? open.epic.com lists some nice FHIR apis? (Or this more a marketing stunt?)

Re: What’s Really Killing Digital Health Startups

#153
post #28

No discussion about APIs in health care EMRs would be complete without mentioning HL7's new FHIR protocols: REST-ful web service endpoints for HL7 health data. It makes developing applications with these standards much easier. But that's only one piece. You need business relationships to even connect to the EMR in the first place. I think the problem with breaking into this industry is: (1) Huge incumbents with tons…

FHIR is probably the best hope that we've got. I am biased of course, but I've bet a few years of my life on it. :) Happy to help anyone learn more about the spec @medhacker [1] http://www.annemergmed.com/article/S0196-0644(15)00226-7/ful...

EM resident with an interest in EHR design and development here -- this is really cool, I didn't take a close enough look at this in Annals in August but I'm reading about the spec now. Looks promising.

Re: What’s Really Killing Digital Health Startups

#154

Earlier quoted context omitted.

>the reality is that the majority of established businesses are using unsexy and what they would consider to be "legacy" technology. I once asked a question online about a legacy technology. The only answer I got was a smug "don't use [technology], it's outdated." I work in a "people's lives depend on this" industry, not a "move quick and break things" industry. That's why I am working with "outdated" technology. We…

Does it though? Does it do its job well? Does it have scheduled maintenance every evening for the mainframe batch job? Does it not handle non-ascii in names? Does it not have the perspective of knowing how much better it could be done, like webmail before gmail? Just rewriting in new technology won't necessarily make it any better though, I'll definitely grant you that. I'm one of the crabby people who prefers techno…

Does it though?

Yes.

Does it do its job well?

Yes.

Does it have scheduled maintenance every evening for the mainframe batch job?

No, its used 24/7 and does not run on a mainframe.

Does it not handle non-ascii in names?

Who the hell cares? It doesn't have to.

Does it not have the perspective of knowing how much better it could be done, like webmail before gmail?

I don't even know what you mean. I think webmail before Gmail was great. Gmail is always changing its UI and confusing users. Gmail didn't bring anything to webmail except a ton of free storage.

The software is fine it doesn't have many big flaws and it operates in a space where people depend on it working right so they don't die. We still release new versions once in a while but its not too much work.

Re: What’s Really Killing Digital Health Startups

#155

Earlier quoted context omitted.

> Basically you need to go into this knowing it'll take 3-4 years before you can show any traction. This x10MM

An upvote is preferable to a meaningless comment like "this" which adds very little value to the discussion.

this

Re: What’s Really Killing Digital Health Startups

#156
post #151
post #108

Earlier quoted context omitted.

Open Epic is a joke

Care to elaborate? open.epic.com lists some nice FHIR apis? (Or this more a marketing stunt?)

They aren't really ready for use. FHIR isn't really ready for use. While it's version 1.0.2, there's a lot of functionality lacking; for example you can't send back orders. And it seems like they have frequent breaking changes at this point. I've also yet to hear of anyone actually getting permission and using the open Epic FHIR apis in production.

Calling it a joke is probably too harsh though. It just isn't the panacea that PR makes it out to be.

Re: What’s Really Killing Digital Health Startups

#157
post #94
post #92

Earlier quoted context omitted.

Well that's because a grocery store isn't a health care company: it's a retailer. You can also buy very unhealthy things at the grocery store. What you describe is absolutely the wrong way to start a business: you should look at the type of business you want to open (in this case, a restaurant) and look for white spaces. Opening an organic restaurant is only a sensible idea if the market would respond to an organic r…

What you describe is absolutely the wrong way to start a business It seems to me that what I am describing is exactly what (at least some) disruptive businesses -- like AirBnB -- do: Redefine the problem in order to find a white space because the thing they are doing did not exist until they did it, so there isn't really any competition.

Right; but that doesn't work in health care because of the regulatory environment (which in this case, is absolutely necessary). It's not like the hotel business where if you have a bad experience, Airbnb can just solve the problem with money. There is a long history of misleading health claims on products that has existed for almost all of human history; so any product you claim improves the health of the user has to be backed up by data.

"Redefining the problem" is marketing speak for finding a way to trick consumers into using your business model. It's fine in the case of something like Uber where you're short-circuiting a bunch of disparate and protectionist taxi laws, but federal regulatory agencies are rarely fooled by such tactics, and aren't shy about labeling you and your company as scam artists while sending a federal prosecutor at you if you try.

Basically, if you're gonna fuck with the government, make sure you fuck with municipal and state governments. The feds don't take crap, and will steamroll you if you threaten to circumvent their jurisdiction or deceive them in any way. This happens to hundreds of companies a year (just look at Theranos and 23andme for some high-profile examples), so they're definitely not bluffing.

Re: What’s Really Killing Digital Health Startups

#158
post #136

Earlier quoted context omitted.

> 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 w…

Must you really deal with the intricacies of HL7 to do this, then, or do you simply pull a few fields from the MSH and then go grepping away for ^IN1\|(something-interesting)? In my limited experience various parties use HL7 messages and structures in strange ways for whatever the heck they feel like, within the loose bounds of reasonableness.

We use a proper HL7 parser built into our interface engine (Mirth Connect), extract the data we use and dump it into PostgreSQL. Regular expressions would be an adequate tool for parsing HL7 if you wanted to roll your own, but it made little sense to do everything from scratch.

Re: What’s Really Killing Digital Health Startups

#159
post #71

Earlier quoted context omitted.

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 thi…

Including XML and RDF doesn't bother me. A lot of people greatly prefer JSON over XML. I don't get exorcised either way. The final two look like problems. I would guess the penultimate one is because most medical systems ignore time zone so you just assume it happened in the time zone of the system of origin. It probable doesn't matter often in practice. If two different patients had a lab test done on opposite sides of the world would that knowledge ever be important? On the other hand, time is important within a patient data set. This might be a problem if a patient radically changed time zones within the course of a day.

I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.

Post reply on HN