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.
The beginner's guide to the FDA 510(k)
This article is an excerpt from The beginner's guide to the 510(k) ebook.
Table of Contents
- Introduction
- 510(k) basics
- Contents of a Traditional 510(k)
- 510(k) submission and timelines
- Other 510(k) forms
Congratulations! You have successfully developed a new medical device. Now you need to take it to market. In the United States, this often means submitting a 510(k). A 510(k) is a structured package of information about your device and its performance and safety that you submit to the Food and Drug Administration (FDA) for “clearance” before you can sell your device in the U.S. In order to receive clearance from the FDA, your 510(k) will need to demonstrate that your medical device is substantially equivalent to another legally marketed device (called a predicate device). The substantial equivalence approval process is a simple equation that looks something like this:
The 510(k) is generally the most efficient route to market clearance in the U.S. because you show your device is safe and effective based on this substantial equivalence standard, instead of needing to present more extensive clinical trial data.
There are three types of 510(k): Traditional, Abbreviated, and Special. This eBook will begin with a general overview of the 510(k) process, including its purpose and benefits. Next, we will explore the Traditional 510(k) and the sections and components required in depth. Finally, we will look at the Special and Abbreviated 510(k).
FDA: background and device oversight
Before we explain what a 510(k) is let’s first talk generally about the FDA and device oversight. The FDA is the U.S. governmental agency responsible for overseeing medical devices, drugs, food, and tobacco products. When it comes to medical devices, the FDA’s mission is to “protect the public health by ensuring the safety, efficacy, and security of…medical devices.” At the same time, the FDA also has an interest in “advancing public health by helping to speed innovations.” In other words, the FDA’s goal is to make sure devices are safe and effective for public use, while also ensuring that devices have a quick and efficient path to market.
In order to achieve this balance of safety and efficiency, the FDA has three different levels of oversight depending on the risk level of the device: (1) exempt from premarket submission, (2) Premarket Notification, also known as 510(k), and (3) Premarket Approval (PMA).
When is a 510(k) required?
A 510(k) is required for medium risk devices that have a predicate on the market which can be used to demonstrate the safety and effectiveness of the new device. Meanwhile, a PMA is required for high-risk or novel devices which require a higher level of scrutiny to be confirmed safe and effective.
A 510(k) is not only required for new devices, but also for devices that have been modified in a way that could impact safety or effectiveness. This could include changes to the:
- Design
- Components
- Materials
- Chemical composition
- Energy source
- Manufacturing process
- Intended use
You must submit your 510(k) at least 90 days before marketing the device.
What Exactly is Substantial Equivalence?
Now that we know what a 510(k) is, let’s talk about the substantial equivalence standard. You’ll recall from the introduction that your 510(k) must show that the new (or modified) device is substantially equivalent to at least one other legally marketed device, called a predicate device. Substantial equivalence looks at the intended use and the technological characteristics of the two devices.
More specifically, you must show:
- that the new device has the same intended use as the predicate, and
- the differences between the two devices do not raise questions about the safety and effectiveness of the new device.
Now let’s take a closer look at intended use and technological characteristics.
Intended use
Intended use means the general purpose or function of the device. The FDA will look at your proposed labelling and your Indications of Use section of the 510(k) to determine the intended use of your device (this is covered in Chapter 2). Intended use includes:
Technological characteristics
Once the FDA has determined that a predicate device exists and that the new device and the predicate device have the same intended use, it will move on to compare the technological characteristics. Technological characteristics include:
- Materials
- Design
- Energy source
- Other device features
The two devices do not have to be identical, and in fact they almost never are. The key here is to demonstrate that any differences do not have a significant impact on safety or effectiveness. Here’s what to cover when you compare your device’s technological characteristics with that of the predicate device:
Overall description of the device design
- Engineering drawings or diagrams to explain the device and component parts.
- List of component parts and explanation of how each component contributes to the overall use and function of the device.
- Physical specifications: dimensions, weight, temperature, tolerances, etc.
Materials
- Detailed chemical formulation used in all materials of constructions (especially those that come into contact with a patient).
- Any additives, coatings, paint, or surface modifications.
- How materials have been processed and what state they’re in.
Energy Sources
- Use of batteries, electricity, etc.
Other technological features
- Software/hardware
- Features
- Density
- Porosity
- Degradation characteristics
- Nature of reagents
- Principle of the assay method
In deciding whether the differences in technological characteristics impact safety or effectiveness, the FDA will typically rely on descriptive information about the technological characteristics as well as non-clinical and clinical performance data.
Let’s look at an example: A manufacturer submits a 510(k) for a new type of contact lens. Both the new device and the predicate device are indicated for daily wear for the treatment of astigmatism. The predicate device is only available in a clear lens, but the new device comes in a line of colors, including purple tinted lenses.
Who is responsible for submitting a 510(k)?
The following four types of organizations may be responsible for submitting a 510(k):
Manufacturers
- End-of-line device manufacturers who will be placing a device on the U.S. market.
- Note: Does not apply to component part manufacturers unless components will be marketed independently.
Specification developers
- Companies that develop the specifications for a finished device which has been manufactured elsewhere
Repackers or relabelers
- Required to submit a 510(k) if they significantly alter the labeling or condition of the device, including modification of manuals, changing the intended use, deleting or adding warnings, contraindications, sterilization status.
- Note: This is rare. The manufacturer, not the repackager or labeler, is typically responsible for the 510(k) submission.
Importers
- Importers that introduce a new device to the U.S. market may need to submit a 510(k), if it hasn’t already been submitted by the manufacturer.
Now that we’ve covered the basics, let’s explore what actually goes into your 510(k).
A Traditional 510(k) should contain all the following components in the list below. In some cases, a particular section may not apply to your device. When that happens, it’s a good idea to include the section anyway and just state “This section does not apply” or “N/A” under that heading.
To continue reading this eBook including a detailed walk-through of all the Traditional 510(k) components, submission requirements and timelines, and an overview of the other 510(k) forms including the Abbreviated 510(k) and the Special 510(k), please register to download the full version
The ultimate guide to the China UDI system and database
This article is an excerpt from The ultimate guide to the China NMPA UDI system and database ebook.
Table of Contents
- Overview
- UDI basics and benefits
- UDI format requirements and issuing entities
- UDI database and submission requirements
- Implementation of UDI and the UDI database in China
The current Chinese medical device regulatory regime kicked-off in 2014 with the Regulation on Supervision and Administration of Medical Devices. This core set of registration requirements, modeled after the United States and European Union systems, established a set of device classifications (class I, II, and III) based on risk and procedures for obtaining market clearance for each type of device.
Medical devices in China are regulated by the National Medical Products Administration (NMPA). Class I devices, such as clinical laboratory equipment or non-invasive skin dressings, require only notification to the NMPA for marketing authorization, and that authorization does not expire. Class II and III devices such as implantable devices or devices with a measuring function require full registration and a formal review before market clearance can be obtained.
These initial regulations have been expanded since their introduction, adding accelerated pathways to market for certain products in certain regions, easing acceptance of clinical data from overseas, and more specific roles and responsibilities for local agents of international manufacturers. In addition, in 2019, the regulations added a provision that medical devices carry a unique device identification (UDI). China’s UDI requirements are similar to those in the US and European Union. They establish specific device ID and labeling requirements, as well as a central, state-administered database of devices.
This eBook walks through the basics of medical device UDIs, the specifics of China’s implementation, and how MedTech companies who market their devices in China can prepare for the full rollout of these regulations in the coming years.
A UDI is a unique alphanumeric code that is designed to identify medical devices sold in a particular country/region from manufacturing, through distribution, to use by a patient. Like other aspects of the medical device regulatory regime, the UDI system in China follows the approach taken by the United States FDA and European Commission, and is based on the guidance from the International Medical Device Regulators Forum (IMDRF). Generally, UDI systems are designed to improve patient safety and optimize care by:
- Increasing the traceability of medical devices, including field safety corrective actions
- Providing an unambiguous identification method for medical devices throughout distribution and use
- Making adverse event reports more accessible
- Reducing medical errors by providing detailed information related to the device
- Simplifying medical device documentation and making it more consistent
There are three components to the UDI system in China:
- UDI code: The actual UDI code can be assigned by one of three (3) issuing agencies and contains information about the product, it’s expiration date, and the manufacturing batch/lot it’s associated with.
- UDI labeling: Put simply, medical devices must carry the UDI code on them. The regulations stipulate how devices and their packaging must be labeled for compliance.
- UDI database: In addition to labeling, all device UDIs must be submitted to a central database that is administered by the NMPA.
The following sections explore each of these components in more detail.
The UDI code
The first element of the UDI system is the code itself. The UDI code is the alphanumeric identifier that is associated with a specific medical device. UDI codes have two (2) elements to them, the UDI device identifier (UDI-DI) or static portion, and the UDI production identifier (UDI-PI) or dynamic portion. You can see the two components in the UDI diagram below:
The UDI-DI contains information about the issuing entity—the organization that is authorized to assign UDI codes. In China, this can be one of three entities: GS1, an international barcode and electronic data interchange standards organization, and two domestic organizations: the Zhongguancun Industry & Information Research Institute (ZIIOT), and AliHealth. Additional details about the issuing agencies are covered in Chapter 2. In addition, the UDI-DI contains information about the manufacturer and the specific model or version of the device.
The UDI-PI contains information about the manufacturing and production of the device. This typically includes information about the lot or batch number in which the device was manufactured, the manufacturing date and expiration date for the device (if applicable), and the specific serial number for the device. Here you can see all of the components marked up using the same UDI example:
Note that each packaging permutation and level for a given device will need to be assigned its own UDI. So for example, let’s say that a company manufactures 5ml enteral (oral) syringes in two packaging options: 1 – packaged individually and 2 – packaged in a box of 5. Each packaging option would need its own UDI, despite the fact that the underlying product is the same.
Now looking at packaging levels, let’s assume that the manufacturer packages the single syringe offering into boxes of 6, and again into larger containers of 24. Each of those packaging options needs its own UDI as well.
Labeling
In addition to obtaining UDI code for each device as outlined in the previous section, medical device manufacturers are required to ensure that devices are appropriately labeled with the assigned UDI. This label is called the UDI Carrier. The UDI is represented in two forms on the UDI Carrier: a machine-readable form and a human-readable form.
The machine-readable form or automatic identification data capture (AIDC) is a barcode or some other technology that can be used to automatically capture UDI information. The NMPA regulations support 3 types of machine-readable formats: 1-dimensional barcode, 2-dimensional barcode, and radio-frequency identification (RFID).
The regulations note that “use of advanced automatic identification and data collection technologies is encouraged”—prompting manufacturers to use more modern 2D and RFID machine-readable carriers where possible. Note, however, that if a device uses RFID, the UDI Carrier must also include the UDI in barcode format.
The human-readable form or human-readable interpretation (HRI) is the numeric or alphanumeric code for the UDI that can be read and manually entered into systems.
The UDI Carrier should be included on the device and on all levels of packaging. The UDI Carrier must be clear and readable during the operation and use of devices. If there isn’t room on the device for both the human and machine-readable forms of the UDI, then manufacturers should prioritize the machine-readable form.
UDI database
The third component of the NMPA UDI system is the UDI database. This is a centralized database of UDI and product information, administered by the NMPA. Manufacturers are required to submit UDI information into the database within 60 days after a product is approved (for sale in China) and before it is commercialized. The database contains a more detailed product record than what is included in the UDI itself, and it is the responsibility of the manufacturer (and/or their in-country representative) to submit the information correctly, and ensure that it’s kept up to date.
Chapter 3 of this eBook goes into detail about the specific fields and data requirements for UDI database submissions.
To continue reading this eBook including information about UDI format requirements and issuing entities, implementation timelines, and affected device types, please register to download the full version.
The ultimate guide to the EU MDR/IVDR unique device identifier (UDI) System
This article is an excerpt from The ultimate guide to the EU MDR/IVDR UDI ebook.
Table of contents
- Overview
- UDI basics and benefits
- UDI format requirements and issuing entities
- UDI rules for specific device types
- Implementation of UDI and UDAMED in the European Union
- US vs EU UDI comparison
The EU Medical Device Regulation (2017/745) (“MDR”) and EU In Vitro Diagnosis Regulation (2017/746) (“IVDR”) introduce two new systems for information exchange: UDI (Unique Device Identifier) for device identification and EUDAMED (European Databank on Medical Devices) to centralize and disseminate information. UDI is a specific code assigned to all devices and higher levels of packaging. This will allow for devices being sold in the European market to be identified and traced through a globally harmonized approach. EUDAMED is the IT system developed by the European Commission to replace the EUDAMED2 database previously in place under the Medical Device Directives (MDD). EUDAMED is a multi-functional system that will be used to coordinate device registration, provide information about devices to industry professionals and the public, and highlight necessary safety details.
The EU MDR and IVDR UDI system is based upon the guidance of the International Medical Device Regulators Forum (IMDRF). It’s a globally harmonized system that’s designed to increase patient safety and optimize care.
UDI system goals
Increase patient safety
- Improve tracing of devices
- Reduce the presence of counterfeit devices
Ensure access to accurate information
- Unambiguous identification of devices throughout distribution and use
Improve post-market surveillance
- Improve accessibility of adverse event reports
Enhance supply chain Management
- Streamline supply chain process and inventory management
- Simplify medical device documentation processes
The UDI system has four key elements
Element 1: Assignment of UDI (UDI Components)
The first element of the UDI system is the assignment of a UDI. The UDI is a code of alphanumeric characters that acts as the access key to information about a specific medical device on the market. The EU MDR and EU IVDR requires that a UDI be assigned to all medical devices except for custom-made or investigational devices. There are three components of a UDI:
- Basic UDI-DI
- UDI (consisting of UDI-DI and UDI-PI)
- Packaging UDI (Note: This is not an official term used in the EU MDR and IVDR, but we’re using it to help explain the concept. The Packing UDI is part of the UDI itself.)
1. Basic UDI-DI
The Basic UDI-DI identifies the device group that a particular device fits into. A device group is a group of products that all share the same intended purpose, risk class, essential design, and manufacturing characteristics. A device group is generally classified by medical device manufacturers as a “Product Family” or “Product Category,” depending on the internal nomenclature used within the company. The Basic UDI-DI functions as a parent or higher-level descriptor of a device.
NOTE: There can only be one Basic UDI-DI per UDI-DI.
The Basic UDI-DI is not printed on the product itself or on the packaging of a product, but rather it must be included in the following documents and applications:
- Certificates (Including Certificate of Free Sale)
- EU Declarations of Conformity
- Techical Documentation
- Summary of Safety and Clinical Performance
2. UDI (UDI-DI and UDI-PI)
The second component is the UDI itself, which consists of two parts:
Device Identifier (DI)
Production Identifier (PI)
The UDI-DI (Device Identifier DI, also referred to as “static”) identifies specific, detailed information about a particular device. If any of the below details should change, the device will need a new UDI-DI.
- Name or trade name of the device
- Device version or model
- If labelled as a single use device
- Packaged as sterile
- Maximum number of uses
- Need for sterilization before use
- Quantity of devices provided in a package
- Critical warnings or contra-indication
- CMR/endocrine disruptors
NOTE: There can be several UDI-DIs for one Basic UDI-DI.
Meanwhile, the UDI-PI (Production Identifier PI, also referred to as "dynamic") contains manufacturing information (including serial number, lot/batch number, software identification, and manufacturing or expiry date or both types of dates.)
To better illustrate this concept of Basic UDI-DI and UDI (UDI-DI and UDI-PI), let’s use a syringe as an example. The Basic UDI-DI would identify the category of a syringe, for example, "Enteral (Oral) Syringe."
A 5ml Enteral (Oral) Syringe – Sterile (Color: Purple) would get a unique UDI-DI and a 10m Enteral (Oral) Syringe – Sterile (Color: Orange) would get a unique UDI-DI. Both products would be associated to the same Basic UDI-DI. In this case, the "Enteral (Oral) Syringe," which defines the category.
Each time that 5ml Enteral (Oral) Syringe – Sterile (Color: Purple) is manufactured at the same revision, it will get a new UDI-PI per lot. See the graphic below.
Each product is identical and therefore has the same UDI-DI. However, the UDI-PI changes to reflect the manufacturing date, lot number, expiry date, and serial number, as applicable.
The UDI will contain all device-specific information and have the same functions as the comparable database (GUDID) of the United States FDA. The main difference (in EUDAMED) is that the UDI data is divided into components of Basic UDI-DI, UDI, and Packaging UDI.
3. Packaging UDI
The third component of UDI is the Packaging UDI. (Note: This is not an official term used in the EU MDR and IVDR, but we’re using it to help explain the concept.)
Each level of packaging, except shipping containers, must receive its own unique UDI. Packaging UDI refers to the unique UDI assigned to higher levels of packaging instead of the device itself.
In the event of significant space constraints on the unit of use packaging, the UDI Carrier may be placed on the next higher packaging level.
Returning to our earlier example of syringes, if a manufacturer first packages a single sellable syringe into an individual box, this package would receive its own UDI-DI and UDI-PI.
If then the manufacturer packages those individual boxes into containers of six (6), those containers would receive their own UDI-DI and UDI-PI.
And finally, if the manufacturer packages those six (6) containers into cases of four (4), those cases would receive their own UDI-DI and UDI-PI.
Each of those levels of packaging must be assigned its own UDI-DI and UDI-PI. The initial syringe did not change, but the way it is packaged did, therefore, requiring its own UDI-DI and UDI-PI.
Element 2: Placing UDI on the device and/or packaging
The second element to the UDI system is the placing of the UDI on the device or on its packaging through what is referred to as a “UDI Carrier.” The UDI Carrier is the part of the label that contains the UDI information that is applied directly to the device or included on the device packaging. The UDI Carrier should have both a machine-readable portion (AIDC) and a human-readable portion (HRI). (Specific details about each element of the UDI will be covered in Chapter 2.)
- Machine-readable form – AIDC – (Automatic Identification and Data Capture) is a barcode or other machine-readable technology that can be accessed automatically by scanning the UDI information.
- Human-readable form – HRI – (Human Readable Interpretation) is the numeric or alphanumeric code, which can be manually entered into the system for access to the UDI information.
If there are space constraints limiting the use of both the AIDC and HRI on the label, then only the AIDC is required to appear. However, on devices that are intended to be used in home-health care or other non-medical facility settings, the HRI would be required to appear.
Single-use devices may contain the UDI Carrier on its lowest level of packaging rather than on the device itself.
Reusable devices must include the UDI Carrier on the device itself, unless any type of direct marking would interfere with the safety or performance of the device, or if it is not technologically feasible to directly mark the device. If so, this should be properly documented in your design history file.
Most importantly, the UDI Carrier must be readable for the intended lifecycle of the device.
Below is an example of a GS1 AIDC and HRI barcode label.
Element 3: Storage of UDI information by Economic Operators
Storage of UDI information by "Economic Operators" is the third element of the UDI system. 2017/745 Articles 2(35), 22(1), and 22(3) define an economic operator as:
- A manufacturer
- An authorized representative
- A distributor
- An importer
- An investigator for clinical investigations
- A person who sterilizes systems or procedure packs
Class III, implantable device:
According to EU MDR 2017/745 Annex II, the manufacturer shall keep an updated list of all UDIs that it has assigned. Economic operators and all health institutions are required to store, preferably by electronic means, the UDI of all the devices for which they have supplied or with which they have been supplied.
For Devices Other than Class III:
Member States are encouraged, and in some cases require, health institutions to store, preferably by electronic means, the UDI of the devices with which they have been supplied. The UDI must also be included in any field safety notice for reporting serious incidents and field safety corrective actions.
The EU MDR and EU IVDR also give the European Commission authority to make additional requirements regarding the submission or maintenance of UDI information. In making those decisions, the European Commission must consider six (6) areas:
- Confidentiality and data protection
- Risk-based approach
- Cost-effectiveness of the additional measures
- The need to avoid duplications in the UDI system
- The needs of the healthcare systems of the member states
- Harmonization with other medical device identification systems
To continue reading this eBook including information about the EUDAMED database, UDI format requirements and issuing entities, implementation timelines, and key differences between the EU and US UDI systems, please register to download the full version
Rimsys Launches the Regulatory Execution Engine for MedTech
Spring 2026 embeds submission authoring, AI-poweredregulatory monitoring, and configurable impact workflows inside a single RIM platform,the first step toward Rimsys’ AI vision for global regulatory operations.
PITTSBURGH, PA, May 5, 2026 –Regulatory Information Management (RIM) software was built to store records.That foundation has served its purpose and reached its limit. Today, Rimsys announces the Spring 2026 release: aplatform designed not to hold regulatory data, but to executeon it.
Submission volumes are growing. Markets are multiplying. Regulatory change is accelerating. Spring 2026 gives regulatory teams the tools to keep pace: embedded authoring, reusable submission content, configurable impact workflows,and AI-powered intelligence, all inside a single platform.
"Our vision for Rimsys is a platform that makes regulatory expertise go further, companies move faster, and products reach more markets than any team could accomplish alone. Spring 2026 is another meaningful step toward that vision. We are embedding the tools and intelligence that allow regulatory affairs professionals to operate at a different level, doing more strategic work, entering markets faster, and staying ahead of regulatory change rather than reacting to it. What we are building next makes this release thestarting line." – James Gianoutsos, CEO
What Spring 2026 Delivers
A brand new website that provides in-depthinformation about the Rimsys offering and the benefits to MedTech manufacturers,including details on these new products:
Intelligence: AI-Powered Regulatory Monitoring
Rimsys Intelligence provides access to regulations, guidance documents, safety alerts, and legislationacross more than 90 countries. AI triage and prioritization surface the updates most relevant to each customer’s specific products and markets, eliminatinghours of manual surveillance and putting the right information in front of theright people.
When a changerequires action, teams can move directly from regulatory signal to impact assessment without a manual handoff. Intelligence represents Rimsys’ firstproduction deployment of context-aware AI operating across a customer’s liveregulatory data, a foundation that will expand significantly in future releases.
Advanced Submissions: A Unified Submission Execution Workflow
Advanced Submissions consolidates everything required to create, manage, and publish a regulatory submission into a single workflow inside Rimsys, eliminating the disconnected tools, manual reformatting, and version fragmentation that have defined submission work for too long. Three capabilities anchor it:
Rimsys Editor
The Rimsys Editor is the cornerstone of Advanced Submissions and the most significant capability in this release. It brings word-compatible authoring and editing natively inside Rimsys, fully compatible with Microsoft Word®, allowing regulatory teams to create, co-author, review, and publish submission content without leaving the platform for the first time.
The Editor supports real-time co-authoring, tracked changes and redlining, rich content including tables and images, document comparison, and PDF publishing with standardized headers, footers, and company branding applied automatically.AI-assisted authoring is available as a configurable option, enabling teams to summarize, refine, expand, and translate content within their workflow. Rimsys AI is human-in-the-loop by design.
Universal Submissions
Universal Submissions enables teams to build from a single universal template (an IMDRF Technical Document) with content automatically mapped into market-specific templates. One master structure, many markets,without rebuilding from scratch.
Reusable Submissions
Reusable Submissions takes a completed submission from one market and uses it as the starting point for a new one. The system automatically maps content into the target market’s template, carrying applicable sections forward reducing the content creation time up to 90% and compressing the time required to enter each additional market.
Configurable Impact Surveys: Governed Change Assessment at Scale
Impact Surveys are now fully configurable. Templates can be defined for specific change event types, tied to countries orregistrations, and triggered automatically from Rimsys Intelligence findings replacing ad hoc assessments with repeatable, governed workflows. This integration creates a direct line from change event toregulatory scope, with results tracked in a single audit-ready trail.
A Platform Built for What’s Next
Spring 2026 establishes more than a set of new capabilities. It establishes the execution infrastructure, structured data model, and embedded AI foundation on which Rimsys’ longer-term vision is being built.
That vision: aworld where regulatory experts are amplified by intelligence, not constrained by information. Where the knowledge required to enter a new market, interpret a regulatory change, or scope a submission is instantly available to every member of the team. Where regulatory operations scale not by spreading experts thin, but by giving them tools that multiply their impact.
Spring is the first production step in that direction. Every submission authored inside the platform, every intelligence signal triaged by AI, and every impact assessment connected to structured regulatory data deepens the foundation. Future releases will build on it directly, expanding AI capabilities, automating more of theregulatory workflow, and ultimately enabling teamsto do work that today requires external expertise to be done inside Rimsys.
Regulatory Execution as a Business Lever
Spring 2026 is built to move metrics that matter: reduced submission cycle time variance,improved approval predictability, lower marginal effort per market, and increased team capacity without proportional headcount growth. For executive leadership, earlier approvals translate directly into faster market access and accelerated revenue recognition.
Availability
Spring 2026 isnow Generally Available. Existing customers on the Organizer product will retain access to their current experience.
To learn more about the Spring 2026 release and how Rimsys can accelerate your regulatory operations, visit rimsys.io or contact your Rimsys representative.
About Rimsys
Rimsys is the heart of regulatory operations for the medical device industry and the platformat the center of an AI-driven transformation in how regulated products reachglobal markets. A living, connected regulatory platform, Rimsys keepsregulatory intelligence, product data, approvals, and change management continuously connected, enabling organizations to expand into global markets with speed, precision, and confidence. Enterprise-ready yet intuitive to use,Rimsys is trusted by 6 of the top 12 global MedTech manufacturers to acceleratetime to market and scale regulatory operations worldwide. To learn more, visit rimsys.io.
Media Contact
letschat@rimsys.io
rimsys.io
The Real Cost of “We’ll Build It Ourselves”
If you are reading this from inside a large MedTech organization, you may be thinking: we have ten times the engineering staff. Why can’t we just build this ourselves?
We-Should-Just-Build-This-Ourse…
It is a fair question.
But software has a well-known paradox. Adding more people to a complex project does not make it go faster. It usually makes it go slower. More coordination. More handoffs. More meetings about meetings. More surface area for misalignment
A large IT organization is optimized for breadth — supporting dozens of systems, managing infrastructure, keeping the lights on across the enterprise
That is valuable work.
But it is fundamentally different from building and sustaining a deep vertical product over a decade.
The people on your team have day jobs. They run devices through regulatory pathways, manage quality systems, support manufacturing, and commercialize products globally
Building a regulated platform is not a side quest.
It is a second company
What the Numbers Actually Look Like
When people compare license fees to internal builds, they stop at the wrong baseline
The real comparison is:
Licensing a specialized platform
versus
Standing up and operating a regulated software company inside your enterprise
Product management.
UX research.
Engineering.
Regulatory SMEs.
Validation and QA.
Security operations.
Compliance programs.
24/7 support.
Infrastructure.
Multi-year modernization
AI makes some of that faster.
It does not make any of it optional
With a specialized vendor, that investment is amortized across an entire customer base.
With an internal build, the full long tail of ownership falls on you
And most of that spend ends up recreating the 80 percent that has already been solved — all because someone decided the remaining 20 percent justified building from scratch
The return on that 20 percent rarely survives honest scrutiny.
The Questions That Should Keep You Honest
It is easy to get excited about how fast something can be built.
The harder exercise is asking what happens in year three, year five, year eight
When your VP of Regulatory Affairs leaves, who maintains validation documentation?
When regulations change across jurisdictions simultaneously, who redesigns workflows and pushes a validated release before the deadline?
When an auditor asks for change control history and disaster recovery test results, who is accountable?
Internal initiatives often stumble not because engineers cannot prototype, but because sustaining them for a decade is brutally hard
Sponsors move on. Budgets change. Teams reorganize.
Regulatory systems do not get to pause.
They must remain inspection-ready through acquisitions, divestitures, and leadership turnover
Systems of record are commitments, not experiments
AI Changed the Tools, Not the Gravity
I am genuinely excited about what AI enables. It will reshape regulatory operations, reduce headcount growth, compress timelines, and raise expectations for every vendor in this space
What it has not done is repeal gravity.
Most of what AI replaces today is busy work. That is enormously valuable. But busy work was never the strategic bottleneck
The hard parts remain.
- Deciding submission strategy.
- Interpreting regulator feedback.
- Designing defensible workflows.
- Staying inspection-ready.
- Running global rollouts
Agents help teams move faster.
They do not decide what is safe, defensible, or durable
In MedTech, software is not just built.
It is designed, governed, operated, and defended
And gravity still applies.
Day Zero Is Easy. Day One Is Where It Gets Hard
There is something I keep coming back to in these conversations.
You can go from idea to prototype incredibly fast right now. That is the day-zero problem, and AI has essentially solved it. You can spit out working code, scaffold an integration, and stand up a proof of concept in a week
But the nuance around an actual business workflow — the day one and beyond activities — those are dramatically harder than day zero ever was
Software engineering done well is craftsmanship.
There is more to it than generating code and turning a prototype into something a regulated enterprise can depend on. It means thinking about edge cases, failure modes, upgrade paths, observability, and long-term operability. It means deleting as much as adding. Simplifying interfaces. Collapsing concepts down to what actually matters
Inside my own teams, I see impressive first versions all the time.
That is not the hard part anymore.
The hard part is everything that comes after
We-Should-Just-Build-This-Ourse…
Faster Engineering Just Pushes Work Somewhere Else
There is a tradeoff that rarely makes it into the first ROI spreadsheet.
AI compresses build cycles. In regulated companies, that speed shows up downstream. More releases mean more validation, more SOP updates, more training, more compliance review, and more audit prep
Engineering gets cheaper.
Governance becomes the constraint
There is also a subtler version of this problem.
Agents make it easy to generate output at scale. More workflows. More automation. More code.
But in regulated environments, every new service or automation path increases surface area. More things to secure. More things to validate. More things to explain to auditors
Speed without discipline creates complexity faster.
For CTOs, that is an architectural concern.
For Regulatory leaders, that is an inspection risk.
Are You Trying to Be a Software Company?
This is the part of these conversations that most often gets skipped.
A MedTech company is not a software shop. Most are largely outsourced IT organizations, and there is nothing wrong with that. The core business is devices, science, R&D, manufacturing quality, clinical programs, and global commercialization
When internal teams talk about building major regulatory platforms, the question is not whether they can spin up a prototype.
It is whether they want to operate a full-time software company inside their enterprise
Building software at scale is a people problem. It is not a technology problem. The constraint is coordination, judgment, institutional knowledge, and sustained focus over years
The people problem does not get fixed by agents and AI.
Regulatory platforms are deeply vertical. They encode jurisdiction-specific rules, regulator expectations, submission templates, QMS integrations, inspection trails, and post-market obligations
That knowledge is earned slowly.
It lives in product decisions, data models, operating procedures, and support playbooks.
AI will reshape how these platforms evolve.
It does not remove the learning curve that created them
AI Agents and the Confidence Shift Inside MedTech IT
In some MedTech IT planning meetings, a new kind of confidence has started to show up.
Not everywhere. Not in every organization. But often enough that it is worth paying attention to.
It is subtle. Casual. The kind that appears when something new begins to feel inevitable
A VP of IT or a CIO sits in a planning meeting. Someone pulls up a demo. An AI agent drafts a regulatory summary, generates a workflow, and scaffolds an integration. It looks impressive. It is impressive
Then someone says it:
Why are we paying for a platform when we could build this ourselves?
I understand the impulse.
SaaS valuations are volatile. Boards are pressing on efficiency. Hiring is under scrutiny everywhere. AI arrives, and suddenly there is a clean story. Automate friction. Avoid headcount growth. Modernize everything
Some of that is real.
I am optimistic about AI. In the right hands, it is a genuine superpower
But hope, cost pressure, aggressive marketing, and very human psychology are colliding right now. That collision is shaping how executives talk about technology strategy
In regulated industries, that matters.
The Confirmation Bias Problem
When leaders already feel pressure to reduce costs or flatten organizations, they naturally gravitate toward stories that validate those instincts. Flashy demos and headlines about agents replacing departments reinforce the belief that a breakthrough must be right around the corner
Once that belief sets in, messy operational details get discounted. Risk gets deferred.
That does not make the technology fake.
It does explain why ambition so often outruns delivery reality
For CTOs and Regulatory leaders, this is the moment to slow the conversation down.
Because prototypes are not platforms.
What AI Actually Changes
Years ago, Harvard Business Review wrote about the “hidden data factory,” the idea that organizations accumulate thousands of small one-off efforts to clean data, reconcile systems, patch workflows, and keep operations moving. No single fix ever justifies a major initiative. In aggregate, it quietly costs millions
That concept maps directly to what AI is good at today.
Inside engineering organizations, we call this work toil.
The repetitive, manual, low-judgment effort that keeps systems running but should not consume the time of highly trained people. Environment setup. Data reconciliation. Migration scripts. Test generation. Documentation drafts. Classification lookups. Compliance artifacts
AI is excellent at eliminating toil. It removes friction, collapses queues, and gives teams back time
In regulated environments, that is meaningful.
But here is the distinction that matters:
Eliminating toil does not eliminate accountability
It does not remove the need for architecture, UX design, validation strategy, regulatory interpretation, or operational ownership.
What it does is allow smaller, more senior teams to focus on the work that actually differentiates platforms.
That is very different than from saying agents replace the platforms themselves
Why MedTech Regulatory Teams Are Delegating EUDAMED to IT
And Why That Creates Bigger Problems Over Time
As EUDAMED implementation accelerates and the UDI/Devices module becomes mandatory in May of 2026, many MedTech companies have made a seemingly practical decision. They hand EUDAMED compliance to IT.
At first glance, the logic feels sound. EUDAMED is a system. It requires integrations, data transmission, and technical connectivity. IT already owns those capabilities, so the project lands there.
But this handoff reveals a deeper misunderstanding of what EUDAMED actually represents. It is a tool that enables manufacturers to meet ongoing regulatory obligations that touch product data, submissions, post-market activities, and lifecycle management. EUDAMED also enables manufacturers’ ACTOR partners like Notified Bodies, Authorized Representatives, Importers, and Distributors to meet their obligations under those EU regulations. Treating it as an isolated, one-time IT project creates risks to EU regulatory compliance that grow and spread across partners over time. MDR/IVDR regulatory compliance cannot be established and maintained with a one-time technical integration.
The first problem with delegating EUDAMED to IT is what it signals internally. It frames the regulation as a single event rather than a continuous program.
EUDAMED is not just about getting data into a database. It requires ongoing updates tied to regulatory changes, product modifications, vigilance activities, certificates, and market status. Every change across the product lifecycle can trigger downstream updates in EUDAMED.
When EUDAMED is positioned as a one-time event, organizations underestimate the scope, effort, and ownership required to maintain compliance over time. That gap does not show up immediately. It appears months later when updates are missed; data falls out of sync, or responsibilities become unclear.
IT teams often take on EUDAMED with the expectation that once the pipes are built, the work is largely done. In reality, the opposite happens.
As regulatory data changes, IT becomes the default escalation point for updates they do not own and cannot validate. They are asked to manage regulatory timelines, interpret data requirements, and support continuous updates that fall outside their core mandate.
This creates friction on both sides. Regulatory teams feel blocked by technical dependencies. IT teams feel burdened by compliance work they were never meant to manage. Over time, updates slow down, workarounds emerge, and risk quietly increases.
The most damaging consequence of delegating EUDAMED to IT is architectural. When EUDAMED operates outside of a centralized Regulatory Information Management system, organizations lose the opportunity to reuse data and reduce burden across the business.
Most of the data required for EUDAMED already exists within product information management and resource planning systems. Product registrations, certificates, submissions, UDI, and post-market data are not new. They are part of the regulatory lifecycle. When EUDAMED is disconnected from RIM, teams are forced to duplicate work, reconcile inconsistencies, and manually manage updates across systems.
Instead of becoming a natural extension of regulatory operations, EUDAMED turns into another silo. One that increases workload rather than streamlining it.
Establishing and maintaining regulatory information in EUDAMED is a regulatory obligation, not a technical one. While IT plays a critical role in enablement and integration, there should be a strong partnership between regulatory and IT (or a third-party submitter), but IT shouldn’t own it completely.
When EUDAMED is managed as part of a centralized RIM approach, organizations gain consistency, traceability, and reuse. Regulatory teams can leverage existing data, control updates at the source, and reduce the ripple effects of change across departments. IT supports the infrastructure, but regulatory owns the process.
This shift also changes how organizations think about compliance. Instead of reacting to EUDAMED as a standalone requirement, they treat it as part of a broader regulatory operating model that supports long-term compliance and growth.
Delegating EUDAMED to IT is rarely a conscious strategy. It is usually a symptom of fragmented regulatory operations and unclear ownership.
As MedTech companies scale globally and regulatory expectations continue to evolve, these handoffs become harder to sustain. EUDAMED exposes the cost of treating regulatory compliance as a series of isolated projects rather than an ongoing operational discipline.
The companies that navigate EUDAMED successfully are not the ones with the most complex integrations. They are the ones that anchor EUDAMED within regulatory operations, supported by centralized RIM systems that establish data consistency and reduce duplication, improve visibility, and spread the burden across the organization in a controlled way.
Agentic AI and the Future of Regulatory Operations
Why Regulatory Operations Is Ready for Agentic AI
Regulatory operations teams are under increasing pressure. Global regulatory complexity is rising, data volumes continue to grow, and teams are expected to move faster, often without additional headcount. At the same time, employee turnover and fragmented systems make it harder to maintain continuity and institutional knowledge.
As outlined in the RIM & AI Maturity in MedTech Executive Guide, many organizations are still operating with scattered regulatory data, reactive processes, and manual workflows. These conditions increase compliance risk and slow growth.
This environment has created the conditions where a more advanced form of AI can deliver meaningful value. That is where agentic AI comes into play, not as a replacement for regulatory expertise, but as a way to strengthen how regulatory operations function day to day.
What Is Agentic AI and Why It Matters
Most AI used in regulatory environments today is assistive. It helps classify documents, extract text, or answer questions when prompted. Agentic AI goes further by operating within defined workflows and processes.
Agentic AI systems can monitor structured regulatory data continuously, identify upcoming risks or deadlines, recommend actions based on rules and historical context, and surface next steps within governed processes. Instead of responding to requests, agentic AI supports execution by working alongside regulatory teams inside their operational systems.
The distinction is important. In regulated environments, value does not come from generative output alone. It comes from intelligence that is embedded, auditable, and aligned with how regulatory work actually gets done.
Moving Regulatory Teams Off the Data Treadmill
The executive guide describes early-stage regulatory teams as being stuck on a back-office data treadmill. Highly skilled professionals spend a disproportionate amount of time searching for information, reconciling spreadsheets, and repeating manual tasks rather than applying their expertise strategically.
Agentic AI helps reduce this burden by continuously organizing and validating regulatory data, identifying missing metadata or inconsistencies early, and reducing reliance on individual memory or tribal knowledge. Over time, this improves not just efficiency, but operational resilience. Teams become less vulnerable to audits, turnover, and last-minute regulatory surprises.
Why Agentic AI Depends on Operational Maturity
One of the most important insights from the paper is that AI value scales with RIM maturity. Advanced AI capabilities are not effective without centralized regulatory information and standardized processes .
At higher maturity levels, AI can surface upcoming risks across markets and renewals, analyze submission history to recommend reusable content, and identify bottlenecks before they impact timelines. At this stage, agentic AI begins to function as an operational partner, helping teams anticipate issues rather than react to them.
This is also where many organizations encounter friction. Skipping foundational steps may create the appearance of progress, but it limits reliability and long-term impact. Agentic AI is only as effective as the data, governance, and workflows it operates within.
From Task Automation to Predictive Compliance
At the most mature stage of regulatory operations, AI becomes fully embedded in daily work. The guide describes this level as one where real-time monitoring, predictive analytics, and continuous improvement are standard practice .
In this environment, agentic AI supports predictive compliance by identifying emerging risks, highlighting resource constraints, and improving visibility across submissions and renewals. These insights allow teams to act earlier and with greater confidence.
The paper is clear on one point. AI enhances regulatory expertise, but it does not replace it. Human judgment remains essential for interpretation, decision-making, and accountability. The real value of agentic AI is that it frees regulatory professionals from low-value work so they can focus on the decisions that matter most .
Regulatory Operations as the Heart of Compliant Growth
The most significant impact of agentic AI is not automation alone. It is the elevation of regulatory operations from a reactive support function to the heart of compliant growth.
Organizations that invest in strong RIM foundations, data governance, and workflow integration are better positioned to apply AI in a way that is safe, scalable, and durable. When implemented thoughtfully, agentic AI helps regulatory operations keep pace with growth, reduce risk, and support faster, more confident decision-making across the business.
