Blogs

Software as a medical device (SAMD) - classification overview

Wendy Levine

February 7, 2022

4 min read

What is software as a medical device (SaMD)?

As the pace of technological innovation continues to increase, the definition of what constitutes a medical device also continues to evolve as countries update regulations. In 2013, the International Medical Device Regulators Forum (IMDRF) created the Software as a Medical Device working group. Currently chaired by the U.S. FDA, the working group is chartered with developing guidance that encourages innovation while assuring safe and effective products. While SaMD is regulated differently in different countries, this article will focus on the many similarities, and some differences, between the FDA regulations in the U.S. and the MDR regulations in the EU.

In general, medical device software falls into 3 different categories:

Software as a Medical Device (SaMD): The IMDRF defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” We list specific examples below, but typically the software classified as SaMD isdesigned to run on generally available hardware, such as Windows computers or mobile devices, or online in the “cloud”. While they may be utilizing data from another medical device, SaMD performs its function independently of any medical equipment or hardware.
Software in a Medical Device: Sometimes referred to as SiMD, Software in a medical device cannot operate separately from its device, or perform its primary function without the device. For example, the software used to program and run an MRI machine would be useless without the MRI machine. Software in this category is regulated together, and as part of, the whole device.
Software as an Accessory to a Medical Device: Similarly to Software in a Medical Device, software in this category cannot fulfill a medical purpose on their own. In some cases, a manufacturer may be able to bundle or embed the software in the medical device (making it SiMD) and/or also sell the software separately, making it an accessory.

Similarly, in Europe, the European Commission’s Medical Device Group (MDCG) defines Medical Device Software (MDSW) as a having its own intended purpose. Software which controls a medical device or is otherwise part of a medical device and does not serve a separate medical purpose does not qualify as MDSW, but is regulated by the MDR.

Software in the SaMD category is both a medical device AND software - with relevant regulatory and quality considerations that are specific and unique to each category, yet which must work in tandem. For example, software development best-practices, referenced by the IMDRF SaMD working group, call for iterative feedback loops allowing for quick turnaround of feature requests and bug fixes. While the ability to provide the latest technology and features to the market is an important advantage with SaMD, it does not supersede applicable medical device regulations governing patient safety and efficacy.

Examples of software as a medical device (SaMD)

Because SaMD software, by definition, is capable of running independently of any specific medical device or hardware, there is a relatively clear line between Software as a Medical Device and other medical software:

Software as Medical Device (SaMD)	Not SaMD
Software that evaluates MRI images and makes diagnosis recommendations.	Software that controls an MRI machine (SiMD).
A mobile app that monitors a patient’s heart rate or glucose levels and makes treatment recommendations to the patient and/or patient’s doctor.	Software that allows a patient to control their insulin pump based on glucose readings (SiMD).
An application, based on machine learning algorithms, that reviews patient health data and makes treatment recommendations.	Software that securely stores patient health and treatment history (Digital Health Records or Medical Information System).

SaMD regulatory overview and framework

Why does SaMD have independent regulatory considerations?

Over the past decade, the IMDRF, FDA, and other regulatory bodies have worked to better align regulations with the quickly evolving capabilities and nature of digital devices. Software-only devices (SaMD) generate unique opportunities and considerations:

Because SaMD software typically runs on publicly available hardware:

SaMD software must not only be designed to work on specific platforms (usually multiple), but must also be tested and updated frequently as new hardware and operating systems become available.
Agile software development methodologies can provide an environment in which fast product feedback loops are supported within the required regulatory framework.

Because SaMD software can be made readily available to the general public, or specific patient groups, using their own devices:

SaMD software can generate faster user/patient feedback - both for medical professionals and for the device manufacturer. Given this environment, regulatory bodies generally want to enable the market to safely take advantage of new innovations as quickly as possible.
Product testing needs to take into account the unique and varied environments in which the software may be used, potentially in environments the product is not intended for. The software developer cannot control updates to operating systems or internet browsers, other software that may be running on a user’s device, or the ability for the user to potentially share software or data with others.
The advantages of quickly delivering product fixes and updates need to be measured against potentially introducing new, possibly misunderstood or unwanted features, to all users at once.

