Charna Albert
April 2021—Whirlwind timelines, novel problems, and a never-ending workload: On the anniversary of the COVID-19 pandemic, pathology informatics leaders David S. McClintock, MD, and Christopher Williams, MD, reflected on the year’s onslaught of challenges.
“How do you make do with the few resources you have?” says Dr. McClintock, associate chief medical information officer, Michigan Medicine, University of Michigan. “And how do you put everything else on hold to handle the emergent needs of the pandemic?”
Keeping up day to day was difficult, particularly when clinical labs were developing tests and operating at full capacity, new COVID-19 ICUs were being deployed, field hospitals were being planned, and COVID-19-specific reagent shortages were common.
“For every new analyzer and testing platform that the lab needed to rapidly implement, there were accompanying IT builds in the LIS and EHR,” says Dr. McClintock, who is also associate director of pathology informatics, director of digital pathology, and associate professor of pathology, Department of Pathology. “We had to urgently build out new tests, instrument interfaces, and specimen tracking workflows all while also ensuring orders and results were formatted correctly for clinical needs in addition to meeting state and federal government reporting criteria, such as multiple ask-on-order-entry questions. A lot of work was done behind the scenes by dedicated lab IT analysts that people didn’t hear about.”
The rush to set up SARS-CoV-2 testing at the University of Oklahoma Medical Center led Dr. Williams, director of informatics, Department of Pathology, University of Oklahoma College of Medicine, and colleagues to stitch together three middleware solutions: one purchased from a vendor, one borrowed from an on-site research lab, and one developed in-house.
The main hurdle they faced was communicating results to patients not already registered with the hospital system, says Dr. Williams, who is also an assistant professor in the Department of Pathology. As an academic medical center, “our lab was not used to doing reference-type work, and reporting back outside our EMR was not something we had done on any kind of scale before.” Rather than faxing results—the solution proposed initially—Dr. Williams and his team purchased the Ellkay CareEvolve platform, “an orders aggregator and resulting platform with a built-in patient portal.” Community-based collection sites send orders to the lab via CareEvolve, and when results are ready the lab sends HIPAA-compliant emails to alert the patients, who log in to the platform to receive results over a secure connection.
The borrowed middleware solution came into play with the university’s laboratory-developed SARS-CoV-2 diagnostic test, which runs on the Fluidigm Biomark HD platform. “We needed a quick way to spin up” a laboratory information management system, Dr. Williams says, “and with the way our hospital IT works, bringing a new solution in-house was going to introduce a lot of delay.” Instead, to manage the reporting at a high level, his team borrowed a tried-and-true clinical-grade solution from a research lab that performs clinical work on site. But the borrowed LIMS didn’t have an interface for the Fluidigm platform, and it wasn’t able to ingest files from the instrument directly, so Dr. Williams and a resident collaborated on a custom bridging solution to transfer results from the instrument to the LIMS to the CareEvolve platform. “That’s where the in-house solution came in.”
The project came together in about a month. “Which isn’t incredibly fast, but it was pretty fast for us,” he says, compared with the usual pace for such projects.
The shortages of reagents and other supplies forced lab informatics into uncharted territory. While laboratories hopscotched among testing platforms, Dr. Williams says, informatics had to determine how to “branch out from a common [SARS-CoV-2 test] order code” to a variety of testing methods that changed regularly. “Which is not something the LIS has ever had to contend with before.”
At Michigan Medicine Laboratories, Dr. McClintock says, “We had to use different test codes for each COVID-19 test that came out, and there seemed to be new testing systems coming out every week.” They started with the initial state health department reference lab testing and “just kept going,” he says, “with separate tests built out to accommodate each new COVID test used by our clinicians, including internal and send-out testing.” This solution was viable because of Michigan Medicine’s more extensive IT resources, he says. “We dropped all projects except for COVID and put everybody we could on test code, interface, and reporting development to get this work done right away.”
One way Michigan Medicine ensured that providers would order the proper SARS-CoV-2 test was that the pathology informatics team built out test codes based on different ordering locations. “For example, emergency department providers would place orders with a specific ER-based test code,” he says, “while all other providers would order the same rapid COVID test with another code.” This way, “we were able to more rapidly route specimens that used the same testing platform technology to the instrumentation in the proper location, which then helped to streamline the lab workflows.”
While much went well with the emergent test builds, one aspect “did come back to annoy us later,” Dr. McClintock says. In an effort to ensure that each testing platform was identified for state and federal reporting purposes, COVID-19 lab results were modified to include the name of the testing system, which in turn allowed for the test system’s FDA unique device identifier to be coded into the reporting interface messages as required by Health and Human Services. “It would say ‘not detected/detected by’ and then list the instrumentation or the platform, which worked well initially for clinicians, but now we need to reformat that to better meet the state’s reporting interface message formats,” he says.
“Lesson learned is that, in the future, we should do our best to include the unique device identifiers in the original message result right off the bat.”
[dropcap]A[/dropcap]t the OU Health University of Oklahoma Medical Center, the pandemic revealed a need for a “more robust middleware layer and flexibility to add instrumentation faster,” Dr. Williams says. And Michigan Medicine, Dr. McClintock says, lacked an easy method for importing discrete test results from external laboratories on a large scale. The need became greater in August 2020, when the Centers for Medicare and Medicaid Services began requiring that claims eligible for the 20 percent add-on payment for COVID-19 hospitalizations include a positive COVID-19 diagnostic laboratory test documented in the patient’s medical record.
As a substitute, Dr. McClintock says, the pathology informatics and central IT teams leveraged preexisting workflows already used to manually import lab data faxed from clinicians to automate external lab entry of SARS-CoV-2 results from the regional health information exchange. “This took a lot of extra interface coding and specialty work.” They now have a data feed from their regional HIE that imports COVID-19 test results near real time from when the HIE gets the results, he says, “and that really helps in the COVID-19 clinical decision support arena internally.”
But laboratories that do not have workflows established for importing external results may find “it takes a lot of effort to figure out how to do that and get the institution behind it.” In fact, the pandemic has been an impetus for change in this regard, Dr. McClintock says. Case in point: His institution now intends to automatically import other external lab data using the same workflows built to pull in SARS-CoV-2 results. “Since we’ve proven the process works already, we’re going to leverage that and borrow from our own work.”
Importing laboratory data from outside institutions at scale comes with a new set of questions. For example, a big question that arose from importing external laboratory results and incorporating them into an institution’s patient chart was: Should these results be released to the patient through their patient portal? The patient may already have received the same result from the other institution, Dr. McClintock says, “and they should optimally know it’s the same test. How do you make sure they know that? Is there a legal consequence of not including this data if the clinical decision was made at our institution? It’s technically not our data, but do we have a moral or ethical obligation to inform them of the test?” Unfortunately, institutions do not always trust that other institutions are up to par in performing tests and communicating with patients, he says. “Which ends up with patients having the potential to become inundated with duplicate data now.”
These considerations have become more urgent since the passage of the ONC Cures Act final rule, he says, because the law prohibits information blocking, or the practice of holding on to patient data. (The information-blocking provisions went into effect this month after the ONC extended applicability dates due to the pandemic.) And the pandemic has shed light on the importance of prohibiting information-blocking practices, he says. “You can’t have the situation where someone was tested and you have the result” but it doesn’t get released due to a policy of holding patient data to allow physicians time to follow up.
Amid the quandaries surrounding data interoperability and the pandemic is the unfortunate reality, Dr. McClintock says, that the country’s health information exchanges and the health care delivery organizations that feed them do not have the infrastructure in place to take over the role of reporting SARS-CoV-2 test results to the state and federal government. Ideally, he says, the HIEs would act as a true data aggregator, identifying and matching patients, merging the data, and meeting the disparate reporting criteria required by the agencies. “The truth, though, is that we have to send our data to the HIE, to the state, and with the pandemic, the federal government. So it just adds more burden now.”
“COVID has highlighted the role that HIEs could play,” Dr. Williams says. “Our state health department [in Oklahoma] was struggling to interface with all of the various health care entities across the state and get data from all of them into a common system. That’s an area where HIE could have really shined.”
[dropcap]C[/dropcap]OVID-19 aside, the rapidly evolving state of lab informatics gives laboratory decision-makers plenty to contend with. Of late, Dr. Williams says, “I’m noticing a trend where every analyzer is coming with its own unique middleware that doesn’t necessarily interface directly with the LIS. So at minimum you’re going through two layers of middleware for most of your instruments, and that increases the complexity of getting things stood up.”
It also makes troubleshooting more burdensome. As the number of hops increases, so does the number of areas to investigate when a result doesn’t arrive at its endpoint. In addition, with every piece of middleware comes an upcharge and added maintenance, “and you have to buy another connection for your main middleware,” Dr. Williams says.
Other steps and considerations come into play, Dr. McClintock says, noting that every instrument installation comprises not one but three different projects: purchasing and installing the instrument itself, installing all middleware needed to support the instrument, and building out tests and connecting them to the EHR via the LIS and/or interface engines. Further, instrument-based middleware typically now are server-based applications that require either physical or virtual servers to be purchased, thereby initiating additional cybersecurity reviews and vendor assessments. “All of that has to happen now to fully implement a new system.”
In Dr. McClintock’s experience, there have been many times in which middleware solutions were not fully accounted for in laboratory instrument purchasing and project planning processes. For example, he has seen the implementation of a new chemistry automation line potentially delayed when the lab IT groups were not involved early in the process. “We assumed they had budgeted for servers when performing the RFP”—the automation line middleware requires high-end servers—“and they hadn’t. So now there are unanticipated additional costs for servers that push the limit of what we can do with virtual machines in the enterprise data center.” While in this case they were still able to use their enterprise’s existing virtual machine infrastructure, there was a risk that they would have had to purchase and install physical servers, adding more time and effort to the project, he says. “All of the middleware typically needs to be in place before vendors dedicate their resources to install the line and begin the validation process.”
Yet another consideration is that larger instruments often come with their own analytics engines, Dr. McClintock says, “so you have the potential now to add analytics as a middleware solution for just that one system. And then of course the next ask is to bring in data from other systems into that solution. It has the potential to get complicated quickly.” (For more on data analytics from Dr. McClintock, see April Newsbytes.)
For point-of-care testing, several criteria are used to evaluate the middleware, he says. “One is how promiscuous your POC testing middleware is. Can it connect to a lot of devices, or does it connect to only a few?” The second: “How do you do integration? Maybe it can connect to many devices but only superficially,” meaning it lacks deep integration for device management. “They serve different purposes for what you’re trying to do,” he says, and there are costs and benefits to each. “What is your model? How many testing platforms are you using? How often do you need to change and configure your POC testing devices versus just having basic pass-through abilities for results?”
With POC testing systems, Dr. Williams says, “you may end up going through one middleware for your device management and then that gets interfaced with another point-of-care middleware” to connect to the LIS. POC middleware or one’s LIS generally offers the ability to create an order for an unsolicited result so that it maintains the required order/result combination for lab testing; this prevents a lone result from arriving in the EHR without an order. POC middleware, he adds, helps facilitate end-user training and certification to ensure the program adheres to the CAP POC testing checklist requirements.
[dropcap]W[/dropcap]hile not a pandemic-related struggle, health care cybersecurity has become an increasingly important issue in laboratory informatics. Within the past five years, cybersecurity and risk management have been combined under the umbrella of “information assurance [IA],” Dr. McClintock says, “best thought of as a superset of information security and as the business outcome of information risk management.” (Drs. McClintock and Williams discussed IA in an AACC annual meeting virtual session last year.)
Often overlooked, Dr. Williams says, is that IA is tasked not only with protecting information but also with guaranteeing data access for those who need it. “The big question now is to what extent do they block and keep things safe versus allowing people to get their work done and use data in the appropriate way?” With many health care entities concerned about potential ransomware attacks, “the pendulum has swung in the direction of trying to prevent, more than making sure people have access to their data.” Stronger firewalls, Dr. McClintock adds, make organizations more secure, but also can make it “extremely difficult to exchange data successfully.”
As part of an IA initiative at the University of Michigan, Dr. McClintock sits on multiple medical device committees that are working to develop a standardized process by which every device that has the potential to connect to the network is reviewed to determine if it meets security standards, best practices, and IT principles, and that it’s been reviewed by the proper committees. (Different committees handle different types of medical devices, he says.) A proposed new point-of-care glucose meter must be assessed, for example, to determine that the Wi-Fi chipset in the device meets currently supported Wi-Fi (e.g. Wi-Fi 4, 5, or 6) standards and security standards, among other things.
“We want to make sure,” he says, that the device is modern, “that the vendors don’t have a history of security risks or breaches in their devices, that devices are not going to allow an access point for hackers, and that the device’s middleware has the same degree of security.”
“The problem is that our committees are not staffed with nearly enough people to handle all of the new devices coming in, not to mention all of the existing devices that have never been assessed,” he says. So it becomes a gatekeeping function, he explains, where the question is, does it need to be reviewed and can it be done quickly? “Since our purchasing groups are not plugged into these committees, it’s a safe bet that most of our lab instrumentation has never gone through these committees. That is not to say those instruments are not safe, but instead that we need to find a way to ensure security assessments are done while not being inhibitory to laboratory processes.”
“Many times, you are forced to bring things in quickly, such as COVID-19 testing platforms, and then look at performing the cybersecurity assessment later,” he continues, “which makes up part of the problem with information assurance. It can take months to properly complete an assessment versus a clinical group saying, ‘We need this now. How can we bring it in quickly?’” The trick to working with your IA teams is to understand that cybersecurity is not an option, he says. Instead, the clinical labs should look to develop a strong working relationship with their IA teams so that when a situation arises where a device must be deployed before a full security review is complete, the IA group and chief information security office can trust that the work will eventually be done and any risks found mitigated.
For their part, vendors are increasingly becoming HITRUST CSF-certified, he says, in which a third party runs extensive cybersecurity assessments for a vendor’s software and hardware solutions. But a smaller company may not have the resources to hire a third party or the internal capacity to conduct thorough assessments. “For them it becomes a matter of, ‘Is this contract worth it for the one or two pieces of software I’m selling you?’”
IA is a new field, “one where it seems like criteria change monthly,” Dr. McClintock says, “with every three to six months there being new issues we now have to mitigate risk for. Overall it’s a moving target.”
“However, you need to do cybersecurity risk assessments or else you’re putting your organization at great risk. At the same time, it’s burdensome because most health care institutions have not provided the concomitant increase in IT and unit resources to handle it,” he says.
“It takes a lot of effort to learn all this. It’s like a whole new language.”
Charna Albert is CAP TODAY associate contributing editor.