Human Factors for Legacy Devices Under MDR

Hello, everyone, and welcome. My name is Sean Smith. Today's webinar, is Human Factors, Evidence for Legacy Devices under VR. I'd like to introduce today's speakers, Jenny Collinson, from Clarimed. Louisa Harvey from ClareMed, and Angelina Lisandrelli, president of MVS. Gordon Consulting, and… We have some houses.

Louisa Harvey (ClariMed): Congrat.

Mence, while we're getting started. Somebody needs to mute. And… Let's see… the housekeeping announcements are this webinar will be recorded, and the recording will be made available tomorrow to all registrants, along with a link to the slides. But I'm going to say that again, the slides and recording will be made available tomorrow to all registrants. If you would like a certificate of attendance, please put your name and email address in the chat. Use the chat to communicate with me, use the Q&A to communicate with the speakers. I cannot copy from the chat to the Q&A, so if you put it in the chat, I'm gonna ask you to put it in the Q&A. Now, that said, we have a few

past… Human Factors webinars. All our Human Factors fans, please rate HF in the chat, I want to know. how many Human Factors fans we have. Let's see, last Friday, we… Had… Designing better formative, simulated use, realism and Risks of playing it safe. with Davide Salinitri from Claramed, and then on February 24th, we did Global Human Factor Strategy for MedTech, which was U.S, UK, EU, and China. Both of those are available in replay, and I will put the links in the chat.

Join us this Friday, on Friday in Focus, and… for, AI and regulatory intelligence, clinical, and PMS. with MedBoard. So, let's see… I'm gonna turn it over to Louisa. Any questions, please feel free to put them in the chat. For me, any questions for the speakers, please put them in the Q&A. Looking forward to an exciting event. Thanks, sorry for all the words.

Louisa Harvey (ClariMed): Thank you, Sean. So today, I'm very excited about this particular topic, which is human factors evidence for legacy devices under MDR. And the reason is that MDR really has completely changed the way we view, and submit files. Louisa Harvey (ClariMed): Particularly pertaining to the usability engineering part, which we'll discuss today. So today, I've got two wonderful people with me. My colleague, Jenny Collinson, who is Human Facts and Strategy Advisory, from my company, so I work with Jenny regularly, asking her lots of technical questions. Louisa Harvey (ClariMed): And Angelina, who really is an expert on the regulatory side, and really explained to me earlier how she likes to demystify regulations, which is great, because this can be quite overwhelming, this particular topic. And for that reason, I am going to explain what a few words mean before we begin, and I do apologize for anyone watching today who's already fully aware of that.

Louisa Harvey (ClariMed): But, I'm gonna do a bit of translation. So, legacy… Louisa Harvey (ClariMed): Talk about legacy devices. This is devices already on the market that were approved through the Medical Device Directive, MDD. Louisa Harvey (ClariMed): Sometimes we'll also refer to human factors, as HF, which is, also usability as well, sort of behind under the same umbrella. If you see anything regarding NB, that's notified body. And, the very confusing phrase UOP, which is User Interface of Unknown Provenance, which I know Jenny will go into more detail, in that particular area to explain.

Louisa Harvey (ClariMed): Exactly what that… what that means. Louisa Harvey (ClariMed): Oops, I'll just move on to the next slide. Louisa Harvey (ClariMed): So, why is this important? I touched on this a little bit earlier, but we are seeing a consistent pattern across MDR conformity assessments right now, and primarily because human factors have surfaced too late. Many, many products Louisa Harvey (ClariMed): I wouldn't like to say the sheer number went through MDD, but the, it just wasn't as strict in terms of how much people have to put in, in terms of their human factors. Unless, of course, since you were going to go for FDA submission, in which you would have likely built up quite a decent usability engineering file, which could then

Louisa Harvey (ClariMed): hopefully be shoehorned into your, yeah, your submission for MDD. Louisa Harvey (ClariMed): But, but a lot of people are getting caught out, in this, and particularly, and I'll go through a few of the stage gates that are coming up. Louisa Harvey (ClariMed): Particularly because companies are being made to recertify under MDR, and then it's coming up that they haven't done the original human factors work required. Louisa Harvey (ClariMed): Traceability is missing. Selective legacy files built under MDD reflected standards of that era. Things were just expecting to have, just things that are a lot more… documents are a lot more traceable, nowadays.

Louisa Harvey (ClariMed): And timelines, sadly, are getting quite tight, and the 2027 and 2028 transition end dates are closer than they look once review, and the remediation time is counted backwards. So, remediation. Louisa Harvey (ClariMed): Meaning that… Louisa Harvey (ClariMed): The adaptations people are having to make, to… to get their documentation up to… up to scratch. Louisa Harvey (ClariMed): H? Louisa Harvey (ClariMed): So, as I discussed a little bit, we've got the transition clock. So, 26th of May 2026 is obviously looming very, very close. That's the Class 3 custom-made implantable devices.

