04 — Lacune e punti aperti¶
Punti da chiarire con TESI (il fornitore di T4MED) prima di iniziare lo sviluppo di gt4medServices.
Lacune critiche (impatto diretto sull'implementazione)¶
L1 — Formato risposta al POST /Appointment (Flusso A)¶
Problema: Il formato della risposta T4MED al Flusso A non è documentato.
Si assume che T4MED restituisca una singola risorsa Appointment con il campo "id" valorizzato con il T4MED Appointment ID (es. "T00450").
Attenzione: lo standard FHIR R4 prescrive che la risposta a un Bundle transaction sia un Bundle di tipo
"transaction-response". La risposta con singola Appointment costituisce una deviazione [D02].
Impatto: il parser della risposta in gt4medServices dipende dal formato confermato. Sono state preparate due implementazioni:
- Variante T4MED (assunta):
appointment.Id→"T00450" - Variante FHIR R4 standard:
bundle.Entry[n].Response.Location→"Appointment/T00450/_history/1"→.Split('/')[1]→"T00450"
L4 — T4MED Patient ID = codice ospedaliero?¶
Problema: La specifica non indica quale sia il Patient ID usato nell'URL di T4MED.
Si ipotizza che coincida con il codice ospedaliero (es. Patient/4578934).
Impatto: URL di $generate-pdf (Flusso D) e riferimenti Patient/ nei messaggi FHIR.
Se confermato, gt4medServices può derivarlo direttamente senza lookup aggiuntivi.
L6 — Meccanismo di autenticazione verso le API T4MED¶
Problema: La specifica menziona "API Key + restrizione IP" senza precisare né il meccanismo HTTP né il significato esatto di "API Key".
Le varianti più comuni sono:
| Variante | Header |
|---|---|
| HTTP Basic Auth | Authorization: Basic <base64(utente:password)> |
| Bearer token | Authorization: Bearer <token> |
| Header custom | X-API-Key: <chiave> |
| Header custom alternativo | Authorization: ApiKey <chiave> |
Nei messaggi di esempio è stato usato Authorization: ApiKey <api-key> come ipotesi di lavoro.
Domande da porre a TESI:
- Qual è il tipo esatto di autenticazione?
- Quale header usare?
- Qual è il formato della chiave?
- Chi rilascia la chiave e come?
L8 — URL di base reale di T4MED¶
Problema: L'endpoint https://api.t4med.it/fhir è ipotetico.
Azione richiesta: Ottenere l'URL reale da TESI prima dello sviluppo, incluse eventuali differenze di path e gli URL degli ambienti di test/produzione.
L9 — DELETE fisico vs cancellazione logica (Flusso C)¶
Problema: Non è documentato se T4MED supporta DELETE fisico su Appointment.
Alcune implementazioni FHIR R4 restituiscono HTTP 405 Method Not Allowed sul DELETE e richiedono la cancellazione logica tramite:
Impatto: scelta della variante da implementare in gt4medServices. Entrambe le varianti sono documentate in samples/flusso-c-cancella-prenotazione.md.
Lacune secondarie¶
L2 — De-duplicazione paziente in T4MED¶
Se il paziente è già registrato, il Bundle con Patient potrebbe generare un duplicato.
Nei messaggi di esempio è stato usato il meccanismo FHIR conditional create (ifNoneExist). Da verificare se T4MED lo supporta.
L3 — Campi obbligatori della risorsa Patient in T4MED¶
La specifica non li definisce. I messaggi estesi includono: codice fiscale, codice ospedaliero, nome, cognome, data di nascita, sesso, luogo di nascita. Da confermare.
L5 — Ricerca per identifier esterno su Appointment¶
Non esiste un endpoint documentato per recuperare il T4MED Appointment ID a partire dall'ID CUP.
Conseguenza: gt4medServices deve persistere la mappatura CUP ID → T4MED Appointment ID su DB interno. Non è possibile recuperarla dinamicamente da T4MED.
L12 — Strategia di identificazione del paziente: merge anagrafico e rischio di disallineamento¶
Contesto e decisione presa: il codice ospedaliero del paziente è usato come identificativo univoco del paziente in tutti i sistemi coinvolti (MEDWARE, T4MED, CUP, REPO). In tutti i messaggi FHIR vengono trasmessi entrambi gli identificativi — codice ospedaliero e codice fiscale — nella risorsa Patient.identifier.
Rischio noto — Merge anagrafico: quando due cartelle anagrafica dello stesso paziente vengono fuse ("merge anagrafico"), uno dei due codici ospedalieri viene promosso a master e l'altro diventa slave (disattivato). Se questo evento non viene propagato a T4MED, si verifica il seguente disallineamento:
- MEDWARE conosce il paziente con il codice master (nuovo)
- T4MED conosce il paziente con il codice slave (vecchio)
In questo caso tutte le chiamate che usano il codice ospedaliero come Patient ID nell'URL di T4MED (Flusso D: Patient/{id}/$generate-pdf) falliranno o restituiranno dati di un paziente non aggiornato.
Alternativa valutata — Solo codice fiscale: il codice fiscale è un identificativo stabile e non soggetto a merge, ma è suscettibile di errori di inserimento (trascrizione errata, correzioni successive). Non è stato ritenuto sufficiente da solo.
Alternativa valutata — ID paziente nativo T4MED: ottenere da T4MED un proprio identificativo paziente da mantenere allineato in MEDWARE introduce un onere di sincronizzazione aggiuntivo considerato non sostenibile nella prima fase.
Decisione: mantenere il codice ospedaliero come identificativo primario del paziente in MEDWARE, T4MED, CUP e REPO (pur riconoscendo che nel REPO il codice fiscale è il riferimento prevalente). La politica di trasmissione è di inviare sempre entrambi — codice ospedaliero e codice fiscale — in modo che T4MED possa scegliere autonomamente quale usare e che future variazioni di policy non richiedano modifiche ai messaggi.
Domanda da porre a TESI:
- T4MED attua una politica di aggiornamento autonomo delle anagrafiche dopo un merge? Se il codice slave viene sostituito dal master in MEDWARE, T4MED è in grado di mantenere la coerenza senza intervento esterno?
L7 — ServiceRequest accettata nel Bundle del Flusso A?¶
La specifica T4MED indica solo Patient + Appointment nel Bundle. Non è chiaro se T4MED accetta anche una risorsa ServiceRequest che trasporta la ricetta (NRE) e il codice prestazione.
Impatto: se T4MED la rifiuta, può essere rimossa senza impatto sulla funzionalità core.
L10 — DocumentReference.identifier: codice fiscale o UniqueDocumentId?¶
Problema: La specifica T4MED indica di inserire il codice fiscale del paziente nell'identifier di DocumentReference. In FHIR R4, tuttavia, DocumentReference.identifier è il business identifier del documento, non del paziente. Il paziente è già referenziato tramite DocumentReference.subject.
Il valore semanticamente corretto per DocumentReference.identifier è il UniqueDocumentId del referto — ovvero l'identificativo univoco assegnato al documento al momento della pubblicazione su REPOSITORY (tipicamente nella forma <OID-repository>^<progressivo> o un UUID).
Le due varianti sono entrambe documentate in samples/flusso-e-upload-referto-firmato.md.
Domande da porre a TESI:
- Confermare se T4MED richiede davvero il codice fiscale nell'
identifierdiDocumentReference. - Se sì, è possibile includere anche il UniqueDocumentId come secondo elemento dell'array
identifier? - T4MED usa il codice fiscale come chiave di ricerca per recuperare i documenti del paziente?
L11 — Referto sostitutivo e annullativo non coperti dall'upload (Flusso E)¶
Problema: La specifica T4MED per il Flusso E descrive esclusivamente la prima pubblicazione di un referto (versione 1). Non sono documentati i casi di:
- Referto sostitutivo (versione N > 1): un nuovo documento che sostituisce il precedente, da collegare all'originale tramite
DocumentReference.relatesToconcode = "replaces". - Referto annullativo: revoca di un documento già pubblicato, che in FHIR R4 si gestisce con
DocumentReference.status = "entered-in-error"sull'originale (richiede unPUToPATCHsulDocumentReferenceesistente).
Questi scenari esistono nel contesto FSE 2.0 e sono gestiti regolarmente da altri sistemi (REPO, gefidServices). Se T4MED non li supporta, i referti annullati o sostituiti su REPO/FSE rimarranno in stato attivo su T4MED.
Domande da porre a TESI:
- T4MED supporta il caricamento di referti sostitutivi (con
relatesTo.code = "replaces")? - T4MED supporta l'annullamento di un DocumentReference già caricato?
- Se sì, qual è il meccanismo atteso (PUT con
status = "entered-in-error", DELETE, altro)?
Riepilogo — Domande per TESI¶
| # | Domanda | Impatto |
|---|---|---|
| L1 | Formato risposta al POST /Appointment: singola Appointment o Bundle transaction-response? | Parser risposta Flusso A |
| L4 | T4MED Patient ID = codice ospedaliero? | URL Flusso D |
| L6 | Tipo autenticazione, header, formato chiave? | Tutte le chiamate API |
| L8 | URL base reale di T4MED (test e prod)? | Configurazione gt4medServices |
| L9 | DELETE fisico supportato? O solo cancellazione logica? | Implementazione Flusso C |
| L2 | ifNoneExist supportato per de-duplicazione Patient? |
Flusso A |
| L7 | ServiceRequest accettata nel Bundle del Flusso A? | Flusso A esteso |
| L10 | DocumentReference.identifier: codice fiscale o UniqueDocumentId? Possibile includere entrambi? |
Flusso E |
| L11 | Referto sostitutivo (relatesTo.code = "replaces") supportato? Annullativo (status = "entered-in-error") supportato? |
Flusso E |
| L12 | T4MED aggiorna autonomamente le anagrafiche paziente dopo un merge? (rischio disallineamento codice ospedaliero master/slave) | Flussi A/B/C/D/E |