Big Changes for CFDA in 2016

By Tim Lin

Time To Read 4 minutes

Overview of Change to CFDA Software Regulation

On August 5th 2015, the China Food and Drug Administration (CFDA) announced the release of its “Principle of technical review of medical device software” (2015 Order No. 50)1 . This Principle applies to both stand-alone software and software components which are either developed entirely by the medical device manufacturer or their development partners; including any Off-The Shelf (OTS) software as part of the stand-alone software or component; or are fully adopted Off-The-Shelf software used in the medical device.

This announcement reviews the CFDA’s current thinking and also provides guidance for applicants regarding the required documents for pre-market assessment. It is based on the existing guidance which was published on April 28, 20122 and provides more detail on the requirements, as well as the registration requirements for updated software and revised software.

Major principles included in the Announcement

The updated announcement clearly points out that software safety and effectiveness will be achieved based on the application of risk management, quality assurance, and software lifecycle processes applied during the software development. The essential points of consideration are summarized as follows:

Basic Principle

Software safety classification is categorized into three different classes – Class A, B and C, based on the national standard, YY/T 0664 – Medical device software- Software life cycle process (identical to IEC 62304). Software Descriptive Documentation is required at the time of registration and should include the following elements:

  • Basic Information – necessary items including, software identification; safety classification; architecture and design documents; hardware topology; runtime environment; indication; contraindication; registration history
  • Implementation Process – required items include, development overview; risk management; requirement specifications; lifecycle; verification and validation; defect management; revision history; clinical evaluation
  • Core algorithm

Big Changes for CFDA_2015_V1

 

Software updates

Software updates are a new addition to this announcement. The adoption of national standard, GB/T 20157 – Information Technology – Software maintenance (identical to ISO/IEC 14764), forms the core idea of this rule. Two focal points are stressed:

§   Major software update – Enhanced software update which impacts medical device safety and effectiveness

§   Minor software update –Enhanced or corrective software update which does not impact medical device safety and effectiveness

Major software updates include but are not limited to:

  1. Adaptive maintenance – transferring to a new operation system platform;
  2. Perfective maintenance – change of clinical function, software output, handled task, user behavior, which impacts clinical determination
  3. Others – change of safety classifications architecture, topology, etc.

If it is a major software update, it is necessary to submit the “revision” to CFDA. Software descriptive documentation also requires CFDA review. Minor software updates need to be documented through the quality system, and only need to be reviewed by CFDA at the time of license renewal or modification.

Software Versions

The software version should include revision, build, publishing date, and should be clearly communicated to the CFDA.  Therefore, the naming convention should clearly identify both: (1) the full software version which includes a means to indicate both major and minor software updates, and (2) the published software version –major software updates only.

A clear definition of each code in both the full software version and published software version should be provided at the time of registration. The published software version should also be documented on the user’s manual. The manufacturer needs to apply for a license modification when major software updates occur.

OTS Software

Off the Shelf (OTS) software refers to software either (1) commercially acquired from market, or (2) previously developed by the manufacturer but lacking in development documentations, or (3) outsourced to a supplier to develop.

If OTS software is partially used, the manufacturer should still provide a briefer version of the software descriptive documents.

If the system only uses OTS software acquired from a supplier, the manufacturer should provide copies of the contracts or a declaration of purchase in addition to the software descriptive documents.  If the OTS software has already been approved, a CFDA product license is necessary. If the OTS software was previously developed by the manufacturer but lacking in complete documents to fulfill current requirements, manufacturer should provide supporting evidence such as product licenses or other to demonstrate this OTS software was on the market prior to the date that YY/T 0664 or IEC 62304 was enforced. In addition, the post-market clinical evaluation document is also needed.

Registration Unit and Testing Unit
Registration Unit

For stand-alone software, the consideration principle of grouping into a registration unit includes intended use, device category, and clinical functions. For software components, software registration should be with the associated medical device.

Testing Unit

The Testing Unit describes the representative device when registered. For stand-alone software, every non-compatible operation environment and every independent published software version should be regarded as a sole testing unit. For software components, the testing unit should be with the accompanied medical device.

Registration Requirements

The requirements cover stand-alone software and software components including product name and composition, software descriptive documentations, software version, product technical specifications, clinical evaluations, OTS software and user’s manual. This announcement provides detailed documentation requirements and templates for application.

What we suggest

Many manufacturers are not aware of the changing regulatory environments and requirements across the globe.  This often results in inadequate design or software processes that do not provide for the required software documentation.  In the worst case, it may result in the rejection of an application. The CFDA medical device regulations are getting increasingly more stringent due to the increasing risk for the Chinese population in the event of an adverse event.

The Announcement provides directions covering a wide-spectrum of medical device software.  In order to quickly respond to these revised regulatory requirements, we suggest manufacturers:

  • Implement software development processes that meet regulatory requirements during the product design stage
  • Document all of the software development activities during the development phase
  • Complete software documentation based on regulatory requirements when the design is completed.

 

We also recommend you consult our experts to shorten the time of understanding the new regulatory requirements to reduce the burden of your in-house regulatory affairs team. Well-prepared software documentation driven by robust software lifecycle processes are the key to shorten review timeline for successful market access.

Thank you for reading our article, Please complete the form to download the entire article.

Author

Tim Lin is the senior manager at UL Medical Solutions inthe Greater China Region, and is currently responsible for regulatory affairs and technical documentation consultancy. He was a medical device / IVD reviewer in Center for Drug Evaluation / Taiwan FDA for clinical trial protocols and pre-market evaluation for many years. He can be reached at Tim.Lin@ul.com