WEBVTT
00:00:00.100 --> 00:00:04.389
Hello, and welcome to SCRS Talks, provided by the Society for Clinical Research Sites.
00:00:04.440 --> 00:00:17.719
I'm Jimmy Bechtel, the chief site success officer with the Society, and today I'm joined by Ashley O'Brien, who is the executive director of product management, and David Steckler, who is the director of product management, with Signant Health.
00:00:17.750 --> 00:00:19.460
It's great to have you both here with us.
00:00:19.469 --> 00:00:31.352
Really excited to talk to a technology company who's focused on developing technology with sites and not just on sites, or on top of them or in force against them, right?
00:00:31.352 --> 00:00:38.701
We talk a lot about how important it is that as we're developing solutions and implementing technology, that we bring sites along with us.
00:00:38.712 --> 00:00:42.942
So I'm excited to dig into this topic with you all and tease out a little bit of how you do that.
00:00:42.962 --> 00:00:47.822
But before we get into that, I'd love for the audience to learn a little bit more about each of you.
00:00:47.822 --> 00:00:50.591
So if you guys could expand on your introductions.
00:00:50.612 --> 00:00:52.292
Ashley, love to start with you.
00:00:52.311 --> 00:00:53.682
Tell us a little bit more about yourself.
00:00:53.781 --> 00:00:54.042
Yeah.
00:00:54.042 --> 00:00:54.962
Thanks, Jimmy.
00:00:55.012 --> 00:00:55.351
Yeah.
00:00:55.351 --> 00:00:58.332
So Ashley O'Brien, executive director at Signant Health.
00:00:58.432 --> 00:00:59.962
I've been here for 16 years.
00:01:00.012 --> 00:01:02.671
That, that might qualify me in a very unique way.
00:01:02.771 --> 00:01:11.421
But largely, my focus and tenure at Signant has been focused in the CNS technology response that Signant provides to the market.
00:01:11.522 --> 00:01:18.971
This is primarily around sort of quality assurances that our customers can get through the technology implementations within those clinical trials.
00:01:18.981 --> 00:01:31.531
So this could be something as simple as rater training or even more complex, such as blinded analytics and support of downstream quality checks with third-party consultants that could do a data review.
00:01:31.632 --> 00:01:41.932
So being in this space for this long, I think I've definitely seen some, some emergent technologies that have hit the mark and those that have missed the mark when it comes to our site users.
00:01:42.031 --> 00:01:42.591
David?
00:01:42.691 --> 00:01:43.081
Hi.
00:01:43.132 --> 00:01:47.831
Yeah, so I've been with Signant also for a long time, not quite as long, about 13 years.
00:01:47.932 --> 00:01:53.371
And I've also been focused on this space and specifically this product called RaiderStation.
00:01:53.382 --> 00:01:59.162
So I started out delivering RaiderStation to sites, getting them set up, helping them.
00:01:59.262 --> 00:02:05.850
And now I'm in a position where I'm actually building the RaiderStation product, which is our Raider focused product.
00:02:05.900 --> 00:02:14.911
And yeah, just really excited to, to be working on this technology that I think has a great opportunity to address a lot of the things that we're gonna talk about today.
00:02:15.010 --> 00:02:15.570
I am as well.
00:02:15.570 --> 00:02:16.211
Thank you both.
00:02:16.241 --> 00:02:20.911
And again particularly excited to talk through this subject with you guys.
00:02:21.010 --> 00:02:25.061
As I had mentioned, technology comes up a lot as a pain point in our community.
00:02:25.061 --> 00:02:28.901
It's consistently right at the top of some of the challenges site face.
00:02:28.901 --> 00:02:31.580
We've got data and anecdotes to support that.
00:02:31.640 --> 00:02:44.651
It's been a problem and a challenge for a long time, but really the infusion of technology and decentralization in clinical trials as sparked by COVID the COVID pandemic has really put that at the forefront of a lot of the conversations we've had since then.
00:02:44.651 --> 00:02:54.670
So from where you each sit and, Ashley, maybe starting with you here, where do vendors typically get it wrong then when we're designing technology solutions for sites?
00:02:54.770 --> 00:02:55.251
Yeah.
00:02:55.350 --> 00:03:01.061
Sites, I think the number one problem is sites are often not the first thought and that makes sense, right?
00:03:01.091 --> 00:03:10.079
A lot of us don't sell directly to sites, and so a lot of the vendors in the space struggle with finding the balance between those different persona needs.
00:03:10.179 --> 00:03:21.179
I think the core mistake is that we design within the boundaries of our own software or that customer relationship or business strategies, and we're not considering the boundaries of the site's actual day.
00:03:21.278 --> 00:03:27.348
You can build a genuinely excellent best-in-class application looking at the feature set alone.
00:03:27.449 --> 00:03:38.019
You can, and still get it wrong, because I think you've never asked, What does this technology have to coexist with?" And I don't mean that just with regards to other technologies.
00:03:38.058 --> 00:03:41.079
I think literally we're looking at other vendor solutions, yes.
00:03:41.179 --> 00:03:46.859
But also, what is the context of the site and the staff and the explicit visit day?
00:03:46.959 --> 00:03:58.329
So questions that really matter to my team, if you think about where we position ourselves a little bit differently since COVID is what did the site do right before opening the device or the software application?
00:03:58.338 --> 00:04:01.098
What else is running on another device at the same time?
00:04:01.199 --> 00:04:04.848
How many other vendors and systems are also in play?
00:04:04.868 --> 00:04:07.278
And these aren't direct competitors necessarily.
00:04:07.278 --> 00:04:10.479
They're complementary or amplification type of technologies.
00:04:10.579 --> 00:04:15.699
So is this just one more thing I'm introducing that adds to that site's complexity?
00:04:15.799 --> 00:04:22.778
If the site is waiting for a notification or a prompt for an outcome after they submit data, is it clear to them that they're waiting?
00:04:22.879 --> 00:04:23.559
How long?
00:04:23.658 --> 00:04:26.949
And does that flow with their actual study day or does it obscure it?
00:04:27.048 --> 00:04:40.978
So I think at the end of the day what we get wrong typically in this space is we aren't appreciative of the fact that sites are juggling a lot, not just different technologies and vendors, but there's a lot of activities that happen above and beyond just the transaction with your actual solution.
00:04:41.115 --> 00:04:50.005
so they don't want one study's experience trapped on this piece of hardware in a separate login per each device shipped from each of these different vendors.
00:04:50.105 --> 00:04:58.798
That administrative overhead of another box to keep charged on the shelf is sometimes the straw that breaks the camel's back, so to speak.
00:04:58.898 --> 00:05:09.235
So to be fair, none of us in this space, so Signant Health or any of the other vendors in the technology space here, none of us want that, but every workaround compounds.
00:05:09.336 --> 00:05:16.896
And honestly, those site points that I mentioned, that's what happens when you focus on meeting only one part of the narrative, which is the customers.
00:05:16.995 --> 00:05:17.406
David?
00:05:17.555 --> 00:05:17.795
Yeah.
00:05:17.975 --> 00:05:22.454
I think To underline this part about the sponsor is the paying customer here.
00:05:22.553 --> 00:05:25.653
But our users are sites specifically.
00:05:25.754 --> 00:05:29.723
I think vendors are failing the sites if they don't advocate for them.
00:05:29.824 --> 00:05:48.824
If we just become order takers and,"Hey, customer A needs this feature, let's just build it." It should be that when someone asks for something or a requirement comes through for your software, you have to build this to accomplish this regulatory feature or this protocol need.
00:05:48.923 --> 00:05:52.184
And we look at that sort of initial version of that idea.
00:05:52.283 --> 00:05:56.163
Like we're failing if we don't go,"Ooh, ouch.
00:05:56.244 --> 00:05:58.774
That would hurt if I was that user.
00:05:58.874 --> 00:06:11.237
Ooh that's a really bad thing for us to add to the to the site's day and the flow of their day." You can translate This, If you think about just normal consumer technology that we use every day.
00:06:11.338 --> 00:06:12.997
So I have a personal example of this.
00:06:13.098 --> 00:06:16.377
We use Microsoft Teams every single day in our job.
00:06:16.478 --> 00:06:22.557
They had a feature in there at some point, which I absolutely loved, which was just the ability to save your message, right?
00:06:22.577 --> 00:06:34.603
If I Saw a message that someone sent to me, I could just click save, and I'm like,"Ah, I know I need to get back to that later." At some point, someone made a decision to remove that feature, and it was horrible for me.
00:06:34.622 --> 00:06:40.326
Now I'm copying and pasting messages into a notepad somewhere just to keep track of them.
00:06:40.427 --> 00:06:47.036
They eventually brought this feature back, but it was a span of a, a year or two where it was missing.
00:06:47.137 --> 00:06:58.286
And you can, of course, go on forums, and you can find endless people complaining about this because someone made a decision high up that I had to absorb the cost and the impact of.
00:06:58.297 --> 00:07:00.357
That had a real impact on my day.
00:07:00.456 --> 00:07:04.036
And the same thing is happening with this clinical trial technology.
00:07:04.137 --> 00:07:15.127
If you go on Reddit, and you go on the clinical research subreddit, and you look in there you can see what people are struggling with with all of this vendor technology.
00:07:15.226 --> 00:07:23.507
And a lot of it is just because we're designing things without their input, without reflecting it back to them and getting their reaction
00:07:23.607 --> 00:07:24.096
Thanks, guys.
00:07:24.096 --> 00:07:25.956
A lot of really interesting points there.
00:07:25.956 --> 00:07:35.487
And, it really does to me center around this, first and foremost, this consideration for what's actually going on at the site level and putting that first.
00:07:35.487 --> 00:07:40.716
And it sounds like such a simple and sensical approach to it, but we know that it's not.
00:07:40.807 --> 00:07:45.228
To Both of your points, but Ashley, you specifically it's really not being done, right?
00:07:45.228 --> 00:07:45.858
We're going...
00:07:45.867 --> 00:07:59.767
A lot of technology is implemented with a technology output or a data output in mind, but doesn't consider how that's going to affect various roles or tasks or workflows at the site and patient level, most importantly there.
00:07:59.767 --> 00:08:18.648
So I think that's a, really important starting point as we look at said technology or, asking ourselves the question, there is a piece of technology that can help us, collect this data or speed this process of the trial faster, theoretically, but then take the step to understand what will that look like then once implemented at the site level.
00:08:18.778 --> 00:08:25.805
And to Expand on that a little bit, back to an earlier point that Ashley made about thinking outside of the boundaries of your product.
00:08:25.906 --> 00:08:35.696
I don't think it's even enough to just say let's just talk to the site and get their feedback." And then we get their feedback, and then we go, Okay, what new button am I gonna add to my product?
00:08:35.696 --> 00:08:43.865
What new feature am I gonna put in there?" We have to think a little bit bigger than that, which is it, it may not just be a button conversation.
00:08:43.875 --> 00:08:52.975
Do I need to add a new button, or do I need to add a new integration to a service or a product that the site is already using in their day-to-day?
00:08:53.076 --> 00:08:59.566
Do I need to make something self-service for them that normally they would have to contact our support about?
00:08:59.666 --> 00:09:09.735
So I don't think it's always about just adding a new button but it's about thinking broader term into what are all of the different solutions that the site is interacting with in their day
00:09:09.836 --> 00:09:10.816
That's exactly right.
00:09:10.816 --> 00:09:20.046
thinking of that broad picture and as you guys had, had both acutely mentioned how does this fit into the macro picture of what's going on at that site is another critical consideration.
00:09:20.046 --> 00:09:27.806
So as you're developing, technology, can you talk a little bit about the broader approach to gathering input from sites during that development?
00:09:27.806 --> 00:09:29.966
Is it something that's very structured?
00:09:29.975 --> 00:09:31.265
Are they informal?
00:09:31.296 --> 00:09:36.576
Is it, usability testing, or are you guys taking a combination of these approaches?
00:09:36.676 --> 00:09:37.956
Yeah, happy to discuss this.
00:09:37.956 --> 00:09:42.806
So I would say our first principle is always discovery before design.
00:09:42.905 --> 00:09:48.686
and I'll add that this is, has to be true even when you think that you already know the answer.
00:09:48.785 --> 00:09:57.936
So this, for me, was, I grew up in this company and working with sites, talking to sites every day from an operational standpoint initially.
00:09:58.035 --> 00:10:03.765
And, 10 years ago, I may have a certain understanding of what life looks like at a site.
00:10:03.865 --> 00:10:08.135
But hey, we're gonna go build a new product or solve a new problem.
00:10:08.235 --> 00:10:16.155
We need to go talk to those sites again, and we need to understand where are they today because everything changes so rapidly.
00:10:16.255 --> 00:10:19.605
What was true one year ago may not be true anymore.
00:10:19.706 --> 00:10:36.216
So we treat site feedback as a sort of strategic product input from the very start to the point where we shouldn't even be taking a pencil and drawing out screens or thinking about what features and buttons we're gonna put in place.
00:10:36.316 --> 00:10:58.515
We should start just by talking to people, getting on the phone, going to meet people face to face, and getting a real sense of who they are and what they're working on and what their day looks like and what is the actual problem that we're trying to solve So that human connection, it should be fueled by a lot of curiosity to get that full picture.
00:10:58.615 --> 00:11:07.255
So what I mean is we may go into an interview with a site and we may have a list of questions or things that we're curious about that we wanna get their answer on.
00:11:07.355 --> 00:11:09.985
But we should be allowed to go down rabbit holes.
00:11:10.056 --> 00:11:15.326
We should be asking questions that allow them to answer outside of the box.
00:11:15.426 --> 00:11:24.306
And when we ask those questions, I think it's very important that we don't try to engineer the answer that we want, which is very tempting, right?
00:11:24.306 --> 00:11:46.306
Which is we come out with a thesis of,"Hey, we think we kinda wanna build this certain type of feature or this product," so what question am I gonna ask so that they'll say the right thing that I can quote that, put that in my PowerPoint, and reflect that back to my leadership team as,"Oh, it's definitely a good idea to build this." We wanna ask questions that get at the hard-hitting truth.
00:11:46.355 --> 00:11:51.875
Sometimes what we do at Signant as we look for people to talk to, we look for volunteers.
00:11:52.135 --> 00:11:56.285
Sometimes We'll get people that'll say,"Oh, this, this site is really nice.
00:11:56.316 --> 00:11:57.676
They're so easy to talk to.
00:11:57.676 --> 00:12:00.155
They would love to talk to you." I'm like,"Awesome," right?
00:12:00.255 --> 00:12:05.895
But we also sometimes get those sites where they say,"Hey, this site is very busy.
00:12:05.995 --> 00:12:07.025
They're tough.
00:12:07.056 --> 00:12:11.186
They are hard on our technology." I wanna talk to those people, right?
00:12:11.206 --> 00:12:12.836
Because they're the critics.
00:12:12.846 --> 00:12:23.296
They're the ones that are gonna, really give us great feedback to find things that, that we didn't even expect, or that we need to take a really hard look at how to solve those problems.
00:12:23.395 --> 00:12:35.235
An example of a type of question that we might ask is imagine that t- you're allowed to to wave a magic wand and tomorrow there's a technology solution for something that you're doing in your day.
00:12:35.336 --> 00:12:36.466
How is it different?
00:12:36.475 --> 00:12:38.046
What does it look like?
00:12:38.145 --> 00:12:41.426
What is the sort of dream solution that you have for yourself?
00:12:41.525 --> 00:12:46.245
And, they may give you an answer that is impossible or purely fantastical.
00:12:46.346 --> 00:12:50.676
But- But there might be some nugget of truth in there that you can take back to your product design.
00:12:50.775 --> 00:12:53.816
So this is all the sort of upfront work that we're doing, right?
00:12:53.826 --> 00:13:02.235
Very early on in the design process, we're talking to people, we're collating feedback, we're looking for trends, we're looking for themes.
00:13:02.336 --> 00:13:12.313
We're trying to diversify the people that we're talking to in terms of their relationship with our company, their spread across the globe.
00:13:12.413 --> 00:13:13.953
Are they new to Signant?
00:13:14.014 --> 00:13:16.293
Have they worked with us for a long time?
00:13:16.394 --> 00:13:17.634
To get that variety.
00:13:17.734 --> 00:13:24.933
Then we take that and then we start to actually ideate and prototype and say, Based on all this feedback, what should we build?
00:13:24.933 --> 00:13:30.933
What do we think this looks like?" With the tools that we have available now, we can rapidly prototype.
00:13:31.033 --> 00:13:44.453
So almost immediately, we can come back to them within a week, two weeks, with a fully functional clickable prototype, and we can use this just to show it to them and say,"Hey, did we get this right?
00:13:44.464 --> 00:13:50.193
Does this look like it would solve your problem, or did we totally miss the mark?" And we can also allow them to use it.
00:13:50.203 --> 00:13:51.783
We can allow them to click through it.
00:13:51.823 --> 00:13:59.096
We can observe them and do usability testing, see where did they get tripped up and that may give us clues about what we built.
00:13:59.197 --> 00:14:23.419
But this rapid prototyping just allows us to have this iterative relationship with the site so that all along the way, they're shaping and guiding the solution towards something that by the time it gets into their hands or the hands of another site, those users feel like,"Oh, okay, this was actually designed for someone like me in mind."
00:14:23.519 --> 00:14:24.070
Thanks, David.
00:14:24.070 --> 00:14:26.039
A lot of really interesting points there.
00:14:26.039 --> 00:14:27.259
A lot to tease out of that.
00:14:27.259 --> 00:14:33.860
But I think the message is there is not any one specific approach that is better than the other.
00:14:33.860 --> 00:14:37.940
It's based on the direction, the product, what you need.
00:14:38.039 --> 00:14:46.289
There are different approaches you should take, and some cautions around each of those approaches that help you, eliminate any sort of bias that might creep in.
00:14:46.289 --> 00:15:05.470
And I think having those different again, having those different approaches also supports, a reduction in bias and making sure that what you're getting is truly the feedback, good or bad, that you need to improve the product or make it work at the site level, instead of trying to push a narrative or, support that.
00:15:05.470 --> 00:15:07.440
And you guys kinda said it at the beginning, right?
00:15:07.500 --> 00:15:13.870
Not being afraid of going back to the drawing board and failing a little bit in that space, I think is is critically important to that.
00:15:13.970 --> 00:15:19.279
And David, I'd go to you again for this next question here, and then maybe Ashley, if you wanna chime in as well.
00:15:19.289 --> 00:15:27.240
I understand that you guys ran a series of, specific feedback sessions with your sites on the RaterStation platform that you had mentioned earlier.
00:15:27.240 --> 00:15:33.350
So can you talk a little bit about what you learned and maybe some of the things that might have surprised you that came out of those sessions?
00:15:33.450 --> 00:15:33.789
Yeah.
00:15:33.820 --> 00:15:49.830
I'm gonna actually just jump ahead of David,'cause I think first, just for context for those listening, RaterStation at Signant is an eCall platform that we use primarily for the site-based experience and usually in a CNS space to administer clinical rating scales during that visit.
00:15:49.860 --> 00:15:55.419
It captures your data along with an integrated audio/video evidence capture as well.
00:15:55.519 --> 00:15:57.750
So just for context, that's what RaterStation is.
00:15:57.759 --> 00:16:01.409
And I'm gonna lead with the surprise, David, and you can fill in the context.
00:16:01.710 --> 00:16:18.123
For years So David and I obviously have a long tenure at Signant Health both starting in operations and maturing into our product organization, and for a long time, we as an organization believed that having the capability to be fully offline was a huge differentiator.
00:16:18.222 --> 00:16:20.043
We really thought that this was key.
00:16:20.143 --> 00:16:24.773
Lots of our customers and sales opportunities led with that dialogue.
00:16:24.873 --> 00:16:46.743
But when we actually spent time just in the past three years really digging into that core marquee product, because RaterStation is very important to Signant, we actually figured out by talking to the site users that some of the symptoms of being offline first were actually compounding some of their biggest issues or their day-to-day experience with that technology.
00:16:46.842 --> 00:16:49.682
So it definitely wasn't the strength we thought it was
00:16:49.783 --> 00:16:58.602
And as we interviewed people and did all of that discovery that we talked about, I think what happened is that our perception widened a lot.
00:16:58.602 --> 00:17:01.763
I would say that was the surprise element of it.
00:17:01.832 --> 00:17:06.772
It's very tempting to you're working on software when you're mocking things up.
00:17:06.803 --> 00:17:16.413
You're thinking about an individual user that's clicking through a bunch of screens that you designed, and can they get from point A to point B?
00:17:16.423 --> 00:17:20.712
And if they can, and it's designed really well, and it looks pretty, then great.
00:17:20.813 --> 00:17:23.292
that's not enough, especially in this space.
00:17:23.393 --> 00:17:28.873
We're talking about somebody who is at a busy trial site who...
00:17:28.972 --> 00:17:32.853
one example is something called simultaneous administration.
00:17:32.952 --> 00:17:40.423
So the participant and the observer, or sometimes called the caregiver, comes into the site on the same day.
00:17:40.522 --> 00:17:42.833
They both need to be interviewed.
00:17:42.932 --> 00:17:58.125
In an offline first solution where this participant's record is locked to an individual piece of hardware, I now have to wait for the participant's interview to be done so that I can interview the caregiver.
00:17:58.134 --> 00:18:02.765
And while we're doing these things, the other person is sitting in a waiting room somewhere.
00:18:02.865 --> 00:18:05.644
And this, this visit day is already super long for them.
00:18:05.654 --> 00:18:12.924
Why do they wanna sit around waiting and wasting more time when there are staff available to handle both of these people simultaneously?
00:18:13.025 --> 00:18:15.154
So that was one thing that we learned.
00:18:15.255 --> 00:18:16.855
Interrupted connection, right?
00:18:16.954 --> 00:18:18.474
They need to shut their laptop.
00:18:18.494 --> 00:18:19.914
They need to move rooms.
00:18:20.015 --> 00:18:23.845
They need to deal with a recording being interrupted.
00:18:23.944 --> 00:18:27.835
They need flexibility to handle paper scale transcription.
00:18:27.884 --> 00:18:36.315
If for some reason they're not able to get ahold of the technology, they need to write it down on a piece of paper and then get it back into the system in an elegant way.
00:18:36.414 --> 00:18:53.224
So there's all this sort of context or activity that's happening in the real world outside of the context of your screen of your application that our perception grew and that really, I think, helped us inform where we were going next.
00:18:53.265 --> 00:18:58.954
Another piece of this is the fact that Cygnet is just one of many vendors that they are dealing with.
00:18:59.055 --> 00:19:07.785
As a vendor we like to think that we're the only thing that the user is thinking about when they wake up and turn their computer on in the morning.
00:19:07.884 --> 00:19:09.625
We're just another browser tab.
00:19:09.634 --> 00:19:12.944
We're another vendor, another solution that they're dealing with.
00:19:13.045 --> 00:19:22.625
And we also heard that older thinking may have been that online is Maybe not that great because maybe that not many sites have great connectivity.
00:19:22.724 --> 00:19:24.825
We went out and we retested that.
00:19:24.865 --> 00:19:28.095
We asked, How do you guys feel about an online solution?
00:19:28.105 --> 00:19:39.085
How do you feel about this being a bookmark in your browser rather than a piece of hardware on your shelf?" And what we heard directly from sites was,"We're not concerned about that anymore.
00:19:39.184 --> 00:19:46.875
We want it to be online." So as we got all of this information, the picture started to click into place.
00:19:46.944 --> 00:19:48.365
Our perception widened.
00:19:48.444 --> 00:20:09.545
We gathered all of this detail, and we said,"Okay, the stability of an offline modality is a mismatched jigsaw piece that doesn't fit in with the site stay." So suddenly we pivot to something, a solution that was online first, that's built on a real insight and not an assumption about what the site needs
00:20:09.644 --> 00:20:10.384
Thank you both.
00:20:10.484 --> 00:20:29.585
Again, I think that the really interesting thing about that approach, which is it seems so straightforward and sensical, but it's that taking understanding first and building or reiterating later, and not coming out with something that is final or considered final and forcing it upon the site.
00:20:29.585 --> 00:20:30.545
I think that's really important.
00:20:30.545 --> 00:20:33.065
You nailed it right there on the head, David, right at the end there.
00:20:33.065 --> 00:20:40.625
So then where do sites and sponsor priorities sometimes come into tension when developing technology like this?
00:20:40.724 --> 00:20:51.241
Because you guys, Realistically, oftentimes you're sitting in the middle of what w- the needs and the priorities of these two different sides of the same clinical trial here.
00:20:51.241 --> 00:20:58.231
And I guess how do you then effectively navigate some of those trade-offs as you're trying to do some of the things that you've just described?
00:20:58.342 --> 00:21:00.602
This, this absolutely happens.
00:21:00.836 --> 00:21:10.307
So big areas where it happens are security, regulatory stuff around audit trails, and especially with protocol rigor.
00:21:10.406 --> 00:21:22.115
So the sponsor, of course is gonna tend to lean towards make it more robust make it more locked down and bulletproof from a regulatory and security perspective.
00:21:22.214 --> 00:21:26.494
Of course, those types of decisions can lead to site friction.
00:21:26.595 --> 00:21:32.535
The site is gonna be leaning more towards I want efficiency, I want ease of use.
00:21:32.575 --> 00:21:40.454
I want the technology to get out of my way so that I can focus on the participant, so I can focus on the data collection.
00:21:40.555 --> 00:21:42.714
And both are correct, both are right.
00:21:42.805 --> 00:21:45.204
It's about finding a balance.
00:21:45.305 --> 00:21:48.085
So how does Signant navigate that?
00:21:48.184 --> 00:21:51.914
I think a big part of it is just weighing the site impact early.
00:21:52.015 --> 00:21:57.095
A lot of what we've been talking about here, getting the site's input from day one.
00:21:57.244 --> 00:22:07.144
Example is customer comes to you with new requirement for something that is a sort of heavy regulatory or protocol type enforcement.
00:22:07.244 --> 00:22:12.704
We should immediately be thinking about, okay, what, what burden does this place on the site?
00:22:12.805 --> 00:22:14.795
What is the site experience with this?
00:22:14.894 --> 00:22:16.125
So how do we deal with that?
00:22:16.134 --> 00:22:19.714
So we want excellence in product design.
00:22:19.815 --> 00:22:35.694
So within the constraints that we are given by the regulations, by the protocol, we now need to solve how can we do this in a way that is least burdensome to the site with still honoring the spirit of the law.
00:22:35.795 --> 00:22:37.914
So we dealt with this recently.
00:22:37.964 --> 00:22:44.174
So the way that we solve these, these sort of tensions is by weighing the site impact early.
00:22:44.275 --> 00:22:52.744
So very early on we are thinking about how does what requirement came through to us, impact the site's day-to-day use?
00:22:52.845 --> 00:22:55.154
And is it adding burden to them?
00:22:55.255 --> 00:23:00.315
One way that we deal with this is by making sure that we have an excellent design.
00:23:00.414 --> 00:23:05.674
So the way that we did this recently is through a feature called Principal Investigator Review.
00:23:05.775 --> 00:23:17.535
This is a feature where a regulatory requirement requires us to make sure that the principal investigator can individually review each visit that comes through for a study.
00:23:17.634 --> 00:23:24.654
This is a heavy process, a lot of data for them to parse through on a very frequent rolling basis.
00:23:24.755 --> 00:23:37.305
So we needed to prototype this solution very fast for the customer, and we were able to, with their feedback and with site input, really dial that design in.
00:23:37.404 --> 00:23:50.285
And even though, yes, it's not fun for the principal investigator to have to review all of this data, how can we make that process as painless for them as possible, the most user-friendly experience?
00:23:50.384 --> 00:23:53.474
That's, I think, a, a big guiding principle for us.
00:23:53.575 --> 00:23:59.535
And another thing that we do is what I would call regulatory interpretation and negotiation.
00:23:59.634 --> 00:24:18.875
So Signant has a great quality department, and as customers come through with different regulations and say, blanket statement,"Build me this feature because this regulation says X," we'll take that to our quality department and say,"Do we really need to build it that black and white, or is there some leeway?
00:24:18.875 --> 00:24:39.894
Is there some, some room here to make it a little bit more user-friendly while still adhering to the spirit of the requirement?" And so we're able to come to some compromises there, where we're still hitting the main asks of the customer but doing it in a way that sites appreciate and sites feel that they were thoughtfully made.
00:24:39.994 --> 00:24:53.296
I think the ultimate goal though here is that these upstream decisions that sometimes have to be made in studies and from customers don't feel like a thoughtless surprise that lands on the site's doorstep.
00:24:53.395 --> 00:25:02.806
That one day there's a new feature or a new requirement there that just feels like a terrible experience for them that they now have to suffer through.
00:25:02.905 --> 00:25:08.817
It should feel thoughtfully designed and something that, that they feel that they had input into
00:25:08.917 --> 00:25:09.557
Thanks, David.
00:25:09.557 --> 00:25:16.867
And if nothing else there's so mu- so much to tease out of your responses here today and what's been going on, and a lot of insight into the process.
00:25:16.897 --> 00:25:19.117
It's an understanding of that process.
00:25:19.218 --> 00:25:43.817
Having a little, we'll say, empathy at the site level in particular for the nuance and the different areas that need to be involved in this decision-making, I think hopefully gives truly the sites a little bit of understanding and patience and the willingness to work effectively together on on, on advancing this instead of simply resisting it for a variety of different reasons.
00:25:43.917 --> 00:25:48.248
So Ashley I wanna come back to you here as we begin to conclude our conversation here.
00:25:48.248 --> 00:25:55.597
So what would you say to other vendors, other service providers about involving sites earlier in the development process?
00:25:55.597 --> 00:25:58.877
You both did a great job of articulating some, some good examples there.
00:25:58.877 --> 00:26:04.468
So maybe, succinctly or in summary really bring home a couple of the key pieces of advice.
00:26:04.567 --> 00:26:05.117
For sure.
00:26:05.218 --> 00:26:06.688
Curiosity is king, right?
00:26:06.728 --> 00:26:08.938
You wanna come curious, not opinionated.
00:26:09.038 --> 00:26:13.857
If you walk into a site conversation with that assumption, it's just an affirmation session.
00:26:13.857 --> 00:26:15.248
You're not gonna learn anything.
00:26:15.347 --> 00:26:22.805
So I know this is simple or maybe seen as a little pedantic but it is about listening and not presenting.
00:26:22.815 --> 00:26:28.845
You wanna think of outside the boundaries of what you know as the product and think about the folks using it.
00:26:29.125 --> 00:26:37.421
when we're talking about site advocacy, I couldn't Create a finer point around this You need to account for when the user's pathway isn't so happy, right?
00:26:37.480 --> 00:26:39.540
Connectivity failures will happen.
00:26:39.641 --> 00:26:42.411
transcription on paper will need to occur.
00:26:42.510 --> 00:26:49.891
Someone will show up late for a visit, and there'll be a continuity break flow for the sites as they're re-moving everyone to a different study room.
00:26:49.990 --> 00:26:50.181
It...
00:26:50.280 --> 00:26:51.471
those things happen.
00:26:51.570 --> 00:27:02.181
So though we all really are desirous of the most frictionless day possible that we could imagine, you do need to think about, how can you enable the user to get through?
00:27:02.280 --> 00:27:04.770
That's really the, the crux of what we're trying to do.
00:27:04.871 --> 00:27:07.391
Advocacy and autonomy, I think, go hand in hand.
00:27:07.401 --> 00:27:11.951
The more autonomous your sites and raters are, the more advocacy you've built into the product.
00:27:12.050 --> 00:27:17.050
So what can you amplify that may already be in their toolbox, to David's point earlier.
00:27:17.060 --> 00:27:21.921
Sometimes it's not layering another technology, another dose of change management.
00:27:22.020 --> 00:27:27.701
It's truly thinking about, how can you work in concert with the ecosystem that already exists for them?
00:27:27.800 --> 00:27:31.000
And finally, we've given a lot of good credible examples.
00:27:31.030 --> 00:27:34.340
I would also say this, continuity is important.
00:27:34.441 --> 00:27:39.290
Part of these dialogues aren't just, okay, sit with them and really listen, and then design.
00:27:39.290 --> 00:27:40.800
I know that sounds really flowery.
00:27:40.901 --> 00:27:41.090
It...
00:27:41.191 --> 00:27:47.800
The principle is understand your current state within the ecosystem of that actual site user.
00:27:47.901 --> 00:27:50.010
Think about where you sit.
00:27:50.111 --> 00:27:51.330
Have a dialogue with them.
00:27:51.340 --> 00:27:52.490
Listen to pain points.
00:27:52.490 --> 00:27:55.070
Listen to problems they have that no one's trying to solve.
00:27:55.240 --> 00:28:02.105
That's all important, But if you've ever been in a relationship, voicing your problems to someone and having them listen, that's therapy.
00:28:02.205 --> 00:28:06.145
Having them come back with a response to that, that's a problem solver.
00:28:06.155 --> 00:28:10.526
And I think vendors in this space really should feel called to arms here.
00:28:10.625 --> 00:28:14.165
So the continuity I'm speaking of is go back to those folks.
00:28:14.195 --> 00:28:18.855
Show them the current state that you outlined after the initial discussion with them.
00:28:18.955 --> 00:28:31.256
Show them their new dream state or at least the new state which demonstrates that you didn't just hear what they said, that what they said drove actions in your actual design process and your feature build.
00:28:31.355 --> 00:28:32.766
An excellent point, Ashley.
00:28:32.766 --> 00:28:45.385
We talk a lot about how important it is that we close that feedback loop, that we bring and help the sites understand that what they told us, we listened to, we made changes based on, and then we're telling you, right?
00:28:45.385 --> 00:28:48.855
We're showing you what we've done as a result of your direct feedback.
00:28:48.855 --> 00:28:50.705
So I think that's a, an, an excellent point.
00:28:50.705 --> 00:28:56.046
It's great to hear that that's a focus of how you all develop technology solutions.
00:28:56.046 --> 00:28:56.925
Thank you for sharing that.
00:28:56.925 --> 00:28:58.006
I wish we had more time.
00:28:58.006 --> 00:28:59.296
We could probably talk about this.
00:28:59.306 --> 00:29:03.986
It's such a pressing issue at the site level, and both of you shared so many great insights into this.
00:29:04.046 --> 00:29:08.925
And really a lot of considerations for every different constituency group to think about, right?
00:29:08.935 --> 00:29:15.175
Other service providers, sponsors and CROs, but also sites as we're approaching this from a holistic and a relationship based approach.
00:29:15.175 --> 00:29:18.986
So thank you both for your time today and for engaging on this topic.
00:29:19.086 --> 00:29:19.596
Thank you.
00:29:19.615 --> 00:29:25.205
best product decisions come from the people living the problem, not just us speculating from a distance.
00:29:25.306 --> 00:29:26.885
Signant's leaning into that for real.
00:29:26.885 --> 00:29:31.066
It drove us to dynamically rethink a core marquee offering.
00:29:31.086 --> 00:29:36.425
So excited for where that takes us, not just as Signant, but as a, a market.
00:29:36.526 --> 00:29:41.885
Because I, I think that if you let your user surprise you it can only keep getting better
00:29:41.986 --> 00:29:42.885
Yeah, absolutely.
00:29:42.885 --> 00:29:50.046
It's been a pleasure, and I think I think that's what I'm excited about g- generally with technology but specifically in this space, right?
00:29:50.145 --> 00:29:57.905
There's a sort of bright future of these things and these tools that sites are using continuing to get better, continuing to iterate.
00:29:58.036 --> 00:30:04.195
and that will be true as long as we are thoughtful about what we're building and what we're designing.
00:30:04.296 --> 00:30:05.326
It's a bright future.
00:30:05.425 --> 00:30:06.395
I couldn't agree more.
00:30:06.395 --> 00:30:07.066
Thank you both.
00:30:07.066 --> 00:30:08.645
And again, thank you for your time today.
00:30:08.746 --> 00:30:30.476
And for those that are listening, I also wanna make sure that you take some time to check out other site-focused resources on our website, myscrs.org, other podcasts covering great topics like this one, excellent webinar opportunities, information about opportunities to get together at our global site solution summits, and articles centered around technology and how we move forward with it together.
00:30:30.476 --> 00:30:34.016
But for now, thanks for listening, for tuning in, and until next time.
00:00:00.100 --> 00:00:04.389
Hello, and welcome to SCRS Talks, provided by the Society for Clinical Research Sites.
00:00:04.440 --> 00:00:17.719
I'm Jimmy Bechtel, the chief site success officer with the Society, and today I'm joined by Ashley O'Brien, who is the executive director of product management, and David Steckler, who is the director of product management, with Signant Health.
00:00:17.750 --> 00:00:19.460
It's great to have you both here with us.
00:00:19.469 --> 00:00:31.352
Really excited to talk to a technology company who's focused on developing technology with sites and not just on sites, or on top of them or in force against them, right?
00:00:31.352 --> 00:00:38.701
We talk a lot about how important it is that as we're developing solutions and implementing technology, that we bring sites along with us.
00:00:38.712 --> 00:00:42.942
So I'm excited to dig into this topic with you all and tease out a little bit of how you do that.
00:00:42.962 --> 00:00:47.822
But before we get into that, I'd love for the audience to learn a little bit more about each of you.
00:00:47.822 --> 00:00:50.591
So if you guys could expand on your introductions.
00:00:50.612 --> 00:00:52.292
Ashley, love to start with you.
00:00:52.311 --> 00:00:53.682
Tell us a little bit more about yourself.
00:00:53.781 --> 00:00:54.042
Yeah.
00:00:54.042 --> 00:00:54.962
Thanks, Jimmy.
00:00:55.012 --> 00:00:55.351
Yeah.
00:00:55.351 --> 00:00:58.332
So Ashley O'Brien, executive director at Signant Health.
00:00:58.432 --> 00:00:59.962
I've been here for 16 years.
00:01:00.012 --> 00:01:02.671
That, that might qualify me in a very unique way.
00:01:02.771 --> 00:01:11.421
But largely, my focus and tenure at Signant has been focused in the CNS technology response that Signant provides to the market.
00:01:11.522 --> 00:01:18.971
This is primarily around sort of quality assurances that our customers can get through the technology implementations within those clinical trials.
00:01:18.981 --> 00:01:31.531
So this could be something as simple as rater training or even more complex, such as blinded analytics and support of downstream quality checks with third-party consultants that could do a data review.
00:01:31.632 --> 00:01:41.932
So being in this space for this long, I think I've definitely seen some, some emergent technologies that have hit the mark and those that have missed the mark when it comes to our site users.
00:01:42.031 --> 00:01:42.591
David?
00:01:42.691 --> 00:01:43.081
Hi.
00:01:43.132 --> 00:01:47.831
Yeah, so I've been with Signant also for a long time, not quite as long, about 13 years.
00:01:47.932 --> 00:01:53.371
And I've also been focused on this space and specifically this product called RaiderStation.
00:01:53.382 --> 00:01:59.162
So I started out delivering RaiderStation to sites, getting them set up, helping them.
00:01:59.262 --> 00:02:05.850
And now I'm in a position where I'm actually building the RaiderStation product, which is our Raider focused product.
00:02:05.900 --> 00:02:14.911
And yeah, just really excited to, to be working on this technology that I think has a great opportunity to address a lot of the things that we're gonna talk about today.
00:02:15.010 --> 00:02:15.570
I am as well.
00:02:15.570 --> 00:02:16.211
Thank you both.
00:02:16.241 --> 00:02:20.911
And again particularly excited to talk through this subject with you guys.
00:02:21.010 --> 00:02:25.061
As I had mentioned, technology comes up a lot as a pain point in our community.
00:02:25.061 --> 00:02:28.901
It's consistently right at the top of some of the challenges site face.
00:02:28.901 --> 00:02:31.580
We've got data and anecdotes to support that.
00:02:31.640 --> 00:02:44.651
It's been a problem and a challenge for a long time, but really the infusion of technology and decentralization in clinical trials as sparked by COVID the COVID pandemic has really put that at the forefront of a lot of the conversations we've had since then.
00:02:44.651 --> 00:02:54.670
So from where you each sit and, Ashley, maybe starting with you here, where do vendors typically get it wrong then when we're designing technology solutions for sites?
00:02:54.770 --> 00:02:55.251
Yeah.
00:02:55.350 --> 00:03:01.061
Sites, I think the number one problem is sites are often not the first thought and that makes sense, right?
00:03:01.091 --> 00:03:10.079
A lot of us don't sell directly to sites, and so a lot of the vendors in the space struggle with finding the balance between those different persona needs.
00:03:10.179 --> 00:03:21.179
I think the core mistake is that we design within the boundaries of our own software or that customer relationship or business strategies, and we're not considering the boundaries of the site's actual day.
00:03:21.278 --> 00:03:27.348
You can build a genuinely excellent best-in-class application looking at the feature set alone.
00:03:27.449 --> 00:03:38.019
You can, and still get it wrong, because I think you've never asked, What does this technology have to coexist with?" And I don't mean that just with regards to other technologies.
00:03:38.058 --> 00:03:41.079
I think literally we're looking at other vendor solutions, yes.
00:03:41.179 --> 00:03:46.859
But also, what is the context of the site and the staff and the explicit visit day?
00:03:46.959 --> 00:03:58.329
So questions that really matter to my team, if you think about where we position ourselves a little bit differently since COVID is what did the site do right before opening the device or the software application?
00:03:58.338 --> 00:04:01.098
What else is running on another device at the same time?
00:04:01.199 --> 00:04:04.848
How many other vendors and systems are also in play?
00:04:04.868 --> 00:04:07.278
And these aren't direct competitors necessarily.
00:04:07.278 --> 00:04:10.479
They're complementary or amplification type of technologies.
00:04:10.579 --> 00:04:15.699
So is this just one more thing I'm introducing that adds to that site's complexity?
00:04:15.799 --> 00:04:22.778
If the site is waiting for a notification or a prompt for an outcome after they submit data, is it clear to them that they're waiting?
00:04:22.879 --> 00:04:23.559
How long?
00:04:23.658 --> 00:04:26.949
And does that flow with their actual study day or does it obscure it?
00:04:27.048 --> 00:04:40.978
So I think at the end of the day what we get wrong typically in this space is we aren't appreciative of the fact that sites are juggling a lot, not just different technologies and vendors, but there's a lot of activities that happen above and beyond just the transaction with your actual solution.
00:04:41.115 --> 00:04:50.005
so they don't want one study's experience trapped on this piece of hardware in a separate login per each device shipped from each of these different vendors.
00:04:50.105 --> 00:04:58.798
That administrative overhead of another box to keep charged on the shelf is sometimes the straw that breaks the camel's back, so to speak.
00:04:58.898 --> 00:05:09.235
So to be fair, none of us in this space, so Signant Health or any of the other vendors in the technology space here, none of us want that, but every workaround compounds.
00:05:09.336 --> 00:05:16.896
And honestly, those site points that I mentioned, that's what happens when you focus on meeting only one part of the narrative, which is the customers.
00:05:16.995 --> 00:05:17.406
David?
00:05:17.555 --> 00:05:17.795
Yeah.
00:05:17.975 --> 00:05:22.454
I think To underline this part about the sponsor is the paying customer here.
00:05:22.553 --> 00:05:25.653
But our users are sites specifically.
00:05:25.754 --> 00:05:29.723
I think vendors are failing the sites if they don't advocate for them.
00:05:29.824 --> 00:05:48.824
If we just become order takers and,"Hey, customer A needs this feature, let's just build it." It should be that when someone asks for something or a requirement comes through for your software, you have to build this to accomplish this regulatory feature or this protocol need.
00:05:48.923 --> 00:05:52.184
And we look at that sort of initial version of that idea.
00:05:52.283 --> 00:05:56.163
Like we're failing if we don't go,"Ooh, ouch.
00:05:56.244 --> 00:05:58.774
That would hurt if I was that user.
00:05:58.874 --> 00:06:11.237
Ooh that's a really bad thing for us to add to the to the site's day and the flow of their day." You can translate This, If you think about just normal consumer technology that we use every day.
00:06:11.338 --> 00:06:12.997
So I have a personal example of this.
00:06:13.098 --> 00:06:16.377
We use Microsoft Teams every single day in our job.
00:06:16.478 --> 00:06:22.557
They had a feature in there at some point, which I absolutely loved, which was just the ability to save your message, right?
00:06:22.577 --> 00:06:34.603
If I Saw a message that someone sent to me, I could just click save, and I'm like,"Ah, I know I need to get back to that later." At some point, someone made a decision to remove that feature, and it was horrible for me.
00:06:34.622 --> 00:06:40.326
Now I'm copying and pasting messages into a notepad somewhere just to keep track of them.
00:06:40.427 --> 00:06:47.036
They eventually brought this feature back, but it was a span of a, a year or two where it was missing.
00:06:47.137 --> 00:06:58.286
And you can, of course, go on forums, and you can find endless people complaining about this because someone made a decision high up that I had to absorb the cost and the impact of.
00:06:58.297 --> 00:07:00.357
That had a real impact on my day.
00:07:00.456 --> 00:07:04.036
And the same thing is happening with this clinical trial technology.
00:07:04.137 --> 00:07:15.127
If you go on Reddit, and you go on the clinical research subreddit, and you look in there you can see what people are struggling with with all of this vendor technology.
00:07:15.226 --> 00:07:23.507
And a lot of it is just because we're designing things without their input, without reflecting it back to them and getting their reaction
00:07:23.607 --> 00:07:24.096
Thanks, guys.
00:07:24.096 --> 00:07:25.956
A lot of really interesting points there.
00:07:25.956 --> 00:07:35.487
And, it really does to me center around this, first and foremost, this consideration for what's actually going on at the site level and putting that first.
00:07:35.487 --> 00:07:40.716
And it sounds like such a simple and sensical approach to it, but we know that it's not.
00:07:40.807 --> 00:07:45.228
To Both of your points, but Ashley, you specifically it's really not being done, right?
00:07:45.228 --> 00:07:45.858
We're going...
00:07:45.867 --> 00:07:59.767
A lot of technology is implemented with a technology output or a data output in mind, but doesn't consider how that's going to affect various roles or tasks or workflows at the site and patient level, most importantly there.
00:07:59.767 --> 00:08:18.648
So I think that's a, really important starting point as we look at said technology or, asking ourselves the question, there is a piece of technology that can help us, collect this data or speed this process of the trial faster, theoretically, but then take the step to understand what will that look like then once implemented at the site level.
00:08:18.778 --> 00:08:25.805
And to Expand on that a little bit, back to an earlier point that Ashley made about thinking outside of the boundaries of your product.
00:08:25.906 --> 00:08:35.696
I don't think it's even enough to just say let's just talk to the site and get their feedback." And then we get their feedback, and then we go, Okay, what new button am I gonna add to my product?
00:08:35.696 --> 00:08:43.865
What new feature am I gonna put in there?" We have to think a little bit bigger than that, which is it, it may not just be a button conversation.
00:08:43.875 --> 00:08:52.975
Do I need to add a new button, or do I need to add a new integration to a service or a product that the site is already using in their day-to-day?
00:08:53.076 --> 00:08:59.566
Do I need to make something self-service for them that normally they would have to contact our support about?
00:08:59.666 --> 00:09:09.735
So I don't think it's always about just adding a new button but it's about thinking broader term into what are all of the different solutions that the site is interacting with in their day
00:09:09.836 --> 00:09:10.816
That's exactly right.
00:09:10.816 --> 00:09:20.046
thinking of that broad picture and as you guys had, had both acutely mentioned how does this fit into the macro picture of what's going on at that site is another critical consideration.
00:09:20.046 --> 00:09:27.806
So as you're developing, technology, can you talk a little bit about the broader approach to gathering input from sites during that development?
00:09:27.806 --> 00:09:29.966
Is it something that's very structured?
00:09:29.975 --> 00:09:31.265
Are they informal?
00:09:31.296 --> 00:09:36.576
Is it, usability testing, or are you guys taking a combination of these approaches?
00:09:36.676 --> 00:09:37.956
Yeah, happy to discuss this.
00:09:37.956 --> 00:09:42.806
So I would say our first principle is always discovery before design.
00:09:42.905 --> 00:09:48.686
and I'll add that this is, has to be true even when you think that you already know the answer.
00:09:48.785 --> 00:09:57.936
So this, for me, was, I grew up in this company and working with sites, talking to sites every day from an operational standpoint initially.
00:09:58.035 --> 00:10:03.765
And, 10 years ago, I may have a certain understanding of what life looks like at a site.
00:10:03.865 --> 00:10:08.135
But hey, we're gonna go build a new product or solve a new problem.
00:10:08.235 --> 00:10:16.155
We need to go talk to those sites again, and we need to understand where are they today because everything changes so rapidly.
00:10:16.255 --> 00:10:19.605
What was true one year ago may not be true anymore.
00:10:19.706 --> 00:10:36.216
So we treat site feedback as a sort of strategic product input from the very start to the point where we shouldn't even be taking a pencil and drawing out screens or thinking about what features and buttons we're gonna put in place.
00:10:36.316 --> 00:10:58.515
We should start just by talking to people, getting on the phone, going to meet people face to face, and getting a real sense of who they are and what they're working on and what their day looks like and what is the actual problem that we're trying to solve So that human connection, it should be fueled by a lot of curiosity to get that full picture.
00:10:58.615 --> 00:11:07.255
So what I mean is we may go into an interview with a site and we may have a list of questions or things that we're curious about that we wanna get their answer on.
00:11:07.355 --> 00:11:09.985
But we should be allowed to go down rabbit holes.
00:11:10.056 --> 00:11:15.326
We should be asking questions that allow them to answer outside of the box.
00:11:15.426 --> 00:11:24.306
And when we ask those questions, I think it's very important that we don't try to engineer the answer that we want, which is very tempting, right?
00:11:24.306 --> 00:11:46.306
Which is we come out with a thesis of,"Hey, we think we kinda wanna build this certain type of feature or this product," so what question am I gonna ask so that they'll say the right thing that I can quote that, put that in my PowerPoint, and reflect that back to my leadership team as,"Oh, it's definitely a good idea to build this." We wanna ask questions that get at the hard-hitting truth.
00:11:46.355 --> 00:11:51.875
Sometimes what we do at Signant as we look for people to talk to, we look for volunteers.
00:11:52.135 --> 00:11:56.285
Sometimes We'll get people that'll say,"Oh, this, this site is really nice.
00:11:56.316 --> 00:11:57.676
They're so easy to talk to.
00:11:57.676 --> 00:12:00.155
They would love to talk to you." I'm like,"Awesome," right?
00:12:00.255 --> 00:12:05.895
But we also sometimes get those sites where they say,"Hey, this site is very busy.
00:12:05.995 --> 00:12:07.025
They're tough.
00:12:07.056 --> 00:12:11.186
They are hard on our technology." I wanna talk to those people, right?
00:12:11.206 --> 00:12:12.836
Because they're the critics.
00:12:12.846 --> 00:12:23.296
They're the ones that are gonna, really give us great feedback to find things that, that we didn't even expect, or that we need to take a really hard look at how to solve those problems.
00:12:23.395 --> 00:12:35.235
An example of a type of question that we might ask is imagine that t- you're allowed to to wave a magic wand and tomorrow there's a technology solution for something that you're doing in your day.
00:12:35.336 --> 00:12:36.466
How is it different?
00:12:36.475 --> 00:12:38.046
What does it look like?
00:12:38.145 --> 00:12:41.426
What is the sort of dream solution that you have for yourself?
00:12:41.525 --> 00:12:46.245
And, they may give you an answer that is impossible or purely fantastical.
00:12:46.346 --> 00:12:50.676
But- But there might be some nugget of truth in there that you can take back to your product design.
00:12:50.775 --> 00:12:53.816
So this is all the sort of upfront work that we're doing, right?
00:12:53.826 --> 00:13:02.235
Very early on in the design process, we're talking to people, we're collating feedback, we're looking for trends, we're looking for themes.
00:13:02.336 --> 00:13:12.313
We're trying to diversify the people that we're talking to in terms of their relationship with our company, their spread across the globe.
00:13:12.413 --> 00:13:13.953
Are they new to Signant?
00:13:14.014 --> 00:13:16.293
Have they worked with us for a long time?
00:13:16.394 --> 00:13:17.634
To get that variety.
00:13:17.734 --> 00:13:24.933
Then we take that and then we start to actually ideate and prototype and say, Based on all this feedback, what should we build?
00:13:24.933 --> 00:13:30.933
What do we think this looks like?" With the tools that we have available now, we can rapidly prototype.
00:13:31.033 --> 00:13:44.453
So almost immediately, we can come back to them within a week, two weeks, with a fully functional clickable prototype, and we can use this just to show it to them and say,"Hey, did we get this right?
00:13:44.464 --> 00:13:50.193
Does this look like it would solve your problem, or did we totally miss the mark?" And we can also allow them to use it.
00:13:50.203 --> 00:13:51.783
We can allow them to click through it.
00:13:51.823 --> 00:13:59.096
We can observe them and do usability testing, see where did they get tripped up and that may give us clues about what we built.
00:13:59.197 --> 00:14:23.419
But this rapid prototyping just allows us to have this iterative relationship with the site so that all along the way, they're shaping and guiding the solution towards something that by the time it gets into their hands or the hands of another site, those users feel like,"Oh, okay, this was actually designed for someone like me in mind."
00:14:23.519 --> 00:14:24.070
Thanks, David.
00:14:24.070 --> 00:14:26.039
A lot of really interesting points there.
00:14:26.039 --> 00:14:27.259
A lot to tease out of that.
00:14:27.259 --> 00:14:33.860
But I think the message is there is not any one specific approach that is better than the other.
00:14:33.860 --> 00:14:37.940
It's based on the direction, the product, what you need.
00:14:38.039 --> 00:14:46.289
There are different approaches you should take, and some cautions around each of those approaches that help you, eliminate any sort of bias that might creep in.
00:14:46.289 --> 00:15:05.470
And I think having those different again, having those different approaches also supports, a reduction in bias and making sure that what you're getting is truly the feedback, good or bad, that you need to improve the product or make it work at the site level, instead of trying to push a narrative or, support that.
00:15:05.470 --> 00:15:07.440
And you guys kinda said it at the beginning, right?
00:15:07.500 --> 00:15:13.870
Not being afraid of going back to the drawing board and failing a little bit in that space, I think is is critically important to that.
00:15:13.970 --> 00:15:19.279
And David, I'd go to you again for this next question here, and then maybe Ashley, if you wanna chime in as well.
00:15:19.289 --> 00:15:27.240
I understand that you guys ran a series of, specific feedback sessions with your sites on the RaterStation platform that you had mentioned earlier.
00:15:27.240 --> 00:15:33.350
So can you talk a little bit about what you learned and maybe some of the things that might have surprised you that came out of those sessions?
00:15:33.450 --> 00:15:33.789
Yeah.
00:15:33.820 --> 00:15:49.830
I'm gonna actually just jump ahead of David,'cause I think first, just for context for those listening, RaterStation at Signant is an eCall platform that we use primarily for the site-based experience and usually in a CNS space to administer clinical rating scales during that visit.
00:15:49.860 --> 00:15:55.419
It captures your data along with an integrated audio/video evidence capture as well.
00:15:55.519 --> 00:15:57.750
So just for context, that's what RaterStation is.
00:15:57.759 --> 00:16:01.409
And I'm gonna lead with the surprise, David, and you can fill in the context.
00:16:01.710 --> 00:16:18.123
For years So David and I obviously have a long tenure at Signant Health both starting in operations and maturing into our product organization, and for a long time, we as an organization believed that having the capability to be fully offline was a huge differentiator.
00:16:18.222 --> 00:16:20.043
We really thought that this was key.
00:16:20.143 --> 00:16:24.773
Lots of our customers and sales opportunities led with that dialogue.
00:16:24.873 --> 00:16:46.743
But when we actually spent time just in the past three years really digging into that core marquee product, because RaterStation is very important to Signant, we actually figured out by talking to the site users that some of the symptoms of being offline first were actually compounding some of their biggest issues or their day-to-day experience with that technology.
00:16:46.842 --> 00:16:49.682
So it definitely wasn't the strength we thought it was
00:16:49.783 --> 00:16:58.602
And as we interviewed people and did all of that discovery that we talked about, I think what happened is that our perception widened a lot.
00:16:58.602 --> 00:17:01.763
I would say that was the surprise element of it.
00:17:01.832 --> 00:17:06.772
It's very tempting to you're working on software when you're mocking things up.
00:17:06.803 --> 00:17:16.413
You're thinking about an individual user that's clicking through a bunch of screens that you designed, and can they get from point A to point B?
00:17:16.423 --> 00:17:20.712
And if they can, and it's designed really well, and it looks pretty, then great.
00:17:20.813 --> 00:17:23.292
that's not enough, especially in this space.
00:17:23.393 --> 00:17:28.873
We're talking about somebody who is at a busy trial site who...
00:17:28.972 --> 00:17:32.853
one example is something called simultaneous administration.
00:17:32.952 --> 00:17:40.423
So the participant and the observer, or sometimes called the caregiver, comes into the site on the same day.
00:17:40.522 --> 00:17:42.833
They both need to be interviewed.
00:17:42.932 --> 00:17:58.125
In an offline first solution where this participant's record is locked to an individual piece of hardware, I now have to wait for the participant's interview to be done so that I can interview the caregiver.
00:17:58.134 --> 00:18:02.765
And while we're doing these things, the other person is sitting in a waiting room somewhere.
00:18:02.865 --> 00:18:05.644
And this, this visit day is already super long for them.
00:18:05.654 --> 00:18:12.924
Why do they wanna sit around waiting and wasting more time when there are staff available to handle both of these people simultaneously?
00:18:13.025 --> 00:18:15.154
So that was one thing that we learned.
00:18:15.255 --> 00:18:16.855
Interrupted connection, right?
00:18:16.954 --> 00:18:18.474
They need to shut their laptop.
00:18:18.494 --> 00:18:19.914
They need to move rooms.
00:18:20.015 --> 00:18:23.845
They need to deal with a recording being interrupted.
00:18:23.944 --> 00:18:27.835
They need flexibility to handle paper scale transcription.
00:18:27.884 --> 00:18:36.315
If for some reason they're not able to get ahold of the technology, they need to write it down on a piece of paper and then get it back into the system in an elegant way.
00:18:36.414 --> 00:18:53.224
So there's all this sort of context or activity that's happening in the real world outside of the context of your screen of your application that our perception grew and that really, I think, helped us inform where we were going next.
00:18:53.265 --> 00:18:58.954
Another piece of this is the fact that Cygnet is just one of many vendors that they are dealing with.
00:18:59.055 --> 00:19:07.785
As a vendor we like to think that we're the only thing that the user is thinking about when they wake up and turn their computer on in the morning.
00:19:07.884 --> 00:19:09.625
We're just another browser tab.
00:19:09.634 --> 00:19:12.944
We're another vendor, another solution that they're dealing with.
00:19:13.045 --> 00:19:22.625
And we also heard that older thinking may have been that online is Maybe not that great because maybe that not many sites have great connectivity.
00:19:22.724 --> 00:19:24.825
We went out and we retested that.
00:19:24.865 --> 00:19:28.095
We asked, How do you guys feel about an online solution?
00:19:28.105 --> 00:19:39.085
How do you feel about this being a bookmark in your browser rather than a piece of hardware on your shelf?" And what we heard directly from sites was,"We're not concerned about that anymore.
00:19:39.184 --> 00:19:46.875
We want it to be online." So as we got all of this information, the picture started to click into place.
00:19:46.944 --> 00:19:48.365
Our perception widened.
00:19:48.444 --> 00:20:09.545
We gathered all of this detail, and we said,"Okay, the stability of an offline modality is a mismatched jigsaw piece that doesn't fit in with the site stay." So suddenly we pivot to something, a solution that was online first, that's built on a real insight and not an assumption about what the site needs
00:20:09.644 --> 00:20:10.384
Thank you both.
00:20:10.484 --> 00:20:29.585
Again, I think that the really interesting thing about that approach, which is it seems so straightforward and sensical, but it's that taking understanding first and building or reiterating later, and not coming out with something that is final or considered final and forcing it upon the site.
00:20:29.585 --> 00:20:30.545
I think that's really important.
00:20:30.545 --> 00:20:33.065
You nailed it right there on the head, David, right at the end there.
00:20:33.065 --> 00:20:40.625
So then where do sites and sponsor priorities sometimes come into tension when developing technology like this?
00:20:40.724 --> 00:20:51.241
Because you guys, Realistically, oftentimes you're sitting in the middle of what w- the needs and the priorities of these two different sides of the same clinical trial here.
00:20:51.241 --> 00:20:58.231
And I guess how do you then effectively navigate some of those trade-offs as you're trying to do some of the things that you've just described?
00:20:58.342 --> 00:21:00.602
This, this absolutely happens.
00:21:00.836 --> 00:21:10.307
So big areas where it happens are security, regulatory stuff around audit trails, and especially with protocol rigor.
00:21:10.406 --> 00:21:22.115
So the sponsor, of course is gonna tend to lean towards make it more robust make it more locked down and bulletproof from a regulatory and security perspective.
00:21:22.214 --> 00:21:26.494
Of course, those types of decisions can lead to site friction.
00:21:26.595 --> 00:21:32.535
The site is gonna be leaning more towards I want efficiency, I want ease of use.
00:21:32.575 --> 00:21:40.454
I want the technology to get out of my way so that I can focus on the participant, so I can focus on the data collection.
00:21:40.555 --> 00:21:42.714
And both are correct, both are right.
00:21:42.805 --> 00:21:45.204
It's about finding a balance.
00:21:45.305 --> 00:21:48.085
So how does Signant navigate that?
00:21:48.184 --> 00:21:51.914
I think a big part of it is just weighing the site impact early.
00:21:52.015 --> 00:21:57.095
A lot of what we've been talking about here, getting the site's input from day one.
00:21:57.244 --> 00:22:07.144
Example is customer comes to you with new requirement for something that is a sort of heavy regulatory or protocol type enforcement.
00:22:07.244 --> 00:22:12.704
We should immediately be thinking about, okay, what, what burden does this place on the site?
00:22:12.805 --> 00:22:14.795
What is the site experience with this?
00:22:14.894 --> 00:22:16.125
So how do we deal with that?
00:22:16.134 --> 00:22:19.714
So we want excellence in product design.
00:22:19.815 --> 00:22:35.694
So within the constraints that we are given by the regulations, by the protocol, we now need to solve how can we do this in a way that is least burdensome to the site with still honoring the spirit of the law.
00:22:35.795 --> 00:22:37.914
So we dealt with this recently.
00:22:37.964 --> 00:22:44.174
So the way that we solve these, these sort of tensions is by weighing the site impact early.
00:22:44.275 --> 00:22:52.744
So very early on we are thinking about how does what requirement came through to us, impact the site's day-to-day use?
00:22:52.845 --> 00:22:55.154
And is it adding burden to them?
00:22:55.255 --> 00:23:00.315
One way that we deal with this is by making sure that we have an excellent design.
00:23:00.414 --> 00:23:05.674
So the way that we did this recently is through a feature called Principal Investigator Review.
00:23:05.775 --> 00:23:17.535
This is a feature where a regulatory requirement requires us to make sure that the principal investigator can individually review each visit that comes through for a study.
00:23:17.634 --> 00:23:24.654
This is a heavy process, a lot of data for them to parse through on a very frequent rolling basis.
00:23:24.755 --> 00:23:37.305
So we needed to prototype this solution very fast for the customer, and we were able to, with their feedback and with site input, really dial that design in.
00:23:37.404 --> 00:23:50.285
And even though, yes, it's not fun for the principal investigator to have to review all of this data, how can we make that process as painless for them as possible, the most user-friendly experience?
00:23:50.384 --> 00:23:53.474
That's, I think, a, a big guiding principle for us.
00:23:53.575 --> 00:23:59.535
And another thing that we do is what I would call regulatory interpretation and negotiation.
00:23:59.634 --> 00:24:18.875
So Signant has a great quality department, and as customers come through with different regulations and say, blanket statement,"Build me this feature because this regulation says X," we'll take that to our quality department and say,"Do we really need to build it that black and white, or is there some leeway?
00:24:18.875 --> 00:24:39.894
Is there some, some room here to make it a little bit more user-friendly while still adhering to the spirit of the requirement?" And so we're able to come to some compromises there, where we're still hitting the main asks of the customer but doing it in a way that sites appreciate and sites feel that they were thoughtfully made.
00:24:39.994 --> 00:24:53.296
I think the ultimate goal though here is that these upstream decisions that sometimes have to be made in studies and from customers don't feel like a thoughtless surprise that lands on the site's doorstep.
00:24:53.395 --> 00:25:02.806
That one day there's a new feature or a new requirement there that just feels like a terrible experience for them that they now have to suffer through.
00:25:02.905 --> 00:25:08.817
It should feel thoughtfully designed and something that, that they feel that they had input into
00:25:08.917 --> 00:25:09.557
Thanks, David.
00:25:09.557 --> 00:25:16.867
And if nothing else there's so mu- so much to tease out of your responses here today and what's been going on, and a lot of insight into the process.
00:25:16.897 --> 00:25:19.117
It's an understanding of that process.
00:25:19.218 --> 00:25:43.817
Having a little, we'll say, empathy at the site level in particular for the nuance and the different areas that need to be involved in this decision-making, I think hopefully gives truly the sites a little bit of understanding and patience and the willingness to work effectively together on on, on advancing this instead of simply resisting it for a variety of different reasons.
00:25:43.917 --> 00:25:48.248
So Ashley I wanna come back to you here as we begin to conclude our conversation here.
00:25:48.248 --> 00:25:55.597
So what would you say to other vendors, other service providers about involving sites earlier in the development process?
00:25:55.597 --> 00:25:58.877
You both did a great job of articulating some, some good examples there.
00:25:58.877 --> 00:26:04.468
So maybe, succinctly or in summary really bring home a couple of the key pieces of advice.
00:26:04.567 --> 00:26:05.117
For sure.
00:26:05.218 --> 00:26:06.688
Curiosity is king, right?
00:26:06.728 --> 00:26:08.938
You wanna come curious, not opinionated.
00:26:09.038 --> 00:26:13.857
If you walk into a site conversation with that assumption, it's just an affirmation session.
00:26:13.857 --> 00:26:15.248
You're not gonna learn anything.
00:26:15.347 --> 00:26:22.805
So I know this is simple or maybe seen as a little pedantic but it is about listening and not presenting.
00:26:22.815 --> 00:26:28.845
You wanna think of outside the boundaries of what you know as the product and think about the folks using it.
00:26:29.125 --> 00:26:37.421
when we're talking about site advocacy, I couldn't Create a finer point around this You need to account for when the user's pathway isn't so happy, right?
00:26:37.480 --> 00:26:39.540
Connectivity failures will happen.
00:26:39.641 --> 00:26:42.411
transcription on paper will need to occur.
00:26:42.510 --> 00:26:49.891
Someone will show up late for a visit, and there'll be a continuity break flow for the sites as they're re-moving everyone to a different study room.
00:26:49.990 --> 00:26:50.181
It...
00:26:50.280 --> 00:26:51.471
those things happen.
00:26:51.570 --> 00:27:02.181
So though we all really are desirous of the most frictionless day possible that we could imagine, you do need to think about, how can you enable the user to get through?
00:27:02.280 --> 00:27:04.770
That's really the, the crux of what we're trying to do.
00:27:04.871 --> 00:27:07.391
Advocacy and autonomy, I think, go hand in hand.
00:27:07.401 --> 00:27:11.951
The more autonomous your sites and raters are, the more advocacy you've built into the product.
00:27:12.050 --> 00:27:17.050
So what can you amplify that may already be in their toolbox, to David's point earlier.
00:27:17.060 --> 00:27:21.921
Sometimes it's not layering another technology, another dose of change management.
00:27:22.020 --> 00:27:27.701
It's truly thinking about, how can you work in concert with the ecosystem that already exists for them?
00:27:27.800 --> 00:27:31.000
And finally, we've given a lot of good credible examples.
00:27:31.030 --> 00:27:34.340
I would also say this, continuity is important.
00:27:34.441 --> 00:27:39.290
Part of these dialogues aren't just, okay, sit with them and really listen, and then design.
00:27:39.290 --> 00:27:40.800
I know that sounds really flowery.
00:27:40.901 --> 00:27:41.090
It...
00:27:41.191 --> 00:27:47.800
The principle is understand your current state within the ecosystem of that actual site user.
00:27:47.901 --> 00:27:50.010
Think about where you sit.
00:27:50.111 --> 00:27:51.330
Have a dialogue with them.
00:27:51.340 --> 00:27:52.490
Listen to pain points.
00:27:52.490 --> 00:27:55.070
Listen to problems they have that no one's trying to solve.
00:27:55.240 --> 00:28:02.105
That's all important, But if you've ever been in a relationship, voicing your problems to someone and having them listen, that's therapy.
00:28:02.205 --> 00:28:06.145
Having them come back with a response to that, that's a problem solver.
00:28:06.155 --> 00:28:10.526
And I think vendors in this space really should feel called to arms here.
00:28:10.625 --> 00:28:14.165
So the continuity I'm speaking of is go back to those folks.
00:28:14.195 --> 00:28:18.855
Show them the current state that you outlined after the initial discussion with them.
00:28:18.955 --> 00:28:31.256
Show them their new dream state or at least the new state which demonstrates that you didn't just hear what they said, that what they said drove actions in your actual design process and your feature build.
00:28:31.355 --> 00:28:32.766
An excellent point, Ashley.
00:28:32.766 --> 00:28:45.385
We talk a lot about how important it is that we close that feedback loop, that we bring and help the sites understand that what they told us, we listened to, we made changes based on, and then we're telling you, right?
00:28:45.385 --> 00:28:48.855
We're showing you what we've done as a result of your direct feedback.
00:28:48.855 --> 00:28:50.705
So I think that's a, an, an excellent point.
00:28:50.705 --> 00:28:56.046
It's great to hear that that's a focus of how you all develop technology solutions.
00:28:56.046 --> 00:28:56.925
Thank you for sharing that.
00:28:56.925 --> 00:28:58.006
I wish we had more time.
00:28:58.006 --> 00:28:59.296
We could probably talk about this.
00:28:59.306 --> 00:29:03.986
It's such a pressing issue at the site level, and both of you shared so many great insights into this.
00:29:04.046 --> 00:29:08.925
And really a lot of considerations for every different constituency group to think about, right?
00:29:08.935 --> 00:29:15.175
Other service providers, sponsors and CROs, but also sites as we're approaching this from a holistic and a relationship based approach.
00:29:15.175 --> 00:29:18.986
So thank you both for your time today and for engaging on this topic.
00:29:19.086 --> 00:29:19.596
Thank you.
00:29:19.615 --> 00:29:25.205
best product decisions come from the people living the problem, not just us speculating from a distance.
00:29:25.306 --> 00:29:26.885
Signant's leaning into that for real.
00:29:26.885 --> 00:29:31.066
It drove us to dynamically rethink a core marquee offering.
00:29:31.086 --> 00:29:36.425
So excited for where that takes us, not just as Signant, but as a, a market.
00:29:36.526 --> 00:29:41.885
Because I, I think that if you let your user surprise you it can only keep getting better
00:29:41.986 --> 00:29:42.885
Yeah, absolutely.
00:29:42.885 --> 00:29:50.046
It's been a pleasure, and I think I think that's what I'm excited about g- generally with technology but specifically in this space, right?
00:29:50.145 --> 00:29:57.905
There's a sort of bright future of these things and these tools that sites are using continuing to get better, continuing to iterate.
00:29:58.036 --> 00:30:04.195
and that will be true as long as we are thoughtful about what we're building and what we're designing.
00:30:04.296 --> 00:30:05.326
It's a bright future.
00:30:05.425 --> 00:30:06.395
I couldn't agree more.
00:30:06.395 --> 00:30:07.066
Thank you both.
00:30:07.066 --> 00:30:08.645
And again, thank you for your time today.
00:30:08.746 --> 00:30:30.476
And for those that are listening, I also wanna make sure that you take some time to check out other site-focused resources on our website, myscrs.org, other podcasts covering great topics like this one, excellent webinar opportunities, information about opportunities to get together at our global site solution summits, and articles centered around technology and how we move forward with it together.
00:30:30.476 --> 00:30:34.016
But for now, thanks for listening, for tuning in, and until next time.
