Epic maintains on its own web site that the Beaker LIS supports best-of-breed functionality. My personal definition for a best-of-breed LIS is that it will meet or outperform most or all of the LISs in the market across a wide array of functions. This is a tall order given that the well-known and established LISs have been installed in hundreds of large hospitals and have have been in operation for decades. It may be the case that Beaker actually meets this definition and will serve both Allina and OHSU well but let me express here some degree of skepticism about this claim for a product that is currently running in only a small number of sites.
In fact, I would suggest that any lab that installs and runs Beaker qualifies as a beta test site for the product, defined in the following way : Second-phase test of a new computer system or program in a live operating environment. Beta testing helps to identify flaws in the system prior to a full-scale introduction. There is nothing wrong with being a beta test site. All of the LISs currently in the market were in a beta phase earlier in their development cycle. However, serving as an LIS beta tester places intense pressure on lab resources for two reasons: (1) veteran lab personnel spend much of their time communicating with the software developers, discussing how to correct software problems and increase system functionality; and (2) extra personnel then need to be added to the lab work force in order to compensate for the work not being accomplished by the newly installed and immature LIS. I would estimate that lab productivity decreases by at least 30% in a beta test mode and this situation often persists for two or more years depending on the rate of progress.
It would be instructive for Allina and OHSU to know before they sign up as Beaker beta testerswhether there are any major functionality gaps in Beaker, how lab operations will be affected by them, and how many new FTEs they will need to hire. This can be accomplished relatively easily. Most high-quality LIS RFPs (requests for proposals) contain a list of statements, categorized by function (e.g., order-entry, result-reporting, quality control, billing), and stating the various tasks that the new LIS will be expected to perform (see: More Ideas about Developing and Refining an RFP ). Competing vendors respond in writing to each of these statements, documenting for each whether the particular task can be accomplished or not by their system. These written responses to the RFP become part of any eventual contract and can be used legally to hold the vendor to these terms. The lab leadership at Allina and OHSU merely needs to borrow an RFP from colleagues in other labs and ask Epic to respond to a detailed list of the LIS functions that will be required from Beaker.
I am acutely aware of the irony of requesting a response to functionality requirements for a system (i.e. Epic) that has already been purchased by a hospital. I suspect that the upcoming availability of an acceptable LIS was included in the total Epic purchase price with the LIS, in a sense, being obtained for nothing. Unfortunately, it's the true cost of installing a beta or open-source LIS that prompted the saying: I can't afford a free system. However, I beg forbearance on this issue because I didn't coin the phrase "enterprise solution" nor do I personally believe that it's a viable approach to hospital computing when taken as a whole. The intense specialization of the various diagnostic units such as lab and radiology militates against it. I will therefore make no pretense at defending the idea.