Louisa Harvey (ClariMed): So this is where the gating milestones required notified body application by 26th of May 2024, and written notified body agreement by 26th of September 2024. If those conditions were not met, this path is sadly no longer available. Louisa Harvey (ClariMed): And then we've got 31st of December 2027, so Class 3, all in certain Class 2 implantables. Louisa Harvey (ClariMed): Got a few exclusions there, like Zeus, staples, dentures, and similar, and then 31st of December 2028, remaining Class 2B, Class 2A, sterile Class 1, Class 1 with measuring function, and Class 1 devices now requiring notified body under… under MDR.

Louisa Harvey (ClariMed): So, Louisa Harvey (ClariMed): Jenny, I am going to ask you if you could present, the next, few slides, as Louisa Harvey (ClariMed): This is the kind of thing you see come up all the time. What gets legacy files questioned?

Thanks, Louisa, and thank you for explaining some of the terminology, because I may slip into it and be a bit confusing at times, but people can ask questions if they need to. So we can loosely group some of the issues that are seen in MDR conformity assessments into four areas that you can see here. Firstly, user definitions are sometimes too generic. Users can be grouped into clinician or trained user, when really, we know that there's a lot more segmentation. That goes on by role. And some of the user characteristics that need to be described as part of that segmentation could really have an impact on use.

So reviewers really need to see descriptions of roles, of training level, frequency of use, and they need to understand how these aspects might produce different use interactions. And so it is therefore really important to describe, groups clearly. In particular, layer users. We'll talk about them a little bit later. But they are typically less well understood. And there is aspects of labelling within the MDR as well, so we need to be able to demonstrate That their users can understand labelling, and they find it clear. So the next two, so number two and three, relate to risk analysis, which I think, really, when you try to conform to 62366, and therefore to the MDR,

It's really one of the keys that we need to consider. And it's really important that the use risk is traceable, and… because the gap that's identified is often not just that risks are unrecognised, but also that they're not visible in ISO 14N71 risk files. Often, there's a standalone human factors document that exists separately from the risk file. Such as, what we call, typically, a use-related risk analysis. And it can break that usability, that traceability chain. So reviewers can't follow from… A requirement through to a mitigation, so they can't… they can't really follow what that… what tasks could present a risk.

And then what's being done to demonstrate that that's not realised? So, I think it's important to recognise that 16366 references risk a lot, and it includes a lot of terminology associated with 14971, so reviewers will look for compliance and interconnectivity between the two. And often, critical tasks are absent from files. And… It's important here, I'm talking about critical tasks, but actually that's more FDA terminology. 62366 Refers to hazard-related use scenarios. And it's just very important that we identify those very clearly. And they can be linked through to whatever Work you do to demonstrate that those hazards

Hazard-related use scenarios won't be realised. Because, of course, if you don't identify them properly. Then you can… that can result in an incomplete summative being conducted, or an incomplete dataset being collected, if you're looking at post-market data to support Why these risks aren't realised. And that then is an incomplete usability engineering file. And then the final gap is that summative evidence is not present in that usability engineering file, and there's no justification. So… virus devices, it's usual. That summative study. would have been conducted. However, for some of these legacy devices, it wasn't.

And if it's not present, then there needs to be a justification, and this… can sometimes be through the UAP pathway, or the user interface of Unknown Provenance pathway. All through a risk-benefit analysis. But if you don't include anything, and you don't produce it as part of a compliant usability engineering file, then that will… will generate questions. So… I suppose once you understand what these… these triggers, are, and what could draw reviewer attention, then you… we need to understand what a strong file would look like. So, Louisa, could you move on a slide, please? Thank you. And so a strong file, I mean, it really just reiterates what we just said, but a strong file, is one that can demonstrate a documented process and traceable evidence.

And the key, really, is to ensure that you're providing A clear story to the reviewer, and traceable evidence. Because if you… if they can understand your rationale and your story for why your device is safe and effective for use, then they will have less questions. So there's 5 really key components to a strong HF file. So the first one is that it's really important to clearly identify users and their characteristics and their expected tasks. And to fully understand use environments, because that allows for all, potential use-related issues to be identified and understood. So if we just give an example of that, we could consider what additional issues might be seen in a use environment. That is a lay user, home use environment, and that… and if you don't consider that properly, you won't identify the risks associated with that, and therefore.

That will be a question for the reviewer. The next one is that it is expected that the usability engineering file is linked to the risk file, and the risk file drives and determines hazard-related use scenarios. It drives any user interface mitigations and how they will be evaluated. And also links back the documentation of any evaluation. And then, of course, there needs to be a determination of acceptability. So, whereas… if people are familiar with how they work for the FDA, that is sort of a separate and standalone human factors file with some linkages back to a use-related risk assessment. 62366 and the MDR expect

That very robust link back to 14971. So it needs to be… you need to be considering 14971 in the development of your usability engineering file, and it shouldn't be a standalone document, because that will generate questions. And I think the reviewers They're really… they're really familiar with 14971, and less familiar with 62366, so if we can talk about it in those terms, then it's more likely to be acceptable. I mentioned before that it's really important to document the reasoning for the selection of critical tasks or hazard-related use scenarios. Because… because the reviewers really need to know why.

