(vibrant music) - This is "Lab Medicine Rounds", a curated podcast for physicians, laboratory professionals and students. I'm your host, Justin Kreuter, the Bow Tie Bandit of Blood, a transfusion medicine pathologist at Mayo Clinic. Today, we're rounding with Dr. John Mills, an assistant professor of laboratory medicine and pathology here at Mayo Clinic. He is Vice Chair of test implementation and we're gonna be talking with him about navigating these implementation challenges in the laboratory.
Thanks for joining us Dr. Mills. - Thank you for having me. - Hey, so let's kick off with kind of like a obvious question maybe for some, why is implementation often a struggle? We kind of, we have a plan we wanna put in place, but making that happen seems to often be a struggle. Why is that? - Great question.
I guess before I get into it, I just probably just explain where I kind of define the division between kind of test development and test implementation 'cause I think it's an important distinction to make. So really when we talk about test implementation, we're talking about after a test has been designed, developed, analytically and clinically validated and we've basically made the decision that this is a test that we wanna offer clinically.
So it's from that period of time for you know you wanna offer that test clinically, until the test actually launches and is an available test for physicians to order. That's kind of the, that's what we categorize as the implementation phase. And I'd like to break it down further into kind of two parts. Part one is the work that needs to happen to make a test go live. That actually happens in the clinical lab. That's gonna be performing the test.
That can include training staff, ensuring adequate instrument capacity, finalizing SOPs, procedures, workflows, establishing a quality control program and then also just the movement of data within the lab. And that's not by any means an exhaustive list, but so those are some of the activities that have to happen physically in the clinical lab. And then the second part are those implementation activities that typically occur outside the lab.
So where the lab may not have direct influence over resources and those things relate to things like establishing the cost of a test, billing related items, building your test in your institution's LIS, ensuring there's good, proper communication between the LIS and the electronic health record. And then as well as planning for any education related material for the test that might be provided to clinical colleagues.
So those are two kind of distinct phases or portions of the test implementation. And I think one of the things you quickly realize is that wow there's a lot of different people, groups involved in that implementation process. And I think that that's probably one of the largest driving factors for why implementation can often be a struggle is that just the size and the number of tasks that are required.
And you have a lot of stakeholders that are not embedded in the lab that are critical and you need really, you know, you need strong communication between all those key stakeholders, some that are in the lab, some that are outside of the lab.
And then another component, and this is where things maybe don't go well or they're not optimal, is that a lot of these, a lot of the decisions that require stakeholder input maybe don't get dealt with until after the test development phase and then you're trying to deal with them on the back end. And that makes things very difficult. And so to me, that's it in a nutshell. A lot of people, very complex.
You really need great communication and if that doesn't happen and it doesn't happen early, that's where the bottlenecks happen. - Well, I think you really pegged it well for us, right? As you're talking through there, I'm jotting down notes. And yeah, it's more than just, okay, we've developed some tests so that it's gonna help out our patients and so let's make it happen. Let's start tomorrow, right? Your idea of there's several components that are there.
So it's not just as simple as let's do it. You were mentioning, you know, the staff trained. Do we have capacity? Do we have the testing equipment, reagents able to do it? You use the abbreviation SOP, so standard operating procedures. So there's instructions for how to perform the test. Movement of data you highlighted. So that's another thing that sometimes isn't first top of line for some people. And then I like you bringing in the component, this is not all under our control.
As is many things in healthcare, it really takes a team and there's people that we are reliant on across the institution. I kind of wanted to ask you a follow up question, kind of highlighting, you know, this challenge of stakeholder input and I imagine that stakeholder input is, you know, also really important earlier on, maybe during test development, right? Which is that earlier phase, not implementation. But do you think that comes up kind of later?
Is that because sometimes stakeholders aren't really understanding a clearer picture of what the test is going to look like? Is that something that is as it gets formed, you have something more concrete to share? - Yeah, I think, you know, I think there's, when you're talking about a new test, there's always a lot of enthusiasm, right? And there's a lot of energy to hit the ground and get moving quickly. And I think that's just an inherent part of test development.
It's something that we actively need to, you know, sometimes press the breaks and pause and say, "Okay I got this great idea. I got this new test. I know it's gonna help patients, but have I really taken the time to really map out how this new test is gonna fit in the big picture?" How's it gonna impact the people in the lab? How's it gonna impact our clients, physicians?
How complex is it going to be?" Generally, I think it's often clear or there's a relatively well mapped out steps in the development phase. I'm gonna do X, Y, Z and I'm gonna show the utility and the analytical validity of the test, but I'm not worrying about, you know, what it's actually gonna look like in the live clinical lab environment. I think this is a common problem across labs and the solution to me really is, and I mentioned it earlier, just good communication with stakeholders.
And so I guess the single best piece of evidence I would have is just identify all relevant stakeholders early in the process, make sure they're aware of the test, make sure they're aware of any timelines associated with the development and launch of that test and make sure there's a really good understanding of the amount of resources and time that's gonna be needed to complete all those critical tasks.
Having, you know, having relevant stakeholders at meetings rel regular frequencies early on to ensure projects moving forward, to me that's a recipe for success. Again, when we don't address those things early, the later and later we do address 'em, the harder and harder it gets to address 'em and the bigger any potential change or rework becomes. So get people involved early, really thoroughly map out all of the requirements for a test and move forward that way.
I will note the one other important thing is really having that lead proponent, that person that's responsible for the test that is kind of taking ownership from the beginning 'til the end. Without kind of that lead proponent pushing and ensuring things are moving along in a timely fashion, you know, things can take longer than they need to or important items can be forgotten. - You know, I was gonna ask you about what can be done to set up for a successful implementation.
I think you've really given us that, Jim, there about inviting all those key stakeholders early and having them involved throughout the process. It's one of the things that I know I have kind of struggled with over time is like, you know, am I over inviting people to meetings? Am I under inviting? That's one of the things that I've kind of noticed.
And probably some of our listeners are, you know, within their departments, they might be doing some change and somebody might show up to a meeting and like, you know, why am I in invited to this meeting? Or, you know, what's the famous meme now or whatever? It's like, you know, this could have been done with an email. How do you navigate who and when to get involved with the planning of an implementation? - Yep. So that, I mean that is one of the challenges.
I think it starts with, again, understanding your own test development, test implementation process and understanding what needs to get done and then making sure you understand the people that are gonna actually be doing the work that are gonna make it happen and making sure that they're getting the information they need at the right time. Mainly, I think the big benefit is to avoid surprises.
Nobody likes surprises where something all of a sudden comes out of the blue and it becomes an urgent must deal with now. And you know, that's stressful for people because people by nature like to plan out their work and know what they're gonna have on their plate and try to avoid those situations where four or five large things are happening at once and then you feel overwhelmed. So identify the key people, get them the right information they need.
And the answer to that really does come down to mapping out your lab's process. Knowing who is gonna be, you know, if work needs to be done to build it into your lab information system, know who is who will be doing that work and making sure they're getting invited to meetings where those topics come up. I agree we don't want meeting fatigue.
We don't want a thousand meetings where redundant information is being brought up or information's being brought up that isn't relevant to the people at the meeting, but I still think having early meetings with targeted objectives where the right people are at that meeting and high level just going through. You know, raising awareness about the tests so that if somebody does foresee an issue, they can speak up.
They can share that information rather than hearing about the issues after, you know, a lot of work's been done. - Yeah, I think that's brilliant and well said. I wonder, you know, so as being Vice Chair of test implementation, I'm sure you've been privy to some implementations that are maybe not going as well. And how do you pivot when that's happening to, you know, wow, this isn't really going so well? Like you said, let's kind of pump the brakes and figure some things out.
Can you kind of walk us through what are some of those key steps you do to kind of take something that's not going so well and get it back on tracks? - Yeah, so the first thing I'd say about that is unfortunately it's not uncommon for implementation projects to not meet initial timelines. The reality is, is labs are dynamic, right? There's lots of competing priorities that come up out of the blue. More and more these days, it seems we have supply chain issues.
Labs are faced with high staff turnover. A lot of these things are newer for labs but we still have to deal with them and they directly impact implementation. So I think rule number one is expect delays, expect problems to come up, build flexibility into timelines, have realistic timelines and try to make sure that you're staying on track with timelines. And as soon as you are falling off of a timeline, that's the chance to really take a look at why, like what are the barriers.
Really try to proactively identify those problematic areas. I mean, ideally, you know, once a test idea is conceived to begin with, one of the best things you could probably do is already think through, like okay, where are the potential problematic areas in this test? So that when they do happen, they're not as big of a surprise. But even a well-planned implementation, you're gonna encounter unforeseen challenges.
And so again, quickly recognize the problem so that you can determine if there's something that you can address, either through asking for additional resources, reaching out to somebody with expertise that isn't currently in the group to help solve the problem. But then there could also be situations where the test just isn't, it's not meeting expectations.
So even though it went through a test development, validation, verification, you could encounter an issue, you know, right at the time where you're implementing. And it's just important that labs feel confident to say, "Hey, there's a problem. We've encountered a problem with the test or software system." And basically pause, identify the problem, come up with a solution, and then look at how that's gonna impact the timeline or resources.
So to me, success in these situations, really identifying and addressing the problems quickly. Make well-informed decisions. Communicate to all your stakeholders about what those problems were and why you made the decision you made. And then, you know, in the future try to learn from those situations to put things in place to maybe ensure that that same problem doesn't happen again.
But at the end of the day, if a test isn't meeting expectations, what I always say is pause and figure out a solution. There's always additional work for other tests that where you can pause one project, pick up another that needs some attention. So that's kind of how, that's my recommendation. - Yeah, no, that's fantastic. And you know, that makes me think about, you know, three things that I'm hearing that I need to do better at, you know. So you said one is realistic timelines.
And I'm always kind of thinking in best case scenarios. But as you're highlighting, laboratory medicine is dynamic and so those things can change and I need to be more thoughtful about building in some more buffers so they can become a realistic turnaround time that I can give.
I think, you know, that forget where I've heard it before, but this concept of, you know, starting out planning, thinking about, you know, where are the failure points gonna be, where are the challenging points gonna be and plan for those challenges, to think about that ahead of time. And then I also like your third point there about communicating when things are kind of falling off, right?
Because I think that's one of the things that when we're starting to not quite meet our target, we're like, "Oh well, I don't wanna, you know, raise alarm bells. Maybe I can figure this out." And as we're not communicating every day that goes by. And there might be, as you're pointing out, there might be resources that we can tap into that would really help us not impact things to such an extent. One final question I have for you.
You know, when we were talking about test implementation, you were talking about stakeholder input. You were also talking about education for the clinicians who'll be using, ordering the test. How do you communicate with those clinical colleagues? Is this? And now I'm not talking about the stakeholders. Maybe you have a leader that's involved with planning, giving you feedback.
But you know when a test is going live, are you kind of communicating a heads up periodically ahead of time or is this kind of more of a just in time training or education that you advocate for? - So I personally am communicating with clinical colleagues really through the entire test life cycle, including once the test has been launched.
And so that can start with, you know, just having a discussion with clinical colleagues about, you know, the new test that you're thinking of developing, understanding, you know, getting their perspective on it, getting their feedback, sharing your thoughts. And that right there kind of, that is the initial aha moment where they are aware of, okay, here's a new test that my lab colleagues are working on. Kind of get it on their mind. They're aware.
It's not something that you're gonna be, you know, meeting on a monthly basis to say, "Oh, let's talk about this idea." But just once a test idea has has come up, it's a great time to just bounce that off of your clinical colleagues. But I would say during the implementation phase, I do think it's important to revisit some of those discussions that you've had along the way.
Some of the big ones that I would think about is, you know, just revisiting how that test will be utilized in the clinical workup, talking about turnaround time, and from a clinical perspective and for the patient needs, what those turnaround times need to be. Is it something that it's critical to have things out as fast as possible?
Those are important discussions because they also, one, they relate to how likely a clinician is to use your test and then also what are the demands that are gonna be on the lab, in terms of getting testing done quickly. And then others would be just appropriateness of any interpretive comments that you might provide with your test. So in my lab, we like to have interpretive comments to help our clinical colleagues interpret results.
So it's important that you have a really good understanding of how to word things, what the test result means and making sure that the language that you might include with your report makes sense to clinicians. And then also just providing the end user with the information about the analytical and clinical performance of a test, how it might differ from earlier versions of a test or similar tests that are available in the market. - I love it.
This answer really kind of brings together what this podcast is all about, right? This idea of encouraging those connections between lab medicine and the clinical practice through these conversations. So this idea of communicating throughout the process really echoes a lot of the ethos of what this podcast is about. Thank you so much Dr. Mills. - Thanks for having me. It was great to talk with you. - It's awesome. And thank you to all of our listeners. Thank you for joining us today.
We invite you to share your thoughts and suggestions via email. Please direct any suggestions to [email protected]. And if you've enjoyed "Lab Medicine Rounds" podcast, please follow or subscribe. Until our next rounds together, we encourage you to continue to connect lab medicine and the clinical practice through insightful conversations, just like Dr. Mills is showing us. (vibrant music)