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
What’s Really Killing Digital Health Startups
151–159 of 159 posts
Re: What’s Really Killing Digital Health Startups
#152Re: What’s Really Killing Digital Health Startups
#153No 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...
Re: What’s Really Killing Digital Health Startups
#154Earlier 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…
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
#155Re: What’s Really Killing Digital Health Startups
#156Earlier 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?)
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
#157Earlier 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.
"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
#158Earlier 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.
Re: What’s Really Killing Digital Health Startups
#159Earlier 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…
I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.