progetto SysPrest v.4 DOCUMENTAZIONE TECNICA · 2019-09-26 · • Operazioni pianificate (processi...

DOCUMENTAZIONE TECNICA _________________________________________________________________________________________________

_________________________________________________________________________________________________ CSIO Società di informatica e organizzazione s.r.l. pagina 1 di 276

progetto

SysPrest v.4

DOCUMENTAZIONE TECNICA



SOMMARIO ARCHITETTURA DEL SISTEMA .............................................................................................................................................................. 7

Ambiente Produzione 8 DBSQLCAP1 – server DB SQL Server di produzione (ip 172.16.100.240) ............................................................................... 8 SQLCLUST1 – web server interno produzione (ip 200.1.1.20) .................................................................................................. 8 SRVREPCUP - server report ed elaborazioni di produzione (172.16.100.15) .......................................................................... 9 VINTEGRA.usl11.net - application server integrazioni di produzione (200.1.1.117).................................................................. 9 SERVER UC-EM-CUPEXT – web server sito SysPrest pubblico su Internet ........................................................................... 10 NSERVIZI (linux)– web CUP ON-LINE pubblico su Internet ................................................................................................... 11

Ambiente Test 11 UC-EM-CUPDBSQL - server DB SQL Server di test (ip 172.16.100.241) .............................................................................. 11 UC-EM-CUPINT-TE – web server LAN test (ip 172.16.100.159) ............................................................................................. 11 PPCUP – application server integrazioni di TEST (ip 172.16.100.56)...................................................................................... 12

Disattivare intero sistema 13 Organizzazione del sistema 14

ARCHITETTURA DEL SISTEMA DI ELABORAZIONI ............................................................................................................................ 15 Organizzazione del sistema automatico di elaborazioni applicative 15

ELENCO FUNZIONI ................................................................................................................................................................................ 16 Come riattivare un utente scaduto 16 Assistito selezionato 16 Erogazione 16 Valorizzazione delle tariffe secondo il listino di riferimento 17 Tariffe per prestazioni appartenenti ad un pacchetto 18 Ricevute 19

Ricevuta Bonum “mancata prenotazione” ............................................................................................................................... 19 Ricevuta di cassa.................................................................................................................................................................... 19 Ricevuta Promemoria per il pagamento .................................................................................................................................. 22 Ricevuta di prenotazione ........................................................................................................................................................ 23 Ricevuta prenotazioni di un contatto ....................................................................................................................................... 25 Ricevuta di prenotazione su prenotazioni effettuati sul Cup Area Vasta .................................................................................. 25 Fattura .................................................................................................................................................................................... 26

Diario Rpt Automatici (REPORT – LISTE) 27 Contabilizza 27

Esenzioni assistiti per contabilizzazione automatica (funzionalità sospesa) ............................................................................ 27 Contabilizza - Flussi SPA ........................................................................................................................................................ 27 Contabilizzazione automatica di documenti (funzionalità SOSPESA) ..................................................................................... 27

Accettazione – Elimina code 29 Lista Prenotati HTML 30 Prenotazione – multipla “un posto prestazione” 31 Prenotazione – memorizzazione prima disponibilità 33 Calendario prenotazione 34

Esempio del sistema di calcolo delle disponibilità ................................................................................................................... 34 Esempio del sistema di calcolo del calendario Sintesi (utilizzato per la prenotazione per codice di priorità) ............................ 36 Rigenerazione del calendario “MAX BUCHI LIBERI” (utilizzato per la prenotazione su agende “un posto prestazione”) ......... 41 Generazione notturna dei calendari delle agende per codice di priorita’ ................................................................................. 43

Fusione manuale assistiti 43 Ricerca attività assistito nei database Storici 44 Filtri USL-Regione di residenza assistiti applicati in fase di prenotazione 45

PROCESSI SQL...................................................................................................................................................................................... 46 SysPrest 01 - Mail attività processi - 46 SysPrest 02 - Notifica disponibilità agende non colore - 47 SysPrest 04 - Preparazione dati OLAP Offerta disponibilità - 47 SysPrest 05 - Prepara prenotazioni CUP Online - 48 SysPrest 06 - Erogazione automatica prestazioni ALP/Area Pagamento - 48 SysPrest 07 - Preparazione dati OLAP Attività - 49 SysPrest 08 - Schedulazione elaborazione Flussi SPA (SOSPESO)- 49 SysPrest 09 - Storicizzazione log: prenotazioni, integrazione, ricettario, Iris 51 SysPrest 10 - Notifica disponibilità agende colore - 52 SysPrest 11 - Notifica agende senza disponibilità - 53 SysPrest 12 - Schedulazione report TAT - 53 SysPrest 13 - Autocontabilizza (sospeso) - (SOSPESO) 53 SysPrest 14 - Notifica prenotazione spostate - 54 SysPrest 15 - Calendario - Pulizia Tab - Storicizzazione log anagrafe 54 SysPrest 16 - Log allineamento anagrafe CRM – esenzioni assistito 56



SysPrest 17 - CUP AV Workslot - 56 SysPrest 21 – Schedulatore Integrazione Anagrafica 56 SysPrest 22 - Notifica assistiti con lo stesso codice aziendale ed errori 56 SysPrest 23 - Notifica prenotazioni registrate non corretamente – Ricevute di cassa Doppie 56 SysPrest 24 - Schedulatore Integrazione Erogato 56 SysPrest 25 - Disattivazione utenti non collegati al sistema da x giorni 56 SysPrest 26 - Integrazione - Erogato con errore 57 SysPrest 27 – Integrazione medici 57 SysPrest 28 - Preparazione dati OLAP pubblicazione prestazioni 58 SysPrest 29 - Integrazione - Inizializza coda prenotazione 58 SysPrest 30 - Notifica prestazioni senza disponibilita 58 SysPrest 31 - Integrazione anagrafe comuni - ASL – stati - Esenzioni 58 SysPrest 32 - Integrazione anagrafe - Rischedulazione 59 SysPrest 33 – Notifica controllo offerta 60 SysPrest 34 – IRIS Pendenze rinvio per variazione anagrafica 61 SysPrest 35 - IRIS Schedulatore Integrazione notifiche pagamenti 61 SysPrest 36 - Integrazione verifica automatica MSG con errore 62

ELABORAZIONI ..................................................................................................................................................................................... 64 Estrazione File stipendi (cod. elaborazione stipen) 64 Creazione file stipendi - NUOVA Elaborazione (cod. elaborazione stipV4) 65

Premessa ............................................................................................................................................................................... 65 Contabilizza ............................................................................................................................................................................ 65 Erogazione ............................................................................................................................................................................. 65 Cassa ..................................................................................................................................................................................... 65 Elaborazione ........................................................................................................................................................................... 66

Importazione listino SSN 68 Estrazione Flusso TAT (tracciato dal 2019) 69 FLUSSI SPA - FED 71 Annullamento elaborazione FLUSSI SPA 88 Ricettari 88 Recupero ricettari (SOSPESA) 89 Estrazione 730 - precompilato 90

PROCEDURE MANUTENZIONE E BACKUP SERVER DBSQLCAP1 ................................................................................................... 93 PROCESSI SCHEDULATI ...................................................................................................................................................................... 96 SERVER INVIO EMAIL ......................................................................................................................................................................... 101 COLLEGAMENTO SYSPREST – CRM ................................................................................................................................................ 102

Premessa ..............................................................................................................................................................................102 Come generare i file dll utili per richiamare il web service ......................................................................................................102 Apertura in contensto di SysPrest ..........................................................................................................................................103 Funzione di “prenotazione“ ....................................................................................................................................................105 Funzione di “cancellazione prenotazione“ ..............................................................................................................................105 Il flusso di una prenotazione ..................................................................................................................................................106 Schedulatore CRM (NON attivo) ...........................................................................................................................................107 ..............................................................................................................................................................................................107 Elaborazione notturna per l’allineamento anagrafe CRM .......................................................................................................108 Definizione delle entità del database ......................................................................................................................................111

INTEGRAZIONE CUP AREA VASTA ................................................................................................................................................... 114 Premessa ..............................................................................................................................................................................114 Standard adottato ..................................................................................................................................................................116 Integrazione tra CUP1L e CUP2L (Lato Server) .....................................................................................................................117

CUP.getDriverInfo .......................................................................................................................................................... 117 CUP.findService ............................................................................................................................................................ 118 CUP.findStructure .......................................................................................................................................................... 120 CUP.findWorkingUnit ..................................................................................................................................................... 121 CUP.getModifiedDiares.................................................................................................................................................. 122 CUP.getModifiedWorkSlots ............................................................................................................................................ 130 CUP.getAppointments ................................................................................................................................................... 132 CUP.getBookingInfo ...................................................................................................................................................... 135 CUP.findBooking ........................................................................................................................................................... 140 CUP.book ...................................................................................................................................................................... 141 CUP.revoke ................................................................................................................................................................... 145 CUP.Move (non attivo) ................................................................................................................................................... 146

Integrazione tra CUP2L e CUP1L (Lato Client) ......................................................................................................................148 CUPMET.getAvilabilities ................................................................................................................................................ 148 CUPMET.getAppointments ............................................................................................................................................ 150 CUPMET.book ............................................................................................................................................................... 151 CUPMET.revoke ............................................................................................................................................................ 152 CUPMET.move .............................................................................................................................................................. 152 CUPMET.getBookingInfo ............................................................................................................................................... 153 CUPMET.findBooking .................................................................................................................................................... 154



CUPMET.findStructure................................................................................................................................................... 154 CUPMET.findWorkingUnit .............................................................................................................................................. 155 CUPMET.findVirtualService ........................................................................................................................................... 155

Elaborazioni notturne .............................................................................................................................................................156 Elaborazione Structure................................................................................................................................................... 156 Elaborazione WorkingUnit .............................................................................................................................................. 157 Elaborazione findVirtualService ..................................................................................................................................... 157 Elaborazione WORKSLOT ............................................................................................................................................. 159 Flusso chiamata metodi – lato cliente ............................................................................................................................ 159 LATO CLIENT ................................................................................................................................................................ 162 LATO SERVER .............................................................................................................................................................. 164 APPENDICE 1 – CLASSE LOG (LATO CLIENT) ........................................................................................................... 165 APPENDICE 2 – MODIFICHE COOKCOMPUTING.XMLRPC (CLASSE UTIL.CS) ....................................................... 167 APPENDICE 3 – CLASSE LOGG (LATO SERVER - COOKCOMPUTING.XMLRPC) .................................................... 168 APPENDICE 4 – MODIFICHE COOKCOMPUTING.XMLRPC CLASSE XMLRPChttpSERVERPROTOCOL.CS ........... 169

Note installazione integrazione ..............................................................................................................................................170 Installazione della parte server ....................................................................................................................................... 170 Installazione della parte client ........................................................................................................................................ 172

INTEGRAZIONE ECOMEDICA ............................................................................................................................................................ 173 Premessa ..............................................................................................................................................................................173 Comunicazione all’Ecomedica delle prenotazioni SysPrest ....................................................................................................173 Utente SQL per Ecomedica ...................................................................................................................................................175 Elaborazione d’importazione attività Ecomedica ....................................................................................................................176 Disegno del database ............................................................................................................................................................185

INTEGRAZIONE IDM ........................................................................................................................................................................... 187 Premessa ..............................................................................................................................................................................187 Storede Procedure IDM_005_UTENTE_INS ..........................................................................................................................188 Storede Procedure IDM_006_UTENTE_UPD ........................................................................................................................189 Storede Procedure IDM_007_DISATTIVA .............................................................................................................................190 Storede Procedure IDM_008_ATTIVA ...................................................................................................................................190

INTEGRAZIONE PRENOTATO/CONTABILIZZATO/CASSA - EROGATO......................................................................................... 192 Comunicazione delle Richieste SysPrest al DISPATCHER 192

Web Services Richieste .........................................................................................................................................................194 Servizio di Windows “CSIO SysPrest Dispatcher Richiesta” ...................................................................................................197 Inizializzazione delle code .....................................................................................................................................................204

DISPATCHER invia prestazioni erogate a SysPrest 205 Flusso integrazione ................................................................................................................................................................205 Web services Erogato ............................................................................................................................................................205 Servizio di Windows “CSIO SysPrest Erogato” ......................................................................................................................208 Processo di elaborazione del messaggio ricevuto ..................................................................................................................213

INTEGRAZIONE RICETTARI ............................................................................................................................................................... 220 Comunicazione di movimenti effettuati sui ricettari SysPrest al DISPATCHER 220

Web Services Ricettario .........................................................................................................................................................221 Servizio di Windows “CSIO SysPrest Dispatcher Ricettario” ..................................................................................................222

APERTURA IN CONTESTO DI SYSPREST ......................................................................................................................................... 226 Caricamento farmaci di una prenotazione 226 Apertura diretta di una interfaccia di prenotazione su un determinato assistito 227

INTEGRAZIONE ANAGRAFE ............................................................................................................................................................. 229 Comunicazione delle variazioni anagrafiche SysPrest al DISPATCHER 230

Web Services Peolple.Save ...................................................................................................................................................230 Servizio di Windows “CSIO Anagrafe Client” ..........................................................................................................................236

DISPACER invia variazioni anagrafiche a SysPrest 237 Web services Anagrafeserver ................................................................................................................................................237 Processo di elaborazione del messaggio ricevuto processo SQL “SysPrest 21 - Schedulatore Integrazione Anagrafe” .........240

INTEGRAZIONE IRIS............................................................................................................................................................................ 241 Premessa 241 Pendenze: contabilizzazioni/cassa effettuate su SysPrest 241

Tabella IRIS_Pendenze_001_Documento .............................................................................................................................244 Tabelle IRIS_Pendenze_002_Documento_DettaglioImporto ..................................................................................................248 Tabella IRIS_Pendenze_003_Prestazioni ..............................................................................................................................249 Tabella IRIS_Pendenze_006_Anag_TipoOperazione ............................................................................................................250 Tabella IRIS_Pendenze_009_Ricevuta ..................................................................................................................................250 Tabella IRIS_Pendenze_010_Ricevuta_ImportoVoci .............................................................................................................250 Rinvio pendenze per cambio codice fiscale dell’assistito ........................................................................................................251 Storicizzazione messaggi ......................................................................................................................................................252 Relazioni tabelle ....................................................................................................................................................................252

Ricezione del pagamento effettuato su IRIS 253 Tabella IRIS_Pagamento_001_notifica ..................................................................................................................................253 Tabella IRIS_Pagamento_002_notifica_DettImportoTransato ................................................................................................256 Storicizzazione messaggi ......................................................................................................................................................256 Relazioni tabelle ....................................................................................................................................................................256

Tabella di ambiente 256



BUS 257 INTEGRAZIONE CONTICKI ................................................................................................................................................................. 258

Prescrizione 258 Prenotazione 260 Erogato 261 Sistema di monitoraggio dell’integrazione 262 INVIO 263

Rinvio messaggi ....................................................................................................................................................................265 RICEZIONE 268 Processi SQL utilizzati dall’integrazione 270 Ricette NRE gestite sul modulo ricetta rossa 271 Tabelle 272



ARCHITETTURA DEL SISTEMA

SysPrest raccorda, in un sistema “concettualmente unitario”, la complessa e molteplice variabilità di situazioni in cui le prestazioni sanitarie sono memorizzate ed elaborate all’interno di una struttura sanitaria, e lo fa mediante componenti software interconnesse in rete e concepite per consentire l’accesso al sistema ad innumerevoli e differenti utenti. SysPrest automatizza il processo di prenotazione e consuntivazione di tutte le prestazioni sanitarie erogate, e precisamente:

SysPrest si basa esclusivamente sulla tecnologia WEB e richiede:

• Windows 2000 Server

• Internet Information Service

• Microsoft SQL Server

SysPrest si basa fondamentalmente su tre elementi (rappresentati con tre server) e precisamente:

• Server di database: Windows 2000 server MS SQL server 2000

• Server web: Windows 2000 server Internet Information Service

• Server di elaborazioni e report Windows 2000 server MS ACCESS 2000/XP

I - MAC

INTERNET

WEB SERVER SERVER DI AUTENTICAZIONE

SERVER TCP

DATABASE SERVER

SERVER COMPONENTI

COM +

Collegamento "Anagrafe" Collegamento "Ricoveri" Struttura Agende - Calendario Utenti Documenti - Impegnative Prenotazioni Prestazioni Tempi di Attesa Collegamento con dipartimentali Log

Sito WEB Pagine ASP

Pagine HTML

Componenti specializzati secondo il modello n-tier. . . Sistema di reporting

Modulo di interfaccia per il

collegamento on le procedure

dipartimentali

PC WINDOWS

I-MAC PC WINDOWS

Hub

FIREWALL

ETHERNET Esterna

Router



Ambiente Produzione

DBSQLCAP1 – server DB SQL Server di produzione (ip 172.16.100.240)

Il server deve essere abilitato per l’invio delle email (Servizio SMTP di Windows)

PRODUZIONE - Data base:

• ANAGRAFEASL

• SysPrestV3_EMPOLI

• SysPrestV3_EMPOLI_CRM (utilizzato dall’integrazione con il CRM)

• SysPrestV3_Empoli_INTEGRAZIONI (utilizzato per integrazione Richieste - Erogato/contabilizzato)

• SysPrestV3_Empoli_DW : contiene le tabelle (e le relative elaborazioni di alimentazione) per il cubo aziendale

• Processi SQL (elencati nel paragrafo “Processi SQL SERVER - SERVER SQL ip 172.16.100.240”)

SQL Server agent - jobs:

• Processi SQL (con il prefisso “SysPrest ….”) . Elencati nel paragrafo “Processi SQL SERVER”

SQLCLUST1 – web server interno produzione (ip 200.1.1.20)

• Web SysPrest (con integrazione CUP AREA VASTA - CRM)

• Componenti installati: o Codici Colori_v2 (Componente utile per la generazione dei calendari) o cs_fileSystemBase (Componente utile per navigazione file system)

• Il server deve poter chiamare i componeti CUP AREA VASTA (vedere paragrafo integrazione Cup Area Vasta)

• Il server deve poter chiamare i componeti CRM (vedere paragrafo integrazione call center)

• Operazioni pianificate (processi elencati nel paragrafo “Operazioni pianificate - Server WEB ip 200.1.1.20”)

• file di conessione di sistema SysPrestV3EmpoliConnect_DLL.dsn (utilizzata da DLL di generazione del calendario

Colori_v2)

Organizzazione directory:

Root\componenti\

- Dll

- dll_CRM

- Schedulatore_findStructure

- Schedulatore_findVirtualService

- Schedulatore_findWorkingUnit

- SchedulatoreCRM

- Source

Root\Elaborazioni

- CRM

Le connessioni normalmente sono memorizzate nella cartella “C:\Programmi\File comuni\ODBC\Data Sources”:

o SysPrestV3EmpoliConnect.dsn -- file DSN utilizzato dal web

o SysPrestV3EmpoliConnect_mdb.dsn -- file DSN utilizzato dalla reportistica

o SysPrestV3Empoli_Storico_Connect.dsn -- file DSN utilizzato dal web per collegarsi al database di storico dei dati

o SysPrestV3Empoli_CRMConnect.dsn --- file DSN utilizzato dal web per collegarsi al database SysPrestV3_Empoli_CRM (per integrazione con il CRM)



o SysPrestV3EmpoliConnect_mdb_INTEGRAZIONE.dsn -- file DSN utilizzato dal web per collegarsi al database SysPrestV3_Empoli_INTEGRAZIONI

SRVREPCUP - server report ed elaborazioni di produzione (172.16.100.15)

• Schedulatore report

• Schedulatore elaborazione

• Operazioni pianificate (processi elencati nel paragrafo “Operazioni pianificate - Server report/elaborazioni ip 172.16.100.15”)

• Ci deve essere l’unità di rete H (collegata al server 200.1.1.20 sulla cartella contivisa csioweb -- L:\csioweb ) dove viene creato il report sul server web LAN di produzione. L’accesso all’unità di rete con l’utente CUPDM01\csio

• Ci deve essere l’unita di rete F (collegata al server UC-EM-CUPEXT sulla cartella contivisa SysPrest –

C:\OSLO\SysPrest) dove viene copiato nella uintà il report prodotto per SysPrest Internet. L’accesso all’unità di rete con l’utente UC-EM-CUPEXT \srv_csio

VINTEGRA.usl11.net - application server integrazioni di produzione (200.1.1.117)

• Servizi di Windows per integrazioni – ambiente produzione: o CSIO SysPrest Dispatcher Richiesta o CSIO SysPrest Erogato o CSIO SysPrest Ricettario o CSIO SysPrest Anagrafe client o CSIO SysPrest Anagrafe server

• Servizi di Windows per integrazioni Conticki – ambiente produzione: o CSIO Ricezione RFC98 o CSIO Trasmissione RFC98

• Operazione pianificata “Schedulatore allineamento anagrafe CRM” (operazione che può essere effettuata solo dal CED di Empoli). Operazione pianificata Run con utente “VINTEGRA\srv_integra” (E:\CSIO-Integrazioni\Componenti\CRM\CRM_allineaAnagrafe\crm_allineaAnag.exe)

o Driver Oracle ▪ C:\oracle\ora92\network\ADMIN\ tnsnames.ora

CRM.USL11.NET = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.200.11)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.200.21)(PORT = 1521)) (FAILOVER = ON) (LOAD_BALANCE = yes) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = CRM) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 5) (DELAY = 1) ) ) ) CRM1.USL11.NET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = oraboc3.usl11.net)(PORT = 1523)) (CONNECT_DATA = (SERVICE_NAME = CRM) (INSTANCE_NAME = CRM1) ) ) CRM2.USL11.NET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = oraboc2.usl11.net)(PORT = 1523)) (CONNECT_DATA = (SERVICE_NAME = CRM) (INSTANCE_NAME = CRM2) ) )



o Le connessioni nella cartella “C:\Program Files\Common Files\ODBC\Data Sources”: ▪ SysPrestV3EmpoliConnect.dsn -- file DSN utilizzato per la conessione al db SysPrestV3_Empoli

▪ SysPrestV3Empoli_CRMConnect.dsn -- file DSN utilizzato dal web per collegarsi al database SysPrestV3_Empoli_CRM

▪ Sibel_CRMConnect.dsn – file dsn per collegarsi al db Oracle CRM

[ODBC] DRIVER=Oracle in OraHome92 UID=IMPORTSP PWD=IMPORTSP TLO=O PFC=10 FWC=F CSR=F MDI=Me MTS=F BAM=IfAllSuccessful FRL=Lo GDE=F RST=T LOB=T FDL=10 FRC=10 QTO=T FEN=T XSM=Default EXC=F APA=T DBA=W DBQ=CRM.USL11.NET SERVER=CRM.USL11.NET

SERVER UC-EM-CUPEXT – web server sito SysPrest pubblico su Internet

Nel server è presente il sito di SysPrest a cui accedono le strutture convenzionate/farmacie (accesso da esterno LAN)

• componenti dell'applicativo (web, oggetti COM, ecc) collocati nel percorso cartella C:\OSLO\SysPrest: o ComponentiCOM

▪ RigenerazioneCalendario o Report_Snp (contenete i file dei report SNP prodotti nel server dei report) o InputOputupfile

▪ Ecomedica (file txt importati dalla funzione di elaborazione dati Ecomedica) o Web

• native client provider SQL 2008 r2 (64 bit inglese)

• powershell 4

• configurazione IIS o Application Pool 'SysPrestWebAppPool'

▪ Net framework version = v2.0

▪ 32 BIT

▪ Managed pipeline mode= Classic

▪ process model - identity =ApplicationPoolIdentity o Sito SysPrestWeb con cartella virtuale Report_snp che punta alla cartella dei report prodotti

(C:\OSLO\SysPrest\Report_snp)



o http response HEADERS → X-UA-Compatible= IE=7 (forzatura su Explore7) o abilitazione ASP o abilitazione percorsi principali

• Installazione DLL OSLO per generazione calendari CodiciColori_v2.dll (C:\OSLO\SysPrest\componentiCOM\RigenerazioneCalendario)

• Non e' attivata l'integrazione del CRM (apertura in contesto di SysPrest) o pagina exeLogIn_CRM.asp → rinominata in DISATTIVATA_exeLogIn_CRM_.asp o prova_exeLogIn_CRM.asp → rinominata in DISATTIVATA_prova_exeLogIn_CRM.asp

• Non è attiva la funzione di elaborazione Ecomedica ( non è stato configurata nel sito la cartella virtuale Ecomedica_txt (su cartella C:\OSLO\SysPrest\txt_v3\Ecomedica)

• utente della macchina SRV_OSLO (utilizzato per la condivisione di rete per i report in formato SNP)

NSERVIZI (linux)– web CUP ON-LINE pubblico su Internet

Server web dl CUP ON-Line. Il CUP ON-Line il 18/01/2016 è stato disattivato.

Ambiente Test

UC-EM-CUPDBSQL - server DB SQL Server di test (ip 172.16.100.241)

Il server deve essere abilitato per l’invio delle email (Servizio SMTP di Windows) TEST - Data base:

• TEST_ANAGRAFEASL

• TEST_SysPrestV3_EMPOLI

• TEST_SysPrestV3_EMPOLI_CRM (utilizzato dall’integrazione con il CRM)

• TEST_SysPrestV3_Empoli_INTEGRAZIONI

• TEST_SysPrestV3_Empoli_DW

SQL Server agent - jobs:

• Processi SQL (con il prefisso “TEST - SysPrest ….”)

UC-EM-CUPINT-TE – web server LAN test (ip 172.16.100.159)

• Web Test SysPrest http://uc-em-cupint-te/sysprestweb

• Non e' attivata l'integrazione del CRM (apertura in contesto di SysPrest) o pagina exeLogIn_CRM.asp → rinominata in DISATTIVATA_exeLogIn_CRM_.asp

http://uc-em-cupint-te/sysprestweb



o prova_exeLogIn_CRM.asp → rinominata in DISATTIVATA_prova_exeLogIn_CRM.asp

• Componenti COM installati: Codici Colori_v2

• Schedulatore report Access non presente

PPCUP – application server integrazioni di TEST (ip 172.16.100.56)

• Servizi di Windows per integrazioni – ambiente test: o CSIO SysPrest Dispatcher Richiesta o CSIO SysPrest Erogato o CSIO SysPrest Ricettario o CSIO SysPrest Anagrafe client o CSIO SysPrest Anagrafe server

• Servizi di Windows per integrazioni Conticki – ambiente test: o CSIO Ricezione RFC98 o CSIO Trasmissione RFC98



Disattivare intero sistema

Per disattivare l’utilizzo del sistema e necessario effettuare le seguenti operazioni:

❖ Arestare IIS nei seguenti server o ip 200.1.1.20 (per SysPrest LAN di produzione + CUP AREA VASTA lato client) o UC-EM-CUPEXT (per SysPrest di produzione per strutture convenzionate-medici-farmacie o ip 172.16.123.20 (per CUP ON-LINE - operazione che può essere effettuata solo dal CED di Empoli)

❖ Arrestare schedulatori Access nel server ip 172.16.100.15 (report, elaborazioni)

❖ nel server ip 172.16.100.240

o Sospendere i processi sql (tutti quelli nominati SysPrest)

o Sospensione operazione pianificate dei backup (SysPrest manutenzione giornaliera, SysPrest manutenzione oraria, SysPrest manutenzione settimanale)

❖ Operazioni pianificate di backup

❖ Sospendere le operazioni pianificate nel server 200.1.1.20: generazione calendari, CUP AREA VASTA chiamata componenti di allinemanto FindStructure, FindVirtualService, FindWorkingUnit

❖ Gli utenti che accedo al DB per integrazioni gestite direttamente con accesso alle tabelle (es. IRIS, Ecomedica, IDM, ecc) rimarranno attivi

❖ Dal server vintegra.usl11.net

o arrestare i servizi:

▪ Servizio di Windows “CSIO SysPrest Dispatcher Richiesta” (integrazione)

▪ Servizio di Windows “CSIO SysPrest Erogato” (integrazione)

▪ Servizio di Windows “CSIO SysPrest Ricettario” (integrazione)

▪ Servizio di Windows “CSIO SysPrest Anagrafe client” (integrazione)

▪ Servizio di Windows “CSIO SysPrest Anagrafe server” (integrazione)

▪ Servizio di Windows “CSIO Ricezione RFC98” (integrazione Conticki)

▪ Servizio di Windows “CSIO Trasmissione RFC98” (integrazione Conticki)

o Sospensione operazione pianificata “Schedulatore allineamento anagrafe CRM” (operazione che può essere effettuata solo dal CED di Empoli)



Organizzazione del sistema

Per poter comprendere come è stato implementato il meccanismo di elaborazione occorre conoscere innanzitutto la struttura delle tabelle del database che conservano le informazioni necessarie al corretto funzionamento del sistema. Le tabelle interessate sono:

➢ DocumentiElaborabili: tabella contenente tutti i modelli di report previsti da SysPrest.

➢ DocumentiElaborabiliParametri: tabella contenente il nome dei parametri che ogni singolo report deve utilizzare.

➢ DocumentiCodiciClassificazione: tabella contenente la classificazione dei modelli di report

Le tre tabelle sopra indicate contengono le informazioni necessarie alla richiesta di un nuovo report. Quando un utente richiede un report, innanzitutto individua la classificazione (DocumentiCodiciClassificazione), quindi sceglie il tipo di report (DocumentiElaborabiliParametri), e infine immette i parametri necessari (DocumentiElaborabiliParametri). I sistema memorizza, per lo specifico report dall’utente, i dati nelle seguenti tabelle:

➢ DocumentiLog: tabella contenente il report richiesto, il codice dell’operatore che ha richiesto il report, l’ora della richiesta e lo stato della stessa. Inizialmente il report avrà un codice di stato che indiche che è ancora da elaborare. Quando verrà elaborato, se è stato correttamente prodotto, il report avra stato 9, altrimenti stato 8 (terminata con errori). La tabella dei codii di stato è la seguente

DocumentiCodiciStatus

status descrizione

0 in fase di predisposizione

1 da elaborare

2 in fase di elaborazione

6 report vuoto

7 depositato

8 terminata con errori

9 terminata correttamente

➢ DocumentiLogParametri - DocumentiElaborabiliParametri_Carrello: tabella contenente, per ogni report richiesto i reali parametri richiesti dall’utente (quali ad esempio la data inizio e data fine) coerentemente con il modello di report

* * * Tenendo presente le tabelle precedentemente citate, l’organizzazione del sistema si articola in:

➢ Modelli di report: registrati all’interno delle tabelle DocumentiElaborabili, DocumentiElaborabiliParametri e DocumentiCodiciClassificazione .

➢ Report richiesti dall’utente e non ancora elaborati: tramite le funzioni del sito l’utente richiede uno specifico report e compila i parametri necessari (come dal modello precedente). I report richiesti e non ancora elaborati sono registrati all’interno delle tabelle DocumentiLog e DocumentiLogParametri - DocumentiElaborabiliParametri_Carrello e si riferiscono ai record con StatusId = 1.

➢ Schedulatore di report: il programma root\ Report_pgm\ ReportV3Elab.mdb è sempre attivo ed ha il compito di verificare nella tabella DocumentiLog i report ancora da elaborare e l’ordine di elaborazione degli stessi. Quando si accorge che un report deve essere elaborato, richiama il programma relativo (campo PgmFile) e il metodo (campo PgmMetodo). Il campo metodo si contiene due valori separati da un punto xxxxx.yyyyy dove xxxx rappresenta codice da elaborare all’interno del PgmFile e yyyy il nome del report all’interno del PgmFile.

➢ Report richiesti dall’utente e elaborati: quando il processo elaborativo di cui ai campi PgmFile e PgmMetodo precedentemente indicarti termina l’elaborazione, modifica il valore di StatusId in 9 (terminata correttamente) o 8 (terminata con errori).



ARCHITETTURA DEL SISTEMA DI ELABORAZIONI

I processi elaborativi batch, si effettuano sfruttando il prodotto MS ACCESS 2000 o XP della Microsoft. In questo modo si coniuga l’economicità, semplicità e diffusione di tale prodotto con l’esigenza di poter disporre di elaborazioni batch schedulabili e “pilotate” dal web.

Organizzazione del sistema automatico di elaborazioni applicative

Qualora dovesse essere necessario effettuare delle elaborazioni periodiche che non rientrano nel sistema applicativo di reporting e di elaborazione, SysPrest prevede le seguenti modalità:

a. PROCESSI SQL: esecuzione di storage procedure (o altri comandi SQL). Utilizzo di SQL Agent per l’esecuzione a tempo di tali comandi. NOTE:

➢ effettuare in questo modo il backup periodico del datatabase ➢ effettuare in questo modo la riorganizzazione degli archivi (indici e dati) ➢ effettuare in questo modo l’eliminazione del file di log (vedere backup_log with no_log) e compatta

database (tramite enterprice manager o l’istruzione DBCC SHRINKDATABASE e DBCC SHRINKFILE)

b. OPERAZIONI PIANIFICATE di eseguibili in Visual Basic ➢ email_calendario per la generazione automatica del calendario delle agende e invio delle mail ai

responsabili ➢ operatore_chiusura per il controllo periodico e l’eventuale revoca del diritti di accesso a SysPrest, in

rispetto delle legge 196/03 sulla privacy.



ELENCO FUNZIONI

Come riattivare un utente scaduto

Bisogna modificare manualmente i dati nelle seguenti tabelle:

• tabella Utenti_001_Operatori

flgSospeso=0 motivo_sospensione_id=NULL data_fine=NULL where idUtente=xxx

• tabella dbo.Sito_010_LOG.idUtente modificare la data "data_ultimo_collegamento" indicare una data nel mese di corrente

Assistito selezionato

Nell riquadro “giallo” viene visualizzato il contenuto dei seguenti Cookies:

• Cookies("kaid"): codice assistito SysPrest

• Cookies("kaNominativo"): nominativo assistito (cognome + ‘ ‘ + nome)

• Cookies("kaDati"), "||"): i dati di dettaglio dell’assistito sono memorizzati tutti nel Cookies “kaDati” separati da || nell’ordine:

o 0 – sesso o 1- comune nascita o 2- data nascita o 3- indirizzo residenza o 4- comune residenza o 5- telefono 1 o 6- telefono 2 o 7- icona esente o 8- icona doc da pagare o 9- nominativo medico (cognome + ‘ ‘ + nome) o 10 codice fiscale medico o 11 età assistito

Erogazione

Il medico erogatore è obbligatorio:

• dalla funzione web di erogazione della singola prestazione quando la prestazione è aggiuntiva

• dalla funzione web di erogazione intero foglio (prenotato e non prenotate) L’integrazione con Ecomedica non valorrizza mai il medico erogante.



Valorizzazione delle tariffe secondo il listino di riferimento

Le tariffe vengono valorizzate nel seguente modo:

1) Per le prestazioni prenotate (per tutti i regimi): al momento della prenotazione →listino presente nel sistema al momento del contatto valido alla data di prenotazione

Es. 15/01/2006 (data di contatto) sto prenotando per il 20/06/2006 (data di prenotazione) listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € la tariffa sarà quella del listino presente nel sistema al 15/01/2006 e valido al 20/06/2006, quindi 100 € viene registrata la prenotazione num. xxxx con tariffa 100 €

2) Per le prestazioni prenotate al momento della contabilizzazione:

• per regime SSN e ALP listino presente nel sistema al momento della contabilizzazione valido alla data di prenotazione (aggiornamento della tariffa) Es. il 25/06/2006 sto contabilizzando la prenotazione num. xxxx del 20/06/2006 (data di prenotazione) listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € dal 01/06/2006 tariffa 120 € dal 22/06/2006 tariffa 150€ la tariffa sarà quella del listino presente nel sistema al 25/06/2006 e valido al 20/06/2006, quindi 120 € viene aggiornata la tariffa relativa alla prenotazione num. xxxx Anche quando si crea un documento di tipo impegnativa e vengono collegate in automatico le prenotazioni viene aggiornata la tariffa relativa alla prenotazione

• per altri regimi rimane tariffa registrata in fase di prenotazione

3) Per le prestazioni di tipo “accesso diretto”: al momento della contabilizzazione → listino valido alla “data di riferimento” indicato nel modulo web (per default viene impostata con la data odierna)

Es. 05/05/2006 (data di contatto) sto contabilizzando una prestazione in accesso diretto listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € dal 01/06/2006 tariffa 120 € la tariffa della prestazione sarà quella del listino presente nel sistema e valido al 05/05/2006, quindi 100 €

4) Per le prestazioni aggiuntive al momento della contabilizzazione/accettazione di prestazioni prenotate:

• per regime SSN e ALP listino valido alla data di prenotazione

• per altri regimi tariffa valida alla data odierna

5) Per le prestazioni aggiuntive al momento della contabilizzazione di prestazioni di tipo “accesso diretto”: listino valido alla data odierna



Tariffe per prestazioni appartenenti ad un pacchetto

− Listino dott. Rossi composto ha 4 prestazioni:

➢ check-up donna → 110€ ➢ visita cardiologia → 90€ ➢ elettrocardiogramma →70€

- L’operatore prenota la prestazione” check-up donna” erogata dal medico Rossi

- Nel database l’importo delle singole prestazioni viene valutato nel seguente modo: importo prestazione semplice = ( importo pacchetto* importo prestazione semplice) / totale importo prestazioni semplici )

visita cardiologia → (110*90)/160= 61,88€ elettrocardiogramma → (100*70)/160= 48,13€

- Se la somma delle singole prestazioni non coincide (61,88 +48,13=110,01) con l’importo del pacchetto (110), l’ultima prestazione del pacchetto viene sommata la differenza (48,13 + (110-110,01)= 48.12)

- stampa della ricevuta di prenotazione : check-up donna 110€ visita cardiologia elettrocardiogramma



Ricevute

Ricevuta Bonum “mancata prenotazione”

Il logo e dati aziendali (riportati in testata della ricevuta) sono diversi in base alla data della ricevuta

Ricevuta di cassa

La ricevuta di cassa viene stampata nel seguente modo:

[LOGO ENTE] (22) www.usl11.toscana.it

sede legale: [Indirizzo SedeLegale] [Citta SedeLegale]

[partita iva ente]

RICEVUTA NUM. [prefisso ricevuta] (23)

[numero ricevuta] DEL [data ricevuta di cassa]

CAUSALE [codice causale] - [descrizione causale]

CONTO [codice conto] - [descrizione conto]

SOGGETTO (13) [Soggetto incasso]

ASSISTITO (14) [cognome] * [nome] *

RESIDENTE A [comune residenza] INDIRIZZO [indirizzo residenza]

COD REGIONALE [codice sanitario] COD FISCALE [codice fiscale]

[tipo operazione] (1)

• Prestazioni sanitarie [importo prestazioni - imponibile]

• Ticket quote aggiuntive (18) [Importo_ContributoDigitalizzazione]

• Importo bollo (2) [importo bollo]

• Importo IVA (3) [importo solo iva]

• Importo ENPAV (19)

• Importo Contributo digitalizzaione (20)

TOTALE PAGATO [importo totale pagato]

NOTE (4) [Note indicate dall’operatore nella ricevuta di cassa]

DOCUMENTO(5) N.[Numero documento] DEL [data documento]

PRESTAZIONI DOCUMENTO(5)

PER LA CAUSALE 31- 32 (16)

Qta importo Compenso lordo professionista

Compensi lordi Supp. Diretto ed Indiretto

Costi-Imposte Quota Azienda Quota compartecipazione DGRT 743/2011

Prenotazione [num. prenotazione ] (6) [descrizione prestazione aziendale ] (15)

[quantita] [importo prestazione]

[Onorario] [Ripartizione : cod.36 “personale” + cod.40 “Personale indiretto”]

[ripartizioni: cod.37 “Imposte e tasse” + cod.38 “Costi aziendali” + cod. 7 “arrotondamento”]

[ripartizioni : cod. 35 “Quota Azienda”]

ripartizioni : cod. 45 “Quota Azienda manovra”]

PER LA CAUSALE 30 (16)

Qta importo Compenso lordo professionista

Compensi lordi Supp. Diretto ed Indiretto

Costi-Fondi-Imposte Quota Azienda Quota compartecipazione DGRT 743/2011

Prenotazione [num. prenotazione ] (6) [descrizione prestazione aziendale ] (15)

[quantita] [importo prestazione]

[Onorario] [Ripartizione : cod.13 “personale supporto” + cod.23 “Fondo supporto indiretto”]

ripartizioni: cod.3 “beni di consumo” + cod.5 “incidenza costi aziendali” + cod. 22 “fondo

[ripartizioni : cod. 6 “Quota Azienda”]

ripartizioni : cod. 45 “Quota Azienda manovra”]



perequazione” + cod.24 “fondo formazione” + cod.21 “imposte e tasse” + cod.41 “cod azienda vincolata” + cod. 7 “arrotondamento”]

PER ALTRE CAUSALI

Prestazione Qta importo

[num.prenotazione ] (6) [descrizione prestazione aziendale ] [quantita] [importo prestazione]

(7)Nessuna prestazione collegata al documento

DOCUMENTO(8) BONUM N.[numero ricevuta

BONUM] DEL [data ricevuta BONUM]

INFORMAZIONI • [Nota causale] (12)

• IVA esente Art 10 p.18 DPR 633/72 (9)

• IVA [percentuale IVA applicata ] % Art 10 p.18 DPR 633/72 (10)

• modalità di pagamento: [descrizione modalità pagamento]

• Imposta di bollo assolta in modo virtuale – Autorizzazione dell’Ufficio Territoriale Firenze 1 – Prot. 104296 del 04/12/2015 (11)

• (21) Per questo documento l'intestatario ha manifestato l'opposizione all'invio delle spese sanitarie per il 730”

L'INCARICATO

DATI AMMINISTRATIVI Operazione [numero movimento di cassa interno] effettuato dal operatore [codice

operatore che ha registrato l’incasso] il [data ora registrazione movimento di cassa]

Cassa N° [numero cassa che ha registrato l’incasso]

(1) [tipo operazione] se il tipo di movimento di cassa è di tipo “entrata” verrà stampato “HA PAGATO PER ” mentre se il tipo di movimento di cassa è di tipo “uscita” verrà stampato “HA RICEVUTO PER”

(2) La riga “importo bollo” verrà visualizzata solo se il movimento di cassa prevede il bollo

(3) La riga “importo IVA” verrà visualizzata solo se il movimento di cassa prevede IVA

(4) La riga “note” verrà visualizzata solo se l’operatore ha registrato una nota sul movimento di cassa

(5) La riga “documento” e “prestazioni documento”verrà visualizzata solo se il movimento di cassa è collegato ad un documento contabile

(6) Se la prestazione è prenotata verrà visualizzato “prenotazione N. [numero prenotazione] altrimenti verrà visualizzato “senza pren. – rif. [data collegamento della prestazione al documento]”

(7) Viene visualizzata solo se il documento non ha associato nessuna prestazione

(8) Viene visualizzata solo se il movimento di cassa si riferisce a una ricevuta BONUM

(9) Riga visualizzata se il movimento di cassa non ha IVA

(10) Riga visualizzata se il movimento di cassa ha IVA

(11) Riga visualizzata se il movimento di cassa è di regime <> SSN

(12) La riga viene visualizzata se nella causale dell’operazione di cassa è stato valorizzato il campo “nota ricevuta di cassa”

(13) Visualizzato per i movimenti di cassa diretti (senza selezione assistito/documento)

(14) Visualizzato per i movimenti di cassa diretti con selezione assistito e per i movimenti di cassa su documenti. I dati del paziente saranno i dati validi in anagrafe al momento della stampa della ricevuta.

(15) La descrizione della prestazione viene stampata se si è selezionata la modalità di stampa della ricevuta “con prestazioni”

(16) Per le causali 30, 31 e 32 vengono visualizzate le ripartizioni anche sulla stampa senza prestazioni (in questo caso non viene visualizzata la descrizione della prestazione). Se la prestazione appartiene a un pacchetto la ripartizione è quella relativa al pacchetto in porporzione al valore della prestazione singola come avviene nel report 215.



(17) La descrizione della prestazione viene stampata se si è selezionata la modalità di stampa della ricevuta “con prestazioni”

(18) La riga è visualizzata solo se il movimento di cassa prevede ticket aggiuntivi

(19) La riga è visualizzata solo se il movimento di cassa prevede imposta ENPAV

(20) La riga è visualizzata solo se il movimento di cassa prevede contributo digitalizzazione

(21) La riga è visibile se ricevuta intestata ad un assistito selezionato dall’anagrafe. Indica se l’assistito ha indicato l’opposizione all’invio del movimento di cassa al 730 precompilato.

(22) Il logo e dati aziendali diversi in base alla data della ricevuta (23) Il previsso di ricevuta “EMC” viene visualizzato se l’anno della ricevuta > 2015



Ricevuta Promemoria per il pagamento

Ricevuta visualizzata in prenotazione e contabilizzazione

sede legale: [dbo].[Sito_016_Ambiente_Storico].[IndirizzoSedeLegale] per AmbientePrg =2

[dbo].[Sito_016_Ambiente_Storico].[ PartIva] per

AmbientePrg =2

www.usl11.toscana.it

DOCUMENTO NUM. [numero IUV del documento] DEL [data registrazione documento]

N. IMPEGNATIVA [per i documenti senza impegnativa la riga non viene visualizzata]

REGIME [descrizione del regime]

[descrizione causale]

TOTALE Importo prestazioni sanitarie da pagare [Importo totale da pagare]

DOCUMENTO N.[numero documento contabile] DEL [data documento]

Il codice barcode deve essere al centro. Il codice di BarCode è composto dal numero IUV del documento (di 15 caratteri) + il carattare di controllo calcolato nel seguenet modo:

• SP= somma delle cifre nelle posizioni pari del valore IUV

• SD= somma delle cifre nelle posizioni dispari del valore IUV

• S= SP+ (SD*3)

• CRC= si ottiene con il numero più piccolo che sommato a S consente di ottenere un numero S1 multiplo di 10 (S1 MOD 10)=0 → CRC= 10 – (ultimo carattere numero di S)



Ricevuta di prenotazione

[Logo ente] (17) www.usl11.toscana.it

sede legale: [Indirizzo SedeLegale] [Citta SedeLegale]

[partita iva ente]

DATI ASSISTITO [cognome] * [nome] *

NATO/A [comune di nascita] IL [data di nascita]



TEL. [telefono 1] TEL. [telefono 2]

DATA/ORA PRENOTAZIONE

[data prenotazione] ALLE [ora prenotazione] (N.PRENOTAZIONE [numero prenotazione])

SEDE Per agende senza indicazione delle stanze avremmo:

[descrizione struttura dell’agenda prenotata]

[indirizzo struttura – da anagrafe strutture]

[note sede dell’agenda]

(3) [descrizione Equipe dell’agenda prenotata]

Per agende con associato un stanze valida alla data di prenotazione avremmo:

[descrizione comune] - [descrizione sede]

BLOCCO [palazzina] – PIANO [piano-stanza] – STANZA [stanza]

(3) [descrizione Equipe dell’agenda prenotata]

PRESTAZIONI [regime erogazione] (13)

• [descrizione prestazione aziendale ] Qta [quantita] [importo prestazione (1)]

(2) ]PREPARAZIONE: [preparazione prestazione]

• [descrizione prestazione aziendale ] Qta [quantita [importo prestazione (1)]


• [descrizione prestazione aziendale ] Qta [quantita] [importo prestazione (1)]


NUMERO CHIAMATA

[XXXX (4)]

Frase per agende il flg “accettazione elimina code”= SI

ATTENZIONE !!! Il numero a fianco sarà visualizzato sul monitor nella sala d’attesa per indicare il turno di accesso all’ambulatorio

Frase per agende il flg “accettazione elimina code”= NO

ATTENZIONE !!! Con il numero indicato qui a fianco sarai chiamato per entrare in ambulatorio

MODALITA’ DI ACCESSO(5)

• [nota tempi accesso indicate nel regime] (15)

• Portare i referti di esami e visite eseguite precedentemente nonché eventuali relazioni di dimissioni ospedaliere

• In caso di impossibilità a presentarsi all’appuntamento, si prega di comunicarlo telefonicamente al n. 0571/7041 (14)



• In caso di impossibilità a presentarsi all’appuntamento, si prega di comunicarlo telefonicamente al n. 0571/7051 (18)

DATI RICETTA N. Ricetta [numero della ricetta indicato in prenotazione] (7)

Motivo della non indicazione del numero ricetta: [descrizione motivo] (8)

Codice Ricetta [colore ricetta] prima data prenotabile per codice ricetta [data prima disponibilità per il colore della ricetta] (9)

Codice Prenotazione [colore prenotazione] prima data prenotabile per codice prenotazione [data prima disponibilità per il colore della prenotazione] (10)

Prima data prenotabile dell’azienda ULS 11 [data prima disponibilità] (12)

Prima data prenotabile nel regime SSN dell’azienda ULS 11 [Prima_disp_SSN] (16)

INFORMAZIONI UTILI (6) • In caso di impossibilità a presentarsi all’appuntamento, si prega di comunicarlo

telefonicamente al n. 0571/7051 oppure tramite mail all'indirizzo [email protected] riportando i seguenti dati relativi alla prenotazione: nr. di prenotazione, nome, cognome, codice fiscale

• Chi non disdice l'appuntamento almeno 48 ore prima della data di prenotazione è tenuto al pagamento della somma corrispondente al ticket della prestazione, compreso il ticket aggiuntivo, anche se esente (del GRT 493/2011 e successive integrazioni)

[note ricevuta di prenotazione] (11)

DATI AMMINISTRATIVI Operatore Prenotazione [codice operatore che ha effettuato la prenotazione] DEL

[data registrazione prenotazione] ALLE [ora data registrazione prenotazione]

(1) [importo prestazione] l’importo della prestazione viene visualizzato se la prestazione è erogata in regime di Libera professione o area pagamento

(2) [preparazione prestazione] viene visualizzata la preparazioni indicata nell’associazione agenda-prestazione se presente altrimenti la preparazione indicata nell’anagrafe delle prestazioni. Se non è presente nessuna delle due non viene visualizzata la riga preparazione

(3) [descrizione Equipe dell’agenda prenotata] viene visualizzato solo se è erogata in regime di Libera professione o area pagamento

(4) Il numero chiamata è rappresentato dalle ultime 4 cifre del numero di prenotazione (viene stampato in tutte le ricevute

(5) Il testo della “modalità di accesso” verrà visualizzato per tutti i regimi di erogazione

(6) Il testo “INFORMAZIONI UTILI” verrà visualizzato solo per il SSN

(7) La riga” N. Ricetta” viene visualizzato se la prestazione è erogata in regime SSN e se in fase di prenotazioni per il SSN è stato indicato il numero dell’impegnativa.

(8) La riga” Motivo della non indicazione del numero ricetta” viene visualizzato se la prestazione è erogata in regime SSN e non è stato indicato in fase di prenotazione il numero della ricetta

(9) La riga “Codice Ricetta” viene visualizzato se la prestazione è erogata in regime SSN su agende di tipo “colore”. Viene stampata la data di prima disponibilità su codice di priorità della ricetta. Se la data prenotata < della data di prima disponibilità viene stampata la data di prenotazione. Se la data di prima disponibilità e NULL viene stampata la data di prenotazione

(10) La riga “Codice Prenotazione” viene visualizzato se la prestazione è erogata in regime SSN su agende di tipo “colore”. Viene stampata la data di prima disponibilità su codice di priorità della prenotazione. Se la data prenotata < della data di prima disponibilità viene stampata la data di prenotazione. Se la data di prima disponibilità e NULL viene stampata la data di prenotazione

(11) [nota ricevuta di prenotazione] viene stampata la nota della ricevuta di prenotazioni diversa per il regime di erogazione (gestita dalla funzione “gestione ambiente - modifica nota fissa prenotazione per regime”

(12) La riga “Prima data prenotabile dell’azienda ULS 11” verrà visualizzata se la prenotazione è di tipo non colore. Se la data prenotata < della data di prima disponibilità viene stampata la data di prenotazione. Se la data di prima disponibilità e NULL viene stampata la data di prenotazione.

(13) La descrizione del regime di erogazione verrà visualizzata per tutti i regime di erogazione

mailto:[email protected]



(14) La riga verrà visualizzata se la prenotazione è di Area Pagamento

(15) La nota dei tempi di accesso (dbo.Sito_009_Ambiente_Note_Prenot.RicPrenot_NoteTempiAccesso) viene visualizzata per tutti i regimi di erogazione (campo gestito dalla funzione ambiente)

(16) La riga viene visualizzata solo per regime ALP e se la data di prima disponibilità SSN è valorizzata

(17) Il logo e dati aziendali diversi in base alla data della registrazione della prenotazione

(18) La riga verrà visualizzata se la prenotazione è di regime ALP

Ricevuta prenotazioni di un contatto

Il logo e dati aziendali (riportati in testata della ricevuta) sono diversi in base alla data odierna

Ricevuta di prenotazione su prenotazioni effettuati sul Cup Area Vasta


sede legale: via dei Cappuccini, n.79 cap. 50053 - Empoli (FI) Cod.Fisc e Part. IVA n.04616830487

DATI ASSISTITO [cognome] * [nome] *

NATO/A [comune di nascita] IL [data di nascita]



TEL. [telefono 1] TEL. [telefono 2]

DATA/ORA PRENOTAZIONE

[data prenotazione] ALLE [ora prenotazione] (N.PRENOTAZIONE [numero prenotazione])

SEDE [descrizione struttura CUP AV]

Indirizzo: [indirizzo struttura CUP AV]

TEL. [telefono della struttura]

Ambulatorio: [descrizione working unit] (tel. [telefono working unit])

PREPARAZIONE [preparazione]

PRESTAZIONI • Cod.[codice prestazione CUP AV] [descrizione prestazione CUP AV] Qta [quantita]

• Cod.[codice prestazione CUP AV] [descrizione prestazione CUP AV] Qta [quantita

• Cod.[codice prestazione CUP AV] [descrizione prestazione CUP AV] Qta [quantita]

[note ricevuta di prenotazione]

DATI AMMINISTRATIVI Operatore Prenotazione [codice operatore che ha effettuato la prenotazione] DEL

[data registrazione prenotazione] ALLE [ora data registrazione prenotazione]



Fattura

Nella stampa non è gestita la dicitura “originale” e “ristampa”

[LOGO ENTE]

sede legale: [Indirizzo Sede Legale ASL TC] [Citta SedeLegale]

[partita iva ente]

[Fattura / Nota di credito]

[ANNO]/[PROGRESSIVO FATTURA]/ [SEZIONALE] DEL [data fattura]

Fattura di riferimento (6)

[ANNO]/[PROGRESSIVO FATTURA]/ [SEZIONALE] DEL [data fattura]

SOGGETTO [FATTURA.INTEST_NOMINATIVO]

[FATTURA INTEST_INDIRIZZO]

[FATTURA

INTEST_CAP] [FATTURA.INTEST_COMUNE_DSC] ([FATTURA.INTEST_PROVINCIA])

C.F. [FATTURA. ASSISTITO_CODICE_FISCALE]

HA RICEVUTO PER (9)

HA PAGATO PER(10)

• Importo imponibile [FATTURA. TOTALE_IMPONIBILI]

• Importo bollo (1) [FATTURA.IMPORTO_BOLLO]

• Importo IMPOSTE (2) [FATTURA.TOTALE_IMPOSTE]

TOTALE PAGATO [FATTURA.TOTALE_FATTURA]

DOCUMENTO(5) N.[Numero documento] DEL [data documento]

Prestazione (8) Qta importo

[num.prenotazione ] (3) [descrizione prestazione aziendale ] [quantita] [importo prestazione]

INFORMAZIONI • (7) note movimento di cassa

• modalità di pagamento: [descrizione modalità pagamento relativa al movimento di cassa]

• Imposta di bollo assolta in modo virtuale – Autorizzazione dell’Ufficio Territoriale Firenze 1 – Prot. 104296 del 04/12/2015 (11)

• (4) Per questo documento l'intestatario ha manifestato l'opposizione all'invio delle spese sanitarie per il 730”

DATI AMMINISTRATIVI

Operazione N.[numero movimento di fattura interno] effettuato dall’operatore [codice operatore che ha registrato la fattura] il [data ora registrazione fattura]

Cassa [numero cassa che ha registrato l’incasso] - N.[numero movimento di cassa interno]

(1) (11) La riga verrà visualizzata solo se la fattura prevede il bollo a carico paziente

(2) Viene riportata una riga per ogni tipologia s’imposta presente per la fattura. Se fattispecie IVA è “esente” non viene stampato l’importo dell’imposta.

(3) Se la prestazione è prenotata verrà visualizzato “prenotazione N. [numero prenotazione] altrimenti verrà visualizzato “senza pren. rif. [data collegamento della prestazione al documento]”

(4) Indica se l’assistito ha indicato l’opposizione all’invio del movimento di cassa al 730 precompilato. (5) Dati documento/prestazioni del relativo movimento di cassa

(6) La riga viene visualizzata solo se la fattura è di tipo “nota di credito”

(7) La riga viene visualizzata solo se per il movimento di cassa è stata indicata una nota

(8) La grid di elenco delle prestazioni è visibile solo se è stato selezionato il modello di stampa “con prestazioni”

(9) “HA RICEVUTO PER “ Visualizzato se importo restituito;“HA PAGATO PER” visualizzato per importi pagati



Diario Rpt Automatici (REPORT – LISTE)

Funzione web che visualizza i report schedulati automaticamente dal sistema con un processo SQL Server. A differenza della funzione “Diario Report” che mostra ad ogni operatore solo i report che ha schedulato manualmente, questa funzione da la possibilità di visualizzare a tutti gli operatori i report schdulati dal sistema. La pagina principale si aggiorna ogni 15 secondi.

Contabilizza

Esenzioni assistiti per contabilizzazione automatica (funzionalità sospesa)

In fase di contabilizzazione di un documento, se l’esenzione selezionata è “esente per età e reddito” il sistema memorizzerà per l’assistito il codice di esenzione e l’anno per l’anno di validità. La tabella che memorizza le esenzioni per ogni assistito è dbo.AnagraficaBase_esenzioni, mentre la stored procedure chiamta in fase di contabilizzazione per inserire o aggiornare le esenzioni di un assistito è dbo.p_Contabilizza_060_AnagraficaBase_Esenzioni (per ulteriori spiegazioni sull’utilità di questa tabella vedi la sezione “Contabilizzazione automatica” nella funzione di Prenotazione).

Contabilizza - Flussi SPA

In registrazione di un nuovo documento contabile viene classificato da “estrarre” dai flussi SPA (FLG_FLUSSI_SPA_ELAB=0 e FLG_FLUSSI_SPA_DA_RIESTRARRE=0). Se viene riaperto un documento contabile classificato come “estratto” dai flussi SPA (FLG_FLUSSI_SPA_ELAB=1) viene automaticamente classificato da riestrarre (FLG_FLUSSI_SPA_DA_RIESTRARRE=1).

Mentre se viene cancellato un documento contabile classificato come “estratto” dai flussi SPA (FLG_FLUSSI_SPA_ELAB=1) viene memorizzato in una tabella per poi essere estratto dall’elaborazione dei flussi (DocumentiLogici_DEL).

Contabilizzazione automatica di documenti (funzionalità SOSPESA)

Effettuata la prenotazione, il sistema genererà solo se non presente, un documento contabile di tipo “impegnativa” per assistiti esenti totali (collegamento con anagrafe esterna dbo.v_AnagrafeEsterna_vtabesen). Il documento creato avrà come esenzione “esenti altro” (cod.1). L’elaborazione notturna segnala quali sono i documenti che sono stati auto contabilizzati ed invia una mail con l’elenco. Il report num. 312 per individuare i documenti errati è stato sospeso (per ulteriori spiegazioni vedi la sezione “Contabilizzazione automatica” nei Report). Durante la prenotazione, il flusso del sistema per la contabilizzazione automatica di una ricetta/impegnativa (tutto all’interno della stored procedure p_Prenotazione_050_num_ricetta_upd) sarà il seguente:



Nota: in data 05/06/2007 è stata eliminata la o la contabilizzazione automatica per gli assistiti presenti nella tabella dbo.xAnagraficaBase_esenzioni con anno validita corrispondente all’anno della data odierna.

Creo un nuovo documento collegato a quella ricetta con

p_Conttabilizza_009_ImpegnativeNew

regime è SSN ed è presente

ricetta e data

la prenotazione

L’ssistito è “esente

(.xAnagraficaBas

INIZIO

…

…

Non esistono altri documenti

con quella

Aggiorno il flag_Autocontabilizza al documento collegato a quella ricetta

FINE

SI NO

NO

NO

NO SI

SI

SI



Accettazione – Elimina code

La vista “V_ELIMINA_CODE” riporta l’elenco delle prenotazioni con data prenotazione = alla data odierna associate ad agende con codice stanza valido e agende classificate “elimina code” (con ora prenotazione <= ora odierna) . La vista ha le seguenti colonne:

Nome campo descrizione

STANZA_COD Testo di 8 caratteri → Il codice aziendale della stanza composto da “identificativo_comune” (1 carattere) + “identificativo_sede_palazzina” (2 carattere) + “identificativo_piano” (2 carattere) + “identificativo_stanza” (3 carattere). (codice stanza valido alla data di prenotazione).

Gruppo_stanze_cod Codice gruppo stanza indicato alla stanza.

PRENOTAZIONE_ID Codice prenotazione - numerico

PRENOTAZIONE_DATA Data prenotazione formato GG/MM/AAA

PRENOTAZIONE_ORA Ora prenotazione espressa in minuti -Numerico (es.600 → ore 10.00)

STATO_ELIMINA_CODE_ID Codice stato

STATO_ELIMINA_CODE_DSC Descrizione dello stato

STATO_ELIMINA_CODE_DATA_ORA_UPD Data ora aggiornamento stato (se stato =0 AVANTI il campo è NULL)



Lista Prenotati HTML


sede legale: via dei Cappuccini, n.79 cap. 50053 - Empoli (FI)

Cod.Fisc e Part. IVA n.04616830487

LISTA PRENOTATI di [giorno settimana] [giorno della data] [mese descrittivo della data] [ANNO]

Struttura Equipe

[descrizione struttura dell’agenda] [descrizione dell’equipe dell’agenda]

Agenda: cod. [numero agenda] - [descrizione agenda] Stanza xxxxxx

[ORA] [nominativo assistito] Nato il [data di nascita] Tel.1 [numero di telefono 1] Tel.2 [numero di telefono 2] Prenotazione num. [ID prenotazione] durata: [durata] NUMERO CHIAMATA [ultimi 4 caratteri prenot.] Codice priorità prenotazione: [colore prenotazione se presente] Note prenotazione: [note prenotazione visualizzate solo se presenti] Prenotazione Forzata [visibile solo se la prenotazione è stata forzata] Prenotato da altra agenda [visibile solo se prenotazione effettuata su altra agenda del raggruppamento] • Descrizione prestazione 1 q.ta [quantità]

• Descrizione prestazione 2 q.ta [quantità] • Descrizione prestazione 3 q.ta [quantità]



Prenotazione – multipla “un posto prestazione”

Nella modalità di prenotazione “multipla - per agenda/per luoghi” (SSN, ALP, Paganti, Area a pagamento) per le prestazioni associate ad agende classificate “un posto per prestazione” vengono visualizzate le date disponibili che hanno un tot. di buchi consecutivi liberi.

Per la modalità di prenotazione “multipla - per agenda/per luoghi - SSN per fascia di priorità” per le prestazioni associate ad agende classificate “un posto per prestazione” oltre a controllare che la data abbia un numero di buchi consecutivi adeguati il sistema visualizza solo le date che hanno un numero di posti liberi richiesti per la fascia di priorità selezionata.

Esempio prenotazione multipla SSN “non colore”

Agenda num XX di tipo “un posto per prestazione” e “non colore” Con associate le prestazioni: P1, P2, P3 Apertura dal 01/12/2006 al 19/12/2006 tutti i lunedì dalle 08.00 alle 12.00 -- durata =30 minuti Calendario max buchi liberi:

- 04/12/2006 max buchi=2 - 11/12/2006 max buchi=6 - 18/12/2006 max buchi=3

se nel carrello di prenotazione sono state selezionate le prestazioni P1, P2 e P3 il sistema visualizzerà le date del 11/12/2006 e del 18/12/2006 (max buchi>= numero di prestazioni nel carrello) l’operatore seleziona il 11/12/2006 per l’agenda num.XX per la data 11/12/2006 nel calendario ci sono i seguenti orari:

- 08.00 libero - 08.30 occupato - 09.00 libero - 09.30 libero - 10.00 libero - 10.30 libero - 11.00 libero - 11.30 libero

il sistema visualizza gli orari disponibili 09.00 - 09.30 - 10.00 - 10.30 → orari che possono avere 3 buchi liberi consecutivi. N.B. proporre più orari potrebbe generare dei buchi prenotabili sono singolarmente. Un’altra possibilità sarebbe di visualizzare solo il primo orario. L’operatore seleziona l’orario delle 09.00 e il sistema effettuerà la prenotazione occupando i buchi (se sono tutti ancora disponibili) delle 09.00, 09.30 e delle 10.00 .

Esempio prenotazione multipla SSN “colore”

Agenda num XX di tipo “un posto per prestazione” e “colore” Con associate le prestazioni: P1, P2, P3 Apertura dal 01/12/2006 al 19/12/2006 tutti i lunedì dalle 08.00 alle 12.00 -- durata =30 minuti Fascia: B tra 0gg a 20gg D tra 11gg a 365gg Data contatto = 01/12/2006 Calendario max buchi liberi:

- 04/12/2006 max buchi=2



- 11/12/2006 max buchi=6 - 18/12/2006 max buchi=3 - 25/12/2006 max buchi=8

Calendario sintesi: - 04/12/2006 per il B 5 posti liberi - 11/12/2006 per il B 6 posti liberi - 18/12/2006 per il B 5 posti liberi - 25/12/2006 per il B 2 posti liberi per il D 6 posti liberi

colore prenotazione B

se nel carrello di prenotazione sono state selezionate le prestazioni P1, P2 e P3 il sistema visualizzerà le date del 11/12/2006 e 18/12/2006 (max buchi>= numero di prestazioni nel carrello e numero AND numero buchi liberi B >= numero di prestazioni nel carrello) l’operatore seleziona il 11/12/2006 per l’agenda num.XX per la data 11/12/2006 nel calendario ci sono i seguenti orari:

- 08.00 libero - 08.30 occupato - 09.00 libero - 09.30 libero - 10.00 libero - 10.30 libero - 11.00 libero - 11.30 libero

il sistema visualizza gli orari disponibili 09.00 - 09.30 - 10.00 - 10.30 → orari che possono avere 3 buchi liberi consecutivi. L’operatore seleziona l’orario delle 09.00 e il sistema effettuerà la prenotazione occupando i buchi (se sono tutti ancora disponibili) delle 09.00, 09.30 e delle 10.00 .



Prenotazione – memorizzazione prima disponibilità

In fase di prenotazione viene memorizzata la prima disponibilità (esclusa la data prenotata) nel seguente modo:

• Percorso non-colore (forzata o meno) o la prima disponibilità relativa alle agende appartenenti alla classificazione dell'agenda (urgente,

riservata, di reparto, non urgente) prenotata filtrate in base all'abilitazione dell'operatore, considerando il regime prenotato

• Percorso “colore” (forzato o meno) o la prima disponibilità relativa alle agende “colore” riferita alla priorità della ricetta in base

all'abilitazione dell'operatore, considerando il regime prenotato o la prima disponibilità relativa alle agende “colore” riferita alla priorità della prenotazione in base

all'abilitazione dell'operatore, considerando il regime prenotato Nota. Si ricorda che la classificazione “di reparto” non è un percorso di prenotazione. Potrebbe quindi verificarsi il seguente caso:

o L’operatore seleziona il percorso “non colore – non urgente” o Il sistema visualizza la disponibilità (tenendo conto dell’abilitazioni dell’operatore)

▪ Dell’agenda A classificata “di reparto” ▪ Dell’agenda B classificata “non urgente” ▪ Dell’agenda C classificata “di reparto” ▪ Dell’agenda D classificata “non urgente”

o Se l’operatore prenota in una agenda “di reparto” la prima disponibilità sarà valorizzata con la data

minima prenotabile tra le agende A e C → l‟operatore però a video ha visualizzato anche le disponibilità dell‟agenda B e D

o Se l’operatore prenota in una agenda “non urgente” la prima disponibilità sarà valorizzata con la

data minima prenotabile tra le agende B e D → l‟operatore però a video ha visualizzato anche le disponibilità dell‟agenda A e C



Calendario prenotazione

Esempio del sistema di calcolo delle disponibilità

orario segnato in verde orario disponibile per la prenotazione

DETTAGLIO GIORNO 10/04/2004

ORA PREVISTI PRENOTATI DISPONIBILITA’

14:00 1 0 1

14:30 1 0 1

15:00 1 0 1

15:30 1 0 1

16:00 1 0 1

TOT. 5 0 5

1. Prenotazione per le 14.00

DETTAGLIO GIORNO 10/04/2004 dopo operazione 1


14:00 1 1 0

14:30 1 0 1

15:00 1 0 1

15:30 1 0 1

16:00 1 0 1

TOT. 5 1 4

2. Prenotazione forzata per le 14.30



14:00 1 1 0

14:30 1 1 0

15:00 1 0 1

15:30 1 0 1

16:00 1 0 1

TOT. 5 2 3



3. Prenotazione forzata per le 14.30



14:00 1 1 0

14:30 1 2 -1

15:00 1 0 1

15:30 1 0 1

16:00 1 0 1

TOT. 5 3 3

4. Prenotazione per le 15.00 - prenotazione per le 15.30



14:00 1 1 0

14:30 1 2 -1

15:00 1 1 0

15:30 1 1 0

16:00 1 0 1

TOT. 5 5 1

5. Prenotazione forzata per le 16:30



14:00 1 1 0

14:30 1 2 -1

15:00 1 1 0

15:30 1 1 0

16:00 1 0 1

16:30 0 1 -1

TOT. 5 6 1

6. Cancello prenotazione delle 16:30



14:00 1 1 0

14:30 1 2 -1

15:00 1 1 0

15:30 1 1 0

16:00 1 0 1

TOT. 5 5 1



Esempio del sistema di calcolo del calendario Sintesi (utilizzato per la prenotazione per codice di priorità)

Se l’agenda ha una programmazione con codici colore oltre alla generazione del calendario già esistente la rigenerazione deve suddividere il numero di buchi in base alle percentuali assegnate (arrotondando allo 0,5). La generazione del calendario deve calcolare i posti previsti per codice di priorità considerando i valori minimi di buchi previsti nella settimana (in seguito si trova la descrizione del programma).

Il calcolo dei posti previsti per codice di priorità avviene per settimana (non per giorno). ESEMPIO

Agenda num. XXXX di tipo colore con tipologia di fascia a 3 fasce Percentuali fascia P (oltre 30 gg) :

▪ B = 50% num. posti Minimi =5 ▪ D = 30% num. posti Minimi =3 ▪ P = 20%

Calendario agenda XXXX alla data odierna 16/02/2006 1° settimana

Lunedì Martedì Mercoledì

Giovedì 16/02/2006

Venerdì 17/02/2006

Sabato 18/02/2006

Domenica 19/02/2006

0 posti 0 posti 0 posti 2 posti 5 posti 0 posti 0 posti Tot. posti = 7

2° settimana

Lunedì 20/02/2006

Martedì 21/02/2006

Mercoledì 22/02/2006

Giovedì 23/02/2006

Venerdì 24/02/2006

Sabato 25/02/2006

Domenica 26/02/2006


3° settimana

Lunedì 27/02/2006

Martedì 28/02/2006


Giovedì 02/03/2006

Venerdì 03/03/2006

Sabato 04/03/2006

Domenica 05/03/2006


4° settimana

Lunedì 06/03/2006

Martedì 07/03/2006


Giovedì 09/03/2006

Venerdì 10/03/2006

Sabato 11/03/2006

Domenica 12/03/2006


5° settimana

Lunedì 13/03/2006

Martedì 14/03/2006


Giovedì 16/03/2006

Venerdì 17/03/2006

Sabato 18/03/2006

Domenica 19/03/2006


6° settimana

Lunedì 20/03/2006

Martedì 21/03/2006


Giovedì 23/03/2006

Venerdì 24/03/2006

Sabato 25/03/2006

Domenica 26/03/2006


7° settimana

Lunedì 27/03/2006

Martedì 28/03/2006


Giovedì 30/03/2006

Venerdì 31/03/2006

Sabato 01/04/2006

Domenica 02/04/2006


N° settimana ……….. Programma di calcolo disponibilità per codice di priorità – Calendario Sintesi



Il sistema deve analizzare settimana per settimana

1° settimana

➢ Si calcola il numero di posti per settimana per codice di priorità della fascia oltre i 30 gg B = (7/100) * 50 = 4 D = (7/100) * 30 = 2 P = (7/100) * 20 = 1

➢ Si controlla se il numero di posti calcolati sulla settimana soddisfano i valori minimi per il codice di priorità Per il B: B calcolati >= B Minimi (4 >=5 ) → no i posti del B diventano i minimi B = 5 Per il D: D calcolati > D Minimi (2 >= 3) → no i posti del D diventano i minimi (se la somma di B+ D non supera il totale dei posti; altrimenti è il numero totale di posti - B) D = 2 Per il P: totale posti – totale B ricalcolato - totale D ricalcolato (7-5-2) P = 0

B = 5 D = 2 P = 0

➢ Distribuzione sulla settimana i posti per codice di priorità:

1. distribuzione codice priorità B

Funzione di distribuzione appo_B=1 giorno_settimana= 1 ‘ Lunedi while B calcolati >= appo_B if giorno_settimana=8 then ‘ si ri-inizia la settimana dal lunedi giorno_settimana= 1 ‘ Lunedi

end if if NumPostiLiberi(giorno_settimana) > 0 then numPosti_B(giorno_settimana) = numPosti_B(giorno_settimana) + 1 appo_B= appo_B +1

end if

giorno_settimana= giorno_settimana +1

end while



Esempio utilizzo funzione di distribuzione: while 5 >= 1 if 1=8 then

end if

if 0 > 0 then ‘ il lunedì non ha disponibilità end if

giorno_settimana= giorno_settimana +1 ‘ Martedi end while while 5 >= 1 if 2=8 then

end if

if 0 > 0 then ‘ il martedi non ha disponibilità end if

giorno_settimana= giorno_settimana +1 ‘ Mercoledi end while while 5 >= 1 if 3=8 then

end if

if 0 > 0 then ‘ il Mercoledi non ha disponibilità end if

giorno_settimana= giorno_settimana +1 ‘ Giovedi end while while 5 >= 1 if 4=8 then

end if

if 2 > 0 then ‘ il giovedì ha 2 disponibilità numPosti_B(4) = 0 + 1 appo_B= 1 +1

end if giorno_settimana= giorno_settimana +1 ‘ Venerdi

end while dopo la prima distribuzione nel calendario sintesi per i previsti avremmo:


Giovedì 16/02/2006

Venerdì 17/02/2006

Sabato 18/02/2006

Domenica 19/02/2006

B

while 5 >= 2 if 5=8 then

end if

if 5 > 0 then ‘ il Venerdi ha 5 disponibilità numPosti_B(5) = 0 + 1 appo_B= 2 +1

end if giorno_settimana= giorno_settimana +1 ‘ Sabato

end while


Giovedì 16/02/2006

Venerdì 17/02/2006

Sabato 18/02/2006

Domenica 19/02/2006



B B

….per il sabato, domenica, lunedì, martedì, mercoledì non ci sono disponibilità mentre per il giovedi while 5 >= 3 if 4=8 then

end if

if 1 > 0 then ‘ il giovedì ha ancora 1 disponibilità numPosti_B(4) = 0 + 1 appo_B= 1 +1

end if giorno_settimana= giorno_settimana +1 ‘ Venerdi

end while dopo la prima distribuzione nel calendario sintesi per i previsti avremmo:


Giovedì 16/02/2006

Venerdì 17/02/2006

Sabato 18/02/2006

Domenica 19/02/2006

B B

B

Terminata la distribuzione B nel calendario sintesi per i previsti avremmo


Giovedì 16/02/2006

Venerdì 17/02/2006

Sabato 18/02/2006

Domenica 19/02/2006

B B

B B

B

2. distribuzione codice priorità D (come per la funzione di distribuzione dei B) Terminata la distribuzione D nel calendario sintesi per i previsti avremmo


Giovedì 16/02/2006

Venerdì 17/02/2006

Sabato 18/02/2006

Domenica 19/02/2006

B B

B B

B



D

D

3. distribuzione codice priorità P (come per la funzione di distribuzione dei B)

➢ Si controlla la fascia di appartenenza del giorno della settimana


Giovedì 16/02/2006

I° fascia

Venerdì 17/02/2006

I° fascia

Sabato 18/02/2006

Domenica 19/02/2006

0 posti 0 posti 0 posti

2 B 2 B

2 D

0 posti 0 posti

- Se il giorno appartiene alla I° fascia (entro i 10 gg) i buchi sono 100% con codice di priorità B - Se il giorno appartiene alla 2° fascia (tra 11 gg e 30 gg) i buchi di priorità P vengono ripartiti nel B e D

secondo la percentuale indicata nella 2° fascia - Se il giorno appartiene alla 3° fascia (oltre i 30) non deve essere apportata nessuna modifica alla

distribuzione già avvenuta -

Nel caso della 1° settimana il calendario sintesi dei previsti sarà il seguente:


Giovedì 16/02/2006

I° fascia

Venerdì 17/02/2006

I° fascia

Sabato 18/02/2006

I° fascia

Domenica 19/02/2006

I° fascia

0 posti 0 posti 0 posti

2 B 4 B

0 posti 0 posti

3° settimana

➢ Si calcola il numero di posti per settimana per codice di priorità della fascia oltre i 30 gg B = (20/100) * 50 = 10 D = (20/100) * 30 = 6 P = (20/100) * 20 = 4

➢ Si controlla se il numero di posti calcolati sulla settimana soddisfano i valori minimi per il codice di priorità Per il B: B calcolati >= B Minimi (10 >=5 ) → si B = 10 Per il D: D calcolati > D Minimi (6 >= 3) → si D = 6 Per il P: totale posti – totale B ricalcolato - totale D ricalcolato (20-10-6) P = 4

B = 10 D = 6 P = 4

➢ Distribuzione sulla settimana i posti per codice di priorità:

Lunedì 27/02/2006

Martedì 28/02/2006


Giovedì 02/03/2006

Venerdì 03/03/2006

Sabato 04/03/2006

Domenica 05/03/2006

B B B B B

B B B B B

D D D D

D D

P P

P

P

➢ Si controlla la fascia di appartenenza del giorno della settimana



Lunedì 27/02/2006

2° fascia

Martedì 28/02/2006

2° fascia


2° fascia

Giovedì 02/03/2006

2° fascia

Venerdì 03/03/2006

2° fascia

Sabato 04/03/2006

2° fascia

Domenica 05/03/2006

2° fascia

2 B 1 D

2 B 2 D 3 P

B 1 D

2 B 2 B

2 D 1 P

0 posti 0 posti

Percentuali fascia D (tra 11 gg e 30 gg) :

▪ B = 60% ▪ D = 40%

- Se il giorno appartiene alla 2° fascia (tra 11 gg e 30 gg) i buchi di priorità P vengono ripartiti nel B e D

secondo la percentuale indicata nella 2° fascia

Lunedì 27/02/2006

Martedì 28/02/2006


Giovedì 02/03/2006

Venerdì 03/03/2006

Sabato 04/03/2006

Domenica 05/03/2006

2 B 1 D

4 B 3 D

2 B 1 D

2 B 3 B

2 D

0 posti 0 posti

La tipologia di fascia di un’agenda può prevedere 2 o 3 fasce. Il programma si comporta in modo diverso a seconda del numero di fasce dell’agenda.

Nel caso di agenda con 2 fasce nella generazione del calendario la percentuale della seconda fascia rappresenta come devono essere ripartiti i buchi e non, come nel caso di agenda con 3 fasce, la percentuale del P rimanente da ripartire.

Rigenerazione del calendario “MAX BUCHI LIBERI” (utilizzato per la prenotazione su agende “un posto prestazione”)

Se l’agenda è classificata “un posto prestazione” generando il calendario viene anche alimentata la tabella workCalendario_Max_buchi_liberi che memorizza per ogni data e orario prenotabile il numero massimo di buchi liberi consecutivi.

Il programma è contenuto nelle stored procedure del database SysPrestv3_Empoli:

• P_WORK_CALENDARIO_0020_MAX_BUCHI_LIBERI_AGENDA

• P_WORK_CALENDARIO_0010_MAX_BUCHI_LIBERI_DATA

Quando si prenotano prestazioni multiple vengono poi visualizzate solo le date ed orari che hanno un numero di buchi liberi consecutivi >= al numero di prestazioni inserite nel carrello. Quando si prenota, si cancella una prenotazione o si spostano prenotati il sistema chiama il componente che rigenera il calendario “max buchi liberi” per la data. Non è possibile forzare prenotazioni su agende classificate “un posto prestazione” perché il sistema non riuscirebbe a trovare a quale fascia appartiene l’orario forzato.



Valorizzazione delle tariffe secondo il listino di riferimento

PRESTAZIONI SSN

1) Per le prestazioni prenotate → listino presente nel sistema al momento del contatto valido alla data di prenotazione (da modificare la funzione di prenotazione) Es. 15/01/2006 (data di contatto) sto prenotando per il 20/06/2006 (data di prenotazione) listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € la tariffa sarà quella del listino presente nel sistema al 15/01/2006 e valido al 20/06/2006, quindi 100 € viene registrata la prenotazione num. 1234567 con tariffa 100 € 2) Per le prestazioni prenotate: al momento della contabilizzazione → listino presente nel sistema al momento del contatto/contabilizzazione valido alla data di prenotazione (aggiornamento della tariffa) Es. 25/06/2006 (data di contatto) sto contabilizzando la prenotazione num. 1234567 del 20/06/2006 (data di prenotazione) listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € dal 01/06/2006 tariffa 120 € dal 22/06/2006 tariffa 150€ la tariffa sarà quella del listino presente nel sistema al 25/06/2006 e valido al 20/06/2006, quindi 120 € viene aggiornata la tariffa relativa alla prenotazione num. 1234567 3) Per le prestazioni non prenotate → listino valido alla data di contatto/contabilizzazione (come avviene attualmente) Es. 05/05/2006 (data di contatto) sto aggiungendo una prestazione listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € dal 01/06/2006 tariffa 120 € la tariffa della prestazione sarà quella del listino presente nel sistema e valido al 05/05/2006, quindi 100 € PRESTAZIONI NON SSN

Per le prestazioni prenotate listino valido alla data di prenotazione Es. 01/05/2006 (data di contatto) sto prenotando una prestazione per 05/05/2006 listino: dal 01/01/2006 tariffa 50 € dal 16/03/2006 tariffa 100 € dal 01/06/2006 tariffa 120 € la tariffa della prestazione sarà quella del listino presente nel sistema e valido al 05/05/2006, quindi 100 € In fase di contabilizzazione non viene rivalutato Per le prestazioni non prenotate listino valido alla data di associazione della prestazione al documento .



Generazione notturna dei calendari delle agende per codice di priorita’

Ogni notte viene eseguito un programma batch di elaborazione utile per ricalcolare il numero di posti liberi, prenotati e jolly per codice priorità secondo le percentuali definite a livello di agenda.

Il programma che calcola la sintesi del giorno ragiona nel seguente modo:

1) cancella da workCalendario_sintesi la riga relativa all’agenda in esame relativa alla data in esame

2) inserisce in workCalendario_sintesi la data in esame ed i valori calcolati relativi a numPrevisti_tot, numForzati_FO_colore1 , numForzati_FO_colore2 , numForzati_FO_colore3, numPrevisti_colore1, numPrevisti_colore2, numPrevisti_colore3, numPrenotati_tot, numPrenotati_colore1, numPrenotati_colore2, numPrenotati_colore3, numLiberi_tot, numLiberi_colore1, numLiberi_colore2, numLiberi_colore3, numLiberi_jolly

Fusione manuale assistiti

Utilizzare la Storede procedure P_Anagrafe_008_FusioneManuale_cursore che fonde (un record alla volta) gli assisti presenti nella tabella (xAnagrafeBase_FusioneManuale). I record elaborati vengono classificati fusi (FLG_FUSO=1).



Ricerca attività assistito nei database Storici

Per la ricerca d’informazioni dell’attività registrata per un assistito negli archivi storici eseguire la storede procedure che estrae per assistito (nei vari archivi storici) le seguenti informazioni:

• Progressivo: progressivo di registrazione della prestazione

• dataOraRichiesta: data contatto

• regimeErogazione: codice regime erogazione

• idAgenda

• idPrestazione

• prestazione_dsc

• idPrenotazione

• PrenotazioneData

• quantita,

• flgAccessoConfermato: 1 se accesso confermato;altrimenti =0

• idDocumentoLogico

• AccettazioneData : data erogazione

• doc_importo_accertato,

• doc_importo_pagato

• idassistito

• DB: descizione db storico dove è stata trovata l’informazione

• DOC_DSC: descizione del documento

• Esenzione_OLD_DOC_DSC :descrizione esenzione documento valorizzata nei documenti precedenti all’indicazione dell’esenzione sulla prestazione

• Esenzione_OLD_DOC_Esenticket

• Agenda_Struttura_DSC

• Esenzione_DOC_DSC

• Esenzione_DOC_COD

• Esenzione_Prestazione_DSC

• Esenzione_Prestazione_COD

Passi da eseguire per ricercare nello storico:

• Dal db syspreststorico_v4 aprire la storede procedure tmp_ricerca_attivita; copiare il codice SQL

• Aprire SQL query analyzer dal db syspreststorico_v4, incollare il codice SQL precedentemente copiato, nella condizione where cambiare il codice dell’assistito; ed eseguire le istruzioni sql per singola insert/delete (in quanto non si può eseguire tutto in unica volta in quanto l’esecuzione va in time-out

• I dati estratti si trovano nella tabella tmp_ricerca_attivita_assistito

• Esportare con SQL server i dati della vista V_ricerca_attivita_assistito_OUTPUT nel formato Excel (tasto destro sul nome del db “all task” – “Export data” (seguire poi passo per passo il wizard)



Filtri USL-Regione di residenza assistiti applicati in fase di prenotazione

L’usl (comune e regione) dell’assistito sono rilevati dalla posizione anagrafica dell’assistito.

Codice filtro Filtro Descrizione

1 Residenti in ASL Toscana Nord Ovest o in ASL Toscana Sud Est

2 Residenti fuori toscana o residenti in ASL Toscana Centro

3 TUTTI

4 Solo residenti ASL 111

5 Residenti fuori toscana

6 Residenti in Toscana

7 Residenti in ASL Toscana Centro

Funzione [dbo].[fn_Assistito_FiltroResidenza] (@Assistito_CodRegione varchar(3),@Assistito_CodUsl varchar(3),@Assistito_ComuneRes_FlgPropriaComp int) INSERT @TipiFiltriAssistitoResidenza SELECT 3 IF @Assistito_CodRegione='090' BEGIN INSERT @TipiFiltriAssistitoResidenza SELECT 6

IF @Assistito_ComuneRes_FlgPropriaComp=1 ‘ =1 se il comune di residenza dell’assistito è di propria competenza dell’ASL

BEGIN INSERT @TipiFiltriAssistitoResidenza SELECT 4 END IF @Assistito_CodUsl = "110" OR

@Assistito_CodUsl = "103" OR @Assistito_CodUsl = "104" OR @Assistito_CodUsl = "111" OR @Assistito_CodUsl = "201"

BEGIN INSERT @TipiFiltriAssistitoResidenza SELECT 2 INSERT @TipiFiltriAssistitoResidenza SELECT 7 END

IF @Assistito_CodUsl <> "110" AND @Assistito_CodUsl <> "103" AND @Assistito_CodUsl <> "104" AND @Assistito_CodUsl <> "111" and @Assistito_CodUsl <> "201"

BEGIN INSERT @TipiFiltriAssistitoResidenza SELECT 1 END END ELSE BEGIN INSERT @TipiFiltriAssistitoResidenza SELECT 2 INSERT @TipiFiltriAssistitoResidenza SELECT 5 END

Esempio per l’assistito con @Assistito_CodRegione='090' e @Assistito_CodUsl=’111’ saranno visibile le agende con associato il filtro: 3, 6, 4, 2, 7



PROCESSI SQL

SysPrest 01 - Mail attività processi -

Il processo invia un’e-mail (oggetto email "SysPrest Azienda Ospedaliera Empoli - Attività processi elaborativi del <<data_odierna>> ) agli operatori abilitati (feedback 5) per questa tipologia di feedback (Processo SQL: << SysPrest 01 - Mail attività processi - >> e-mail di comunicazione esito processi) con l’elenco dei processi elaborativi notturni raggrupati per esito elaborazione. Ognuno dei processi elaborativi hanno come passaggio iniziale la cancellazione per proprio codice processo e l’inserimento di una riga nella tabella di log delle elaborazioni. In caso di errore la riga viene classificata con esito negativo, altrimenti come finita correttamente. Il primo passaggio:

- prende l’elenco delle mail degli operatori abilitati per questo feedback (codice 5) - prende i parametri di invio dalla tabella Sito_008_Ambiente e spedisce le mail leggendo dalla tabella di

log di esecuzione dei processi; Esempio E-mail

NB: In quanto l’editor di codice script ActiveX di SQL Management Studio 2005 e di SQL Enterprise Manager 2000

hanno limitazioni sulla lunghezza del codice, questo processo usa una modalità di riferimento sul file system. In pratica il codice presente nel editor include codice presente in file sul file system nel percorso Sysprest \ Elaborazioni \ ScriptProcessiSQL\ SysPrest 01 - Mail attività processi - Email.vbs



SysPrest 02 - Notifica disponibilità agende non colore -

Il processo invia un’e-mail (oggetto email SysPrest: TIPOLOGIE DI PRESTAZIONI NON COLORE CHE NON SODDISFANO IL NUMERO MINIMI DI ACCESSI ) agli operatori abilitati (feedback 1) per questa tipologia di feedback (controllo disponibilità non colore) che contengono l’elenco delle disciplina- tipologie di prestazioni che non soddisfano il numero di accessi minimi previsti per le agende di tipo “non colore”. Il primo passaggio:

- lancia la stored procedure p_email_040_agende_buchi_min_non_colore che elabora i per la tabella PRENOT_0230_EMAIL_RPT_NO_COLORE (per ulteriori dettagli consultare il paragrafo Database) sulla quale lavora il secondo passaggio.

Il secondo passaggio:

- lancia la stored procedure p_email_041_agende_buchi_min_non_colore_testo che restituisce i dati necessari per la composizione del testo delle mail da inviare

- prende l’elenco delle mail degli operatori abilitati per questo feedback (codice 1) - prende i parametri di invio dalla tabella Sito_008_Ambiente e spedisce le mail

i dati nell’email sono ordinati per per codice disciplina, codice tipologia e codice agenda.

L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -).


hanno limitazioni sulla lunghezza del codice, questo processo usa una modalità di riferimento sul file system. In pratica il codice presente nel editor include codice presente in file sul file system nel percorso Sysprest \ Elaborazioni \ ScriptProcessiSQL\ SysPrest 02 - Notifica disponibilità agende non colore - Email.vbs

SysPrest 04 - Preparazione dati OLAP Offerta disponibilità -

E’ un processo SQL Server che è schedulato periodicamente come descritto nel punto ”processi schedulati”.

Questa elaborazione notturna alimenta, con i dati necessari per l’analisi dell’offerta di prestazioni, alcune tabella del database SysPrest (per il dettaglio delle tabella vedi punto database SysPrestv3_empoli ) :

➢ Elab_100_Offerta (tabella storica) ➢ Elab_110_Offerta_Appoggio (tabella utile a preparare i dati da inserire nella tabella storica) ➢ Elab_120_Offerta_Appoggio_ragrupp (tabella utile a preparare i dati che alimentano la tabella storica)

Le tabelle verranno inizializzate con i dati dal 01/01/2006 alla data odierna.

L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -). Le stored procedure utilizzate sono le seguenti:

➢ p_Elab_020_offerta_workCalendario ➢ p_Elab_025_offerta_workCalendario_storico ➢ p_Elab_030_offerta_Appoggio ➢ p_Elab_035_offerta_Appoggio_ragrupp ➢ p_Elab_036_offerta_up_ds ➢ p_Elab_037_offerta_data_ins

L’elaborazione eseguirà le seguenti operazioni:

➢ Cancella il contenuto di: Elab_110_Offerta_Appoggio, Elab_120_Offerta_Appoggio_ragrupp ➢ Cancellerà da Elab_100_Offerta tutti i record con data Prenotazione >= data elaborazione ➢ Verranno inseriti nella tabella Elab_110_Offerta_Appoggio tutti i record (con data prenotazione >= data

elaborazione) provenienti dalla tabella workCalendario (di tipo “a” e “b”) ➢ I dati contenuti nella tabella Elab_110_Offerta_Appoggio verranno raggruppati e inseriti nella tabella

Elab_120_Offerta_Appoggio_ragrupp

➢ I dati contenuti nella tabella Elab_120_Offerta_Appoggio_ragrupp verranno formattati e inseriti nella

tabella storica azione >= data odierna ➢ Aggiornamento delle descrizioni sull’intera tabella dell’offerta: agenda, struttura, tipologia, disciplina,

specialità, unità operativa, regime



I dati così ottenuti provengono dal calendario (orari che hanno una programmazione valida) e non dalla programmazione dell’agenda, per tener conto delle eventuali sospensioni di date o di singoli orari. Nota sulla valorizzazione del campo “freqGiorno”:

Sugli orari delle agende se sono presenti frequenze diverse per la stessa agenda, stesso giorno, stessa fascia oraria il sistema non è ingrado di trovare la programmazione che ha generato la data di prenotazione. La frequenza viene aggiornata con il MAX(freqGiorno). ESEMPIO:

idAgenda dataInizio dataFine giornoSettimana oraInizio oraFine freqGiorno descrFrequenza

1665 08/12/2009 03/01/2010 1 870 1110 1 ogni primo del mese

1665 08/12/2009 03/01/2010 1 870 1110 3 ogni terzo del mese

In questo caso, non sapendo a quale frequenza attribuire i buchi di quella apertura, è stata considerata la MAX, quindi 3.

SysPrest 05 - Prepara prenotazioni CUP Online -

Il processo svuota e poi popola la tabella SITO_P_080_PRESTAZIONI con le prenotazioni da visualizzare da CUP

online. Il primo passaggio:

- lancia la stored procedure SP_SITO_P_0200_PREST_PROCESSO_SQL che inserisce le prenotazionii nella tabella SITO_P_080_PRESTAZIONI


SysPrest 06 - Erogazione automatica prestazioni ALP/Area Pagamento -

Processo SQL (schedulato ogni notte) per l’erogazione automatica delle prestazioni effettuate in regime indicato nella tabella ELAB_195_EROG_AUTO_AMBIENTE.

Le prestazioni verranno erogate se il documento contabili a cui sono associate è stato completamente pagato ( importo accertato = importo pagato).

Il processo eroga le prestazioni (non erogate che appartengono ad agende non integrazione) collegate ai documenti contabili (completamente pagati) incassati in un determinato giorno (movimento di cassa di tipo “entrata” con data registrazione movimento <= schedulazione elaborazione – 7 gg AND data registrazione movimento >= ELAB_195_EROG_AUTO_AMBIENTE.Data_inizio (relativa al regime)).

Per le prestazioni prenotate la data-ora di erogazione sarà uguale alla data-ora di prenotazione. Mentre per le prestazioni in accesso diretto la data–ora di erogazione verrà impostata con la data ora del collegamento della prestazione al documento (data richiesta). L’operatore che ha registrato l’accesso risulterà l’operatore che ha inserito il documento,

Non vengono erogate prestazioni con data-ora di erogazione successiva alla data odierna.

Il medico erogatore sarà valorizzato con il medico proprietario dell’agenda se presente altrimenti il dato non sarà valorizzato.

Terminata l’elaborazione il sistema memorizzerà quali prestazioni ha erogato (nella tabella ELAB_200_EROG_AUTO).

Il processo eseguirà i seguenti step:

• inizialmente estrarrà tutte le prestazioni con accesso non indicato collegate a documenti contabili di regime ALP e Area a Pagamento con importo pagato = importo accertato con data



creazione documento >= ELAB_195_EROG_AUTO_AMBIENTE.Data_inizio (relativa al regime)

• per i documenti estratti verifica se hanno un movimento di cassa di tipo “entrata” con data registrazione <= schedulazione elaborazione – 7 gg AND data registrazione movimento >= ELAB_195_EROG_AUTO_AMBIENTE.Data_inizio (relativa al regime)

• cancellazione dei documenti che non hanno il movimento di cassa

• erogazione delle prestazioni e memorizzazione nella ELAB_200_EROGATO_ALP dei progressivi di prestazioni che l’elaborazione ha erogato


SysPrest 07 - Preparazione dati OLAP Attività -

Il processo SQL notturno che memorizza in nella tabella “Elab_010_attivita“ le prestazioni registrate.

Inizialmente la tabella è stata inizializzata con le tutte le prestazione presenti in archivio alla data d’installazione 01-07-2008.

L’elaborazione notturna analizza le prestazioni non prenotate con data registrazione (data richiesta) >= 01/ Mese(data odierna – 6 mesi)/Anno(data odierna – 6 mesi) e le prestazioni prenotate con data prenotazione >= 01/ Mese(data odierna – 6 mesi)/Anno(data odierna – 6 mesi).

Esempio data elaborazione

Data odierna Data inzio elaborazione

10-03-2008 01-10-2007

30-05-2008 01-12-2007

10-06-2008 01-01-2008

L’elaborazione esegue i seguenti step:

1. in un tabella di appoggio (Elab_020_attivita_tmp) scaricherà le prestazioni da elaborare

2. aggiornamento dei vari campi (accesso, assistito, documento, prestazione, ecc..)

3. cancellazione dalla tabella Elab_010_attivita tutti i “progressivi” di prestazioni modificati (progressivi presenti nella tabella di appoggio)

4. Nella tabella dell’attività vengono cancellati le prestazioni non prenotate con data registrazione (data richiesta) >=data odierna – 6 mesi e le prestazioni prenotate attive con data prenotazione >= data odierna – 6 mesi

5. memorizzazione nella tabella Elab_010_attivita i dati presenti nella tabella di appoggio

Nota: le tabelle sono descritte nella sezione “definizione database”


SysPrest 08 - Schedulazione elaborazione Flussi SPA (SOSPESO)-

Il processo schedula l’elaborazione “Flussi SPA tracciato 2008” il 25 di ogni mese (con periodo=mese corrente) e schedula il giorno 1 del mese una elaborazione di tipo “definitiva” del mese precedente alla data corrente. Il processo schedula l’elaborazione della bozza se nella tabella Elab_003_CodiciElaborazioni il campo FLG_ELAB_SCHEDULATA_BOZZA_ATTIVA=1; il processo schedula l’elaborazione definitiva se nella tabella Elab_003_CodiciElaborazioni il campo FLG_ELAB_SCHEDULATA_ DEFINITIVA_ATTIVA =1



L’elaborazioni sono schedulate con modalità “Classificazione delle prestazioni registrata in fase di contabilizzazione”. Se il periodo corrente non corrisponde con il periodo da elaborare calcolato dal sistema (utimo periodo elaborato in modalita definitivo + 1), il processo non schedula l’elaborazione. L’elaborazioni schedulate automaticamente vengono memorizzate nella tabella FLUSSI_SPA_V2_0006_ELAB_SCHEDULATE.




SysPrest 09 - Storicizzazione log: prenotazioni, integrazione, ricettario, Iris


Prenotazioni Il processo ogni notte trasferisce i dati del LOG delle prenotazioni dalle tabelle PRENOT_LOG_001_testata e PRENOT_LOG_005_PRESTAZIONI alle tabelle dello storico PRENOT_LOG_020_testata_STORICO e PRENOT_LOG_025_prestazioni_STORICO. Integrazione Prenotato/contabilizzato (richieste) Il processo trasferisce nello storico i dati dalle tabelle INTEGRAZIONE_0020_C_RICHIESTE, INTEGRAZIONE_0025_C_RICHIESTE_PREST alle tabelle INTEGRAZIONE_0030_C_RICHIESTE_STORICO, INTEGRAZIONE_0035_C_RICHIESTE_PREST_STORICO. Nella coda corrente rimangono messaggi elaborati con errore che non sono stati verificati. Nello storico vengono spostati i messaggi:

• Elaborati senza errore (Integrazione_DataOraProcessato IS NOT NULL and Integrazione_TipoEsito=1)

• Elaborati con errore ma verificati da utente o rielaborati (Integrazione_DataOraProcessato IS NOT NULL and Integrazione_TipoEsito <>0 and Integrazione_Stato_Verifica_Errore_ID<> NULL)

Integrazione Erogato Il processo trasferisce nello storico i dati dalla tabella INTEGRAZIONE_1010_S_EROGATO alla tabella INTEGRAZIONE_1020_S_EROGATO_STORICO (database SysPrestV3_Empoli_INTEGRAZIONI). Nella coda corrente rimangono messaggi elaborati con errore che non sono stati verificati.

Il sistema per classificare in modo automatico come messaggio con errore "verificato" (Integrazione_StatoVerificaErrore_ID=12 --Errore gestito da sistema - messaggio non elaborato) i messaggi ricevuti con i seguenti codici di errore di tipo “controllo formale” :

• cod. 999992 “Progressivo di una prenotazione non corretto”

• cod. 999988 “Prestazione di ulteriore sostituzione su prestazione precedentemente ricevuta”

• cod. 998888 “Prestazione erogata e gia inviata a Conticki”

• cod. 999999 " Messaggio di cancellazione accesso su prestazione non erogata su SysPrest"

Nello storico vengono spostati i messaggi

• elaborati senza errore (Elab_DataOra is not NULL AND Elab_Errore_COD is null)

• Elaborati con errore ma verificati da utente (Elab_DataOra IS NOT NULL and Elab_Errore_COD IS NOT NULL and Integrazione_Stato_Verifica_Errore_ID<> NULL)

Integrazioni tabelle di sessione Il processo tronca la tabella INTEGRAZIONE_0002_SESSIONE_LOG_IN. Integrazione ricettari Il processo trasferisce nello storico anche i dati dell’integrazione riccetari dalla tabella RICETTARIO_100_LOG alla tabella RICETTARIO_110_LOG_STORICO. Integrazione IRIS ricezione pagamento Il processo trasferisce nello storico i dati dell’integrazione IRIS per il pagamento dalle rabelle [IRIS_Pagamento_001_notifica] e [IRIS_Pagamento_002_notifica_DettImportoTransato] alle tabelle [IRIS_Pagamento_030_notifica_STORICO] e [IRIS_Pagamento_040_notifica_DettImportoTransato_STORICO]. Nelle tabelle di storico vengo spostati i messaggi elaborati corretamete (ELAB_dataOra IS NOT NULL AND ELAB_errore_DSC IS NULL) e i messaggi con errore classificati verificati (Integrazione_StatoVerificaErrore_ID is not null and ELAB_dataOra IS NOT NULL AND ELAB_errore_DSC IS not NULL) Esegue storede procedure SysPrestV3_Empoli_INTEGRAZIONI.[Iris].[p0003_Pagamenti_LOG_STORICO] Integrazione IRIS pendenze Il processo trasferisce nello storico i dati dell’integrazione IRIS per le pendenze dalle tabelle:

• Da IRIS_Pendenze_001_Documento] A [IRIS_Pendenze_050_Documento_STORICO]



• Da [IRIS_Pendenze_002_Documento_DettaglioImporto] A[IRIS_Pendenze_052_Documento_DettaglioImporto_STORICO]

• Da [IRIS_Pendenze_003_Prestazioni] A [IRIS_Pendenze_053_Prestazioni_STORICO]

• Da [IRIS_Pendenze_004_Prestazioni_Ripartizioni] A [IRIS_Pendenze_054_Prestazioni_Ripartizioni_STORICO] Nelle tabelle di storico vengo spostati i messaggi elaborati corretamete (ELAB_Data IS NOT NULL AND ELAB_IRIS_stato = ELABORATO_CORRETTAMENTE AND ELAB_IRIS_DataOra IS NOT NULL) e i messaggi classificati verificati (Integrazione_StatoVerificaErrore_ID is not null) Esegue storede procedure SysPrestV3_Empoli_INTEGRAZIONI. [Iris].[p0004_Pendenze_LOG_STORICO]

SysPrest 10 - Notifica disponibilità agende colore -

Il processo sql invia un‘email (oggetto dell’email “SysPrest: TIPOLOGIE-DISCIPLINE DI PESTAZIONI CHE NON

SODDISFANO IL NUMERO DI ACCESSI”), agli operatori abilitati (al feedback 2), con l’elenco delle tipologie-discipline di prestazioni che non soddisfano il numero di accessi minimi disponibili previsti per fascia di priorità “B - breve” e “D - differita” per prenotazione. L’esito del processo viene notificato anche nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -). L’elaborazione considera solo le agende dove sono presenti entrambe le classificazioni. Per le tipologie-discipline che non hanno l’indicazione dei buchi minimi non saranno riportate comunque nell’e-mail. Dalla funzione “specialità e tipologia” è possibile associare alla tipologia le discipline (dati memorizzati nella tabella PRENOT_CC_0090_TIPLOGIA_DISCIPLINA). Esempio: tipologia disciplina Num. accessi disponibili

minimi B Num. accessi disponibili minimi D

HM 001 80 20

C1 003 50 80

K2 031 20 20

C3 099 30 30

C3 088 20 15

L’elaborazione esaminerà le agende di tipo “colore“ e aperte. Agenda Accessi

disponibili fascia B

Accessi disponibili fascia D

Tipologia disciplina

Agenda n.10 50 30 HM 001

Agenda n.20 60 10 C1 003

Agenda n.22 30 60 C1 003

Agenda n.33 30 18 K2 031

Agenda n.44 25 10 C3 099

Agenda n.88 4 6 C3 088

Agenda n.88 15 10 C3 088

tipologia disciplina Num. accessi

disponibili B Num. accessi disponibili D

Num. accessi disponibili B non soddisfano il numero di accessi minimi B

Num. accessi disponibili D non soddisfano il numero di accessi minimi D

HM 001 50 30 SI (50 > 80 → no) NO

C1 003 90 (60 + 30 ) 70 (10 + 60) NO SI (70 > 80 → no)

K2 031 30 18 NO NO

C3 099 25 10 SI (25 > 30 → no) SI (10 > 30 → no)

C3 088 19 (4 + 15) 16 (10 + 6) SI (19 > 20 → no) NO



Nell’e-mail avremmo: HM - angiografia 001 - Allergologia

Accessi disponibili fascia B = 50

Agenda num.10

C1 - interventi di proctologia 003 - Anatomia ed istologia patologica

Accessi disponibili fascia D = 70

Agenda num.20

Agenda num.22

C3 - biopsia tc guidata 099 - xxxx

Accessi disponibili fascia B = 25 Accessi disponibili fascia D = 10

Agenda num.44

C3 - biopsia tc guidata 088 - yyyy

Accessi disponibili fascia B = 19

Agenda num.88

L’elenco delle tipologie-discipline delle prestazioni sarà ordinato per codice tipologia e per codice disciplina.

L’elaborazione inoltre prepara i dati (memorizzati nella tabella PRENOT_CC_0210_EMAIL_RPT) per il report num. 302 “Report sul superamento di buchi minimi per le fasce di priorità B e D”.

SysPrest 11 - Notifica agende senza disponibilità -

Il processo elabora tutte le agende che hanno calendario (di qualsiasi tipo) e classifica l’agenda full se nessuna data di prenotazione (> della data odierna) ha disponibilità. invio email (con oggetto “SysPrest: agende prenotabili full” ad operatori abilitati (feedback 3) ) con elenco delle agende che non hanno giorni più disponibili alla prenotazione.


SysPrest 12 - Schedulazione report TAT -

Il processo che schedula in automatico ogni 15 del mese o fine mese l’elaborazione dei report num. 321 (uguale al report num.277) “Tempi di Attesa prestazioni monitoraggio -prima disponibilità per prestazione”, il num. 322 “Tempi di Attesa prestazioni monitoraggio - agende colore (uguale al report num.278), il num. 329 “TAT prestazioni monitoraggio - agende colore - prima disponibilità per prestazione” (uguale al report num. 313) e il num. 334 “Tempi di Attesa prestazioni monitoraggio” (uguale al report num. 186). L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -).

SysPrest 13 - Autocontabilizza (sospeso) - (SOSPESO)

Questa elaborazione non aggiorna più la branca dei documenti logici contabilizzati automaticamente dal sistema ma invia la mail con l’esito del processo.

E’ un processo SQL, che chiama una stored procedure, in un orario notturno. Le stored procedure interessate sono:

• p_Elab_040_autocontabilizza_ins

Mentre, le tabelle interessate sono (le tabelle di appoggio vengono ripulite ad ogni avvio dell’elaborazione interessata):

• Elab_152_AutoContabilizza_appo (appoggio): elenco di documenti logici che durante il giorno sono stati contabilizzati automaticamente dal sistema



• Elab_154_AutoContabilizza_prest (appoggio): elenco delle prestazioni collegate ai documenti logici autocontabilizzati

Al termine dell’esecuzione verrà spedita una e-mail agli indirizzi presenti nella tabella dbo.Elab_140_Offerta, con l’esito del processo.

Il processo è stato sospeso il 29/04/2008.

SysPrest 14 - Notifica prenotazione spostate -

Il processo SQL ogni ora invia un e-mail a determinati utenti abilitati abilitati al feedback 4

con l’elenco delle prenotazioni spostate utilizzando la funzione “sposta prenotati” non ancora comunicate (PRENOT_LOG_001_testata.OPERAZIONE_TIPO_ID =29 OR =30 =31 AND FLG_INVIATO_EMAIL=0). Esempio e-mail: Oggetto “SysPrest: avviso - sposta prenotati” Testo Sono state spostate le seguenti prenotazioni dalla struttura xxxxxxxx

Agenda num. xxx - xxxxxxx

Prenotazione num. xxxxx data-ora operazione gg/mm/aaaa alle hh.mm utente xxxxx Prenotazione num. xxxx1 data-ora operazione gg/mm/aaaa alle hh.mm utente xxxxx

Agenda num. xx1 - xxxxxxx

Prenotazione num. xxxx2 data-ora operazione gg/mm/aaaa alle hh.mm utente yyyy

Sono state spostate le seguenti prenotazioni dalla struttura yyyyyy Agenda num. yy2 - xxxxxxx

Prenotazione num. xxxx8 data-ora operazione gg/mm/aaaa alle hh.mm utente xxxxc Prenotazione num. xxxx7 data-ora operazione gg/mm/aaaa alle hh.mm utente xxxxl Prenotazione num. xxxx6 data-ora operazione gg/mm/aaaa alle hh.mm utente yyyyp

La lista è raggruppata per struttura, agenda e ordinata per descrizione struttura, codice agenda, data prenotazione e codice prenotazione. Nota. le informazioni di dettaglio dello spostamento è possibile visualizzarle utilizzando la funzione “ricerca prenotazione”.


hanno limitazioni sulla lunghezza del codice, questo processo usa una modalità di riferimento sul file system. In pratica il codice presente nel editor include codice presente in file sul file system nel percorso Sysprest \ Elaborazioni \ ScriptProcessiSQL\ SysPrest 14 - Notifica prenotazioni spostate - Email.vbs

SysPrest 15 - Calendario - Pulizia Tab - Storicizzazione log anagrafe


p_Elab_040_autocontabilizza_ins Cancello contenuto tabelle: Elab_152_AutoContabilizza_appo, Elab_154_AutoContabilizza_prest

Inserisco tutti i documenti logici auto contabilizzati il giorno precedente nella tabella Elab_152_AutoContabilizza_appo

Inserisco tutte le prestazioni collegate ai documenti logici auto contabilizzati nella tabella Elab_154_AutoContabilizza_prest



Integrazione Angrafe Client Storede procedure SysPrestV3_Empoli_INTEGRAZIONI.Anagrafe_010_LOG_STORICO Il processo di storicizzazione dei messaggi lascia in coda corrente i messaggi elaborati con errore che non sono stati verificati Integrazione client - nello storico vengono spostati i messaggi:

• Elaborati senza errore (Integrazione_DataOraProcessato IS NOT NULL and Integrazione_Errore is null)

• Elaborati con errore ma verificati da utente (Integrazione_DataOraProcessato IS NOT NULL and Integrazione_Errore is NOT NULL and Integrazione_Stato_Verifica_Errore_ID<>NULL)

Integrazione Anagrafe server Storede procedure SysPrestV3_Empoli_INTEGRAZIONI.Anagrafe_010_LOG_STORICO Il processo di storicizzazione dei messaggi lascia in coda corrente i messaggi elaborati con errore che non sono stati verificati Nello storico vengono spostati i messaggi:

• elaborati senza errore (Elab_DataOra is not NULL AND Elab_Errore_COD is null)

• Elaborati con errore ma verificati da utente (Elab_DataOra IS NOT NULL and len( Elab_Errore_COD)>0 and Integrazione_Stato_Verifica_Errore_ID<> NULL)



SysPrest 16 - Log allineamento anagrafe CRM – esenzioni assistito

L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -). Il processo aggiorna il campo:

• dbo.xAnagraficaBase.FLG_ANAG_ESENTE_TOT

• dbo.xAnagraficaBase.FLG_DOC_DA_PAGARE → =1 se per l’assistito esiste un documento con data creazione >=01/01/2009 con “importo pagato” <> da “importo accertato”

SysPrest 17 - CUP AV Workslot -


SysPrest 21 – Schedulatore Integrazione Anagrafica

Lo schedulatore chiama 3 volte ogni 12 secondi la stored di elaborazione dei dati ricevuti da integrazione. In caso di errore ogni passo chiama la stored procedure di scrittura errori.

SysPrest 22 - Notifica assistiti con lo stesso codice aziendale ed errori

Il processo segnala gli assistiti con stesso codice aziendale ed i record di integrazione elaborati con errore. La mail viene inviata agli operatori abilitati al feedback 6. L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -).

SysPrest 23 - Notifica prenotazioni registrate non corretamente – Ricevute di cassa Doppie

Il processo comunica le prenotazioni registrate non correttamente

• prenotazioni attive con data >=della data odierna che non hanno rifermenti nel calendario

• prenotazioni attive con data >=della data odierna che non hanno prestazioni.

• Prenotazioni con calendario ma che non sono più in testata prenotazioni

• Prenotazioni su un agende un posto prestazione che il numero di buchi occupati non coincide con il numero di prestazioni

Il processo inoltre comunica le ricevute di cassa doppie (controlla le ricevute con anno > 2015 sui campi: anno, progressivoAnno,PrefissoRicevuta). La mail viene inviata agli operatori abilitati al feedback 7. L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -).

SysPrest 24 - Schedulatore Integrazione Erogato

Lo schedulatore chiama 10 volte al minuto la stored di elaborazione dei messaggi ricevuti dall’integrazione (P_INTEGRAZIONE_S_1050_ELAB_INS). In caso di errore ogni passo chiama la stored procedure di scrittura errori.

SysPrest 25 - Disattivazione utenti non collegati al sistema da x giorni

Il processo passa ogni notte e disattiva gli utenti che non hanno utilizzato il sistema per x giorni.



invio email (con oggetto “SysPrest 25 - Notifica utenti disattivati” ad operatori abilitati (feedback 8) ) con elenco utenti che sono stati disattivati.


SysPrest 26 - Integrazione - Erogato con errore

Il processo passa ogni 2 ore ed invia una mail per notificare i messaggi di erogato con errore. Invio email (con oggetto “SysPrest 26 – Integrazione – Erogato con errore” ad operatori abilitati (feedback 9) ) con elenco messaggi di erogato elaborati con errore e non verificati. Il processo inoltre classifica come verificati ( Integrazione_StatoVerificaErrore_ID=11 ‘Errore gestito da sistema - Cod.999888 Progressivo non valorizzato (da non gestire)’) i messaggi con codice di errore di elaborazione “999888” “Progressivo di una prenotazione non valorizzato” (in quanto ssono le prestazioni aggiuntiche che da Galileo sono ancora possibili).


SysPrest 27 – Integrazione medici

Il processo è schedulato ogni notte (dopo l’esecuzione dell’allineamento nel database AnagrafeASL) che legge dalla tabella medici del database AnagrafeASL e aggiorna/inserisce sulla tabella tblMedici di SysPrest. Il processo aggiorna i dati (cognome, nome, CodMedicoRegionale, DataCesazioneMedico, regioneResidenza, indirizzo, COD_universale, Data_Ora_Ultima_UPD= GETDATE(), data_inizio_validita, IdTipoMedico, tipo medico) per i medici/professione sanitaria già presenti in archvio (con idendificativo codice Fiscale, regione, usl, IdTipologiaMedico) e inserirà le nuove anagrafiche (con Medicina_gruppo_id=0 “non indicato”; IdZonaMedico=NULL; UNITA_OPERATIVA_ID=NULL, Data_Ora_Ultima_UPD= GETDATE()). Il processo inoltre alimenta la tabella tblMedici_CF (storede procedure p_Medici_110_Integrazione_CF) che contiene l’anagrafe dei medici con chiave il codice fiscale (il sistema individua dalla tabella tblmedici il codice massimo del medico con lo stesso codice fiscale). Al termine dell’elaborazione il processo notificherà, ad operatori abilitati al feedback 10:

- eventuali anagrafiche aggiornate ma con dati non corretti - anagrafiche medico attive su SysPrest ma non aggiornate da integrazione

Nota. Non viene mantenuta traccia (in tabelle di LOG) di tutte le variazioni avvenute in una posizione anagrafica del medico. Ma viene solo valorizzato il campo Data_Ora_Ultima_UPD indicando la data dell’ultima variazione avvenuta. L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -).



SysPrest 28 - Preparazione dati OLAP pubblicazione prestazioni

Il processo è schedulato ogni notte Il processo alimenta le seguenti tabella (nel database SysPrestV3_EMPOLI_DW):

• FACT_PREST (che contiene le prestazioni erogate dall’azienda con la definizione degli orari dell’ambulatorio) Saranno estratte tutte le agende attive che hanno almeno una apertura valida alla data odierna. Vengono riportate tutte le aperture valide dalla data odierna in poi.

• FACT_PREST_LISTINO_RIPARTIZIONI (che contiene le ripartizioni della tariffa di prestazioni erogate nel regime ALP e Area a Pagamento)

Ad ogni elaborazione le tabelle sono troncate.


SysPrest 29 - Integrazione - Inizializza coda prenotazione

Il processo è schedulato ogni 2 ore

il processo per permettere di “rinviare” o “inizializzazione code” delle prenotazioni (con data prenotazione > della data

odierna) di tutte le agende indicate nella tabella INTEGRAZIONE_0025_PRENOT_AGENDE_DA_INVIARE (alimenta tabelle INTEGRAZIONE_0020_C_RICHIESTE e INTEGRAZIONE_0025_C_RICHIESTE_PREST) In una tabella di storico (INTEGRAZIONE_0026_PRENOT_AGENDE_DA_INVIARE_LOG) viene mantenuta traccia delle agende elaborate. Al termine della elaborazione (andata a buon fine) la tabella INTEGRAZIONE_0025_PRENOT_AGENDE_DA_INVIARE verrà pulita delle agende elaborate e verrà inviata un e-mail di notifica delle agende elaborate ad operatori abilitati a ricevere tale e-mail (feedback num. 11)

Per le agende con TIPO_OPERAZIONE_ID =1 viene aggiornato il codice applicativo integrazione e l’unità organizzativa che era stati indicati all’agenda relativa. Mentre con TIPO_OPERAZIONE_ID =2 non viene aggiornata

nessuna informazione sull’anagrafica agenda relativa.

SysPrest 30 - Notifica prestazioni senza disponibilita

Il processo elabora tutte le prestazioni collegate ad agende del SSN che hanno calendario (di qualsiasi tipo) e classifica l’agenda full se nessuna data di prenotazione (> della data odierna) ha disponibilità. invio email (con oggetto “SysPrest 30 - prestazioni senza disponibilita” ad operatori abilitati (feedback 12) ) con elenco delle prestazioni prenotabili che non hanno nessuna disponibilità a prenotare.

Nell’e-mail sono riportate solo le prestazioni (ordinate per descrizione) differenziate nella tipologia d’agenda (colore, non urgente, riservata, di reparto, attività aggiuntiva, urgente) che non hanno disponibilità in almeno una delle tipologie.

Esempio e-mail

Rx- mano cod.444 (nessuna disponibilità: colore, non urgente – disponibile riservata)

Rx- piede cod.333 (nessuna disponibilità: non colore- riservata)


SysPrest 31 - Integrazione anagrafe comuni - ASL – stati - Esenzioni

Il processo (schedulato ogni notte – dopo l’esecuzione dell’allineamento nel database AnagrafeASL) legge dalla tabella Comuni, ASL, Stati, Esenzioni del database AnagrafeASL e aggiorna/inserisce sulle rispettive tabelle di SysPrest.



Comuni (tabella tblComuni) :

• Il processo inserisce le nuove anagrafiche (con flg_comune_proprio=0; FLG_COMUNE_MULTI_ASL=0, Data_Ora_Ultima_UPD= GETDATE())

• Il processo aggiorna i dati (descrizione comune, Provincia, ASL, Codice fiscale, CAP, DATA_INIZIO_VALIDITA, DATA_FINE_VALIDITA, Data_Ora_Ultima_UPD= GETDATE()) per i comuni già presenti in archivio.

• I comuni presenti in SysPrest ma non presenti nelle tabelle dell’integrazione vengono chiusi (DATA_FINE_VALIDITA= 01/01/1800)

USL (tabella tblUsl) :

• Il processo inserisce le nuove anagrafiche (con propria=false; provincia=NULL; Data_Ora_Ultima_UPD= GETDATE())

• Il processo aggiorna i dati (descrizione, indirizzo, comune, DATA_INIZIO_VALIDITA, DATA_FINE_VALIDITA, Data_Ora_Ultima_UPD= GETDATE()) per le USL già presenti in archivio.

• Le ASL presenti in SysPrest ma non presenti nelle tabelle dell’integrazione vengono chiusie(DATA_FINE_VALIDITA= 01/01/1800)

Stati (tabella tblStati) :

• Il processo inserisce le nuove anagrafiche (Data_Ora_Ultima_UPD= GETDATE())

• Il processo aggiorna i dati (descrizione, codice stato europeo , DATA_INIZIO_VALIDITA, DATA_FINE_VALIDITA, Data_Ora_Ultima_UPD= GETDATE()) per gli stati già presenti in archivio.

• Gli stati presenti in SysPrest ma non presenti nelle tabelle dell’integrazione vengono chiusi (DATA_FINE_VALIDITA= 01/01/1800)

Esenzioni (tabella tblEsenzioni_codici) :

• Il processo inserisce le nuove anagrafiche (Data_Ora_Ultima_UPD= GETDATE())

• Il processo aggiorna i dati (ESENZIONE_DSC, DATA_FINE_VALIDITA, esentick, Data_Ora_Ultima_UPD= GETDATE()) per gli stati già presenti in archivio.

L’esito del processo sarà notificato nell’e-mail riepilogativa dei processi notturni. Nota. Non verrà mantenuta traccia (in tabelle di LOG) di tutte le variazioni avvenute in una posizione anagrafica di comune, ASL, stato e esenzioni. Ma verrà solo valorizzato il campo Data_Ora_Ultima_UPD indicando la data dell’ultima variazione avvenuta.

SysPrest 32 - Integrazione anagrafe - Rischedulazione

Il processo (schedulato ogni ora) classifica da rielaborare i messaggi anagrafici arrivati (lato server) che hanno avuto l’errore Elab_Errore_COD = '9999' (errore di schedulatore)



SysPrest 33 – Notifica controllo offerta

Il processo (schedulato ogni giorno) notificha ad operatori abilitati le agende che soddisfano i criteri di controllo dell’offerta. Il processo per tutte le agende, con calendario con data >= della data odierna individua:

• il “numero di buchi offerti”

• il “numero di buchi prenotati”

• la “percentuale di saturazione” (numero di buchi prenotati/numero di buchi offerti)*100 → se numero di buchi offerti=0 la percentuale di saturazione è =0

• la “disponibilità residua” (numero di buchi offerti - numero di buchi prenotati)

• la “data massima di prenotazione”

• il “numero di prenotazioni” registrate con data prenotazione>= “data massima di prenotazione” - “X” giorni.

L’e-mail segnala le agende per le quali si verificha la seguente condizione:

“Numero di prenotazioni “>=1 AND (“percentuale di saturazione” < di “Y” OR “numero di buchi offerti” < “Z”).

“X”,” Y”, “Z” sono valori parametrizzati e valgano per tutta l'offerta (non differenziati per struttura, equipe, agenda, regime, etc...).

Nella funzione “ambiente” nel tab “Parametri controllo offerta” è possibile variare i parametri

Il corpo dell’e-mail contiene le seguenti informazioni: codice agenda - descrizione agenda (campo descrizione amministrazione) - disponibilità residua. L’elenco sarà ordinato per codice agenda.

Non viene mantenuta traccia delle elaborazioni precedenti, in archivio c’è solo l’ultima. Invio email (con oggetto “SysPrest 33 – controllo offerta”) ad operatori abilitati (feedback 13). L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -). Esempio:

agenda Num buchi_offerti (E)

Num Buchi_prenotati (G)

Num Buchi_disponibili

% saturazione (D)= G/E

Data massima di prenotazione (A)

Numero prenotazioni registrate (C)

Data controllo prenotazione (B)

4760 112 114 -2 101,79 02/12/2013 2 27/11/2013

X=5 Y=20 Z=50 Data controllo prenotazione (B) = (A) – X → 02/12/2013 – 5 GG = 27/11/2013 Numero prenotazioni registrate (C)= numero di prenotazioni con data prenotazione >= 27/11/2013 → sono 2 L’agenda viene segnalata se si verifica la condizione:

Num_prenotazioni_registrate (C) >=1 and (Percentuale_Saturazione (D)< Y or NUM_Buchi_offerti (E) < Z) Per il caso → 2>=1 and (101,79< 20 or 112<50 → quindi non verificato



SysPrest 34 – IRIS Pendenze rinvio per variazione anagrafica

Il processo (schedulato ogni minuto) verifica se nella tabella IRIS_Pendenze_007_RinvioPendenze (ELAB_DataOra is NULL) ci sono pendenze da creare, dovute ad una variazione di codice fiscale dell’assistito. Il processo esegue la storede procedure [p_IRIS_015_RinvioPendenze].

SysPrest 35 - IRIS Schedulatore Integrazione notifiche pagamenti

Lo schedulatore chiama 1 volta ogni 5 minuti la stored di elaborazione dei messaggi ricevuti dall’integrazione (p_IRIS_100_PAGAMENTI_SCHEDULATORE).



SysPrest 36 - Integrazione verifica automatica MSG con errore

Il processo SQL (pianificato ogni 30 minuti) che classifica in automatico lo stato di verifica dei messaggi d’integrazione anagrafe (client/server), prenotato/contabilizzato(richieste), erogato Anagrafe client (storede procedure p_INTEGRAZIONE_054_ANAG_Client_GestioneErr_Processo)

• Il messaggio viene classificato “verificato “(Integrazione_Stato_Verifica_Errore_ID=2) se è presente un messaggio successivo, per lo stesso assistito (stesso codice aziendale), inviato correttamente

• Il messaggio viene classificato “verificato “(Integrazione_Stato_Verifica_Errore_ID=3) se è presente un messaggio server (nel log corrente) successivo, per lo stesso assistito (stesso codice aziendale), elaborato correttamente

Anagrafe server (storede procedure p_INTEGRAZIONE_057_ANAG_Server_GestioneErr_Processo)

• Il messaggio verrà classificato “verificato “(Integrazione_Stato_Verifica_Errore_ID=3) se è presente un messaggio successivo, per lo stesso assistito (stesso codice aziendale), elaborato correttamente

Prenotato/contabilizzato (richieste - p_INTEGRAZIONE_060_Richieste_GestioneErr_Processo):

• Se presente un messaggio con errore e non verificato (Integrazione_Stato_Verifica_Errore_ID=NULL) o Se STATO_RICHIESTA = 'A

▪ Verifica se esiste un messaggio successivo (su tabella LOG corrente) con STATO_RICHIESTA = 'A’, elaborato corretamente per la richiesta

• Se SI o Il messaggio viene classificato “Errore verificato da sistema – Messaggio con

stato A non rigenerato in quanto è presente un messaggio successivo con stato A elebaorato corretamente” (Integrazione_Stato_Verifica_Errore_ID=7)

• NO o Viene verificato se esiste un messaggio successivo (su tabella LOG corrente)

con STATO_RICHIESTA = 'C’, elaborato corretamente o meno per la richiesta ▪ Se SI

• Il messaggio viene classificato “Errore verificato da sistema – Messaggio con stato A non rigenerato in quanto è presente un messaggio successivo con stato C” (Integrazione_Stato_Verifica_Errore_ID=10)

▪ NO

• Il messaggio viene classificato “Rigenerazione da sistema del messaggio” (Integrazione_Stato_Verifica_Errore_ID=5)

o Stato STATO_RICHIESTA = 'C’ ▪ Verifica se esiste un messaggio precedente (su tabella LOG corrente + Stporico) con

STATO_RICHIESTA = 'A’, elaborato corretamente per la richiesta

• Se SI o Il messaggio viene rinviato (copiando i dati del messaggio corrente) o Il messaggio viene classificato “Ri - invio da sistema del messaggio con stato

C” (Integrazione_Stato_Verifica_Errore_ID=9)

• NO o Il messaggio viene classificato ” Errore verificato da sistema – Messaggio con

stato C non rinviato in quanto NON è presente un messaggio precedente con stato A elebaorato corretamente” (Integrazione_Stato_Verifica_Errore_ID=8)



CASO 1:

MSG Richiesta Stato_richiesta Stato messaggio

1 1000 A Errore

2 1000 A OK

Il MSG 1 viene classificato “verificato da sistema: non rigenerato in quanto è presente messaggio successivo con stato A elaborato OK” (Integrazione_Stato_Verifica_Errore_ID=7).

CASO 2:


2 1000 A OK

3 1000 C Errore

Il MSG 3 viene classificato “Ri-inviato” (Integrazione_Stato_Verifica_Errore_ID=9) e il sistema genera un nuovo messaggio copiando il messaggio 3

CASO 3:


1 1000 A Errore

3 1000 C Errore

Il MSG 1 viene classificato “verificato da sistema: non rigenerato in quanto è presente un messaggio successivo di tipo C” (Integrazione_Stato_Verifica_Errore_ID=10) Il MSG 3 viene classificato “verificato da sistema: non ri-inviato in quanto non è presente un messaggio precedente di tipo A elaborato corretamente” (Integrazione_Stato_Verifica_Errore_ID=8).

CASO 4:


1 1000 A Errore

Il MSG 1 viene rinviato rigenerato (Integrazione_Stato_Verifica_Errore_ID=5).

CASO 5:


1 1000 A Errore

2 1000 A Errore

Il MSG 1 viene rinviato rigenerato (Integrazione_Stato_Verifica_Errore_ID=5). Il MSG 2 viene rinviato rigenerato (Integrazione_Stato_Verifica_Errore_ID=5).

CASO 6:


2 1000 A OK

3 1000 A Errore

4 1000 C Errore

Il MSG 1 viene classificato “verificato da sistema: non rigenerato in quanto è presente un messaggio successivo di tipo C” (Integrazione_Stato_Verifica_Errore_ID=10) Il MSG 4 viene classificato “Ri-inviato” (Integrazione_Stato_Verifica_Errore_ID=9) e il sistema genera un nuovo messaggio copiando il messaggio 4

Erogato:

• Il messaggio verrà classificato “verificato “(Integrazione_Stato_Verifica_Errore_ID=6) se è presente un messaggio successivo, per lo stesso progressivo d’integrazione della prestazione, elaborato correttamente



ELABORAZIONI

Estrazione File stipendi (cod. elaborazione stipen)

MDB: pgmStipendi.mdb

Il tracciato del file esportato è il seguente:

Nome campo Inizio Larghezza

CODI 1 8

CDVO 9 4

CDPR 13 1

ANNO 14 2

MESE 16 2

QTRE 18 6

UNMI 24 1

SEGN 25 1

IMUN 26 11

SEGN1 37 1

IMPO 38 11

ALIQ 49 4

Il file prodotto ha estensione .seq Attenzione: L’elaborazione elabora anche l’area a pagamento → ma non viene estratto nei file perché la causale non ha valorizzato il campo “voce” L’elaborazione esegue una spunta che segnala eventuali conti estratti senza matricola (matricola = NULL)



Creazione file stipendi - NUOVA Elaborazione (cod. elaborazione stipV4)

Premessa

Le prestazioni “da pagare” al professionista saranno quelle collegate ad un documento contabilizzato (relativo alle causali indicate nella tabella STIPENDI_001_CAUSALI), completamente erogato e pagato. La cancellazione di un erogazione di una prestazione collegata ad un documento “pagato al ALP” genererà uno storno dell’intero documento (ultimo documento estratto dagli stipendi in modo definitivo - DocumentiLogici. STIPENDI_PERIODO_PAGAMENTO). Una operazione di cassa di tipo “uscita” di un documento “pagato al ALP” genererà uno storno dell’intero documento (ultimo documento estratto dagli stipendi in modo definitivo - DocumentiLogici. STIPENDI_PERIODO_PAGAMENTO). In fase d’installazione i documenti con data registrazione <= 01/11/2014 sono stati classificati come “estratti vecchia versione elaborazione stipendi” (DocumentiLogici.STIPENDI_FLG_ELAB=NULL) Database: tabella DocumentiLogici:

• campo STIPENDI_FLG_ELAB di tipo numerico (=NULL se estratto dall’attuale elaborazione degli stipendi; = 1 se elaborato; altrimenti =0 se documento deve essere elaborato)

• campo STIPENDI_PERIODO_PAGAMENTO di tipo numerico (formato AAAAMM – viene memorizzato l’ultimo periodo in qui è stato pagato il documento al professionista)

tabella STIPENDI_001_CAUSALI (elenco causali che devono essere elaborate stipendi)

Contabilizza

In fase di registrazione di un nuovo documento, se il documento si riferisce ad una delle causali che prevedono elaborazione stipendi, il sistema classifica il documento da estrarre dall’elaborazione degli stipendi ALP (DocumentiLogici.STIPENDI_FLG_ELAB=0). La riapertura di un documento classificherà il documento da estrarre dall’elaborazione degli stipendi ALP (DocumentiLogici.STIPENDI_FLG_ELAB=0) se documento precedentemente classificato elaborazione “nuova” (DocumentiLogici.STIPENDI_FLG_ELAB<>NULL)

Erogazione

In cancellazione di un erogazione associata ad una prestazione collegata a documento “elaborata Stipendi” (DocumentiLogici.STIPENDI_FLG_ELAB=1), in una apposita tabella di LOG (STIPENDI_010_STORNI con TIPO_operazione_id=1) viene mantenuta traccia dell’operazione, in quanto il sistema genererà una operazione di storno del pagamento del professionista (relativo al pagamento del periodo DocumentiLogici. STIPENDI_PERIODO_PAGAMENTO)

Cassa

Se l’operazione si storno si riferisce ad un documento classificato “elaborato Stipendi” (DocumentiLogici.STIPENDI_FLG_ELAB=1) in una apposita tabella di LOG (STIPENDI_010_STORNI con TIPO_operazione_id=1) viene mantenuta traccia dell’operazione, in quanto il sistema genererà una operazione di storno del pagamento del professionista (relativo al pagamento del periodo DocumentiLogici. STIPENDI_PERIODO_PAGAMENTO)



Elaborazione

Il periodo di elaborazione è sequenziale (ultimo periodo elaborato di tipo DEFINITIVO +1). Elaborazione estrae il file per gli stipendi (con estensione .seq) con il seguente tracciato:

Nome campo Inizio Larghezza Note valorizzazione

CODI 1 8 Codice Matricola associata al codice conto del documento (campo formattato con 0 davanti fino alla lunghezza del campo)

CDVO 9 4 Codice voce associato alla causale del documento (campo formattato con 0 davanti fino alla lunghezza del campo)

CDPR 13 1 Se importo onorario totale >= 0 →Codice precodiceVoce associato alla causale del documento; altrimenti fisso a R

ANNO 14 2 Anno del periodo di elaborazione (ultime 2 cifre dell’anno)

MESE 16 2 Mese del periodo di elaborazione (formato MM)

QTRE 18 6 Fisso 0000000

UNMI 24 1 vuoto

SEGN 25 1 vuoto

IMUN 26 11 Fisso 00000000000

SEGN1 37 1 vuoto

IMPO 38 11 Somma (onorario medico) (campo formattato con 0 davanti fino alla lunghezza del campo, le ultime due cifre sono i decimali esempio 34,60 € →00000003460)

ALIQ 49 4 Fisso 0000

L’elaborazione prevede i seguenti parametri:

• Modalità: bozza o definitivo (selezionata dall’operatore)

• Periodo (formato AAAAMM): impostato dal sistema - l’ultimo periodo elaborato in modo “definitivo” +1)

Le spunte dell’elaborazioni (per periodo) sono memorizzate in una apposita tabella (STIPENDI_ELB_005_SPUNTE) da interrogare dal sistema SAS. Dal diario delle elaborazioni di SysPrest è solo possibile vedere solo le quadrature (effettuata sul numero dei documenti). L’elaborazione effettua le seguenti operazioni:

1. estrazione tutti i documenti contabili (contabilizzati o meno) classificati “da estrarre” (DocumentiLogici.STIPENDI_FLG_ELAB =0)

2. Valorizzazione periodo competenza per i documenti: il periodo di competenza sarà = periodo della data massima di erogazione di tipo confermata delle prestazioni

3. Cancellazione dei documenti con periodo competenza > periodo elaborazione 4. Cancellazione dei documenti con nessuna prestazione associata 5. Cancellazione dei documenti con max data di prenotazione > periodo di elaborazione 6. Cancellazione dei documenti (senza prenotazioni) con data registrazione > periodo di elaborazione e senza periodo di

competenza 7. Quadratura Q0 - numero documenti da elaborare 8. Classificazione dei documenti formalmente non corretti e che non verranno pagati al professionista

a. Spunta errore 1 – elenco documenti “non contabilizzati” (con relativa quadratura Q1) b. Spunta errore 2 – elenco documenti “con prestazioni non erogate” (con relativa quadratura Q2) c. Spunta errore 3 – elenco documenti “con nessuna prestazione erogata” (con relativa quadratura Q3) d. Spunta errore 4 – elenco documenti “con pagato” (con relativa quadratura Q4) e. Spunta errore 5 – elenco documenti “prestazione senza tariffa” (con relativa quadratura Q6) f. Spunta errore 6 – elenco documenti “importo pagato <> importo delle prestazioni” (con relativa quadratura Q6) g. Spunta errore 7 – elenco documenti “con conto senza matricola” (con relativa quadratura Q7) h. Spunta errore 8 – elenco documenti “con causale senza codice voce valorizzato” (con relativa quadratura Q8) i. Spunta errore 9 – elenco documenti “con causale senza pre codice voce valorizzato” (con relativa quadratura

Q9) 9. Calcolo del compenso (per i soli documenti formalmente corretti) per le singole prestazioni 10. valorizzazione importo SSN applicando il listino SSN (per le prestazioni prenotate è applicato il listino valido alla data di

prenotazione, mentre per le prestazioni in accesso diretto è applicato il listino valido alla data di registrazione del documento contabile – se per la prestazione non è presente un listino SSN l’importo SSN della prestazione è 0)

11. Estrazione di tutti i documenti da stornare (da tabella STIPENDI_010_STORNI where STIPENDI_FLG_ELAB=0). Per ogni documento verrà stornato i valori del documento del periodo ultimo pagamento presente al momento dell’operazione di storno ( tabella STIPENDI_010_STORNI.DOC_STIPENDI_PERIODO_PAGAMENTO).



12. L’onorario del medico = onorario del medico * 0,75 where causale.codvoce= 702 and causale=35 13. Copia movimenti con causale.codvoce= 702 and causale=35 → con codvoce= 703 14. L’onorario del medico = onorario del medico * 0,25 where causale.codvoce= 703 and causale=35 15. Scarico in tabella di output i dati:

a. [dbo].[STIPENDI_ELB_005_SPUNTE] b. [dbo].[STIPENDI_ELB_020_OUT_DOC] → documenti elaborati c. [dbo].[STIPENDI_ELB_025_OUT_DOC_PREST] → prestazioni associati a documenti elaborati d. [dbo].[STIPENDI_ELB_030_OUT_FILE] -- > file da esportare e. STIPENDI_ELB_028_OUT_DOC_PREST_Ripartizioni → per le prestazioni vengono registrate le

ripartizioni (codici classificati stampabili associati alla causale) 16. Se elaborazione definitiva:

a. Classifica come estratto i documenti DocumentiLogici.STIPENDI_FLG_ELAB=1 con DocumentiLogici.STIPENDI_PERIODO_PAGAMENTO=periodo elaborazione

b. Classifica come estratto i documenti stornati STIPENDI_010_STORNI.STIPENDI_FLG_ELAB=1 con STIPENDI_010_STORNI.STIPENDI_PERIODO_PAGAMENTO=periodo elaborazione

Attenzione: dopo avere eseguito l’elaborazione definitiva non sarà possibile annullare l’elaborazione in quanto le operazioni

di storno vengono memorizzate se il documento è classificato “pagato stipendi”

(documentilogici.STIPENDI_PERIODO_PAGAMENTO <> NULL).

Le spunte dell’elaborazione vengono salvate nella tabella STIPENDI_ELB_005_SPUNTE (tabella che deve accederci SAS)

STIPENDI_ELB_005_SPUNTE

SPUNTA_ID contatore

ERRORE_TIPO_ID Decodifica tabella STIPENDI_ELB_001_TIPO_ERRORE

DOCUMENTO_ID Codice documento

PROGRESSIVO_PRESTAZIONE Progressivo di prestazione con errore -- ATTUALMENTE NON VALORIZZATO

PERIODO_ELAB Periodo di elaborazione

ELAB_ID Codice elaborazione

CAUSALE_ID Codice causale

CONTO_ID Codice conto

I file prodotti (em-lp.seq) si trovano nel server SRVREPCUP nella cartella E:\csioweb\sysprestv3\txt_V3\Stipendi_v4\xxxx<anno periodo estrazione> + ‘out’ + yy<mese periodo estrazione> \(lpem01.txt)



Importazione listino SSN

L’elaborazione prevede l’importazione di un file txt (con il tracciato seguente) con il listino SSN. L’eleaborazione inoltre prevede il parametro “data inizio validità” utilizzata per valorizzare la tada di listino delle nuove tarriffe importate. Tracciato da importare

Nota. Se per il codice nomenclatore non è variata la tarriffa viene comunque creata una nuova tariffa valida alla data di riferimento indicata. Passi eseguiti dall’elaborazione:

• Dal file importato il sistema cancella le prestazioni con tarriffa non valida alla data di elaborazione

• Il sistema segnala (quadratura/spunta) i codici nomenclatori non presenti nel listino di SysPrest

• Il nuovi codici vengono inseriti in SysPrest su tabella tblListiniPrestazioni

• Il sistema segnala (quadratura/spunta) i codici nomenclatori presenti nel listino di SysPrest ma non presenti nel file importato

• Il sistema cancella dal listino SSN di SysPrest le tarriffe alla data inserita come parametro dell’elaborazione

• Il sistema inserisce le nuove tariffe SSN su SysPrest alla data inserita come parametro dell’elaborazione (nella tabella tblListiniPrestazioniTariffe)

• Aggiorna la desrizione del codice nomenclatore per i codici nomenclatori già presenti in SysPrest

• Nella tabella Nomenclatore_001_Prestazioni viene memorizzato il listino SSN importato (la tabella prima di inserire il nuovo listino viene troncata→ non c’è quindi lo storico dei listini SSN importati)

• Nella tabella Nomenclatore_006_Prestazioni_Branca viene memorizzato l’associazione del codice nomenclatore alla branca alla data indicata

Il file di importazione deve essere inserito nella cartella elaborazione\fileimput della macchina ip 172.16.100.15 e 200.1.1.20 affinché l'elaborazione venga eseguita.

Nome campo Tipo dati Larghezza

cod_prest Testo 8

branca Testo 3

descrizione Testo 200

sedute Testo 2

cod_somm Testo 7

tariffa Testo 7

nota Testo 3

data_inizio Testo 8

data_fine Testo 8

livello Testo 1



Estrazione Flusso TAT (tracciato dal 2019)

MDB: pgmTempiAttesa_2019.mdb

L’elaborazione ha per finalità la creazione dei file txt dei tempi d'attesa. Parametri dell’elaborazione: periodo (anno e mese) L’elaborazione prende in considerazione tutte le prestazioni (nessun filtro sul regime di erogazione) prenotate (contabilizzate o meno), la cui data di inserimento della richiesta è compresa nel periodo di elaborazione. Non vengono prese in considerazione le prenotazioni cancellate. L’elaborazione esclude:

• le agende utilizzate per memorizzare le prenotazioni effettuate sul CUP AV (codici agenda presenti nella tabella CUP_AV_C_0005_AGENDE_PRENOT)

• le prestazioni inerenti gli episodi di pre e post ricovero (associate ai documenti “pre ricovero” , “SSN IMPEGNATIVA PRE-RICOVERO”, “SSN IMPEGNATIVA NRE PRE-RICOVERO”)

• le prestazioni su prenotazioni forzate con data prenotazione uguale alla data di contatto Il file di output rispetta il seguente tracciato (rif. TAT - Specifiche funzionali versione 1.1pdf) :

Nome campo Tipo Larghezza note

1 Anno testo 4 Anno (dataContatto)

2 Mese testo 2 Mese(dataContatto)

3 Giorno testo 2 Giorno(data conatto) – se prestazione di branca K Giorno=00 Nota: la branca della prestazionione è individuata dalla branca valida alla data odierna

4 CodAz testo 3 = 201

5 CodZona testo 1 =L

6 CodStru testo 6 Codice struttura STS indicata nell’equipe dell’agenda prenotata ( StruttureAnagrafe.codStru)

7 CodSpe testo 3 Codice specialità indicata nell’ agenda prenotata

8 CodDisc testo 3 codice disciplina associato alla prestazione aziendale (da tabella tblPrestazioniAnagrafe)

9 CodPrest testo 8 codice nomenclatore associato alla prestazione aziendale (da tabella tblPrestazioniAnagrafe) se codice nomenclatore non è presente nella tabella Nomenclatore_001_Prestazioni il valore del campo viene valorizzato con NULL

10 Priorita testo 1 Valori possibili B,D, P, 0

• Codice priorita indicato nella ricetta: B,D, P, 0 “non rilevato”

• Per le prestazioni non contabilizzate o contabilizzate su documenti diversi dal tipo “ricetta” il campo viene valorizzato con il codice “priorita ricetta” indicato in fase di prenotazione se presente

• Altrimenti =0

11 Contatto testo 1 =2 se tipomedico del documento =03 OR =08 OR =09; altrimenti =1

12 ModAcc testo 1 =1

13 RegiEro testo 1 se “libera professione” e “area a pagamento= 0”, altrimenti =1

14 TempAtt testo 6 Il tempo attesa su prenotato è la differenza calcolata in giorni tra la data di inserimento della richiesta e la data di prenotazione. Se il tempo attesa su prenotato risulta nullo o inferiore a 0 verrà valorizzato a 0. Campo formatto con 0 a sinistra

15 TempAttRel testo 6 Il tempo attesa su disponibile è la differenza calcolata in giorni tra la data di inserimento della richiesta e la data di prima disponibilità. Se il tempo attesa su disponibile risulta nullo o inferiore a 0 verrà valorizzato a 0.

• Per prenotazioni del percorso “colore” la prima disponibilità= data prima disponibilità relativa alla priorità della prenotazione



La prima data disponibile è calcolata diversamente per prenotazioni relative ad agende normali o ad agende colore (prima disponibilità per il colore della ricetta). La prima disponibilità per agenda è calcolata per la tipologia d’urgenza, riservata e regime. Per le prenotazioni per cui non è presente nessuna “data prenotabile”, la data prenotabile sarà uguale alla data di prenotazione. L’elaborazione segnala la quadratura dei record (per sinsola prestazione) estratti inizialmente, eliminati per record incompleti e record finali esportati. L’elaborazione non spegnala nessuna spunta. All’interno del database Access pgmTempiAttesa_2019.mdb è presente la tabella spunta_recordIncompleti che contiene i record incompleti per dati non completi:

• codZona

• codStru

• codDisciplina

• codSpe

• regime Erogazione

• Stru1d

• Codprest

Le viste z_qy_xxx_datiIncompleti_xxx permetto di individuare il campo non valorizzato. Inoltre la vista z_qy_040_tempoAttesa_superiore_730 che elenca le prenotazioni con tempo di attesa (su prenotato e su disponibile) > 730 GG (la regione scarta le prestazioni con tempo di attesa superiore a 730 GG).

• Per prenotazioni del percorso “non colore” la prima disponibilità = data prima disponibilità della prenotazione

• = data di prenotazione se la prima disponibilità è NULL

• = data di prenotazione se la prima disponibilità < data prima disponibilita

16 CodAz1d testo 3 = 201

17 Stru1d testo 6 codice STS11 struttura (StruttureAnagrafe.codStru) associata alla equipe dell’agenda prenotabile

18 ScelUte testo 1 =1 se tempoAttesaSuPrenotato < tempoAttesaSuDisponibile (in questo caso tempoAttesaSuDisponibile = tempoAttesaSuPrenotato e DataPrenotabile = PrenotazioneData)

altrimenti =2

19 Numpres testo 7 20 D_service Testo 1 =1 se nella descrizione dell’agenda è presente “DAY

SERVICE”; altrimenti =0 21 AiutoPoint Testo 1 Se prenotazione registrata dalla struttura “CUP - CENTRO DONNA”

=1 ; altrimenti =0 22 Catalogo Testo 10 Codice regionale della prestazione; se non valorizzato il

campo viene valorizzato a ‘0000000000’ 23 Comresu Testo 6 Codice istat del comune di residenza dell’assistito associata

alla posizione anagrafica alla data di estrazione; se comune non rilevato “000000”; se il codice comune nei primi 3 caratteri =999, il campo viene valorizzato con 999999

24 UslAss Testo 3 Azienda toscana di assistenza sanitaria dell’utente =Codice USL di domicilio della regione toscana dell’assistito associata alla posizione anagrafica alla data di estrazione; se USL non rilevata “000”

25 ZonaAss Testo 1 Zona socio-sanitaria toscana di assistenza sanitaria dell’utente =ZONA associata al comune di domicilio dell’assistito da tabella dbo.FLUSSI_SPA_0400_COMUNI_ZONE; se zona non rilevata “0

26 Opera testo 1 =1



FLUSSI SPA - FED

L’elaborazione (su MDB Access pgmFlussiSPA_2019.mdb) prevede un’estrazione mensile dei file secondo il tracciato FED_dal_2019.pdf e SPA_dal_2019.pdf. Il periodo di elaborazione è sequenziale (utimo periodo elaborato di tipo DEFINITIVO +1). L’elaborazione estrae i documenti con periodo di competenza (periodo della massima data di erogazione delle prestazioni, che compone il documento) >= periodo inizio indicato direttamente nella tabella Elab_003_CodiciElaborazioni e nel campo “periodo_inizio” AND periodo competenza <= periodo fine dato dall’ultimo periodo elaborato in modo definitivo + 1 L’elaborazione prevede i seguenti parametri:

• Modalità: bozza o definitivo (selezionata dall’operatore)

• Periodo inizio (formato AAAAMM): impostato da sistema con periodo indicato Elab_003_CodiciElaborazioni.periodo_inizio

• Periodo fine (formato AAAAMM): impostato dal sistema - l’ultimo periodo elaborato in modo “definitivo” +1). Nella pagina di visualizzazione del periodo di elaborazione verrà visualizzato anche il periodo inizio (Elab_003_CodiciElaborazioni. periodo_inizio), dato non modificabile se non accedendo direttamente alla tabella.

• modalità di classificazioni delle prestazioni (selezionata dall’operatore): o classificazione delle prestazioni registrata in fase di contabilizzazione (@modalita_elab =1) o classificazione delle prestazioni valida alla data di schedulazione dell'elaborazione senza aggiornamento

dei dati estratti su SysPrest (@modalita_elab =2) o classificazione delle prestazioni valida alla data di schedulazione dell'elaborazione con aggiornamento

dei dati estratti su SysPrest (@modalita_elab =3) In fase di schedulazione dell’elaborazione è possibile selezionare il 13° mese dell’anno di elaborazione (successivo al AAAA12). L’elaborazione schedulata per il 13° mese estrarrà i documenti con “periodo di competenza” >= periodo inizio indicato direttamente nella tabella Elab_003_CodiciElaborazioni e nel campo “periodo_inizio” AND “periodo competenza” <=AAAA12. In archivio l’estrazione del 13° mese verrà memorizzata con periodo invio = AAAA13. L’elaborazione schedulata per il 13° mese permette così di estrarre i soli documenti classificati da “estrarre” (alla schedulazione dell’elaborazione) di un anno di competenza (es. periodo_inizio=200801 e periodo_fine= 200812. Per le prestazioni pacchetti “di servizio” la valorizzazione di alcuni campi avviene come da esempio seguente:

Per le prestazioni “pacchetto di servizio” vengono estratte le prestazioni di dettaglio memorizzate nella fase del calcolo ticket in contabilizzazione. L’importo della singola prestazione del pacchetto viene calcolato in fase di estrazione dello SPA (per le prestazioni prenotate la tariffa della prestazione viene calcolata alla data di prenotazione mentre per le prestazioni in accesso diretto alla data di contabilizzazione). Nessuna Spunta evidenzia i pacchetti con tariffa diversa dalla somma delle singole prestazioni



L’elaborazione effettua le seguenti operazioni: 17. estrazione tutti i documenti contabili classificati “da estrarre” e di tipo documento da estrarre dai flussi

(DocumentiLogici.FLG_FLUSSI_SPA_ELAB=0 AND documentiLogici_tblTipoDocumentoEsterno.flgFlussi=1) 18. vengono escluse le prestazioni associate a documento con importo a 0 19. estrazione di tutti i documenti contabili cancellati (dalla tabella DocumentiLogici_DEL con

FLG_FLUSSI_SPA_ELAB=1 AND dbo.DocumentiLogici_tblTipoDocumentoEsterno.flgFlussiSpa = 1). Lo SPA 2 sarà fittizio (con i campi valorizzati con valori di default come segue):

campo valore

Usl_strutt_erog 201

presidio 11011A

speciali 026

reparto 00

disciplina 26

dataini

datafine

contatto

ScelUte 9

Dataprenotabile 00000000

Tipopr 8

codpres C

codcatalogo Vuoto

branca 0

Numacc 001

Quantiuni 001,00

Tariffa 00000,00

Lordo 00000,00

Convenzione 0

compensa 0

Tipoerog 00

Chiavespa2 1

MRA_erog Vuoto

Pacchetto vuoto

20. Valorizzazione periodo competenza per i documenti “attivi”: il periodo di competenza sarà = periodo della

data massima di erogazione confermata delle prestazioni che compone il documento 21. Valorizzazione periodo competenza per i documenti cancellati: il periodo di competenza sarà = al periodo

competenza del documento dell’ultima elaborazione flussi che ha estratto il documento 22. Per i documenti con” periodo copetenza” non valorizzato verrà impostato = al periodo inizio elaborazione 23. Dei documenti da elaborare si cancellano tutti i documenti con “numero totale prestazioni

documento”=”numero prestazioni associate ad agende no flussi SPA” e “documento mai inviato in regione” 24. Dei documenti da elaborare si cancellano tutti i documenti con “periodo di competenza” < “periodo inizio

elaborazione” AND “periodo di competenza ” > “periodo fine elaborazione” e le relative prestazioni 25. Quadratura numero documenti da elaborare 26. Cancellazione documenti non contabilizzati (quadratura - spunta S.1.0) 27. Cancellazione documenti con tutte le prestazioni non erogate (quadratura - spunta S.1.1) 28. Cancellazione documenti con solo una parte delle erogate (quadratura - spunta S.1.2) Se in un documento tutte le prestazioni sono aggiuntive, una viene modifica in non “aggiuntiva”. Il valore dell’impegnativa (importo a carico paziente e importo a carico SSN) viene valorizzato con le sole prestazioni inviate. Per le impegnative non esenti viene applicato il calcolo come nel modulo web dell’impegnativa. Per i documenti estratti SPA1 l’elaborazione FED:

• Cancellerà i documenti con FED non inviati precedentemente in regione (FLG_FLUSSI_FED_INVIATO_REGIONE=0) e che non hanno nessun farmaco associato

• Classicherà con opera=1 i documenti con farmaci associati ma non inviato precedentemente in regione (FLG_FLUSSI_FED_INVIATO_REGIONE=0)

• Classicherà con opera=3 i documenti con farmaci associati e documento FED inviato precedentemente in regione (FLG_FLUSSI_FED_INVIATO_REGIONE=1)

• Classicherà con opera=4 i documenti con nessun farmaco associato e documento FED inviato precedentemente in regione (FLG_FLUSSI_FED_INVIATO_REGIONE=1)



L’elaborazione di tipo”definitiva” classifica i documenti “elaborati” nel seguente modo: • Per i documenti “attivi” che vengono inviati in regione:

DocumentiLogici.FLG_FLUSSI_SPA_INVIATO_REGIONE=1

DocumentiLogici.FLG_FLUSSI_SPA_ELAB=1

• Per i documenti “attivi” precedentemente inviati in regione ma che non contengono nessuna prestazione

erogata per i flussi:

DocumentiLogici.FLG_FLUSSI_SPA_INVIATO_REGIONE=0 DocumentiLogici.FLG_FLUSSI_SPA_ELAB=1

• Per i documenti “attivi” mai inviati in regione ma che non contengono nessuna prestazione erogata per i flussi:

DocumentiLogici.FLG_FLUSSI_SPA_INVIATO_REGIONE=0 DocumentiLogici.FLG_FLUSSI_SPA_ELAB=1

• Per i documenti “cancellati” che vengono inviati in regione:

DocumentiLogici_DEL.FLG_FLUSSI_SPA_ELAB=1

L’elaborazione di tipo “definitiva” classifica i documenti “elaborati FED” nel seguente modo:

• I documenti “attivi” estratti con opera <> 4 vengono classificati come inviati in regione (FLG_FLUSSI_FED_INVIATO_REGIONE=1).

• I documenti “attivi” estratti con opera=4 vengono classificati come non inviati in regione (FLG_FLUSSI_FED_INVIATO_REGIONE=0).

L’elaborazioni di tipo DEFINITIVA vengono memorizzate nella tabella FLUSSI_SPA_V2_0005_ELAB. Il flusso inviato viene memorizzato nelle tabelle FLUSSI_SPA_V2_0020_SPA2_OUT, FLUSSI_SPA_V2_0010_SPA1_OUT, FLUSSO_FED_0020_FED1_OUT e FLUSSO_FED_0030_FED2_OUT. I file prodotti dall’elaborazione vengono creati nella directory “SysPrestV3\txt_v3\AAAAoutMM\flussiSPA_V2\” (dove AAAAoutMM è il periodo di elaborazione).

I documenti vengono classificati “da elaborare” nel seguente modo:

• Quando viene creato un documento viene classificato da estrarre dai flussi SPA

(DocumentiLogici.FLG_FLUSSI_SPA_ELAB=0)

• Quando viene riaperto un documento contabilizzato viene classificato da estrarre dai flussi SPA

(DocumentiLogici. FLG_FLUSSI_SPA_ELAB=0)

• Cancellato/inserito/modificato un accesso di una prestazione contabilizzata il relativo documento viene

classificato da estrarre dai flussi SPA (DocumentiLogici.FLG_FLUSSI_SPA_ELAB=0)

• Quando viene cancellato un documento inviato in regione

(DocumentiLogici.FLG_FLUSSI_SPA_INVIATO_REGIONE=1) viene memorizzato in una tabella di LOGe

viene classificato da estrarre dai flussi SPA (DocumentiLogici_DEL.FLG_FLUSSI_SPA_ELAB=0)

• Se in modifica di una posizione anagrafica di un assistito viene variato il codice fiscale i documenti “attivi”

dell’assistito con l’anno della data di registrazione >= all’anno dell’ultima elaborazione vengono classificati da

estrarre dai flussi SPA (DocumentiLogici.FLG_FLUSSI_SPA_ELAB=0). Se il codice fiscale dell’assistito

contiene “STP” i documenti non verranno riestratti.



ARCHIVIO SPA1

Campo Nome Note valorizzazione

1 Record =1

2 Opera • = 1 per i documenti estratti per la prima volta (DocumentiLogici.FLG_FLUSSI_SPA_INVIATO_REGIONE=0)

• = 3 per i documenti già estratti e che devono essere rinviati (DocumentiLogici.FLG_FLUSSI_SPA_INVIATO_REGIONE=1)

• = 4 per i documenti cancellati (DocumentiLogici_DEL.FLG_FLUSSI_SPA_INVIATO_REGIONE=1)

• =4 Per i documenti precedentemente estratti (opera =3) ma che non contengono nessuna prestazione erogata I documenti con opera=4 avranno i record dello SPA1 e lo SPA2 fittizio

3 Chiave Il campo è valorizzato “E0C” + codice univo del documento SysPrest (es. per il 2007 → 07C12345)

4 tipoIndu • = 5 se assistito EE o UE (documento contabile di tipo UE o EE)

• =F se nel campo “codice stp” i primi tre caratatteri dono ENI

• =3 se il campo “codice stp” è valorizzato (len(xAnagraficaBase.Cod_STP) > 0 e non contiene ENI)

• =1 per tutti gli altri casi

5 IdUtente • = xAnagraficaBase.ASSISTITO_COD_UNIVERSALE

6 Sexu • =1 maschio

• =2 femmina

• I record con sesso non corretto verranno valorizzati con 0 (spunta S.3)

7 datanasc Data nascita assistito ggmmaaaa (tabella xAnagraficaBase). I record con data nascita non corretta verranno valorizzati con vuoto (spunta S.4)

8 cittu Cittadinanza dell’assistito (tabella xAnagraficaBase). Se la cittadinanza non è corretta (=NULL, =000, non presente nella tabella FLUSSI_SPA_0300_STATI_ESTERI) verrà impostata a ‘999’ (spunta S.5)

9 Regresu Regione del comune di residenza (dal comune di residenza)

10 Comresu Comune di residenza dell’assistito (tabella xAnagraficaBase).

• I record con il comune non corretto (non indicato, =000000, non presente nella tabella dei comuni ‘tblComuni’) verranno comunque estratti con il valore presente in archivio (spunta S.6)

• Se il comune di residenza = '099999' e la cittadinanza ='100' (assistiti con nazionalità italiana ma residenti in uno stato estero non individuato (spunta S.7)

• Se il codice comune di residenza = '099999' → Comresu= ‘'999999' ’

11 Uslresu il codice USL indicato nell'anagrafe del comune di residenza dell'assistito

12 Azienda Fisso 201

13 Tipologia_erog = 2 se tutte le prestazioni del documento appartengo ad agende associate a struttura (codice struttura dell’agenda) con tipo classificazione = 2 (dbo.StruttureAnagrafe.TipoClassificazione_id=2) = 1 negli altri casi

14 Accesso Codice accesso indicato nell’anagrafe dei documenti contabili (campo codice Accesso nella tabella DocumentiLogici_tblTipoDocumentoEsterno). I record con ‘Accesso’ =NULL o =00 non verranno eliminati (spunta S.8) Tabella anagrafe accessi possibili FLUSSI_SPA_0500_CODICI_ACCESSO

15 Finalita Codice indicato nel campo finalita nella tabella DocumentiLogici_tblTipoDocumentoEsterno



I record con ‘finalità =NULL o non valido non verranno eliminati (spunta S.14) Tabella anagrafe accessi possibili → FLUSSI_SPA_0600_FINALITA

16 Priorita • Per tutti i dati =0

• Viene individuata il codice di priorità del documento ricetta

• = ‘P’ se non precedentemente valorizzato and Accesso=’01’ 17 TipoContatto • = 1 se (idTipologiaMedicoPrescrittore <> '03' and idTipologiaMedicoPrescrittore <> '08' and idTipologiaMedicoPrescrittore is

not null)

• = 2 se (idTipologiaMedicoPrescrittore = '03' OR idTipologiaMedicoPrescrittore ='08')

• = 2 se non precedentemente valorizzato and Accesso=’01’

• = 0 per gli altri casi Nota. Medico indicato nel documento (dbo.DocumentiLogici.idTipologiaMedico)

18 Ricetta Per i documenti con “ricetta” diverso da NRE è valorizzato con il “numero della ricetta”; altrimenti presente = ‘0000000000000000’

19 DataPres • Se il documento ha “accesso” (campo 14 SPA1) = “01” il campo viene valorizzato con la “data ricetta”; se data ricetta non

valorizzata il campo non sarà compilato.

• Altrimenti campo non compilato 20 DataSped Se il documento ha tipo accesso (campo 16)= “01” → il documento ha collegato prestazioni prenotate, verrà valorizzato con la data

minima di registrazione (data contatto) della prenotazione. Altrimenti se il documento non ha collegato prestazioni prenotate verrà valorizzato con la data minima di erogazione del documento. La data deve essere <= della massima data di erogazione delle prestazioni collegate. i documenti con dataSped successiva alla massima data di erogazione delle prestazioni vengono elencati nella spunta S.26. Per documenti con accesso <>“01” il campo non verrà valorizzato.

21 RicSug Se il documento ha accesso= “01” (campo 16): o Per documentio di tipo “ricetta rossa” →il campo è valorizzato con RIC_SUGGERITA nella tabella Documenti_Impegnative

applicando la seguente trasformazione: ▪ =02 “NO” → “00” ▪ =03 “non rilevato” →”00”

o Per documentio di tipo = “01” se “tipologia prescrizione” =”S” (=”00” per gli altri casi)

o =00 se non precedentemente valorizzato

Altrimenti se accesso <> “01” (campo 16) → campo vuoto

22 Tipomp se la modalità di “accesso”=01 OR 02 o tipologia medico prescrittore (presente al momento dell’estrazione in anagrafe medici – tabella tblMedici campo

“IdTipologiaMedico”). o Se il dato non è presente in archivio il campo sarà valorizzato con ‘00’.

per altri casi ‘00’

23 Totprest Somma delle quantità delle prestazioni collegate al documento



24 NumPrestEff • Per i documenti con accesso ‘01’ o num record di SPA2 dove tipopr=1 or D (per i pacchetti di servizio il numero di prestazioni è data dalle prestazioni singole

del pacchetto) o Le prestazioni a ciclo devono essere considerate una sola prestazione. o Se NumPrestEff>99 then NumPrestEff=99

Per altri tipi di documento campo vuoto.

25 impprest = (Somma della tariffa delle prestazioni con il campo “compensa”=1 dello SPA2) – importo ticket a carico paziente (campo 29)

Se impprest <0 → impostato a 00000,00

26 Imptick • Se il documento ha tipo accesso<> “04”

importo ticket a carico paziente → = importoAccertato del documento

• Per i documenti che hanno il tipo accesso<> “04” e il tipo documente prevede la gestione dei ticket aggiuntivi

(dbo.DocumentiLogici_tblTipoDocumentoEsterno.FLG_MANOVRA_TICKET_AGGIUNTIVI = 1) → Imptick= importoAccertato del

documento – importo contributo digitlizzazione – importo ticket aggiuntivi

• Se il documento ha tipo accesso= “04” and documento “NON esente” ( documentiLogici.EZENZIONE_ID=0)

imptick = importo accertato del documento – importo quota accesso

• altri casi ‘00000,00’

27 codese In ordine: 1) codesen viene inizialmente valorizzato con l'esenzione del documento 2) Se il documento ha collegato almeno una prestazione esente:

o se tutte le prestazioni "esenti" del documento hanno lo stesso codice di esenzione --> codese= codice esenzione "esente" indicata nella prestazione.

3) per documenti "non esenti" (ESENZIONE_ID = 0) codesen= 000000 nota. codice esenzione da tabella tblEsenzioni_codici.COD_ESENZIONE

28 FE_Quoric Valori ammessi RA per la classe di reddito familiare fiscale fino a 36.151,98 euro RB per la classe di reddito familiare fiscale 36.151,99 - 70.000 euro RC per la classe di reddito familiare fiscale 70.000,01 - 100.000 euro RD per la classe di reddito familiare fiscale superiore a100.000 euro IA per la classe di reddito familiare equivalente ISEE fino a 36.151,98 euro IB per la classe di reddito familiare equivalente ISEE 36.151,99 - 70.000 euro IC per la classe di reddito familiare equivalente ISEE 70.000,01 - 100.000 euro ID per la classe di reddito familiare equivalente ISEE superiore a 100.000 euro per i documenti “con gestione NO MANOVRA” (creazione di un documento con associate le prestazioni ticket aggiuntivi + contributo digitalizzazione)

o il sistema verifica se esiste un documento associato di tipo “ticket su ricetta” (tipoDocumentoEsterno = 102) OR (tipoDocumentoEsterno = 103) OR (tipoDocumentoEsterno = 104)



▪ se presente il campo verrà valorizzato con l’associazione codice tipo documento/prestazione presente nella tabella FLUSSI_SPA_0700_PREST_FE_Quoric campo SPA_FE_Quoric (di una delle prestazioni associate al documento di tipo tiket su ricetta

▪ per individuare la prestazione con la fascia di redito associata viene esclusa la prestazione cod.5406 "Contributo digitalizzazione radiodiagnostica"

per i documenti “con gestione MANOVRA” o = valore del campo “SPA_FE_Quoric” relativo alla fascia di redito dell’assistito (DocumentiLogici_tblFasceReddito) indicata

nel documento contabile se il tipo documento della relevazione del redito è <> ISEE altrimenti viene valorizzato con il campo “SPA_FE_Quoric_ISEE”

00 negli altri casi

29 quoric Per tutti i record estratti il campo verrà valorizzato con “00000,00” per i documenti SSN “con gestione NO MANOVRA” (creazione di un documento con associate le prestazioni ticket aggiuntivi + contributo digitalizzazione)

• il sistema verifica se esiste un documento associato di tipo “ticket su ricetta”, se presente: o Se "importo accertato del documento" = 0 → Quoric = 00000,00 o Se "importo accertato del documento" > 0

▪ Se “esenzione prestazione del contributo digitalizzazione” = “non esente” → Quoric = l’importo acertato del documento – il totale delle prestazioni del documento del contributo digitalizzazione (prestazione cod.5406)

▪ Se “esenzione prestazione del contributo digitalizzazione” <> “non esente” ” → Quoric = l’importo acertato del documento

per i documenti SSN “con gestione MANOVRA” (dbo.DocumentiLogici_tblTipoDocumentoEsterno.FLG_MANOVRA_TICKET_AGGIUNTIVI = 1)

• Somma degli importi dei ticket aggiuntivi (escluso contributo diditalizzazione)

30 quotAcPS • Se il documento ha tipo accesso “04” AND il documento è non esente (DocumentiLogici.ESENZIONE_ID<>0) → =

DocumentiLogici.Importo_QuotaAccesso

• Se il documento ha tipo accesso “04” AND il documento è esente (DocumentiLogici.ESENZIONE_ID=0) → = ‘00000,00’

00000,00 negli altri casi

31 IstiCompEurop Se tipoindu = '5' (campo 4) valorizzato con il campo IMPEGNATIVA_COD_ISTITUZIONE della tabella Documenti_Impegnative; altrimenti campo vuoto

32 CodIdeUteEurop Se tipoindu = '5' (campo 4) valorizzato con il campo IMPEGNATIVA_NUM_PERSONALE della tabella Documenti_Impegnative; altrimenti campo vuoto se tipoIndu=5 e il campo è vuoto (spunta S.24)

33 CodIdedocuEuro Se tipoindu = '5' (campo 4) valorizzato con il campo IMPEGNATIVA_NUM_TESSERA della tabella Documenti_Impegnative; altrimenti campo vuoto



34 CodStatDocuEurop Se tipoindu = '5' (campo 4) valorizzato con il campo STATO_ESTERO_UE_ID della tabella Documenti_Impegnative; altrimenti campo vuoto

35 DataScadDocuEurop • Se il documento ha tipo accesso “01” (campo 16), il campo verrà valorizzato con Documenti_Impegnative.

DATA_SCADENZA_TESSERA_EUROPEA; se dato non presente campo vuoto

• Per altri tipi di documento campo vuoto

36 BiffaStmpElect Ricetta NRE su modulo “ricetta NRE” fisso 0 “Ricetta rossa” o “ricetta NRE” su modulo “ricetta rossa”:

• Se il documento ha tipo accesso “01” (campo 16), il campo verrà valorizzato con RIC_STMP_ELET nella tabella Documenti_Impegnative.

• I record con “BiffaStmpElect” non valido (diverso da 1 o diverso da 2 o diverso da 0) verranno valorizzato con 0 (spunta S.10). =’’ per gli altri tipi di documento

37 tipoassist Valorizzato con il capo ‘tipo_assistenza’ nella tabella DocumentiLogici_tblTipoDocumentoEsterno; I record con “tipoassist” non valido (diverso dai valori ammessi ) non verranno eliminati (spunta S.16) → campo vuoto

38 Dservice =1 se almeno una prestazioni del documento afferisce ad agende con descrizione dell’agenda dove è presente “DAY SERVICE”; altrimenti =0

39 PACC Fisso 000

40 patpres patologia indicata nell’impegnativa (Documenti_Impegnative.PATOLOGIA_CODICE ); se non è presente nessun valore il campo viene valorizzato a 00000

41 ICD9 Fisso 00000

42 NRE Per i documenti con “ricetta” e il 4 + 5 carattere non sono numerici è valorizzato con il “numero ricetta”; altrimenti presente = ‘0000000000000000’

43 C_digit Per tutti i record estratti il campo verrà valorizzato con “00000,00” Per i documenti “con gestione NO MANOVRA” (creazione di un documento con associate le prestazioni ticket aggiuntivi + contributo digitalizzazione) Se individuato il documento ticket aggiuntivi (come avviene per il campo 33):

▪ Se "importo accertato del documento" = 0 → C_digit = 00000,00 ▪ Se "importo accertato del documento" > 0

• Se “esenzione prestazione del contributo digitalizzazione” = “non esente” → C_digit = l’importo delle prestazioni del documento del contributo digitalizzazione (prestazione cod.5406)

• Se “esenzione prestazione del contributo digitalizzazione” <> “non esente” → C_digit = 00000,00 per i documenti SSN “con gestione MANOVRA” (dbo.DocumentiLogici_tblTipoDocumentoEsterno.FLG_MANOVRA_TICKET_AGGIUNTIVI = 1)

• Importo contributo digitalizzatione relativo al documento (dbo.DocumentiLogici.Importo_ContributoDigitalizzazione)

44 DispReg Campo vuoto

45 IDmp

• se la modalità di “accesso”=01, 02 → Codice universale del medico prescrittore se valorizzato (presente al momento dell’estrazione in anagrafe medici – tabella tblMedici.CodUniversale da joing tabella di attività dbo.DocumentiLogici.MedicoAgendaCod);

• altrimenti ‘000000000000000000000000’ (24 zeri)

46 esitovf Campo vuoto



47 domicilio • =1 se almeno una delle prestazioni del documento appartiene ad un’agenda che nella descrizione ha la parola “domicilio”

• Altrimenti =0 ---- CodiceAssistito Campo uso CED

codice fiscale assistito/codice STP/codice ENI (di 16 caratteri)

• =”codice STP/ENI” se è valorizzato in campo codice STP (len(xAnagraficaBase.Cod_STP) > 0)

• per tutti gli altri casi il “codice fiscale”

---- CognomeAssistito Campo uso CED (di 50 caratteri)

---- NomeAssistito Campo uso CED (di 50 caratteri)

ARCHIVIO SPA 2 - prestazioni erogate Per ogni prestazione a ciclo del documento (raggruppato per tutti i campi dello SPA2 escluso: Lordo, dataini,datafine, contatto, dataPrenotabile, numacc,quantini) viene esportato un unico record SPA2 contenente tutte le sedute erogate.


1 Record =2

2 chiave = al campo chiave dello SPA1

3 Usl_strutt_erog Fisso "201"

4 presidio Campo StruttureAnagrafe.codStru (codice indicato nell’equipe dell’agenda della prestazione). I record con presidio non valorizzato verranno cancellati con i relativi documenti (spunta S.17)

5 speciali • Se la tipologia di elaborazione è @modalita_elab =1: classificazione delle prestazioni registrata in fase di contabilizzazione -dbo.RichiestePrestazioni_classificazione.specialita_id_CONTAB.

• Se la tipologia di elaborazione è @modalita_elab =2 o 3: classificazione da agende AgendeclassificazioneOfferta.branca Record con “speciali” non valorizzato non verranno cancellati (spunta S.18)

6 reparto Codice indicato in anagrafe agende (agende.codReparto – dall’agenda della prestazione) se non indicato (=NULL or =’’) viene valorizzato con ‘00’

7 disciplina • Se la tipologia di elaborazione è @modalita_elab =1: classificazione delle prestazioni registrata in fase di contabilizzazione -dbo.RichiestePrestazioni_classificazione.disciplina_id_CONTAB.

• Se la tipologia di elaborazione è @modalita_elab =2 o 3: classificazione da prestazioni tblPrestazioniAnagrafe.codDisciplina Se il codice disciplina è lungo 3 presente nel sistema ha come primo carattere a sinistra un numero <> da 0 (per es "522") il campo sarà valorizzato a vuoto; altrimenti verrà valorizzato con le ultime due cifre (per es "026" diventa "26. Record con “disciplina” non valorizzato non verranno cancellati (spunta S.19)

8 dataini Data erogazione della prestazione Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → data minima di erogazione delle prestazioni del ciclo

9 datafine Data erogazione della prestazione



Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → data massima di erogazione delle prestazioni del ciclo

10 contatto • = AgendePrenotazioni.dataOraInsert se ( tipopr = '1' OR tipopr = '5' OR tipopr = '8') AND prenotazioneId is not null AND dataPrenotazione<=dataErogazione

• =”00000000” se tipopr = '4'

• Se contatto =null → viene valorizzato dataErogazione Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → data minima “contatto” delle prestazioni del ciclo La spunta S.28 evidenzia i documenti che hanno almeno una prestazione con data erogazione (campo 14 “dataIni” dello SPA2) < della data “contatto” (se <> da ‘00000000’).

11 ScelUte • Se Tipopr=1 OR Tipopr=5 OR Tipopr=8 (campo 18 SPA2)

o =1 per prestazioni prenotate AND data prenotazione = data prima disponibilità della prenotazione su intera azienda

o Altrimenti = 2

• Altrimenti 9

12 Dataprenotabile • Se Tipopr=1 OR Tipopr=5 OR Tipopr=8 (campo 18 SPA2)

o Prestazione non prenotate

▪ = data erogazione (campo 14 SPA2.dataIni)

o Prestazione prenotata su percorso “colore”

▪ = data prima disponibilità relativa alla priorità della prenotazione

o Prestazione prenotata su percorso “non colore”

▪ = data prima disponibilità

o Se la prenotazione è “forzata” e se la data prenotata è < della prima disponibilità

▪ = data prenotazione

o Se la prenotazione è “non forzata” e se la data prenotata è < della prima disponibilità

▪ = data prenotazione

o Se prenotazione senza prima disponibilità

▪ Data prenotazione

(formato ggmmaaaa)

• Altrimenti 00000000

Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → data minima “dataprenotabil” delle prestazioni del ciclo

La spunta S.29 evidenzia i documenti che hanno almeno una prestazione con “data prenotabile” < della “data contatto” OR “data prenotabile” > data erogazione (campo 14 SPA2.dataIni) (se “data prenotabile” <> da ‘00000000’).

13 Tipopr Il campo viene valorizzato dopo il campo “codpres”

• =1 se la prestazione ha codice nomenclatore valido

• =8 se la prestazione “codpres” = null (e aggiorna “codpres”=codice prestazione aziendale)

• = C se prestazione pacchetto “di servizio”



= D se prestazione di dettaglio di un pacchetto

14 codpres • Se la tipologia di elaborazione è @modalita_elab =1: classificazione delle prestazioni registrata in fase di contabilizzazione –

o =RichiestePrestazioni_classificazione.nomenclatore_cod_CONTAB (e aggiorna Tipopr=1) se codice nomenclatore presente nella tabella Nomenclatore_001_Prestazioni AND prestazione aziendale presente nel listino SSN aziendale

o =RichiestePrestazioni_classificazione.nomenclatore_cod_CONTAB (e aggiorna Tipopr=8) se e prestazione aziendale presente nel listino SSN aziendale

• Se la tipologia di elaborazione è @modalita_elab =2 o 3: o = tblPrestazioniAnagrafe.nomenclatore_cod (e aggiorna Tipopr=1) se codice nomenclatore presente nella tabella

Nomenclatore_001_Prestazioni e prestazione aziendale presente nel listino SSN aziendale o = tblPrestazioniAnagrafe.nomenclatore_cod(e aggiorna Tipopr=8) se prestazione aziendale presente nel listino SSN

aziendale Se dopo i precedenti aggiornamenti il campo codpres è vuoto (spunta num.20 evidenzia i casi) viene valorizzato con il codice della prestazione aziendale (tipopr = '8', codpres = idPrestazione, branca = '0') Per riga del pacchetto si servizio “codice nomenclatore pacchetto” altrimenti codice nomenclatore prestazione di dettaglio del pacchetto

Il codice nomenclatore è considerato corretto se presente nella tabella Nomenclatore_001_Prestazioni. Elenco dei codici nomenclatori non presenti nella tabella Nomenclatore_001_Prestazioni (spunta S.25) Record con “codPres” non valorizzato non verranno cancellati (spunta S.20)

15 codcatalogo • Se Tipopr=1 (campo 18 SPA2) codice regionale della prestazione dove presente per la prestazione

(tblPrestazioniAnagrafe.CodPrestazioneRegionale)

• Altrimenti campo vuoto

16 branca • se (Tipopr=1 ) and accesso<>’04’ si valorizza con la branca ricalcolata (branca del documento) (quella ricalcolata dai flussi se il documento era da ricalcolare, mentre quella calcolata da programma se non era da ricalcolare DocumentiLogici_TMP_TESTATA.BRANCA_DOC); se branca null (succede per i documenti vecchi) si valorizza con la branca del documento (campo DocumentiLogici.idBranca)

• Altrimenti se (Tipopr=1) and accesso=’04’ si valorizza con la branca della prestazione(da tabella Richieste Prestazioni_classificazione)

• =0 se (Tipopr<>1 or or Tipopr<>8)

• Se Tipopr=8 si valorizza con la branca della prestazione(da tabella Richieste Prestazioni_classificazione)

• se la branca della prestazione <> 0 e la prestazioni in contabilizza RichiestePrestazioni_classificazione.BRANCA_CODICE=’Z’ la branca verrà valorizzata con Z

17 Numacc =001 se (Tipopr=1 or Tipopr=3 or Tipopr=8) Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → Somma delle quantità delle singole prestazioni del ciclo

18 Quantiuni 001,00 Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → Somma delle quantità delle singole prestazioni del ciclo

19 Tariffa Tariffa della prestazione singola (da richieste prestazioni importo/quantita) Per le prestazioni senza tariffa il campo verrà inizializzato a 00000,00



Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → Tariffa minima della prestazione singola della prestazione a ciclo

20 Lordo Se tipopr= D → 00000,00 altrimenti lordo=tariffa (campo 19 SPA1). Se tipopr=4 o se tipopr=1 e la prestazione specialistica è articolata in cicli → Per le prestazioni a ciclo somma importo delle singole prestazioni del ciclo

21 Convenzione fisso 0

22 compensa = 0 se Tipopr = 8 = 0 se Regresu (archivio spa1) = 999 = 0 se Accesso (archivio spa1) = 05, 07 , 08, 11 , 12 = 0 se Finalità (archivio spa1) = 20 =1 se compensa IS NULL

23 Tipoerog • = 00 se accesso (campo dello SPA1)<>11

• = tipologia medico erogatore se accesso (campo dello SPA1)= 11 AND (tipologia medico erogatore= 08 OR tipologia medico erogatore=03)

• =99 Se Tipoerog=NULL

24 Chiavespa2 Campo che consente l’individuazione univoca del record (ordinati per progressivo, tipopr) di spa2 all’interno dello stesso gruppo documento Valorizzato con un progressivo creato in fase di estrazione per ogni documento con zeri a sinistra. EsempioSPA2

Record chiave … Tipopr … Chiavespa2

2 08C12345 2 1

2 08C12345 2 2

2 08C125555 2 1

2 08C125555 2 2

25 MRA_erog Campo vuoto

26 pacchetto • Codice catalogo regionale della prestazione “pacchetto di servizio” Altrimenti campo vuoto



ARCHIVIO FED1


1 Record =1

2 Opera • = 1 per i documenti estratto per il FED la prima volta (DocumentiLogici.FLG_FLUSSI_FED_INVIATO_REGIONE=0)

• = 3 per i documenti già estratti per il FED e che devono essere rinviati (DocumentiLogici.FLG_FLUSSI_FED_INVIATO_REGIONE=1)

• = 4 per i documenti cancellati (DocumentiLogici_DEL.FLG_FLUSSI_FED_INVIATO_REGIONE=1)

• = 4 Per i documenti precedentemente estratti ma che non contengono nessun farmaco I documenti con opera=4 avranno i record dello FED1 e lo FED2 fittizio

3 Chiave = campo “chiave” dello SPA1

4 tipoIndu = campo “tipoIndu” dello SPA1 Se tipoIndu=6 verrà aggiornato con 7

5 Idutente = campo “Idutente” dello SPA1

6 Sexu = campo “Sexu” dello SPA1

7 datanasc = campo “datanasc” dello SPA1

8 cittu = campo “cittu” dello SPA1

9 Regresu = campo “Regresu” dello SPA1

10 Comresu = campo “proresu” + “Comresu” dello SPA1

11 Ulsresu = campo “Ulsresu” dello SPA1

12 Zonresu Codice delle zone sanitarie toscane se l’assistito è residente in toscana (tabella FLUSSI_SPA_0400_COMUNI_ZONE); altrimenti =0 → = campo “Zonresu” dello SPA1

13 Modero Valorizzato con il capo ‘FED_MODALITA_EROGAZIONE_COD’ nella tabella DocumentiLogici_tblTipoDocumentoEsterno

14 FkScheda = campo “chiave” dello SPA1

15 contatto =1 se documento di tipo ricetta; 3= se NRE; altrimenti=2

16 Ricetta = campo “Ricetta” dello SPA1 troncata a 15 caratteri

17 codfismp = 0000000000000000

18 Regmp = 000

19 Uslmp = 000

20 Zonmp = 0

21 Tipomp = 00

22 Regazie Fisso 090

23 Azienda = campo “Azienda” dello SPA1

24 impprest Somma importo (campo 18 FED2).

25 compensa =0 se campo regresu=999

Altrimenti =1

26 NRE = campo 46 “NRE” dello SPA1



ARCHIVIO FED2


1 Record =2

2 chiave = campo “chiave” del FED1

3 tipopres = dbo.tblCodiciStruttureStS.tipopresidio (dal presidio della struttura dell’agenda)

4 comstrut = dbo.tblCodiciStruttureStS.codCom (dal presidio della struttura dell’agenda)

5 presidio = campo “presidio” del SPA2 della prestazione a cui e collegato il farmaco

6 disciplina (ex speciali)

= campo “speciali” del SPA2 della prestazione a cui e collegato il farmaco

7 progdiv (ex reparto)

= campo “reparto” del SPA2 della prestazione a cui e collegato il farmaco

8 datapres = data documento (formato ggmmaaaa)

9 dataero = campo “dataini” del SPA2 della prestazione a cui e collegato il farmaco

10 tipoFar Tipo farmaco associato al codice farmaco (campo ‘FED_TIPO_FARMACO_COD’ nella tabella FARMACI_010_ANAGRAFE) Tipi possibili nella tabella FLUSSO_FED_015_TIPO_FARMACO

11 codfar Codice farmaco

12 targatura 0000000000

13 quantuni Quantità del farmaco erogato

14 Costo Costo unitario del farmaco somministrato ( importo/quantita)

15 fatconv • Se tipofar (campo 10 FED2)=01 OR =03 il CAMPO è valorizzato con Fatconv associato al codice farmaco (campo ‘FED_Fatconv nella tabella FARMACI_010_ANAGRAFE). Se Fatconv del farmaco non è valorizzato il campo sarà valorizzato con 1

• Altrimenti = 1

16 importo Importo del farmaco somministrato

17 servizio 00000,00

18 MRAerog valorizzato con il campo 25 dello SPA2 MRA_erog

19 Flag_innovativita 0

20 Filler1 Campo vuoto




Nel caso di opera=4 il FED2 viene valorizzato nel seguente modo:


1 Record 2

2 chiave campo “chiave” del FED1

3 tipopres 02

4 comstrut 014

5 presidio 11011A

6 disciplina 026

7 progdiv 00

8 datapres data documento (formato ggmmaaaa)

9 dataero 00000000

10 tipoFar 03

11 codfar X

12 targatura 0000000000

13 quantuni 00001,00000

14 Costo 000000,00000

15 fatconv 1

16 importo 000000,00

17 servizio 00000,00

18 MRAerog Campo vuoto



DOCUMENTAZIONE TECNICA ________________________________________________________________________________________________ Rif: SysPrest_MANUALE_TECNICO.docx

Progetto: SysPrest v.3

________________________________________________________________________________________________ CSIO Società di informatica e organizzazione s.r.l. pagina 86 di 276

I campi di tipo data sono formattati come testi di 8 caratteri del tipo ggmmaaaa. Gli importi sono formattati come testi di 8 caratteri del tipo 00000,00. Se la prestazione ha quantità>1 verranno inseriti più record SPA2

Quadrature SPA1

• (+) Numero documenti da elaborare

• (-) Numero documenti cancellati in quanto non contabilizzati (spunta S.1.0)

• (-) Numero documenti cancellati in quanto non corretti: tutte le prestazioni del documento non hanno una accesso confermato (spunta S.1.1)

• (-) Numero documenti cancellati in quanto non corretti: almeno una delle prestazioni del documento ha un accesso non indicato o non confermato (spunta S.1.2)

SPA2

• (-)numero documenti cancellati per campo “presidio” (campo 6) non corretto (spunta S.17)

• (=) numero documenti inviati




Spunte SPA1

• S.1.0 elenco dei documenti estraibili ma non elaborati perché non contabilizzati

• S.1.1 elenco dei documenti estraibili ma non elaborati perché nessuna pestazione con accesso confermato

• S.1.2 elenco dei documenti estraibili ma non elaborati perché una o più pestazioni hanno accesso non confermato o non indicato

• S.3 elenco assistiti con sesso errato (campo 7); i record non vengono eliminati ma valorizzati con valore di default

• S.4 elenco assistiti con data nascita non indicata o non è una data (campo 8); i record non vengono eliminati ma valorizzati con valore di default

• S.5 elenco assistiti con codice cittadinanza non corretto (campo 9) ; i record non vengono eliminati ma valorizzati con valore di default

• S.6 elenco assistiti con codice comune residenza non indicato

• S.7 elenco assistiti con codice comune di residenza = '099999' e la cittadinanza ='100'

• S.8 elenco dei documenti contabili con codice “accesso” (campo 16) non valido

• S.10 elenco documenti con il campo “ricetta stampata elettronicamente” non valido (campo 40); i record non vengono eliminati ma valorizzati con valore di default.

• S.12 elenca documenti con accesso= “01” e il campo RicSug non valorizzato (campo 23)

• S.24 elenco documenti con il campo “CodIdeUteEurop” non valido (campo 36)

• S.14 elenco documenti con il campo “finalita” non valido (campo 17)

• S.16 elenco documenti con il campo “tipoassist” non valido (campo 41)

• S.26 elenco documenti con dataSped (campo 22) successiva alla massima data di erogazione delle prestazioni

• S.27 elenco documenti (con accesso=’01’) che hanno almeno una prestazione con data erogazione (campo 14 “dataIni” dello SPA2) < della data della documento DataPres (campo 31 SPA1) per documenti con data valorizzata.

SPA2

• S.17 elenco documenti con prestazioni con il campo “presidio” non valorizzato (campo 4); i record non validi verranno eliminati (intero documento)

• S.18 elenco documenti con prestazioni con il campo “speciali” non valorizzato (campo 5)

• S.19 elenco documenti-prestazione con prestazioni con il campo “disciplina” non valorizzato (campo 7)

• S.20 elenco documenti-prestazione con prestazioni con il campo “codPres” non valorizzato (campo 14); i record non validi non verranno eliminati ma valorizzati con il codice della prestazione aziendale

• S.25 elenco documenti-prestazione con codice nomenclatore non presente nel nomenclatore

• S.28 elenco documenti che hanno almeno una prestazione con data erogazione (campo 8 “dataIni” dello SPA2) < della data “contatto” (campo 10 SPA2 se <> da ‘00000000’).

• S.29 elenca i documenti che hanno almeno una prestazione con “data prenotabile” (campo 12 dello SPA2) < della “data contatto” OR “data prenotabile” > data erogazione (campo 8 SPA2.dataIni) (se “data prenotabile” <> da ‘00000000’).

Le viste W_FLUSSI_SPA_V2_0080_SPUNTA_S_1_1, W_FLUSSI_SPA_V2_0081_SPUNTA_S_1_2 e W_FLUSSI_SPA_V2_0081_SPUNTA_S_1_0 permettono di verificare i documenti scartati dell’ultima elaborazione lanciata rispettivamente dalle spunte S.1.1, S.1.2 e S.1.0




Annullamento elaborazione FLUSSI SPA

Elaborazione cod. “SPA_DEL” - Annullamento ultima elaborazione definitiva flussi SPA (MDB access pgmFlussiSPA_ANNULLA.mdb)

L’elaborazione permette di annullare l’ultima estrazione flussi SPA effettuata in modalità definitiva.

L’elaborazione fa in modo che vengano ripristinati i flag (FLG_FLUSSI_SPA_ELAB, FLG_FLUSSI_SPA_INVIATO_REGIONE, FLG_FLUSSI_SPA_DA_RIESTRARRE, FLG_FLUSSI_FED_INVIATO_REGIONE) nelle tabelle DocumentiLogici e DocumentiLogici_DEL come erano prima della elaborazione.

Ricettari

Elaborazione cod. “RicOut” - Generazione file mensile Ricettari (MDB access pgmRic.mdb)

Il programma di estrazione dei ricettari per la regione (rispetta le norme contenute nel file Flusso_RIC_tracciato_ALL1.pdf) ragiona nel seguente modo:

L’elaborazione per la gestione dei ricettari è una funzione schedulata su SysPrest. Si tratta di una elaborazione mensile. Sono previsti tredici periodi per ogni anno. Il tredicesimo periodo estrae tutto quello che non è stato ancora estratto per periodi precedenti a quello selezionato.

L’elaborazione estrae i ricettari consegnati ai medici non ancora inviati in regione (tabella RICETTARIO_010_ANAGRAFE where FLG_ELAB_INVIATO_REGIONE=0).

E’ possibile scegliere se effettuare una elaborazione definitiva o in bozza. Il sistema riconosce automaticamente qual è il periodo da elaborare, valutando quale sia stato l’ultimo periodo elaborato definitivamente (MAX(Periodo) AS Periodo FROM dbo.RICETTARIO_200_FLUSSO_RIC_ELAB_PERIODI). Nel caso di elaborazione definitiva, una volta terminata l’elaborazione, non è più possibile ripeterla per il periodo in oggetto. In caso di bozza (non definitiva) invece il sistema produce il medesimo output ma rimane sullo stesso periodo anche nell’elaborazione successiva.

I file di output generati a seguito dell’elaborazione si trovano sul server delle elaborazioni, a partire dalla cartella \txt_V3\Ricettari, nella sottocartella relativa al periodo elaborato: supponiamo ad esempio di aver elaborato il mese di gennaio 2005, l’output sarà nella sottocartella \txt_V3\Ricettari\2005out01\ricettari_200501.txt

Nella tabella RICETTARIO_210_FLUSSO_RIC_OUT viene mantenuta traccia dei dati estratti.

I ricettari con periodo di consegna < del periodo di elaborazioni vengono inviati in regione con opera=2 “integrazione”.

Attenzione: le consegne e la revoca di consegna non sono tramesse. Una volta estratto il ricettario è inviiato in regione non verrà più riestratto.




Recupero ricettari (SOSPESA)

L’elaborazione verrà effettuata manualmente utlizzando il file Visualizzazione Ricettari.mdb che si trova nella cartella C:\csioweb\sysprestv3\Elaborazioni\MdbAppoggio nel server dei report.

Dopo l’apertura del file mdb, importare i file di ricupero comedescritto nella procedura seguente:

- eseguire le seguenti query di svuotamento delle tabelle temporanee: 10_appo_input, 10_appo_input_tblMedici, 10_appo_Output, 10_appo_tblMedici, 10_Input_RIC_01012006_31122006, 10_tblRecordErrati

- scegliere dal menu File > Carica dati esterni > Importa..

- scegliere come origine File di testo (*.txt;*.csv;*.tab;*.asc)

- navigare nella cartella C:\csioweb\sysprestv3\Elaborazioni\MdbAppoggio e scegliere il file corrispondente al mese che si vuole importare

- nella finestra che compare cliccare su Avanzate… > Specifiche.. poi Apri e OK

- una volta impostata la specifica di importazione scegliere Avanti > Avanti

- come destinazione scegliere Tabella esistente > la tabella Input_RIC_01012006_31122006

- finita l’importazione di un file, ripetere la procedura per tutti i file che si desidera importare

- esegurie in seguenza tutte le query presenti nel file mdb partendo da 15_002_appo_input

Alla fine della procedura descritta sopra gli eventuali record errati si troveranno nella tabella tblRecordErrati.




Estrazione 730 - precompilato

L’elaborazione di estrazione delle spese sanitarie sostenute dai Cittadini per la predisposizione del 730-precompilato dovrà essere effettuata accedento al sistema Rcubo:

URL del sistema http://172.16.100.150/rcubo/

Username:sysprest - password: sysprest

L’utente “sysprest” è abilitato alle sole funzioni di elaborazione (attenzione l’utente vedrà tutte le elaborazioni di Rcubo)

Elaborazioni (sorgente \RCubo\SS_ETL\EMP\ETL\SysPrest)

• Num.482 “SysPrest: Elaborazione estrazione 730 – BOZZA” (esteree i dati in modalità bozza per il periodo indicato)

• Num.483 “SysPrest: Elaborazione estrazione 730 – DEFINITIVA” (esteree i dati e classifica il periodo elaborato come “definitivo” non può quindi essere più riestratto)

L’elaborazione estrae l’elenco dei movimenti di cassa (entrate e uscite) registrati in un determinato mese e associati a specifiche causali. Vengono estratti:

• i movimenti di cassa associati a causali con il campo “tipo spesa” valorizzato e solo quelli associati ad assistiti (selezionati dall’anagrafe) per i quali il campo “codice fiscale” risulti valorizzato al momento dell’estrazione.

• I movimenti di cassa associati alle casse di zona “Empolese” e “IRIS”

• I movimenti di cassa con importo totale incassato <= 99999.99

• I movimenti di cassa con anno data ricevuta diverso dall’anno del periodo di elaborazione

• sono stati esclusi: o i movimenti di cassa con associato un documento che abbia avuto altri movimenti di cassa con “anno

ricevuta” diverso dall’anno del periodo di elaborazione. o I movimenti di cassa per cui l’assistito ha espresso opposizione all’invio. Per i movimenti di rimborso, in

fase di estrazione, l’opposizione da parte dell'assisto all'invio del movimento al 730 precompilato viene ereditata dalla ricevuta “da rimborsare” indicata dall’operatore.

o I movimenti di cassa diretti e i movimenti di rimborso diretti con data registrazione <=18/01/2016

(data dell’installazione del nuovo modulo di cassa con la rilevazione della ricevuta di rimborso) o I movimenti relativi ad una rendicontazione che ha un movimento di storno dove non è valorizzato il

numero di ricevuta di rimborso (il caso si verifica in quanto il campo della ricevuta di rimborso vene

rilevato dal modulo di cassa dal 19/01/2016). La spunta “S.30” evidenzia i casi.

L’elaborazione prevede il parametro mese e i mesi dovranno essere schedulati in sequenza in quanto nei movimenti di storno deve essere indicata la ricevuta d’incasso (esempio non si potrà estrarre il periodo 201502 se non è stato precedentemente elaborato in modo definitivo il periodo 201501). Attenzione: se non è stato indicato un periodo corretto, l’elaborazione termina correttamente (ma non elabora nessun dato), ma la spunta “S.0 Periodo NON CORRETTO” segnala l’errore.

Per i movimenti di storno i campi relativi alla ricevuta di rimborso vengono valorizzati con i dati della ricevuta di rimborso indicati nel modulo di cassa (il numero di ricevuta rimborsata non viene quindi più individuata dal sistema). Il movimento di storno viene estratto se il relativo movimento da rimborsare e stato precedentemente estratto o e presente nell’estrazione corrente. Una apposita spunta evidenzia i movimenti di storno con “ricevuta da rimborsare” non estratta per il 730 (spunta S.20)

ATTENZIONE: si potrebbe quindi verificare che vengano estratti movimenti che successivamente sono stati stornati, ma il movimento di storno non viene estratto (casi evidenziati nella spunta




Spunte elaborazione (di movimenti che non verranno estratti):

• S.00 Periodo NON CORRETTO (si verifica se non è stato indicato il periodo corretto)

• S.01 Ci sono causali di storno (associate ad un tipo di spesa) definite come principali

• S.10 ricevuta rimborso non presente nel sistema

• S.20 Ci sono movimenti di storno la cui ricevuta non alimenta l'estrazione per il 730.

• S.30 Ci sono movimenti di storni senza ricevuta rimborso

• S.40 Ci sono movimenti di cassa con il campo CodiceSSA non valorizzato Di seguito il tracciato prodotto con le relative note di valorizzazione:

Campo Tipo Dim. Obbligatorio Commento Note valorizzazione CSIO

codiceRegione varchar(3) 3 Si Codice della Regione = 090 (valore fisso)

codiceASL varchar(3) 3 Si Codice dell'azienda = 201 (valore fisso)

codiceSSA varchar(6) 6 Si Codice struttura che emette il documento

Codice STS di struttura indicato nella struttura dell’operatore che ha eseguito la registrazione del movimento di cassa (spunta S.40)

pIva varchar(11) 11 Si Partita Iva della struttura che emette il documento fiscale

= 06593810481 (valore fisso)

dataEmissione date(8) 8 Si Data di emissione del documento fiscale (formato ggmmaaaa)

Data di registrazione del movimento di cassa

dispositivo number(3) 3 Si Codice del dispositivo che emette la ricevuta =001 (valore fisso)

NumDocumento varchar(50) 50 Si Id della spesa di pagamento/rimborso

Progressivo annuo della ricevuta di cassa + ‘-‘ + anno di ricevuta di cassa per i movimenti con il “prefisso ricevuta” valorizzato (per le ricevute doppie) verrà valorizzato nel seguente modo: “progressivo” + ‘-‘ + “prefisso ricevuta” + ‘-‘ + “anno ricevuta”

dataPagamento date(8) 8 Si Data di pagamento/rimborso (formato ggmmaaaa)

Data documento di cassa

flagPagamentoAnticipato varchar(1) 1 No Flag per pagamento anticipato =1 se “data documento” < “data emmisione”; altrimenti campo vuoto

flagOperazione varchar(1) 1 Si Tipo di operazione (flag)

I= per movimenti di cassa con tipo operazione Entrata R= per movimenti di cassa con tipo operazione Uscita

cfCittadino varchar(16) 16 Si Codice fiscale del soggetto Codice fiscale dell’assistito presente in anagrafe al momento dell’estrazione

tipoSpesa varchar(2) 2 Si Natura dell'importo “Tipo spesa” indicata nell’anagrafica della causale relativa al movimento di cassa

flagTipoSpesa varchar(1) 1 No Flag per evidenziare particolari tipologie di spesa

“Flag tipo spesa” associato al “tipo spesa” indicato nell’anagrafica della causale relativa al movimento di cassa

importo number(7,2) 8 Si

Importo del pagamento/rimborso (formato iiiii,dd) con il carattere “,” come separatore per i decimali con riempimento di caratteri “0” a sinistra, allineando il numero a destra (es.: 00023,12).

Inoltre per i movimenti di rimborso l’importo deve essere indicato con segno positivo

Importo totale del movimento di cassa (complessivo di iva, bollo e ENPAV)

Rimborso pIva varchar(11) 11 No Partita Iva della struttura che emette il documento fiscale

Campo valorizzato se il record si riferisce ad una ricevuta di storno = 06593810481 (valore fisso)

Rimborso dataEmissione date(8) 8 No Data di emissione del documento fiscale (formato ggmmaaaa)

Campo valorizzato se il record si riferisce ad una ricevuta di storno = Data documento di cassa della relativa ricevuta d’incasso del movimento di storno

Rimborso dispositivo number(3) 3 No Codice del dispositivo che emette la ricevuta

Campo valorizzato se il record si riferisce ad una ricevuta di storno =001 (valore fisso)

Rimborso NumDocumento varchar(50) 50 No Id della spesa di pagamento/rimborso

Campo valorizzato se il record si riferisce ad una ricevuta di storno = Progressivo annuo + ‘-‘ + anno di ricevuta di cassa della relativa ricevuta d’incasso del movimento di storno




Campo Tipo Dim. Obbligatorio Commento Note valorizzazione CSIO

pro_id varchar(2) 2 Si Codice ID della procedura di cassa all'interno dell'azienda

=01 (valore fisso)

pro_key varchar(50) 50 No Composizione della chiave di identificazione del record della procedura

Id univo del movimento di cassa

dat_cognome varchar(50) 50 No Cognome dell’assistito Cognome dell’assistito presente in anagrafe al momento dell’estrazione

dat_nome varchar(50) 50 No Nome dell’assistito Nome dell’assistito presente in anagrafe al momento dell’estrazione

dat_sesso varchar(1) 1 No Sesso dell’assistito M=Maschio / F=Femmina

Sesso dell’assistito presente in anagrafe al momento dell’estrazione

dat_data_nascita date(8) 8 No Data di nascita dell’assistito (formato ggmmaaaa) Se non indicata inserire 00000000.

Data di nascita dell’assistito presente in anagrafe al momento dell’estrazione

com_id varchar(6) 6 No Codice istat del comune di nascita dell’assistito

Codice Istat comune di nascita dell’assistito presente in anagrafe al momento dell’estrazione

dat_note varchar(250) 250 No Note utili per rintracciare il record, soprattutto per l’eventuale fase di completamento.

Campo non valorizzato

Il file prodotto è in formato txt a lunghezza fissa e ha il nome composte nel seguente modo: 730_<periodo elaborazione AAAAMM>.txt. Il file estratto è posizionato nel server ip. 172.16.100.240 nella cartella C:\CSIO\SysPrest\SysP_Repo\730 (la cartella SysP_Repo è condivisa). Utilizzare l’utente username: sysprest730 – password:_730_sysP@2016 per accedere ai file estratti (in sola lettura).




PROCEDURE MANUTENZIONE E BACKUP SERVER DBSQLCAP1

Manutenzione giornaliera

E’ schedulata tramite “Operazioni pianificate di Windows” con le seguenti modalità

Nome operazione pianificata Account esecuzione LUN MAR MER GIO VEN SAB DOM

SysPrest manutenzione giornaliera CUPDM01\csio 00:30 00:30 00:30 00:30 00:30 00:30 00:30

Il backup full dei database avviene nel percorso: D:\MSSQL\Backup\CSIO\SysPrest.

Nella cartella è presente sempre l’ultimo backup (il sistema sovrascrive il file precedente). Per il db SysPrestV3_Empoli, AnagrafeAsl, SysPrestV3_Empoli_CRM, SysPrestV3_Empoli_INTEGRAZIONE se il relativo backup full è anadato a buon fine il sistema elimina i relativi file di backup del log delle transazioni orarie.

Ordine Nome db Backup log transazioni

Verifica integrità

Compattazione Ricostruzione indici

Backup completo

Compressione backup

Eliminazione log transazioni precedenti

Troncamento log transazioni

1. AnagrafeAsl - X - X X X X -

2. SysPrestV3_Empoli_CRM - X - X X X X -

3. SysPrestV3_Empoli_INTEGRAZIONE - X - X X X X -

4. SysPrestV3_Empoli_DW - X X X X X - X

5. SysPrestV3_Empoli - X - X X X X -




Manutenzione oraria E’ schedulata tramite “Operazioni pianificate di Windows” con le seguenti modalità

Nome operazione pianificata Account esecuzione tutti i giorni

SysPrest manutenzione oraria CUPDM01\csio alle 05 di ogni ora

Il backup degli log delle transazioni dei database avviene nel percorso: D:\MSSQL\Backup\CSIO\SysPrest.

Nella cartella è presente sempre l’ultimo backup (il sistema sovrascrive il file precedente).


Verifica integrità


Backup completo

Compressione backup



1. AnagrafeAsl X - - - - X - -

2. SysPrestV3_Empoli_CRM X - - - - X - -

3. SysPrestV3_Empoli_INTEGRAZIONE X - - - - X - -

4. SysPrestV3_Empoli X - - - - X - -

Manutenzione settimanale

E’ schedulata tramite “Operazioni pianificate di Windows” con le seguenti modalità

Nome operazione pianificata Account esecuzione Domenica

SysPrest manutenzione settimanale CUPDM01\csio 10:00

Il backup completo dei database avviene nel percorso: D:\MSSQL\Backup\CSIO\SysPrest\Settimanale.

Nella cartella è presente sempre l’ultimo backup (il sistema sovrascrive il file precedente).


Verifica integrità


Backup completo

Compressione backup



1. SysPrestStorico - X X X X X - X

2. SysPrestStorico_v2 - X X X X X - X



5. TEST_SysPrestV3_Empoli - X X X X X - X

6. TEST_SysPrestV3_Empoli_CRM - X X X X X - X

7. TEST_SysPrestV3_Empoli_INTEGRAZIONI

- X X X X X - X

8. TEST_SysPrestV3_Empoli_DW - X X X X X - X




Ridondanza backup su supporto remoto a carico ASL Backup a carico dell’USL dei percorsi “C:\” e “D:\”:

• con le esclusioni di: o File = "C:/pagefile.sys" o File = "C:/TEMP" o File = "D:/MSSQL/Backup/CSIO/"

• su nastro: o Run = Differential 1st sun at 20:05 o Run = Full 4th sun at 20:05

• e contemporaneamente su disco: o Run = Full 2nd sun at 20:05 o Run = Differential 3rd sun at 20:05 o Run = Differential 5th sun at 20:05

backup a carico dell’USL della cartella "D:/MSSQL/Backup/CSIO/" con la seguente schedulazione:

• Run = Full 2nd sun at 20:05

• Run = Differential 3rd sun at 20:05

• Run = Differential 5th sun at 20:05

• Run = Incremental hourly at 0:30




PROCESSI SCHEDULATI

OPERAZIONE TIPO SERVER FREQUENZA PIANIFICATA

ALLE ORE INVIO

E-MAIL INVIO E-MAIL

RIEPILOGATIVA

SysPrest 21 – Schedulatore Integrazione Anagrafe

• processo che ogni 12 secondi chiama 3 volte la p_INTEGRAZIONE_ANAG_100_S_SCHEDULATORE

SQL Server Agent 172.16.100.240 ogni 12 secondi

dalle 00.00.00

alle 23.59.00

NO

SysPrest 24 - Schedulatore integrazione Erogato

• processo che ogni minuto chiama per 10 volte la P_INTEGRAZIONE_S_1050_ELAB_INS

SQL Server Agent

172.16.100.240

ogni minuto

dalle 00.00.00

alle 23.59.00

NO

SysPrest 35 – IRIS Schedulatore Integrazione notifiche pagamenti

• processo che ogni minuto chiama per 5 volte la p p_IRIS_100_PAGAMENTI_SCHEDULATORE

SQL Server Agent

172.16.100.240

ogni minuto

dalle 00.00.00

alle 23.59.00

NO

SysPrest 26 – Integrazione – Erogato con errore

• processo che ogni 2 ore manda mail di notifica dei messaggi di erogato dell’integrazione elaborati con errore

SQL Server Agent

172.16.100.240

ogni 2 ore

dalle 00.00.00

alle 23.59.00

SI SI

SysPrest 32 - Integrazione anagrafe – Rischedulazione

• classificazione dei messaggi anagrafe lato server da rielaborare SQL Server Agent

172.16.100.240

Ogni ora

dalle 00.00.00

alle 23.59.00

NO

SysPrest 34 – IRIS Pendenze rinvio per variazione anagrafica

• processo che ogni minuto chiama per 1 volta la P_INTEGRAZIONE_S_1050_ELAB_INS

SQL Server Agent

172.16.100.240

ogni minuto

dalle 00.00.00

alle 23.59.00

NO

SysPrest 36 - Integrazione verifica automatica MSG con errore

SQL Server Agent

172.16.100.240

Ogni 30 minuti

dalle 00.00.00

alle 23.59.00

NO

SysPrest 37 - Conticki prep tx – PRESC

• per 10 msgid (da tabella [CTK-PRESC].[INVIO] prepara XML del corpo del messaggio nella tabella [CTK].[TRASMISSIONE]

SQL Server Agent

172.16.100.240

Ogni 10 secondi

dalle 00.00.00

alle 23.59.00

SI

SysPrest 38 - Conticki prep tx - PREN ** SOSPESO ** SQL Server Agent 172.16.100.240 ------- -------




SysPrest 39 - Conticki prep tx – EROG

• per 5 msgid (da tabella [CTK-EROG].[INVIO] prepara XML del corpo del messaggio nella tabella [CTK].[TRASMISSIONE]

SQL Server Agent

172.16.100.240

Ogni 15 secondi

dalle 00.00.00

alle 23.59.00

NO

SysPrest 40 - Conticki smista rx + espandi PRESC

• smista i messaggi riecvuti nelle specifiche tabelle -> chiama storede procedure [CTK].[p001_SmistaRicezione] smista 20 msgid

• espande il dettaglio delle prescrizioni ricevute → chiama storede procedure [CTK-PRESC].[p002_EspandiRx] espande 10 msgid

SQL Server Agent 172.16.100.240

Ogni 10 secondi

dalle 00.00.00

alle 23.59.00

NO

SysPrest 42 - Conticki espandi rx - PREN ** SOSPESO ** SQL Server Agent 172.16.100.240 ------- -------

SysPrest 43 - Conticki espandi rx – EROG per 5 msgid


Ogni 15 secondi

dalle 00.00.00

alle 23.59.00

NO

SysPrest 14 - Notifica prenotazione spostate -

• invio email con l’elenco delle prenotazioni spostate utilizzando la funzione “sposta prenotati” non ancora comunicate

SQL Server Agent

172.16.100.240

ogni ora da 01:00:00

alle 23:00:00

SI

SysPrest 29 - SysPrest 29 - Integrazione - Inizializza coda prenotazione-

• invio email con l’elenco agende inviate ad integrazione

SQL Server Agent

172.16.100.240

ogni 2 ore da 01:00:00

alle 23:00:00

SI NO

SysPrest 45 - Conticki prep dati - AGEN ** SOSPESO ** SQL Server Agent 172.16.100.240 ------- -------

SysPrest 09 - Storicizzazione log integrazioni: prenotazioni – prenotato/contabilizzato/erogato- ricettario

• processo che trasferisce in tabelle di storico le operazioni di prenotazione registrate nella giornata ed eventualmente lette da altri sistemi, i dati dell’integrazione (prenotato/contabilizzato/erogato), dati log ricettario

SQL Server Agent

172.16.100.240

giornaliera 21.00.00 SI

SysPrest 44 - Conticki prep dati - EROG SQL Server Agent 172.16.100.240 giornaliera 22.00.00 SI

SysPrest 07 - Preparazione dati OLAP Attività -

• scarico prestazioni registrate SQL Server Agent

172.16.100.240 giornaliera 21.30.00 SI

SysPrest 28 - Preparazione dati OLAP pubblicazione prestazioni



SysPrest 22 - Notifica assistiti con lo stesso codice aziendale ed errori

• email con elenco assistiti con lo stesso codice aziendale e con gli errori SQL Server Agent

172.16.100.240 giornaliera 23.00.00 SI

SysPrest 23 - Notifica prenotazioni non registrate correttamente – ricevute di cassa doppie



SysPrest 16 - Log allineamento anagrafe CRM – esenzioni assistito SQL Server Agent

172.16.100.240 giornaliera 23.30.00 SI




• Passaggio dei dati elaborati (anagrafica e sessione prenotazione) su tabelle di log

• Aggiornamento campi anagrafe assistito (FLG_DOC_DA_PAGARE - FLG_ANAG_ESENTE_TOT)

Backup DB (SysPrestV3_Empoli, AnagrafeAsl, SysPrestV3_Empoli_CRM, SysPrestV3_Empoli_INTEGRAZIONE, SysPrestV3_Empoli_DW)

operazione pianificata Windows

172.16.100.240

giornaliera 00.30.00 SI NO

SysPrest 15 - Calendario - Pulizia Tab – storicizzazione log anagrafe

• Trasporto dati calendari SysPrest

• pulizia tabelle di sessione

• dati integrazione anagrafe (client, server)

SQL Server Agent

172.16.100.240


SysPrest 18 - CUP AV Find Structure – ** SOSPESO **

• richiama il programma [root sito] \CUP_AREA_VASTA\Schedulatori\Installazione\Csio.SysPrest.CupAv.Schedulatori.FindStructure.exe

Operazione pianificata: File EXE chiamata WebService

200.1.1.20 giornaliera 03:00.00 SI

SysPrest 03 - Allineamento anagrafe CRM –

• richiama il programma crm_allineaAnag.exe in E:\CSIO-Integrazioni\Componenti\CRM\CRM_allineaAnagrafe

File EXE 200.1.1.117 giornaliera 03.15.00 SI

SysPrest 19 - CUP AV Find Working Unit – ** SOSPESO **

• richiama il programma [root sito] \ CUP_AREA_VASTA\Schedulatori\Installazione\Csio.SysPrest.CupAv.Schedulatori.FindWorkingUnit.exe


200.1.1.20 giornaliera 03:30.00 SI

SysPrest 04 - Preparazione dati OLAP Offerta disponibilità –

• alimenta tabelle con i dati necessari per l’analisi dell’offerta (i dati vengono elaborati dal calendario con data prenotazione >= data odierna)

SQL Server Agent

172.16.100.240


SysPrest 06 - Erogazione automatica prestazioni ALP/Area Pagamento

• eroga in automatico prestazioni in libera professione SQL Server Agent

172.16.100.240 giornaliera 03.45.00 SI

SysPrest 08 - Schedulazione elaborazione Flussi SPA -

• schedulazione automatica elaborazione flussi SPA (versione 2008) SQL Server Agent

172.16.100.240 giornaliera 04.00.00 SI

SysPrest 20 - CUP AV Find Virtual Service - ** SOSPESO **

• richiama il programma [root sito] \ \CUP_AREA_VASTA\Schedulatori\Installazione\Csio.SysPrest.CupAv.Schedulatori.FindVirtualService.exe


200.1.1.20 giornaliera 04:00.00 SI

SysPrest 02 - Notifica disponibilità agende non colore - SQL Server Agent 172.16.100.240 giornaliera 04.15.00 SI SI




• email con l’elenco delle tipologie-discipline di prestazion che non soddisfano il numero di accessi minimi previsti per le agende di tipo “non colore”.

SysPrest 05 - Prepara prenotazioni CUP Online -

• preparazione prenotazioni da visualizzare da CUP online SQL Server Agent

172.16.100.240 giornaliera 04.30.00 SI

Generazione notturna dei calendari delle agende

• richiama il programma [root sito] \componenti\dll\RigeneraAgendeAll_v2.exe

• le e-mail vengono inviate agli indirizzi presenti nella tabella AGENDE_CALENDARI_EMAIL (non è presente la funzione web per gestire i dati)

Operazione pianificata: File EXE

200.1.1.20 giornaliera 05.00.00 SI NO

SysPrest 27 – integrazione medici

• aggiorna inserisce anagrafica medici SQL Server Agent

172.16.100.240 giornaliera 05.30.00 SI SI

SysPrest 31 – integrazione anagrafe – comuni – ASL - stati

• aggiorna inserisce anagrafica medici SQL Server Agent

172.16.100.240 giornaliera 05.45.00 SI

SysPrest 25 - Disattivazione utenti non collegati al sistema da x giorni-

• disattivazione utenti non collegati al sistema da x giorni SQL Server Agent

172.16.100.240 giornaliera 06.15.00 SI SI

SysPrest 17 - CUP AV Workslot - – ** SOSPESO **

• generazione workslot SQL Server Agent

172.16.100.240 giornaliera 06.30.00 SI

SysPrest 12 - Schedulazione report TAT -

• Processo SQL Server per la schedutazione automatica di alcuni report (report n. 321 – 322 – 329 - 334 per il monitoraggio dei tempi d’attesa)

SQL Server Agent

172.16.100.240


SysPrest 30 - Notifica prestazioni senza disponibilità SQL Server Agent 172.16.100.240 giornaliera 07.00.00 SI

SysPrest 10 - Notifica disponibilità agende colore -

• Email con l'elenco delle tipologie-discipline di prestazioni che non soddisfano il numero di accessi minimi previsti per fascia di priorità B e D

SQL Server Agent

172.16.100.240

giornaliera 07.15.00 SI SI

SysPrest 11 - Notifica agende senza disponibilità -

• invio e-mail ad operatori abilitati con elenco delle agende che non hanno giorni più disponibili alla prenotazione

SQL Server Agent

172.16.100.240

giornaliera 07.30.00 SI SI

SysPrest 01 - Mail attività processi -

• email con l’elenco degli esiti dei processi elaborativi notturni SQL Server Agent

172.16.100.240 giornaliera 08.00.00

E-mail riepilogativa esito processi

SysPrest 33 - Notifica controllo offerta

• invio e-mail ad operatori abilitati con elenco delle agende che soddisfano la condizione di controllo

SQL Server Agent 172.16.100.240 giornaliera 13.00.00 SI SI

Generazione giornaliera dei calendari delle agende colore

• richiama il programma [root sito] \componenti\dll\RigeneraAgendeColoreAll_v2.exe

Operazione pianificata:

200.1.1.20 giornaliera 13:30.00 SI




• le e-mail vengono inviate agli indirizzi presenti nella tabella AGENDE_CALENDARI_EMAIL (non è presente la funzione web per gestire i dati

File EXE

CRM: Schedulatore SchedulatoreCRM

• NON ATTIVO

• richiama il programma [root sito] \ componenti \ SchedulatoreCRM \

SchedulatoreCRM \ bin \ Release \ SchedulatoreCRM.exe

• le e-mail vengono inviate agli indirizzi presenti nella tabella AGENDE_CALENDARI_EMAIL (non è presente la funzione web per gestire i dati

File EXE 200.1.1.20




SERVER INVIO EMAIL

Server TO FROM smtpserver smtpserverport

DBSQLCAP1 (ip 172.16.100.240 SQL 2008)

Vari processi SQL di SysPrest

Indirizzo e-mail di operatori SysPrest abilitati alla notifica

[email protected] postfixrelay.usl11.net 25

Manutenzione SysPrest operazioni pianificate Windows

[email protected] [email protected]


Rcubo processi applicativi

Indirizzo e-mail di operatori Rcubo abilitati alla notifica


SQLCLUS1 (ip 200.1.1.20 server web SysPrest)

Exe generazione calendari

Indirizzo e-mail di operatori SysPrest abilitati alla notifica


CUP ON LINE (ip 172.16.123.20)

Coldifusion (invio ricevuta prenotazione e conferma registrazione)

Indirizzo e-mail assistiti [email protected] postfixrelay.usl11.net

SRVREPCUP (ip 172.16.100.15 server elaborazioni + report)

NESSUN INVIO EMAIL

CUPMED (IP. 172.16.123.21 SysPrest su internet)

NESSUN INVIO EMAIL

PPCUP (ip 172.16.100.56 ambiente di test web e integrazioni)

NESSUN INVIO EMAIL

http://postfixrelay.usl11.net/









COLLEGAMENTO SYSPREST – CRM

Premessa

l’integrazione è tra il sistema SysPrest e il sistema CRM (Call Center). L’integrazione prevede un flusso di dati unidirezionale da SysPrest verso il sistema CRM. L’anagrafica di riferimento sarà quella di SysPrest e la chiave univoca per l’integrazione sarà il codice assistito SysPrest. Indirizzi web service: http://crmsiebel.usl11.net/eai_ita/start.swe?SWEExtSource=SecureWebService&S

WEExtCmd=Execute&Username=SYSPREST&Password=SYSPREST

Come generare i file dll utili per richiamare il web service

Per generare i file dll c’è bisogno di:

• Visual studio 2005;

• L’indirizzo per collegarsi al web service oppure un file wsdl. Nel nostro caso Siebel (società che mette a disposizione il web service) ci ha fornito 2 files wsdl che si trovano sul server di sviluppo al percorso ..\SysPrestEmpoli\componenti\dll_CRM\ I files sono:

• AggiornamentoContatto.wsdl

• AggiornamentoRichiesta.wsdl Per creare le dll utili per collegarsi al web service seguire i seguenti step:

• Aprire il prompt dei comandi di visual studio 2005 al percorso: Start/ Tutti i Programmi/ Microsoft Visual Studio 2005/ Visual Studio Tools/ Prompt dei comandi di Visual Studio 2005. Se non ci fosse il link che ho appena citato basta andare nel prompt dei comandi generico (Start/ Tutti i Programmi/ Accessori/ Prompt dei comandi) e digitare il seguente per corso: C:\Programmi\Microsoft Visual Studio 8\SDK\v2.0\Bin\.

• Digitare i seguenti comandi modificando i percorsi in base a dove si trovano i file di input e output: wsdl /out:C:\...\SysPrestEmpoli\componenti\dll_CRM\proxyClassAggContattoCRM.cs /namespace:contattocrm C:\...\SysPrestEmpoli\componenti\dll_CRM\AggiornamentoContatto.wsdl

In poche parole il comando ha la seguente sintassi: wsdl /out:[percorso del file .cs che verrà creato con il relativo nome] /namespace:[nome con cui verrà richiamata la libreria contenuta nella dll] [percorso e nome del file di origine .wsdl]

• Nel percorso specificato verrà generato un file .cs che nel nostro caso è proxyClassContattoCRM.cs. Da quest’ultimo file verrà generata la relativa dll.

• Digitare i seguenti comandi modificando i percorsi in base a dove si trovano i file di input e output: csc /out:C:\...\SysPrestEmpoli\componenti\dll_CRM\contattocrm.dll /t:library /r:System.XML.dll /r:System.Web.Services.dll C:\...\SysPrestEmpoli\componenti\dll_CRM\proxyClassAggContattoCRM.cs

In poche parole il comando ha la seguente sintassi: csc /out:[percorso del file .dll che verrà creato con il relativo nome] t:library /r:System.XML.dll /r:System.Web.Services.dll [percorso e nome del file di origine .cs]

• Nel percorso specificato verrà generato un file dll, che nel nostro caso è contattocrm.dll Per poter richiamare i metodi del web service basta:

• (se non esiste già) creare nel nostro sito la cartella “Bin”

• Inserire all’interno della cartella “Bin” i file dll

• Digitare nell’intestazione del nostro file cs interno al sito: using [namespace] Nel caso del CRM, i nomi scelti per i vari file sono i seguenti:

• AggiornamentoContatto.wsdl → proxyClassAggContattoCRM.cs → contattocrm.dll (namespace: contattocrm)

http://crmsiebel.usl11.net/eai_ita/start.swe?SWEExtSource=SecureWebService&SWEExtCmd=Execute&Username=SYSPREST&Password=SYSPREST

http://crmsiebel.usl11.net/eai_ita/start.swe?SWEExtSource=SecureWebService&SWEExtCmd=Execute&Username=SYSPREST&Password=SYSPREST




• AggiornamentoRichiesta.wsdl → proxyClassAggRichiestaCRM.cs → richiestacrm.dll (namespace: richiestacrm)

Apertura in contensto di SysPrest

La pagina exeLogIn_CRM.asp (senza interfaccia grafica) è a disposizione del CRM per eseguire l’identificazione su SysPrest. La pagina si aspetta i seguenti parametri:

• wRichiestaCRM: numero della richiesta CRM (dato di tipo testo obbligatorio)

• wAssisttoCRM: codice assistito CRM (dato di tipo testo obbligatorio)

• wUserName: userName per log-in SysPrest (dato di tipo testo obbligatorio)

• wAssistitoSysPrest: codice assistito SysPrest (dato di tipo testo non obbligatorio)

• wAssistitoNome: nome dell’assistito (dato di tipo testo obbligatorio)

• wAssistitoCognome: cognome dell’assistito (dato di tipo testo obbligatorio)

• wAssistitoDataNascita: data di nascita dell’assistito nel formato MM/GG/AAAA (dato di tipo testo non obbligatorio)

L’identificazione dell’utente viene effettuata solo sulla UserName (per utenti attivi). La struttura dell’operatore è impostata fissa da sistema con il valore “CUP - CONTACT CENTER – URP” (kaUtenteStruttura = "106638" e con ruolo fisso “Call Center” (kaUtenteRuolo = "CAL"). Se l’identificazione utente non và a buon fine verrà visualizzata un messaggio di errore. Se l’operatore dovesse uscire dal sistema ed entrare normalmente con la pagina di SysPrest predisposta per la log-in, non sarà più attivo il collegamento con il CRM per quella sessione. Infatti così facendo il cookie previsto per la sessione CRM verrà cancellato, non consentendo all’operatore di spedire le prenotazioni al web service CRM. Se i dati inviati non sono formalmente corretti verrà visualizzata un messaggio di errore. In base al valore del campo “wAssistitoSysPrest” verrà visualizzata una pagina iniziale differente.

• Se “wAssistitoSysPrest” è di tipo testo oppure è vuoto, il sistema visualizzerà la pagina di ricerca dell’assistito con alcuni campi già valorizzati (es: cognome, nome, anno di nascita).

• Se “wAssistitoSysPrest” è di tipo numerico, ed è già presente nell’anagrafe SysPrest allora il sistema visualizzerà la pagina di prenotazione con l’assistito già impostato.

NB ➔ Se l’assistito trasmesso esiste in SysPrest (contatto esistente) è importante che l'operatore NON utilizzi per la prenotazione un assistito diverso da quello individuato. Altrimenti l’anagrafe CRM/SysPrest verrebbe disallineata, ovvero non ci sarebbe più corrispondenza tra l'assistito che effettua la prenotazione (e quindi la Richiesta di servizio) su Siebel e quello che effettua la stessa prenotazione su Sysprest.

Note per l’implementazione: Verrà creata una nuova alla tabella CRM_010_SESSIONE (nell’apposito database) che memorizzerà i dati inviati dal CRM. Il numero della sessione CRM verrà memorizzata in un COOKIE. E’ stata predisposta una pagina di log-in utile per simulare la log-in di un utente CRM, ovvero prova_exeLogIn_CRM.asp.




Il flusso seguito dalla pagina di log-in è il seguente:

Nel caso si verifichi un

qualsiasi errore verranno

svuotati parte dei cookies e nella pagina

verrà visualizzato il messaggio di

errore

exeLogIn_CRM.asp = il sistema SIBEL chiama una pagina web messa a disposizione da SysPrest, inviando alcuni parametri

Svuotamento Cookies

Verifica parametri obbligatori

Eseguo dbo.p_CRM_022_sessione_new per creare una nuova sessione CRM

Ruolo = CAL Struttura = 106638

Applicazione/ yU_PrenotaEsterni/

y_Main.asp

Recordset per la verifica del parametro username; esecuzione della stored procedure

dbo.p_Utenti_032_log_operatore; valorizzazione del cookie dell’operatore

Applicazione/ yU_Assistito/ yAssistito.asp

Recordset per prendere i dati dell’assistito spediti da CRM (in base al cookie della sessione CRM)

SI NO Il codice assistito è numerico e non è

vuoto?

Valorizzo i cookies con javascript (sessione CRM, ruolo, struttura)

Recordset per valorizzare il cookie dell’assistito tramite javascript solo se il codice di quest’ultimo è presente in SysPrest

Inizializzazione variabili

Applicazione/ yU_StartFrame_CRM.asp = imposta i frame iniziali di SysPrest

Applicazione/ yU_MainCorpo_CRM.asp




Funzione di “prenotazione“

Registrata la prenotazione il sistema controllerà che se l’utente che ha effettuata la prenotazione è di tipo CRM. In questo passaggio verrà controllata la valorizzazione del cookie relativo alla sessione CRM. Se l’esito del controllo è positivo allora verranno chiamati 2 componenti utili a comunicare con il web service messo a disposizione da Sibel tramite protocollo SOAP RPC:

• AggiornamentoContatto (assistito)

• AggiornamentoRichiesta (prenotazione) Il web service “AggiornamentoRichiesta” prevede i seguenti parametri:

descrizione campo input

formato note

SRNumber varchar (64) Numero richiesta CRM

Flag char(1) Flag cancellazione prenotazione: valori possibili ("Y" o N")

Num number(22) Numero prenotazione SysPrest

DataP datetime(7) Data prenotazione formato (mm/dd/yyyy hh:mm:ss)

LuogoPreparaz varchar (2000) Il campo verrà valorizzato con i seguenti dati concatenati (separati dal carattere “|”):

• descrizione struttura

• descrizione equipe

• note della sede

• medico dell’agenda

• preparazioni (per ogni prestazione prenotata) Se i dati da inviare hanno una lunghezza > 2000 caratteri verranno troncati.

Tipo varchar(50)

Il campo verrà valorizzato con i seguenti dati concatenati (separati dal carattere “|”):

• Descrizione prestazione aziendale

• importo Se i dati da inviare hanno una lunghezza > 50 caratteri verranno troncati.

Il web service “AggiornamentoContatto” prevede i seguenti parametri:

descrizione campo input

formato Note

RowId varchar (15) Numero contatto CRM

IDSysprest varchar(30) Codice assistito SysPrest

SysPrest manterrà un log delle prenotazioni effettuate che non sono state trasmesse per eventuali errori di trasmissione. Sarà previsto uno schedulatore che invierà le prenotazioni non ancora trasmesse.

Funzione di “cancellazione prenotazione“

Come per la creazione, anche nella cancellazione di una la prenotazione, il sistema controllerà che se l’utente che ha effettuata la prenotazione è di tipo CRM. In caso positivo chiamerà i 2 componenti utili per comunicare con il web service CRM. L’unica distinzione tra cancellazione di una prenotazione e la creazione di una prenotazione è il parametro “FLAG”. Se quest’ultimo è impostato a “Y” la prenotazione verrà cancellata, se è impostato a “N” verrà creata una nuova prenotazione. SysPrest manterrà un log delle prenotazioni cancellate che non sono state trasmesse per eventuali errori di trasmissione. Sarà previsto uno schedulatore che invierà le prenotazioni non ancora trasmesse.




Il flusso di una prenotazione

Il flusso di una prenotazione è il seguente:


qualsiasi errore verrà visualizzato

a video

“Pagina.asp” - exe utile a creare/ cancellare una prenotazione

Stored procedure utili a creare /cancellare una prenotazione

Verifica se il cookie relativo alla sessione CRM è valorizzato in caso positivo si prosegue con la chiamata ai componenti CRM

Tramite il Progressivo leggo in tabella i dati opportunamente formattati

Con una stored procedure inserisco un nuovo record nella tabella CRM_012_SESSIONE_PRENOT; restituzione di un Progressivo

Controllo se idPrenotazione, idAssistito, idSessioneCRM sono valorizzati; chiamo alcuni metodi di ComponenteCRM.cs

Eseguo la chiamata al metodo per l’aggiornamento Richiesta

Se la trasmissione dei dati al web service è andata a buon fine aggiorno il flag del relativo Progressivo

“Pagina.aspx” - exe utile all’aggiornamento della richiesta

Tramite il Progressivo leggo in tabella i dati opportunamente formattati

Controllo se idProgressivo è valorizzato; chiamo alcuni metodi di ComponenteCRM.cs

Eseguo la chiamata al metodo per l’aggiornamento Contatto

“Pagina.aspx” - exe utile all’aggiornamento del contatto

Se la trasmissione dei dati al web service è andata a buon fine aggiorno il flag del relativo Progressivo

“Pagina.asp” – pagina di ritorno


qualsiasi errore verrà visualizzato

a video




Schedulatore CRM (NON attivo)

SysPrest manterrà un log delle prenotazioni effettuate/cancellate che non sono state trasmesse per eventuali errori di trasmissione. Sarà previsto uno schedulatore che invierà le prenotazioni non ancora trasmesse. Il file eseguibile, ovvero SchedulatoreCRM.exe, non può funzionare da solo. Nella stessa cartella in cui risiese questo file devono essere presenti le due dll utili per il collegamento al web service. Questa elaborazione verrà inserita tra le operazioni pianificate di windows. Ogni volta che viene eseguito, il processo spedirà un’e-mail agli utenti abilitati al feedbak 2.

SI


qualsiasi errore l’elaborazione viene interrotta e verrà spedita una mail con la

descrizione dell’errore. Nel caso si verifichi

un errore durante la

chiamata del web service

l’elaborazione prosegue

ugualmente.

NO

SI NO

INIZIO

Definizione di variabili e di una connessione a SysPrest CRM

Apertura connesione

Inserisco in una variabile tutti gli indirizzi di posta elettronica degli utenti abilitati al feedbak 2

Chiusura connessione

Il recordset

Il recordset

Aggiorno il relativo flag in tabella

Chiamata web Service per l’aggiornamento Contatto

Aggiorno il relativo flag in tabella

Chiamata web Service per l’aggiornamento Richiesta

FIN

Apertura connesione

Recordset utile ad individuare tutti i record non trasmessi

Chiudo recordset Chiusura connessione

e rilascio risorse

Spedizione mail per avvenuta elaborazione




Elaborazione notturna per l’allineamento anagrafe CRM

Il batch ogni notte alimenta due tabelle (EIM_CONTACT e EIM_CON_DTL - database ORACLE), messe a disposizione del sistema CRM, con le variazioni anagrafiche effettuate nel giorno (aggiornamenti effettuati su SysPrest). Inoltre verranno comunicate le fusioni di più posizioni anagrafiche (aggiornamenti ricevuti da Patidok).

Non vengono aggiornati i campi del numero di telefono. Viene inviata nel giorno una sola variazione per assistito (viene quindi inviata l’ultima modifica). Il progetto sviluppato con visual basic 6.0 è stato spezzato in due moduli: modElab, modUtiliy. Alla partenza il progetto inizia a eseguire la routine “Main” presente nel modulo “modElab”. Nel modulo “modUtility” sono presenti alcune funzioni per la gestione del log (“scriviLog”, “impostaStep”), e per la gestione degli errori (“scriviLog”, “impostaErrore”, “inviaMail”). Per la connessione al database vengono utilizzati 2 DSN:

• "SysPrestV3Empoli_CRMConnect.dsn" = file di connessione al database SysPrestV3_Empoli_CRM (tipo di database = SQL SERVER)

• "Sibel_CRMConnect.dsn" = file di connessione al database di SIBEL (tipo di database = ORACLE)

Il processo crea un file nella cartella “log” (all’interno del percorso in cui si trova il file eseguibile) che contiene i passaggi principali dell’elaborazione. L’esito del processo viene notificato nell’email riepilogativa delle elaborazioni notturne (processo SQL SysPrest 01 - Mail attività processi -). E’ schedulato un processo di SQL Server che la sera sposta in tabelle di LOG i dati da tabella:

CRM_002_OUTPUT_ANAGRAFE, CRM_003_OUTPUT_FUSIONE, CRM_010_SESSIONE, CRM_012_SESSIONE_PRENOT,

su tabelle CRM_002_OUTPUT_ANAGRAFE_LOG, CRM_003_OUTPUT_FUSIONE_LOG, CRM_010_SESSIONE_LOG, CRM_012_SESSIONE_PRENOT_LOG

le righe trasmesse a CRM la notte prima, lasciando le righe che non sono state trasferite. Il programma segue i seguenti step:




SI


qualsiasi errore la funzione esegue le

routine “impostaErrore”, “scriviLog” e prosegue con l’esecuzione

dello step successivo. Solo alla fine del processo

eseguirà “inviaMail”

SI


qualsiasi errore la funzione esegue le

routine “impostaErrore”

, “scriviLog”, “inviaMail” e

non prosegue con

l’esecuzione degli step successivi

NO

SI NO

INIZIO

Inizializzazione variabili

Connessione a SysPrest

Esecuzione stored procedure: p_CRM_002_format_anagrafe

Esecuzione stored procedure: p_CRM_004_output_anagrafe

Apro recordset che legge i dati presenti nella tabella di appoggio CRM_002_OUTPUT_ANAGRAFE alimentata dalle stored procedure

Il recordset

Il recordset

Inserisco record nella tabella EIM_CONTACT

Inserisco record nella tabella EIM_CON_DTL

Aggiorno flag nella tabella SysPrest CRM_002_OUTPUT_ANAGRAFE

progressivo CRM=1

Aumento progressivo

Chiudo connessione CRM

Chiudo connessione SysPrest

FIN

Connessione a CRM

Cancellazione tabelle CRM

Chiudo recordset

Chiudo recordset

SI

NO

SI NO Il recordset

Il recordset

Inserisco record nella tabella EIM_CONTACT

Aggiorno flag nella tabella SysPrest CRM_003_OUTPUT_FUSIONE

Aumento progressivo

Pagina.aspx - exe utile all’aggiornamento del contatto




Le tabella che verranno alimentate in CRM sono le seguenti:

Tabella Interfaccia Colonna Interfaccia Tipo Lunghezza Descrizione Valore Fisso

EIM_CONTACT ROW_ID varchar 15 Progressivo univoco riga

EIM_CONTACT IF_ROW_STAT varchar 30 "FOR IMPORT"

EIM_CONTACT IF_ROW_BATCH_NUM number 9 2

EIM_CONTACT PARTY_UID varchar 100 Codice assistito SysPrest da eliminare

EIM_CONTACT PARTY_TYPE_CD varchar 30 "Person"

EIM_CONTACT CON_PERSON_UID varchar 100 Codice assistito SysPrest da eliminare

EIM_CONTACT MANAGE_PERSON_UID varchar 100 Codice assistito SysPrest da mantenere

Tabella Interfaccia Colonna Interfaccia Tipo Lunghezza Descrizione Valore Fisso

EIM_CONTACT ROW_ID varchar 15 Progressivo univoco riga

EIM_CONTACT IF_ROW_STAT varchar 30 "FOR IMPORT"

EIM_CONTACT IF_ROW_BATCH_NUM number 9 1

EIM_CONTACT PARTY_UID varchar 100 identificativo univoco ID SYSPREST

EIM_CONTACT PARTY_TYPE_CD varchar 30 "Person"

EIM_CONTACT CON_PERSON_UID varchar 100 identificativo univoco ID SYSPREST

EIM_CONTACT CON_FST_NAME varchar 50 Nome

EIM_CONTACT CON_LAST_NAME varchar 50 Cognome

EIM_CONTACT CON_BIRTH_DT Date 7 Data di nascita formato dd/mm/yyyy

EIM_CONTACT CON_ALIAS_NAME varchar 50 Descrizione comune di nascita

EIM_CONTACT CON_COMMENTS varchar 255 Descrizione Comune di Residenza

EIM_CONTACT ADDR_ADDR varchar 200 Indirizzo

EIM_CONTACT ADDR_CITY varchar 50 Descrizione Comune di Residenza

EIM_CONTACT ADDR_ZIPCODE varchar 30 CAP comune residenza

EIM_CONTACT ADDR_STATE varchar 10 Sigla provincia comune residenza

EIM_CONTACT CON_SEX_MF varchar 30 Sesso "S" o "M"

EIM_CONTACT CON_HOME_PH_NUM varchar 40 Telefono (nel formato +39PrefissoNumero)

EIM_CONTACT CON_CELL_PH_NUM varchar 40 Cellulare (nel formato +39PrefissoNumero)

EIM_CONTACT CON_WORK_PH_NUM varchar 40 Telefono (nel formato +39PrefissoNumero)

EIM_CONTACT CON_ALT_PH_NUM varchar 50 Cellulare (nel formato +39PrefissoNumero)

EIM_CON_DTL ROW_ID varchar 15 Progressivo univoco riga

EIM_CON_DTL IF_ROW_STAT varchar 30 "FOR IMPORT"

EIM_CON_DTL IF_ROW_BATCH_NUM number 9 1

EIM_CON_DTL PARTY_UID varchar 100 identificativo univoco ID SYSPREST

EIM_CON_DTL PARTY_TYPE_CD varchar 30 "Person"

EIM_CON_DTL EXT_ATTRIB_09 character 1 "Y"

EIM_CON_DTL EXT_ATTRIB_34 varchar 50 Codice Fiscale

EIM_CON_DTL EXT_ATTRIB_35 varchar 50 Codice Sanitario




Definizione delle entità del database

Per permettere il corretto funzionamento del progetto il database SysPrestV3_Empoli_CRM deve comprendere le seguenti tabelle (il dettaglio delle tabelle sono riportate nel paragrafo “4. disegno del database”) :

• Tabella CRM_001_APPO_ANAGRAFE

• Tabella CRM_002_OUTPUT_ANAGRAFE

• Tabella CRM_002_OUTPUT_ANAGRAFE_LOG

• Tabella CRM_004_AMBIENTE_ELABORAZIONE

• Tabella CRM_003_OUTPUT_FUSIONE

• Tabella CRM_003_OUTPUT_FUSIONE_LOG

• Tabella CRM_010_SESSIONE

• Tabella CRM_010_SESSIONE_LOG

• Tabella CRM_012_SESSIONE_PRENOT

• Tabella CRM_012_SESSIONE_PRENOT_LOG




Flusso integrazione

SysPrest visualizza la funzione di prenotazione con l’assistito già impostato L’operatore seleziona la funzione di prenotazioni con le attuali

modalità

L’operatore effettua la prenotazione su SysPrest. Il sistema invoca il web service “AggiornamentoRichiesta” di SIBEL comunicando i dati della prenotazione: - numero richiesta SIBEL - Assistito SysPrest - Numero prenotazione - Data ora prenotazione, descrizione della prestazione, preparazione, luogo di erogazione ( tutti i dati attualmente

presenti nella stampa della ricevuta di prenotazione) - Flag cancella = NO Il sistema invoca anche il web service “aggiornamnetoContato” di sibel per comunicare l’assistito:

• Codice assistito SysPrest

• Codice richiesta Sibel SysPrest mantiene un log delle prenotazioni effettuate che non sono state trasmesse per eventuali errori di trasmissione. Sarà previsto uno schedulatore che invierà le prenotazioni non ancora trasmesse.

Codice assistito SysPrest è numerico ?

SI

Identificazione utente effettuata?

SysPrest visualizza una pagina di errore “utente e password non corretti”

NO

SI

SysPrest visualizza il modulo di ricerca dell’assistito con alcuni i campi di ricerca già impostati (es. cognome, nome, anno nascita se indicata la data di nascita). L’operatore selezionerà un’assistito o deciderà di registrare una nuova posizione anagrafica)

NO

Il CRM riceve un telefonata di un assistito che richiede un prenotazione

Il sistema SIBEL chiama una pagina web messa a disposizione da SysPrest inviando i seguenti dati:

- numero richiesta SIBEL (obbligatorio) - assistito SIBEL (obbligatorio) - assistito SysPrest (non obbligatorio) - nome, cognome (obbligatorio) - data nascita assistito (non obbligatorio) - identificazione utente: username (obbligatorio)

Controllo dati inviati (es. campi obbligatori non valorizzati), corretti?

SI

NO




INTEGRAZIONE CUP AREA VASTA

Premessa

Lo scopo del progetto è l’integrazione del CUP di primo livello (CUP1L) in uso presso l’Azienda USL n. 11 di Empoli nel CUP metropolitano di secondo Livello (CUP2L).

REQUISITI TECNOLOGICI E PRESTAZIONALI

L’integrazione bidirezionale, è effettuata mediante il protocollo XML-RPC secondo le specifiche tecniche inviate dall’azienda ISED (rif. All.1). Le funzionalità esposte dai CUP sono fruibili mediante una connessione HTTP via TCP/IP su porta non predefinita.

I componenti sviluppati da CSIO sono realizzati con tecnologia Microsoft Windows 2000, ambiente DOT .NET e pagine ASP e ASPX.

Ogni richiesta, conferma o annullamento inviato dai CUP2L a CUP1L ed ogni informazione inviata dl CUP1L a CUP2L viene ad essere registrata dal sistema in modo da avere un Log delle operazioni effettuate e delle informazioni trasmesse.

REQUISITI FUNZIONALI

Dal punto di vista funzionale i metodi utilizzati a tale scopo dal CUP1L sono divisi in due categorie:

• metodi per la lettura delle informazioni di base del CUP1L

• metodi per la richiesta delle transazioni di prenotazione e revoca nel CUP1L.

I metodi implementati dal CUP2L hanno invece lo scopo di permettere a CUP1L di usufruire dei servizi di prenotazione a livello metropolitano.

Nell’allegato “20050303 Specifiche_CUPMet_ALL3.doc” sono presenti le specifiche dei metodi implementati (lato server e lato cliente).




Integrazione tra CUP1L e CUP2L (Lato Server)

➢ getDriverInfo (informazioni relative al driver)

➢ findService (ricerca informazioni sulle prestazioni messe a disposizione del CUP1L al CUP2L)

➢ findStructure (ricerca informazioni sui presidi e sulle strutture gestite dal CUP1L) ➢ findWorkingUnit (ricerca informazioni sulle unità eroganti del CUP1L: es. medici,

reparti, macchine, equipe, ecc.) ➢ getModifiedDiares (aggiornamenti sulle informazioni delle agende messe a

disposizione del CUP1L al CUP2L) ➢ getModifiedWorkSlots (aggiornamenti delle fasce di lavoro delle unità eroganti) ➢ getAppointments (appuntamenti disponibili in una data fascia di lavoro) ➢ getBookingInfo (informazioni sulle prenotazioni) ➢ findBooking (ricerca delle prenotazioni) ➢ book (prenotazione di un appuntamento) ➢ revoke (revoca di una prenotazione) ➢ move (spostamento di un appuntamento prenotato)

• Integrazione tra CUP2L e CUP1L (Lato Client) ➢ getAvailabilities (interrogazione delle disponibilità) ➢ getAppointments (appuntamenti disponibili per una determinata sessione di lavoro) ➢ book (prenotazione di un appuntamento) ➢ revoke (revoca un prenotazione) ➢ move (spostamento di un appuntamento prenotato) ➢ getBookingInfo (informazioni sulle prenotazioni) ➢ findBooking (ricerca delle prenotazioni) ➢ findStructure (ricerca informazioni sui presidi e sulle strutture gestite dal CUP2L) ➢ findWorkingUnit (ricerca informazioni sulle unità eroganti del CUP2L: es. medici,

reparti, macchine, equipe, ecc.) ➢ findVirtualService (ricerca informazioni sulle prestazioni virtuali del CUP2L)

• funzioni modificate/nuove sul sistema SysPrest ➢ Prestazioni ➢ Agende:

• per indicare se l’agenda può essere prenotata dal CUP AREA VASTA

• per agende colore quale fascia può essere prenotata dal CUP AREA VASTA ➢ Struttura

• Per inserire l’indirizzo ➢ Gestione Operatori ➢ Ricerche- Ricerche prenotazione

• Per indicare se la prenotazione e di tipo CUP AREA VASTA ➢ Prenotazione per il SSN ➢ Cancellazione prenotazione ➢ Agende-Sposta pren Cup Av ➢ Ricerche-Ricerche pren Cup Av




Standard adottato

I metodi implementati sono realizzati mediante tecnologia DOT.NET.

Interfaccia applicativa

L’interfaccia applicativa di questa specifica è espressa in termini di metodi XML-RPC. Ogni metodo è caratterizzato da un identificativo univoco e da una lista di parametri di tipo eterogeneo (semplice o composto). Il risultato dell’elaborazione della richiesta può essere fornito mediante un unico valore di ritorno di tipo semplice o composto. Ogni metodo prevede l’identificazione dell’utente. Segnalazioni di anomalie Il protocollo XML-RPC prevede che l’esecuzione di un metodo possa segnalare un errore in alternativa al risultato. Questa specifica prevede le seguenti segnalazioni di errore, che possono essere emesse da qualsiasi metodo:

Codice errore

Spiegazione Descrizione errore

1 Parametro obbligatorio mancante.

Nella struttura di ingresso, non è stato fornito un parametro necessario all’esecuzione.

Nome del parametro mancante.

2 Tipo del parametro errato.

Nella struttura di ingresso, è stato indicato un parametro con un valore di tipo diverso da quello previsto.

Nome del parametro indicato con un tipo errato.

3 Errore di autenticazione. Credenziali non valide. Utente non identificato

4 Errore interno Descrizione errore

Log chiamate

Per memorizzare il log dal lato server è stato definito un nuovo metodo LOGG.scriviDB il quale ha il compito di registrare i dati richiesti (input) e i dati inviati (output) sulla tabella “CUP_AV_S_022_LOG”. La classe LOGG è stata definita nella dll “CookComputing.XmlRpc.dll” e chiama la Stored Procedure "P_CUP_AV_S_0010_LOG". Il metodo LOGG.scriviDB viene richiamato dalla classe XmlRpcHttpServerProtocol.cs all’interno del metodo HandleHttpRequest (rif. All.8).

Valori di Default di C#

Il linguaggio C# prevede un inizializzazione di default se i campi non lo sono stati prima. Dati di tipo int, double o boolean, DateTime hanno come valori di dafault, rispettivamente: 0; 0,0 ; false; 01/01/0001 00:00. Questo poterebbe creare delle incomprensioni nella comunicazione e nella corretta comprensione dei dati inviati. Le specifiche comunicateci dalla ISED prevedono che un dato non valorizzato non debba essere passato, cioè non comparire nel XML assolutamente (!!). Il problema sorge in questi casi, perché C# va ad inizializzare per Default questi campi.




Integrazione tra CUP1L e CUP2L (Lato Server)

CUP.getDriverInfo

Il metodo fornisce le informazioni relative al driver e l’identificazione dell’utente.

La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.getDriverInfo” chiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs”. La condizione di validità dell’utente viene verificata confrontando i dati trasmessi con quelli presenti nei campi “UserName” e “Password” nella tabella di SysPrest “Utenti_001_Operatori”. Inoltre l’utente in questione deve essere attivo, ovvero il campo “flgSospeso“ deve essere uguale a 0. Attualmente non è testata la condizione di validità della Password (utente sempre attivo).

Se l’identificazione ha avuto successo il metodo fornisce le informazioni relative al driver. I dati vengono in parte estratti dalla tabella: “CUP_AV_010_AMBIENTE” permette di visualizzare solo le informazioni relative al CUP di Empoli. L’elenco dei metodi supportati viene invece fornito chiamando un metodo esterno “MetodiSupportati” presente nella pagina: “Metodi.cs”, metodo restituisce l’elenco dei metodi estratti dalla tabella “CUP_AV_015_METODI”

Vengono di seguito elencati i parametri di ingresso e di uscita previsti dal metodo. Tipo Campi Tipo Descrizione Obb

Input

User <Credential> Credenziali dell’utente del sistema di primo livello da utilizzare per il controllo degli accessi.

SI

Ouput

DriverInfo \\VSRV3\Dev\Documenti\Documents and SettingsmariaenricaDesktop" l - _Struttura_<DriverInfo><DriverI

nfo>

Informazioni relative al driver. SI

I parametri sono strutturati secondo la seguente specifica:

Struttura <Credential> Campo Tipo Descrizione

SystemId string Identificativo del sistema chiamante.

UserName string Identificativo dell’utente.

Password string Password dell’utente.

ClientId string IDENTIFICATIVO DELLA MACCHINA USATA DALL’UTENTE.

Struttura <DriverInfo> Campo Tipo Descrizione Note CSIO Output

DriverName string Nome del driver. Tabella CUP_AV_010_AMBIENTE. DRIVER_NAME

Description string Descrizione del driver. Tabella CUP_AV_010_AMBIENTE. CUP_NAME_DSC

CUPCode string Codice del CUP. Tabella CUP_AV_010_AMBIENTE. CUP_CODE

CUPName string Nome del CUP. Tabella CUP_AV_010_AMBIENTE. CUP_NAME

Version string Versione del driver. Tabella CUP_AV_010_AMBIENTE. VERSION

Vendor string Fornitore del driver. Tabella CUP_AV_010_AMBIENTE. VENDOR

SupportedMethods array of string Lista dei metodi supportati.

Tabella CUP_AV_015_METODI

SystemDate dateTime.iso8601 Data e ora del sistema. E’ fornita secondo std ISO8601 AAAAMMGGTHH:MM:SS




Gestione dell’errore:

Nel momento dell’ identificazione dell’utente, se non sono stati trasmessi i campi obbligatori (“UseName” e “Password”) il metodo risponde con un errore di codice “1” e la relative descrizione: ➢ " Parametro utente mancante" ➢ " Parametro password mancante" ➢ " Parametri utente e password mancanti" Se l’identificazione non ha avuto successo il metodo restituisce un errore di tipo “3” e la relativa descrizione: "Utente o password errati". Se si verifica un errore interno (es. SQL) il metodo restituisce un errore di tipo “4” e la relativa descrizione

CUP.findService

Il metodo fornisce l’elenco delle prestazioni messe a disposizione dal CUP1L.

La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.findService” chiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs”.

Se l’identificazione ha avuto successo il metodo fornisce le informazioni sulle prestazioni messe a disposizione dal CUP1L al CUP2L (prestazioni della tabella: tblPrestazioniAnagrafe con condizione FLG_ATTIVA =1 e associate ad agende classificate FLG_CUP_AREA_VASTA =1) in funzione dei parametri di ricerca inseriti (non è possibile effettuare la ricerca per “ServiceWarning”, “CUPCode”, “ServiceAlias”, “BookableByPhone”).

E’ possibile effettuare la ricerca per descrizione della prestazione (“ServiceName”) e della preparazione (“ServiceNotes”) inserendo solo parte del testo (LIKE ‘%’ + testo ricerca + ‘%’). Se non è stato inserito alcun parametro di ricerca viene fornita l’intera lista .

Il metodo accetta in ingresso i parametri di tipo strutturato <Credential> (già descritto nel metodo precedente), <ServiceInfo> ed in uscita il parametro < ServiceInfo >.

Note: Se la ricerca è effettuata per tariffa il formato deve essere “xx,xx” (es.59,68) altrimenti se indicato con il punto (es. 59.68) il protocollo XMLRPC lo elimina. Il server riceve quindi un valore diverso da quello introdotto (es. 5968).





Input Service <ServiceInfo> Modalità di ricerca delle prestazioni. In caso in qui il parametro non viene fornito devono essere restituite tutte le prestazioni messe a disposizione dal CUP1L

User <Credential> Credenziali dell’utente del sistema di primo livello da utilizzare per il controllo degli accessi

SI

output

Service <ServiceInfo> Elenco prestazioni trovate. SI

Struttura <ServiceInfo> Campo Tipo Descrizione Note CSIO output

ServiceCode string Codice interno al CUP della prestazione.

Codice della prestazione aziendale SysPrest

CUPCode string Codice del CUP. Codice CUP della risposta dato da Tabella CUP_AV_010_AMBIENTE. CUP_CODE

ServiceNationalCode string Codice ministeriale della prestazione

Codice nomenclatore nazionale (es: 89.7) ) (dato tabella: tblPrestazioniAnagrafe. Nomenclatore_cod)

ServiceRegionalCode string Codice regionale della prestazione.

Codice nomenclatore nazionale (es: 89.7) (dato tabella: tblPrestazioniAnagrafe. Nomenclatore_cod)

ServiceName string Nome della prestazione. Descrizione della prestazione aziendale SysPrest (dato tabella: tblPrestazioniAnagrafe. Descrizione)

ServiceAlias string Eventuale sinonimo interno al CUP della prestazione.

Il campo non è valorizzato

ServiceBranch string Codice regionale della branca di appartenenza.

La branca di appartenenza è legata alla prescrivibilità, è quindi valida solo per SSN. (dato tabella: Nomenclatore_001_Prestazioni. branca)

ServicePrice double Tariffa SSN della prestazione.

Tariffa della prestazione fornita dal listino SSN valida nella data di richiesta del dato. Se la tariffa non è presente li campo assume valre 0.

BookableByPhone boolean Prenotabile telefonicamente

Fisso a TRUE ( tutte le prestazioni sono prenotabili telefonicamente).

ServiceWarning string Note rivolte all’operatore Il campo non è valorizzato

ServiceNotes string Note rivolte all’assistito o preparazione.

Preparazione standard della prestazione


Se l’identificazione dell’utente non ha avuto successo il metodo restituisce gli stessi codici di errore e le relative descrizioni viste nel metodo CUP.getDriverInfo (S.1.1).

Se viene indicato in fase di ricezione un codice di prestazione (campo “ServiceCode”) diverso da un numero intero il metodo restituisce un errore di tipo “2” e la relativa descrizione: " ServiceCode deve essere un intero".

Se la ricerca non individua alcuna prestazione, il metodo risponde con un messaggio di errore di tipo “2” e la relativa descrizione:




➢ Nessuna prestazione

Se si verifica un errore interno (es. di tipo SQL) il metodo restituisce un errore di tipo “4” e la relativa descrizione.

CUP.findStructure

Il metodo fornisce l’elenco delle strutture/presidi gestite dal CUP1L.

La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.findService” richiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs”.

Se l’identificazione ha avuto successo il metodo fornisce le informazioni sulle strutture/presidi messe a disposizione dal CUP1L ( strutture collegate ad agenda con la condizione: FLG_CUP_AREA_VASTA = 1 and flgChiusa = 0) al CUP2L in funzione dei parametri inseriti per effettuare la ricerca (non è possibile la ricerca per “CUPCode”).

La ricerca per descrizione della struttura (“StructureName”) e l’indirizzo della prestazione (“StructureAddress”) è possibile introducendo anche solo parte del testo (LIKE ‘%’ + testo ricerca + ‘%’). Se non è stato inserito alcun parametro di ricerca viene fornita l’intera lista.

Il metodo accetta in ingresso i parametri di tipo strutturato <Credential> (già descritto nel metodo precedente) , <ServiceInfo> ed in uscita il parametro < ServiceInfo >.

Vengono di seguito elencati i parametri di ingresso e di uscita previsti dal metodo.

Tipo Campi Tipo Descrizione Obb

Input Structure < StructureInfo> Modalità di ricerca delle strutture. In caso in qui il parametro non viene fornito devono essere restituite tutte le prestazioni messe a disposizione dal CUP1L


SI

output Structures

Array < StructureInfo>

Elenco strutture trovate SI

Struttura <StructureInfo>

Campo Tipo Descrizione Note CSIO output

StructureCode string Codice interno al CUP della struttura.

Codice della struttura SysPrest

CUPCode string Codice del CUP. Codice CUP della risposta dato da Tabella CUP_AV_010_AMBIENTE. CUP_CODE

StructureParent string Codice della struttura di appartenenza.

Codice della struttura “padre” SysPrest

StructureName string Nome della struttura. Descrizione della struttura

StructureAddress string Indirizzo della struttura. Dato da tabella StruttureAnagrafe. IndirizzoStruttura

StructurePhone string Telefono di riferimento della struttura(es. centralino, informazioni, ecc.)

Dato da tabella StruttureAnagrafe. TelefonoStruttura

StructurePostCode string CAP della struttura. Dato da tabella StruttureAnagrafe.CAPStruttura

StructurePlaceCode string Codice luogo della struttura. Dato da tabella StruttureAnagrafe. CodStru (codice struttura STS)





Se l’ identificazione dell’utente non ha avuto successo il metodo restituisce gli stessi codici di errore e le relative descrizioni viste nel metodo CUP.getDriverInfo (S.1.1).

Se la ricerca non individua alcuna struttura, il metodo risponde con un messaggio di errore di tipo “2” e la relativa descrizione:

➢ Nessuna struttura


CUP.findWorkingUnit

Il metodo fornisce informazioni sulle unità eroganti messe a disposizione dal CUP1L al CUP2L ( es:

equipe, agli indirizzi, ecc…).

La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.findService” richiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs”.

Se l’ identificazione ha avuto successo il metodo fornisce le informazioni sulle equipe messe a disposizione dal CUP1L (equipe collegate ad agenda con la condizione: FLG_CUP_AREA_VASTA=1 and flgChiusa=0) al CUP2L in funzione dei parametri inseriti per effettuare la ricerca (non è possibile la ricerca per “WaitingRoom”, “Location”, “Proponent”).

Ad identificazione avvenuta, il metodo fornisce le informazioni sulle equipe scelta dall’utente. Le equipe devono avere almeno una agenda abilitata al progetto (FLG_CUP_AREA_VASTA =1) e devono essere attive ( flgChiusa = 0).

La ricerca può essere effettuata inserendo anche solo parzialmente la descrizione dell’equipe o dell’ indirizzo (LIKE ‘%’ + testo ricerca + ‘%’).

I parametri di ricerca possono essere anche vuoti e nel caso in cui lo fossero tutti, cioè non è indicato alcun valore per la ricerca, il metodo risponde elencando tutte le unità eroganti messe a disposizione dal CUP1L.

Il campo ”WorkingUnitInfo.Proponent”, non essendo presente nel nostro DB, è stato posto uguale a “true”. Il client invia tale campo al server sempre valorizzato a true, anche se l’utente lo ha posto “false”.

Il metodo accetta in ingresso i parametri di tipo strutturato <Credential> (già descritto nel metodo precedente) , <WorkingUnitInfo> ed in uscita un array di tipo < WorkingUnitInfo>.



Input WorkingUnit <WorkingUnitInfo> Informazioni sulle unità eroganti da ricercare. I campi valorizzati definiscono il filtro di interrogazione.

NO


SI

output WorkingUnits

Array of < WorkingUnitInfo>

Lista delle unità eroganti trovate SI




Struttura <WorkingUnitInfo> Campo Tipo Descrizione Note CSIO output

WorkingUnitCode string Codice interno al CUP dell’ unità erogante.

Codice della equipe SysPrest

StructureCode string Codice interno al CUP del presidio.

Codice della struttura “padre” SysPrest

WorkingUnitName string Descrizione dell’unità erogante.

Descrizione della equipe

WorkingUnitAddress string Indirizzo dell’unità erogante. Dato da tabella StruttureAnagrafe. IndirizzoStruttura

WorkingUnitPhone string Telefono della struttura erogante

Dato da tabella StruttureAnagrafe. IndirizzoStruttura

WorkingUnitPostCode string CAP della struttura erogante Dato da tabella StruttureAnagrafe.CAPStruttura

WorkingUnitPlaceCode string Codice luogo dell’unità erogante.

Dato da tabella Struttura Anagrafe.CodStru ( codice struttura STS)

WaitingRoom string Sala d’attesa dell’unità erogante.


Location string Ubicazione dell’unità erogante


Proponent Bool Indica se l’unità erogante può essere o meno inviate.

Campo fisso a “True”.


Se l’ identificazione dell’utente non ha avuto successo il metodo restituisce gli stessi codici di errore e le relative descrizioni viste nel metodo dal CUP.getDriverInfo (S.1.1).

Se la ricerca non individua alcuna equipe, il metodo risponde con un messaggio di errore di tipo “2” e la relativa descrizione:

➢ Nessuna Equipe


CUP.getModifiedDiares

Il metodo fornisce le informazioni riguardanti le date di aperture, gli orari e le prestazioni delle agende messe a disposizione CUP1L al CUP2L.


Ad identificazione avvenuta, il metodo fornisce le informazioni sulle agende appartenenti all’ equipe scelta dall’utente (il campo “WorkingUnit” è infatti obbligatorio!!) messe a disposizione dal CUP1L .

Le agende devono soddisfare le seguenti condizioni: devono essere abilitate al progetto (FLG_CUP_AREA_VASTA =1); devono essere attive ( flgChiusa = 0 ) e devono avere la data di apertura valida nella data di richiesta.

Il metodo restituisce tutte le agende e non solo quelle modificate dopo l’ultima chiamata al metodo (non viene effettuato il filtro per “LastUpdate”).




Per ogni Equipe viene indicata una sola apertura ( data inizio (BeginDate di DiaryInfo) = MIN (data apertura agenda), data fine(EndDate di DiaryInfo) = MAX (data apertura Agenda). Nell’apertura sono però presenti tutte le aperture orarie delle singole agende interessate. Quindi il WorkingPlan visualizzerà per ogni giorno della settimana tanti DiaryRange quanti sono presenti per le varie agende e le varie aperture del giorno.

Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel metodo precedente), il parametro di tipo string “WorkingUnitCode” e il parametro di tipo <datetime.iso8601> “LastUpdate “ ed in uscita il parametro di tipo strutturato < DiaryInfo >.



Input WorkingUnitCode string Codice CUP1l dell’ equipe SI

LastUpdate datetime.iso8601 Data ora dell’ultimo aggiornamento SI


SI

outupt

Diaries Array < DiaryInfo>

Lista delle agende SI

Struttura < DiaryInfo>


BeginDate dateTime.iso8601 Data di inizio validità del piano di lavoro descritto da WorkingPlan.

Data apertura programmazione

EndDate dateTime.iso8601 Data di fine validità del piano di lavoro descritto da WorkingPlan.

Se non specificata si assume validità indefinita.

Data fine programmazione (se non presente valore di default 31/12/9999)

StatusCode string Stato relativo all’agenda

A = attiva;

D = disattiva..

StructureCode string Codice interno al CUP del presidio

Codice della struttura dell’agenda

WorkingUnitCode string Codice interno al CUP della unità erogante.

Codice della equipe dell’agenda

WorkingPlan <WorkingPlan> Piano di lavoro dell’agenda.

Orari dell’apertura




Struttura < WorkingPlan > Campo Tipo Descrizione

Sunday Array <DiaryRange>

Fasce orarie della domenica.

Se non specificato viene considerato come array di lunghezza 0.

Monday Array <DiaryRange>

Fasce orarie della lunedi.


Tuesday Array <DiaryRange>

Fasce orarie della martedi.


Wednesday Array <DiaryRange>

Fasce orarie della mercoledi.


Thursday Array <DiaryRange>

Fasce orarie della giovedi.


Friday < Array <DiaryRange>

Fasce orarie della venerdi.


Saturday < Array <DiaryRange>

Fasce orarie della sabato.





struttura < DiaryRange> Campo Tipo Descrizione Note CSIO output

BeginTime dateTime.iso8601 Ora inizio fascia oraria.

EndTime dateTime.iso8601 Ora fine fascia oraria

Contract int Contratto di erogazione:

1 = SSN; 2 = LP (Libera Professione).

Weeks string Stringa di 5 caratteri ciascuno dei quali può assumere i seguenti valori:

S – Settimana abilitata

N – Settimana disabilitata.

Es: SNSNN vuol dire che la fascia è da considerarsi valida nella prima e nella terza settimana del mese.

Se non specificata si assume SSSSS.

Frequenza SysPrest

0= SSSSS

1=SNNNN

2=NSNNN

3=NNSNN

4=NNNSN

5=SNSNN

6=NSNSN

7=SSSSS

8=SSSSS

9=NNNNS

Characteristic string Il campo Characteristic rappresenta una informazione che caratterizza la fascia oraria (DiaryRange).

Alcune caratteristiche possono essere: SPAZIO RISERVATO ALLE URGEZE, SPAZIO DI RECUPERO, SPAZIO MEDICO, ecc.

Il senso delle diciture è legato al servizio erogatore, esso ad ogni modo è legato alla possibilità di riservare alcune fasce secondo le esigenze di servizio.

Per default 0

ExpiryCharacteritic int Scadenza della caratteristica espressa in numero di giorni.

Rappresenta il numero di giorni a partire dall'appuntamento in cui "decade" questa caratteristica.

Questo serve per implementare un meccanismo di sblocco in maniera che, ad esempio, 3 giorni prima dell'appuntamento se ci sono ancora posti liberi questi spazi da riservati diventano spazi prenotabili da tutti.

Per default 0

Urgency string Codice urgenza:

0 – Normale

1 – Differita

2 – Urgente

3 – Massima Urgenza

Se non specificato si assume 0.

Se il campo tipoUrgenza delle agende =1 → Urgency =2 altrimenti Urgency =0

ExpiryUrgency int Scadenza dell’urgenza espressa in numero di giorni. Tale parametro è utilizzato nel meccanismo di sblocco delle fasce riservate alle urgenze.

Se 0 non vi è sblocco e la fascia risulta sempre riservata all’urgenza specificata.


Per default 0





DiaryServices array of <DiaryServiceInfo>

Prestazioni erogate nella fascia oraria

Groups array of

int

Lista delle tipologie di utenti abilitati alla prenotazione su tale fascia:

1 – Operatore di sportello;

2 – Operatore di Call Center;

3 – Utente esterno (es. farmacia);

4 – Utente struttura convenzionata.

Se non specificato l’abilitazione si intende estesa a tutte le tipologie di utenti.

Non indicato

ExpiryGroups int Scadenza dell’abilitazione espressa in numero di giorni. Tale parametro è utilizzato nel meccanismo di sblocco.

Se 0 non vi è sblocco e la fascia risulta sempre riservata alle tipologie di utenti.


Per default 0

Struttura < DiaryServiceInfo >


ServiceCode string Codice interno al CUP della prestazione.

Length int Occupazione della prestazione espressa in millesimi rispetto all’offerta della fascia oraria.

Es: Se in una fascia oraria di 1 ora vi entrano 4 prestazioni si ha Length = 250.

1000/((oratine _fascia – orainizio_fascia)/tempoSTDesecuzione)

MaxCount int Limite riferito al numero di prestazioni prenotabili per la fascia di appartenenza.

Per default 0

Sex string Sesso (“M”; “F”).

Se non specificato l’erogazione risulta valida per entrambi i sessi.

Sesso indicato nell’agenda; se “tutti” il campo non viene valorizzato

MinAge int Età minima prevista per l’erogazione espressa in mesi. Se non specificato si considera 0.

Eta inizio indicata nell’agenda

MaxAge int Età massima prevista per l’erogazione espressa in mesi. Se non specificato si considera 1800.

Eta fine indicata nell’agenda

ServicePrice double Costo della prestazione espresso nella valuta corrente riferito ad una data agenda.

Da valorizzare solo in caso di Libera Professione

Se SSN=0

Se ALP = tarriffa valida nella data di richiesta del metodo

ServiceWarning string Note rivolte all’operatore Non indicato

ServiceNotes string Note rivolte all’assistito o preparazione.

Preparazione legata all’agenda

Di seguito un esempio di un possibile messaggio di risposta alla chiamata del metodo:

Esempio:

Se per la struttura cod.xxxx e per equipe (workingUnitCode) cod.yyyy

ci sono le seguenti agende:

• Agenda cod. 1 aperta dal 01-05-2008 al 31/12/2008




Tutte le settimane il lunedì dalle 10.00 alle 12.00

Tutte le settimane il giovedì dalle 10.00 alle 12.00

Con prestazioni: P1, P2








• Agenda cod. 4 aperta dal 01/01/2008 al



<DiaryInfo>

<BeginDate>01/01/2008 →MIN (data inizio apertura agenda dell’equipe)

<EndDate>NULL →MAX (data fine apertura agenda dell’equipe)

<StatusCode>A

<StructureCode> xxxx

<workingUnitCode> yyyy

<workingPlan>

<Monday>

<DiaryRange_1> orari Agenda cod. 1

<BeginTime>10.00

<EndTime>12.00

<Weeks>SSSSS

<DiaryServices>

<DiaryServiceInfo_1>

<SeviceCode>P1

</DiaryServiceInfo_1>


<SeviceCode>P3


</DiaryServices>

</DiaryRange_1>


<BeginTime>10.00

<EndTime>12.00

<Weeks>SSSSS

<DiaryServices>


<SeviceCode>P1



<SeviceCode>P2





</DiaryServices>

</DiaryRange_2>

<DiaryRange_3> à orari Agenda cod. 3

<BeginTime>10.00

<EndTime>14.00

<Weeks>SSSSS

<DiaryServices>


<SeviceCode>P1



<SeviceCode>P2


</DiaryServices>

</DiaryRange_3>

</Monday>

<thursday>


<BeginTime>10.00

<EndTime>12.00

<Weeks>SSSSS

<DiaryServices>


<SeviceCode>P1



<SeviceCode>P3


</DiaryServices>

</DiaryRange_1>


<BeginTime>10.00

<EndTime>12.00

<Weeks>SSSSS

<DiaryServices>


<SeviceCode>P1



<SeviceCode>P2


</DiaryServices>

</DiaryRange_2>

<DiaryRange_3> à orari Agenda cod. 4

<BeginTime>10.00

<EndTime>14.00




<Weeks>SSSSS

<DiaryServices>


<SeviceCode>P1



<SeviceCode>P2


</DiaryServices>

</DiaryRange_3>

</ thursday >

</workingPlan>

</DiaryInfo>





Se l’identificazione dell’utente non ha avuto successo il metodo restituisce i codici e le descrizioni degli errori descritti nel metodo CUP.getDriverInfo (S.1.1). Se non sono stati trasmessi i campi obbligatori “WorkingUnitCode” e “LastUpdate” il metodo risponde con un errore di codice “1” e la relative descrizione:

➢ Parametro WorkingUnitCode mancante ➢ Parametro LastUpdate mancante

Se la ricerca non individua alcuna agenda , il metodo risponde con un messaggio di errore di tipo “2” e la relativa descrizione:

➢ Nessuna Equipe Se si verifica un errore interno (es. SQL) il metodo restituisce un errore di tipo “4” e la relativa descrizione.

CUP.getModifiedWorkSlots

Il metodo descrive la fascia di lavoro nelle disponibilità generate in cui una unità erogante (WorkingUnit che per il DB SysPrest corrisponde all’Equipe) opera in corrispondenza della fascia oraria definita dall’agenda. Per fascia oraria si intende l’intervallo temporale generato a fronte della corrispondente fascia oraria definita dall’agenda.

I parametri “BeginTime” ed “EndTime” della struttura <WorkSlot> devono corrispondere a quelli della fascia oraria descritta da <DiaryRange> per un dato giorno. Mentre la struttura <DiaryRange> descrive la fascia oraria riferita ad una giornata nel piano di lavoro, la struttura <WorkSlot> descrive la fascia oraria nelle disponibilità generate.


Ad identificazione avvenuta, il metodo restituisce tutte le fasce di lavoro (dati presenti nella tabella CUP_AV_C_010_WORK_SLOT valorizzata dalla elaborazione WORKSLOT descritta nel paragrafo 2.3 del presente documento). I WorkSlot restituiti devono corrispondere alle fasce orarie ( <DiaryRange>) definite nelle agende dell’unità erogante specificata, il campo “WorkingUnitCode” è infatti obbligatorio.

Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel metodo precedente), il parametro di tipo string “WorkingUnitCode” e il parametro di tipo datetime.iso8601 “LastUpdate “ ed in uscita il parametro strutturato < WorkSlot >.

Il metodo non permette di filtrare sulla data di ultimo aggiornamento, “LastUpdate”. Il client fornisce “LastUpdate “ valorizzata con la data della chiamata al metodo e il metodo non effettua alcun filtro per tale parametro.






Input WorkingUnitCode string Codice CUP1l dell’ equipe SI

LastUpdate datetime.iso8601 Data ora dell’ultimo aggiornamento SI


SI

Output

WorkSlots Array < WorkSlot>

Lista delle fasce di lavoro. (Lista completa e non solo di quelle aggiornate dopo la “LastUpdate”).

SI

Struttura < WorkSlot> Campo Tipo Descrizione Note CSIO output

WorkSlotId string Identificativo del work slot.

DateSlot dateTime.iso8601 Data a cui si riferisce la fascia di lavoro.

BeginTime dateTime.iso8601 Ora inizio fascia di lavoro.

EndTime dateTime.iso8601 Ora fine fascia di lavoro.

MaxLength int Massima offerta disponibile espressa in millesimi rispetto all’offerta complessiva della fascia oraria. Es: se in una fascia di 1 ora vi sono 15 min adiacenti allora MaxLenght =250.

Per default “0”.

StatusCode String Stato della fascia di lavoro:

D= totalmente o parzialmente disponibile;

O=totalmente occupata;

S=sospesa;

Contract Int Contratto di erogazione:

1=SSN;

2=LP (libera professione);

StructureCode string Codice interno al CUP del presidio;

WorkingUnitCode string Codice interno al CUP dell’nuità erogante;


Se l’identificazione dell’utente non ha avuto successo il metodo restituisce i codici e le descrizioni degli errori descritti nel metodo CUP.getDriverInfo (S.1.1). Se non sono stati trasmessi i campi obbligatori “WorkingUnitCode” e “LastUpdate” il metodo risponde con un errore di codice “1” e la relative descrizione:

➢ Parametro WorkingUnitCode mancante ➢ Parametro LastUpdate mancante ➢ Parametri WorkingUnitCode e LastUpdate mancanti

Se l’utente effettua la ricerca per una WorkingUnit non esistente o a cui non afferisce alcun WorkSlot il metodo risponde con un errore di tipo “2” e la descrizione:

➢ Errore: Nessun Work Slot associato

Se si verifica un errore interno (es. SQL) il metodo restituisce un errore di tipo “4” e la relativa descrizione.




CUP.getAppointments

Il metodo fornisce gli appuntamenti disponibili per un certo WorkSolt (fascia di lavoro). Il WorkSlots viene ad essere specificato mediante i campi che lo caratterizzano, (es: DateSlot o WorkSlotId) Gli appuntamenti restituiti devono garantire l’erogazione dell’intero insieme di prestazioni specificato nel parametro Services (array di <BookService>) considerando le eventuali occorrenze di una singola prestazione espresse nel campo ServiceCount della struttura <BookService>. La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.findService” chiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs”. Ad identificazione avvenuta, il metodo restituisce gli appuntamenti. Corrispondenti ai parametri inseriti dall’utente. I parametri: <Workslot>, <Prescriptions>,<Services>, <User >sono tutti obbligatori. I parametri <Prescription> e <BookService>, pur essendo obbligatori, non sono tenuti in considerazione nella ricerca dell’<Appointments>. Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel metodo precedente), il parametro strutturato <WorkSlot>, un array della struttura <Prescription> e un array della struttura <BookService>. I dati in ingresso vengono inseriti in tabelle di appoggio di SysPrest:

➢ CUP_AV_C_012_GETAPPONITMENTS_WORKSLOT; ➢ CUP_AV_C_013_GETAPPONITMENTS_PRESCRIPTION; ➢ CUP_AV_C_014_GETAPPOINTMENTS_BOOKSERVICE;

Il metodo effettua un controllo sui parametri trasmessi, per verificarne la correttezza e la effettiva disponibilità tramite la Stored Procedure “P_CUP_AV_C_0545_getAppointments_CONTROLLO”. Vengono eseguiti i seguenti controlli:

➢ Che il parametro “WorkSoltID”, se inserito, sia effettivamente presente nella tabella “CUP_AV_C_010_WORK_SLOT”.

➢ Che le prestazioni inserite siano ancora associate all’ agenda a cui si riferisce il WorkSlot.

Se i dati trasmessi sono formalmente corretti il metodo restituisce gli orari disponibili relativi al workslot richiesto valorizzando la tabella “CUP_AV_C_020_APPOINTMENT”. Se per la Workslot richiesta non c’è nessuna disponibilità il metodo genera un errore di tipo “4” con la descrizione “nessuna disponibilità”.






Input WorkSlot <WorkSlot> Fascia di lavoro SI

Prescriptions Array of <Prescription>

Lista di impegnative. SI

Services Array of <Prescription>

Lista delle prestazioni da prenotare SI


SI

Output

Appointments Array < Appointment>

Lista degli appuntamenti disponibili SI

Struttura< WorkSlot> I dati ricevuti dal server corrispondenti a questa struttura vengono memorizzati nella tabella: CUP_AV_C_012_GETAPPONITMENTS_WORKSLOT.

Campo Tipo Descrizione

WorkSlotId string Identificativo del work slot.

DateSlot dateTime.iso8601 Data a cui si riferisce la fascia di lavoro.

BeginTime dateTime.iso8601 Ora inizio fascia di lavoro.

EndTime dateTime.iso8601 Ora fine fascia di lavoro.

MaxLength int Massima offerta disponibile espressa in millesimi rispetto all’offerta complessiva della fascia oraria. Es: se in una fascia di 1 ora vi sono 15 min adiacenti allora MaxLenght =250.

StatusCode String Stato della fascia di lavoro:

D= totalmente o parzialmente disponibile;

O=totalmente occupata;

S=sospesa;


1=SSN;

2=LP (libera professione);

StructureCode string Codice interno al CUP del presidio;

WorkingUnitCode string Codice interno al CUP dell’nuità erogante;

Struttura <Prescription> I dati ricevuti dal server corrispondenti a questa struttura vengono memorizzati nella tabella: CUP_AV_C_013_GETAPPONITMENTS_PRESCRIPTION.


PrescriptionId Int Intero utilizzato per associare le prestazioni all’impegnativa in una richiesta di prenotazione.

PrescrptionNumber String Numero della prescrizione

PrescriptionDate dateTime.iso8601

Data della prescrizione

DiagnosticInquiry String Quesito diagnostico associato alla prescrizione.

Proponent String Codice dell’invariante ( unità erogante)

Exemptioncode String Importo alla prescrizione epresso nella valuta corrente.

Urgency String Codice urgenza:

0 – Normale

1 – Differita

2 – Urgente


DoctorName string Nome completo del prescrittore.

DoctorTaxCode string Codice fiscale del medico prescrittore.




DoctorRegionalNumber

string Codice regionale del medico prescrittore

DoctorAddress string Indirizzo del medico prescrittore

DoctorCAP string CAP del medico prescrittore

DoctorPlaceCode string Codice del luogo del medico prescrittore.

DoctorePhone string Numero di telefono prescrittore

Notes string Note dell’impegnativa.

Struttura < BookService> I dati ricevuti dal server corrispondenti a questa struttura vengono memorizzati nella tabella: CUP_AV_C_014_GETAPPOINTMENTS_BOOKSERVICE.

Campo Tipo Descrizione Note CSIO


0 sel la prestazione non è associata ad alcuna impegnativa

VirtualService <VirtualServiceInfo> Prestazione virtuale. La struttura <VirtualServiceInfo> dovrà contenere le scelte operate dall’utente circa le prestazioni aziendali per le quali è richiesto un appuntamento. Questo parametro è da valorizzare per le chiamte destinate al CUP2L. In questo caso ServiceCode è ingnorato.

Campo non valorizzato. I dati inseriti dall’utente non vengono memorizzati.

CUPCode String Codice del CUP al quale è riferita la prestazione individuata da ServiceCode.

ServiceCode String Codice interno al CUP della prestazione

ServiceCount int Numero di prestazioni richieste

ServicePrice double Importo alla prestazione espresso nella valuta corrente.

ServiceWarning String Note rivolte all’operatore

ServiceNotes String Note rivolte all’assistito o preparazione.

Struttura <Appointment>


AppointmentId String Identificativo univoco dell’appuntamento interno del CUP.

DateTime dateTime.iso8601 Data e ora dell’appuntamento.


1=SSN;

2=LP (Libera professione)

Regime dell’agenda

StructureCode String Codice interno al CUP del presidio.

Codice della struttura dell’agenda

WorkingUnitCode String Codice interno al CUP dell’unità erogante.

Codice della equipe dell’agenda





Se l’identificazione dell’utente non ha avuto successo il metodo restituisce i codici e le descrizioni degli errori descritti nel metodo CUP.getDriverInfo (S.1.1). Se non sono stati trasmessi i campi obbligatori “Prescription” e “BookService” il metodo risponde con un errore di codice “1” e la relative descrizione:

➢ Parametro Prescription mancante (in Prescription sono obbligatori i seguenti campi PrescriptionId, PrescrptionNumber, PrescriptionDate)

➢ Parametro BookService mancante ➢ Parametro Prescription e BookService mancanti

Se è stato trasmesso un WorkSoltId o Prestazioni non più disponibili il metodo risponde con un errore di codice “2” e la relativa dercizione:

➢ Parametro WORKSLOT errato; ➢ PRESTAZIONI non presenti in SysPrest;

Se per la Workslot richiesta non c’è nessuna disponibilità il metodo genera un errore di tipo “2” con la descrizione “nessuna disponibilità”. Se si verifica un errore interno (es. SQL) il metodo restituisce un errore di tipo “4” e la relativa descrizione.

CUP.getBookingInfo

Il metodo restituisce le informazioni di dettaglio relative alla prenotazione specificata. La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.findService” chiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs”. Ad identificazione avvenuta, il metodo, dopo il controllo sui dati ricevuti, fornisce il dettaglio della prenotazione specificata dal campo “BookingId” in ingresso. Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel primo metodo) e il parametri “BookingId”. Possono avere solo informazioni su prenotazioni prenotate dal CUP AREA VASTA. Il metodo effettua un controllo sulla correttezza del parametro “BookingId” trasmesso mediante il metodo “ControlloMetodoBookingId”. Il metodo, in particolare verifica che “BookingId” sia effettivamente presente nella tabella dei SysPrest: “AgendePrenotazioni”. I dati di dettaglio dell’Appintment_Id (“DataPrenotazione”,”OraPrenotazione”) sono estratti dalla tabella di SysPrest: “AgendePrenotazioni”.






Input BookingId <string> Identificativo CUP1L della prenotazione da ricercare.

SI


SI

Output

BookingInfo <BookingInfo> INFORMAZIONI DI DETTAGLIO DELLA PRENOTAZIONE IDENTIFICATA DA BOOKINGID

SI

Struttura < BookingInfo > Campo Tipo Descrizione Note CSIO

BookingId Int Identificativo CUP1L della prenotazione

Appointment <Appointment> Appuntamento prenotato Restituiti i dati della tabella CUP_AV_S_020_APPOINTMENT

Patient <Patient> Dati anagrafici del paziente. Restituiti i dati della tabella xAnagraficaBase

Prescriptions Array <Prescription>

Lista di impegnative associate alla prenotazione.

Progressivo prestazione con eventuale dettaglio impegnativa

BookServices Array

<BookService>

LISTA DI PRESTAZIONI PRENOTATE.

Prestazioni prenotate

StatusCode String Stato in cui può trovarsi la prenotazione:

C = confermata;

A = annullata;

F = sospesa;

E = Erogata;

N = Non erogata;

P = Erogata e Pagata;

✓ Stato A se la prenotazione è stata cancellata

✓ Stato E se almeno una delle prestazioni è stata erogata (accessoconeframato=1)

✓ Stato N se almeno una delle prestazioni non è stata erogata (accessoconeframato=0)

✓ Stato P se erogata e il documento a cui è collegata almeno una prestazione è stato pagato

Struttura < Appointment> Campo Tipo Descrizione

AppointmentId String Identificativo univoco dell’appuntamento interno del CUP.



1=SSN;







Struttura < Patient> Campo Tipo Descrizione Note CSIO

PatientId string Codice interno al CUP del paziente. Codice assistito SysPrest

HealthCode string Codice sanitario della persona

TaxCode string Codice fiscale della persona.

FirstName string Nome della persona

LastName string Cognome della persona

Sex string Sesso(“M”;”F”)

BirthDate DateTime.iso8601

Data di nascita

BirthPlaceCode string Codice del luogo di nascita

BirthPlaceName string Descrizione del luogo di nascita

BirthPlaceCountryCode

string Codice dello stato di nascita Dato non valorizzato

BirthPlaceCountryName

string Descrizione dello stato di nascita Dato non valorizzato

CountryCode string Codice dello stato di cittadinanza Cittadinanza

CountryName string Descrizione dello stato di cittadinanza

ResAddress string Indirizzo del luogo di residenza

ResPostCode String CAP del luogo di residenza

ResPlaceCode String Codice del luogo di residenza

ResPlaceName String Descrizione del luogo di residenza

ResCountryCode String Codice dello stato di residenza Dato non valorizzato

ResCountryName String Descrizione dello stato di residenza Dato non valorizzato

DomAddress String Indirizzo del luogo del domicilio

DomPostCode String CAP del luogog di domicilio

DomPlaceCode String Codice del luogo di domicilio

DomPlaceName String Descrizione del luogo di domicilio

DomCountryCode String Codice dello stato di domicilio Dato non valorizzato

DomCountyName String Descrizione dello stato di domicilio Dato non valorizzato

AslCode String Codice azienda della persona

AslName String Descrizione azienda della persona

Phone String Numero telefonico della persona

PhoneMobile String Numero telefonico della persona

PhoneRes String Numero telefonico della persona Dato non valorizzato

PhoneDom String Numero telefonico della persona Dato non valorizzato




Struttura < Prescription> Campo Tipo Descrizione Note CSIO


Progressivo tabella “richiestePrestazioni”

PrescrptionNumber String Numero della prescrizione Numero della ricetta se presente

PrescriptionDate dateTime.iso8601

Data della prescrizione Data documento contabile se presente

DiagnosticInquiry String Quesito diagnostico associato alla prescrizione.

Dato non valorizzato

Proponent String Codice dell’invariante ( unità erogante)


Exemptioncode String Importo alla prescrizione epresso nella valuta corrente.

Importo alla prescrizione tabella “richiestePrestazioni”

Urgency String Codice urgenza:

0 – Normale

1 – Differita

2 – Urgente


Default 0

DoctorName string Nome completo del prescrittore.

Nominativo del medico prescrittore se presente

DoctorTaxCode string Codice fiscale del medico prescrittore.

Codice fiscale del medico prescrittore.

DoctorRegionalNumber string Codice regionale del medico prescrittore

Codice regionale del medico prescrittore

DoctorAddress string Indirizzo del medico prescrittore

Indirizzo del medico prescrittore

DoctorCAP string CAP del medico prescrittore CAP del medico prescrittore

DoctorPlaceCode string Codice del luogo del medico prescrittore.

Codice del luogo del medico prescrittore.

DoctorePhone string Numero di telefono prescrittore Dato non valorizzato

Notes string Note dell’impegnativa. Dato non valorizzato




Struttura <BookService> Campo Tipo Descrizione Note CSIO


0 sel la prestazione non è associata ad alcuna impegnativa

Progressivo tabella “richiestePrestazioni”

VirtualService <VirtualServiceInfo> Prestazione virtuale. La struttura <VirtualServiceInfo> dovrà contenere le scelte operate dall’utente circa le prestazioni aziendali per le quali è richiesto un appuntamento. Questo parametro è da valorizzare per le chiamte destinate al CUP2L. In questo caso ServiceCode è ingnorato.

Campo non valorizzato.

CUPCode String Codice del CUP al quale è riferita la prestazione individuata da ServiceCode.

ServiceCode String Codice interno al CUP della prestazione

Codice della prestazione aziendale

ServiceCount int Numero di prestazioni richieste Quantità

ServicePrice double Importo alla prestazione espresso nella valuta corrente.

ServiceWarning String Note rivolte all’operatore Dato non valorizzato

ServiceNotes String Note rivolte all’assistito o preparazione.



Se l’identificazione dell’utente non ha avuto successo il metodo restituisce i codici e le descrizioni degli errori descritti nel metodo CUP.getDriverInfo (S.1.1).

Se non sono stati trasmessi i campi obbligatori il metodo risponde con un errore di codice “1” e la relative descrizione:

➢ Parametro BookingId mancante.

Se è stato trasmesso un “BookingId” errato il metodo risponde con un errore di codice “2” e la relativa descrizione:

➢ Codice BookingId errato.

Se il parametro “BookingId” corrisponde ad una prestazione il cui stato è ”X” il metodo risponde con un messaggio di errore di codice “a” e la relativa descrizione:

➢ ‘Prenotazione non più presente in SysPrest’





CUP.findBooking

Il metodo ricerca le prenotazioni esistenti per un dato assistito o per unità erogate o per struttura.


Ad identificazione avvenuta, il metodo, dopo il controllo sui dati ricevuti, fornisce un array di parametri strutturati di tipo <BookingInfo> secondo i parametri di ricerca .

Il metodo accetta in ingresso i parametri strutturati <Credential> (già descritto nel primo metodo), <Patient>,<Prescription>, i parametri di tipo DateTime “BeginDate” e “EndDate” e le stringhe “StructureCode” e “WorkingUnitCode”. Sono obbligatori i parametri “BeginDate” e “EndDate”. Non è consentita la ricerca per “Presription”.

La correttezza del codice fiscale del paziente e delle date è accertata mediante il metodo:” ControlloMetodofindBooking”.

Se i dati trasmessi sono corretti il sistema procede elencando tutti i BookingId e i relativi attributi risultanti dalla ricerca. Il metodo utilizza una sola Store Procedure, per poi chiamare a sua volta il metodo: “MethodgetBookingInfo”. La Store Procedure utilizzata (P_CUP_AV_S_0830_FindBookingInfo_campi ) effettua la ricerca in funzione dei parametri inseriti. Il metodo fornisce anche informazioni relative a prenotazioni precedentemente revocate.



Input Patient <Patient> Dati anagrafici del paziente che ha richiesto la prenotazione.

NO

Prescription <Prescription> Dati della richiesta NO

BeginDate <dateTime.iso8601> Data di fine intervallo di ricerca SI

EndDate <dateTime.iso8601> Data di fine intervallo di ricerca SI

StructureCode String Codice interno al CUP del presidio NO


NO


SI

Output Bookings

Array of <BookingInfo> PRENOTAZIONI TROVATE SECONDO LE INFORMAZIONI PASSATE

SI

Struttura < BookingInfo >


BookingId Int Identificativo CUP1L della prenotazione

Appointment <Appointment> Appuntamento prenotato

Patient <Patient> Dati anagrafici del paziente.

Prescriptions Array <Prescription>

Lista di impegnative associate alla prenotazione.

BookServices Array

<BookService>

LISTA DI PRESTAZIONI PRENOTATE.

StatusCode String Stato in cui può trovarsi la prenotazione:

C = confermata;

A = annullata;

F = sospesa;

E = Erogata;

N = Non erogata;

P = Erogata e Pagata;

Si è scelto di non riportare tutte le strutture del metodo in quanto vengono gestite chiamando il metodo: CUP.getBookingInfo. La stessa cosa è valida nella gestione degli errori.





Se l’identificazione dell’utente non ha avuto successo il metodo restituisce i codici e le descrizioni degli errori descritti nel metodo CUP.getDriverInfo. Se non sono stati trasmessi i campi il metodo risponde con un errore di codice “1” e la relative descrizione:

➢ Parametro BeginDate mancante

➢ Parametro EndDate mancante

Se è stato trasmesso un TaxCode non presente in Sysprest il metodo risponde con un errore di codice “2” e la relativa descrizione:

➢ Codice TaxCode errato

Se BeginDate è posteriore a EndTime il metodo risponde con un errore di codice “2” e la relativa descrizione:

➢ Dato BeginDate precedente a EndDate.

Se si verifica un errore interno (es. SQL) il metodo restituisce un errore di tipo “4” e la relativa descrizione. Se nessuna prenotazione corrisponde ai parametri di ricerca il metodo risponde con un errore di tipo “4” con le relativa descrizione:

➢ Nessuna prenotazione

CUP.book

Il metodo permette la prenotazione di un appuntamento. L’output del metodo infatti è l’identificativo CUP1L dell’appuntamento prenotato . La prima azione del metodo è l’identificazione dell’utente. Il metodo “CUP.findService” chiama il metodo “IdentificazioneUtente” allocato nella pagina “Metodi.cs” . Ad identificazione avvenuta, il metodo, dopo il controllo sui dati ricevuti, fornisce il campo “BookingId”, codice dell’ appuntamento prenotato. Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel primo metodo), i parametri strutturati < Patient>, < Appointment> , <BookingAttributes>. I dati in ingresso vengono inseriti in tabelle di appoggio di Sysprest:

➢ CUP_AV_S_035_BOOK_APPOINTMENT; ➢ CUP_AV_S_030_BOOK_PATIENT; ➢ CUP_AV_S_040_BOOK_ATTRIBUTES;

Il metodo effettua un controllo sui parametri trasmessi, per verificarne la correttezza e la effettiva disponibilità tramite il metodo “ControlloDatiAssistito”. Vengono eseguiti i seguenti controlli:

➢ Che il parametro codice comune di nascita “BirthPlaceCode” sia effettivamente presente nella tabella “tblComuni”;

➢ Che il parametro codice comune di residenza “ResPlaceCode” sia effettivamente presente nella tabella “tblComuni”;

➢ Che il parametro codice comune di domicilio “DomPlaceCode” sia effettivamente presente nella tabella “tblComuni”;

➢ Che il parametro codice cittadinanza “CountryCode“ sia effettivamente presente nella tabella “tblCittadinanza”;

Il sistema procede con la prenotazione se i dati sono coretti. La prenotazione è gestita con le stesse stored procedure usate da SysPrest e altre che aggiornano tabelle specifiche del progetto. In ordine:




➢ p_Prenotazione_125_Sessione_Ins (creazione sessione di prenotazione); ➢ sp_5023_Prenota_AgendaSessione (testata tipologia di prenotazione); ➢ P_CUP_AV_C_0600_book_sessione_prest_ins (memorizzazione nel carrello di

prenotazione le prestazioni richieste); ➢ p_xAnagrafe_002_Assistito_new (memorizzazione in anagrafe SysPrest l’assistito); ➢ P_CUP_AV_S_0646_BOOK_CONTROLLO_AGENDA_ASSISTITO

− E’ presente un controllo (bloccante) sulla coerenza della residenza dell’assistito con la il filtro “residenza” indicato nell’agenda dove si vuole prenotare; se l’agenda non ha le caratteristiche dell’assistito il sistema riporta l’errore “Agenda non coerente con i dati del paziente (sesso,residenza,eta)

➢ sp_5555_prenota_esterni (registrazione prenotazione); ➢ p_Prenotazione_050_num_ricetta_upd (registrazione numero impegnativa sulla

prenotazione) ➢ P_CUP_AV_S_0630_book_appointment_upd (memorizzazione nella tebella

“AgendePrenotazioni” l’appointment_Id). ➢ P_CUP_AV_S_0640_BOOK_NUM_DISP_SETT_CONTROLLO (effetua un controllo

delle disponibilità di SysPrest) L’appuntamento voluto risulta che è stato già occupato (la stored procedure sp_5555_prenota_esterni ritorna con il codice 2001), il metodo risponde con un messaggio di errore di codice “4” con la descrizione “Orario non disponibile”. Il paziente è filtrato in funzione del codice fiscale. Se il paziente è già presente in anagrafe, si procede all’aggionamento dei campi: “Patient.Phone” e “Patient.PhoneMobile” se questi non vengono forniti nulli. Se il paziente non è presente in anagrafe si precede con il suo inserimento. La struttura richiedente dell’appuntamento è ricavata tramite il metodo identificativo dell’utente: “IdentificativoUserName” (struttura SysPrest del cup code associato all’utente - CUP_AV_020_CUPCODE). La quantità delle prestazioni è fissa a 1, la quantità per SysPrest è riferita all’intera prenotazione non alla singola prestazione . La prenotazione effettuata dal CUP AREA VASTA su una agenda “colore” gli verrà attribuito la fascia di priorità relativa alla data prenotata rispetto la data di contatto. Esempio 1

dato contatto = 01/12/2006 agenda = num. XXX --- B tra 0gg a 10gg D tra 11gg a 365gg data prenotazione = 15/12/2006 colore prenotazione D colore ricetta D

Esempio 2

dato contatto = 01/12/2006 agenda = num. XXX --- B tra 0gg a 10gg D tra 11gg a 365gg data prenotazione = 07/12/2006 colore prenotazione B colore ricetta B



Input Patientt <Patient> Dati anagrafici del paziente che ha richiesto la prenotazione.

SI

Appointment <Appointment> Appuntamento da prenotare SI

Attributes <BookingAttributes> Attributi di prenotazione SI


SI




output

BookingId String IDENTIFICATIVO CUP1L DELL’APPUNTAMENTO PRENOTATO.

SI

Struttura < Patient>

I dati ricevuti dal server corrispondenti al paziente vengono memorizzati nella tabella: CUP_AV_S_030_BOOK_PATIENT.

Campo Tipo Descrizione Note CSIO

PatientId string Codice interno al CUP del paziente.

HealthCode string Codice sanitario della persona

TaxCode string Codice fiscale della persona.

FirstName string Nome della persona

LastName string Cognome della persona

Sex string Sesso(“M”;”F”)

BirthDate DateTime.iso8601

Data di nascita

BirthPlaceCode string Codice del luogo di nascita

BirthPlaceName string Descrizione del luogo di nascita

BirthPlaceCountryCode

string Codice dello stato di nascita Dato non gestito in SysPrest

BirthPlaceCountryName

string Descrizione dello stato di nascita Dato non gestito in SysPrest

CountryCode string Codice dello stato di cittadinanza Se il codice di Cittadinanza non viene trasmesso per default =000

CountryName string Descrizione dello stato di cittadinanza

ResAddress string Indirizzo del luogo di residenza

ResPostCode String CAP del luogo di residenza

ResPlaceCode String Codice del luogo di residenza

ResPlaceName String Descrizione del luogo di residenza

ResCountryCode String Codice dello stato di residenza Dato non gestito in SysPrest

ResCountryName String Descrizione dello stato di residenza Dato non gestito in SysPrest

DomAddress String Indirizzo del luogo del domicilio

DomPostCode String CAP del luogog di domicilio

DomPlaceCode String Codice del luogo di domicilio

DomPlaceName String Descrizione del luogo di domicilio

DomCountryCode String Codice dello stato di domicilio Dato non gestito in SysPrest

DomCountyName String Descrizione dello stato di domicilio Dato non gestito in SysPrest

AslCode String Codice azienda della persona

AslName String Descrizione azienda della persona

Phone String Numero telefonico della persona

PhoneMobile String Numero telefonico della persona

PhoneRes String Numero telefonico della persona Dato non gestito in SysPrest

PhoneDom String Numero telefonico della persona Dato non gestito in SysPrest

Struttura < Appointment> I dati ricevuti dal server dell’appuntamento vengono memorizzati nella tabella: CUP_AV_S_035_BOOK_APPOINTMENT.


AppintmentId String Identificativo univoco edll’appuntamento interno al CUP.


Contract Int Contratto di erogazione: 1=SSN; 2=LP(Libera Professione).


WorkingUnitCode String Codice interno al CUP dell’untià erogante.




Struttura < BookingAttributes> I dati ricevuti dal server corrispondenti agli attributi dell’appuntamento vengono memorizzati nella tabella: CUP_AV_S_040_BOOK_ATTRIBUTES.


FirstAvaibility DateTime.iso8601 Prima data disponibile

WorkingUnitCode String Codice unità erogante

StructureCode String Codice struttura

CorporationCode String Codice azienda

Notes String Note legate alla prenotazione

Contract Int Tipologia contratto: 0=primo accesso; 1=secondo accesso; 2=da pronto soccorso; 3=interni;


Se l’ identificazione dell’utente non ha avuto successo il metodo restituisce i codici e le descrizioni degli errori descritti nel metodo CUP.getDriverInfo (S.1.1). Se non sono stati trasmessi i campi obbligatori (la scelta dell’obbligatorietà dei parametri è stata dovuta anche alle esigenze di SysPrest, in particolare per i dati di inserimento nel caso di un paziente nuovo) il metodo risponde con un errore di codice “1" e la relative descrizione:

➢ Parametro Patient.TaxCode mancante ➢ Parametro Patient.LastName mancante ➢ Parametro Patient.Sex mancante ➢ Parametro Patient.FirstName mancante ➢ Parametro Patient.LastName mancante ➢ Parametro Patient.BirthDate mancante ➢ Parametro Patient.BirthPlaceCode mancante ➢ Parametro Patient.ResPlaceCode mancante ➢ Parametro Appointment.AppointmentId mancante ➢ Parametro Attributes.FirstAvailability mancante ➢ Parametro Attributes.StructureCode mancante ➢ Parametro Attributes.CorporationCode mancante ➢ Se uno dei due parametro Phone PhoneMobile non è indicato viene indicato:

parametro Phone o PhoneMobile non indicato Se è stato trasmesso un AppointmentId, codici comuni errati o codice cittadinanza errati il metodo risponde con un errore di codice “2” e la relativa descrizione:

➢ Codice AppointmentId errato ➢ Codice BirthPlaceCode errato ➢ Codice ResPlaceCode errato ➢ Codice DomPlaceCode errato ➢ Codice CountryCode errato

Se i dati corretti corrispondono ad un appuntamento che è stato già occupato, il metodo risponde con un messaggio di errore di codice “4”:

➢ Orario non disponibile.





CUP.revoke

Il metodo permette la cancellazione di un appuntamento.


Ad identificazione avvenuta, il metodo, dopo il controllo sui dati ricevuti, restituisce un booleano per l’avvenuta cancellazione. I parametri: “BookingID”, <User> e <Service> sono obbligatori.

Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel primo metodo), il parametro stringa “BookingId” e il parametro strutturato < Service>.

I dati in ingresso vengono inseriti in tabelle di appoggio di SysPrest:

➢ CUP_AV_S_050_REVOKE_TESTATA ➢ CUP_AV_S_055_REVOKE_PREST

Il metodo effettua un controllo sulla correttezza del parametro “BookingId” trasmesso mediante il metodo “ControlloBookingId”. Il metodo, in particolare verifica che “BookingId” sia effettivamente presente nella tabella della anagrafe degli appointment: “AgendePrenotazioni”.

Un secondo controllo viene effettuato tramite la Stored Procedure “p_Prenotazione_040_controllo_del” (controlli dell’attuale procedura SysPrest: prestazioni erogate, prenotazione contabilizzata, prenotazione con data pregressa alla data di cancellazione,ecc…) .

Se i dati trasmessi sono formalmente corretti il sistema procede con la cancellazione dell’appuntamento. La revocazione di una prenotazione è gestita con le stesse stored procedure usate da SysPrest e altre che aggiornando tabelle specifiche del progetto. In ordine:

➢ p_Prenotazione_040_controllo_del; ➢ P_CUP_AV_S_0840_REVOKE_Prenotazione_Del Se la prenotazione è efftuata su un’agenda un posto prestazione il sistema eseguela la cancellazione per prestazione

❖ p_Prenotazione_085_Del_un_posto_prest altrimenti il sistema cancella l’intera prenotazione eseguendo la stored procedure:

❖ p_Prenotazione_009_del;

La revocazione della prenotazione coinvolge tutte le prestazioni afferenti a quel “BookingID”, non viene effettuato alcun filtro sulle prestazioni.


Input BookingId String Identificativo CUP1L della prenotazione da revocare.

SI

Serices Array of string Vettore di codici CUP1L delle prestazioni da revocare.

SI


SI

ouput

Result Boolean TRUE SE L’ELIMINAZIONE DELLA CORRISPONDENTE PRENOTAZIONE HA AVUTO ESITO POSITIVO, FALSE ALTRIMENTI.

SI

Service

I dati ricevuti dal server delle prestazioni vengono memorizzati nella tabella: CUP_AV_S_055_REVOKE_PREST.







➢ Parametro BookingId mancante ➢ Parametro Services mancante

Se è stato trasmesso un BookingId errato il metodo risponde con un errore di codice “2” e la relativa descrizione:

➢ Codice BookingId errato


CUP.Move (non attivo)

Il metodo permette la spostamento di un appuntamento.


Ad identificazione avvenuta, il metodo, dopo il controllo sui dati ricevuti, restituisce il numero della prenotazione (lo stesso dell’ingresso in quanto SysPrest non genera un nuovo numero di prenotazione).

Il metodo accetta in ingresso il parametro strutturato <Credential> (già descritto nel primo metodo), il parametro stringa “BookingId”, il parametro strutturato <Service> e <Appointment>. Sono tutti parametri obbligatori.

I dati in ingresso vengono inseriti in tabelle di appoggio di SysPrest: ➢ CUP_AV_S_060_MOVE_TESTATA ➢ CUP_AV_S_065_MOVE_PREST

Il metodo effettua un controllo sulla correttezza dei parametri trasmessi mediante il metodo “ControlloMetodoMove”. Il metodo, in particolare verifica che “BookingId” e “AppointmentId” siano presenti nella tabella della anagrafe degli appointment: “AgendePRenotazioni”. Il controllo passa poi sulla disponibilità per l’ ”AppoinmtntId” desiderato e sulla coerenza della agende di appartenenza, infatti sia “BookingId” che “AppointmentId” devono essere della stessa agenda. Un ulteriore verifica è sulla data del nuovo “AppointmentId” affinché non sia percedente a quella odierna. Come ultima analisi si procede interrogando le tabelle di SysPrest, verificando ancora la disponibilità del nuovo appuntamento. SysPrest infatti non aggiorna le tabelle di CUP AREA VASTA.

A controllo avvenuto, il sistema procede con lo spostamento dell’appuntamento. Il tutto è gestito con le stesse stored procedure usate da SysPrest e altre che aggiornando tabelle specifiche del progetto . In ordine:

➢ p_AgendeDisp_007_SpostaPrenotazione ➢ P_CUP_AV_S_0785_Prenotazione_upd ➢ P_CUP_AV_S_0640_BOOK_NUM_DISP_SETT_CONTROLLO (effetua un controllo

delle disponibilità di SysPrest) Lo spostamento della prenotazione coinvolge tutte le prestazioni afferenti a quel “BookingID”, non viene effettuato alcun filtro sulle prestazioni.






Input BookingId <string> Identificativo CUP1L della prenotazione da revocare.

SI

Serices Array of string Vettore di codici CUP1L delle prestazioni da revocare.

SI



SI

Output

BookingId String IDENTIFICATIVO CUP1L DELL’APPUNTAMENTO PRENOTATO.

SI

Struttura < Appointment>

I dati ricevuti dal server dell’appuntamento vengono memorizzati nella tabella: CUP_AV_S_060_MOVE_TESTATA.


AppintmentId String Identificativo univoco edll’appuntamento interno al CUP.



1=SSN;

2=LP(Libera Professione).


WorkingUnitCode String Codice interno al CUP dell’untià erogante.

Service

I dati ricevuti dal server delle prestazioni vengono memorizzati nella tabella: CUP_AV_S_065_MOVE_PREST.




➢ Parametro BookingId mancante ➢ Parametro Services mancante ➢ Parametro Appointment mancante

Se è stato trasmesso un BookingId, AppointmentId errati o afferenti a agende diverse o senza disponibilità, il metodo risponde con un errore di codice “2” e la relativa descrizione:

➢ Codice BookingId errato ➢ Codice AppointmentID errato ➢ err.1 AGENDA SU CUI SPOSTARE APPUNTAMENTO NON VALIDA ➢ Data dell'AppointmentId precedente all'odierna"; ➢ err.1 Nessuna disponibilità





Integrazione tra CUP2L e CUP1L (Lato Client)

CUPMET.getAvilabilities

Il metodo fornisce le fasce di lavoro disponibili per la prenotazione.

Questo metodo, come tutti gli altri metodi lato Client, risponde ad una chiamata effettuata dal sistema SysPrest. SysPrest si limita a fornire i parametri di ingresso necessari e a gestite poi adeguatamente quelli di output.

I metodo necessita deii seguenti dati:


Input Prescriptions Array of <Prescription>

Impegnativa sulla quale effettuare la prenotazione

SI

Serices Array of <BookServices>

Vettore di codici delle prestazioni di cui visualizzare le fasce di lavoro.

SI

Preferences <BookingPreferences>

Preferenze espresse per l’ interrogazione delle disponiblità

SI

User <Credential> Credenziali dell’utente del sistema di secondo livello da utilizzare per il controllo degli accessi

SI

WorkSlots Array di <WorkSolt> VETTORE DELLE FASCE DI LAVORO DISPONIBILI

SI

FirstAvailability <WorkSlots> PRIMA DISPONIBILITÀ SI

Per quanto riguarda il capmo “Preferences” si è scelto di non fornire alcun parametro di filtro.

I dati vengono memorizzati nelle tabelle:

➢ CUP_AV_C_0100_GET_WORKSLOT

➢ CUP_AV_C_0110_GET_WORKSLOT_FIRST_AVAILABILITY .

Se la pagina di chiamata la metodo viene richiamata successivamente, essa prevede la cancellazione dei record inseriti con la medesima sessione nelle tabelle suddette mediante la store procedure:

➢ P_CUP_AV_C_0240_DEL_DISP.

La struttra non ancora definita si ora è la <BookingPreferences>:




Struttura < BookingPreferences>


FromDate dateTime.iso8601 Data di inizio ricerca. Se non specificata d

Si assume quella attuale.

ToDate dateTime.iso8601 Data di fine ricerca. Se non specificata si assume quella attuale.

FromTime dateTime.iso8601 Ora di inizio dell’intervallo di ricerca. Se non specificata si assume 0.

ToTime dateTime.iso8601 Ora di fine intervallo di ricerca. Se non specificata si assume 23:59.

WeekDays String Giorni della settimana prescelti Se non specificato si assume: “1111111”

Characteristic String Codice caratteristica

SexPatient Int Sesso del paziente (M,F)

AgePatient Int Età del paziente spressa in mesi.


1=SSN;


Se non specificato viene considerato indefinito.

StructureCode String Codice interno a Cup del presidio. Se non specificato viene considerato indefinito.

WorkingUnitCode String Codice interno al Cup dell’unità ergante. Se non specificato viene considerato indefinito.

MaxItems Int Numero massimo di disponibilità che devono essere restituite. Se non specificato si assume 50.


Se il metodo risponde con un errore XMLRPC viene ad essere visualizzato la pagina: “exe_ErroreXML_dsc.aspx” che visualizza la descrizione dello stesso




CUPMET.getAppointments

Il metodo fornisce le fasce orarie disponibili per la prenotazione.


I metodo necessita dei seguenti campi:


Input WorkSlot <WorkSlot> Fasci di lavoro SI

Prescriptions Array of <Prescription>

Lista di impegnative SI

Services Array of <BookService>

Lista delle prestazioni da prenotare SI


SI

Output

Appointmets Array di <Appointment>

Lista degli appuntamenti disponibili SI

Warning String NOTE RIVOLTE ALL’OPERATORE No

Notes String NOTE RIVOLTE ALL’ASISTITO O PREPARAZIONE.

No

I dati vengono memorizzati nelle tabelle:

➢ CUP_AV_C_0120_SCARICO_APPOINTMENT

➢ CUP_AV_C_0125_SCARICO_WARNINGS_NOTES.

Se la pagina di chiamata la metodo viene richiamata successivamente, essa prevede la cancellazione dei record inseriti con la medesima sessione nelle tabelle suddette mediante la store procedure:

➢ P_CUP_AV_C_0280_DEL_APPOINTMENT_PAGINA_RITORNO.

La struttra non ancora definita si ora è la <BookingPreferences>:






CUPMET.book

Il metodo effettua la prenotazione in funzione della fascia di lavoro e appuntamento selezionati.


I metodo necessita dei seguenti dati:


Input

Patient <Patient> Dati anagrafici del paziente per cui si effettua la prenotazione

SI


User <Credential>

Credenziali dell’utente del sistema di secondo livello da utilizzare per il controllo degli accessi

SI

output BookingId String

IDENTIFICATIVO CUP2L DELL’ APPUNTAMENTO PRENOTATO

SI

I dati vengono memorizzati nella tabella:

➢ CUP_AV_C_0130_SCARICO_BOOKINGID






CUPMET.revoke

Il metodo effettua la cancellazione della prenotazione fornita in Input.

Questo metodo, come tutti gli altri metodi lato Client, risponde ad una chiamata effettuata dal sistema SysPrest. SysPrest si limita a fornire il parametro di ingresso ( “BookingId”) e a gestite poi adeguatamente quello di output.



Input

BookingId String

Identificativo CUP2L della prenotazione da revocare

SI

Services Array di string Vettore dei codici CUP2L delle prestazioni da revocare

SI


SI

Output Result Boolean

TRUE SE L’ELIMINAZIONE DELLA CORRISPONDENTE PRENOTAZIONE HA AVUTO ESITO POSITIVO. FALSE ALTRIMENTI

SI

Con la cancellazione vengono revocate tutte le prestazioni afferenti a quella prenotazione, in quanto è previsto che siano passate tutte.

Il codice della prestazione viene passato il codice del catalogo CUP AV.


Se il metodo risponde con un errore XMLRPC viene ad essere visualizzato la pagina: “exe_ErroreXML_dsc.aspx” che visualizza la descrizione dello stesso.

CUPMET.move

Il metodo effettua lo spostamento della prenotazione in Input.

Questo metodo, come tutti gli altri metodi lato Client, risponde ad una chiamata effettuata dal sistema SysPrest. SysPrest si limita a fornire i parametro di ingresso e a gestite poi adeguatamente quello di output.



Input

BookingId String

Identificativo CUP2L della prenotazione da revocare

SI

Services Array di string Vettore dei codici CUP2L delle prestazioni da revocare

SI

Appointments <Appointmet> Nuovo appuntamento da prenotare SI

User <Credential>


SI

Output BookingId String

IDENTIFICATIVO CUP2L DEL NUOVO APPUNTAMENTO PRENOTATO

SI

Con lo spostamento della prenotazione vengono spostate tutte le prestazioni della prenotazione, in quanto è previsto che siano passate tutte.





Se il metodo risponde con un errore XMLRPC viene ad essere visualizzato la pagina: “exe_ErroreXML_dsc_findBooking.aspx” che visualizza la descrizione dello stesso.

CUPMET.getBookingInfo

Il metodo fornisce informazioni relative alla prenotazione inserita in Input.

Questo metodo, come tutti gli altri metodi lato Client, risponde ad una chiamata effettuata dal sistema SysPrest. SysPrest si limita a fornire i parametri di ingresso necessari e a gestite poi adeguatamente quelli di output. In questo caso parametri di output non vengono memorizzati in alcuna tabella, ma visualizzati semplicemente a video.



Input BookingId String Identificativo CUP2L della prenotazione di cui si vuole ottenere le informazioni di dettaglio.

SI


SI

Output BookingInfo <BookingInfo>

INFORMAZIONI DI DETTAGLIO DELLA PREOTAZIONE IDENTIFICATA DA BOOKINGID.

SI


Se il metodo risponde con un errore XMLRPC viene ad essere visualizzato la pagina: “Generica_exe_ErroreXML_dsc.aspx” che visualizza la descrizione dello stesso




CUPMET.findBooking

Il metodo restituisce le prenotazioni effettuate per un dato assistito o per unità erogante.

Questo metodo, come tutti gli altri metodi lato Client, risponde ad una chiamata effettuata dal sistema SysPrest. SysPrest si limita a fornire i parametri di ingresso necessari e a gestite poi adeguatamente quelli di output. In questo caso parametri di output non vengono memorizzati in alcuna tabella, ma visualizzati semplicemente a video.

Il metodo prevede il filtro rispetto il paziente tramite il campo: Patient.TaxCode come richiesto dalla Ised.



Input

Patient <Patient>

Dati anagrafici del paziente che ha richiesto la prenotazione.

NO

Prescription <Prescription> Dati della richiesta NO

BeginDate dateTime.iso8601 Data di inizio intervallo di ricerca SI

EndDate dateTime.iso8601 Data di fine intervallo di ricerca SI

StructureCode String Codice del presidio NO

WorkingUnitCode String Codice dell’equipe NO


SI

Output Bookings

Array di <BookingInfo>

PRENOTAZIONI TROVATE SECONDO LE INFORMAZIONI PASSATE

SI


Se il metodo risponde con un errore XMLRPC viene ad essere visualizzato la pagina: “Generica_exe_ErroreXML_dsc.aspx” che visualizza la descrizione dello stesso

CUPMET.findStructure

Il metodo restituisce le informazioni delle strutture richieste.

Questo metodo è stato utilizzato per avere un catalogo di tutte le strutture coinvolte nel progetto. Il metodo viene ad essere chiamato all’interno di un file eseguibile che è lanciato ogni notte.

Il metodo necessita dei seguenti dati:


Input

Structure <StructureInfo>

Informazioni sui presidi sulle strutture da ricercare. I campi valorizzati definiscono i filtri di interrogazione.

NO


SI

Output Structures

Array di <StructureInfo>

LISTA DEI PRESIDI E DELLE STRUTTURE TROVATE

SI


Se il metodo risponde con un errore XMLRPC viene inviata una email agli indirizzi della tabella: CUP_AV_030_EMAIL con la descrizione dell’errore relativo.




CUPMET.findWorkingUnit

Il metodo restituisce le informazioni delle unità eroganti richieste.

Questo metodo è stato utilizzato per avere un catalogo di tutte le equipe coinvolte nel progetto. Il metodo viene ad essere chiamato all’interno di un file eseguibile che è lanciato ogni notte.



Input

WorkingUnit <WorkingUnitInfo>

Informazioni sulle unità eroganti da ricercare.

NO

User <Credential>


SI

Output WorkingUnits

Array di <WorkingUnit>

LISTA DELLE UNITÀ EROGANTI TROVATE

SI


Se il metodo risponde con un errore XMLRPC viene inviata una e-mail agli indirizzi della tabella: CUP_AV_030_EMAIL con la descrizione dell’errore relativo.

CUPMET.findVirtualService

Il metodo restituisce le informazioni sulle prestazioni erogate dai Cup appartenenti al progetto.

Questo metodo è stato utilizzato per avere un catalogo di tutte le prestazioni coinvolte nel progetto. Il metodo viene ad essere chiamato all’interno di un file eseguibile che è lanciato ogni notte.



Input

VirtualService <VirtualServiceinfo>

Informazioni sulle prestazioni virtuali da ricevere. I campi valorizzati definiscono il filtro di interrogazione.

NO


SI

VirtulaServices

Array di <VirtulaServiceInfo>

LISTA DELLE PRESTAZIONI VIRTULAI TROVATE

SI


Se il metodo risponde con un errore XMLRPC viene inviata una email agli indirizzi della tabella: CUP_AV_030_EMAIL con la descrizione dell’errore relativo.




Elaborazioni notturne

Elaborazione Structure

L’elaborazione schedulata ogni notte (operazione pianificata) ha il compito di chiamare il metodo “findStructure” (descritto nel presente documento) messo a disposizione dal CUP AREA VASTA per alimentare la tabella “CUP_AV_C_0010_FIND_STRUCTURE “ (contenente tutte le strutture appartenenti al progetto Cup Area Vasta.)di SysPrest:

Terminato il processo il sistema invierà una email agli indirizzi presenti nella tabella: “CUP_AV_030_EMAIL” definendo il suo esito:

➢ SysPrest CUP AREA VASTA -Elaborazione findStructure

➢ Errore elaborazione: findStructure

Non esiste una funzione web per la gestione dei dati della tabella.

La tabella CUP_AV_C_0010_FIND_STRUCTURE contiene i seguenti campi:

StructureCode (chiave) E’ il codice della struttura, codice interno a Cup

CUPCode Codice Cup della struttura

StructureParent Codice della struttura di appartenenza

StructureName Nome della struttura

StructureAddress Indirizzo della struttura

StructurePhone Telefono di riferimento della struttura. Es:centralino,informazioni

StructurePostCode CAP della struttura

StructurePlaceCode Codice luogo della struttura

DATA_ORA_INS Data e ora inserimento della struttura

FLG_ELABORATO Flg che verifica lo stato del record




Elaborazione WorkingUnit

L’elaborazione schedulata ogni notte (operazione pianificata) ha il compito di chiamare il metodo “findWorkingUnit” (descritto nel presente documento) messo a disposizione dal CUP AREA VASTA per alimentare la tabella “CUP_AV_C_0020_FIND_WORKING_UNIT “(contenente tutte le WorkingUnit appartenenti al progetto Cup Area Vasta.)di SysPrest:

Terminato il processo il sistema invierà una e-mail agli indirizzi presenti nella tabella: “CUP_AV_030_EMAIL” definendo il suo esito:

SysPrest CUP AREA VASTA -Elaborazione findWorkingUnit

Errore elaborazione: findWorkingUnit


La tabella CUP_AV_C_0020_FIND_WORKING_UNIT contiene i seguenti campi:

WorkingUnitCode (chiave) E’ il codice della equipe,codice interno all’unità erogante

StructureCode Codice interno al Cup del presidio

WorkingUnitName Descrizione dell’unità erogante

WorkingUnitAddress Indirizzo dell’unità erogante

WorkingUnitPhone Telefono dell’unità ergante

WorkingUnitPostCode CAP dell’unità erogante

WorkingUnitPlaceCode Codice luogo dell’unità erogante

Location Ubicazione dell’unità erogante

Proponent Indica se l’unità erogante può essere o meno invariante

DATA_ORA_INS Data e ora inserimento dell’equipe

FLG_ELABORATO Flg che verifica lo stato del record

Elaborazione findVirtualService

L’elaborazione schedulata ogni notte (operazione pianificata) ha il compito di chiamare il metodo “findVirtualService” (descritto nel presente documento) messo a disposizione dal CUP AREA VASTA per alimentare le seguenti tabella di SysPrest:

CUP_AV_C_0030_FIND_VIRTUAL_SERVICE_TESTATA contenente l’anagrafe delle prestazioni virtuali

CUP_AV_C_0040_FIND_VIRTUAL_SERVICE_PREST “ contenente l’associazione della prestazione virtuale con la prestazione aziendale dei diversi CUPCODE

Terminato il processo il sistema invierà una e-mail agli indirizzi presenti nella tabella: “CUP_AV_030_EMAIL” definendo il suo esito:

SysPrest CUP AREA VASTA – Elaborazione findVirtualService

Errore elaborazione: findVirtualService





La tabella CUP_AV_C_0030_FIND_VIRTUAL_SERVICE_TESTATA contiene i seguenti campi:

PK_VIRTUAL_SERVICE (chiave) progressivo interno

ServiceCode Codice prestazione virtuale

ServiceNationalCode Codice nomenclatore nazionale

ServiceRegionalCode Codice nomenclatore regionale

ServiceName Descrizione prestazione virtuale

ServiceAlias CAP dell’unità erogante

ServiceBranch Branche della prestazione

BookableByPhone

Proponent

ServiceWarning Note all’operatore

ServiceNotes preparazione

DATA_ORA_INS Data e ora inserimento della prestazione

La tabella CUP_AV_C_0040_FIND_VIRTUAL_SERVICE_PREST contiene i seguenti campi:

PK_VIRTUAL_SERVICE_PREST (chiave) progressivo interno

PK_VIRTUAL_SERVICE Progressivo prestazione virtuale decodifica tabella CUP_AV_C_0030_FIND_VIRTUAL_SERVICE_TESTATA

ServiceCode Codice prestazione azienale

CUPCode Codice cup code (azienda)

ServiceNationalCode Codice nomenclatore nazionale

ServiceRegionalCode Codice nomenclatore regionale

ServiceName Descrizione prestazione aziendale

ServiceAlias CAP dell’unità erogante

ServiceBranch Branche della prestazione

ServicePrice

BookableByPhone

ServiceWarning Note all’operatore

ServiceNotes preparazione

DATA_ORA_INS Data e ora inserimento della prestazione




Elaborazione WORKSLOT

Ogni notte passerà un programma batch di elaborazione ( processo SQL: CUP_AV_WORKSLOT ) utile per calcolare i “WORKSLOT” (fasce di lavoro) per agenda e data. Il processo SQL invierà una email di conferma agli indirizzi e-mail presenti nella tabella: “CUP_AV_030_EMAIL” se avrà esito positivo.


Il Cup Area Vasta richiede la disponibilità per fasce di lavoro (denominate “WORKSLOT”), ma SysPrest ragiona per singolo buco e non per fasce. E’ quindi necessario classificare ogni singolo buco del calendario assegnandogli una fascia. I WORKSLOT vengono scaricati ogni notte nella tabella CUP_AV_C_010_WORK_SLOT per le agende con Flg_Area_Vasta = 1. Vengono scaricate le date di prenotazione del calendario successive a GETDATE()-1 per agende non colore. Mentre per le agende per “codice di priorità” vengono fornite le date prenotabili (WORKSLOT) per le fasce selezionate per il CUP AREA VASTA (da funzione agende- gestione percentuali).

La tabella CUP_AV_C_010_WORK_SLOT contiene i seguenti campi:

WORK_SLOT_ID (chiave) E’ formato dalla concatenazione dello SLOT_ID (numero agenda & giorno settimana & orario inizio fascia) della tabella AgendeOrari & anno & mese & giorno

di calendario

DATE_SLOT Data del calendario

BEGIN_TIME Orario di inizio fascia

END_TIME Orario di fine fascia

MAX_LENGTH E’ così calcolata: 1000 / ((END_TIME - BEGIN_TIME)/ MINUTI_MAX_LENGTH)

STATUS_CODE =D se per il giorno e l’agenda ci sono disponibilità, =O se non ci sono disponibilità

CONTRACT =1 se regime SSN, 0 negli altri casi

STRUTTURE_CODE Struttura dell’agenda

WORKING_UNIT_CODE Equipe dell’agenda

DATA_ORA_INS Data e ora di inserimento del record

AGENDA_ID Codice agenda

SLOT_ID Formato da numero agenda & giorno settimana & orario inizio fascia (dalla tabella AgendeOrari)

MINUTI_MAX_LENGTH È’ la somma delle durate per lo SLOT_ID espressa in minuti

REGIME_ID Regime di erogazione di sysprest

Nella tabella CUP_AV_C_011_WORK_SLOT_OLD è conservato uno storico dei WORKSLOT del giorno precedente.

Flusso chiamata metodi – lato cliente

Di seguito viene riportato un flowciart dell’integrazione lato client:




Visualizzazione pulsante

Prestazione o l’insieme delle prestazioni appartenenti al

carrello di prenotazione:

• appartiene al catalogo Cup area Vasta

(tbl:CUP_AV_C_0040_FIND_VIRTUAL_SERVICE_PREST );

• appartiene al regime Servizio Sanità Nazionale;

Pagina 1

Prenotazione Cup Area Vastalunedì 30 ottobre 2006

Controllo dati obbligatori:

▪ Assistito;

▪ Impegnativa;

EXE_SESSIONE_INS.aspx

ERRORE!!

Controllo se impegnativa è già stata

usata in Cup Area Vasta

Prendo il Cup Code usato nella

precedente prenotazione

Controllo se impegnativa è già stata

usata in EmpoliERRORE!!

P_CUP_AV_C_0140_PRENOT_SESSIONE_INS

Inserimento sessione di prenotazione

P_CUP_AV_C_0170_PRENOT_SESSIONE_PREST_VIRTUALE_UPD

• Trovare le prestazioni virtuali in funzione di quelle di SysPrest

• Trova quali CupCode erogano tutte le prestazioni del carrello;

• CupCode di default

P_CUP_AV_C_PRENOT_SESSIONE_CUP_CODE_CONTROLLO

Controlla se avremo un CupCode che eroga tutt le prestazioni

P_CUP_AV_C_0205_PREST_1_INS_CUP

Inserimento nel carrello delle prestazioni Cup Area Vasta i Cup Code con una sola

prestazione aziendale

ERRORE!!

SI

SI




Pagina 1

prest_selezione.aspxL’utente sceglie il cup presso il quale prenotare le prestazioni selezionate in precedenza

Cup_AV_call_get_work_slot.aspxPagina di attesa

Controlla della disponibilità nel Cup Area Vasta

per le prestazione selezionata

CUPMET_getAvailabilities.aspx

Chiamata al metodo CUPMET.getAvailabilities

exe.ErroreXML_dsc.aspx

Errore XMLRPC: descrizione fornita dal Cup Area Vasta

Selezione_WorkSlot.aspxL’utente sceglie la fascia di lavoro sulla quale prenotare

CUPMET_getAppointments.aspxChiamata al metodo CUPMET.getAppointments

Controlla gli orari disponibili nel Cup Area

Vasta per il WorkSlot selezionato

exe.ErroreXML_dsc.aspx

Errore XMLRPC: descrizione fornita dal Cup Area Vasta

Selezione_Appointemts.aspxL’ utente sceglie l’ appuntamento sul quale prenotare

Cup_AV_call_book.aspxPagina di attesa

Sp_5555_prenota_esterniPrenotazione su agenda fittizia

p_Prenotazione_050_num_ricetta_updIn RichiestaPrestazioni viene inserita la prestazione virtuale

CUPMET_book.aspxChiamata al metodo CUPMET.book

P_CUP_AV_C_0300_INS_AGENDA_PRENOT_CUP_AVVengono memorizzati i dati di dettaglio della prenotazione Cup Av (prima

disponibilità e struttura)

SI

SI

NO

NO




GUIDA AL LOG DI XML RPC

In questa guida verranno illustrati i procedimenti utilizzati per realizzare la procedura di log nel protocollo XML RPC. Tramite questa procedura è infatti possibile memorizzare su DATABASE le informazioni relative a ogni chiamata XML RPC.

I record su tabella di database siano composti dai seguenti campi:

1. PRG_LOG → ID della chiamat

2. INPUT → file xml di input al server

3. OUTPUT → file xml di risposta fornito dal server

4. DATA_ORA_INS → data e ora della chiamata

5. FLG_ERRORE → vale “0” se l’operazione è andata a buon fine, altrimenti “1”

6. METODO → indica il nome del metodo chiamato

7. USERNAME → indica il nome dell’utente che ha effettuato la chimata.

Analizziamo ora la faccenda dai due punti di vista differenti: lato client e lato server.

LATO CLIENT

Partiamo dal log visto dal lato client. Per cominciare poniamo di avere un metodo capace di

inserire i dati richiesto su tabella di database, una volta passato come parametro un oggetto,

ricavato dalla dll, che contenga i flussi di I/O. Nella fattispecie questo oggetto si chiama

RequestResponseLogger ed è direttamente derivato dall’interfaccia che chiama i metodi xmlrpc.

Vediamo la chiamata:

InterfacciaRpc miaInterfaccia = (InterfacciaRpc)XmlRpcProxyGen.Create(typeof(InterfacciaRpc));

RequestResponseLogger dumper = new RequestResponseLogger();

dumper.Attach(miaInterfaccia as XmlRpcClientProtocol);

//CHIAMATA A METODO TRAMITE XMLRPC

→ ……………………….

→ ingresso ingr = new ingresso( @ElencoParametri );

→ uscita usc = miaInterfaccia.nomeMetodo(ingr);

LOG.Logger(dumper);

Del codice sopra presentato l’unica vera novità rispetto al codice presentato nella guida al client

RPC sta nell’ultima chiamata, quella al metodo LOG.Logger(dumper):

• L’oggetto dumper contiene al suo interno i campi dumper.FileRichiesta e

dumper.FileRisposta




o dumper.FileRichiesta è la stringa corrispondente al file .xml di richiesta al Server

o dumper.FileRisposta è la stringa corrispondente al file xml di ritorno dal Server

• a partire da queste due possiamo ricavare:

o int err = 1 se FileRisposta contiene la parola chiave FAULT

o string met che corrisponde al nome del metodo ricavato direttamente da

FileRichiesta

o string utente che corrisponde all’utente¸ ricavato direttamente da FileRichiesta

• I campi data e ID verranno inseriti automaticamente per incremento o per funzione DATE()

• L’inserimento dei dati è affidata ad una stored procedure, con questa chiamata:

o SqlConnection connessioneSQL = new SqlConnection ("Data

Source=trantor;Initial Catalog=SysPrestV3_Empoli;Persist Security

Info=true;User ID=sa;Password=csio"))

o SqlCommand command = new SqlCommand ("P_CUP_AV_C_0010_LOG",

connessioneSQL);

o ELENCO PARAMETRI (@NOMEPARAMETRO = VALORE)

Il codice relativo al metodo LOG.Logger è riportato nella APPENDICE 1 ed è inserito nel progetto

di client, e richiamato all’interno dei metodi lato clienti che necessitano di LOG. Per richiamare tale

metodo occorre aver definito l’oggetto dumper da passare come parametro, e richiamarne il metodo

Attach().

Tuttavia il codice sorgente originale della dll. non prevedeva l’esistenza dei parametri FileRichiesta

e FileRisposta nell’oggetto di tipo RequestResponseLogger, ne tanto meno che il metodo Attach

settasse tali parametri come da noi richiesto. È stato quindi necessario andare a modificare la parte

della .dll in modo che contenesse queste funzioni, e precisamente la classe UTIL.CS. Tali

modifiche sono state realizzate in modo da:

• Inserire il campo pubblico FileRichiesta

• Inserire il campo pubblico FileRisposta

• Fare in modo che al verificarsi dell’evento OnRequest il campo FileRichiesta corrisponda

al contenuto xml della richiesta

• Fare in modo che al verificarsi dell’evento OnResponse il campo FileRisposta corrisponda

al contenuto xml della risposta

Il codice relativo al cambiamento nel metodo LOG RequestResponseLogger Logger è riportato

nella APPENDICE 2.




LATO SERVER

Per quanto riguarda dal log visto dal lato server, cominciamo definendo il metodo

LOGG.scriviDB il quale esegue la medesima funzione di LOG.Logger, ma scrivendo i dati sulla

tabella del server. La classe LOGG è stata definita nella dll ed è composta allo stesso modo della

classe LOG, salvo per la Stored Procedure chiamata. Questa, infatti è

("P_CUP_AV_S_0010_LOG") la quale scrive su un’altra tabella del medesimo database.

Il codice relativo al metodo LOGG.scriviDB è riportato nella APPENDICE 3 ed è inserito nella

.dll. Questo viene richiamato dalla classe XmlRpcHttpServerProtocol.cs all’interno del metodo

HandleHttpRequest.

Il metodo HandleHttpRequest è stato anch’esso modificato in modo da richiamare questo

metodo di scrittura su database. Le modifiche fatte sono riportate in appendice 4.

CONCLUSIONE Si noti come per qunto il lato server non si è dovuto inserire nessuna chimata al metodo di

scrittura su database, in quanto il metodo LOGG.scriviDB e la chiamata ad esso sono già

incorporate nella dll. Tuttavia, perché queste modifiche entrino in funzione, è stato necessario:

• rigenerare la dll, eseguendo il comando BUILD SOLUTION (genera -> genera

soluzione) della dll.

o la soluzione relativa alla dll si chiama xmlrpc ed è contenuta all’indirizzo: xml-

rpc.net.0.9.2\src\xmlrpc.sln

• andare sulle soluzioni client e server da noi realizzate e eseguire i seguenti comandi:

o nella cartella bin della solution explorer (sulla destra) eliminare i riferimenti

relativi a CookComputing.XmlRpc già presenti

o sempre sulla cartella bin fare tasto destro quindi scegliere add reference.

o Selezionare dal browser la dll rigenerata dal comando BUILD SOLUTION

(stesso indirizzo di prima)

o Premere OK

o Per quanto riguarda il lato cline abbiamo concluso

o Per quanto riguarda il lato server occorre infine ripubblicare il sito web.




APPENDICE 1 – CLASSE LOG (LATO CLIENT)

using System; using System.Data; using System.Configuration; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using CookComputing.XmlRpc; using System.IO; using System.Data.SqlClient; /// <summary> /// Summary description for LOG /// </summary> public class LOG { public static void Logger(RequestResponseLogger dumper) { string richiesta = dumper.FileRichiesta; string risposta = dumper.FileRisposta; int err = 0; if (risposta.ToLower().Contains("falut")) { err = 1;} int len = richiesta.IndexOf("</methodName>") - richiesta.IndexOf("<methodName>") - 12; string met = richiesta.Substring(richiesta.IndexOf("<methodName>") + 12, len); string utente = "ANONYMOUS USER"; if (richiesta.Contains("<name>UserName</name>")) { int inde = richiesta.IndexOf("<name>UserName</name>"); int inde2 = richiesta.IndexOf("<string>", inde); int inde3 = richiesta.IndexOf("</string>", inde); utente = richiesta.Substring(inde2+8, inde3-inde2-8); } // per IL CLIENTE non AVENDO il tag della tipologia del dato if (richiesta.Contains("<name>UserName</name>")) { int inde = richiesta.IndexOf("<name>UserName</name>"); int inde2 = richiesta.IndexOf("<value>", inde); int inde3 = richiesta.IndexOf("</value>", inde); utente = richiesta.Substring(inde2+7, inde3-inde2-7); } using (SqlConnection connessioneSQL = new SqlConnection("Data Source=trantor;Initial Catalog=SysPrestV3_Empoli;Persist Security Info=true;User ID=sa;Password=csio")) { using (SqlCommand command = new SqlCommand("P_CUP_AV_C_0010_LOG", connessioneSQL)) { command.CommandType = CommandType.StoredProcedure; command.Parameters.Add(new SqlParameter("@richiesta", richiesta)); command.Parameters.Add(new SqlParameter("@risposta", risposta)); command.Parameters.Add(new SqlParameter("@errore", err)); command.Parameters.Add(new SqlParameter("@metodo_dsc", met)); command.Parameters.Add(new SqlParameter("@user", utente)); connessioneSQL.Open(); command.ExecuteNonQuery(); }




} } }




APPENDICE 2 – MODIFICHE COOKCOMPUTING.XMLRPC (CLASSE UTIL.CS)

public class RequestResponseLogger : XmlRpcLogger { static long baseTicks = DateTime.Now.Ticks; string _directory = "."; // MODIFICA FRANCESCO MANCUSI 04/07/2006 string _fileRichiesta = ""; string _fileRisposta = ""; // FINE MODIFICA FRANCESCO MANCUSI 04/07/2006 public string Directory { get { return _directory; } set { _directory = Path.GetDirectoryName(value + "/"); } } // MODIFICA FRANCESCO MANCUSI 04/07/2006 public string FileRichiesta { get { return _fileRichiesta; } set { _fileRichiesta = value; } } public string FileRisposta { get { return _fileRisposta; } set { _fileRisposta = value; } } // FINE MODIFICA FRANCESCO MANCUSI 04/07/2006 protected override void OnRequest(object sender, XmlRpcRequestEventArgs e) { // MODIFICA FRANCESCO MANCUSI 04/07/2006 StreamReader xmlRead = new StreamReader(e.RequestStream); _fileRichiesta = xmlRead.ReadToEnd(); // FINE MODIFICA FRANCESCO MANCUSI 04/07/2006 } protected override void OnResponse(object sender, XmlRpcResponseEventArgs e) { // FRANCESCO MANCUSI 04/07/2006 StreamReader xmlRead = new StreamReader(e.ResponseStream); _fileRisposta = xmlRead.ReadToEnd(); // FINE MODIFICA FRANCESCO MANCUSI 04/07/2006 } }




APPENDICE 3 – CLASSE LOGG (LATO SERVER - COOKCOMPUTING.XMLRPC)

using System; using System.Data; using System.Configuration; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using CookComputing.XmlRpc; using System.IO; using System.Data.SqlClient; public class LOGG { public static void scriviDB(string chiamo, string rispondo) { string richiesta = chiamo; string risposta = rispondo; int err = 0; if (risposta.ToLower().Contains("fault")) { err = 1; } int len = richiesta.IndexOf("</methodName>") - richiesta.IndexOf("<methodName>") - 12; string met = richiesta.Substring(richiesta.IndexOf("<methodName>") + 12, len); string utente = "ANONYMOUS USER"; if (richiesta.Contains("<name>UserName</name>")) { int inde = richiesta.IndexOf("<name>UserName</name>"); int inde2 = richiesta.IndexOf("<string>", inde); int inde3 = richiesta.IndexOf("</string>", inde); utente = richiesta.Substring(inde2 + 8, inde3 - inde2 - 8); } using (SqlConnection connessioneSQL = new SqlConnection("Data Source=trantor;Initial Catalog=SysPrestV3_Empoli;Persist Security Info=true;User ID=sa;Password=csio")) { using (SqlCommand command = new SqlCommand("P_CUP_AV_S_0010_LOG", connessioneSQL)) { command.CommandType = CommandType.StoredProcedure; command.Parameters.Add(new SqlParameter("@richiesta", richiesta)); command.Parameters.Add(new SqlParameter("@risposta", risposta)); command.Parameters.Add(new SqlParameter("@errore", err)); command.Parameters.Add(new SqlParameter("@metodo_dsc", met)); command.Parameters.Add(new SqlParameter("@user", utente)); connessioneSQL.Open(); command.ExecuteNonQuery(); } } } }




APPENDICE 4 – MODIFICHE COOKCOMPUTING.XMLRPC CLASSE XMLRPChttpSERVERPROTOCOL.CS

// MODIFICA FRANCESCO MANCUSI 04/07/2006

StreamReader lett = new StreamReader(httpReq.InputStream);

string chiamata = lett.ReadToEnd();

StreamReader writ = new StreamReader(Invoke(Util.StringAsStream(chiamata)));

string risposta = writ.ReadToEnd();

Stream responseStream = Util.StringAsStream(risposta);

Stream respStm = httpResp.OutputStream;

Util.CopyStream(responseStream, respStm);

respStm.Flush();

httpResp.ContentType = "text/xml";

LOGG.scriviDB(chiamata, risposta);

// FINE MODIFICA FRANCESCO MANCUSI 04/07/2006




Note installazione integrazione

Il progetto CUP Area Vasta è comprensivo di una parte client (Empoli richiama dei metodi messi a disposizione dal CUP Area Vasta di Firenze ) e di una parte server, (CUP Area Vasta di Firenze richiama i metodi messia a disposizione da Empoli. Sia per la parte Client che per la parte Server, occorre installare e configurare opportunamente il software di base, che nella fattispecie è composto da:

- Microsoft .Net Framework 2.0 - Internet Information Services (5.0 o 6.0)

In particolare occorre: 1. Configurare il server Windows con il ruolo Applicazioni (IIS) 2. Scaricare il Microsoft .Net Framework 2.0 all’indirizzo http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=it 3. Installare il Framework (non richiede successive configurazioni) 4. Aprire lo snap-in di IIS e in Web Service Extension consentire ASP.NET v2.0 (come in figura)

Installazione della parte server

L’integrazione lato server è installata sul server Cupmed (172.16.123.21).

Nel server Cupmed deve essere presente la directory virtuale CUPAREAVASTASERVER (C:\Inetpub\wwwroot\CupAreaVastaServer) sotto il sito web predefinito. Occorre assicurarsi che nelle proprietà, selezionando il tab “ASP.NET”, sia impostata la versione 2.0 (ASP.NET version = 2.0.50727) come nella seguente immagine

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=it

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=it




Nel file C:\Inetpub\wwwroot\CupAreaVastaServer\Web.Config la stinga di connessione deve essere: <add name="CONNECTION_SysPrestV3Empoli" connectionString="Data Source=172.16.100.240;Initial Catalog=SysPrestV3_Empoli;Persist Security Info=true; …> Inoltre occorre ricordare che il server deve essere raggiungibile dal server CUP Area Vasta di Firenze, in quanto il servizio è pubblicato all’indirizzo: http://159.213.47.21/CUPAREAVASTASERVER/ws_csio.ashx

La parte server dipende per il LOG sul db (verificare la stringa di conessione) della DLL (CookComputing.XmlRpc.dll) la qui soluzione stà all’indirizzo xml-rpc.net.0.9.2\src\xmlrpc.sln). per la spiegazione del funzionamento del LOG vedere paragrafo “GUIDA AL LOG DI XML RPC”.

http://159.213.47.21/CUPAREAVASTASERVER/ws_csio.ashx




Installazione della parte client

La parte “Client” del progetto CUP Area Vasta, è stata distinta in due installazioni separate, una utilizzabile dal sito di SysPrest raggiungibile all’interno della Intranet, l’altra raggiungibile via https attraverso la rete Internet.

La parte client dipende per il LOG sul db (verificare la stringa di conessione) della DLL (CookComputing.XmlRpc.dll) la qui soluzione stà all’indirizzo xml-rpc.net.0.9.2\src\xmlrpc.sln). per la spiegazione del funzionamento del LOG vedere paragrafo “GUIDA AL LOG DI XML RPC”.

Sul server web (200.1.1.20)

L’integrazione del Client di Cup Area Vasta è incluso nel sito di SysPrest. In particolare il percorso del Cup Area Vasta è il seguente: L:\csioweb\SysPrestV3\web\CUP_AREA_VASTA Tutto il sito “sysprestweb” deve dunque utilizzare la versione di ASP.NET 2.0 Nel file Web.config del sito, la stinga di connessione deve essere: <add name="CONNECTION_SysPrestV3Empoli" connectionString="Data Source=172.16.100.240;Initial Catalog=SysPrestV3_Empoli;Persist Security Info=true; …>

E’ necessario che il server sia in grado di richiamare (attualmente) l’indirizzo internet http://sprint.ised.it/sprint/ws

Sul server Cupmed (172.16.123.21)

L’integrazione del Client di Cup Area Vasta è incluso nel sito di SysPrest. In particolare il percorso del Cup Area Vasta è il seguente: C:\Inetpub\wwwroot\web\CUP_AREA_VASTA Tutto il sito “sysprestweb” deve dunque utilizzare la versione di ASP.NET 2.0 Nel file Web.config del sito, la stinga di connessione deve essere:

<add name="CONNECTION_SysPrestV3Empoli" connectionString="Data Source=172.16.100.240;Initial Catalog=SysPrestV3_Empoli;Persist Security Info=true; …>

E’ necessario che il server sia in grado di richiamare (attualmente) l’indirizzo internet http://sprint.ised.it/sprint/ws

Processi Schedulati

Nel server Cupmed (172.16.123.21) sono presenti tre processi elaborativi, la cui esecuzione è pianificata per le ore notturne. L’esecuzione di queste operazioni è delegato al sistema di Pianificazione delle attività di Windows. Per accedervi aprire Operazioni Pianificate presente in Pannello di Controllo. Seguire il semplice wizard per schedulare le attività riportate nel paragrafo “Operazioni pianificate - Server WEB CUPMED ip 172.16.123.21”

http://sprint.ised.it/sprint/ws

http://sprint.ised.it/sprint/ws




INTEGRAZIONE ECOMEDICA

Premessa

Iintegrazione tra il sistema SysPrest e il sistema installato presso il centro Ecomedica.

In particola si intende per integrazione:

1. Comunicazione all’Ecomedica delle prenotazioni SysPrest 2. Possibilità dell’Ecomedica di utilizzare la funzione sposta prenotati (di SysPrest per poter

gestire le proprie prenotazioni) 3. Invio e l’elaborazione dei file mensili relativi alle prenotazioni realmente erogare 4. Invio e l’elaborazione dei file mensili relativi alle prenotazioni “non erogate” e le prenotazioni

che il paziente non si è presentato

L’integrazione prevede la ricezione si sole prestazioni prenotate erogate in regime SSN (con documenti di tipo “impegnativa”e non).

La trascodifica delle prestazioni tra i due sistemi sarà carico dell’Ecomedica.

Comunicazione all’Ecomedica delle prenotazioni SysPrest

SysPrest mette a disposizione delle viste con il log delle prenotazioni effettuate su agende della struttura Ecomedica. Le viste visualizzeranno le solo i movimenti non ancora “lett”i dalla procedura Ecomedica (FLG_LETTO_DA_ALTRI_SISTEMI =0 AND AGENDA_STRUTTURA_ID=codice struttura Ecomedica presenti nella tabella ECOMEDICA_0010_STRUTTURE). Alla lettura di una prenotazione il sistema Ecomedica classificherà il movimento come letto (FLG_LETTO_DA_ALTRI_SISTEMI =1).

Sono state messe a diposizioni anche le viste V_ECOMEDICA_020_PRENOTAZIONI_STORICO e V_ECOMEDICA_025_PRENOTAZIONI_PREST_STORICO per permettere di ricercare tutte le prenotazioni dell’Ecomedica.

Vista V_ECOMEDICA_010_PRENOTAZIONI ( su tabella PRENOT_LOG_001_testata)

nome parametro tipo descrizione

PRG_PRENOT INT Numero contatore prenotazione - Contatore

interno

PRENOTAZIONE_ID INT Numero prenotazione

PRENOTAZIONE_DATA datetime Data prenotazione formato GG/MM/AAAA

PRENOTAZIONE_ORA INT ora prenotazione espressa in minuti (es. 09.00 →540)

PRENOTAZIONE_DATA_CONTATTO datetime Data registrazione prenotazione formato GG/MM/AAAA

PRENOTAZIONE_NOTE Varchar(1000) Note delle prenotazione (da AgendePrenotazioniNote)

AGENDA_ID INT Codice agenda della prestazione

AGENDA_DSC Varchar(100) Descrizione agenda

ASSISTITO_ID INT Codice assistito SysPrest

ASSISTITO_NOME Varchar(50) Nome assistito

ASSISTITO_COGNOME Varchar(50) Cognome assistito

ASSISTITO_DATA_NASCITA datetime Data nascita assistito formato GG/MM/AAAA

ASSISTITO_CODICE_FISCALE Varchar(16)

ASSISTITO_CODICE_SANITARIO Varchar(16)




ASSISTITO_COD_COMUNE_NASCITA Varchar(6) Codice ISTAT del comune di nascita

ASSISTITO_COD_COMUNE_RES Varchar(6) Codice ISTAT del comune di residenza

ASSISTITO _INDIRIZZO_RES Varchar(50) Indirizzo residenza dell’assistito

ASSISTITO_TEL Varchar(15)

ASSISTITO_TEL_2 Varchar(15)

ASSISTITO_SESSO Varchar(1)

OPERAZIONE Varchar(3) NW = nuova prenotazione CA = prenotazione cancellata

DATA_ORA_INS datetime Data ora registrazione

FLG_LETTO_DA_ALTRI_SISTEMI INT =0 se l’Ecomedica non ha ancora elaborato il record; altrimenti =1

DURATA INT Durata della prenotazione espressa in minuti

OPERAZIONE_TIPO_ID INT Codice tipo di operazione SysPrest che ha generato il movimento nel LOG

Vista V_ECOMEDICA_015_PRENOTAZIONI_PREST (su tabella PRENOT_LOG_005_prestazioni)

nome parametro tipo descrizione

PRG_PRENOT_PREST INT Numero progressivo prestazione

PRG_PRENOT INT Numero contatore prenotazione

PRESTAZIONE_ID INT Codice prestazione SysPrest

PRESTAZIONE_DSC Varchar(150) Descrizione prestazione

PRESTAZIONE_QTA INT

Per le prenotazioni modificate hanno sempre operazione NW (tutti i record avranno il campo PRENOTAZIONE_ID con lo stesso numero di prenotazione).

E’ stata predisposta la Storede Procedure P_ECOMEDICA_0010_ALL_PRENOT che permette di scaricare in determinate tabelle (ECOMEDICA_0070_ALL_PRENOT_TESTATA e ECOMEDICA_0075_ALL_PRENOT_PRESTAZIONI) le prenotazioni attive delle strutture Ecomedica.

La storede procedure prevede un parametro "@wDataRif" testo di 10 caratteri che rappresenta la data di filtro (in formato AAAA-MM-GG).

Se il parametro è valorizzato vengono scaricate le prenotazioni delle strutture Ecomedica con data prenotazione> = @wDataRif mentre se il parametro è vuoto il sistema scarica le prenotazioni con data prenotazione> = data odierna .

La storede procedure esegue le seguenti operazioni:

❖ pulisce le tabelle ECOMEDICA_0070_ALL_PRENOT_TESTATA e ECOMEDICA_0075_ALL_PRENOT_PRESTAZIONI

❖ inserimento prenotazioni (testata) delle strutture Ecomedica con data prenotazione> = data odierna e le relative prestazioni (con modalità <> 3 “sostituita”)

❖ aggiornamento del campo FLG_LETTO_DA_ALTRI_SISTEMI = 1 nel log delle prenotazioni (PRENOT_LOG_001_testata) per le prenotazioni Ecomedica




Utente SQL per Ecomedica

Utente = ecomedica

Password=3C0mE4I)@ Database= SysPrestV3_Empoli

Utente sql "ecomedica" è stato abilitato ad: ❖ utilizzare le viste (in sola lettura) V_ECOMEDICA_010_PRENOTAZIONI

,V_ECOMEDICA_015_PRENOTAZIONI_PREST,V_ECOMEDICA_020_PRENOTAZIONI_STORICO,V_ECOMEDICA_025_PRENOTAZIONI_PREST_STORICO

❖ utilizzare la vista V_ECOMEDICA_010_PRENOTAZIONI anche con diritti di UPDATE ❖ eseguire la storede procedure P_ECOMEDICA_0010_ALL_PRENOT ❖ utilizzare le tabelle (Select, insert, UpDate)

ECOMEDICA_0070_ALL_PRENOT_TESTATA, ECOMEDICA_0075_ALL_PRENOT_PRESTAZIONI, ECOMEDICA_0077_ALL_PRENOT_APPODURATA (tabella di appoggio per valorizzare il campo DURATA)




Elaborazione d’importazione attività Ecomedica

La funzione “Elab. Ecomedica” (il dettaglio funzionamento è descritto nel manuale utente di SysPrest) permette di schedulare l’elaborazione d’importazione dell’attività nel periodo effettuata dalla struttura Ecomedica. L’elaborazione prevede i seguenti parametri:

• Data fine erogazione: indicare la data massima di erogazione delle prestazioni da elaborare

• File impegnativa (dati impegnativa): il file viene trasmesso al server SysPrest tramite una funzione di upload

• File prestazioni (dati prestazioni erogate): il file viene trasmesso al server SysPrest tramite una funzione di upload

• File non erogato-non presentato(prenotazioni non erogate o prenotazioni che l’assistito non ci è presentato): il file viene trasmesso al server SysPrest tramite una funzione di upload

I file devono essere di formato txt e devono rispettare i tracciati forniti (riportati di seguito). I dati ricevuti ed elaborati vengono mantenuti i apposite tabelle di LOG.

Inizialmente l’elaborazione effettuerà dei controlli, se i dati trasmessi sono coretti verranno registrati su SysPrest (contabilizzazione impegnativa, erogazione prestazioni, cassa) altrimenti i dati non verranno accettati (totalmente) e viene fornito l’elenco dei dati errati (con la motivazione). Il file viene inoltre scartato se esistono documenti senza prestazioni o prestazioni senza documenti e se la cassa dell’Ecomedica è stata già chiuso nel periodo di elaborazione.

Su SysPrest rimane sempre possibile modificare i dati ricevuti. Le operazioni registrate su SysPrest saranno associate all’operatore indicato nella tabella ECOMEDICA_0005_AMBIENTE.OPERATORE_ID. Nell’elaborazione è presente una spunta che elenca le prenotazioni del periodo per cui non è stato indicato nessun tipo di erogazione (non bloccante in quanto le prestazioni poterebbero essere trasmesse in periodi successivi). L’elaborazione terminera con stato “elaborato - con segnalazioni” (semaforo conteporaneamente rosso-verde) nel caso ci siano documenti con importo pagato <> dall’import accertato calcolato da SysPrest

Documenti

Nel file “impegnativa” ci possono essere documenti di tipo “impegnativa” (con numero impegnativa valorizzato) e documenti di tipo “non impegnativa” (con numero impegnativa non valorizzato). I documenti che sono di tipo “non impegnativa” (numero impegnativa non valorizzato) vengono registrati su SysPrest sul documento di tipo “SSN- senza impegnativa” (con descrizione documento = “Documento ecomedica” mentre i documenti di tipo “impegnativa” verranno registrati su SysPrest sul documento di tipo “SSN- impegnativa”. I documenti creati saranno su documenti con la gestione dei ticket aggiuntivi. Un’ impegnativa può essere inviata una sola volta è dovrà essere inviata quando è chiusa (tutte le prestazioni che la compongono sono state erogate) quanto la contabilizzazione deve essere effettuata automaticamente (FLG_CONTABILIZZATO =SI). Dall’integrazione è possibile inviare più volte una impegnativa con collegato solo le prestazioni erogate nel periodo (non devono essere inviate tutte le prestazioni erogate ad oggi del ciclo di terapie ma solo le effettuate dall’ultimo invio di dati) quanto la contabilizzazione non deve essere effettuata automaticamente (FLG_CONTABILIZZATO =NO)




L’esenzione indicata sulla prestazione non è l’esenzione sysprest, ma il codice esenzione (esempio “002” , “002.427” ecc..). L’esenzione sul documento viene valorizzata nel seguente modo:

• Se almeno una prestazione è “non esente” l’esenzione dell’impegnativa sarà “non esente”.

• Altrimenti il documento avrà l'esenzione delle prestazioni; se ci sono prestazioni con esenzione diversa viene presa una a caso (TOP 1).

Per le impegnative per cui è previsto la trasmissione di dati in più estrazioni (esempio i cicli di radioterapia) devono essere classificati “No chiusura automatica della contabilizzazione” (FLG_CONTABILIZZATO =NO). Per i documenti classificati “No chiusura automatica della contabilizzazione”

• il sistema d’integrazione non scollega in automatico le prestazioni contabilizzate nel documento ma mai inviate dall’integrazione, in quanto in nessun invio sono presenti tutte le prestazioni di un documento (che questo permetterebbe di individuare le prestazioni non valide). Eventuali correzioni devono essere fatte manualmente accedendo al sistema SysPrest.

• La chiusura del contabilizzazione per questi documenti deve essere effettuata manualmente su l’applicativo SysPrest.

• Il sistema d’integrazione non inserisce in automatico una erogazione di tipo “non erogata” per le prestazioni della prenotazione trasmessa per cui non hanno indicato un accesso (in quanto le prestazioni di una prenotazione potrebbero essere inviate in più estrazioni). Eventuali correzioni devono essere fatte manualmente accedendo al sistema SysPrest.

Mentre le impegnative che vengono inviate completamente in una sola estrazione devono essere classificate “chiusura automatica della contabilizzazione”. Per i documenti classificati “chiusura automatica della contabilizzazione”:

• Devono essere trasmesse tutte le prestazioni del documento in una unica estrazione (non verrà però attivato nessun controllo applicativo)

• Il sistema d’integrazione scollega in automatico le eventuali prestazioni (senza indicazioni dell’accesso e appartengono alla struttura “Ecomedica”) presenti nella contabilizzazione ma non trasmesse nel file.

Se il documento trasmesso è già presente in SysPrest l’integrazione aggiorna i seguenti campi del documento con i relativi dati trasmessi (nel documento l’operatore che ha inserito il documento rimarrà l’operatore CUP)

• data documento,

• verifica compilazione codice fiscale,

• Ric. stampata elettr. riconosciuta da biffatura,

• Ric. stampata elettr. riconosciuta da altra verifica ,

• ricetta suggerita,

• patologia,

• codice priorità,

• tipo rilevazione reddito,

• fascia di reddito

• Flag previsto contributo digitalizzazione

• Esenzione documento Se i campi del medico prescrittore non sono stati trasmessi (o non sono completi) rimarrà indicato il medico presente in SysPrest altrimenti viene aggiornato con i dati del medico trasmesmessi.




Cassa

Le operazioni di cassa verranno registrate tutte con la cassa indicata nella tabella ambiente dell’integrazione (ECOMEDICA_0005_AMBIENTE.CASSA_ID). La data d’incasso sarà la data “data fine erogazione” indicata in schedulazione dell’elaborazione. La modalità di pagamento è sempre “contanti”. Eventuali documenti erogate in parte dalla ASL ed in parte da Ecomedica, dovranno essere pagate solo presso sportelli ASL.

Prestazioni

Potranno essere erogate solo prestazioni prenotate o comunque collegabili a prenotazioni (aggiuntive). Non saranno gestite le prestazioni di tipo “sostitutive”. Per la classificazione delle prestazioni in contabilizza per le “confermate” il codice del medico proscrittore è impostato al medico del documento se presente altrimenti il medico dell’agenda. Per le aggiuntive non viene indicato il proscrittore. In erogazione il medico erogante non viene valorizzato. Viene invece valorizzato il centro di costo erogante. Per le prenotazioni che vengono “modificate” per l’associazione di prestazioni “aggiuntive” viene registrato nel LOG delle prenotazioni la modifica (con OPERAZIONE=NW e OPERAZIONE_TIPO_ID = 4 “Aggiunta su Prenotazione esistente per stesso giorno/ora”). Per le prenotazioni trasmesse nel file “non erogato-non presentato“ il sistema registra l’erogato di tipo “non erogato” e “non presentato”. Al termine dell’elaborazione per le prestazioni delle prenotazioni elaborate rimaste senza l’indicazione dell’accesso il sistema inserirà l’accesso di tipo “non erogato” (con data e ora erogazione data odierna di elaborazione) per i documenti con classificati “chiusura automatica della contabilizzazione” .




I campi con * sono obbligatori.

Tracciato file prenotazioni “NON EROGATE” e “NON PRESENTATO”

CAMPO LUNG. NOTE TIPO CONTROLLI

PRENOTAZIONE_ID 10 Codice prenotazione SysPrest – numerico

testo * • Il campo deve essere valorizzato altrimenti si segnala un errore cod.66

• Il valore del campo deve essere numerico altrimenti si segnala un errore cod.67

• codice prenotazione valida per l’Ecomedica (struttura Ecomedica su agende SSN) altrimenti si segnala un errore cod.68

• Nessuna delle prestazioni della prenotazione deve essere indicato l’accesso (accesso di tipo “erogato” o accesso o di tipo “non erogato” o “non presentato”) altrimenti si segnala un errore cod.55

• Nessuna delle prestazioni della prenotazione deve contabilizzata (collegata a documento) altrimenti si segnala un errore cod.74

• Il Codice prenotazione non deve presente anche nel file prestazioni altrimenti si segnala un errore cod.92

EROGATO_TIPO 1 =1 se prenotazione non erogata =2 se non presentato


• Il valore del campo deve essere tra i valori ammessi altrimenti si segnala un errore cod.76

Tracciato file Impegnativa


PRG_IMPEGNATIVA 10 Numero progressivo documento Ecomedica



• Il documento deve avere prestazioni altrimenti si segnala un errore cod.90

NUM_IMPEGNATIVA 15 Numero impegnativa (se documento di tipo “non impegnativa” lasciare il campo vuoto )

testo Se campo valorizzato si effettuano i seguenti controlli:

• L’impegnativa non deve essere già stata trasmessa dell’Ecomedica in precedenti importazioni (terminate correttamente) per documenti con FLG_CONTABILIZZATO =SI altrimenti si segnala un errore cod.3

• Il numero impegnativa nel file non deve essere presente più volte altrimenti si segnala un errore cod.4

• Se impegnativa già presente in SysPrest le proprietà devono essere uguali a quelle ricevute (data, esenzione, ….) altrimenti si segnala un errore cod.5

• Se impegnativa già presente in SysPrest le prestazioni associate al documento SysPrest non devono essere erogate (di qualsiasi tipo) altrimenti si segnala un errore cod.80 su documenti con FLG_CONTABILIZZATO =SI

• Il codice ente (primi tre caratteri del numero impegnativa) deve essere un codice valido presente in tabella tblEnti, altrimenti si segnala un errore cod. 99

• L’anno (quarto e quinto carattere del numero impegnativa) deve essere un anno >2003 e < dell’anno corrente, altrimenti si segnala un errore cod. 100

DATA_DOCUMENTO 10 Data impegnativa se è presente l’impegnativa; altrimenti data documento (formato GG/MM/AAAA)


• Il valore del campo deve essere una data valida altrimenti si segnala un errore cod.7

• Anno della data documento deve essere >= 2000 altrimenti si segnala un errore cod.94




• Anno della data documento deve essere <= anno corrente altrimenti si segnala un errore cod.95

ASSISTITO_CODICE 10 Codice assistito SysPrest testo * • Il campo deve essere valorizzato altrimenti si segnala un errore cod.24

• il valore del campo deve essere numerico altrimenti si segnala un errore cod.25

• codice assistito presente in SysPrest numerico altrimenti si segnala un errore cod.26

• il codice assistito deve essere uguale al codice assistito delle prenotazioni altrimenti si segnala un errore cod.78

• il codice assistito deve essere uguale al codice assistito del documento se già presente in Sysprest altrimenti si segnala un errore cod.113

FLG_VER_COD_FISCALE 1 =1 verifica della correttezza del codice fiscale; altrimenti =0 (se documento di tipo “non impegnativa” lasciare il campo vuoto )

testo Se documento di tipo “impegnativa” (campo NUM_IMPEGNATIVA valorizzato) si effettuano i seguenti controlli:

• Il campo deve essere valorizzato altrimenti si segnala un errore cod.8

• il valore del campo deve essere tra i valori ammessi altrimenti si segnala un errore cod.9

FLG_BIFFATA_STAMPA_ELET 1 =0 assenza della biffattura nell’apposito spazio; =1 Ricetta informatizzata con biffattura del campo “stampa PC” e codice fiscale barcode; =2 Ricetta informatizzata con sola biffattura del campo “stampa PC” (se documento di tipo “non impegnativa” lasciare il campo vuoto )




ALTRA_VER_STAMPA_ELET 1 =1 ricetta stampata elettronicamente riconosciuta da altra verifica; =2 non riconosciuta;=3 altra verifica non effettuata (se documento di tipo “non impegnativa” lasciare il campo vuoto )




RICETTA_SUGGERITA 1 =1 ricetta suggerita;=2 ricetta non suggerita;=3 non rilevato (se documento di tipo “non impegnativa” lasciare il campo vuoto )




MEDICO_CODICE_FISCALE 16 Codice fiscale del medico testo

Se il medico è presente in anagrafe medici di SysPrest si considera valido (non si segnalano errori se il medico non è presente in anagrafe Sysprest)

MEDICO_REGIONE 3 Regione di appartenenza del medico testo

MEDICO_USL

3 Usl di appartenenza del medico testo

MEDICO_TIPOLOGIA 2 Tipologia del medico testo

CODICE_PRIORITA 2 Codice di priorità della ricetta. Valori ammessi:

01- bianco (P) 02- azzurro (D) 03- verde (B)







99- non colore (se documento di tipo “non impegnativa” lasciare il campo vuoto )

IMPORTO_PAGATO 10 Importo pagato per la ricetta (es. 36,15 numerico con virgola); se importo pagato non presente valorizzare con 0


• il valore del campo deve essere numerico altrimenti si segnala un errore cod.20

• se l’impegnativa è già presente in SysPrest → l’impegnativa SysPrest non deve essere già pagata altrimenti si segnala un errore cod.21

• Se l’impegnativa è già presente in SysPrest e ha associato prestazioni in parte dall’ASL l’importo pagato deve essere valorizzato con 0 altrimenti si segnala un errore cod.23

• L’importo pagato può essere >0 se FLG_CONTABILIZZATO =SI altrimenti si segnala errore num.110

• L’importo pagato deve essere compressivo dell’importo dei ticket aggiuntivi e del contributo digitalizzazione (dove previsti)

• Se in fase di registrazione del movimento di cassa l’importo pagato indicato risultasse diverso dall’importo accertato del documento il sistema non registrerà il movimento di cassa e una spunta indicherà i documenti per cui non è stato registrato il movimento di cassa (questo controllo non è possibile applicarlo in fase di controllo formale del file in quanto per calcolare l’importo del documento i dati devono essere già scaricati in archivio)

• L’importo pagato non deve comprendere bollo.

TIPO_RILEVAZIONE_REDITO 1 Modalità di rilevazione della situazione economica dell’assistito. Valori ammessi:

• vuoto

• 1 - Presentato modulo ISEE

• 2 - Autocertificazione

• 3 - Non dichiarato

testo • Il campo deve essere valorizzato se almeno una delle prestazioni associate al documento è “non esente” altrimenti si segnala un errore cod.101


FASCIA_REDITO_ID 1 Fascia di redito dell’assistito. Valori ammessi:

• vuoto

• 1 0 - <= 36.151,98

• 2 > 36.151,98 <= 70.000

• 3 >70.000 <= 100.000

• 4 > € 100.000

testo • Il campo deve essere valorizzato se almeno una delle prestazioni associate al documento è “non esente” altrimenti si segnala un errore cod.102


• se il campo TIPO_RILEVAZIONE_REDITO =3 il campo deve essere valorizzato a 4 (se l’assistito rifiuta di fornire l’informazione della fascia di redito viene applicata la fascia di redito più alta

ICD9 5 Codice della patologia • il valore del campo deve essere tra i valori ammessi (codice presente nella tabella SysPrest tblPatologie_ICD9CM )altrimenti si segnala un errore cod.103

IMPORTO_CONTRIBUTO_DIGITALIZZAZIONE

10 =0 se importo contributo non applicato; altrimenti importo contributo che l’assistito ha pagato

testo • Il campo deve essere valorizzato altrimenti si segnala un errore cod. 104

• il valore del campo deve essere numerico altrimenti si segnala un errore cod. 104

• L’importo contributo può essere >0 se FLG_CONTABILIZZATO =SI altrimenti si segnala errore num.111




FLG_CONTABILIZZATO

1 =SI (se la contabilizzazione deve essere chiusa) =NO (se la contabilizzazione deve rimanere aperta (caso della radioterapia – Ecomedica chiuderà manualmente su SysPrest))

testo NUOVO CAMPO

• campo obbligatorio altrimenti si segnala un errore cod. 112

• il campo deve essere valorizzato con i valori ammessi (SI-NO)

Tracciato file prestazioni


PRG_IMPEGNATIVA 10 Numero progressivo documento Ecomedica



PRG_PRESTAZIONI 10 Numero progressivo prestazione Ecomedica



• La prestazione deve avere il documento altrimenti si segnala un errore cod.91

CODICE_PRESTAZIONE 10 Codice prestazione SysPrest testo * • Il campo deve essere valorizzato altrimenti si segnala un errore cod.52


• Codice prestazione SysPrest deve essere associato ad agende attive della struttura Ecomedica altrimenti si segnala un errore cod.54

• La prestazione deve essere di tipo “prestazione semplice” altrimenti si segnala un errore cod.82

QUANTITA 10 Numero prestazioni effettuate - numerico



• Il campo deve essere=1 altrimenti si segnala un errore cod.81

ICD9 5 Codice della patologia testo • il valore del campo deve essere tra i valori ammessi (codice presente nella tabella SysPrest tblPatologie_ICD9CM )altrimenti si segnala un errore cod.59

DATA_EROGAZIONE 10 Data erogazione della prestazione; formato GG/MM/AAAA


• Il valore del campo deve essere una data valida altrimenti si segnala un errore cod.61

• la data di erogazione non può essere > della data odierna altrimenti si segnala un errore cod.62

• la data di erogazione deve essere > della data del documento altrimenti si segnala un errore cod.98

ORA_EROGAZIONE 4 Ora erogazione della prestazione espressa in minuti (es. 09.00 →540)



• Il valore del campo deve essere una ora valida (>=0 and <=1440) altrimenti si segnala un errore cod.65

PRENOTAZIONE_ID 10 Codice prenotazione SysPrest – numerico



• codice prenotazione valida per l’Ecomedica (struttura Ecomedica su agende SSN) altrimenti si segnala un errore cod.68




• la prenotazione non deve essere estratta dal MALUM altrimenti si segnala un errore cod.69

• Nessuna delle prestazioni della prenotazione deve essere indicato l’accesso (accesso di tipo “erogato” o accesso o di tipo “non erogato” o “non presentato”) altrimenti si segnala un errore cod.55

• Nessuna delle prestazioni della prenotazione deve essere indicato dei “farmaci” altrimenti si segnala un errore cod.93

Se prenotazione trasmessa senza numero impegnativa si effettua il seguente controllo:

• Tutte le prestazioni della prenotazione non devono essere già state contabilizzate altrimenti si segnala un errore cod.74

Se prenotazione trasmessa con numero impegnativa si effettua il seguente controllo:

• Se le prestazioni della prenotazione risultano contabilizzate devono avere lo stesso numero d’impegnativa altrimenti si segnala un errore cod.79

ESENZIONE 11 Codice esenzione delle prestazioni. Se la persona è “non esente” per la prestazione valorizzare il campo con “0”.


• il valore del campo deve essere tra i valori ammessi (codice presente nella tabella SysPrest tblEsenzioni_codici)altrimenti si segnala un errore cod.71




FASI Elaborazione

• Pulizia tabelle d’appoggio

• Importazione file in tabella: ELAB_ECOMEDICA_0010_INPUT_IMPEGNATIVA, ELAB_ECOMEDICA_0020_INPUT_PRESTAZIONI, ELAB_ECOMEDICA_0030_INPUT_NON_EROGATO

• Controllo file impegnativa in tabella ELAB_ECOMEDICA_0040_APPO_IMPEGNATIVA

• Controllo file prestazioni in tabella ELAB_ECOMEDICA_0050_APPO_PRESTAZIONI

• Controllo file “non erogato” in tabella ELAB_ECOMEDICA_0060_APPO_NON_EROGATO

• Verifica se ci sono stati errori nei controlli o Nessun errore

▪ Preparazione in tabelle di appoggio dati per documenti da registrare ▪ Inserimento documenti senza impegnativa ▪ Inserimento documenti di tipo impegnativa ▪ Apertura “contabilizza” per documenti già presenti in SysPrest (stesso numero

d’impegnativa) ▪ Preparazione in tabelle di appoggio dati prestazioni (con classificazione e estensioni

medici): - prestazioni “Ecomedica” da scollegare dai documenti già presenti in archivio - prestazioni da confermare (stesso numero di prenotazione, stessa quantità,

stesso codice di prestazione) - prestazioni aggiuntive - “LOG prenotazioni” per prenotazioni modificate per prestazioni aggiuntive

▪ Inserimento/conferma/scollega prestazioni ▪ Inserimento strutture competenza documento ▪ Inserimento in “LOG prenotazioni” ▪ Loop sui documenti elaborati per calcolo importo accertato e chiusura documento ▪ Preparazione in tabelle di appoggio erogazioni da registrare (con classificazione):

- prestazioni con accesso di tipo “non erogato” da file “non erogato” - prestazioni con accesso di tipo “non presentato” da file “non erogato” - prestazioni con accesso di tipo “erogato” da file “prestazioni” - prestazioni con accesso di tipo “non erogato” per prestazioni delle

prenotazioni trasmesse rimaste da erogare ▪ inserimento erogazione delle prestazioni (con estensione assistito e classificazione

erogato) ▪ Loop sui documenti elaborati con importo pagato > 0 per registrazione movimento di

cassa ▪ Spunta prenotazioni con “data prenotazione” >= “data inizio integrazione” and “data

prenotazione” <= “data fine erogazione dell’elaborazione” che non hanno indicato l’accesso.

▪ Scarico in tabelle di OUT in dati elaborati e ricevuti ▪ Classificazione dell’elaborazione come elaborata correttamente.

o Errori

▪ Scarico in tabelle di OUT in dati ricevuti ▪ L’elaborazione termina con errore e nelle tabelle

ELAB_ECOMEDICA_4300_OUT_ERRORI_IMPEGNATIVA ELAB_ECOMEDICA_4400_OUT_ERRORI_PRESTAZIONI ELAB_ECOMEDICA_4500_OUT_ERRORI_NON_EROGATO Vengono riportati i campi che non hanno superato i controlli




Disegno del database

La tabella ECOMEDICA_0005_AMBIENTE

La tabella ECOMEDICA_0010_STRUTTURE (strutture SysPrest che appartengono all’integrazione)

Tabella ECOMEDICA_0070_ALL_PRENOT_TESTATA

Tabella ECOMEDICA_0075_ALL_PRENOT_PRESTAZIONI Tabelle utilizzate dall’elaborazione:

- ELAB_ECOMEDICA_0000_ELAB (dati appoggio elaborazione in corso) - ELAB_ECOMEDICA_0010_INPUT_IMPEGNATIVA (dati ricevuti file impegnativa) - ELAB_ECOMEDICA_0020_INPUT_PRESTAZIONI (dati ricevuti file prestazioni) - ELAB_ECOMEDICA_0030_INPUT_NON_EROGATO (dati ricevuti file non erogato) - ELAB_ECOMEDICA_0040_APPO_IMPEGNATIVA (dati appoggio file impegnativa) - ELAB_ECOMEDICA_0042_APPO_IMPEGNATIVA_NUM - ELAB_ECOMEDICA_0043_ESENZIONI - ELAB_ECOMEDICA_0045_APPO_ERRORI_IMPEGNATIVA - ELAB_ECOMEDICA_0050_APPO_PRESTAZIONI (dati appoggio file prestazioni) - ELAB_ECOMEDICA_0055_APPO_ERRORI_PRESTAZIONI - ELAB_ECOMEDICA_0056_PRENOT_DOC - ELAB_ECOMEDICA_0057_PRENOT_DOC_SYSP - ELAB_ECOMEDICA_0060_APPO_NON_EROGATO (dati appoggio file non erogato) - ELAB_ECOMEDICA_0065_APPO_ERRORI_NON_EROGATO - ELAB_ECOMEDICA_0070_COD_ERRORI (anagrafe errori dati trasmessi) - ELAB_ECOMEDICA_2000_RichiestePrestazioni - ELAB_ECOMEDICA_2010_RichiestePrestazioni_classificazione - ELAB_ECOMEDICA_2100_Accessi - ELAB_ECOMEDICA_2120_Accessi_AppoPrestPrenot - ELAB_ECOMEDICA_3000_OUT_RichiestePrestazioni - ELAB_ECOMEDICA_3010_OUT_RichiestePrestazioni_classificazione - ELAB_ECOMEDICA_3100_OUT_Accessi - ELAB_ECOMEDICA_4000_OUT_IMPEGNATIVA - ELAB_ECOMEDICA_4100_OUT_PRESTAZIONI - ELAB_ECOMEDICA_4200_OUT_NON_EROGATO - ELAB_ECOMEDICA_4300_OUT_ERRORI_IMPEGNATIVA - ELAB_ECOMEDICA_4400_OUT_ERRORI_PRESTAZIONI - ELAB_ECOMEDICA_4500_OUT_ERRORI_NON_EROGATO - ELAB_ECOMEDICA_4600_OUT_SPUNTA_PREST_DATA_FINE_EROG - ELAB_ECOMEDICA_5000_PRENOT_LOG_001_testata - ELAB_ECOMEDICA_5010_PRENOT_LOG_005_PRESTAZIONI




INTEGRAZIONE IDM

Premessa

L’integrazione tra i due sistemi avviene con delle Storede Procedure messe a disposizione da SysPrest.

- Tutti gli utenti SysPrest, dipendenti, operatori di strutture esterne e operatori di procedura (non umani) vengono creati da IDM chiamando la Storede Procedure “IDM_005_UTENTE_INS”. In fase di creazione dell’utente dovrà essere indicato (obbligatorio) anche una associazione ruolo/struttura. L’associazione all’operatore delle casse/feedback e altri ruoli/strutture saranno gestite direttamente dal modulo web “gestione operatori” di SysPrest.

- IDM può aggiornare la descrizione di un utente, l’e-mail, il codice fiscale e impostare la password a “password” (nel caso l’operatore si fosse dimenticato la propria password) chiamando la Storede Procedure “IDM_006_UTENTE_UPD”.

- IDM disattiva in modo definitivo un utente chiamando la Storede Procedure IDM_007_UTENTE_DISATTIVA. Un utente disattivato da IDM in SysPrest non sarà possibile riattivarlo (potrà essere riattivato solo da IDM). Gli operatori disattivati da IDM sono quelli con motivo di sospensione uguale a 3 “Disattivato IDM”

- IDM può riattivare un utente chiamando la Storede Procedure IDM_008_UTENTE_ATTIVA. Quando viene riattivato un utente la password verrà impostata a “password”.

- Su SysPrest è possibile riattivare solo gli utenti sospesi di tipo “non utilizzo del sistema da x giorni”

- Su SysPrest non è possibile inserire un nuovo operatore.

- Nel modulo di aggiornamento di SysPrest è possibile modificare solo i seguenti campi: gruppo, CupCode, flag “prenota fuori fascia”, flag “forza prenotazione” e imposta password a “password”.

- Le operazioni effettuate sono memorizzate con un specifico utente di SysPrest “IDM” (memorizzato nella tabella IDM_010_AMBIENTE)

L’utente SQL (User=idm - Password=idm) a disposizione di IDM può accedere alle seguenti viste/tabelle

• Tabella Utenti_001_Operatori con permessi: INSERT, SELECT, UPDATE • Tabella Utenti_003_OperatoriRuoliStrutture con permessi: INSERT, SELECT • Tabella Utenti_002_Ruoli con permessi: SELECT • Vista V_IDM_001_STRUTTURE con permessi: SELECT • Stored procedure

o IDM_005_UTENTE_INS o IDM_006_UTENTE_UPD o IDM_007_DISATTIVA o IDM_008_ATTIVA




Storede Procedure IDM_005_UTENTE_INS

Parametri Input: - @UserName varchar(12) Obbligatorio - @UtenteDsc varchar(150) Obbligatorio - @E-mail varchar(200) - @UtenteCodiceFiscale varchar(16) - @idRuolo varchar(3) Obbligatorio - @idStruttura int Obbligatorio

Parametri Output: nessuno La storede procedure effettua una query d’inserimento nella tabella Utenti_001_Operatori, una query d’inserimento nella tabella Utenti_003_OperatoriRuoliStrutture e una registrazione sul LOG.

INSERT INTO Utenti_001_Operatori (userName, password, utenteDsc, flgSospeso, data_inizio, data_fine, data_scadenza_psw, motivo_sospensione_id, E_MAIL, CUPCODE_ID, FLG_PRENOT_CC_FUORI_FASCIA, MEDICINA_GRUPPO_ID, FLG_PRENOT_FORZATA, UtenteCodiceFiscale) VALUES (@UserName, ‘password’, @UtenteDsc, 0, GETDATE(),NULL, GETDATE ()-1,0, @E-mail, 0,0,0,0, @UtenteCodiceFiscale) SET @IdUtente= @@IDENTITY INSERT INTO Utenti_003_OperatoriRuoliStrutture (idUtente, idRuolo,idStruttura) VALUES (@IdUtente, @idRuolo, @idStruttura) EXEC p_Utenti_050_operatore_LOG (@UserName ,1 ,@IdUtenteIntegrazione)

Se i la UserName è già presente in archivio l’errore restituito sarà quello di SQL SERVER (chiave duplicata). Non verrà verificato se il ruolo o la struttura sono presenti in anagrafe SysPrest. I campi obbligatori vengono controllati da SQL SERVER, in qunato in archivio i campi non ammetono NULL.




Storede Procedure IDM_006_UTENTE_UPD

Parametri Input: - @UserName varchar(12) Obbligatorio - @UtenteDsc varchar(150) Obbligatorio - @E-mail varchar(200) - @UtenteCodiceFiscale varchar(16) - @FLG_PSW_DEFAULT int Obbligatorio (=1 se la password deve essere

impostata a “password”; altrimenti =0) Parametri Output: nessuno Inizialmente la storede procedure verifica che la UserName sià presente in archivio:

se presente effettua una query di aggiornamento nella tabella Utenti_001_Operatori e una registrazione sul LOG:

UPDATE Utenti_001_Operatori SET utenteDsc=@UtenteDsc, E_MAIL =@E-mail, UtenteCodiceFiscale= @UtenteCodiceFiscale WHERE userName =@UserName

IF @FLG_PSW_DEFAULT=1 BEGIN

UPDATE Utenti_001_Operatori SET password= ‘password’ ,

data_scadenza_psw=getdate()-1 WHERE userName =@UserName

END EXEC p_Utenti_050_operatore_LOG (@UserName ,2 ,@IdUtenteIntegrazione)

Altrimenti viene restituito un errore SQL SERVER forzato: RAISERROR ('Operatore non presente in archivio',16,1)




Storede Procedure IDM_007_DISATTIVA

Parametri Input: - @UserName varchar(12) Obbligatorio

Parametri Output: nessuno

Inizialmente la storede procedure verifica che la UserName sià presente in archivio

se presente effettua una query di aggiornamento nella tabella Utenti_001_Operatori e una registrazione sul LOG:

UPDATE Utenti_001_Operatori SET flgSospeso =1, data_fine =GETDATE(), motivo_sospensione_id =3 WHERE userName =@UserName

EXEC p_Utenti_050_operatore_LOG (@UserName ,3 ,@IdUtenteIntegrazione)


Storede Procedure IDM_008_ATTIVA

Parametri Input: - @UserName varchar(12) Obbligatorio

Parametri Output: nessuno

Inizialmente la storede procedure verifica che la UserName sià presente in archivio:

se presente effettua una query di aggiornamento nella tabella Utenti_001_Operatori (e aggiornamento ultima data di collegamento) e una registrazione sul LOG:

UPDATE Utenti_001_Operatori SET flgSospeso =0,

data_fine =NULL, motivo_sospensione_id =NULL,

password= ‘password’ , data_scadenza_psw=getdate()-1

WHERE userName =@UserName

UPDATE Sito_010_LOG SET data_ultimo_collegamento=GETDATE()

WHERE idUtente = @wUtente

EXEC p_Utenti_050_operatore_LOG (@UserName ,4 ,@IdUtenteIntegrazione)





INTEGRAZIONE PRENOTATO/CONTABILIZZATO/CASSA - EROGATO

Comunicazione delle Richieste SysPrest al DISPATCHER

Quando su SysPrest si verifica uno dei seguenti eventi su agende che prevedono l’integrazione (identificativo applicativo diverso da “non integrazione” con codice “0”) verrà invocato il Web Service “Richieste” messo a disposizione dal DISPATCHER :

- Nuova prenotazione

- Cancellazione prenotazione

- Spostamento prenotazione (singola prestazione, intero foglio su stessa agenda, intero foglio su altra agenda con lo stesso applicativo d’integrazione indicato)

- Modifica prenotazione:

▪ aggiunta prestazione dalla funzione di prenotazione,

▪ aggiunta prestazione (da contabilizza e accettazione)

▪ cancellazione prestazione aggiuntiva (da contabilizza e accettazione) alla prenotata

- Cancellazione prestazione aggiuntiva alla prenotazione da contabilizza

- Incasso

Il web service non viene invocato contestualmente alla prenotazione/contabilizzazione, ma è previsto un servizio di Windows “CSIO SysPrest Dispatcher Richiesta” che ogni x secondi (indicato nel file di configurazione del servizio) verificherà in una determinata tabella di LOG se ci sono dati da trasmettere al DISPATCHER.

Le richieste sono comunicate al DISPATCHER se per l’assisto è presente il “codice assistito aziendale”.

Il servizio elabora le richieste assegnando una priorità maggiore alle richieste generate con data prenotazione uguale alla data odierna (data prenotazione= data odierna) (come da p1.1804-2014) .

Viene mantenuto traccia dell’esito (positivo o negativo) della chiamata al Web Service per ogni singolo movimento da trasmettere.

In fase d’installazione per le agende già esistenti che verranno classificate come “integrazione” (agendo direttamente sull’archivio) è necessario inviare al DISPATCHER le prenotazioni attive con data prenotazione > data inizio integrazione (attività che verrà effettuata manualmente da CSIO).

Non è previsto nessun sistema di notifica per i messaggi non inviati correttamente (il DISPATCHER non è attivo, messaggi XML che non corretto) e arresto del servizio.

La contabilizzazione di documenti di tipo deposito non viene comunicata all’integrazione.

Per le prenotazioni il messaggio della richiesta viene creato solo la data prenotazione >= data odierna – 30 giorni.




NOTA Quando si invia una contabilizzazione si inviano anche prestazioni che dovrebbero essere accettate in data futura. NOTA TECNICA I messaggi di richiesta da inviare vengono memorizzati nel db

SysPrestV3_Empoli_INTEGRAZIONI nella tabelle dbo.INTEGRAZIONE_0020_C_RICHIESTE dbo.INTEGRAZIONE_0025_C_RICHIESTE_PREST Le richiesta da inviare sono rappresentati dalla vista dbo.V_INTEGRAZIONE_0010_C_RICHIESTE_TESTATA ( WHERE (dbo.INTEGRAZIONE_0020_C_RICHIESTE.FLG_DA_INVIARE = 1) AND (dbo.xAnagraficaBase.ASSISTITO_ID_ANAGRAFE_ULS IS NOT NULL) AND (dbo.INTEGRAZIONE_0020_C_RICHIESTE.Integrazione_DataOraProcessato IS NULL))




Web Services Richieste

Il messaggio è composto da una testata (dettaglio della richiesta) e da più righe (prestazioni).

L’identificativo della testata del messaggio è il “numero richiesta”.

La struttura dati è la seguente:

<RICHIESTA>

<TESTATA>

<RICHIESTA_ID> numerico *

<STATO_RICHIESTA> testo di 2 caratteri (A richiesta attiva; C = richiesta cancellata) *

<AGENDA_ID> Numerico (codice dell’agenda) *

<STRUTTURA_COD_STS11> testo di 6 caratteri (indicato nell’equipe dell’agenda) *

<APPLICATIVO_COD> testo di 10 caratteri (codice identificativo applicativo di destinazione del messaggio indicato nell’agenda)

*

<STANZA_COD> Testo di 8 caratteri (codice della stanza esteso). Per prenotazioni stanza valida alla data di prenotazione; altrimenti per prestazioni in accesso diretto stanza valida alla data odierna.

*

<STANZA_NUM> Testo di 4 caratteri (numero della stanza – 1 carattere identicativo palazzina + il secondo carattere dell’identificativo del piano (es.T3 → 3) + gli ultimi due caratteri dell’identificativo della stanza (es.012 → 12)

*

<STANZA_GRUPPO_COD> Testo di 3 caratteri (codice gruppo della stanza - se >= 900 identifica una sala operatoria).

*

<UNITA_ORG_EROGANTE> *

<CDC_COD_EROGANTE> testo di 20 caratteri. Per prenotazioni CDC valido alla data di prenotazione; altrimenti se prestazione accesso diretto CDC valido alla data odierna

< DATA_CONTATTO> numerico (formato YYYYMMDD) *

<REGIME> testo di 3 caratteri (può assumere solo uno dei seguenti valori: SSN, ALP, AAP)

*

</TESTATA>

<ASSISTITO>

<ASSISTITO_ID_AZIENDALE> Testo di 8 caratteri. Contiene il codice aziendale dell’assisto che deve essere numerico formato con gli zeri a sinistra (esempio 00012345).

*

<ASSISTITO_COGNOME> testo di 50 caratteri *

<ASSISTITO_NOME> testo di 50 caratteri *

<ASSISTITO_SESSO> testo di 1 carattere (F o M) *

<ASSISTITO_DATA_NASCITA> numerico (formato YYYYMMDD) *

<ASSISTITO_COD_FISCALE> testo di 16 caratteri *

<ASSISTITO_COMUNE_NASCITA> testo di 6 caratteri (codice ISTAT comune nascita) *

</ASSISTITO> *

<PRENOTAZIONE> valorizzato solo se la richiesta e di tipo “prenotazione”

< PRENOTAZIONE _ID> numerico

<PRENOTAZIONE_DATA_ORA> numerico (formato YYYYMMDDHHMM)

<PRENOTAZIONE_FLG_FORZATA> numerico (=1 se prenotazione forzata; altrimenti =0)

<IMPEGNATIVA_NUM> testo di 15 caratteri (indicata in fase di prenotazione)

<IMPEGNATIVA_DATA> numerico (formato YYYYMMDD) (indicata in fase di prenotazione)

<UNITA_ORG_RICHIEDENTE> testo di 20 caratteri (Valorizzato solo se prenotazione è stata registrata dall’apertura in contesto di SysPrest da parte di Galileo)

</PRENOTAZIONE>

<PRESTAZIONI>

<PRESTAZIONE>

<PROGRESSIVO> numerico *

< COD_AZIENDALE > testo di 30 caratteri (codice del catalogo aziendale) *

< COD_REGIONALE > testo di 30 caratteri (codice del catalogo REGIONALE)

<QUANTITA> numerico (fisso a 1) *

<DESCRIZIONE> testo di 150 caratteri descrizione della prestazione di SysPrest *

<ESENZIONE_COD> Se prestazione contabilizzata verrà riportata l’esenzione della prestazione contabilizzata; altrimenti viene valorizzata con l’esenzione indicata in anagrafe assistito se presente; se assistito “non esente il campo non sarà valorizzato”




<DOCUMENTO> valorizzato solo se prestazione contabilizzata

<DOCUMENTO_ID> numerico

<IMPEGNATIVA_NUM> testo di 15 caratteri

<DATA_DOC> numerico (formato YYYYMMDD – data del documento/dell’impegnativa)

<ESENZIONE_COD> testo di 11 caratteri

<IMPORTO_ACCERTATO>. Numerico con virgola (importo del documento)

<IMPORTO_PAGATO> Numerico con virgola (importo pagato del documento)

<STATO_DOC> testo di 4 caratteri

=NPAG non pagato

=PAG pagato (importo accertato=importo pagato)

=PPAG importo pagato in parte (importo pagato <> 0)

<MEDICO_COD_FISCALE> testo di 16 caratteri (medico prescrittore)

<MEDICO_COD_REGIONE> testo di 3 caratteri

<MEDICO_COD_USL> testo di 3 caratteri

<MEDICO_COD_TIPOLOGIA> testo di 2 caratteri

<IMPEGNATIVA_COD_PRIORITA> testo di 2 caratteri (01 bianco (P); 02 azzurro (D); 03 verde (B); 99- non colore) – campo valorizzato se documento di tipo impegnativa

<FLG_VER_COD_FISCALE> numerico (=1 verifica della correttezza del codice fiscale; altrimenti =0 ) – campo valorizzato se documento di tipo impegnativa

< FLG_BIFFATA_STAMPA_ELET> numerico (=0 assenza della biffatura nell’apposito spazio;=1 ricetta informatizzata e codice fiscale barcode; =2 ricetta informatizzata) – campo valorizzato se documento di tipo impegnativa

< ALTRA_VER_STAMPA_ELET> numerico (=1 ricetta stampata elettronicamente riconosciuta da altra verifica; =2 non riconosciuta;=3 altra verifica non effettuata ) – campo valorizzato se documento di tipo impegnativa

< QUESTITO_DIAGNOSTICO> testo di 500 caratteri

</DOCUMENTO>

<ACCESSO> Valorizzato se prestazione erogata

<ACCESSO_ID> Numerico (identificativo dell’erogazione SysPrest)

<PROGRESSIVO_INTEGRAZIONE> testo di 30 caratteri

< NUM_CASO> testo di 50 caratteri

</ACCESSO>

</PRESTAZIONE>

<PRESTAZIONE>

-----------------

</PRESTAZIONE>

</PRESTAZIONI>

</RICHIESTA>

I campi con * sono obbligatori

Se richiesta non prenotata il TAG <PRENOTAZIONE> non viene inviato.

Se prestazioni non contabilizzata il TAG <DOCUMENTO> non viene inviato.

Se prestazioni non erogata il TAG <ACCESSO> non viene inviato.

Web Services Esito chiamate


<EsitoChiamata>

<CodiceEsito > → testo di 5 caratteri

<Descrizione Esito > → testo di 300 caratteri

</EsitoChiamata>

Se la chiamata va a buon fine il codice di errore restituito sarà “00000”




l Web Service “Richieste” messo a disposizione dal DISPATCHER

• In ambiente di TEST (server ip.172.16.100.56) viene invocato il WS

http:// jcapstest2.usl11.net:9000/prjWS_Prenotazione_In_jce_jcdPrenotazione_In_prjCUP_WS_u002F_dpWS2024399290/ExecutePortType

• In ambiente di produzione (server ip.200.1.1.117) viene invocato il WS

http://jcaps.usl11.net:9000/prjWS_Prenotazione_In_jce_jcdPrenotazione_In_prjCUP_WS_u002F_dpWS2024399290/ExecutePortType






Servizio di Windows “CSIO SysPrest Dispatcher Richiesta”

Prerequisiti

• Microsoft .NET Framework 2.0

• Microsoft .NET Framework 3.0 (http://go.microsoft.com/fwlink/?LinkId=70848)

• Microsoft .NET Framework 3.5 SP1 (http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe)

• programma service trace viewer per aprire eventuali file di log (.svclog ) Installato Il servizio in produzione è installato nel server vintegra.usl11.net nel percorso “D:\Program Files\CSIO” Installazione

Nella cartella del servizio è presente le note per l’installazione. Se si deve rinstallare il servizio è necessario prima d’installare il servizio precedente.

http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe





Configurazione del servizio

Il file di configurazione CSIO.SysPrest.Integrazioni.Richiesta.exe.config del servizio si trova nel percorso dove è stato installato il servizio. Nel file di configurazione è possibile variare il tempo attesa di esecuzione del prossimo messaggi, indirizzo web service da invocare, attivazione del log dei messaggi elaborati. Importante: se si cambia la configurazione è necessario riavviare il servizio. Contenuto file configurazione NOTE <?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="IntervalloInterrogazioneCodaStandard" value="5" /> Tempo, espresso in secondi,di attesa di esecuzione del prossimo

messaggio

<add key="IntervalloInterrogazioneCodaProblemiDispatcher" value="300" /> Tempo, espresso in secondi,di attesa di esecuzione del prossimo messaggio nel caso si sia verificato precedentemente un errore di time out

</appSettings> <connectionStrings> <add name="SysPrestV3_Empoli_INTEGRAZIONI_ConnectionString" connectionString="Data

Source=192.168.210.237;Initial Catalog=SysPrestV3_Empoli_INTEGRAZIONI;Persist Security

Info=True;User ID=sa;Password=XXX" providerName="System.Data.SqlClient" />

Definizione della connessione al DB (non cambiare la proprietà nome)

</connectionStrings> <system.serviceModel> <bindings> <ws2007HttpBinding> <binding name="ExecutePortTypeBinding" /> </ws2007HttpBinding> </bindings> <client> <endpoint address="http://172.16.200.123:9000/

prjWS_Prenotazione_In_jce_jcdPrenotazione_In_prjCUP_WS_u002F_dpWS2024399290/

ExecutePortType"

Indirizzo web service da richiamare

binding="ws2007HttpBinding" bindingConfiguration="ExecutePortTypeBinding" contract="ExecutePortType" name="ExecutePortType" />

</client> <diagnostics> <messageLogging logEntireMessage="true" maxMessagesToLog="5000"

logMessagesAtServiceLevel="true" logMalformedMessages="true" /> logEntireMessage= true indica l’attivazione del LOG; il LOG

non viene attivato se non ci sono nessuna fonte di traccia (in <system.diagnostics> <sources>) maxMessagesToLog= numero massimo di messaggi scritti nel file

del log logMessagesAtServiceLevel= true per attivare log per HHTP

</diagnostics> </system.serviceModel> <system.diagnostics> <sources>   </sources> <sharedListeners> <add initializeData="SysPrest.Integrazioni.Richiesta.svclog"

type="System.Diagnostics.XmlWriterTraceListener" name="TracciaInXML" /> initializeData= file del log (se non specificato il percorso il file

si troverà nella caretella dove è installato il servizio). Il file con formato svclog si apre con il programma service trace viewer

</sharedListeners> <trace autoflush="true" /> </system.diagnostics> </configuration>




Avvio/Arresto

Da “strumenti di amministrazione” – “servizi” è possibile avviare/arrestare/o mettere in pausa il servizio “CSIO SysPrest Dispatcher Richiesta”

Il servizio viene configurato che non parta automaticamente all’avio del server.

Quando parte il servizio scrive sempre un evento informativo sui dati di configurazione.




Visualizzazione eventi

Da “strumenti di amministrazione“ – “eventi” è possibile consultare gli eventi del servizio. Gli eventi del servizio si provano nella cartella “SysPrest.Integrazioni” con origine “RichiestaClient”

Visualizzazione servizio da Task Manager Il nome dell’eseguibile del servizio è SysPrest_Richiesta_EXE




Disinstallazione Da Pannello di controllo\Programmi\Programmi e funzionalità è possibile disinstallare il servizio (con nome prodotto “CSIO Richiesta Client”

Quando si disinstalla bisogna aver chiuso la finestra di gestione dei servizi. Funzionamento servizio

Se il db di SysPrest non è attivo il servizio si arresta.

Le richiesta da inviare sono rappresentati dalla vista dbo.V_INTEGRAZIONE_0010_C_RICHIESTE_TESTATA.

Di seguito flusso di elaborazione:




Costruzione struttura dati Richiesta

Corretta ?

Invocazione web service

Time outException?

FaultException<JavaExcep

tionType> ?

Fault Exception?

CommunicationException ?

Si arresta il servizio

SI

NO

SI

NO

NO

OK ?

NO

NO

NO

Il sistema classifica il messaggio elaborato riportando nel campo “errore_richiesta” la descrizione dell’errore (integrazione_tipo_esito=2)

Il sistema classifica il messaggio elaborato riportando nel campo “integrazione_errore” la descrizione dell’errore (integrazione_tipo_esito=3)

SI

Il messaggi rimane da elaborare e il sistema scrive una avvertenza nel log degli eventi. Il sistema aumenta il tempo l’intervallo del timer (tempo indicato nel

file di configurazione)

Il sistema classifica il messaggio elaborato e nel campo “integrazione_esito_cod” viene riportato il codice dell’esito della chiamata (integrazione_tipo_esito=1). Viene ripristinato il tempo dell’intervallo del timer.



SI

SI

SI

Lettura messaggio da inviare




Inizializzazione delle code

Inserire nella tabella INTEGRAZIONE_0025_PRENOT_AGENDE_INVIARE le agende per cui si vuole inizializzare le code. E’ necessario indicare il codice dell’agenda, il codice dell’applicativo integrazione (es. RIS) , il codice dell’unità organizzativa e tipo operazione 1 “inizializzazione code”. ATT:NE: le agende inserite devono avere la stanza! Il processo SQL “SysPrest 29 - Integrazione - Inizializza coda prenotazione” eseguira alimentazione delle code. Per l’agenda vengono inviate le prenotazioni con AgendePrenotazioni.PrenotazioneData > GETDATE() – 1. E’ possibile lanciare il processo più volte per la stessa agenda (in tal caso verranno inserite più volte le stesse richieste).




DISPATCHER invia prestazioni erogate a SysPrest

Flusso integrazione

Web services Erogato

Il DISPATCHER invocha il Web Services messo a disposizione da SysPrest per comunicare l’avvenuta erogazione.

Il messaggio di erogato è composto da una testata (dettaglio) e da 1 sola riga (prestazione).

Lo stato del messaggio può assumere i seguenti valori:

- E: erogata (effettuata)

- EC: cancellazione erogazione (di qualsiasi tipo)

- NP: erogato di tipo non presentato (l’assistito non si è presentato all’appuntamento)

- NC: erogato di tipo non erogato (all’assistito non è stata effettuata la prestazione)

Il Web services è ospitato dal servizio di windows “CSIO SysPrestErogato”.

DISPATCHER

servizio di windows “CSIO SysPrestErogato”.

Se dati formalmente corretti: Memorizzazione in tabella dei dati ricevuti ([dbo].[INTEGRAZIONE_1010_S_EROGATO])

Lo schedulatore ‘ SysPrest 24 - Schedulatore Integrazione Erogato’ elabora messaggi ricevuti corretamete

Dato visibile su SysPrest

Risposta WS (OK; dati formalmente non corertti)

Controllo dati ricevuti (P_INTEGRAZIONE_S_1010_CONTROLLO).

Verifica applicativa dei dati (esempio: prestazione non presente SysPrest; prestazione erogata e inviata Conticki; prestazione presente SysPrest di tipo sostituita;prestazione di ulteriore sostituzione su prestazione precedentemente ricevuta; Progressivo di una prenotazione non corretto; ecc..)





< EROGATO >

<TESTATA>

<EROGATO_DATA_ORA> numerico (formato YYYYMMDDHHMM) *

<MEDICO_EROG_COD_REGIONE> testo di 3 caratteri

<MEDICO_EROG_COD_FISCALE> testo di 16 caratteri

<MEDICO_EROG_COD_USL > testo di 3 caratteri

<MEDICO_EROG_COD_TIPOLOGIA > testo di 2 caratteri

<PATOLOGIA_ACCERTATA_COD> esto di 5 caratteri

<STATO> testo di 2 caratteri (E, EC, NP,NC) *

< PRENOTAZIONE _ID > numerico (non valorizzato per accessi diretti)

<APPLICATIVO_COD> testo di 10 caratteri (codice identificativo applicativo di erogazione) *

<ASSISTITO_ID_AZIENDALE> Testo di 8 caratteri. Contiene il codice aziendale dell’assisto che deve essere numerico formato con gli zeri a sinistra (esempio 00012345).

*

<REGIME> testo di 3 caratteri (può assumere i seguenti valori: SSN, ALP, AAP) *

<NUM_CASO> testo di 50 caratteri (se i primi 3 caratteri PRE e il regime=SSN è una preospedalizzazione)

*

< UNITA_ORG_EROGANTE > testo di 20 caratteri *

< UNITA_ORG_RICHIEDENTE > testo di 20 caratteri *

<CDC_COD_EROGANTE > testo di 20 caratteri

</TESTATA>

< PRESTAZIONE >

< PROGRESSIVO > numerico

< PROGRESSIVO_INTEGRAZIONE > testo di 30 caratteri *

< COD_AZIENDALE > testo di 30 caratteri (codice prestazione del catalogo aziendale) *

< QUANTITA > numerico (fisso a 1) *

< /PRESTAZIONE >

< EROGATO >


I messaggi ricevuti (con esito positivo o negativo) vengono memorizzati nella tabella INTEGRAZIONE_1010_S_EROGATO dell’archivio SysPrestV3_Empoli_INTEGRAZIONI. Non viene mantenuta traccia dei messaggi scartati per XML non valido (esempio se la lunghezza dei campi non viene rispettata viene inviata una ecezzione).

l Web Service “Erogato” deve esere invocato dal DISPATCHER con il seguente percorso a seconda dell’ambiente:

• In ambiente di TEST (server ip.172.16.100.56)

http://172.16.100.56:55055/SysPrest/Integrazioni/SysPrestErogato

• In ambiente di produzione (server vintegra.usl11.net)

http://vintegra.usl11.net:55055/SysPrest/Integrazioni/SysPrestErogato

http://200.1.1.56:55055/SysPrest/Integrazioni/SysPrestErogato

http://vintegra.usl11.net:55055/SysPrest/Integrazioni/SysPrestErogato




Esito chiamate


<EsitoChiamata>



</EsitoChiamata>

Se la chiamata va a buon fine il codice di errore restituito è sarà “00000” e con descrizione “Ricezione erogato avvenuta correttamente”

SysPrest effettua i seguenti controlli applicativi in fase di ricezione sui messaggi ricevuti e memorizzati in tabella (storede procedure P_INTEGRAZIONE_S_1010_CONTROLLO).

Codice Esito

Se campo “PRENOTAZIONE_ID” valorizzato deve essere presente in archivio SysPrest (e prenotazione non estratta dal Malum)

00010

Se campo “PROGRESSIVO” valorizzato deve essere presente in archivio SysPrest e la prestazione non deve essere di tipo sostitutiva

00020

Se valorizzato sia il campo “PROGRESSIVO” che il campo “PRENOTAZIONE_ID”, il campo “PROGRESSIVO” deve essere della “PRENOTAZIONE_ID” e la prestazione non deve essere di tipo sostitutiva

00030

“COD_AZIENDALE” codice prestazione del catalogo aziendale deve essere presente in archivio SysPrest (e deve essere una prestazione di tipo “semplice”, quindi non di tipo “pacchetto” o “profilo”)

00040

Codice applicativo (campo APPLICATIVO_COD ) che ha erogato deve essere presente in archivio SysPrest

00050

Codice aziendale dell’assistito (campo ASSISTITO_ID_AZIENDALE ) deve essere presente in anagrafe SysPrest

00060

Codice patologia (campo PATOLOGIA_ACCERTATA_COD) deve essere presente in archivio SysPres

00070

Unità organizzativa (campo UNITA_ORG_EROGANTE) deve essere presente in SysPrest 00080

Se valorizzato il campo MEDICO_EROG_COD_REGIONE, MEDICO_EROG_COD_FISCALE , MEDICO_EROG_COD_USL viene verificato se è presente in SysPrest:

• Se valorizzato il campo MEDICO_EROG_COD_TIPOLOGIA il Medico erogante con campi MEDICO_EROG_COD_REGIONE, MEDICO_EROG_COD_FISCALE , MEDICO_EROG_COD_USL, MEDICO_EROG_COD_TIPOLOGIA deve essere presente in archivio SysPrest;

o altrimenti il sistema verifica se esiste un medico con i campi MEDICO_EROG_COD_REGIONE, MEDICO_EROG_COD_FISCALE , MEDICO_EROG_COD_USL e con MEDICO_EROG_COD_TIPOLOGIA =03 che deve essere presente in SysPrest

▪ se medico non trovato il sistema verifica se esiste un medico con i campi MEDICO_EROG_COD_REGIONE, MEDICO_EROG_COD_FISCALE , MEDICO_EROG_COD_USL che deve essere presente in SysPrest

00090

REGIME deve essere uno tra i valori ammessi 00100

STATO deve essere uno tra i valori amessi 00110

Data erogazione (campo EROGATO_DATA_ORA ) deve essere <= alla data odierna 00120

Il CDC_COD_EROGANTE se indicato deve essere presente in SysPrest (e deve essere coerente con l’unita organizzativa e il regime indicato nel messaggio) – non si controlla il periodo di validità

00130

“PRENOTAZIONE_ID” se indicata: l’ unità organizzativa della prenotazione deve coincidere con unità organizzativa erogante indicata nel messaggio

00140

Il campo QUANTITA deve essere = 1 00150




Servizio di Windows “CSIO SysPrest Erogato”

Prerequisiti




Installato il servizio in produzione è installato nel server vintegra.usl11.net nel percorso “D:\Program Files\CSIO” Installazione-disinstallazione

Nella cartella del servizio è presente il file con le note per l’installazione e disinstallazione. Se si deve rinstallare il servizio è necessario prima d’installare il servizio precedente.



Il file di configurazione csio_syspr_erog_host.exe.config del servizio si trova nel percorso dove è stato installato il servizio. Nel file di configurazione è possibile variare il tempo attesa di esecuzione del prossimo messaggi, indirizzo web service che altri sistemi invocano, attivazione del log dei messaggi elaborati. Importante: se si cambia la configurazione è necessario riavviare il servizio. Contenuto file configurazione NOTE <?xml version="1.0" encoding="utf-8"?> <configuration> <connectionStrings> <add name="SysPrestV3_Empoli_INTEGRAZIONI_ConnectionString" connectionString="Data

Source=192.168.210.237;Initial Catalog=SysPrestV3_Empoli_INTEGRAZIONI;Persist Security

Info=True;User ID=sa;Password=XXX" providerName="System.Data.SqlClient" />

Definizione della connessione al DB integrazione (non cambiare la proprietà nome)

<add name="SysPrestV3_Empoli_PCC_ConnectionString" connectionString="Data

Source=192.168.210.237;Initial Catalog=SysPrestV3_Empoli;Persist Security Info=True;User

ID=sa;Password=XXX" providerName="System.Data.SqlClient" />

Definizione della connessione al DB (non cambiare la proprietà nome)

</connectionStrings> <system.serviceModel> <services> <service behaviorConfiguration="SysPrestErogato_Behavior"

name="CSIO.SysPrest.Integrazioni.SysPrestErogato.SysPrestErogatoService">

<endpoint address="" binding="basicHttpBinding"

bindingNamespace="urn:csio.sysprest.integrazioni.syspresterogato.v1"

name="SysPrest_CSIO_basicHttpEndpoint"

contract="CSIO.SysPrest.Integrazioni.SysPrestErogato.ISysPrestErogatoService" />

 <host> <baseAddresses> <add

baseAddress="http://172.16.100.56:55055/SysPrest/Integrazioni/SysPrestErogato" /> Indirizzo servizio che gli altri sistemi devono invocare

</baseAddresses> </host> </service> </services> <behaviors>




Avvio/Arresto

Da “strumenti di amministrazione” – “servizi” è possibile avviare/arrestare/o mettere in pausa il servizio “CSIO SysPrest Dispatcher Richiesta”

Il servizio viene configurato che parta automaticamente all’avio del server.

Quando parte il servizio scrive sempre un evento informativo sui dati di configurazione.





Da “strumenti di amministrazione“ – “eventi” è possibile consultare gli eventi del servizio. Gli eventi del servizio si provano nella cartella “SysPrest.Integrazioni” con origine “SysprestErogato”

Visualizzazione servizio da Task Manager Il nome dell’eseguibile del servizio è SysPrest_Erogato_EXE

Funzionamento servizio Se i dati ricevuti ( se rispettano il tracciato )i dati vengono memorizzati nella tabbella SysPrestV3_Empoli_INTEGRAZIONI. INTEGRAZIONE_1010_S_EROGATO. Nella tabella vengono memorizzati anche i messaggi ricevuti con errori applicativi.




Processo di elaborazione del messaggio ricevuto

I messaggi corretti ricevuti SysPrestV3_Empoli_INTEGRAZIONI. INTEGRAZIONE_1010_S_EROGATO ( where Elab_DataOra IS NULL and Integrazione_CodiceEsito ='00000') vengono elaborati 10 ogni minuto dal processo SQL “SysPrest 24 - Schedulatore Integrazione Erogato” . Dall’integrazione non è possibile efefttuare prestazioni aggiuntive.

La sostituzione di un esame di una prestazione prenotata è associata al progressivo della prestazione prenotata da sostituire. Il “progressivo” viene aggiornato con la prestazione realmente effettuata, mentre la prestaz ione inizialmente prenotata viene inserita con un nuovo progressivo. Se la prestazione da sotituire è collegata al documento “contabilizzato” il sistema non sostituisce la prestazione (al documento rimane collegata la sostituita e la sostitutiva rimane da contabilizzare). Se il progressivo di prestazione è già stato ricevuto e la prestazione erogata è diversa della prestazione di SysPrest il messaggio non viene elaborato e viene segnalato elaborato con errore “prestazione di ulteriore sostituzione su prestazione precedentemente ricevuta”. La prestazione di tipo “sostitutiva” una volta ricevuta non può più essere cancellata dall’integrazione. L’erogato di tipo “effettuato” può essere dato anche a prestazioni non contabilizzate. Le modifiche della prenotazioni che vengono effettuate dall’integrazione (prestazioni sostituite) non vengono comunicate come variazioni di prenotazioni all’integratore. Viene ricomunicata la prestazione se viene contabilizzata alla ricezione del messaggio di erogato. Se la prestazione del messaggio ricevuto fosse già stata precedentemente erogata (di qualsiasi tipo) verrà cancellato l’accesso precedente e registrato l’erogazione ricevuta. Se la prestazione erogata è gia stata inviata all’integrazione Conticki non è possibile modificare l’erogazione (il messaggio viene elaborato con errore). L’erogato di tipo “accesso diretto” viene accettato solo per il regime SSN (gli accessi diretti dovrebbero verificarsi solo per preospedalizzazione e screening). Il “numero caso” viene memorizzato nell’accesso. In fase di elaborazione vengono ripetuti dei controlli applicativi, prestazione, medico, applicativo, ecc.., in quando i dati potrebbero essere variati dalla momento della ricezione:

• Cod. errore 998888 ‘prestazione erogata e gia inviata a Conticki

• Cod. errore 999988 ‘prestazione di ulteriore sostituzione su prestazione precedentemente ricevuta’

• Cod. errore 999991 ‘prestazione presente SysPrest di tipo sostituita’

• Cod. errore 999992 ‘Progressivo di una prenotazione non corretto’

• Cod. errore 999994 ‘Applicativo cod non presente SysPrest’’

• Cod. errore 999998 prestazione non presente SysPrest

• Cod. errore 999997 Prestazione in sostituzione di prestazioni di tipo pacchetto

I dati ricevuti dall’integrazione su SysPrest vengono registrati con l’utente definito nella tabella INTEGRAZIONE_0001_AMBIENTE (campi EROGATO_Utente_id e EROGATO_Utente_Struttura_id).

Il medico erogatore sull’accesso viene valorizzato se i campi MEDICO_EROG_COD_REGIONE, MEDICO_EROG_COD_FISCALE , MEDICO_EROG_COD_USL sono valorizzati.




Di seguito viene riportato lo schema di elaborazione di un messaggio di “erogazione”:

BLOCCO F Cancellazione erogato

PROGRESSIVO_INTEGRAZIONE + APPLICATIVO_ID già ricevuto ?

SI

PRENOTAZIONE_ID<> NULL

SI

PROGRESSIVO<> NULL

SI

SI

Messaggio classificato con errore “Scarto messaggio”

BLOCCO E Registrazione erogazione

SI

PRESTAZIONE= PRESTAZIONE del progressivo SysPrest

SI

NOSI

NO

NO

NO

NO

Stato <> EC

PRESTAZIONE= PRESTAZIONE del progressivo SysPrest

NO

BLOCCO A Registrazione prestazione in Accesso Diretto

Errore cod. 999888

BLOCCO C Sostituzione della prestazione prenotata




Se non è presente l’agenda contenitore il messaggio non viene elaborato e vine classificato elaborato con errore.

BLOCCO A Registrazione prestazione in Accesso Diretto

Inserimento richiesta per l’assistito ricevuto

Inserimento prestazione su agenda raccoglitore del applicativo/regime erogante




Inserimento una nuova prestazione copiando dati da PROGRESSIVO (non collegata a DOC –senza accesso- stato prestazione = ‘sostituita’)

Se presente: cancellazione accesso per la prestazione “sotituita” ( il nuovo progressivo inserito)

Modifica dati del PROGRESSIVO (sostituzione prestazione, stato prestazione =’sostitutiva’; FLG_PRENOTATA=0 )

LOG prenotazione

PROGRESSIVO collegato a DOC con stato “non catabilizzato”

SI

NO

Collegamento della prestazione sostitutiva al documento e scollegamento della prestazione sotituita

Se prestazione sostituita era contabilizzata su documento con stato “contabilizzato” al documento rimane collegato la prestazione sostituita e la sostitutiva rimane da contabilizzare

BLOCCO C Sostituzione della prestazione prenotata




Se la Tipologia medico non viene trasmessa dall’integrazione il sistema verifica se il medico è presente con la tipologia= “03” ; se il medico relativo non avesse questa tipologia, ne viene presa una tramite la funzione top1. Se l’erogazione si riferisce ad una prestazione (prenotata o meno) del SSN AND i primi tre caratteri del “Numero caso” = “PRE” AND il tipo di erogazione = E (prestazione effettuata) AND la prestazione non è contabilizzata

• Si verifica se esiste già un documento di tipo “preospedalizzazione” con lo stesso “Numero caso” per l’assistito, se si

o collega la prestazione al documento trovato o LOG integrazione per comunicare l’avvenuta contabilizzazione

• Altrimenti o il sistema crea un nuovo documento (definito nella tabella d’ambiente

SysPrestV3_Empoli_INTEGRAZIONI.dbo.INTEGRAZIONE_0001_AMBIENTE campo TIPO_DOC_Preospedalizzazione) di tipo “preospedalizzazione” con il “Numero caso” ricevuto. Se nella tabella d’ambiente non è indicato la tipologia del documento il sistema non elabora il messaggio e lo classifica elaborato con errore. Il documento creato da la data documento = alla data odierna di elaborazione e con descrizione “preospedalizzazione” + numero caso e non viene valorizzato il medico proscrittore.

o collega la prestazione erogata o LOG integrazione per comunicare l’avvenuta contabilizzazione

Attenzione che si possono verificare i seguenti casi:

• esempio 1 1. l’operatore CUP contabilizza la prestazioni xxx in un documento di tipo impegnativa 2. l’integrazione riceve un messaggio di erogato di tipo”effettuata” con “numero caso”

=”PRExxxx” per la prestazione xxx La prestazione rimarrà collegata al documento di tipo impegnativa → integrazione non scollega mai le prestazioni del documento almeno che non siano sostitutive.

• esempio 2 1. l’integrazione riceve un messaggio di erogato di tipo”effettuata” con “numero caso”

=”PRExxxx” per la prestazione yyy 2. l’integrazione eroga e crea un nuovo documento “preospedalizzazione” con collegato la

prestazione yyy 3. l’operatore CUP scollega la prestazione dal documento

progressivo SysPrest già erogato?

SI

Cancellazione accesso precedente

Registrazione accesso

NO

BLOCCO E Erogazione di tipo E, NP, NC




BLOCCO F

Se la prestazione che si deve cancellare l’erogato non risulta “erogata” su SysPrest il sistema classifica il messaggio elaborato con errore. Qunado viene cancellato un accesso il “progressivo d’integrazione” della prestazione rimane valorizzato su SysPrest, in quanto se l’integrazione rinvia l’erogato il sistema inserirebbe altre prestazioni. CASI CHE SI POSSONO VERIFICARE CASO 1

1. si riceve un messaggio di conferma erogato su prestazione prenotata 2. il messaggio viene elaborato e nella tabella richiestePrestazioni avremmo:

progresso idAccesso Progressivo_integrazione APPLICATIVO_ID_ INTEGRAZIONE

idprestazione idModalitità

1111 1010 Xxxx1 1 P1 confermata

3. successivamente si riceve un messaggio di sostitutuzione prestazione. Poiché la prestazione

è già stata ricevuta il sistema sostituisce la prestazione prenoatata → si perde quindi la prestazione inizialmente prenotata

progresso idAccesso Progressivo_integrazione APPLICATIVO_ID_

INTEGRAZIONE idprestazione idModalitità

1111 1012 Xxxx1 1 P2 confermata

CASO 2

1. si riceve un messaggio di erogato di tipo accesso diretto 2. successivamente si riceve un messaggio di cancellazione dell’erogato 3. la prestazione rimarrà presente in SysPrest ma non erogata → comparirà nei report di spunta

“prestazioni in acesso diretto su agende integrazione non erogate” 4. Da contabilizza la prestazione è cancellabile, in quanto non erogata

CASO 3

1. l’operatore SysPrest contabilizza una prestazione 2. l’integrazione eroga la prestazione di tipo “non erogata” 3. la prestazione rimarrà collegata al documento, verrà eventualmente segnalato dalla spunta

dell’elaborazione dei flussi SPA




INTEGRAZIONE RICETTARI

Comunicazione di movimenti effettuati sui ricettari SysPrest al DISPATCHER

Quando su SysPrest si verifica uno dei seguenti eventi:

• consegna di un ricettario ad un medico

• revoca consegna di un ricettario

• riconsegna di un ricettario (o parziale) da parte del medico

• revoca riconsegna

• annullamento di un ricettario ( o parte)

• revoca annullamento

Viene invocato il Web Service “Ricettario” messo a disposizione dal DISPATCHER.

Il web service non viene invocato contestualmente alla variazione, ma è previsto un servizio di Windows “CSIO SysPrest Dispatcher Ricettario” che ogni x secondi (indicato nel file di configurazione del servizio) verificherà in una determinata tabella di LOG (SysPrestV3_Empoli_INTEGRAZIONI.dbo.RICETTARIO_100_LOG) se ci sono dati da trasmettere al DISPATCHER

Non è previsto nessun sistema di notifica per i messaggi non inviati correttamente (il DISPATCHER non è attivo, messaggi XML che non corretto) e arresto del servizio.




Web Services Ricettario


<CONSEGNA> <MEDICO_TIPOLOGIA> testo di 2 caratteri (codice tipologia del medico a cui è stato

consegnato il ricettario ) *

<MEDICO_COD_FISCALE> testo di 16 caratteri (codice fiscale del medico a cui è stato consegnato il ricettario)

*

<RICETTARIO_CARATTERE_CONTROLLO > Testo di 1 carattere * < RICETTARIO_TIPO > Testo di 1 carattere * < RICETTARIO_SERIE > Testo di 5 carattere * < RICETTARIO_PRIMO_NUMERO_RICETTA>

Testo di 9 carattere *

<RICETTA_PROGRESSIVO_INIZIALE> Testo di 2 carattere * <RICETTA_PROGRESSIVO_FINALE> Testo di 2 carattere * <DATA_CONSEGNA> numerico (formato YYYYMMDD) -data consegna del ricettario al

medico- campo valorizzato se tipo operazione = 1 o =2

<DATA_REVOCA_CONSEGNA> numerico (formato YYYYMMDD) – data revoca consegna del ricettario al medico - campo valorizzato se tipo operazione = 2

<DATA_RICONSEGNA> numerico (formato YYYYMMDD) – data riconsegna del ricettario da parte del medico - campo valorizzato se tipo operazione = 3 o =4

< MOTIVO_RICONSEGNA_COD> Testo di 2 caratteri – motivo riconsegna del ricettario da parte del medico - campo valorizzato se tipo operazione = 3 o =4

<DATA_REVOCA_RICONSEGNA> numerico (formato YYYYMMDD) – data revoca riconsegna del ricettario da parte del medico - campo valorizzato se tipo operazione = 4

<DATA_ ANNULLAMENTO > numerico (formato YYYYMMDD) – data annullamento del ricettario da parte del medico - campo valorizzato se tipo operazione = 5 o =6

< MOTIVO_ANNULLAMENTO_COD> Testo di 2 caratteri – motivo annullamento del ricettario da parte del medico - campo valorizzato se tipo operazione = 5 o =6

<DATA_REVOCA_ ANNULLAMENTO > numerico (formato YYYYMMDD) – data revoca annullamento del ricettario al medico - campo valorizzato se tipo operazione = 6

<DATA_ORA_OPERAZIONE> numerico (formato YYYYMMDDHHMM)- data ora registrazione dell’operazione

*

<TIPO_OPERAZIONE> =1 consegna; =2 revoca consegna ; =3 riconsegna;=4 revoca riconsegna; =5 annullamento;=6 revoca annullamento

*

</ CONSEGNA >




<EsitoChiamata>



</EsitoChiamata>

Se la chiamata và a buon fine il codice di errore restituito è “00000”.

l Web Service “Richieste” messo a disposizione dal DISPATCHER





http://jcaps-test.usl11.net:31500/prjWS_Ricettario_In_jce_jcdRicettarioEventi_In_prjRicettarioEventi_u002F_prjWS_Ricettari1885356622/ExecutePortType


http://jcaps-test.usl11.net:31500/prjWS_Ricettario_In_jce_jcdRicettarioEventi_In_prjRicettarioEventi_u002F_prjWS_Ricettari1885356622/ExecutePortType

Servizio di Windows “CSIO SysPrest Dispatcher Ricettario”

Prerequisiti




• programma service trace viewer per aprire eventuali file di log (.svclog ) Installato

• In ambiente di produzione il servizio è installato nel server vintegra.usl11.net nel percorso “D:\Program

Files\CSIO”

• In ambiente di test il servizio è installato nel server vintegra.usl11.net nel percorso “C:\Program Files\CSIO”

Installazione-disinstallazione

Nella cartella del servizio è presente il file con le note per l’installazione e disinstallazione. Se si deve rinstallare il servizio è necessario prima d’installare il servizio precedente. Configurazione del servizio

Il file di configurazione CSIO.SysPrest.Integrazioni.Ricettario.exe.config del servizio si trova nel percorso dove è stato installato il servizio. Nel file di configurazione è possibile variare il tempo attesa di esecuzione del prossimo messaggio (60 secondi), indirizzo web service da invocare, attivazione del log dei messaggi elaborati. Importante: se si cambia la configurazione è necessario riavviare il servizio.

http://jcaps-/

http://jcaps-/

http://jcaps-/

http://jcaps-/






Avvio/Arresto

Da “strumenti di amministrazione” – “servizi” è possibile avviare/arrestare/o mettere in pausa il servizio “CSIO SysPrest Dispatcher Ricettario”

Il servizio viene configurato che parta automaticamente all’avio del server. Quando parte il servizio scrive sempre un evento informativo sui dati di configurazione. Visualizzazione eventi

Da “strumenti di amministrazione“ – “eventi” è possibile consultare gli eventi del servizio. Gli eventi del servizio si provano nella cartella “SysPrest.Integrazioni” con origine “RicettarioClient” Visualizzazione servizio da Task Manager Il nome dell’eseguibile del servizio è SysPrest_Ricettario_EXE Funzionamento servizio Se il db di SysPrest non è attivo il servizio si arresta.

Le consegne da inviare sono rappresentati dalla vista dbo. SysPrestV3_Empoli_INTEGRAZIONI.dbo.V_RICETTARIO_0010_C_RICETTARIO. Di seguito flusso di elaborazione:




Costruzione struttura dati Consegna

Corretta ?

Invocazione web service

Time outException?

FaultException<JavaExcep

tionType> ?

Fault Exception?

CommunicationException ?

Si arresta il servizio

SI

NO

SI

NO

NO

OK ?

NO

NO

NO

Il sistema classifica il messaggio elaborato riportando nel campo “errore_ricettario” la descrizione dell’errore (integrazione_tipo_esito=2)

Il sistema classifica il messaggio elaborato riportando nel campo “integrazione_errore” la descrizione dell’errore (integrazione_tipo_esito=3)

SI



Il sistema classifica il messaggio elaborato e nel campo “integrazione_esito_cod” viene riportato il codice dell’esito della chiamata (integrazione_tipo_esito=1). Viene ripristinato il tempo dell’intervallo del timer.



SI

SI

SI

Lettura messaggio da inviare




APERTURA IN CONTESTO DI SYSPREST

Caricamento farmaci di una prenotazione

Richiamando la pagina Applicazione/AperturaContesto_farmaci/prova_exeLogIn_Integrazione_farmaci.asp (senza interfaccia grafica) si esegue l’identificazione su SysPrest e l’apertura di una interfaccia che permettere di registrare sulle prestazioni (che prevedono farmaci) di una determinata prenotazione i farmaci. La pagina si aspetterà i seguenti parametri:

• wUserName: user name per log-in SysPrest (dato di tipo testo obbligatorio)

• wPrenotazione: codice prenotazione SysPrest (dato di tipo numerico obbligatorio) L’identificativo dell’utente viene effettuata solo sulla UserName (per tutti gli utenti attivi). La struttura e il ruolo dell’operatore saranno fissi (indicati nella tabella d’ambiente INTEGRAZIONE_0001_AMBIENTE). Viene visualizzato un messaggio di errore:

• se dati obbligatori non valorizzati

• Se l’identificazione utente non và a buon fine Effettuata l’dendificazione dell’utente il sistema visualizza il dettaglio della prenotazione:

Se la prestazione non è di tipo “sostituita” e prevede l’indicazione dei farmaci il sistema visualizzerà l’icona . Potranno essere caricati farmaci anche su prestazioni non contabilizzate

Cliccato nell’icona il sistema visualizza la pagina di ricerca-selezione farmaco .

Cliccando nell’icona il sistema cancellerà il farmaco associato alla prestazione. L’associazione -cancellazione di un farmaco di una prestazione contabilizzata classificherà il documento relativo “da estrarre flussi SPA”




Apertura diretta di una interfaccia di prenotazione su un determinato assistito

Richiamando la pagina exeLogIn_Integrazione.asp (senza interfaccia grafica) si esegue l’identificazione su SysPrest e l’apertura di una interfaccia di prenotazione posizionata su un determinato assistito.

La pagina si aspetteta i seguenti parametri:

• wUserName: userName per log-in SysPrest (dato di tipo testo obbligatorio) • wAssistitoAziendale: codice assistito aziendale (dato di tipo numerico non obbligatorio)

• wUnitaOrgRichiedente: codice dell’unità organizzativa richiedente (dato di tipo testo obbligatorio)

L’identificazione dell’utente viene effettuata solo sulla UserName (per utenti attivi). Se l’identificazione utente non và a buon fine viene visualizzato un messaggio di errore. Se i dati inviati non sono formalmente corretti (unità organizzativa richiedente non presente in SysPrest, dati obbligatori non valorizzati) viene visualizzato un messaggio di errore. Il Ruolo dell’operatore è fisso (definito nella tabella di ambiente SysPrestV3_Empoli_INTEGRAZIONI.dbo.INTEGRAZIONE_0001_AMBIENTE campo LOG_IN_Ruolo). La struttura viene valorizzata con la struttura abilitata all’utente (utilizzando la funzione gestione utenti). Se l’utente ha associato più di una struttura il sistema visualizza una nuova pagina con l’elenco delle strutture abilitate è l’utente ha l’obbligo di selezionarne una (se l’utente ha solo una struttura associata il sistema automaticamente associera all’utente la struttura trovata). Se l’utente non ha associata nessuna struttura il sistema visualizza un messaggio di errore. In base al valore del campo “wAssistitoAziendale” viene visualizzata una pagina iniziale differente.

• Se “wAssistitoAziendale” è vuoto, il sistema visualizza la pagina di ricerca assistito (con nessun filtro impostato)

• Se “wAssistitoAziendale” è di tipo numerico, ed è presente nell’anagrafe SysPrest (il primo assistito che ha il codice aziendale) allora il sistema visualizzerà la home di prenotazione con l’assistito già impostato

Entrati in SysPrest effettuando la Log-in nel frame di testa viene visualizzata l’icona

In prenotazione viene memorizzata la “Unità organizzativa richiedente” trasmessa in fase di LOG-IN.




INTEGRAZIONE ANAGRAFE

L’integrazione prevede la comunicazione ad altri sistemi delle variazioni anagrafiche effettuate nel sistema SysPrest e la ricezione su SysPrest delle variazioni anagrafiche effettuate da altri sistemi.

L’integrazione prevede un flusso di dati bidirezionali.

L’integrazione prevede quindi le seguenti fasi:

- SysPrest comunica al sistema People le variazioni anagrafiche invocando il Web Service “PersonWS” (messo a disposizione da Noemalife)

- Il DISPATCHER comunica a SysPrest le variazioni anagrafiche invocando il Web Service “anagrafeserver” (messo a disposizione da CSIO)

Da web SysPrest variazione anagrafica

scrittura su tabelle: dbo.Rad_xAnagraficaBase (LOG) dbo.xAnagraficaBase

Scrittura su tabella: SysPrestV3_Empoli_INTEGRAZIONI ANAGRAFE_010_C_VARIAZIONI

Chiamata Web Service PEOPLE. PERSON.SAVE

Messaggio di risposta WS con tipo_operazione_id=1

Scrittura tabella: SysPrestV3_Empoli_INTEGRAZIONI ANAGRAFE_100_S_VARIAZIONI

SCHEDULATORE ospitato dal servizio “CSIO Anagrafe Client”

SCEDULATORE processo SQL 21 Scarica su tabella di anagrafe assistiti SysPrest i messaggi ricevuti

Web Service CSIO “anagrafeserver” Ospitato dal SERVIZIO “CSIO Anagrafe Server”

Risposta WS

DISPACER comunica variazioni anagrafiche




Comunicazione delle variazioni anagrafiche SysPrest al DISPATCHER

Quando su SysPrest si verifica uno dei seguenti eventi su viene invocato il Web Service “PersonWS” messo a disposizione dal sistema People:

- Nuova assistito

- Aggiornamento

- Aggiornamento telefono da prenotazione

Il web service non viene invocato contestualmente alla variazione, ma è previsto un servizio di Windows che ogni x secondi verificherà in una determinata tabella di LOG (SysPrestV3_Empoli_INTEGRAZIONI.ANAGRAFE_010_C_VARIAZIONI WHERE Integrazione_DataOraProcessato IS NULL) se ci sono dati da trasmette al DISPATCHER.

Il servizio elabora i messaggi in coda assegnando una priorità più alta ai messaggi per nuovo assisttito (([ANAGRAFE_010_C_VARIAZIONI].[TIPO_OPERAZIONE_SYS

PREST_ID]=1) (come da p1.1804-2014).

Non è previsto nessun sistema di notifica per i messaggi non inviati correttamente (il DISPATCHER non è attivo, messaggi XML che non corretto).

Il metodo da invocare è “save” sia per l’inserimento che per l’aggiornamento di un paziente avvenuto su SysPrest.

Il metodo ritorna tutti i dati di dettaglio dell’assistito presente in anagrafe People. Dei dati di ritorno verrà ri-aggiornata la posizione anagrafica con i dati ricevuti. L’aggiornamento in anagrafe SysPrest non viene effettuata contestualmente ma i dati ricevuti verranno memorizzati nella tabella di LOG (SysPrestV3_Empoli_INTEGRAZIONI.ANAGRAFE_100_S_VARIAZIONI) dei messaggi ricevuti dal DISPACER (integrazione lato server) con tipo “tipo operazione=dati risposta lato client” (Integrazione_tipo_operazione_ID=1)

Nell’allegato IntegrazioneAnagrafica_Peolple.zip sono presenti i documenti di dettaglio del WS di People.

Web Services Peolple.Save

La struttura dati da valorizzare è la seguente (chiama servizio):

<person>

<classCode> = fisso a PSN

<currentDemographic>

<addresses>

<address>  L’intero tag viene inviato se valorizzato il campo “code comune domicilio”

<city>

<code> Codice ISTAT comune di domicilio

< displayvalue> descrizione comune domicilio

</city>

<district>

<code> Provincia del comune di domicilio

</district>

<hdis>

<code> Codice regione + codice USL domicilio (es. 080105)

</hdis>

<qualifier>

<code> Fisso a H

</qualifier>

<state>

<code> Codice stato comune di domicilio

</state>

<street>

<displayvalue> Indirizzo domincilio con civico

</street>

<zip> CAP del commune di domicilio

<valid> =fisso a true

</address>

<address> 

<city>

<code> Codice ISTAT comune di residenza

< displayvalue> Descrizione commune residenza

</city>

<district>

<code> Provincia del comune di residenza

</district>

<hdis>

<code> Codice regione + codice USL residenza (es. 080105)

</hdis>

<qualifier>

<code> Fisso a HP

</qualifier>

<state>

<code> Codice stato comune di residenza

</state>

<street>

<displayvalue> Indirizzo residenza

</street>


<zip> CAP del comune di residenza

</address>

</addresses>

<birthdate> Data di nascita

<birthdateSpecified> =fisso a true

<birthplace>

<city>

<code> Codice ISTAT comune di nascita

< displayvalue> descrizione comune nascita

</city>

<district>

<code> Provincia del comune di nascita

</district>

<qualifier>

<code> Fisso a BIRTHPL

</qualifier>


</ birthplace >

<citizenship>

<code> Codice cittadinanza

<citizenship>

< dataext >  L’intero tag viene inviato se valorizzato il campo “Numero di identificazione della tessera”

<identifier> Numero di identificazione personale

<teamend> data scadenza tessera

<state>

<code> Codice stato estero

</state>

<teamnum> Numero di identificazione della tessera

<teamorg>

<code> Codice istituzione competente

< displayvalue> Descrizione istituzione

</teamorg>

<teamendSpecified >

Viene valorizzato a true se la data scadenza della tessera è valorizzata

</dataext >

<gender>

<code> =M per marchio

=F per femmina

</gender>

<taxcode> Codice fiscale assistito

<telecoms>

<qualifier>

<code> Fisso a HP

</qualifier>

<urltype>

<code> Fisso a TEL

</urltype>




<value> Telefono 1

</telecoms>

<telecoms>

<qualifier>

<code> Fisso a MC

</qualifier>

<urltype>

<code> Fisso a TEL

</urltype>

<value> Telefono 2

</telecoms>

</currentDemographic>

<ids>

<extension> Codice fiscale assistito

<root>

<rootOID> Fisso CF

</root>

</ids>

<ids>

<extension> Codice sanitario

<root>

<rootOID> Fisso CS

</root>

</ids>

<ids>

<extension> Codice aziendale dell’assistito

<root>

<rootOID> Fisso PKPATIDOK

</root>

</ids>

<ids>

<extension> Codice STP dell’assistito

<root>

<rootOID> Fisso STP

</root>

</ids>

<ids>

<extension> Codice assistito SysPrest

<root>

<rootOID> Fisso “SYSPREST”

</root>

</ids>

<names>

<name> Nome assistito

<surname> Cognomen assistito

<qualifier>

<code> Fisso a L

</qualifier>

</names>

<originApplication> fisso a “SYSPREST” (sigla applicativo)

<valid > Fisso a true

</person>

Su SysPrest i telefono non sono differenziati tra telefono fisso e cellulare, vengono quindi trasmessi tutti come “TEL”.




La risposta del messaggio viene memorizzata nella tabella SysPrestV3_Empoli_INTEGRAZIONIANAGRAFE_100_S_VARIAZIONI:

Campo Note

ASSISTITO_ID_ANAGRAFE_ULS ids.First(x => x.root.rootOID == "PKPATIDOK").extension

Assistito_Cognome names.First(x => x.valid && x.qualifier.code == "L").surname

Assistito_Nome names.First(x => x.valid && x.qualifier.code == "L").name1

Assistito_Sesso oggettoRisposta.currentDemographic.gender.code

Nascita_data currentDemographic.birthdate

Nascita_Comune_cod currentDemographic.birthplace.city.code

Nascita_Provincia currentDemographic.birthplace.district.code

Cittadinanza_cod currentDemographic.citizenship.code

Codice_Fiscale ids.First(x => x.root.rootOID == "CF").extension

Codice_Sanitario ids.First(x => x.root.rootOID == "CS").extension

Codice_STP ids.First(x => x.root.rootOID == "STP").extension

Dom_Comune_cod currentDemographic.addresses.First(x => x.qualifier.code == "H").city.code

Dom_Cap currentDemographic.addresses.First(x => x.qualifier.code == "H").zip

Dom_Indirizzo currentDemographic.addresses.First(x => x.qualifier.code == "H").street.displayvalue;

Dom_CodRegione currentDemographic.addresses.First(x => x.qualifier.code == "H").hdis.code.Substring(0, 3)

Dom_CodUsl currentDemographic.addresses.First(x => x.qualifier.code == "H").hdis.code.Substring(3, 3)

Dom_Stato_cod currentDemographic.addresses.First(x => x.qualifier.code == "H").state.code

Dom_Provincia currentDemographic.addresses.First(x => x.qualifier.code == "H").district.code

Res_Comune_cod currentDemographic.addresses.First(x => x.qualifier.code == "HP").city.code

Res_Cap currentDemographic.addresses.First(x => x.qualifier.code == "HP").zip

Res_Indirizzo currentDemographic.addresses.First(x => x.qualifier.code == "HP").street.displayvalue;

Res_CodRegione currentDemographic.addresses.First(x => x.qualifier.code == "HP").hdis.code.Substring(0, 3)

Res_CodUsl currentDemographic.addresses.First(x => x.qualifier.code == "HP").hdis.code.Substring(3, 3)

Res_Stato_cod currentDemographic.addresses.First(x => x.qualifier.code == "HP").state.code

Res_Provincia currentDemographic.addresses.First(x => x.qualifier.code == "HP").district.code

TelAssistito currentDemographic.telecoms.First(x => x.qualifier.code == "HP" && x.urltype.code =="TEL").value

TelAssistito2 currentDemographic.telecoms.First(x => x.qualifier.code == "MC" && x.urltype.code =="TEL").value

TEAM_ISTITUZIONE_COD currentDemographic.dataext.teamorg.code

TEAM_ISTITUZIONE_DSC currentDemographic.dataext.teamorg.displayvalue

TEAM_NUM_TESSERA currentDemographic.dataext.teamnum

TEAM_DATA_SCADENZA currentDemographic.dataext.teamend

TEAM_NUM_PERSONALE currentDemographic.dataext.identifier

TEAM_STATO_ESTERO_UE_ID currentDemographic.dataext.state.code

DATA_POSI Se (posizione == ‘08’) → currentDemographic.deathdate; altrimenti currentDemographic.addresses.First(x => x.qualifier.code == "HP").interval.starting;

DATA_ISCRIZIONE ids.First(x => x.root.rootOID == "CS").interval.starting

POSIZIONE currentDemographic.status.code

FLG_ASSISTENZA currentDemographic.assistanceFlag ? "S" : "N"

FLG_CERTIFICATA_SCEREV oggettoRisposta.owner.displayvalue.Contains("ASL") ? "S" : "N"

ASSISTITO_COD_UNIVERSALE ids.First(x => x.root.rootOID == "IDUNIVERSALE").extension

ASSISTITO_ID_ANAGRAFE_USL_FUSIONE NULL

INTEGRAZIONE_CLIENT_PRG Progressivo del messaggio client

INTEGRAZIONE_CLIENT_ASSISTITO_ID Codice assistito del messaggio client

Integrazione_tipo_operazione_ID =1

Integrazione_DataOraRicevuto Data odierna

Integrazione_CodiceEsito 00000




l Web Service “PersonWS” messo a disposizione dal DISPATCHER


http://jcapstest2.usl11.net:10080/people/PersonWS


http://people.usl11.net:18080/people/PersonWS

(con ip http://172.16.200.121:18080/people/PersonWS)

http://jcapstest2.usl11.net:10080/people/PersonWS

http://people.usl11.net:18080/people/PersonWS




Servizio di Windows “CSIO Anagrafe Client”

Installato Il servizio in test è stato installto nel server PPCUP nel percorso D:\Csioweb\SysPrestV3\Integrazioni\Installazioni\Anagrafe Client\ Il servizio in produzione è installato nel server vintegra.usl11.net nel percorso “D:\Program Files\CSIO” Installazione-disinstallazione

Nella cartella del servizio è presente il file con le note per l’installazione e disinstallazione. Va indicato l’utente di esecuzione del servizio (deve essere un amministratore della macchina) Il servizio con l’installazione non viene avviato automaticamente. All’avvio del sistema (da configurazione d’installazione) il servizio riparte automaticamente (configurabile dalla funzione “servizi”).

Se si deve aggiornare il servizio è necessario prima d’installare il servizio precedente e rieffettuare l’installazione.


Il file di configurazione CSIO.SysPrest.Integrazioni.Anagrafe.exe.config del servizio si trova nel percorso dove è stato installato il servizio (se si è lasciato il percorso di default si trova in C:\Program Files\CSIO\CSIO SysPrest Dispatcher Anagrafe Client\Runtime). Nel file di configurazione è possibile variare il tempo attesa di esecuzione del prossimo messaggi, indirizzo web service da invocare, attivazione del log dei messaggi elaborati. Importante: se si cambia la configurazione è necessario riavviare il servizio.


Da “strumenti di amministrazione“ – “eventi” è possibile consultare gli eventi del servizio. Gli eventi del servizio si provano nella cartella “SysPrest.Integrazioni” con origine “AnagrafeClientDALHelper” Funzionamento servizio

Se i dati ricevuti ( se rispettano il tracciato )i dati vengono memorizzati nella tabbella SysPrestV3_Empoli_INTEGRAZIONI.ANAGRAFE_100_S_VARIAZIONI. Nella tabella vengono memorizzati anche i messaggi ricevuti con errori applicativi.




DISPACER invia variazioni anagrafiche a SysPrest

Quando il DISPATCHER deve inviare una variazione anagrafica (comprese le richieste di fusioni anagrafiche) invoca il Web Service “anagrafeserver” messo a disposizione da SysPrest.

SysPrest effettuerà i seguenti controlli sui messaggi ricevuti:

• Le dimensione dei campi devono rispettare quelli revisti nella struttura dati

• I campi obbligatori devono essere valorizzati

• Non verrà effettuato nessun controllo sulla obbligatorietà o meno che siano valorizzati i campi codice STP e codice della tessera TEAM

Qualora almeno uno dei campi sopradescritti non corrispondesse ai criteri di validità il messaggio ritorna con un codice di errore.

Mentre se i dati ricevuti rispettino i criteri citati, si procede con la registrazione su SysPrest:

Web services Anagrafeserver

I messaggi ricevuti (con esito positivo o negativo) vengono memorizzati nella tabella ANAGRAFE_100_S_VARIAZIONI dell’archivio SysPrestV3_Empoli_INTEGRAZIONI. Non viene mantenuta traccia dei messaggi scartati per XML non valido (esempio se la lunghezza dei campi non viene rispettata viene inviata una ecezzione).

Il Web services è ospitato dal servizio di windows “CSIO SysPrest Anagrafe Server”.

l Web Service “Anagrafe” deve esere invocato dal DISPATCHER con il seguente percorso a seconda dell’ambiente:

• In ambiente di TEST (server ip.172.16.100.56)

http://ppcup/sysprest/integrazioni/anagrafeserver

• In ambiente di produzione (server vintegra.usl11.net)

http://vintegra.usl11.net:55055/SysPrest/Integrazioni/xxxxx




La struttura dati è la seguente: <ASSISTITO>

<ASSISTITO_ID> testo di 10 caratteri (codice assistito Sysprest) - non obbligatorio

<ASSISTITO_ID_ANAGRAFE_ULS> testo di 8 caratteri (codice assistito aziendale) - obbligatorio

<COGNOME> testo di 50 caratteri - obbligatorio

<NOME> testo di 50 caratteri - obbligatorio

<SESSO> testo di 1 carattere – valori ammessi F o M - obbligatorio

<CODICE_FISCALE> testo di 16 caratteri – non obbligatorio

<CODICE_SANITARIO> testo di 16 caratteri – non obbligatorio

<CODICE_STP> testo di 16 caratteri – non obbligatorio

<DATA_NASCITA> numerico (formato YYYYMMDD) - obbligatorio

<COD_COMUNE_NASCITA> testo di 6 caratteri (codice ISTAT comune nascita) - obbligatorio

<COD_CITTADINANZA> testo di 3 caratteri - obbligatorio

<RESIDENZA>

<COD_COMUNE > testo di 6 caratteri (codice ISTAT comune residenza) –obbligatorio

<CAP > testo di 5 caratteri – obbligatorio

<INDIRIZZO > testo di 50 caratteri – non obbligatorio

<COD_USL > testo di 3 caratteri –obbligatorio

<COD_REGIONE > testo di 3 caratteri –obbligatorio

<COD_STATO > testo di 3 caratteri –obbligatorio (codice dello stato associato al comune di residenza)

</RESIDENZA>

<DOMICILIO >

<COD_COMUNE > testo di 6 caratteri (codice ISTAT comune domicilio) –non obbligatorio

<CAP > testo di 5 caratteri – non obbligatorio

<INDIRIZZO > testo di 50 caratteri – non obbligatorio

<COD_USL > testo di 3 caratteri – non obbligatorio

<COD_REGIONE > testo di 3 caratteri – non obbligatorio

<COD_STATO> testo di 3 caratteri – non obbligatorio (codice dello stato associato al comune di domicilio)

</DOMICILIO >

<TEAM >

<TEAM_ISTITUZIONE_COD> testo di 28 caratteri – non obbligatorio

<TEAM_ISTITUZIONE_DSC> testo di 200 caratteri – non obbligatorio

<TEAM_NUM_TESSERA> testo di 20 caratteri – non obbligatorio

<TEAM_ DATA _ SCADENZA> numerico (formato YYYYMMDD) – non obbligatorio

<TEAM_ NUM _ PERSONALE> testo di 20 caratteri – non obbligatorio

<TEAM_STATO_ESTERO> testo di 3 caratteri – non obbligatorio

</TEAM >

<TELEFONO1> testo di 15 caratteri – non obbligatorio

<TELEFONO2> testo di 15 caratteri – non obbligatorio

<DATA_POSI> numerico (formato YYYYMMDD) – non obbligatorio

<DATA_ ISCRIZIONE > numerico (formato YYYYMMDD) – non obbligatorio

<POSIZIONE> testo di 2 caratteri – non obbligatorio

Valori ammessi

00 = Residente e Domiciliato nel territorio della ASL 93 = Residente stessa Regione Domiciliato nel territorio ASL 92 = Residente in altra regione Domiciliato nel territorio ASL 86 = Residente in ASL, Domicilio in altra ASL stessa Regione 85 = Residente in ASL, Domicilio in altra ASL altra Regione 89 = Residente e Domiciliato in ASL stessa Regione 88 = Residente e Domiciliato in ASL altra Regione 03 = Posizione non conosciuta o non applicabile 02 = Soggetto deceduto

<FLG_ASSISTENZA > testo di 1 caratteri - valori ammessi S o N – non obbligatorio

<FLG_CERTIFICATA_SCEREV> testo di 1 caratteri - valori ammessi S o N – non obbligatorio

<ASSISTITOCODUNIVERSALE> testo di 24 – non obbligatorio (codice regionale dell’assistito)

<MEDICOCODFISCALE> testo di 16 – non obbligatorio (codice fiscale del medico dell’assistito)

<MEDICOCODREGIONALE> testo di 6 caratteri – non obbligatorio (codice regionale del medico dell’assistito)




<ASSISTITO_ID_ANAGRAFE_ULS_FUSIONE> testo di 8 caratteri - Codice aziendale assistito da fondere con ASSISTITO_ID_ANAGRAFE_ULS – campo valorizzato solo dai messaggi ricevuti dal DISPATCHER - non obbligatorio

</ASSISTITO>

I campi data devono avere una data >=01/01/1753

Se i TAG non vengono ricevuti il contenuto dei campi verrà impostato a NULL (escluso i campi telefono, codice comune, cittadinanza, sesso, USL che avranno valori di default)


La struttura dati è la seguente: <EsitoChiamata>

<CodiceEsito > testo di 5 caratteri

<Descrizione Esito > testo di 300 caratteri

</EsitoChiamata>

Se la chiamata và a buon fine il codice di errore restituito sarà “00000”




Processo di elaborazione del messaggio ricevuto processo SQL “SysPrest 21 - Schedulatore Integrazione Anagrafe”

Il primo passaggio del processo di elaborazione determina, per tutti i messaggi ricevuti correttamente e non ancora elaborati, se l’assistito relativo al messaggio è presente in SysPrest. Successivamente, 12 volte ogni minuto viene elaborato un messaggio dalla coda ( where Elab_DataOra IS NULL and Integrazione_CodiceEsito ='00000', con priorità più alta dei messaggi con codice assistito aziendale non presente su SysPrest). I dati ricevuti dall’integrazione su SysPrest vengono registrati con l’utente definito nella tabella INTEGRAZIONE_0001_AMBIENTE (campi EROGATO_Utente_id).

I messaggi ricevuti che hanno uno dei seguenti campi non valorizzati o con un codice non presente in SysPrest non vengono scartati ma vengono registrati con un valore di default:

• Codice comune di residenza (se codice non valido viene valorizzato con 000000)

• Codice comune di nascita (se codice non valido viene valorizzato con 000000)

• Codice comune di domicilio (se codice non valido viene valorizzato con 000000)

• Codice cittadinanza (se codice non valido viene valorizzato con 000)

• Sesso (se codice non valido viene valorizzato con F)

• USL di residenza (se USL non valida viene valorizzata con regione= 000 e USL= 000)

• USL di domicilio (se USL non valida viene valorizzata con regione= 000 e USL= 000)

• Codice posizione (se codice non valido viene valorizzato con NULL)

I messaggio con il codice assistito da fondere (campo ASSISTITO_ID_ANAGRAFE_ULS_FUSIONE) non presente in SysPrest non verrà elaborato (è verrà classificato con errore). Il processo “SysPrest 22 - Notifica assistiti con lo stesso codice aziendale ed errori” nottifica ad operatori abilitati i messaggi elaborati con errore.

Se il campo ASSISTITO_ID_ANAGRAFE_ULS_FUSIONE (codice assistito da cancellare – valorizzato con il codice aziendale del paziente) è valorizzato viene eseguita la fusione.

FUSIONE

Viene fuso (sostituito e poi cancellato) il primo assistito SysPrest che ha xAnagraficaBase.ASSISTITO_ID_ANAGRAFE_ULS = ASSISTITO_ID_ANAGRAFE_ULS_FUSIONE con il codice SysPrest precedentemente elaborato.

Altrimenti

INSERIMENTO – AGGIORNAMENTO posizione anagrafica

• se ASSISTITO_ID_ANAGRAFE_ULS è già presente in anagrafe SysPrest (= xAnagraficaBase.ASSISTITO_ID_ANAGRAFE_ULS) il sistema aggiornerà i dati del primo assisto SysPrest che ha lo stesso codice aziendale. Se i campi dei numeri di telefono che vengono trasmessi dall’integrazione non sono valorizzati non verranno aggiornati i relativi campi su SysPrest

• Altrimenti il sistema inserisce una nuova posizione anagrafica (assegnando il xAnagraficaBase.ASSISTITO_ID_ANAGRAFE_ULS= ASSISTITO_ID_ANAGRAFE_ULS) generando un nuovo codice assistito SysPrest.

Di tutte le variazioni anagrafiche effettuate dall’integrazione ne viene mantenuta traccia nel LOG delle l’anagrafica (Rad_xAnagraficaBase)

Il processo sql “SysPrest 32 - Integrazione anagrafe – Rischedulazione” classifica da rielaborare i record con codice errore Elab_Errore_COD = '9999' (errore schedulatore)




INTEGRAZIONE IRIS

Premessa

Il “BUS” rappresenta il sistema aziendale d’invio/ricezione messaggi di IRIS.

Pendenze: contabilizzazioni/cassa effettuate su SysPrest

In fase d’inserimento di un documento contabile (su tutti i tipi di documento: ricetta, pronto soccorso, ricetta bianca, ecc..) il documento viene classificato “integrazione IRIS” (DocumentiLogici.IRIS_FLG_INTEGRAZIONE=1) se

l’integrazione risulta attiva (IRIS_0010_Ambiente.DataInizioIntegrazione <= GETDATE() → ad oggi la data e futura → la storede procedura di generazione del messaggio se il documento è del SSN il sistema lo classifica “integrazione iris”). Per i documenti classificati “integrazione IRIS” quando su SysPrest si verifica uno dei seguenti eventi di debito/pagamento, viene mantenuta traccia in una apposita tabella di LOG IRIS_Pendenze_001_Documento:

• Contabilizzazione (conclusione della fase di contabilizzazione – chiusura documento)

• Cancellazione documento inviato a IRIS

• Incasso (entrata/uscita) su documento inviato a IRIS.

In fase di registrazione del log dei messaggi di pendenza da contabilizza:

• Viene calcolato l’importo totale del documento comprensivo dell’eventuale IVA e imposta ENPAV perché sono

importi calcolati in fase di cassa

• viene classificato “prevista ricevuta XML” se il documento risulta da pagare




Di seguito lo schema di generazione LOG

CONTABILIZZA

Nuovo documento?

Documento con gestione integrazione IRIS IRIS_FLG_INTEGRAZIONE =1 ?

Documento inviato a IRIS IRIS_FLG_INVIATO=1 ?

Importo accertato >0 ?

Inserimento LOG con RFC_Pendenza_TipoO

perazione =”replace”

SI

SI

SI

SI Inserimento LOG con RFC_Pendenza_TipoOperazione =”delete” + classificazione del documento come non inviato a IRIS (caso possibile se da “non esente” si trasforma in “esente” o svuotato dalle prestazioni) IRIS_FLG_INVIATO=0

Inserimento LOG con RFC_Pendenza_TipoOperazione =”insert” + classificazione documento inviato a IRIS_FLG_INVIATO=1

NOSI

FINE

NOSI

NOSI

Importo accertato >0 ?

SI

NOSI

Il documento creato viene classificato (se integrazione attiva) IRIS_FLG_INTEGRAZIONE=1 IRIS_FLG_INVIATO=0

Premuto il pulsante Contabilizza e individuato l’importo accertato del documento

NOSI




La cancellazione di un documento che prevede integrazione IRIS (IRIS_FLG_INTEGRAZIONE=1), con stato

inviato a IRIS (IRIS_FLG_INVIATO=1), crea un movimento di LOG con tipo operazione <delete>.

CASSA

Movimento di cassa su documento

Documento a IRIS

IRIS_FLG_INVIATO=0

?

Tipo operazione incasso (entrata)?

Inserimento LOG con RFC_Pendenza_TipoOperazione

=”updateStatus” + Status.Stato = “chiuso” Dettagliopagamento.stato=”pagato”

SI

SI

SI

NOSI

NOSI

NOSI

Inserimento LOG con RFC_Pendenza_TipoOperazione

=”updateStatus” + Status.Stato = “aperta” Dettagliopagamento.stato=”non pagato”

FINE




Tabella IRIS_Pendenze_001_Documento

Campo formato Note valorizzazione

MsgId_Pendenza intero progressivo univoco del messaggio (campo contatore) RCF 127 *

RFC_ServiceName Varchar(50) Codice del servizio da utilizzare =valore fisso “IdpAllineamentoPendenze”

RCF 127 *

RFC_XMLCrtDt datetime Data ora inserimento messaggio RCF 127 *

RFC_SenderId Varchar(20)

Identificativo del mittente, codice con cui l'Ente si accredita al CART =valore fisso “RegioneToscana”

RCF 127 *

RFC_SenderSys Varchar(20)

Identificativo del Sistema mittente,codice del SIL riconosciuto al CAR =valore fisso “SIL_CONTICKI”

RCF 127 *

RFC_ReceiverId Varchar(20)

Identificativo del ricevente =valore fisso “RTIRIS”

RCF 127 *

RFC_ReceiverSys Varchar(20)

Identificativo del Sistema ricevente =valore fisso “SIL_IRIS_ITR”

RCF 127 *

RFC_Pendenza_TipoOperazione Varchar(20)

valori possibili “Insert”,”Replace”.”UpdateStatus”,”Delete”, “Update Massivo”

• “Insert” comunicazione del primo invio della specifica pendenza

• ”Replace” comunicazione delle variazioni effettuate sulla

specifica pendenza già precedentemente inviata.

• ”UpdateStatus” comunicazione dell’avvenuto pagamento/storno

della specifica pendenza

• ”Delete” comunicazione della cancellazione della pendenza

RCF 127 *

RFC_TipoPendenza Varchar(20)

TipoPendenza corrisponde a uno dei codici di tributi gestiti dall’Ente e noti all’IdP attraverso la Configurazione dell’Ente. Codifica dei “Tipi Pendenza” previsti:

Tipo Pendenza Descrizione

TICKET_111 Ticket Prestazioni Sanitarie

PRONTO_SOCCORSO_111 Pronto soccorso

MANC_DISD_PRENOT_111 Mancata disdetta prenotazione

MANC_RIT_REFERTO_111 Mancato ritiro referto

LIBERA_PROFESSIONE_111 Libera professione

RECUPERO_CRED_SANZ_111 Recupero crediti e sanzioni relative al ticket o sanzioni non pagate

Il campo è valorizzato nel seguente modo:

• RFC_TipoPendenza= “TICKET_111” o Per tutti i documenti diversi da “PS” e “Malum”

• RFC_TipoPendenza= “PRONTO_SOCCORSO_111” o Se il documento della pendenza ha codiceAccesso = '04'

• RFC_TipoPendenza =” MANC_DISD_PRENOT_111” o Se il documento della pendenza e di tipo “Malum”

• RFC_TipoPendenza= “LIBERA_PROFESSIONE_111”→ o Se il documento è del regime ALP e Area a pagamento

Non sono usati i tipi pendenze “MANC_RIT_REFERTO_111” e “RECUPERO_CRED_SANZ_111”

RCF 127 *

RFC_IdPendenza Varchar(35)

Identificativo documento = “201” (ID AZIENDA -3CHAR) + “4” (Codice Area -1CHAR ) + “1” + (id sw -1CHAR ) + IdDocumentoLogico (30 caratteri per il progressivo) (esempio con IdDocumentoLogico=1 → 20141000000000000000000000000000001)

RCF 127 *

RFC_Mittente_ID Varchar(50)

Codice struttura SysPrest dell’operatore che ha generato il messaggio RCF 127 *

RFC_Mittente_Descrizione Varchar(70)

descrizione struttura SysPrest dell’operatore che ha generato il messaggio Attenzione la descrizione verrà troncata a 70 caratteri

RCF 127 *

RFC_Destinatario_ID Varchar(50)

codice fiscale assistito (beneficiario prestazioni è un assistito) se codice fiscale dell’assistito non valorizzato il campo viene valorizzato con il codice STP dell’assistito

RCF 127 *

RFC_Destinatario_Tipo Varchar(50) valori possibili “Cittadino”, “Delegato”, ”Altro” Campo valorizzato da valore fisso “Cittadino” (in quanto il beneficiario delle prestazioni è sempre un assistito – in anagrafe assistito non sono differenziati gli assistiti e le aziende)

RCF 127 *

RFC_Destinatario_Descrizione Varchar(70) = nominativo assistito (cognome + ‘ ‘ + nome) Attenzione la descrizione verrà troncata a 70 caratteri

RCF 127 *




RFC_Note Varchar(2000) Descrizione del pagamento (riportato anche nella stampa della ricevuta di pagamento IRIS) Valore fisso PRESTAZIONI SANITARIE

RCF 127 *

RFC_DescrizioneCausale Varchar(300) • Se RFC_TipoPendenza= 'TICKET_111' o ='Ticket Prestazioni Sanitarie'

• Se RFC_TipoPendenza= 'PRONTO_SOCCORSO_111' o ='Pronto Soccorso'

• Se RFC_TipoPendenza= 'MANC_DISD_PRENOT_111' o ='Mancata Disdetta'

• Se RFC_TipoPendenza= 'LIBERA_PROFESSIONE' o ='Libera Professione'

RCF 127 *

RFC_Riscossore_Id Varchar(50) Fisso a NULL RCF 127

RFC_Riscossore_Riferimento Varchar(50) Fisso a NULL RCF 127 RFC_DataCreazione Datetime Data creazione documento RCF 127 * RFC_DataEmissione Datetime Data creazione documento RCF 127 * RFC_DataPrescrizione Datetime Data di prescrizione (data dopo la quale i dati vengono spostati

nell’archivio di storico di IRIS) Deve essere individuato il periodo di archiviazione: valorizzato attualmente con data registrazione documento + 2 anni

RCF 127 *

RFC_AnnoRiferimento intero Anno della Data di registrazione documento RCF 127 *

RFC_DataModificaEnte Datetime Data ora di creazione del movimento del documento (data di scrittura nel LOG)

RCF 127 *

RFC_Pendenza_Stato Varchar(10) =Aperta (se documento non pagato) =Chiusa (se documento pagato)

RCF 127 *

RFC_ImportoTotale money Importo complessivo del documento(compreso IVA + Bollo + ticket aggiuntivi + ENPAV + contributo digitalizzazione )

RCF 127 *

RFC_Divisa Varchar(10) =Valore fisso “EUR” RCF 127 * RFC_InfoPag_TipoPagamento Varchar(20) =Valore fisso “Pagamento Unico” RCF 127 * RFC_InfoPag_IdPagamento Varchar(15) IUV (13CHAR) + PagoPa (2CHAR)

IUV = “201” (ID AZIENDA -3CHAR) + “4” (Codice Area -1CHAR ) + “1” + (id sw -1CHAR ) + IdDocumentoLogico (8 caratteri per il progressivo) (esempio con IdDocumentoLogico=1 → 2014100000001 PagoPa= AUX_DIGIT(1CHAR) + CODICE_STAZIONE(2CHAR) + IUV(13CHAR) Mod 93 AUX_DIGIT=0 CODICE_STAZIONE=01 Codice IUV generato dalla funzione [Iris].[fn_Codice_IUV]

RCF 127 *

RFC_InfoPag_CIP_Tipo Varchar(10) = Valore fisso “String” RCF 127 *

RFC_InfoPag_CIP_Codice Varchar(300) Codice a bare del documento Valorizzato come il campo RFC_IdPendenza

RCF 127 *

RFC_InfoPag_DataScadenza datetime Data entro la quale deve essere pagato il tributo per evitare sanzioni aggiuntive. = MIN data prenotata tra le prestazioni del documento (in mancanza di questa data creazione documento )

RCF 127 *

RFC_InfoPag_DataInizioValidita datetime Data da cui sarà possibile eseguire il pagamento; prima di questa data il tributo risulterà non pagabile = data registrazione documento

RCF 127 *

RFC_InfoPag_DataFineValidita datetime Data fine a cui sarà possibile effettuare il pagamento Se tipo RFC_Pendenza_TipoOperazione='Delete'

• =data documento + X giorni Altrimenti

• = MAX (data delle prestazioni del documento)+ X giorni; per le prenotazioni sarà la data di prenotazione e per gli accessi diretti la data di contabilizzazione

o @MaxDataPrenotazioneDoc >= @MaxDataContabilizzaPrestDoc THEN @MaxDataPrenotazioneDoc ELSE @ MaxDataContabilizzaPrestDoc

“X giorni” sono definiti nella tabella di ambiente [IRIS_0010_Ambiente].[GG_DataFineValiditaPendenza] (= 90 giorni)

RCF 127 *

RFC_InfoPag_stato Varchar(30) =”non pagato” (documento non pagato) =”pagato” (documento pagato)

RCF 127 *

RFC_InfoPag_Importo money Se tipo RFC_Pendenza_TipoOperazione='Delete'

• =0

Altrimenti

RCF 127 *




• Importo complessivo da pagare (compreso IVA + Bollo + ticket

aggiuntivi + ENPAV + contributo digitalizzazione )

Msg_Flg_Sincrono intero = 1 messaggio sincrono;= 2 messaggio asincrono Valore fisso =2

RCF 127

RFC_OTF_URL_BACK Varchar(200) Valore fisso NULL RCF 127 * RFC_OTF_URL_CANCEL Varchar(200) Valore fisso NULL RCF 127 *

RFC_OTF_OFFLINE_PAYMENT_METHODS

Varchar(200) Valore fisso NULL RCF 127 *

Doc_SequenzaMsg intero Numerico progressivo di sequenza dei messaggi del documento Esempio valorizzazione

MsgId_Pendenza Doc_Id Doc_SequenzaMsg

1 1000 1

2 1001 1

3 1000 2

4 1000 3

5 1001 2

*

Doc_Id intero Numerico documento SysPrest Uso interno *

Doc_Data datetime Data del documento Uso interno

Doc_Impegnativa_Num Varchar(15) Numero dell’impegnativa Uso interno

Doc_Impegnativa_Data Datetime Data dell’impegnativa Uso interno

Doc_Esenzione_Cod Varchar(11) Codice esenzione indicata nel documento Uso interno *

Doc_Importo_Accertato money Importo accertato del documento Uso interno *

Doc_Causale_Id intero Codice SysPrest della causale del documento Uso interno *

Doc_Conto_Id intero Codice SysPrest del conto del documento Uso interno *

Assistito_Id numerico Uso interno *

Assistito_CodiceFiscale Varchar(16) Uso interno

Assistito_CodUniversale Varchar(24) Uso interno

Assistito_Id_Aziendale int Uso interno

RFC_UpdateStatus_IdPagamento Varchar(15) Campo valorizzato solo se movimento di tipo cassa Valorizzato come il campo RFC_InfoPag_IdPagamento

RCF 127

RFC_UpdateStatus_Stato Varchar(20) Campo valorizzato solo se movimento di tipo cassa =”chiusa” per operazione di tipo incasso; =“aperta” se operazione di

tipo storno.

RCF 127

RFC_UpdateStatus_DataModificaEnte

datetime Campo valorizzato solo se movimento di tipo cassa Data registrazione incasso/storno

RCF 127

RFC_UpdateStatus_Importo Money Campo valorizzato solo se movimento di tipo cassa Importo totale (compreso IVA + Bollo + ticket aggiuntivi + ENPAV + contributo digitalizzazione) incassato/stornato (se storno il valore sarà negativo)

RCF 127

RFC_UpdateStatus_DataPagamento

datetime Campo valorizzato solo se movimento di tipo cassa Data di movimento di cassa

RCF 127

RFC_UpdateStatus_CanalePagamento

Varchar(35) Campo valorizzato solo se movimento di tipo cassa Numero della cassa che ha registrato il pagamento + identificativo pagamenti (cassa.idCassa)

RCF 127

Cassa_TipoOperazione_Id Varchar(1) Campo valorizzato solo se movimento di tipo cassa = E entrata; = U Uscita

Uso interno

RicCassaPDF_daGenerare_FLG int =1 se SysPrest deve generare la ricevuta di cassa PDF per il movimento =0 se SysPrest non deve generare la ricevuta di cassa PDF per il movimento Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

RicCassaPDF_FILE Varchar(200) Nome del file PDF della ricevuta di cassa se per il messaggio è prevista (RicCassaPDF_daGenerare_FLG=1). Valorizzato solo se il file è stato generato correttamente. Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

RicCassaPDF_StatoElaborazioneRicevutaPendenzaId

tinyint stato di elaborazione del file PDF – decodifica tabella IRIS_Pendenze_008_StatoElaborazioneRicevutaPendenza Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

Uso interno

RicCassaPDF_InizioElaborazione datetime Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

Uso interno

RicCassaPDF_FineElaborazione datetime Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

Uso interno




RicCassaPDF_DettaglioEsito varchar(MAX) Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

Uso interno

RicCassaPDF_ConversazioneElaborazione

uniqueidentifier

Identificativo della conversazione sql server service broker per produzione ricevuta Campo non più valorizzato dopo aggiornamento con gestione ricevuta da XML

Uso interno

INS_DataOra datetime Data ora inserimento del messaggio Uso interno *

INS_Utente_id intero Codice utente SysPrest dell’operatore che ha generato il messaggio Uso interno *

INS_Struttura_Id intero Codice struttura dell’operatore che ha generato il messaggio Uso interno *

INS_TipoOperazioneId intero Tipo di operazione SysPrest che ha generato il messaggio decodifica tabella IRIS_Pendenze_006_Anag_TipoOperazione

Uso interno *

Msg_Pendenza_Completato_FLG intero =1 se la composizione del messaggio è completa; altrimenti =0 *

ELAB_Data Datetime =NULL se messaggi non è ancora stato preso in carico dal BUS =data nella quale il BUS a preso in carico il messaggio

Campo valorizzato da BUS

ELAB_IRIS_stato Varchar(50) Risposta da IRIS Valori possibili: “elaborato con errori, “elaborato correttamente”


ELAB_IRIS_DataOra datetime Risposta da IRIS Data ora di registrazione dello stato di ricezione da parte di IRIS


ELAB_IRIS_errore_Cod Varchar(100) Risposta da IRIS Campo valorizzato da BUS

ELAB_IRIS_errore_descizione Varchar(3000) Risposta da IRIS Campo valorizzato da BUS

BUS_NOTE Varchar(3000) Campo a disposizione del BUS (es. utilizzato per indicare se non sono riusciti a leggere il file pdf)


Integrazione_StatoVerificaErrore_ID

int = NULL se messaggio con errore non verificato da operatore; altrimenti decodifica tabella INTEGRAZIONE_0003_STATO_VERIFICA_ERRORE

Uso interno

RFC_E2E_SenderE2ESndrId varchar(20) =valore fisso “AUSL_CENTRO” RCF 127

RFC_E2E_SenderE2ESndrSys varchar(20) =valore fisso “SIL_IRIS_111” RCF 127

RFC_E2E_ReceiverE2ERcvrId varchar(20) =valore fisso “RTIRIS” RCF 127

RFC_E2E_ReceiverE2ERcvrSys varchar(20) =valore fisso “SIL_IRIS_ITR” RCF 127

FLG_su_storico

tinyint

Campo utilizzato dal processo di storicizzazione dei messaggi elaborati Uso interno

PRG_TMP_PENDENZA int Campo utilizzato per il rinvio delle pendenze Uso interno

I campi con * sono obbligatori Il BUS per individuare i messaggi da inviare deve filtrare per:

• Il campo ELAB_Data deve essere =NULL

• Il campo RFC_Destinatario_ID deve essere valorizzato (codice fiscale dell’assistito)

• Il campo Msg_Pendenza_Completato_FLG=1 ATTENZIONE: Nel RFC 127 il destinatario è individuato dal codice fiscale (e non dal codice regionale dell’assistito). I messaggi potranno quindi essere inviati se tale campo è valorizzato. Si ricorda però che il codice fiscale è obbligatorio per i residenti in Italia (lo stato del comune di residenza ha il campo TblStati.Stato_COD=100) con cittadinanza europea.




Tabelle IRIS_Pendenze_002_Documento_DettaglioImporto

Dettaglio dell’importo da pagare per voce (per alimentare TAG ripetuto < DettaglioImporto >.< Voce> del RFC 127)


MsgId_Pendenza intero progressivo del messaggio *

RFC_TipoVoce Varchar(50) RCF 127 *

RFC_BilancioCodice Varchar(50) RCF 127 *

RFC_BilancioDescrizione Varchar(100) RCF 127 *

RFC_BilancioCapitolo Varchar(50) RCF 127

RFC_Accertamento Varchar(50) RCF 127

RFC_Importo money RCF 127 *

La tabella di seguito riporta la codifica del Dettaglio Importo previsti.

Tipo pendenza Voce.Tipo Voce.Codice Voce.Descrizione

TICKET_111

TICKET_BASE 1 Importo base

CONTRIB_DIGIT 2 Contributo di digitalizzazione

QUOTA_FASC_ECO 3 Quota fascia economica

PRONTO_SOCCORSO_111 CONTRIB_DIGIT 4 Contributo di digitalizzazione

QUOTA_PRONTO_SOCC 5 Quota pronto soccorso

RECUPERO_CRED_SANZ_111

TICKET_BASE 6 Importo base

CONTRIB_DIGIT 7 Contributo di digitalizzazione

QUOTA_FASC_ECO 8 Quota fascia economica

INTERESSI 9 Interessi

SPESE 10 Spese di gestione

SPESE_SPED 11 Spese di spedizione

INTERESSI_RUOLO 12 Interessi pratica ruolo

• Per i tipo pendenza “MANC_DISD_PRENOT_111” e “MANC_RIT_REFERTO_111” non è previsto un dettaglio

• Per il tipo pendenza “LIBERA_PROFESSIONE” Il dettaglio deve essere ancora definito La tabella viene valorizzata nel seguente modo:

• Per i documenti RFC_TipoPendenza= “TICKET_111” RFC_TipoVoce =” TICKET_BASE”

RFC_BilancioCodice=”1” RFC_BilancioDescrizione=” TICKET_BASE”

RFC_Importo = importo accertato del documento – importo ticket aggiuntivi – quota digitalizzazione RFC_BilancioCapitolo=NULL RFC_Accertamento=NULL

Se documento prevede il contributo digitalizzazione: RFC_TipoVoce =” CONTRIB_DIGIT”

RFC_BilancioCodice=”2” RFC_BilancioDescrizione=” CONTRIB_DIGIT”


Se documento prevede i ticket aggiuntivi:

RFC_TipoVoce =”QUOTA_FASC_ECO” RFC_BilancioCodice=”3” RFC_BilancioDescrizione=”QUOTA_FASC_ECO”

RFC_Importo = importo ticket aggiuntivi RFC_BilancioCapitolo=NULL RFC_Accertamento=NULL

• Per i documenti RFC_TipoPendenza= “PRONTO_SOCCORSO_111”




RFC_TipoVoce =” QUOTA_PRONTO_SOCC”

RFC_BilancioCodice=”5” RFC_BilancioDescrizione=” QUOTA_PRONTO_SOCC”

RFC_Importo = quota pronto soccorso + ticket RFC_BilancioCapitolo=NULL RFC_Accertamento=NULL Se documento prevede il contributo digitalizzazione:

RFC_TipoVoce =” CONTRIB_DIGIT” RFC_BilancioCodice=”4” RFC_BilancioDescrizione=” CONTRIB_DIGIT”


• Per i documenti con “RFC_TipoPendenza =” MANC_DISD_PRENOT_111” non viene inserita nessuna tipologia di voce

• Per RFC_Pendenza_TipoOperazione = 'Delete' non viene inserita nessuna tipologia di voce

Tabella IRIS_Pendenze_003_Prestazioni

Tabella contenente le prestazioni del documento



progressivo intero Progressivo della prestazione *

Prestazione_Id intero Codice SysPrest della prestazione *

Prestazione_CodAziendale Varchar(30) codice del catalogo aziendale *

Prestazione_CodRegionale Varchar(30) codice del catalogo regionale

Quantita intero

Esenzione_Cod Varchar(11) Codice esenzione applicato alla prestazione *

Prenotazione_Id Intero Valorizzato solo se la prestazione è associata ad una prenotazione

Prenotazione_Data Datetime Valorizzato solo se la prestazione è associata ad una prenotazione

Prenotazione_Ora int Valorizzato solo se la prestazione è associata ad una prenotazione

Importo money Importo della prestazione *

Contabilizzazione_dataOra Datetime Data ora di contabilizzazione della prestazione

Contabilizzazione_Utente_id Intero Utente che ha contabilizzato la prestazione

Listino_id Intero Uso interno *

Listino_data Datetime Uso interno *

Prestazione_DSC Varchar(200) Uso interno

RichiestaId Intero Uso interno

DataOraRchiesta

Datetime Uso interno

idProfilo Intero Uso interno

dataListino_pacchetto Datetime Uso interno

tariffa_pacchetto money Uso interno

I campi con * sono obbligatori La tabella non viene valorizzata per i documenti cancellati. Nota: Per i pacchetti nella vista sono riportate le singole prestazione che compongono Il pacchetto. Nel tracciato proposto non è presente un campo che indichi il riferimento al pacchetto/profilo.




Tabella IRIS_Pendenze_006_Anag_TipoOperazione

Tabella uso interno per decodifica tipo operazione effettuata su SysPrest che ha generato la pendenza


INS_TipoOperazioneId intero *

INS_TipoOperazioneDsc Varchar(200) Progressivo della prestazione *

INS_TipoOperazioneId INS_TipoOperazioneDsc

10 CASSA: Incasso

11 CASSA: Storno

12 CASSA: IRIS

20 CONTABILIZZA

30 CONTABILIZZA: cancellazione documento

40 Variazione Codice Fiscale Assisto

Tabella IRIS_Pendenze_009_Ricevuta



RFC_Debitore_NomeCognome Varchar(100) Nome + ‘ ‘ + Cognome assistito RCF 127 *

RFC_Debitore_DataNascita datetime Data nascita assistito RCF 127 *

RFC_Debitore_CodiceFiscale varchar(16) RCF 127 *

RFC_Debitore_ResidenzaLocalita varchar(100) Descrizione comune di residenza RCF 127 *

RFC_Debitore_ResidenzaIndirizzo varchar(255) Indirizzo residenza RCF 127 *

RFC_DatiPag_IUV varchar(15) = IRIS_Pendenze_001_Documento.RFC_InfoPag_IdPagamento

RCF 127 *

RFC_DatiPag_CausalePagamento varchar(100) = IRIS_Pendenze_001_Documento.RFC_DescrizioneCausale RCF 127 *

RFC_DatiPag_ImportoComplessivo money = IRIS_Pendenze_001_Documento.RFC_ImportoTotale RCF 127 *

RFC_NoteInfo_IdentificativoDocumento varchar(50) = IRIS_Pendenze_001_Documento. Doc_Id RCF 127

RFC_NoteInfo_Informazioni varchar(2048) = 'Data primo appuntamento: ' + min(data prenotazione) RCF 127

I campi con * sono obbligatori La tabella viene valorizzata per i documenti da pagare.

Tabella IRIS_Pendenze_010_Ricevuta_ImportoVoci



TipoVoce Varchar(50) IRIS_Pendenze_002_Documento_DettaglioImporto.RFC_TipoVoce

*

RFC_Descrizione Varchar(100) IRIS_Pendenze_002_Documento_DettaglioImporto.RFC_BilancioDescrizione

RCF 127 *

RFC_Importo money IRIS_Pendenze_002_Documento_DettaglioImporto.RFC_Importo

RCF 127 *

I campi con * sono obbligatori La tabella viene valorizzata per i documenti da pagare.




Rinvio pendenze per cambio codice fiscale dell’assistito

Se per un assistito varia il codice fiscale o il codice universale verranno ritrasmesse le pendenze (per variazione da

integrazione anagrafica o modulo web se l’integrazione IRIS è attiva). Il sistema ri-inierà le pendenze (documenti

classificate integrazione IRIS con importo accertato >0 e importo pagato=0)

Il rinvio delle pendenze per variazione anagrafica non è effettuato contestualmente alla variazione, ma è previsto uno schedulatore “SQL SysPrest 34 –Pendenze rinvio per variazione anagrafica“ che ciclicamente verificherà nella tabella Pendenze_007_RinvioPendenze se ci sono pendenze da creare. Tabella IRIS_Pendenze_007_RinvioPendenze


Msg_PRG intero contatore

Doc_Id int

Assistito_Id int

MotivoRinvio_Tipo_ID int =1 rinvio per variazione codice fiscale;=2 rinvio per variazione codice universale

MotivoRinvio_DSC Varchar(16) Testo con indicazione dei valori variati

INS_DataOra datetime

ELAB_DataOra datetime

ELAB_FLG_Errore

int =1 se il messaggio è stato elaborato con errore; altrimenti =0

ELAB_Errore_DSC Varchar(500)

ATTENZIONE: nessun processo verifica se ci sono messaggi non elaborati.




Storicizzazione messaggi

Il processo SQL 9 storicizza i messaggi elaborati nelle tabelle

• IRIS_Pendenze_050_Documento_STORICO

• IRIS_Pendenze_052_Documento_DettaglioImporto_STORICO

• IRIS_Pendenze_053_Prestazioni_STORICO

• IRIS_Pendenze_056_Ricevuta_ImportoVoci_STORICO

• IRIS_Pendenze_055_Ricevuta_STORICO

Relazioni tabelle

La tabella IRIS_Pendenze_008_StatoElaborazioneRicevutaPendenza contine la decodifica dello stato della

generazione del file PDF (attualmente non più generato) per i messaggi generati con la versione precedente dell’integrazione.




Ricezione del pagamento effettuato su IRIS

Tabella messa a disposizione per il sistema aziendale per comunicare a SysPrest l’avvenuto pagamento di una pendenza effettuata su IRIS

Tabella IRIS_Pagamento_001_notifica


MsgId_NotificaPagamento Progressivo di notifica pagamento (contatore) Contatore di tabella

RFC_ServiceName Varchar(50) Codice del servizio [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_MsgId Varchar(50) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_XMLCrtDt datetime [dato non memorizzato su tabelle di gestione

SysPrest] valorizzato dal BUS

RFC_SenderId Varchar(20)

[dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_SenderSys Varchar(20)


valorizzato dal BUS

RFC_ReceiverId Varchar(20)


valorizzato dal BUS

RFC_ReceiverSys Varchar(20)


valorizzato dal BUS

RFC_TipoPagamento Varchar(50)


valorizzato dal BUS

RFC_IdPagamento Varchar(15)

Campo utilizzato per identificare il Codice del documento SysPrest a cui si riferisce il pagamento (CAST(left(RIGHT(RFC_IdPagamento, 10),8) AS int)

valorizzato dal BUS

*

RFC_DataOraPagamento datetime Data incasso su IRIS valorizzato dal BUS

*

RCF_DataScadenzaPagamento datetime [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_Importo money Importo pagato (importo totale pagato) valorizzato dal BUS

*

RFC_RiferimentoDebitore Varchar(50)


valorizzato dal BUS

RFC_Esito Varchar(50)

- “ESEGUITO”: pagamento effettuato sulla piattaforma IRIS in attesa di essere regolato contabilmente dal circuito bancario (per l'Ente assume valore di previsionale di incasso) - “REGOLATO”: pagamento confermato dal circuito bancario e accreditato sul Conto Tecnico di IRIS (per l'Ente assume valore di previsionale di incasso) - “INCASSO” : l'importo corrispondente al pagamento pagamento è stato riaccreditato da IRIS sul conto di Tesorieria dell'Ente (per l'Ente conferma l'avvenuto incasso)


valorizzato dal BUS

RFC_PaganteTipo Varchar(50)

Tipo dell'identificativo del soggetto che ha effettuato il pagamento. Testo libero con default “Codice Fiscale” . [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_Pagante_IdPagante Varchar(50)

Codice Fiscale o partita IVA del pagante [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_Pagante_Descrizione Varchar(200)

Descrizione del pagante [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_CanalePagamento_Tipo Varchar(500) Descrizione quale canale di pagamento è stato utilizzato per il pagamento (SISAL, posta, Web, ecc) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_CanalePagamento_Descrizione Varchar(500) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_MezzoPagamento_Tipo Varchar(50)

Tipologia del mezzo di pagamento,testo libero.:“Carta di credito”, “Bonifico On-Line”, “Pagamento ATM”, “RID On-Line”, “Bollettino Freccia”, “Bonifico Bancario” ,”Bollettino

Postale”,”MAV”,”RAV”, “ALTRO”

valorizzato dal BUS




Nota: in anagrafe modalità di pagamento di SysPrest forse di deve inserire anche Rid, bonifico, carta di credito. Va trovata una corrispondenza tra le modalità di pagamento Sysprest e IRIS.

RFC_MezzoPagamento_Descrizione Varchar(500) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_DettCanalePagamento_Filiale Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_DettCanalePagamento_Sportello Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_DettCanalePagamento_Idterminale Varchar(200) [dato non memorizzato su tabelle di gestione


RFC_DettCanalePagamento_IdOperazione Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RCF_Tranzazione_Id Varchar(100) Numero identificativo della transazione di pagamento

valorizzato dal BUS

RCF_Tranzazione_DataOra datetime [dato non memorizzato su tabelle di gestione


RFC_Autorizzazione_codice Varchar(100) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_Autorizzazione_DataOra datetime [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_TipoSicurezza Varchar(100) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_ImportoTransato money L'importo transato rappresenta l'importo pagato comprensivo delle commissioni [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_DettImportoTransato_Descrizione Varchar(100) Descrizione della causale [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_FlagQuietanzaCartacea Varchar(10) Flag di richiesta invio quietanza cartacea. Segnala la volontà espressa dal debitore di volere ( se uguale a “vero”) o meno ricevere a casa (per posta o mezzo telematico) una ricevuta che attesti in modo ufficiale l'avvenuto pagamento. [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_Note Varchar(1000) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RIC_RiferimentoDebito_Tipo Varchar(50) Può assumere i valori :“Pendenza” e “Spontaneo”.Indica se è stato effettuato il pagamento di un tributo predeterminato ( “Pendenza”) o se è stato effettuato il pagamento spontaneo di un tributo non predeterminato “Spontaneo” secondo la configurazione attribuita al tipo di tributo pagato [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_RiferimentoDebito_Pendenza Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_RiferimentoDebito_DescrCausale Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_RiferimentoDebito_IdentifUnivocoVersamento

Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

INS_DataOra Datetime Data ora inserimento messaggio valorizzato dal sistema

ELAB_dataOra Datetime Data ora elaborazione del messaggio su SysPrest Valorizzato da SysPrest

ELAB_errore_COD Varchar(100) Valorizzato da SysPrest

ELAB_errore_DSC Varchar(300) Valorizzato da SysPrest

ELAB_CASSA_ID int Numero movimento di cassa generato da SysPrest

Valorizzato da SysPrest

Integrazione_StatoVerificaErrore_ID

int = NULL se messaggio con errore non verificato da operatore; altrimenti decodifica tabella INTEGRAZIONE_0003_STATO_VERIFICA_ERRORE

Valorizzato da SysPrest




ELAB_DOC_ID int Documento ID di riferimento al pagamento Valorizzato da SysPrest

BUS_NOTE varchar(100) valorizzato dal BUS

BUS_ACK_CODICE varchar(100) valorizzato dal BUS

BUS_ACK_ESITO varchar(3000) valorizzato dal BUS

RFC_E2E_SenderE2ESndrId varchar(20) valorizzato dal BUS

RFC_E2E_SenderE2ESndrSys varchar(20) valorizzato dal BUS

RFC_E2E_ReceiverE2ERcvrId varchar(20) valorizzato dal BUS

RFC_E2E_ReceiverE2ERcvrSys varchar(20) valorizzato dal BUS


Il messaggio ricevuto non è processato contestualmente alla ricezione, ma è previsto uno schedulatore (processo SQL 35) che ciclicamente verificherà tabella di LOG IRIS_Pagamento_001_notifica se ci sono dati da elaborare. E’ possibile effettuare con questo messaggio solo pagamenti (entrate in cassa).

I pagamenti avvenuti dall’integrazione sono registrati in una determinata cassa/operatore (definita nella tabella IRIS_0010_AMBIENTE.CASSA_ID - IRIS_0010_AMBIENTE.UTENTE_ID; la modalità di pagamento è “IRIS” che non movimenta la cassa)

L’elaborazione del messaggio effettua dei controlli formali dei dati ricevuti:

• Doc_Id (che corrisponde all’ idDocumento) deve essere presente in SysPrest -- > Il messaggio non sarà elaborato

e viene classificato elaborato con errore (cod.1)

• Il documento risulta già pagato su SysPrest -- > Il messaggio non sarà elaborato e viene classificato elaborato

con errore (cod.2)

• Il documento risulta non contabilizzato -- > Il messaggio non sarà elaborato e viene classificato elaborato con

errore (cod.3)

Non viene effettuato nessun controllo con l’identificativo del pagante e l’assistito del documento riferito al pagamento. L’incasso verrà registrato con l’assistito del documento. La causale di registrazione dell’incasso è la causale del documento (non viene eventualmente individuata la causale di recupero crediti, in quanto se l’incasso è di tipo recupero credito è deciso dall’operatore). Il campo che identifica l’importo pagato è RFC_Importo. La modalità di pagamento degli incassi di IRIS viene utilizzato quello indicato nella tabella ambiente, campo ModalitaPagamento_id ( che dovrebbe essere IRIS) La verifica se l’importo pagato su IRIS corrisponde all’importo pagato su SysPrest viene effettuato dopo aver registrato il

pagamento su SysPrest. L’importo d’incasso è l’importo accertato del documento SysPrest. Nel caso in qui i due importi

sono diversi tra i due sistemi il messaggio viene classificato elaborato con errore (cod.999) ma risulterà registrato incasso.

Registrato l’incasso su SysPrest viene inviato il messaggio di pendenza (che rappresenta la chiusura della pendenza).

Ricevuto il messaggio di notifica pagamento su SysPrest viene generato il pagamento solo se il campo RFC_Esito='ESEGUITO' (pagamento effettuato sulla piattaforma IRIS), non sono attualmente gestite eventuali fasi intermedie ( “REGOLATO”: pagamento confermato dal circuito bancario e accreditato sul Conto Tecnico di IRIS; INCASSO”: l'importo corrispondente al pagamento è stato riaccreditato da IRIS sul conto di Tesorieria dell'Ente). Per le fase intermedie il messaggio non viene processato su SysPrest ma viene edicchetato elaborato (ELAB_dataOra =data odierna).

Successivamente alla ricezione del messaggio il BUS invia a IRIS l’esito dell’elaborazione delle notifiche di pagament su SysPrest nel seguente modo:

• "elaborato correttamente" se [ELAB_dataOra] is not NULL and [ELAB_errore_COD] is null

• "elaborato con errore" se [ELAB_dataOra] is not NULL and [ELAB_errore_COD] is not null --> la descrizione dell'errore si trova nel campo [ELAB_errore_DSC]




Tabella IRIS_Pagamento_002_notifica_DettImportoTransato


MsgId_NotificaPagamento valorizzato dal BUS

RFC_Voce_Tipo Varchar(50) Tipo della voce: enumerato con valori “ImportoTransato”, “ImportoAutorizzato”, “ImportoCommissioni” che specifica l'importo autorizzato, e quello relativo alle commissioni. [dato non memorizzato su tabelle di gestione SysPrest]

valorizzato dal BUS

RFC_Voce_Descrizione Varchar(200) [dato non memorizzato su tabelle di gestione SysPrest] valorizzato dal BUS

RFC_Voce_Importo money [dato non memorizzato su tabelle di gestione SysPrest] valorizzato dal BUS

Storicizzazione messaggi

Il processo SQL 9 storicizza i messaggi elaborati nelle tabelle

• IRIS_Pagamento_030_notifica_STORICO

• IRIS_Pagamento_040_notifica_DettImportoTransato_STORICO

Relazioni tabelle

Tabella di ambiente


DataInizioIntegrazione datetime

Utente_id int

Utente_struttura_id int

Cassa_Id int

ModalitaPagamento_id int Modalità di pagamento utilizzato per la registrazione dell’incasso su SysPrest da notifiche pagamento IRIS

DebugSSBIAAttivato int =1 se attivo debug sql per generazione pdf; altrimenti =0

DataInizioAttivazioneRicevutaPromemoria datetime In prenotazione contabilizzazione la ricevuta di promemoria di pagamento sarà visibile se DataInizioAttivazioneRicevutaPromemoria <= GETDATE() Se campo =NULL la stampa non sarà visibile

GG_DataFineValiditaPendenza int "numero di giorni" da utilizzare per il calcolo del campo "data fine validità" della pendenza




BUS

Il BUS può accedere alle tabelle del database TEST_SysPrestV3_Empoli_INTEGRAZIONI + SysPrestV3_Empoli_INTEGRAZIONI utilizzando l’utente BUS_IRIS con password=@busiris. L’utente BUS_IRIS ha accesso alle seguenti tabelle:

TABELLE accesso Permesso

di scrittura Permesso di lettura

Permesso di cancellazione

IRIS_Pagamento_001_notifica SI SI (ins+upd)

SI NO

IRIS_Pagamento_002_notifica_DettImportoTransato SI SI (ins+upd)

SI NO

IRIS_Pagamento_030_notifica_STORICO SI NO SI NO

IRIS_Pagamento_040_notifica_DettImportoTransato_STORICO SI NO SI NO

IRIS_Pendenze_001_Documento SI SI (ins+upd)

SI NO

IRIS_Pendenze_002_Documento_DettaglioImporto SI SI (ins+upd)

SI NO

IRIS_Pendenze_003_Prestazioni SI NO SI NO

IRIS_Pendenze_006_Anag_TipoOperazione SI NO SI NO

IRIS_Pendenze_007_RinvioPendenze NO --------- --------- ---------

IRIS_Pendenze_008_StatoElaborazioneRicevutaPendenza NO --------- --------- ---------

IRIS_Pendenze_009_Ricevuta SI NO SI NO

IRIS_Pendenze_010_Ricevuta_ImportoVoci SI NO SI NO

IRIS_Pendenze_050_Documento_STORICO SI NO SI NO

IRIS_Pendenze_052_Documento_DettaglioImporto_STORICO SI NO SI NO

IRIS_Pendenze_053_Prestazioni_STORICO SI NO SI NO

IRIS_Pendenze_055_Ricevuta_STORICO SI NO SI NO

IRIS_Pendenze_056_Ricevuta_ImportoVoci_STORICO SI NO SI NO




INTEGRAZIONE CONTICKI

Prescrizione

o Un assistito può prenotare con la stessa prescrizione elettronica in diverse strutture. Effettuata la “presa

in carico” da una struttura la prescrizione non potrà più essere utilizzata dalle altre aziende. In fase di

prenotazione non vengono visualizzate le eventuali prenotazioni effettuate presso altre aziende. La

“presa in carico” effettuata da un’altra azienda verrà segnalata dall’elaborazione che invia i messaggi di

erogato (in quanto è stato registrato una erogazione su una prescrizione in carico ad un’altra azienda).

o Per gli NRE “non esenti” se non è indicata la fascia di reddito viene interpretata come l’assistito non

abbia dato il consenso quindi paga la fascia massima.

o Il numero della ricetta NRE e sensibile ai caratteri maiuscoli e minuscoli (per la parte dei primi 5 caratteri).

Il sistema inserisce automaticamente i caratteri in maiuscolo.

o Ricevuti i dati di una nuova prescrizione sarà possibile confermare l’operazione solo se è possibile

trovare la corrispondenza in SysPrest con il tipo ricetta e la fascia di reddito.

o Se Il codice di esenzione della prescrizione non è presente nel sistema, la prescrizione viene

automaticamente considerata “non esente” (applicando la fascia di reddito di tipo 'non dichiarata')

o La fascia di reddito viene impostata automaticamente con i dati ricevuti nel campo “disposizioni

regionali” (prenotazione/contabilizzazione)

o I dati dell’assistito riportati della ricetta NRE sono memorizzati in un’apposita tabella d’integrazione;

viceversa in SysPrest rimangono memorizzati i dati della propria anagrafica.

o Dai dati ricevuti dalla prescrizione non viene identificato il medico dell’anagrafica SysPrest. In quanto

dall’integrazione non viene trasmessa l’informazione della tipologia del medico ma solo “il codice

specializzazione”

o Le prestazioni ricevute con quantità > 1 sono memorizzate singolarmente. Una prestazione a ciclo viene

memorizzata per singola seduta (in medico nella prescrizione indica nella quantità il numero di

prestazioni a cicli→ p1 con qta 2 → se p1 è un ciclo di 8 sedute→ il medico ha prescritto 16 sedute)

o Le keyword del messaggio vengono generate per ”idAssistito” SysPrest

o Per le prescrizioni classificate “manuali” l’eventuale messaggio ricevuto di “visualizzazione” non

aggiorna i dati della prescrizione. Viene pero aggiornato lo stato in “ANNULATA VISUALIZZAZIONE:

visualizza OK” o “ANNULATA VISUALIZZAZIONE: visualizza ERRORE”. Nel caso di “errore” il sistema

scarica comunque gli errori.




o Messaggio di risposta su tipo operazione “visualizza”

▪ Se prescrizione caricata “manualmente”:

• il messaggio di risposta non modifica i dati della prescrizione.

• Se ricevuto messaggio “corretto” lo stato della prescrizione è aggiornato a

“ANNULATA VISUALIZZAZIONE: visualizza ok”

• Se ricevuto messaggio “non corretto”

o lo stato della prescrizione è aggiornato a “ANNULATA VISUALIZZAZIONE:

visualizza ERRORE”

o nella prescrizione viene mantenuto traccia degli errori ricevuti

▪ Se prescrizione gestita da integrazione:

• Se ricevuto messaggio “corretto” lo stato della prescrizione è aggiornato a

“VISUALIZZAZIONE: OK”

• Se ricevuto messaggio “non corretto”:

o lo stato della prescrizione è aggiornato a “VISUALIZZAZIONE: ERRORE”

o nella prescrizione viene mantenuto traccia degli errori ricevuti

o registrazione dati prescrizione

o Il messaggio di risposta per il tipo operazione “presa in carico” non modificano i dati della prescrizione.

Ricevuto un messaggio di visualizza corretto i dati della prescrizione non vengono più aggiornati.

o Una prescrizione con tutte le prestazioni con accesso diverso da “confermato” (quindi “non presentato”

o “non erogato”) non verrà mai inviato un messaggio di “presa in carico”.

o Per una prescrizione che si è ricevuto il messaggio di errore alla richiesta di visualizzazione non sarà

possibile effettuare la registrazione della prescrizione per l’assistito.

Eventi che generano il messaggio di “prescrizione”: o L’operazione di “visualizzazione” viene richiesta all’inserimento di un numero NRE (in prenotazione e

in contabilizzazione) se la prescrizione non è già presente nel sistema.

o L’operazione di “presa in carico” viene richiesta all’erogazione di tipo “confermato” della prima

prestazione della prescrizione (da contabilizza, da accettazione (singola o per foglio), da integrazione

erogato)

Attenzione: “la presa in carico” viene comunicata in automatico all’accesso “confermato”. Nella spunta dell’elaborazione di preparazione dei dati dell’erogato da inviare a Conticki viene segnalato le eventuali prescrizioni inviabili ma “non prese in carico”.

o L’operazione di “rilascio”: nessuna funzione permette di rilasciare una prescrizione (in quanto se si

rilascia un NRE la prescrizione ritorna in stato di “prescritta”)




Prenotazione

o Il messaggio di prenotazione viene creato in fase di registrazione web della prenotazione.

o In prenotazione nella pagina di dettaglio degli orari disponibili non è più possibile prenotare nello stesso

buco occupato da una prenotazione precedente per l’assistito (dalla funzione di forzatura la funzionalità

rimane disponibile)

o I messaggi ricevuti prevedono un messaggio di ritorno (nel corpo del messaggio ritorna RFC231).

o Il messaggio riporta il riferimento del codice IUV di pendenza. Si evidenzia che eventuali operazioni di

annullamento della contabilizzazioni e nuova contabilizzazione, non rinviano i messaggi di prenotazione.

Inoltre se le prestazioni di una prenotazione sono contabilizzate in documenti diversi viene comunicato

il primo documento inviato a IRIS.

o Il messaggio riporta il riferimento al numero di ricetta (Rossa o NRE). Il numero di ricetta inviato coincide

con il numero di ricetta indicato in prenotazione. Attualmente non è presente nessun controllo (per la

ricetta rossa) che assicuri la coerenza tra la ricetta e le prestazioni contabilizzate. Pertanto bisogna fare

attenzione nelle operazioni di annullamento e nuova contabilizzazione; ad esempio se una prestazione

precedentemente prenotata su una determinata ricetta venisse collegata ad una nuova ricetta, su

Conticki rimane la precedente situazione.

o ATTENZIONE: Nel messaggio per l’assistito i campi obbligatori del sono (il messaggio viene comunque

generato ma avrà un ritorno di errore)

▪ Indirizzo residenza (campo non obbligatorio nel modulo web di gestione dei dati anagrafici

dell’assistito)

▪ Comune residenza

▪ Cap comune residenza

▪ Un tipo di codice identificativo (CF a 16 caratteri / CF 11 caratteri/ codice STP/ codice TEAM/

identificativo straniero)

o ATTENZIONE: Il codice prestazione inviato è il codice regionale: se non valorizzato la prenotazione non

verrà registrata (il sistema visualizzerà l’errore da database)

o Le keyword del messaggio vengono generate per ”idAssistito” SysPrest

o Il messaggio 0 fine= ora appuntamento + durata prenotazione; disponibilità totale=1). L’informazione

completa dei modelli di apertura saranno comunicati a Conticki successivamente all’attivazione

dell’integrazione degli “eventi di disponibilità” (RFC Agende).

o Il sistema Conticki se la nuova prenotazione si riferisce ad una prescrizione elettronica invoca i servizi

della RFC231 della prescrizione con tipo operazione “visualizza” (cod.15). Il messaggio di risposta della

prenotazione per la parte del RFC231 viene ignorato.

o Il sistema Conticki se la cancellazione di una prenotazione si riferisce ad una prescrizione elettronica

invoca i servizi della RFC231 della prescrizione con tipo operazione “rilascio” (cod.13). Il messaggio di

risposta della prenotazione per la parte del RFC231 viene ignorato.

o Non è previsto nessun invio delle prenotazioni future già presenti ne sistema all’attivazione

dell’integrazione Conticki.




Erogato

o Vengono inviate solo le prestazioni con accesso di tipo “confermato”. Non è possibile inviare le prestazioni con accesso di tipo “non erogato” in quanto la prestazione viene scollegata dalla prescrizione e inoltre potrebbe verificarsi il caso che una prestazione prescritta venga “non erogata” più volte (in quanto si utilizza lo stato “non erogato” anche per le prestazioni per cui deve essere spostato l’appuntamento). Non si è in grado quindi di distinguere il vero “non erogato”.

o Il messaggio di erogato Rfc231 viene scartato se “data spedizione” (che corrisponde alla data max di erogazione del doc) < della data di “presa in carico” → esempio: indicata data erogazione 26-11-2015 (data spedizione) inferiore al momento in qui è stata data l'erogazione 03-12-2015 (quindi all'invio della richiesta di presa in carico) → la data di “presa in carico” non è una data che viene trasmessa nel tracciato (è quindi non utilizzabile)..il problema si può verificare anche quando il sistema non è attivo → carico manualmente la prescrizione (01/12/2015), erogo la prestazione il 01/12/2015, invio presa in carico (che non viene inviata per il blocco) → la presa in carico viene effettuata il giorno seguente → l’erogato verrà scartatato in quanto la data spedizione è < della data di presa in carico → NESSUN BLOCCO DA SISTEMA

o Per le prestazioni a ciclo si inviano i dati di prenotazione/spa relativi al max (id accesso) o Le prestazioni erogate vengono inviate da una elaborazione notturna (processo sql SysPrest 44 -

Conticki prep dati – EROG → rimane da definire la pianificazione). 1. Il processo crea un elaborazione che può essere controllata dalla funzione web “diario delle

elaborazioni”

2. Vengo elaborati i documenti classificati Conticki= SI (CTK_FLG = 1), non precedentemente inviati

(CTK_EROG_STATO_ID = 0)

3. Dai documenti da elaborare vengono cancellati (nessuna quadratura per queste cancellazione):

• I documenti che hanno la data erogazione + 8 giorni < =della data odierna

“fino al fino al 30/06/2016 Si chiede di adeguare il controllo sulla chiusura dell’erogazione per permettere la chiusura stessa entro 10 gg. dall’ultima prestazione erogata” E’ stato indicato “8 giorni” per permettere di correggere eventuali documenti che devono essere spediti al massimo nei 2 sue giorni successivi

• I documenti che hanno almeno una prestazione associata senza indicazioni dell’accesso

• I documenti senza nessuna prestazioni associata

4. Spunte dell’elaborazione (di documenti cancellati) con relative quadrature

• S.03: Attenzione, ci sono documenti di tipo prescrzione elettronica ma non associata prescizione elettronica.

• S.05 : Attenzione, ci sono documenti associati a prescrizione con nessuna prestazione associata

• S.10 : Attenzione, ci sono documenti estraibili (con tutte le prestazioni indicato accesso) ma non elaborati in quanto sono associate prestazioni non erogate

• S.15 : Attenzione, ci sono documenti estraibili ma non elaborati in quanto sono Contabilizzati.

• S.20 : Attenzione, ci sono documenti estraibili ma presa in carico Conticki non confermata.

• S.22 : Attenzione, ci sono documenti estraibili ma che hanno associate prestazioni non collegate alla prescrizione

• S.25 : Attenzione, ci sono documenti estraibili ma non elaborati in quanto assistito senza indirizzo/comune residenza

• S.30 : Attenzione, ci sono documenti estraibili ma con prestazioni con codice STS non valorizzato.

• S.35 : Attenzione, ci sono documenti estraibili ma con prestazioni con codice ambulatorio agenda non valorizzato.

• S.40 : Attenzione, ci sono documenti estraibili ma con prestazioni con disciplina non valorizzata.

• S.50 : Attenzione, ci sono documenti estraibili ma con prestazioni con codice regionale non valorizzato.

• S.55 : Attenzione, ci sono documenti estraibili ma non elaborati in quanto MSG di Prenotazioni su prescrizioni non tutti inviati correttamente

• S.56 : Attenzione, ci sono documenti estraibili ma con prestazioni con codice branca non valorizzata

• S.60 : Attenzione, ci sono documenti estraibili ma con prestazioni prenotate classificate Conticki con ReferenceAgenda_IdSeduta_codice non valorizzata




5. Spunte di verifica

• S.200 : Attenzione, ci sono prescrizioni prese in carico ma senza documento contabile

• S.210 : Attenzione, ci sono prescrizioni senza documento contabile ma con associate prestazioni con accesso di tipo “confermato”

6. Le prestazioni/documenti non elaborati sono memorizzati solo nelle spunte (visibili dalla funzione web “diario elaborazioni”)

7. Le prestazioni erogate inviate vengono classificate “elaborate erogato Conticki” (campo CTK_EROG_DATA_ELAB valorizzato con la data di elaborazione erogato sull’ accesso e sul documento; mentre per la prescrizione viene impostato lo stato “EROGATO: totale” o “EROGATO: parziale”)

Sistema di monitoraggio dell’integrazione

• Attualmente non è presente nessun servizio che in automatico rinvia in messaggi con errore (escluso i

messaggi inviati che il “Proxy 98 CAST” non riesce ad inviare a Conticki). Sono Presenti le seguenti viste (sul

database SysPrestV3_Empoli_INTEGRAZIONI) per monitorare i messaggi di errore non ancora verificati

(StatoVerificaErrore_ID=NULL)

o Trasmissione

▪ CTK.v0001_TRASMISSIONE_Errore_SenzaRx (messaggi trasmessi senza risposta e non

ritrasmessi)

o Erogato

▪ CTK-EROG. v0001_ErroriPreparazione

▪ CTK-EROG.v0002_ErroriTransmissione

▪ CTK-EROG.v0003_ErroriRicezione ▪ CTK-EROG.v0004_ErroriEsito ▪ CTK-EROG.v0005_ErroriEsito_Evento ▪ CTK-EROG.v0006_ErroriEsito_EventoRicevutaNRE ▪ [CTK-EROG].[v0007_PRESTAZIONI_ELAB_Errori]

o Prenotazione

▪ CTK-PREN.v0010_Prenotazioni_ConErrore (dalla tabella di attività CTK-

PREN.PRENOTAZIONI)

▪ CTK-PREN.v0009_Prenotazioni_Attesa_RX (dalla tabella di attività CTK-

PREN.PRENOTAZIONI)

▪ CTK-PREN. v0001_ErroriPreparazione

▪ CTK-PREN. v0002_ErroriTransmissione

▪ CTK-PREN.v0003_ErroriRicezione

▪ CTK-PREN.v0004_ErroriEsito

▪ CTK-PREN.v0005_ErroriEsito_Evento

o Prescrizione

▪ DOC. v0002_Prescrizione_ConErrore (dalla tabella di attività DOC.PRESCRIZIONE) ▪ DOC.v0003_InAttesaRisposta (dalla tabella di attività DOC.PRESCRIZIONE) ▪ CTK-PRESC.v0001_ErroriPreparazione ▪ CTK-PRESC.v0002_ErroriTransmissione ▪ CTK-PRESC.v0003_ErroriRicezione ▪ CTK-PRESC.v0004_ErroriEsito ▪ CTK-PRESC.v0005_ErroriEsito_Evento ▪ CTK-PRESC.v0006_ErroriEsito_EventoNRE ▪ [CTK-PRESC].[v0007_Errori_ACK] (esempio per ACk con codici di errore 007 “numero

tentativi rinvio…” -501 ecc)

• Sistema di pulizia delle tabelle di LOG e [CTK-AGEN].[TEMPLATE]




INVIO

• Lo schedulatore d’invio dei messaggi è unico per tutti gli RFC. E’ un servizio di Windows che ogni 5 secondi invia

5 messaggi. Il servizio elabora i messaggi in ordine di priorità dello scenario e QidMessaggio (ORDER BY

CTK.RFC_ANAGRAFE.PrioritaTrasmissione, CTK.TRASMISSIONE.QidMessaggio). Il messaggio inviato (con

risposta corretta o meno o con errore in fase di creazione del messaggio) viene spostato nel LOG. I messaggi

che non si riescono ad inviarli (proxy non è raggiungibile) rimangono nella coda di trasmissione.

• Il log di operazioni che dovranno generare un messaggio sono memorizzati in specifiche tabelle diverse per ogni

scenario (esempio CTK-PRESC.INVIO per le prescrizioni). Uno specifico processo sql (esempio “SysPrest 37 -

Conticki prep tx – PRESC”) per ogni scenario elabora “msgId” (prepara XML del corpo del messaggio nella tabella

[CTK].[TRASMISSIONE]) e passa il dato in specifiche tabelle di log (esempio CTK-PRESC.INVIO_LOG). I

messaggi per cui non si è riusciti a costruire XML vengono spostati nel log classificandoli elaborati con errore.

• I messaggi da inviare che hanno un errore in fase di costruzione del messaggio (esempio la struttura dati da

inviare non è corretta), il messaggio viene classificato con errore e viene spostato nella tabelle di log dello

specifico scenario (esempio [CTK-PREN].[INVIO_LOG] con Elab_StatoId =2 “elaborato con errore”) Per i

messaggi di prescrizione si precisa che si si verifica un errore di questo tipo la prescrizione non viene classificata

con errore.

• L'accesso ai servizi prevede una autenticazione http con chiave "Authorization" e valore "Basic

cmZjdXNlcjpwYXNzd29yZA=="

o L’URL invocato per l’ambiente di test è http://172.27.144.34:10991/RFC98Asincrono.

o L’URL invocato per l’ambiente di produzione http://172.16.100.169:10991/RFC98Asincrono

Msessaggio di risposta da SAC/SAR <ns13:MsgEsito azienda="201" msgId="337c4475-9f0b-4963-a029-e31fec695941" stato="0"> <ns13:esitoEvento idEvento="10476725" stato="0"> <ns13:risposta> <ns13:invioErogatoRicevuta> <ns6:InvioErogatoRicevuta> <ns6:nre>090A02134700540</ns6:nre> <ns6:dataRicezione>2016-06-21 22:13:34</ns6:dataRicezione> <ns6:codEsitoInserimento>0000</ns6:codEsitoInserimento> <ns6:ElencoErroriRicette> <ns7:ErroreRicetta> <ns7:codEsito>0000</ns7:codEsito> <ns7:esito>Operazione eseguita correttamente</ns7:esito> <ns7:progPresc>0</ns7:progPresc> <ns7:tipoErrore /> </ns7:ErroreRicetta> </ns6:ElencoErroriRicette> <ns6:ElencoComunicazioni> <ns7:Comunicazione> <ns7:codice>0600</ns7:codice> <ns7:messaggio>Nessuna comunicazione</ns7:messaggio> </ns7:Comunicazione> </ns6:ElencoComunicazioni> </ns6:InvioErogatoRicevuta> </ns13:invioErogatoRicevuta> </ns13:risposta> </ns13:esitoEvento> <ns13:rfc> <ns13:nome>PROCESSO</ns13:nome> <ns13:numero>246</ns13:numero> </ns13:rfc> </ns13:MsgEsito>

http://172.27.144.34:10991/RFC98Asincrono




Msessaggio di risposta da CTK <ns13 azienda="201" msgId="2926fd0e-cdbd-4207-ae0f-3212a4886c12" stato="0"> <ns13:esitoEvento idEvento="10591762" stato="0" /> <ns13:rfc> <ns13:nome>PROCESSO</ns13:nome> <ns13:numero>246</ns13:numero> </ns13:rfc> </ns13:MsgEsito>




Rinvio messaggi

Se il “Proxy 98 CAST” non riesce ad inviare un messaggio a Conticki invia al sistema CUP un messaggio con

riferimento RFC98 (o RFC specifico) con il “dettaglio Ack” con codice errore “007- inoltro fallito per

raggiungimento del numero massimo di tentativi”.

<IntestazioneAck xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://regione.toscana.it/sis/generic"> <QIdMessaggio> <Dominio radice="2.16.840.1.113883.2.9.2.90" estensione="4.5.CTK.1" /> <Id>P98Empoli_P98EmpoliSPCoopIT_1068876_2016-01-22_14:23</Id> </QIdMessaggio> <TipoComunicazione>P</TipoComunicazione> <Data>2016-01-22T02:14:23</Data> <Interazione> <RFC>246</RFC> <Versione>0</Versione> <Scenario>2</Scenario> </Interazione> <RifMessaggio> <Dominio radice="2.16.840.1.113883.2.9.2.90111" estensione="4.5.CUP.1" /> <Id>692</Id> </RifMessaggio> <Acknowledgement> <Esito>E</Esito> <DettaglioAck> <Codice>007</Codice> <Descrizione>Inoltro fallito per raggiungimento del numero massimo di tentativi</Descrizione> </DettaglioAck> </Acknowledgement> </IntestazioneAck> <IntestazioneAck xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://regione.toscana.it/sis/generic"> <QIdMessaggio> <Dominio radice="2.16.840.1.113883.2.9.2.90" estensione="4.5.CTKt.1" /> <Id>P98EstavcTEST_P98EstavcTESTSPCoopIT_28645_2015-08-19_11:19</Id> </QIdMessaggio> <TipoComunicazione>T</TipoComunicazione> <Data>2015-08-19T11:55:19</Data> <Interazione> <RFC>98</RFC> <Versione>6</Versione> <Scenario>0</Scenario> </Interazione> <RifMessaggio> <Dominio radice="2.16.840.1.113883.2.9.2.90111" estensione="4.5.CUPt.1" /> <Id>127</Id> </RifMessaggio> <Acknowledgement> <Esito>E</Esito> <DettaglioAck> <Codice>007</Codice> <Descrizione>Inoltro fallito per raggiungimento del numero massimo di tentativi</Descrizione> </DettaglioAck> </Acknowledgement> </IntestazioneAck>

http://www.w3.org/2001/XMLSchema-instance

http://www.w3.org/2001/XMLSchema

http://regione.toscana.it/sis/generic

http://www.w3.org/2001/XMLSchema-instance

http://www.w3.org/2001/XMLSchema

http://regione.toscana.it/sis/generic




Il “Proxy 98 CAST” tenda di inviare il messaggio 5 volte (ogni 10 secondi), il CUP dopo la ricezione del messaggio

Ack con errore “007” deve rinviare il messaggio.

Un processo “ SysPrest 46 - Conticki retry tx” ogni xxx identifica I messaggi da rinviare sono

SELECT QidMessaggio FROM CTK.TRASMISSIONE_LOG WHERE (ConteggioErroriCAST = 1) AND (Retry_DataOra IS NULL) AND (NumeroTentativo <= 5) ORDER BY QidMessaggio

Esempio 1) Dati in tabella CRK.TRASMISSIONE_LOG

QidMessaggio

ConteggioErroriCAST

NumeroTentativo

QidMessaggioTentativoPrecedente

Retry_DataOra

10 5 1

Il processo di rinvio identifica QidMessaggio=10 da rinviare

QidMessaggio

ConteggioErroriCAST

NumeroTentativo

QidMessaggioTentativoPrecedente

Retry_DataOra

10 5 1 28/07/2015

20 0 2 10

Rimane da definire dopo quanto tempo il messaggio deve essere rinviato




SCENARIO DI INVIO

** NON ATTIVATO**

Funzioni web prenotazione+ sposta prenotati

Funzioni web contabilizza + prenotazione con contabilizzazione + accettazione

Tabelle log operazioni da inviare per specifico scenario

Tabelle messaggi da inviare

Tabelle messaggi inviati (inviati ok o con errore)

Un processo sql per scenario che prepara il corpo del messaggio xml

CTK-PRESC.INVIO MsgId

CTK-PREN.INVIO MsgId

Processo SQL SysPrest 38 - Conticki

prep tx – PREN (2 msg ogni xx secondi)

Processo SQL SysPrest 37 - Conticki

prep tx – PRESC (10 msg ogni 10 secondi)

CTK.TRASMISSIONE QidMessaggio RFC MsgId

CTK-PRESC.INVIO_LOG MsgId

Elab_StatoId

CTK-PREN.INVIO_LOG MsgId

Elab_StatoId

CTK.TRASMISSIONE_LOG Elab_StatoId

Proxy 98 CAST

Servizio di Windows

“Trasmissione”

Consumatore della coda unica di trasmissione verso l’infrastruttura CAST (5 msg ogni 5 secondi)

CTK-EROG.INVIO MsgId

Processo SQL SysPrest 44 - Conticki preparazione MSG EROG (una volta al giorno alle xx:xx)

Processo SQL TEST - SysPrest 39 - Conticki prep tx - EROG (5 msg ogni 10 secondi)

CTK-ERG.INVIO_LOG MsgId

Elab_StatoId




RICEZIONE

• E’ presente un solo servizio esposto per la ricezione dei messaggi. I messaggi ricevuti vengono memorizzati nella

tabella CTK.RICEZIONE.

o Il servizio di test è http://ppcup.usl11.net:10991/RFC98Asincrono (su server ip 172.16.100.56)

o Il servizio in produzione è http://vintegra.usl11.net:10991/RFC98Asincrono (su server ip. 200.1.1.117)

• Il processo SQL smistatore “SysPrest 40 - Conticki smista rx” (sono elaborati in ordine di arrivo, non possono

essere elaborati in ordine di priorità dello scenario in quanto tutti i messaggi arrivano con lo stesso RFC 246 e

scenario 6)

• Se il sistema CAST non riesce ad inviare i messaggi ritorna un errore di “Inoltro fallito per raggiungimento del

numero massimo di tentativi”

• Si accettano messaggi con le seguenti coppie radice-estensione :

o 2.16.840.1.113883.2.9.2.90-4.5.CTK.1: Contiki

o 2.16.840.1.113883.2.9.2.90 - 4.5.P98.1 : Proxy Cast Regione

o 2.16.840.1.113883.2.9.2.90802 - 4.5.P98.1 : Proxy Cast AVC

o 2.16.840.1.113883.2.9.2.90111 - 4.5.P98.1 : Proxy Cast Empoli

http://ppcup.usl11.net:10991/RFC98Asincrono

http://vintegra.usl11.net:10991/RFC98Asincrono




SCENARIO DI RICEZIONE

Processo SQL che smista in specifiche tabelle per scenario, per priorità di scenario

Un processo SQL per scenario che espande il messaggio xml ricevuto in specifiche tabelle

Proxy 98 CAST

Servizio Esposto RFC98

asincrono CSIO

CTK.RICEZIONE SPCoopId RFC

Processo SQL SysPrest 40 - Conticki smista rx (elabora 20 msg ogni 10 secondi) + espandi PRESC (10 messaggi)

CTK-PRESC.RICEZIONE SPCoopId

CTK-PREN.RICEZIONE SPCoopId

CTK.RICEZIONE_LOG SPCoopId RFC

espandi rx – PRESC (direttamente da processo SQL 40)

Processo SQL SysPrest 42 - Conticki espandi rx – PREN (elabora 3 msg ogni 10 secondi)

Aggiornamento prescrizione SysPrestV3_Empoli.DOC.PRESCRIZIONE

CTK-PRESC.ESITO

CTK-PREN.ESITO

Aggiornamento

prescrizione SysPrestV3_Empoli.CTK-PREN.PRENOTAZIONI

CTK-EROG.RICEZIONE SPCoopId

Processo SQL SysPrest 43 - Conticki espandi rx – EROG (elabora 3 msg ogni 10 secondi)

CTK.TRASMISSIONE_LOG (per indicare RX_SPCoopId




Processi SQL utilizzati dall’integrazione

• SysPrest 37 - Conticki prep tx – PRESC

• SysPrest 38 - Conticki prep tx – PREN → NON ATTIVO

• SysPrest 39 - Conticki prep tx - EROG

• SysPrest 40 - Conticki smista rx + espandi rx - PRESC

• SysPrest 42 - Conticki espandi rx – PREN → NON ATTIVO

• SysPrest 43 - Conticki espandi rx - EROG

• SysPrest 44 - Conticki prep dati - EROG

• SysPrest 45 - Conticki prep dati - AGEN → generazione template di disponibilità - NON ATTIVO

• SysPrest 46 - Conticki retry tx → NON ATTIVO

I processi SQL partono sfasati di alcuni secondi: processo N.37 inizia alle 00:00; processo N.40 inizia alle 00:04; processo N.41 inizia alle 00:07 → per evitare tempi di attesa lunghi nel passaggio tra i vari processi. Per l’ambiente di test il routing dei messaggi è la seguente: Andata: SysPrest TEST (172.16.100.56) --> Cast AVC test(172.27.144.34) --> Cast Regionale (159.213.95.84) → Conticki Ritorno: Conticki → Cast Regionale (159.213.95.84) --> Cast AVC test(172.27.144.34) --> Cast Empoli (172.27.80.50) --> SysPrest TEST (172.16.100.56) Cast Regionale: http://159.213.95.84:8080/picassoesb.proxy98/test/RFC98Asincrono?wsdl ([email protected])

http://159.213.95.84:8080/picassoesb.proxy98/test/RFC98Asincrono?wsdl





Ricette NRE gestite sul modulo ricetta rossa

All'attivazione dell’integrazione Conticki nel sistema saranno presenti ricette NRE registrate su modulo di tipo “ricetta rossa”, si potranno quindi verificare i seguenti casi: CASO 1) ricetta NRE registrata su modulo contabilizzazione “ricetta rossa” già presente nel sistema SysPrest all'attivazione di Conticki

• CASO 1.1) L’operatore da prenotazione seleziona il percorso di prenotazione “ricetta Elettronica NRE”: inserito il numero di ricetta NRE il sistema visualizza un messaggio di errore “Esiste già registrata prescrizione NRE nel modulo ricetta rossa” (contabilizzazione)

• CASO 1.2) L’operatore da contabilizza selezionando nuovo documento “ ricetta NRE: inserito il numero di ricetta NRE il sistema visualizza un messaggio di errore “Esiste già registrata prescrizione NRE nel modulo ricetta rossa”

• CASO 1.3) L’operatore da prenotazione seleziona il percorso “ricetta rossa”: inserito il numero di ricetta NRE il sistema visualizza il modulo di aggiornamento di tipo “ricetta rossa” . NOTA: non è attivo il controllo formale sul numero di ricetta inserito in quanto deve essere possibile registrare eventuali ricette NRE da non gestire con l’iter d’integrazione Conticki

• CASO 1.4) L’operatore da contabilizza potrà modificare la ricetta NRE su modulo di tipo “ricetta rossa” CASO 2) nuova ricetta NRE

• CASO 2.1) L’operatore da prenotazione seleziona il percorso “ricetta Elettronica NRE”: la ricetta NRE seguirà l’iter d’integrazione con Conticki

• CASO 2.2) L’operatore da contabilizza seleziona nuovo documento “ ricetta NRE”: la ricetta NRE seguirà l’iter d’integrazione con Conticki

• CASO 2.3) l’operatore da prenotazione seleziona il percorso “ricetta rossa”: inserito il numero di ricetta NRE il sistema visualizza il modulo di registrazione di tipo “ricetta rossa”.

• CASO 2.4) l’operatore da contabilizza seleziona nuovo documento di tipo “ricetta rossa: inserto il numero di ricetta NRE il sistema visualizza il modulo di registrazione di tipo “ricetta rossa”. NOTA: non è attivo il controllo formale sul numero di ricetta inserito in quanto deve essere possibile registrare eventuali ricette NRE da non gestire con l’iter d’integrazione Conticki

CASO 3) ricetta NRE registrata su iter d’integrazione con Conticki

• CASO 3.1) L’operatore da prenotazione seleziona il percorso “ricetta Elettronica NRE”: la ricetta NRE seguirà l’iter d’integrazione con Conticki

• CASO 3.2) l’operatore da prenotazione seleziona il percorso “ricetta rossa”: inserito il numero di ricetta NRE il sistema visualizza un messaggio di errore “Ricetta Nre gestita da prescrizione elettronica”

• CASO 3.3) l’operatore da contabilizza seleziona nuovo documento di tipo “ricetta rossa”: inserito il numero di ricetta NRE il sistema visualizza un messaggio di errore “Esiste già una prescrizione elettronica inserita per il numero NRE xxxxxxxxxxxxxxx” Dal modulo d’inserimento del numero di ricetta, l’operatore potrà indicare il numero di ricetta NRE (come attuale funzionalità).

Si ricorda inoltre che:

✓ Ad una ricetta NRE registrata su modulo “ricetta rossa” potranno essere collegate solo prenotazioni non associate a prescrizioni gestite da integrazione.

✓ Ad una ricetta NRE gestita da integrazione potranno essere collegate solo prenotazioni associate alla prescrizione ricevuta.




Tabelle

Tabella PRESCRIZIONE

PRESCRIZIONE CAMPO TABELLA Documenti_Impegnative

PRESCRIZIONE_ID bigint

RICETTA varchar(16) Ricetta

MedicoCF varchar(16) MedicoCF

AssistitoCodice varchar(16)

CodEsenzione varchar(6)

NonEsente varchar(1)

TipoRicetta varchar(2)

QuesitoDiagnosticoCod varchar(10) NRE_quesitoDiagnosticoCod

QuesitoDiagnosticoDsc varchar(500) NRE_quesitoDiagnosticoDsc

DataCompilazione datetime DataRicetta

TipologiaPrescrizione varchar(1) RIC_SUGGERITA = (TipologiaPrescrizione='S' then '01' else '03' end) NRE_TipologiaPrescrizione

Altro varchar(1)

ClassePriorita varchar(1) Trasformato colore_id_ricetta

StatoEstero varchar(2) STATO_ESTERO_UE_ID

IstruCompetente varchar(28) IMPEGNATIVA_COD_ISTITUZIONE

NumIdentPersonale varchar(20) IMPEGNATIVA_NUM_PERSONALE

NumIdentTessesera varchar(20) IMPEGNATIVA_NUM_TESSERA

DataScadenzaTessera datetime DATA_SCADENZA_TESSERA_EUROPEA

DataNascitaEstero datetime DataNascitaEstero

DisposizioniRegionali varchar(8) NRE_DisposizioniRegionali

AssistitoCognomeNome varchar(200)

AssistitoAslResidenza varchar(3)

AssistitoRegioneResidenza varchar(3)

AssistitoCodComuneResidenza varchar(6)

AssistitoProvinciaResidenza varchar(2)

AssistitoIndirizzo varchar(300)

idAssistito int IdAssistito SysPrest

idDocumentoLogico int

CTK_MedicoCF1 varchar(16)

CTK_Medico_codRegione varchar(3)

CTK_Medico_codAsl varchar(3)

CTK_Medico_codSpecializzazione varchar(1)

CTK_Reddito varchar(1)

CTK_OscuramentoDati char(1)

CTK_StatoProcesso varchar(2)

CTK_StrutturaDiPresaInCarico varchar(20)

idStrutturaEquipe_PresaInCarico_CTK int

DataOraIns datetime

DataOraUltimaOperazione datetime

Stato_ID_CTK int

FLG_GestitaManualmente int

FASCIA_REDDITO_ID int Fascia di reddito sysprest – valorizzato alla registrazione del documento di contabilizza NRE

TIPO_RILEVAZIONE_REDDITO_ID int Fascia di reddito sysprest – valorizzato alla registrazione del documento di contabilizza NRE




Tabella Documenti_Impegnative

Impegnativa PRESCRIZIONE NRE

idDocumentoEsterno int

IdAssistito int Valorizzato da prescrizione

medico varchar(50) • NULL se prescrizione da integrazione

• Nominativo medico se prescrizione MANUALE

cognomeUtente varchar(30) Da anagrafe assistito

nomeUtente varchar(30) Da anagrafe assistito

codiceSanitario varchar(16) Da anagrafe assistito

codiceFiscale varchar(16) Da anagrafe assistito

sesso varchar(1) Da anagrafe assistito

dataNascita datetime Da anagrafe assistito

comuneResidenza varchar(6) Da anagrafe assistito

ulssResidenza varchar(3) Da anagrafe assistito

ricetta varchar(16) Valorizzato da prescrizione

esenzioneTicket int NULL

importoTicket money NULL

regioneDebitrice varchar(3) Da anagrafe assistito

dataRicetta datetime Valorizzato da prescrizione

urgenza char(1) NULL

codMedico (id SysPrest) varchar(16) • NULL se prescrizione da integrazione

• Nominativo medico se prescrizione MANUALE

codEsenzione varchar(10) NULL

tipoErogazione tinyint 0

documentoChiuso tinyint NULL

flgRefertoInviato tinyint NULL

colore_id_ricetta int Valorizzato da prescrizione

VER_COD_FISCALE varchar(2) NULL

RIC_STMP_ELET varchar(1) NULL

RIC_STMP_ELET_DA_ALTRA_VER varchar(1) NULL

RIC_SUGGERITA varchar(2) Valorizzato da prescrizione IMPEGNATIVA_COD_ISTITUZIONE varchar(28) Valorizzato da prescrizione IMPEGNATIVA_NUM_PERSONALE varchar(20) Valorizzato da prescrizione IMPEGNATIVA_NUM_TESSERA varchar(20) Valorizzato da prescrizione STATO_ESTERO_UE_ID varchar(2) Valorizzato da prescrizione ID_ELABORAZIONE_ECOMEDICA int

PROGRESSIVO_IMPEGNATIVA_ECOMEDICA int

DATA_SCADENZA_TESSERA_EUROPEA datetime Valorizzato da prescrizione

PATOLOGIA_CODICE varchar(5) NULL

MedicoTipologiaId varchar(2) • NULL se prescrizione da integrazione

• tipologia medico se prescrizione MANUALE

MedicoCF varchar(16) Valorizzato da prescrizione

DataNascitaEstero datetime Valorizzato da prescrizione

NRE_TipologiaPrescrizione varchar(1) Valorizzato da prescrizione NRE_DisposizioniRegionali varchar(8) Valorizzato da prescrizione NRE_quesitoDiagnosticoDsc varchar(500) Valorizzato da prescrizione NRE_quesitoDiagnosticoCod varchar(10) Valorizzato da prescrizione




Tabella DocumentiLogici

DOCUMENTI NRE

idDocumentoLogico int

idDocumentoEsterno int

idAssistito int

UlterioreDescrizione varchar(100) “Ricetta NRE N.” + ricetta

dataRiferimento smalldatetime Valorizzato da prescrizione

MedicoAgendaCod varchar(16) • NULL se prescrizione da integrazione

• id medico se prescrizione MANUALE

MedicoAgendaDsc varchar(50) • NULL se prescrizione da

integrazione

• nominativo medico se prescrizione MANUALE

idZonaMedico varchar(1) • NULL se prescrizione da

integrazione

• zona medico se prescrizione MANUALE

idTipologiaMedico varchar(2) • NULL se prescrizione da

integrazione

• tipologia medico se prescrizione MANUALE

ESENZIONE_ID int Valorizzato da prescrizione (se CodEsenzione indicato il sistema individua id Esenzione associata altrimenti =0 “non esente”)

flgIndigenti tinyint Da modulo web

FASCIA_REDDITO_ID int Valorizzato da prescrizione

TIPO_RILEVAZIONE_REDDITO_ID int Valorizzato da prescrizione (dal tipo disposizioniregionali della fascia di reddito)

FLG_ContributoDigitalizzazione tinyint Da modulo web

NUM_CASO NULL

progetto SysPrest v.4 DOCUMENTAZIONE TECNICA · 2019-09-26 · • Operazioni pianificate (processi...

Documents

Transcript of progetto SysPrest v.4 DOCUMENTAZIONE TECNICA · 2019-09-26 · • Operazioni pianificate (processi...