Diagramma di sequenza — gt4medServices / Integrazione T4MED¶

Se il diagramma non viene visualizzato correttamente, aprilo direttamente su mermaid.live:

Endpoint di base T4MED (ipotetico): https://api.t4med.it/fhir
Copertura: Flusso A, B, C (prenotazioni) — Flusso D (firma referto) — Flusso E (pubblicazione e upload T4MED)
Paziente di riferimento: ROSAVIOLA DALMINA — CF RSVDMN11A41H620X — Prenotazione CUP 26B001956 — T4MED T00450

Script Mermaid¶

sequenceDiagram
    participant CUP
    participant MIR as MIRTH
    participant GT as gt4medServices
    participant MW as MEDWARE
    participant T4M as T4MED
    participant GEF as gefidServices
    participant GRE as grepoServices
    participant REPO
    participant FSE

    rect rgb(210, 230, 255)
    Note over CUP,T4M: FLUSSO A — Nuova prenotazione televisita
    CUP->>MIR: HL7 OMG^O19 (ins. prenotazione 26B001956)
    MIR->>MW: Scrive prenotazione in tabella prenotazioni
    MIR->>GT: Chiama gt4medServices (inserimento)
    GT->>T4M: POST /fhir/Appointment — Bundle {Patient + Appointment}
    T4M-->>GT: 200 OK — Appointment {id: "T00450"}
    GT->>GT: Salva mappatura: 26B001956 → T00450
    end

    rect rgb(255, 240, 210)
    Note over CUP,T4M: FLUSSO B — Variazione prenotazione
    CUP->>MIR: HL7 OMG^O19 (var. prenotazione 26B001956)
    MIR->>MW: Aggiorna prenotazione in tabella prenotazioni
    MIR->>GT: Chiama gt4medServices (variazione)
    GT->>GT: Legge mappatura: 26B001956 → T00450
    GT->>T4M: PUT /fhir/Appointment/T00450 — Appointment aggiornata
    T4M-->>GT: 200 OK
    end

    rect rgb(255, 220, 220)
    Note over CUP,T4M: FLUSSO C — Cancellazione prenotazione
    CUP->>MIR: HL7 OMG^O19 (canc. prenotazione 26B001956)
    MIR->>MW: Cancella prenotazione in tabella prenotazioni
    MIR->>GT: Chiama gt4medServices (cancellazione)
    GT->>GT: Legge mappatura: 26B001956 → T00450
    GT->>T4M: DELETE /fhir/Appointment/T00450
    T4M-->>GT: 200 OK / 204 No Content
    GT->>GT: Invalida mappatura: 26B001956 → T00450
    end

    rect rgb(220, 255, 235)
    Note over MW,GEF: FLUSSO D — Firma referto post-visita
    MW->>GEF: Medico clicca "firma" — innesca gefidServices
    GEF->>GT: Richiesta referto T4MED (CF: RSVDMN11A41H620X, data: 2026-06-03)
    GT->>T4M: POST /fhir/Patient/4578934/$generate-pdf — Parameters
    T4M-->>GT: 200 OK — stream PDF monitoraggio
    GT->>MW: Download referto clinico MEDWARE
    MW-->>GT: stream PDF referto visita
    GT->>GT: Merge PDF (T4MED accodato al referto MEDWARE)
    GT-->>GEF: PDF unito
    GEF->>GEF: Firma digitale SINED
    end

    rect rgb(200, 245, 220)
    Note over GRE,FSE: FLUSSO E — Pubblicazione schedulata e upload su T4MED
    Note over GRE,FSE: grepoServices schedulato ogni ~10 min
    GRE->>REPO: Upload referti firmati pendenti
    REPO-->>GRE: Pubblicato su REPO
    REPO->>FSE: Pubblicazione su FSE
    FSE-->>REPO: OK
    REPO-->>GRE: Pubblicato su FSE
    GRE->>GT: Upload referto firmato su T4MED
    GT->>T4M: POST /fhir — Bundle {Binary + DocumentReference}
    T4M-->>GT: 200 OK — Bundle transaction-response
    GT-->>GRE: Upload T4MED completato
    end

Note sul diagramma¶

Gli URL usano path relativi all'endpoint di base https://api.t4med.it/fhir per leggibilità.
La mappatura CUP-ID → T4MED-ID è persistita su DB interno di gt4medServices e usata dai Flussi B, C, D, E.
Flussi A/B/C: il messaggio HL7 OMG^O19 del CUP arriva a MIRTH, che scrive in MEDWARE e chiama gt4medServices per replicare l'operazione su T4MED.
Il Flusso D è innescato dal medico che clicca il pulsante "firma" in MEDWARE. gefidServices coordina il recupero del referto tramite gt4medServices (download da T4MED + MEDWARE, merge) e firma digitalmente il PDF unito.
Il Flusso E è gestito da grepoServices, servizio schedulato (~10 min), non direttamente innescato da gefidServices. grepoServices pubblica i referti firmati pendenti su REPO/FSE e, solo dopo conferma, chiama gt4medServices per l'upload su T4MED.
L'upload del referto firmato su T4MED avviene sempre DOPO la pubblicazione su REPO/FSE.
Il Flusso A usa POST /fhir/Appointment con body Bundle: deviazione T4MED dallo standard FHIR R4 (che richiederebbe POST /fhir). Vedere D01 — Analisi conformità API.
Cancellazione logica (PUT status="cancelled") è alternativa al DELETE nel caso T4MED non supporti DELETE fisico (da chiarire con TESI).