You've considered some things important and why some things If there's a missing explanation, that's just a gap that would prompt a question from a reviewer. And then, the next one is you need a really clearly documented evidence path. So it's very important to be clear about the strategy to comply with 62366. A detailed usability engineering plan can help, so I always recommend A plan, even if it's a retrospective one, because it helps looking… helps you build the evidence and how you justify certain decisions, rather than trying to do it in a checklist format. It also helps you work out what steps you need to take, and whether you might be able to use the user interface of Unknown Providence, route, or whether you need to conduct a small summative, or whether you've got that existing evidence that you need that you can pull together into a file.

And finally, but certainly no less important, In legacy files, IFU and training is often being treated as a regulatory output. And MDR is very clear that they're a part of the human factors process, and need to have been evaluated for use-related clarity. And it could be very simple, you know, it could have already been done as part of formative assessment. But it's a gap that needs to be considered and documented. And if it's not present, then it will… it will prompt questions. So a strong file just will make it really easy for a reviewer to follow a story from intended use, To look at the user population, to assess the use-related risk.

To look at the critical tasks, and then to link through the data from evaluations. So… Yeah, let's move forward and see where the… where the legacy files might break down. And again, I think, we're telling the same story here around traceability and user populations, I think the key… one of the key points here is that quite often legacy files are built as summaries rather than Demonstrating that a process was followed. So IEC 62366 is built around a standard and expects a process, So…

Reviewers want to see that that process has been followed and embedded into development, which is very difficult if it hasn't been, but we have to try and retrospectively demonstrate that that thought process was in place, and just not documented in the way that they expect, so we can reformat it or reframe it into the correct Type of documentation. And as we mentioned before, That can be a lack of traceability. Through… from the risk file to the human factors work. User populations could have been described as far too generic, so healthcare professional really probably isn't specific enough. Because the healthcare professional could cover a surgeon, it could be a nurse, it could even be a caregiver with minimal training. So, it's really important that it's very specific about the tasks that someone undertakes, about the skills that they have.

And about their characteristics that might influence the use of that product. We've mentioned that critical tasks are often undocumented, And I think… This is… this is really key, because they're… if they're… if the reviewer can't understand what the key risks are with the use of that product. Then they won't be able to determine whether Whether you've given them the appropriate evidence to be able to mitigate those risks. So that clear traceability from risk to identification of whether it's a critical risk. to the evidence that you've provided. That's just one of the key, the key parts. Again, we mentioned

having no summative, I've recently seen this, just the absence of a summative just immediately alerted Alerted a reviewer to the fact that that file wasn't As complete as it should have been. And there was no justification associated with it, so there was no explanation of why it wasn't there, it was just… We followed a user interface of unknown provenance. Pathway with absolutely no rationale as to why that was appropriate. So I think… Explaining why it's not there, even if you're not following the user interface of unknown provenance, and you're building a justification in a different way, that might help the cause.

And then, as I mentioned. previously, labelling needs to be very much part of that human factors process. It needs to be pulled in, assessed, made sure that any labelling IFUs are appropriate for that user group you've identified. And… Making sure it's part of your usability engineering file. Now, I've mentioned this a number of times, user interface of unknown provenance, so the next slide, we'll just go into that a little bit more, because it's a key step. Luisia, if we can just move on.

Can I… can I interject one thing here to kind of get the audience thinking, if we go back to the last slide there? So, I want to ask a question to the audience here. How many of your products that you work on Have competitor products. raise your hand for me to say that you know that your product has a competitor. Right. So, most. How many of those products have already gone into? Already gone into a notified body assessment. Probably… most. Thank you, Mark. When you see these comments come back from a notified body, or even from the agency. They are seeing themes on their side of the fence.

And when they come back and say, we see some of these areas that you need to address, is probably, one, from their perspective, but likely is that they're seeing trends a lot with legacy devices here. So, I want to plant a seed here where Do you think you can move forward with a certain strategy and not expect that these might come around? That is very low probability here. And… more and more why it's becoming prevalent for legacy devices later on than when early MDR came back is because of the scrutiny that MDD devices now have to provide more post-market surveillance data.

And so, because of that, the trends are coming through, the tech duck deficiencies are coming through, and there's patterns here that we see. Make sense? Give me a thumbs up. Give me… give me a pulse that you guys understand that. Nice. Alright.

Thanks for that, Angelina. I think there's a whole other webinar we could do on Post-market trends, post-market surveillance, how it should be embedded into design, how How… how actually use related issues aren't, aren't really very well identified through a lot of post-market systems, which is why this user interface of unknown provenance pathways problematic. To some extent, it's a pathway, but it is completely reliant on Having good post-market data. And being able to prove that That you don't have those use-related issues in market with that existing product. So… User interface of Unknown Provenance is, normative annexy of IC62366,

