Flusso C — Cancellazione prenotazione¶
Operazione: DELETE /Appointment/{id}
Flusso: C — CUP → gt4medServices → T4MED
Dati del caso di esempio¶
| Campo | Valore |
|---|---|
| T4MED Appointment ID | T00450 (da tabella di mappatura, inserita al Flusso A) |
| ID CUP prenotazione | 26B001956 |
Conformità FHIR R4¶
Per il Flusso C (DELETE /Appointment/{id}) la specifica T4MED e lo standard FHIR R4 coincidono pienamente:
- Endpoint:
DELETE /Appointment/{id}— identico - Corpo: nessuno — identico
- Risposta:
200 OKo204 No Content— identico
Non ci sono deviazioni.
La versione estesa e la versione minima coincidono: DELETE non prevede body. L'unico dato necessario è il T4MED Appointment ID nell'URL, ricavato dalla tabella di mappatura interna di gt4medServices.
Il Flusso C prevede esclusivamente la cancellazione fisica tramite
DELETE. Non è prevista alcuna modalità alternativa di cancellazione logica (PUTconstatus = "cancelled").
Endpoint e autenticazione¶
Endpoint di TEST. In PROD:
https://biocaresuite.evisus.it/api/fhir. Autenticazione tramite header customX-API-Key.
DELETE fisico — T4MED = FHIR R4¶
REQUEST¶
(nessun corpo)
RESPONSE ATTESA — T4MED = FHIR R4¶
oppureEntrambe le risposte sono conformi allo standard FHIR R4.
Azione gt4medServices dopo la risposta:
- Invalidare (o rimuovere) il record
26B001956→T00450dalla tabella di mappatura interna.
Response di fallimento¶
Per il formato generale e l'elenco completo degli scenari di errore vedi 06-response-failure.md. Esempio pertinente al Flusso C:
Appointment già concluso, non cancellabile
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "conflict",
"details": {
"text": "L'Appointment 'T00450' e' nello stato 'fulfilled' e non puo' essere cancellato"
},
"diagnostics": "DELETE /Appointment/T00450"
}
]
}
Su 409 Conflict, gt4medServices non deve ritentare la DELETE, ma segnalare il conflitto per verifica (vedi Eccezione C1 in 05-vincoli-e-eccezioni.md).