Blogs

Quick reference guide - global medical device UDI requirements and timelines

Bethaney Lentz

February 10, 2025

4 min read

This article was last updated on February 10, 2025.

What is UDI?

UDI systems are intended to benefit healthcare providers, manufacturers, authorized health authorities, hospitals and institutions, and individual consumers by providing:

Faster discovery of possible flawed medical device information by health authorities.

Quicker access to recall information, and visibility into current inventory.

A reduction in medical errors through consistently documented product expiration dates.

Identification of any counterfeit products being used in healthcare facilities.

Assurances that information regarding an implanted device is safely retained and traceable.

UDI timelines and deadlines vary by market, classification risk, and product and have been revised multiple times in some countries*. This article details the UDI deadlines for the countries which have announced specific programs (draft or implemented) and is current as of the date of this article.

*Note: these dates can change as participating countries adjust their plans. We do our best to update this as more information becomes available.
‍

‍Quick Links to country-specific sections:

General UDI labeling requirements

There are two components to a medical device UDI: the UDI device identifier (UDI-DI) and the UDI production identifier (UDI-PI). The UDI is presented as a barcode label (human and machine readable) on device packaging or on the device itself and acts as the access key to all device UDI attributes.

UDI-DI: This is the static portion of the UDI which identifies the manufacturer along with the specific device version. The UDI-DI (device identifier), also known as the Global Trade Item Number (GTIN) is assigned by an approved organization, such as GS1, and contains:

Company prefix
Manufacturers internal product code
Check character

The UDI-DI is the primary identifier to be used in looking up device attributes in country-specific databases and is assigned prior to placing a product on the market. Note that the device identifier is different for different packaging levels of the same device.

UDI-PI: This is the dynamic portion of the UDI which is assigned by the manufacturer and identifies one or more of the following:

Manufacturer’s lot or batch number
Serial number
Manufacturing date
Expiration date
Other attributes as defined by country-specific regulations

The UDI-PI actual values do not appear in country-specific databases (with the exception of the EU vigilance database).

Australia UDI requirements

Australian UDIGuidelines
Reporting Database: AusUDID (pre-production)

The Australian government for medical devices, the TGA, has not launched any official regulations or timeline for mandatory UDI labeling. They do provide a wealth of information on their website that is worth reviewing. In the meantime, however, they are hoping for a Q1 2025 implementation. The AusUDID Pre-Production environment is available for sponsors and manufacturers of medical devices supplied in Australia. It is a test environment that allows testing of data submission, prior to submission to the AusUDID Production environment. Any sponsor or manufacturer with an active TBS account can access the database.

Brazil UDI requirements

ANVISA UDI guidelines
Reporting database:TBD

RDC No. 591/2021 is the regulations guideline for the identification of medical devices regulated by ANVISA, implementing the Unique Identification of Medical Devices (UDI) system. In July 2024, ANVISA finalized amendment RDC No. 884/2024 which implemented various adjustments to RDC 591/2021. The biggest take-away regarding UDI is the extension of one year on the implementation deadlines.

Brazil compliance timeline
Device risk class	Compliance dates (labeling)
Class IV	Jul 2025
Class III	Jan 2026
Class II	Jan 2027
Class I	Jan 2028

Canada UDI requirements

Health Canada website
Reporting Database: N/A
Position paper on the current state of UDI implementation
‍
Medtech Canada strongly supports the global initiative led by regulators under the guidance of the International Medical Devices Regulators Forum (IMDRF), which aims to standardize the identification of medical devices by requiring that certain medical devices carry an internationally recognized UDI. Currently, there is no process in place for UDI in Canada.

China UDI requirements

China (NMPA) website
Reporting Database: China National UDI Database
Announcement No 22 of 2023

On January 1, 2021, the NMPA implemented the UDI system for its first batch of medical devices, including 69 Class III devices. The following year, June 1, 2022, followed the implementation for the second batch of other Class III medical devices (including IVD reagents). Then in 2023, Order No. 22 announced the third batch of products to adopt the UDI system.

As of June 1, 2024, medical devices listed in the third batch implementation product catalog must have already had UDI implemented. According to the degree of risk and regulatory needs, some Class II medical devices in the third batch included high-demand single-use products, items selected for centralized procurement, and medical aesthetic products, totaling 103 types in 15 categories.

