The Black Liszt

Summary: Software Innovation

This is a summary with links to my posts on software innovation. It includes posts on barriers to innovation and how to grow a winner.

Software is taking over the world. The pace and scope of the transformation of human activity has no precedent. People often assume that this is the result of fierce innovation in software. While brand-new software is built every day, the actual innovation is the result of computer innovation – which does indeed proceed at an unprecedented pace.

https://www.blackliszt.com/2013/12/fundamental-concepts-of-computing-speed-of-evolution.html

https://www.blackliszt.com/2014/03/innovation-with-computers-and-slow-things-1.html

The fact is that innovation in software is incredibly simple. It rarely involves fancy stuff like AI, but mostly figuring out the best way to accomplish things and getting the computer to do as much of the work as possible.

https://www.blackliszt.com/2014/07/innovation-made-simple.html

Here are some of the most important patterns of the small groups that innovate their way to success in software.

https://www.blackliszt.com/2017/01/the-science-of-innovation-success.html

The general impression is that software is all about innovation and rapid evolution. Programmers are on the front lines, constantly making new things. Sadly, this general impression, which is shared by most programmers, doesn't hold up under examination.

https://www.blackliszt.com/2023/07/does-software-evolve-rapidly.html

People love to brag about the software innovations they’ve invented. The fact is, most of the fundamental innovations in software are proven and in place; they’re ignored by practically everyone, including the experts.

https://www.blackliszt.com/2015/06/fundamental-innovations-in-software.html

This holds true even when you look at a narrow field of application such as financial technology.

https://www.blackliszt.com/2016/03/fintech-innovation-the-drivers.html

An amazing fraction of what appears to be innovations are little but taking advances that are proven in a narrow domain and applying them to a new one. Here is the story of an algorithm that was standard practice in oil refinery operation over 50 years ago that, decade by decade, is still crawling its way into new domains.

https://www.blackliszt.com/2019/08/the-slow-spread-of-linear-programming-illustrates-how-in-old-vation-in-software-evolution-works.html

Here is an example of a truly beneficial innovation proven over 50 years ago that is still not used in medical imaging.

https://www.blackliszt.com/2019/07/barriers-to-software-innovation-radiology-1.html

https://www.blackliszt.com/2019/08/barriers-to-software-innovation-radiology-2.html

It’s not just fancy algorithms that are proven and waiting for application in new domains. It’s simple things like production human data entry, where widely proven “heads down” methods are at least 5 times more efficient than what is normally done.

https://www.blackliszt.com/2019/09/simple-data-entry-technology-illustrates-how-in-old-vation-in-software-evolution-works.html

Here are details of the advantages of “heads down” data entry and how it was ignored at a huge project at Sallie Mae.

https://www.blackliszt.com/2019/10/software-professionals-would-rather-be-fashionable-than-achieve-10x-productivity-gains.html

One of the common ways to ignore a major innovation such as “heads down” data entry is to concentrate on a method that is highly fashionable, even though it doesn’t do much good.

https://www.blackliszt.com/2019/09/laser-disks-and-workflow-illustrate-the-insane-fashion-driven-nature-of-software-evolution.html

Given this, it’s all the more amazing that companies have Chief Innovation Officers whose job is usually to “foster innovation.” Heh.

https://www.blackliszt.com/2016/04/the-innovation-bubble.html

Barriers and Resistance to Innovation

Software innovation faces huge barriers from people and established practice, like innovation in medicine, where a cure for scurvy was proven in practice for decades before the authorities grudgingly accepted it.

https://www.blackliszt.com/2014/02/lessons-for-software-from-the-history-of-scurvy.html

Innovation has been strongly resisted for a long time.

https://www.blackliszt.com/2020/01/luddites.html

https://www.blackliszt.com/2016/05/innovation-some-history.html

Have you heard the story of Samuel Pierpont Langley, the renowned expert on manned flight? He’s a case study in how experts prevent innovation.

https://www.blackliszt.com/2016/07/innovation-and-experts.html

Major advisory institutions reflect common thinking and prevent their customers from "making mistakes" with innovative companies.

https://www.blackliszt.com/2017/05/the-value-of-computer-industry-advisory-groups.html

Here is the story of how the British military resisted a huge innovation for combating submarines in World War 2.

https://www.blackliszt.com/2021/10/deep-seated-resistance-to-software-innovation.html

Even the experts in entrepreneurship resist innovation. Amazing. Experts!

https://www.blackliszt.com/2020/05/experts-vs-innovation-new-book.html

Perhaps you think that the big tech companies are great at innovation? When you look at how they actually innovate, they don’t look so great.

https://www.blackliszt.com/2016/05/organizing-for-successful-innovation-recent-history.html

Often important innovations don’t require software at all, which doesn’t seem to stop people spending loads on money on exotic software.

https://www.blackliszt.com/2016/09/healthcare-innovation-from-washing-hands-to-ai.html

https://www.blackliszt.com/2016/05/healthcare-innovation-can-big-data-and-cognitive-computing-deliver-it.html

Healthcare is a rich source of examples of how to screw up and fail to take advantage of obvious, long-overdue “innovations” like electronic medical records.

https://www.blackliszt.com/2016/06/healthcare-innovation-emrs-and-paper.html

https://www.blackliszt.com/2016/05/healthcare-innovation-emr-procurement-is-broken.html

https://www.blackliszt.com/2016/06/healthcare-innovation-emrs-and-data-quality.html

While experts and big companies put up active resistance to innovation, regulations are an important source of passive resistance.

https://www.blackliszt.com/2016/09/innovation-the-barriers.html

The huge cost of medical imaging systems is a clear example of how regulations prevent innovation and keep costs high.

https://www.blackliszt.com/2023/01/how-to-reduce-the-cost-of-medical-imaging-and-pacs.html

When you look into sample sets of regulations, you see how onerous they are and how they hamstring innovation.

https://www.blackliszt.com/2016/12/regulations-that-enable-innovation.html

There’s a clear path to eliminating regulatory resistance while making the enforcement power of the regulations even stronger, by shifting from massive how-type regulations to simple but effective what-type ones.

https://www.blackliszt.com/2011/12/regulations-goals-or-directions.html

https://www.blackliszt.com/2012/03/lets-criminalize-our-regulations.html

When you look at how innovation works in practice, it's hard to avoid thinking that there's a conspiracy to prevent innovation. It's mostly not a conscious effort on the part of the conspirators, but it has the same net effect.

https://www.blackliszt.com/2024/06/the-conspiracy-to-prevent-innovation.html

Growing the Innovation to Success

Once you’ve got your software company up and running, there are strategic moves that will keep you on the track to success.

https://www.blackliszt.com/2010/05/from-start-up-to-real-success.html

https://www.blackliszt.com/2010/12/from-startup-to-success-costs.html

Would you like to follow Facebook’s growth path? Their success wasn’t about great software development. It was due to a classic product/company growth strategy.

https://www.blackliszt.com/2014/12/fb.html

Your strategy may be good, but unless you build applications that can be changed quickly, you’ll lose the race.

https://www.blackliszt.com/2020/02/how-to-build-applications-that-can-be-changed-quickly.html

When you’re moving quickly, classically-trained programmers may start whining about the growing amount of “technical debt” and how important it is to pay it down. Here’s how to do it.

https://www.blackliszt.com/2020/03/how-to-pay-down-technical-debt.html

If you follow classic software development methods instead of fast ones, the chances are you could be hit with a big surprise at the end of the project.

https://www.blackliszt.com/2014/06/building-software-the-bad-old-way-and-the-good-new-way.html

There is a way to avoid disasters of this kind. It's practicing wartime software development, optimizing your methods for speed instead of meeting expectations.

https://www.blackliszt.com/2023/07/summary-wartime-software-to-win-the-war.html

When you’ve built a successful narrow-focus software company, how can you grow it further?

https://www.blackliszt.com/2022/07/the-dimension-of-software-automation-breadth-examples.html

The Book

Here are highlights of winning growth strategies and the book with more stories and details.

https://www.blackliszt.com/2016/04/software-business-and-product-strategy-book.html

https://www.blackliszt.com/2016/05/innovation-from-startup-to-success.html

Here are highlights of the companies used as examples in the book.

https://www.blackliszt.com/2016/07/innovation-stories.html

 

the Conspiracy to Prevent Innovation

There is a conspiracy to prevent innovation. It’s widespread, strong and effective, more in some domains than others. Like all  conspiracies, it goes to great lengths to conceal its actions and goals. The members of the conspiracy are desperate not to be revealed, because they would certainly be subjected at least to ridicule, if not total ostracizing. More important to the active members of the conspiracy, they would lose power, if not their jobs.

The anti-innovation conspiracy is at war with the transformative power of radical improvements of computer and networking technology. Computer evolution, which continues to follow Moore’s Law of exponential growth, without precedent in human experience, largely powers innovation, directly or indirectly. The exploding growth of computer power and network speeds with similarly amazing reductions in size and cost are an overwhelming force, practically begging people and organizations to tap its power and make things better for everyone.  See this:

https://www.blackliszt.com/2013/12/fundamental-concepts-of-computing-speed-of-evolution.html

As anyone can see with the transformation of rotary, wired phones into wireless, mobile computer phones, the forces of innovation are winning.

Victories of the Conspiracy

The entrenched anti-innovation forces refuse to concede defeat and give up. Decades into the computer revolution, the conspiracy lives on, showing few signs of weakening. It has established entrenched positions in a surprising array of places. Even when it can’t prevent innovation, the conspiracy manages to slow the pace of innovation to a crawl in places where conspirators maintain positions of power. They force innovators to slog through sodden, muddy paths, when in other industries, innovators are whizzing along on mag-lev trains.  There are also wide-spread pockets of resistance, in which the conspirators manage to hold off the application of proven innovations to their industry, often by decades.

Skeptical? An amazing fraction of what appears to be innovations are little but taking advances that are proven in a narrow domain and applying them to a new one. Here is the story of an algorithm that was standard practice in oil refinery operation over 50 years ago that, decade by decade, is still crawling its way into new domains.

https://www.blackliszt.com/2019/08/the-slow-spread-of-linear-programming-illustrates-how-in-old-vation-in-software-evolution-works.html

Here is an example of a truly beneficial innovation proven over 50 years ago that is still not used in medical imaging.

https://www.blackliszt.com/2019/07/barriers-to-software-innovation-radiology-1.html

https://www.blackliszt.com/2019/08/barriers-to-software-innovation-radiology-2.html

There are many more examples of the effectiveness of the anti-innovation conspiracy.

It's Secret!

Among the greatest strengths of the anti-innovation conspiracy is that it has not been “outed.” No one talks about an “anti-innovation conspiracy,” or even about “the forces that slow or prevent innovation.” The fact that innovation takes place widely, touching all of our personal lives, leaves everyone in awe of what innovation has wrought. And rightly so! What is not discussed are the deep forces that prevent and/or slow innovation. Without the resistance, the innovation that would be unleashed would make today’s by-itself-amazing innovation look sluggish by comparison.

The anti-innovation conspiracy has two major wings.

The first wing is particularly pernicious, since it establishes positions inside the people and groups who innovate and implement innovation. In this wing, the conspiracy concedes that innovation will take place, but assures that it will be as expensive, slow and ineffective as possible. The first wing is essentially an effort to cripple and co-opt the “offense,” the efforts of the innovators.

The second wing operates silently and secretly, often waving flags supporting innovation and supporting innovation efforts. It operates inside the institutions that will be affected by innovation, and inside the organizations such as regulatory bodies that control the institutions that are targeted by innovation. The second wing is essentially an effort to bolster the “defense,” the ability of institutions that could be impacted by innovation to resist the efforts of innovators.

One of the great strengths of the anti-innovation conspiracy is that the vast majority of people benefit to some extent by the innovation that does take place, and naturally compare  what is available to them today compared to ten or twenty years ago. Progress has happened, and it’s a good thing. Of course I agree with this.

But meanwhile, the conspirators are rubbing their hands together and mumbling something like “heh, heh … still got ‘em.” The reason for the acclaim for the results of innovation and the near-complete lack of awareness of the conspiracy against it is simple: very few people are in a position to see the amazing innovations, true advances that would make everyone’s lives better, that have been and are being today prevented and/or drastically watered down as a direct result of the efforts of the anti-innovation conspiracy. If there were widespread knowledge of “what could have been,” people would see the results of innovation in a completely different light. It would be like a starving person in a room being given a bit of bread and water; they eagerly consume it and are glad to have it. But how would their attitude be different if they knew that, just through a door in the room, there was a sumptuous feast all laid out, ready to eat, and the person giving them the bread and water was preventing them not just from going through that door, but even from letting them know it was there? Gratitude for the bread and water would suddenly be transformed into fury at the person keeping them from the food they so desperately need, even hiding the fact that it’s there! The vast majority of people are like the starving person in the room, grateful for the food they now have, completely unaware of the feast they can’t eat because the conspiracy successfully hides it from them.

I know these are strong claims. But after decades of writing innovative software and more decades of looking deeply at innovative companies and their spread of innovation in various companies and industries, this describes the patterns I have observed.

Finally, let me make something clear: There is no cabal of anti-innovation conspirators who explicitly communicate among themselves that their goal is to prevent or slow innovation. If there were such a cabal, it would have been exposed and shamed long ago. The long-lasting conspiracy is fueled by a wide variety of goals that appear to have nothing to do with preventing innovation; the conspirators, as they deserve to be called, don’t say or even (for the most part) tell themselves that they are trying to prevent innovation. It’s always something else: they are trying to protect the public, prevent people from being harmed, assuring that things are built to proper standards, trying to maintain stability in a well-oiled operation, avoiding wasteful distractions, and on and on. Most of the people involved might sincerely claim they are promoting innovation everywhere they can. The trouble isn’t their thoughts or words; the trouble is their actions, which have the net effect of preventing or slowing innovation.

I have already written about some of the issues involved in the anti-innovation conspiracy.

https://www.blackliszt.com/2023/07/summary-software-innovation.html

There is more to be written, for example to shame those who promote themselves and their institutions as being leaders in innovation. I hope others will take up this long-neglected issue.

How to reduce the cost of medical imaging and PACS

Medical imaging devices like MRI's, CT and X-Ray machines are extremely valuable. They're also extremely expensive. So expensive, in fact, that health insurance companies typically require a pre-authorization for an MRI scan to make sure that it's "medically justified." The market is currently estimated at about $40 Billion a year, with more spent on proprietary PACS (Picture Archiving and Control Systems) for storing and managing the systems.

The medical imaging market is highly regulated, with the design and construction of the devices subject to detailed requirements for how the hardware and software should be designed and built. The result of the regulations is that a small number of large companies control the market, effectively preventing innovation and new companies from entering the market.

There is a proven path towards opening the market to innovation and dramatic cost reductions, while improving quality. We should break the iron grip of monopolistic companies and harmful government control to enable a medical imaging revolution.

The Software industry case

Something similar happened in the software industry. IBM mainframe computers and software once owned the world. Everyone bought from IBM, and were then required to buy IBM software and applications. They worked, but were incredibly expensive. A government anti-trust suit broke some of their monopolistic power, and new mini-computers changed the game. Then with computers built on multiple microprocessors, low cost, high quality and performance with intense competition ruled the roost in the computer industry. Separate companies built each part of the new world; each competed to be the best.

The crowning touch was that for important parts of the software such as operating systems, open source software emerged and became the norm. Even IBM acknowledged this by porting the Linux open source operating system to its IBM mainframe computers.

What should happen in medical imaging

Medical imaging machines are like specialized mainframe computers. In addition to the physical hardware that does the scanning, there are processors with operating systems and application software. Software controls each step of the scanning process, collects the data, stores it and displays it. Today, every bit of that computer hardware and software is built by the hardware supplier. Just like it was for IBM mainframes before the anti-trust suit.

The big difference is that no government agency exercised control over the details of how the IBM software was designed and built. Sadly, ignorant bureaucrats at the FDA exercise total control over this process, as I detail here. They require the use of methods that are so old and bad that even giant corporations have long-since moved on for their unregulated software.

The argument is that this is about your health. Do you want imaging devices that don't work or give bad results? The FDA performs the essential function of guaranteeing quality and safety, they say.

What they actually do is the equivalent of demanding that only hand saws be used for turning trees into lumber and refusing to allow nails or hammers to be used in house construction. Of course it can be done. But people using modern tools get far better results faster at lower cost. There is a simple way the FDA can assure quality, by shifting from lengthy HOW style regulations to simple WHAT style regulations as I explain here.

