No program is an island

I want to take a moment and effectively apologize for the fact that this is quite a technical blog post. I think it is a very important topic because it speaks to the way in which medical software is now being designed. CEOs and CFOs need to understand these principles. Otherwise they will not understand why the IT department is desperate to make major changes in existing systems.

There was a time when most software was designed in a monolithic manner. Developers within a company, or developers for a services company, would create large packages of code that incorporated the majority of utilities required. If the software needed to be able to send emails, or make phone calls,  these were designed as components of the system. While it is true that the general principles behind such components were standard, the way in which the code was written and implemented was quite different from monolithic system to monolithic system.

The benefit to such a development approach is that you have control over all of the parts of your system. If for whatever reason, you suddenly wish to  change the way in which emails are sent, you can make any type of change needed. With this approach, the developers have full control of the way in which the software runs.

As in most things in life, for every positive there is a negative. The downside to such a system is that it tends to be far more complex than desired. For example, if a company designs accounting software, their focus should be on  accounting. It truly seems inappropriate for the developers to spend any significant amount of time writing and debugging software that sends out emails. Also, monolithic systems tend to be developed in a more haphazard way, not necessarily holding to certain principles of clean and reproducible software writing, as is standard today. That means that when a problem occurs, it could take a great deal of time to unravel the “spaghetti” of code that makes up the system.

The worst-case scenario is when the lead person on such monolithic projects leaves. Sometimes this individual is fired, or retired or even dies. When talking about systems that were developed decades ago, it was quite common for the lead designers to have moved or even passed on. For the “new guy” who is not intimately familiar with such monolithic systems, debugging them can be a horror, if not impossible. In cases where the systems need to be updated, it is at times easier to rewrite a whole section of the system, rather than try to modify existing code (and accidentally add who-knows-what number of bugs).

These days, compartmentalized software design is very much the universal approach. Also, many units of functionality exist as totally separate services, that can be plugged into one of the compartments. So, imagine once again that a company is developing an accounting system. It may be that the reports section of the accounting system is totally self encased such that changes can be made to it without affecting any other compartments of the system. If a user wants to be able to print a certain report while scanning customers, then the way this would be done is by programmatically requesting  the report from the customer system. In this way, there would not be any of the actual software that generates the report, sitting in the customer section of the system.

For things like logging-in and sending SMSes, compartmentalized software would tend to make use of external packages whose entire focus is designing top level systems for user security and communications. The accounting company would pay to use these external packages. But the time and cost savings of not having to design all of this non-accounting software would be huge.

Another resource that our accounting system might require is standardized packages of data that may be available from other companies or even the government. For example, the accounting company would need to know the tax laws. Such information could be imported from another company that specializes in computerizing tax law so that companies like our accounting firm, can just search the tax law data. Such a resource would spare our accounting company from having to manually review the tax law. Once again, the time and cost savings can be tremendous.

But, as I said above, for every positive there is a negative. This is getting to be very Zen, I know.

When a system is dependent on an external resource, what happens if that resource “dries up”? Hopefully, there is an equivalent resource from a competitor. But the software would need to be updated in order to make use of this alternate resource. If our accounting system has not been sufficiently compartmentalized, it could be that switching resources would require a tremendous amount of software rewriting. That is why when compartmentalizing code, it is so important to hide away references to external resources behind aliases. So, if our accounting company has to switch to a different source for tax law, it should only require rewriting a small portion of this system, that acts as a liaison between the external tax law resource and the internals of the accounting system.

The issue of changes in major resources is very real. A recent article discusses a major change that Google is making. What is significant about this change is that it will probably affect millions of businesses (and not for the better). Google is a private company and is very much not a democracy. Therefore, people whose livelihood depends on Google, and interestingly enough, who support Google by using Google services, still have no say in such major changes.

Very recently, Twitter did something similar when it changed its policy about how its data can be used by outside companies. Many businesses depend on the Twitter-verse for critical information that is not available otherwise. Once again, companies must live with a reality that their foundation can vanish from one day to the next.

Strictly speaking, this not any different than many other challenges that businesses face, such as when government regulations change or a new major competitor opens its doors across the virtual street. This reinforces the need to create a software system that is as flexible as possible. Ideally, a system should be so flexible such that almost any external services/data flow can easily be switched out for another. So, if Twitter cuts off its feed, hopefully, the same kind of data can be found elsewhere. Then, the developers can make limited internal updates to their software and be ready to start working again very quickly.

I purposely kept referring to an accounting firm rather than a medical service, in order to make the point that all of these principles of software design are universal. In the case of an electronic medical record, the kinds of external resources that might be used would be a list of medications from the FDA, or alerts about high risk infectious disease cases and their locations from the CDC. These days there are a tremendous number of resources that can be plugged into medical software. Of course, the medical software has to be able to incorporate these external resources.

The major EMR companies are making major modifications to their systems so that they should be far more flexible than they are now. This is not a small thing. In fact, it is effectively a revolution in the mindset of the developers of the major EMRs. The hope is that this new mindset and approach will make medical software far more nimble and far more powerful with many fewer bugs that can be quickly fixed.

Thanks for listening