SaMD and MDSW risk-based categories

As with all medical devices, the FDA and European MDR classify SaMD and MDSW, respectively, based on the potential impact to patient or public health. The SaMD categorization framework from the IMDRF is an effort “to introduce a foundational approach, harmonized vocabulary, and general and specific considerations, for manufacturers, regulators, and users alike to address the unique challenges associated with the use of SaMD...” This framework provides guidance only for today’s medical software developers, as well as regulatory bodies, such as the FDA. The chart below lists these risk categories by the state of the healthcare situation or condition and by the significance of the information provided by the SAMD:

SaMD categories

State of healthcare situation or condition	Treat or diagnose	Drive clinical management	Inform clinical management
Critical	IV	III	II
Serious	III	II	I
Non-serious	II	I	I

‍‍SaMD Category I:

SaMD Category I software can provide information for both Serious and Non-Serious health conditions or diseases. Software dealing with serious conditions can be classified in Category I only if it is providing information to inform, not drive, clinical management and is of low impact. Otherwise, Category I SaMD software provides information related to non-serious diseases or health conditions.

Example: Software that collects exercise-related data, such as heart rate, number of steps, and distance walked. If the information is stored and/or transmitted for use by a qualified professional the software is considered to be in Category I, as long as the information is not used by the software to make treatment recommendations directly to the patient or healthcare provider.‍

SaMD Category II:‍

SaMD software in Category II may be used to provide information relevant to a non-serious, serious, or critical healthcare condition or disease, depending on the significance of the information it provides to the healthcare decision. Software that is used to treat or diagnose a health condition is only classified in Category II for non-serious health conditions. Software that provides information regarding serious or critical health conditions or diseases will be classified in Category II only if it provides information to drive or inform, respectively, clinical management decisions (as opposed to providing treatment or diagnosis recommendations directly).‍

Example: SaMD that monitors a diabetic patient’s carbohydrate intake and blood glucose level to calculate recommended insulin dose.‍

SaMD Category III:

SaMD software that provides information to treat or diagnose serious conditions - or which drives clinical management for a critical condition - is classified in Category III.‍

Example: SaMD that analyzes individual data from at-risk populations for a specific type of cancer, and is used to develop preventative intervention strategies. ‍

SaMD Category IV:

SaMD Category IV software provides information used to treat or diagnose a critical health condition and is considered to be very high impact.‍

Example: SaMD that evaluates images of skin lesions in order to determine malignancy. ‍

For SaMD intended to be used in multiple healthcare situations, the software will be categorized at the highest category according to the SaMD definition statement. ‍

SaMD within the FDA and MDR regulatory framework

The graph below relates SaMD categories with FDA medical device classes, and further identifies where an independent review is recommended by the FDA. For additional information see Software as a Medical Device (SaMD): Clinical Evaluation. Guidance for Industry and Food and Drug Administration Staff.‍

Note that FDA regulatory classifications more closely align with the IMDF’s SaMD categories than do those defined by under the European MDR. In the U.S., a device is classified by identifying similar, predicate devices. The simpler 510(k) pre-market submission can be used if a manufacturer can show that their device is substantially equivalent to a Class I or II device. With few exceptions, devices that are Class III are subject to the more rigorous Pre-Market Authorization (PMA) process. Devices where no substantial equivalent can be shown are subject to to the PMA or De Novo regulatory submissions processes. The De Novo process was implemented in 2010 to provide a pathway for novel devices with lower risk profiles.

Medical Device Software is classified by the European Commission’s Medical Device Coordination Group (MDCG) into Class I, II, or III. For devices falling under the IVDR, the MDR defines four classes using letters; A, B, C, and D.

