Maintaining Compliance Across Every MedTech Product Configuration

This blog was written in collaboration with Daniel Joseph Barry, VP of Product Marketing, Configit.

Imagine a field service engineer updating the software on an imaging system in a hospital. The update is released, but is it valid for this hardware revision, in this region, with the options this customer purchased? Answering these questions should take seconds. For many manufacturers, it can take days of searching across PLM, ERP, sales configurators, and spreadsheets.

Medical device companies operate in an environment where regulatory requirements are evolving alongside increasingly complex products. As devices combine hardware, software, connected capabilities, and AI, manufacturers need to understand not only whether a product meets regulatory requirements, but whether every product configuration offered, delivered, and serviced remains valid and compliant.

This requires accurate, governed, and traceable product data across engineering, quality, regulatory, manufacturing, sales, and service. For manufacturers managing complex product portfolios, maintaining that consistency across systems and throughout the product lifecycle is becoming increasingly important.

Changing regulations challenge medical device manufacturing

Medical device manufacturers must continually adapt their processes and systems to changing regulatory requirements.

In the United States, the FDA’s Quality Management System Regulation (QMSR) took effect on February 2, 2026. It replaces the former Quality System Regulation (QSR) under 21 CFR Part 820, which governs how devices are designed, manufactured, packaged, labeled, stored, installed, and serviced. Rather than maintaining its own framework, the FDA now incorporates ISO 13485:2016 by reference, while keeping specific requirements such as records, labeling, and packaging. The bottom line: procedures, checklists, and documentation built around the old QSR may need an update.

In the European Union, the Medical Device Regulation (EU) 2017/745 (MDR) and the In Vitro Diagnostic Medical Device Regulation (EU) 2017/746 (IVDR) set similar expectations. The technical documentation must describe the variants and configurations of a device that are intended to be made available on the market. The Unique Device Identification system also requires a new UDI-DI whenever a change could lead to misidentification of the device or ambiguity in its traceability. In other words, configuration decisions can have direct regulatory consequences.

These requirements reinforce the importance of consistent processes, reliable product information, and traceability. For manufacturers with highly configurable medical devices, the challenge extends beyond maintaining individual product records. They also need to understand which combinations of hardware, software, features, and options are valid for a particular product, market, or customer requirement, and which combinations are covered by the relevant marketing authorization, whether that is a 510(k) clearance, a PMA approval, or a CE certificate, in each market.

AI adds another dimension to compliance

The introduction of AI into medical devices adds another layer of complexity.

As AI becomes embedded in products and manufacturing processes, organizations need to address AI-related risks alongside established product safety and quality requirements. This makes AI governance a cross-functional responsibility spanning engineering, product safety, quality assurance, cybersecurity, regulatory, and compliance teams.

Regulators are already raising the bar. Under the EU Artificial Intelligence Act, AI in medical devices that require notified-body assessment is classified as high-risk, with added requirements for data governance, technical documentation, logging, and post-market monitoring from August 2, 2028. In the United States, the FDA’s guidance on Predetermined Change Control Plans allows manufacturers to update AI models without a new submission, provided that changes remain within the authorized plan. Both lead to the same configuration question: Which model version runs in which device configuration, and does every change remain within the authorized scope?

Medical device manufacturers already operate in a highly regulated environment. Product conformity, quality management, risk assessments, technical documentation, and validation activities are familiar concepts for engineering and quality teams. AI does not replace these processes. Instead, it adds new requirements to an already complex product and regulatory environment, along with new elements, such as model versions and training data sets, that must be managed and traced as part of each product configuration.

The need for aligned product configuration data

Managing this complexity requires engineering, quality, regulatory, manufacturing, sales, and service teams to work from a consistent understanding of the product.

This becomes difficult when product information and configuration rules are distributed across product lifecycle management (PLM), enterprise resource planning (ERP), and configure-price-quote (CPQ) systems, as well as spreadsheets, sales configurators, and other tools. Engineering may define technical product structures in PLM, while manufacturing, commercial, market, and regulatory constraints are maintained elsewhere. The result: A sales configurator may offer an option that is not authorized in the target market, or a service team may install a software version that was never released for that hardware revision.

PLM remains critical for managing product and engineering information. But for configurable products, important configuration rules and business constraints can extend beyond the PLM environment.

A Configuration Lifecycle Management approach complements existing enterprise systems by consolidating and coordinating configurable product data and rules in a common product model. This establishes a shared source of truth that can be synchronized with critical systems and consumed across the organization.

For medical device manufacturers, this provides a foundation for maintaining consistency as configurations change across hardware, software, markets, and regulatory requirements.

From product data to configuration traceability

Alignment is only one part of the challenge. In a regulated industry, manufacturers also need to understand how individual product configurations have evolved.

A product may change between what was designed, offered, ordered, delivered, and ultimately serviced. Software may be updated. Components may be replaced. New regulatory requirements may affect available options. Understanding this history becomes critical when evaluating the impact of a product change, investigating a complaint, or determining which installed devices are affected by a recall or field safety corrective action.

A Digital Configuration Thread provides lifecycle traceability specifically for configurable products. Product configurations can be captured at different lifecycle stages, creating a record of how a configuration has evolved from design through delivery and service.

By connecting configuration rules and product data across functions, manufacturers gain greater visibility into how and why configurations have changed. This supports change-impact analysis and helps teams identify potentially inconsistent or invalid configurations before they move downstream.

Supporting compliance across the product lifecycle

For MedTech manufacturers, regulatory compliance is not limited to verifying a product once before release. Products, configurations, software, regulations, and customer requirements continue to change throughout the lifecycle.

A shared configuration foundation helps organizations maintain a consistent view of valid product options and rules across existing systems. Configuration traceability adds the historical context needed to understand what was offered, delivered, and subsequently changed.

Historical context also creates an opportunity to optimize the portfolio. By understanding which configurations are actually sold and serviced, and how often, manufacturers can identify what large portfolios often contain: product variants that are no longer sold or configurations that have never been sold at all. Retiring them saves time, resources, and costly warehouse inventory space. It also reduces the regulatory effort involved in maintaining technical documentation, UDI records, and market registrations for variants that customers no longer buy.

Together, these capabilities can provide engineering, quality, regulatory, manufacturing, and service teams with a more reliable foundation for managing product configuration complexity and supporting compliance activities throughout the lifecycle. In practice, PTC Windchill remains the authoritative source for product structures, engineering change, and design records, while Configit Ace manages the configuration rules and constraints that determine which combinations are valid for each market and customer. Configit’s CLM approach is designed to connect product configuration information across engineering, sales, manufacturing, and service without replacing the systems that already manage critical business and product data.

Maintaining compliance as MedTech complexity grows

Medical device manufacturers face increasing product complexity alongside evolving regulatory requirements and the adoption of AI. Managing compliance in this environment requires more than maintaining individual product records. Manufacturers increasingly need to understand which product configurations are valid, how configuration rules have changed, and which configurations have been delivered to customers.

By combining strong product lifecycle management with a Configuration Lifecycle Management approach, manufacturers can establish more consistent product configuration data across systems while maintaining traceability throughout the lifecycle, from the first design review to the last service visit. The question for every MedTech organization is simple: If a regulator, notified body, or customer asked today exactly which configuration was delivered to a specific hospital, and why, how quickly could you answer?