Tag Archive for: Compliance & Regulation

Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from The New York Times, titled “Using A.I. to Detect Breast Cancer That Doctors Miss” – originally authored by Adam Satariano and Cade Metz, with photography by Akos Stiller for the New York Times, published on March 5, 2023.

Using A.I. to Detect Breast Cancer That Doctors Miss

Hungary has become a major testing ground for A.I. software to spot cancer, as doctors debate whether the technology will replace them in medical jobs.

A patient getting a mammogram at Bács-Kiskun County Hospital in Kecskemét, Hungary. The hospital has been testing A.I. software for breast cancer detection. Credit Akos Stiller for The New York Times

By Adam Satariano and Cade Metz
Photographs by Akos Stiller For The New York Times
Published March 5, 2023 – Updated March 6, 2023, 2:18 p.m. ET

Inside a dark room at Bács-Kiskun County Hospital outside Budapest, Dr. Éva Ambrózay, a radiologist with more than two decades of experience, peered at a computer monitor showing a patient’s mammogram.

Two radiologists had previously said the X-ray did not show any signs that the patient had breast cancer. But Dr. Ambrózay was looking closely at several areas of the scan circled in red, which artificial intelligence software had flagged as potentially cancerous.

“This is something,” she said. She soon ordered the woman to be called back for a biopsy, which is taking place within the next week.

Advancements in A.I. are beginning to deliver breakthroughs in breast cancer screening by detecting the signs that doctors miss. So far, the technology is showing an impressive ability to spot cancer at least as well as human radiologists, according to early results and radiologists, in what is one of the most tangible signs to date of how A.I. can improve public health.

Hungary, which has a robust breast cancer screening program, is one of the largest testing grounds for the technology on real patients. At five hospitals and clinics that perform more than 35,000 screenings a year, A.I. systems were rolled out starting in 2021 and now help to check for signs of cancer that a radiologist may have overlooked. Clinics and hospitals in the United States, Britain and the European Union are also beginning to test or provide data to help develop the systems.

A.I. usage is growing as the technology has become the center of a Silicon Valley boom, with the release of chatbots like ChatGPT showing how A.I. has a remarkable ability to communicate in humanlike prose — sometimes with worrying results. Built off a similar form used by chatbots that is modeled on the human brain, the breast cancer screening technology shows other ways that A.I. is seeping into everyday life.

Dr. Éva Ambrózay, a radiologist at Bács-Kiskun County Hospital with more than two decades of experience, has been using A.I. software to help look for signs of cancer that doctors may have missed.Credit…Akos Stiller for The New York Times

Widespread use of the cancer detection technology still faces many hurdles, doctors and A.I. developers said. Additional clinical trials are needed before the systems can be more widely adopted as an automated second or third reader of breast cancer screens, beyond the limited number of places now using the technology. The tool must also show it can produce accurate results on women of all ages, ethnicities and body types. And the technology must prove it can recognize more complex forms of breast cancer and cut down on false-positives that are not cancerous, radiologists said.

The A.I. tools have also prompted a debate about whether they will replace human radiologists, with makers of the technology facing regulatory scrutiny and resistance from some doctors and health institutions. For now, those fears appear overblown, with many experts saying the technology will be effective and trusted by patients only if it is used in partnership with trained doctors.

RELATED: 2023 Medical Device Product Development Predictions

And ultimately, A.I. could be lifesaving, said Dr. László Tabár, a leading mammography educator in Europe who said he was won over by the technology after reviewing its performance in breast cancer screening from several vendors.

“I’m dreaming about the day when women are going to a breast cancer center and they are asking, ‘Do you have A.I. or not?’” he said.

Possible anomalies in a breast cancer screen are highlighted by the A.I. software.Credit…Akos Stiller for The New York Times

Hundreds of images a day

In 2016, Geoff Hinton, one of the world’s leading A.I. researchers, argued the technology would eclipse the skills of a radiologist within five years.

“I think that if you work as a radiologist, you are like Wile E. Coyote in the cartoon,” he told The New Yorker in 2017. “You’re already over the edge of the cliff, but you haven’t yet looked down. There’s no ground underneath.”

Mr. Hinton and two of his students at the University of Toronto built an image recognition system that could accurately identify common objects like flowers, dogs and cars. The technology at the heart of their system — called a neural network — is modeled on how the human brain processes information from different sources. It is what is used to identify people and animals in images posted to apps like Google Photos, and allows Siri and Alexa to recognize the words people speak. Neural networks also drove the new wave of chatbots like ChatGPT.

Many A.I. evangelists believed such technology could easily be applied to detect illness and disease, like breast cancer in a mammogram. In 2020, there were 2.3 million breast cancer diagnoses and 685,000 deaths from the disease, according to the World Health Organization.

But not everyone felt replacing radiologists would be as easy as Mr. Hinton predicted. Peter Kecskemethy, a computer scientist who co-founded Kheiron Medical Technologies, a software company that develops A.I. tools to assist radiologists detect early signs of cancer, knew the reality would be more complicated.

Peter Kecskemethy, a founder of Kheiron Medical Technologies, and his mother, Dr. Edith Karpati, who was a radiologist, with an X-ray data that was fed into A.I. models.Credit…Akos Stiller for The New York Times

Mr. Kecskemethy grew up in Hungary spending time at one of Budapest’s largest hospitals. His mother was a radiologist, which gave him a firsthand look at the difficulties of finding a small malignancy within an image. Radiologists often spend hours every day in a dark room looking at hundreds of images and making life-altering decisions for patients.

“It’s so easy to miss tiny lesions,” said Dr. Edith Karpati, Mr. Kecskemethy’s mother, who is now a medical product director at Kheiron. “It’s not possible to stay focused.”

Mr. Kecskemethy, along with Kheiron’s co-founder, Tobias Rijken, an expert in machine learning, said A.I. should assist doctors. To train their A.I. systems, they collected more than five million historical mammograms of patients whose diagnoses were already known, provided by clinics in Hungary and Argentina, as well as academic institutions, such as Emory University. The company, which is in London, also pays 12 radiologists to label images using special software that teaches the A.I. to spot a cancerous growth by its shape, density, location and other factors.

From the millions of cases the system is fed, the technology creates a mathematical representation of normal mammograms and those with cancers. With the ability to look at each image in a more granular way than the human eye, it then compares that baseline to find abnormalities in each mammogram.

Last year, after a test on more than 275,000 breast cancer cases, Kheiron reported that its A.I. software matched the performance of human radiologists when acting as the second reader of mammography scans. It also cut down on radiologists’ workloads by at least 30 percent because it reduced the number of X-rays they needed to read. In other results from a Hungarian clinic last year, the technology increased the cancer detection rate by 13 percent because more malignancies were identified.

Mr. Kecskemethy, left, with Kheiron’s co-founder, Tobias Rijken, said that A.I. should assist doctors.Credit…Akos Stiller for The New York Times

Dr. Tabár, whose techniques for reading a mammogram are commonly used by radiologists, tried the software in 2021 by retrieving several of the most challenging cases of his career in which radiologists missed the signs of a developing cancer. In every instance, the A.I. spotted it.

“I was shockingly surprised at how good it was,” Dr. Tabár said. He said that he did not have any financial connections to Kheiron when he first tested the technology and has since received an advisory fee for feedback to improve the systems. Systems he tested from other A.I. companies, including Lunit Insight from South Korea and Vara from Germany, have also delivered encouraging detection results, he said.

Proof in Hungary

Kheiron’s technology was first used on patients in 2021 in a small clinic in Budapest called MaMMa Klinika. After a mammogram is completed, two radiologists review it for signs of cancer. Then the A.I. either agrees with the doctors or flags areas to check again.

RELATED: Jama Connect® Validated Cloud Package for Medical Device and Life Sciences

Across five MaMMa Klinika sites in Hungary, 22 cases have been documented since 2021 in which the A.I. identified a cancer missed by radiologists, with about 40 more under review.

“It’s a huge breakthrough,” said Dr. András Vadászy, the director of MaMMa Klinika, who was introduced to Kheiron through Dr. Karpati, Mr. Kecskemethy’s mother. “If this process will save one or two lives, it will be worth it.”

What the A.I. software can do is “a huge breakthrough,” said Dr. András Vadászy, the director of MaMMa Klinika.Credit…Akos Stiller for The New York Times