The Result

The result of this change will probably resemble what happened to IBM once their monopoly power was broken. IBM continues to this day to manufacture the successors of mainframe computers, now called the Z series. They support both their own operating system and a leading open source one. Applications that run on their systems are available from a wide variety of companies.

Similarly, major vendors such as GE and Siemens will continue to do what they do, but all of the hardware and software will be open to competition by both new and existing vendors, and possibly also by open source efforts. It's likely that Linux would be ported.

Image storage systems for imaging continue to cost many billions of dollars a year. They don't do much more than what you could with Dropbox or AWS S3 storage, for example. Each patient would have cloud folder that would hold all their records and images. The system would store each new file in the cloud, which would securely store it with full multi-site protection and backup. Sharing can be accomplished simply by creating and sending a link, something that can be done with a few lines of code or manually in seconds. The huge problem of medical imaging records storage and sharing that I demonstrated here would go away! Yes, you'd put some UI on top of the cloud storage to make it super-easy and not dependent on any one cloud storage vendor.

Conclusion

The essential and growing world of medical imaging and supporting systems form an indispensable part of modern medicine. It's long since time for them to catch up to the transformation of the computer industry four decades ago, dispense with harmful regulation and allow healthy competition to flourish. We would all benefit by the resulting increase in availability and dramatically lower costs. And yes, with better quality.

 

Revolutionize health by making medical data and studies open source

Medical studies are essential to knowing what works and what doesn't work in medicine. There are a few problems, though. There aren't nearly enough studies, they are expensive and cumbersome, the funding is often by groups seeking an outcome, there isn't enough follow-up, most of the data is secret and they are rarely crafted for personalization. Among other things. What can we do?

Often the cure for a problem isn't isolated genius, but finding a field that had a similar problem that got solved and adapting the solution. I propose that the problem of building software (expensive, cumbersome, takes too long, etc.) is similar to that of medical studies, and the solution of making software open source can be adapted to the problem of medical studies. If medical research and data were open source, most of the problems I listed could be solved.

Open Source Software

The open source software movement has revolutionized the industry. Operating system software, for example, was the proprietary crown jewel of computer manufacturers. IBM's 360 mainframe operating system software, for example, took over 1,000 people years to build. A well-known book by one of its leaders, Fred Brooks' "The Mythical Man-Month" went into detail explaining the nightmare.

There's been a revolution since then. The Linux operating system completely dominates the operating system market; for example, it runs on over 95% of the top million web servers. This isn't new news -- Linux was started over 30 years ago! Since then, even major profit-making software companies such as Google (Android, Chrome, Kubernetes) and Facebook (React) sometimes open-source valuable software they've built internally.

Much (not all) open source software is built by volunteers and the resulting software is freely available. Sometimes company employees work on open source that is valuable to their employers. There are hybrid models such as Red Hat, which charge for services they offer to companies that want to use the open source software. After the early years of resistance and skepticism by traditional programmers and managers, open source software is broadly accepted as a fact of life -- and a good fact! -- in the software world.

Open Source Medical Data

The data from a research study is incredibly important to the people whose disease or condition is studied, to the medical professionals who treat it and to the device or pharma company that creates the new device or drug. The results of the study cause the patients (guided by medical providers) to take drugs, change their behavior or undergo procedures that can have a major impact on their lives. Shouldn't that data be freely available to anyone who cares to study it? Just as open source software hugely benefits by having large numbers of volunteers pore over the code looking for errors, limitations and omissions, so would open source medical test data benefit by having large numbers of people who are even more motivated than software contributors comb through the data -- in software, we're talking about annoying bugs, while in medical data we're talking about life and death.

Anyone with software experience knows that no amount of software testing in a lab environment can match what happens to the software when it's widely distributed. When things go wrong with open source software in the field, open source contributors have a real-life test case of error and have a reasonable shot of finding and fixing the problem, contributing their fix to the central source code. With thousands upon thousands of copies of the software working all over the world and motivated engineers responding to issues and pooling their solutions, open source software achieves a quality that can't be matched by dedicated groups of employees working for a company. Much less a government agency.

The equivalent of this for medical testing is to start with opening all the test data to volunteer analyzers, withholding nothing. Releasing all the data that is now kept secret would be a big step forward.

But that's the equivalent of lab testing.The huge value in open source data will come from extending it to more people than were included in the study, and to include much more data about them, both before the formal start of the study to continuous aggregation of data over time. Among other things, this will enable surfacing factors that weren't considered by the original study designers, both from patient history and from medical events that take place after the formal end of the study. For example, this kind of extended data could surface the facts about the relationship between blood pressure pills and going blind, as I describe here and here.

Open Source Medical Studies

There is no reason why paid medical researchers couldn't continue to define and run medical studies in much the same way as they do today, much the same way as for-profit tech companies create software that they then open source. However, they would have to make 100% of their data open source and fully available anyone to investigate.

The "open source" version would be first to expand the selected participants in the study far beyond what would normally be done with volunteers, and second to extend the data collected to everything that is knowable about the participants, both before the start of the study and continuing long after what would normally be its conclusion. I don't claim to know how best to accomplish this, but I know that today the cost of running study sites, qualifying participants and so on is high. A way would have to be found to enable participants to volunteer remotely, and to enable local volunteers to perform whatever actions like drug injection that have to be performed locally and physically.

This process really kicks in when the new drug or procedure gets past the test environment and becomes more widely deployed. It would be good to emulate the open source software practice of having a careful staged roll-out of a new release instead of the current medical practice of unlimited distribution after approval. This would enable reports from the field, enhancing the open source data, to surface problems that weren't clear in the earlier, more limited testing of the new drug or procedure.

Once the distribution gets very broad, there still needs to be a way to surface and report issues. For example, here is a message from Google to enable broad data reporting about one of their products:

Why shouldn't such permission be added to patient medical records, so that as those records are updated for any reason, the updates are added to any relevant open source data collections? This would make longitudinal tracking automatic and painless to everyone involved.

Conclusion

Medical studies and associated data strongly resemble the proprietary operating systems of computer vendors in the 1960's and 70's. Each body of code was created at great expense by employees of the companies. The code (like medical data) was considered a trade secret, never to be revealed to an outsider. Problems usually surfaced after the code was shipped, just as many problems with approved drugs only surface after they are distributed. Manufacturers kept spending more time and money to make their software bug-free in the lab before shipment, but never got it right -- just as drug makers jump through endless FDA hoops prior to approval, and there are still problems. Makers of proprietary software have huge quality problems to this day, as I have documented, which the "free" open source software largely avoids.

Applying open source software concepts to medical drug and procedure testing and tracking could greatly enhance the safety and effectiveness of augmenting the toolkit available to patients who have medical issues. As it became understood and widely used, patients would have reason to have confidence and trust in the medical profession far beyond what many of them have today. Instead of being constantly hammered about how some drug is "safe and effective," which kinda tells many patients that it probably isn't, the open source method would create a level of transparency and openness that would let people draw their own conclusions.

I have been thinking of this issue for a long time; a discussion with Jonathan Bush at the recent HLTH conference inspired me to write it up.

 

Deep-Seated Resistance to Software Innovation

Everyone says they're in favor of innovation. Some organizations promote innovation with lots of publicity. Many organizations even have CIO's (Chief Innovation Officers) to make sure it gets done. But the reality is that resistance to innovation runs strong and deep in organizations; the larger the organization, the greater the resistance usually is. The reason is simple: innovation threatens the power and position of people who have it. They feel they have nothing to gain and much to lose.

It's not just psychology. Innovation resistance throws up barriers that are thick and high. See this for examples.

A good way to understand the resistance is look at sound technologies that have been proven in practice that could be more widely applied, but are ignored and/or actively resisted by the organizations that could benefit from them. I have called these In-Old-vations. Here is an innovation that is still waiting for its time in the sun, and here's one that's over 50 years old that is still being rolled out VERY slowly.

In this post I will illustrate the resistance to technology innovation in a little-known extreme example: the people in charge of Britain's war effort resisted innovations that could help them win the war. They were literally in war and losing and decided, in effect, that they'd rather lose. Sounds ridiculous, I know, but this is normal behavior of people in organizations of all kinds.

The Battle of Britain

Britain was at war, facing Hitler’s much larger, better-prepared military, who had already rolled over its adversaries. Life and death. Literally. The established departments did all they could do defend from attacks. The so-called Battle of Britain is well-known. What is not as widely known is the battle in the seas. German submarines were sinking British ships at an alarming rate. The Navy had no answers other than to do what they were already doing harder.

The situation was desperate. If there was ever a time to "think outside the box" it would seem this was it. The response of the Navy to new things? NO WAY. Amazing new weapons developed by uncertified people outside the normal departmental structures? NO WAY. Once those weapons are built and proven, use them to stop the submarines that were destroying boats and killing men by the thousands? NO WAY!!

Of course, you might think that someone would have known that the fairly recent great innovation in flying machines was achieved by "amateurs" flying in the face of the establishment and the acknowledged expert in flying as I describe here. You might think that Navy men would remember that perhaps the greatest innovation in naval history was invented by Navy-related people. But no. Protecting our power and the authority of our experts is FAR more important than a little thing like losing a war!

The story of the new way to fight submarines is told in this book:

Someone who was not part of the Navy establishment invented a whole new approach to fighting submarines. The person wasn't a certified, official expert. He was rejected by all relevant authorities and experts. Fortunately for the survival of England, Churchill made sure the concept was implemented and tested. The new devices were delivered to a ship.

This all took time and it was not until the spring of 1943 that the first Hedgehogs were being installed on Royal Navy vessels. When Commander Reginald Whinney took command of the HMS Wanderer, he was told to expect the arrival of a highly secret piece of equipment. ‘At more or less the last minute, the bits and pieces for an ahead-throwing anti-submarine mortar codenamed “hedgehog” arrived.’ As Whinney watched it being unpacked on the Devonport quayside, he was struck by its bizarre shape. ‘How does this thing work, sir?’ he asked, ‘and when are we supposed to use it?’ He was met with a shrug. ‘You’ll get full instructions.' Whinney glanced over the Hedgehog’s twenty-four mortars and was ‘mildly suspicious’ of this contraption that had been delivered in an unmarked van coming from an anonymous country house in Buckinghamshire. He was not alone in his scepticism. Many Royal Navy captains were ‘used to weapons which fired with a resounding bang’, as one put it, and were ‘not readily impressed with the performance of a contact bomb which exploded only on striking an unseen target’. They preferred to stick with the tried and tested depth charge when attacking U-boats, even though it had a hit rate of less than one in ten. Jefferis’s technology was too smart to be believed.

Here's what the new mortars looked like:

What happened? It was transformative:

Over the course of the next twelve days, Williamson achieved a record unbeaten in the history of naval warfare. He and his men sank a further five submarines, all destroyed by Hedgehogs. Each time.

If resistance to change to true technological innovation is so strong when you’re desperate, literally at death’s door, how do you think it’s going to be in everyday life? The rhetoric is that we all we love innovation! The reality is that anything that threatens anybody or anything about the status quo is to be ignored, shoved to the side and left to die. Anyone who makes noise about it obviously isn’t a team player and should find someplace to work where they’ll be happier. And so on.

Conclusion

Innovation happens. Often nothing "new" needs to be invented -- "just" a pathway through the resistance to make it happen. Here is a description of the main patterns followed by successful innovations. If you have an innovation or want to innovate, you should be aware of the deep-seated resistance to innovation and rather than meeting it head-on, craft a way to make it happen without head-on war. Go for it!

Experts vs Innovation New Book

Experts and anointed authorities of various kinds, both academic and commercial, have been the front lines of resistance to innovation for centuries, up to the present. They are the firewall keeping what they consider to be rogue ideas outside the protected environments they oversee, protecting them from bad influences that their naïve but innocent charges might inadvertently adopt. It’s a good thing they’re on the job – otherwise things would be chaos and nothing would get done!

This pattern is raised to a new level when the subject isn’t some specific business domain like healthcare, but the process of innovation itself. As you may have noticed, many organizations now have the expensive modern equivalent of “suggestion boxes,” departments devoted to fostering innovation in the organization, led by a Chief Innovation Officer. Government officials have gotten into the game, establishing centers for innovation, and “incubators” for startups. Eager not to be left behind, academia has jumped into the game, with august professors doing what they do best: pronouncing truths and activities designed to promulgate them.

There was a time in my relatively innocent past when I was willing to give the experts a pass. Hey, how can you know everything? I know I don’t!  They’re probably just trying to keep their organizations from being taken down by harebrained ideas, and sometimes they fail to recognize a true innovation when it appears! I no longer believe that pleasant, forgiving fiction. They’re also not evil geniuses immediately recognizing a juicy innovation when it sniffs around the door, and stamping it out before it can start making changes. The truth is far worse: the vast, vast majority of them wouldn’t know a practical, effective innovation if it came up to them and slapped them in the face! See this and this for more.

The bulk of front-line experts act this way to “protect” their organizations against scary change. They go to great lengths on multiple dimensions to assure that nothing upsets the status quo. Here is detail about the measures they take to prevent innovation, and simple methods to overcome the measures – which the experts are universally ignoring.

But the elite of the experts are experts in entrepreneurship – people who are “expert” in enabling people who want to create and lead innovation to make it happen. These experts on innovation are like experts on being expert. We are definitely still in the middle of an “innovation” bubble, with everyone acting like it’s a new thing. In fact, it’s looking like less of a bubble these days, and looking more like something that’s going to stick around. Here’s some information about the bubble and how we got here.

I’ve seen so much of this over so many years, and been so disgusted with the useless wisdom of experts, that I’ve put together some preliminary thoughts, drawn from experience and observation, about how innovation happens. See this.

Imagine my surprise when I read an article about entrepreneurs that actually made sense! I'd never heard of the guy, Carl Schramm.  It appears from the article that he knows a bunch of stuff about entrepreneurs and innovation that matches up pretty well with my observations, but is actually backed by … real data! OMG! One of my initial shocks was learning that he was a real professor at a real university, even with a PhD, but that … he had worked as an entrepreneur! How is that possible? How did he manage to slip by the super-strict requirements that prevent anyone who actually knows something from experience becoming a Professor?? Maybe it helped that he had been the head of the Kaufman Foundation, the largest foundation devoted to the study of entrepreneurs and innovation, and that instead of just doling out grants, he did real studies to gather real data. What an idea. You think maybe the people who run Departments of Computer Science could get inspired? Sorry, forgive me, you caught me dreaming the impossible dream there...

I’m not finished reading the book yet, but here it is:

As you might guess from the title, he talks a lot in the beginning about that near-universal requirement for getting innovation funded, the dread business plan. He trashes it. Vigorously and effectively. No, he doesn’t trash this or that business plan, he trashes the very idea that business plans are both essential and good. He’s right! For exactly the same reason (he doesn’t say this, I’m saying it) that project management in software development is not just brain-dead, but a positive impediment to getting good software done!

If you are ready to learn about a different and better way to be an entrepreneur, check out this book.

Simple Data Entry Technology Illustrates How In-Old-Vation in Software Evolution Works

Since when is “data entry” (entering data into a computer) a pivotal, innovative technology? When the difference between doing it the normal way and doing it with advanced technologies is a …ten-to-one productivity difference … that’s when.

I’ve described how the Operations Research algorithm of Linear Programming is fifty years into an agonizingly slow roll-out through different applications, from scheduling oil refineries in the 1960’s to scheduling retail sales in the 1990’s, and now scheduling medical infusion centers and operating rooms in the late 2010’s. In each case, laborious and error-prone human scheduling was replaced by the algorithm, with improvements ranging from no less than 10% to over 50%. This is major! Why did such an innovation wait for decades to be applied, and for many applications, is still waiting!!?? This is the mystery of how what’s called “innovation” works in reality, and why it should be called “in-old-vation” instead.

You may think that part of the cause is that LP is an exotic algorithm – even though it’s a standard part of the Operations Research engineering curriculum, most so-called normal people haven’t heard about it. While it appears that even the hosts of people who wax eloquent about AI and ML are clueless about LP, it’s not exactly a secret. So let’s see if obscurity is the reason why LP remains a “future innovation” in many potential applications, by examining the super-plain, ordinary, completely-understandable-by-normal-people case of data entry.

Data Entry

