Shortcomings of the AIVG when procuring medical software

Healthcare spending is set to rise from 118 to 124 billion euros, according to the Budget Memorandum (Dutch: Miljoenennota). The Dutch government is already committing hundreds of millions next year to data exchange, digital infrastructure and research. The Netherlands aims to have Europe's strongest Med-Tech ecosystem by 2035. In addition, AI is expected to reduce administrative burdens in healthcare. Cybersecurity is also high on the agenda, with digital resilience now extending to the availability of medical devices.

These ambitions ultimately land with healthcare providers, who are responsible for implementation. A key pillar in this process is the procurement of medical software. Combined with the rise of AI, this brings challenges that need to be addressed not only through legislation but also in contracts. The healthcare sector uses the General Procurement Conditions for Healthcare 2022 (AIVG).

These current procurement conditions largely lack such contractual arrangements. This creates a contractual gap: there are no specific agreements on who is responsible when things go wrong. Regulatory requirements keep increasing and the ministry's ambitions keep growing, but when an incident occurs, the healthcare provider is left contractually empty-handed. What helps when procuring medical software safely? An addendum to the standard procurement conditions with concrete suggestions for amendments and additions. This allows healthcare organisations to keep pace with rapidly evolving legislation and cover risks contractually.

Procurement conditions in contracting

The healthcare sector uses the AIVG, supplemented by an ICT Module for medical software. However, these procurement conditions do not align with relevant upcoming (or already applicable) regulations on medical software. With the (phased) entry into force of the MDR, AI Act, EHDS and NIS2/Cbw, various new requirements have been introduced. These have not yet been incorporated.

This is not just a missed opportunity, but a concrete risk. The MDR, AI Act and NIS2/Cbw apply directly: a supplier must comply with them by law. But the law does not automatically determine what you as a healthcare organisation can enforce contractually when things go wrong. Without explicit agreements in your contract, you are left empty-handed in the event of an incident, even if the supplier should have acted differently under the law.

Below, we offer an initial starting point. With these additions and amendments to your contracts, you translate statutory requirements into concrete provisions.

1. The absence of MDR and AI Act provisions

The AIVG and ICT Module lack provisions on medical software that qualifies as a medical device under the MDR, and on AI systems under the AI Act. Medical devices are defined in the AIVG, but specific provisions on the MDR are entirely absent.The AI Act is not reflected in the procurement conditions at all.

Including provisions in the AIVG and ICT Module is therefore essential. This requires elaboration in the ICT Module: how do you handle medical software and how do you incorporate the relevant MDR requirements? The AI Act also deserves a central role in the AIVG. This is particularly important because a medical device combined with the AI Act qualifies as a high-risk system. High-risk systems are subject to stricter requirements that healthcare organisations should be alert to when procuring.

2. An expansion of liability

Product liability deserves a more prominent place in the procurement conditions. Implementation of the European Product Liability Directive into national law is required by December 2026.

Software and AI will fall within the scope of this directive. Healthcare organisations therefore face greater risk when a defect arises in software or AI. The scope of application is becoming broader. Producer liability is also wider and the burden of proof for claimants is lighter. Clear agreements on this belong in the AIVG, again with elaboration in the ICT Module.

3. The interplay of three regulations

The EHDS requirements on interoperability and common specifications apply to medical software that forms part of an EHR system. In this blog, we have already discussed in more detail the practical implications of the EHDS for your EHR system, and it is therefore important to include at least a provision that provides clarity on the requirements, responsibilities and risks arising from this.

Sometimes medical software falls simultaneously under the MDR, the AI Act and the EHDS.^[9] Consider, for example, a medical device within the EHR that uses AI to assist healthcare professionals in making a diagnosis or providing treatment recommendations. In such cases, you need to account for the interplay of three regulations that the software must comply with. All the more reason to set this out properly in your contracts.

4. Liability in the supply chain

For the procurement of medical software, the security of network and information systems in the supply chain is relevant. This duty of care applies to healthcare organisations and affects liability. The current procurement conditions do not yet address this. It is important to make supplementary agreements with suppliers now. An addition to the AIVG and ICT Module on the supply chain is also desirable here.

A general roadmap

We hope the additions outlined above will soon be reflected in the AIVG. Until then, it is wise to follow a general roadmap. This helps you avoid unnecessary risks amid rapidly changing laws and regulations:

1. Take stock of your current contracts.
2. Carry out a check before procuring the relevant medical software.
3. Review whether your insurance covers the new legislation.
4. Determine internally which provisions you want to include.
5. Design standard provisions that you can reuse.
6. Include these in your requirements package with an RFI/RFP for future contracts.

No need to wait for the AIVG or ICT Module to be updated. You can start today. Have questions? We're here to help you move forward.