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 differentiation to 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?
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).
2. Definitions
The terms parameterization, customization, and configuration are often used synonymously. But they are not always the same thing.
a) Parameterization
“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).
b) Configuration
“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
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:
- Only unlocking the modules, developed by the manufacturer
- Linking the modules, originating from the manufacturer, in the by them intended way
- Linking the modules, intended by the manufacturer, regardless of origin
- Linking the modules, regardless if intended by the manufacturer
c) Customizing
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.
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 purpose? - 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 takes over 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, takes on 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 (German) here and how it differs from placing 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.
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 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 evidence of fulfilling the general 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 only 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 general requirements – the MDR talks 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 Computerized Systems Validation (CSV), the corresponding regulatory requirements, and some best practice guides such as IEC 80002-2 and AAMI TIR 36.
Pitfall 5: Too much flexibility
Many manufacturers 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.
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.