Kheiron said the technology worked best alongside doctors, not in lieu of them. Scotland’s National Health Service will use it as an additional reader of mammography scans at six sites, and it will be in about 30 breast cancer screening sites operated by England’s National Health Service by the end of the year. Oulu University Hospital in Finland plans to use the technology as well, and a bus will travel around Oman this year to perform breast cancer screenings using A.I.

“An A.I.-plus-doctor should replace doctor alone, but an A.I. should not replace the doctor,” Mr. Kecskemethy said.

The National Cancer Institute has estimated that about 20 percent of breast cancers are missed during screening mammograms.

Dr. Constance Lehman, a professor of radiology at Harvard Medical School and a breast imaging specialist at Massachusetts General Hospital, urged doctors to keep an open mind.

“We are not irrelevant,” she said, “but there are tasks that are better done with computers.”

At Bács-Kiskun County Hospital outside Budapest, Dr. Ambrózay said she had initially been skeptical of the technology — but was quickly won over. She pulled up the X-ray of a 58-year-old woman with a tiny tumor spotted by the A.I. that Dr. Ambrózay had a hard time seeing.

The A.I. saw something, she said, “that seemed to appear out of nowhere.”

A correction was made on March 5, 2023: An earlier version of this article misspelled the surname of the director of MaMMa Klinika. He is Dr. András Vadászy, not Vadász. The earlier version also referred incorrectly to the relationship of Dr. László Tabár with Kheiron Medical Technologies. While he did not have any financial connections to Kheiron when he first tested its breast cancer screening technology, he has since received an advisory fee to provide feedback about how it can be improved.

A correction was made on March 6, 2023: An earlier version of this article misidentified Dr. Constance Lehman. She is a breast imaging specialist at Massachusetts General Hospital, not chief of breast imaging and radiology.

Adam Satariano is a technology correspondent based in Europe, where his work focuses on digital policy and the intersection of technology and world affairs. @satariano

Cade Metz is a technology reporter and the author of “Genius Makers: The Mavericks Who Brought A.I. to Google, Facebook, and The World.” He covers artificial intelligence, driverless cars, robotics, virtual reality and other emerging areas. @cademetz


Aerospace & Defense

In this blog, we recap the “Launch Your Aerospace & Defense Product Development Processes with Jama Connect®” webinar.

In this webinar, we discuss exciting new features in our updated Jama Connect® for Aerospace & Defense framework. These updates include refreshed solutions for cybersecurity, the DoD Range Safety Requirements Library, and other libraries of standards.

Also, Cary Bryczek, Solutions Director for Aerospace & Defense at Jama Software®, shares best practices in the Jama Connect platform and demonstrates significant new features that can help you further enhance your aerospace and defense product development processes, including:

  • ARP 4761A – Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment
  • DO-326A – Airworthiness Security Process Specification
  • US CFR Parts 21-57 Pre-imported Libraries and Usage
  • Defense MBSE and Digital Engineering Guidance
  • NASA and Air Force Range Safety Requirements
  • European Cooperate with Space Standards (ECSS) Pre-Imported Libraries

Below is an abbreviated transcript and a recording of our webinar.

Launch Your Aerospace & Defense Product Development Processes with Jama Connect®

Cary Bryczek: Let’s get started. So the Airborne Systems Solution. So when we say solution, it’s really a complete set of frameworks, example projects and the procedural documentation that goes along with that. It’s really intended to accelerate your implementation of Jama Connect, especially those that are developing Airborne Systems and the Airborne Systems components that are going to live on these aircraft. When you utilize these frameworks, you can either have zero set up time, so we’re developed the solution to align with the standards and you can also tailor it. So your consultant who does team with you could help you tailor it to meet your very specific business needs as well. So it’s really designed for any organization, whether you’re a startup in the Airborne Systems world or whether you’re a longtime developer of aircraft.

The Airborne Systems Solution is really designed to help you ease the path to regulatory compliance, to help the engineers produce the evidence and collect that evidence in coordination with the regulatory requirements and the industry standards that are used that are requiring the acceptable means of compliance. Today’s. In today’s world, there is a lot of new engineers that are being employed in Airborne Systems development. And really this particular template is helpful to them because it really gets them to understand “How am supposed to do development?” We all know that Airborne Systems development has the most onerous and rigorous standards of any industry. And teaching our new engineers is very time-consuming. So having this template with all of the guidance built into it and the procedure guide really helps our new engineers to get started.

So there’s three components to the Airborne Systems Solution that what we call the data set, a procedure guide, and the success program. The data set essentially is what you get when you install Jama and it has the templates, it has a ready to use configuration that matches those regulations. It has all of the item types, all of the reports, all of the best practices built right in. And then the procedure guides and the documentation of the reports essentially show you how the Airborne Systems template is meeting the industry standards. So how does it meet ARP4754, how do you use the solution to meet DO-178. That’s sort of a thing.

RELATED: Jama Software® Delivers Major Enhancements to the Jama Connect® for Airborne Systems Solution

Bryczek: And then we also pair our solution with specific consulting. So our consultants already are very familiar with the regulations with working with our customers that have been delivering and developing Airborne Systems already, as well as systems engineering best practices. Some of our customers have interesting supply chain needs. And so they might want to use an additional tool that we package called data exchange. That’s just an add-on to the solution.

So when we look at the framework itself, there are a lot of industry standards that we support. These industry standards are the acceptable means of compliance that the FAA and EASA recognize in order to meet type certifications. So we have those processes that come right out of those standards built right in to the framework. So that framework consists of specially configured item types, pick lists and views of that information. Our relationship rules are aligned to the types of trace matrices these particular standards are calling for. We have workflows and guidance for how you conduct reviews of information as well. We have the libraries of standards, so if you need to comply with the different CFR parts, we actually have those pre imported. This is something new that we’ve added and we’ll talk about that a little bit more. The framework includes these document export templates as well as risk templates and analysis templates and more.

Now this is a company with a procedure guide. So along with not only just the template itself in Jama, we give you the procedure guide. You can take this guide and tailor it to meet your specific needs as well. This procedures guide is updated. So as a subscriber to the Airborne Systems Solution, any updates we make or new releases like what we have right now is included with your subscription. It just makes it easy for everyone to kind of understand “How do I use Jama if I need to meet these industry standards?”

RELATED: Digital Engineering Between Government and Contractors

Bryczek: Also with this particular release is the configuration and update guide. So this is new this time around. This particular guide gives a very detailed description of the entire dataset. It includes all of the types that we’ve defined, all of the pick lists that are defined, all of the relationship rules, all of the workflows. So if you need to update from your existing Airborne Systems Solution and take in aspects of the new release, it makes it really easy for you guys to update as well. This might be something as well… So if you tailor from your existing Jama solution and you want to keep track of that, something like this might be a really great way for you to document your own implementation of Jama itself.

So exciting. This is one of the new things. So we have for cybersecurity, DO-326A is an acceptable means of compliance for doing security analyses. There are a significant number of new item types that have been added to the solution that comprise our cybersecurity solution as well as how do you really do the airworthiness security analysis. Essentially there are seven steps to do this particular type of analysis. This really starts with developing your PSecAC. And for those of you who are maybe new to Airborne Systems development or are not familiar with DO-326 or cybersecurity, it is a process that’s sort of done in tandem with both the system development and safety. But this is different in that this is analyzing the intentional unauthorized electronic interaction. So it’s really designed to find ways that hackers or bad actors might be accessing parts of the Airborne Systems that you don’t want them to.

To watch the entire webinar, visit
Launch Your Aerospace & Defense Product Development Processes with Jama Connect®


Software Validation, Medical Device

Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I

Intro

This is Part 1 of a 2-part series on software validation and computer software assurance in the medical device industry.

While it is clear that software validation is required by regulation in the US and elsewhere (e.g., the EU (European Union)), as regulated by the MDR and IVDR), how to execute continues to cause challenges, both for established medical device companies, and those just entering the medical device industry.

Between the different types of software, variations in terminology, type, and source of software (developed in-house, or purchased OTS, customized OTS (COTS), SOUP, etc.) advances in software technology, and evolving guidance of the FDA (Food and Drug Administration) and other regulatory bodies, it’s no wonder that implementation of software validation practices and procedures causes confusion.

This blog outlines the top things to know about software validation and computer software assurance as you implement practices and procedures for your organization in a way that is compliant and brings value.

Are you building or updating your software validation practices and procedures? If so, read on!

Top Things to Know About Software Validation and Computer Software Assurance

