02 — Architettura e flussi dati¶

Schema generale¶

── FLUSSI A/B/C — Gestione prenotazioni ─────────────────────────────

CUP (HL7 OMG^O19)
  └─► MIRTH (integration engine)
          ├──► MEDWARE  (scrive in tabella prenotazioni)
          └──► gt4medServices
                    └─► T4MED (FHIR R4)
                         POST /Appointment  (Flusso A)
                         PUT  /Appointment/{id}  (Flusso B)
                         DELETE /Appointment/{id}  (Flusso C)

── FLUSSO D — Firma referto post-visita ─────────────────────────────

MEDWARE [medico clicca pulsante "firma"]
  └─► gefidServices
          │  chiede il referto T4MED
          └─► gt4medServices ──► T4MED  (scarica PDF monitoraggio)
                    │
                    └─► MEDWARE  (scarica referto clinico visita)
                    └─► merge PDF (T4MED accodato al referto MEDWARE)
          │
          └─► gefidServices  (riceve PDF unito, lo firma digitalmente SINED)

── FLUSSO E — Pubblicazione e upload su T4MED ───────────────────────

grepoServices  [schedulato ogni ~10 minuti]
  ├──► REPO ──► FSE  (pubblica referti firmati pendenti)
  │
  └─► gt4medServices  (per ogni referto pubblicato su REPO/FSE)
            └─► T4MED  (upload Bundle Binary + DocumentReference)

Flusso A — Nuova prenotazione televisita¶

Trigger: CUP invia HL7 OMG^O19 (inserimento) al canale MIRTH.

CUP
 │  HL7 OMG^O19 (ins. prenotazione 26B001956)
 ▼
MIRTH
 ├──► MEDWARE  (scrive prenotazione in tabella prenotazioni)
 │
 │  chiama gt4medServices
 ▼
gt4medServices
 │  POST /fhir/Appointment
 │  Bundle {Patient + Appointment}
 ├──► T4MED  ──► 200 OK {id: "T00450"}
 │
 └──► Salva mappatura: 26B001956 → T00450

Importante: gt4medServices deve persistere la mappatura CUP Appointment ID → T4MED Appointment ID per i Flussi B e C.

Flusso B — Variazione prenotazione¶

Trigger: CUP invia HL7 OMG^O19 (variazione) al canale MIRTH.

CUP
 │  HL7 OMG^O19 (var. prenotazione 26B001956)
 ▼
MIRTH
 ├──► MEDWARE  (aggiorna prenotazione in tabella prenotazioni)
 │
 │  chiama gt4medServices
 ▼
gt4medServices
 │  Legge mappatura: 26B001956 → T00450
 │  PUT /fhir/Appointment/T00450
 └──► T4MED  ──► 200 OK

Flusso C — Cancellazione prenotazione¶

Trigger: CUP invia HL7 OMG^O19 (cancellazione) al canale MIRTH.

CUP
 │  HL7 OMG^O19 (canc. prenotazione 26B001956)
 ▼
MIRTH
 ├──► MEDWARE  (cancella prenotazione in tabella prenotazioni)
 │
 │  chiama gt4medServices
 ▼
gt4medServices
 │  Legge mappatura: 26B001956 → T00450
 │  DELETE /fhir/Appointment/T00450
 ├──► T4MED  ──► 200 OK / 204 No Content
 │
 └──► Invalida mappatura: 26B001956 → T00450

Nota: Alcune implementazioni FHIR R4 non supportano DELETE fisico (HTTP 405). In quel caso usare cancellazione logica: PUT /Appointment/T00450 con status = "cancelled". Da chiarire con TESI (lacuna L9).

Flusso D — Firma referto post-visita (gefidServices)¶

Trigger: il medico visualizza il referto della televisita in MEDWARE e clicca il pulsante "firma" (icona penna in alto a destra). Questo innesca gefidServices.

Ruolo di gefidServices: middleware di firma digitale SINED già in esercizio. Quando attivato dal pulsante "firma" di MEDWARE, coordina il recupero e la firma del referto completo.

MEDWARE [clic pulsante "firma"]
 └─► gefidServices
      │  Richiesta referto T4MED (CF: RSVDMN11A41H620X, data: 2026-06-03)
      ▼
     gt4medServices
      │  POST /fhir/Patient/4578934/$generate-pdf
      ├──► T4MED  ──► 200 OK (stream PDF monitoraggio)
      │
      │  Download referto clinico
      ├──► MEDWARE  ──► stream PDF referto visita
      │
      │  Merge PDF (T4MED accodato al referto MEDWARE)
      └──► gefidServices  (riceve PDF unito)
           │
           └──► Firma digitale SINED (PDF firmato pronto)

Flusso E — Pubblicazione e upload su T4MED (grepoServices)¶

Trigger: grepoServices è un servizio schedulato (tipicamente ogni ~10 minuti). Non viene innescato direttamente da gefidServices. Ad ogni esecuzione, grepoServices raccoglie i referti firmati pendenti, li pubblica su REPO/FSE e, per ognuno, chiama gt4medServices per l'upload su T4MED.

gefidServices
 │  PDF firmato
 ▼
grepoServices
 │  Upload documento firmato
 ├──► REPO  ──► Pubblicato su REPO
 │       └──► FSE  ──► Pubblicato su FSE
 │
 │  (solo dopo OK da REPO/FSE)
 │  Richiesta upload su T4MED
 ▼
gt4medServices
 │  POST /fhir
 │  Bundle {Binary + DocumentReference}
 └──► T4MED  ──► 200 OK (Bundle transaction-response)
      └──► gt4medServices  ──► grepoServices  (upload T4MED completato)

Tabella di mappatura interna (obbligatoria)¶

gt4medServices deve persistere su DB interno le seguenti mappature:

Chiave	Valore	Usata nei flussi
CUP Appointment ID (es. `26B001956`)	T4MED Appointment ID (es. `T00450`)	B, C
Codice fiscale / cod. ospedaliero	T4MED Patient ID	D, E

Decisioni architetturali aperte¶

Parser HL7 v2 per i messaggi OMG^O19 del CUP
Modalità di integrazione con MEDWARE (API proprietaria / DB / interfaccia HL7 — non ancora documentata)
Libreria per il merge dei PDF
Interfaccia esposta da gt4medServices verso gefidServices (Flusso D)
Interfaccia esposta da gt4medServices verso grepoServices (Flusso E)
Ambiente di deployment e gestione della configurazione (API Key T4MED, ecc.)