China compliance timeline
Device risk class	Compliance date (labeling and registration)
Class III (subgroup)	Jan 2021
Class III (remaining devices)	Jun 2022
Class II	Jun 2024 (estimated)
Class I	Oct 2026 (estimated)

European Union UDI requirements

European Union UDI Information
Reporting Database: EUDAMED
Rimsys Updated EUDAMED Timeline Blog Post

The UDI & Devices module is expected to be declared fully functional by the end of Q2 2025 and mandatory for industry use on January 1, 2026. The EU continues to strongly recommend to the industry to establish its solution and to submit data on a voluntary basis.

European compliance timeline
Device risk class	Compliance date
Class III and Class II implantables	Dec 31, 2027
Class IIa and IIb	May 26, 2023
Class I	May 26, 2025
Class III - reusable	May 26, 2023
Class IIa and IIb - reusable	May 26, 2025
Class I - reusable	May 26, 2027
Class D (IVD)	May 26, 2023
Class B and C (IVD)	May 26, 2025
Class A (IVD)	May 26, 2027

India UDI requirements

Medical Devices Rules, 2017
Legal Metrology Act, 2009

Reporting Database: N/A

Rule 46 of Medical Device Rule 2017 was set to require UDI labeling by January 1, 2022. However, details on how the UDI needs to be implemented have not yet been released but India's labeling and traceability requirements must be met as per CDSCO regulations.

In addition to the Medical Device Rule 2017, the Legal Metrology Act, 2009 focuses on standardizing weights and measures and ensures that packaged commodities, including medical devices, are labeled with accurate and clear information.

Japan UDI requirements

Law to Ensure Quality, Efficacy and Safety of Pharmaceuticals, Medical Device, and Similar Products

Reporting Database: N/A

There are two regulatory authorities responsible for regulation of medical devices in Japan: The Ministry of Health, Labour and Welfare (MHLW) and the Pharmaceuticals and Medical Devices Agency (PMDA). The MHLW is responsible for the administrative actions such as guidance and approval, and judgment on whether or not a product is considered a medical device. The PMDA undertakes product review and post-market safety measures.

As of Dec 2022, bar code labeling based on international standards is required for immediate containers/wrappings/retail packages of medical devices. It is expected for barcodes to be displayed on every medical device in unit of use for patients. Japan was an early promoter of standardized barcodes and is still working towards harmonizing the requirements with global UDI expectations.

The Pharmaceuticals and Medical Devices Act (PMD Act) translates in Japanese meaning "Law to Ensure Quality, Efficacy and Safety of Pharmaceuticals, Medical Devices, and Similar Products," but is often shortened to Act on Pharmaceuticals and Medical Devices or just PMD Act.

Saudi Arabia UDI requirements

Requirements for Unique Device Identification (UDI for Medical Devices)
Reporting Database: Saudi-DI

The SFDA requires compliance with the Unique Device Identification (UDI) regulations on all medical device companies in Saudi Arabia for all classifications. Medical device classifications include: devices, IVD, non-medical IVD, chemical for medical use, distillation device, general lab use, HCT/Ps product and radiation devices.

Saudi Arabia compliance timeline
Device risk class	Compliance dates (labeling and registration)
Class D (high risk)	Sep 1, 2023
Class B & C (medium risk)	Sep 1, 2023
Class A (low risk)	Sep 1, 2024

Singapore UDI requirements

Guidance for UDI Implementation
Reporting Databases: Singapore Medical Device Register (SMDR) - For risk class B or higher, Class A Medical Device Database - Risk class A only

Singapore is now requiring compliance with UDI labeling and database registration. They will accept UDI labels for devices already marketed in the U.S. and the EU without any need for modification. However, if they are not marketed in either country, then they are required to implement via Singapore UDI regulations.

Companies are given an additional 6 months from the compliance date to deplete the respective medical devices that have been imported prior to the compliance date and exist in their current supply chain.

Note:

• UDIs will not be required for medical devices for clinical research, investigational testing or clinical trial and custom-made medical devices

• Medical devices authorized for supply via Special Access Routes (GN26, GN27, GN29) are required to comply with UDI requirement on a risk-calibrated approach