#1. Yes, there are different terms, methods, and definitions for software validation.

For the purposes of this blog, we’ll use the FDA’s definition of software validation, from their 2002 guidance. The FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”

At a high level, this makes sense. The confusion starts when folks try to define how that confirmation is performed and documented. How do I determine and document the requirements? How detailed do I need to go to my user needs and intended uses? For each feature? What kind of objective evidence? What if I’m using software to automate test scripts? Do I have to qualify the testing software? Turning to guidance and standards for a “standard” set of practices can add to the confusion. Even within just the medical device industry, there are multiple regulations and standards that use similar and at the same time, slightly different concepts and terminology. Examples include the IQ/OQ/PQ (Installation Qualification / Operational Qualification / Performance Qualification) analogy from process validation, black box testing, unit testing, just to name a few.

Before getting overwhelmed, take a breath and read on to point #2.

RELATED: How to Use Requirements Management as an Anchor to Establish Live Traceability in Systems Engineering

#2. Start with the regulations and standards.

While the multiple regulations and standards around software validation cause confusion, they are also a good place to start. I say that because at a high level they are trying to achieve the same thing- software that meets its intended use and maintains a validated state. Keeping the intent in mind can make it easier (at least it does for me) to see the similarities in the lower-level requirements between any terminology differences and not be as focused on making all the terminology match.

To start, select those regulations and guidance from one of your primary regulatory jurisdictions (like the FDA for the US). In the US, three main FDA guidance documents to incorporate are 1) General Principles of Software Validation; Final Guidance for Industry and FDA Staff, issued in 2002; 2) Part 11, Electronic Records; Electronic Signatures – Scope and Application, issued in 2003.

The 3rd guidance is relatively new, a draft guidance released in September, 2022, Computer Software Assurance for Production and Quality System Software. While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). It is also in this guidance that the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”

Once you’ve grounded yourself in one set, then you can compare and add on, as necessary, requirements for other regulatory jurisdictions. Again, focus on specific requirements that are different and where the high-level intent is similar. For example, in the EU, Regulation (EU) 2021/2226 outlines when instructions for use (IFUs) may be presented in electronic format and the requirements for the website and eIFUs presented.

#3. Start on the intended use and make your software validation and computer software assurance activities risk based.

Start with documenting the intended use of the software and associated safety risk if it were to fail. Then define the level of effort and combination of various software validation activities commensurate with the risk. Software and software features that would result in severe safety risk if it fails are to be validated more rigorously and have more software assurance activities than software that poses no safety risk.

Here are some examples of intended use and the associated safety risk.

Example 1: Jama Connect®, Requirements Management Software

Intended Use: The intended use of Jama Connect is to manage requirements and the corresponding traceability. The following design control aspects are managed within Jama Connect, user needs, design inputs, and traceability to design outputs, verification and validation activities. Risk analysis is also managed in Jama Connect.

Feature 1 Intended Use: Jama Connect provides visual indicators to highlight breaks in traceability. For example, when a user need is not linked to a design input, or vice versa.

Risk-based analysis of Feature 1: Failure of the visual indicator would result in the possibility of not establishing full traceability or missing establishment of a design control element like a design input. This risk is considered moderate as manual review of the traceability matrix is also performed as required by the Design Control SOP. Reports are exported from Jama Connect as pdfs, reviewed externally to the software, and then approved per the document control SOP.

RELATED: Traceability Score™ – An Empirical Way to Reduce the Risk of Late Requirements

Example 2: Imbedded software in automated production equipment

Intended use: The intended use of the software is to control production equipment designed to pick in place two components and weld them together.

Risk-based analysis: This is a critical weld that affects patient safety if not performed to specification. Thus, the software is considered high risk.

#4. Software Validation and computer software assurance is just one part of the software life cycle… you need to be concerned about the whole lifecycle.

There is more to software development and management than just the validation. Incorporate how custom software will be developed, how purchased software will be assessed to determine the appropriate controls based on risk, including verification and validation activities, and revision controlled.

#5. Have different procedures and practices for the different types of software.

This is a good time to consider how different types of software in your organization will be managed, and it’s not a one-size fits all approach. A best practice is to have separate practices and procedures; one for software in a medical device (SiMD) and software as a medical device (SaMD) and at least one other procedure and set of practices for other software, like software used in the production of a device, software in computers and automated data processing systems used as part of medical device production, or software used in implementation of the device manufacturer’s quality system.

Closing

Stay tuned for Part 2 of this 2-part blog series, where we’ll dive deeper into computer software assurance, highlight the risk-based approach, and provide tips and tools to manage your software in a compliant and efficient manner.


Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from EURACTIVE, titled “The AI Act’s Fine Line On Critical Infrastructure” – originally authored by Luca Bertuzzi on February 8, 2023.

The AI Act’s Fine Line On Critical Infrastructure

As EU policymakers make progress in defining an upcoming rulebook for Artificial Intelligence, the question of to what extent AI models employed to manage critical infrastructure should be covered by tight requirements still remains open.

The AI Act is reaching a critical stage in the legislative process, with the European Parliament set to reach a common position in the coming weeks. The legislative proposal is the world’s first attempt to put in place a comprehensive set of rules for Artificial Intelligence based on its potential risks.

A critical aspect of the draft law is the category of AI models that can cause significant harm, which must comply with stricter obligations regarding quality and risk management. However, concerning critical infrastructure, how to assess risk remains a matter of debate.

AI in critical infrastructure

Artificial Intelligence is increasingly employed in managing critical infrastructure, notably for project development, maintenance and performance optimization.

An example on the construction side is Sweco Netherlands, an engineering consultancy company tasked to extend the light-rail system of Bybanen, Norway’s second-largest city, considering the existing tram lines, adjacent roads, cycle lanes, pedestrian zones and surrounding public areas.

To put together these different factors, Sweco NL used a digital twin model to visualise its project and understand how design changes would impact the timeline, costs and surroundings. The company estimates it reduced construction errors by 25% as a result.

Another area of application for this technology is dams. In 2017 HDR, a US construction company, applied machine learning to a dam’s digital twin model to simulate how the infrastructure would be affected by changes like natural shifting and erosion of the surrounding soil over time.

The model allowed dam operators to detect anomalies like cracks with an accuracy of two centimeters, differentiating them from harmless algae growth, and taking corrective measures before they grew into more significant problems.

RELATED: 2023 Predictions for Industrial and Consumer Electronics Product Development

Regulatory approach

The original AI Act proposal noted that “it is appropriate to classify as high-risk the AI systems intended to be used as safety components in the management and operation of road traffic and the supply of water, gas, heating and electricity.”

In the EU Council of Ministers, member states clarified that the concept of the safety component should be distinguished by the management system itself. In other words, in a dam, the mechanism to open the volts is the management system, whilst the technology that monitors the water pressure is a safety component.

In the European Parliament, the MEPs spearheading the work on the AI Act proposed to differentiate the management of traffic on roads, rail and air, from supply networks like water, gas, heating, energy and electricity, in compromise amendments obtained by EURACTIV.

While the Council included digital infrastructure like cloud services and data centres in the list of high-risk use cases, since the intent is to prevent “appreciable disruptions in the ordinary conduct of social and economic activities”, EU lawmakers have so far not done so.

The addition to the high-risk list caused significant anxiety in the telecom industry, which uses AI to manage network capacity, plan upgrades, detect frauds and improve energy efficiency. The question is whether the malfunction of any of these algorithms might bring the whole system down.

RELATED: [Webinar Recap] Managing Functional Safety in Development Efforts for Robotics Development

Where to draw a line

For example, if a telecom operator miscalculates traffic peaks in different areas of its network, would that lead to internet outages? A representative of telecom operators told EURACTIV they are not aware of any situation where that occurred, branding the issue as ‘highly hypothetical’.

More generally, critical infrastructure operators are concerned that, by casting the high-risk category of the AI regulation too wide, they might be precluded from useful tools that contribute to making their systems more efficient and secure.

A case in point is that member states excluded AI-powered cybersecurity tools from the definition of safety component.

Anti-virus malware analysis is based on predictive models and machine learning, meaning critical infrastructure service providers would have been precluded from using virtually all commercially available anti-viruses.

At the same time, AI-powered management systems are not without risks. Kris Shrishak, a technologist at the Irish Council for Civil Liberties, made the case of India in 2012 when a miscalculation of the electric grid’s peak traffic led to perhaps the largest blackout in history.

