Changelog¶

[1.6.7] — 2026-07-17¶

Le voci di changelog [1.5.0] e [1.6.0] sono state rimosse: le modifiche ivi descritte sono state sostituite dalle decisioni espresse in questa versione [1.6.7]. Le versioni [1.6.1], [1.6.2], [1.6.3], [1.6.4], [1.6.5] e [1.6.6], pubblicate lo stesso giorno, sono state inoltre accorpate in questa voce su richiesta: rappresentano incrementi successivi dello stesso lavoro di consolidamento, non decisioni indipendenti. Le versioni [1.6.4], [1.6.5], [1.6.6] e [1.6.7] hanno introdotto esclusivamente modifiche di nomenclatura e consolidamento documentale interni, che non comportano alcuna aggiunta di informazione né alcun impatto sulle procedure di integrazione lato T4MED.

La versione 1.6.7 non introduce nuovi elementi funzionali rispetto alle decisioni già assunte nel corso delle revisioni del 17/07/2026. Le modifiche hanno carattere esclusivamente documentale e di consolidamento, senza alcun impatto sui flussi FHIR, sui messaggi scambiati o sul comportamento applicativo.

Decisioni consolidate¶

Revisione del modello degli identificativi T4MED

Definito in modo definitivo il modello degli identificativi utilizzati tra SINED e T4MED. Ogni pubblicazione documentale è identificata da tre identificativi distinti:

UniqueDocumentId: identificativo documentale assegnato da SINED (business identifier), trasmesso in DocumentReference.identifier.
T4MedDocumentId: identificativo della risorsa FHIR DocumentReference, assegnato da T4MED e restituito nella Bundle.entry.response.location. Non deve mai essere derivato o calcolato dallo UniqueDocumentId, ma sempre acquisito dalla response e memorizzato esplicitamente.
T4MedBinaryId: identificativo della risorsa FHIR Binary contenente il PDF, assegnato da T4MED e restituito nella Bundle.entry.response.location.

Per i documenti sostitutivi viene inoltre introdotto il ParentT4MedDocumentId, corrispondente al T4MedDocumentId della versione sostituita e utilizzato in relatesTo.target.reference (unico campo usato per il riferimento: target.identifier non viene valorizzato, essendo opzionale in FHIR R4 e ridondante).

Codici Azione SINED

Uniformata la nomenclatura interna delle operazioni documentali con quella già adottata per le prenotazioni:

Precedente	Nuovo	Significato
`T02`	`NWD`	New Document (prima pubblicazione)
`T10`	`RPD`	Replace Document (pubblicazione sostitutiva)
`T11`	`CAD`	Cancel Document (annullamento)
`UPD`	`UPM`	Update Metadata (aggiornamento dei metadati)

I Codici Azione SINED costituiscono esclusivamente una classificazione interna utilizzata da SINED nella documentazione e nell'implementazione applicativa. Sono esclusivamente interni a SINED e non vengono trasmessi a T4MED: non producono alcun effetto sui flussi FHIR, sugli endpoint, sui verbi HTTP o sul contenuto dei messaggi scambiati tra SINED e T4MED. Un'ipotesi di estensione FHIR document-action per rappresentarli esplicitamente era stata valutata e non è stata mantenuta.

Chiarimenti sul ciclo di vita documentale

Le operazioni documentali sono riconducibili a due soli modelli operativi:

Operazione (codifica interna)	Metodo HTTP	Effetto
`NWD`	`POST` Bundle transaction	Crea un nuovo `Binary` e una nuova `DocumentReference`.
`RPD`	`POST` Bundle transaction	Crea un nuovo `Binary` e una nuova `DocumentReference` sostitutiva.
`CAD`	`PUT DocumentReference/{T4MedDocumentId}`	Aggiorna la `DocumentReference` esistente senza creare nuove risorse.
`UPM`	`PUT DocumentReference/{T4MedDocumentId}`	Aggiorna i soli metadati della `DocumentReference` esistente.

