A Hospital System Just Asked for Your AI Clinical Notes Tool's Post-Market Monitoring Plan Under Article 22: Here's What to Send

A hospital system just asked for your AI clinical notes tool's post-market monitoring plan under Article 22: here's what to send

Your enterprise account manager sent a screenshot of the question at 6 AM. A regional hospital network in the Netherlands — seven hospitals, eleven thousand staff — has your AI clinical documentation tool on a short list of two. Their vendor governance committee is reviewing both options this Friday. The question blocking sign-off is from their clinical informatics lead:

"Please provide your post-market monitoring plan as required under Article 22 of the EU AI Act, including how you detect, record, and report serious incidents."

Article 22 is one of the most operationally demanding requirements in the regulation. Here is what it requires and what you send to unblock the deal.

What Article 22 Actually Requires

Article 22 imposes a post-market monitoring obligation on providers of high-risk AI systems. The obligation has three components.

A post-market monitoring system. You must proactively collect, document, and analyse data on the performance of the AI system in the real-world deployment environment over its entire lifetime. The monitoring system must be described in the technical documentation.

A post-market monitoring plan. The plan documents how the monitoring system operates: what data is collected, how frequently, what performance thresholds trigger review, what the escalation path is, and how findings feed back into the risk management system under Article 9.

Serious incident reporting. If the system causes or contributes to a serious incident — defined in Article 3(49) as an incident that results in death, serious harm to health, or serious damage to property or the environment — you must report it to the relevant national market surveillance authority without undue delay. For non-serious malfunctions that may constitute non-compliance with the EU AI Act, you report to the authority within fifteen working days of becoming aware.

Why This Question Hits Differently in Healthcare

An AI clinical notes tool — whether it summarises physician-patient encounters, extracts structured data from unstructured notes, or generates draft clinical documentation for physician review — typically falls into Annex III, Category 5(a) or (b): AI systems used in health or safety-critical contexts.

The hospital asking this question is not ticking a box. Their clinical risk team and information governance lead have almost certainly reviewed the regulation. They know that a malfunction in your tool — a missed allergy, a wrong medication name carried through into structured data, an incorrect diagnosis code — could affect patient care. They want to know that you have a live, operational process for catching and reporting these events.

What Your Post-Market Monitoring Plan Contains

A plan adequate to answer the question covers:

Performance metrics tracked in production. For a clinical notes tool, this typically includes: accuracy on key clinical entity extraction (medications, dosages, diagnoses, procedures) measured against physician corrections; rates of flagged outputs requiring rework; and any systematic errors identified in physician feedback channels. The plan states the baseline acceptable thresholds for each metric and the review frequency.

Data collection mechanism. How does performance data flow from the deployment environment into your monitoring system? In healthcare this often involves structured physician correction data, audit logs of outputs reviewed and amended, and periodic accuracy audits conducted on de-identified data sets.

Review cadence and responsibility. Who reviews monitoring data, how often, and against what criteria? The plan names the role (e.g. "clinical AI safety lead") and the review interval (e.g. quarterly, with immediate review triggered if any threshold is breached).

Escalation and remediation path. If monitoring reveals a systematic accuracy issue, what happens? The plan describes the internal escalation path, the criteria for issuing a customer safety notice, and the criteria for suspending or withdrawing the system.

Serious incident definition and reporting process. The plan includes a precise definition of what constitutes a serious incident in the context of your tool — not just the statutory definition from Article 3(49), but the operational criteria your clinical safety team uses to triage incoming reports. It also states the notification process: who receives the report internally, who files with the national authority, and within what timeline.

Incident log. Article 22 requires that serious incidents and malfunctions be documented. The plan describes the log format and retention period.

What You Send the Hospital

Send three documents under NDA:

The post-market monitoring plan. This is the primary deliverable. It covers all the elements above. If you have not yet drawn this up as a standalone document — if it currently lives as sections within your technical documentation — extract and formalise it before this deal closes. Enterprise healthcare buyers will not accept a cross-reference to a larger document they cannot review.

Your current incident log or a summary. If you have had zero reportable incidents since launch, say so and provide the log header showing the log exists and is maintained. If you have had incidents, describe what happened, what you reported, and what you changed. Transparency here builds trust.

Your Article 9 risk management output for the clinical notes use case. The post-market monitoring plan and the risk management system under Article 9 are interlinked — Article 22(3) explicitly requires monitoring findings to feed back into the risk management process. Showing the hospital that this loop exists and is operational is the strongest possible answer to their question.

The Shortest Path to Closing This Deal

Clinical informatics leads at hospital networks have reviewed a lot of vendor documentation. They know the difference between a one-page policy statement and an operational monitoring process with real data behind it.

If your monitoring plan is genuinely operational — if you have a live dashboard of production accuracy metrics, a named clinical safety lead, and a tested incident reporting path — say so, share the evidence, and the question closes. If you are building these processes now, say that too: name the components in place, the components in progress, and the expected completion date. What closes deals is precision, not perfection.

Try Complizo free at complizo.com