01 — Overview del progetto¶
Contesto¶
Il reparto di Nefrologia e Dialisi dell'ASL VCO - Ospedale di Verbania eroga visite nefrologiche in televisita. Le prenotazioni vengono gestite dal CUP (Centro Unico di Prenotazione) tramite messaggi HL7 v2 OMG^O19 e devono essere replicate sulla piattaforma di televisita T4MED tramite API FHIR R4.
Al termine della visita, quando il medico clicca il pulsante "firma" in MEDWARE, viene innescata la seguente catena:
- gefidServices recupera il PDF di monitoraggio da T4MED tramite gt4medServices
- gt4medServices scarica anche il referto clinico da MEDWARE e unisce (merge) i due PDF
- gefidServices firma digitalmente il PDF unito (piattaforma SINED)
- grepoServices pubblica il documento firmato su REPO e poi su FSE
- Solo dopo la conferma di pubblicazione, grepoServices chiama gt4medServices per caricare il referto firmato anche su T4MED (prima pubblicazione, sostitutivo, annullamento o aggiornamento metadati — Flussi E/F/G/H)
Obiettivo¶
Realizzare il middleware gt4medServices che funga da collante tra tutti i sistemi coinvolti.
Azioni richieste¶
| Flusso | Trigger | Azione gt4medServices |
|---|---|---|
| A — Nuova prenotazione | CUP → MIRTH (OMG^O19 ins.) → MEDWARE + chiama gt4medServices | POST Appointment su T4MED |
| B — Variazione prenotazione | CUP → MIRTH (OMG^O19 var.) → MEDWARE + chiama gt4medServices | PUT Appointment su T4MED |
| C — Cancellazione prenotazione | CUP → MIRTH (OMG^O19 canc.) → MEDWARE + chiama gt4medServices | DELETE Appointment su T4MED |
| D — Firma referto post-visita | Medico clicca "firma" in MEDWARE → innesca gefidServices → chiama gt4medServices | Scarica PDF da T4MED (per la specifica prenotazione, T4MedAppointmentId) + da MEDWARE, merge, restituisce PDF unito a gefidServices per firma SINED |
| E — Pubblicazione nuovo referto su T4MED | grepoServices schedulato (~10 min) → dopo OK su REPO/FSE chiama gt4medServices | Carica Bundle Binary+DocRef (v1) su T4MED |
| F — Pubblicazione referto sostitutivo su T4MED | grepoServices, quando il referto sostituisce una versione già pubblicata | Carica Bundle Binary+DocRef (v>1, relatesTo=replaces) su T4MED |
| G — Annullamento referto su T4MED | grepoServices, quando il referto pubblicato viene annullato | PUT DocumentReference/{id} con status=entered-in-error su T4MED |
| H — Aggiornamento dei soli metadati | grepoServices, quando cambia un metadato (es. stato pagamento ticket) senza variare PDF/versione | PUT DocumentReference/{id} con status=current su T4MED |
Sistemi coinvolti¶
| Sistema | Tipo | Note di integrazione |
|---|---|---|
| CUP | Prenotazioni | Genera messaggi HL7 v2 OMG^O19 verso MIRTH |
| MIRTH | Integration engine | Riceve OMG^O19, scrive in MEDWARE, chiama gt4medServices |
| MEDWARE | Cartella clinica EHR | Sorgente prenotazioni e referti; pulsante "firma" innesca gefidServices |
| T4MED | Piattaforma televisita | API FHIR R4 (API Key + IP restriction) |
| gefidServices | Firma digitale SINED (gia' in esercizio) | Innescato dal pulsante "firma" di MEDWARE; chiama gt4medServices per il referto |
| grepoServices | Servizio schedulato (~10 min) | Pubblica referti firmati su REPO/FSE; chiama gt4medServices per upload su T4MED |
| REPO | Repository documentale aziendale | Riceve documenti firmati da grepoServices |
| FSE | Fascicolo Sanitario Elettronico | Alimentato da REPO |
API T4MED — Endpoint base e autenticazione¶
URL ufficiali:
| Ambiente | URL base |
|---|---|
| TEST | https://biocaretest.evisus.it/api/fhir |
| PROD | https://biocaresuite.evisus.it/api/fhir |
Negli esempi della documentazione si fa riferimento all'endpoint di TEST.
Autenticazione tramite header HTTP custom:
| Flusso | Metodo | Endpoint |
|---|---|---|
| A | POST | {base-url} — Bundle transaction (FHIR R4 standard) |
| B | PUT | {base-url}/Appointment/{id} |
| C | DELETE | {base-url}/Appointment/{id} |
| D | POST | {base-url}/Patient/{cfisc}/$generate-pdf — richiede DateFrom, DateTo, T4MedAppointmentId |
| E | POST | {base-url} — Bundle transaction (prima pubblicazione, v1) |
| F | POST | {base-url} — Bundle transaction (referto sostitutivo, v>1, relatesTo=replaces) |
| G | PUT | {base-url}/DocumentReference/{id} (annullamento, status=entered-in-error) |
| H | PUT | {base-url}/DocumentReference/{id} (aggiornamento dei soli metadati, status=current) |
Il Patient ID su T4MED coincide con il codice fiscale (
{cfisc}). Il Flusso H riusa lo stesso endpointPUT {base-url}/DocumentReference/{id}del Flusso G, senza cambiarestatus— vedi samples/flusso-h-aggiornamento-metadati.md.
Stato delle specifiche¶
Le specifiche API T4MED ("Bozza specifiche API FHIR R4 - Integrazione Sined") coprono tutti e otto i flussi (A–H). A seguito della riunione del 12 giugno 2026, tutti i punti dubbi individuati sono stati chiariti con TESI/T4MED. Vedere 04-open-questions.md.