Le operazioni CAD e UPM non creano nuovi Binary, non creano nuove DocumentReference, non modificano UniqueDocumentId/T4MedDocumentId/T4MedBinaryId, e aggiornano esclusivamente la risorsa DocumentReference esistente.

Altre decisioni consolidate: rimosso relatesTo.target.identifier dal messaggio RPD (opzionale in FHIR R4, ridondante con target.reference); l'eventuale transizione a status = "superseded" del documento precedente dopo un RPD non è un punto da confermare con T4MED, essendo un comportamento interno alla sua gestione del ciclo di vita, irrilevante per gt4medServices; gestione degli errori invariata in tutti i Flussi E/F/G/H.

Modificato¶

docs/samples/flusso-e-upload-referto-firmato.md: aggiornato il modello a tre identificativi (UniqueDocumentId, T4MedDocumentId, T4MedBinaryId); rimossa l'estensione document-action; rinominati i Codici Azione SINED (NWD/RPD/CAD/UPM); aggiornata la documentazione relativa alla gestione degli identificativi restituiti da T4MED.
docs/samples/flusso-f-referto-sostitutivo.md: introdotto ParentT4MedDocumentId; rimossa l'estensione document-action; rimosso relatesTo.target.identifier, mantenuto il solo relatesTo.target.reference; rinominato T10 in RPD; rimossa la nota sulla conferma con T4MED della transizione a superseded.
docs/samples/flusso-g-annullamento-referto.md: aggiornato il modello degli identificativi T4MED; rimossa l'estensione document-action; rinominato T11 in CAD.
docs/samples/flusso-h-aggiornamento-metadati.md: aggiornato il modello degli identificativi T4MED; rimossa l'estensione document-action; rinominato UPD in UPM.
docs/04-open-questions.md: aggiornato l'elenco dei punti ancora aperti e da confermare con T4MED — rimossi i punti divenuti privi di oggetto (UPD/UPM, modalità di trasmissione del codice azione, transizione a superseded, target.reference vs target.identifier); riferimenti ai codici azione aggiornati a NWD/RPD/CAD/UPM.

[1.4.0] — 2026-07-16¶