It's an option that you can take instead of performing the full usability engineering process. But it's not informal, it's not a get-out. It's not a workaround. It still requires a use specification, post-market data review, use-related risk identification, and mitigations. It requires an overall residual risk evaluation, A formal written justification. And it's really another way to show that a device is safe and effective. for use, without carrying out a summative study. And it's not for all. all scenarios. There are a couple of really major things that… that You need to be able to meet the conditions of before you can even progress this room.

Your user interface needs to have been on the EU market before February 2015. Although I've actually recently seen challenge that it should have been before 2007. Which is the first date of the issuance of 16366. So… I think there's some… a lot of variability between Notify Body's acceptance of this. So I think building that… building that justification around, Around why it's appropriate, it's really important, and conversations with the notified body might be really important in… before taking this route. And the other thing is, it's not an appropriate route if The user interface has changed.

fairly recently, because actually what you're looking at, what you're using to generate the evidence, is post-market data. So if the product that's in market is different to the project that you're currently trying to provide justification for, or the product that's been in market is different to the product that you're currently trying to provide justification for. then there's no evidence. You can't say that the user interface is safe and effective because you're planning on changing it for MDR certification. So… Those things need to be true to… In order to, you know, to progress with this user interfaceable known provenance pathway, but I have seen a significant amount of pushback on it.

throughout, you know, throughout the different submissions that I've made, and… A lot of variability in its acceptance. But I suppose the key to… the key to success is to demonstrate that the product under consideration is safe and effective for use, and that should be evidenced by a lack of use-related issues in market. Which demonstrate that your user interface mitigations are effective in preventing you, Sarah. But if your post-market data is insufficient, or the product user interface has changed, then it's probably going to be very difficult to provide it as evidence. And of course, as this, you know, as we move forwards and these dates get further.

longer ago, then it becomes less and less of an option for a lot of people as well. So, 2015's now quite a long time ago, 2007's really a long time ago. So, you know, can you… can everyone, you know, truly say that they had a product in market unchanged from the one they currently want to register or submit for MDR. That's a… it's a difficult… it's a difficult story to tell. So, as I mentioned, it's key to know that acceptability of this route, it varies across notified bodies. And if at all possible, it's probably worth discussing with a reviewer before Embarking on… on this approach, or building a justification that doesn't

rely on usability of unknown provenance. Or user interface of Unknown Provenance, and just builds a case based on the risk profile of the device and other mitigations that are in place. So if we just… move forward unless anyone's got any questions.

Louisa Harvey (ClariMed): Yeah, Jenny, there are actually a few questions, probably quite worth, yeah, worth mentioning now. Could you please share a few use cases related to IEC62366 in artificial intelligence slash machine learning enabled devices?

I don't know if Angelina's got anything where she can…

I, I will say, I will say there, again. When you think about AIML, you have to understand state-of-the-art. Can you demonstrate state-of-the-art with your device? And it's very subjective, because… what's your intended use here? What's your contradiction… er, contradictions, your warnings? So, the experience that I've had is that we have fully demonstrated state-of-the-art by doing gap assessments, and we'll talk about this a little bit later. Does your gap assessment identify issues that you have seen? And especially if your device, which I've seen. it wasn't called AI at the time. It was on the market for a very long time before we started coining the phrase AIML.

you start going down the route of what software looks like, and how that was defined, and how your end users use your software. If you have gaps, and your post-market data is telling you a signal. you're gonna have issues there trying to demonstrate that your device still meets state-of-the-art. I'm putting this in a very nutshell. scenario, because it's so huge, we could blow this up. But, I'm willing to chat with you offline, but we could go for hours on that.

Louisa Harvey (ClariMed): Thank you, Angelo. Probably, actually, yeah, one for you, Jenny, I think, yeah, how would you recommend approaching the definition… approaches and defining of critical tasks? I know you do this every day, so it's probably one for you.

Yeah, I mean, it completely depends what format you've drafted your use risk files in, but typically, you know, we would say that for a device, it would be something that could result in serious harm. upwards. So, only looking at severity and looking at things that, you know, would result in serious harm or death. for, you know, and so this is for Europe specifically, you know, that's where I would… would go. for that. But ultimately, it's up to… Your development team, what… how you feel you want to define it, document justifications, and making sure that you have the evidence to document why you believe things are serious or not serious, because quite often, certain things that can happen, harms that can happen, get classified as serious in one organization and not in others.

So that's really up to An organization to draw the line as to what they believe is serious in the use of their product and what isn't.

Louisa Harvey (ClariMed): Excellent, thank you, Jenny. I will move your slide on to the next one. Louisa Harvey (ClariMed): Very good.

So, I think we just… we just touched on this slightly, but… but this is just a little slide that talks about, various device profiles where, you know, scrutiny could be heavier. And I think the important thing here is it's not necessarily about the complexity of the device. I think people often assume that complex devices get more scrutiny, but actually. Those complex devices are often used by People who are highly trained. So, the risk profile's lower and less complex than simpler devices. So if we… if we look at, you know, these four, infusion and drug delivery is up there, just because it… they are… they've got high associated risk.