Intervention type	Treat or diagnose	Drive clinical management	Informs clinical management
Critical	III	IIb	IIa
Serious	IIb	IIa	IIa
Non-serious	IIa	IIa	IIa

In the EU, a rules-based framework is used to classify devices. MDSW classification is relatively complex, using a series of 22 “waterfalling” rules with yes/no questions that lead to a final classification of each device. While we won’t go into detail in this article on each of the rules, Rule 11 does deserve discussion. (You can read the Guidance on Classification of Software for MDR and IVDR here).

The MDR’s “rule 11” regarding MDSW classification was released in 2017. This rule states, in part, that “Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa.” The rule then provides 2 exceptions that increase the MDSW classification in cases where the decisions could cause “a serious deterioration of a person’s state of health or a surgical intervention” (class IIb), or could cause “death or an irreversible deterioration of a person’s state of health” (class III).

As a result of this rule, very few MDSW products can be classified as Class I, meaning that the majority of MDSW is subject to conformity assessments by a Notified Body. Medical software manufacturers marketing their product in Europe should therefore not rely on previous product classifications as a guide.

The future of regulatory approval for software as a medical device (SaMD)

The FDA recently released a new draft guidance document addressing the Content of Premarket Submissions for Device Software Functions. This is a major update of the 2005 guidance on pre-market submissions for software in medical devices and is also long overdue, given the pace of change in the software industry (the FDA originally committed to delivering this update in their fiscal year 2019 as part of the MDUFA IV agreement). This guidance sets out requirements for all pre-market submissions, including 510(k), DeNovo, and PMA submissions.

The recent draft document provides additional guidance around the documentation required for premarket submissions. It defines an “enhanced” level of documentation required for software that is a Class III device, combination product, Blood Establishment Computer software, or when the failure of the software would present probable risk of death or serious injury.

Staying on top of medical device classifications

Classifying a medical device and gaining regulatory clearance can be a complex process, especially if the device contains software or other emerging technology where some regulatory bodies may be further along than others in developing applicable regulations. For additional information about some of the common pathways to market for new products in the U.S., read our Beginner’s Guide to the FDA 510(k) and Beginner’s Guide to the FDA De Novo Classification Process.

Interested in learning how Rimsys can automate your submission process? Request a custom demo of our RIM platform.

Share this post

Featured

Rimsys Announces Rimsys AI to Eliminate Repetitive Tasks and Enhance Decision-Making for MedTech Regulatory Teams

Rimsys, the leading Regulatory Information Management (RIM) platform for the MedTech industry, today announced the launch of Rimsys AI, a suite of embedded artificial intelligence (AI) agents.

GET IN TOUCH

Talk to the Rimsys Team

Book a Demo

Similar posts

Registration deadlines don't have to be a risk. See how centralized data, automated alerts, and standardized workflows keep global registrations on track

How to Prevent Registration Deadline Misses in 2026

Bethaney Lentz

August 4, 2026

4 min read

A missed registration deadline can halt sales, trigger regulatory penalties, and damage your organization's credibility with health authorities. For MedTech regulatory affairs teams managing hundreds or thousands of product registrations across dozens of markets, preventing deadline misses requires more than calendar reminders. It demands structured data, clear workflows, and real-time visibility into expiration timelines.

This guide explains why registration compliance deadlines are missed and how your team can prevent delays through stronger data control, workflow visibility, and process standardization.

Key Takeaways: How to Prevent Registration Deadline Misses in 2026

Registration deadline misses typically stem from fragmented data, unclear ownership, and siloed communication between teams.

Proactive renewal management requires real-time visibility into expiration dates across your entire global product portfolio.

Standardized workflows with assigned accountability eliminate the confusion that leads to overlooked deadlines.

Rimsys centralizes registration data and automates renewal alerts, reducing the risk of missed deadlines by up to 90%.