Therefore, the argument for a more granular approach in the high-risk categorisation relates to when the AI solutions make the infrastructure safer and if their failure does not entail an imminent threat.

Physical maintenance, for instance, is often costly and time-consuming, which might lead to infrastructures falling into disrepair. Not employing AI’s capacity to identify patterns and spot anomalies before they develop into bigger problems can also come at a cost.

Last year, amid the Russian-prompted energy crisis, France, usually Europe’s largest energy exporter, became a net importer as a record number of its nuclear reactors were put out of service due to maintenance stoppages.

[Edited by Nathalie Weatherald]


Robotics Industry
Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from Data Science Central, titled “Revolutionizing the Supply Chain: Developments in the Warehouse Robotics Industry” – originally authored by Nikita Godse on January 24, 2023.

Revolutionizing the Supply Chain: Developments in the Warehouse Robotics Industry

Robotics Industry

Warehouse robotics is witnessing steady growth, driven by the increasing adoption of automated solutions in storage for food and beverages, consumer goods, retail, and third-party logistics. The collaboration between the e-commerce sector and warehouse robotics is also a major driver of this market, as it allows for developing increasingly sophisticated warehouse automation systems. Additionally, the advent of autonomous mobile robots (AMRs) and the rising popularity of automated guided vehicles (AGVs) are also fueling the growth of this market.

Reforming Warehouse Operations: Increasing Adoption of AMRs and AGVs

One of the most notable trends in the warehouse robotics market is the increasing adoption of AMRs and AGVs. These robots are allowing for the development of more efficient and cost-effective warehouse operations, as they can automate tasks such as picking, packing, and transporting goods. Additionally, the use of AMRs and AGVs is also allowing for the development of more flexible and scalable warehouse operations, which can better meet the changing needs of businesses.

Efficient and Cost-effective: Rising Collaboration between eCommerce Sector and Warehouse Robotics

Another major trend in the warehouse robotics market is the increasing collaboration between the e-commerce sector and warehouse robotics. This is being driven by the growing demand for efficient and cost-effective warehouse operations, as e-commerce businesses look to keep pace with the rapid growth in online sales. Additionally, the use of warehouse robotics is also allowing e-commerce businesses to better meet the changing needs of their customers by providing faster and more accurate delivery of goods.

 

RELATED: Managing Functional Safety Development Efforts for Robotics Development

Advanced Automation: Increasing Preference for Advanced Robots in Warehouses

As the warehouse robotics market continues to evolve, it is clear that there will be a growing demand for advanced robots in warehouses. This is being driven by the surge in the adoption of robots during the COVID-19 outbreak, as businesses look to automate their operations and reduce their dependence on human labor. Additionally, the increasing adoption of industrial automation and control solutions is also contributing to the growth of this market.

Global Perspective: North America to Lead, Europe to hold Second Largest Share

The warehouse robotics market is a global industry, and it is clear that different regions are at different stages of development. Currently, North America is the largest market for warehouse robotics, driven by the rapid adoption of warehouse automation and the presence of major players in the market such as the United States. However, Europe is expected to hold the second-largest market share, driven by the rising adoption of industrial automation and control solutions in the region.

 

RELATED: 2023 Predictions for Industrial and Consumer Electronics Product Development

Innovations in Warehouse Automation: A Look at Leading Players’ Latest Developments

The warehouse robotics market is a highly competitive industry with several leading players. Some of the major players in the market include KUKA AG, FANUC Corporation, ABB, and Yaskawa Electric Corporation. These companies have made significant investments in the development of warehouse automation solutions and have a strong presence in the market.

Additionally, there are also several startups and smaller companies that are emerging in the market, such as Locus Robotics and GreyOrange, which are focusing on specific areas of warehouse automation. The competitive landscape is expected to become more intense with the entry of new players and increasing investments in the development of warehouse automation solutions.

In the warehouse robotics market, major players such as Kuka AG, FANUC Corporation, and ABB Limited have been focusing on developing advanced robots for warehouse automation. Recently, Kuka AG announced the launch of its new autonomous mobile robot, LBR iiwa, which is designed for use in the logistics and manufacturing sectors. Similarly, FANUC Corporation has introduced its new autonomous mobile robot, CRX-10iA, which is designed for use in the logistics and distribution sectors.

ABB Limited has also recently launched its new autonomous mobile robot, YuMi, which is designed for use in small parts assembly and other applications in the manufacturing sector. These advancements by leading players demonstrate the increasing focus on developing advanced warehouse automation solutions in the market.


RUO

In this blog, we recap our eBook, “An Introduction to Research Use Only (RUO)” – Click HERE to download the entire publication.

An Introduction to Research Use Only (RUO)

Learn how it differs from adjacent labels, the FDA and EU guidance, its appropriate use, and the consequences of mislabeling products RUO.

Introduction

In the complex world of medical device development, regulation, and distribution, finding the appropriate label to put on a device may not be simple. When is one label appropriate over another?
Does a device need to go through additional testing, verification, or validation? And what are the consequences of using the wrong label? In this eBook, we’ll cover the differences between Research
Use Only (RUO) and a medical device – although, it’s generally a very clear distinction.

Using the right language and label is critical to complying with best practices. This is why Regulatory Affairs works with the regulatory bodies to ensure that the limitations of the product are properly documented. In a rush to get products to market, it may be tempting to use a Research Use Only (RUO) label to avoid additional regulatory processes while still empowering other researchers and developers. However, there are risks to using the RUO label inappropriately that can have serious consequences for developers, users, and patients. In fact, mislabeling a product is illegal, and punishable. You can see an example warning letter the FDA sent to Carolina Liquid Chemistries Corp after finding intentional mislabeling in 2019 here.

This introduction will provide an overview of the Research Use Only label, how it differs from similar, adjacent labels, its appropriate use, and the consequences of mislabeling products RUO.

What is Research Use Only (RUO)?

The label Research Use Only (RUO) is generally used to indicate products that are intended for scientific research only. They cannot be used for diagnostic or medical purposes. However, there is no standard definition of “research use only,” and the label has slightly different meanings in the European Union and the United States. With the IVDR regulations, RUO products that are being used in
the LDT space are going to be revisited and potentially reclassified as a medical device. With this new classification, teams will likely need to follow design controls, best practices, and industry standards.

What is the FDA guidance on Research Use Only products?

Under the FDA’s guidance issued in 2013, a product labeled Research Use Only is an In Vitro Diagnostic (IVD) product “that is in the laboratory research phase of development and is being shipped
or delivered for an investigation that is not subject to part 812.” The agency includes in this category:

  • “Tests that are in development to identify test kit methodology, necessary components, and analytes to be measured.
  • “Instrumentation, software, or other electrical/mechanical components under development to determine correct settings, subcomponents, subassemblies, basic operational characteristics, and possible use methods.
  • “Reagents under development to determine production methods, purification levels, packaging needs, shelf life, storage conditions, etc.”

The European guidance document MEDDEV 2.14/2 states that a product categorized as an RUO product “must have no intended medical purpose or objective.” The guidance does exempt some tests developed for in-house use as long as the products are not sold to other companies. Some examples of items that can be classified as “research use only” under this exemption include PCR enzymes, gel
component agars, and primers.

RELATED: FDA released new draft guidance of premarket submissions for medical devices – are you ready?

What is the difference between RUO and IVD?

An IVD is an “In Vitro Diagnostic Medical Device,” and the general term applies to any device or product that either alone or with other products is intended to be used for diagnostic, monitoring, or compatibility purposes. There are four different regulatory levels for IVDs:

  • Research Use Only (RUO)
  • General Laboratory Use (GLU)
  • For Performance Studies Only (PSO)
  • In Vitro Diagnostic Medical Device (IVD)

Chart

The simplest explanation for these different levels is that each increasing level requires more testing and oversight. Research Use Only products are at the lowest level of regulation, and In Vitro Diagnostic Medical Devices are at the highest level. Occasionally in the US, products will be labeled as “RUO IVD,” which means an in vitro device that is intended for research use only.

Products labeled with the “CE-IVD” label indicate that they have progressed through the applicable regulatory process and standards (such as IVDD or IVDR). These products are approved for diagnostic use and must include the IVD symbol to be used for medical purposes.

In the EU, as of May 2022, IVDs must comply with Regulation (EU) 2017/746 (IVDR). The IVDR defines IVDs as follows:

“‘in vitro diagnostic medical device’ means any medical device which is a reagent, reagent product, calibrator,
control material, kit, instrument, apparatus, piece of equipment, software or system, whether used alone or in
combination, intended by the manufacturer to be used in vitro for the examination of specimens, including blood
and tissue donations, derived from the human body, solely or principally for the purpose of providing information
on one or more of the following:

(a) concerning a physiological or pathological process or state;
(b) concerning congenital physical or mental impairments;
(c) concerning the predisposition to a medical condition or a disease;
(d) to determine the safety and compatibility with potential recipients;
(e) to predict treatment response or reactions;
(f) to define or monitoring therapeutic measures.”

All IVDs that comply with the IVDR must carry the CE Mark if marketed in the EU.

Research Use Only products are not subject to regulatory requirements in either the US or the EU, but because they don’t meet the same compliance standards as IVDs, they must be clearly labeled as RUO products and cannot be used for medical purposes.

A known exception is the lab developed test (LDT) pathway for clinical purposes.

What are the requirements for an RUO product?

In the US, RUO products are basically unregulated and do not need to meet any specific requirements to carry the RUO label. The FDA does not specify any restrictions or limitations on RUO products, provided they are clearly labeled “For Research Use Only. Not for use in diagnostic procedures.” For this reason, RUO products can be an excellent solution for laboratories that need research materials for testing and research purposes. Because products with the RUO label do not require extensive testing, verification, and validation, they tend to be more cost-effective for research purposes.

The EU rules are similar. Because RUO products do not have clinical applications, they are not considered medical devices, and there are no requirements for RUO products defined by either the IVDD or the IVDR. These products should not be marked with the IVD mark, and they should be clearly labeled as “Research Use Only.”

RELATED: See how Jama Software® helped Össur improve the mobility of millions by replacing process rigidity with speed and agility.

Are there alternatives to RUO labels?

Given the significant differences between labeling a product as RUO and labeling a product as IVD, manufacturers and users can’t be too careful when it comes to assigning labels or using products for
specific purposes. If there is a risk to using products labeled as RUO, manufacturers and users should opt for products that have attained a higher compliance level. For example, for a doctor’s office or home use, IVD is the right path. For clinical purposes or hospital labs, RUO could be used as LDT as long as they are CAP/CLIA certified, such was the case with COVID-19 testing kits when the pandemic first hit.

For products that meet a higher degree of compliance, it is possible to assign General Laboratory Use (GLU), Performance Studies Only (PSO), or even In Vitro Diagnostic Medical Device (IVD) labels. However, depending on the intended use for the Research Use Only products, pursuing these additional levels of compliance may or may not make sense.

What is CLIA certification?

CLIA stands for Clinical Laboratory Improvement Amendments. The Centers for Medicare & Medicaid Services (CMS) regulates all clinical laboratory testing performed on humans in the United States
through CLIA.

What is a CAP accreditation?

CAP stands for The College of American Pathologists (CAP). The purpose of CAP laboratory accreditation is to ensure laboratories provide precise test results for accurate patient diagnoses, meet CLIA and CAP requirements, and demonstrate compliance with professionally and scientifically sound and approved laboratory operating standards.

What are RUO products used for?

As the name implies, RUO projects should be used for research purposes only. They may be used for basic research, pharmaceutical research, or in-house manufacturing of “home brew kits” for research purposes and potentially for clinical applications via the LDT pathway. RUO products are specifically not to be used to make diagnoses, conduct performance studies, or as a substitute or comparator for a CE-IVD device. They may also not be used for market or feasibility studies. Raw ingredients labeled as RUO products may not be incorporated into a finished IVD product.

Learn more about the advantages and disadvantages of the RUO label (and more) by downloading the entire eBook HERE.


Risk Management

In this blog, we’ll recap our whitepaper, “Understanding Integrated Risk Management for Medical Devices” – To read the entire paper, click HERE.

Understanding Integrated Risk Management for Medical Devices

Knowledge on best practices, how to integrate risk-based thinking into product development cycles, and the importance of having end-to-end traceability to improve risk management, shared by industry and solution experts.

A level of risk exists with all medical devices, no matter how simple they are.Companies developing medical devices are constantly considering who (or what environment, facility, etc.) could potentially be hurt by a device so they can help reduce risk and meet regulatory requirements. Risk management in the context of ISO 14971 is designed to support medical device manufacturers with these tasks — but not all approaches are equal.

The amount of time it takes to manage risks, connect specific risks to specific requirement tasks, and pull together required documents to respond to an audit varies slightly depending on the approach. The risk management process is an integrated process that not only includes teams in product development, quality, but also many other parts of an organization.

This whitepaper taps into the knowledge of industry and solution experts to uncover best practices, how to integrate risk-based thinking into product development cycles, and the importance of having end-to end traceability to improve risk management. Before we dig into integrated risk management, let’s first define some key terms.

RELATED: Jama Connect® Features in Five: Risk Management for Medical Device

Risk Management Terms According to ISO 14971

Harm – Harm occurs when people are injured physically or their health is compromised or when property or the environment is damaged.

Hazard – A hazard is a potential source of harm. Annex E.2 categorizes hazards in the following way: energy hazards, chemical hazards, biological hazards, operationalhazards, and informational hazards.

Hazardous – A hazardous situation occurs when people are exposed to a hazard or when property or the environment is threatened. A hazardous situation exists when a vulnerable entity is exposed to a hazard.

Situation – According to ISO 14971, the concept of risk combines two variables: the probability of harm and the severity of harm.

Risk – For example, if a particular hazardous situation is very likely to cause harm and would be very harmful if it actually occurred, then it would be a high risk situation. Conversely, if it’s very unlikely to cause harm and would be only slightly harmful if it actually occurred, then it would be a trivial risk.

Risk Analysis – Risk analysis is a systematic process that is used to identify hazards and to estimate risk. It includes an examination of every reasonably foreseeable sequence or combination of events that could produce a hazardous situation and cause harm.

Risk Assessment – Risk assessment is a process that is, in turn, made up of two interconnected processes: risk analysis and risk evaluation.

Risk Evaluation – Risk evaluation is a process that is used to examine the estimated risk for each hazardous situation and then to use risk acceptability criteria to determine whether
or not the estimated risk is acceptable and to decide if risk reduction is required.

Risk Control – Risk control is a process that is used to consider risk control options and to select and implement risk control measures that will reduce risk or maintain risk within
specified levels. ISO 14971 expects you to consider the following risk control options and, if possible, to apply them in the following order:

  1. Design safety into the product.
  2. Establish protective measures.
  3. Provide safety information.

Risk Estimation – Risk estimation is a process that is used to assign qualitative or quantitative probability values and severity values to each hazardous situation. These values are then used to estimate risk.

Risk Management – Risk management uses policies, procedures, and practices to systematically analyze, evaluate, control, and monitor risk.

Safety – Safety is freedom from unacceptable risk. Risk acceptability criteria are used to help decide whether or not a risk is unacceptable.

Severity – Severity is a measure of the possible harmful consequences that a hazard could potentially cause.

RELATED: Download our whitepaper, Application of Risk Analysis
Techniques in Jama Connect® to Satisfy ISO 14971

The Risk Management Process

During risk management — after one defines a device’s intended use(s) — risk analysis can begin with identifying all potential hazards, and hazardous situations. Once this is defined, risk can be estimated and can determine the type of appropriate risk control required. Once the risk controls are implemented, residual risk needs to be analyzed to ensure that the benefits outweigh the risks. Let’s take a look at what’s involved in the risk management process.

Identifying Hazards

“Risk” is defined as the severity and probability that harm will occur. Defining the severity of harm requires you to identify all the known and foreseeable hazards for both intended and unintended uses.

For example, let’s say you have an infusion pump, and that pump has air in the line, which creates a hazardous situation for the patient. Different levels of patient harm can occur, so it’s about uncovering the possible scenarios and the likelihood of a situation’s occurring.

Risk Harm

Understanding Harm

Understanding harm includes both people and property. A medical device that catches fire might threaten property, while an infusion pump with air in the line might threaten human life. Think about what could cause harm to people, like a shark swimming in the water. A shark that attacks a person could create different levels of harm. A few examples include loss of a limb, an infection from getting bitten and loss of life. The various levels of harm result from the hazardous situation, which is the shark in the water.

Harm Severity

Risk Evaluation

