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.
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.
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.
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.
>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.
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.
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.
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).
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.
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.
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.
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.
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:
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.)
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.
What you describe is absolutely the wrong way to start a business
It seems to me that what I am describing is exactly what (at least some) disruptive businesses -- like AirBnB -- do: Redefine the problem in order to find a white space because the thing they are doing did not exist until they did it, so there isn't really any competition.
Right; but that doesn't work in health care because of the regulatory environment (which in this case, is absolutely necessary). It's not like the hotel business where if you have a bad experience, Airbnb can just solve the problem with money. There is a long history of misleading health claims on products that has existed for almost all of human history; so any product you claim improves the health of the user has to be backed up by data.
"Redefining the problem" is marketing speak for finding a way to trick consumers into using your business model. It's fine in the case of something like Uber where you're short-circuiting a bunch of disparate and protectionist taxi laws, but federal regulatory agencies are rarely fooled by such tactics, and aren't shy about labeling you and your company as scam artists while sending a federal prosecutor at you if you try.
Basically, if you're gonna fuck with the government, make sure you fuck with municipal and state governments. The feds don't take crap, and will steamroll you if you threaten to circumvent their jurisdiction or deceive them in any way. This happens to hundreds of companies a year (just look at Theranos and 23andme for some high-profile examples), so they're definitely not bluffing.
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.
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."
I disagree. I can relate to application setup and deployment feeling like its a fragile, error prone process but library usage in general is a good thing. Now if you're picking up obscure, poorly maintained libraries from GitHub I can see that going south quickly but as long as you're smart about not only which dependencies to choose from whom but also knowing when you really need them then you end up with a robust, easy to maintain system in the end.
The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself.
This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far.
Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment.
I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.
A perfectly valid case for using a library is when it implements a huge standard that you don't have the time, knowledge or expertise to implement yourself. Think of zlib, libpng or libcurl. These are de facto "reference implementations" of the respective standards, so you'd better rely on them in order to be future proof.
> We have so many hobbyist libraries precisely because our languages and tools are so flexible.
I beg to differ. The (initially) small hobbyist libraries are often working around the deficiencies of the language/runtime/core libraries. This has been the case for JavaScript since jQuery. If a third-party library doesn't implement a format or a protocol, or an intricate algorithm, but rather tries to augment the language, that is a huge red flag.
I don't see the benefit. It seems no easier on the eyes than JSON and it's more complex with more syntax rules to learn. I wouldn't recommend this for either humans or machines. HJSON would be my choice for a human readable data notation format.
I've been using this as the basis for my typographic styles for maybe a year now. My only problem with it has been the spacing between paragraphs and headings. I find myself using the .hug class a lot.
Haven't tried it. I don't think I would as its a SASS project and I prefer LESS. My initial thought just upon glancing the readme was that it seems a bit bloated. Starts out with some great options then it looks like they've defined variables for every system don't imaginable. I like typebase because it's a very complete base that you can customize and build on without having to tear apart. Typographic seems more framework-y which is a turnoff for me.
But that's just a first impression and my needs and preferences aren't everyone else's.
Most people don't disable JavaScript but beyond that edge case (I consider JS disabled an edge case) I agree that this architecture isn't necessary and overused. A single page app is great on a MacBook Pro with 2 tabs open but run that on most "normal" people's machines and it gets laggy quick.
People always mention disabled JS and SEO as pitfalls but I think performance and practicality are the obvious reasons not to do this that get overlooked. SPA architecture is something I use alongside server rendered pages. When you have one page or a series of pages in a particular user flow that would benefit from no page reloads and are heavy on interactivity then it makes sense but otherwise I can't see the value. I think developers will realize this and take a more balanced approached with a practical mix of pages rendered server side and pages that use XHR and JavaScript to enhance the experience.
Sure, it's probably a reasonable guess. I just wonder how many of the people making this claim are simply assuming it to be true or relying on some sort of analytics service. About the only way you could tell is by counting the server logs, which I'm often told are hard/annoying/unavailable by analytics advocates.
Great suggestions for non-technical people in there but if a real concern is ownership and control of content then the only real option is buying or renting server space and putting up a website with maybe Ghost (the most overrated blogging platform ever) or the open source Wordpress or just plain HTML. All the other options listed still could potentially shut you down for some weird TOS violation (like if you're a big KKK supporter or something). Is it likely to happen? No. But isn't this where we post our overanyzed takes on everything?
Really though, the only way to own your own web content is to run your own server, and physically control access to it. Even buying or renting server space puts your content in the control of a third party.
The process is the same for those with sleep apnea who aren't overweight. Like me. I weigh 155 and an 6' tall. Born with a small airway and just got lucky it seems. So if your point is that if people just lost some weight they wouldn't have anything to complain about then I'm not sure weight is even relevant here. It's a very lengthy and time consuming process regardless of the cause.
Not defending DanBC, but if he was talking about "The Public" I think that would disclude someone with a small airway because it falls outside the norm. However, if he plans on making the suggestion that "the public" is all fat so they can't sleep, he should back it up with facts.
What facts? This is not a peer reviewed journal, you know.
Here are two distinct facts:
1. I do have eyes and I can see a trend.
* I do not recall seeing less fat people as a child, but I do recall seeing more thin people now.
* I also notice that the fat people I see now seems on average younger than the fat people I recall from my childhood.
* I also notice that the fattest ones - those grossly obese instead of merely overweight - are both larger and more common now than what I recall from childhood (and I was practically raised by an aunt that used to be at the very top of the scale back then, but somehow found herself surpassed in the last 20 years or so).
2. We are told by the media that there are statistics that show an epidemic of overweight. The study pointed out claims that physicians consider overweight as one cause (not the cause) of sleep apnea. We are now told that there is also an epidemic of sleep apnea.
* If A causes B, and we observe an increase of both A and B. It is only logic that the "increase of A" is at least partially responsible for the "increase of B".
* It would make an interesting scientific study to figure out the degrees of correlation between "increase of A" and "increase of B". It would be even better if such study could conclude if such correlation is strong enough to justify calling "increase of A" a driving factor in the "increase of B" or not.
* On the other hand, it is a logical fallacy to claim that no conclusion can be reached regarding the causation/correlation between increases of A and B without "backing it up with facts". I will even claim that it is AntiScientific. If you start with that kind of attitude, you will never be able to form falsifiable hypothesis and therefore will be going through the motions of the scientific method without getting down to the substance.
The observable results are somewhat consistent with a contagious disease. Adenovirus 36 has been shown to cause long-term obesity in lab animals. Gut microbiome comparative studies have shown a marked difference between the intestinal flora of fat people and skinny people.
Additional environmental factors are in play. Car culture in the US reduces the necessity for daily exercise in comparison to walkable city infrastructure elsewhere in the world. The US uses a lot of chemically altered corn syrup in prepared foods in lieu of other sugars. Agricultural practices differ between the US and other nations, particularly with respect to allowable herbicides and pesticides. Real inflation-adjusted disposable income has been declining in the US since about 1970, and poorer people have less healthy diets. Parenting culture has changed since 1970, such that children left to play outside (aka exercise) without direct adult supervision may actually get a parent arrested. People have increased their consumption of sedentary entertainments, and reduced the time that they typically sleep.
The only way to really figure out which factors contribute most to increases in obesity is by objective analysis of unbiased data. That will lead to actual, testable hypotheses, which will in turn lead to solutions that actually work to reduce the public health risks represented by excess adiposity.
Telling every fat person "hey fatty, go lose some fat" may seem like a simple and easy solution on its face, but it really is a lot more complex and difficult than that.
No one is denying that fat people would be healtier if they were skinnier, or that they do want to be less fat. Very few fat people actually want to be fat, and most do take active measures to try to become less fat. But no one apparently knows with certainty why those measures--often the exact same measures employed by skinny people to avoid becoming fat--do not always work.
When people dismiss those discrepancies as "not trying hard enough" rather than "potential research opportunity", that does not advance the human knowledge in this domain that would allow us to better address obesity on a worldwide scale rather than piecemeal.
Agreed on most accounts. I am obese myself (closer to 'Fat Tony' than to 'Comic Book Guy'), so I know first hand that telling people to "get thin" is less than useless.
What I get pissed off at, is the insistence on some people around here that if you cannot quote scientific articles from memory, then you must be lying and your opinion should be disregarded.
There's lots we don't know about human biology. It does not mean we should go find somewhere to roll and die of whatever ill is affecting us. Somehow we need to make decisions and take actions under incomplete and inaccurate information.
Maybe my grandchildren will benefit from the enhanced understanding you talk about, and I will be grateful for it. But this does not change the fact that I need to address my own problem today.
As a lifetime fat person the best decision I made was to go on a paleo diet. Essentially: No grains, no legumes, no processed food, no dairy. Limit intake to : grass fed meat (when possible), veggies, some select nuts, limited fruit.
That in combination with stopping drinking, eliminating pop and just adding some mild walking has made a huge impact. I don't worry about portion size, counting calories etc.
If you are like me, you might want to check paleo out.
Hard to know if your success is driven by paleo, or by cutting out booze and soda and adding in walking, or if you're just taking less calories than before.
Whatever works for you is great, but I just hear so many people raving about diet X, when at the same time they started it, they also cut out candy/soda/booze and starting hitting the gym...
As I understand it, the only beverage allowed on paleo is water, and the only sweets allowed are whole fruits and limited quantities of honey.
It is a matter for some debate among paleo advocates as to whether exercising in a gym is an adequate simulation of hunter-gatherer activity. And that's about when I start tuning out. Then I get to the part about donating blood to account for recoverable injuries, and I switch off. It's a diet/lifestyle, not a cosplay.
The success is driven by having a plan and maintaining the individual motivation to carry it out.
Is there no alternative that saves users' data? Of course there is. But you probably don't want to put anything sensitive into any of them. There's no shortage of bare bones Evernote type services out there. I've been running one for three years without a single user losing data. They tend to forget their usernames and passwords a lot but never the data. (Link in profile, won't plug it here).
I still use Evernote for things I needed to store a long time ago and never ported anywhere else. It boggles that mind that the very core of such a service, writing and reading data from some store, takes a backseat to all the other buttons and gadgets they wrap around it.
> Developers shouldn't have to sacrifice their rights to speak and innovate freely just to bring their applications to millions of Apple users.
Ummm... Is this really why they develop for iOS or are they just having fun mostly, enjoying their craft and (sometimes) making a small profit on the side. The App Store is but one way to get apps. Sounds like developers with the beliefs the EFF attributes to them would be better suited to developing for Jailbroken phones.
I doubt and don't think they should feel threatened. If I were them I wouldnt be guarding my application because it's a very simple and easy to replicate concept. The real value is in the service. You pay for StatusPage because you expect they'll have better uptime than you and they allow you to focus on building your app and communicating with your customers. They take the work of building and maintaining a status page away. Pingdom is very similar. Something you could definitely build yourself but why bother when you have better things to do with your time.
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.