So like Zapier but for that sector?
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.
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.
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.
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.
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: pricing; I'd argue they're vastly underpriced, when you consider the development costs of writing the integrations yourself. I could pay them $20/month indefinitely and never spend more than the development effort would cost to write and maintain 20 (heck, even 10) integrations.