Investing in a purpose-built RIM platform protects revenue continuity and maintains uninterrupted market access.

Why Do MedTech Teams Miss Registration Compliance Deadlines?

Registration deadline misses occur because the operating model cannot scale with growing portfolio complexity. Understanding root causes is the first step toward prevention.

Fragmented Data Across Systems and Regions

Many organizations track registrations using disconnected regional trackers, shared drives, and individual team member records. When product data lives in multiple locations, no single source of truth exists. This fragmentation makes it difficult to identify upcoming expirations before they become urgent.

A registration that expires in Brazil may be tracked in one system while the same product's EU approval is monitored elsewhere. Without connection between these records, teams lack portfolio-wide visibility into renewal timelines.

Unclear Ownership and Accountability

When responsibilities are distributed across regional leads, in-country partners, and distributors without clear accountability structures, deadlines fall through the cracks. Team members may assume someone else is handling a renewal, leading to inaction until the deadline passes.

Organizations with high turnover face additional risk. When key personnel leave, institutional knowledge about pending renewals often leaves with them.

Reactive Tracking Instead of Proactive Management

Calendar-based reminders and email notifications are inherently reactive. By the time a reminder appears, teams may not have enough runway to gather required documentation, coordinate with authorities, or address unexpected complications.

Effective deadline management requires proactive monitoring that surfaces upcoming expirations months in advance, not days before they occur.

‍

What Happens When Registration Deadlines Are Missed?

The consequences of missed registration deadlines extend beyond administrative inconvenience. They create tangible business disruptions that affect revenue, reputation, and regulatory standing.

Loss of Market Access and Revenue Disruption

An expired registration means your product cannot legally be sold in that market. Regulatory teams must halt shipments, distribution partners cannot fulfill orders, and revenue stops flowing. For high-volume products or critical markets, even brief interruptions to the supply chain can translate to significant financial impact.

Re-registering a lapsed product often takes longer than a standard renewal. Your team may face additional scrutiny, updated documentation requirements, or queue delays that extend the time to market restoration.

Regulatory Penalties and Increased Scrutiny

Health authorities track compliance history. Missed deadlines signal operational weaknesses that can trigger increased inspection frequency, additional documentation requests, or enhanced scrutiny on future submissions. Building trust with regulators takes years; eroding it takes one avoidable miss.

Damage to Distributor and Partner Relationships

In-country partners and distributors depend on your organization to maintain valid registrations. When market access lapses, partners bear the burden of explaining delays to healthcare providers and end customers. Repeated misses can damage long-term business relationships and competitive positioning.

‍

How to Identify Products at Risk of Deadline Misses

Prevention starts with identifying which registrations are most vulnerable. A systematic risk assessment helps teams prioritize attention and allocate resources effectively.

Create a Consolidated Registration Inventory

Bring all registration data into a single view. Include product identifiers, registration numbers, approval dates, expiration dates, responsible parties, and market-specific requirements. This inventory becomes your foundation for risk assessment.

Rimsys Registration Software centralizes this data automatically, linking registrations to products, submissions, and regulatory intelligence in one structured system.

Segment by Expiration Timeline and Complexity

Not all renewals carry equal risk. Categorize registrations by time remaining until expiration and by the complexity of renewal requirements. Products expiring within the next 90 days with extensive documentation needs should receive immediate attention.

Consider country-specific factors. Some markets require local testing, updated clinical data, or notified body involvement. These requirements extend lead times and increase the risk of delays.

Assess Documentation Readiness

For each at-risk registration, evaluate whether required documentation is current and accessible. Outdated technical files, missing test reports, or incomplete labeling information create bottlenecks that delay renewal submissions.

Documentation gaps discovered weeks before a deadline often cannot be addressed in time. Early assessment ensures enough runway to resolve issues.

‍

Building a Proactive Renewal Management System

Moving from reactive tracking to proactive management requires intentional process design. The following components form the foundation of an effective renewal management system.

