feat(eqa-v2): EQA programme registry as deployment config files + CPHL cutover checklist (OGC-935)

[samuelmale]

Summary

Contract item 18 finalisation for CPHL Port Moresby (OGC-935): the programme registry as deployment configuration, plus the cutover instrument that retires the Access-based EQA reporting and Excel-based sample distribution.

A deployment's EQA programme registry (which schemes a lab provides or joins) is implementation data, so it loads from CSV through the existing configuration-initialization framework (ConfigurationInitializationService / DomainConfigurationHandler) instead of being coded into the repository. No liquibase changes.

• EQAProgramConfigurationHandler (domain eqa-programs) — reads CSV from configuration/backend/eqa-programs/ (columns name, description, provider, schemeType, frequency, testSection, active). Rows upsert by programme name: a corrected file re-applies without duplicating, and columns the file does not mention keep their values. An unknown testSection logs and leaves the link empty. The handler commits per row, so a service-rejected row (BR-004: external scheme without a provider) is logged and skipped without marking the whole file's transaction rollback-only.
• docs/eqa/cphl-eqa-programs.csv — CPHL's starting registry: six provider-side REGIONAL_PT programmes, one per ePT-validated test domain (AC-V2.1-23), provider "Central Public Health Laboratory (CPHL), Port Moresby"; confirmed row by row at cutover sign-off. Ships as a docs template (deliberately not on the classpath, which every deployment would load) and is deployed by copying it into the config directory.
• docs/eqa/cphl-cutover.md — the cutover checklist: programme registry with per-row CPHL confirmation boxes, Excel→OpenELIS and Access→OpenELIS mapping tables against the shipped V2.5 screens (FR-V2.5-02/03/12/13/14/15, OGC-933/934), registry loading steps (restart or POST /rest/configuration/domains/reload; checksums re-apply a file only when it changes), a no-historical-migration decision record, and the stakeholder sign-off block.

Testing

• EQAProgramConfigurationHandlerIntegrationTest (3/3): loads the shipped CPHL template through the handler and asserts all six rows (names, scheme type, frequency, per-row section id against an independent catalog query, distinct FHIR UUIDs) plus rerun idempotence; a partial-column update changes only the named columns on the same row; degraded paths behave as documented (unknown section → NULL link, invalid schemeType row skipped, provider-less external row rejected by BR-004, empty schemeType → entity default).
• Live UAT on the dev stack through the real startup path: the framework registered eqa-programs(330) in its handler order and logged Processed 6 EQA programme rows from cphl-eqa-programs.csv; the DB shows 6 rows with 6 distinct FHIR UUIDs — the loader cleanly updated pre-existing rows rather than duplicating them. Board behavior unchanged: after a participant enrollment, the scheme appears on the provider scheme board with its New cycle action.

🤖 Generated with Claude Code