Flusso B — Variazione prenotazione¶

Operazione: PUT /Appointment/{id}
Flusso: B — CUP → gt4medServices → T4MED

Dati del caso di esempio¶

Campo	Valore
T4MED Appointment ID	`T00450`
Paziente	ROSAVIOLA DALMINA (nome di fantasia)
Codice fiscale (= T4MED Patient ID)	`RSVDMN11A41H620X`
Variazione	Spostamento al 10/06/2026 ore 14:00
Nuova data	`2026-06-10T14:00:00+02:00` → `14:30:00+02:00`
Presidio	Ospedale di Verbania, cod. STS11 `000256`
Reparto	Nefrologia e Dialisi, cod. `NEF001`
Prestazione	`89.01.B` — Visita nefrologica di controllo
ID CUP prenotazione	`26B001956`

Conformità FHIR R4¶

Per il Flusso B (PUT /Appointment/{id}) la specifica T4MED e lo standard FHIR R4 coincidono pienamente:

Endpoint: PUT /Appointment/{id} — identico
Corpo: singola risorsa Appointment (sostituzione completa) — identico
Risposta: risorsa Appointment aggiornata — identico

Non ci sono deviazioni. I messaggi sotto sono validi per entrambi gli approcci.

Nota: PUT esegue la sostituzione completa della risorsa. Il T4MED Appointment ID (T00450) deve essere stato memorizzato da gt4medServices al momento della creazione (Flusso A).

Endpoint e autenticazione¶

PUT https://biocaretest.evisus.it/api/fhir/Appointment/T00450
Content-Type: application/fhir+json
X-API-Key: <chiave>

Endpoint di TEST. In PROD: https://biocaresuite.evisus.it/api/fhir. Autenticazione tramite header custom X-API-Key.

Versione estesa — T4MED = FHIR R4¶

Contiene tutti i campi clinici, tutti i partecipanti (paziente, reparto, presidio), serviceType con codice prestazione.

REQUEST¶

PUT https://biocaretest.evisus.it/api/fhir/Appointment/T00450
Content-Type: application/fhir+json
X-API-Key: <chiave>

{
  "resourceType": "Appointment",
  "id": "T00450",
  "identifier": [
    {
      "system": "urn:local:cup:id-prenotazione",
      "value": "26B001956"
    }
  ],
  "status": "booked",
  "serviceType": [
    {
      "coding": [
        {
          "system": "urn:oid:2.16.840.1.113883.2.9.2.10.6.11",
          "code": "89.01.B",
          "display": "Visita nefrologica di controllo"
        }
      ]
    }
  ],
  "start": "2026-06-10T14:00:00+02:00",
  "end":   "2026-06-10T14:30:00+02:00",
  "participant": [
    {
      "actor": {
        "reference": "Patient/RSVDMN11A41H620X",
        "display": "ROSAVIOLA DALMINA"
      },
      "required": "required",
      "status": "accepted"
    },
    {
      "actor": {
        "type": "HealthcareService",
        "identifier": {
          "system": "urn:local:asl-vco:reparto",
          "value": "NEF001"
        },
        "display": "Reparto Nefrologia e Dialisi - Ospedale di Verbania"
      },
      "required": "required",
      "status": "accepted"
    },
    {
      "actor": {
        "type": "Location",
        "identifier": {
          "system": "urn:oid:2.16.840.1.113883.2.9.4.1.3",
          "value": "000256"
        },
        "display": "Presidio Ospedaliero di Verbania"
      },
      "required": "required",
      "status": "accepted"
    }
  ]
}

RESPONSE ATTESA — T4MED = FHIR R4¶

HTTP/1.1 200 OK
Content-Type: application/fhir+json

{
  "resourceType": "Appointment",
  "id": "T00450",
  "status": "booked",
  "start": "2026-06-10T14:00:00+02:00",
  "end":   "2026-06-10T14:30:00+02:00",
  "participant": [
    {
      "actor": {
        "reference": "Patient/RSVDMN11A41H620X",
        "display": "ROSAVIOLA DALMINA"
      },
      "required": "required",
      "status": "accepted"
    }
  ]
}

Nota FHIR R4: alcuni server restituiscono 204 No Content (senza body) invece di 200 OK con body. Entrambe le risposte sono conformi allo standard.

Versione minima — T4MED = FHIR R4¶

Solo campi obbligatori FHIR R4 per Appointment + riferimento T4MED Patient ID.

REQUEST¶

PUT https://biocaretest.evisus.it/api/fhir/Appointment/T00450
Content-Type: application/fhir+json
X-API-Key: <chiave>

{
  "resourceType": "Appointment",
  "id": "T00450",
  "status": "booked",
  "start": "2026-06-10T14:00:00+02:00",
  "end":   "2026-06-10T14:30:00+02:00",
  "participant": [
    {
      "actor": {
        "reference": "Patient/RSVDMN11A41H620X"
      },
      "status": "accepted"
    }
  ]
}

RESPONSE ATTESA — T4MED = FHIR R4¶

HTTP/1.1 200 OK
Content-Type: application/fhir+json

{
  "resourceType": "Appointment",
  "id": "T00450",
  "status": "booked",
  "start": "2026-06-10T14:00:00+02:00",
  "end":   "2026-06-10T14:30:00+02:00",
  "participant": [
    {
      "actor": {
        "reference": "Patient/RSVDMN11A41H620X"
      },
      "status": "accepted"
    }
  ]
}

Response di fallimento¶

Per il formato generale e l'elenco completo degli scenari di errore vedi 06-response-failure.md. Esempio pertinente al Flusso B:

Appointment non trovato (T00450 non esiste su T4MED)

HTTP/1.1 404 Not Found
Content-Type: application/fhir+json

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "not-found",
      "details": {
        "text": "Nessuna risorsa Appointment trovata con id 'T00450'"
      },
      "diagnostics": "PUT /Appointment/T00450"
    }
  ]
}

In questo caso la mappatura interna (26B001956 → T00450) punta a una risorsa inesistente su T4MED: gt4medServices non deve ritentare con lo stesso ID, ma segnalare il disallineamento per verifica (vedi Eccezione B1 in 05-vincoli-e-eccezioni.md).