8 ms·

Based on this article whats killing digital health startups is they dont understand they are fundamentally in the integration business. I worked for a company

by apalmer 11y ago

Based on this article whats killing digital health startups is they dont understand they are fundamentally in the integration business. I worked for a company in a total different sector that eventually ended up being acquired for a significant amount of money. More or less the company 'succeeded' because almost everything 'product' wise was window dress. the actual value of the company was the fact that we had done the legwork to integrate with dozens and dozens of difficult legacy systems and was able to expose them in a single unified API that our 'product' used. The purchasers didnt really value the 'product' or the companies 'brand' they valued the integration and the business relationships with the integration partners that were necessary to keep these integrations working... Seems like what the article is really saying is that in this particular market the money is in the integration not the 'product' over the integration.

shostack 11y ago
So like Zapier but for that sector?
- jnbiche 11y ago
  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). And yet the main people who are using them seem to be the "internet marketing" crowd (who is using them to great effect, by the way). Off topic, but I've been really perplexed by this. It's not lack of promotion, since Zapier seems to do a lot of that. Could it be that most non-programmers aren't using programming because they can't learn how to use a programming language, but because they just aren't interested in those technologies, even when they're presented to them as a super-easy web GUI.
  - gopher2 11y ago
    Random thoughts from working at a marketing/software company that people occasionally build Zapier integrations for. Instead of their being one point of failure Company X <--> Company Y integration, there are now two points of failure Company X <--> Zapier <--> Company Y. So, things may break. And if they do there are more points of failure in figuring out why. If we really want a working integration with some other software, we build it directly and support it directly.
  - exelius 11y ago
    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 combination of products you integrated with. And this isn't even touching the hundreds of other proprietary data formats, for everything from medical telemetry (pulse, o2 levels, etc) to imaging (x-rays, MRIs, etc) to billing. Many of these companies don't want you to be able to use their data (because, of course, they offer their own EMR platform or require a hefty licensing fee), so it will be encrypted. All this is on top of all the deployment problems that SaaS platforms solved in the 2000s -- most offices are still using ancient on-premesis EMR platforms built in the 90s for record keeping purposes. Younger doctors with newer practices are using SaaS systems, but very few young doctors can afford to go into practice for themselves right out of med school. So it's a problem that will eventually be solved, but the time horizon is probably closer to 5-10 years than the 3-5 years we're used to in technology. As far as Zapier goes, I don't know that it really saves a lot of money for companies. The hardest part of integration isn't coding the integration, it's building out the business requirements -- something you still have to do with Zapier. For anything simple enough to use Zapier for, a junior developer could write the code in an hour or two of his spare time.
    - snuxoll 11y ago
      > 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.
joe_the_user 11y ago
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 talk to your "talks to ten things thing". 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. The problem of integration, of conforming to byzantine standards and to the mess that overall existing health IT, is itself still just a detail in the overall problem of health and technology. The fundamental problem is the messiness and unpredictability of physical human bodies/human health. The reason that health records are a mess is that there is no easy to way to universally classify "what is going on" with a given person in a cut-and-dried fashion. For any field of a health record, there is significant gray areas once you get to a large scale (including "basic" things like "male" and "female"). Just as much, health procedures often don't benefit from automation because what one person does to care for another person is subtle and not easily codified.
- kuschku 11y ago
  > 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.
  - joe_the_user 11y ago
    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).
specialist 11y ago
we had done the legwork to integrate with dozens and dozens of difficult legacy systems and was able to expose them in a single unified API Bingo. That is precisely what our backend did for healthcare data. And the front end (portal) was really good for the time.

by apalmer 11y ago

shostack 11y ago

So like Zapier but for that sector?

jnbiche 11y ago
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). And yet the main people who are using them seem to be the "internet marketing" crowd (who is using them to great effect, by the way). Off topic, but I've been really perplexed by this. It's not lack of promotion, since Zapier seems to do a lot of that. Could it be that most non-programmers aren't using programming because they can't learn how to use a programming language, but because they just aren't interested in those technologies, even when they're presented to them as a super-easy web GUI.
- gopher2 11y ago
  Random thoughts from working at a marketing/software company that people occasionally build Zapier integrations for. Instead of their being one point of failure Company X <--> Company Y integration, there are now two points of failure Company X <--> Zapier <--> Company Y. So, things may break. And if they do there are more points of failure in figuring out why. If we really want a working integration with some other software, we build it directly and support it directly.
- exelius 11y ago
  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 combination of products you integrated with. And this isn't even touching the hundreds of other proprietary data formats, for everything from medical telemetry (pulse, o2 levels, etc) to imaging (x-rays, MRIs, etc) to billing. Many of these companies don't want you to be able to use their data (because, of course, they offer their own EMR platform or require a hefty licensing fee), so it will be encrypted. All this is on top of all the deployment problems that SaaS platforms solved in the 2000s -- most offices are still using ancient on-premesis EMR platforms built in the 90s for record keeping purposes. Younger doctors with newer practices are using SaaS systems, but very few young doctors can afford to go into practice for themselves right out of med school. So it's a problem that will eventually be solved, but the time horizon is probably closer to 5-10 years than the 3-5 years we're used to in technology. As far as Zapier goes, I don't know that it really saves a lot of money for companies. The hardest part of integration isn't coding the integration, it's building out the business requirements -- something you still have to do with Zapier. For anything simple enough to use Zapier for, a junior developer could write the code in an hour or two of his spare time.
  - snuxoll 11y ago
    > 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.

joe_the_user 11y ago

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 talk to your "talks to ten things thing". 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. The problem of integration, of conforming to byzantine standards and to the mess that overall existing health IT, is itself still just a detail in the overall problem of health and technology. The fundamental problem is the messiness and unpredictability of physical human bodies/human health. The reason that health records are a mess is that there is no easy to way to universally classify "what is going on" with a given person in a cut-and-dried fashion. For any field of a health record, there is significant gray areas once you get to a large scale (including "basic" things like "male" and "female"). Just as much, health procedures often don't benefit from automation because what one person does to care for another person is subtle and not easily codified.

kuschku 11y ago
> 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.
- joe_the_user 11y ago
  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).

specialist 11y ago

we had done the legwork to integrate with dozens and dozens of difficult legacy systems and was able to expose them in a single unified API Bingo. That is precisely what our backend did for healthcare data. And the front end (portal) was really good for the time.