Subscribe
Share
Share
Embed
A Mayo Clinic podcast for laboratory professionals, physicians, and students, hosted by Justin Kreuter, M.D., assistant professor of laboratory medicine and pathology at Mayo Clinic, featuring educational topics and insightful takeaways to apply in your practice.
(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)