Medics Quality Indicators

Ukraine's national health service ties primary care reimbursement to a set of quality indicators codified by Ministry of Health orders — cancer screenings, cardiovascular risk assessment, TB and HIV screening, age-based preventive exams. A family physician with ~1,800 patients on their declaration list is responsible for hitting these indicators across the entire roster.

The problem is operational. To know which screenings a specific patient still needs, a doctor opens their card in Medics — one of the largest EMRs used in Ukrainian primary care — and manually reviews diagnoses, observations, referrals, and diagnostic reports across multiple collapsed sections. With a 15-minute appointment slot, this isn't done thoroughly. The country-wide outcome is well-documented: low oncology screening coverage, missed cardiovascular risk windows, declining indicator performance year-over-year.

I'm a family physician at a rural Ukrainian outpatient clinic with ~1,800 patients on my list. I saw the same pattern in my own practice: the indicators existed, the EMR contained the data, but bridging the two was manual work that didn't happen consistently.

I built a Chrome extension that runs as an overlay on medics.ua. When a doctor opens a patient card, the extension parses the page contents (diagnoses with ICPC-2 / ICD-10 codes, LOINC observations, referrals, diagnostic reports, interaction actions), runs the data through a rule-based matcher encoding the MoH indicator logic, and surfaces a per-patient status panel: which of 13 indicators are done, overdue, partial, or not started.

The extension covers the following indicators:

• Cardiovascular risk score (full assessment)
• Hypertension management
• Diabetes screening
• Prostate cancer screening (referral + result)
• Colorectal cancer screening (referral + result)
• Breast cancer screening (referral + result)
• TB screening (4-symptom WHO)
• HIV screening
• Preventive exam, age 40-64
• Preventive exam, age 65+

The matcher is deliberately rule-based, not LLM-driven. Indicator logic is regulatory — it has to be auditable, predictable, and explainable. A black-box model would create medico-legal liability. Rules are coded against ICPC-2 / ICD-10 whitelists and LOINC observation codes, so when MoH updates the regulation, only the rule definitions change.

A secondary feature auto-collects text for form 027/о (a standard outpatient summary form), pre-filling structured fields from the chart.

Physicians at the primary care clinic where I practice (a cohort of family doctors managing parallel rosters) used the extension from February 2026 onward. The national health service sends monthly performance reports to outpatient clinics in Excel — these became the verification source.

Over January → April 2026 the cohort showed measurable shifts in oncology screening behavior:

Two observations matter:

First, the lag pattern is clean. February (deployment month) showed early adoption (prostate cancer referrals lifted within the first month). March–April is where most of the cohort-wide gains landed — which matches the realistic timeline of doctors integrating a new tool into routine.

Second, the cardiovascular risk indicator stayed stable. This is a healthcare-product win, not a healthcare-product disaster — it means the tool improved one outcome without regressing established practice. In tools that surface "what's missing", there's a real risk of attention shift away from what's already working. That didn't happen.

The "actual coverage" column is more informative than the referral column. Referral percentage shows what the doctor ordered; coverage shows what patients actually completed. Coverage moves slower (patients have to go to imaging centers, return for results), but it's the metric that matters for population health.

Architecturally the extension separates concerns into:

• parser.js (176 LOC) — DOM selectors for medics.ua's AngularJS-based UI
• data-collector.js (196 LOC) — interaction with collapsible sections, episode toggles
• analyzer.js (898 LOC) — extracted data structured into a patient model
• indicators-rules.js (436 LOC) — declarative rules per indicator (MoH regulation as code)
• indicator-matcher.js (481 LOC) — pure matching logic against the patient model
• ui.js (1,152 LOC) — overlay UI injected into the page

About 30% of the codebase (rules + matcher + helpers, ~1,100 LOC) is platform-agnostic — it would port to a different EMR by writing a new parser. The current design doesn't formalize a PlatformAdapter interface, but the separation is clean enough that adapting to Helsi or EMCi is a known-shape engineering task, not a rewrite. In June 2026 a standalone build reused this core unchanged behind an auth gate — practical confirmation rather than a hypothesis.

• Regulatory logic deserves rule-based code, not AI inference. Black-box models in clinical decision support create liability and break the audit trail. The instinct to "throw an LLM at it" was wrong here. Hand-encoded rules against ICPC-2 codes give us explainability, reproducibility, and a clear update path when regulations change.
• Distribution among doctors works socially, not technically. I never built an install pipeline, an admin panel, or onboarding. Colleagues adopted the tool because they saw it on each other's screen and asked for access. For internal clinical tools, professional curiosity is the channel.
• The most valuable metric was the one the doctors didn't ask for. Referral % is what doctors track. Actual coverage (what patients completed) is what the national health service pays for. Showing both side-by-side reframed the conversation about which indicators matter.
• The adoption story among older physicians surprised me. Most of my colleagues are senior doctors near retirement age. I expected resistance to a Chrome extension layered on top of their EMR. What I got instead was curiosity and active use — the metrics confirm it. Worth remembering when designing tools for clinical users: the demographic stereotype about technology adoption breaks down when the tool removes work rather than adding it.
• Encoding regulatory logic into code was less the bottleneck than choosing the right AI partner. The MoH indicator rules are precisely written — translating them to ICPC-2 whitelists and observation matching was tractable. What took longer was the meta-problem: this was my first AI-native build, and I cycled through several models and prompting approaches before landing on Claude with a task decomposition that fit my mental model. The lesson generalizes: when you're new to AI-assisted development, the tool selection and workflow design is the real curve, not the project itself.

The extension already covers all 13 indicators currently defined for primary care quality reporting in Ukraine, so the core surface is feature-complete. The active work is integration with the TB Module — already shipped through an extended display callback that auto-syncs diagnoses and fluorography results into the TB system. A second direction I'm considering is a parallel module for vaccination tracking, which would follow the same pattern: parse the EMR, surface what's due, sync the result. Whether that ships depends on whether the underlying schema rewards it — vaccination tracking lives in a different part of the EMR with different data shape, and a copy-paste of the indicator logic may not be the right approach.