LIS panel talks middleware, wish lists, workflow

Tony Barresi, senior marketing manager, workflow and automation business, Beckman Coulter: At first, middleware might have been viewed as somewhat of an ancillary product or a black box connecting the instruments and the LIS. Middleware has since become an integral part of the laboratory’s ability to perform and deliver meaningful information into the broader health care organization. I envision that trajectory to continue. We’re going to see the data that middleware is in control of become more and more critical to not just the lab’s performance but the overall health care system’s performance. The role that middleware will play, I suspect, will be one that interfaces with many other types of clinical informatics applications.

Go to interactive laboratory information systems product guide

Download laboratory information systems product guide

With that being where I expect middleware to evolve, my ask of LIS vendors would be that they invest in maintaining an open and free-flowing dialogue with us. We are partners in this, and as we proceed into the future I described, we are going to have to integrate even more, not only with middleware but also with our automation systems and the instruments connected to them. Many of these future integrations will be unprecedented, so with respect to protocols and technical requirements, it will help if we have proactive and regular communication with LIS vendors so that as we approach our mutual customers, we’re working well together to give them seamless implementation experiences and enable them to make the most of their data.

Sepehr, would you like to comment on your wish list from LIS vendors? In addition, please answer the question around protocols and data standards and interface standards. The IVD industry has devoted a lot of time and attention to this in the last half-dozen years or so.

Sepehr Seyedzadeh (Siemens): First, just looking through our IVD instrument supplier lens, we have to serve many customers around the world with different capabilities in their LIS, all with different versions and packages. Customers are asking more and more to optimize their operations regardless of their LIS capabilities. Often, they expect the IVD instrument suppliers to close the gaps, whether it’s because of deficiencies in certain LISs or the costs associated with making the improvements. At times this can become an almost illogical workflow in middleware to solve a simple problem that could have been addressed at the LIS level.

A recent example of this is the calculation of the estimated glomerular filtration rate, where the patient’s race information is required and therefore should be communicated through a dedicated LIS interface protocol field. But instead, those customers that need to change their LIS interface for this purpose, in order to avoid significant LIS fees, ask middleware companies to somehow process the race information within the existing interface protocol fields. For example, utilizing the general results “comments” field and then writing rules in middleware to extract this information for calculations. We end up having to accommodate these requests resulting from inflexibilities of some LIS companies, making it time-consuming and more complex in future troubleshooting. I’m talking generally, not to our LIS colleagues on this panel.

My wish would be a little more flexibility in interfacing along with adoption of the industry standards. We are not seeing heavy adoption of the IVD Industry Connectivity Consortium/Integrating the Healthcare Enterprise Laboratory Analytical Workflow [IICC/IHE LAW], which we have built into our next-generation instruments.

My other wish would be slightly different. We all believe, and I think all my colleagues on the panel agree, that data is king. The potential of digitalization can only be reached if there is access to the data, but such access has proved to be costly and difficult. If the data were available in a more structured and secured manner, then more and more applications could utilize it to ultimately optimize laboratories’ operations. On my wish list would be a greater willingness to do the data sharing.

My last wish is portability. We are spending a lot of time making lab operations easier for our customers. For example, how many screens they need to look at, how many clicks to validate results, et cetera. Sometimes it may make sense to integrate screens of siloed sources. Today we accomplish this through rudimentary remote monitoring/sharing of screens, but there are opportunities to collaborate and deeply integrate user experiences through proper interface sharing. These are things on which we should be partners so that ultimately we can improve lab operations and make our customers happy.

Tony and Sepehr make an interesting point, which is that the major instrument vendors like Siemens Healthineers and Beckman Coulter, and we can all easily name three or four others, are designing their systems for a global laboratory market. The same systems that are going to run successfully in the U.S. will run in Western Europe, in the Middle East, in South America, and so on. Yet the LIS installation tends to be fairly national and local in scope. Do I have that right, Curt, and how do you react to this discussion of what wishes the instrument companies will have of LIS companies?

Curt Johnson (Orchard): Yes, I would agree with you. Let me begin with middleware. To us at Orchard, middleware is becoming a green word. Is an LIS middleware if it sits between instrumentation and the EHR? Is middleware something such as Data Innovations, which sits between the LIS and the instruments? Or is RALS, Alere, or new software that maximizes the automation line from Siemens considered middleware? The way we subdivide it at Orchard is this: Anything created by the manufacturers—Beckman Coulter, Roche, Siemens—we call vendorware, to keep it clear for ourselves, and many times the vendorware is required. You’re going to have to have the software from Siemens if you expect to have connectivity to the Siemens automation line. You’re going to have to work with Beckman Coulter’s Remisol if you’re going to hook up a large enterprise hematology. It isn’t a competitor. It’s another piece that has to be integrated tightly, as both instrument manufacturers have mentioned.