Just as process optimization is done by hand or stupid methods for decades until some genius comes up with the brilliant idea of applying tried-and-tested LP to the problem and dramatically improves it, so is Data Entry widely performed by primitive methods until some “innovator” comes along and applies “Heads-Down Data Entry” (HDDE) methods to the process – and typically gets improvements of 3 to 10X! The only difference is that while LP is taught in Engineering departments and studied by math nerds, Heads-Down-Data-Entry is “just” a collection of common-sense techniques that require no math and no professors to understand or implement. It’s so “common” that it doesn’t even have a generally accepted name – though it’s been implemented in many places and been thoroughly proven in practice. It’s far too humble to merit an academic department – and yet, when applied, has delivered truly massive gains, far higher proportionately than exotic Linear Programming has!

The methods of HDDE were first implemented in places that had huge volumes of repetitive data to be entered into computers. Banks were early users for check entry, and so were the credit card companies who, at the start, had huge volumes of paper charge slips to process. Simple ideas like minimizing keystrokes and eye movement were implemented, and then taking advantage of the eye-to-fingers pipeline, when people noticed that showing clerks the next item to be entered before the current one was complete led to a big jump in speed. Other methods like double-blind techniques were invented, so that entry clerks just entered – whether their work was original or used to check someone else’s work was entirely handled by the Data Entry system.

As soon as scanning and image display became practical, HDDE adopted them. That led to another jump in productivity, enabling large, complex forms to be broken up into pieces, so that a clerk would see the image on a screen of the same piece of data from a whole set of forms instead of entering a whole form from start to finish. No HDDE shop would even consider having the entry clerk think about anything on the form, stuff like “if this field is missing, do this instead of that,” because it would just slow them down.

Finally, there’s ICR (Image Character Recognition), which is having the computer “read” the image instead of a human. This technology has existed for many decades. Once you’ve got HDDE in place, phasing in ICR is a natural, so that the proportion of entry done by humans gradually decreases as the effectiveness of ICR increases.

Remember, applying LP to scheduling might result in a 30% improvement, which in most cases, is major to the point of being revolutionary. What about HDDE? Entering data from a paper form into a computer using primitive methods might get between 1,000 and 1500 KPH (keystrokes per hour). There are lots of stages of improvement, including things I’ve mentioned like eliminating the thinking and breaking up the form, but levels of 10,000 to 15,000 KPH in a professional environment are widely achieved – with superior quality. That’s a minimum of 5X! Typically much more. Of course, as you incorporate ICR into the process, it gets even better, gradually reducing the human factor, so that most fields are entered with no human involvement. At this point, the technology is probably best called ICR+HDDE, though there is no generally accepted term.

Given all this, it would be insane to handle computer data entry by anything other than HDDE methods, right? Welcome to the software industry, where insanity of this kind is the accepted state of affairs. And where almost no one practices the most simple and basic of computer fundamentals, such as counting.

How HDDE gets implemented

I described how Linear Programming went from problem domain to domain, each time acting like an innovation, as indeed it was in that area of application. Once it gets established, it tends to stay. The case of HDDE is different, I think because it’s not a recognized “thing” in the halls of academia, or among the poo-bahs of big business. It’s the kind of thing that no self-respecting Professor of Computer Science would stoop to consider, assuming he ever encountered such a low-status thing – you know, the kind of thing that “merely” makes common sense and, well, works.

HDDE has appeared in competitive, high-volume service businesses, where it has a major role to play in delivering results for the customers of the business. There have been software products that directly support HDDE, so that all you have to do is buy and implement them. It’s neither obscure nor hidden. But it’s never been talked about at conferences as the “coming thing.”

Case Study: HDDE rejected

In the early 1990’s, when document imaging and workflow technology were hot and something people talked about the way they talk about AI/ML and innovation today, the government-backed student loan organization, Sallie Mae, decided to apply the technology to improve the operations at the handful of processing centers they had at the time, employing many thousands of people and processing millions of documents a year. The popular thing to do at the time was to scan documents on receipt, and then send them to the same places the paper was sent, so that workers could process the images of the documents displayed on new big screens instead of paper. The job was basically to type the data into the right places of the software application they used.

Everyone at the time said that converting the documents was important ONLY because it enabled wonderful workflow, the elimination of inboxes and outboxes for paper. And the bits of other stuff you could do, like having a group of people taking from a common inbox instead of each having their own. The common “wisdom” was that you could gain 30% productivity improvement by implementing this marvelous new technology.

I got involved, since I was a recognized expert on document imaging technology at the time, and had personally coded one of the early workflow systems. I figured out and showed in detail that by canning the workflow and implementing HDDE techniques, they could gain a minimum of 5X productivity improvement. No one disputed my thoughts or detailed plan. They just ignored it, and proceeded to implement the standard stuff. I strongly suspect that after considerable time and expense, there were walk-throughs of the Sallie Mae sites showing visitors the big screens and absence of paper – what a big success the project was!

Case Study: ICR-HDDE applied with success

There are two current cases I know of where ICR-HDDE is being applied and winning. Each are classic, narrow service businesses where converting forms to data is the key value of the business, and where the companies buying the service just want fast, accurate data delivery, they don’t care how it’s done. Disclosure: each of these is an Oak HC/FT investment.

At Groundspeed, insurance forms and reports are captured and the relevant data is extracted from them by the most effective relevant means, often involving forms of ICR-HDDE. There is lots of forms recognition from documents and images that are often computer output, with the relevant data appearing at varying places on a page. Nonetheless, Groundspeed is able to deliver the data stream the customer needs, quickly and accurately, The results are so powerful that new levels of analytics are enabled by the newly available stream of structured data.

At Ocrolus, financial documents of all kinds including bank statements and pay stubs are converted to data in a standard format to enable fast and effective operations like giving loans for business and personal use, along with a growing list of other operations that also need good data. An effective combination of ICR-HDDE techniques are applied to get results for companies that need accurate data to make fast decisions.

Conclusion

HDDE is a collection of methods that have been proven in practice for many decades. The technology that is behind it continues to deepen and reduce human effort even more, with the addition of ICR. But it remains a niche technology, ignored by the numerous places that could benefit from it, even more than LP.

The big difference between LP and HDDE is that LP is a formal piece of magic that’s in academia. HDDE is nowhere. In fact, it’s really just an example of classic industrial engineering applied to computer software and the people who use it. Which makes it all the more mysterious that it's largely ignored.

In-old-vation is real. Most “innovations” are minor variations on things long-since proven and demonstrated in practice, but are unimplemented in the many situations that would benefit from them until some mysterious combination of circumstances arises to let them explode into practical reality.

Barriers to Software Innovation: Radiology 2

Value-creating innovations are rarely the result of a bright new A-HA moment, though an individual may have that experience. A shocking number of innovations are completely predictable, partly because they've already been implemented -- but put back in the vast reservoir of ready-to-use innovations, or implemented in some other domain. This fact is one of the most important patterns of software evolution.

Sometimes the innovation is created, proven and fully deployed in production, like the optimization method Linear Programming, which I describe here. In other cases, like this one, the innovation is built as a functioning prototype with the cooperation of major industry players -- but not deployed.

In a prior post I described how I went to the San Francisco bay area in the summer of 1971 to help a couple of my friends implement a system that would generate a radiology report from a marked-up mark-sense form. We got the system working to the point where it could generate a customizable radiologist's report from one of the form types, the one for the hand. Making it work for all the types of reports would have been easy -- we demonstrated working software, and wrote a comprehensive proposal for building the whole system. It was never built.

True to the nature of software evolution, the idea probably pounded on many doors over the years, always ignored. But about 10 years ago, a pioneering radiologist in Cleveland came up with essentially the same idea. Of course, instead of paper mark-sense forms, the radiologist would click on choices on a screen, and would usually look at the medical image on the computer screen. This enabled the further benefit of reducing the work, and letting doctors easily read images that were taken in various physical locations. Tests showed that doctors using the system were much more productive than those who worked in the traditional way. Finally, they decided that mimicking the radiologist's normal writing style was a negative, and that the field would be improved by having all reports follow a similar format, with content expressed in the same order in the same way. This was actually a detail, because the core semantic observations would be recorded and stored in any case, enabling a leap to a new level of data analytics. It also, by the way, made the report generation system much easier to build than the working prototype we had built decades earlier, which enabled easy customization to mimic each radiologist's style of writing.

The founding radiologist was a doctor, of course, and knew little about software. He did his best to get the software written, got funding, and got the system working. Professional management was hired. My VC group made an investment. Many people saw the potential of the system; it was adopted by a famous hospital system in 2015. But in the end, the company was sold off in pieces.

Nearly 50 years after software was first written that was able to produce medical imaging diagnostic reports quickly and reliably while also populating a coded EMR to enable analytics, the system is sitting in the vast reservoir of un-deployed innovations. It can be built. It saves time. It auto-populates an EMR.

Many people have opined on why this particular venture failed to flourish. It's a classic example of the realities of software innovation and evolution. The reasons for failure were inside the company and outside the company. For the inside reasons, let's just say that the work methods of experienced, professional managers in the software development industry lead to consistently expensive, mediocre results. Nonetheless, the software worked and was in wide production use, delivering the advertised benefits. For the outside reasons, let's say that, well, the conditions weren't quite right just yet for such a transformation of the way doctors work to take place.

The conditions that weren't right just yet for this and uncountable other innovations add up to the walls, high and thick, behind which a reservoir of transformative innovation and "new" software awaits favorable conditions. In other words, the reservoir of innovations wait for that magic combination of software builders who actually know how to build software that works, with a business/social nexus that accepts the innovation instead of the standard no-holds-barred resistance.

Corporations promote what they call innovation. They are busily hiring Chief Innovation Officers, creating innovation incubation centers, hanging posters about the wonders of innovation, etc. etc. They continue to believe the standard-issue garbage that innovation needs to be invented fresh and new.

The reality is that there is a vast reservoir of in-old-vations that are proven and frequently deployed in other domains. All that's needed is to select and implement the best ones. HOWEVER, a Chief Innovation Officer is STILL needed -- to perform the necessary function of identifying and breaking down the human and institutional barriers that have prevented the in-old-vations from being deployed, in many cases preventing roll-out for -- literally! -- decades!!

The Slow Spread of Linear Programming Illustrates How In-old-vation in Software Evolution Works

There is loads of talk about “innovation.” Lots of people want to do it, lots of people think they’re doing it, consultants run courses in how to be innovative, and large organizations claim to promote innovation and be innovative. The assumption behind most of this “innovation” talk is that a wonderful bright idea that will change the world (or at least your organization or startup) can pop into anyone’s head. It’s new! It’s brilliant! We’re going to win big with this great new idea! See this for example.

When you study software evolution, you get an entirely different picture of software-based “innovation.” Software evolution shows you that new ideas that work are extremely rare. Oh sure, there’s a flood of new ideas popping into people’s heads all the time. Mostly, they’re not new, and the new ones rarely work. The software concepts that make it big are, in the vast majority of cases, clear examples of existing patterns of software evolution, and have in most cases already been implemented in a different context.

I first encountered the mystery of software evolution while in my first job programming software.

I started programming in a course I took starting in 1966 in high school, taught by a math teacher who couldn’t himself program, but had convinced the school to let him teach the course, and had convinced a local company, a pioneering rocket engine company called Reaction Motors, to give us computer time on Saturdays. I had a textbook about FORTRAN, a steady stream of programming assignments and a computer on which to test my programs. It was great! I continued programming the following summer, as part of an NSF math camp I was able to attend. As I was nearing high school graduation the following year, I got lucky; Diane, a high school friend, talked about me with her father, who got me connected with a nearby company, and I landed a job there for the summer before starting at Harvard College in the fall of 1968.

The company was EMSI, Esso Mathematics and Systems, Inc. in Florham Park NJ.

They were a service company, one of the about 100 units of the Standard Oil of NJ (Esso) companies, devoted to applying math and computers to improving every aspect of the company. I was immediately thrown into the group that was developing optimization models for oil refinery operation. Our focus was on the giant refinery in Venezuela.

What we had running was an implementation of a classic OR (Operations Research) algorithm called LP (linear programming), solved via the simplex algorithm first devised by George Danzig in 1948. In this kind of model, there is a goal equation and a set of constraints. The goal equation calculated profits, using hundreds of contributing variables, including prices you could sell things for, and the costs of various inputs. The constraints were greater/less than equations, each essentially describing some tiny aspect of how the refinery worked. What the algorithm did was find the values of the variables that maximized the goal equation (profits) while satisfying all the constraint equations.

The model was constantly being modified to make it more precise and applicable to actual refinery operations. I had a variety of jobs, including writing new code, fixing bugs, etc.

Since prices were such a key part of the LP model, we had a separate program to calculate what they were likely to be in the future, a Monte Carlo model. I also made enhancements and fixed bugs in this body of code.

I was fortunate to be able to hitch a ride to work and back with a PhD who worked there and lived in my town. During the ride I would tap his deep knowledge of things. He put me onto the various journals in which advances in various forms of OR were described, which I dove into. The math was often above my head, but I was motivated to teach it to myself on a rolling, as-needed basis.

I thought this was a really cool way of running things. There were all sorts of controls in the refinery, controls that let you create more airline fuel and less heating oil, or any number of other trade-offs. It was amazing that you could compute the setting of all the control knobs that would produce the best mix of products that the market needed. Why would you ever run any operation any other way?? It would be simply ignorant and stupid.

I finished school, learned more about the way the world worked, and searched high and low for implementations of LP. Anywhere! If they were out there, they were doing a great job of hiding.

I was confused. How could this be? LP was math, doggone it. It yielded a provably optimal way of running a business. It’s proven in real-life production at Esso. Any other way of operating a business was clearly seat-of-the-pants, wet-finger-in-the-wind amateur hour; anyone whose operation was sizable enough to justify the effort would have to use this method if they weren’t plain-and-simple incompetent. But no one seemed to be using it! What’s going on here??

This mystery was on my mind while I participated in one of the periodic AI crazes that has swept the world of with-it people. While I was still in college, Winograd published his MIT SHRDLU research, in which an “intelligent” robot would converse with a human in English about a world consisting entirely and solely of blocks. You could ask SHRDLU to “put the red block on top of the blue block” and it would do it; you could ask it questions about block world, and it would answer. Amazing! Super-practical! While this was happening, I wrote and submitted a thesis about how to structure knowledge inside of an intelligent robot. All of it useless compared to LP and the associated OR techniques.

The craze was AI, and the mania lasted a few more years, generating a steady stream of "promising" results, none of them in the same universe of practicality and benefit as LP or any other OR optimization technique, which continued to be used only in "secret" little islands of astounding efficiency and productivity.

Later in the 1970’s I first applied for a home mortgage. A key part of getting the mortgage was the interview with the loan officer. You had to pass muster to get the mortgage! Another 10 years passed before OR-type models started to be used for credit. When I next applied for a mortgage in 1981, I was interviewed by a loan officer. By my next mortgage in 1987 it was at least partly automated.

When I got into venture capital in the 1990’s, I discovered that high-value repair parts were had recently been optimized in terms of inventory levels and locations. I looked in detail at the pioneering company ProfitLogic, which did inventory and sale optimization for retail stores, answering questions like when should which products be put on what kind of sale, questions that had traditionally been answered by the local marketing “expert,” just as oil refineries had previously been run exclusively by experienced experts.

Only in the late 2010’s did exactly the same LP models start being applied to medical scheduling, to optimize the use of things like infusion centers and operating rooms. Just as oil refineries produced much more value from exactly the same crude oil inputs in 1968 as a result of LP models, so are infusion centers handling 30% more throughput using exactly the same capital and human resources using the very same LP models.

Here’s the mystery: why did it take so blankety-blank long for LP models to be applied??? There has been no theoretical break-through. Yes, the computers are less expensive, but given the scale of the opportunity, that was never the obstacle. WHY??!! The answer is simple: there is no good answer. Except of course for the ever-relevant one of human ignorance, stupidity and sloth.

The example of LP optimization and its agonizingly long roll-out through different applications and industries over more than 50 years – a roll-out that is far from complete! – is a prime example of the reality of computer/software evolution. Among other things, it illustrates the point that many of the most impactful "innovations" are really "in-old-vations," things that are just sitting there, proven in production and waiting for someone to apply them to one of the many domains which they would benefit.

Here are a couple cornerstones of computer software evolution:

• Software evolution resembles biological evolution only a little. Not-very-fit software species thrive in broad areas of application, unchallenged for years or decades, while vastly superior ones rule the roost not far away. The only reason why the superior software species don’t migrate to the attractive new place appears to be human ignorance and inertia.
• Software evolution resembles the much-derided theory of “intelligent design” quite a bit, if you make a slight edit and call it “un-intelligent, un-educated design.” A “superior” (HA!) being does indeed do the designing of the software, in the form of highly paid software professionals.
• When software appears in a new “land” (platform, business domain), it most often starts evolution all over again, first appearing in classic primitive forms, and then slowly re-evolving through stages already traversed in the past in other “lands.” This persistent phenomenon supports the “unintelligent design with blinders on" theory of software evolution.

