Turning a consultation into structured clinical codes is not simply a faster way to type the same information. A code can make a statement easier for other software to find, count and act on. The central safety question is whether the coded meaning matches what was actually established, including uncertainty, time and the person concerned.
Start with what the code is asserting
In a fictional consultation, a patient asks whether a persistent cough could be asthma. Their sibling has asthma, and the clinician agrees that further assessment is needed. A coding assistant identifies the word "asthma" and offers a diagnosis code.
Before accepting it, the reviewer needs to determine what the code would mean in that location. Is it recording a family history, a diagnostic possibility, the patient's concern or an established condition? The same keyword cannot safely answer all four questions.
This is not a criticism of any named coding product. It is a constructed example of why concept recognition and clinical assertion are different tasks. A system can correctly recognise the clinical term while representing the encounter incorrectly.
The expected output should therefore be defined before evaluation starts. Asking whether an AI "codes accurately" without specifying the destination, context and acceptance process leaves the most consequential part of the task unclear.
Terminology does not remove the need for context
SNOMED International's guidance on explicit context, checked on 10 October 2026, explains that a condition can refer to a current diagnosis, a family history or a past history, with different implications for record interpretation and population retrieval.
That distinction matters even when the receiving system supplies some context automatically. The organisation should establish which meaning comes from the terminology and which comes from fields such as encounter date, verification status or problem-list location. Displaying a familiar label does not establish that the full meaning survives export.
FHIR R4 also distinguishes clinical condition data and supporting evidence. This provides a technical reference for implementation questions, not a guarantee that two connected systems interpret every field identically.
For clinicians, the practical question is straightforward: what would another person or process reasonably conclude from seeing this entry without the surrounding conversation?
Separate a suggestion from an accepted record change
A proposed coding workflow should show the suggested concept beside the source statement and its intended destination. Accepting a code into a transient encounter field is not necessarily equivalent to adding a persistent problem, and neither should happen invisibly because a note has been approved.
The interface should make clear whether the clinician is approving prose, structured codes or both. An organisation should not assume that a general sign-off action demonstrates deliberate review of every new structured assertion.
For high-impact entries, consider requiring explicit confirmation of the assertion rather than merely the spelling of the term. Examples include whether a condition is confirmed, whether an adverse reaction is actually documented, and whether an event belongs to the patient or a relative.
This is a proposed safeguard, not a recommendation that every minor code needs a separate interruption. The design challenge is to keep consequential changes visible without creating a stream of low-value clicks that obscures them.
Follow the consequences beyond the consultation
Imagine that the fictional asthma code is accepted as an active diagnosis. In a locally configured system, that entry might contribute to a recall list, a future summary or a decision-support prompt. The exact consequences depend on the deployment; they should be mapped rather than assumed.
A subsequent clinician may also treat the structured entry as evidence that an earlier assessment established the diagnosis. Repetition can then make the original uncertainty harder to recover. This is a plausible propagation mechanism, not a measured outcome of the fictional example.
The local safety assessment should identify which codes trigger which processes. A concept that appears harmless in a draft becomes more consequential when it changes a population search or informs an automated action.
The most useful test is not only "Was the right term selected?" It is "Did the accepted entry cause the intended interpretation and nothing materially different at the next stage?"
Reconcile provisional entries when the picture changes
A system also needs a way to revisit information. Further assessment may confirm the initial possibility, establish a different explanation or leave the question unresolved. The record should not accumulate incompatible labels simply because adding a new code is easier than reviewing an earlier one.
A proposed reconciliation process would identify the original assertion, its source, its status and any downstream records relying on it. A clinician can then decide whether it should be updated, qualified or corrected through the authorised record-management process.
This should not become indiscriminate deletion of historical information. An earlier working diagnosis may explain why an investigation occurred, even after it has been superseded. The objective is accurate history and a clear current problem list, not a record that pretends uncertainty never existed.
The distinction between a genuine historical assessment and an entry made in error should remain explicit.
Evaluate clinical meaning, not only code agreement
A local test set should include family history, excluded conditions, suspected conditions, historical problems, patient fears and clinician questions. It should also include statements where the appropriate outcome is no new diagnosis code.
Exact agreement with a reference code can be useful, but the assessment should consider clinically equivalent expressions and the receiving system's requirements. It should not reward a technically precise code that asserts the wrong status.
Assess drafts separately from accepted records, and measure the review and correction work. Include downstream search and export tests where those are part of the deployment. These are proposed evaluation methods, not results from a completed iatroX comparison.
As checked on 10 October 2026, GMC record-keeping standards require clear, accurate and contemporaneous records. Automation should support that purpose rather than redefine accuracy as agreement between two pieces of software.
Use coding disagreements as learning signals
An incorrect code can reveal either a technical mapping problem or an unresolved clinical question. Those should lead to different responses. A mapping defect requires correction in the software or configuration; uncertainty about the diagnosis may require review of the clinical reasoning.
As described by iatroX in October 2026, Ask-iatroX provides source-linked clinical reference. It can support a general learning question about a diagnostic distinction, but it is not a coding authority, a patient-record reconciliation service or permission to upload identifiable records.
The durable principle is that structure should preserve meaning. A code is useful because it enables reliable retrieval and action. That is also why accepting the wrong assertion deserves more attention than correcting a typographical error.
Frequently asked questions
Can an AI select the right clinical term but still create an incorrect record?
Yes. The term may concern a relative, a historical event or an unconfirmed possibility rather than the patient's current diagnosis.
Should approving an AI note automatically approve all suggested codes?
Only within an explicitly assessed workflow that makes the structured changes clear and reviewable. Prose approval should not silently authorise additional clinical assertions.
Does using SNOMED CT guarantee that context is preserved?
No. Correct representation also depends on the information model, local implementation, review and downstream interpretation.