They're used very frequently, and adverse events are high. and the severity of harm is high. You know, something goes wrong with these, it's bad. And I think, you know, that… so that… so obviously, they will come under higher scrutiny because… because they've got serious harms associated with them. And then I mentioned a little bit earlier that lay users and herb use environments represent a lot of variability, which can introduce unexpected risks. And often these products are perceived as simple, because they're in the home, they're being used by layer users, but the amount of errors that, you know, you can… you can uncover when you start to look with layer users, because of the variability that they present.

And the variability in the environments that they're used in. That can really result in a… in complex, complex use issues and complexity of the use errors that can occur? And in addition to that, also, we mentioned that a focus can be on, placed on the suitability of labelling as well, with the user populations. So, how do you know you've designed the right IFU and labeling for those environments? And that definitely is something that the MDR focuses on now, is lay users and the importance of considering them in In the design of the product. Are this legit?

Louisa Harvey (ClariMed): Sorry. Jenny, that is your response to one of the questions. I thought I'd just pop that in here, because what if the IFE was fully reworked and nothing else otherwise? Would you all still work in that case?

And we've changed the user interface, so it depends whether you've changed things that you deem to be critical, or information for safety. I think there's a… there's a level of flexibility that I would apply when assessing it, so I would look at comparable products in market, like Angelina said, and see whether there's things that you could pull on from there. Like, this is the same labeling as this product that's very similar, so therefore we believe that… that that's safe and effective. So I wouldn't necessarily jump straight into doing a new summative for an IFU change, but they often contain a lot of instructional

information. And if that's unique to your product. then yes, I would think you would probably need to do some validation work with it. But if it's a… if it's a product that's very similar to another product, and the labeling's very similar. then it might be that it could be avoided. I don't know whether, Angelina, you have a…

Yeah, I have… I have some thoughts there, because… with the home use devices, I have seen a lot more scrutiny across those, because usually you're dealing with people who are older in age, people who, again, like what Jenny said, are not… physicians, healthcare workers, but these are the people, like, you and me at home. And so, if you have an IFU that's size 5 font. How does someone on a daily basis, because I need my glasses and have the patience to read it, well, what if you have a child using your device? what if you have a teenager using your device? I will tell you, I have teenagers, they don't follow anything. They just do trial and error. So you have to work these sort of aspects into your

thought process when you think critical tasks. I had something that I worked on that if you tightened it too hard, well, what would happen there? You have a baby. And it helped with percussing. What kind of critical task could come there? your bones are still developing. What if you keep it too tight for too long? So you have to kind of put these things into perspective. I also… not that you put your own personal proprietary, but you could use AI, you could use literature, you could use mod database and pull from real-life scenarios to help you identify a list of potential critical tasks with your cross-functional teams and go, is this a reality that we need to face? Because

when you first launch a device that's brand new in the market, your imagination is out there. But… Is that the reality? And that's what you have to balance, and keep… you… if you have a good QMS, you're keeping that… constant feedback loop into here, and when we think about feedback, it's not just post-market, there's a domino effect. Your clinical documentation, your IFU, if you have defects, if your literature shows off-label use. The string starts to get pulled really quick, and where does that go? It goes to your risk management. Where else does it go? Human factors.

Louisa Harvey (ClariMed): Thank you, Angelina, I'll let Jenny carry on.

Yeah, so I think we were just talking about, the different types of device profiles, which might… might lead to scrutiny, and it's nice that Angelina mentioned Lee's population, because I just feel… I just feel that's somewhere that should be scrutinized, you know, and And I do think, also, sometimes. And we haven't mentioned it in this presentation, but sometimes Lay user and home use is added to the scope of use of a product after it's launched, so it will start out in professional use, and then it will end up in the homes, and that needs to be considered as well, you know, whether that's been added and is being fully considered.

So another… another… another area which I think adds a lot of complexity is Where there's multi-user workflows. It just really presents a more complex profile. And can have… can result in multiple user interfaces and complexity. That just can result in use error and problems and more use-related issues. So, that could also result in increased scrutiny and just increased focusing on human factors engineering. And then, as we were just talking about on the last slide, Connected devices, at control devices, software as a medical device. the software is within human factors scope. I think with some of these legacy devices, though, apps were maybe developed as an afterthought, so the project was launched, and then there's been apps added, or guides.

And documentation wasn't necessarily put in place as it should have been, from a human factors point of view. But it's true… That apps that have hazard-related use scenarios or critical tasks or contain information for safety, they are fully within the scope of human practice engineering, and therefore the gap would need to be filled. For any submissions.

Louisa Harvey (ClariMed): Thank you, Jenny. Actually, there's a question, like, sort of guessing some topics, just as you're about to get there. So you've covered on this slightly, but I just wondered if either of you had any further thoughts. So, you were discussing about when a device has different user groups, and some interfaces are shared, are there special considerations that should be taken to make sure, for example, it is to fit the device sufficiently Louisa Harvey (ClariMed): Details for expert groups. Louisa Harvey (ClariMed): but not complicated for the everyday user. So, any special techniques you would use for that?