Risk evaluation involves comparing an estimated risk against a specific criterion to determine if a risk is acceptable. Five different levels to evaluate risk are common practice, but you can use as many as you’d like. The most severe risk (level five) might include death or impairment. Level one might include no risk to a patient or operator. The levels inbetween include all the other varying
degrees of risk.

Sequence of Events

A hazardous event includes a number of steps, which is the sequence of events. A risk situation might have two, three, or more steps that, when aligned, create a hazardous event. Risk management tools such as fault trees and failure modes and effects analysis (FMEA) help identify these steps.

Previous version of ISO 14971 used terms like “acceptable” and “unacceptable” to describe risks, but that language has since been removed and the most current version maintains as low as possible (ALAP). The goal of every manufacturer is to lower the risk as much as possible and rethinking how to prioritize risk controls can help.

Harm Flow Chart

This has been a preview of the content in our whitepaper, Understanding Integrated Risk Management for Medical Devices to read the entire paper, click HERE


In this blog, we partially recap this customer story, “Vave Health Migrates to Jama Connect® to Accelerate Development and FDA Clearance” Read the entire story HERE.

Vave Health is committed to revolutionizing the physician-patient experience through innovative, industry-transforming technologies. Their innovative handheld ultrasound device packs the ability to wirelessly connect with your Android or iOS smartphone or tablet.

After initially selecting Matrix Requirements, Vave Health found themselves constrained by the tool’s limited functionality and were ready for a change. Following a requirements management market analysis, Jama Connect® was selected and onboarded due to its ease of use and industry-leading functionality.

Read this customer story to see how now, with more confidence in their processes, Vave health has achieved the following outcomes:

  • Accelerate the release cadence from what previously took a couple weeks, down to a day or two
  • Decrease generation of trace matrices from 30 days to one per project
  • Scale development process with the ability to run multiple projects in parallel
  • Maintain traceability and instantly identify coverage for verification and validation of requirements to respond to action items sooner in development

VAVE HEALTH CUSTOMER STORY OVERVIEW

CHALLENGES WITH MATRIX

  • Reports, such as a traceability matrix, were taking too long to generate
  • The steep learning curve caused most people to revert to working in Word and Excel
  • Inability to develop parallel projects and reuse data between releases, contributed to duplicated work and slower-than-desired release cadence

SELECTION CRITERIA

  • A solution that would scale with their growth
  • Quick-to-adopt and easy-to-use 
  • Strong market presence
  • Ease of data migration

OUTCOME + FUTURE

  • Accelerate the release cadence from what previously took a couple of weeks, down to a day or two
  • Decrease generation of trace matrices from 30 days to one per project
  • Scale development process with the ability to run multiple projects in parallel
  • Maintain traceability and instantly identify coverage for verification and validation of requirements to respond to action items sooner in development

RELATED: 2023 Predictions for Medical Device Product Development

CHALLENGES

In the early days of Vave Health, the development team originally selected Matrix Requirements due to its low cost. While the tool was sufficient for managing their requirements in the preliminary stages of development, as the company began to scale, it became apparent that they needed a more mature, enterprise-grade solution with more robust capabilities.

The main challenges that Vave Health had which led them to seek out a new solution were:

  • Reports, such as a traceability matrix, were taking too long to generate
  • Steep learning curve caused most people to revert to working in Word and Excel
  • Inability to develop parallel projects and reuse data between releases, contributed to duplicated work and slower-than-desired release cadence

As a small team, they did not have dedicated staff to manage requirements – it was a shared responsibility. With Matrix Requirements, the learning curve was so steep, only a few people were able to use it. Even then, it was used similarly to an Excel spreadsheet.

“Matrix Requirements was difficult to use, and it limited our ability to easily extract reports and quickly show traceability. The whole process just took too long,” said Craig Loomis, Vice President of Product at Vave Health.

“One of the deliverables in getting our product released is generating the trace matrix. With Matrix Requirements, it was very cumbersome,” said Sandhya Mitnala, Head of Quality and Regulatory at Vave Health. “We realized that something that should have taken one or two days, and managed through the project, took us almost a month. It was a very manual process.”

Additionally, as the team grew and the development work went from singular to multiple projects, the team ran into limitations using Matrix Requirements.

“One thing we didn’t initially think about when selecting Matrix Requirements was the ability to have multiple projects in motion at the same time,” said Loomis. “Although it was technically possible, there was no good way to extract the trace matrix and manage revisions across different projects at the same time in parallel.”

RELATED: FDA Updates to the Medical Device Cybersecurity Guidance

SELECTION CONSIDERATIONS

In order to overcome the limitations of their current tool, the team set out to find a solution that could meet their current needs and grow with them as they expanded in the market.

“The startup world is unique in that you’re trying to do so much more with fewer resources. Sometimes you do need to leverage technology to automate things that larger companies would be
able to throw bodies at,” said Loomis.

When it came time to evaluate the available solutions in the marketplace, things moved quickly.

“From my experience working with Jama Software® at other companies, and my coworkers’ similar experiences, we wanted to move to a more automated solution and Jama Software was on everyone’s mind,” said Mitnala. “It was a very easy choice for us. All of the solutions we looked at, outside of Jama Connect®, were ruled out quickly,” shared Loomis.

During the evaluation process, the Vave Health team was able to access a sandbox account created specifically for them, so they could test out the solution to make sure it was the right fit.
Because there were so many things already in motion, the team wanted to ensure that data migration would not be an issue, so they could keep moving quickly.

“Before we even signed a contract, we spent time in Jama Connect and had a lot of confidence in moving forward. We knew that our data would be migrated easily, and we wouldn’t be putting our projects at risk,” said Loomis.

Although Matrix Requirements supported some initial needs, the team knew that in order to derive the value they needed, it was time to up-level their tool for requirements management and systems engineering. The return on investment for Jama Connect, a robust, yet easy-to-use platform (which comprised the feature set and functionality they required) would increase efficiencies, simplify compliance, reduce risk, and ultimately speed time-to-market, paying dividends in the long run.

“As a startup, the one thing you must ensure is that you are able to move fast. You’re learning the market, you’re working against your competitors, and speed to market is critical. Especially where there are things that can be automated – that’s where you want to invest,” said Loomis.

To read the entire outcome from Vave Health’s choice of Jama Connect, read the entire customer story here:
Vave Health Migrates to Jama Connect® to Accelerate Development and FDA Clearance


CE Marking

Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from Spyrosoft, titled “CE marking for Medical Device Software: a step-by-step guide” – originally authored by MAŁGORZATA KAWAŁKOWSKA.

CE Marking for Medical Device Software: A Step-By-Step Guide

The recent introduction of EU MDR brought many changes to the CE marking certification process for medical devices. There are more requirements to fulfil, which makes the process more complex and much more time-consuming.

To avoid a scenario where the only thing that stops you from releasing your Medical Device Software to the market is the ongoing CE marking certification, you should know when to take the first steps in this process and how to include it in your overall business strategy.

From this blog post, prepared based on an interview with Krzysztof Minicki, Director of Healthcare and Life Sciences, you’ll get to know the steps of the CE marking process for Medical Device Software. You’ll also learn your responsibilities as a manufacturer, and thus get a better understanding of how to plan and optimise the process to avoid possible bottlenecks.

ToC:

  1. Does your software need a CE marking certification?
  2. How to get the CE marking certification for Medical Device Software in the EU?
  3. How to do CE marking self-certification?
  4. How long is the CE marking certification valid?
  5. How much does it cost to get CE marking certification?
  6. How long does the CE marking certification process take?
  7. Need support in the CE marking certification process?

Does your software need a CE marking certification?

Since the introduction of EU MDR in May 2021, the software is now classified as an active medical device. All Medical Device Software that is released to the EU market is required to have the CE marking. Otherwise, it cannot be sold within the EU.

CE MARKING AFTER BREXIT

As of January 1st, 2021, any type of business collaboration between the UK and EU countries got a lot more complicated. So did the CE marking process, which has gone into the transition period ending on January 1st, 2023 – medical companies operating on the British market will be obliged to receive UKCA certification instead of CE marking, with medical products sold in Northern Ireland still requiring the latter. Healthcare products that require to be assessed by a Notified Body will need to be check by an UK Notified Body rather than a EU one.

How to get the CE marking certification for Medical Device Software in the EU?

As a Medical Device Software manufacturer, regardless of whether or not you outsource the manufacturing process, you are responsible for acquiring the CE marking.

In general, the path towards obtaining the CE marking depends on the medical device’s class. Since, in the light of the EU MDR, Medical Device Software is considered as an active medical device, the majority will undergo the upclassification and will belong at least to class IIa.

