Closed BiMind closed 1 year ago
Buongiorno, ci sono novità?
Linkiamo la PR https://github.com/ministero-salute/it-fse-accreditamento/pull/180
Buongiorno, riportiamo in allegato i cda richiesti. Rimaniamo a disposizione nel caso in cui fosse necessario ulteriore supporto.
f773766e72fbd443.txt 166ab5d17ffaae6e.txt bb09f9497d1671c1.txt f3e2cdf75686c4de.txt
Buonasera @IStacchiotti, Ci scusiamo preventivamente per la risposta lunga, ma la maggior parte degli errori che ci vengono notificati sembrano non seguire le specifiche HL7.
Abbiamo confrontato i CDA2 ed effettivamente vediamo che non abbiamo inserito gli attributi ID nei tag section. Notiamo però una differenza tra gli attributi ID presenti negli errori e quelli presenti nei CDA2 di esempio https://github.com/ministero-salute/it-fse-support/tree/main/doc/esempi/CDA
Ad esempio per LDO, nella section relativa al motivo del ricovero, leggiamo nell'esempio "Motivo_del_Ricovero", mentre nel file degli errori il vostro programma di verifica cerca "Motivo_Ricovero". Dove possiamo trovare una lista aggiornata di questi ID che vi aspettate?
Per quanto riguarda gli altri errori: Test case: 147 RSA_CT1
CONF-RSA-18:, L’elemento <act> PUÒ contenere uno o più elementi <entryRelationship> utili a descrivere, mediante differenti ClinicalStatement, le procedure operative eseguite associabili alla specifica prestazione.
Nel nostro CDA2, il tag entryRelationship non è presente visto che è OPZIONALE non obbligatorio, ma ci vengono notificati due errori per la mancanza degli attributi classCode e moodCode nel tag entryRelationship/procedureTest case: 6 LDO_CT1
CONF-LDO-98: La sezione "Motivo del ricovero" PUÒ contenere un elemento 1650 <entry>/<observation>. Tale <observation>, se presente, DEVE contenere un elemento <code> valorizzato con l’attributo @code = "8646-2" e @root = "2.16.840.1.113883.6.1" e PUÒ contenere un elemento <value> che descrive la diagnosi di ammissione, avente l’attributo @xsi:type=”CD”; l’attributo @code derivato dal dizionario IDC9CM e l’attributo @root uguale a "2.16.840.1.113883.6.103”.
Nel nostro CDA2, l'entry non è presente visto che è OPZIONALE non obbligatoria, ma ci vengono notificati 8 errori
Per l'attributo displayName della sezione relativa al decorso ospedaliero, il vostro programma di verifica cerca un valore pari a "Decorso_ospedaliero Decorso ospedaliero", mentre nelle specifiche abbiamo
Qual è la valorizzazione corretta?
CONF-LDO-172: La sezione “Condizioni del paziente alla dimissione e diagnosi” 3285 DOVREBBE contenere un elemento <entry>/<observation>. Se presente, tale Observation: DEVE contenere un elemento <code> valorizzato con l’attributo @code = "8651-2" e @root = "2.16.840.1.113883.6.1" e PUÒ contenere un elemento <value> che descrive la diagnosi alla dimissione, avente l’attributo @xsi:type=”CD”; l’attributo @code derivato dal dizionario IDC9CM e l’attributo @root uguale a 3290 "2.16.840.1.113883.6.103”
. Nel nostro CDA2, non è presente l'elemento entry visto che è RACCOMANDATO non obbligatorio, ma ci vengono notificati 8 errori
Test case: 150 RSA_CT4
Ci confermate che la sezione relativa al quesito diagnostico debba avere come title "Quesito Diagnostico", nell'esempio delle specifiche è valorizzato con "Quesito diagnostico"
Il tag entry del quesito diagnostico è OPZIONALE, ma ci vengono notificati 8 errori relativi alla mancanza di questo tag
CONF-RSA-112: La sezione Storia Clinica PUÒ essere costituita da una o più 1530 elementi <entry> che riportano le informazioni codificate relative alle diverse tipologie di anamnesi.
Nel nostro CDA2, non è presente l'elemento entry visto che è OPZIONALE non obbligatorio, ma ci vengono notificati 36 errori legati alla mancanza di questo tag
CONF-RSA-136: La sezione Storia Clinica PUÒ contenere una ed una sola sottosezione “Allergie”.
Nel nostro CDA2, non è presente la sezione Allergie visto che è OPZIONALE non obbligatoria, ma ci vengono notificati 24 errori legati all'assenza di questo elemento
CONF-RSA-163: La sezione Storia Clinica PUÒ contenere una ed una sola sottosezione “Terapia Farmacologia in Atto”.
Nel nostro CDA2, non è presente l'elemento terapia farmacologica in atto visto che è OPZIONALE, ma ci vengono notificati 8 errori per la sua assenza
CONF-RSA-171: Il documento PUÒ contenere una ed una sola sottosezione “Precedenti Esami Eseguiti”
Nel nostro CDA2, non è presente l'elemento Precedenti esami eseguiti visto che è OPZIONALE, ma ci vengono notificati 9 errori per la sua assenza
CONF-RSA-189: Il documento PUÒ contenere una ed una sola sottosezione 2805 “Confronto con Precedenti Esami Eseguiti”
Stessa cosa qui, 5 errori per la mancanza di questo elemento
CONF-RSA-196: Il documento PUÒ contenere una ed una sola sezione “Diagnosi”
Stessa cosa, 13 errori per la mancanza dell'elemento Diagnosi
CONF-RSA-201: Il documento PUÒ contenere una ed una sola sezione “Conclusioni”
. Stesso comportamento qui. 5 errori per la mancanza di questo elemento
CONF-RSA-205: Il documento PUÒ contenere una ed una sola sezione “Suggerimenti per il Medico Prescrittore”
. 5 errori per la mancanza di questo elemento
CONF-RSA-209: Il documento PUÒ contenere una ed una sola sezione 3065 “Accertamenti e Controlli Consigliati”
. 7 errori per la mancanza di questo elemento
CONF-RSA-216: Il documento PUÒ contenere una ed una sola sottosezione 3150 “Terapia Farmacologia Consigliata”.
. 14 errori per la mancanza di questo elemento
Test case: 9 LDO_CT4 Per brevità, tralasciamo gli errori per mancanza di dati OPZIONALI
Grazie
Buonasera, rispondiamo in merito ai punti di perplessità da lei sollevati. In dettaglio:
Buongiorno, grazie per il gentile riscontro.
Visto che gli elementi opzionali richiesti dai test in questione non sono previsti nella nostra implementazione, setteremo questi test case come non applicabili. Essendo questi documenti stati validati dal gateway, siamo tranquilli che gli elementi opzionali che abbiamo inserito siano corretti dal punto di vista sintattico.
Aggiungiamo una nota sull'ultimo punto del test case 9 LDO_CT4, l'errore che abbiamo nel json è questo
{
"id" : 9,
"error" : "VERIFICA_NON_SUPERATA",
"description" : "<error code='027' attribute='code' actual = '' expected = '30954-2 47519-4'>ClinicalDocument/component/structuredBody/component/section[ID='Esami_eseguiti_durante_il_ricovero']/code</error>"
}
Sembra che il vostro programma di validazione cerchi entrambi i codici, 30954-2 e 47519-4
Buongiorno,
lo scorso 11 Maggio, dopo circa 2 settimane dalla ricezione della mail riguardo il corretto superamento dei test, abbiamo ricevuto la seguente comunicazione:
Dall’analisi delle pull inserite non risulta applicabile nessun caso di test OK. Al fine di verificare la corretta comunicazione con il Gateway per il processo di accreditamento, sarebbe necessario che ci forniste timestamp-traceid-workflowinstanceid di una invocazione recente effettuata verso il Gateway e che abbia ricevuto un esito positivo.
Di seguito le info richieste per LDO:
Gentilmente, chiediamo un rapido riscontro
Grazie
Buongiorno, per allineamento riportiamo il contenuto inviato anche per email:
Buongiorno,
dalle analisi effettuate non ci risultano popolati i seguenti campi subject_application_id, subject_application_vendor, subject_application_version, come indicato su [https://developers.italia.it/it/fse/.](https://developers.italia.it/it/fse/)
Le chiederemo cortesemente di effettuare delle nuove invocazioni al Gateway.
Saluti,
Il Team FSE 2.0
Buongiorno, I campi subject_application_id, subject_application_vendor, subject_application_version nel JWT sono popolati rispettivamente con Human, BiMind e 10.6. Abbiamo rispettato le specifiche.
Non ci è chiaro se a voi risultano vuoti o valorizzati in modo non corretto
Da ulteriori verifiche abbiamo notato che nel JWT di Signature che sta inviando non stanno arrivando i campi
subject_application_id
/ subject_application_vendor
/ subject_application_version
Potrebbe verificare come sta generando i token? Se ha necessità di verificare il contenuto dei token generati, può usufruire del tool online https://jwt.io/
Buongiorno, per la generazione del token JWT utilizziamo il tool da voi fornito https://github.com/ministero-salute/it-fse-gtw-tools
Ci è stato notificato via Slack che questo tool effettivamente non inseriva nel JWT di signature i claim subject_application_id, subject_application_vendor, subject_application_version, da ieri richiesti come obbligatori. Ora questo problema è stato risolto con una nuova release e abbiamo di conseguenza adeguato la nostra implementazione.
Di seguito i dati richiesti a completamento dei test di accreditamento riguardo RSA:
Per LDO, invece, abbiamo questo errore nella validazione del JWT: {"traceID":"fd31dc4660f0101c","spanID":"fd31dc4660f0101c","type":"/msg/jwt-validation","title":"Campo token JWT non valido.","detail":"Il codice fiscale nel campo sub non è corretto","status":403,"instance":"/jwt-mandatory-field-malformed","workflowInstanceId":"UNKNOWN_WORKFLOW_ID"}
Il campo sub viene valorizzato in questo modo: MDCSRU58T23E670H^^^&2.16.840.1.113883.2.9.4.3.2&ISO Il codice fiscale del medico corrisponde a quello riportato in ClinicalDocument/author/assignedAuthor/id/@extension e in ClinicalDocument/legalAuthenticator/assignedEntity/id/@extension
Ci potreste dare delucidazioni rispetto a questo errore?
In attesa di riscontro
Buongiorno,
tramite tool online di validazione dei codici fiscali, sembrerebbe che il valore MDCSRU58T23E670H
utilizzato nel sub non sia corretto
Potrebbe verificare se sta utilizzando il valore corretto e riprovare?
Buon pomeriggio, si confermiamo che, essendo un test, abbiamo utilizzato dei codici fiscali fittizi. Prima di oggi non ci avevano mai dato problemi durante la validazione con il gateway.
Abbiamo ricreato il documento valorizzando il codice fiscale del medico con un cf valido. Di seguito le info richieste a completamento dei test per LDO:
Per completezza riportiamo nuovamente anche le info per RSA:
Restiamo in attesa di un gentile riscontro, grazie
Buonasera, Le confermiamo l'avvenuta verifica dei test inviati, per cui dovrebbe aver già ricevuto esito via mail. La presente viene pertanto chiusa come risolta. Si può procedere con la riapertura nel caso fosse necessario ulteriore supporto. Grazie
Buongiorno, Per 4 test case (6, 9, 147, 150), abbiamo ricevuto degli errori di tipo PDF_UNEXPECTED_CDA, "CDA contenuto nel PDF non conforme a quello associato al TraceID".
Questi errori hanno portato a una serie di altri errori di tipo "VERIFICA_NON_SUPERATA" in cui ci viene notificata una mancata valorizzazione di alcuni dati che in realtà sono presenti nel CDA2 inglobato nel PDF.
Ci potreste fornire i CDA2 che risultano associati ai seguenti TraceID, così che possiamo controllare?
Grazie per il supporto