You are.

Right now.

Or you go first, Jenny.

Yeah, so, I mean, I was just going to say, you know, whenever you've got multi… devices for multiple users, you need to just make sure that you've considered both of those user groups. This is why it's important to make sure you have appropriate segregation in your user groups, so that if you have A screen that's being used by a surgeon and also by a nurse, that you're taking into account their different Their different training and expertise and influences into the use of that product. So I think… I think as long as you consider As you would for the development of a new product, that you've documented

the different use-related risks that can occur from different user groups, then that should… should help to build the file.

I'll also add on to their… Those that have worked on higher-class devices, and you have different patient populations do you have to address, especially when you think about the lay user at home versus the expert, meaning the physician, or the nurse, or the radiologist. you might have two different instructions for use. You might have one for the physician, and one for the patient itself. And typically, when you have the patient, and you see this with SSCPs especially, you have sections that are different… written differently for the lay user. It's a… Level of, a reading level that's lower, so that people can understand.

or you have pictures, you have examples, to make sure that the messaging comes across in addition to what Jenny mentioned about how the testing incorporates all those patient populations in there.

Louisa Harvey (ClariMed): Thank you very much. Actually, Angelina, I've got a question for you as well. So, at what point does human factors typically become a real program risk during MDR work?

I think… why don't we go to the next one, and I'll actually answer that while I'm going through that. for those that went through MDR, right, that was… that was an interesting kind of… 2017 came by, you started to look into your devices as a regulatory affairs Professional, and when you started looking at that. you identified gaps, right? And so those gaps caused extra work, or, and I saw someone put this in the question and answer, when should you take certain products off the market? I will tell you, many Many companies in industry, the big ones all the way to the little, pruned their portfolio, because they could not meet the evidence to meet state-of-the-art or the regulation.

So, with your question there, Louisa, when is a good time? To address this. The best time is as soon as you can see it. It's not horrible that you are trying to remediate it while you're preparing the tech doc, but I will say, once your tech doc goes to the reviewer. It… it is now… you're dealing with fire, and so whenever questions or deficiencies come in, you're going to have to mobilize a team that has to come with the justifications. There's strategies to go do this if you know that you're probably going to get that Deficiency, and it's gonna take 6 to 18 months. That is a strategy the business has to agree on and understand, and the regulatory affairs specialist has to be very clear in their communication is, this is the risk that could happen. You could have a delay in clear… er, clearance… you can have a delay in your CE marking.

So, I hope that answers the question. Let me just…

I want to jump in with the poll. If everybody would kindly take a minute to complete the poll. Angela, you can just talk over the poll, just minimize the thing with the yellow.

Sure. So, I'm gonna just talk about 3 general buckets here. There's no 100% that you have to do, each bucket separately. There could be a hybridization between these. But the three buckets that, after you go through and look at your device with your cross-functional teams, you could do a couple different avenues. And the timelines here are very, I want to say. very, hopeful. I've seen timelines go fast, and I've seen timelines go long, so this is just a generalization. But let's talk about the first bucket. After you've done your gap assessment, you've looked at the standard, and you've looked at other areas, and you can meet the human factors aspect.

This is where it really becomes a documentation exercise. You have to come up with rationales to pull the story together. One of the areas that I see fall short is when you talk about your device description. You have to be very clear about how your device works, who is your patient population? The environment of use. Yes, the tech doc has sections for this, but you cannot just put it in 3 sentences, and then I open your IFU, and I see a long dissertation of how this device works. It all has to line up. So when you look at your documentation and traceability, does this all make sense? Does your GSPR say the same references? Does your IFU

Call out the right… Outputs from your design validation, including human factors. Everything is coming together, so it's really… pulling it together and making sure the story's there. So, no additional testing is required, you just need to work through the documentation. The second bucket here is targeted user research. You've done your gap assessment, and you've seen some areas where you need to kind of fill in the gaps, because your device has been on the market for so long. I think I saw… I want to say Mr. Russo here. You know, the product's been on the market since 2012. Well, I bet you you have data on there that you need to pull in to show that your device is safe.

Or, you might need to do additional formative testing to address this, to make sure that the issues that you see in the field aren't something that you need to mitigate now. And if you do, that might cause design changes. And then lastly, the full summative evaluation. This is where you have no other choice but to actually go down that route and do full summative evaluation to make sure that you have the justifiable evidence to meet state-of-the-art. you see at the bottom there, there's multiple different functions that could come in here, but you are touching all the way from RA, QA, post-market, clinical.

Everybody gets touched here, so there's not one bucket that you should not consider. Any questions?

Louisa Harvey (ClariMed): There is one question that came up, in the chat, it's probably… yeah, probably best to ask it now. Should you give stronger weight to critical tasks in the home, as opposed to the hospital, if the risk is the same for hospital and home care device? Either Angelina or Jenny.

