3 ms·
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 m
by 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.
- sk5t 11y agoMust 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.
- snuxoll 11y agoWe 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.