Singapore compliance timeline
Device risk class	Compliance dates (labeling and registration)
High-risk implantable	Nov 2022
Class D, General medical devices and IVDs	Nov 1, 2024
Class C, General medical devices and IVDs	Nov 1, 2026
Class B, General medical devices and IVDs	Nov 1, 2028
Class A, General medical devices and IVDs	Not required, voluntary

South Korea UDI requirements

Act on In Vitro Diagnostic Medical Devices
Act on Medical Devices
Reporting Database: South Korean Integrated Medical Device Information System (IMDIS)

South Korea has already implemented UDI regulations by Article 20-23 of the Medical Device Act (No. 14330) and Article 54-2 of Enforcement Regulations of Medical Device Act (No. 1512).

South Korea compliance timeline
Device risk class	Compliance dates (Labeling and registration)
Class IV (high risk)	Jul 2019
Class III (serious risk)	Jul 2020
Class II (potential risk)	Jul 2021
Class I (lower risk)	Jul 2022

Taiwan UDI requirements

Guidance document from Taiwan FDA
Reporting Database: TUDID

Taiwan has previously implemented UDI regulations, which include labeling and database reporting requirements.

Taiwan compliance timeline
Device risk class	Compliance dates (labeling and registration)
Class III – implantable	Jun 2021
Class III	Jun 2022
Class II	Jun 2023

United States UDI requirements

FDA website for UDI
Reporting database: GUDID database

The United States has previously implemented UDI regulations, which includes labeling and database reporting requirements.

United States compliance timeline
Device risk class	Compliance dates (labeling and registration)
Class III	Sept 24, 2014
Class II	Sept 24, 2016
Class II - reusable	Sept 24, 2018
Class I	Sept 24, 2018
Class I - reusable	Dec 8, 2022

Country-specific UDI databases

Each country has their own UDI database and varying requirements for the data stored in those databases. There is overlap in the data required among the various UDI databases, but each country also has unique data they require.

In addition, countries require that UDI-DI information be provided by “issuing entities.” Note that with the exception of China, all countries accept GS1, HIBCC, and ICCBA as issuing entities.

UDI databases
Country	Database	Data attributes *	Accepted issuing entities
Australia	AusUDID	tbd**	tbd**
Brazil	to be established	21	GS1, HIBCC, ICCBBA
China	CUDID	51	GS1 China, ZIIOT, Ali Health
European Union	EUDAMED	130	GS1, HIBCC, ICCBBA, IFA
Saudi Arabia	Saudi-DI	35	GS1, HIBCC, ICCBBA
Singapore	SMDR	13	GS1, HIBCC, ICCBBA
South Korea	IMDIS UDID	40	GS1, HIBCC, ICCBBA
Taiwan	TUDID	23	GS1, HIBCC, ICCBBA
United States	GUDID	64	GS1, HIBCC, ICCBBA

* Data attributes are approximations based on country UDI requirements and include mandatory, optional, mandatory if applicable, and country database auto generated elements.

** Expected to be similar to US GUDID requirements.

Keeping pace with UDI regulations

Keeping track of country-specific UDI requirements, implementation timelines, and affected devices can be a big challenge to RA teams—especially because the information is scattered across many sources and simply hard to find. In this guide, we have consolidated timeline information and device class requirements across multiple countries. While we make every effort to provide accurate and up to date information, it's always advised to check the government website for the country in question.

Additional UDI resources

Looking for more information? You can visit our EUDAMED resource center, where you will find videos and resources to help you plan for UDI requirements in Europe. In addition, you may enjoy our blog post that outlines our views on the recent EUDAMED timeline updates.

For a broader introduction to UDI, see our Rimsys UDI Overview blog post.

If you're looking for an automated, integrated solution to help you meet changing regulations and manage your global UDI program, request a custom Rimsys demo!

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.

Defining nonconformance

Very simply, a nonconformance occurs when a specification is not met. The FDA defines a specification in 21 CFR 820.3 as “any requirement with which a product, process, service, or other activity must conform,” and ISO 13485:2016 as a “need or expectation that is stated, generally implied, or obligatory.”

While managing nonconformance starts with fully defining specifications; it is the identification, tracking, and resolution of nonconformance that is a focus of medtech quality and regulatory teams and a requirement of both ISO 13485:2016 and the FDA’s 21 CFR Part 820 quality system regulation.

