Changelog¶

[0.8.0] — 2026-06-01¶

Grassetto sui nomi dei servizi: gt4medServices, gefidServices e grepoServices sono ora sempre in grassetto in tutta la documentazione (100 occorrenze su 13 file). Il testo all'interno dei blocchi di codice è stato escluso dalla modifica.
Diagramma di sequenza: aggiunto link diretto a mermaid.live con il diagramma pre-caricato come fallback, nel caso in cui il rendering inline non funzioni correttamente su Cloudflare Pages.

Rendering elenchi su Cloudflare Pages: aggiunta riga vuota obbligatoria tra paragrafo e lista in 6 file. Python-Markdown (MkDocs) richiede una riga vuota prima di un elenco che segue un paragrafo; GitHub è più tollerante e lo renderizzava correttamente anche senza. Corretti: 01-overview.md, 04-open-questions.md, samples/flusso-a, samples/flusso-c, samples/flusso-d, samples/flusso-e. Build mkdocs build verificato: 0 errori, 0 warning.

Pubblicazione su Cloudflare Pages: ristrutturato il repository per la pubblicazione come sito di documentazione statico navigabile tramite Cloudflare Pages con MkDocs Material.
Aggiunto mkdocs.yml con tema Material, navigazione a tab, supporto Mermaid, syntax highlighting, ricerca in italiano e dark/light mode.
Aggiunto requirements.txt (mkdocs-material>=9.5).
Aggiunto .gitignore per escludere la cartella site/ generata dal build.
Spostati samples/, diagrams/ e changelog/ dentro docs/ per rispettare la convenzione standard MkDocs (docs_dir: docs).
Creato docs/index.md (home del sito, copia di README.md); README.md mantenuto alla root per GitHub.
Corretti tutti i link relativi interni nei file Markdown dopo lo spostamento delle cartelle.
Build mkdocs build verificato in locale: 0 errori, 0 warning.
Configurazione Cloudflare Pages: framework preset MkDocs, build command mkdocs build, output directory site, variabile d'ambiente PYTHON_VERSION=3.11.

Lacuna L12 in docs/04-open-questions.md: strategia di identificazione del paziente e rischio merge anagrafico. Documenta la decisione di usare il codice ospedaliero come identificativo primario (trasmettendo sempre anche il codice fiscale), il rischio di disallineamento master/slave dopo un merge anagrafico, le alternative valutate (solo CF, ID nativo T4MED) e la domanda aperta a TESI su aggiornamento autonomo delle anagrafiche.

Lacuna L10 in docs/04-open-questions.md: ambiguità su DocumentReference.identifier — la spec T4MED richiede il codice fiscale del paziente, ma in FHIR R4 quel campo è il business identifier del documento (UniqueDocumentId). Da chiarire con TESI.
Lacuna L11 in docs/04-open-questions.md: referto sostitutivo (relatesTo.code = "replaces") e annullativo (status = "entered-in-error") non coperti dalla spec T4MED per il Flusso E. Punti aperti da chiarire con TESI prima dell'implementazione.

samples/flusso-e-upload-referto-firmato.md: ristrutturato in due parti:
Parte 1 — Versione conforme alla spec T4MED (identifier = CF): versione minima + versione estesa con metadati completi.
Parte 2 — Versione FHIR R4 standard (identifier = UniqueDocumentId): prima pubblicazione (v1), referto sostitutivo (punto aperto L11), referto annullativo (punto aperto L11).
Aggiunta tabella di versionamento del documento (v1 / sostitutivo / annullativo) con meccanismi FHIR R4 e note sui punti aperti.
Aggiunta deviazione [D03] per la divergenza sull'identifier.
docs/03-api-analysis.md: S13 aggiornato con nota di non conformità FHIR R4 (L10); sezione Flusso E aggiornata con riferimenti a L10 e L11.

docs/05-vincoli-e-eccezioni.md: nuovo capitolo che documenta i vincoli architetturali della prima fase:
Assenza di modifiche a MEDWARE; impossibilità di verifica e correzione manuale del disallineamento da parte degli operatori.
Il referto complessivo (merge MEDWARE + T4MED) è visibile al medico solo dopo la firma digitale: se riscontra un problema ha circa 10 minuti per richiedere l'annullamento. Mitigazione proposta: schedulare la pubblicazione su REPO/FSE a partire dalle 22:00 per dare al medico l'intera giornata lavorativa come finestra di annullamento.
7 scenari eccezionali di deviazione dal flusso nominale (A1, A2, B1, C1, D1, E1, E2) con causa e conseguenza per ciascuno.
Strategia di retry verso T4MED: 3 tentativi, 5 s di intervallo, timeout 60 s per tentativo; nota aperta sull'impatto nei flussi interattivi D/E.
SUMMARY.md e README.md aggiornati con il riferimento al nuovo capitolo.

Flussi A/B/C: introdotto MIRTH come integration engine tra CUP e gt4medServices. Il canale MIRTH riceve il messaggio HL7 OMG^O19 dal CUP, scrive in MEDWARE e chiama gt4medServices per replicare l'operazione su T4MED. In precedenza gt4medServices era descritto come destinatario diretto del messaggio CUP.
Flusso D: chiarito il trigger della firma post-visita. Il flusso parte dal clic sul pulsante "firma" (icona penna) in MEDWARE, che innesca gefidServices. gefidServices chiama gt4medServices per ottenere il referto da T4MED, gt4medServices scarica anche il referto clinico da MEDWARE, esegue il merge dei due PDF e restituisce il documento unito a gefidServices per la firma digitale SINED.
Flusso E: corretto il trigger e l'ordine delle operazioni. grepoServices è un servizio schedulato (ogni ~10 minuti), non innescato da gefidServices. Ad ogni esecuzione pubblica i referti firmati pendenti su REPO e FSE; solo dopo la conferma di pubblicazione chiama gt4medServices per l'upload su T4MED. L'upload su T4MED avviene quindi sempre dopo la pubblicazione su REPO/FSE.
grepoServices: aggiunto come sistema distinto in tutti i documenti (README, overview, architettura, diagramma). In precedenza non era presente.
Diagramma di sequenza Mermaid aggiornato con MIRTH, grepoServices e FSE come partecipanti espliciti; flussi D ed E riscritti con la sequenza corretta.

Rimossi tutti i riferimenti allo stack tecnologico dai file di documentazione.
Tabella sistemi coinvolti aggiornata in README e in 01-overview con MIRTH e grepoServices.

Pre-implementazione. Solo analisi e documentazione. Implementazione di gt4medServices da avviare dopo chiarimento delle lacune con TESI.