I will explain and illustrate these points in future posts and a forthcoming book.

Barriers to Software Innovation: Radiology 1

There is a general impression that software innovation in one of its many forms e.g. “Digital Transformation” is marching ahead full steam. There are courses, consultants, posters hanging in common spaces and newly-created Chief Innovation Officer positions.  What’s new? What’s the latest in software?

The reality is that there are large reservoirs of proven, tested and working software innovations ready to be rolled out, but these riches are kept behind the solid walls of dams, with armies of alert guardians ready to leap in and patch any holes through which these valuable innovations may start leaking into practice. Almost no one is aware of the treasure-trove of proven innovations kept dammed up from being piped to the many places that could benefit from them; even the guardians are rarely fully conscious of what they’re doing.

If anyone really wanted to know what was coming in software, all they would have to do is find the dams and peer into the waters they hold back.  In spite of the mighty dams, it sometimes happens that the software finds its way into practice, normally in a flood that blankets a small neighborhood. Sometimes the flood has been held back for decades. There are cases I know of where an innovation was proven 50 years ago, and is still not close to being rolled out.

The dams are built in many ways with many materials. The raw materials appear to include aspects of human nature: ignorance, sloth, greed -- you know, the usual. The really high, solid dams have broad institutional support, in which “everyone” is fine with things as they are, and won’t so much as give the time of day to an amazing innovation that would change many things for the better – except of course for a key interest group.

Here is one of the examples I personally know about. It was one of my introductions to what innovation is all about, and the sad fact that creating a valuable innovation is generally the easy part – the hard part is usually overcoming the human and institutional barriers to deploying it.

Automating Medical Image Reading and Reporting

When a radiologist gets an X-ray, there are two phases of work. The first is to “read” the X-ray and observe anything non-typical that it shows, anything from a broken bone to a tumor. The second is to generate a report of the findings. Most radiologists, then and now, dictate their findings; then someone transcribes the dictated report and sends it as needed. The details of the report can vary depending on the purpose of the X-ray and the kind of person for whom it’s intended.

There has been technology first tested decades ago that appears to show that software is capable of “reading” an X-ray at least as accurately as a human radiologist. I will ignore that work for now, and focus on what should be the less threatening technology, which is translating the doctor's observations to an appropriate report.

While I was in college, I worked on the early ARPAnet with an amazing group of people, one of whom was an MIT student from the San Francisco area who later went on to fame making major advances in integrated circuits, among other things. The summer after we did most of our ARPAnet work, he got involved with a new initiative to transform the way radiologist reports of X-rays were created. He knew that some of my skills in automated language parsing and generation were relevant, so he invited me out to pitch in. I went.

GE, then and now, was a major maker of medical imaging systems. They were seriously experimenting with ways of enhancing their systems to make it easier for radiologists to produce reports of their findings. They created a set of mark sense forms, of the kind widely used at the time for recording the answers to tests, to enable a radiologist to quickly mark his observations of the part of the body in question. Here is the form for a person's guts:

Here is part of the form for the hand, showing how you can mark your observations:

Here is part of the form for the spine, showing how you can customize the report output as needed:

My friends had gotten most of the system together -- all I had to do was build the software that would create the radiologist's report. Because of uncertainty about radiologist's accepting the results, I had to make the report generator easily customizable, so that the radiologist's typical style of writing was created.

Leaving out the details, in a few weeks I created a domain-specific language resembling a generative grammar and rules engine to do the job -- along with the necessary interpreter, all written in PDP-8 assembler language, which was new to me. My friends wrote a clear and compelling report describing our work and included an example of our working software in it. Here was the sample filled-out form:

And here was part of the report that was generated by the software we wrote from the input of that form:

The software worked! And yes, the date on the report, 1971, is the date we did the work.

A major company, prominent in the field, had taken the initiative to design mark-sense forms, incorporating input from many radiologists. A few college kids, in contact with one of GE's leading partners, created a working prototype of customization report-generating software, along with a proposal to bring the project to production.

Just as a side effect, this project would have done something transformative: capture the diagnostic observations of radiologists into fully coded semantic form. This is a form of electronic medical record (EMR) that still doesn't exist, even today! For all the billions of dollars that have been spent on EMR's, supposedly to capture the data that wil fuel the insights that will improve medical care, a great deal of essential medical observation is still recorded only in un-coded, narrative form -- including medical imaging reports!

The bottom line is that this project never got off the ground. Not because the software couldn't be written, but because ... well, you tell me.

See the next post for the continuation of this sad but typical story.

Use Advanced Software Methods to Speed Drug Discovery

Drug discovery is like the worst imaginable, old-style software development process, guaranteed to take forever, cost endless amounts of money, and far under-achieve its potential. There are methods that the most advanced software people use to build effective software that works in the real world, quickly and inexpensively. These small groups invent all the new things in software, and then get bought by the big companies.

Can these fast, agile, effective methods be applied to invent and test new, life-saving drugs and get them to the patients who are dying without them? Yes. The obstacles are the usual ones: the giant regulatory bureaucracies and the incumbents who would be disrupted. Yes, the very people who claim to keep you healthy and cure your ills are the very ones standing between us and speedy drug discovery.

Drug Discovery and Software

While I'm not an expert in drug discovery, I've learned more than I wish to know about the regulations through the software providers to the industry. And like many other people, I've learned from being a patient with a disease that could be addressed by drugs that I am not allowed to take, because they are deep in the labyrinth of the years-long approval process.

I've explained elsewhere how a revolution in medical device innovation could be enabled by transforming the applicable regulations from complex, old-style software prescriptions to simple, goal-oriented ones.

A similar concept can be applied to the process of drug discovery itself.

Old-style Software is Like the FDA's New Drug Regulations

The classic software development process is a long, expensive agony. It's an agony that sometimes ends in failure, and sometimes ends in disaster. It most resembles carefully constructing Frankenstein's monster. It starts with requirements and goes on to various levels of design, planning and estimation. Finally the build takes place. But wait -- we can't "release" the software until we know that its quality is top-notch. And that it meets all the requirements. It's gotta work! So let's make absolutely sure that it's up to snuff before inflicting it on the innocent users. Here are details.

Yes, those innocent users -- who are, by the way, chomping at the bit to get at the long-awaited new software whose requirements they signed off on years ago, and that they actually need to get their jobs done.

So is software development like drug discovery? Let's see.

• Development that's a long, expensive agony. Check.
• Don't release it until its adequacy is PROVEN. Check.
• People who are just dying to use it. Check.

But here's the difference: for software, usually one company both builds it and decides whether and when to release it. That means the business leaders of the company can balance the tension between adequacy and getting it out there. In the case of drugs, it is adversarial: the FDA declares how each step of drug discovery and testing has to be done, and has armies of people to impose its will on the companies that do the work.

The FDA Nightmare

The FDA nightmare has two main parts.

The first nightmare assures that development and testing is performed in what is claimed to be the "safest" way possible -- it's all about protecting patient health! In fact, this means incredibly slow and incredibly expensive. The overhead is far more burdensome than the work itself, which really tells you something. There is a multi-billion company, Documentum, that got started with and still is the leading provider of software to the pharmaceutical industry for handling the documents required by the FDA. Right away, this expense and overhead burden assures that no group of brilliant people will create a start-up and create a new cure for a disease.

The second nightmare is that the process is incredibly high risk. The FDA can kill your new drug at any time, including near the end, after all the time and money is gone. This again reduces the number of groups performing new drug development to a tiny number of rich, giant, risk-averse corporations.

This is like big-corporate software development -- only far worse.

Wartime Methods for Drug Discovery

I've written a lot about wartime software development. A good way to understand it is to look at bridges in peace and war. In wartime, we build effective bridges while under fire in a tiny fraction of the time needed in peace. And the bridges work.

The methods translate well to software. They are practical. They work. They are in regular use by groups that are driven to innovate and get stuff done. There are details in my book on the subject, with lots of examples and supporting material in my other books.

It's very clear that the methods also apply to the FDA's regulation of software. Here is an example. There is no reason other than the usual obstacles to innovation that the principles couldn't be applied to drug discovery in general.

Wartime Drug Development

What we should try is Wartime Software Development morphed into Wartime Drug Development. Here are the principles:

• Grow the baby.

Instead of going through a whole long process and supposedly coming out with perfection at the end, you start with something that sort of works, try it (on volunteers), see how it goes, make changes and iterate.

• Principles of e-commerce and social media

When you think of buying a product, do you just walk into a store and trust the salesperson? If so, you're probably in your 100's and hope to get a computer someday. Everyone else goes on-line, checks reviews, and above all checks comments from real users. The sheer number of comments tells you how popular something is. Of course, you don't blindly believe everyone, and of course you translate what people say to your own situation. There could be awful risks and side effects, but if it sometimes works and your alternative is misery shortly followed by death, you might decide it's worth the risk.

It's a decision that should be in your hands, informed by full sharing and disclosure, not decided on your behalf by a bunch of bureaucrats sitting in offices.

• Open source and full disclosure.

Of the top million servers on the internet, over 95% run linux, an open source operating system. Linux was created by an interesting nerd, and developed by an evolving band of distributed volunteers. It is superior to any commercial operating system. And operating systems are complex; linux contains more than 12 million lines of code! Why shouldn't we make drug discovery open to a similar process? With open source, everything about a drug and its results so far would be open and available for anyone, including patients, to see. Patients and researchers would all be active participants in the open discussions.

• Continuous release

The most advanced sites first bring up their software in extremely limited, volunteer-only releases. Everything is tracked. If things go well, more people can be invited in. Incredible tracking, lots of feedback, explicit and implicit. As software goes into wider release, a new version of it may be made available to a combination of new and existing users. Its use may be expanded, or it may be withdrawn. The process is continuous and iterative. It's called continuous improvement. We use it in lots of domains, ever since its use was formalized by W Edwards Deming in car manufacturing. It's not exactly weird or marginal. We simply refuse to apply its proven principles to drug discovery.

Conclusion

The FDA says its mission is to keep us safe. The gigantic bureaucratic monolith in practice assures that new drug development is performed by a tiny number of elite corporations at great expense, and rarely. Let's at least try a better way of doing things!

The Science of Innovation Success

Most of what you read about how to innovate and how to achieve success as an entrepreneur is irrelevant at best, and a cargo cult at worst. The real success patterns are not well known. They work. If you want to be seen by the world as doing the right thing, keep doing what "everyone" says you should do. But if you want to ... win ... you may want to consider learning from the patterns that actually work.

Patterns that work in health and fitness

Let's look at a clear winning pattern in health and see if it can be applied to learning how to innovate. (Hint: it can't.)

Sometimes you're struck down by an illness that no action of yours could have prevented. HOWEVER, there are proven patterns of behavior that greatly improve your health and resistance to disease, and related patterns that clearly result in your being able to run faster, jump higher and lift more weight. While the specific advice to achieve these things varies, the principles as understood by mainstream experts are largely valid.

It's pretty simple: eat a variety of mostly un-pre-packaged foods with a minimum of additives and things like fructose, and balance exercise and eating so that you maintain a moderate weight for your body type. For fitness, it's exercise and practice.

In addition to these common-sense patterns, there other things people do that make sense. If you see someone who has achieved what you want to achieve in terms of health and fitness, it makes sense to find out how they did it and emulate their actions. In addition, it's broadly known that motivation is a key factor, along with attitude and consistent behavior.

In other words, study what the fit, healthy people do, and do it yourself. Pretty simple, at least in concept.

Applying the Observe-and-Emulate Pattern to Innovation

Most things you learn or achieve, you are doing again or for yourself something that has already been done, typically by millions of people. That's what education is all about, for example. When you get educated, you are walking down a well-trod road. What about science education? Same thing. You have to learn the facts, the concepts, the math.

What about innovation? Is it just another thing you can get educated in and learn from the teachers, who learn from the experts? No! Innovation is different. Innovation is some combination of creation, discovery and adapting. It's being the first. It's creating something that wasn't there before. It's taking something that worked in a particular time and place, and making the substantial changes required to work in entirely new circumstances.

Imagine taking a course in exploring new lands in Europe in 1480. Who were the experts? What did they teach? Who could you study and emulate? Of course, there were lots of self-styled, widely revered "experts" who knew all about it. Sure. Columbus had to do it without any help that was actually, you know, helpful!

Innovation is not like health, fitness and most everything else. It's different.

Winning Innovation Patterns

I truly hope someone will figure out if there are winning patterns for innovation and make a science out of it. Until then, from years of observation of people trying hard to innovate, I've noticed a couple of things.

• Pattern: Expert-phobia

Successful innovators ignore the experts. They ignore (1) the experts in their field of innovation, and they ignore (2) experts on innovation itself.

Sometimes experts in a given field, even widely-acknowledges ones, are actually good. While the vast majority simply assert and defend the common view, sometimes an unusual expert will innovate or be helpful to an innovator. But this is the exception. The invention of powered flight is a great example of what usually happens; how the "expert" approach never got off the ground, and the hard-working unknowns made the key innovations. Here's my description.

Successful innovators just don't have time to waste on people who claim to be experts in "innovation" itself. They know that real knowledge is all that matters.

With all the noise about "innovation" in the air, it may seem to make sense to dive in to the "innovation" pond. I've noticed that the people who actually end up innovating with success don't go there. They've got better things to do. If they largely ignore experts in their field, why would they pay attention to experts in generic innovation?

• Pattern: Dive Deep, be the Best

The people who create innovations that work started by diving real deep into some particular area of experience or knowledge. They became real-life, on-the-ground, go-to experts in something. Not famous. Not writing books and giving talks. Just knowing more and accomplishing more in some narrow area of activity.

Knowing as much as they do, they stick their heads about water, and get dissatisfied. They see waste; or stupidity; or something that could be better or be done better. They set out to do it, from the basis of being the best at the status quo. They know how things should be done. They start by wondering how things could be done.

• Pattern: Ignore the Big Picture, Focus on the Little Picture

Most people who get known as experts spend most of their energy sharing their wisdom and broadening their knowledge. They don't innovate.

The successful innovators can be remarkably clueless about the "big picture." Not their problem. They are absorbed with the day-to-day, with what confronts them in the here-and-now. They tend to be do-ers who can think, not thinkers who pretend they could do if they really wanted to.

Often, the problems that inspire innovators are "trivial," from the big-picture point of view. It is just those problems that inspire practical, real-life innovation. Here's a description of "little picture" innovation, and here's an example of "little data" innovation.

• Pattern: Innovate as Little as Possible

Innovators like to innovate. They think of themselves as creative people. They love to solve knotty problems. This is the main problem of many creative people who fail to innovate with success. They can't stop!

People who innovate successfully innovate something that matters. Then they stop innovating, and do what they need to do to make their innovation work in the real world. They reduce their risk. They stick with proven things. Because they want their innovation to work!

• Pattern: Solve Real Problems of Real People

Everyone knows that medical records have to go digital. They've know it for a long time. There were and are loads of experts and industry committees piously pontificating about the best way to do it.

Then a programmer -- yes, a real, live software engineer -- went into the records room of a medical practice and learned how to do the job from the people who were already doing it. He did the work, not just for a couple hours, but for days on end. Long enough to see all the issues. Long enough to get bored, get annoyed, get ideas and get motivated to automate stuff.

He didn't make a plan. He didn't create a strategy. He didn't run some ideas past some people. He wrote some code. Code that would make his life in the filing room better. He tried it out. He wrote more code. The people who really worked there asked if they could use it when he wasn't there -- because it would make their jobs easier. What a concept! The code became Athena Health's highly successful clinical records management product -- a rare example of innovation taking place inside an already-successful company.

• Pattern: Apply Step Theory

Successful innovators don't tend to have carefully-thought-out strategic plans. They don't lay careful foundations. They don't create detailed plans that account for a wide range of contingencies. They know that if they don't get through today, there will be no tomorrow. They know that there may end up being 1,000 steps in their journey, but they also know that if they fail on step 1, they have failed. So step 1 is the ONLY step that matters.

This is "step theory." For more details and examples, see my book.

• Pattern: Ignore Fashion, Except for Scale-up Marketing