Identifying nonconformance occurrences

As part of a compliant quality system, medical device manufacturers should implement procedures to identify and address both major and minor non-conformances. Nonconformances may be identified through processes found in multiple subsystems that are part of an overall quality management system within the organization.

The systems and subsystems in which nonconformances are identified typically include:

ERP
Regulatory information management (RIM)
Product lifecycle management (PLM)
Document management
Customer service / customer management
Complaint handling
Device history records
Audit management
CAPA
Training/learning management
Calibration/preventative maintenance
Development change management

Evaluating nonconformance

Once a nonconformance is identified, it should be evaluated in a timely manner, and a determination made as to the disposition of any affected products. Requirements for additional investigation and reporting should also be identified. Based on the severity of the nonconformance and its effect on the safety and efficacy of devices being manufactured or already in the market, a CAPA (corrective/preventative action) record may need to be created. In the U.S., this is defined in the quality regulation 21 CFR Part 820.100.

To disposition a nonconformance, consider the following:

Will the existing system detect the nonconformance if it recurs in time for remediation?
How likely is it that this issue will recur?
What is the impact of the non-conformance (i.e., could it affect patient health)?

Issues that are more severe or are more likely to recur should trigger a more immediate and comprehensive response.

Nonconformances that are escalated and handled under CAPA are based on risk and can include those that have or could have an impact on a product or process that is:

Not easily corrected
Recurring
Severe

In addition, nonconformances that rise to the level of a CAPA require significant resources and typically result in a full project to identify root cause(s), containment, and corrective actions, and monitoring for effectiveness.

Nonconformances that don’t require a CAPA have simpler resolutions that include documenting actions taken to correct the issue (or justification for no action). If the issue is not recurring, there may be no other action required. For example, a nonconforming material received from a vendor may be a singular issue that was easily identified through existing inspection procedures and is not expected to recur. In this case, the material is returned to the vendor and no additional action is required.

Processes that are out of conformance are often resolved through improved documentation and/or additional user training. However, be sure that the true root cause of the nonconformance is identified as procedural nonconformances can signal additional issues.

Documenting nonconformances

An important part of nonconformance procedures is the nonconformance report (NCR) or other documentation procedures. Nonconformances are typically documented within the subsystem in which they were identified. Some organizations will have a nonconforming system in which issues originating from all subsystems are documented. Centralized nonconformance systems allow for trending and other analysis across all subsystems, the results of which may generate CAPAs.

The requirements for documenting a nonconformance may vary by subsystem. In general, however, nonconformance documentation records:

The requirement/specification that was not met.
The objective evidence supporting the determination.
The action that is being taken to address the nonconformity.

Nonconformances are a common point of focus during quality audits by regulatory bodies, including the FDA, and should follow a well-documented process. Auditors will often try to determine if the quality system is functioning effectively by looking at self-identified nonconformances and comparing them to externally reported nonconformances. This is to ensure that nonconforming products were not released, or that the appropriate actions were taken to resolve issues in the field.

The importance of nonconformance reports

Nonconformances related to distributed products of higher risk result in nonconformance reports issued to government authorities through vigilance reporting, medical device reporting, and field action/recall reports. For example, the FDA requires that a medical device report be submitted within 30 days of a serious adverse event (see 21 CFR Part 803 Subpart E). Strong reporting procedures for nonconformances of all types are important in identifying trends, addressing issues before they become critical, and as part of a complete quality management system.

A nonconformance reporting procedure is only part of a strong quality system. Read An overview of 21 CFR part 820 and ISO 13485 overview for more information on establishing quality systems for medtech companies.

‍

Why we developed Rimsys from the ground up

Wendy Levine

May 26, 2022

4 min read

Rimsys has had quite a year already! In early December, we closed on $16 million in Series A financing and since then we have been carefully growing the company to better serve our customers and the regulatory affairs community. We have almost doubled our employee count and redesigned the Rimsys system to deliver deeper functionality that is even easier to use. We had our first in-person employee meeting here in Pittsburgh at the end of April where we introduced our new mission statement, and we are all excited to be doing our part to improve global health!

