Clinical lab processes have become technological hodgepodges of laboratory information systems, hospital information systems, and instruments produced and supported by entire ecosystems of developers. Because of the diversity of providers, much of the technology lacks standardized language and the compatibility it affords. Each system or instrument and its corresponding stage of the lab process therefore represents an island of security, while the area between islands lacks formal process, automation, computer support, and control mechanisms. The exchange between one tool and the next depends on the attention of human beings using paper, sticky notes, emails, spreadsheets, and sneakernet (physically carrying information from one station to another). Humans don’t perform repetitive activities with adequate reliability—particularly when those activities are complex and produce outcomes on which critical decisions are based. Thus, a lack of compatibility and software support between technology tools can be costly.
One response to this challenge is what some have termed “middleware”: software designed to bridge the gaps between technologies. Middleware developers produce software for the specific purpose of connecting disparate technologies, enabling laboratories to automate the transitions between systems to eliminate the pitfalls inherent in human intervention.
Middleware can integrate with any system or instrument, but a critical challenge to producing effective middleware is creating software that is customizable and adaptable enough for laboratory settings. The prevailing business model for software development consists of writing a program once and selling it many times so that, rather than each customer bearing the expense of building an entire system, the cost is spread over many customers. This works well in settings where needs are universal. However, it does not work in the laboratory world, where processes have more differences than similarities; two labs, for example, may use similar processes for actual testing, but each may use different methods of shipping, storage, training personnel, reagent qualification, etc., and the accurate execution of those steps is just as critical to the delivery of a consistent product as the testing itself. Rather than a thousand customers who need one system, therefore, the middleware market consists of a thousand customers who need a thousand systems. For the same reason off-the-shelf orthodontic braces would not be a viable product, one-size-fits-all software does not work for the lab community.
The ability to customize is not the only challenge facing effective middleware development: in order to economize resources, incorporate new technology, and adapt to changing business environments, laboratories must continually revise both processes and the tools used to support them. End-to-end software support is thus difficult to maintain: an instrument or information system is interchangeable enough when human attention links one stage of a process to another. When software written in traditional programming languages is used to bridge those gaps, however, change or evolution becomes expensive and time consuming, because the software must change as well. Middleware must have the capacity to adapt with relative speed, or it becomes a barrier instead of an aid to growth, improvement, and the ability to compete.
One response to the challenge of interconnectivity has been the formation of coalitions such as the IVD Industry Connectivity Consortium—an organization whose goal is to convince providers to create products that meet interconnectivity standards. Movement toward increased compatibility is clearly desirable, but software formats have tremendous inertia, and there is no one entity big enough to dictate compliance by every vendor. Because buyers possess a great deal of power, members of the lab community need to become better organized and more intelligent consumers. Technology industries are diverse and dynamic enough that efforts toward compatibility are likely to face ongoing challenges, though efforts to that end continue.
The goal of a common format focuses on the nature of the products with which middleware integrates, but there should also be a call to transform middleware itself into a more customizable, modifiable product. Computer technology can be better leveraged to meet the specific needs of the laboratory community than it has been to date. The prohibitive cost of customization and modification is a result of the resources required to work with traditional programming languages, but programming languages are themselves software products that can be tailored to function in specialized ways. Operating systems and user interfaces, for example, represent very high-level functions that enable even unskilled users to perform complex tasks.
The laboratory community would benefit from software constructed with programming languages that express laboratory process concepts as opposed to programmer concepts—languages that, rather than functioning at the level of strings, integers, and subroutines, use vocabulary like qualification, authentication, grouping, workflow, and content flow. The business model for producing software using process-oriented language does much of the “build it once” work in creating the language itself and then leverages that tool to produce software to support unique laboratory processes at less cost and with greater speed.
UNIConnect (www.uniconnect.com) is a laboratory informatics company that delivers standalone, distributed, and middleware solutions that can integrate with other vendor solutions where needed to support underserved areas of laboratories. UNIConnect offers technology based on UNIFlow—a process-oriented language that eliminates the prohibitive cost and time burden of customizable, adaptable solutions and thereby enables laboratories to affordably track and control unique, dynamic processes from beginning to end.
Bill Harten is founder, CEO and Chief Technology Officer of UNIConnect. He is the creator of the UNIFlow process definition language, process tracking database, and UNIFlow quality compliance engine. A recognized expert on database architectures for extreme computing requirements, he is a Sun-certified Java developer and has completed post-graduate work in artificial intelligence at the University of Utah.
