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.
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:
For these activities, the people involved have to agree on the following:
If the roles and the responsibilities are not clarified, i.e. the above questions are not answered, the legal risks increase both for the manufacturer and for the company. This applies both under civil law (in the event of a dispute between parties) and criminal law (e.g. breaches of the German Medical Devices Act or the German Medical Device Operator Ordinance).
The terms parameterization, customizing and configuration are often used synonymously. But they are not always the same thing.
“Parameterization of software: the adaptation of software to the desired range of functions by setting parameters.”
Source: Johner Institute and others
The parameters are set within the range of functions provided by the manufacturer. However, if the customer (company, hospital) requires additional functionalities, it will need either additional modules (see Configuration below) and/or additional programming.
Either the manufacturer does the programming itself and extends the originally provided range of functions in this way, or the customer or a third party commissioned by the customer does the programming (see Fig. 1).
Fig. 1: Parameterization of a software compared to an extension
Configuration is the process of assembling software from different modules and “linking” these modules. These modules are created by the manufacturer of the software system or by third parties (e.g. plug-ins) or they have been tailor-made.”
Source: Johner Institute
Fig. 2: Configuration of a modular software system
The term configuration has varying definitions. The above mentioned originates from the configuration management. There is no general understanding, as to how broad this term is to be understood:
Customizing includes all of the above actions. It is about adapting the software to the needs of the customer (hence “customizing”), regardless of how this adaptation is performed.
Fig. 3: Customizing includes parameterization, configuration and extensions with special solutions.
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:
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?
Read more on the subject of in-house production here and how it differs from places a product on the market.
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.
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:
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:
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.
Read more on the
Computerized Systems Validation (CSV), the corresponding regulatory requirements and some best practice guides such as IEC 80002-2 and AAMI TIR 36.
"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”.
Parameterization must not be misused to replace systematic requirements engineering.
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:
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.