It's rare that people who jump on one of the fancy new bandwagons accomplish much of real value. In fact, most of the fancy new bandwagons are little but fancy new names for things that have been around, while others are fads that will fade out. Big Data? Old news. Machine learning? Been around. Blockchain? Great for Bitcoin, not much else.

Nonetheless, to the extent that the fashionable thing happens to be applicable to a narrow, real-world problem and smart, go-deep people focus on real problems and solve them with urgency, innovation can result. Then, as the innovation starts to get traction, it makes perfect sense to embrace the fashion. Why not? If that's what it takes to get people to pay attention to you, you do it.

Conclusion

Here are a few examples of real-life innovation that I'm associated with. Here is a whole book of innovation stories, taken from real life and personal experience. I hope that these patterns of successful innovation will be further explored and help inspire future innovators.

Regulations that Enable Innovation

Regulations that enable innovation? How can that be?? Don't regulations inhibit or even prevent innovation?

Yes they do. Wouldn't it be nice if there were a way to write regulations that enabled innovation? Well, there is a way to do it! It's actually easier to write regulations that enable innovation than the usual way. There are fewer of them. They're easier to understand, and easier to keep up to date. They're more effective at regulating what you could reasonably want to regulate, while at the same time keeping the door open for inventive people to find better ways to get things done, while still conforming to the regulations.

So why isn't this the standard way of writing regulations? Inertia. Lack of understanding. Fear. Bureaucratic intransigence. The usual reasons.

Regulations that Enable Innovation

Practically all regulations tell you, in varying levels of detail, tending to the excruciating, How you're supposed to do the regulated thing. The more detail, the less innovation.

By sharp contrast, regulations that enable innovation tell you What you're supposed to do or avoid doing. The less said about how to reach the goal, the wider the door for innovation.

Suppose the point of a regulation was to make sure you got to work on time.  Typical how-type regulations would tell you exactly when to leave your apartment and exactly what streets and avenues to walk until you got to the office. It would allow for red lights. The regulations would have to change to allow for construction and other changes. If you deviated from the prescribed route or used a different method of transportation, you'd be in violation.

What-type regulations for the same thing are simple: dude, get to the office on time! How? You figure it out, it's your problem! But it's also your opportunity for learning and evolution. You could try walking, and try different routes. You could try the bus and subway. Taxi and Uber. Different ones under different circumstances. So long as you got to work on time, you'd meet the regulation!

For more detail on What vs. How, see this.

If this sounds crazy to you, you should realize that there is a whole, vast area of our legal system that works in just this way: the criminal law. See this for more.

I wouldn't be advocating for change if how-type regulations worked. They usually don't get the job done. They prevent innovation. Worse, when you satisfy all the regulations, you're under the illusion that things are fine. Except that they're usually not. The ongoing cyber-security disasters we have experienced are prime examples of this.

Cutting down the number of regulations

Lots of people complain about regulations. Some people want to reduce their number. For good reason! Have a look at this to see the scale of regulations.

I hope it's now clear that reducing the number of How-type regulations won't make a big difference. It may even make things worse. It's better to replace a whole pile of How-type regulations with a couple of simple, goal-oriented What-type regulations.

An example of regulatory innovation prevention

The rhetoric of regulations and licensing is that they protect us poor, innocent consumers from the awful products and services that would be inflicted on us in their absence. The reality is that they are a massive effort that increases the costs of everyone already providing a product or service, while putting up huge barriers to competition from fast, light-footed innovators who have figured out a better way to do things. Regulation, certification and licensing do almost nothing to protect consumers, but are remarkably effective incumbent protection programs.

While this dynamic plays out in many industries, nowhere is it more harmful to our health and well-being as it is in healthcare.

The FDA is supposed to protect our health. It's even what they say they do:

One of the many ways they do this is by heavily regulating the software that goes into all medically-related devices.

The right way, the What-type way of regulating that software, would be like a criminal law:

Your software has to perform all its intended functions in a timely and effective way, without error. When updates are made, no errors or other problems should be introduced.

Now that's just a first draft. But I bet the final goal-oriented "regulation" wouldn't be too far from this.

This simple regulation states what everyone really wants: the software should do what it's supposed to do. Period.

The FDA does the opposite of simple and effective. It tells you exactly how you're supposed to develop software, and in gruesome detail. Here's the overview of the regulation:

The sections are listed on the left. Each explodes into many sub-sections, some of which are further divided. Each one is long, detailed and brooks no variation (or innovation). On the right in the image above, you see just some of the bibliography, the many underlying documents you'd better get and understand if you're going to be in regulatory compliance.

Here's a diagram that gives an overview of what is required:

Here are the section headings from the software planning part of the document:

As this makes clear, you'd better not write a line of software until you've spent boatloads of time and effort in planning -- exactly what people do when they build buildings using steel and poured concrete, but exactly the opposite of the iterative approach that is the standard among fast-paced, innovative organizations. I mean little upstarts with a high failure rate, like Google, for example.

If the FDA were serious about their stated mission, "protecting and promoting your health," they would immediately blow up IEC 62304 and the who-knows-how-many-other mountains of how-type regulations they oh-so-lovingly promulgate and enforce, and replace them with simple goal-type, what-type "regulations." It would unleash a torrent of health-promoting innovation and open the lobbyist-loving incumbents to much-needed competition. To the benefit of nearly everyone, except a bunch of progress-preventing bureaucrats employed both by the government and by their corporate "homies."

Conclusion

We need regulations. The last thing any of us wants is for corporations to build crappy equipment that doesn't work or deliver services that deceive or hurt us. There are bad and incompetent people in the world, and without appropriate regulations that are vigorously enforced, we'd be worse off. And in extreme cases, dead when we could be thriving.

Which is why it is so upsetting that major organizations like the FDA keeping waddling along, crowing about what a great job they're doing, when it's just not true.

I wish it were just the FDA. Most major sectors of society that are supposed to be protected by regulations are instead hobbled by incumbent-protecting, innovation-killing, ineffective how-type regulations.

The path to regulation that is both effective and enables innovation is clear. Let's do it!!!

Innovation: the Barriers

It's hard to be an innovator. You have to come up with cool new stuff, make it work, and get people to use it. Not easy! Depending on your situation, there can be barriers, active and passive, to being a successful innovator. Lots of people in business and government love to talk about how they're innovative, and how they foster innovation. Hah! In all too many cases, what they actually do is build and sustain barriers so strong and so high that innovation is nearly impossible.

If you look at my earlier posts on innovation, you may think that I'm a cynic. The reality is that I'm an enthusiastic, life-long believer in innovation. My sarcasm is targeted exclusively at the hollow, creativity-killing rhetoric that too often passes for support for innovation.

Active barriers to innovation

What about big companies who innovate? That's mostly rumor and self-promotion, rarely a reality.

What if you're a small company trying to innovate? The barriers are mostly put up by the large businesses that dominate the field in which you want to innovate.

Will the big business itself innovate? In spite of all the talk, probably not. It's likely they want to be seen as modern, with it and innovative. It's highly unlikely that they actually want change. This post goes into some detail about the reality behind giant companies that supposedly are great innovators. Why can't big companies innovate? Who knows, but I think the attitude of the pointy-haired boss is a hint:

There is lots of information and a few stories about how to out-fox the giants that want to keep you down in my book on building a growing business from a startup. But it's tough. The big guys hold most of the cards.

Passive barriers to innovation

Governments are the main source of "passive" barriers to innovation. The barriers are usually in the form of regulations -- regulations that can quickly morph into active barriers once you get caught in the cross hairs of one of these innovation-killing agencies.

You think those regulations are no big deal? The current code of federal regulations is massive, and getting bigger every day. Here's a quick glance at its size:

Of course, no government agency will ever admit that what they are doing is preventing innovation. They are protecting consumers! Enforcing fairness! Doing good stuff, the peoples' business! That's what they say. Sometimes it's even true. But in most cases, what they are really doing is protecting existing businesses and professionals from competition. They do this by putting increasingly burdensome and expensive barriers to new products and services entering the market, and competing with the establishment.

Regulatory barriers to innovation are everywhere, in nearly every industry. Why isn't there a huge outcry? Simple:

• The companies and people that are on the "inside," benefiting from the barriers, vociferously support "protecting consumers" or whatever the b.s. cover story is.
• The people who would benefit from the innovation don't see the innovations, because they don't exist yet, and so can't really lobby against the barriers.
• It's just the way things are. Who has the energy to "fight City Hall," particularly when the innovative benefits don't exist yet because of the barriers?!

The barriers are everywhere, preventing innovation or worsening convenience and price. The barriers are in old, tangible things like a store being able to sell liquor or a car company being able to sell its cars. More importantly, they're in newer, life-issue things like nearly every aspect of healthcare.

Barriers to innovation in healthcare are massive, and getting worse. The barriers aren't called that, of course. The government agencies are protecting our health and privacy! But when you lift the covers, it is easy to see that what is really going on is a rapidly metastasizing federal bureaucracy that prevents life-enhancing products and drugs from being invented, and massively increasing the cost and slowing down the relatively few innovations that squeeze through the gauntlet.

Conclusion

We're clearly in the middle of an innovation bubble. Everyone says they want it. Companies and government agencies claim to be fostering and promoting it. I'm someone who has worked in the innovation trenches for decades. I try to innovate myself, and help others to do it. It's not easy. That's why I get so cynical about all these innovation-smothering institutions who are so loudly in favor of innovation. Their words say one thing and their actions say another. All their innovation amounts to is a pile of marketing rhetoric, an attempt to make themselves appear to be modern.

The Healthcare Innovation Spectrum: From Washing Hands to AI

There's a spectrum of ways to innovate in healthcare. On one end is simple stuff, like making sure things are clean and germ-free. On the other end is exotic stuff, like using AI: Artificial Intelligence and Cognitive Computing. Obvious questions: (1) where is the money going? (2) where is the value? (3) Is the money going where the value is? Simple answer: the "smart" money is going to exotic gee-gaws, ignoring near-term value and patient health.

Where the Money is going

The money is clearly going to exotica. Ignoring for the moment the billions IBM and others are pouring into what they call Cognitive Computing, VC's are investing heavily in healthcare-directed AI. See this:

We're talking serious money here:

While there are loads of conferences, trials, talks and articles talking about the great future here, there is an obvious conclusion to be drawn: while the money is being spent now, the benefits (if any) are in the future.

That's about all you need to say about it.

The middle of the spectrum

While things like AI are clearly at one far end of the spectrum of healthcare innovation, there are intelligent, educated things in the middle of spectrum. Lots of people are pursuing these innovations with great energy. I've discussed an example of one such approach here.

The Oak HC/FT portfolio company VillageMD is another clear example of data-driven innovation in healthcare. No new math or fancy computers are required. "Just" educated, dedicated people looking at the data and making required behavioral changes based on those facts. The founder of VillageMD, Clive Fields, just won a major award for his work, using all-organic and natural intelligence -- no artificial ingredients! Guess what: it's here and now! The outcomes of real patients are being improved as you read this!

The basic end of the spectrum

On the other end of the spectrum from AI, we've got things that shouldn't need "innovation." They should be standard practice. They have huge impact. They are the shocking, scandalous modern equivalent of antiseptic surgery -- things that no one seriously disagrees with, but which the important experts and leadership type people somehow can't lower themselves to pay serious attention to. Or when they pay attention, it's with actions that do nothing to solve the problems.

A good candidate for the poster child of this end of the spectrum is what the CDC calls healthcare-associated infections, HAI's. In other words, getting sick from going to the hospital. Here is the CDC's summary of the situation:

I don't know about you, but this makes me sick. 75,000 preventable deaths in a year, preventable using non-exotic methods. No Cognitive Computing required! There are cures, demonstrated at multiple hospitals that have put serious effort into it. This article summarizes the efforts and approaches, ranging from simple changes of cleaning practices to fancy new machines.

Conclusion

There's a clear spectrum of innovation in healthcare, ranging from blocking-and-tackling basics at one end, to exotic new things based on various forms of Artificial Intelligence at the other end, with smart, non-exotic, data-driven methods occupying the middle ground. Most of the "smart" money appears to be going to the fancy exotic end, with results sometime in the indefinite future, while the rest of the spectrum trundles along, largely under the radar, delivering results to patients today.

Innovation Stories

I worked at Oak Investment Partners for a long time until retiring from it at the end of 2015. Here is part of my page on the Oak website in 2015:

During that time, I had the opportunity to dive into hundreds of tech companies over many cycles, and the further opportunity to be an insider at dozens in which we invested. I learned that what most people tell you about how to be a successful entrepreneur often doesn't match up well with the winning companies I saw.

So what's a person to do?

One thing you can do is read my book. It won't tell you how to win (that's on you), but it will clearly identify some of the most important success patterns to follow, and some of the popular failure patterns to avoid. It has dozens of examples from real life to illustrate the points.

Here are some of the companies in the book and the points or patterns they illustrate.

CRM co., OpenData, Sybase: Do NOT make your execution match your strategy! If you're going to invade a country, don't attack everywhere, pick a beach.

Captura/Concur: Don't let perfection get in the way of making your product usable.

Web services company: Pick something that you can finish, well and quickly.

Smartdrive: When you think you're really focused, try making the focus even narrower.

Inktomi: Don't move on to the next battle until the current one is totally wrapped up; mostly wrapped up may not be good enough.

Workflow companies, collections: The customer defines the problem, not you.

HNC/FICO: Using a platform to attack a narrow but important problem set.

US Auto Parts: Does the customer have a problem right now?

G-Market/E-Bay: Cross-border issues are more than language.

Bank processors e.g. Fiserv: Customers aren't fond of risk.

Nextpage: Are your benefits tangible?

Fastclick: Can you deliver results quickly?

Rebelmouse: Make each step towards a vision be usable.

Athena Health: Adding a whole new service can be 1+1=3

Radisphere to Candescent Health: Giving your customers to someone else can be a great idea!

Company A: Using end-user products in a product/service can save time and money.

Video Ad Network: Sell it first, then build and deliver it seems backwards, but it beats everything else in the right situation.

Maestro Health: You don't always have to program everything; sometimes having people do some of the work is a big win.

Evident: Methods that are great in one domain maybe be failures in a different one.

The Innovator’s Dilemma book: Listening to your customers can hold you back.

Smartdrive: Picking the right group of customers to listen to is key.

TxVia, Feedzai: Building a tool and delivering an application or service with it can be an overwhelming advantage.

MobiTV: Do you have large customers? The power relationship determines the outcome.

Huffington Post: Pick a direction, go quickly, stop for nothing.

Conclusion

I'm kind of slow. It took me more than ten years to start noticing the patterns I've written about, and another ten years testing the patterns against the companies my partners looked at and/or invested in. But they've held up. I know I haven't discovered all the relevant patterns or explained the success of every company, but I also know that I don't read about the things I wrote in the book, which is why I took the trouble to write it. I hope new generations of innovators will improve their odds of success by following the path of the winners.

 

Innovation and Experts

Lots of people want to promote Innovation these days. Why not get in a top expert to help? Answer: if you want to innovate, ignore the experts! With rare exceptions, "experts" are the enemy of innovation, and supporters of the status quo.

Experts

If you're doing something new and want to do it right, it's natural to seek the help of someone who's been there and done that. If you want to do the thing in an innovative way, that's all the more reason to seek expert help; the innovation you need may already be out there, and who's more likely to know it than an expert?

Turning to experts is what we do. At a basic level, that's why we have schools, degrees and certification programs. A person with an MBA is supposed to be much more of an expert about business than the average Jane or Joe. But an MBA is just an entry-level expert. What many people want is an Expert, or even better, an EXPERT!!

An expert is someone who knows loads and loads about a certain portion of common knowledge. They can tell you what are the common practices in a given area, what they would characterize as "best practices." There may be some weird, fringe people out there working at you've-never-heard-of-it places who do things differently and make wild claims about what they do. But can you take the risk of going out on a limb and failing, when all the top organizations do X? Of course not.

Experts are herd dogs. They get everyone to make roughly the same choices that everyone else makes, and go in roughly the same direction.

Think about the process of selecting an expert. Don't you want someone who is generally acknowledged to be an expert? Who advises major organizations to do what the "leading" other major organizations do?

Think about being successful as an expert. The vast majority of the potential fees come from major organizations. None of whom want to be told they're doing things all wrong. Most of whom would like validation, and maybe some minor tweaks. That's where the client list and fees come from.

Experts want to be recognized, hired and paid by rich, mainstream organizations. Organizations want experts to help guide them to not stray too far from the pack.

