Configuration management is much more than just using version management tools like git or svn. This becomes immediately clear if you look at the IEC 62304 and FDA guidance documents.

Read this article

1. Configuration management, basics

a) What does configuration management include

Configuration management goes beyond version management. It is based on four pillars:

1. Version management
2. Construction management
3. Change management
4. Release management

b) Objectives of configuration management

The need for these four pillars comes from the definition and objectives of configuration management:

To control, manage and document changes in large and complex systems, throughout their entire lifecycle.

This includes ongoing direction and control of adjustments, corrections and expansions. The respective system and all its components should always be in a clearly defined state that can be traced back to its origins. Configuration management is therefore essential for a systematic and always traceable product development process.

c) Objectives of configuration management in medical technology

For medical device manufacturers, the most important goal is to develop safe products that deliver the promised benefits and actually fulfill their intended purpose.

These goals are at risk if manufacturers (particularly of software-based medical devices)

• Providing incorrect artifacts (e.g. own software, third-party libraries)
• confusing artifacts or versions of these artifacts,
• Deliver incomplete artifacts,
• incorrectly assembled software from artifacts,
• they forgot to check and release some of the software,
• accidentally reintroduce errors that have already been corrected
• Configuring products incorrectly (for a given environment, for a particular customer)
• they overlooked the influence of the development, construction, test and production environment on the product and were not informed about the changes (e.g. at the customer),
• because an employee did something (changed code, requested changes, delivered software) that other employees were unaware of,
• etc.

The goal of configuration management is to contribute, manage complexity, and avoid the mistakes mentioned above.

2. Configuration management elements

a) Version management

Version management records and manages changes to so-called configuration elements. This allows you to understand who changed what, when and why.

Examples of configuration elements are

• own source code
• Third party components (SOUP, OTS)
• Platforms
• Tools
• Configuration settings (of products, tools, environments). This also includes build scripts and configuration files.
• Multimedia files (images, videos)
• Instructions for use
• Release notes

Only version management (version management) creates the basis for knowing which artifact became part of which version of the product in which version.

Without a tool, you would have to manage these relationships manually (for example in a table):

Development documents requirements specifications, architectures, and test reports must also be subject to version control. However, they are usually not part of the delivered product.

A software’s runtime environment and build scripts are also subject to document control, but they do not even become part of the product.

b) Construction management

Version management is not yet sufficient to create the product in a reproducible way given the initial artifacts (e.g. source code). For example, the order in which artifacts are processed (e.g. dependencies resolved, compiled, generated, assembled) can play a role.

The goal of construction management is to produce products in a reproducible, complete and error-free manner.

With thousands, tens of thousands, and more of complex artifacts and “production processes,” companies have no choice but to automate these processes. Build management tools (here’s a list) and continuous integration tools are cutting edge.

Published configurations are releases, sometimes called versions.

c) Change management (focus: changes to products, not to organizations)

Often it is environmental requirements that cause changes: errors must be corrected, function must be redefined, a new technical environment requires adjustments. Change management includes documented(!) decisions about whether and how new releases will be created in response to those challenges. The goal is to control the management of a system’s new and changing requirements, as well as troubleshooting requests.

Change management includes the process or processes for the purpose of

• document modification requests,
• evaluate change requests,
• decide on measures (e.g. report to the authorities, change the product, do nothing, training)
• approve the changes,
• monitor the implementation of changes

Some companies have established a change control board to evaluate and approve changes.

If this committee decides not only whether but also when a change can be made and released, it also has sovereignty over the management of the release.

d) Release management

Release management is the process by which software is made available. Determines which version (release) of a product incorporates which configuration changes. Decisions in this regard are influenced by:

• the importance of change for patient safety
• Laws such as the Medical Device Safety Plan Ordinance (MPSV), which establishes specific deadlines
• Urgency of change from the customer’s perspective
• availability of people who can implement change,
• Dependencies between configuration changes

e) Phase

Although version control systems are the most important and most widely used tool in configuration management, configuration management encompasses much more than simple version management.

3. Regulatory requirements

a) CEI EN 62304

IEC 62304 (“Medical Device Software – Software Lifecycle Processes”) explicitly requires configuration management. Its planning must already be part of the development plan. Manufacturers must specify

• which artifacts or types of artifacts should be subject to version control,
• what activities are necessary in this regard,
• who (in the company) is responsible for it,
• when artifacts need to be placed under configuration control (necessarily before verification) e
• how all this should also happen with software maintenance and troubleshooting.

According to IEC 62304, the software configuration management process includes exactly the above-mentioned aspects of configuration management such as

• Change evaluation (→ Change management)
• Decision on measures (→ change management)
• Releasing Changes (→ Change Management)
• Configuration history (→ version management)

Specifically in the standard, the requirement for configuration control is also explicit for SOUPs and for verification that planned changes have been successfully implemented.

b) ISO 13485

ISO 13485 (“Medical devices – Quality management systems – Requirements for regulatory purposes”) does not require explicit configuration management. However, he sees it as a means of ensuring identification and traceability.

c) FDA

The FDA also requires a configuration management plan in the “Software Validation Guidance Document”:

“A configuration management plan should be developed […] Controls are necessary to ensure positive and correct correspondence between all approved versions of the specification documents, source code, object code, and test suites that make up a software system. Controls should also ensure accurate identification of and access to currently approved versions.”

d) Further information

Mapping to IEEE 828:2012

A little more comprehensively (and perhaps a little more academically), IEEE 828:2012 defines the subprocesses of configuration management as follows:

• Configuration identification (CI) → one part is version management
• Configuration Change Control (CCC) → Change Management
• Configuration State Accounting (CSA) → Release Report zB, DHF usw.
• Configuration Control (CA) → Analytical Quality Assurance.
• Configuration Release Management (CoRM) → corresponds to the illustration above 1:1

IEEE 828:2012 and construction management

According to the standard, construction management extends to all CM disciplines. For example, build scripts must be identified as CI. Of course they are under CCC and records of the versions that belong to a version or are currently valid (CSA) are kept.

Changes to build scripts must be verified (CA) and the build script to be used for a release must be available for the same (CoRM).

4. Most common configuration management mistakes

The following issues regularly emerge during audits

• Not all artifacts are under version control
• The development and test environment is not under version control
• The trial key and product key cannot be reset to match each other for specific times and versions.
• The manufacturer did not think about validating the instruments.
• There is no reason why the requested changes will not be implemented.
• There is no explicit modification version.
• Only the latest version of the software before release is “registered”.
• There is no evidence that the changes made actually meet the requirement.
• The manufacturer does not test the delivered version.

5. Conclusion and summary

Configuration management is a prerequisite for developing professional, cutting-edge software.

Countless tools automate steps and avoid errors that regularly occur in manual tasks.

However, the tools are not a substitute for a strategy to release software in line with the market and fix errors quickly and effectively.

Change the history

• 2024-10-17: Headings numbered and added, order changed in chapters 1 and 4, chapter 5 added.
• 2016-08-03: The first version of the article published

Similar posts