Parameterization of Software

The parameterization of software - in this context, we can also talk about customizing or configuring software - often leads to discussion, e.g. regarding responsibilities and the limits of in-house production.

This article gives manufacturers and their customers important advice on what to look out for when parameterizing software and how to avoid the usual pitfalls.

1. Parameterization: examples

a) Examples of activities

A lot of software applications, such as ERP systems and hospital information systems, have to be configured (e.g. “parameterized”) before they can be used in a company. Examples of these adjustments are:

• Defining roles and authorizations
• Creating users and assigning roles
• Defining processes and adapting workflows
• Configuring interfaces
• Adjusting the calculation of scores
• Defining warnings and alarm limits
• Entering database parameters including passwords

b) Examples of typical difficulties

For these activities, the people involved have to agree on the following:

• Who is responsible for the parameterization?
• Is this still a parameterization or is it already an in-house product?
• Is the parameterization done before or after it is placed on the market?
• Do the manufacturer's employees act on the role of a person who manufactures the product or the (additional) role of a service provider who parameterizes the software on behalf of the operator (company)?
• If the software has to be replaced by third-party components or by an in-house solution in order to guarantee the required functionality: Who is responsible for the interaction of the system as a whole? Who is responsible for its conformity?

2. Definitions

The terms parameterization, customizing and configuration are often used synonymously. But they are not always the same thing.

a) Parameterization

_{Fig. 1: Parameterization of a software compared to an extension}

b) Configuration

_{Fig. 3: Customizing includes parameterization, configuration and extensions with special solutions.}

3. Typical pitfalls

Pitfall 1: Unclear agreements

Manufacturers regularly fail to meet their customers’ requirements with a standardized product. Therefore, they are forced to develop a modular system, which means that the software is only created through parameterization, configuration and special solutions, i.e. customization.

Manufacturers and customers thus run the risk of leaving important questions unanswered:

• Product definition
  What is the product that the customer buys or that the manufacturer places on the market? Is the configuration by the customer still part of the software or is it already use of the product within the scope of its intended?
• Medical device?
  Is the product a medical device (in itself) or is it a collection of modules and tools for creating a medical device?
• Marketing versus in-house production
  Is there a medical device manufacturer or is it an in-house development or even both?
• Responsibilities
  Should the development activities performed by the manufacturer's staff be classified as manufacturer developments and thus form part of the delivered product? Or are these activities to be regarded as services performed by the same people on behalf of the customer?

Pitfall 2: Parametrization creates in-house production

If the company assumes the task of parameterizing the software system, it must make sure that it is using the product within the scope of the intended purpose defined by the manufacturer. Otherwise, it is manufacturing its own products and thus assumes the manufacturer’s responsibility for meeting the regulatory requirements.

This distinction is always difficult when the manufacturers do not define the intended purpose clearly. If, for example, the manufacturer provides the product with the option of extending it with scripts: is an algorithm developed in this script language for checking contraindications then covered by the manufacturer's declaration of conformity?

If the product is used within the scope of its functional specification, the Parametrization and configuration fall under what ISO 13485 calls installation. The requirements of
ISO 13485 for the installation should be noted.

Pitfall 3: Update capability is lost

The more standardized a product is (and remains), the easier it is for the manufacturer to develop updates, upgrades and patches for it. Each parameterization, each configuration and each special development increases the complexity and thus the difficulty of developing and testing updates, and having them installed by the customer.

All this increases the effort and therefore the price. A special software solution costs money on a one-off basis. The regression testing of this solution, possibly permanently.

Therefore, operators should consider carefully, if they insist on 'special solutions'.
These do frequently have disadvantages for both parties:

• For the operator, because of their efforts to maintain older versions increase
• For the manufacturer, because their efforts need compensation and they risk having to work with a non-upgradable product with older and less efficient versions.

Pitfall 4: Non-compliance with regulatory requirements

If a manufacturer develops a tailor-made medical device for a customer and there is only one copy of this product, it is still a medical device that has to meet all regulatory requirements. This includes in particular the verification of the basic requirements:

• Software life cycle processes
  Software development does not necessarily have to be limited to the manufacturer's premises - it can also take place at the customer's premises.
• Risk management
  The manufacturer must consider all risks - not just those related to the building blocks. This includes the risks associated with the specific intended purpose, functionalities and architecture of the product.
• Usability
  Particularly if specific or new user interfaces and user scenarios are created by the customizing, these must also undergo a formative or summative usability evaluation. That usually doesn't happen.
• Labeling
  There is no law that states that the requirements, e.g. for the existence and completeness of manuals, do not apply for products sold only once. A manual that only describes how to use the “building blocks” rather than the whole product, probably does not meet the requirements regarding completeness.

The basic requirements – the Mortals about “general safety and performance requirements” – apply for medical devices produced in-house in the same way as for any other medical device.

In addition to these requirements, companies operating software systems should also be aware that they may be obliged to perform a Computerized Systems Validation, as required by, for example, ISO 13485:2016 and described by GAMP 5.

Pitfall 5: Too much flexibility

"Do not be so open-minded that your brains fall out.", is a popular and somewhat cynical Bonmot. 
It applies to the situation of a lot of manufacturers find themselves in. They want to be prepared for all possible situations and customer requirements. Therefore, they postpone as many specifications as possible until later, by making each parameter adjustable.But this flexibility comes back to bite them later on. The number of possible parameter combinations can no longer be controlled. The degree of coverage during testing collapses, and quality problems are literally “pre-programmed”.

4. Conclusion and summary

Products, especially software applications, that can be parameterized within wide limits are characterized by a high degree of flexibility. At the same time, they blur the line between development and adaptation. This brings risks for regulatory compliance and for the safety of patients, users and third parties.

This is another reason why customers such as hospitals should not celebrate it as a victory if they force their manufacturer to come up with another custom solution. This comes at a price, that they will end up paying whether they know it or not.

The less standardized a manufacturer’s product is, the more they are to have to pay attention to the following:

• Exact specification of what the delivered product is
• Precise definition of the intended purpose of the product (and not just its functionality)
• Clarity about where development ends and where the parameterization begins
• Clear understanding between the manufacturer and customer regarding which activities take place within the scope of the development and which are to be understood as a service on behalf of the customer

It is absurd that manufacturers are being forced to develop safe products by ever more stringent regulatory requirements and notified bodies, while at the same time their customers adapt these products to their needs on a large scale, almost unchallenged by regulatory authorities.

Manufacturers should secure themselves from this, by proving, that the product worked according to specifications during delivery. To do this, they must have lawful verifications and validations. This way you cannot be blamed for mistakes made by the operator.   

For patients, it is irrelevant whether the product is unsafe because it was already unsafe when the manufacturer delivered it or because the operator has made the product unsafe through incorrect parameterization.