Decisioni prese (prima fase di test dell'integrazione SINED/T4MED)¶

A seguito dei test di integrazione, sono state recepite le decisioni concordate tra SINED e T4MED. Tutti i "punti da chiarire" residui relativi ai Flussi D ed E sono ora requisiti implementativi definitivi.

Flusso D — $generate-pdf: il parametro T4MedAppointmentId (valueString) è ora obbligatorio insieme a DateFrom/DateTo. Limita il telemonitoraggio restituito alla specifica prenotazione T4MED (Flusso A). Aggiunti gli scenari di errore "Appointment inesistente" (404 Not Found, not-found) e "Appointment appartenente ad altro paziente" (422 Unprocessable Entity, business-rule). Aggiunto il caso speciale "nessun dato clinico disponibile": quando paziente e parametri sono corretti ma non esistono schede di telemonitoraggio nel periodo, T4MED risponde 204 No Content (senza body) — non è un errore. In tutti questi casi — errore 4xx/5xx oppure 204 No Content — gt4medServices non effettua il merge PDF: il referto MEDWARE viene comunque firmato digitalmente da gefidServices, semplicemente senza l'allegato dei dati di monitoraggio T4MED.
Flusso E — formato di DocumentReference.identifier: definito il formato ufficialmente supportato — system = "urn:ietf:rfc:3986", value = "urn:sined:documentid:<tipo>:<valore>", con quattro varianti tipizzate (vco, guid32, siss15, numeric33) e un formato di compatibilità (urn:uuid:<uuid>, senza il prefisso sined:documentid). Documentato il limite di lunghezza: identifier.value è trattato da T4MED come stringa libera, lunghezza massima 200 caratteri; gli identificativi SINED (fino a ~150 caratteri) sono pienamente compatibili.
Suddivisione del Flusso E in quattro flussi distinti, sulla falsariga di quanto già fatto per i Flussi A/B/C: il Flusso E copriva quattro azioni (prima pubblicazione, sostitutivo, annullamento, aggiornamento dei soli metadati) documentate in un unico file. Per coerenza con il resto della documentazione, sono stati creati quattro documenti separati:
Flusso E — prima pubblicazione del referto (v1), POST {base-url} Bundle transaction
Flusso F — pubblicazione del referto sostitutivo (v>1), POST {base-url} Bundle transaction con relatesTo.code = "replaces"
Flusso G — annullamento del referto già pubblicato, PUT /DocumentReference/{id} con status = "entered-in-error"
Flusso H — aggiornamento dei soli metadati di un referto già pubblicato (es. stato di pagamento ticket), senza variare PDF, versione o status (che resta "current"); riusa lo stesso endpoint PUT /DocumentReference/{id} del Flusso G, distinto solo dal valore di status e dai campi effettivamente variati

Aggiunto¶

docs/samples/flusso-f-referto-sostitutivo.md: nuovo documento per il referto sostitutivo (v>1), estratto da flusso-e-upload-referto-firmato.md, con l'aggiunta dello scenario di errore "documento originale (relatesTo.target) non trovato" (404 Not Found).
docs/samples/flusso-g-annullamento-referto.md: nuovo documento per l'annullamento del referto, estratto da flusso-e-upload-referto-firmato.md, con l'aggiunta degli scenari di errore "DocumentReference originale non trovato" (404) e "documento già annullato" (409 Conflict).
docs/samples/flusso-h-aggiornamento-metadati.md: nuovo documento per l'aggiornamento dei soli metadati, estratto da flusso-e-upload-referto-firmato.md, ampliato con una sezione "Contesto" che lo distingue esplicitamente dai Flussi F e G, e con una nuova sezione "Response di fallimento" (404 DocumentReference non trovato, 409 documento già annullato).
docs/06-response-failure.md: nuove sezioni 2.6 (Flusso F), 2.7 (Flusso G) e 2.8 (Flusso H); aggiornata la sezione 2.4 (Flusso D) con gli esempi 3 e 4 (404/422 su T4MedAppointmentId) e il caso speciale 204 No Content; aggiornate la tabella dei flussi coperti (ora A–H), la sezione 1.3 (atomicità Bundle transaction, ora A/E/F) e il riepilogo finale (sezione 3).

Modificato¶

docs/samples/flusso-d-download-referto.md: aggiunto il parametro obbligatorio T4MedAppointmentId; aggiornati dati d'esempio, messaggio di richiesta, response di fallimento (404/422) e nuova sezione sul caso 204 No Content; chiarito che, sia in caso di errore sia di 204 No Content, il referto MEDWARE viene comunque firmato digitalmente, senza l'allegato T4MED.
docs/samples/flusso-e-upload-referto-firmato.md: ridotto alla sola prima pubblicazione (v1); aggiunta la sezione "Formato dell'identificativo del documento" (varianti SINED + limite di lunghezza); rimosse le sezioni "Referto sostitutivo", "Referto annullativo" e "Aggiornamento dei soli metadati" (spostate rispettivamente in Flusso F, Flusso G e Flusso H); aggiornata la tabella di versionamento con i link ai nuovi documenti.
docs/01-overview.md, docs/02-architecture.md, docs/03-api-analysis.md, docs/05-vincoli-e-eccezioni.md: propagata la suddivisione del Flusso E in E/F/G/H, il nuovo parametro obbligatorio del Flusso D e il relativo comportamento in caso di errore/204 No Content; corretto un residuo "coprono tutti e cinque i flussi" in "otto flussi (A–H)".
docs/diagrams/sequence-diagram.md: aggiornato il diagramma Mermaid — Flusso D con i tre parametri di $generate-pdf e un blocco alt per i casi 200 OK/204 No Content (in entrambi i rami il referto MEDWARE viene comunque firmato); Flusso E rinominato "FLUSSI E/F/G/H" con un blocco alt a quattro rami (prima pubblicazione / sostitutivo / annullamento / aggiornamento metadati); rigenerato il link mermaid.live.
mkdocs.yml, SUMMARY.md, README.md, docs/index.md: aggiunte le voci di navigazione per i Flussi F, G e H; aggiornati i riferimenti "Flussi A–E" → "Flussi A–H" e "Flusso E" → "Flussi E/F/G/H" in tutto il repository (inclusi i capitoli di monitoraggio e riconciliazione).

[1.3.1] — 2026-07-10¶

Modificato¶

docs/samples/flusso-a-nuova-prenotazione.md: rivista la gestione dell'indirizzo del paziente. Il Bundle contiene al massimo un elemento in Patient.address, quello il cui tipo è indicato dal CUP nell'estensione address-tipo ("residenza" oppure "domicilio"); gt4medServices non deduce né replica più l'indirizzo mancante e, se il tipo di indirizzo non è specificato, la risorsa Patient viene inviata senza address. Aggiornate di conseguenza la nota "residenza e domicilio" e la riga "Domicilio" nella tabella dei dati d'esempio.

[1.3.0] — 2026-06-24¶

Nota: tutto quello che viene descritto in questa versione riguardo al monitoraggio e alla riconciliazione non ha nessun effetto sull'implementazione dei Flussi A, B, C, D, E, che sono i principali — e per ora unici — flussi da gestire nell'integrazione tra la cartella clinica MEDWARE e T4MED.

Aggiunto¶

docs/10-monitoraggio-riconciliazione.md: nuovo capitolo che introduce il tema del monitoraggio e della riconciliazione tra gt4medServices e T4MED. Descrive il problema di base (asimmetria di visibilità fra chiamante e chiamato), il Monitoraggio (invio giornaliero di Report Sintetico e Report Analitico), la Riconciliazione Manuale (referente T4MED → servizio assistenza SINED) e la Riconciliazione Automatica (query periodiche di gt4medServices su Appointment/DocumentReference), con un diagramma di sequenza Mermaid per ciascun meccanismo, una tabella di confronto Manuale vs Automatica, e un paragrafo "Fattibilità e percorso di adozione" che inquadra il tutto come ipotesi di lavoro da validare con T4MED/TESI, proponendo come primo passo la sola spedizione del Report Sintetico.
docs/11-dettaglio-monitoraggio.md: approfondimento del Report Sintetico (MeasureReport, con dizionario di CodeSystem urn:t4med:monitoring:measure-group/population) e del Report Analitico (Parameters, in alternativa Bundle di risorse Task), con esempi FHIR R4, tabelle equivalenti, dizionari dei parametri/valori codificati, e la modellazione a stadi della pipeline di un referto (reportStatus: not-produced/pending/signed; repositoryOutcome/t4medOutcome: not-sent/success/failure).
docs/12-dettaglio-riconciliazione-manuale.md: approfondimento degli endpoint ipotizzati per l'invio dei report (operazione FHIR custom $submit-monitoring-summary/$submit-monitoring-detail vs creazione REST standard), con le quattro varianti di risposta OperationOutcome (ricezione semplice, dettagliata con/senza discrepanze, failure) e il relativo dizionario dei codici (urn:t4med:error-code: DISC-001…DISC-004, PR-001/PR-002, MR-001).
docs/13-dettaglio-riconciliazione-automatica.md: approfondimento della riconciliazione automatica, con le query FHIR standard su Appointment e DocumentReference (ricerca per intervallo, lettura puntuale per id, ricerca per identifier), le chiavi di confronto, la logica di reinvio e la gestione dell'idempotenza, separatamente per appuntamenti e referti.

Modificato¶

SUMMARY.md: aggiunta la voce "Monitoraggio e Riconciliazione" (docs/10-monitoraggio-riconciliazione.md) nella sezione "Documentazione".

[1.2.1] — 2026-06-23¶

Corretto¶

docs/03-api-analysis.md: chiarito quali campi della risorsa Patient (Flusso A) sono obbligatori e quali opzionali. Obbligatori: cognome, nome, data di nascita, sesso, codice fiscale. Opzionali: luogo di nascita, indirizzo di residenza, indirizzo di domicilio, numero di telefono. In precedenza il documento elencava tutti i campi come se fossero obbligatori.

[1.2.0] — 2026-06-12¶

Decisioni prese (riunione T4MED del 12/06/2026)¶

Formato della response al Bundle transaction del Flusso A: il Flusso A aderisce completamente allo standard FHIR R4. La request è un Bundle "transaction", inviato all'endpoint base (POST {base-url}, lo stesso usato dal Flusso E). La response è un Bundle "transaction-response". gt4medServices estrae il T4MED Appointment ID dalla location dell'entry Appointment della response (Appointment/T00450/_history/1 → "T00450") e lo salva negli archivi di SINED in corrispondenza dell'appuntamento CUP (mappatura CUP Appointment ID ↔ T4MED Appointment ID). La response del Flusso A è atomica: se anche una sola entry del Bundle non può essere registrata, l'intera transazione viene annullata — incluso un eventuale Patient già censito nella stessa transazione — e T4MED restituisce una segnalazione di errore (vedi 06-response-failure.md). Non esistono esiti "parziali".
Campi obbligatori della risorsa Patient: la risorsa Patient del Bundle (Flusso A) deve contenere cognome, nome, data di nascita, sesso, luogo di nascita, codice fiscale, indirizzo di residenza, indirizzo di domicilio, numero di telefono. Il codice ospedaliero è eliminato: non viene più trasmesso in nessun messaggio FHIR.
T4MED Patient ID: l'unico identificativo del paziente in T4MED è il codice fiscale. Ovunque sia necessario specificare l'id del paziente in un endpoint T4MED (es. Flusso D, Patient/{id}/$generate-pdf), {id} è il codice fiscale (cfisc) — es. Patient/RSVDMN11A41H620X/$generate-pdf.
Autenticazione verso le API T4MED: tramite header HTTP custom X-API-Key: <chiave>, dove <chiave> è la API Key fornita da T4MED.
URL di base di T4MED: TEST https://biocaretest.evisus.it/api/fhir, PROD https://biocaresuite.evisus.it/api/fhir. Gli esempi della documentazione fanno riferimento all'endpoint di TEST.
Cancellazione prenotazione (Flusso C): si mantiene esclusivamente la cancellazione fisica tramite il verbo DELETE (DELETE {base-url}/Appointment/{id}). Non è prevista alcuna modalità alternativa di cancellazione logica (PUT con status = "cancelled").
De-duplicazione paziente in T4MED: chiarimento non più necessario, eliminato dall'elenco dei punti da chiarire.
Ricerca per identifier esterno su Appointment: non è un problema, poiché T4MED restituisce il proprio T4MED Appointment ID direttamente nella response del Flusso A. gt4medServices persiste su DB interno la mappatura CUP Appointment ID → T4MED Appointment ID, ricavata da quella response: non è necessario alcun endpoint di ricerca aggiuntivo.
Merge anagrafico e rischio di disallineamento: chiarimento eliminato. Il rischio di disallineamento del codice ospedaliero in caso di merge anagrafico non si pone più, poiché il codice ospedaliero non viene più utilizzato: l'identificativo paziente in T4MED è il codice fiscale, stabile e non soggetto a merge anagrafico.
ServiceRequest nel Bundle del Flusso A: sì, la risorsa ServiceRequest è accettata nel Bundle del Flusso A.
DocumentReference.identifier (Flusso E): contiene lo UniqueDocumentId, nel formato comunicato da SINED al REPOSITORY OSPEDALIERO in fase di pubblicazione del referto.
Referto sostitutivo e annullativo (Flusso E): T4MED supporta anche la gestione del referto sostitutivo (relatesTo.code = "replaces") e del referto annullativo (status = "entered-in-error").
Flusso A — messaggio di esempio unico: un solo messaggio di esempio, pienamente conforme a FHIR R4 (Bundle transaction / transaction-response), con la risorsa Patient completa dei campi di residenza e domicilio, il campo "Reparto" documentato esplicitamente, e nota sull'atomicità della response (tutto-o-niente).
Response di fallimento (Flussi A-E): documentate centralmente in 06-response-failure.md, con esempi pertinenti riportati in ciascun documento di flusso.
Flusso E — metadati e versionamento: aggiunti i metadati di riservatezza (Confidentiality Code, oscuramenti, visibilità al cittadino, pagamento ticket), il numero di versione del documento (per nuove pubblicazioni e annullativi), e la gestione dell'aggiornamento dei soli metadati tramite PUT /DocumentReference/{id}.

Aggiunto¶

docs/06-response-failure.md: nuovo documento con il formato unificato delle risposte di fallimento (OperationOutcome), la tabella HTTP status/IssueType, la nota sull'atomicità della Bundle transaction (Flussi A ed E) e un esempio di risposta di errore per ciascun flusso (A-E).
Sezione "Response di fallimento" in tutti i documenti samples/flusso-*.md, con esempi specifici per flusso e riferimento a 06-response-failure.md e alle relative eccezioni in 05-vincoli-e-eccezioni.md.
samples/flusso-e-upload-referto-firmato.md: metadati di riservatezza/visibilità/versionamento sul DocumentReference (securityLabel di confidenzialità, document-oscuramento, patient-visibility-authorized, ticket-payment-status, document-version), nuovi esempi per referto sostitutivo, referto annullativo e aggiornamento dei soli metadati (PUT).
docs/05-vincoli-e-eccezioni.md: nota sui criteri di retry (5xx vs 4xx) con riferimento a 06-response-failure.md.

Modificato¶

A seguito della riunione con T4MED del 12/06/2026, che ha chiuso tutti i 12 punti aperti precedentemente elencati in 04-open-questions.md (ora rinominato "Punti chiariti con T4MED"):

docs/04-open-questions.md: ridotto a un breve documento introduttivo, che rinvia alla sezione "Decisioni prese" di questo changelog per la descrizione delle decisioni prese in riunione.
samples/flusso-a-nuova-prenotazione.md: riscritto. Rimossa la sezione "Parte 1" non conforme; risorsa Patient completata con indirizzo di residenza/domicilio (extension proprietarie ISTAT/ASL/regione), telefono; documentato il campo "Reparto" e l'atomicità della risposta.
samples/flusso-b-aggiorna-prenotazione.md e samples/flusso-c-cancella-prenotazione.md: aggiornati endpoint ({base-url}, X-API-Key), Patient ID = codice fiscale; rimossa da Flusso C l'alternativa di cancellazione logica.
samples/flusso-d-download-referto.md: riscritto, consolidando le precedenti "Versione estesa"/"Versione minima"; Patient ID = codice fiscale, codice ospedaliero eliminato.
docs/01-overview.md, docs/02-architecture.md, docs/03-api-analysis.md: aggiornati con gli endpoint reali T4MED (TEST https://biocaretest.evisus.it/api/fhir, PROD https://biocaresuite.evisus.it/api/fhir), autenticazione X-API-Key, codice fiscale come unico identificativo paziente; rimosse le deviazioni [D01]/[D02]/[D03], ora risolte.
docs/diagrams/sequence-diagram.md: aggiornati gli endpoint nel diagramma di sequenza ({base-url}, Bundle transaction/transaction-response, Patient ID = codice fiscale); rimosse le note su deviazione [D01] e cancellazione logica alternativa; rigenerato il link mermaid.live.
SUMMARY.md, docs/index.md, README.md: rinominata la voce "Punti aperti e chiarimenti" in "Punti chiariti con T4MED", aggiunta voce per 06-response-failure.md, aggiornato lo stato di avanzamento dei punti aperti con TESI/T4MED.
Tutti i documenti in docs/: rimossi i riferimenti puntuali "punto Lxx" / [Lxx] (rimandi a 04-open-questions.md, ora ridotto a un breve documento introduttivo) e i riferimenti residui a [D01]/[D02]/[D03]; le frasi interessate sono state riformulate per restare autonome.
docs/03-api-analysis.md: rimosse le sezioni "Elementi conformi alle specifiche T4MED" (S01-S17), "Elementi non specificati / inventati" (I01-I15) e "Correzioni FHIR R4 applicate" (C01-C03); rimosso il riferimento al parametro PatientIdentifier nella valutazione del Flusso D.
samples/flusso-d-download-referto.md: rimosso il parametro PatientIdentifier dal messaggio di richiesta $generate-pdf — il body contiene solo DateFrom/DateTo, l'identificazione del paziente avviene tramite {id} nell'URL dell'operazione.

[1.1.0] — 2026-06-03¶

Modificato¶

Rimossa la sezione "Struttura del repository" dalla home page (docs/index.md).

[1.0.0] — 2026-06-03¶

Modificato¶

Revisione terminologica.

[0.9.0] — 2026-06-03¶

Corretto¶

Diagramma di sequenza (docs/diagrams/sequence-diagram.md): rimosso il carattere ~ dalla nota del Flusso E (ogni ~10 min → ogni 10 min circa). Il carattere ~ è riservato dalla sintassi Mermaid per la notazione generics e causava un parse error (line 59) all'apertura del diagramma su mermaid.live.
Link mermaid.live: aggiornato il base64 nel link diretto a mermaid.live per riflettere il testo corretto.

Modificato¶

Rimossi riferimenti a data e autore da tutti i documenti (01-overview.md, 03-api-analysis.md, docs/index.md). La tracciabilità delle modifiche è affidata esclusivamente al CHANGELOG.

[0.8.0] — 2026-06-01¶

Modificato¶

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.

[0.7.0] — 2026-06-01¶

Corretto¶

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.

[0.6.0] — 2026-06-01¶

Infrastruttura¶

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.

[0.5.0] — 2026-06-01¶

Aggiunto¶

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.

[0.4.0] — 2026-06-01¶

Aggiunto¶

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.

Modificato¶

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.

[0.3.0] — 2026-06-01¶

Aggiunto¶

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.

[0.2.0] — 2026-06-01¶

Corretto¶

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.

Modificato¶

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.

[0.1.0] — 2026-06-01¶

Aggiunto¶

Documentazione iniziale del progetto di integrazione MEDWARE / T4MED
Analisi di completezza delle specifiche API T4MED (Flussi A–E)
Messaggi FHIR R4 di esempio per tutti e cinque i flussi:
Flusso A — Nuova prenotazione (POST /Appointment)
Flusso B — Variazione prenotazione (PUT /Appointment/{id})
Flusso C — Cancellazione prenotazione (DELETE /Appointment/{id})
Flusso D — Download referto da T4MED ($generate-pdf)
Flusso E — Upload referto firmato (Bundle Binary+DocumentReference)
Identificazione di 9 lacune/punti aperti da chiarire con TESI
Diagramma di sequenza Mermaid (Flussi A–E)
Quadro di conformità T4MED vs FHIR R4

Stato¶

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