In this blog post, we will cover key components of the important medical device standard ISO 13485 and cover steps for successful adherence.
In the complex world of medical device development, teams not only face challenges of innovation, but also a shifting regulatory environment and evolving standards.
Balancing the competing interests of customers and stakeholders with the guidance and regulations from different entities across global boundaries presents challenges that even the most organized and methodical teams may struggle to meet.
In this environment, systems thinking can greatly improve the ability of medical device development teams to get products from the idea stage to market. By breaking down complex problems into manageable pieces, teams can better evaluate their systems and streamline and strengthen processes.
Using an applied systems approach will also help resolve inefficiencies in the development process and produce the outputs necessary for the design history file (DHF).
A growing number of organizations and teams are already pursuing a general systems approach by applying the guidance in ISO 13485:2016. This standard helps define a framework for the Quality Management System (QMS) for medical device development and pushes the development process naturally toward a systems approach. But for those teams that have not yet adopted the standard, adding one more document or piece of guidance to the overall process can feel like another layer of complication.
It doesn’t have to be. Adopting this standard can help standardize and systematize the medical device development process. Though it may look daunting at first, once adopted, ISO 13485 can streamline processes and position organizations for a better outcome with regulatory requirements.
The standard was developed by the International Organization for Standardization (ISO) to outline the standard for a Quality Management System (QMS) for the design and manufacture of medical devices.
The ISO defines “medical device” as “a product, such as an instrument, machine, implant or in vitro reagent, that is intended for use in the diagnosis, prevention and treatment of diseases or other medical conditions.” It is a stand-alone document designed for use by organizations of any size involved in any stage of medical device development, from design to production to installation to service of devices. Both internal and external parties can use the standard to support the auditing process.
ISO 13485 is the most common standard for quality management in the field of medical device development across the globe. Adoption of the standard indicates a commitment to the highest quality and safety across the development process, and it provides a foundation for QMS requirements.
While not required by all government entities, the standard does provide a good foundation for addressing regulations such as the EU Medical Device Directive and the EU Medical Device Regulation. In 2018, the FDA proposed a rule that would align US FDA 21 CFR 820 with ISO 13485:2016; this rule would make this standard the mandatory QMS for medical devices.
Note: The rule was set for release in 2019; however, as of December 2020, the rule was still forthcoming. Check for current guidance.
Though adoption of ISO 13485 may look complicated or daunting, in reality, adhering to the standard helps eliminate some of the ad hoc nature of requirements and systems in the medical device field.
With increasing worldwide adoption of ISO 13485 by both companies and government entities, the medical device industry should start to realize some harmonization and consistency of processes and systems. This standardization will help streamline the industry overall and allow important innovations a smoother and potentially faster route to market.
The requirements to obtain ISO 13485 certification start with a QMS. ASQ defines a Quality Management System as “a formal system that documents the structure, processes, roles, responsibilities and procedures required to achieve effective quality management.” The QMS must include documentation that defines the overall scope and implementation of the QMS; important documentation includes Quality Policy, Quality Objectives, and Quality Manual.
Bottom Line These documents should be sure to address customer requirements. In addition, organizations need to create mandatory and additional processes and requirements necessary for all stages of development. Examples of documents required by ISO 13485:2016 can be found here.
Key Takeaways from Our Complete Guide
ISO 13485 and systems thinking go hand-in-hand; teams will find that adoption of ISO 13485 directs them toward systems thinking.
Adoption of this standard will streamline processes and position medical device teams for better regulatory outcomes.
ISO 13485 is a stand-alone document; however, it closely aligns with ISO 9001:2008 and EN ISO 13485.
ISO 13485 and ISO 14971 are related, but ISO 14971 is more focused on risk management – the two standards can be used in tandem.
This standard is not mandatory; teams can develop a Quality Management System (QMS) without the standard as long as it meets regulatory requirements. However, adoption of the ISO 13485 will create a QMS that is ideally positioned to meet the requirements of various regulatory and legislative entities, including the EU.
Jama Software’s Complete Guide to ISO 13485 for Medical Device Development covers requirements for adherence, the difference between ISO 13485 and other medical device standards, and steps for successful adoption and certification.
Download The Complete Guide to ISO 13485 for Medical Device Development to untangle everything there is to know about this important standard.
https://www.jamasoftware.com/media/2021/02/2021-02-18-ISO-13485-ebook-1024x512-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2022-09-08 03:00:002023-03-20 16:46:12[GUIDE] ISO 13485 for Medical Device Development
In this post, we pull out key takeaways from a recent whitepaper written in conjunction with Beanstock Ventures on the new EU medical device regulations (EU MDR) and how they might impact medical device development.
As medical device technologies have rapidly advanced in recent years, regulations governing definitions, testing, and post-market activities have struggled to keep up. The pace of change and adoption of these technologies has made it difficult for governments and agencies to create the kind of inclusive and expansive rules that will ensure safety.
In response to this expanding market, the European Union released new guidance governing medical devices. With the release of Medical Device Regulation (MDR) 2017/745/EU, in 2017, the EU has issued the first updated regulations in more than 20 years. The new Medical Device Regulation (MDR) 2017/745/EU addresses software as a medical device [SaMD], as well as other products. It also places stringent requirements for compliance with post-market activities and post-market surveillance. While enforcement of these new regulations was scheduled to begin in May 2020, it was postponed until May 2021 due to the COVID-19 pandemic. What do these new regulations mean for the medical device industry? Experts from Beanstock Ventures explain what you need to know for EU MDR compliance.
The EU Medical Devices Regulation (MDR) has replaced the EU Medical Device Directive effective 26 May 2021.
The EU MDR is greatly expanded to cover more devices, including Software as Medical Device, implantable devices, contact lenses, and many digital health technologies. It also promotes a lifecycle approach to regulation.
EU MDR requires improved device traceability by introduction of a unique identification system, or UDI (see section 05), for medical devices approved for use in the EU. To keep track of devices through every lifecycle stage, a device identifier (UDI) will be assigned, and all production series will be marked with a production identifier.
EU Medical Devices Regulation (MDR), adopted by the European Parliament and Council as REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 5 April 2017, has replaced the former EU Medical Device Directive (MDD) and went into effect 26 May 2021. After this date, the MDR is applicable for all medical devices sold (developed or imported) in the European Union.
The most important changes in the EU MDR include:
Increased scope of medical device definition;
New classification rules (including Rule 11 that specifically addresses software);
Increased scope of general safety and performance requirements, technical documentation, and clinical data and evaluation requirements;
Introduction of traceability and identification system and database; and
https://www.jamasoftware.com/media/2021/12/2021-12-28-new-eumdr-regulations-1024x512-1.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2021-12-28 03:00:462023-01-12 16:47:48Key Takeaways: What the New Medical Device Regulations (EU MDR) Mean for You
Complying with FDA Design Control Requirements Using Requirements Management Principles
Mercedes Massana: So agenda for today is we’re going to talk a little bit about the design controls and what they are. We’re going to talk about requirements management and what that is. And then we’re going to talk about how the two relate to each other. Then we’ll discuss how we can build a good requirements management process and how that process can help us improve compliance to design controls.
Okay. So let’s get started. All right. So by the end of this presentation, hopefully you’ll have a good general working knowledge of design controls. You’re going to understand requirements management and how to evaluate and accept requirements, how to perform bi-directional traceability, how to use requirements attributes to help manage the requirements, and how requirements metrics can help you make better decisions. We’re going to learn how to manage and control requirements changes, and then how to use attributes, especially a requirements credit quality attribute to help us on manage and identify essential requirements and requirements that are critical to quality.
FDA Design Controls
Mercedes Massana: So let’s start with design control background. So design controls have been part of the FDA QSR since 1997. So it’s been a long time. The FDA initially implemented design controls to try to help medical device manufacturers identify deficiencies with design input requirements, to identify discrepancies between proposed designs and requirements, and increase the likelihood that the design transferred to production is going to translate into a device that is appropriate for the intended use and satisfies the user needs. And they did this in relation to having a lot of issues in the field with medical devices. So they thought design controls would improve the quality of the medical devices that were being approved.
In the FDA design control guidance, they state that developing a solid foundation of requirements is the single most important design control activities. So that kind of tells you how important FDA thinks design control requirements management is. So design controls is made up of several elements. There is design and development planning, design inputs, design outputs, design review, design verification, design validation, design transfer, design changes, and design history file.
Mercedes Massana: Now, most of those, even though requirements really falls under design inputs, and that’s what everybody understands by design inputs, most of these items relate to requirements in one way or another. So design outputs, we have to develop design outputs that will conform to design inputs. For design reviews, we’re going to review our design inputs to make sure that they’re appropriate and not conflicting or unambiguous. Design verification will confirm that design outputs meet the design input requirements. And design validation will confirm that the user needs and intended uses are met, which is their another form of design input.
And then design changes, obviously managing requirements changes is important. And obviously all our design inputs or all of our user needs documents or system requirements or product requirements documents will end up in the design history file. And then obviously our deliverables that user needs that we create, or system requirements, product requirements, all become part of our design history file.
Requirements Management
Mercedes Massana: So let’s talk about requirements management. So what is requirements? Why do we need requirements management? Why would we want to do this? Well, if your projects are late because you’re trying to introduce changes at the end, or if sometimes your developers can really figure out what the requirements may mean and they’re making their own interpretation, those are all issues that can be addressed through requirements management. In fact, it is said that approximately for IT projects, which encompass software obviously, that at least 50% of projects are late, or delivered with reduced functionality or over budget.
Mercedes Massana: If you have a good requirements management process, this will improve those statistics and make projects more successful. So what is a requirement? So for IEEE, a requirement is a property that a product must have to provide value to a stakeholder. That’s the IEEE definition. The FDA definition is a condition or capability needed by a user to solve a problem or achieve an objective. So couple of key items here is, something that is needed by somebody, right? So that tells you that anything that goes into your requirements has to have a purpose. Why is it there? And it’s needed to solve a problem. So it has to solve a problem for the user, right? So if it’s something that a software developer thinks is a cool feature, but nobody needs it, then it really shouldn’t be a requirement.
So requirements management process has four main goals. It tries to ensure that there is an understanding of requirements, but all the stakeholders, that they commit to those requirements or approve or agree that those are the requirements that need to be implemented. That we manage requirements changes. And we’ll talk what managing requirements changes means a little later. And then we identify inconsistencies between project work and requirements. And what that means is that you can’t have a project plan that says you’re going to be done in a year if you have 10,000 requirements to implement, right? So you have to have consistency between the requirements and the other deliverables of the project.
So to obtain an understanding of the requirements, first, we need to know who are we solving the problem for? Right? So we need to determine how we identify the stakeholders. So who are those requirements providers, right? Those are the stakeholders. We need to know how we’re going to evaluate the requirements, how we’re going to know if the requirements are good and complete. And then we need to know who needs to approve the requirements and when do requirements get approved. So that’s how we obtain an understanding of requirements.
Then a commitment to requirements is basically that agreement between the different stakeholders that says, if you develop these set of requirements, we’re going to have satisfied customers, that our agreement is usually made through approval of the requirements.
Managing requirements changes is, obviously the one constant in life is change. So requirements will also change. But it’s very important to manage changes so that the rest of the product reflects the impact of those changes, right? Nothing comes for free, and requirements changes usually are either going to cost more, and we’re going to have to add more resources or we’re going to have to add more scheduled, but something will have to be done in order to manage the impact of that change.
Requirements Traceability
Mercedes Massana: And then maintaining bidirectional traceability. This requires that requirements be traced forward from higher level requirements to lower level requirements and that every lower level requirement be able to be traced backwards to its parent or a higher level requirement. Additionally, other elements like design, tests and risks should also be included in our traceability. And later on, I’ll show you a fully elaborated trace matrix that shows the relationship between pretty much every deliverable that we’ll create as part of our development process.
All right. So what’s the connection between requirements management and design controls? So this table will show us a little bit of that. So these requirements management elements relate to design controls as follows. So design inputs are defined as the physical and performance requirements of the device that are used as the basis for device design. So the FDA tells us that design inputs must be appropriate. That we need to address incomplete, ambiguous or conflicting requirements. And that these requirements related to design inputs are addressed by the requirements management element and obtaining an understanding of requirements.
Design outputs are defined as the results of the design effort at each design phase and at the end of the total design effort. The FDA says that design controls must be able to evaluate the design outputs conformed to design inputs, that we must be able to establish acceptance criteria so that we can verify the design outputs conform to the design inputs. And then we identify the essential requirements or essential to proper function requirements. So again, requirements management can help us meet this part of the regulation.
FDA design controls also state that we must identify document, verify, validate and approve design changes before implementation. Additionally, the design control guidance specifies that the trace matrix is a form of verification. So both of these areas are also covered by requirements management. And here, we can see that there is definitely a relationship between FDA design controls and any requirements management process.
https://www.jamasoftware.com/media/2021/11/WB-2021-10-20_Complying-with-FDA-Design-Control-Requirements_Social-Image-1.png5121024Jama Software/media/jama-logo-primary.svgJama Software2021-11-11 03:00:122023-01-12 16:47:55Complying with FDA Design Control Requirements Using Requirements Management Principles
In this post, we will discuss why start-up medical device companies should prioritize requirements and risk management before a quality management system.
As a medical device product development consultant, I often see start-up companies having trouble deciding what to prioritize – design controls and risk management or the quality management system (QMS). And what they mean specifically is, which software systems should the company invest in first – the requirements and risk management solution that will aid in building a regulatory compliant design history file, or the electronic-QMS system to establish the FDA required and ISO 13485-compliant QMS?
From my experience over the past 15 years, here are the 3 reasons why I advise start-ups to prioritize requirements and risk management over an eQMS system.
1. Design controls and risk management processes start earlier
For best product, schedule, and compliance success, incorporating design controls should be done proactively instead of reactively. Companies are typically developing their medical device from day 1. This is compared to other QMS processes that may not be used until years later when the product is being transferred to manufacturing and being commercially distributed. A few of these other processes include non‑conforming materials, device master record, product change control, and complaint management.
Thus, purchasing a full eQMS system earlier than necessary results in paying for functionality that may not be used for years. That is of low value to the start-up closely watching its funds.
In contrast, as the medical device is being developed from the onset of the company, the benefits of requirements and risk management solutions can be realized very quickly and much sooner than a full eQMS system.
2. Requirements and risk management is often unwieldy
Unless your device is ‘simple,’ for example no software, no electro-mechanical parts, low-risk Class 1 devices; thoughtful consideration should be given to the processes and solutions that will manage the various requirements and risk management for your medical device development. Organizing all the user needs, design inputs, regulatory requirements, requirements from industry standards, system requirements, sub-requirements, and risk management can quickly become unwieldy without proper management.
In my experience, even a Class II electro-mechanical device can easily approach a thousand line items to manage and connect. Add on embedded software or a digital interface, and that number can easily jump to multiple thousands of line items or more, depending on the complexity of the medical device. A solution like Jama Connect® has immediate value to ensure all items are linked, traced, verified, and validated for a regulatory complaint design history file and medical device file.
3. In the early years, a company can create and manage a regulatory compliant QMS without an all-electronic system
Does forgoing the eQMS mean settling with a non-compliant QMS? No. A company can implement a regulatory compliant QMS without an eQMS system. SOPs can be implemented in stages, prioritized on the stage of the company. These SOPs, along with a cloud-based document sharing repository, is often sufficient in those early product development years. As the company approaches transfer to manufacturing and commercial distribution, then is the time to evaluate whether it’s time to transition to an eQMS system.
Summary
In summary, these are the three reasons I advise start-ups to prioritize requirements and risk management first before an eQMS system. This path allows for the development of a successful product and complaint design history file, as well as establishing the rest of the quality management system, all in a practical manner that maximizes value and meets regulatory expectations.
https://www.jamasoftware.com/media/2021/10/2021-10-28-why-med-device-startups-prioritize-rm-risk_1024x512.jpg5121024Michelle Wu/media/jama-logo-primary.svgMichelle Wu2021-10-26 03:00:132023-01-12 16:47:57Why Startup Medical Device Companies Should Prioritize Requirements and Risk Management Before QMS
Over the last decade, digital health solutions have become increasingly important, powering revolutionary developments in areas such as robotics, genomics, diagnostics, patient/provider interactions, and many more.
In our recent webinar with MDM Engineering Consultants and BeanStock Ventures, we talked about critical standards and best practices to follow. Attendees also heard critical insight from industry leaders in digital health development.
Watch the webinar or read the recording to learn more about:
Digital health solution classifications
The most common digital health development challenges
How Jama Connect can be leveraged in your development process to help ensure FDA compliance
Industry leading insight and knowledge
Below is an abbreviated transcript and a recording of our webinar, Ensuring FDA Compliance for Your Digital Health Solution.
Mercedes Massana: Digital health merges different digital technologies to make health and healthcare applicable to our living in society and make it more personalized for the patient. Many people see digital health as the future of healthcare. Some things that are digital health are like wearable devices. For example, your Apple Watch. It has some sensors that can do an EKG. That would be considered a wearable device. Things like telehealth and telemedicine, which we all became more familiar with because of COVID, are also part of digital health.
For digital health to use technologies such as different computing platforms connectivity, which is very important because you’re trying to get information to the healthcare provider, software plays a huge and significant role in digital health, and then different technology with sensors. So these technologies are intended to be used as a medical product or as a companion diagnostic to a medical product and help the healthcare provider make decisions. Software is playing an increasingly important role in healthcare in general. As medical devices have gotten more complex, software has played a bigger role.
Three Types of Software in Medical Devices
Mercedes Massana: There are three different types of software related to medical device. One is software in a medical device, embedded in a medical device. Another is software as a medical device, which we’ll call SaMD, and we’ll be discussing today. And the third is software used to produce or maintain a medical device. All these three types of software are regulated by the different regulatory agencies. Software as a medical device, is software that is intended to be used for one or more medical purposes that perform these purposes without being embedded in a medical device. So when we say embedded in a medical device, it’s software that’s physically part of a medical device. Like an infusion pump has embedded software in it that runs on the GUI on infusion pump.
This means that this software that’s a medical device in itself is not something that’s tangible. It’s not something that you can touch, like a medical device where you can touch. Well, this software lives on the ether and it’s not something you can touch. But it provides meaningful information that can help you mitigate disease, it can help you diagnose screening. For example, if you had software that took information from an MRI and helped define whether cancer was present, that would be software as a medical device. It takes information from another device and it helps a healthcare provider and make a diagnosis.
Determining the Intended Use of Software in a Medical Device
Mercedes Massana: So for software as a medical device, an important part is to determine what that intended use is. And in order to do that, guidance documents provide… You have to provide the answers to these three very direct questions. One is what is the significance of the information provided by SaMD to the healthcare decision? Is this information going to be used to help treat a disease, to help diagnose a disease, to help clinical management of the disease like diabetes, or to just inform clinical management? Obviously, it’s more critical if it’s going to treat or diagnose a disease. We also want to know the healthcare situation or condition, the scenario in which the software is going to be used and whether absence for incorrect information at that time can result in critical and putting somebody in a critical position, where they might be subjected to serious injury. Or in a serious position where they might be subjected to additional procedures and things that would not be necessary. Or in a non-serious position where it’s just information is not really that critical.
And then we also want to know what is the core functionality of the software. What are the what is it supposed to do? What are his critical features and functions? So based on these three questions, we would craft an intended use statement for the software as a medical device. The healthcare situation, there’s three different classifications, as we said. Critical is where accurate or timely diagnosis or treatment action is vital to avoid death or serious injury. Serious is where we need accurate and timely information in order to avoid an unnecessary intervention. And then non-serious is where the information is important, but it’s not critical in order to avoid that serious injury or unnecessary intervention.
Using Categories provided by International Medical Device Regulators Forum (IMDRF)
Mercedes Massana: Once we’ve determined what that healthcare situation or condition is, then we can determine the significance of the software. We use the categories provided by IMDRF, which is the International Medical Device Regulators Forum. This organization has actually generated some guidance for SaMD. And it’s used by regulators to try to have some common level of standards on how the software is going to be regulated. So in order to get to the classification, we determine the healthcare condition, what’s that healthcare scenario. And then we determine what that information provided is going to be used for. So if it’s going to be used to treat or diagnose disease, and it’s in a critical scenario, that will have the highest level of criticality, which is a four. There’s four levels of classification one being the least critical.
Again, it’s a level of one to four. Four has a very high impact and one in low impact. So, a device that would screen for cancer or something that software would be used to screen for cancer, would be very high impact. Something where maybe we’re sending a heart rate for somebody who’s going through cardiac rehabilitation, that might be a lower impact because it’s just using to inform the clinician on how things are going, but it’s not being used directly to impact on the treatment. There are additional ways to classify medical devices. The global harmonization task force has a classification of A, B, C, or D. So four stage classification, where A is the lowest level of risk, and D is the highest level of risk. These can be used because SaMD is in itself a medical device, we can use this level too.
Mercedes Massana: Additionally, IEC 62304 classifies software in three different classes, C, B or A, where C is if the software fails, it can result in serious injury or death. B it can result in non-serious injury. And A would result in no injury or harm. Now, why is it important to classify software? Because this will tell us how much effort we need to put into the documentation and testing and so forth of software. Obviously, the more critical it is, the more effort it will be required. FDA also classifies software. They have a level of concern for software. And there’s three levels also which align pretty well with the definition of IEC 62304. For FDA, they use major, moderate and minor.
Software in general has always been challenging for manufacturing. Software as a Medical Device (SaMD) poses some additional challenges to the developer of the software. Some of these are, for example, the use of off-the-shelf software is a lot more prevalent in SaMD than it is with embedded devices. Regulatory agencies want to see a lot of information when you’re using off-the-shelf software or suit, which is software of unknown providence, so there’s a lot of requirements that you need to meet. This is essentially software that you don’t own, you don’t have the source code for, but it’s still used in your medical device, so you’re still responsible to ensure that it’s safe within the parameters that you’re using it. Software as a Medical Device also, it will run on different platforms. It can run on a computer. It can run on an iPad, it can run on a smartphone as opposed to embedded software where you know the environment that it will always operate in. So it is a challenge to ensure that software behaves effectively in any of the platforms that it will run it.
Challenge: Interconnectivity with Other Systems
Mercedes Massana: Even though most medical devices today have some form of interconnection right to other systems, for SaMD, it’s almost given that it will have to be interconnected because the information will have to get to the healthcare provider, and that is typically through the internet. It’s going to be sent… There will be connectivity to other systems that will provide challenges like cybersecurity. We need to keep information safe. Those are challenges that we need to meet. Secondly, the method of distribution, the frequency of updates of SaMD is different than that of an embedded medical device. So for an embedded medical device, the device gets built, the software gets put in EPROMS that gets built into the device, the device gets packaged. It gets sent out to a pharmacy where you might buy it or it gets sent out to a hospital where it will be unpacked and tested.
Well, Software as a Medical Device is not a tangible thing, so it’s going to be distributed through the internet there is no checks and balances there. There’s no checksum to know that you’ve downloaded it correctly, so it proves some additional challenges there. And then lastly here, it’s much easier to duplicate software that’s on the internet that you can download. The manufacturer doesn’t always have control of how this software is duplicated, as opposed to software for an embedded medical device where in the manufacturing facility it gets thrown into EPROMS and then gets put into the medical device. So the manufacturer has control. For SaMD, the manufacturer does not have control, or does not always have control.
Mercedes Massana: For most applications, the apps we have on our smartphones, they get updated probably three, four, five, six times a year. So for a medical device software, you need to have a pretty rapid development time in order to keep up with this change of information. Then there’s also cybersecurity risks that we need to be aware of. Again, information security is a big issue. SaMD is something that regulatory agencies are very interested in. How do we get to meet these development challenges? Well, we need to have a very robust design development process to help us meet these challenges. We need a process that’s very methodical and systematic. We need a good quality management system. And then we need a software lifecycle process that takes us through the entire software lifecycle for the development of this application. It should take us from the point of where we’re starting to understand user needs, all the way to where we’re ready to retire the software. IEC 62304 is such a process where most people that are developing medical device software are utilizing this process.
Challenge: Managing Software Changes
Mercedes Massana: In addition, because the environment that the software is used and can change after release of the software, it is important to have a very strong post-market surveillance process to monitor customer issues in the field. You also need to monitor for cyber security threats, things like that. And you might need to make changes to your software based on what you’re observing in the field. So a post-market surveillance process is very important. Additionally, managing software changes, which is always important no matter what the software is used for, whether it’s a Software as a Medical Device, or embedded software in a medical device, is very important to manage changes. But for Software as a Medical Device, it’s even more important because what you change in the software could actually change the classification of the software. It could be more critical or less critical and it can also change the intended use. If you change the intended use, that means that you’re going to have to submit to regulatory agencies, so you want before you get approval to market that software.
There are a lot of software applications. Now, Software as a Medical Devices where they’re getting so much data and information that they’re using artificial intelligence, or machine learning to make the software smarter and better. Using this could potentially change the classification of the software. SaMD is still fairly new to regulatory agencies so I don’t think they’ve figured out exactly how they’re going to regulate things like artificial intelligence and machine language. But managing changes and understanding the impact of those changes is very important for our Software as a Medical Device. There aren’t a lot of guidance documents out there for Software as a Medical Device, but luckily there are a few standards that can guide us in our development efforts.
https://www.jamasoftware.com/media/2021/09/2021-08-19-digital-health-webinar-1024x512-1.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2021-09-07 03:00:502023-01-12 16:48:06Ensuring FDA Compliance for Your Digital Health Solution
The medical device market in Europe is growing fast and is expected to reach $61.4 billion by 2025, up from $48.9 billion in 2020. A large aging population, demand for more surgical procedures, and technological expansion are driving this trend.
The Medical Device Directive (MDD) is a legal framework that includes three directives that are designed to regulate the safety of medical devices in Europe. The MDD came into effect during the 1990s; however, since that time, the technology landscape has quickly evolved. Many technologies that didn’t exist previously, such as software as a medical device (SaMD), are now widely used to treat, diagnose, mitigate, and even prevent disease.
Governing agencies were concerned that the MDD was outdated and didn’t address many evolving safety threats. As a result, they developed a whole new set of standards called the European Medical Device Regulation (MDR). Medical device companies that are already compliant with MDD regulations shouldn’t be fooled into a false sense of security. The EU MDR is far more comprehensive than the previous regulations were. Understanding what the MDR is, changes to the regulations, and what to expect can help your company get prepared and stay compliant in the future.
The Medical Device Industry is Undergoing a Time of Rapid Growth
The industry in Europe is expected to reach $61.4 billion by 2025, up from $48.9 billion in 2020. The rules that applied to medical devices are shifting to keep up with that growth and the resulting innovation.
What is the EU MDR?
The European Medical Device Regulation is an entirely new set of standards that outlines rules around the production and distribution of medical devices in Europe. The regulations were designed to ensure that companies produce medical devices safely and that potential risks are mitigated. The prior document, the MDD, had roughly 60 pages, compared with the MDR which spans 174 pages. The new document includes a 13-page introduction, 123 articles, and 17 annexes. Additionally, there are 42 implementing acts, which further clarify the MDR, and 12 delegated acts, which modify and amend the regulation.
Understanding the major changes can help you better understand how to stay compliant.
MDD vs. MDR: What’s the Difference?
MDD REGULATIONS: Roughly 60 pages in length and focused heavily on the preapproval stage of medical device management.
MDR REGULATIONS: Includes 174 pages that present a lifecycle approach to regulations. Expanded to include new categories of coverage, such as cosmetic devices, contact lenses, and many others, as well as more rigorous oversight.
To learn more about EU MDR and get a better understanding of the changes being made, download our full EU MDR eBook.
https://www.jamasoftware.com/media/2021/07/eu-mdr-ebook-1024x512-1.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2021-07-08 03:00:102023-01-12 16:49:01EU MDR: What You Need to Know
Editor’s Note: This posts on EU MDR was originally published here by MedTech Drive and written by Greg Slabodkin.
Dive Brief:
While the Medical Device Regulation’s May 26 go-live date marks a significant milestone, MedTech Europe warned in a statement that MDR challenges remain, limiting the industry’s ability to “seamlessly supply certified devices under the new rules.”
The European trade group contends that despite the EU MDR going into effect, “some key pillars” of the necessary infrastructure are “still not fully operational or even in place,” creating challenges in particular for many small and medium enterprises.
CEO Serge Bernasconi argued that the complexity of MDR and the delay in the new regulatory system’s full readiness is resulting in European patients “losing their previous opportunities to be the first to benefit from critical medical technology innovation.”
Dive Insight:
MedTech Europe had been sounding the alarm for some time about MDR’s potential to disrupt product supply due to issues around the ability of the EU’s infrastructure to ensure a smooth transition when the rules came into force on May 26. Now that the new regulatory regime has reached Wednesday’s date of application, the trade group is once again warning that significant challenges remain unresolved that could negatively impact the sector.
A range of MDR uncertainties and potential problems are hovering on the horizon. While the medical device industry has resolved some near-term pressures as the delayed landmark regulation goes into effect, MedTech Europe on Wednesday listed a litany of MDR challenges that are hindering the successful deployment of the new regulatory system.
These MDR challenges include:
Non-harmonized interpretation and application of MDR rules across the EU.
Limited capacity among notified bodies, especially for certification of new and innovative devices.
Uncertainties with regards to pending discussions on the rules and agreements between the EU and other countries such as Switzerland.
Unpredictable recognition of MDR certifications at the international level vis-à-vis regulatory approvals from other jurisdictions.
“Such challenges need ongoing attention and work by the EU Commission and Member States, if Europe is to ensure a workable system in the long-term,” MedTech Europe said.
The trade group also highlighted an urgent need for attention to be given to the In Vitro Diagnostic Regulation, a major overhaul of the diagnostics sector slated to go into effect in 12 months.
“As with the MDR, the medical technology industry fully supports the new regulatory regime for IVDs but due to many factors, the system is not yet ready to support its implementation. Urgent solutions are needed here as well, and lessons learned from the MDR implementation should be taken into account,” according to MedTech Europe.
The group added that it is working with the EU and stakeholders to “rapidly propose solutions to avoid disruptions” in supply of medical devices and diagnostics.
https://www.jamasoftware.com/media/2021/06/2021-06-23_MDR-MedTech-Post-1024x512-1.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2021-06-23 03:00:262023-01-12 16:49:03MDR Challenges Remain as Regulation Goes Into Effect: MedTech Europe
2020 has been a year that’s been described as “unprecedented” and “unparalleled” – as well as other descriptors probably best left out of our blog. As we close out this year, it’s hard to say what awaits us in the new one. One thing that we can be sure of is that innovation in medicine, science, and technology shows no sign of slowing down.
As we enter a new year of technological advancements, Jama Software asked select thought leaders – both internal and external – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In Part I of our four-part series, we ask Steven Meadows, Medical Device Solutions Lead at Jama Software, and Founder & CEO, Shawnnah Monterrey at Beanstock Ventures to weigh in on trends they see in the medical device industry for 2021.
Note: Now that our 2021 Predictions Series is complete, you can also go back and read, Part II,Part III, and Part IV.
What are the biggest trends you’re seeing in the medical device industry right now? How will they impact products, systems, and software development?
Steven Meadows:
From a product perspective, there are a number of areas in the medical space that are set to grow in 2021 and beyond, including robotics nanotechnology, wearable health tech, and extended reality devices.
With more medical devices incorporating software components and connecting to systems, like hospital networks, enhanced cybersecurity is becoming increasingly important. Medical device companies will continue to invest heavily in this area through 2021 and beyond.
Shawnnah Monterrey:
There are three primary trends that I am seeing: A shift in initial product launches from Europe to the United States; An increase in Software as Medical Device products; and an increase in IVDsfrom lab-developed tests.
We are seeing a shift in initial product launches from Europe to the United States, due to the upcomingEU MDR regulations.Typically, US–based companies would launch medical products in Europe first, followed by a US launch shortly after due to the rigor and lag time in receiving FDA approval. CE Mark was typically more straightforward, required less clinical evidence, and was a faster process, especially when companies could self-certify.EU MDR is currently being perceived to be more onerous than the FDA regulatory clearance process and is therefore creating a trend of product launches occurring first in the United States and then in Europe. The cascading impact would therefore be the need for more services providing expertise in regulationsto support EU MDR and a need for a more harmonized regulatory strategy.
The second trend we are seeing is an increase in Software as a Medical Device (SaMD). There have been numerous healthcare, fitness, and consumer products launched into industry recently that were not previously considered a medical device. As a result of the SaMD FDA guidancecombined with the EU changes from CE, MDDto EU MDR, many products that were not originally deemed clinical products or medical devices are now falling into that category. Products that were previously not classified as medical deviceswere not necessarily held to the same standards thatare required to produce a medical-grade product such as quality management, design control, risk management, clinical studies, and post-market surveillance. This shift will cause companies to delay product launches in order to satisfy the regulatory requirements, resulting in an increased need for training, systems, software, and tools to make it easier for companies to make that transition. Since these companies generally lackquality and regulatory expertise, additional support will be requiredto deliver medical-grade software products.
The last trend we are seeing is an increase in IVDsfrom lab-developed tests (LDTs), research use only (RUO) and emergency use authorization (EUA).There are numerous laboratory-basedtests and associated software that havebeen developed to support very complex assaysthat are being used clinically which has recently been deemed outside of the scope of LDT guidance.Products that were covered under CLIA are now required to be cleared with the FDA and EUas an IVD.From a CLIA perspective, the focus is on validation. Validation is centered on the intended use of the product and workflow. But with medical devices such as IVDs, there needs to be a shift to bringing it down to verification levels –namely design verification. Design verification is quite different than validation, design verification islooking at the design aspects of the product, not from a workflow perspective, but from a design feature perspective.Design verification occurs at the subsystem and system level, where the subsystem is the breakdown of the system from the architecture.The scrutiny will be from a hazard perspective for the entire system and a failure mode analysis perspective at the subsystem level. Finally, ensuring that there is a full product definition and full verification associated with theproduct. The impact is that it is going to require taking a different look at the software that has been provided and looking at it differently from a process software perspective to an IVD perspective this might require looking at the architecture and redesigning the system to break apart the items that were allocated to CLIA and the lab system processes versus the actual product that performs the clinical interpretation and the diagnosis.
An overarching impact will be evolving medical device productdevelopment from a methodology perspective. Manycompanies are lean and agile and are performing continuous integration and development of their products. It will be important to set up processes and procedures to still allow for that while continuing to meet the regulations. From a systems perspective, it would be beneficial to take advantage of available tools.There isa myriad of tools in place that can assist indevelopingquality management systems, manage design control, support requirement and risk management, testing, test automation, and deployment. There is anopportunity for companies to start investing in tools to help withcompliance and save time and money whilestill maintainingtheir efficiencies.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
Steven Meadows:
Software is becoming an increasingly used component in medical devices and we expect this trend to continue. More of our customers are adopting an Agile methodology when developing their software, a shift that has been happening for some time, and will continue to over the next decade.
Shawnnah Monterrey:
Over the next decade, I see the use of Artificial Intelligence (AI) supportingthe creationof sophisticated data-drivenalgorithms such as autonomous diagnosis. AI is gainingrenewed traction, even though it has been used in medical products since the 2000s. I believe there will continue to be a tremendous amount of investmentin the development and understanding AI in the healthcare space and how it could be used to improve clinical outcomes. AI will continue to progress over time as the industry develops an understanding of the utility and how it can contribute to guiding clinical decisions as an autonomous tool. Thereis FDAdraft guidance around AI, however, I think the biggest potential constraint will be how to continuously improve upon the algorithms as new data comes in, without requiring a new regulatory submission.
The other trend I see progressing over the next 10 years is one we are already seeing,cybersecurity. This trend is a bi-product of the increasing numbers of clinical cloud applicationsthat integrate with or use medical devices. As the need for sharing clinical data, advanced computing, remote diagnostics,and accessibility increases, so will the migration of healthcare applications to the cloud.This increased need will be the catalyst that pushes up the demand for securing patient data not only in terms of patient privacy but also in terms of patient safety.We have seen several instances now where, established medical device manufacturers, medical device cloud software, could be hackedby an unauthorized person and potentially cause adverse side effects to the patient. Such hazards could trigger a class I recall, the most serious type of recall. Not only do these hazards put patients at risk, but they also impact a company’s reputation and financial viability. Occurrences like this will justifiably result in a growing emphasis on creating software systems, processes, and tools tosupport the industry inmaturing standards and guidance around cybersecurity.
In terms of what will remain the same in the medical device industry throughout 2021, I would say that the regulationswill remain unchanged. It is unlikely we will see a change in this coming year. To the contrary, we will likely see an increase in the regulation. Ipreviously discussed the potential for harmonization. However, I do notbelieve that will happen until there is a push for it or until the FDA acts on the overlap between many of the guidance documents. Additionally, there will need to be harmonization on the development methodology across different devices so there is not a need to have different guidance documents. In short, I do not see the regulations changing over the coming year.
In discussing 2021, we should also take a moment to discuss Covid-19. It’s not my belief that things will change from a Covid perspective. The trend that I see continuing involves businessesincreasingly going digital, putting pressure on products to focus on cybersecurity. Specialties, such as telemedicine will likely increase, requiring true patient authentication and there will be progress, but a delay in medical device development in areas of selected surgeries.
Regarding development teams, I think Agile is here to stay. I thinkthat development teams will continue to use the agile approach and methodology. The organizational struggle of internal alignment of the quality management system will persist until there is adisruption in the regulatory environment itself. Relative to the need for systems as software tools become more useful and more integrated. The main area I see increasing are the new entrants into the market.There has been a large amount of new investment and I believe that will continue.I think we can assume that there will still be quite a bit of investment opportunities for new players.
What sorts of process adjustments do you think development teams will need to make to accommodate these changes? Do you think they’ll need to make technology investments, process adjustments, or both?
Steven Meadows:
As we continue to deal with the new normal, I expect medical device teams to continue to invest in collaborative product development software, enabling their teams to continue bringing new devices to market in a safe and competitive way. Development teams, using legacy product development platforms and Word/Excel need to switch to a modern alternative, in order to be as successful as possible in 2021.
Shawnnah Monterrey:
My belief is that development teams are going to need both technology investments and process adjustments to accommodate the changes that are coming. There will be a heavy reliance on technology as the software realm moves more towards focusing on core IP and leveraging the existing software components available. For example, there could be an organizationsuccessfully providing cybersecurity packages where other organizations may not have that expertise, so they would be leveraging assets from another organization.In short, software re-use will be important.
My sense is that the industry will shift more towards investing in technology such as AI and mechanisms to improve data sharing.There is an opportunity to really understand the clinical value that the data brings.Currently, the healthcare environment iscomprised of disparate systems that will eventually need to come together to be able to fully leverage the data and use the data in unique yet meaningful ways.
We are currently seeing a big shift where the medical device companies and their quality management systems do not satisfy the way in which engineers perform medical device development. For example, software engineers are very agile and tool oriented by nature, while many established companies still utilizea paper-based quality management system or document control system. We’d like to see software teams and the Agile methodologiesdrive changes to the quality system so that the quality system can be nimbler and more adaptiveallowing them torelease compliant products faster.
We have observed a hindrance in the companies and auditors themselves to adopt a more progressive and nimble approach that is not necessarily driven by the regulations. Our interpretation is that the intent of the current regulations is to be nimble andstill provide safe and effective products.My belief is that if we do not make a change to the current way in which we develop medical devices in thecorporate environment, innovation from these larger organizations will be stifled. The innovation gap will ultimately be filled by startups entering the marketplace and experiencingimmediate success because the old way of doing things is no longer sustainable or effective. I foresee a trend in an increase in the volume of new, emerging, small players. These players are going to be nimble and will look at the regulations from a different perspective.
How do you foresee regulations shifting in the medical device industry over the next decade?
Steven Meadows:
Key medical device standards and regulations are constantly changing. Notably, EU MDR is undergoing a number of changes and will need to be fully implemented by May 2025. Key standards like ISO 14971 go through multiple iterations and Jama can help our customers stay current with these changes.
Shawnnah Monterrey:
I will say something that ‘should’ happen, not that ‘will’ happen,relative to regulatory changes in the medical device industry over the next decade.Ideally, there would be harmonization across the guidance documents. There are too many guidance documents and many of them are repeating the same requirements but in different ways. With a harmonization effort, it would remove the perceived burden of applying multipleguidance and standard documents. With the current format, there is a need to understand each and every guidance and standard document andto be able to apply them all correctly. With more alignment and more harmonization, it would facilitate adoption and push forward innovation.
The impact of harmonization would certainly be in facilitating development. Withone cohesive guidance document and less confusion in applying multiple regulations and guidance documents across development, it would result in more development. If there was more alignment across the agencies to create cohesive processes, it would be easier to get consistency in the application of it. Additionally, the FDA’s time to approve products would be reduced because the FDA would be seeing similar submissions and be able to focus on the critical aspects of the product.
Anotherregulatory change that I expect to grow over the next decade is with the FDA’s adoption of third-party review organizations. The FDA has begun utilizing third-party vendors to streamline and offload their burdenof reviewing Class I & II devices. By working with approved partners to facilitate the review, the FDA can focus on higher risk devices. This allows a company’s submissionto get reviewed more quickly. Over the next decade, the FDA will likely become more sophisticated in this partnership with third-party organizations. The impact would be a faster time to market, possibly launching products months more quickly.
What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?
Steven Meadows:
Medical device companies that embrace a proactive approach to quality will ultimately find fewer issues with their products, improve customer satisfaction, and stay competitive for the foreseeable future. Companies that invest in best-of-breed medical device development solutions like Jama Connect will have the upper hand in reducing risk and complying with various standards and regulations.
New cutting-edge technologies in the medical field, like robotics nanotechnology, and wearable health tech devices, bring complexities for medical device companies and risk for patients and consumers. Jama Software will continue to serve as the leading solution and partner to help innovative companies bring medical products to market, in a collaborative, safe, and efficient way.
Will those trends still be prevalent 5 years from now? 10 years?
Shawnnah Monterrey:
I believe there will be disruption in the regulatory space in the next five to ten years, so I do not see the trends staying the same.
It will be important to have industry guidance by having industry experts partner with the FDA to help make those improvements. Based on the FDA approach currently, I believe they will welcome industry guidance.In relation to the previous discussion of the FDA 510(k) Third-Party Review Program, if we want to put it into a broader bucket, this is really the FDAutilizingexternal resources to support the industry.However, the collaboration is not simply due to a lack of resources, it is also because there is a very challenging, difficult infrastructure to navigate. I believe that there is a push to simplify the system and there will be a reliance on industry partners to do so. The industry partners will include those that are doing software product development, providing quality regulatory services, and providing tools to help facilitate medical device development.
What innovations in regulation in the medical device industry do you hope to see in 2021? 5 years from now? 10 years?
Shawnnah Monterrey:
The innovations in regulation in the medical device industry that I hope to see is the increasingopportunities for companies to collaborate with the FDA. I also hope to see more companies, larger organizations, or startups, take a more lean, nimble approach and be more receptive to the Agile methodology that software development teams are currently using. Current processes and procedures were generally derived from good engineering practices;however,perspectives of quality and regulatory experts and independent auditors remain the same. I would like to see them be more adaptive towards compliance,as compared tothetypical approach of checking the box, and instead, establish a partnership with their medical device development team to help facilitate compliance without sacrificing the quality of the product.
More specifically, I would like to see more efficient uses of tools and technology to support medical device development. There are many tools out there, butthey are very disparate.I believe that with more cohesion between those tools it would better facilitate medical device development to comply with the regulations.
In five years, my hope would be that there would be a first pass at simplifying the guidance documents.
In 10 years, I hope to see a streamlining of the processes. I hope for standardization of the submissions.I would hope to see a simplification of the current guidance documents across the board in the form of a standard method for supporting 510(k) and PMA submissions.
Stay tuned in the coming weeks for additional 2021 predictions! In the meantime, to see more information specific to the medical device development industry, we’ve compiled a handy list of valuable resources for you!
https://www.jamasoftware.com/media/2020/12/2020-12-16_2021Predictions_Med_1024x512-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2020-12-16 03:00:022023-01-12 16:49:402021 Predictions for Medical Device Product and Systems Development
In 2016, the Jama Software team proudly announced that we had received a certification from internationally-recognized testing body TÜV SÜD. Jama Connect™ was certified as a software tool for development of safety-related products according to ISO 26262 (up to ASIL D) and IEC 61508 (up to SIL 3). It was especially noteworthy, as Jama Software was one of the first vendors to be both SaaS and agile to have received this certification.
Three years later, we are excited to announce we have extended the scope of our certification from TÜV SÜD. Jama Connect is now also certified as a software tool for development of medical devices according to IEC 62304 and railway applications according to EN 50128.
This new certification gives medical device developers and railway application developers confidence that Jama Connect has been evaluated and qualified for defining, building and testing products that have to meet critical functional safety requirements.
We recently talked with Christian Nowak, Functional Safety Expert at TÜV SÜD, to discuss what is required to receive such certifications and what they mean for our customers.
Jama Software: Can you explain, generally, how the certification process is completed?
Christian Nowak: For a software tool certification, we are focusing our assessment on the development processes and the validation approach and evidences provided by our customers. An important activity is the on-site audit at the customer’s premises. The first audit was conducted in 2016 as part of the original certification and we performed a three-day re-audit in June 2018 at Jama Software’s headquarters in Portland, OR.
During the initial audit we looked at the organization’s processes in the light of the functional safety standards’ requirements for developing and maintaining safety-relevant software. The recent re-audit included sample checks to see if these processes are being followed based on the evidences created.
We also discussed and assessed modifications and improvements of processes, which play an important role for verification and validation especially in the context of the Agile development approach at Jama Software.
JS: What is required in addition to the on-site audit?
CN:The on-site activities are usually supported by off-site reviews of the documentation evidences generated by the customer. Due to the agile development approach at Jama Software leading to frequent releases, our assessment approach had to be adapted and is following this pace.
In other words, we are regularly assessing the modifications Jama Software is applying remotely and updating our certification report accordingly. In a way, our assessment approach has, in this case, also become “agile.”
JS:What does this certification mean for our customers? How can they benefit from these certifications?
CN: Every Jama customer who is attempting to adhere to the mentioned standards for developing safety-related systems, hardware or software must provide documentation evidences addressing the requirements defined in the standards.
Those requirements also consider the software tools that are used for the development of safety-related systems, hardware or software. The idea is that systematic faults should be avoided not only in the actual developed systems, hardware or software, but also in the software tools used for the development.
By undergoing a successful third-party certification by an accredited testing body like TÜV SÜD, Jama Software demonstrates that they are following adequate development processes and performing adequate validation activities for preventing systematic faults.
Thus, Jama customers can use the TÜV SÜD certificate as an argument for software tool qualification in projects where increased confidence in the software tool is required. They do not have to spend all the efforts for qualifying the tool themselves; they only have to make sure that they are following the safety manual that Jama Software is providing for each release.
JS: What is the value for organizations developing products in accordance with these standards?
CN:In some industry fields, functional safety standards are mandatory to be complied with – in others, product liability is a main driver. In general, the quality, reliability and of course the safety of those products are being improved, which helps avoiding recalls, sanctions, and worse – consumer injury.
JS: How long is the certificate valid for?
CS: Generally, a TÜV SÜD functional safety product certificate is valid for five years. During this timeframe, TÜV SÜD is however regularly monitoring the adherence to the requirements by accompanying the agile development remotely as mentioned before and by returning every two years for an on-site audit.
JS:Is TÜV SÜD involved in the development of the functional safety standards?
CN: Yes, TÜV SÜD is actively participating in the standardization committees. Please note that just recently the second edition of the automotive functional safety standard was released (ISO 26262:2018).
JS: How long does the tool certification process take, on average?
CN: Well, this depends on the maturity of the existing development processes, the complexity of the tool and the experience of the company with functional safety when we start with the assessment. I would say the initial certification can be achieved within six months, but it can also take much longer if many iteration loops are required.
To learn more about how Jama Connect can help your team simplify compliance, streamline development, and speed time to market, download our solution overview.
Medical device development is inherently complex, with numerous ever-evolving regulatory statutes to comply with and especially high stakes for ensuring the ultimate safety of the product. In fact:
Medical device recalls rose 50% in 2019, demonstrating the growing complexity of devices and their points of failure, as well as active regulatory enforcement.
Class I recalls, the most serious type, having a “reasonable probability” of the affected device causing harm, have surged at an even higher rate.
Devices like software-driven pacemakers illustrate the tradeoff between more complex hardware and more extensive risks requiring mitigation.
Indeed, the growing centrality of software to modern medical devices is a particularly notable challenge for manufacturers in this context.
Not only do software-driven devices require a particular and extensive approach to risk and requirements management, but they also create pressure to accelerate time to market due to an increasingly competitive market. New entrants into the medical device space have used software design to rapidly differentiate their products and compete with incumbents, as the FDA’s 2018 Class II de novo clearance for EKG-equipped Apple Watches shows.
Bringing medical devices to market quickly while preserving their quality and complying with regulations is a balancing act, albeit one that can be executed successfully with the right requirements management platform. Medical device compliance is achievable via a coherent, well-documented product lifecycle and real-time collaboration, both of which require efficient processes.
Based on our work with hundreds of medical device developers, we’ve compiled this guide to navigating the complexity of medical device compliance. Let’s dive into six tips for improving your development practices.
Tip 1: Use a Tool That’s Already Aligned with Industry Standards
ISO 14971:2019 and ISO 13485:2016 both include detailed guidance on how to manage medical risk and quality management processesas part of the product lifecycle process. However, it can be difficult to know how to even start adhering to them under an requirements management (RM) methodology rooted in Microsoft Word or Excel. Teams can struggle to capture and export all of the necessary data to prove end-to-end traceability and pass audits.
Instead of reinventing the wheel for standards adherence for each project, take advantage of the standard frameworks in a platform like Jama Connect™ for Medical Device Development. These save precious setup time and keep development aligned with key industry regulations such as ISO 14971:2019, 21 CFR 820.30, and ISO 13485:2019.
Tip 2: Migrate Away from Document-Based Workflows
Medical devices take an average of three to seven years to reach market. During that time, they will require many tests that must be traced back to requirements, plus the requirements themselves will frequently change in response to stakeholder feedback. Add in the risk inherent in complicated medical device creation, and it’s a recipe for trouble without a modern, structured platform in place.
To keep pace with the complexity of medical device development, document-based workflows must be left behind. Circulating lengthy, discrete documents via email doesn’t scale to modern projects, nor is it the most efficient means of gathering and synthesizing feedback from remote engineering teams. A dedicated RM platform that offers a single source of truth makes medical device compliance processes much more straightforward.
Traceability is central to medical device development, as it is the only systematic way to demonstrate that design inputs are being met and verified as part of the design control process. Inadequate traceability can lead to errors when done manually, also making it difficult to produce audit documentation, manage change, and prove medical device compliance.
Beginning in the 2010s, software became a leading cause of medical device recalls. Accordingly, in order to avoid medical device recalls or worse, traceability must be sufficiently advanced to:
Link high-level requirements to sub-system requirements across the development lifecycle
Provide traceabililty between all requirements and tests in one system, ensuring requirements are verified and validated
Produce necessary documentation for audits and regulatory standards
Eliminate the need to manually rebuild traceability
By having an automated way to show the impact of change on requirements rather than a spreadsheet, it significantly reduces the amount of manual effort needed to look at siloed data and where changes may be needed.
Tip 4: Create a Detailed Audit Trail
Another benefit of traceability is the ability to create a detailed audit trail demonstrating why something was built the way it was, at what time, and by whom. These audit trails are required for medical device development but can be nearly impossible to produce effectively if done so too late in the development process or with manual tools.
Real-time reporting and baselining are necessary for accuratelytracking changes to information within a system. Make sure your RM platform can provide this type of “living” documentation of the development process, with all changes accurately captured as they happen. Plus, look for export functionality for sending data easily to other systems of record like a quality management system (QMS) if necessary.
Tip 5: Prioritize Secure Management of ElectronicSignatures and Records
The FDA’s 21CFR Part 11 defines criteria for how electronic signatures and records can be used as equivalent to paper records. In order to meet this regulation’s very high bar for proof of electronic record and signature compliance, the proper access controls and security mechanisms need to be in place, such as:
Authentication of users via unique usernames and passwords
Limitations on who has the authority to create an electronic signature
Full details on when the signature was created, what it means, and who authorized it
Options for accurately and safely exporting the data in it for other systems or formats
In Jama Connect, we consider reviews the electronic record, which the FDA defines as “any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.” Reviews in Jama Connect adhere to the requirements for closed systems and include electronic signatures and the requirements for linking between signatures and records.
Tip 6: Perform Risk Analysis Early and Continuously
Waiting until the later stages of development to perform risk analyses will complicate medical device compliance and uncertainty in the product development process. More specifically, it will slow down the entire project due to the need to gather documentation from multiple sources, make any necessary late-stage changes (for example, in response to missing traceability between requirements and risks), and ensure test results reflect the latest updates to risks.
Jama Connect allows for risk analysis aligned to industry standards like ISO 14971:2019, treating risk management as an integral part of the product lifecycle process. Your organization can standardize and integrate your risk analysis, evaluation, and management processes in our platform to create a single source of truth for everything risk related.
To see more information specific to the medical device development industry, we’ve compiled a handy list of valuable resources for you!
![[GUIDE] ISO 13485 for Medical Device Development](https://www.jamasoftware.com/media/2021/02/2021-02-18-ISO-13485-ebook-1024x512-1.jpg "[GUIDE] ISO 13485 for Medical Device Development")
In this post, we pull out key takeaways from a recent whitepaper written in conjunction with Beanstock Ventures on the new EU medical device regulations (EU MDR) and how they might impact medical device development. 
Medical device development is inherently complex, with numerous ever-evolving regulatory statutes to comply with and especially high stakes for ensuring the ultimate safety of the product