(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 mcleducation@mayo.edu.
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)