Jenny, I'll let you go, and then I'll follow up.

Well, no, I wouldn't. The purpose of identifying the different users is to be able to pull them into a risk file, and if they're critical, they need consideration. So… it's… it's not that we think things are more dangerous in the home, it just might… they might be more probable of happening, but we're not really interested in that in human factors. We're looking at the severity of harm that's possible. So, if something could cause death, in a… In a hospital situation. Or it could cause death at home. They need to be given the same consideration.

And I agree to that. I will say, should you get that deficiency question, and you're trying to defend it, and say, well, that critical task is not as significant as that critical task in the home. I'm going after the risk management file as a reviewer. Because that shows me that, have you actually evaluated the critical tasks effectively to 14971? you start unraveling very quick. And so, while the question is I think a great question. Be careful how you respond to that question, because if you do respond, we're like, well, in the hospital you have trained physicians, but we call it a critical task.

To Jenny's point, a critical task is a critical task, as you've defined it.

Louisa Harvey (ClariMed): Thank you very much, Angelina. There is another one on a different topic, that I may well for you, Angelina. For the… for the patient safety, and because it is so complicated to regulate legacy devices, why isn't the legacy device, or the IBDs. Louisa Harvey (ClariMed): Like, Class 3, such as implants, simply withdrawn from the market where they are used and sold.

That goes into a business decision, that goes into the justification to support it. If they can support the patient's safety, then… I mean, that they have demonstrated why that device is safe. If you have issues in the field, then I think that's a hard sale, and that's where we've seen in early MDR, where you… it's very hard to establish patient safety. That device might be pruned and taken off the market. Jenny, your thoughts?

I completely agree. I think if you have… like I mentioned earlier, a lot of the time. projects that have been developed under MDD, they've… they've actually got the evidence, and they've got the… they've got the documentation. It just needs to be reframed. to meet… to meet the expectations of the reviewer. So it's… it's knowing how to lay that out, and how to describe that process in a different way to the reviewer. And if it's just the documentation remediation, and that's a, you know, 4 to 12 weeks timeline, like we've got on screen. then that doesn't feel like it should be with… should be withdrawing that product from market. It feels like a bit of effort to

Keep that product in market and get it recertified.

Yeah. Let's go. As a… I'm gonna skip this, or go over this very quick, because we've talked about that this touches all different departments, but I want to call out one department. I wanted to see in the chat. Who else should we talk about this? Who deals with the product in the field the most? I'm not talking about the patient, I'm talking about within the company. I want to see it in the chat. Somebody… somebody's gotta put it in. That's right. Yes. Yes. One of the biggest sources of truth that people need to reach out to when they develop and start looking at gaps is your sales team. Is the training that they have been given.

And, how are they communicating with their patients or their customers? And so, one of the aspects that I say for RA quality clinical team to lean into is pull that sales team in. Talk to them, evaluate them. You might not consider certain critical tasks. that were present, that they have heard firsthand. And this is not to knock sales. This is not at all. But sometimes when they interpret something that is a critical task, they might not understand what that means from our end, on the side that we have to deal with the regulators. So, the earlier you communicate them and partner with them big time, marketing.

They should not be excluded out of these conversations for legacy devices. They are the ones that are hands-on on the day-to-day with these products. pull them in. So, not to preach to the choir here, but… I think sometimes they are a valued partner that is inadvertently not pulled into conversations. And I think that this two-way street where regulatory can really lean in and learn a lot, because this helps to go with your defensibility and your deficiencies, it helps to make the clarification in the technical documentation when you review your risk management files, when you review the design.

It's all clarity. And this is what makes a good tech file, to what Jenny was bringing up earlier, versus a tech file that you have to deal with under fire, which is not the ideal scenario here. Make sense? Okay, last slide before we go into panel discussion, and I got 9 minutes. Let's go to the next one. So what should manufacturers know? I'm going to go through this very quick, because I want to give you guys some time. Confirm transition path and device scope. I think we talked about this. How does your device fit into the buckets of it? Is it Class 2A, Class 2B, Class 2B implantable, Class 3?

Where does that look? Pull in your reg, folks, pull into that. Do you have to make adjustments here? There were some legacy devices that had to be up-classified. That was a rude awakening, right? So… Let's look at that. Audit your existing human factors evidence set. This is going with your whole state of the art, not just human factors, your whole design everything. But to the latest standards, 62366-1 and 60601, or 606-1. Because there's usability in there. Go through it line by line. I know it's tedious, but you know who goes through it line by line? Your reviewer. the person that they hired to go through things line by line, so…

Pay now or pay later. That's one of the two scenarios that you're facing. Determine if UOP is on the table. If you identify large gaps, start your approach now, start your strategy. you… if you have a great relationship with your notified body, after, don't do this while you're trying to figure out the scenario. After you go through your gap assessment and UAP is on the table, make sure you have a clear strategy and approach it with your notified body. Some are welcoming to it. I had BSI before, I had TUV. I was able to approach my reviewer and have these conversations, but it's all about the relationship you have.