As per the EU MDR rules, medical devices from classes IIa, IIb and III, have to go through the conformity assessment conducted by a Notified Body. A Notified Body is a third-party organisation, accredited by a European Competent Authority, that checks compliance with the MDR. As a medical device manufacturer, you can select which Notified Body you want to do the assessment for you.

Now, let’s move on now to what the CE marking process for Medical Device Software looks like step by step.

RELATED: 2023 Predictions for Medical Device Product Development

How to do CE marking via self-certification?

1: IMPLEMENT A QUALITY MANAGEMENT SYSTEM

As you determine the classification of your Medical Device Software and appoint a person responsible for regulatory compliance in your organisation, the next step is to create and implement a Quality Management System in accordance with Annex VIII of the MDR and ISO 13485. The compliance must be assessed and certified by a Notified Body. Moreover, the Quality Management System must include Clinical Evaluation, Post Market Surveillance and Post Market Clinical Follow-up plans.

2: PREPARE THE TECHNICAL FILE

In the Technical File you have to include the information about the Intended Use of your Medical Device Software, all the testing reports as well as the Clinical Evaluation Report, your risk management plan and other information specified in Annex II of the MDR.

3: REGISTER IN THE EUDAMED DATABASE

Register your Authorised Representative who will handle the regulatory matters as well as your company as a medical device manufacturer in the EUDAMED database. It’s important to note that the authorised representative is mandatory only for importers outside of the EU.

You don’t necessarily have to do it at this point. It can also be done earlier or later in the process.

4: PREPARE A DECLARATION OF CONFORMITY

The next step for you, the manufacturer, is to prepare a Declaration of Conformity. It’s a legally binding document in which you affirm that your Medical Device Software is compliant with the MDR. At this stage, your product becomes officially CE marked.

5: REGISTER THE MEDICAL DEVICE SOFTWARE IN THE EUDAMED DATABASE

Now it’s time to register your software in the EUDAMED database. Keep in mind, that the UDI number must be placed, for example, in the “footer” or “About” section or other visible and easy-to-access places.

That’s it – your Medical Device Software is ready to be sold on the EU market. Your duty as a manufacturer is now to keep it safe and effective. In this regard, the EU MDR requires that manufacturers conduct Post Market Surveillance Activities. Also, each year you will undergo a Notified Body surveillance audit to ensure continuous compliance with the EU MDR. If you fail to pass it, your CE marking may become invalid.

During the transitional period, the manufacturers are required to perform the Clinical Evaluation and Post Market Surveillance Activities required by MDR, even though their CE marking certification for class I is still valid.

How to CE mark your software if it falls into a higher risk class?

The certification of software that belongs to a higher risk class requires the involvement of a Notified Body. A Notified Body shall audit the quality management system to determine whether it meets all the regulatory and product requirements. If the quality management system conforms to the relevant regulatory provisions, the notified body shall issue an EU quality management system certificate. After that, the declaration of conformity can be signed. Then, the product can be registered in the Eudamed database and finally introduced into the market.

Specific requirements depend on the characteristics and the level of complexity of a product as well as the risk associated with using it, which directly translates into the scope and timeframe of the audit.

How long is the CE marking certification valid?

The CE marking certification for classes IIa, IIb and III is valid for up to five years. After the five-year period, the registration of the certification must be renewed. It’s key to have it on the radar and plan the process in advance. It’s recommended to start the registration renewal at least six months before the certification expires.

How much does it cost to get CE marking certification?

The total cost of the CE marking certification process is proportionate to a device’s class. The higher the class, the bigger the risk and the more complex the process. Hence, the cost is also higher. The CE Marking certification is the most expensive for class III devices and can reach even tens of thousands of dollars.

RELATED: Euro Roundup: MDCG Publishes Guidance on MDR, IVDR Authorized Representative Requirements

How long does the CE marking certification process take?

Since there are still very few Notified Bodies, conducting the conformity assessment may take quite a long time. The time to begin a Notified Body audit varies between half a year and a year. In comparison, under the MDD it was usually a quarter. The time between an audit and approval may take up from two to even seven months.

Why so long? The EU MDR brought in more requirements, especially for the QMS. This makes the whole process more complex and time-consuming.

One of the reasons why it takes so long is also that there are few Notified Bodies that got already accredited in compliance with the new MDR requirements.

Currently, the MDR requires Notified Bodies to make their price list public. However, it’s worth noting that it includes the hourly rates. It’s especially important to keep in mind when introducing a product to the market for the first time (also for the first time since the MDR came into force) as it requires more than one audit to be performed. Firstly, the Notified Body checks the readiness for certification and after a few months it conducts the certification audit. It significantly impacts the cost. The yearly surveillance or recertification audits are performed once per year.

In total, the CE marking certification process may last more than a year. It’s important to take it into consideration when planning your business strategy. For example, you can optimise the process by creating an MVP first and start the CE marking Certification in the meantime, while at the same time developing your product further on.

Need support in the CE marking certification process?

We provide a technical file ready to be assessed for conformity by a Notified Body. Moreover, our specialists can conduct an independent conformity assessment before the official one to check what areas need improvement.

The software we create is compliant with all legal requirements, especially the IEC 62304 and ISO14971. In addition, we provide a Technical File and offer consultation and support with completing the CE marking certification process.

For more information, use the form at the bottom of this blog to contact Krzysztof Minicki, Director of Healthcare and Life Sciences.


automotive

As we enter 2023, Jama Software asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.

In the final blog of this five-part series, we asked Steve Neemeh,  CEO / CTO of LHP Engineering Solutions – Danny Beerens, Senior Consultant at Jama Software – and Richard Watson, Practice Director at Jama Software – to weigh in on automotive product and systems development trends they’re anticipating in 2023.

Click the following links to visit part 1 – 2023 Predictions for Product & Systems Development Teams – part 2 – 2023 Predictions for Aerospace & Defense Product Development – part 3 – 2023 Predictions for Industrial and Consumer Electronics Product Development– and part 4 – 2023 Predictions for Medical Device Product Development

Read more about the authors at the end of this blog.

2023 Predictions for Automotive Product Development

Design Trends – What are the biggest trends you’re seeing in your industry right now? How will they impact automotive product, systems, and software development?

Steve Neemeh: A generation ago software was introduced in engine controls that changed the automotive industry and allowed for efficiency and emissions improvement that mechanical systems could not provide. In today’s world, software is entering a new stratosphere of complexity. Rather than focusing on emissions, the goal is the user experience. High-tech meeting transportation changes the paradigm for automotive companies.

Danny Beerens: I don’t see a lot has changed in this regard. What is changing is what’s being built, not how it is being built.

Richard Watson: Taking advantage of Live Traceability™ will become increasingly important.

Definition of Live Traceability: The ability for any engineer at any time to see the most up-to-date and complete up and downstream information for any requirement, no matter what stage of development it is in or how many siloed tools and teams it spans. This enables the engineering process to be managed through data, and its performance improved in real-time.

RELATED: Jama Software® Partners with Sterling PLM: Expands Lifecycle Management and Live Traceability™ Expertise Offerings

Biggest Challenges – What are some of the biggest challenges you think automotive companies will be working to overcome in 2023?

Neemeh: The commercialization of the zero-emissions vehicle is the biggest challenge for 2023. The price points are a challenge. The supply chains are limited and not optimized for worldwide expansion. And, the energy grids are outdated in many places, such as California.

In terms of product and systems development, what do you think will remain the same over the next decade? What will change?

Beerens: More and more brands will move to electric vehicles, making those vehicles and specifically their motor management components more software driven. The various other components (primary functions, driver assistance/automation, as well as onboard entertainment) will also become more electronically controlled and thus software driven.

[Side note] Autonomous driving vehicles even sparked new fields in Software Engineering, like Ethical Software Engineering (studies the interactions of human values and technical decisions involving computing).

Clearly the Automotive Industry is shifting from Hardware/Mechanical Engineering and Electo-Mechanical to Software Engineering, forcing Product Data Management, or Product Lifecycle Management, vendors to start including Application Lifecycle Management into their environments. Hence you see Siemens Teamcenter has acquired Polarion and PTC Windchill acquired Codebeamer recently.

The Holy Grail will be an ALM/PLM environment that truly embraces Configuration Management for all engineering disciplines involved, combined.