In other words, the vast majority of large organizations are like sheep traveling in a herd. If they wander off from the herd, they may get lost or hurt! Experts are like sheep dogs who bark and nip at the sheep who wander off or lag behind.

If you want to innovate, the last thing you should want is a typical "expert."

An expert on experts

To get the real story on experts, let's turn to the person who is, above all others, THE expert on experts. Richard Feynman boils the subject down to terms anyone can understand:

An "expert" is someone whose knowledge we are supposed to accept based on the authority of the expert. It's not our place to question it. The whole reason to get an expert is that we assume we can't possibly figure out what to do ourselves!

A scientist reacts to assertions by the expert saying things like "why?" "How do you know that?" "Where are the experiments that prove that what you are saying is true?" Scientists don't take things on authority. Feynman is saying that experts are nothing more than people who say, with deep voices and calm authority, "This is the truth, my child." In any situation in which you are supposed to take things on faith, the natural reaction of the scientist is: you're definitely ignorant, and probably wrong. Why do you need the take-it-on-faith stuff if you can prove it? Science replaces faith in people (i.e. experts) with reliance on facts, proof, numbers and math.

Experts and flight

One of the best examples of innovation and the expert effect is the history of manned flight.

One of the most famous experts of his day was Samuel Pierpont Langley:

He built and launched a couple unmanned planes that flew thousands of feet. He was famous. He got major funding from the government, and everyone expected him to succeed. He was the ultimate expert in aviation.

There was just one problem. His planes all crashed. Here's one that "flew" right into the Potomac River in 1903:

Nonetheless, belief in the expertness of the wonderful expert Langley remained so great, in spite of his complete and utter failure to even come close to controlled manned flight, that his reputation remained high and all sorts of aviation-related things are named in his honor, from medals to airports.

We all know who actually figured out how to make a flying machine: the Wright Brothers.

These guys built bicycles in Dayton, Ohio! No fame. No government money. In no way were they experts. But: they were scientists! In the true sense of the word -- in Feynman's sense. Here's a bit of what they did:

In other words, they figured out what the real problems were, did designs, built prototypes, ran tests, and ... innovated!!!  Here is one of their flights in 1904:

The rest of the story tells us a huge amount about innovation and experts. Briefly, no one believed them! They went for years trying to get government interest. Years later they were celebrated as heroes, but at the time, even the local government and press ignored them. Finally their accomplishments were accepted in 1909, when they flew up and down the Hudson River for half an hour in front of an estimated one million people, circling the Statue of Liberty.

No one could believe that these non-expert nobodies could have solved a problem that stumped the nationally recognized, accepted experts.

Conclusion

If you want to know what to do, you have two basic paths.

One is to hire an expert to tell you basically what everyone else is doing. It's a good way to be "safe," and avoid innovation of any kind. But nothing stops you from crowing about how innovative you are, at least compared to the sheep staring at your back legs!

The other way is to be a scientist and figure out what the real problems are and how to solve them. Then do it. It's what innovators do.

You pick. I know what my choice is.

 

Healthcare Innovation: How to Achieve EMR Interchange

EMR interchange has been a major goal of the tens of billions of dollars that have been spent to buy and install EMR's. The theory is that making it easy for the next medical provider you see to have access to your complete health record will improve health. It might! But the current methods for achieving integration are not working. Not. Working. It's easy to understand why they will NEVER work, and what can be done to achieve the same result.

Not to be mysterious about it, here's how: forget EMR interchange. It's not working because it's hard and none of the people who build and control EMR's really want it to work. Instead, enable a new generation of personal EMR's. It's literally hundreds of times easier.

My EMR vs. Integrated EMR's

Everything is great if I go to a single integrated hospital system that uses a single EMR. I go from place to place in the hospital complex, and everyone knows who I am, where I've been and what's going on:

No problem.

The problem happens when I go to an office, a clinic and a hospital. They each have EMR's. What all the "experts" think is best, backed by tens of billions of dollars, is for the systems to talk with each other. What I suggest instead is MyEMR app, which gets the latest information from each EMR and uploads everything to the next place I visit. Here's the choice:

They look pretty similar, right? There are three unique lines (data paths) connecting my EMR to each of the places I've visited, and there are three unique lines connecting each of the providers (H-C, H-O and C-O).

When the numbers grow, they start looking not quite so equivalent. Let's look at six distinct EMR's. With My EMR, there are just six possible connections:

But if the six have to interchange with each other, we're up to 15 possible connections.

Hmmm. Not a good trend. What about when the number gets bigger? What if 100 EMR's had to talk with each other? How many unique connections (data paths) would there be then? Here it is:

You may say there aren't that many vendors. But getting two different installations of EMR software from the same vendor to talk is still a lot of work! Not to mention the fact that there are many different versions, configurations and customizations of each piece of software. The real number is likely to be much larger!

Conclusion

Just installing an enterprise EMR tends to be an incredibly expensive, years-long disaster. There's a good reason based on simple arithmetic that many years and tens of billions of dollars have yet to achieve any meaningful amount of interchange between EMR's -- there's a combinatorial explosion. The same arithmetic strongly favors the personal EMR approach.

Incentives also favor the personal EMR as the center point of integration. How eager is one hospital CEO to make it real painless for patients to go to the competitor? Patients, on the other hand, are highly incented to want the data in their hands; not only would it save endless hours filling out paperwork and avoiding yet another history interview with its inevitable misinformation, but it's likely to help their providers avoid errors and keep them healthier. Of course, the vendors and systems have a death-grip on patient data, and really don't want to give it to patients, regardless of what they might say. But at least sending data to personal EMR's is a solvable problem without a combinatorial explosion of work to get it done.

I want a personal EMR!

Healthcare Innovation: EMR's and Paper

EMR's are essential. They are going to bring healthcare into the digital age -- finally! Healthcare organizations are spending billions of dollars to implement EMR's, and the government is doing the same.They're preparing the ground for the incredible benefits of Big Data and Cognitive Computing!

There is no doubt that the money is being spent. EMR's are certainly being implemented. Are they working? Eliminating paper? Not so much. One thing they are certainly doing is making doctors spend less time with patients and more time with computer screens.

I could go wild with statistics, but all this got tangible for me when I accompanied a family member to a surgical procedure with a top-flight provider at a first class facility in Manhattan recently.

Here is the notebook of papers that accompanied the patient everywhere:

Some of the papers were computer-generated, but most were not. We spend loads of time fielding questions whose answers had already been entered into various systems -- including the provider's! Various papers whose text had nothing to do with medicine had to be signed -- papers concerning regulators, administrators and lawyers.

I heard the dialog in other booths, with huge amounts of time trying to get information out of the memory of patients and onto paper. Here is a nurse doing her job:

I could see that there were also lots of computers all over the place. Not that it mattered.

It turns out that the medical care was excellent, and the procedure successful. Good news! Would eliminating the paper have made it better? Hard to see. If the medical history had already been available, would it have saved some time? Well, the medical history was all available -- the provider had already gotten everything required and entered it into his own system before agreeing to conduct the procedure! So everything done at the hospital was just a bunch of wasted effort anyway, whether it was on paper or on computer! Could the provider's EMR have transferred the information about the patient to the hospital's EMR for this scheduled procedure? Maybe. But it didn't happen, and we know from government statistics that it rarely does.

Tens of billions of dollars are being spent implementing EMR's so we can experience the wonderful benefits of getting rid of paper. Sounds good, but I suspect that no true science or even engineering has been done here. How do we know things will be better in the gold-plated EMR future? Has anyone done patient outcome studies? How about time utilization studies? Has anyone tried alternatives? After all, EMR's can't possibly be a goal -- who cares about EMR's except EMR vendors? EMR's can only be a means to an end; and the only end worth anything is better patient care at lower cost.

What we know for sure is that we're achieving higher costs by implementing EMR's. We're not eliminating the paper. Too much of the data that ends up in the EMR is crap, and too much is missing or wrong. We're not getting accurate data into a single place. We don't have a clue whether we're making patients healthier as a result; we don't know whether we could make patients healthier by spending the money in a different way. Maybe it's time to apply some fresh thinking here.

I'm computer guy. And a facts kind of person. I know that computers and software can make things better for everyone in medicine. I'm NOT saying we should forget this new-fangled computer thing. I'm saying we could get dramatically better results for a fraction of the money we're spending.

Healthcare Innovation: EMR's and Data Quality

Tens of billions of dollars are being spent to implement EMR's in healthcare. There's still a long way to go. Everyone seems to agree that EMR's will make things better than they were with paper. But it's hard to imagine that things will be better if the data is incomplete, inconsistent, and simply wrong.

The big strategic thinkers and powerful people who push EMR use ignore this issue. I guess it's a detail, beneath them, unworthy of their notice. But for anyone who lives in the world of software, numbers and math, data quality is the foundation on which everything is built. Ever hear of "bad data in, bad data out?" It's true!

I can run some personal tests on this issue because I'm being treated for a kind of cancer at one of the world's best hospitals, Mount Sinai. I'm getting excellent care and doing well. Mount Sinai is completely up to date with EMR's. It's clear from my experience to date that my excellent care has nothing to do with the EMR -- arguably, the good care I'm receiving is in spite of the EMR.

Let's look at some details. I recently waded through the hospital website to access my medical records. If whoever designed the website had tried to make it difficult for patients to access their records, they couldn't have done much better.

I finally managed to get a PDF for an encounter. The document makes clear that the hospital's computer graciously deigned to share information with me, the patient:

The document makes equally clear that information is missing. What information isn't here? We have to guess. What an attitude.

Think of an incredibly unpleasant, arrogant class of professionals. What did you come up with? My guess was lawyer. Even with lawyers, when you fire them and request your files they give them to you, minus snarky notes about how things "may be" missing.

There was a section with my name and address. Also how to communicate with me:

They included the identical number for Home and Mobile. You think the computer could have checked for that? This is one of the fatal flaws of the whole EMR approach: the patient is barred from entering and/or correcting his own data! In a sensible, modern system, I would have received an email or text asking me if this information was correct, and asking me to correct it if it's not. But an Enterprise EMR system with layers of security, bureaucracy, administrators, regulators and lawyers involved? Maybe next century.

Now we get to my meds. Here they are. Notice anything?

You may notice that information is missing from the second drug, losartan. What I noticed is that the dosage is wrong. What I have actually been prescribed is 100 mg tablets. This record is from the encounter with the cardiologist who prescribed the drugs! If it's wrong, anything can be wrong!

In my case, it makes little difference, since I'm on top of things. But not everyone is so fortunate, and this is just the kind of error that could, with a different patient and drug, have awful consequences.

Now let's look at my "social history."

It's wrong too. And I'm not allowed to correct it. If I did use alcohol, it's missing the amounts. But I don't use alcohol. If it were correct, it would be incomplete; but it's incorrect.

Finally, let's look at my plan of care:

An appointment. But that's wrong too! The appointment I actually have is for a diagnostic procedure, not what's written here, and the follow-up with the doctor is just missing.

Bad data wrecks everything

You want benefits from Big Data? Nothing good comes from data that's bad, no matter how big it is.

There is very little data exchange among EMR's, in spite of all the tens of billions of dollars that have been spent. Here is the latest stat from the government:

Do you think that's bad? In principle I think it's bad, until I consider all the inconsistent and incomplete piles of crap data that's sitting out there in EMR's. Then I think of the lack of interchange as being more like keeping the bad data in isolation so it doesn't wreck anything. And who's allowed to fix it? I'm certainly not allowed anywhere near it, even though it's my data.

Conclusion

What's the solution? Make health care providers spend even more time bent over computer screens than they do today, which is already excessive?

The core problem is that our whole approach to hospital, health care and provider automation is rooted in the ancient approach to "enterprise software" that was created in the days of mainframes, and lives on in the incredibly expensive, ponderous and user-hating world of modern healthcare IT. The data will become accurate, complete and high-quality when the systems are built correctly, using modern techniques, and when they interact with all concerned parties -- including patients!! -- to get their jobs done.

Innovation: From Startup to Success

I've recently published a book whose subtitle will soon become the title: "From Startup to Success." It's a tiny voice in the hurricane of books, conferences and attention paid to Innovation. Anyone doing something new that somehow involves computers and software would benefit by paying attention to this book. It identifies success patterns that aren't found elsewhere.

Software-fueled Innovation

We currently benefit from more than 150 year's worth of general-purpose innovation. Trains, planes, cars, phones, refrigerators, prepackaged ice cream, etc. The innovations are now a broad array of products and services offered by major organizations. You go to business school to learn how to run and staff such organizations.

A sizable fraction of today's innovation is built on and using computer hardware and software: the internet, smart phones, Amazon, Google, Facebook, Uber, and a host of others. The new generation of innovation is software-fueled innovation. It's still innovation, but it's different because of the software.

Software makes it different

Airplanes were invented by the Wright brothers, who were experts in bicycles. Anyone could see everything important about the device they built, and even basically understand it. The same holds true for all the innovations up to and including early computers: you could see the card readers, the plugs, and the vacuum tubes. But then things got tough.

Once complex circuits could be built on a chip, you could see the chip, but not the millions of electronic devices on it. Even worse, you can't see the software that may process billions of instructions on the way to getting something done. You can view the "source code" of a piece of software, but how many people can read it with understanding? Software has piled up over the years, so that today, new software is built on the foundation of millions of lines of code that is in older software, the foundation without which the new software could not operate. Even most modern software "experts" have never seen that code that's "under the surface" of what they write. They don't understand it and couldn't write it themselves.

Software is a new world, invisible to the majority of normal people, and only partly visible to the vast majority of people who call themselves programmers. Software is a new world, and startups that are fueled with software have new rules for success. Well, not entirely new rules. But they're different enough that most startups don't understand them. Why?  No one is teaching the rules of success for software-fueled startups -- least of all business schools!

That's why I wrote the book. I don't know all the answers. But I have figured out a bunch of them from twenty years of closely examining software-fueled startups, partly as a programmer, but mostly as a technically-oriented investor.

Applied common sense

Many of the things I point out in the book sound like simple common sense. But it's not common at all. For example, "solve a problem a customer knows he has" sounds like the dumbest of not-needed advice. But in practice, it's one of the least-commonly-followed dicta you can imagine! Here's an excerpt from the book on that subject.

Solve a problem the customer knows he has

This one is so obvious it may sound like a joke; why would a company try to sell a solution to a problem a customer doesn’t know he has? It sounds insane! But it happens over and over again.

People who come up with new things are often pretty smart. They tend to be imaginative, and see past the here-and-now. They can create abstractions easily, and find the commonalities among apparently unrelated things. They’ll see an obstacle or limitation in a business, or a way to make it much better. They’ll put together a way to remove the obstacle, overcome the limitation or implement the enhancement. They will typically be pretty excited about what they’ve accomplished. Then they’ll try to sell it, get frustrated, and before long they’ll be venting about stupid customers who can’t see past their noses, who will refuse an offer to pay a dollar to get five in return and who are otherwise mentally damaged. This is the typical result of solving a problem a customer does not know he has.

The problem and the solution may be clear to you, with your skills and ability, and having walked the path of analysis and understanding that you have. But is it clear to the average customer, without either injecting him with brain-enhancing drugs or putting him through a multi-week education course?

Should you be smarter than your customers? Maybe. But if you are so far "ahead" of them that you insist on selling them a scratching service for an itch they don't feel, maybe you're "too smart," and should get over it.

This is one of the dozens of things that are obvious in theory, but hard to get in practice. The book has lots more.

Common sense that doesn't work

On the other hand, there are some widely accepted practices that are sure-fire ways to fail at a startup. Here are a couple that are described in detail in the book:

• Understand the market. Bad idea. The "market" is what is there today. You're building something new.
• Make your tactics match your strategy. One of the worst commonly-accepted notions. It seems to make sense, but it leads to failure.
  
• Assure that you have a sound strategy. "Strategy" is a time sink that sucks valuable resources away from the effort to win. "Step Theory" (read the book) explains why.
  

Conclusion

I've had an insider's view of hundreds of software-fueled startups over multiple technology cycles. One of the most striking things I've learned is the winners do things the "wrong" way in the eyes of most experts. That's how they win! Of course, it's got to be the right "wrong" way that wins, not just any old wrong way; there are plenty of wrong ways that are losers...

Healthcare Innovation: EMR Procurement is Broken

Computers and software get faster and less expensive at a dramatic rate. Healthcare systems implementing computers and software gets slower and more expensive at a dramatic rate. Why is buying the thing getting so much worse at the same time as the thing being bought is getting so much better?

