AI clinical coding automation: regulatory map and controls

The system reads discharge summaries, operative notes, pathology reports and other clinical documentation, then assigns standardised codes (ICD-10-CM, ICD-11, SNOMED CT, OPCS-4 in the UK, CCAM in France). The codes feed billing, case-mix grouping (DRG), quality registries, mortality statistics and research datasets. A coder reviews the AI suggestions, accepts or adjusts them and finalises the record.

The AI is an assistive tool. It does not diagnose, treat or determine clinical care. That distinction is what keeps most deployments out of MDR and SaMD territory.

Regulation (EU) 2017/745 (MDR) Article 2(1) defines a medical device as software intended by the manufacturer for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. Pure billing and statistical coding does not satisfy the intended-purpose test. MDCG 2019-11 guidance on the qualification and classification of software confirms that administrative software is outside MDR scope [2].

The boundary is intent. A coding tool that adds clinical-decision-support features (suggesting differential diagnoses, flagging missed conditions for treatment) crosses into MDR. A tool that strictly maps documented diagnoses to codes does not. Documenting the intended purpose narrowly matters.

The FDA framework follows the IMDRF SaMD definition: software intended for one or more medical purposes, performing those purposes without being part of a hardware medical device. Pure billing and administrative software is outside SaMD scope, mirroring the EU position [3].

US health systems should still document the intended-purpose statement and ensure marketing materials do not drift into clinical claims. SaMD classification turns on what the software is intended to do; ambiguous documentation creates regulatory exposure that the underlying technology does not.

Health data is special category under Article 9. Processing requires both an Article 6 lawful basis and an Article 9 condition. For healthcare provision and management of services, Article 9(2)(h) is the typical basis, supplemented by Member State law on health data. National derogations under Article 9(4) and the European Health Data Space Regulation add further conditions [4].

Coding AI typically processes the clinical narrative inside the hospital's existing legal basis for healthcare provision. The new layer is usually the AI vendor as processor, which requires an Article 28 data-processing agreement with appropriate technical and organisational measures, and (under DORA-equivalent and ENISA guidance) substantive security controls.

The AI Act's high-risk classification for healthcare is driven primarily by Article 6(1), which makes AI systems that are themselves safety components of products covered by EU harmonisation legislation (including MDR) high-risk. Pure billing-and-coding AI outside MDR scope therefore does not trigger Article 6(1).

Annex III contains no specific entry for clinical coding. Limited-risk transparency obligations under Article 50 apply if patients interact with the AI directly, but most coding tools sit between clinicians and back-office systems and never face patients.

Five elements. Narrow intended-purpose statement keeping the tool out of MDR and SaMD scope. Article 28 data-processing agreement with the vendor including audit rights and Article 32 security measures. Mandatory coder review with documented override and audit log. Performance monitoring against gold-standard human-coded samples on a periodic basis. ENISA-aligned security controls including pseudonymisation where feasible and encryption in transit and at rest.