Country readiness — what each market still needs

One place to see what each market needs before a practice there can run OdonHub as its only system, and which of those pieces is open for someone to pick up (issue #146). Every row links to the issue with the detail. Update this file whenever a country piece lands — the issue that created it went stale within a quarter, which is exactly the failure mode a repo-tracked doc avoids.

The honest summary: OdonHub is complete for Spain and India (GST invoicing), and usable anywhere a practice invoices outside its practice software. Everywhere else one or two country pieces are missing — and they are the pieces a local developer can write far better than we can.

What "ready" means

Three independent axes per market:

1. UI language — the staff-facing interface. Nine languages ship today (en, es, fr, pt, ta, de, hu, pl, it), core and every module layer, with CI-enforced key parity.
2. Invoicing / tax compliance — whatever the tax authority requires of invoices (certification, real-time reporting, document formats). This is per-country by nature and is OdonHub's established plug-in seam: verifactu (Spain) and india_gst (India) are the two reference implementations.
3. Clinical / insurance interop — statutory billing or clinical networks (KZV, SESAM-Vitale, TISS…). Only relevant in some markets, and often gated on a feasibility question about self-hosted software being admitted at all.

Patient-facing communications (email templates, PDFs) render in five languages (es, en, fr, pt, ta) — a market whose language is UI-only still sends patient documents in one of these until its templates are contributed.

Where each market stands

Market	UI	Comms	Invoicing / tax	Clinical / insurance interop	Open issues
Spain	✅ es	✅	✅ verifactu module (AEAT)	n/a	—
India	✅ en + ta	✅	✅ india_gst module (CGST/SGST/IGST, GSTIN checksum, FY numbering; e-invoice is applicability-tracking only)	❓ ABDM voluntary? DPDP audit	#145 (e-invoicing GSP/IRP, DPDP, ABDM)
France	✅ fr	✅	❌ e-invoicing reform (partner platforms, e-reporting)	❓ SESAM-Vitale homologation feasibility	#141, #142
Portugal	✅ pt	✅	❓ AT certification feasibility (ATCUD, QR, SAF-T)	n/a	#140
United States	✅ en	✅	✅ patient invoicing works as-is	❌ CDT coding, X12 837D claims; HIPAA gap analysis	#137
Mexico	✅ es	✅	❌ CFDI stamping through a PAC	n/a	#138
Brazil	✅ pt	✅	❌ NFS-e	❌ TISS	#139
Germany	✅ de	❌	❌ BEMA / GOZ, KZV submission	❓ Telematikinfrastruktur feasibility	#135, #136
Italy	✅ it	❌	❌ FatturaPA / SDI (the verifactu pattern applied to IT)	❌ Sistema Tessera Sanitaria	#133, #134
Poland	✅ pl	❌	❌ KSeF	❌ P1 / EDM	#143
Hungary	✅ hu	❌	❌ NAV Online Számla real-time invoice reporting (no issue yet — open one if you pick this up)	n/a	—
Tamil-speaking markets	✅ ta	✅	see India	see India	—

Legend: ✅ done · ❌ missing, scoped in the linked issue · ❓ open feasibility question — a sourced "no, and here is the rule" is as valuable as an implementation.

Three things worth knowing before you pick one up

1. Several of these are research issues, not coding issues. #136 (Telematikinfrastruktur), #140 (AT certification), #141 (SESAM-Vitale) and #145's ABDM half all start with: can an self-hosted product a practice installs and operates be certified, homologated or admitted at all in that market?
2. The invoicing seam is proven twice. Both verifactu and india_gst are optional, country-gated modules that plug into billing through the BillingComplianceHook — snapshotting compliance data at issue time, own Alembic branch, own settings page. Read docs/modules/india_gst.md and the verifactu module docs before starting a third; the pattern transfers almost mechanically (#133 explicitly asks for "the verifactu pattern applied to IT").
3. UI language is never the blocker anymore. Since the 2026-08 i18n wave, all nine languages cover core + every module layer, and adding a tenth is a translation-only contribution. The remaining language gap is communications (templates/PDFs for de, hu, pl, it) — smaller than a UI sweep and a good first contribution for a native speaker.