[bpatrianakos]

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 "legacy" technology.

So you have companies like one I was recently a part of integrating a Node web app and API with SOAP and SAML end points and suddenly it's everyone else's fault that things are hard when really you probably should have thought through those tech stack choices before you started.

I'm not saying the article is wrong. I agree with it wholeheartedly but there's a lot to be said for not researching the market you're about to jump into thoroughly enough before you begin.

[tkiley]

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 now, though. Right now, I'm interfacing with a market leading EMR vendor's web services API. They advertise it as "REST" with a straight face, but it's the lake wobegon of REST APIs, where all of the responses are "HTTP/1.1 201 Created" (even the GETs) and all of the response times are horrible.

Personally, I'm rooting for startups like Redox Engine (https://www.redoxengine.com/) to bring some sanity to this world, because I don't think the EMR vendors are going to do it on their own.

[bpatrianakos]

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 compliance to deal with. It's tough but not as crazy as $50k fines for every instance of leaked data with HIPAA.

[dreamfactory2]

Not just healthcare, but pretty much any enterprise sector from travel to gov.

[nommm-nommm]

>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 could have spent hundred of millions of dollar and several years to rewrite the system I was working on to use the latest technology stack. But for what? It works and does its job well.

[webjprgm]

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.

[ploxiln]

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 technology from the early 2000s that grew out of unix technology of the 80s. But the really really old stuff can actually have meaningful limitations.

With regards to the medical industry, most of the software and systems are truly bad (in addition to being made with very very old tech). The reason IMHO is that due to all the regulation and all the money, all the power is on the political side rather than the technical side of the market, and it's a market where users don't choose what they use, administrators choose for them (and then don't have to use it).

(My mother is an MD)

[kenko]

What's really killing digital health startups: failure to do due diligence.

[exelius]

I'd say that the potential digital health startups that do their due diligence end up picking another industry. So it's only the guys who failed to do it who end up starting companies.

The VC startup model relies on finding white space and occupying it. Heavily regulated industries (like health care) tend not to have a lot of white space because the boundaries are rigidly defined by law. It's not a good fit for health care.

[mbesto]

I'm sitting in the office of one right now. Their codebase is sitting in Microsoft Visual SourceSafe: https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe

Yes, that's right folks - it's last release was exactly 10 years ago. You wouldn't believe some of the systems I've seen.

[disposition2]

Yes, but migrating to another VCS would be like working on a moving car and you have to pay the mechanic to plan -> dev -> implement...and then convince everyone who's worked with the VSS thought pattern (which is pretty different from SVN, GIT, just about everything) to use this new 'better' thought pattern or create something that will mimic the workflow they're are used to and connects to the new VCS...all the while you are still try to generate revenue rather than resolve a legacy 'issue' that really just looks bad and is still in place because: it works, everyone is used to it, you don't have the time / resources to make a change until it doesn't work.

Not that I'm arguing for VSS, it's awful, but there are business reasons I can see trumping the desires of wanting an upgrade.

Edit: spelling

[specialist]

Yes. And on the other side, you have dinosaurs stuck on using MUMPS, Cache (InterSystems), eGate/JCAPS, BizTalk, or some other monstrosity.