Anticipating a new player not hindered by their already existing PLM or ALM application, neither their customer base, to develop a truly all incorporating ‘Engineering Assets Configuration Management’ environment, platform or application.

For the next decade, next to fully autonomous driving vehicles, flying cars might be the new way to fight congestion and a more personalized way to get around.

Regulations – What changing regulatory guidelines do you anticipate having an impact on companies in 2023?

Neemeh: With any new products in automotive, recalls will drive governments to regulate safety more closely. Functional safety is now a common term in automotive and most large OEMs are trying to find a way to comply and keep themselves from facing potential liability. The implementation of functional safety in the software development process will keep inching forward until a trigger makes it mandatory.

How do you foresee regulations shifting in Automotive Product and Systems Development over the next decade?

Beerens: Certainly, autonomous driving will introduce regulations to control not only functional safety and cybersecurity, but also for road safety (and legal responsibility) to interact with non-autonomous driven cars, until we’ve reached an era where none of us drive ourselves and all cars are controlled centrally to manage traffic flows.

Demands on alternative powertrains (e.g., hydrogen, or fuel cells) and existing electric driven cars’ necessity for fast charging and/or quick exchange of batteries, will spark off new technologies.

Apart from the obvious increase in data points and data exchange of the vehicle itself (sharing information for predictive maintenance, or usage of the car; tachograph in trucks) and its manufacturer and/or service station, G5 Connectivity of (autonomous driving) vehicles interacting with new traffic control instruments in, next to or on the road that assist with difficult traffic situations (automatically move to the side to allow emergency vehicles to pass), or location (purposely slow down at intersections that don’t have clear visibility of oncoming traffic) and react to traffic lights.

As a reaction to reduce CO2 emissions (cars sales are in a slow decline for a few years now already) new forms of mobility will arise where MaaS (Mobility as a Service) are being offered, sparking off disruptive newcomers to the traditional car sharing companies (renting: Hertz, and even taxi: Uber), like for example Lynk&Co, offering “memberships” for more flexible car usage and for car sharing with family and friends.

Tool Innovation – From an automotive engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process and why?

Neemeh: Functional safety requires a strict development process and tools that support that process. Traditional tools only meet a small piece of that. They need to be integrated into an overall workflow and safety culture.

Any major disruptions to the Automotive Product and Systems Development industry you’re anticipating in 2023?

Watson: Political environment, supply chain issues, increased cost of specific items (such as chips). This increased cost is pushing the buyers into higher income areas, changing what kinds of cars will be successfully built.

Because of cost issues, refurbishing and retrofitting existing cars will become increasingly important. Similarly, car sharing will be increasingly wanted to control costs.

What role will cybersecurity play in automotive development in the coming year and beyond?

Neemeh: Safety can’t be achieved without cybersecurity. Assessment of your system’s vulnerability and its inclusion in your safety case is key to overall product acceptance. The more that cars become connected, the more this becomes important. Autonomous driving will be the pinnacle of connected cars. The more we move in that direction the more cybersecurity becomes a concern.

RELATED: A Guide to Road Vehicle Cybersecurity According to ISO 21434

What sorts of process adjustments do you think development teams will need to make to be successful in 2023?

Watson: Automotive systems continue to have a stronger focus on software and this shift will continue. Different categories of software are provided in a vehicle from safety-critical to entertainment and this drives complexity sky-high.

With regulations continuing to get more stringent, development practices for non-safety-critical software systems must be tightened and this drives a focus to improve Agile practices. “Agile” is not an excuse to “throw something together” and must be supported by improved specification and verification techniques.

In your opinion, what are the biggest differences between an automotive company that survives to see 2030, and one that doesn’t?

Neemeh: Getting prototypes on the road and small-scale production with new technology (EV/Autonomous) is a monumental feat. The next step, however, is the commercialization of that technology into a transportation industry that is concerned about public safety. Those that consider that in the rollout and enable the scaling of safety-critical infrastructure will win, while the others will hit a brick wall of regulation.

Watson: A combination of sustainability with control of spiraling costs. There is a world shift in planetary awareness and the automotive market is at the forefront of reducing our consumption of fossil fuels. Car prices are increasing beyond inflationary rates and this increase will price out much of the lower market. Only organizations that can shuffle sustainability, quality and costs will survive this decade.

What role will cybersecurity play in automotive development in the coming year and beyond?

Watson: A shift towards Internet of Things (Iot) has exposed almost all aspects of automotive systems to the internet and social media. Cybersecurity will take a stronger focus, especially for those software systems that already interact with our social networking applications.

Beerens: Not only for our social networking applications; for long all systems utilizing the various onboard connections simply accepted instructions, without checking if that instruction was from a valid source. The infamous hack of a Landrover during Black Hack 2014 proved that. Encryption and intrusion detection are a good line of defense, but Zero-trust (or validating the source of the commands) Cybersecurity will be increasingly important for onboard systems from entertainment systems, connections like CAN, wifi, bluetooth or NFC, to motor management.

What advice would you give to new companies entering the automotive industry?

Neemeh: Get your workflows set up and your tools ready and optimized before you start throwing bodies at problems. Engineers are expensive. When they are set up properly, they can create miracles. But if they are burdened with administrative problems, they will get frustrated and leave.

Beerens: Look at established tool chains and industry templates to have a running start at the get-go. The European Union has an advisory board with such tool chains and templates. Concern yourself with compliancy from the beginning. Which compliancy standards you concern yourself with will depend on what parts of the auto you are working on.

Watson: Don’t try and define and invent the wheel and get help. There are many development tools available, find which tools work best based on tool reviews. Once selected, ask the vendor for the best way of working and don’t force the tool to do inefficient practices.

RELATED: Accelerate Your Automotive Development Requirements Management with Jama Connect®

What topic(s) do you wish companies were paying more attention to?

Watson: Understanding how to address complex problems without the systematic nature we have relied upon. This is the only way to keep control of costs.

Predictions – What do you think will remain the same in your industry throughout 2023?

Neemeh: The adoption of electric vehicles will continue. Governments are behind it and the adoption rate is increasing.

What do you predict for regulation in the Automotive industry in 2023?

Neemeh: Involvement in the design process and review of ADAS features will become more important. The NHTSA has already started putting frameworks in place for that in the USA. In Europe, functional safety is commonplace and regulated already.

Will those trends still be prevalent 5 years from now? 10 years?

Neemeh: Yes, and it will move as fast as ADAS features move forward. Any autonomous Level 5 applications will jump-start this trend.

Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?

Watson: Jama Software® is perfectly positioned to help the automotive industry allowing extended stakeholders to be directly involved with authoring and reviewing specification and verification activities rather than relying on tool super-users and PDF reports.

Beerens: Jama Connect® is a perfect fit for Product Design and collaboration with all its Stakeholders to refine, expand and improve Product Design, before any of these (proposed) changes are even visible in a PLM environment thereby preventing disruptions in Production before consensus has been reached.

——————————–

About the Authors:

Steve Neemeh joined LHP in 2015 to lead the expansion of the west coast operations. He is the leader of the strategy and solutions architects as well as president of the delivery consulting organization. Steve has over 25 years of Functional Safety experience prior to joining LHP. Steve has launched multiple start-up operations and has taken them to full production. Notably, a complete ground up electronics and software development group to service commercial aerospace electronics and military vehicle power electronics. For LHP, Steve pioneered the implementation of safety critical applications in California, launching functional safety for autonomous driving applications as well as air mobility.

Danny Beerens has 15 years of experience implementing, training, maintaining and supporting Application Lifecyle Management processes and their environments. Danny started in Software Configuration and Change & Defect Management (i.e., Workflows.) After joining Telelogic, he moved into Requirements and Test Management over the last decade, in roles as Support Engineer, Process Engineer, Consultant, and System Architect. Throughout his career Danny’s worked on projects and collaborated with customers in the Medical Devices, Aerospace & Defense, Automotive, and Semi-conductor industries. “The need to integrate ALM and PLM (and even beyond!) is apparent across all industries.”

Richard Watson is the Practice Director for horizontal solutions, engaged in identifying and creating services and assets spanning the Jama Software vertical solutions. Richard has a client first attitude and is passionate about Requirements and Systems Engineering. Based in the UK, Richard has been working in the systems and software industry for nearly 35 years and has been directly involved in most aspects of Systems Engineering from testing flight systems, through to software development of modeling tools, and Product management of IBM DOORS. Richard joined Jama Software as Practice Director in 2021.