Establish Clear Ownership for Every Registration

Assign a single accountable owner for each registration. This person is responsible for monitoring expiration timelines, coordinating renewal activities, and escalating issues that require additional support.

Ownership should be documented within your registration management system, not stored in separate organizational charts or email threads. When someone leaves the organization, ownership transfer becomes straightforward.

Define Standard Lead Times by Market and Product Type

Different markets have different renewal timelines. EU MDR renewals involve notified body coordination. FDA establishment registrations follow annual cycles. ANVISA submissions may require specific local documentation.

Document the standard lead time needed for each market and product type. Use these lead times to trigger renewal workflows well before deadlines approach.

Implement Automated Expiration Monitoring

Replace manual calendar tracking with automated monitoring that surfaces upcoming expirations across your entire portfolio. Alerts should trigger at multiple intervals, such as 180 days, 90 days, 60 days, and 30 days before expiration.

Automated monitoring ensures that no registration is overlooked, regardless of portfolio size or team bandwidth. Rimsys Global Regulatory Compliance capabilities include lifecycle tracking and automated alerts that reduce missed renewal risk.

‍

Standardizing Workflows to Prevent Oversight

Consistent workflows eliminate the variability that leads to deadlines. When every renewal follows the same structured process, teams can identify and address deviations before they cause problems.

Create Renewal Workflow Templates

Define the steps required for each type of renewal. Include documentation gathering, internal review, submission preparation, authority submission, and post-submission tracking. Assign responsible parties and expected durations for each step.

Templates ensure that new team members can execute renewals correctly without relying on undocumented institutional knowledge.

Build Escalation Paths for Delayed Activities

Not every renewal proceeds according to plan. Documentation may be delayed. Authority responses may take longer than expected. Partners may fail to submit required local information.

Define clear escalation paths that activate when activities fall behind schedule. Escalation should be automatic and visible, not dependent on individual team members raising concerns manually.

Conduct Regular Pipeline Reviews

Schedule recurring reviews of your renewal pipeline. During these reviews, examine registrations approaching expiration, identify any blocked activities, and confirm that responsible parties are on track.

Pipeline reviews surface potential issues early, when corrective action is still possible. They also reinforce accountability by making renewal status visible to leadership.

‍

How Data Control Reduces Deadline Risk

Strong data control is the foundation of reliable deadline management. When registration data is accurate, current, and accessible, teams make better decisions and avoid preventable misses.

Maintain a Single Source of Truth

Eliminate competing data sources by establishing one authoritative system for registration information. All team members, partners, and stakeholders should access the same data, ensuring consistency and reducing confusion.

A single source of truth means that when someone asks about a product's registration status in a specific market, the answer is immediate and reliable. No cross-referencing multiple trackers. No waiting for colleagues to respond to email inquiries.

Connect Registration Data to Product and Submission Records

Registrations do not exist in isolation. They connect to specific products, rely on previous submissions, and may be affected by regulatory changes or product modifications. Systems that link these data types enable more accurate impact analysis.

When a product design change occurs, connected data helps teams identify which registrations may need updated. When regulations evolve, linked intelligence shows which markets and products are affected.

Ensure Version Control and Audit Readiness

Regulatory authorities expect organizations to demonstrate controlled processes. Maintain version history for all registration-related documentation. Track who made changes, when changes occurred, and what was modified.

Audit readiness built into daily operations means less scrambling when inspections occur. It also shows the historical context needed to understand how registration status evolved over time.

Leveraging Technology for Visibility and Automation ‍

Technology plays a critical role in scaling deadline management across large portfolios. Purpose-built regulatory information management platforms offer capabilities that generic tools cannot match.

Dashboard Visibility Across Global Markets

Executive and operational dashboards display at-a-glance visibility into registration status across your entire portfolio. Filter by market, product line, expiration timeline, or responsible party, to focus on relevant subsets.

Dashboard visibility enables leadership to ask and answer questions quickly:

How many registrations will expire in the next quarter?

Which markets have the highest concentration of upcoming renewals?

Are any renewals currently blocked?

Automated Alerts and Notifications

Configure alerts that notify responsible parties when action is required. Notifications should be specific, actionable, and timely. Rather than generic reminders, alerts should identify the specific registration, required action, and deadline.

Effective notification systems reduce the cognitive burden on team members. Instead of tracking deadlines mentally, they receive prompts when attention is needed.

Reporting for Continuous Improvement

Track metrics that indicate process health. Monitor the number of registrations renewed on time, average lead time utilization, and frequency of expedited renewals. Use these metrics to identify process weaknesses and drive improvement.

Organizations that measure renewal performance can demonstrate compliance maturity to regulators, partners, and investors. Metrics also help justify investments in process improvement.

‍

How Rimsys Helps Prevent Registration Deadline Misses

Rimsys is the first and only holistic Regulatory Information Management software purpose-built for MedTech. It centralizes registrations, submissions, regulatory intelligence, and UDI data in one connected platform, giving teams the visibility and automation needed to prevent deadline misses.

Centralized Global Registration Tracking

Rimsys maintains a structured, product-centric data model that connects registrations to products, markets, and submissions. Teams gain real-time visibility into where every product can be sold, which registrations are pending, and which are approaching expiration.

Six of the world's top 12 MedTech manufacturers trust Rimsys to manage global regulatory operations, achieving up to 90% reduction in reporting effort and elimination of manual tracking risk.

Automated Lifecycle Alerts

Rimsys monitors registration lifecycles and automatically alerts teams to upcoming expirations, renewals, and information requests. Automated alerts ensure that no registration is overlooked, regardless of the portfolio size.

With Rimsys AI, teams can accelerate regulatory work through AI-assisted workflows that reduce repetitive tasks while keeping human judgment in control.

Connected Regulatory Intelligence

Registration deadlines do not exist in isolation from regulatory change. New requirements can affect renewal timelines, documentation needs, or market access conditions.

Rimsys connects registration data to regulatory intelligence and impact assessment workflows, helping teams understand how changes affect their portfolio before deadlines become urgent.

Creating a Culture of Deadline Accountability

Technology and process alone do not prevent deadline misses. Organizations must also cultivate a culture where deadline accountability is valued and reinforced.

Make Renewal Performance Visible

Share renewal metrics with teams and leadership regularly. Celebrate on-time renewals and analyze near-misses to identify improvement opportunities. Visibility creates accountability without requiring punitive measures.

Invest in Team Training and Development

Ensure that team members understand the importance of deadline management and have the skills to execute renewal workflows effectively. Training should cover both procedural requirements and the business impact of missed deadlines.

Support Cross-Functional Collaboration

Registrations often require input from quality, engineering, labeling, and commercial teams. Foster collaboration across functions to ensure that dependencies are identified early and addressed proactively.

When regulatory affairs teams operate in silos, they lack the information needed to anticipate complications. Cross-functional visibility enables earlier intervention.

‍

In Conclusion: How to Prevent Registration Deadline Misses

Preventing registration deadline misses requires intentional effort across three dimensions: data control, workflow visibility, and process standardization. Organizations that invest in these areas protect revenue continuity, maintain regulatory standing, and preserve partner relationships.

The complexity of global regulatory operations is not slowing down. As portfolios expand and requirements evolve, teams need infrastructure that scales. Rimsys transforms regulatory operations from administrative tracking into strategic enablement, bringing speed, visibility, and confidence to global expansion.

Ready to eliminate deadline risk from your registration management? Speak with the Rimsys team to see how leading MedTech manufacturers manage global registrations with precision and control.

‍

References:

How to Register and List a Medical Device with the U.S. FDA

Medical Devices and EUDAMED in Europe

U.S. FDA, Code of Federal Regulations, Title 21, Subchapter H, Part 807

