Medical coding inside an Irish GP practice is one of those quiet engineering problems that nobody outside healthcare appreciates until they sit beside a practice manager at month-end. The clinician sees a patient, dictates or types a few lines into the EMR, and somewhere downstream a code has to attach itself to that encounter — for the GMS claim, for the chronic disease management programme, for the maternity scheme, for the private insurer, or just for the practice's own audit trail. Get it wrong and you either underclaim (the practice loses money it earned) or overclaim (the practice has a problem with the HSE PCRS). Most practices I talk to are doing this work by hand, in evenings, with a printed crib sheet beside the screen. There is a better way, and it does not involve sending patient data to OpenAI.
Why medical coding is harder than it looks
Coding sounds like a lookup problem. It is not. A GP consultation note is a compressed, idiomatic, often shorthand record of a clinical encounter. "Px BP 142/88, on ramipril 5mg, reviewed bloods, eGFR stable, repeat 6/12, BP diary requested" contains at least three codeable events: a hypertension review, a chronic disease management contact under the structured care programme, and an implicit medication review. None of these are spelled out in a way a regex or a keyword search will catch reliably.
The Irish coding landscape compounds this. ICPC-2 is the standard for primary care. ICD-10 lives in secondary care. The HSE's Chronic Disease Management programme has its own claim categories. The GMS scheme uses item-of-service codes. Private insurers — Laya, VHI, Irish Life Health — each have their own claim forms and code expectations. A single consultation can legitimately produce entries across three or four of these systems, and the mapping between them is not always one-to-one.
On top of that, you have the language problem. Clinicians abbreviate. "SOB" is shortness of breath, not what your spell-checker thinks. "?PE" is a query, not a diagnosis. "T2DM c/o R5" means something specific in the practice that wrote it and possibly nothing in the practice next door. Any coding system that cannot handle local idiom will fail on real notes within a week.
What "AI coding" actually needs to do
When people say medical coding AI, they usually mean one of three things, and it is worth being precise about which.
The first is suggestion: the system reads the consultation note and proposes ICPC-2 codes, with confidence, for the clinician or coder to accept. This is the safest pattern and the one I'd recommend most practices start with. The clinician stays in the loop, the system learns from accepts and rejects, and nothing leaves the practice without a human signoff.
The second is reconciliation: given a note and an existing claim, the system flags discrepancies. Did the clinician document a structured CDM review but the claim only captured the GMS consultation? Did the bloods reviewed today qualify as a separate item? This is where most practices leak revenue, and it is also where audit risk lives.
The third is batch retrospection: running across a quarter or a year of notes to identify systematic under-coding or miscoding. This is less about real-time billing and more about practice-level intelligence — which clinicians are documenting CDM contacts in a way that codes correctly, which patients have likely had a codeable event that was never claimed.
A serious system has to do all three, and it has to do them on the practice's own infrastructure. Patient notes are special category data under GDPR. They do not belong on someone else's GPU.
The on-premise constraint and why it matters
Most cloud-based practice coding tools route notes through a third-party API. Even with a Data Processing Agreement, you have a real problem: the data has left the controller's premises, it has crossed jurisdictions in many cases, and the practice has lost the ability to demonstrate, with technical evidence, that the data did what the DPA said it would.
The Medical Council's guidance on confidentiality and the HSE's own data protection requirements push hard in the direction of minimising third-party processing of identifiable clinical data. The pragmatic answer is to run the model locally — on a box that lives in the practice or in a controlled data centre under the practice's contract — so that the note never leaves a perimeter the practice controls.
This is the architecture I built the Intelligence Brain for medical practices around. The model runs on local hardware. The notes are read, coded, and the suggestions returned, all without anything crossing the practice's network boundary. Audit logs stay local. The DPIA gets shorter. The practice manager can answer the inevitable patient question — "where does my data go?" — with "nowhere".
How the coding pipeline actually works
The pipeline has four stages and they each matter.
Stage one is ingestion. The system reads from the EMR — Socrates, HealthOne, Helix Practice Manager, whatever the practice runs — through whatever export or API the vendor offers. In practice this is often a scheduled pull of consultation notes, problem lists, and prescribing data. The schema varies. A useful coding system has to normalise across vendors so the practice isn't locked into one.
Stage two is segmentation. A consultation note is not one event. It is a sequence of clinical actions, observations, and decisions. Before you code anything you have to chunk the note into codeable units. This is harder than it sounds because clinicians do not write in clean paragraphs. The segmentation step uses a smaller, fine-tuned model that knows what an Irish GP note looks like.
Stage three is candidate generation. For each segment, the system proposes ICPC-2 codes, GMS items, CDM categories, and private insurance line items where relevant. Each candidate carries a confidence score and a citation back to the specific phrase in the note that triggered it. The citation is not optional. A coding suggestion without a "because you wrote X" is not auditable, and an unauditable suggestion is useless when the PCRS comes asking.
Stage four is reconciliation and human review. The candidates are presented to the practice manager or the coder alongside the existing draft claim. Accepts, rejects, and edits feed back into the local model. Over weeks the system learns the practice's idiom — that "Dr K's patients with R5" means a specific cohort, that this practice always codes vaccination encounters in a particular way — without that learning ever leaving the practice.
Where Irish medical billing AI tends to fail
I have seen a few patterns of failure with Irish medical billing AI deployments and they're worth flagging.
The first is the generic-LLM trap. A general-purpose model with a prompt that says "code this note in ICPC-2" will produce plausible-looking output that is wrong in subtle, expensive ways. It will hallucinate codes that don't exist. It will confuse ICPC-2 and ICD-10. It will miss the structured CDM contact because the prompt didn't tell it to look for one. Generic models without domain grounding are not safe for billing.
The second is the over-automation trap. Some vendors pitch fully automatic claim submission. Don't. The clinician or practice manager has to remain the decision-maker on what gets claimed. The AI's job is to make their decision faster and better-informed, not to replace it. Audit liability sits with the practice regardless of what the vendor's marketing says.
The third is the integration trap. A coding system that does not write back to the EMR, or that requires the practice manager to copy-paste between two screens, will be abandoned within a month. The integration with Socrates or HealthOne or whatever the practice uses has to be real and bidirectional, not a CSV export at the end of the week.
What a small practice should actually look at
If you run or manage a GP practice in Ireland and you're thinking about GP coding AI, the questions to ask are practical. Where does the model run? If the answer involves any cloud provider you have not signed a contract with directly, walk away. What does the audit trail look like? You need to be able to show, for any given coded suggestion, the exact text in the note that produced it. How does it integrate with your EMR? A demo on synthetic data tells you nothing — ask for a pilot on your own data, on your own hardware, with a clear exit path. What happens to the model's learning if you cancel? It should stay with you; you paid for it with your data.
The broader pattern here — local model, local data, local audit, human in the loop — is the same one I apply across the Intelligence Brain product line for legal firms, accountants, and other regulated sectors. Medical practices have the strictest data constraints of any vertical I work with, and the architecture has to reflect that from the first line of code, not as an afterthought.
Where to start this week
Pull a quarter of your consultation notes and your matching claims into a spreadsheet. Spend two hours with your practice manager going through fifty random encounters and asking, for each one, whether the claim captured everything the note documents. If you find systematic gaps — and you almost certainly will — that is the business case. From there, the question is not whether to use AI to help with coding, but whose AI, on whose hardware, with what audit trail. Get those three answers right before you sign anything.