All of these changes made us think back to the founding of Rimsys and how far we have come. So - I sat down with Rimsys Founder and CEO, James Gianoutsos, to talk about the genesis of the company and how he knew that a new type of system designed for medtech regulatory affairs professionals was needed, and needed to be built from the ground up.

Q: What was the biggest challenge you faced as a regulatory professional that led you to form Rimsys?

James: The biggest challenge I saw while working at Philips for many years was completely understanding the complexity and the nuances around everything regulatory from a product standpoint. This really came to light whenever we acquired products. Just seeing firsthand how inefficient and out of compliance these manufacturers really were, and how hard it was from an administrative standpoint just to get into compliance and then to stay compliant, was striking.

I was working with a smaller medical device company which had acquired products from Philips. Philips provided the company with a list (a color-coded Excel spreadsheet) of all of their products that the company had acquired along with the registration status of those products globally. After digging into the spreadsheet for several months, we found that about 50% of it was wrong, incomplete, or just completely missing. The company was trying to keep track of registration information, but the available tools were making it nearly impossible. I realized that this was the challenge, and that there really wasn’t a solution on the market that could solve that problem in an easy manner and in a medtech regulatory-focused way.

‍Q: There were solutions on the market that were geared more towards the pharmaceutical industry, correct?

‍James: Yes. So I did what every other regulatory professional did, which was to Google “regulatory software,” and I saw that there just really wasn’t anything on the market that fit our needs. The solutions on the market really were pharma-specific, even those that said they worked with medical devices. The workflows and regulatory requirements for medtech are very specific for each market, depending on the product type and risk class and so many other factors. To use a pharma system that was already on the market just wasn’t even an option because it was like comparing apples to oranges. It is completely different from the regulatory and workflow side of things.

‍Q: There are existing tools used by the regulatory community, such as quality management and document management systems. Did you envision the new RIM system integrating with existing tools, replacing them, or a little of both?

‍James: I never set out to replace those types of systems, no. In fact, I knew that existing system architecture and infrastructure couldn’t handle the specific medtech regulatory workflows but needed to connect to those systems. There have always been PLM (Product Lifecycle Management) systems that contain a company’s product master data, but those systems were never meant to be workflow-driven based on regulatory requirements. At the same time, they are critical for organizing and maintaining product-specific metadata. Then there are ERP systems, which are really about making sure companies have sales flags (i.e. regulatory blocks) in place, appropriate shipping codes, or selling status linked to product registration status. Regulatory professionals are concerned about answering two questions for ERP users; one, “does the product have a valid and current registration within the country or market,” and two, “if it is registered, are we selling and shipping into that market.” Lastly, quality/document management systems house critical documentation and records needed for registrations. The problem with these systems is that there are no regulatory workflows and no way to compile technical documentation, leaving the documents and records siloed from the regulatory filings.

To do the things that a regulatory affairs professional, in a critical regulatory department, does for their company, the system really had to be built from the ground up with all of these systems in mind. It had to be product-centric. It had to integrate with all these other sources of information, because there really wasn’t a common connection point between your products, your documentation, and the records that you needed to compile and how that relates to getting products on the market. We had no way to communicate to our other systems that a product is actually available for sale in that market or that it confidently can, or more importantly cannot, ship to that market.

‍Q: What was the most difficult piece of functionality to implement in Rimsys?

James: Well, at the time it kind of all seemed difficult! No, really the most difficult part was thinking thoughtfully and strategically about how data was going to be mapped and used in conjunction with other data elements, in order to make the system most helpful from a user perspective. We wanted to single-source information to enhance and streamline regulatory workflows, but then also make sure that it was as user friendly as possible. There are a lot of stakeholders that need information or have input into regulatory workflows. Quality assurance, marketing operations, R&D, engineering, sales - all of those specific stakeholders need to view information in a way that is understandable to them.

We worked hard to bring all that information, streamline complex regulatory workflows, and all of those internal and external data sources together in an understandable and user-friendly way.

Q: How important has the technology itself been in the creation of Rimsys?

James: Technology has been a huge advantage for us from day one. Our team had quality and regulatory backgrounds, so we knew what companies would expect from us. We knew we had to be 21 CFR Part 11 compliant. We knew we had to be ISO 27001 certified. We knew we had to have SOC2 Type 2 reports. We knew we had to integrate with a company’s existing IT infrastructure. We really had to build this thing from the ground up on a GxP compliant platform that we could build upon and expand, without having to go back and reinvent the wheel every time we added new functionality.