Their wish lists coincide in many ways with the desires of the LIS company. Communication before analyzers are rolled out and in the initial implementation is always valuable. That goal is the same for both of us: to provide information to decision-makers to improve patient care. So we’re aligned in that way and always communicating to understand what features are being put into the analyzers that benefit not only the user but also the patient and provider. Making sure we’re in a position to take advantage of those is important.

With regard to global implementations and how they think of the LIS in terms of middleware, at that point, when you think about the national perspective, an LIS is most valuable when it’s integrated into Epic’s hospital systems, Epic’s EMR, Allscripts’ EHR, AthenaHealth EHR. The goal is to be integrated into the whole health care system, and each system around the world is unique.

It’s important in the U.S. health care system to be able to work with insurance companies and insurance data, ICD-10 data, medical necessity checking. It’s not important in the British system, where it’s more important to understand the physician workflow and how they use the laboratory, and it’s having the laboratory assist in choosing the tests. So when you look at integration of an LIS globally, you have to take into consideration that national health care system, how it works, what the value is, and how the integration has to take place.

Dr. Tuthill, all of us on this panel are aware of the need to have a better designed workflow for the entire laboratory, which would include, it seems to me, a better designed laboratory result reporting workflow into the EMR. How are you looking at this from the perspective of the Henry Ford system?

Dr. Tuthill (Henry Ford): You have to keep it simple. What we know and have seen reported is that clinicians have only about seven to 10 minutes per day to look at patient results. If you’re sending out long reports, it becomes difficult for people to interpret them or even to spend time with them.

This is particularly true of molecular diagnostics, where reports can run 30 or 40 pages. So it is a conundrum. How do you keep it simple yet continue to provide the valuable information people need? How do you turn long laboratory reports and scrolling through large amounts of screens into something that looks more like the baseball scores in the newspaper? Some of this comes down to the visual presentation of that information, showing trending, showing how data have changed historically for a given patient, and then being able to allow people to interact with this information dynamically. One of the things we’re trying to do is engage our clinicians in an effort to understand in a more prospective manner what they need from us, rather than our just chucking the data over the wall and hoping they’re able to consume it.

That’s probably the biggest thing we’re working on now—figuring out how to keep it simple, and what data points people need to do their work.

Michelle, can you comment on the genuine need to improve workflow and clarity and the understanding of laboratory data in the laboratory report?

Michelle Del Guercio (Sunquest): Dr. Tuthill brings up a good point about the amount of time caregivers have today to read a report and do something with it. Providing precise, consolidated, and timely information to that physician is key, in addition to other information the laboratory has—maybe in the form of ordering patterns. It really all starts with the order. There can be duplication of genetic test ordering, for example, which can be expensive for the health system and the patient. So it’s about helping to guide and educate the physician, not just in the resulting end of it but also starting with the order and helping to reduce the extra noise the physician gets as a result of that. With orders coming from multiple sources—physician offices, EHRs, other hospitals or labs—having better insight into how to manage and process the orders is important for the health system. Consider mergers and acquisitions as part of that mix as well—organizations need to support better test routing and sharing to help ensure alignment with the health system’s strategic initiatives that reduce costs and improve outcomes and physician satisfaction.

Nick, Epic is front and center in some of this. In the August 2019 issue of CAP TODAY, we reported on Raj Dash’s presentation at this year’s Executive War College about the Beaker AP LIS. One of the things he cited as a blessing was greater functionality by leveraging EHR data. Can you tell us how you’re working at Epic with Beaker to help leverage the data in the electronic health record?

Nick Trentadue (Epic): All of our pathologists and laboratorians who are on Beaker also use Epic as their EMR. They have the full patient record at their disposal for all of the patient’s pertinent clinical history and information. I know Raj Dash and the team at Duke, and when he and colleagues sign out cases, they like to know as much about the patient as possible. For example, for prioritizing cases, they like to know whether this patient is scheduled to come to clinic tomorrow. We try to bring some of that situational awareness to make sure the patient is getting the care they need, and to give the pathologist all relevant history, background, and the full patient story so we’re not dealing with just a transactional lab test.