10 — Monitoraggio e Riconciliazione¶

Stato: proposta di gt4medServices, in attesa di conferma da parte di T4MED/TESI (endpoint, formati e scope descritti in questo capitolo non sono ancora parte della specifica T4MED nota).

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

Il problema¶

Nei Flussi A-H, gt4medServices è sempre il client che chiama T4MED: per ogni chiamata conosce sempre l'esito (successo, errore di contenuto, o nessuna risposta). T4MED, al contrario, ha visibilità solo sulle richieste effettivamente ricevute ed elaborate — se una chiamata di gt4medServices non arriva mai a destinazione (timeout, server down), T4MED non se ne accorge.

La soluzione adottata è che gt4medServices invii periodicamente a T4MED un report del proprio stato, così che T4MED possa confrontarlo con i propri dati e individuare le discrepanze altrimenti invisibili a entrambi i sistemi (Monitoraggio). Le discrepanze rilevate vengono poi gestite in due modi complementari: con l'intervento di un operatore (Riconciliazione Manuale) oppure in piena autonomia da gt4medServices stesso (Riconciliazione Automatica).

Monitoraggio¶

Ogni giorno alle 06:00, gt4medServices invia a T4MED due report in standard HL7 FHIR R4 — stessa direzione di chiamata dei Flussi A-H (gt4medServices client, T4MED server):

Report sintetico (MeasureReport): conteggi aggregati dall'inizio dell'integrazione (prenotazioni ricevute, televisite eseguite, referti firmati e spediti con successo/fallimento). Ogni indicatore porta un codice stabile (coding), oltre al testo descrittivo, per un confronto robusto fra i due sistemi.
Report analitico (Parameters, in alternativa Bundle di risorse Task): dettaglio delle singole televisite delle ultime due settimane (finestra mobile, per tollerare problemi di comunicazione temporanei), con chiave logica appointmentId + documentId.

L'assenza del report quotidiano è essa stessa un'anomalia (problema di connettività, autenticazione o disponibilità).

sequenceDiagram
    participant GT as gt4medServices
    participant T4M as T4MED

    Note over GT,T4M: Ogni giorno alle 06:00
    GT->>T4M: Report sintetico (MeasureReport)
    T4M-->>GT: OperationOutcome (ricezione + confronto)
    GT->>T4M: Report analitico (Parameters / Bundle di Task)
    T4M-->>GT: OperationOutcome (ricezione + confronto, eventuali discrepanze)

Riconciliazione Manuale¶

T4MED confronta i due report ricevuti con i propri dati. La riconciliazione che ne segue è manuale: segnalazione e risoluzione passano per due operatori, non per uno scambio automatico fra sistemi.

Un referente T4MED confronta i report con i dati del proprio sistema e individua le discrepanze (prenotazioni o referti dichiarati da SINED ma non noti a T4MED, oppure con stato disallineato).
Il referente segnala le discrepanze al servizio assistenza di SINED.
Il servizio assistenza di SINED attiva le procedure di riconciliazione (verifica e, se necessario, reinvio tramite gt4medServices) per risolverle.

sequenceDiagram
    participant GT as gt4medServices
    participant T4M as T4MED
    participant REF as Referente T4MED
    participant ASS as Servizio Assistenza SINED

    Note over T4M,ASS: Segue l'invio giornaliero dei report (Monitoraggio)
    T4M->>T4M: Confronta i report ricevuti con i propri dati
    T4M->>REF: Evidenzia prenotazioni/referti mancanti o discordanti
    REF->>ASS: Segnala le discrepanze riscontrate
    ASS->>ASS: Attiva le procedure di riconciliazione
    ASS->>GT: Richiede verifica/reinvio
    GT->>T4M: Reinvio mirato (Flusso A/B/E-G)

Riconciliazione Automatica¶

In alternativa — e in modo complementare, non sostitutivo, alla riconciliazione manuale — gt4medServices può interrogare periodicamente T4MED per ottenere l'elenco delle prenotazioni e dei referti effettivamente noti in un intervallo, confrontarlo con i propri archivi e reinviare automaticamente quanto risultasse mancante, senza alcun intervento umano:

GET {base-url}/Appointment?date=ge{X}&date=lt{Y} — elenco prenotazioni nel periodo;
GET {base-url}/DocumentReference?date=ge{X}&date=lt{Y} — elenco referti pubblicati nel periodo.

Il confronto usa gli identificativi già noti a entrambi i sistemi: codice CUP e T4MED Appointment ID per le prenotazioni; UUID assegnato da gt4medServices (identifier con system: urn:ietf:rfc:3986, Flusso E) e T4MED DocumentReference ID per i referti.

sequenceDiagram
    participant GT as gt4medServices
    participant T4M as T4MED

    loop Periodicamente
        GT->>T4M: GET /Appointment?date=ge{X}&date=lt{Y}
        T4M-->>GT: Bundle searchset — prenotazioni nel periodo
        GT->>T4M: GET /DocumentReference?date=ge{X}&date=lt{Y}
        T4M-->>GT: Bundle searchset — referti nel periodo
        GT->>GT: Confronta con gli archivi interni (referti: solo quelli già firmati e spediti a REPO)
        alt Elementi mancanti
            GT->>T4M: Reinvio automatico (Flusso A o Flussi E/F/G)
            T4M-->>GT: 200 OK
        else Nessuna discrepanza
            GT->>GT: Nessuna azione
        end
    end

Manuale vs Automatica¶

	Manuale	Automatica
Direzione	T4MED riceve i report (push)	gt4medServices interroga T4MED (pull)
Chi rileva le discrepanze	T4MED	gt4medServices
Chi le risolve	Servizio assistenza SINED, su segnalazione umana	gt4medServices, in autonomia
Cosa può rilevare	Anche discrepanze di contenuto/stato	Solo presenza/assenza

I due meccanismi coesistono: l'automatica risolve in autonomia la maggior parte dei casi di mancata ricezione, la manuale resta come rete di sicurezza per i casi (di contenuto/stato, o di fallimento della riconciliazione automatica stessa) che l'altra non può rilevare da sola.

Fattibilità e percorso di adozione¶

Quanto descritto in questo capitolo — Monitoraggio, Riconciliazione Manuale e Riconciliazione Automatica — è un'ipotesi di lavoro che richiede una valutazione di fattibilità, tecnica e organizzativa, sia lato T4MED sia lato SINED.

Lo scenario ideale prevede la produzione di entrambi i report (sintetico e analitico), l'attivazione della Riconciliazione Automatica, e il ricorso alla verifica manuale solo nei casi residui: quando T4MED, dall'analisi dei report, rileva una discrepanza e ne avvisa SINED perché possa sanarla.

In una prima fase si propone — se possibile e fattibile per T4MED — di valutare la sola spedizione del Report Sintetico, per permettere a T4MED di segnalare a SINED un'eventuale discrepanza relativa a un determinato giorno o periodo (al massimo entro la settimana). A fronte di tale segnalazione:

SINED verifica le proprie tabelle di log per individuare eventuali indicazioni di errore nel periodo segnalato — in pratica, l'operatore SINED esegue una query che restituisce il dettaglio di tutte le spedizioni e dei relativi fallimenti, un report concettualmente simile a quanto si otterrebbe dai dati del Report Analitico, ma prodotto su richiesta invece che in automatico;
se vengono individuati problemi di spedizione, l'operatore SINED, se possibile, ripete l'invio del referto;
se ciò non fosse possibile, l'operatore SINED informa T4MED che non sarà possibile spedire il referto.

Questo percorso, in tutte le sue fasi, va concordato tra le parti: implica un impiego di risorse umane (lato SINED e lato T4MED) che probabilmente non era stato considerato in fase di pianificazione iniziale dell'integrazione.

Note¶

{base-url} — ambiente di TEST: https://biocaretest.evisus.it/api/fhir.
Tutti gli endpoint, gli scope (system/Appointment.read non è oggi previsto dalla specifica nota) e i formati di richiesta/risposta descritti in questo capitolo sono ipotesi di lavoro da validare con T4MED/TESI.