It’s continued to pay dividends for us because it was something that we thought about from the beginning and that gave us a lot of flexibility. We already had the system and infrastructure in place that we could then expand upon a lot more quickly than we would have been able to otherwise. It’s like the difference between building a house today and trying to remodel a house that was built in the year 1900. If you break down a wall in the older house, there might be so many hidden issues behind that wall - load bearing issues, knob and tube wiring, asbestos, etc. With new modern infrastructure, it is just night and day in terms of adapting quickly with changing regulations and a fast-paced market.

Q: Was there any specific technology you can talk about that became important to the development of Rimsys?

James: Our choice of technology was driven by our desire to build a system that was user friendly and built on a modern infrastructure that felt familiar to our users. So, we took a lot of the Google framework to build an application that didn’t look like enterprise software, but looked and felt more like a consumer product that is inviting, not overwhelming.

The other thing is that we built the system from day one to integrate because we knew we had to connect with a lot of different sources of information. We strategically built the system with API’s in mind.

Q: What is Rimsys doing differently than other software companies in the regulatory space?

James: We are creating a holistic solution, which is different from what is out there now. We know that registration management is just one key aspect of what regulatory affairs teams need. In order to create a proper regulatory system, we had to take into account all of the data and dependencies and build a system specifically for medtech regulatory teams and other key consumers of regulatory data. There has to be a single source of truth for this data, because otherwise it becomes a nightmare at the end of the day. Existing software solutions were siloed and purpose-built for other industry needs, such as eQMS, PLM and ERP. None of those systems can do what a holistic RIM platform can do. Because of the complex workflows, the regulatory needs are far too broad and interdependent, that data infrastructure is completely different, data sources are too numerous, and the systems offer limited support to bring everyone and everything together into a cohesive, streamlined, compliant and medtech-specific solution.

Another key component of what we are doing is to institutionalize regulatory knowledge and resources into Rimsys—this is at the heart of who we are and what we do. Having the only purpose-built, holistic RIM platform built by and for regulatory professionals specific for the medtech industry really couldn’t be done without internalizing that experience within our own team.

Q: What are you most proud of when it comes to Rimsys?

James: I think there are two things that immediately come to mind. Having our Rimsys 5 platform launch is really exciting. This is the fifth iteration of our platform, and we did it by listening to our customers and iterating over and over again to get it right. We had to go back to the drawing board a couple of times, not because what we had written wasn’t working, but because our customers that were using the system every day gave us better ways to do things. Rimsys 5 is a really proud moment because this is the platform that we are taking into the future, that will let us get to the next level where we are truly empowering regulatory professionals to make critical decisions and do the job that they are meant to do.

The ability for us to listen to our customers, take that feedback and move fast is the second thing I’d mention here. We know that this has to be a validated system, but we are able to make changes and add features in a way that is thoughtful and gets our customers what they need right away. Regulatory professionals are very particular. I know since I am one, and making sure they are comfortable using Rimsys from day 1 is critically important. Being a customer-centric company really makes our experience as a team extremely rewarding.

Q: Where is Rimsys going next? What are you most excited about?

I think I am most excited about Rimsys being an advocate for the medtech regulatory community and helping them wherever we can. Regulatory has a seat at the table now and it is a great feeling to see that we’re able to help these companies to streamline their workflows, accelerate time to delivery for life-saving products and maintain that compliance to keep those products on the market. Regulatory affairs is a mission critical department that the medtech industry cannot underestimate. It’s empowering because while we are helping our customers, they are helping us and every single one of our other customers through the journey of regulatory uncertainty that everyone is going through right now. It feels like a real partnership between us, our customers, and the industry as a whole and I am excited to see where that will take us.

I am also really excited about where we are going with regulatory intelligence. We are just scratching the surface of this now, but you will see regulatory intelligence data built into Rimsys and providing RA professionals with tools that can really provide a competitive advantage for their company. The release of Rimsys 5 platform (“Phase 1”) provides us that platform that will take us into “Phase 2” of Rimsys, with embedded intelligence that will further empower regulatory professionals to make decisive, correct and confident decisions for their products and their company.