There is only one explanation: the procurement process used by the large organizations is broken. Badly. It doesn’t need “improvement” or “innovation.” Today's standard procurement system needs to be thrown out. We need to start over.

Improving Computers: Incredibly complex, successful

It's just unbelievable how much better, faster, smaller and cheaper computers get. The rate of improvement is unprecedented in human experience. Nothing comes close.

Even software that used to be unavailable or expensive to buy is free! Think "open source," for example.

Procurement of computers: Basically simple, a worsening mess

Most large organizations are just awful at building, acquiring and implementing computer hardware and software. It's not getting better.

How do these organizations respond to their screw-ups? They look closely at what went wrong, "improve" the process ... and make it even worse.

Back to paper

Organizations really try to make it work. The US Coast Guard, for example, embarked on a project to plan the implementation of a leading EMR in 2010, and committed $14 million just to do some planning. Six years later they cancelled it:

They knew something was really wrong, not just the usual wrong stuff. You know things are tough when they go back to paper:

On the other hand, they can provide all the health services their members need with paper alone! Tells you something about today's EMR's, doesn't it?

New York City's HHC EMR procurement

NYC's public hospital system is big. They're also a pioneer in using EMR's. They've won awards because of it, and gotten $200 million from the feds for achieving full "meaningful use" status with it. They go way beyond just electronic recording; they manage diseases, do screening, and lots of advanced things. See this from a January 2013 HHC press release:

By their own report and by the judgment of important institutions, HHC has this EMR thing nailed!

HHC has bigger problems than EMR. It is in big financial trouble, and it's getting worse. See this report from late 2013:

They've got an industry-leading, award-winning, value-enhancing, WORKING EMR, and huge financial troubles. Sounds like an ideal time to buy a new, system-wide EMR, right??!!

Well, that's what they did. In same early 2013 press release in which they bragged about their wonderful existing EMR, quoted above, they announced they were buying a new one:

A close reading of the press release leaves one wondering why they had to have a new one: the touted wonders of the new system line up pretty well with the wonders of their award-winning existing system. I guess they really hankered after that new-EMR smell. And with the big award from the feds, $200M of the $302M is already paid for, leaving just pocket change to pay for it!

But then, less than a month after this press release, HHC issued an RFP for extensive additional services. Here is a list of the consultant skills they wanted to hire:

Strange. I got the distinct impression from reading the press release about getting Epic that the $302 million covered everything. What's this about?

The July 2015 board meeting of HHC had an update on how things were going. Things weren't working out too well on the cost side; those numbers are millions, by the way:

Wow. Just a bit more that $302 million. Digging a little further in the Board minutes, we find a little about the $113 Million. Here's the summary:

Or maybe not -- this $119 million is for consultants, not FTE's, and it's per year -- the surprise on-going cost of getting that shiny-new-EMR-system smell into the hospital! And you have to notice that 20 vendors will be awarded contracts -- because everyone knows that having lots of temporary people from lots of vendors working on a single project is the proven way to maximize coordination and minimize surprises. Sure.

Oh well, at least things are "under control." Or maybe not. Just a month later, in August 2015 we learned:

And the dates? Let's talk about something else, because "full operation by 2017 for all users" is history, along with the $302 million cost and lots of other things for this troubled system.

Conclusion

HHC is a nice, big, fat example -- but it's not unusual. This is what EMR procurement is like, over and over again. The buyers just keep shuffling ahead to the painful and prolonged slaughter, like cattle. Few organizations are as smart as the US Coast Guard, and decide that paper is just fine. Big-organization procurement in general is broken, and EMR procurement in particular is badly broken. Every attempt to "fix" it seems to make it worse. The procurement process needs to be thrown out. We need to start over.

But start over with what? I will summarize how in forthcoming posts. But it's not mysterious. It's just an application of the proven methods described in my books and summarized in various posts on this blog.

Healthcare Innovation: Can Big Data and Cognitive Computing Deliver It?

Most people seem to agree that healthcare is ripe for innovation, and badly needs it. Lots of people are talking up two potential sources for that innovation: Big Data and Cognitive Computing.

I'm strongly in favor of data, the bigger the better. But is the Big Data movement going to make a difference? I'm strongly in favor of cognition, computing, and computing that is smarter rather than dumber. But is the Cognitive Computing movement likely to make a difference? Here's a summary of some thoughts.

Process Automation and continuous improvement

Here is a description of the core process automation process implemented by a company I've invested in, Candescent Health. It describes the process that can and should be applied to all of health care.

The point isn’t that there’s data and analytics – the point is that there’s a closed-loop process of continuous improvement where actions are based on rules. This is the framework that is required to make anything happen. Without it, you can’t put your proposed new clinical action into practice with double-blind A-B test and see if the results of your analytics actually deliver benefits in the real world! Or even just deploy it!

How about just making the basics work?

Here is the story illustrated by Mt Sinai hospital about how everyone focuses on “innovation” and fancy new things, when just having the computer systems run reliability has a huge impact on patients – and unless those systems run, the results of fancy new analytics can’t be delivered to benefit patients.

If the car won't start or run reliably, who cares how good the fancy sound and navigation systems are?

How about making the computers work?

I love data and analytics. But doesn’t it make sense to focus on getting the operational computer systems to actually run well before moving on to the fancy stuff?

Paying top dollar for computers doesn't make them work

In fact, just about anything you do with healthcare data that is going to be brought to the front line of care requires functioning computer systems to be able to pull off – the big healthcare systems pay Greenwich CT prices and get trailer park results.

Clean data isn't easy to get

Both data warehousing and the fancy new Big Data movement share the under-appreciated problem of getting good quality data in analytics-ready form. Sounds simple, but the difficulties make progress a grinding crawl on many efforts. See this for example.

Big data sets tend to have Big problems

Massive data sets have built-in problems that make it hard to get actionable results.

AI: How about under-promise and over-deliver for a change?

Skepticism about Cognitive Computing in health care is warranted. There is a rich history of over-promise and under-deliver for AI efforts in general.

Real-world solutions waiting to be automated

Meanwhile, there are proven gems in the medical literature just waiting to be disseminated to the front lines of health care via point-of-care computer systems that are languishing in journals.

What can make a difference?

There are lots of practical, tangible ways to make things better, in spite of all the obstacles to change pervading our healthcare system. Here are some examples of people doing the right thing, all them with investments by Oak HC/FT:

• Candescent delivers better imaging results with less expense by applying basic continuous-improvement workflow automation.
• VillageMD delivers better results with lower cost by feeding back results and advice to PCP’s.
• Aspire delivers better results at lower cost for end of life – by having one person be in charge, managing everything from the patient point of view.
• Quartet makes a difference by applying behavior health as needed to help other conditions.

These companies embody some common themes:

• Knock down the silos, have a patient-experience-centric point of view.
• Applying common sense has huge benefits.
• Focus on delivering results to the front line (patient) is hard but necessary.
• A system of continuous learning and delivery is a pre-condition to delivering any results of analytics for patient benefit.

Conclusion

The big hot topics in healthcare of Big Data and Cognitive Computing are little more than fashion statements. Data, of course, is a good thing; so is having computers do smart things. But without doing some basic blocking-and-tackling and applying some practical common sense, a great deal of time, money and energy will be spent accomplishing nothing.

Innovation: Some History

"Innovation" is an innovation -- it's a new thing that loads of people think it's important and something we should pay attention to. The Chief Innovation Officer is the most recent addition to the CxO suite.

Someone other than me should write a history of "innovation," fully explaining how we got to where we are with it. I've contributed two or maybe even three cents to the effort. I'd like to go back a century or so and explore some of the fertile soil out of which modern "innovation" grew.

What is Innovation?

Just last year, you could have spent a whole week learning about innovation from the best and brightest:

During that week, here's some of what you would have learned:

See what you missed? Not just regular innovation, but "game-changing" innovation; innovation that "generates new ideas" and "executes new solutions." Hadn't thought of that before: innovation can "execute" solutions, and "new" solutions, at that! This Innovation appears to be an "essential skill" of leaders who have the "desire to transform organizational processes and behaviors." Wow.

This is big. What's the core idea? It appears to be coming up with "new ideas" and acting on them.

The roots of Innovation

People have been doing new stuff for a while now. Make a list of the things that have been invented in the last two hundred years, and when your hand gets sore from writing, let me know. However strong your hand, you're likely to run out of strength long before you run out of things to add to your list.

So why do we need to beat the drum and add yet more to the overhead with CIO's and the rest?

The reason is simple:

1. People resist change
2. Organizations resist change
3. Big organizations resist change in a BIG way.

We've been through this. It's a well-understood idea, thoroughly grounded in human psychology. It's not just that psychologically, people resist change. It's that they are highly incentivized, even rewarded, for resisting change. If that sounds strange, you should check out books like the Innovator's Dilemma.

We can learn a couple important things from organizations that were terrifically innovative at the start:

1. They were started by unusual, driven people, often education drop-outs, who never took a single course or seminar in innovation, much less business education. See this and this.
   
2. Once those amazing organizations grew to become leaders in their field, they almost always stop innovating! But they know they need it, so they acquire what they can't create. See this.
   

Large companies figured this out a long time ago.

Here's an attempt at H.J. Heinz around 1909 to solve the problem:

Yes, it's a suggestion box.

Why have a suggestion box? It's anonymous! The person who has the feedback or the great idea can make it without fear of punishment or retribution. That's absurd, perhaps you say! Why would anyone in authority punish someone who makes a suggestion for improvement? Try it sometime. Just make sure that your suggestion goes against the "common wisdom" at your organization.You'll see.

The impulse to foster what is now called innovation has been around for a long time. It's a bubble phenomenon now, but some form of it has been bubbling along for centuries. "Change," like motherhood, is judged to be a good thing, unless and until it's you who have to change, and the change isn't in your favor. That's why real change mostly comes from upstart people who create upstart organizations.

Conclusion

The well-intended suggestion box of past centuries was an attempt to solve a deep-seated issue with people and organizations. It has morphed into the modern innovation movement. You can expect results that are every bit as stunning as those well-known new things that came from pieces of paper stuffed into suggestion boxes. If you still insist on change that works, see this.

 

Organizing for Successful Innovation: Recent History

One of today's hottest trends is fostering innovation. It's real important! There are books, conferences, certified experts and all sorts of things. Let's do two things: (1) look at the origins of today's acknowledged tech leaders; and (2) see how those tech leaders innovate today.

The origins of today's tech leaders

What would we find if we looked at the origins of some important organizations that took the market by storm, grew rapidly and became part of the modern landscape? Did they come from people following the popular methods for fostering innovation? Let's look at some big, successful tech companies, and find out how they got started. There are two possibilities:

1. It came out of some large organization that followed modern innovation methods. Or its founders were avid readers of books on innovation, certified innovation trainers, attendees of innovation conferences, or otherwise showed that they were nurtured by innovation thinking.
2. It was started by one or two people who set out on a mission without any of #1 and kept marching forward until they got it done, perhaps with the help of VC's (venture capitalists).

I've already discussed the cases of Microsoft, Facebook and Oracle here. Their founders not only lacked training in "innovation," they were all college drop-outs!  How could they have possibly founded three of the largest, most successful and valuable tech organizations? Must have been luck, I guess.

Maybe they're the exceptions! Maybe most of the rest fit comfortably into the mold of #1! Let's look at a few:

• Apple. Jobs and Wozniak. College drop-outs.
• Amazon. Bezos. Princeton grad, worked in finance, hedge funds. Jumped on a vision.
• Dell. Michael Dell. Started in his dorm room, dropped out.
• Google. Stanford grad students, dropped out. VC backing.

Why all the college drop-outs? In each case, a founder who was already obsessively good at something saw a related opportunity (sometimes with a buddy), dove in to make sure he didn't miss the opportunity, and made it more important than anything else. Including "education."

A pattern seems to be emerging here. It's not looking good for theory #1.

How today's tech leaders foster innovation

Now that these companies are big and successful, surely they are great at innovation, right? They must have certified innovation experts just crawling the halls, and a good fraction of the staff out attending innovation conferences, right? They must be just cranking out innovations left and right!

They try, in various ways. But it turns out that these great companies aren't any better than any other large organization at innovating -- and you can see it by all the acquisitions they do! They have HUGE resources -- how could some scrappy bunch of nobodies possibly come up with something they couldn't invent themselves?

Well it happens. It's happening right now, in AI. Look at who's doing the acquiring:

Facebook alone has made more than 50 acquisitions, most of them since 2010.

How about Google, who are supposed to be the smartest and most innovative of all? They've acquired more than 180 companies. Someone figured out the ten most expensive buys:

And the grand total is ...

Now, that's innovation for you. Just ask your boss for a multi-billion dollar budget, and you'll be able to innovate like Google!

Until then, remember, there really is a better way to approach making your company better, even if it is unlikely to win any awards for "innovation."

The Innovation Bubble

We're in the middle of an innovation bubble. "Innovation" is hot. Innovation "experts" are coming out of the woodwork. Everyone wants some innovation. If you're not "fostering innovation" you're hopelessly outdated.

Some people say you need teams for innovation to take place. As a responsible manager, it's your job to foster innovation in your teams. Here's one of the books you can read about how to do it:

"Leadership" is a timeless favorite. Naturally, if you're an excellent leader, part of what you do is make innovation happen. Here's one of the books you can read about it:

Maybe you're not a big reader, but want to make sure innovation happens anyway. You can go to conferences, world-wide ones even:

What if you really want to get serious about innovation; how do you do it, after all? The good news is, it's not at all mysterious! You can go to school and learn all about innovation:

If you're an executive, you can take some time off and learn about it too.

Maybe you're having trouble breaking through. It could be that the missing ingredient is certification. Hmm, let's Google it, and see if any places can help out:

After all, you can say you're a great innovator, but without an official certification, why should anyone believe you?

Lots of people are doing it, even people with MBA's:

If you're really good, maybe you can become a CIO -- no, not a chief Information officer, a chief INNOVATION officer. And then, if you're really good, maybe you can attend a round table:

What if you want help fostering innovation inside your organization? There are prestigious places just waiting to help you out -- it's their business, and you may not be doing it the right way:

It's probably too late, but it would be a shame not to at least try to catch up with this innovation thing. An awful lot of people seem to think it's the best thing ever.

Of course, there are a few lonely voices saying this innovation thing is just a fad. They seem to say that if you want real innovation, there is a simple way to get it. They're probably just whiners who ignore the experts, and don't want to take the trouble to read a book, attend a conference or get certified. Too bad for them.

 

Fintech Innovation: the Drivers

What are the underlying principles driving innovation in Fintech? The same, identical, unchanged principles that drive innovation of tech in general. Nothing new! It's just applied to Fin.

We all know what those principles are. We've become used to them as wave after wave of improvement washes over the devices and services we use every day. In normal, physical things the changes are dramatic, going from literally using horse-power:

To steam-powered engines on rails:

To jet-powered planes that fly us in the sky:

Compared to last year, things get: faster, cheaper and better. That's it!

But when electronics and software are involved, as they are in most of fintech, the rate of change is even greater. That's why most of the disruptive changes we see in fintech are little more than fintech catching up with other sectors that have pioneered and are already using the technology. Like for example, "gee, people seem to like their smartphones. There are an awful lot of them out there. Maybe we could figure out a way to put the tech in fintech; maybe build an app or something?!"

What this amounts to is simple in principle, though often challenging in practice.

So how does faster, cheaper, smaller/better underlie innovation in fintech? The main ways include:

Replace physical objects large and small with digital

This reduces cost and speeds things up.

Devices instead of places

Don't go to a place (which is expensive to build/buy, maintain and staff), use your computing device. Call up the specific banking-like function you want on your device, and get your job done, right now. Consumers prefer it because it eliminates travel time, wait time and hassle. For example, money transfer with Abra:

Replace people with data and algorithms

This reduces cost and speeds things up. Consumers prefer it for the same reason they'll use an ATM even when human tellers are available. Don't make an appointment, get dressed up and see the loan officer at the bank; enter your data in the loan app and get an immediate decision with immediate access to the money. For example:

Summary:

• Use the device you have to get the job done.
• Eliminate the man in the middle; no people.
• Digital beginning, middle and end.

Result: faster, cheaper, better!

 

Healthcare: Problems and Opportunities

The US medical system is the best in the world, by the simple measure of patients voting with their feet. How many US patients flee the US so they can enjoy the superior medical care in other countries? How many foreign patients come to the US in order to benefit from the superior medical care available here? This simple measure allows you to cut through the rhetoric and find the truth: instead of listening to what people say, watch what they do.

