VERIFICHE E APPROVAZIONI
Specifica di servizi GPA pagoPA e S.I. dell’ASR
VERIFICHE E APPROVAZIONI
VERS. | REDAZIONE | CONTROLLO APPROVAZIONE | AUTORIZZAZIONE EMISSIONE | |||
NOME | DATA | NOME | DATA | NOME | DATA | |
V01 | X. XXXXXXX | 30/09/2018 | X. XXXXXXXXX X. XXXXXXX | 01/10/2018 | M. ITALIANO X. XXXXXXXXX | 05/10/2018 |
V02 | X. XXXXXXX | 16/10/2018 | X. XXXXXXXXX X. XXXXXXX | 17/10/18 | M. ITALIANO X. XXXXXXXXX | 17/10/18 |
V03 | X. XXXXXXX | 07/11/2018 | X. XXXXXXXXX X. XXXXXXX | 08/11/18 | M. ITALIANO X. XXXXXXXXX | 08/11/18 |
V04 | X. XXXXXXX | 05/12/2018 | X. XXXXXXXXX X. XXXXXXX | 12/12/18 | M. ITALIANO X. XXXXXXXXX | 12/12/18 |
V05 | X. XXXXXXX | 27/12/2018 | X. XXXXXXXXX X. XXXXXXX | 28/12/18 | M. ITALIANO X. XXXXXXXXX | 28/12/18 |
V06 | X. XXXXXXX | 08/02/2019 | X. XXXXXXXXX X. XXXXXXX | 08/02/19 | M. ITALIANO X. XXXXXXXXX | 08/02/19 |
V07 | X. XXXXXXX | 06/03/2019 | X. XXXXXXX | 06/03/19 | M. ITALIANO | 07/03/19 |
V08 | X. XXXXXXX | 03/04/2019 | X. XXXXXXX | 04/04/19 | M. ITALIANO | 05/04/19 |
V09 | EXPRIVIA | 25/05/2020 | X. XXXXXXX | 25/05/20 | M. ITALIANO | 25/05/20 |
V10 | X. XXXXXXX | 10/06/2020 | X. XXXXXXX | 10/06/2020 | M. ITALIANO | 10/06/2020 |
V11 | X. XXXXXXX | 15/06/2020 | X. XXXXXXX | 15/06/2020 | M. ITALIANO | 15/06/2020 |
V12 | X. XXXXXXX | 09/09/2020 | X. XXXXXXX | 09/09/2020 | M. ITALIANO | 09/09/2020 |
V13 | X. XXXXXXX | 10/09/2020 | X. XXXXXXX | 10/09/2020 | M. ITALIANO | 10/09/2020 |
V14 | X. XXXXXXX | 22/12/2020 | X. XXXXXXX | 22/12/2020 | M. ITALIANO | 22/12/2020 |
V15 | X. XXXXXXX | 16/03/2021 | X. XXXXXXX | 16/03/2021 | M. ITALIANO | 16/03/2021 |
V16 | EXPRIVIA | 31/03/2021 | X. XXXXXXX | 31/03/2021 | M. ITALIANO | 31/03/2021 |
V17 | EXPRIVIA | 26/04/2021 | X. XXXXXXX | 26/04/2021 | M. ITALIANO | 26/04/2021 |
V18 | X. XXXXXXX | 14/05/2021 | X. XXXXXXX | 14/05/2021 | M. ITALIANO | 14/05/2021 |
V18A | X. XXXXXXX | 28/05/2021 | X. XXXXXXX | 28/05/2021 | M. ITALIANO | 28/05/2021 |
V19 | X. XXXXXXX X. XXXXXXX | 02/09/2021 | X. XXXXXXX | 02/09/2021 | M. ITALIANO | 02/09/2021 |
V20 | X. XXXXXXX | 28/01/2022 | X. XXXXXXX | 28/01/2022 | M. ITALIANO | 28/01/2022 |
V21 | X. XXXXXXX | 24/02/2022 | X. XXXXXXX | 24/02/2022 | M. ITALIANO | 24/02/2022 |
V22 | X. XXXXXXX | 31/03/2022 | X. XXXXXXX | 31/03/2022 | M. ITALIANO | 31/03/2022 |
V23 | X. XXXXXXX X. XXXXXXX | 27/02/2023 | X. XXXXXXX | 27/02/2023 | X. XXXXXXX | 27/02/2023 |
V24 | X. XXXXXXX | 04/04/2023 | X. XXXXXXX | 04/04/2023 | X. XXXXXXX | 04/04/2023 |
V25 | X. XXXXXXX X.XXXXXXX | 21/03/2024 | X. XXXXXXX | 21/03/2024 | X. XXXXXXX | 21/03/2024 |
STATO DELLE VARIAZIONI
VERS. | PARAGRAFO O PAGINA | DESCRIZIONE DELLA VARIAZIONE |
V01 | Tutto il documento | Versione iniziale. |
V02 | 2.12.1.2 2.13.1.3 | Correzione valorizzazione tag AZIONE e tipizzazione dei tag. Inserito ulteriore specifica di ignorare i tag esposti dal WSDL non citati nella request. |
2.13.2.2 2.13.2.3 | Correzione valorizzazione tag AZIONE e tipizzazione dei tag. Correzione valorizzazione tag AZIONE e tipizzazione dei tag. Inserito ulteriore specifica di ignorare i tag esposti dal WSDL non citati nella request. | |
V03 | 2.13.2.2 | Correzione obbligatorietà del tag NUMERO_PRATICA. |
V04 | 1.3 | Aggiornamento esempio relativo alla SetTicketAcquisiti. |
2.12.6.2 | Correzione costrutto ERRORE, rinomina tag DESCRIZIONE con MESSAGGIO. | |
V05 | 2.12.3.3 | Correzione tag <PRECENTUALE_IVA> in <PERCENTUALE_IVA> sugli output dei metodi SetAvvenutoPagamento, GetListaTicket. |
2.12.4.3 | ||
V06 | 2.12.4.3 | Inserimento tag LISTA_TICKET e LISTA_REGISTRAZIONE_PAGAMENTI_DIFFERITI nella struttura di output. |
V07 | 1.2, 2.4, 2.5, 2.12.1.3, 2.12.4.3, 2.12.5.3 | Aggiunto riferimento [A17] Aggiunti per completezza codici di errore 9° e 9B (già presenti nel paragrafo 2.12.6.2). Aggiunto codice di errore 802 per la segnalazione dell’importo da rimborsare. |
V08 | 2.12.1.2, 2.12.1.3, 2.12.2.3, 2.12.3.2, 2.12.3.3, 2.12.4.3 | Eliminato la valorizzazione del tag APPLICATION_CODE (rimane non valorizzato per limitare l’impatto su sviluppi già esistenti). |
2.12.2.3 | Oltre all’eliminazione della valorizzazione del tag APPLICATION_CODE, viene dato indicazione su come valorizzare i tag COMUNE_APPUNTAMENTO, INDIRIZZO_APPUNTAMENTO, PROVINCIA_APPUNTAMENTO, CAP_APPUNTAMENTO. | |
V09 | • Modificate request e response del servizio SetAvvenutoPagamento per consentire al SIA la ricezione dell’avvenuta erogazione di un rimborso (totale o parziale) e la restituzione dei dati aggiornati dello stesso. Per transitività anche la SetOpposizionePrecompilazione730 eredità gli aggiornamenti. • Modificata la response del servizio GetListaTicket per introdurre i tag utili a restituire i dati dei ticket da rimborsare. • Modificata la response del servizio GetImportoTicket per introdurre i tag utili a restituire alcuni dei dati dei ticket da rimborsare. • Modificati i par 3.8 e 3.9. • Introdotti il par 3.10 e 3.11. • Modificata la response dei servizi SetAvvenutoPagamento, SetOpposizionePrecompilazione730, GetListaTicket, GetImportoTicket introducendo sotto il tag RIMBORSO il tag PRATICA_PAGATA_CON_CREDITO. • Eliminato il tag LISTA_RIMBORSI dalla response di GetImportoTicket | |
V10 | TUTTO IL DOCUMENTO | Aggiornamento lunghezza IUV nel modello 3. Aggiornamento esempio di response del metodo GetMultiIUVGPA in allegato [A15]. |
V11 | Dettagliato nelle sezioni “Interfaccia di output” dai servizi GetImportoTicket, GetListaTicketCF il contenuto del tag IMPORTO_DA_PAGARE da ritornare come somma di importo ticket, bollo ed IVA. |
Specificato inoltre lo stesso tag nei tracciati tornati da SetAvvenutoPagamento e GetListaTicket senza bollo ed IVA. | ||
V12 | N.A. | Correzione valorizzazione tag FLAGTIPOSPESA e TIPOSPESA negli esempi in allegati A08. Inserimento pdf allegato A07. |
V13 | Par. 2.7 | Inserito il dettaglio relativo ai dati anagrafici dei pazienti certificati in Aura. |
Par. 2.12.1.3, 2.12.2.3, 2.12.3.3, 2.12.4.3 | Eliminazione del riferimento ad Aura. | |
Par. 2.12.3.3, 2.12.5.3 | Depennato il refuso sulla codifica dei pagamenti parziali. | |
V14 | Par. 2.2 | Eliminazione metodo GetRicevutaFiscaleFattura (barrato). |
Par. 2.12.5 | Eliminazione metodo GetRicevutaFiscaleFattura (il paragrafo verrà barrato per non modificare la numerazione dei paragrafi). | |
V15 | Par. 2.12.3.2 | Specificato nel dettaglio l’utilizzo del tag IMPORTO_PRATICA in caso di rimborsi. |
V16 | Tutto il documento | MEV 2.4/2021: E’stato specificato che è possibile popolare il campo CODICE_FISCALE con la partita iva, in caso di persona giuridica, nella costruzione delle response dei WS GetImportoTicket, GetListaTicketCF, SetAvvenutoPagamento e SetOpposizionePrecompilazione730, GetListaTicket nonché nella costruzione della request del WS GetSingleIUVGPA richiamato sul GPA. Specificare inoltre che il WS GetListaTicketCF potrà ricevere un CODICE_FISCALE di 11 cifre nella request. |
2.12.1.3,2.12.2.3, 2.12.3.3, 2.12.4.2, 3.12 | MEV 2.4/2021 (dopo revisione) • Modificate le indicazioni per avvalorare il tag PAZIENTE nelle response di GetImportoTicket, GetListaTicketCF, SetAvvenutoPagamento e GetListaTicket nel caso di pagamenti associati ad una persona giuridica • Aggiuntato il riferimento all’allegato A06 e corretti tutti i riferimenti sbagliati all’allegato A07 facendoli puntare all’A06. MEV 2.9/2021: • MEV 2.9/2021: modificate le response di GetListaTicket, GetImportoTicket, SetAvvenutoPagamento e specularmente SetOpposizionePrecompilazione730 e per specificare con quale valore popolare il tag TIPOSPESA nel caso in cui si voglia impedire l’invio del relativo pagamento al SistemaTS. • Introdotto il paragrafo 3.12 per specificare che oltre ai valori standard che è possibile utilizzare per popolare il tag TIPOSPESA è anche possibile per le aziende definire ed utilizzare un valore speciale utile per istruire il GPA di non inviare al SistemaTS i dati di uno specifico pagamento. | |
V17 | MEV 2.9/2021: modificate indicazioni per popolare le response di GetListaTicket, SetAvvenutoPagamento e specularmente di SetOpposizionePrecompilazione730 allo scopo di: • introdurre il tag PAGAMENTO_TRACCIATO; • modificare la semantica del PERCENTUALE_IVA in modo da ospitare in alternativa alla aliquota IVA percentuale anche la natura IVA. • Introdotto il par 3.13 per dettagliare come popolare il tag. | |
V18 | 2.13.3 | Metodo per assegnare una posizione debitoria ad uno IUV modello 3. |
V18A | AVVISO IMPORTANTE PRIMA DI IMPLEMENTARE LA MODIFICA È in corso l’aggiornamento del GPA per quanto riguarda l’integrazione con SOGEI per la trasmissione dei pagamenti sanitari al fine del calcolo del 730. Tale aggiornamento non si è ancora concluso. Per cui prima di procedere con lo sviluppo delle modifiche introdotte nella versione V17 contattare il CSI per concordare le date di avvio dei test di integrazione. |
V19 | 1.2 | Modifica esempio [A10], sostituito <OPPOSIZIONE_730></OPPOSIZIONE_730> con </OPPOSIZIONE_730>. |
2.8 | Aggiunte nuove codifiche già in uso. | |
2.12.3.2 | Correzione della nota 8 a pagina 28 con esempio: </OPPOSIZIONE_730>. | |
2.12.1.3, 2.12.2.3, 2.12.3.3 2.12.4.3 | Modifica obbligatorietà dati della sezione PAZIENTE. | |
2.13.1.1, 2.13.2.1, 2.13.3.1 | Dettagliato l’utilizzo dei servizi GetMultiIUVGPA, GetSingleIUVGPA e SetAssociazioneIUVTicketGPA. | |
V20 | 2.12.3 | Dettaglio numero_ricevuta in input al metodo setavvenutopagamento in configurazione 7,8 e 9. |
V21 | 2.12 | Generazione dell’identificativo di pagamento e della ricevuta/fattura da consegnare al paziente. |
2.12.1.2, 2.12.1.3, 2.12.2.2, 2.12.2.3, 2.12.3.2, 2.12.3.3, 2.12.4.2, 2.12.4.3, 2.12.6.2, 2.12.6.3, 2.12.7.2 | Revisione della descrizione dell’elenco dei tag previsti nelle request e response. | |
V22 | 2.4 2.13.1 | Aggiornamento elenco dei codici azioni (modifica e refuso); modifica codice azione per il servizio GetMultiIUV. |
2.12.7.3 | MEV 2.9/2021: esplicitato l’intervento da applicare anche alla response del WS SetOpposizionePrecompilazione730. | |
V23 | 2.12.3.4 | Correzione indicazioni della gestione soap fault. |
2.12.1.3, 2.12.2.3, 2.12.3.3, 2.12.4.3 | Corretta lunghezza IUV in output dei servizi GetImportoTicket, GetListaTicketCF, SetAvvenutoPagamento e GetListaTicket. | |
2.12.1.3, 2.12.2.3, 2.12.3.3, 2.12.4.3 | Specificata lunghezza CAP in output dei servizi GetImportoTicket, GetListaTicketCF, SetAvvenutoPagamento e GetListaTicket. | |
V24 | 2.3 2.12.1.1, 2.12.2.1, 2.12.3.1, 2.12.4.1, 2.12.6.1, 2.12.7.1 | Specificato il vincolo sul time-out imposto da PagoPA S.p.A. per tutti i servizi esposti da una Azienda Sanitaria. |
V25 | 2.2.1 | Aggiornamento paragrafo di change log. |
2.13 | Par. 2.13 Introduzione dei metodi esposti in internet dal GPA e Authorization Server per poterli utilizzare. Cap. 2.13.1 Inserimento della richiesta del Bearer Token. Slittamento capitoli: il precedente cap. 2.13.1 diventa 2.13.2 e così via. Il contenuto di questi capitoli non è stato modificato. | |
1.2 2.12.3.1, 3.8 | Rimborsi: cambiato il riferimento al prodotto Fascicolo Finanziario con quello di Estratto conto, ed aggiunto l’URL all’applicativo. | |
2.12.3.1, 2.12.3.2 | Specificato come comportarsi in caso di OPPOSIZIONE_730 non valorizzato nella SetAvvenutoPagamento. | |
3 | Il capitolo delle FAQ non verrà più aggiornato. Al suo posto tutte le FAQ saranno accentrate nel documento “FAQ specifiche di integrazione SERVIZI al GPA PagoPA-V05”. |
INDICE
7
2 SERVIZIO DI INTEGRAZIONE GPR
10
2.5 CODIFICA ERRORI GESTITI E STATO DELLA PRATICA 12
2.7 ANAGRAFICA DEL PAZIENTE 12
2.8 CODIFICA MOTIVO PAGAMENTO 12
2.11 Struttura del Numero Pratica 14
2.12 DESCRIZIONE DELL’INTERFACCIA DEI SERVIZI ESPOSTI DAL S.I. DELL’ASR 15
2.12.1 Operazione: GetImportoTicket 15
2.12.2 Operazione: GetListaTicketCF 24
2.12.3 Operazione: SetAvvenutoPagamento 30
2.12.4 Operazione: GetListaTicket 41
2.12.5 Operazione: GetRicevutaFiscaleFattura 51
2.12.6 Operazione: SetTicketAcquisiti 53
2.12.7 Operazione: SetOpposizionePrecompilazione730 55
2.13 DESCRIZIONE DELL’INTERFACCIA ESPOSTO DAL GPA 58
2.13.1 Operazione: Richiesta di un Bearer Token e introduzione della Authorization Bearer nelle request .58 2.13.2 Operazione: GetMultiIUVGPA 58
2.13.3 Operazione: GetSingleIUVGPA 60
2.13.4 Operazione: SetAssociazioneIUVTicketGPA 61
64
3.1 Codifica errori gestiti 64
3.2 Importi e separatore decimali 64
3.3 Numero Ricevuta / Quietanza 64
3.4 Campi Anagrafica Paziente 64
3.5 Campo Note Appuntamento e Descrizione Prestazione 64
3.6 Gestione di elenchi corposi di prestazioni (es. Laboratorio Analisi) 64
3.7 Gestione pratiche annullate 65
3.8 Gestione pratiche rimborsate e da rimborsare 65
3.9 Gestione della variazione di importo e rimborsi 65
3.10 Definizione delle modalità di erogazione rimborso 65
3.11 Definizione operatori a cui notificare le avvenute erogazioni dei rimborsi 65
3.12 Popolamento del tag TIPOSPESA ed inibizione dell’invio del ticket al SistemaTS 65
3.13 Popolamento del tag PERCENTUALE_IVA 66
Il presente documento fornisce le specifiche di integrazione necessarie per integrare al GPA pagoPA (Gateway dei Pagamenti Aziendale) i servizi produttori di richieste di pagamento (ticket, fatture di libera professione) all’interno di una delle ASR abilitate al GPA pagoPA stesso.
La nuova versione GPA pagoPA differisce dalla versione precedente, rilasciata nel 2013, perché consentirà la gestione dei pagamenti con canale pagoPA, il pagamento della libera professione, l’assegnazione dell’identificativo di pagamento e l’emissione della ricevuta di pagamento emessa dal Sistema Informativo (S.I.) dell’ASR. Per realizzare le nuove funzionalità di pagamento con canale pagoPA il GPA pagoPA esporrà al S.I. dell’ASR dei nuovi servizi WSDL.
Il pagamento cosiddetto pagoPA consentirà al paziente di scegliere il prestatore di servizio di pagamento da cui desidera pagare la propria pratica. Il Prestatore di Servizio di Pagamento (PSP) è un soggetto, abilitato dalle norme vigenti in materia, ad eseguire le richieste di pagamento in via elettronica ed a restituire la ricevuta elettronica di avvenuto pagamento/incasso. L’infrastruttura pagoPA ha il vantaggio di consentire al cittadino di scegliere il PSP tra i vari che aderiscono al sistema, confrontando le commissioni, indipendente dal provider di pagamento e dal tipo di servizio per cui lo si sta effettuando.
Il GPA pagoPA consentirà di gestire pagamenti avviati dal paziente presso il portale della pubblica amministrazione (PTW), in questo caso si parla di pagamenti secondo il modello 1, oppure pagamenti avviati dal paziente presso i locali o attraverso l’infrastruttura predisposta dal PSP, in questo caso si parla di pagamenti secondo il modello 3.
1.1 CONTESTO
Al fine di rendere più chiare le specifiche di integrazione, nel seguito sono elencati gli attori coinvolti e relative funzioni.
• SOGEI: Offre una soluzione informatica a supporto della corretta archiviazione dei dati di pagamento per l’invio a SOGEI per la generazione del 730 precompilato.
• BANCA TESORIERA: La struttura di credito (es. Unicredit Spa, Intesa San Paolo – Imi Spa, etc.), in base ad un affidamento aziendale, oltre ai servizi di tesoreria a favore dell’azienda stessa, offre all’utenza canali di pagamento specifici: fra essi i punti di riscossione automatici (es. punti gialli o punti rossi) o sportelli ubicati nelle proprie filiali.
• GESTORE DEI PAGAMENTI AZIENDALE: è il servizio di gateway che consente di gestire pagamenti a favore di diverse aziende sanitarie. Il servizio è in grado di gestire più canali di pagamento verso il Sistema Informativo Aziendale.
• SISTEMA INFORMATIVO AZIENDALE: il singolo sistema informativo aziendale con i quali può interagire il GPA pagoPA; è il sistema che calcola e produce le richieste di pagamento, oggetto dei pagamenti di cui trattasi nel presente progetto (CUP, LIS, RIS, …).
• PORTALE DEL CITTADINO: è il portale regionale (PTW) dal quale è possibile accedere all’elenco delle richieste di pagamento pagati o da pagare ed eseguire un pagamento.
1.2 RIFERIMENTI
Num. | Riferimento | Data | Autore | Descrizione |
[A01] | sgt.wsdl | Maggio 2018 | WSDL che il servizio generatore di ticket deve esporre per integrarsi con il GPA | |
[A02] | Novembre 2013 | Xxxxxxx Xxxxxxx | Xxxxxxxxxx identificativo ticket regionale e identificativo per pagamenti | |
[A04] | specifiche_integrazione_servizi_GP R-V06q.zip | Aprile 2018 | CSI | Specifiche di integrazione dei sistemi informativi aziendali produttori di ticket (CUP, LIS..) |
[A05] | xxxx://xxx.xxxx.xxx.xx/xxxxx/xxxxxxx/xx les/regole_tecniche/guidatecnica_a vvisoanalogico_1_2.pdf | Giugno 2016 | AgID | Avviso di pagamento nel sistema pagoPA |
xxxxx://xxx.xxxx.xxx.xx/xx/xxxxxxxxxxx/x agopa/linee-guida-documentazione- tecnica, link "Il NUOVO AVVISO DI PAGAMENTO ANALOGICO NEL SISTEMA PAGOPA Versione 2.1" | Maggio 2018 – valido a partire da dicembre 2018 | |||
[A06] | xxxxx://xxxxxxxxx0.xxxxxx.xxxxxxx.xx/x ortale/documents/20182/34450/730 +Spese+Sanitarie+- +WS+Asincrono+- +Invio+dati+di+spesa++sanitaria+2 0_12_2020.pdf/4c2acd7d-3a0b- 13f4-27eb-a02ff8bf9c1f | Documento pubblicato il 06/8/2015 e aggiornato il 20/12/2020 | Sistema Tessera Sanitaria | Specifiche tecniche per lo sviluppo dei web service asincroni per la trasmissione dei dati di spesa sanitaria |
[A07] | xxxxx://xxxxxxxxx0.xxxxxx.xxxxxxx.xx/x ortale/spese-sanitarie/documenti-e- specifiche-tecniche-ricevute-e- codici-di-errore | Luglio 2015 | PROGETTO TESSERA SANITARIA ACQUISIZIONE DATI DI SPESA SANITARIA AI FINI DEL 730 PRECOMPILAT O DM 31 LUGLIO 2015 TABELLA ERRORI | Elenco dei controlli eseguiti sui dati contenente gli aggiornamenti dello stato delle pratiche. Dati che il GPA riceve dal S.I. dell’ASR |
[A08] | [A08]-GetImportoTicket | Maggio 2018 | CSI | Esempi di ricerca e risposta di pratiche da |
pagare | ||||
[A09] | [A09]-GetListaTicketCF | Maggio 2018 | CSI | Esempi di ricerca delle pratiche da pagare per codice fiscale |
[A10] | [A10]-SetAvvenutoPagamento | Giugno 2021 | CSI | Esempi di registrazione di avvenuto pagamento sul S.I. dell’ASR |
[A11] | [A11]-GetListaTicket | Maggio 2018 | CSI | Esempi di richiesta aggiornamento dello stato delle pratiche da pagare |
[A12] | [A12]-GetRicevutaFiscaleFattura | Maggio 2018 | CSI | Esempio di richiesta di ricevuta fiscale o fattura al S.i. dell’ASR |
[A13] | [A13]-SetTicketAcquisiti | Maggio 2018 | CSI | Esempio di trasmissione esito acquisizione pratiche al S.i. dell’ASR |
[A14] | [A14]- SetOpposizionePrecompilazione730 | Maggio 2018 | CSI | Esempio di richiesta di modifica scelta del paziente circa la trasmissione del pagamento al ministero dell’economia e finanza per la compilazione automatica del 730 |
[A15] | [A15]-GetMultiIUVGPA | Maggio 2018 | CSI | Esempio metodo esposto dal GPA per la richiesta di lotti di IUV (per comporre l’avviso di pagamento) |
[A16] | [A16]-GetSingleIUVGPA | Maggio 2018 | CSI | Esempio metodo esposto dal GPA per la richiesta di un singolo IUV (per comporre l’avviso di pagamento) |
[A17] | [A17]-SetAssociazioneIUVTicketGPA | Maggio 2021 | CSI | Esempio metodo esposto dal GPA per assegnare uno IUV ad una posizione debitoraia |
[A18] | Rimborsi del ticket pagato dal cittadino/utente per prestazioni sanitarie | Maggio 2021 | CSI | Aggiornamento specifiche trasmissione dati MEF |
[A19] | xxxxx://xxx.xxxxxxxxxxxxxx.xx/xxxxxxx/xx tratto-conto?nid=839 | 2023 | CSI | Applicativo Estratto conto |
2 SERVIZIO DI INTEGRAZIONE GPR
2.1 OBIETTIVI
Obiettivo del documento è quello di fornire alle ASR le specifiche di integrazione al Gestore dei pagamenti aziendali, con le specifiche sarà fornito il contratto [A01] rappresentato da un file WSDL e corredato con messaggi xml di esempio. La ASR, con i fornitori produttori dei sistemi informativi oggetto di integrazione, dovrà realizzare la parte di software necessaria per integrare il GPA pagoPA rispettando le specifiche espresse nel contratto WSDL.
Rispetto alla precedente versione, il GPA pagoPA fornirà al S.I. dell’ASR i servizi WSDL finalizzati alla realizzazione del polo regionale dei pagamenti elettronici in sanità (pagoPA).
2.2 ELENCO DEI SERVIZI
L’elenco dei servizi che il S.I. dell’ASR dovrà esporre in modalità server sono:
• GetImportoTicket (aggiornamento): determinazione dell’importo da pagare di un ticket
• GetListaTicketCF (aggiornamento): ricerca dei ticket da pagare legati ad uno specifico codice fiscale
• SetAvvenutoPagamento (aggiornamento): notifica di avvenuto pagamento di un ticket
• SetOpposizionePrecompilazione730 (nuovo): il S.I. dell'ASR espone il servizio affinché il GPA pagoPA possa comunicargli la scelta sull’opposizione dell’invio del pagamento all’Agenzia delle Entrate per la generazione del 730 precompilato
• GetListaTicket (aggiornamento): richiesta aggiornamenti elenco ticket prodotti dai servizi generatori di ticket e loro stato
• GetRicevutaFiscaleFattura (nuovo): richiesta copia pdf della ricevuta o fattura di una pratica pagata
• SetTicketAcquisiti (aggiornamento): elenco dei ticket che sono stati acquisiti a seguito di una GetListaTicket con segnalazione di errori sull’acquisizione.
L’elenco dei servizi che il GPA pagoPA esporrà in modalità server, affinché il S.I. dell’ASR possa utilizzarli, sono:
• GetSingleIUVGPA: invocando questo metodo il S.I. dell’ASR può richiedere uno IUV (modello 1 e modello 3 – par. 2.10) da associare ad una pratica da pagare.
• GetMultiIUVGPA: invocando questo metodo il S.I. dell’ASR può richiedere un lotto di IUV (modello 3) da associare ad a delle pratiche da pagare. In questo caso il S.I. dell’ASR non richiederà uno IUV ogni volta che emette una pratica da pagare.
• SetAssociazioneIUVTicketGPA: invocando questo metodo il S.I. dell’ASR registra sul GPA l’assegnazione di uno IUV modello 3 ad una posizione debitoria emessa da un dipartimentale.
In questa versione delle specifiche di integrazione è stato descritto l’esposizione in Internet dei metodi GPA GetSingleIUVGPA, GetMultiIUVGPA e SetAssociazioneIUVTicketGPA e il meccanismo di autorizzazione al loro utilizzo. Si fa presente nulla è cambiato rispetto all’esposizione e utilizzo degli stessi metodi in rete Rupar.
2.3 MODALITA’ DI RICHIAMO
Il GPA pagoPA trasmette al sistema informativo aziendale un messaggio invocando il servizio richiesto, viceversa, il
S.I. dell’ASR trasmette al GPA pagoPA un messaggio invocando il servizio richiesto. La tipologia di servizi implementati è di tipo sincrono.
Il time-out viene specificato a livello nazionale dalla società PagoPA S.p.A. che eroga la piattaforma pagoPA, e pertanto sia il GPA che l’Ente Creditore sono obbligati a rispettare tale SLA (Service Level Agreement). | |
☞ | Il sistema di pagoPA attende un tempo massimo pari a 7 secondi prima di rispondere al PSP che la risposta dall’Ente Creditore non è pervenuta. Di seguito il link in cui vengono indicate le tempistiche, al paragrafo “Gestione dei timeout verso gli EC”: xxxxx://xxxx.xxxxxx.xx/xxxx/xxxxxxxxx/xxxxxxxxxx-xx-xxxxxxx-xxx-x-xxxxxxxx-xxxxxxxx/xxxxxxx-xx-xxxxxxxx-xxxx- |
Nella pagina sono riportati anche gli SLA nel paragrafo “Livelli di servizio dei metodi degli EC”. È importante evidenziare che pagoPA non sta ancora chiedendo agli Enti Creditori il rispetto degli SLA, che a tendere saranno di soli 2 secondi, e quindi molto inferiori agli attuali 7. | |
Pertanto, tenendo conto della complessità e numerosità dei soggetti coinvolti nelle chiamate - PSP, pagoPA, GPA, S.I. dell’Azienda - si chiede alle Aziende Sanitarie di valutare azioni migliorative sui propri S.I. per dare tempi di risposta inferiori ai 7 secondi, e di predisporsi per scendere sotto i 2 secondi, per rispettare gli SLA che saranno presto in vigore. |
Per comunicare con il sistema informativo aziendale il GPA pagoPA utilizzerà il canale di comunicazione https esposto dal sistema informativo aziendale. Il GPA pagoPA esporrà i propri servizi di integrazione su canale https.
La sicurezza del canale sarà garantita con utilizzo di certificati digitali SHA256 firmati da una Certificate Authority e registrati sull’hostname della macchina che espone i servizi.
2.4 CODIFICA AZIONI
La tabella sottostante contiene i valori dei codici delle azioni possibili.
CODICE | DESCRIZIONE |
1 | Ricerca ticket da pagare per numero pratica o codice fiscale |
2 | Trasmissione legame pratica / avviso di pagamento AgID |
4 | Registrazione avvenuto rimborso di un ticket |
5 | Registrazione avvenuto pagamento spontaneo di un ticket |
6 | Registrazione avvenuto pagamento integrato di un ticket |
8 | Notifica acquisizione informazioni sul ticket |
9 | Notifica di acquisizione Stato ticket |
91 | Trasmissione degli errori / warning sul controllo dei dati per la trasmissione dei dati al MEF per il 730 precompilato |
9A | Trasmissione degli errori / warning rilevati durante l’aggiornamento della base dati del GPA con i dati trasmessi dal S.I. dell’AS |
9B | Trasmissione degli errori / warning sul controllo dei dati per la trasmissione dei dati al MEF per il 730 precompilato |
I | Richiesta singolo IUV |
RLI | Richiesta multi IUV |
SA | SetAssociazioneIUVTicket |
Tabella 1 – Codici delle azioni
2.5 CODIFICA ERRORI GESTITI E STATO DELLA PRATICA
La tabella sottostante contiene i valori dei codici di ERRORE valevoli per tutti i messaggi di risposta alle chiamate dei servizi di seguito detti anche Operazioni.
Per ciascun metodo od Operazione le risposte SOAP conterranno sempre 2 livelli di codici errore:
• Un codice errore a livello di Response SOAP, tag <ERRORE>
• Un codice errore a livello delle singole pratiche che indica lo Stato della pratica estratta.
Nel seguito, metodo per metodo, verranno indicati i codici da usare di volta in volta. Si riporta qui l’elenco esaustivo di tutti i codici di errore e gli stati pratica possibili.
CODICE | DESCRIZIONE |
000 | Ok / Pratica da pagare |
001 | Pratica pagata totalmente |
002 | Pratica pagata totalmente ma integrata |
003 | Pratica esente (da non pagare) |
004 | Pratica da pagare ma integrata |
022 | Pratica non trovata |
032 | Pratica già pagata o da NON pagare |
033 | Pratica già rimborsata |
502 | Errore di sistema generico |
800 | Pratica annullata |
801 | Pratica rimborsata |
802 | Pratica da rimborsare |
999 | Errore per Fault |
Tabella 2 - Errori file XML e Stato della pratica
2.6 UUID
Il GPA pagoPA genererà lo UUID, che è l’identificativo standard usato nelle infrastrutture software, standardizzato dalla Open Software Foundation (OSF) come parte di un ambiente distribuito di computazione (Universally Unique Identify) ed è trasmesso ai S.I. dell’ASR per identificare univocamente le iterazioni tra i sistemi distribuiti.
Il S.I. dell’ASR dovrà quindi associare le attività svolte per rispondere alle richieste pervenute dal GPA pagoPA allo UUID ricevuto. Ad esempio i log dovranno contenere lo UUID, etc.
Lo scopo dell'UUID è di abilitare un sistema distribuito all'identificazione di informazioni in assenza di un sistema centralizzato di coordinamento.
2.7 ANAGRAFICA DEL PAZIENTE
Si richiede che l’anagrafica del paziente sia quella dell’anagrafe unica regionale assistiti (AURA) della Regione Piemonte, per i pazienti non certificati in Aura si può trasmettere i dati anagrafici presenti nel proprio S.I. Il GPA non esegue alcun blocco sui pazienti non certificati in AURA.
Verificare le F.A.Q. per dettagli sulla formattazione di alcuni campi.
2.8 CODIFICA MOTIVO PAGAMENTO
Codifica regionale del motivo del pagamento del ticket. Nella tabella sottostante sono elencati il motivo del pagamento accettato dall’attuale versione del GPA pagoPA.
CODICE | DESCRIZIONE |
S | Richieste di pagamento per prestazioni sanitarie erogate dal Servizio Sanitario Nazionale SSN |
L | Richieste di pagamento per prestazioni sanitarie erogate in regime di Libera Professione |
R | Altra posizione che generi una ricevuta fiscale |
A | Altra posizione debitoria non di libera professione che generi una fattura |
Tabella 3 - Codici dei tipi di pratica
Attraverso la codifica del motivo del pagamento si intende realizzare processi necessari per gestire in maniera corretta le varie tipologie di pagamenti. Il motivo pagamento è codificato dalla Regione Piemonte ed è uguale per tutte le ASR collegate al GPA pagoPA. L’elenco in tabella non è esaustivo ma potranno essere definiti altri codici, concordati con Regione Piemonte e le ASR.
2.9 CODIFICA DEI SERVIZI
La codifica dei servizi segue l’anagrafica seguente.
CODICE | DESCRIZIONE |
01 | CUP (Ambulatorio) |
10 | LIS (Laboratorio) |
20 | RIS (Radiologia) |
30 | PS (Pronto Soccorso) |
40 | SISMAS (Sistema Regionale di salute mentale) |
Tabella 4 - Codici Servizi
La codifica dei servizi, per il GPA, è collegata agli endpoint di integrazione (URL di contatto dei S.I. dell’ASR) e deve essere concordata con CSI Piemonte. L’elenco dei codici servizio elencati in tabella non è esaustivo; potranno essere definiti altri codici concordati con Regione Piemonte.
2.10 Pagamenti pagoPA
Novità introdotta dal GPA pagoPA è la possibilità di consentire il pagamento di una pratica sanitaria utilizzando i payment gateway messi a disposizione da sistema pagoPA (nel seguito canali di pagamento pagoPA). Il sistema pagoPA è stato realizzato da AgID (Agenzia per l’Italia Digitale) e consente di eseguire un pagamento attraverso enti convenzionati con AgID che offrono un servizio di pagamento (nel seguito PSP – Prestatore di Servizio di Pagamento). Definizioni:
• Pagatore: la persona intestataria della pratica da pagare
• Versante: la persona (fisica o giuridica) che esegue il pagamento
• IUV: identificativo univoco di versamento
• Avviso di pagamento: composto dai valori
o Aux digit, application code: codici che permettono di identificare che tipologia di intermediazione ha l’Asr
o IUV
• Modello 1: una pratica si dice pagata secondo il “modello 1” quando viene pagata da PTW utilizzando un canale di pagamento pagoPA
• Modello 3: una pratica si dice pagata secondo il “modello 3” quando viene pagata direttamente da PSP.
2.11 Struttura del Numero Pratica
La struttura del numero ticket come noto al paziente deve essere una stringa di 27 caratteri. Per esempio consideriamo il numero ticket:
S30101000000000012345602670
Il significato dei caratteri è posizionale secondo la seguente tabella:
Da posizione | A posizione | Lunghezza | Stringa | Significato |
1 | 1 | 1 | S | S = SSN (L = Libera prof) |
2 | 4 | 3 | 301 | Identificativo della XXX |
0 | 6 | 2 | 01 | Identificativo del servizio da interrogare |
7 | 22 | 16 | 0000000000123456 | Numero pratica |
23 | 27 | 5 | 02670 | Importo pratica (26.70 euro)1 |
Il sistema GPA pagoPA e il Servizio parlano per il tramite dell’identificativo a 16 caratteri,
L’identificativo generato a livello di servizio generatore di ticket deve essere univoco (Tipologia/ASR/servizio). | |
☞ | Questa nota diventa particolarmente importante quando due ASR vengono accorpate in un’unica ASR ma i sistemi produttori di ticket rimangono distinti. Ad esempio, il CUP delle due precedenti ASR rimangono attivi e potrebbero generare numeri pratica identici. In questo caso l’unico modo che ha il GPA per distinguere il sistema generatore di ticket è dato dall’identificativo del servizio da interrogare. |
Nel caso in cui due o più ASR vengano accorpate in un’unica ASR, e continuino a rimanere attivi i sistemi produttori di ticket (es. due o più CUP), il problema dell’univocità del numero pratica si potrebbe presentare se la nuova ASR decidesse di adottare una cassa unica per tutta l’Azienda. |
1 Nel caso in cui l’importo sia >= 1000.00 la stringa sarà posta “00000”
2.12 DESCRIZIONE DELL’INTERFACCIA DEI SERVIZI ESPOSTI DAL S.I. DELL’ASR
Nelle tabelle che seguiranno è riportata una descrizione puntuale dei tag che compongono la request e la response dei metodi esposti dal S.I. dell’Azienda Sanitaria, corredati delle indicazioni utili per comprenderli. La tabella è costituita dai seg. campi, dove:
Dato | nome del tag |
Liv | indica dove è posizionato il tag |
Gen | indica il genere del dato: o s = struttura o an = Alphanumerico o n = numerico o dec = decimale o d = data o bin = binario |
Tag | indica l’obbligatorietà della presenza del tag, che può essere: o 0 = opzionale (vedere colonna Contenuto) o 1 = obbligatorio o n = ripetibile |
Obb | indica l’obbligatorietà del dato, contenuto nel tag, che può essere: o M = Mandatory (obbligatorio) o O = Opzionale, attenzione il valore del tag dipende da una condizione e può diventare obbligatorio o facoltativo. La regola è riportata dentro il contenuto o F = Facoltativo, valorizzare se il dato è disponibile al dipartimentale |
Len | indica la lunghezza massima del dato |
Xxxxxxxxx | descrive quale dato inserire e la regola per la sua valorizzazione |
Generazione dell’identificativo di pagamento e della ricevuta/fattura da consegnare al paziente
Il processo di pagamento che porta alla produzione della ricevuta o fattura da rilasciare al paziente è indicata dall’ASR ed è impostata sul GPA. Ciascuna configurazione definisce il sistema che deve generare l’identificativo univoco di pagamento (NUMERO_QUIETANZA o NUMERO_RICEVUTA) ed il sistema che deve produrre la ricevuta/fattura da consegnare al paziente (OUTPUT_RICEVUTA).
2.12.1 Operazione: GetImportoTicket
Il servizio è di sola lettura dati. I dati risiedono sul S.I. dell’ASR (sul sistema produttore di ticket CUP, LIS, … o cassa).
2.12.1.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio GetImportoTicket esposto dal sistema informativo aziendale specificando il numero della pratica da ricercare. Il S.I. dell’ASR estrae la pratica ricercata e la restituisce al GPA pagoPA.
Il servizio GetImportoTicket qui descritto rappresenta un’evoluzione del precedente GetImportoTicket [A04].
Il nuovo servizio, il cui scopo è sempre restituire al chiamante l’importo di una posizione debitoria o creditoria, prevede fino a 3 parametri in ingresso, da usarsi selettivamente, tramite i quali ricercare sul S.I. della ASR l’importo della posizione debitoria o creditoria: ricerca per numero pratica (invariato rispetto alle precedenti specifiche), ricerca per NRE (numero di Ricetta Elettronica dematerializzata), ricerca per avviso di pagamento.
Queste tre ricerche sono mutuamente esclusive: il chiamante sceglie di valorizzare uno solo dei tre tag che rappresentano la chiave di ricerca in input. Il servizio capisce dal tipo di valorizzazione dell’input quale ricerca deve porre in atto.
La risposta della chiamata al metodo è sincrona. | |
☞ | Il GPA gestisce un time-out entro il quale deve pervenire la risposta. Eventuali risposte ricevute oltre al tempo massimo verranno ignorate dal GPA (considerate come risposte non pervenute). Fare riferimento al paragrafo 2.3. |
2.12.1.2 Interfaccia di richiamo (input)
Con riferimento a [A01], valorizzazione da parte del GPA pagoPA della Richiesta.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
GetImportoTicket | 1 | s | 1 | M | -- | Contenitore msg |
Richiesta | 2 | s | 1 | M | -- | Contenitore richiesta |
UUID | 3 | an | 1 | M | 36 | valorizzato da GPA pagoPA |
AZIONE | 3 | an | 1 | M | 4 | codice azione (vale “1”) |
XXX | 0 | an | 1 | M | 3 | codice regionale dell’ASR per cui si sta eseguendo la request |
NUMERO_SPORTELLO | 3 | an | 1 | M | 16 | identificativo del dispositivo automatico che ha richiesto la ricerca della pratica |
NUMERO_PRATICA | 3 | an | 1 | O | 16 | viene valorizzato in alternativa ai tag IUV e NRE. Contiene l’identificativo della pratica da ricercare nel S.I. dell’ASR lungo 16 caratteri. Attenzione il numero della pratica sul GPA pagoPA è una stringa di 16 caratteri ed è fillato a sinistra con il carattere “0” sino a raggiungere la lunghezza di 16 caratteri: ad esempio se il numero pratica è una stringa lunga 12 caratteri sul S.I. dell’ASR, es. “201800000123”, il numero pratica del GPA pagoPA sarà “0000201800000123” |
AVVISO_PAGAMENTO | 3 | s | 1 | O | -- | Contenitore viene valorizzato in alternativa al NUMERO_PRATICA e NRE quando si richiede di ricercare una pratica per gli attributi previsti in questo tag [A05] |
AUXDIGIT | 4 | n | 1 | M | 1 | valorizzare con il valore 3 |
APPLICATION_CODE | 4 | an | 1 | O | 2 | Non valorizzare |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
IUV | 4 | an | 1 | M | 17 | nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
NRE | 3 | an | 1 | O | 15 | viene valorizzato in alternativa al NUMERO_PRATICA e AVVISO_PAGAMENTO, quando si richiede di ricercare una pratica per Numero di Ricetta Elettronica |
GIORNI_RITENZIONE | 3 | n | 1 | M | 3 | indica il numero di giorni entro cui pagare la pratica. E’ valorizzato con un numero che indica quanti giorni occorre considerare nell’estrazione delle pratiche da pagare |
Una tipologia di ricerca esclude le altre, quindi nella request si prevede la valorizzazione di uno solo tra i tag: NUMERO_PRATICA, AVVISO_PAGAMENTO e NRE, ma nel caso siano stati valorizzati erroneamente due o più tag, restituire un errore perché trattasi di richiesta malformata.
☞ | Esempi di possibili ricerche [A08]: • si veda GetImportoTicket-Avvisi di pagamento.xml per un esempio di ricerca per avviso di pagamento (pagoPA) • si veda GetImportoTicket-NRE.xml per un esempio di ricerca per Numero di Ricetta Elettronica • si veda GetImportoTicket-NUMERO_PRATICA.xml per un esempio di ricerca per numero pratica regionale. Una tipologia di ricerca esclude le altre, quindi nella request si prevede la valorizzazione di uno solo tra i tag: NUMERO_PRATICA, AVVISO_PAGAMENTO e NRE, ma nel caso siano stati valorizzati erroneamente due o più tag, restituire un errore perché trattasi di richiesta malformata. |
2.12.1.3 Interfaccia di output
Il S.I. dell’ASR esegue la ricerca della pratica per NUMERO_PRATICA, oppure per AVVISO_PAGAMENTO per NRE e in funzione del risultato esegue la valorizzazione della risposta. Con riferimento a [A01]
Valorizzazione dell’oggetto PAZIENTE
Conterrà i dati relativi all’anagrafica del paziente contenuti in Aura; i campi sono auto esplicativi. Tutti i campi dell’oggetto sono obbligatori.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
GetImportoTicketResponse | 1 | s | 1 | M | -- | Contenitore msg |
GetImportoTicketResult | 2 | s | 1 | M | -- | Contenitore richiesta |
PAZIENTE | 3 | s | 1 | M | Contenitore Dati del paziente | |
COGNOME | 4 | an | 1 | M | 250 | Valorizzare con il cognome se persona fisica, con la ragione sociale se persona giuridica |
NOME | 4 | an | 1 | O | 250 | Valorizzare obbligatoriamente con il nome se persona fisica, non valorizzare se persona giuridica perché è stato valorizzato la regione sociale nel tag |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
COGNOME | ||||||
DATA_NASCITA | 4 | d | 1 | M | 10 | Valorizzare con la data di nascita se persona fisica, con la data di costituzione dell’azienda se persona giuridica Es. 10/01/2022 |
CODICE_FISCALE | 4 | an | 1 | M | 16 | Valorizzare con 16 caratteri alfanumerici se persona fisica (codice fiscale o STP o ENI), con 11 caratteri nel caso di persona giuridica (partita IVA) |
INDIRIZZO | 4 | an | 1 | M | 250 | Valorizzare con l’indirizzo di residenza se persona fisica, della sede legale se persona giuridica |
COMUNE | 4 | an | 1 | M | 250 | Valorizzare con il comune di residenza se persona fisica, della sede legale se persona giuridica |
PROVINCIA | 4 | an | 1 | M | 2 | Valorizzare con la provincia residenza se persona fisica, della sede legale se persona giuridica |
CAP | 4 | an | 1 | M | 6 | Valorizzare con il CAP di residenza se persona fisica, della sede legale se persona giuridica. È lungo 6 solo per accogliere il codice dello stato estero in caso di persona extracomunitaria. |
LISTA_PRENOTAZIONE | 3 | s | 1 | M | Contenitore | |
PRATICA | 4 | s | 1 | M | Contenitore valorizzare, altrimenti valorizzare come da specifiche che seguono | |
IMPORTO_PRATICA | 5 | dec | 1 | M | Valorizzare con l’importo totale che il paziente deve pagare o ha pagato. L’importo totale deve corrispondere a: IMPORTO_DA_PAGARE + IMPORTO_PAGATO + IMPORTO_MARCA_BOLLO + IMPORTO_IVA pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_MARCA_BOLLO | 5 | dec | 1 | M | Valorizzare con l’importo della marca da bollo, quando sia dovuta, altrimenti 0.00 pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_IVA | 5 | dec | 1 | M | Valorizzare con l’importo dell’Iva, quando sia dovuto pattern value="\d{1,6}.\d{1,2}" | |
PERCENTUALE_IVA | 5 | an | 1 | M | Valorizzare con la percentuale di iva applicata sulla pratica Numero tra [0 .. 100] |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
Es. 0 per indicare lo 0%, 4 per indicare il 4%, etc. | ||||||
PRESTAZIONE_EROGATA | 5 | an | 0 | F | 2 | Valorizzare, se il dato è disponibile al dipartimentale, con la stringa “SI” se le prestazioni associate alla posizione debitoria sono state erogate, “NO” nel caso contrario |
CODICE_VERSAMENTO | 5 | an | 1 | M | 4 | Composto da quattro caratteri2. Il codice versamento è stabilito dall’ASR e usato per generare lo IUV nel pagamento pagoPA Es. “1100” |
PRENOTAZIONE | 5 | s | 1 | M | Contenitore | |
NUMERO_PRATICA | 6 | an | 1 | M | 16 | Identificativo ticket a 16 caratteri |
IMPORTO_DA_PAGARE | 6 | dec | 1 | M | Valorizzare con l’importo che il paziente deve ancora pagare, comprensivo di eventuale marca da bollo (tag IMPORTO_MARCA_BOLLO) e IVA (tag IMPORTO_IVA) | |
IMPORTO_PAGATO | 6 | dec | 1 | M | Valorizzare con l’importo che il paziente ha già pagato | |
LISTA_FATTURA | 6 | s | 0 | O | Contenitore Se la pratica è in stato ancora da pagare allora non valorizzare, altrimenti valorizzare come da specifiche che seguono Attenzione i pagamenti parziali non sono più gestiti. | |
ELENCO_PAGAMENTI | 7 | s | 1 | M | Contenitore Descrivere in questi campi il pagamento eseguito dal paziente | |
NUMERO_SPORTELLO | 8 | an | 1 | M | 64 | Valorizzare con l’identificativo dello sportello dove è avvenuto il pagamento |
NUMERO_PRATICA | 8 | an | 0 | F | 16 | Non valorizzare |
NUMERO_RICEVUTA | 8 | an | 1 | M | 20 | Valorizzare con l’identificativo del pagamento (es. l’identificativo della ricevuta, …) |
DATA_RICEVUTA | 8 | d | 1 | M | 10 | Valorizzare con la data del pagamento |
IMPORTO_RICEVUTA | 8 | dec | 1 | M | Valorizzare con l’importo pagato pattern value="\d{1,6}.\d{1,2}" | |
AVVISO_PAGAMENTO | 8 | s | 0 | O | Contenitore |
2 Il codice versamento è fornito dall’ASR, valorizzato secondo le codifiche SIOPE. Il SIOPE (Sistema informativo sulle operazioni degli enti pubblici), è un sistema di rilevazione telematica degli incassi e dei pagamenti effettuati dai tesorieri di tutte le amministrazioni pubbliche, che nasce dalla collaborazione tra la Ragioneria Generale dello Stato, la Banca d'Italia e l'ISTAT, in attuazione dall'articolo 28 della legge n. 289/2002, disciplinato dall’articolo 14, commi dal 6 all’11, della legge n. 196 del 2009.
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
Valorizzato se la pratica è stata pagata con PagoPA modello 3 come segue, altrimenti non valorizzato | ||||||
AUXDIGIT | 9 | an | 1 | M | 1 | Composto da un solo carattere |
APPLICATION_CODE | 9 | an | 1 | F | 2 | Non valorizzare |
IUV | 9 | an | 1 | M | 17 | Nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 9 | an | 0 | F | 10 | Non valorizzare |
IUV_MOD1 | 8 | an | 0 | O | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009 |
FLAGPAGAMENTOANTICIPATO | 8 | an | 0 | O | 1 | Il campo deve essere valorizzato a “1” per indicare il pagamento della spesa sostenuta dal cittadino in data antecedente alla data di emissione del “documento fiscale” [A06]. Obbligatorio solo se data pagamento antecedente data emissione |
FLAGTIPOSPESA | 8 | an | 0 | O | 1 | Il campo è valorizzato al fine di evidenziare caratteristiche particolari di alcune tipologie di spesa. Il campo vale: “1” con tipo TK (ticket di pronto soccorso) o “2” con tipo SR (visita in intramoenia) [A06] |
TIPOSPESA | 8 | an | 0 | O | 2 | |
DATAEMISSIONE | 8 | dat | 0 | O | 10 | Data di emissione del “documento fiscale” relativo alla spesa sostenuta dal cittadino [A06] |
ELENCO_PRESTAZIONI | 6 | s | 0 | F | Contenitore Non valorizzare previsto per usi futuri | |
NUMERO_QUIETANZA | 6 | an | 0 | O | 20 | L’identificativo di pagamento può essere generato dal GPA o dall’ASR prima del pagamento oppure dopo aver registrato il pagamento. Se valorizzato dall’Asr l’identificativo di pagamento deve soddisfare il pattern value="([A- Za-z0-9_./\\\-]{1,20})" per dettagli vedasi [A06] |
OUTPUT_RICEVUTA | 6 | an | 0 | O | A discrezione dell’ASR la valorizzazione con il pdf in formato base64 della ricevuta. Attenzione i pagamenti parziali non sono più gestiti. Si fa notare che i dati riportati |
Dato | Xxx | Xxx | Tag | Obb | Xxx | Xxxxxxxxx |
nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa. Nel caso in cui la ricevuta / fattura differisse da una precedente copia in possesso del paziente, il CSI inoltrerà la richiesta di verifica direttamente all’ASR in quanto proprietaria del dato. Il tag non è da valorizzare nel caso in cui il S.I. dell’ASR utilizzi il template regionale delle ricevute / fatture | ||||||
MOTIVO_PAGAMENTO | 6 | an | 1 | M | 1 | Valorizzare con la tipologia del pagamento, con “S” se si tratta di pagamento per prestazione SSN oppure “L” se si tratta di pagamenti di fatture in libera professione, R o A. Ulteriori altre codifiche saranno comunicate quando saranno gestiti altri tipi di pagamenti |
ASR_BENEFICIARIA | 6 | an | 1 | M | 3 | Valorizzare con il codice regionale dell’azienda sanitaria beneficiaria dell’importo ticket (301, 203, …) |
CODICE_SERVIZIO | 6 | an | 1 | M | 2 | Valorizzare con la codifica del servizio. Il codice è di due caratteri ed è concordato a livello regionale |
DATA_CREAZIONE_PRENOTAZIONE | 6 | an | 1 | M | 10 | Valorizzare con la data di creazione e/o ultima modifica della prenotazione disponibile nel dipartimentale |
AVVISO_PAGAMENTO3 | 6 | s | 1 | M | Contenitore | |
AUXDIGIT | 7 | an | 1 | M | 1 | composto da un solo carattere |
APPLICATION_CODE | 7 | an | 1 | M | 2 | non valorizzare |
IUV | 7 | an | 1 | M | 17 | Valorizzato nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 7 | d | 1 | M | 10 | data nel formato dd/mm/yyyy |
IUV_MOD1 | 6 | an | 0 | F | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009, altrimenti il tag non è valorizzato |
3 L’avviso di pagamento sarà fornito da GPA pagoPA e serve per realizzare il pagamento con canale AgID pagoPA
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
OPPOSIZIONE_730 | 6 | bin | 0 | O | 1 | Indica la scelta che ha fatto il paziente circa la trasmissione del pagamento all’Agenzia delle Entrate per la compilazione automatica del 730. Da valorizzare con il carattere: - “0” per esprimere l’opposizione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - “1” per esprimere l’autorizzazione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - non specificare se non disponibile al dipartimentale |
LISTA_NRE | 6 | s | 0 | O | Contenitore valorizzare con l’elenco degli NRE (numero di ricetta elettronica). Se la pratica non è collegata a nessuna ricetta elettronica non valorizzare | |
NRE | 7 | an | n | O | 15 | è un identificativo di 15 caratteri. Attenzione la pratica può essere collegata a più di una ricetta elettronica |
IMPORTO_DA_RIMBORSARE | 6 | dec | 0 | O | Da valorizzare con l’importo che l’ASR deve ancora rimborsare al paziente, se non si tratta di ticket da rimborsare non valorizzare | |
IMPORTO_RIMBORSATO | 6 | dec | 0 | O | Da valorizzare con l’importo che l’ASR ha già rimborsato al paziente, se non si tratta di ticket da rimborsare non valorizzare | |
MODALITA_RIMBORSO | 6 | an | 0 | O | 1 | da valorizzare con la modalità tramite cui il paziente ha scelto di ricevere il rimborso, se l’utente non l’ha ancora scelta o non si tratta di ticket da rimborsare non valorizzare |
ERRORE | 3 | s | 1 | M | Contenitore Per i possibili valori vedi tabella sottostante | |
CODICE | 4 | an | 1 | M | 3 | Codice degli errori/stato posizione debitoria. I codici sono descritti sotto |
MESSAGGIO | 4 | an | 1 | M | Messaggio descrittivo sul codice errore presentatosi nel dipartimentale |
La tabella sottostante contiene i possibili valori del codice di ERRORE atteso.
CODICE | DESCRIZIONE |
000 | Pratica da pagare |
004 | Pratica da pagare ma integrata |
032 | Pratica già pagata o da non pagare |
033 | Pratica già rimborsata |
022 | Pratica non trovata |
800 | Pratica annullata |
801 | Pratica rimborsata |
802 | Pratica da rimborsare |
999 | Errore per fault |
☞ | Rispetto alla versione del GPA 2013, non sono più gestiti pratiche pagate parzialmente. |
Nel campo messaggio è possibile inserire delle descrizioni più dettagliate di quelle genericamente riportate nella tabella.
☞ | Esempi di possibili risposte [A08]: • si veda GetImportoTicketResponse-Pratica non pagata.xml quando viene restituita una pratica non pagata • si veda GetImportoTicketResponse-Pratica non pagata e integrata.xml quando viene restituita una pratica non pagata frutto di una integrazione di altra pratica. In questo caso l’ASR ha emesso un ulteriore pratica allo scopo di aumentare l’importo della partecipazione alla spesa sanitaria • si veda GetImportoTicketResponse-Pratica non trovata.xml quando viene restituito il messaggio di pratica non trovata • si veda GetImportoTicketResponse-Pratica annullata.xml quando viene restituito una pratica annullata, in questo caso la pratica era stata precedentemente pagata • si veda GetImportoTicketResponse-Pratica rimborsata.xml quando viene restituito una pratica rimborsata |
2.12.1.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, restituire la descrizione breve dell’errore all’interno del campo soap fault, come riportato nell’esempio [A08].
2.12.1.5 Gestione altre features
La ricerca delle pratiche deve escludere quelle che risultano da pagare e che sono più vecchi di n giorni, dove n è un numero configurabile scelto a piacere. Il parametro n è indicato in GIORNI_RITENZIONE. I giorni di ritenzione sono concordati con l’ASR prima dell’avvio in esercizio.
Ad esempio, se GIORNI_RITENZIONE vale 60, occorre estrarre le pratiche la cui differenza tra la data di ricezione della richiesta e la data di erogazione delle prestazioni è minore o uguale a 60 giorni. Per calcolare le prestazioni che rientrano nel periodo di ritenzione prendere in considerazione il max della data di erogazione delle prestazioni. Ad esempio, si consideri una pratica P1 con due appuntamenti, A1 del 01/01/2013 e A2 del 15/02/2013. Se viene eseguita una chiamata GetImportoTicket in data 15/03/2013, occorre trasmettere in risposta la pratica P1 perché in valore assoluto la ritenzione calcolata come max (A1, A2) = 15/02/2013 e la ritenzione di A2 è pari a 28 giorni che è inferiore a 60 giorni specificati nel parametro di input del messaggio SOAP.
Trattandosi di una ricerca puntuale il S.I. dell’ASR può anche ignorare i giorni di ritenzione, in questo caso l’ASR non implementerà il massimo numero di giorni che un paziente ha a disposizione per pagare la pratica.
2.12.2 Operazione: GetListaTicketCF
Il servizio è di sola lettura dati. I dati risiedono sul S.I. dell’ASR (sul sistema produttore di ticket CUP, LIS, … o cassa).
2.12.2.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio GetListaTicketCF esposto dal sistema informativo aziendale specificando il codice fiscale del paziente per il quale si stanno ricercando le sue posizioni debitorie. Il S.I. dell’ASR estrae le pratiche appartenenti al codice fiscale che sono da pagare specificato e le restituisce al GPA pagoPA.
Il messaggio di risposta può essere in uno dei seguenti stati: • La lista delle pratiche che sono ancora da pagare, • Nessuna pratica è stata estratta per il codice fiscale specificato. | |
☞ | Non sono da prendere in considerazione le pratiche in stato già pagato o rimborsato o annullato. |
Le pratiche nel messaggio XML di risposta saranno identificate con l’identificativo generato dal servizio che le ha generate (CUP SGP, CUP TRAKCARE, LIS, etc.). | |
La chiamata al metodo è sincrona. | |
È prevista la gestione di un time-out entro cui deve pervenire la risposta. Fare riferimento al paragrafo 2.3. |
2.12.2.2 Interfaccia di richiamo (input)
Con riferimento a [A01], valorizzazione da parte del GPA pagoPA dell’oggetto Richiesta.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
GetListaTicketCF | 1 | s | 1 | M | -- | Contenitore msg |
Richiesta | 2 | s | 1 | M | -- | Contenitore richiesta |
UUID | 3 | an | 1 | M | 36 | valorizzato da GPA pagoPA |
AZIONE | 3 | an | 1 | M | 4 | codice azione (vale “1”) |
XXX | 0 | an | 1 | M | 3 | codice regionale dell’ASR per cui si sta eseguendo la request |
NUMERO_SPORTELLO | 3 | an | 1 | M | 16 | identificativo del dispositivo automatico che ha richiesto la ricerca della pratica |
CODICE_FISCALE | 3 | an | 1 | M | 16 | codice fiscale del paziente di cui è richiesto la ricerca nel S.I. dell’ASR dei ticket che risultano ancora da pagare. Può essere valorizzato con 16 caratteri alfanumerici nel caso di persone fisiche (codice fiscale o STP o ENI) |
ORDINAMENTO | 3 | an | 1 | M | 1 | indica l’ordinamento richiesto nell’output rispetto alla data di prestazione. Se vale 0 ordinare in modo decrescente, se vale 1 ordinare in modo crescente |
GIORNI_RITENZIONE | 3 | dec | 1 | M | è un numero che indica quanti giorni |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
occorre considerare nell’estrazione dei ticket da pagare. Ad esempio se il numero vale 60 occorre estrarre i ticket la cui differenza tra la data di ricezione della richiesta e la massima data di prestazione è minore o uguale a 60 giorni |
☞ | Come esempio di richiesta si veda [A09]. |
2.12.2.3 Interfaccia di output
Il S.I. dell’ASR esegue la ricerca delle pratiche ancora da pagare per il codice fiscale in input e, in funzione del risultato fornisce la risposta. Con riferimento a [A01], vediamo nel seguito i campi complessi PAZIENTE, LISTA_PRENOTAZIONE, ERRORE.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
GetListaTicketCFResponse | 1 | s | 1 | M | -- | Contenitore msg |
GetListaTicketCFResult | 2 | s | 1 | M | -- | Contenitore richiesta |
PAZIENTE | 3 | s | 1 | M | Contenitore Dati del paziente | |
COGNOME | 4 | an | 1 | M | 250 | Valorizzare con il cognome se persona fisica, con la ragione sociale se persona giuridica |
NOME | 4 | an | 1 | O | 250 | Valorizzare obbligatoriamente con il nome se persona fisica, non valorizzare se persona giuridica perché è stato valorizzato la regione sociale nel tag COGNOME |
DATA_NASCITA | 4 | d | 1 | M | 10 | Valorizzare con la data di nascita se persona fisica, con la data di costituzione dell’azienda se persona giuridica Es. 10/01/2022 |
CODICE_FISCALE | 4 | an | 1 | M | 16 | Valorizzare con 16 caratteri alfanumerici se persona fisica (codice fiscale o STP o ENI), con 11 caratteri nel caso di persona giuridica (partita IVA) |
INDIRIZZO | 4 | an | 1 | M | 250 | Valorizzare con l’indirizzo di residenza se persona fisica, della sede legale se persona giuridica |
COMUNE | 4 | an | 1 | M | 250 | Valorizzare con il comune di residenza se persona fisica, della sede legale se persona giuridica |
PROVINCIA | 4 | an | 1 | M | 2 | Valorizzare con la provincia residenza |
Dato | Xxx | Xxx | Tag | Obb | Xxx | Xxxxxxxxx |
se persona fisica, della sede legale se persona giuridica | ||||||
CAP | 4 | an | 1 | M | 6 | Valorizzare con il CAP di residenza se persona fisica, della sede legale se persona giuridica. È lungo 6 solo per accogliere il codice dello stato estero in caso di persona extracomunitaria. |
LISTA_PRENOTAZIONE | 3 | s | n | M | Contenitore | |
PRATICA | 4 | s | 1 | M | Contenitore valorizzare, altrimenti valorizzare come da specifiche che seguono | |
IMPORTO_PRATICA | 5 | dec | 1 | M | Valorizzare con l’importo totale che il paziente deve pagare o ha pagato. L’importo totale deve corrispondere a: IMPORTO_DA_PAGARE + IMPORTO_PAGATO + IMPORTO_MARCA_BOLLO + IMPORTO_IVA pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_MARCA_BOLLO | 5 | dec | 1 | M | Valorizzare con l’importo della marca da bollo, quando sia dovuta, altrimenti 0.00 pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_IVA | 5 | dec | 1 | M | Valorizzare con l’importo dell’Iva, quando sia dovuto pattern value="\d{1,6}.\d{1,2}" | |
PERCENTUALE_IVA | 5 | an | 1 | M | Valorizzare con la percentuale di iva applicata sulla pratica Numero tra [0 .. 100] Es. 0 per indicare lo 0%, 4 per indicare il 4%, etc. | |
PRESTAZIONE_EROGATA | 5 | an | 0 | F | 2 | Valorizzare, se il dato è disponibile al dipartimentale, con la stringa “SI” se le prestazioni associate alla posizione debitoria sono state erogate, “NO” nel caso contrario |
CODICE_VERSAMENTO | 5 | an | 1 | M | 4 | Composto da quattro caratteri4. Il codice versamento è stabilito dall’ASR e usato per generare lo IUV nel pagamento pagoPA Es. “1100” |
4 Il codice versamento è fornito dall’ASR, valorizzato secondo le codifiche SIOPE. Il SIOPE (Sistema informativo sulle operazioni degli enti pubblici), è un sistema di rilevazione telematica degli incassi e dei pagamenti effettuati dai tesorieri di tutte le amministrazioni pubbliche, che nasce dalla collaborazione tra la Ragioneria Generale dello Stato, la Banca d'Italia e l'ISTAT, in attuazione dall'articolo 28 della legge n. 289/2002, disciplinato dall’articolo 14, commi dal 6 all’11, della legge n. 196 del 2009.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
PRENOTAZIONE | 5 | s | 1 | M | Contenitore | |
NUMERO_PRATICA | 6 | an | 1 | M | 16 | Identificativo ticket a 16 caratteri |
IMPORTO_DA_PAGARE | 6 | dec | 1 | M | Valorizzare con l’importo che il paziente deve ancora pagare, comprensivo di eventuale marca da bollo (tag IMPORTO_MARCA_BOLLO) e IVA (tag IMPORTO_IVA) | |
IMPORTO_PAGATO | 6 | dec | 1 | M | Valorizzare con l’importo che il paziente ha già pagato | |
LISTA_FATTURA | 6 | s | 0 | O | Contenitore da non valorizzare perché il metodo restituisce solo pratiche da pagare e il GPA pagoPA non gestisce pagamenti parziali | |
ELENCO_PRESTAZIONI | 6 | s | 1 | M | Contenitore Da valorizzare come specificato sotto | |
PRESTAZIONE | 7 | s | 1 | M | Contenitore Da valorizzare come specificato sotto | |
CODICE | 8 | an | 0 | F | Non valorizzare | |
DESCRIZIONE | 8 | an | 0 | F | Non valorizzare | |
DATA_APPUNTAMENTO | 8 | an | 1 | M | 10 | valorizzare struttura: DD/MM/YYYY |
ORA_APPUNTAMENTO | 8 | an | 1 | M | 5 | valorizzare struttura hh:mm |
NOTE_APPUNTAMENTO | 8 | an | 0 | F | Non valorizzare | |
COMUNE_APPUNTAMENTO | 8 | an | 0 | F | 250 | valorizzare, se disponibile al dipartimentale, con il comune dove viene erogata la prestazione (attenzione questa informazione sarà visualizzata non inserire dati sensibili), |
INDIRIZZO_APPUNTAMENTO | 8 | an | 0 | F | 250 | valorizzare, se disponibile al dipartimentale, con il comune dove viene erogata la prestazione (attenzione questa informazione sarà visualizzata non inserire dati sensibili), |
PROVINCIA_APPUNTAMENTO | 8 | an | 0 | F | 2 | valorizzare, se disponibile al dipartimentale, con la provincia (es. TO, AT, …) dove viene erogata la prestazione (attenzione questa informazione sarà visualizzata non inserire dati sensibili) |
CAP_APPUNTAMENTO | 8 | an | 0 | F | 5 | valorizzare, se disponibile al dipartimentale, con il CAP dove viene erogata la prestazione (attenzione questa informazione sarà visualizzata non inserire dati sensibili) |
NUMERO_QUIETANZA | 6 | an | 0 | O | 20 | L’identificativo di pagamento può essere generato dal GPA o dall’ASR |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
prima del pagamento oppure dopo aver registrato il pagamento. Se valorizzato dall’Asr l’identificativo di pagamento deve soddisfare il pattern value="([A-Za-z0-9_./\\\- ]{1,20})" per dettagli vedasi [A06] | ||||||
OUTPUT_RICEVUTA | 6 | an | 0 | O | A discrezione dell’ASR la valorizzazione con il pdf in formato base64 della ricevuta. Attenzione i pagamenti parziali non sono più gestiti. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa. Nel caso in cui la ricevuta / fattura differisse da una precedente copia in possesso del paziente, il CSI inoltrerà la richiesta di verifica direttamente all’ASR in quanto proprietaria del dato. Il tag non è da valorizzare nel caso in cui il S.I. dell’ASR utilizzi il template regionale delle ricevute / fatture | |
MOTIVO_PAGAMENTO | 6 | an | 1 | M | 1 | |
ASR_BENEFICIARIA | 6 | an | 1 | M | 3 | Valorizzare con il codice regionale dell’azienda sanitaria beneficiaria dell’importo ticket (301, 203, …) |
CODICE_SERVIZIO | 6 | an | 1 | M | 2 | Valorizzare con la codifica del servizio. Il codice è di due caratteri ed è concordato a livello regionale |
DATA_CREAZIONE_PRENOTAZIONE | 6 | an | 1 | M | 10 | Valorizzare con la data di creazione e/o ultima modifica della prenotazione disponibile nel dipartimentale |
AVVISO_PAGAMENTO | 6 | s | 1 | M | Contenitore | |
AUXDIGIT | 7 | an | 1 | M | 1 | composto da un solo carattere |
APPLICATION_CODE | 7 | an | 1 | M | 2 | non valorizzare |
IUV | 7 | an | 1 | M | 17 | Valorizzato nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 7 | d | 1 | M | 10 | data nel formato dd/mm/yyyy |
IUV_MOD1 | 6 | an | 0 | F | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009, altrimenti il tag non è valorizzato | ||||||
OPPOSIZIONE_730 | 6 | bin | 0 | O | 1 | Indica la scelta che ha fatto il paziente circa la trasmissione del pagamento all’Agenzia delle Entrate per la compilazione automatica del 730. Da valorizzare con il carattere: - “0” per esprimere l’opposizione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - “1” per esprimere l’autorizzazione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - non specificare se non disponibile al dipartimentale |
LISTA_NRE | 6 | s | 0 | O | Contenitore valorizzare con l’elenco degli NRE (numero di ricetta elettronica). Se la pratica non è collegata a nessuna ricetta elettronica non valorizzare | |
NRE | 7 | an | n | O | 15 | è un identificativo di 15 caratteri. Attenzione la pratica può essere collegata a più di una ricetta elettronica |
ERRORE | 3 | s | 1 | M | Contenitore Per i possibili valori vedi tabella sottostante | |
CODICE | 4 | an | 1 | M | 3 | Codice degli errori/stato posizione debitoria. I codici sono descritti sotto |
MESSAGGIO | 4 | an | 1 | M | Messaggio descrittivo sul codice errore presentatosi nel dipartimentale |
La tabella sottostante contiene i valori dei codici di ERRORE.
CODICE | DESCRIZIONE |
000 | Pratica da pagare |
022 | Pratica non trovata |
502 | Sevizio non gestito |
Nel campo messaggio è possibile inserire delle descrizioni più dettagliate di quelle genericamente riportate nella tabella.
Negli esempi sottostanti riproduciamo tutti i casi possibili.
☞ | Come esempio di risposta si veda [A09] • GetListaTicketCFResponse-Pratica da pagare.xml riporta un esempio di risposta in cui sono state trovate due pratiche da pagare |
• GetListaTicketCFResponse-pratica non trovata.xml riporta un esempio di risposta in cui non sono state trovate pratiche da pagare
• GetListaTicketCFResponse-servizio non gestito.xml riporta un esempio di risposta in cui il S.I. dell’ASR dichiara di non gestire il servizio di ricerca per codice fiscale
2.12.2.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, restituire la descrizione breve dell’errore all’interno del campo soap fault [A09].
2.12.2.5 Gestione altre features
La ricerca delle pratiche deve escludere quelle che risultano da pagare e che sono più vecchie di n giorni, dove n è un numero configurabile scelto a piacere indicato in GIORNI_RITENZIONE.
Trattandosi di una ricerca massiva il S.I. dell’ASR può anche ignorare i giorni di ritenzione e restituire le pratiche che hanno almeno una prestazione ancora da erogare e non considerare le pratiche con prestazioni già erogate. In questo caso l’ASR non implementerà il massimo numero di giorni che un paziente ha a disposizione per pagare la pratica.
2.12.3 Operazione: SetAvvenutoPagamento
Il servizio è di scrittura dati. I dati risiedono sul S.I. dell’ASR (CUP, LIS, …) e il servizio registra sul S.I. il pagamento o l’avvenuto rimborso di una pratica.
Ulteriore novità introdotta dal servizio consiste nell’inserimento della gestione del NUMERO_QUIETANZA all’interno della response del metodo. In questo modo al termine della registrazione del pagamento il S.I. dell’ASR potrà specificare il proprio identificativo di pagamento da utilizzare all’interno della ricevuta da consegnare al paziente.
2.12.3.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio SetAvvenutoPagamento esposto dal sistema informativo aziendale specificando l’identificativo della pratica su cui è necessario registrare l’avvenuto pagamento o l’avvenuto rimborso. Con la SetAvvenutoPagamento il GPA pagoPA specifica tutti i dati relativi al pagamento o al rimborso (importo, numero ricevuta, data, …). Il S.I. dell’ASR registra i dati relativi al pagamento o rimborso e restituisce tutte le informazioni riassuntive del nuovo stato assunto dalla pratica.
☞ | Il pagamento della pratica è avvenuto su un terminale di pagamento messo a disposizione dall’ASR oppure utilizzando il canale di pagamento pagoPA. Nel caso di canale pagoPA la registrazione del pagamento trasmette al sistema dipartimentale della ASR tutti i dati che caratterizzano il canale (IUV, accordo/opposizione invio al 730 precompilato). L’erogazione di un rimborso è avvenuta per mezzo di voucher o bonifico, quindi tramite il prodotto Estratto conto [A19], oppure per mezzo del borsellino di credito, quindi tramite l’applicativo regionale (PTW). |
Successivamente al SetAvvenutoPagamento il GPA pagoPA invocherà il metodo esposto dal S.I. dell’ASR SetTicketAcquisiti. | |
La chiamata al servizio SetAvvenutoPagamento è sincrona. | |
Il S.I. dell’ASR potrà trasmettere l’identificativo di pagamento al GPA pagoPA nella risposta a seguito della registrazione del pagamento, all’interno del nuovo tag NUMERO_QUIETANZA. | |
Il GPA pagoPA potrà richiedere al S.I. dell’ASR il pdf della ricevuta di pagamento o di rimborso, se previsto |
dall’ASR. |
Il GPA pagoPA prevede la gestione di un time-out entro cui deve pervenire la risposta dal metodo. Fare riferimento al paragrafo 2.3. |
Nel pagamento "modello 3" (banche, tabaccai, app IO, ecc.) il cittadino non può esprimere la scelta sulla trasmissione dei dati al sistema TS. Pertanto, nella chiamata SetAvvenutoPagamento che fa il GPA verso il SIA nel caso del "modello 3", il tag OPPOSIZIONE_730 non può essere valorizzato, e quindi fa fede quanto presente nell'archivio dell'AS. |
Attenzione. Verificare che i dati trasmessi rispettino i vicoli elencati in [A06]. |
2.12.3.2 Interfaccia di richiamo (input)
Valorizzazione richiesta di pagamento.
SetAvvenutoPagamento | 1 | s | 1 | M | -- | Contenitore msg |
Richiesta | 2 | s | 1 | M | -- | Contenitore richiesta |
UUID | 3 | an | 1 | M | 36 | valorizzato da GPA pagoPA |
AZIONE | 3 | an | 1 | M | 36 | 6 (pagamento integrato), 5 (pagamento spontaneo), 4 (erogazione rimborso) |
XXX | 0 | an | 1 | M | 3 | codice regionale dell’ASR per cui si sta eseguendo la request |
NUMERO_PRATICA | 3 | an | 1 | O | 16 | è valorizzato con l’identificativo del ticket pagato o rimborsato a 16 caratteri |
IMPORTO_PRATICA | 3 | dec | 1 | M | è valorizzato con l’importo pagato (se AZIONE = 5 o 6) o rimborsato (se AZIONE = 4) dal paziente pattern value="\d{1,6}.\d{1,2}" | |
AVVISO_PAGAMENTO | 3 | s | 0 | O | Contenitore valorizzato se la pratica è stata pagata con PagoPA modello 3 come segue, altrimenti non valorizzato. Non valorizzato se AZIONE = 4. | |
AUXDIGIT | 4 | an | 1 | M | 1 | Composto da un solo carattere |
APPLICATION_CODE | 4 | an | 1 | F | 2 | Non valorizzare |
IUV | 4 | an | 1 | M | 17 | Nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 4 | an | 0 | F | 10 | Non valorizzare |
NUMERO_SPORTELLO | 3 | an | 1 | M | 16 | è valorizzato con l’identificativo del dispositivo automatico che ha gestito il pagamento del ticket tramite l’intermediazione del GPA pagoPA |
NUMERO_RICEVUTA | 3 | an | 1 | M | 20 | identificativo della ricevuta / quietanza di pagamento valorizzato dal Punto di Riscossione Automatico o dal GPA pagoPA nella configurazione 1, valorizzato dal Punto di Riscossione Automatico nella configurazione 7, 8 e |
9 | ||||||
DATA_RICEVUTA | 3 | d | 1 | M | 10 | Valorizzare con la data della ricevuta |
IMPORTO_MARCA_BOLLO | 3 | dec | 1 | M | non valorizzato | |
IMPORTO_IVA | 3 | dec | 1 | M | non valorizzato | |
IUV_MOD1 | 3 | an | 0 | O | 25 | stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009, altrimenti il tag non è valorizzato. Non valorizzato se AZIONE = 4 |
OPPOSIZIONE_730 | 3 | bin | 0 | O | 1 | Indica la scelta che ha fatto il paziente circa la trasmissione del pagamento all’Agenzia delle Entrate per la compilazione automatica del 730. Da valorizzare con il carattere: - “0” per esprimere l’opposizione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - “1” per esprimere l’autorizzazione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - se non valorizzato, fa fede quanto presente nell'archivio dell'AS. |
MODALITA_RIMBORSO | 3 | an | 0 | O | 1 | valorizzato solo se AZIONE = 4, indica la modalità di erogazione del rimborso scelta dall’utente. Se valorizzato, gli unici valori ammessi sono: • 1: Voucher • 2: Bonifico • 3: Borsellino elettronico |
PRATICA_PAGATA_CON_RIMBORSO | 3 | an | 1 | M | 16 | valorizzato solo se AZIONE = 4 e MODALITA_RIMBORSO = 3, rappresenta l’identificativo della pratica per pagare la quale è stato utilizzato il credito del rimborso |
Negli esempi sottostanti riproduciamo alcuni dei casi possibili. Come esempio di richiesta si veda [A10].
In caso di presenza di rimborsi, il tag IMPORTO_PRATICA dovrà dunque contenere l’importo rimborsato, che sarà in generale <= importo originale del ticket. In dettaglio:
sarà < se il rimborso è una parte del valore originale della pratica,
sarà = in caso di rimborso coincidente con il valore originale della pratica.
In caso di AZIONE = 4 e MODALITA_RIMBORSO = 1 o 2 (voucher o bonifico), l’IMPORTO_PRATICA - cioè l’importo rimborsato - dovrà coincidere con quello dell’intero rimborso per il ticket presente sul SIA, in quanto il rimborso secondo queste due modalità non prevede la possibilità di frazionarlo per pagare più ticket successivi.
Nel caso invece di MODALITA_RIMBORSO = 3 (borsellino), l’IMPORTO_PRATICA potrà essere minore uguale di quello del valore del ticket da rimborsare presente sul SIA, in quanto l’importo di un unico rimborso può essere utilizzato frazionato in più tranches successive per pagare diversi ticket. Il SIA utilizza l’IMPORTO_PRATICA ricevuto per determinare il valore dei tag IMPORTO_RIMBORSATO ed IMPORTO_DA_RIMBORSARE da restituire: al primo va aggiunto l’importo ricevuto, mentre al secondo va sottratto.
Se l’importo di un rimborso viene suddiviso tra N ticket da pagare, il SIA riceverà N invocazioni del servizio in oggetto con AZIONE=4 che comunicherà altrettanti aggiornamenti del rimborso utilizzato: ad ogni invocazione l’IMPORTO_RIMBORSATO crescerà, l’IMPORTO_DA_RIMBORSARE diminuirà, ed il tag PRATICA_PAGATA_CON_RIMBORSO che contiene l’identificativo del ticket per pagare il quale è stato utilizzato il credito del rimborso, sarà sempre differente. In più il SIA riceverà una ulteriore invocazione con AZIONE=6 che comunicherà l’avvenuto pagamento del ticket da pagare.
2.12.3.3 Interfaccia di output
Dopo aver registrato il pagamento, il S.I. dell’ASR trasmette al GPA pagoPA lo stato della pratica avendolo di fatto modificato. Lo stato della pratica è composto dai tag PAZIENTE, LISTA_PRENOTAZIONE, ERRORE.
La LISTA_PRENOTAZIONE avrà una sola occorrenza che corrisponde alla pratica corrente di cui si è registrato il pagamento. Di seguito descriviamo la struttura e negli esempi che seguiranno vedremo come valorizzare i campi.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
SetAvvenutoPagamentoResponse | 1 | s | 1 | M | -- | Contenitore msg |
SetAvvenutoPagamentoResult | 2 | s | 1 | M | -- | Contenitore richiesta |
PAZIENTE | 3 | s | 1 | M | Contenitore Dati del paziente | |
COGNOME | 4 | an | 1 | M | 250 | Valorizzare con il cognome se persona fisica, con la ragione sociale se persona giuridica |
NOME | 4 | an | 1 | O | 250 | Valorizzare obbligatoriamente con il nome se persona fisica, non valorizzare se persona giuridica perché è stato valorizzato la regione sociale nel tag COGNOME |
DATA_NASCITA | 4 | d | 1 | M | 10 | Valorizzare con la data di nascita se persona fisica, con la data di costituzione dell’azienda se persona giuridica Es. 10/01/2022 |
CODICE_FISCALE | 4 | an | 1 | M | 16 | Valorizzare con 16 caratteri alfanumerici se persona fisica (codice fiscale o STP o ENI), con 11 caratteri nel caso di persona giuridica (partita IVA) |
INDIRIZZO | 4 | an | 1 | M | 250 | Valorizzare con l’indirizzo di residenza |
Dato | Xxx | Xxx | Tag | Obb | Xxx | Xxxxxxxxx |
se persona fisica, della sede legale se persona giuridica | ||||||
COMUNE | 4 | an | 1 | M | 250 | Valorizzare con il comune di residenza se persona fisica, della sede legale se persona giuridica |
PROVINCIA | 4 | an | 1 | M | 2 | Valorizzare con la provincia residenza se persona fisica, della sede legale se persona giuridica |
CAP | 4 | an | 1 | M | 6 | Valorizzare con il CAP di residenza se persona fisica, della sede legale se persona giuridica. È lungo 6 solo per accogliere il codice dello stato estero in caso di persona extracomunitaria. |
LISTA_PRENOTAZIONE | 3 | s | 1 | M | Contenitore | |
PRATICA | 4 | s | 1 | M | Contenitore valorizzare, altrimenti valorizzare come da specifiche che seguono | |
IMPORTO_PRATICA | 5 | dec | 1 | M | Valorizzare con l’importo totale che il paziente deve pagare o ha pagato. L’importo totale deve corrispondere a: IMPORTO_DA_PAGARE + IMPORTO_PAGATO + IMPORTO_MARCA_BOLLO + IMPORTO_IVA pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_MARCA_BOLLO | 5 | dec | 1 | M | Valorizzare con l’importo della marca da bollo, quando sia dovuta, altrimenti 0.00 pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_IVA | 5 | dec | 1 | M | Valorizzare con l’importo dell’Iva, quando sia dovuto pattern value="\d{1,6}.\d{1,2}" | |
PERCENTUALE_IVA | 5 | an | 1 | M | Se la pratica è soggetta al pagamento dell’IVA, valorizzare con l’aliquota IVA in percentuale. Numero tra [0..100] Es. 0 per indicare lo 0%, 4 per indicare il 4%, etc. Altrimenti valorizzare con natura IVA [si veda il par. 3.13]. | |
PRESTAZIONE_EROGATA | 5 | an | 0 | F | 2 | Valorizzare, se il dato è disponibile al dipartimentale, con la stringa “SI” se le prestazioni associate alla posizione debitoria sono state erogate, “NO” nel caso contrario |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
CODICE_VERSAMENTO | 5 | an | 1 | M | 4 | Composto da quattro caratteri5. Il codice versamento è stabilito dall’ASR e usato per generare lo IUV nel pagamento pagoPA Es. “1100” |
PRENOTAZIONE | 5 | s | 1 | M | Contenitore | |
NUMERO_PRATICA | 6 | an | 1 | M | 16 | Identificativo ticket a 16 caratteri |
CODICE_SPECIALITA_EROGATA | 6 | an | 0 | F | 100 | valorizzare con la branca regionale se disponibile al dipartimentale |
IMPORTO_DA_PAGARE | 6 | dec | 1 | M | Valorizzare con l’importo che il paziente deve ancora pagare, comprensivo di eventuale marca da bollo (tag IMPORTO_MARCA_BOLLO) e IVA (tag IMPORTO_IVA) | |
IMPORTO_PAGATO | 6 | dec | 1 | M | Valorizzare con l’importo che il paziente ha già pagato | |
LISTA_FATTURA | 6 | s | 1 | M | Contenitore Se la pratica è in stato ancora da pagare allora non valorizzare, altrimenti valorizzare come da specifiche che seguono Attenzione i pagamenti parziali non sono più gestiti. | |
ELENCO_PAGAMENTI | 7 | s | 1 | M | Contenitore Descrivere in questi campi il pagamento eseguito dal paziente | |
NUMERO_SPORTELLO | 8 | an | 1 | M | 64 | Valorizzare con l’identificativo dello sportello dove è avvenuto il pagamento |
NUMERO_RICEVUTA | 8 | an | 1 | M | 20 | Valorizzare con l’identificativo del pagamento (es. l’identificativo della ricevuta, …) |
DATA_RICEVUTA | 8 | d | 1 | M | 10 | Valorizzare con la data del pagamento |
IMPORTO_RICEVUTA | 8 | dec | 1 | M | Valorizzare con l’importo pagato pattern value="\d{1,6}.\d{1,2}" | |
AVVISO_PAGAMENTO | 8 | s | 0 | O | Contenitore Valorizzato se la pratica è stata pagata con PagoPA modello 3 come segue, altrimenti non valorizzato | |
AUXDIGIT | 9 | an | 1 | M | 1 | Composto da un solo carattere |
APPLICATION_CODE | 9 | an | 1 | F | 2 | Non valorizzare |
IUV | 9 | an | 1 | M | 17 | Nel formato Standard ISO 11649:2009 |
5 Il codice versamento è fornito dall’ASR, valorizzato secondo le codifiche SIOPE. Il SIOPE (Sistema informativo sulle operazioni degli enti pubblici), è un sistema di rilevazione telematica degli incassi e dei pagamenti effettuati dai tesorieri di tutte le amministrazioni pubbliche, che nasce dalla collaborazione tra la Ragioneria Generale dello Stato, la Banca d'Italia e l'ISTAT, in attuazione dall'articolo 28 della legge n. 289/2002, disciplinato dall’articolo 14, commi dal 6 all’11, della legge n. 196 del 2009.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
(stringa alfanumerica di lunghezza massima di 17 caratteri) | ||||||
DATA_ASSOCIAZIONE | 9 | an | 0 | F | 10 | Non valorizzare |
IUV_MOD1 | 8 | an | 0 | O | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009 |
FLAGPAGAMENTOANTICIPATO | 8 | an | 0 | O | 1 | Il campo deve essere valorizzato a “1” per indicare il pagamento della spesa sostenuta dal cittadino in data antecedente alla data di emissione del “documento fiscale” [A06]. Obbligatorio solo se data pagamento antecedente data emissione |
FLAGTIPOSPESA | 8 | an | 0 | O | 1 | Il campo è valorizzato al fine di evidenziare caratteristiche particolari di alcune tipologie di spesa. Il campo vale: “1” con tipo TK (ticket di pronto soccorso) o “2” con tipo SR (visita in intramoenia) [A06] |
TIPOSPESA | 8 | an | 0 | O | 2 | |
DATAEMISSIONE | 8 | dat | 0 | O | 10 | Data di emissione del “documento fiscale” relativo alla spesa sostenuta dal cittadino [A06] |
PAGAMENTO_TRACCIATO | 8 | an | 0 | M | 2 | da valorizzare con “SI” se il pagamento è avvenuto tramite mezzo di pagamento tracciato come previsto dall’art. 85 DDLB 2020, “NO” se il pagamento è avvenuto in contanti. Obbligatorio dal 1/1/2020 per tutte le spese tranne che per le tipologie TK, FC, AD, FV e per quelle inviate da strutture specialistiche pubbliche o private accreditate. Vedi [A06] |
ELENCO_PRESTAZIONI | 6 | s | 0 | O | Contenitore Nel caso di pagamento sanitario il tag è da valorizzare, non valorizzare nel caso di pagamento amministrativo. | |
PRESTAZIONE | 7 | s | 1 | M | Contenitore | |
CODICE | 8 | an | 1 | M | codice regionale della prestazione | |
DESCRIZIONE | 8 | an | 1 | M | descrizione regionale della prestazione (vedere F.A.Q.) | |
DATA_APPUNTAMENTO | 8 | an | 1 | M | 10 | DD/MM/YYYY |
ORA_APPUNTAMENTO | 8 | an | 1 | M | 5 | formato hh:mm |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
IMPORTO_PRESTAZIONE | 8 | an | 1 | M | importo della prestazione erogata | |
NOTE_APPUNTAMENTO | 8 | an | 0 | F | note riportate sul foglio della prenotazione che spiega come presentarsi all’appuntamento sanitario (vedere F.A.Q.) | |
COMUNE_APPUNTAMENTO | 8 | an | 0 | F | 250 | comune dove viene erogata la prestazione (attenzione questa informazione sarà visualizzata non inserire dati sensibili), |
INDIRIZZO_APPUNTAMENTO | 8 | an | 0 | F | 250 | indirizzo dove viene erogata la prestazione |
PROVINCIA_APPUNTAMENTO | 8 | an | 0 | F | 2 | provincia (es. TO, AT, …) dove viene erogata la prestazione |
CAP_APPUNTAMENTO | 8 | an | 0 | F | 5 | CAP dove viene erogata la prestazione |
NUMERO_QUIETANZA | 6 | an | 0 | F | 20 | Non valorizzare |
OUTPUT_RICEVUTA | 6 | an | 0 | O | A discrezione dell’ASR la valorizzazione con il pdf in formato base64 della ricevuta. Attenzione i pagamenti parziali non sono più gestiti. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa. Nel caso in cui la ricevuta / fattura differisse da una precedente copia in possesso del paziente, il CSI inoltrerà la richiesta di verifica direttamente all’ASR in quanto proprietaria del dato. Il tag non è da valorizzare nel caso in cui il S.I. dell’ASR utilizzi il template regionale delle ricevute / fatture | |
MOTIVO_PAGAMENTO | 6 | an | 1 | M | 1 | |
ASR_BENEFICIARIA | 6 | an | 1 | M | 3 | Valorizzare con il codice regionale dell’azienda sanitaria beneficiaria dell’importo ticket (301, 203, …) |
CODICE_SERVIZIO | 6 | an | 1 | M | 2 | Valorizzare con la codifica del servizio. Il codice è di due caratteri ed è concordato a livello regionale |
DATA_CREAZIONE_PRENOTAZIONE | 6 | an | 0 | F | 10 | Se si tratta di una prenotazione sanitaria ed è disponibile al dipartimentale valorizzare con la data di creazione e/o ultima modifica della prenotazione disponibile nel dipartimentale |
AVVISO_PAGAMENTO | 6 | s | 1 | M | Contenitore |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
AUXDIGIT | 7 | an | 1 | M | 1 | composto da un solo carattere |
APPLICATION_CODE | 7 | an | 1 | M | 2 | non valorizzare |
IUV | 7 | an | 1 | M | 17 | Valorizzato nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 7 | d | 1 | M | 10 | data nel formato dd/mm/yyyy |
IUV_MOD1 | 6 | an | 0 | F | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009, altrimenti il tag non è valorizzato |
OPPOSIZIONE_730 | 6 | bin | 0 | O | 1 | Indica la scelta che ha fatto il paziente circa la trasmissione del pagamento all’Agenzia delle Entrate per la compilazione automatica del 730. Da valorizzare con il carattere: - “0” per esprimere l’opposizione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - “1” per esprimere l’autorizzazione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - non specificare se non disponibile al dipartimentale |
LISTA_NRE | 6 | s | 0 | O | Contenitore valorizzare con l’elenco degli NRE (numero di ricetta elettronica). Se la pratica non è collegata a nessuna ricetta elettronica non valorizzare | |
NRE | 7 | an | n | O | 15 | è un identificativo di 15 caratteri. Attenzione la pratica può essere collegata a più di una ricetta elettronica |
LISTA_RIMBORSI | 6 | s | 0 | O | Contenitore valorizzare il rimborso da specifiche che seguono | |
RIMBORSO | 7 | s | 1 | M | 1 | può esserci un unico tag RIMBORSO se la MODALITA_RIMBORSO del ticket vale 1(voucher) o 2 (bonifico), può essercene più di uno se vale 3 (borsellino) |
NUMERO_SPORTELLO | 8 | an | 1 | M | 64 | valorizzare con il numero di sportello tramite cui è stata aggiornata la MODALITA_RIMBORSO, se conosciuto |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
NUMERO_RIMBORSO | 8 | an | 1 | M | 20 | valorizzare con l’identificativo del rimborso (es: numero identificativo del documento fiscale emesso a seguito dell’erogazione del rimborso) |
DATA_RIMBORSO | 8 | d | 1 | M | 10 | valorizzare con la data di erogazione del rimborso |
IMPORTO_RIMBORSATO | 8 | dec | 1 | M | valorizzare con l’importo rimborsato al paziente, può essere uguale o inferiore rispetto all’IMPORTO_DA_RIMBORSARE | |
CODICE_VERSAMENTO | 8 | an | 0 | F | 4 | non valorizzare |
AVVISO_PAGAMENTO | 8 | s | 0 | F | non valorizzare | |
IUV_MOD1 | 8 | an | 0 | F | 25 | non valorizzare |
OUTPUT_RIMBORSO | 8 | an | 0 | F | da valorizzare con il pdf in formato base64 della ricevuta del rimborso erogato al paziente. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa | |
DATA_EMISSIONE | 8 | d | 1 | M | 10 | valorizzare con la data di emissione del documento fiscale relativo al rimborso erogato |
PRATICA_PAGATA_CON_CREDITO | 8 | an | 1 | M | 27 | valorizzare con l’identificativo della pratica (a 27 caratteri) per pagare la quale è stato utilizzato in parte o in toto il credito del rimborso. Da popolare solo se la MODALITA RIMBORSO è 3 (borsellino) |
OUTPUT_VOUCHER | 8 | an | 0 | O | a discrezione dell’ASR la valorizzazione con il pdf in formato base64 del voucher del rimborso. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa | |
IMPORTO_DA_RIMBORSARE | 6 | dec | 0 | O | Da valorizzare con l’importo che l’ASR deve ancora rimborsare al paziente, se non si tratta di ticket da rimborsare non valorizzare | |
IMPORTO_RIMBORSATO | 6 | dec | 0 | O | Da valorizzare con l’importo che l’ASR ha già rimborsato al paziente, se non si tratta di ticket da rimborsare non valorizzare | |
MODALITA_RIMBORSO | 6 | an | 0 | O | 1 | da valorizzare con la modalità tramite cui il paziente ha scelto di ricevere il |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
rimborso, se l’utente non l’ha ancora scelta o non si tratta di ticket da rimborsare non valorizzare | ||||||
ERRORE | 3 | s | 1 | M | Contenitore Per i possibili valori vedi tabella sottostante | |
CODICE | 4 | an | 1 | M | 3 | Codice degli errori/stato posizione debitoria. I codici sono descritti sotto |
MESSAGGIO | 4 | an | 1 | M | Messaggio descrittivo sul codice errore presentatosi nel dipartimentale |
La tabella sottostante contiene i valori dei codici di ERRORE.
CODICE | DESCRIZIONE |
001 | Pratica pagata totalmente |
002 | Pratica pagata totalmente ma integrata |
003 | Pratica esente |
010 | Pratica pagata parzialmente |
033 | Pratica già rimborsata |
800 | Pratica annullata |
801 | Pratica rimborsata |
802 | Pratica da rimborsare |
999 | Errore per fault |
Stato Ticket
Nel campo errore inserire lo stato del ticket.
Nel campo messaggio è possibile inserire delle descrizioni più dettagliate di quelle genericamente riportate nella tabella.
Negli esempi sottostanti riproduciamo tutti i casi possibili.
☞ | Come esempio di risposta si veda [A10] • SetAvvenutoPagamentoResponse-Canale tesoriere.xml, esempio di response della registrazione del pagamento avvenuto da un canale messo a disposizione dalla tesoreria • SetAvvenutoPagamentoResponse-pagoPAMod1.xml, esempio di response della registrazione del pagamento avvenuto da PTW • SetAvvenutoPagamentoResponse-pagoPAMod3.xml, esempio di response della registrazione del pagamento avvenuto da PSP |
Attenzione per registrazione di pagamenti errati sono previsti i seguenti codici di errore:
• 003, Pratica esente. In questo caso si sta cercando di registrare un pagamento di una pratica da non pagare
• 010, Pratica pagata parzialmente. In questo caso si sta cercando di registrare un pagamento parziale di una pratica
• 800, Pratica annullata. In questo caso si sta cercando di registrare un pagamento di una pratica annullata
Attenzione per registrazione di rimborsi errati sono previsti i seguenti codici di errore:
• 033, Pratica già rimborsata. In questo caso si sta cercando di erogare un rimborso già completamente erogato.
2.12.3.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, valorizzare il tag CODICE con “999” e restituire la descrizione breve dell’errore all’interno del campo MESSAGGIO [A10].
2.12.3.5 Gestione altre features
2.12.4 Operazione: GetListaTicket
Il servizio è di lettura dati. I dati risiedono sul sistema informativo dell’ASR (CUP, LIS, …, cassa). Il servizio richiede tutte le pratiche (costituite dalle spese e dati sanitari) che sono stati modificati e/o generati rispetto all’ultima trasmissione avvenuta a seguito ad invocazione di una precedente GetListaTicket.
2.12.4.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio GetListaTicket esposto dal sistema informativo aziendale. Con la GetListaTicket il GPA pagoPA richiede le informazioni sulle pratiche che non sono ancora state trasmesse e/o che hanno subito una modifica rispetto alla precedente trasmissione.
In caso di prenotazione annullata o disdettata occorre trasmettere al GPA pagoPA lo stato annullato specificando nel tag ERRORE il codice di Pratica annullata (vedi cap. 2.4) (vedi F.A.Q. | |
Con questa richiesta l’ASR dovrà trasmettere anche i rimborsi ottenuti dai pazienti. | |
Per limitare il volume del messaggio di risposta del S.I. dell’ASR, il GPA pagoPA invocherà il servizio in maniera schedulata la richiesta avverrà più volte al giorno con frequenza prevista ogni 5 minuti. | |
I dati restituiti dal S.I. dell’ASR relativi allo stato delle pratiche alimenterà la sezione PORTALE DEL CITTADINO dedicato al paziente. | |
☞ | Il S.I. dell’ASR riceverà successivamente il messaggio SetTicketAcquisiti (vedi per maggiori dettagli il paragrafo riguardante il servizio SetTicketAcquisiti) per far sì che i ticket trasmessi con la risposta al messaggio GetListaTicket possano essere segnati dentro il S.I. come già trasmessi e quindi se non intercorrono variazioni non dovranno più essere trasmessi nella successiva GetListaTicket. |
La chiamata al servizio è sincrona. | |
Il GPA pagoPA prevede la gestione di un time-out entro cui deve pervenire la risposta dal metodo. Fare riferimento al paragrafo 2.3. | |
Attenzione. verificare che i dati trasmessi rispettino i vicoli elencati in [A06]. | |
Se l’ASR ha deciso di fornire al paziente ricevute / fatture prodotte in autonomia con i propri sistemi (non avvalendosi del template regionale) allora in caso di pratica pagata (totalmente o parzialmente) il S.I. deve fornire anche il pdf in base64. | |
Per migliorare le performance del metodo l’ASR può limitare la risposta ad un certo numero di pratiche. |
2.12.4.2 Interfaccia di richiamo (input)
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
GetListaTicket | 1 | s | 1 | M | -- | Contenitore msg |
Richiesta | 2 | s | 1 | M | -- | Contenitore richiesta |
UUID | 3 | an | 1 | M | 36 | valorizzato da GPA pagoPA |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
AZIONE | 3 | an | 1 | M | 4 | codice azione (vale “8”) |
XXX | 0 | an | 1 | M | 3 | codice regionale dell’ASR per cui si sta eseguendo la request |
Esempio richiesta in [A11].
2.12.4.3 Interfaccia di output
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
GetListaTicketResponse | 1 | s | 1 | M | -- | Contenitore msg |
GetListaTicketResult | 2 | s | 1 | M | -- | Contenitore richiesta |
LISTA_TICKET | 3 | s | 1 | n | Contenitore Contiene la lista delle prenotazioni, se ci sono | |
LISTA_ REGISTRAZIONE_ PAGAMENTI_ DIFFERITI | 4 | s | 1 | M | Contenitore | |
PAZIENTE | 5 | s | 1 | M | Contenitore Dati del paziente | |
COGNOME | 6 | an | 1 | M | 250 | Valorizzare con il cognome se persona fisica, con la ragione sociale se persona giuridica |
NOME | 6 | an | 1 | O | 250 | Valorizzare obbligatoriamente con il nome se persona fisica, non valorizzare se persona giuridica perché è stato valorizzato la regione sociale nel tag COGNOME |
DATA_NASCITA | 6 | d | 1 | M | 10 | Valorizzare con la data di nascita se persona fisica, con la data di costituzione dell’azienda se persona giuridica Es. 10/01/2022 |
CODICE_FISCALE | 6 | an | 1 | M | 16 | Valorizzare con 16 caratteri alfanumerici se persona fisica (codice fiscale o STP o ENI), con 11 caratteri nel caso di persona giuridica (partita IVA) |
INDIRIZZO | 6 | an | 1 | M | 250 | Valorizzare con l’indirizzo di residenza se persona fisica, della sede legale se persona giuridica |
COMUNE | 6 | an | 1 | M | 250 | Valorizzare con il comune di residenza se persona fisica, della sede legale se persona giuridica |
PROVINCIA | 6 | an | 1 | M | 2 | Valorizzare con la provincia residenza se persona fisica, della sede legale se persona giuridica |
CAP | 6 | an | 1 | M | 6 | Valorizzare con il CAP di residenza se persona fisica, della sede legale se |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
persona giuridica. È lungo 6 solo per accogliere il codice dello stato estero in caso di persona extracomunitaria. | ||||||
LISTA_PRENOTAZIONE | 5 | s | 1 | M | Contenitore | |
PRATICA | 6 | s | 1 | M | Contenitore valorizzare come da specifiche che seguono | |
IMPORTO_PRATICA | 7 | dec | 1 | M | Valorizzare con l’importo totale che il paziente deve pagare o ha pagato. L’importo totale deve corrispondere a: IMPORTO_DA_PAGARE + IMPORTO_PAGATO + IMPORTO_MARCA_BOLLO + IMPORTO_IVA pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_MARCA_BOLLO | 7 | dec | 1 | M | Valorizzare con l’importo della marca da bollo, quando sia dovuta, altrimenti 0.00 pattern value="\d{1,6}.\d{1,2}" | |
IMPORTO_IVA | 7 | dec | 1 | M | Valorizzare con l’importo dell’Iva, quando sia dovuto pattern value="\d{1,6}.\d{1,2}" | |
PERCENTUALE_IVA | 7 | an | 1 | M | Se la pratica è soggetta al pagamento dell’IVA, valorizzare con l’aliquota IVA in percentuale. Numero tra [0..100] Es. 0 per indicare lo 0%, 4 per indicare il 4%, etc. Altrimenti valorizzare con natura IVA [si veda il par. 3.13]. | |
PRESTAZIONE_EROGATA | 7 | an | 0 | F | 2 | Valorizzare, se il dato è disponibile al dipartimentale, con la stringa “SI” se le prestazioni associate alla posizione debitoria sono state erogate, “NO” nel caso contrario |
CODICE_VERSAMENTO | 7 | an | 1 | M | 4 | Composto da quattro caratteri6. Il codice versamento è stabilito dall’ASR e usato per generare lo IUV nel pagamento pagoPA Es. “1100” |
PRENOTAZIONE | 7 | s | 1 | M | Contenitore |
6 Il codice versamento è fornito dall’ASR, valorizzato secondo le codifiche SIOPE. Il SIOPE (Sistema informativo sulle operazioni degli enti pubblici), è un sistema di rilevazione telematica degli incassi e dei pagamenti effettuati dai tesorieri di tutte le amministrazioni pubbliche, che nasce dalla collaborazione tra la Ragioneria Generale dello Stato, la Banca d'Italia e l'ISTAT, in attuazione dall'articolo 28 della legge n. 289/2002, disciplinato dall’articolo 14, commi dal 6 all’11, della legge n. 196 del 2009.
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
NUMERO_PRATICA | 8 | an | 1 | M | 16 | Identificativo ticket a 16 caratteri |
NUMERO_PRATICA_ALTERNATIVO | 8 | an | 1 | M | 16 | non valorizzare |
CODICE_SPECIALITA_EROGATA | 8 | an | 0 | F | Valorizzare se gestito dal dipartimentale | |
IMPORTO_DA_PAGARE | 8 | dec | 1 | M | Valorizzare con l’importo che il paziente deve ancora pagare, comprensivo di eventuale marca da bollo (tag IMPORTO_MARCA_BOLLO) e IVA (tag IMPORTO_IVA) | |
IMPORTO_PAGATO | 8 | dec | 1 | M | Valorizzare con l’importo che il paziente ha già pagato | |
LISTA_FATTURA | 8 | s | 0 | O | Contenitore Se la pratica è in stato ancora da pagare allora non valorizzare, altrimenti valorizzare come da specifiche che seguono Attenzione i pagamenti parziali non sono più gestiti. | |
ELENCO_PAGAMENTI | 9 | s | 1 | M | Contenitore Descrivere in questi campi il pagamento eseguito dal paziente | |
NUMERO_SPORTELLO | 10 | an | 1 | M | 64 | Valorizzare con l’identificativo dello sportello dove è avvenuto il pagamento |
NUMERO_PRATICA | 10 | an | 0 | F | 16 | Non valorizzare |
NUMERO_RICEVUTA | 10 | an | 1 | M | 20 | Valorizzare con l’identificativo del pagamento (es. l’identificativo della ricevuta, …) |
DATA_RICEVUTA | 10 | d | 1 | M | 10 | Valorizzare con la data del pagamento |
IMPORTO_RICEVUTA | 10 | dec | 1 | M | Valorizzare con l’importo pagato pattern value="\d{1,6}.\d{1,2}" | |
AVVISO_PAGAMENTO | 10 | s | 0 | O | Contenitore Valorizzato se la pratica è stata pagata con PagoPA modello 3 come segue, altrimenti non valorizzato | |
AUXDIGIT | 11 | an | 1 | M | 1 | Composto da un solo carattere |
APPLICATION_CODE | 11 | an | 1 | F | 2 | Non valorizzare |
IUV | 11 | an | 1 | M | 17 | Nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 11 | an | 0 | F | 10 | Non valorizzare |
IUV_MOD1 | 10 | an | 0 | O | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009 |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
FLAGPAGAMENTOANTICIPATO | 10 | an | 0 | O | 1 | Il campo deve essere valorizzato a “1” per indicare il pagamento della spesa sostenuta dal cittadino in data antecedente alla data di emissione del “documento fiscale” [A06]. Obbligatorio solo se data pagamento antecedente data emissione |
FLAGTIPOSPESA | 10 | an | 0 | O | 1 | Il campo è valorizzato al fine di evidenziare caratteristiche particolari di alcune tipologie di spesa. Il campo vale: “1” con tipo TK (ticket di pronto soccorso) o “2” con tipo SR (visita in intramoenia) [A06] |
TIPOSPESA | 10 | an | 0 | O | 2 | |
DATAEMISSIONE | 10 | dat | 0 | O | 10 | Data di emissione del “documento fiscale” relativo alla spesa sostenuta dal cittadino [A06] |
PAGAMENTO_TRACCIATO | 10 | an | 0 | M | 2 | da valorizzare con “SI” se il pagamento è avvenuto tramite mezzo di pagamento tracciato come previsto dall’art. 85 DDLB 2020, “NO” se il pagamento è avvenuto in contanti. Obbligatorio dal 1/1/2020 per tutte le spese tranne che per le tipologie TK, FC, AD, FV e per quelle inviate da strutture specialistiche pubbliche o private accreditate. Vedi [A06] |
ELENCO_PRESTAZIONI | 8 | s | 0 | O | Contenitore Nel caso di pagamento sanitario il tag è da valorizzare, non valorizzare nel caso di pagamento amministrativo. | |
PRESTAZIONE | 9 | s | 1 | M | Contenitore | |
CODICE | 10 | an | 1 | M | codice regionale della prestazione | |
DESCRIZIONE | 10 | an | 1 | M | descrizione regionale della prestazione (vedere F.A.Q.) | |
DATA_APPUNTAMENTO | 10 | an | 1 | M | 10 | DD/MM/YYYY |
ORA_APPUNTAMENTO | 10 | an | 1 | M | 5 | formato hh:mm |
IMPORTO_PRESTAZIONE | 10 | an | 1 | M | importo della prestazione erogata | |
NOTE_APPUNTAMENTO | 10 | an | 0 | F | note riportate sul foglio della prenotazione che spiega come presentarsi all’appuntamento sanitario (vedere F.A.Q.) | |
COMUNE_APPUNTAMENTO | 10 | an | 0 | F | 250 | comune dove viene erogata la prestazione, esempio Torino, Avigliana, etc…, (attenzione questa |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
informazione sarà visualizzata non inserire dati sensibili). Questo campo è utilizzato per la georeferenziazione su gmap | ||||||
INDIRIZZO_APPUNTAMENTO | 10 | an | 0 | F | 250 | indirizzo (compreso il civico) del luogo dove sarà erogata la prestazione, esempio “Via sant’xxxxxxxx 5”, “xxx xxx xxxxxx 0”, etc. |
PROVINCIA_APPUNTAMENTO | 10 | an | 0 | F | 2 | provincia (es. TO, AT, …) dove viene erogata la prestazione |
CAP_APPUNTAMENTO | 10 | an | 0 | F | 5 | CAP dove viene erogata la prestazione |
NUMERO_QUIETANZA | 8 | an | 0 | F | 20 | Non valorizzare |
OUTPUT_RICEVUTA | 8 | an | 0 | O | A discrezione dell’ASR la valorizzazione con il pdf in formato base64 della ricevuta. Attenzione i pagamenti parziali non sono più gestiti. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa. Nel caso in cui la ricevuta / fattura differisse da una precedente copia in possesso del paziente, il CSI inoltrerà la richiesta di verifica direttamente all’ASR in quanto proprietaria del dato. Il tag non è da valorizzare nel caso in cui il S.I. dell’ASR utilizzi il template regionale delle ricevute / fatture | |
MOTIVO_PAGAMENTO | 8 | an | 1 | M | 1 | |
ASR_BENEFICIARIA | 8 | an | 1 | M | 3 | Valorizzare con il codice regionale dell’azienda sanitaria beneficiaria dell’importo ticket (301, 203, …) |
CODICE_SERVIZIO | 8 | an | 1 | M | 2 | valorizzare con il codice con cui è identificato il servizio generatore della pratica. I codici verranno concordati volta per volta a livello regionale (par. 2.9) |
DATA_CREAZIONE_PRENOTAZIONE | 8 | an | 0 | F | 10 | Se si tratta di una prenotazione sanitaria ed è disponibile al dipartimentale valorizzare con la data di creazione e/o ultima modifica della prenotazione disponibile nel dipartimentale |
AVVISO_PAGAMENTO | 8 | s | 1 | M | Contenitore | |
AUXDIGIT | 9 | an | 1 | M | 1 | composto da un solo carattere |
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
APPLICATION_CODE | 9 | an | 1 | M | 2 | non valorizzare |
IUV | 9 | an | 1 | M | 17 | Valorizzato nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri) |
DATA_ASSOCIAZIONE | 9 | d | 1 | M | 10 | data nel formato dd/mm/yyyy |
IUV_MOD1 | 8 | an | 0 | F | 25 | Stringa alfanumerica di lunghezza massima di 25 caratteri. Valorizzato se la pratica è stata pagata con la procedura regionale di pagamento ticket PTW (PagoPA modello 1) nel formato Standard ISO 11649:2009, altrimenti il tag non è valorizzato |
OPPOSIZIONE_730 | 8 | bin | 0 | O | 1 | Indica la scelta che ha fatto il paziente circa la trasmissione del pagamento all’Agenzia delle Entrate per la compilazione automatica del 730. Da valorizzare con il carattere: - “0” per esprimere l’opposizione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - “1” per esprimere l’autorizzazione all'invio dei dati del ticket all'Agenzia delle Entrate per la precompilazione del 730 - non specificare se non disponibile al dipartimentale |
LISTA_NRE | 8 | s | 0 | O | Contenitore valorizzare con l’elenco degli NRE (numero di ricetta elettronica). Se la pratica non è collegata a nessuna ricetta elettronica non valorizzare | |
NRE | 9 | an | n | O | 15 | è un identificativo di 15 caratteri. Attenzione la pratica può essere collegata a più di una ricetta elettronica |
LISTA_RIMBORSI | 8 | s | 0 | O | Contenitore valorizzare il rimborso da specifiche che seguono | |
RIMBORSO | 9 | s | 1 | M | 1 | può esserci un unico tag RIMBORSO se la MODALITA_RIMBORSO del ticket vale 1(voucher) o 2 (bonifico), può essercene più di uno se vale 3 (borsellino) |
NUMERO_SPORTELLO | 10 | an | 1 | M | 64 | valorizzare con il numero di sportello tramite cui è stata aggiornata la MODALITA_RIMBORSO, se conosciuto |
NUMERO_RIMBORSO | 10 | an | 1 | M | 20 | valorizzare con l’identificativo del |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
rimborso (es: numero identificativo del documento fiscale emesso a seguito dell’erogazione del rimborso) | ||||||
DATA_RIMBORSO | 10 | d | 1 | M | 10 | valorizzare con la data di erogazione del rimborso |
IMPORTO_RIMBORSATO | 10 | dec | 1 | M | valorizzare con l’importo rimborsato al paziente, può essere uguale o inferiore rispetto all’IMPORTO_DA_RIMBORSARE | |
CODICE_VERSAMENTO | 10 | an | 0 | F | 4 | non valorizzare |
AVVISO_PAGAMENTO | 10 | s | 0 | F | non valorizzare | |
IUV_MOD1 | 10 | an | 0 | F | 25 | non valorizzare |
OUTPUT_RIMBORSO | 10 | an | 0 | F | da valorizzare con il pdf in formato base64 della ricevuta del rimborso erogato al paziente. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa | |
DATA_EMISSIONE | 10 | d | 1 | M | 10 | valorizzare con la data di emissione del documento fiscale relativo al rimborso erogato |
PRATICA_PAGATA_CON_CREDITO | 10 | an | 1 | M | 27 | valorizzare con l’identificativo della pratica (a 27 caratteri) per pagare la quale è stato utilizzato in parte o in toto il credito del rimborso. Da popolare solo se la MODALITA RIMBORSO è 3 (borsellino) |
OUTPUT_VOUCHER | 10 | an | 0 | O | a discrezione dell’ASR la valorizzazione con il pdf in formato base64 del voucher del rimborso. Si fa notare che i dati riportati nel pdf devono coincidere con i dati riportati nei vari tag. Il pdf trasmesso sarà salvato nella base dati e sostituirà l’eventuale precedete copia pdf trasmessa | |
IMPORTO_DA_RIMBORSARE | 8 | dec | 0 | O | Da valorizzare con l’importo che l’ASR deve ancora rimborsare al paziente, se non si tratta di ticket da rimborsare non valorizzare | |
IMPORTO_RIMBORSATO | 8 | dec | 0 | O | Da valorizzare con l’importo che l’ASR ha già rimborsato al paziente, se non si tratta di ticket da rimborsare non valorizzare | |
MODALITA_RIMBORSO | 8 | an | 0 | O | 1 | da valorizzare con la modalità tramite cui il paziente ha scelto di ricevere il rimborso, se l’utente non l’ha ancora |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
scelta o non si tratta di ticket da rimborsare non valorizzare | ||||||
ERRORE | 6 | s | 1 | M | Contenitore Questa struttura descrive lo stato del ticket. Per i possibili valori vedi tabella Stato Pratica | |
CODICE | 7 | an | 1 | M | 3 | Codice degli errori/stato posizione debitoria. I codici sono descritti sotto |
MESSAGGIO | 7 | an | 1 | M | Messaggio descrittivo sul codice errore presentatosi nel dipartimentale | |
ERRORE | 3 | s | 1 | M | Contenitore Questa struttura descrive lo l’esito della gestione del messaggio. Per i possibili valori vedi tabella Errore XML | |
CODICE | 4 | an | 1 | M | 3 | Codice degli errori/stato posizione debitoria. I codici sono descritti sotto |
MESSAGGIO | 4 | an | 1 | M | Messaggio descrittivo sul codice errore presentatosi nel dipartimentale |
La tabella sottostante contiene i valori dei codici di ERRORE.
• CODICE, codifica dello stato della pratica, come da tabella sottostante.
• MESSAGGIO, descrizione dello stato della pratica, come da tabella sottostante.
CODICE | DESCRIZIONE |
001 | Pratica pagata totalmente |
002 | Pratica pagata totalmente integrata |
003 | Pratica esente |
015 | Pratica non pagata |
800 | Pratica annullata |
801 | Pratica rimborsata |
802 | Pratica da rimborsare |
999 | Errore per fault |
Stato Pratica
Nel campo messaggio è possibile inserire delle descrizioni più dettagliate di quelle genericamente riportate nella tabella.
Chiudere il messaggio valorizzando il tag ERRORE che si riferisce allo stato della trasmissione degli aggiornamenti
• CODICE, codifica dello stato della trasmissione, come da tabella sottostante.
• MESSAGGIO, descrizione dello stato della trasmissione, come da tabella sottostante.
CODICE | DESCRIZIONE |
000 | Ok |
999 | Errore per Fault |
Errore XML
Esempi di risposta in [A11].
2.12.4.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, restituire la descrizione breve dell’errore all’interno del campo soap fault [A11].
2.12.4.5 Gestione altre features
N.A.
2.12.5 Operazione: GetRicevutaFiscaleFattura
Il servizio è di lettura dati. I dati risiedono sul S.I. dell’ASR (CUP, LIS, …) dove è memorizzata la copia pdf / jpg della pratica che è stata pagata. Il metodo sarà utilizzato dal GPA pagoPA solo se l’ASR si avvale dei propri sistemi per stampare la ricevuta di pagamento da fornire al paziente. Se l’ASR utilizzerà il template regionale previsto per le ricevute o fatture di pagamento, allora il metodo non sarà utilizzato.
2.12.5.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio GetRicevutaFiscaleFattura esposto dal sistema informativo aziendale specificando una delle tre chiavi di ricerca identificativo della pratica, IUV oppure NRE della posizione debitoria per la quale è richiesta la copia pdf della ricevuta / fattura. Il S.I. dell’ASR estrae e trasmette la ricevuta relativa al pagamento con le informazioni dalla pratica.
Il metodo esposto dal S.I. dell’ASR restituisce il pdf / jpg in base64 collegato all’identificativo della pratica | |
☞ | Il S.I. dell’ASR deve obbligatoriamente implementare il metodo se intende produrre in autonomia con i propri sistemi la ricevuta o fattura da consegnare al paziente. In questo caso al termine del pagamento l’applicativo regionale PTW, indipendentemente dal canale di pagamento utilizzato dal paziente (POS o pagoPA), restituirà La copia pdf sarà memorizzata nella base dati del GPA e del GPR e sostituirà un’eventuale altra copia presente La copia sarà messa a disposizione del paziente attraverso il Fascicolo Finanziario |
Il S.I. dell’ASR può decidere di non implementare il metodo se intende produrre la ricevuta o fattura avvalendosi del template regionale valido ai fini fiscali. In questo caso i metadati del pagamento restituiti dal S.I. dell’Azienda Sanitaria Regionale saranno impaginati all’interno di un template regionale valido ai fini fiscali. |
2.12.5.2 Interfaccia di richiamo (input)
Valorizzazione richiesta di ricevuta / fattura.
• UUID, valorizzato da GPA pagoPA
• AZIONE = 1
• ASR, codice regionale dell’ASR per cui si sta eseguendo la request
• NUMERO_PRATICA, viene valorizzato in alternativa al IUV e NRE. Contiene l’identificativo della pratica da ricercare nel S.I. dell’ASR lungo 16 caratteri. Attenzione il numero della pratica sul GPA pagoPA è una stringa di 16 caratteri ed è fillato a sinistra con il carattere “0” sino a raggiungere la lunghezza di 16 caratteri: ad esempio se il numero pratica è una stringa lunga 12 caratteri sul S.I. dell’ASR, es. “201800000123”, il numero pratica del GPA pagoPA sarà “0000201800000123”
• NRE, viene valorizzato in alternativa al NUMERO_PRATICA e AVVISO_PAGAMENTO quando si richiede di ricercare una pratica per Numero di Ricetta Elettronica (15 caratteri)
• AVVISO_PAGAMENTO7, viene valorizzato in alternativa al NUMERO_PRATICA e NRE quando si richiede di ricercare una pratica per gli attributi previsti in questo tag [A05]
• NUMERO_SPORTELLO, se valorizzato è l’identificativo del dispositivo automatico che ha richiesto la ricerca della pratica
Esempi di richiesta in [A12].
7 L’AVVISO_PAGAMENTO è un tag non obbligatorio, composto al suo interno dai tag obbligatori AUXDIGIT, APPLICATION_CODE e IUV (modello 3 di lunghezza 17 caratteri)
2.12.5.3 Interfaccia di output
Il S.I. dell’ASR trasmette al GPA pagoPA lo stato della pratica con annesso il pdf della ricevuta / fattura in formato base64 (TAG OUTPUT_RICEVUTA / OUTPUT_RIMBORSO). La response del messaggio, fatta eccezione per i name space GetRicevutaFiscaleFatturaResponse e GetRicevutaFiscaleFatturaResult, sarà come la response GetListaTicket del par. 4100 con la differenza che al suo interno avrà una sola pratica.
Gli stati della pratica pagata possono essere:
CODICE | DESCRIZIONE |
001 | Pratica pagata totalmente |
002 | Pratica pagata totalmente integrata |
003 | Pratica Esente |
010 | Pratica pagata Parzialmente |
015 | Pratica Non Pagato |
800 | Pratica Annullato |
801 | Rimborso |
802 | Pratica da rimborsare |
999 | Errore per fault |
Esempio di risposta in [A12].
2.12.5.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, valorizzare il tag ERRORE con “999” e restituire la descrizione breve dell’errore all’interno del campo MESSAGGIO [A12].
2.12.5.5 Gestione altre features
N.A.
2.12.6 Operazione: SetTicketAcquisiti
Il servizio è di scrittura dati. I dati risiedono sul sistema informativo dell’ASR (CUP, LIS, …). Il servizio registra sul
S.I. dell’ASR:
• le pratiche che sono state acquisite dal GPA pagoPA a seguito di una GetListaTicket (par. 2.12.4), SetAvvenutoPagamento (par. 2.12.3), SetOpposizionePrecompilazione730 (par. 2.12.7), in maniera tale che queste non vengano più ritrasmesse al GPA pagoPA, a meno che non subiscano un aggiornamento sul S.I. dell’ASR;
• l’esito dell’aggiornamento della base dati del GPA;
• l’esito del controllo dei dati finalizzato alla trasmissione dei pagamenti al MEF.
2.12.6.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio SetTicketAcquisiti esposto dal sistema informativo aziendale specificando l’elenco delle pratiche che sono state acquisite all’interno della banca dati del GPA pagoPA.
Questo metodo esplicita al S.I. che le pratiche in elenco non dovranno essere più soggette a reinvio al GPA, a meno di variazioni di qualsiasi tipo intervenute successivamente sulle pratiche nel S.I. della ASR.
Il metodo restituisce l’elenco delle pratiche acquisite dal GPA per cui non è necessario la ritrasmissione, fatta eccezione che su una delle pratiche menzionate nel metodo non avvenga una modifica di stato per cui è necessario aggiornare il GPA. | |
☞ | In tempi differenti alla ricezione degli aggiornamenti, GPA esegue l’elaborazione delle informazioni ricevute e attraverso lo stesso metodo restituisce gli errori e i warning (codificati) riscontrati nell’elaborazione. I warning non impediscono l’acquisizione della pratica nel GPA. La presenza di errori non consentiranno la registrazione dell’aggiornamento e la pratica verrà scartata. L’ASR dovrà provvedere al controllo, alla correzione sul proprio sistema informativo aziendale, successivamente dovrà ritrasmettere le informazioni. Il numero pratica è l’identificativo Pratica a 16 caratteri. |
La chiamata al metodo è sincrona. | |
Il GPA pagoPA prevede la gestione di un time-out entro cui deve pervenire la risposta dal metodo. Fare riferimento al paragrafo 2.3. |
2.12.6.2 Interfaccia di richiamo (input)
Valorizzazione oggetto Richiesta
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
SetTicketAcquisiti | 1 | s | 1 | M | -- | Contenitore msg |
Richiesta | 2 | s | 1 | M | -- | Contenitore richiesta |
UUID | 3 | an | 1 | M | 36 | valorizzato da GPA pagoPA |
AZIONE | 3 | an | 1 | M | 4 | Valori possibili: • 9 per trasmettere al SIA l’elenco delle pratiche acquisite; • 9A per la trasmissione degli errori / warning rilevati durante l’aggiornamento della base dati del GPA con i dati trasmessi dal S.I. dell’Asr; |
Dato | Xxx | Xxx | Tag | Obb | Len | Contenuto |
• 9B per la trasmissione degli errori / warning sul controllo dei dati per la trasmissione dei dati al MEF per il 730 precompilato | ||||||
LISTA_PAGAMENTI | 3 | s | 1 | M | Contenitore | |
ELENCO_PAGAMENTI | 4 | s | 1 | n | Contenitore | |
NUMERO_PRATICA | 5 | an | 1 | M | 16 | valorizzato con l’identificativo della pratica a 16 caratteri |
LISTA_ERRORE | 5 | s | 0 | O | Contenitore Contiene l’elenco degli errori sui controlli dei dati da trasmettere al MEF per il calcolo delle spese del 730 precompilato. Non specificato se nessun warnging è presente | |
ERRORE | 6 | s | 1 | n | Contenitore Elenco degli errori riscontrati | |
CODICE | 7 | an | 1 | M | 4 | I codici di errore sono disponibili in [A07] |
MESSAGGIO | 7 | an | 1 | M | ||
LISTA_WARNING | 5 | s | 0 | O | Contenitore Contiene l’elenco dei warning sui controlli dei dati da trasmettere al MEF per il calcolo delle spese del 730 precompilato. Non specificato se nessun warnging è presente | |
WARNING | 6 | s | 1 | n | Contenitore Elenco degli errori riscontrati | |
CODICE | 7 | an | 1 | M | 4 | I codici di errore sono disponibili in [A07]. |
MESSAGGIO | 7 | an | 1 | M |
Esempio richiesta in [A13].
2.12.6.3 Interfaccia di output
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
SetTicketAcquisitiResponse | 1 | s | 1 | M | -- | Contenitore response |
ERRORE | 2 | s | 1 | n | Contenitore Elenco degli errori riscontrati | |
CODICE | 3 | an | 1 | M | 4 | Codice ricezione messaggio |
MESSAGGIO | 4 | an | 1 | M |
Esempio risposta in [A13].
CODICE | DESCRIZIONE |
000 | Ok |
999 | Errore per fault |
2.12.6.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, restituire la descrizione breve dell’errore all’interno del campo soap fault [A13].
2.12.6.5 Gestione altre features
N.A.
2.12.7 Operazione: SetOpposizionePrecompilazione730
Il servizio è di scrittura dati. I dati risiedono sul S.I. dell’ASR (CUP, LIS, …), il servizio registra sul S.I. la scelta del paziente circa opposizione dell’assistito a rendere disponibili i dati relativi alle spese sanitarie per la dichiarazione dei redditi precompilata8.
2.12.7.1 Descrizione dell’operazione
Il GPA pagoPA invoca il servizio SetOpposizionePrecompilazione730 esposto dal sistema informativo aziendale specificando l’identificativo della pratica su cui è necessario registrare la scelta dell’assistito a rendere disponibili i dati relativi alle spese sanitarie per la dichiarazione dei redditi precompilata. Con la SetOpposizionePrecompilazione730 il GPA pagoPA specifica tutti i dati relativi alla scelta dell’opposizione e l’identificativo della pratica. Il S.I. dell’ASR registra la scelta dell’opposizione e restituisce tutte le informazioni riassuntive del nuovo stato assunto dalla pratica.
☞ | Successivamente al SetOpposizionePrecompilazione730 il GPA pagoPA invocherà il metodo esposto dal S.I. dell’ASR SetTicketAcquisiti. |
La chiamata al metodo è sincrona. | |
Il GPA pagoPA prevede la gestione di un time-out entro cui deve pervenire la risposta dal metodo. Fare riferimento al paragrafo 2.3. |
2.12.7.2 Interfaccia di richiamo (input)
Valorizzazione richiesta di pagamento
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
setOpposizionePrecompilazione730 | 1 | s | 1 | M | -- | Contenitore msg |
Richiesta | 2 | s | 1 | M | -- | Contenitore richiesta |
UUID | 3 | an | 1 | M | 36 | valorizzato da GPA pagoPA |
AZIONE | 3 | an | 1 | M | 4 | codice azione (vale “6”) |
8 Provvedimento del direttore dell’Agenzia delle Entrate con Prot. n. 103408/2015 del 31 luglio 2015, pubblicato il 3 agosto 2015, recepisce le misure di tutela dei dati personali espressi in due differenti pareri dal Garante per la protezione dei dati personali (rif. doc. web nn. 4160058 e 4160102 del 30 luglio 2015) e offre indicazioni per l’Opposizione dell’assistito a rendere disponibili all’Agenzia delle Entrate i dati relativi alle spese sanitarie (al punto 2.4 del medesimo documento).
Dato | Liv | Gen | Tag | Obb | Len | Contenuto |
ASR | 3 | an | 1 | M | 3 | codice regionale dell’ASR per cui si sta eseguendo la request |
NUMERO_PRATICA | 3 | an | 1 | O | 16 | viene valorizzato in alternativa ai tag IUV e NRE. Contiene l’identificativo della pratica da ricercare nel S.I. dell’ASR lungo 16 caratteri. Attenzione il numero della pratica sul GPA pagoPA è una stringa di 16 caratteri ed è fillato a sinistra con il carattere “0” sino a raggiungere la lunghezza di 16 caratteri: ad esempio se il numero pratica è una stringa lunga 12 caratteri sul S.I. dell’ASR, es. “201800000123”, il numero pratica del GPA pagoPA sarà “0000201800000123” |
NUMERO_SPORTELLO | 3 | an | 1 | M | 16 | identificativo del dispositivo automatico che ha richiesto la ricerca della pratica |
OPPOSIZIONE_730 | 3 | bin | 1 | M | 1 | Indica la scelta che ha fatto il paziente circa la trasmissione del pagamento all’Agenzia delle Entrate per la compilazione automatica del 730. Da valorizzare con il carattere: -“0” per esprimere l’opposizione all'invio dei dati del Pratica all'Agenzia delle Entrate per la precompilazione del 730, -“1” per esprimere l’autorizzazione all'invio dei dati del Pratica all'Agenzia delle Entrate per la precompilazione del 730 |
Esempio richiesta di registrazione della scelta dell’assistito a rendere disponibili i dati relativi alle spese sanitarie per la dichiarazione dei redditi precompilata [A14].
2.12.7.3 Interfaccia di output
Le modifiche indicate nel par 2.12.4.3 (response di SetAvvenutoPagamento) e cioè la modifica alla semantica del tag PRATICA\PERCENTUALE_IVA e l’introduzione del tag ELENCO_PAGAMENTI\PAGAMENTO_TRACCIATO devono essere implementate anche nella response di questo web service.
Di seguito riportiamo un esempio di response del messaggio [A14].
2.12.7.4 Gestione del soap fault
Se vi è un messaggio di errore interno all’applicazione, valorizzare il tag ERRORE con “999” e restituire la descrizione breve dell’errore all’interno del campo MESSAGGIO [A14].
2.12.7.5 Gestione altre features
N.A.
2.13 DESCRIZIONE DELL’INTERFACCIA ESPOSTO DAL GPA
I paragrafi di questo capitolo descrivono i servizi esposti dal GPA su rete Rupar o su rete Internet utilizzati dal S.I. dell’ASR: i dati in ingresso delle request provenienti dal S.I. dell’ASR e le response attese con le descrizioni dei valori attesi.
Il GPA espone in Internet i servizi GetMultiIUVGPA, GetMultiIUVGPA, SetAssociazioneIUVTicketGPA. Per utilizzare questi metodi è necessario richiedere l'autorizzazione (Authorization Server).
Nulla è stato modificato per quanto riguarda l’invocazione dei metodi esposti dal GPA in rete Rupar. Il cap. 2.13.1 si applica ai fruitori dei servizi GPA in Internet.
Verrà utilizzato l’Authorization Server per proteggere i metodi GetMultiIUVGPA, GetMultiIUVGPA, SetAssociazioneIUVTicketGPA esposti dal GPA su rete Internet, cioè è necessario richiedere l'autorizzazione.
Per ottenere l'autorizzazione ad accedere ai metodi esposti in internet dal GPA si dovrà richiedere un “Bearer Token”. I Bearer Token sono un tipo particolare di Access Token conforme con lo standard OAuth2. Nel seguito riportiamo un esempio di richiesta:
curl -k -X POST xxxxx://xxx.xxx.xx/xxxxx -d "grant_type=client_credentials" -H"Authorization: Basic basic64($consumer_key:$consumer_secret)"
Dove la stringa successiva alla Authorization Basic contiene il base64 della “Consumer key” e “Consumer secret”.
Il token in ambiente di test è chiamato “Chiavi Sandbox”, mentre il ticket in ambiente di esercizio è chiamato “Chiavi prod”. Sarà fornito all’utilizzatore la URL di test o esercizio per eseguire la POST.
Ottenuto il token dalla response dall’esecuzione della curl, il chiamante dovrà eseguire la chiamata Soap del metodo desiderato avendo cura di inserire nell’header della request la chiave Authorization con valore “Bearer” più il token. La URL di certificazione sarà visibile sull’applicazione dove ci sarà una combobox per selezionare l’environment della sandbox.
Il token ha validità limitata nel tempo, quindi va richiamata la URL di creazione del token alla scadenza dello stesso. Nel caso in cui si sbagli ad inserire il token o il token è scaduto, nella request si otterrà un messaggio che spiegherà l’errore.
Nel caso in cui con una request ben formata con token valido si dovesse ottenere più volte un errore è necessario rivolgersi all’assistenza.
2.13.2 Operazione: GetMultiIUVGPA
Il servizio è di lettura e scrittura dati. I dati risiedono sul GPA, l’ASR invoca il metodo per richiede al GPA un lotto di IUV da utilizzare per l’emissione di avvisi di pagamento pagoPA.
2.13.2.1 Descrizione dell’operazione
Il S.I. dell’ASR invoca il servizio GetMultiIUVGPA specificando il codice motivo pagamento della pratica. Il GPA estrae il numero di occorrenze di IUV previste in configurazione per il codice motivo pagamento in input e la restituisce al S.I. dell’ASR.
☞ | Sul GPA pagoPA è configurato il numero di IUV che compongono un lotto (IUV da restituire). Nella configurazione del GPA è contenuto il codice pagamento associato al motivo pagamento (es. 1100 per S, etc.). |
La chiamata al metodo è sincrona. |
Il GPA pagoPA prevede la gestione di un time-out entro cui deve pervenire la risposta dal metodo. In caso si utilizzi questo servizio per approvvigionarsi di IUV, quando l’ASR assocerà materialmente un avviso di pagamento ad uno IUV preso da un lotto, occorrerà richiamare il servizio SetAssociazioneIUVTicketGPA per aggiornare di conseguenza il GPA. |
2.13.2.2 Interfaccia di richiamo (input)
valorizzazione da parte del S.I. dell’ASR della Richiesta un lotto di IUV.
• UUID, Universally Unique IDentifier (36 char, obbligatorio non vuoto) valorizzato dal S.I. dell’ASR
• AZIONE = RLI (stringa fissa, obbligatorio non vuoto)
• NUMERO_SPORTELLO, inserire il codice del servizio che invoca la richiesta: 64 char, es. “ASR 301”, “CUP”, “LIS”, “SOVRACUP”, …, obbligatorio non vuoto)
• CODICE_ASR, valorizzato con il codice ASR (3 char, obbligatorio non vuoto)
• CODICE_VERSAMENTO, valorizzare con il codice versamento per cui viene richiesto il lotto di IUV (4 char, obbligatorio non vuoto)
Si rammenta di ignorare i tag previsti dal WSDL del GPA ma non specificati nella request. Esempio di richiesta in [A15].
2.13.2.3 Interfaccia di output
Il GPA estrae dalla propria base dati il lotto di IUV e li restituisce al S.I. dell’ASR. Gli IUV non risulteranno assegnati a nessuna pratica. Quando il S.I. dell’ASR generà l’avviso di pagamento, allora notificherà la pratica a cui uno IUV verrà assegnato utilizzando il metodo esposto dal GPA con l’aggiornamento, attraverso il metodo di aggiornamento massivo di dati GetListaTicket esposto dal S.I. dell’ASR.
Tag valorizzati dal metodo nella response:
• UUID (36 char)
• CODICE_VERSAMENTO (4 char)
• AUXDIGIT (1 char)
• APPLICATION_CODE (2 char)
• LISTA_IUV
o IUV: elenco degli IUV modello 3 che compongono il lotto richiesto come da specifiche AgID (nel modello 3 come da specifiche AgID 17 char);
• ERRORE, vedi sotto.
La tabella sottostante contiene i possibili valori del codice di ERRORE atteso.
CODICE | DESCRIZIONE |
000 | Ok |
032 | Lotto non disponibile |
502 | ASR non gestita |
999 | Errore per fault |
Esempio di messaggio di risposta in [A15].
2.13.2.4 Gestione del soap fault
Se si verifica un errore all’’interno all’applicazione, il GPA pagoPA restituisce la descrizione breve dell’errore all’interno del campo soap fault [A15].
2.13.2.5 Gestione altre features
N.a.
2.13.3 Operazione: GetSingleIUVGPA
Il servizio è di lettura e scrittura dati. I dati risiedono sul GPA, l’ASR invoca il metodo per richiede al GPA pagoPA un singolo di IUV modello 3 da utilizzare per l’emissione dell’avviso di pagamento pagoPA. Al termine della chiamata il GPA pagoPA registrerà a quale pratica è stato assegnato lo IUV.
☞ | Con questo metodo il GPA pagoPA restituisce al S.I. dell’ASR solo IUV modello 3. |
2.13.3.1 Descrizione dell’operazione
Il S.I. dell’ASR invoca il servizio GetSingleIUVGPA specificando l’identificativo della pratica. Il GPA estrae lo IUV e lo restituisce al S.I. dell’ASR.
Il GPA pagoPA restituisce lo IUV allo scopo di emettere l’avviso di pagamento. Nella configurazione del GPA pagoPA è contenuto il codice pagamento associato al motivo pagamento (es. 1100 per S, etc.). | |
☞ | Al termine della chiamata, sul GPA pagoPA e sul GPR, sarà registrata la pratica a cui lo IUV viene assegnato La chiamata al metodo è sincrona. |
Il GPA pagoPA prevede la gestione di un time-out entro cui deve pervenire la risposta dal metodo. In caso si utilizzi questo servizio per approvvigionarsi di IUV, poiché sul GPA l’aggancio tra lo IUV e la pratica è automatico, non bisogna richiamare il servizio SetAssociazioneIUVTicketGPA. |
2.13.3.2 Interfaccia di richiamo (input)
valorizzazione da parte del S.I. dell’ASR della Richiesta un lotto di IUV.
• UUID, Universally Unique IDentifier (36 char, obbligatorio non vuoto) valorizzato dal S.I. dell’ASR
• AZIONE = I (stringa fissa, obbligatorio non vuoto)
• NUMERO_SPORTELLO, inserire il codice del servizio che invoca la richiesta: 64 char, es. “ASR 301”, “CUP”, “LIS”, “SOVRACUP”, …, obbligatorio non vuoto)
• CODICE_ASR, valorizzato con il codice ASR (3 char, obbligatorio non vuoto)
• CODICE_FISCALE, codice fiscale del paziente a cui è intestata la pratica da pagare. Può essere valorizzato con 16 caratteri alfanumerici nel caso di persone fisiche (codice fiscale o STP o ENI) e con 11 cifre nel caso di persone giuridiche (partita IVA). (obbligatorio)
• NUMERO_PRATICA (27 char, obbligatorio). La valorizzazione del tag è obbligatoria e deve essere valorizzata con l’identificativo della Pratica con la numerazione regionale (ottenuto con la concatenazione di: MOTIVO_PAGAMENTO, ASR, CODICE_SERVIZIO, numero pratica dipartimentale (a 16 caratteri), importo della pratica9. Es. S30101000020160039177601590).
• CODICE_VERSAMENTO, valorizzare con il codice versamento per cui viene richiesto lo IUV (4 char,
9 Se l’importo da pagare è < di 1000,00 € valorizzare la stringa concatenando la parte intera con la parte decimale dell’imporot (es.
36,70 -> 03670). Se l’importo è superiore o uguale a 1000,00€ valorizzare con la stringa 00000
obbligatorio non vuoto)
• MODELLO_PAGAMENTO, valorizzato con la costante 3 (char, obbligatorio non vuoto)
Si rammenta di ignorare i tag previsti dal WSDL del GPA ma non specificati nella request. Esempio di richiesta in [A16]
2.13.3.3 Interfaccia di output
Il GPA estrae dalla propria base dati uno IUV modello 3 e lo restituisce al S.I. dell’ASR. Questo IUV sarà assegnato alla pratica passata in input (NUMERO_PRATICA).
Tag valorizzati dal metodo nella response:
• UUID (36 char)
• CODICE_FISCALE (16 char se persona fisica, 11 char se persona giuridica)
• MOTIVO_PAGAMENTO (1 char)
• CODICE_SERVIZIO (2 char)
• NUMERO_PRATICA (16 char)
• CODICE_VERSAMENTO (4 char)
• AUXDIGIT (1 char)
• APPLICATION_CODE (2 char)
• IUV (modello 3 come da specifiche AgID 17 char)
• ERRORE, vedi sotto.
La tabella sottostante contiene i possibili valori del codice di ERRORE atteso.
CODICE | DESCRIZIONE |
000 | Ok |
032 | IUV non disponibile |
502 | ASR non gestita |
999 | Errore per fault |
Esempio di richiesta in [A16]
2.13.3.4 Gestione del soap fault
Se si verifica un errore all’’interno all’applicazione, il GPA pagoPA restituisce la descrizione breve dell’errore all’interno del campo soap fault [A16].
2.13.3.5 Gestione altre features
N.a.
2.13.4 Operazione: SetAssociazioneIUVTicketGPA
Il servizio è di scrittura dati. I dati sono scritti nella base dati del GPA pagoPA, il servizio registra l’assegnazione di uno IUV modello 3 ad una posizione debitoria.
2.13.4.1 Descrizione dell’operazione
Il GPA pagoPA ha ruolo servente rispetto al Sistema Informativo Aziendale. Il servizio
SetAssociazioneIUVTicketGPA esposto dal GPA pagoPA registra nella base dati del GPA a quale posizione debitoria è stato assegnato uno IUV modello 3. Con la SetAssociazioneIUVTicketGPA il Sistema Informativo dell’Asr specifica tutti i dati relativi alla posizione debitoria e allo IUV modello 3. Il GPA utilizzerà questa informazione quando il cittadino cercherà di pagare la posizione debitoria con AgID modello 3, cercando la posizione debitoria sul dipartimentale dove è stata registrata la posizione debitoria.
Uno IUV modello 3 può essere associato ad una sola posizione debitoria. | |
☞ | SetAssociazioneIUVTicketGPA restituisce un errore se lo IUV modello 3 risulta già associato ad un'altra posizione debitoria, o se viene richiamato più volte con lo stesso IUV. |
La chiamata al metodo è sincrona. Questo servizio deve necessariamente essere richiamato in caso lo IUV sia stato fornito all’ASR mediante una chiamata al servizio GetMultiIUVGPA. |
2.13.4.2 Interfaccia di richiamo (input)
Valorizzazione richiesta di pagamento
• UUID, valorizzato da Sistema Informativo Aziendale identifica univoco della chiamata.
• AZIONE = SA
• CODICE_SERVIZIO, valorizzare con la codifica del servizio. Il codice è di due caratteri ed è concordato a livello regionale.
• CODICE_ASR = valorizzare con il codice regionale dell’azienda sanitaria beneficiaria dell’importo ticket (301, 203, …)
• NUMERO_SPORTELLO = Sportello da cui viene richiesta l’assegnazione (es. CUP)
• NUMERO_PRATICA = identificativo regionale della posizione debitoria (es. R20495000000000000102103125)
• CODICE_FISCALE, valorizzare con 16 caratteri alfanumerici se persona fisica (codice fiscale o STP o ENI), con 11 cifre nel caso di persona giuridica (partita IVA)
• MOTIVO_PAGAMENTO, valorizzare con la tipologia del pagamento, con “S” se si tratta di pagamento per prestazione SSN oppure “L” se si tratta di pagamenti di fatture in libera professione. Ulteriori altre codifiche saranno comunicate quando saranno gestiti altri tipi di pagamenti.
• CODICE_VERSAMENTO, composto da quattro caratteri. Il codice versamento è stabilito dall’ASR e usato per generare lo IUV nel pagamento pagoPA.
• MODELLO_PAGAMENTO, valorizzare con il valore 3, perché l’Asr può registrare l’assegnazione di IUV modello 3.
• AUXDIGIT, valorizzare con il valore 3
• APPLICATION_CODE, non valorizzare
• IUV, valorizzare con lo IUV assegnato alla posizione debitoria. Lo IUV è nel formato Standard ISO 11649:2009 (stringa alfanumerica di lunghezza massima di 17 caratteri)
Esempio richiesta di registrazione della scelta dell’assistito a rendere disponibili i dati relativi alle spese sanitarie per la dichiarazione dei redditi precompilata [A17].
2.13.4.3 Interfaccia di output
Dopo aver registrato l’assegnazione della posizione debitoria allo IUV modello 3 il GPA può rispondere con un messaggio riportato negli esempi di [A17].
La tabella sottostante contiene i possibili valori del codice di ERRORE atteso.
CODICE | DESCRIZIONE |
000 | Ok |
999 | Errore per fault |
2.13.4.4 Gestione del soap fault
Se vi è un messaggio di errore, il tag ERRORE è valorizzato con “999”.
2.13.4.5 Gestione altre features
N.A.
3.1 Codifica errori gestiti.
I pazienti con pratiche di pagamento per cui l’importo è pari a zero e i pazienti esenti da Pratica non riceveranno il foglio con la richiesta di pagamento.
3.2 Importi e separatore decimali
Gli importi saranno sempre a 2 cifre decimali anche qualora presentassero valore 0. Il separatore dei decimali DEVE essere il punto (.)
Es.
• 125.45
• 9000.23
• 16.00
3.3 Numero Ricevuta / Quietanza
Il numero ricevuta è una stringa alfanumerica lunga al massimo di 20 caratteri.
3.4 Campi Anagrafica Paziente
L’anagrafica del paziente deve essere valorizzata con i dati certificati e riscontrabili in AURA. Nella parte riguardante l’anagrafica dei dati del paziente, i tag:
• COMUNE si intende la descrizione del comune (per esempio “CHIERI”)
• PROVINCIA si intende la sigla su 2 caratteri della provincia (per esempio “TO”)
3.5 Campo Note Appuntamento e Descrizione Prestazione
A causa della formattazione particolare che possono assumere i campi:
• NOTA_APPUNTAMENTO della prestazione
• DESCRIZIONE della prestazione Occorre
• Racchiudere fra tag CDATA i valori in essi contenuti
• Fare una replace dei caratteri Carriage Return e Line Feed (caratteri ASCII 10 e 13) con il corrispettivo valore in formato XML per non trarre in errore i sistemi che andranno a interpretare il file XML che il sistema
S.I. dell’ASR invia.
o &#13;&#10
o &#10
Per esempio:
<NOTE_APPUNTAMENTO><![CDATA[Xxxxxxx:
- TUTTA la documentazione cardiologica, fosse anche solo un ECG vecchio
- l'elenco dei farmaci assunti
- eventuali ecocardiogrammi eseguiti in precedenza]]></NOTE_APPUNTAMENTO>
3.6 Gestione di elenchi corposi di prestazioni (es. Laboratorio Analisi)
Nel caso di prestazioni per esami di laboratorio, dal momento che la lista prestazioni potrebbe essere lunga e non fornire in questa fase un valore aggiunto di informazioni, si richiede di accorpare le prestazioni per esami di laboratorio sotto un'unica prestazione.
3.7 Gestione pratiche annullate
Per pratiche di pagamento annullate si intende:
• quelle pratiche per cui totalità delle prestazioni non devono più essere erogate (es. disdetta delle prenotazioni).
• pratiche hanno subito una variazione nella composizione delle prestazioni e/o dell’importo pratica e quindi hanno dato vita ad un’altra richiesta di pagamento.
3.8 Gestione pratiche rimborsate e da rimborsare
Per pratiche rimborsate o da rimborsare, si intendono pratiche che non devono essere ulteriormente pagate e per cui il paziente ha ottenuto o deve ottenere la restituzione del denaro.
Relativamente alle pratiche da rimborsare le ASR possono trasmettere al GPA: l’importo da rimborsare (IMPORTO_DA_RIMBORSARE), l’importo già rimborsato (IMPORTO_RIMBORSATO) e la modalità tramite cui erogare il rimborso (MODALITA_RIMBORSO), mentre relativamente alle pratiche già rimborsate, oltre alle informazioni di cui sopra, le ASR possono trasmettere al GPA tutte le informazioni previste nel tag LISTA_RIMBORSI descritto nella response del servizio GetListaTicket, comprensive del pdf con la ricevuta del rimborso erogato ed il pdf dell’eventuale voucher, se è stata scelta questa modalità di rimborso.
La ricevuta ed il voucher saranno resi disponibili al paziente nell’applicativo Estratto conto, una volta autenticato [A19].
3.9 Gestione della variazione di importo e rimborsi
La variazione dell’importo di una pratica deve essere gestita nel seguente modo:
• annullamento di una pratica: trasmissione dell’aggiornamento a GPA pagoPA (stato 800)
• trasformazione di una pratica pagata in pratica da rimborsare: trasmissione aggiornamento a GPA pagoPA (stato 802)
• trasformazione di una pratica da rimborsare in pratica rimborsata: trasmissione aggiornamento a GPA pagoPA (stato 801)
3.10 Definizione delle modalità di erogazione rimborso
Ciascuna ASR può definire in autonomia le modalità di erogazione del rimborso ammissibili definendo sul GPA di riferimento la modalità di erogazione ammessa (voucher, bonifico x xxxxxxxxxx) per ciascuna combinazione di codice servizio (sistema dipartimentale), codice versamento e motivo pagamento.
L’ASR ha inoltre facoltà di stabilire per quanti anni il credito del borsellino debba essere considerato fruibile, nonché l’importo minimo al di sotto del quale non è possibile fruire della modalità bonifico.
NB: Se l’ASR ammette, per una specifica combinazione, la modalità “borsellino” è necessario che preveda, per la stessa combinazione, anche la modalità “voucher”; questo per consentire al sistema di convertire in voucher il credito presente nel borsellino una volta giunto a scadenza.
3.11 Definizione operatori a cui notificare le avvenute erogazioni dei rimborsi
Ciascuna ASR può definire quali siano gli operatori sanitari (nome, cognome, indirizzo ed email) deputati a ricevere una notifica via mail ogni qualvolta un utente scelga di fruire di un rimborso erogato dall’azienda tramite voucher o tramite bonifico.
3.12 Popolamento del tag TIPOSPESA ed inibizione dell’invio del ticket al SistemaTS
Il tag TIPOSPESA può assumere uno dei valori previsti elencati nell’allegato [A06]
Ciascuna ASR può definire in autonomia un valore speciale da utilizzare per impedire che uno specifico pagamento
sia inviato al SistemaTS. Una volta definito il valore come parametro di configurazione (se non specificato vale “99”) l’azienda dovrà utilizzarlo per avvalorare il tag TIPOSPESA nelle response dei ws GetImportoTicket, GetListaTicket, SetAvvenutoPagamento e SetOpposizionePrecompilazione730 relative a ciascuno pagamento che non vuole sia inviato al SistemaTS. Un esempio di pagamenti che è possibile non inviare al SistemaTS è quello dei pagamenti associati a persone giuridiche.
3.13 Popolamento del tag PERCENTUALE_IVA
AVVISO IMPORTANTE PRIMA DI IMPLEMENTARE LA MODIFICA
È in corso l’aggiornamento del GPA per quanto riguarda l’integrazione con SOGEI per la trasmissione dei pagamenti sanitari al fine del calcolo del 730. Tale aggiornamento non si è ancora concluso. Per cui prima di procedere con lo sviluppo delle modifiche introdotte nella versione V17 contattare il CSI per concordare le date di avvio dei test di integrazione.
Se la pratica è soggetta al pagamento dell’IVA il tag PERCENTUALE_IVA va valorizzato con l’aliquota IVA in percentuale da applicare (formato numerico es. 0 per indicare lo 0%, 4 per indicare il 4%, etc.), in caso contrario va valorizzato con la natura IVA.
La natura IVA è di max 2 caratteri ed assume valori da N1 a N6 per documenti di tipo commerciale (tipoDocumento
= D) es. scontrini e ricevuta, mentre è di max 4 caratteri ed assume valori da N1 a N7 o sottovalori per documenti di tipo fattura (tipoDocumento = F).
Le prestazioni sanitarie rese alla persona risultano esenti ai sensi dell’articolo 10 del DPR n. 633 del 1972, per cui se il soggetto che eroga tale tipo di prestazione è in regime ordinario e rilascia una fattura, nel trasmetterla al sistema TS dovrà riportare nel campo naturaIVA il codice “N4”. Se si tratta di un soggetto a regime forfetario, non essendo tenuto agli adempimenti riferiti all’IVA, nella trasmissione dei dati al Sistema TS deve riportare invece il codice “N2.2” in caso di fattura o il codice “N2” in caso di documento commerciale.
NB: Solo alcuni servizi (GetListaTicket, SetAvvenutoPagamento e SetOpposizionePrecompilazione730) utilizzeranno la nuova semantica; gli altri conserveranno quella precedente restituendo quindi solo la percentuale di aliquota IVA quando applicabile.