Classify the remediation path. We gave 3 examples here. Align your internal owners. This is really kind of built into all of these. You need to bring your stakeholders in as soon as possible, especially the ones that we talked about get inadvertently not included. Because if you have to redo HF, which means you have to redo the labeling, means you have to change your training. Those salespeople have been built to continue what they know and what works. If you have to reset your sales team, you are resetting the business. Do this early on, pull in people that want to lean into that, but you have to be very delicate with this situation, because again, the salespeople are really energetic to make sure that we bring devices to our patients.

And then lastly, come up with a list of reviewer questions that you know that you will have to remediate while the submission's under review. This is a strategy that all regulatory affairs people do all the time. This is not like, oh, we're going in knowing that blindly that they're gonna ask us. It is a strategy that you have something prepared in the event that comes in, because as a business, you can start that submission review and go, okay, if they ask this a little bit further, we might have this rationale all ready to go. There's no harm in that, alright? Any questions, thoughts? All right, let's go into the panel, and then we've got 6 minutes, and then people can chime in.

Louisa Harvey (ClariMed): Thank you, Angelo. I think, actually, a lot of the questions have been answered as we're going through, but I have got a new question, from Serena. To what extent does the human factors, evaluation apply to IPDR products? Louisa Harvey (ClariMed): And there's another part to that question, too. Louisa Harvey (ClariMed): Delina Rodin Louisa Harvey (ClariMed): The other second half of the question is, is the URP also justifiable for IBDR legacy devices as well?

Sorry, I was gonna let Jenny go first, and then I could go after.

Louisa Harvey (ClariMed): Sounds good.

Well, I believe that Human Facts Engineering should be applied to all… to all products, so yes, it should be applicable. And in… and in that… in that respect, in theory, I suppose, the user interface of unknown provenance should also be applicable, but as a number of people have said in the chat, and as I mentioned. It's a route that is so variable in its acceptance that we just have to treat it very cautiously, and have those conversations up front, so… maybe your reviewer would… would like… would accept it, and maybe they wouldn't. It's difficult for us to say.

I'll add on to that, Can you tell me, maybe for those that have done GSPRs under IVDR, you're gonna have to justify your human factors in the GSPR. If you don't… the first 9 GSPRs are identical between IVDR and MDR, If you… if you don't have a justification for those, that you're going to get that question. And so, to the extent that you have to do it, it all depends on the device, typical reg response, but… The higher class device, the stronger the documentation, the stronger the testing you might need.

Louisa Harvey (ClariMed): Lovely, thank you, Angelina. And there's another question that's come through. Are there any benchmarks for assessing notified body competency regarding legacy devices and also IBDs as well? That's quite an interesting question.

I will say… the notified bodies that I have had great relationships with and provide excellent rigor for me have been BSI, TUV, and DECRA, but that's my personal experience. I've worked with other notified bodies, and I… smaller notified bodies. It's the experience that you have, but there's a reason why those are the top Notified bodies is when the… the expertise that they have, and Again, notified bodies have to be qualified to even assess for these regulations. So if they're qualified, that means they've demonstrated the threshold to evaluate under the regulation.

I think what I would add to that is, they perform reviews in a slightly different way to people who are used to dealing with the FDA perform them. They're very much applying their rigor to whether you've adhered to a standard. So, if you're… so, actually, to the point where my experience with certain notified bodies is they go through a checklist. does someone have a use specification? Do they have this section complete? Do they… you know… so… so whilst they are very good at doing that, what they're looking for is very different to how a human factors reviewer at the FDA might review your human factors file.

But yes, I agree, they are all qualified and competent to perform the reviews, but the review is maybe not Exactly the same as you would expect from other regulators.

I think the best source of truth is Go plug in the standard into ChatGPT, create a checklist. Do you meet every part of that standard? or you have rationale for it, I think you've covered yourself there as best as you can.

Louisa Harvey (ClariMed): Thank you very, very useful answers. So we're coming up to the end of the session. So, if anyone wants to know how ready they are, I do have, a readiness checklist that you can, you can check, and you can also book a free readiness session as well. And also, I know that, panelists would be very happy to answer any, any further questions you may have, post this discussion as well. Louisa Harvey (ClariMed): So I just want to thank you both very, very much, Angelina and Jenny, that was extremely insightful. I've learned… learned loads. Thank you, Sean, for… for organizing as well.

Louisa Harvey (ClariMed): I think that's everything. Sean?

So, final word is, if you didn't put in your certificate of, attendance request, please do so. If you would like a copy of the checklist, write checklist in the chat, or message me. And I would like to, express my gratitude to everyone who gave up an hour of their time today to attend. the speakers for all their hard work. my partner Claramed, and Angelina especially, for coming and lending her expertise, and years of experience and insight to everyone. This has been a very, very valuable session. The recording and slides will be made available to everyone who registered tomorrow by way of Zoom email, you'll get a link. But again, if you have any questions, comments, or concerns, please reach out to me, and we look forward to having you again soon. Thank you so much.