Live data from Hacker News

What’s Really Killing Digital Health Startups

techcrunch.com

111–120 of 159 posts

Re: What’s Really Killing Digital Health Startups

#111
post #73

Earlier quoted context omitted.

A lot of the HL7 stuff could be made a lot simpler if the hospitals embraced a simpler subset--instead, everybody picks and chooses features and fields, as do vendors, and then punt it off to integration work. It's dumb.

IHE has done good work defining conformance profiles on top of the basic HL7 standards that help to improve interoperability. Adoption is growing but still not universal. http://www.ihe.net/

Mixed bag with IHE.

For example, IHE WCM (the waveform stuff for realtime signals) is not very good: it is overly textual for the data it represents, doesn't solve all the problems it can run into, has some weirdness with timing and how to map things into HL7, and so forth.

Re: What’s Really Killing Digital Health Startups

#112
post #105

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…

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

Perhaps my effort was informed by my prior experiences with ERP/CRM systems and the semantic web.

I'm firmly in the folksonomy (vs taxonomy) camp.

We just showed our customers data back to them. In most cases, it was the first time they'd ever seen it. Hence the churn on "what is a visit", resolving scripts, etc.

I don't know anything about medical data analytics, but if we captured the data, then its there to be mined. It was just HL7 (or whatever), as is.

Re: What’s Really Killing Digital Health Startups

#113
post #28

Earlier quoted context omitted.

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...

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

Happy to hear specific issues! https://chats.fhir.me/feeds/skype/implementers.html - best place to participate if you want to help. Even at v1.0, many people are open to changes that reflect the needs of strong cases.

There are compromises in any API, and FHIR does a decent job of making common needs things simple, the alterative would be some RIM or graph based model that you'd have to get graduate degree in before you could say 'just GET me a Potassium result dammit'.

Please reach out if you see ways the spec could improve.

Re: What’s Really Killing Digital Health Startups

#114
post #28

Earlier quoted context omitted.

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...

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

Instead of complaining, feel free to propose a better alternative. The HL7 standards development process is very open.

However usually the complaints about health IT complexity come from people with a lack of domain knowledge. The industry is irreducibly complex. Attempts to drastically simplify the IT systems and standards are doomed to failure since they lose the ability to cope with many common real world situations.

Re: What’s Really Killing Digital Health Startups

#115
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.

Practices on EPIC are still fundamentally non-networked, so even with an "API", you can't scale your product from one practice to all of them without some amount of non-trivial integration. I work at athena and we're dogfooding our API for an increasing number of products/components as it's an easy way to both decouple internal services and improve the API for our partners. From my lowly, uninformed position as a dev…

That's true on the one hand. On the other hand, Athena wants a significant chunk of your profits to connect to their API. At least HL7v2 interface were one-time, scale everywhere from a cost model.

Re: What’s Really Killing Digital Health Startups

#116

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…

I'm totally on board with FHIR. I just don't think we're there yet. I've talked with 3 of the Argonaut sites and real-life, production ready FHIR capabilities are lacking. There aren't many useful provider-facing applications that you can built with just GET requests. Most applications require real-time pushing and pulling of data. As sad as it is, until FHIR as implemented (not theoretically) that way, we'll still be plugging HL7v2 together. I, as an HL7v2 slinger myself, hope that goes away soon.

Re: What’s Really Killing Digital Health Startups

#117
post #44

Earlier quoted context omitted.

Heh.. you hit the nail on the head here. I've been in health integration for the past five years. By restful nosql whizbang node standards, healthcare is full of really weird old shit, and if you want to interoperate, you have to be ready to party like it's 1999, because a lot of these systems were legacy even then. It is rather frustrating to see some of the API designs that are finally getting shipped in healthcare…

They won't do it on their own because there's really no incentive to make this information easily accessible. Healthcare is like Microsoft and Oracle in the 90's. Everyone wants you locked in to their platforms and services. Add to that the fact that you're constantly dealing with incredibly sensitive information on the level of financial data (arguably even more sensitive) and it gets worse. In finance you have PCI…

It may not be deliberate attempt to lock customers in, but just the first part of what you said: there is no incentive to make this any easier. It basically works, so hospitals/clinics that need to make a few simple customizations can do so with REST API calls but it isn't easy enough for third-parties to quickly and easily build large applications. There's so much going on in healthcare that it is hard for big vendors to justify cleaning up their web services over doing other things. Especially when the "interoperability" buzz fits in better with supporting FHIR, CommonWell, Healtheway, HL7, etc.

