One of the most important decisions that must be made when designing a new system is what elements will be implemented internally and which will remain external. Decisions of this type are common and familiar to everyone. Do you buy a Swiss Army knife or separate knife, fork, spoon, screwdriver, etc?
For more on this topic, see last week's blog post.
One of the most important decisions that must be made when designing a new system is what elements will be implemented internally and which will remain external. Decisions of this type are common and familiar to everyone. Do you buy a Swiss Army knife or separate knife, fork, spoon, screwdriver, etc? Do you build a house with one or two stories?
Each of these decisions, once made, is hard to reverse. Each influences, and in many cases determines, the course of events for years to come. Factors beyond our control may force us to choose one alternative.
Due to personality or inclination, many healthcare managers favor "Swiss Armyknife style" all-encompassing (call them monolithic) systems. This is convenient because systems of this type are precisely what is available for purchase. The upside is that there is only one (albeit large) bill to pay and one vendor to blame when things go wrong. The downside is that the responsibility for making the difficult decisions about how the pieces of the organization function and interdigitate is shifted to the vendor. What each department can (or must) do and how they do it is defined to a large extent by the vendor, not the management.
IT products and systems that are being designed today are rarely monolithic. The current trend in technology is for modular, distributed systems utilizing cloud storage, web services and the utilization of specialized and externally provided services (SaaS - software as a service). Why haven't EHRs changed to take advantage of these advances in technology? Because just like building a one-story house, they are based on design decisions that were made near the dawn of time and which appear to be difficult or impossible to reverse.
Starting in the 1960s, computers had matured to the point where attempts began to develop medical applications. Any and all applications ran on the same computer, not because of a conscious decision that this was the best architecture, but because there was only one computer.
Let's consider two specific decisions:
1) Should the archival storage of medical records be internal or external relative to the application(s) that create and use them?
2) Should an electronic or digital signature be a function of the application that is generating the document or should the signature be applied by an external authority?
People are living longer. It is reasonable to plan for 100-year retention of their medical records. Computer systems have a useful life of between 5 years and -10 years, after which the hardware becomes obsolete and unmaintainable. The software running on those systems may last somewhat longer but one wonders whether program code that is already 25 years old will be around and runnable 50 or 100 years from now. During the lifespan of the software, the computers themselves get replaced periodically; the storage technologies become obsolete and are replace with new and different devices and concomitantly, the way that data is backed-up changes.
Every time "archival" data is rewritten, the process is open to a medico-legal challenge that it was altered during the transfer. As data is migrated from one database technology to another, data may become corrupted because the basic data types are stored differently. The semantics of the data are subject to alteration because the new product assigns different meanings to data than it had originally.
At the present time, every healthIT vendor has its own concept of what a digital or electronic signature is and implements a proprietary scheme. Some institutions may have up to 15 different electronic signature schemes in use simultaneously. Each has a 5-year to 10-year life span. Over the next 100 years, different portions of a medical record may have been "signed" using a myriad of schemes. Imagine that you are in court. An aggressive attorney is challenging the authenticity of your electronic signatures. Will the institution have retained sufficient data to allow you to provide a viable response? I hope so, but I doubt it. For more detailed information about Digital signatures I suggest the American Bar Association "Digital Signature Guidelines Tutorial" http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html.
Every time software is purchased a decision is being made about whether archival storage and digital signatures (and many other things) will be implemented internally, or externally, as services that all your applications can utilize in a consistent manner. You may have been unaware that these decisions were being made or could be made. Nonetheless, these are fundamental architectural decisions that will influence everything that comes later.