The US medical system would also benefit from radical change. It is not nearly as good as it could be. It’s not lacking new ideas, or more of the currently fashionable “innovation;” it needs to apply methods, systems and technology that are proven in wide-spread application in non-medical applications, suitably adapted for medical use.

I’ve already hit on a couple of juicy subjects in this blog. But they only scratch the surface. Here are some of the things I’m thinking about and will be blogging about.

Financial technology and healthcare technology

Both are heavily burdened by giant organizations, heavy regulation, ancient and expensive IT, and deep resistance to anything but surface change. But fintech is in a renaissance of game-changing innovation, while healthcare is a laggard by comparison. What’s this about? One simple example: in finance, when I applied for credit 30 years ago, I went to the bank and was subjected to an interview by a bank officer, who personally determined my credit-worthiness; today, complete automation yields better results with less time and cost. In healthcare, when I have disease symptoms, I go to a doctor who makes a diagnosis and recommends a treatment. It was the same 30 years ago, only now there's much more overhead typing stuff into computer systems, mostly for the benefit of various bureaucracies.

Drug discovery

In drug discovery, there is a huge gap between what we are capable of and what we let ourselves accomplish. As usual, regulations and bureaucracy impose expensive and outmoded barriers, resulting in widespread preventable deaths.

Innovation and best practices

There is a natural tension between assuring that patients are treated according to best practices, while allowing for innovation and expert adaptation. Our methods for resolving this tension are sadly deficient compared to non-medical fields.

Bad science

You would think that as a science-created and science-dominated field, there would be only the best science in medicine. Sadly, this is not the case. There is shockingly bad science at both the detail level and the global level.

Training and credentials

Healthcare is filled with extensive training requirements, certifications and tests. These are accepted as part of life in the field. Some of the credential requirements are well-intentioned -- but others are little but thin veneers of good intentions on top of a pile of self-dealing, and often make things worse for patients.This is best seen by comparison to other countries and other fields.

IT

The level of IT implemented at an average e-commerce website is, in general, vastly superior to the IT implemented at the very best medical institutions. On multiple dimensions, including cost, effectiveness, quality, and level of automation. If done well, excellent IT could be the foundation of a revolutionary wave of excellence in healthcare delivery and continuous innovation.

Conclusion and disclosure

I’ll be addressing these issues and more in future posts on this blog. But I’d like to emphasize: I’m taking the trouble to write this stuff down and make it available because it’s what I really think. I’m proud to be part of a partnership which invests in and supports leading-edge groups that are trying to change healthcare for the better, and I may refer to such companies in the future as I already have. But these posts and thoughts are promotional only in the sense that they promote concepts and practices that would raise the game in healthcare for everyone concerned.

Fundamental Innovations in Software

As a result of the decades I have spent working on, in and around computers, I have learned many things from other people, from books and talks, from studying the results of other peoples' work, from trying to accomplish many things in various ways myself, and from following the course of many projects and products over time. During this period of time, the computer industry has changed dramatically in many ways, and not much in some ways.

Most of the knowledge and insight I have gained from this effort over time match well with those of the industry as a whole. However, there are major subject areas which I have observed don't get much attention, or need major innovation. Here are some of those areas.

Quality

A good deal of attention has been paid to the quality that results from software development efforts. Products have been built to automate various aspects of the quality process, and there are techniques frequently incorporated into the software development process intended to assure good quality results.

However, it is clear that there is a tremendous opportunity to enhance the quality process. There are conceptual and technical advances that can be applied to the quality process that greatly improve the results of software development and reduce the time and effort to attain those results. While it is likely that there are situations to which the optimal techniques do not apply in part or in full, it appears that they are applicable to most software development projects.

Optimal results

There are a few areas in computers where people focus on measures of goodness and generally agree on what those measures are, for example, total cost of ownership. But the concept of the best possible result in theory, comparable to Shannon’s result in communications, is rarely applied in computing. Yet, there are a number of areas where it is applicable and useful.

Similarly, in computer hardware, people frequently reach a consensus concerning the “best” way to implement a certain feature, whereas in software development tools and processes, the thoughts about the optimal way of doing things evolve slowly, but rarely reach resolution. Moving beyond advocacy and thinking about what is truly optimal and how to attain it is very fruitful.

History

Software development is a field that pays remarkably little attention to history; everything is now and the next best thing. But in fact, a study of history in this field is very rewarding, because just like in real history, you find that some thing truly change, some of them extremely slowly and a few rapidly; and that other things go through recurring cycles. Knowledge of this history is interesting in and of itself, just like “real” history, and also enables you to predict the future within reasonable limits by extrapolating the patterns.

Application and systems software

If you look at every line of code that is executed in order to run a program, the lines fall into various categories, including systems software, standard libraries and applications. The “line” between these has been moving “up” very slowly over the last few decades. This glacial trend has impacts on operating systems, databases, application development tools, and related subjects. Understanding and exploiting this trend is a target-rich environment for innovation.

Abstraction levels

When we notice things repeating in computing, we build a level of abstraction to encapsulate the repetition and then work at the level of abstraction. Each abstraction is something that has to be built, adopted and learned, and because of these obstacles (and in spite of the benefits), abstractions propagate slowly. Some are so hard for most people, like those involving real math, that they can only be used by hiding the complications from practically everyone. Exploiting abstractions can lead to huge advances.

Closed loop systems

The concept of running an automation system “open loop” vs. “closed loop” is widely understood. But I find that few computer systems are run closed loop. Even though this is not exactly a novel concept, most people who work on building or operating the systems seem to be unfamiliar with it.

Workflow systems

The concept of workflow has been around for many years, and many systems have been built that embody the concepts. However, most people that I encounter seem not to understand the abstraction, and no good tools have appeared to ease the path to implementation.

Application Building Methods

The biggest, fattest target of all is the project management style of organizing and managing software projects. I have written a long book dissecting the theory and practice of applying otherwise reasonable project management techniques to software, and another one outlining the alternative approach. The larger the organization, the more likely software is going to be built the bad way. When software is built quickly and well, it is most often built in smaller organizations that are working under some kind of severe constraint. And of course, there are people here and there who simply have figured out better ways of building software, and just do it.

Understanding the People

Athletes are special people -- they're people like everyone else, but the outstanding ones are different in important ways. To encourage them to do their best, you have to understand those differences and act in appropriate ways. Same thing for software. HR people, general managers and everyone else applies the same template to software people they apply to everyone else. They emphasize the commonality and ignore the differences. This is why, in general, management of software people is inexcusably bad. I've written a book about this.

Summary

Each of the subjects mentioned here could be a book; some of them are the basis of whole innovative companies. They're not just theoretical. Exploiting some of these subject areas can lead to rapid tactical execution benefits in organizations that build or use software.

An App to Prevent Train Crashes like Amtrak Philadelphia

Innocent people taking a train are dead. Many are injured. The government had an answer in 2008: spend billions of dollars and wait for years. There's a better answer: Build a smartphone app, with some cloud software, a couple sensors and cameras, and engine cab remote-control harness. It would be faster, cheaper and more effective than the existing partly implemented "solution," and lives would be saved.

The Crash

Here's the story of the crash in a nutshell:

Eight people were killed, and 43 still hospitalized days later.

Reactions to the Crash

The basic reaction has been typical all-politics-all-the-time. Here's the Reuters story:

Later in the same story, you learn that the engineer was driving at more than twice the speed limit for that part of the track, and that the accident would not have happened except for his error. But that's a detail, I guess.

Technology Could Have Prevented the Crash!

Then it turns out, we know how to prevent things like this! But according to the experts, it just hadn't been installed.

This PTC ("positive train control") sounds like wonderful stuff. It turns out it's been around for awhile. Everyone seems to agree that it would go a long way to solving the problem of crashes like the Philadelphia one. So what's gone wrong?

Government-Mandated Positive Train Control

Here's a good summary of the issues and problems of the wondrous PTC solution, which was mandated by Congress in 2008. It was declared by Congress that it must be completed by the end of 2015. It won't be. And the cost? The GAO estimated somewhere between $6.7 billion and $22.5 billion.

A brand-new system dreamed up by government bureaucrats in a short period of time -- of course it takes billions of dollars and many years to implement! Of course it's a completely custom system, relying on railroad-only technology that will be generations behind the general computer industry before it's even deployed! Of course everyone assumes you can spec out a never-built-before system and get it right the first time!

This is amateur-hour technology, and it is ... killing! those of us unfortunate enough to be in the wrong place at the wrong time. This is a near-perfect example of bureaucratic "innovation." It is an example of the "what not how" problem of regulation: what should happen is simple declarations of goals (don't murder people) instead of gruesomely detailed directions for how to avoid murdering people. The bureaucratic approach mandated by Congress has already resulted in incredible expense and multiple avoidable deaths, just as its similar approach to computer security has resulted in some of the worst security breaches in history.

The Modern Approach

There is a better way. It leverages modern computing, devices, networks and software. "Experts" will pooh-pooh the approach, saying that anyone who proposes it doesn't understand the harsh and peculiar railroad environment. That's what experts always say in situations like this, standing on their little technology island, protecting their "expertise" and their jobs, until modern, high-volume technology gets the job done. Then, without further comment, they retire.

I won't lay out the whole approach in this post; this blog has lots of the core ideas, and so do lots of modern computing technology people.

Just as mapping software on a phone can track your location and speed when you're in a car, it can do it when you're on a train. Why shouldn't lots of people have this app? Why not publish the complete map of all the train tracks? Most of it already seems to be available to consumer mapping programs -- they just need to be tweaked to allow travel on rails instead of on roads. Yes, there are areas where track maintenance is taking place where trains shouldn't go -- just like with roads! Mapping software already exists to avoid such routes -- just use it! Yes, there are switches -- how about adding them to the maps, and making whatever controls them upload their state to the cloud? Yes, there are other trains to be avoided -- how about the apps all upload their positions to the cloud, and give a view to where other trains are? Yes, there are things you should pay attention to when you're not looking at the app -- navigation apps already handle this through audible alerts or talking to you.

These simple steps, which could be built iteratively and deployed in weekly cycles, would go a long way to solving the problem. There remains the problem of overriding the train controls in case something terrible happens -- but if all the conductors have the app and they have access to the engine car, many of the potential bad things could be avoided. The potentially tricky issue of automated speed control could then be addressed -- but after all, airplanes are largely run by auto-pilot, why shouldn't trains? If auto-pilot works for vehicles that go hundreds of miles per hour, miles in the air with no tracks, surely it can't be too hard to make a version for relatively slow vehicles without steering controls, whose only variable is speed!

While the government is mandating and regulating, billions of dollars are being wasted building systems that will be obsolete before they're installed, and meanwhile people are being killed and injured. There is a better, faster, cheaper way. Its cost to build is likely to be much less than the cost to simply maintain the PTS. So let's do it!

 

Innovation Made Simple

There is lots of noise about “innovation” and its importance. Not only are there books, articles and conferences, large organizations increasingly employ Chief Innovation Officers to make sure innovation really does take place – otherwise, it might not, and what a horror that would be!

Innovation seems to be a big, important, mysterious thing that isn’t one bit obvious. Lots of people have to get together to figure out this grand new thing. Here’s a typical example:

I must be missing something. I agree that making things better is real important, and I’m happy to call that “innovation.” But it appears to me that, in most cases, the innovation that most of the people served by an organization would value most highly is simple and obvious.

For example, in football, people focus on all sorts of fancy things. But what wins most games most of the time? Getting real good at blocking and tackling.

In most non-sports organizations, doing the equivalent of blocking and tackling makes things better. Since most organizations use computers a fair amount, the process is simple:

1. People should do their jobs. Completely. Correctly. On time.
2. Computers should help people do their jobs, and monitor whether they’ve done them correctly.
3. Computers should do things that people used to do.

No magic, no mystery, no focus groups required. It’s simple: Do it right! Then computer-enhance it! Finally, automate the human element! If this bothers you in any way, ask yourself whether you’d prefer to wait until the bank is open, walk into it, wait in line for a teller and get your money – or whether you’d just as soon walk or drive up to an ATM any time you please and get your money from a machine. Hmmmm.

Big Fat Personal Example of the need for simple Innovation

I had an appointment to see a doctor at one of the top hospitals in the US: Mount Sinai in NYC. Lest you think this was a no-big-deal appointment, let me just say I’m taking a drug that can have really bad (but hidden) side effects, and this was to check on how I’m doing. I wasn’t feeling casual about it.

I had written confirmation of the appointment, an on-line reminder of the appointment, and a robo-call reminder of the appointment the day before. Efficient! So I took the couple hours required to get to the hospital in plenty of time. The place where I usually sign in had my appointment in their system, but told me to go to another desk. They also had my appointment, but told me that unfortunately, my doctor was on vacation. They were polite, but the doctor wasn’t there, so the appointment wasn’t going to happen.

Assuring the innocent person giving me the bad news that I wasn’t mad, I asked what he would recommend as the best thing I could do to rattle someone’s cage about this unfortunate event. He got a supervisor to come out. The supervisor apologized and explained that a lady who’s out today was supposed to call me, but obviously didn’t. She’s sorry. Can she pay for my parking or something? Since I know Mount Sinai uses Epic, I asked whether she could get an alert put in to catch cases like this. She acted like she thought it was a good idea. But given how IT works at places like this, I’m not holding my breath. And there were actually two problems: the robo-call should have been cancelled, and a call to re-schedule me should have taken place. Not to mention e-mails, etc.

Mount Sinai’s medicine and doctors are among the best anywhere. But the hospital’s blocking and tackling is abysmal. The day before I was scheduled for an MRI they called to say my appointment was cancelled because they had no pre-authorization. Personal appeals to hold the appointment, followed by frantic phone calls, uncovered than Mt. Sinai has a whole department that does pre-auth’s. My doctor had placed the order correctly, but the pre-auth didn’t happen. My doctor’s assistant said it happens all the time, and is tired of catching the blame for it. It took a couple hours of phone time to get me the go-ahead.

Mt. Sinai thinks all sorts of things are important and worth spending money on. They have big TV’s blaring away in waiting rooms. They have iPad’s available to patients to amuse themselves while waiting. They have signs announcing how great they are marching down many NYC streets. They have classes on meditation and all sorts of activities directed at Arabic-reading people of the Islamic persuasion, judging from displays in the waiting rooms. All of these things are apparently more worthy of attention than blocking-and-tackling for boring, trivial things like appointments and pre-authorizations. And, sadly, I have lots more similar examples.

Mount Sinai hospital and Innovation

Mount Sinai has made its position on innovation clear: they’re for it. They have a whole department in charge of it. They have hosted at least one conference on innovation featuring all sorts of important people. They tout their innovative computer technology, including Epic. I neither dispute nor disparage any of this. But it’s kind of like a surgeon who does genuinely wonderful surgery, but disdains to wash his hands or double-check whether he’s operating on the right thing. They have indeed purchased and installed one of the most advanced, complex EMR systems – but they fail to get it to do the most basic things. And my personal experience is the tip of an iceberg. The waste and inefficiency within the hospital that I have observed that results from failing to pay attention to simple things like scheduling is simply monstrous.

I can’t resist giving just one juicy example. Where I check in, there is a whole line of check-in people who have to enter lots of stuff into the computer while you sit there. I noticed a little speaker on the wall that would sometimes make discrete little sounds. There was no one waiting behind me, so I asked the operator about it. It turns out that the speaker was installed some time ago and everyone like her trained to listen, because it tells you when it’s safe to hit submit on a new entry. The computer is so overloaded most of the time that unless you wait for the “it’s OK” audible signal, all your work will be thrown away and you have to start over.

As a life-long computer geek, my jaw didn’t just hit the floor; it blasted through it and was finally halted in its downward descent when it hit the bedrock under the island of Manhattan. I think I’m still working on putting it back. I’m so blown away I have no words – even sarcasm, my go-to mode, escapes me. Enough said.

Innovation made simple

I like cool new stuff. There should be more of it. It should even work.

But if you’re willing to pay attention to what actually matters, even though it may be pedestrian and boring, you can make a huge impact at nearly any organization without the benefit of a single conference, book or hi-falutin consultant. You can “innovate” by doing the equivalent of blocking and tackling, i.e., taking care of basics. In other words: Make sure every job is done, and everyone does his job. Then assist and enhance them with computers. Then, to the extent you can, replace human labor with full automation, including calling for human attention only when it’s needed. These simple steps are frequently and painfully not done; if they were done, surprising amounts of money and time would be freed for doing the complicated “cool” stuff that most people call “innovation.”