Re: What’s Really Killing Digital Health Startups

#118

Earlier quoted context omitted.

Maybe something like this? https://www.patientslikeme.com/

I have used them and they are definitely on the right path but they haven't yet got past the point of just showing a lot of graphs and comparative statistics, etc. As always, it comes down to translating data to useable knowledge, which we as an industry are obviously trying to figure out across pretty much all verticals

My understanding is that PLM very much translates to useable knowledge - just for the pharma and PHM folks who mine the backend (which is how they make money). Notably, this is all quite above-board: it's not a "secretly mine people's private medical details" situation, it's "overtly mine people's private medical details in order to help find treatments for their rare disease"...

Re: What’s Really Killing Digital Health Startups

#119

Having done exactly this type of integration with legacy systems I think a point that gets glossed over is that it's the startups themselves who are full of engineers who think that the whole world has moved on to using NoSQL Node.js RESTful JSON APIs in the cloud (that buzzword soup was intentional) when the reality is that the majority of established businesses are using unsexy and what they would consider to be "l…

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

I would argue that it isn't about how old the technology is but how good the developer tools and support are. Newer technologies (not brand new, ones that have a few years of maturity) often have better support in common developer platforms, more tutorials and answers on StackOverflow, etc. They are also easier to find employees to hire who know how to use them (or who WANT to use them).

If an older technology is so great then my preference would be to build modern tools for that old technology and then it would be like new. If you can evangelize this old-made-new platform a bit then you could find more people willing to use and learn it, which would fix the online presence and employee hiring problems too.

Note that MUMPS is one of those old technologies used in healthcare. It is basically a NoSQL database from before NoSQL was popular. Intersystems' website suggests that they've made a bunch of additions to it, but Intersystems charges a lot of money. GT.M is the open source one but as far as I know it sticks more to the ANSI M standard. That standard language is pretty old so it can get confusing to read/write it. I'm not sure if GT.M provides dev tools either. Intersystems does, but AFAIK they are not as good as tools like Visual Studio, XCode, or other newer platforms.

Re: What’s Really Killing Digital Health Startups

#120
Lot of interesting comments about difficulty of IT integration. However, there is a much more fundamental problem with Healthcare IT. That has to with a lack of a functioning market. Thanks to HITECH subsidies, a bunch of money has flowed into EHR and related systems. It gives the impression of a customer paying for these systems, but once that fades a lot of these HIT companies are going to find that they are not in a market. People who think another 3-4 years will fix the issue are in denial.

Look, there are lot of industries that work in IT integration. If you take manufacturing, retail, finance, telecom etc. there hundreds of systems from the '60s and integration (and all the pain) is probably 80% of the work. 100's of billions of dollars are spent on IT integration. There is no magic 'one true IT system' but lot of hard work and slog. Nothing very special about healthcare. But, there is functioning market in these industries. Consumers of these systems have a very clear idea of how IT is going to help them run their business, it is sustaining system. They pay money, IT people build systems.

Not so in healthcare IT. Healthcare consists of bunch of fragmented and tiny providers interspersed with some large players. As such very few are managed as a business (as a retailer would for ex.), instead it is managed almost like a bazaar style haggling model. Try to squeeze out as much as possible from the insurance company, reduce the cycle time of payment, negotiate some extra tests, enter the correct ICD code etc. No standard business metrics that everyone can agree upon. If the value pitch is "we will help you get paid", then you have failed. My view is that this state of affairs will continue until there is some large scale integration and verticalization. Until we have these fragmented healthcare system in place I don't see a good future of healthcare IT.

I mean sure there will always be some people doing this, but people have working on healthcare IT since the '60s. Having super clean one true data model is fanciful at best but it actually will not solve anything. The $40 Billion of HITECH subsidies have managed to create a half assed EHR ecosystem with Epic taking a chunk of the market share. It will be interesting to see how the industry will manage to get the customers to pony up the next $40 Billion and the next and the next. In a fragmented system, the only IT system that can work is some sort of Slack type system (or communication tool) for patient/providers or between providers.

Post reply on HN