IMDRF (International Medical Device Regulators Forum)

ISO 13485, Medical Devices

How Smith & Nephew Repositioned Regulatory as a Strategic Commercial Partner

Caroline La

May 28, 2026

4 min read

Smith & Nephew is a global medical device manufacturerwith a broad portfolio spanning orthopedics, sports medicine, and woundmanagement, sold and registered across markets worldwide. Before Rimsys,regulatory data was scattered across spreadsheets, shared drives, anddisconnected systems.

When Smith & Nephew selected Rimsys, they deployed enterprise-wide from day one. Executive reporting moved from manual fire drills to real-time dashboards. Change impact assessments became faster and more consistent. The regulatory team made the shift from reactive compliance function to strategic partner to the business.

The Challenge

Regulatory data at Smith & Nephew lived in multiplespreadsheets, shared drives, SharePoint sites, emails, and disconnectedsystems. Without a centralized record, the team could not reliably trackregistration timelines, measure on-time submissions, assess change impacts, orunderstand the downstream impact of product changes across markets. Preparingexecutive reporting meant manually assembling data from multiple sources, aprocess that consumed time and introduced risk each time.

‍

The Solution

Smith & Nephew selected Rimsys for its configurable, notcustomized, platform: an intuitive user interface, centralized submissionmanagement, robust metrics, change assessment capabilities, and UDI supportwith machine-to-machine transmission. Rimsys’ interconnected modulearchitecture linked products, registrations, projects, change assessments, andUDI in a centralized location.

Rather than piloting in one business unit, Smith &Nephew deployed Rimsys across the entire regulatory organization from day one.The decision was deliberate: a partial deployment would have preserved thefragmentation. Enterprise-wide adoption established consistent metrics,standardized processes, and a single source of truth from the start.

‍

The Results

Executive and board reporting, previously built from manualdata pulls, now flows directly from Rimsys in real time. What had been adisruptive, recurring effort is now a routine view. Leadership has thevisibility to make faster, more confident decisions, and the regulatory team isno longer pulled into reporting fire drills.

Change management has also been transformed. Direct linkagebetween products, registrations, and projects means impact assessments arefaster and less dependent on individual knowledge. UDI operations havesimilarly improved: machine-to-machine transmission has reduced manual uploadsand centralized DI record visibility supports global UDI requirements.

The most significant shift is strategic. With centralizedregulatory intelligence and real-time data, Smith & Nephew’s regulatoryteam now actively supports commercial planning: informing budget cycles,guiding renewal and launch sequencing, and advising on regulatory pathways toaccelerate market entry. Regulatory is no longer a downstream compliancefunction. It is a business partner.

Smith & Nephew now runs four modules across its RIM operation:

Registrations— Centralized license tracking across 250 countries and 30+ business units
Change Assessments— Direct product-registration linkage for faster, consistent impact assessments
Executive Reports— Real-time dashboards replacing manual data pulls and board reporting fire drills
UDI— Machine-to-machine transmission reducing manual uploads across global markets

Take this to your team

If you’re evaluating how to modernize RIM operations at scale, the Smith & Nephew case study is a practical reference to share internally. It covers the full implementation story, module breakdown, and results data in a format built for stakeholder conversations.

Download the Case Study

How Philips Scaled Active Product Registrations More Than 20x

Caroline La

May 21, 2026

4 min read

Philips Healthcare operates one of the largest regulatory portfolios in global MedTech: products registered across 250 countries, with a footprint that grows with every acquisition. Before Rimsys, that complexity was managed through email and spreadsheets. Submission packages moved through inboxes with no audit trail, no performance data, and no reliable view of where products were authorized to ship.

Philips selected Rimsys in 2022 as the enterprise RIM platform to bring regulatory order to that complexity. Since go-live, active product registrations have scaled more than 20x, user adoption has doubled in the last six months, and the regulatory affairs function now operates from a single source of truth spanning the entire enterprise.