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

[webjprgm]

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.

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

[cordite]

The way I see MUMPS or M (because clinicians don't like hearing that word) is a string typed almost-assembly level server scripting language.

GTM does stick to the ANSI M standard with a few extensions for basic escape holes like calling a UNIX process or writing to a file. It doesn't have the same level of optimization, reliability, recoverability, etc. that intersystems sells.

[ethbro]

Non-snarky point, but every new technology is destined to become the next old technology.

And the future will reveal that some choices of the technology in question showed incredible foresight and some were very poorly conceived.

If we're lucky, the good choices match well with certain problem domains and the poor choices are an acceptable price to pay.

[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)

[nommm-nommm]

Does it though?

Yes.

Does it do its job well?

Yes.

Does it have scheduled maintenance every evening for the mainframe batch job?

No, its used 24/7 and does not run on a mainframe.

Does it not handle non-ascii in names?

Who the hell cares? It doesn't have to.

Does it not have the perspective of knowing how much better it could be done, like webmail before gmail?

I don't even know what you mean. I think webmail before Gmail was great. Gmail is always changing its UI and confusing users. Gmail didn't bring anything to webmail except a ton of free storage.

The software is fine it doesn't have many big flaws and it operates in a space where people depend on it working right so they don't die. We still release new versions once in a while but its not too much work.

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

[Mz]

I guess that depends on how you define it. If by "digital health" companies you mean medical industry companies, you may have a point. But part of what is wrong with American health care is that health care is a polite euphemism for medical care. Grocery stores do not get defined as being in "health care," though eating healthy is clearly a cornerstone of good health.

But I think it is possible to want to do something health related, conclude that the medical industry is a nightmare, and find another approach.

[exelius]

They are largely one and the same; because as soon as you start claiming your product or service can improve a user's health, you're subject to the regulatory scope of the FDA.

I mean, you can claim that things like MyFitnessPal are health apps, but it's still a fine line you have to walk where you can't give any advice, all you can do is observe and report. Try to go any further than that and you're providing diagnostic services, which makes you subject to all sorts of laws. The FDA and DHHS are very aggressive in protecting their regulatory scope.

[Mz]

Inspections and licensing of restaurants and grocery stores are typically handled by local and county health departments. (Not the FDA)

http://www.fda.gov/AboutFDA/Transparency/Basics/ucm194244.ht...

Though, yeah, given that the FDA is the FOOD and Drug Administration, I am sure they impact grocery stores: https://foodpoisoningbulletin.com/2014/fda-proposes-rule-for...

That does not mean HIPAA impacts grocery stores, restaurants, etc.

Though if you search for "HIPAA and grocery stores" it does pull up Von's page on HIPAA related to the fact that stores can have a pharmacy window in them:

http://rss.vons.com/ShopStores/Pharmacy-HIPAA.page

So, yes, while anyone selling food will be regulated by existing food safety rules/organizations -- including the FDA -- that does not prevent someone from saying (to themselves) "I would like to make the world healthier. I don't think becoming a doctor is The Answer. I think The Answer is running an organic restaurant."

And please don't argue with me that how you conceptualize it does not matter. You cannot tell me that Chipotle, with its "Food with integrity" concept and supporting policies, is the same as any other fast food taco joint.

(I ate there consistently for a long time to get well after doctors wrote me off for dead. That did not cause Chipotle to suddenly have to comply with HIPAA.)

[dragonwriter]

> You cannot tell me that Chipotle, with its "Food with integrity" concept and supporting policies, is the same as any other fast food taco joint.

It is the same as any other fast food joint. Heck, food quality improvements were an early selling point for McDonald's.

[exelius]

Well that's because a grocery store isn't a health care company: it's a retailer. You can also buy very unhealthy things at the grocery store.

What you describe is absolutely the wrong way to start a business: you should look at the type of business you want to open (in this case, a restaurant) and look for white spaces. Opening an organic restaurant is only a sensible idea if the market would respond to an organic restaurant and the category isn't already over-served. If that overlaps with your passion, then great!

Never mind there is no scientific evidence saying organic food is better for you - this is where "health" delves into pseudoscience, and the entire reason the FDA exists.

[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

[ethbro]

True story: it took two months to explain to an IT department that XML serialization files should be flagged as binary to prevent SVN performing line auto-merges on them.

Then another month to implement the change. And this was only for one sub-group.

I think some of the problem is "People who still feel VCS is a valid technology choice probably shouldn't be trusted to make technical decisions."

[specialist]

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