CAPITOLATO TECNICO
CAPITOLATO TECNICO
ART. 1 – OGGETTO DELL’APPALTO
L’appalto ha per oggetto la manutenzione ordinaria, correttiva, normativa dei software in uso ai MMG/PLS in applicazione della DGRT n. 469/10 e dovrà comprendere i servizi per l’avvio,manutenzione ed help desk come segue, oltre alle nuove installazioni necessarie per nuovi MMG/PLS:
ACQUISTO MANUTENZIONI SOFTWARE secondo le indicazioni di cui all'Allegato 1. Si precisa che gli “add on” oggetto della presente procedura sono di proprietà delle Aziende Sanitarie. Gli “add on” in ambito al presente capitolato sono
• RFC 98 - RFC 123: Eventi Sanitari
• RFC 85 - RFC 87: Eventi Anagrafici
• RFC 161: Eventi ePrescription
• RFC 198: Eventi Esenzioni per reddito e ticket
• RFC 207: Eventi NRE (Numero Ricetta Elettronica)
• RFC 133: Eventi Patient Summary (Il modulo di gestione della RFC133 è installato e funzionanti manon utilizzato dai MMG.)
SERVIZI DI AVVIAMENTO PER NUOVI MMG / PLS
A corredo della fornitura dei prodotti software richiesti per nuovi MMG / PLS, il fornitore deve effettuare i servizi necessari per la loro completa messa in esercizio entro 5 gg lavorativi dalla richiesta con riferimento a:
1) nel momento in cui un medico effettua l’ordine di una nuova cartella clinica alla software house il medico compila anche un modulo contenente una dichiarazione della propria volontà ad acquisire il software ed eventualmente a cessare la cartella clinica da lui utilizzata precedentemente. Il medico dovrà anche dichiarare sotto la propria responsabilità di avere una convenzione attiva con la ASL e la tipologia di convenzione (sostituto/titolare). A seguito di tale dichiarazione la software house è autorizzata ad installare insieme alla cartella clinica anche il modulo di “Add On” oggetto della prima fase del progetto 469. Il modulo compilato dal medico verrà poi inviato dalla software house ad ESTAR che prenderà atto di tale dichiarazione e si occuperà di comunicare l’eventuale cessazione all’altro fornitore;
2) i nuovi medici MMG o PDF sono tenuti a comunicare al fornitore di cartella clinica Addon scelto la loro scelta tramite apposito modulo. Il fornitore a sua volta trasmetterà il modulo compilato al RES e DEC per quanto di competenza (aggiungere facsimile di modulo in allegato);
3) Servizi di pre-avviamento che consistono nelle attività di test e verifiche che devono essere effettuate in fase diinstallazione dei singoli prodotti software proposti: il collaudo di pre-avviamento verrà effettuato dal Fornitore di software di cartella. Tali attività non devono essere quotate per singolo medico ma considerate economicamente incluse nella fornitura complessiva.
4) Servizi di avviamento di ogni singolo medico, da erogarsi – laddove possibile – con utilizzo di sistemi di accesso remoto, per mettere il medico in condizioni di attivare l’integrazione cooperativa con Regione Toscana. Tali attività non devono essere quotate per singolo medico ma considerate economicamente incluse nella fornitura complessiva.
5) La responsabilità di garantire una formazione adeguata è a carico del fornitore del software. Le attività di formazione dovranno essere svolte PRIMA dell’effettuazione del collaudo complessivo. Per i medici utilizzatori del SW il piano formativo deve avvenire, per ogni singolo ambito (flusso/RFC), entro l’avvio dell’utilizzo del sw.L’attività del servizio di formazione non deve essere quotata per singolo medico ma considerata economicamenteinclusa nella fornitura del servizio.
6) Il processo formativo ed il collaudo tecnico dovranno essere raccolti ed inviati ad ogni singola Azienda Sanitaria secondo il Format che verrà predisposto dalle Aziende Sanitarie stesse.
Le modalità di svolgimento dei servizi suddetti devono essere dettagliate nell’offerta tecnica.
SERVIZIO DI MANUTENZIONE SOFTWARE
I servizi di manutenzione proposti devono includere la manutenzione correttiva e adeguativa alle norme di Legge, ivi compresi gli adeguamenti degli RFC che Regione Toscana può adottare nel periodo di durata del contratto.
Si intendono pertanto inclusi i servizi di manutenzione correttiva ed evolutiva a seguito di sviluppo dell'ambiente tecnologico del Progetto CSE, di cambiamento dei requisiti organizzativi, di nuovi requisiti funzionali e/o messaggistiche di integrazione.
Si intendono pertanto escluse SOLO le implementazioni di nuovi RFC non menzionati nel presente contratto. I servizi di manutenzione sopra elencati riguardano le attività oggetto della presente procedura. I servizi di manutenzione di eventuali altri moduli faranno invece riferimento ad accordi tra medico e softwarehouse.
SERVIZIO DI HELP DESK (vedi Allegato n. 2)
Da un punto di vista organizzativo, il sistema di Help Desk dovrà essere così strutturato:
Call Center e Help Desk di primo livello che, attivato da chiamata ad apposito numero telefonico o tramite fax o tramite e-mail, sarà in grado di gestire il contatto con l'utente e, oltre ad effettuare il “trouble ticketing”, effettuerà l’analisi del problema e l’eventuale risoluzione.
Attenzione: per le Ditte che hanno più di N° 100 CLIENTI (intesi come medici che utilizzano il loro software) E' RITENUTO OBBLIGATORIO disporre di un NUMERO VERDE GRATUITO per erogare il servizio di call center ed help desk.
Il servizio di Help Desk dovrà fornire la necessaria assistenza e facilitare i medici nell'utilizzo delle funzionalità di integrazione fra il software di cartella clinica e l'infrastruttura della Regione Toscana, nonché supportare ilmedico in tutte le sue attività tecnico-informatiche.
Sarà pertanto compito dell’Help Desk:
- fornire risposta a domande o richieste di informazioni riguardanti le modalità di utilizzo del software gestionale dei MMG/PLS ivi comprese le problematiche connesse (es. utilizzo delle smart card,connessioni e trasmissioni a INPS, CART, etc.);
- provvedere alla registrazione delle richieste di assistenza relative a problemi e malfunzionamenti, inserendole nel sistema di trouble ticketing, classificando il problema in funzione della gravità, allo scopodi assegnare la priorità di intervento, aprendo il relativo trouble ticket e consegnandolo al richiedente;
- prendere in carico eventuali ticket aperti dal medico via fax/mail/altro;
- provvedere alla risoluzione del problema avvalendosi anche di check list o procedure eventualmenteconcordate con la AS, con RT o con ESTAR;
- gestire, in caso di mancata risoluzione del problema, le procedure di escalation all’Help desk di secondolivello interno o di AS o di RT o di ESTAR;
- registrare la chiusura della richiesta di intervento, anche per quelli smistati ad altre strutture di servizio;
L'help desk dovrà esser reso disponibile dai fornitori nei giorni feriali, con esclusione dei giorni festiviinfrasettimanali, ALMENO dal lunedì al venerdì dalle ore 8.00 alle ore 20.00.
Fuori dall’orario sopra indicato il fornitore dovrà assicurare un servizio di segreteria telefonica, di mail e di webtracking che registrerà le richieste degli utenti, cui verrà data attenzione e risposta alla riapertura del servizio.
Di seguito le impostazioni procedurali del sistema di help desk richiesto:
- Il medico contatta sempre l'help desk messo a disposizione dalla ditta proprietaria del software che utilizza, anziché dover chiamare più numeri a seconda del problema contingente.
- Per presidiare le problematiche di natura NON tecnico-informatica ogni azienda sanitaria dovrà approntare un numero telefonico cui il medico può rivolgersi; è comunque richiesto che l'help desk del fornitore provveda a prendere in carico e gestire/smistare anche le richieste di competenza dell'azienda,in modo che il medico sia seguito da una unica struttura.
- I fornitori dei servizi di help desk avranno a disposizione anche un riferimento nell'ICT di ESTAR e
uno o più riferimenti nell'ICT della Regione Toscana, cui potersi rivolgere per malfunzionamenti con lerispettive infrastrutture/sistemi (es. riferimenti CART/FSE).
- I fornitori dei servizi di help desk avranno a disposizione anche le procedure di escalation per l'ICT diESTAR e per l'ICT della Regione Toscana. A solo titolo di esempio, si riportano possibili casi di assistenza classificati come segue:
CASI FACILMENTE GESTIBILI IN TOTO DALL'HELP DESK di 1° livello
• Problema legato al software di cartella clinica del medico
• Problema legato all'invio dei certificati di malattia via
a) problema tecnico legato all'installazione del lettore
b) problema tecnico se inviati con il software via WBS
c) problema tecnico se inviati direttamente dal sito INPS
• Problema tecnico generico (stampante, ADSL, funzionamento del computer del medico, etc.)
CASI GESTIBILI DALL'HELP DESK di 1° livello di cui va prevista possibile ESCALATION su unPUC (Punto Unico di Chiamata)
• Problema di autenticazione (CNS, sistema TS, carta, ...); in tal caso l'help desk esterno può dirottare adun help desk aziendale di 2° livello:
a) Carta deteriorata, revocata per errore, bloccata, scaduta
b) Carta non consegnata
c) Pin dimenticato o non riconosciuto
d) Mancanza generica di credenziali
e) Mancato allineamento dei dati anagrafici o di ruolo su SOGEI
• Problema legato alla mancata ricezione di dati trasmessi dalla AS al software del medico (es. referti di laboratorio); tale casistica sarà talvolta gestibile in autonomia al primo livello ma è necessaria una procedura di escalation che attivi il contatto con il settore ICT di ESTAR
• Problema legato all'invio delle prescrizioni elettroniche (E-prescription); è probabile che tale casistica sia gestibile in autonomia al primo livello fintanto che tale prescrizione non viene utilizzata in azienda per agevolare le prenotazioni e gli accessi; in tale seconda ipotesi è evidente che interviene anche il settore ICT di ESTAR;
CASI NON GESTIBILI DALL'HELP DESK di 1° livello per cui va previsto HELP DESK INTERNO alla Azienda Sanitaria
• Tutti i casi di cui al punto 4) in quanto alcuni medici potrebbero sapere che devono chiamaredirettamente la azienda sanitaria;
• Problema normativo e/o di gestione delle risorse umane;
L'elenco suddetto costituisce solo titolo di esempio in quanto tutte le procedure di escalation (siano esse verso le AS, RT, o ESTAR) dovranno essere definite al momento dell'avvio di ogni singolo ambito (flusso/RFC) e sottoscritte da tutte le parti coinvolte.
OGNI AZIENDA SANITARIA DOVRA' CONFERMARE/COMUNICARE UN REFERENTEFUNZIONALE PER QUESTO PROGETTO.
ESTAR DOVRA' CONFERMARE/COMUNICARE UN REFERENTE ICT PER QUESTO PROGETTO.
FLUSSO LOGICO DELL'HELP DESK
L’Allegato 2 “Assistenza Tecnica per softwarehouse” fornisce ulteriori dettagli sulle modalità di espletamento delservizio di help desk per i casi in cui esso coinvolge l’infrastruttura tecnologica della Regione Toscana.
SERVICE LEVEL AGREEMENT
Di seguito gli SLA minimi che il fornitore deve impegnarsi a rispettare per tutta la durata contrattuale e che saranno monitorati trimestralmente:
Problema | Tempi di presa in carico | Tempi di risoluzione | Penale |
Bloccante | 1 ora lavorativa nel 100% dei casi | 4 ore lavorative nel 90% dei casi MAX 1gg lavorativo nel 100% dei casi | si |
NON Bloccante | 8 ore lavorative nel 100% dei casi | 3gg lavorativi nel 90% dei casi MAX 10gg lavorativi nel 100% dei casi | si |
Si intende come 'orario lavorativo' quello suddetto dell'help desk (lunedì - venerdì orario 8-20).
Si intende come 'chiusura' a fini della verifica degli SLA la risoluzione o il passaggio al livello esterno competente(es. RT); si richiede tuttavia che una chiamata che ha attivato un ente terzo (es. CART) venga definitivamente chiusa SOLO al momento della effettiva notifica di chiusura proveniente dall'ente terzo, in quanto la ditta aggiudicataria della presente fornitura costituisce interfaccia unica di help desk per i propri MMG/PLS. In questosecondo caso non è prevista l’applicazione di penali ma gli eventi devono comunque essere riportati nei report statistici in resoconti separati da quelli interessati per la misurazione e verifica degli SLA.
Devono essere previste e distribuite ai medici e ai referenti delle AS, ad ESTAR e a RT le procedure di escalationche il cliente può attivare in caso di disservizi per un tempo superiore agli SLA richiesti.
SISTEMA DI TROUBLE TICKETING
Per ogni richiesta di assistenza, l’help desk di primo livello dovrà registrare ALMENO le seguenti informazioni:
• data/ora di ricezione della richiesta;
• soggetto che ha richiesto l’intervento e suoi riferimenti;
• sede lavorativa del richiedente;
• modalità di ricezione (telefono, internet, fax);
• azione avviata (risoluzione, smistamento ad altra struttura), con data e ora di avviamento dellarisoluzione;
• numero univoco del ticket;
• e, al momento della chiusura:
• data/ora di chiusura;
• livello di chiusura;
• ente di competenza (es. RT, ESTAR, AS);
• casistica del problema
MONITORAGGIO SLA PER MEDICO
Deve essere inviato per e-mail ad ogni MMG/PLS trimestralmente un report che riepiloghi:
• le chiamate da esso effettuate
• i tempi di risposta e presa in carico
• i tempi di chiusura della chiamata
• la casistica delle chiamate
• le chiamate contestate
Ogni medico deve possedere le credenziali per accedere via Web al sistema di trouble ticketing del fornitore dacui deve essere possibile:
• inserire segnalazioni in alternativa alla chiamata al call center
• contestare la chiusura di alcune sue chiamate
• scaricare i report di proprio interesse sugli SLA dei trimestri precedenti
MONITORAGGIO SLA PER AZIENDE
Deve essere inviato per e-mail ad ogni AS (e in copia all'ICT dell'ESTAR di afferenza) trimestralmente un reportche riepiloghi:
• le chiamate effettuate dai medici ad essa afferenti
• i tempi di risposta e presa in carico
• i tempi di chiusura delle chiamate
• la casistica delle chiamate
• le chiamate contestate
L'azienda e l'ICT ESTAR devono possedere le credenziali per accedere via Web al sistema di trouble ticketingdel fornitore da cui deve essere possibile:
• verificare e analizzare la storia di ogni singola chiamata
• contestare la chiusura di alcune chiamate di medici ad essa afferenti
• scaricare i report di proprio interesse sugli SLA dei trimestri precedenti
In sede di offerta sarà cura del Fornitore descrivere dettagliatamente le caratteristiche tecniche del sistema perl’erogazione del servizio di Help Desk che intende mettere a disposizione.
PENALI
In caso di NON rispetto degli SLA contrattualizzati, sarà compito delle Aziende Sanitarie effettuare ilmonitoraggio ed eventualmente effettuare l’applicazione delle penali.
Le penali saranno calcolate come segue:
Problema | Tempi di risoluzione richiesto | Xxxxxx |
Xxxxxxxxx | 0 ore lavorative nel 90% dei casi MAX 1gg lavorativo nel 100% dei casi | € 40 per ogni chiamata bloccante risolta con un tempo superiore a 1gg lavorativo |
NON Bloccante | 3gg lavorativi nel 90% dei casi MAX 10gg lavorativi nel 100% dei casi | € 20 per ogni chiamata NON bloccante risolta con un tempo superiore a 10gg lavorativi |
Mancato invio dei report | L'invio dei report trimestrali deve essere effettuato entro il 15 del mese successivo nel 100% dei casi | € 100 per ogni AS che non riceve i report entro il termine previsto |
Tempi di realizzazione
Ogni 15 giorni di ritardo rispetto alle tempistiche di cui al presente Capitolato Tecnico potranno essere applicate le seguenti ulteriori penali:
- Installazione e formazione per i medici (AD ESCLUSIONE di eventuali MMG/PLS che rifiutano diaderire al progetto): 4% dell’importo.
SERVIZI AGGIUNTIVI OPZIONALI
E’ consentito proporre e/o quotare come servizi aggiuntivi opzionali per ogni singola USL Territoriale la manutenzione e assistenza ad eventuali integrazioni e/o flussi dati già oggi esistenti (progetti/sperimentazioni in essere) che realizzano uno scambio telematico tra i MMG/PLS e RT e/o le XX.XX..
La quotazione proposta deve essere riportata in modo separato, sia in termini tecnici che economici, se necessario indicando presso quale AS è oggi attiva, con esplicitati: la tecnologia e/o il software realizzato, il servizio di help desk e manutenzione, il costo annuo per ogni medico.
ART. 2 - ADESIONE SW DA PARTE DI NUOVI MEDICI
Nel caso in cui si verificasse l’adozione della soluzione dell’applicativo SW da parte di nuovi medici dovranno essere applicate le stesse condizioni economiche e contrattuali derivanti dai risultati della presente procedura di gara.
Il Canone di manutenzione decorrerà dal primo giorno del mese successivo dall’adozione dell’applicativo SW.
ART. 3 - PENSIONAMENTO MEDICI O CAMBIO DI SOFTWARE HOUSE
Nel caso di pensionamento del medico il pagamento del servizio di manutenzione cesserà dal 1° giorno del mese successivo a quello della data dell’avvenuto pensionamento.
Nel caso in cui il medico decida di cambiare softwarehouse, il pagamento del servizio di manutenzione cesserà dal 1° giorno del mese successivo a quello della data del cambiamento della softwarehouse stessa. Il medico compilerà apposito modulo contenente le informazioni inerenti il vecchio software e il nuovo software che andrà ad utilizzare ; il modulo verrò poi trasmesso al nuovo fornitore che ne darà comunicazione ad ESTAR .
Le informative inerenti le cessazioni saranno oggetto di reciproco scambio informativo tra ESTAR e gli uffici convenzione delle ASL a cadenza trimestrale (a gennaio, aprile, luglio e ottobre di ciascun anno). ESTAR trasmetterà ai fornitori interessati, a cadenza trimestrale entro 15 giorni dalla comunicazione degli uffici convenzione delle ASL, l’elenco delle cessazioni dei medici con riferimento alle 3 aree vaste.
ART. 4 - CONDIZIONI DI FORNITURA
Per ogni fornitore software si prevede un unico ordine di acquisto che ricomprende le licenze d’uso e le manutenzioni ripartito per le 3 aree vaste in modo da consentire di contabilizzare la spesa sostenuta verso le tre ASL della Toscana (USL Nord Ovest per medici e pediatri delle ex ASL di Massa Carrara, Lucca, Pisa, Livorno eViareggio, USL Centro per i medici e pediatri delle ex ASL di Firenze, Prato, Pistoia ed Empoli e USL Sud Estper i medici e pediatri delle ex ASL di Siena, Arezzo e Grosseto);
ART. 5 - COLLAUDO NUOVE INSTALLAZIONI
Il collaudo di pre-avviamento (comma 1.1) verrà effettuato congiuntamente dal Fornitore di software di cartella clinica e dal MMG/PLS. Il collaudo del pre- avviamento è propedeutico all’avvio in produzione degli MMG/PLS.
In caso di collaudo non positivo, sarà possibile:
1. dichiarare i servizi posti a collaudo “rivedibili” in quanto, seppur non perfettamente aderenti all’attività contrattualizzata possono, entro il tempo massimo di 20 giorni solari, essere resi conformi alle prescrizioni fissate. Il collaudo sarà rinviato a data da fissare non superiore comunque a 30 giorni solari dalla prima seduta.
2. dichiarare per i servizi posti in esame “collaudo negativo” in quanto del tutto non conformi alle prescrizioni contrattuali, a seguito del quale si procederà alla risoluzione del contratto ai sensi art. 1453 del Codice Civile.
Affinché l’ordine di manutenzione possa essere attivato è necessario che il medico abbia inviato almeno unaricetta elettronica.
Le singole installazioni presso i medici si ritengono collaudate con l’invio all’Azienda Sanitaria di riferimento e ad ESTAR del formato timbrato e firmato dal medico
Allegato n. 1: Linee Guida Tecniche
Allegato n. 2: assistenza tecnica per softwarehouse
ALLEGATO 1
LINEE GUIDA TECNICHE
PROCEDURA NEGOZIATA PER MANUTENZIONE DELL’INTEGRAZIONE DEL SOFTWARE MMG/PLS IN APPLICAZIONE DELLA DGRT N. 469/10
Indice
Indice 15
Premessa 17
Contesto 18
Connettività MMG/PLS 18
Infrastruttura 18
RTRT – Rete Telematica Regionale Toscana (xxxx://xxx.xxxx.xx) 18
CART – Cooperazione Applicativa Regionale Toscana (xxxx://xxx.xxxx.xxxx.xxxxxxx.xx) 18
E_compliance (xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxx.xxx) 19
APS 20
Buste evento sanitario (RFC 98 – RFC 123) 20
Servizi Anagrafici (RFC 85 – RFC 87) 20
Patient Summary (RFC 133) 21
Esenzione e fasce di reddito (RFC 198) 22
Sanità di iniziativa (CCM - Chronic Care Model – RFC 208) 22
Contratto Nazionale MMG e PdF (RFC 194) 22
Prescrizione Elettronica (RFC 161) 23
Bilanci di salute – autismo – eccesso ponderale (RFC 181) 23
Certificazioni telematiche di malattia INPS 24
NRE (Numero Ricetta Elettronica – RFC 207) 24
Specifiche funzionali 24
Riepilogo RFC inerenti la Medicina Convenzionata 26
Tempi previsti per Add ON di nuovi fornitori (vedi capitolato speciale di appalto per maggiori dettagli) Errore. Il segnalibro non è definito.
Premessa
Nell’ambito ICT sanitario, negli ultimi anni, si è sempre più affermata a livello internazionale l’esigenza di individuare strumenti sintetici ed efficaci che possano favorire la comunicazione e la condivisione di informazioni fra i diversi attori che partecipano al processo di cura ed assistenza di un paziente; come le diverse esperienze a livello internazionale [ Belgio (SUMEHR), Inghilterra (Summary Health Record), Svezia, Finlandia (Core Patient Data Set), US (Continuity of Care Record), Canada,
… ] e le attività delle organizzazioni di standardizzazione [ IHE PCC (Integrating the HealthCare Enterprise – Patient Care Coordination) su Medical Summary (In particolare XPHR); HL7 specifiche CCD/CCR congiuntamente sviluppate da HL7 US e ASTM] dimostrano. In questo contesto la visione “paziente centrica” ha assunto sempre una maggiore rilevanza fino ad essere promossa come “must” per qualsiasi progetto di ICT sanitario.
In particolare la Regione Toscana ha attivato vari progetti finalizzati a rendere al cittadino le informazioni che riguardano la sua storia sanitaria al fine di:
🡾 Aumentare la consapevolezza
🡾 Semplificare i processi di attivazione dei servizi
🡾 Favorire la rapidità di diagnosi
🡾 Migliorare la Cura
La nuova visione, che prevede il cittadino al centro del processo di cura, ha portato alla più impellente necessità di arrivare, come processi informativi, all’attore principale che affianca il cittadino nel processo di prevenzione e di cura: gli MMG ed i PLS.
La Medicina Generale costituisce il punto di primo contatto tra sistema sanitario e cittadini, garantendo loro la possibilità di accesso ai servizi sia come singoli, in virtù del rapporto di fiducia con il medico di famiglia, sia come parte del contesto familiare e sociale di appartenenza.
Il rapporto di fiducia tra assistito e medico di medicina generale (MMG) costituisce la base per la costruzione di una relazione duratura, basata su di una comunicazione continua ed efficace, grazie alla quale ogni soggetto è in grado di condividere consapevolmente le scelte sulla propria salute e di essere parte attiva e responsabile nel processo di assistenza e cura che lo riguarda. Il medico di famiglia, infatti, affianca nel tempo i propri assistiti, affrontandone i problemi di salute in modo omnicomprensivo (dimensione fisica, psicologica, sociale, culturale ed esistenziale) e fornendo loro gli strumenti di volta in volta utili nei percorsi di vita. In questo modo, il medico di famiglia assume un ruolo di responsabilità per la salute della comunità di riferimento, ruolo che costituisce un elemento portante del modello della sanità d’iniziativa.
Contesto
Quanto riportato nei paragrafi successivi costituisce la richiesta di add-on da implementare per un collegamento telematico fra i sw di cartella clinica dei MMG/PLS e l’infrastruttura del SST.
Connettività MMG/PLS
La connettività dei MMG, o come descritto in vari atti “collegamento ADSL”, è stata finanziata dalla DGR 467 del 03.06.2009 e dalla DGR 962 del 2010.
Infrastruttura
RTRT – Rete Telematica Regionale Toscana (xxxx://xxx.xxxx.xx)
La Rete Telematica Regionale Toscana è molte cose in una.
È una Rete di Soggetti, in quanto nata, gestita e sviluppata non solo dalla Regione Toscana ma in parte dagli Enti che per primi hanno investito in tale progetto e da tutti gli altri che man mano, dal 1997, vi hanno aderito.
È un Modello Organizzativo di rapporti fra i diversi soggetti fondato sul concetto della condivisione degli obiettivi, della cooperazione e della compartecipazione, capace di produrre e sostenere processi di innovazione.
È una Infrastruttura Tecnologica di ampie capacità, diffusa su tutto il territorio regionale, interconnessa ad Internet, interoperante, in quanto rispondente agli standard promossi dal AgID “Agenzia per l'Italia Digitale” (prima DigitPA), con il Sistema Pubblico di Connettività (prima Rete Unitaria della Pubblica Amministrazione).
È soprattutto un'opportunità unica di sviluppo: per l'instaurarsi di nuovi rapporti fra le pubbliche amministrazioni e fra queste e i cittadini, le imprese e la società più in generale; per l'innovazione tecnologica ed organizzativa interna agli Enti; per la promozione delle risorse della Toscana (territorio, cultura, attività produttive, etc.); per le piccole e medie imprese nel settore dell'innovazione tecnologica; ed altro ancora.
Non è dunque una rete di soli fili, ma un intervento organico per lo sviluppo della Società dell'Informazione.
CART – Cooperazione Applicativa Regionale Toscana (xxxx://xxx.xxxxxxx.xxxx.xxxx.xxxxxxx.xx)
In attuazione della legge nr. 1 del 2004 sulla promozione dell’amministrazione elettronica e della Società dell’Informazione e della Conoscenza nel sistema Regionale. Disciplina della RTRT e del relativo programma di sviluppo dell´e-government denominato e.Toscana, la Regione Toscana di concerto e secondo gli indirizzi della Rete Telematica Regionale Toscana ha definito e attivato una infrastruttura di tecnologie e servizi per la cooperazione applicativa denominata “CART”. Maggiori dettagli
sono incusi nell’allegato A “Allegato A - 20170919-linee.guida.IPF.04.pdf”
Tale infrastruttura rende possibile e perseguibile lo sviluppo coordinato dei sistemi informativi pubblici valorizzando e condividendo il patrimonio informativo pubblico in una logica di servizio per i cittadini, le imprese e la stessa pubblica amministrazione.
L’obiettivo risulta quello della definizione di tecniche, modalità, standard tecnologici e informativi atti a garantire la circolarità delle informazioni nel rispetto dei livelli di sicurezza e riservatezza delle informazioni e con livelli di latenza nell’aggiornamento dei rispettivi patrimoni informativi prossimi allo zero.
CART definisce quindi un modello di cooperazione e interscambio in sicurezza dei dati, determina una architettura e degli standard tecnologici ed infine detta delle regole al fine di consentire a diverse applicazioni informatiche di diversi sistemi informativi allocati in enti diversi di interoperare e cooperare garantendo continuità e automatismi a supporto dei processi che coinvolgono anche i soggetti organizzativi.
CART rappresenta quindi una infrastruttura tecnologica e di servizi a disposizione di tutti i soggetti pubblici e privati che la vogliano utilizzare allo scopo della integrazione e comunicazione fra sistemi informativi diversi secondo una logica di cooperazione applicativa.
CART rappresenta una opportunità per la pubblica amministrazione di mettere a fattor comune i patrimoni informativi secondo una logica di reciproco interscambio a tutto vantaggio della semplicità della soluzione, del rispetto degli ambiti e delle prerogative di competenza, della sicurezza e titolarità nel trattamento delle informazioni.
CART rappresenta una opportunità per il mondo delle imprese di investire in settori nuovi ampliando le funzionalità dei propri prodotti o soluzioni, di poter disporre di un valore aggiunto derivante dallo stare dentro una catena di prodotti nell´ambito del quale ognuno può rappresentare valore aggiunto rispetto a tutti gli altri e può garantire un facile riuso dei prodotti stessi.
E_compliance (xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxx.xxx)
Al fine di rendere disponibili l´infrastruttura CART a tutti, è stato messo a punto un regolamento che ha per obiettivo quello di creare un contesto di concreto e utile confronto con il mondo delle imprese ICT e sostenere un processo di accreditamento di prodotti e soluzioni aderenti agli standard infrastrutturali di e.Toscana: e.Toscana Compliance.
Tale e.Toscana Compliance si riferisce alla capacità di uno specifico software applicativo di interoperare attraverso CART con altri software anch´essi accreditati e connessi applicativamente alla stessa infrastruttura.
Il regolamento regola i rapporti fra la Pubblica Amministrazione Toscana aderente ad RTRT rappresentata nello specifico dalla Regione Toscana, e le imprese ICT al fine di costituire un albo dei prodotti accreditati che andranno a costituire l´insieme delle soluzioni promosse per lo sviluppo dell´e.government in Toscana.
Un contesto nel quale sviluppare attraverso procedure trasparenti una piena collaborazione fra Pubblica Amministrazione e imprese per:
1. Costituire una comunità di imprese che partecipino in modo cooperativo alla definizione e realizzazione di soluzioni e.Toscana Compliant
2. Promuovere la definizione di standard tecnologici ed applicativi a garanzia della interoperabilità, del riuso e della pubblicità delle soluzioni
3. rafforzare una proposta Toscana sui temi dello sviluppo delle soluzioni per l´e.Government
4. di promuovere un marchio e.Toscana indice di qualità ed integrabilità delle soluzioni.
APS
L’ Access Point Subsystem (APS) non è altro che un bocchettone di accesso al mondo dei servizi telematici del SSR. Una volta che l’utente si è presentato con il certificato presente sulla CNS (TS/CNS o Carta dell’ Operatore del SST), vengono attivati tutti quei servizi a cui il soggetto è abilitato. Nel caso di un Medico convenzionato, per esempio, saranno attivati tutti i servizi (RFC) presenti su questo documento.
Buste evento sanitario (RFC 98 – RFC 123)
La busta è un elemento infrastrutturale per la veicolazione delle informazioni sanitarie, sono in essere ad oggi due distinte definizioni, per il cui utilizzo si rimanda ai paragrafi successivi, definite dalle specifiche RFC 98 e RFC 123. In ogni RFC oggetto del presente capitolato, è indicata la relativa busta di trasporto.
Servizi Anagrafici (RFC 85 – RFC 87)
La gestione dell'anagrafe delle Persone, in qualsivoglia caratterizzazione gestite dalla Regione Toscana ed Organismi afferenti ad essa, riveste un ruolo cruciale nell'ambito del sistema informativo sanitario.
In modo particolare risulta fondamentale la possibilità di identificare univocamente i soggetti a partire da profili di identificazione non completi e referenziabili successivamente attraverso un identificativo unico riconosciuto a livello regionale. Il servizio di identificazione risponde a questa esigenza mettendo a disposizione l’anagrafe regionale attraverso dei servizi che permettano di interrogare e/o censire le Persone all’interno di questo.
I servizi che sono definiti in questa RFC sono modellati secondo lo standard HL7 Versione 3, secondo le specifiche di localizzazione Italiana emesse dall’organismo HL7 Italia (xxx.xx0xxxxxx.xx).
Parallelamente ad i dati anagrafici, questo servizio, invierà la posizione corrente inerente le Esenzioni/Fasce economiche. Tale informativa dovrà essere usata per la compilazione della prescrizione in linea con le attuali normative.
Alla interrogazione massiva rappresentata da questo RFC, per l’informazione delle Esenzioni/Fasce economiche si affianca un altro RFC per l’interrogazione
puntuale. A tale proposito si rimanda al paragrafo specifico di questo documento (RFC 198).
Patient Summary (RFC 133)
La RFC 133 del Patient Summary viene inclusa nel documento perché oggetto di sviluppo nella FASE 1 del progetto. Non è oggetto del presente capitolato.
Il Patient Summary è un documento informatico sanitario che riassume la storia clinica del paziente e la situazione corrente. È creato ed aggiornato dal MMG/PLS ogni qualvolta intervengono cambiamenti da lui ritenuti rilevanti ai fini della storia del paziente. Contiene un set predefinito di dati clinici significativi per l’emergenza (emergency data set).
Il set di informazioni che compongono il Patient Summary sono state definite dal gruppo di lavoro “Contenuti”, costituito da Regione Toscana, per il progetto Carta Sanitaria Toscana (DGR n. 125 del 23/02/2009).
Il diagramma in Figura 1 mostra le componenti principali dello scenario di collaborazione realizzato al fine di archiviare i documenti “Patient Summary” prodotti dai medici attraverso il loro software gestionale, nel repository del progetto “Carta della Salute” della Regione Toscana.
Al fine di garantire ai medici un unico punto di accesso autorizzato, si utilizzeranno tre componenti dell’infrastruttura del progetto Storage Geografico (HDIS) : APS (Access Point Subsystem), AAS (Authentication Authorization System) e NIL (Notazione Indirizzamento Logico).
Non è scopo di questo documento entrare nel dettaglio del funzionamento di queste componenti, perché già ampiamente descritte nell’ambito dei documenti di riferimento del Sistema di Storage Geografico.
Lo scenario realizzato è di tipo “Publish&Subscribe” : gli eventi contenenti il Patient Summary verranno pubblicati su CART attraverso l’APS e saranno sottoscritti (e recapitati) sia da “Carta della Salute” che da una o più ASL.
Per una descrizione più dettagliata delle interazioni che avranno luogo nello scenario presentato si rimanda al documento tecnico “RFC 133”.
Esenzione e fasce di reddito (RFC 198)
Data la dinamicità di questo sistema informativo, dovuta alla possibilità di poter effettuare una autocertificazione in qualsiasi momento dell’anno, lo stesso dicasi per le dichiarazioni ISEE, è stato realizzato l’RFC 198, che si affianca all’RFC 87 per l’allineamento dei dati relativi alle Esenzioni/Fasce. Tale RFC offre la possibilità, ad un operatore del SSR preventivamente autorizzato, ad avere accesso alle interrogazioni analitiche di un singolo Cittadino.
Sanità di iniziativa (CCM - Chronic Care Model – RFC 208)
Il PSR 2008 - 2010 definisce un nuovo modello organizzativo che affida alle cure primarie il compito di programmare e coordinare gli interventi a favore dei malati cronici (DGR 467 del 03.06.09).
A livello territoriale, il modello di riferimento per l’attuazione della sanità d’iniziativa è costituito da una versione evoluta del Chronic Care Model (CCM) – definita expanded chronic care model - nella quale il singolo cittadino è calato nella più ampia dimensione della comunità e dove gli aspetti clinici, presi in carico dal medico di famiglia, sono integrati da quelli di sanità pubblica, quali la prevenzione primaria collettiva e l’attenzione ai determinanti di salute. Tale modello prevede, a livello di cure primarie, un team multiprofessionale proattivo, nel quale il medico di famiglia, nello svolgimento del proprio ruolo clinico decisionale, è affiancato da infermieri ed altre figure di supporto, nell’ambito delle rispettive professionalità.
Contratto Nazionale MMG e PdF (RFC 194)
1. Dal 1° gennaio 2009, il medico di assistenza primaria trasmette alla propria azienda sanitaria le informazioni elementari di seguito specificate:
- Richiesta di ricovero per diagnosi accertata, ipotesi diagnostica o problema (indicando se il ricovero è stato suggerito, urgente o programmato, utilizzando l’apposito spazio nella ricetta rossa);
- Accesso allo studio medico, con o senza visita medica;
- Accesso allo studio medico con attività di counselling per i soli PdF;
- Visite domiciliari;
- PPIP (anche i resoconti riferiti alle vaccinazioni antinfluenzali effettuate a soggetti anziani o affetti da patologie croniche);
- Assistenza domiciliare (ADP/ADI);
2. Le informazioni di cui al comma precedente devono:
- riferirsi al singolo caso (assistito, accesso, procedura);
- riportare la data (giorno, mese, anno) in cui il caso si è verificato;
- essere informatizzate e trasmesse con cadenza mensile entro il 10° (decimo) giorno del mese successivo.
Prescrizione Elettronica (RFC 161)
Dal momento dell’avvio a regime da parte della Regione o Provincia Autonoma di appartenenza, del progetto Tessera Sanitaria-collegamento in rete dei medici-ricetta elettronica, formalizzato dalla normativa nazionale e dagli accordi tra lo Stato e la singola regione, il medico prescrittore in rapporto di convenzione con il SSN è tenuto al puntuale rispetto degli adempimenti di cui al DPCM 26 marzo 2008 così come definito ai sensi dell’art. 13 bis, comma 5.
Si fa riferimento al Decreto MEF del 21.07.2011 (Gazzetta Ufficiale N° 183 del 8.8.2011).
Bilanci di salute – autismo – eccesso ponderale (RFC 181)
La Regione Toscana prevede fra le sue azioni la promozione di corretti stili di vita e prevenzione anche nell'età pediatrica tramite l’approccio della Sanità di iniziativa per migliorare la capacità di risposta del sistema al mutamento del contesto epidemiologico.
In questo contesto al Pediatra di Famiglia è attribuito non solamente il compito della diagnosi e cura delle malattie, ma anche quello della prevenzione. Il Progetto Salute Infanzia ha l'obiettivo di strutturare la funzione della prevenzione del Pediatra di Famiglia attraverso lo svolgimento di:
🟃 Visite filtro (definite “Bilanci di Salute”) per l'individuazione precoce dei soggetti affetti da handicap neurosensoriali e psichici;
🟃 Esecuzione di screening;
Certificazioni telematiche di malattia INPS
Il servizio di trasmissione telematica dei certificati di malattia è finalizzato a consentire l’invio, da parte dei medici del SSN, dei certificati attestanti l’assenza per malattia per i lavoratori sia del settore privato sia del settore pubblico all’INPS e, per il suo tramite, ai rispettivi datori di lavoro, secondo le modalità stabilite dalla normativa vigente.
In particolare il decreto emanato il 26 febbraio 2010 dal Ministero della salute, di concerto con il Ministero del lavoro e delle politiche sociali e con il Ministero dell’economia e delle finanze, sentito l’INPS definisce le modalità tecniche di predisposizione e invio telematico dei dati delle certificazioni di malattia al Sistema di Accoglienza Centrale (SAC), da parte dei medici del SSN.
NRE (Numero Ricetta Elettronica – RFC 207)
Il Numero Ricetta Elettronica (NRE) è elemento fondamentale per la numerazione delle prescrizioni elettroniche, avente lo stesso significato del codice a barre stampato dal Poligrafico dello Stato sulle ricette del Servizio Sanitario Nazionale.
Per prescrizione elettronica si intende un documento redatto in modalità informatica da un medico prescrittore secondo regole nazionali e regionali, riportante prescrizioni di tipo farmaceutico o specialistico a favore di un assistito dal Servizio Sanitario Nazionale.
La modalità informatica a cui si fa riferimento consiste non solo nell’utilizzo di una postazione di lavoro che permetta la compilazione del documento prescrittivo e la sua stampa, ma soprattutto nel collegamento ad un sistema regionale, in grado di assegnare un identificativo univoco a livello nazionale, appunto il Numero di Ricetta Elettronica (NRE), tramite il quale riconoscere univocamente la prescrizione nel suo ciclo di vita. L’NRE dovrà essere stampato sulla prescrizione in formato bar-code e numero in chiaro.
Specifiche funzionali
Di seguito le funzionalità interne al software che sono ritenute requisiti minimi per il corretto dialogo con i sistemi regionali:
• IDENTIFICAZIONE SU APS: poiché qualsiasi interazione con l’APS ha come requisito l’autenticazione tramite CNS, e quindi la presenza della SMART CARD del medico inserita e correttamente autenticata, il software deve consentire un login con SMART CARD e garantire che le transazioni possano avvenire solo tramite CNS;
• MESSAGGISTICA: i messaggi di errore che compaiono all’utente devono essere sempre puntuali, precisi, ed esaustivi, mai generici, e devono contenere i riferimenti all’RFC e una CODIFICA univoca dell’errore che l’utente può/deve comunicare all’help desk in caso di richiesta di assistenza;
• LOG INVII: il comportamento lato software deve garantire la visualizzazione dello storico degli invii con il relativo esito;
• PRIVACY E CONSENSI: il comportamento lato software deve garantire:
o Che tutti i dati relativi al consenso o meno di ogni singolo paziente siano registrati, come da normative vigenti e/o da progetti in corso (es. CCM), sul sistema e che esso impedisca l’invio dei dati di pazienti che non hanno registrato un esplicito consenso positivo all’invio
• ANAGRAFICA: in aggiunta alla realizzazione degli RFC come da specifiche, il comportamento lato software deve garantire:
o Che il medico riceva al login una comunicazione in merito alla presenza di variazioni anagrafiche sui suoi assistiti da allineare con l’archivio locale,
pertanto il software deve in autonomia interrogare le posizioni che risultano sul DB centrale, confrontarle con quelle locali e proporre al medico in automatico le variazioni di suo interesse, evidenziandone le differenze nei dati salienti (nome, cognome, CF, data di nascita, dati di residenza, xxxxxxxxx, dati di scelta e revoca, ...)
o Che l’anagrafica locale del medico possa memorizzare l’aggancio all’ID Universale per tutti i pazienti che hanno un abbinamento ‘a buon fine’, ma
che tale informazione non sia mai visibile, esportabile o stampabile dall’utilizzatore.
o Che il medico possa accettare o meno tali variazioni, a meno che esse non comportino un rischio di errore nell’abbinamento con l’ID Universale (es. le variazioni di CF devono essere obbligatoriamente acquisite pena la cancellazione dell’ID Universale da quel record anagrafico locale, che dovrà avvenire dopo un chiaro messaggio all’utente)
o Che il sistema sia in grado di recepire e gestire correttamente i casi di MERGE/ALIASING anagrafico
• ESENZIONE REDDITO/FASCE:
o Il comportamento lato software deve garantire una corretta gestione di tale informazione, caratterizzata da una data inizio e data fine. Ove necessario, il software deve aggiornare il dato, tramite RFC 198, al momento dell’uso (es. rilascio/stampa prescrizione), andando ad aggiornare il DB del medico convenzionato popolato periodicamente tramite RFC 87.
• PATIENT SUMMARY: in aggiunta alla realizzazione degli RFC come da specifiche, il comportamento lato software deve garantire:
o Un supporto alla compilazione per i pazienti visitati, ad esempio consentendo al medico di visionare in modo immediato i pazienti visitati in un periodo e di confermare la creazione/modifica del PASU, piuttosto che l’archiviazione del suggerimento in quanto non vi sono modifiche da apportare
o La possibilità di scegliere le informazioni da inserire in modo agevolato che possono essere distinte da paziente a paziente
o La possibilità di configurare autonomamente un template di PASU che ogni utente desidera che gli venga proposto in automatico
o Che non avvenga alcun invio automatico ma sempre successivo ad una conferma esplicita – paziente per paziente – dell’utente e/o che vi sia la possibilità di sospendere alcuni invii
o Che i dati previsti dall’RFC come strutturati, siano adeguatamente gestiti in modo strutturato dalla cartella clinica elettronica
• E-PRESCRIPTION: in aggiunta alla realizzazione degli RFC come da specifiche, il comportamento lato software deve garantire:
o Che sia gestibile il catalogo regionale delle prestazioni
o Che il sistema recuperi in automatico tutti i dati anagrafici e di esenzione al momento della compilazione della ricetta
o Che siano automatizzati i controlli previsti dalla vigente normativa (es. non più di 8 prestazioni, univocità della branca, …)
o Che l’interazione con il progetto NRE (e quindi relativa RFC) avvenga interamente in automatico senza alcuna operazione aggiuntiva dell’utente
o Che il sistema supporti tutta la gestione dei codici priorità secondo le vigenti normative, sia nazionali che regionali
Riepilogo RFC inerenti la Medicina Convenzionata
Numero RFC(*) | Dominio | Busta usata |
98 | Busta evento sanitario | - |
123 | Storage Geografico - Gestione degli Eventi Sanitari | - |
85 | Servizi Anagrafe Persone HL7v3 | - |
87 | Gestione MMG PLS HL7v3 | - |
161 | E_prescription | RFC 123 |
207 | NRE | RFC 207 |
198 | Esenzioni per reddito e ticket | |
133 | Patient Summary | RFC 98 |
- | Certificazione telematica di malattia INPS | |
Per la verifica delle linee guida si invita a visionare il materiale pubblicato su xxxx://xxxxx.xxxx.xxxxxxx.xx/ (Piattaforma per lo Sviluppo e Rilascio di Componenti Software).
ALLEGATO 2
ASSISTENZA TECNICA PER SOFTWAREHOUSE
PROCEDURA NEGOZIATA PER L’INTEGRAZIONE DEL SOFTWARE MMG/PLS IN APPLICAZIONE DELLA DGRT N. 469/10
Generalità 30
1.1 Definizioni e abbreviazioni 30
Il processo di Help-desk 31
1.2 Standardizzazione della comunicazione 32
Generalità
Questo documento descrive il processo di gestione delle chiamate ricevute dall’Help-Desk Sanità da parte dei referenti delle aziende produttrici di SW per MMG/PLS.
Definizioni e abbreviazioni
• CART = Infrastruttura di Cooperazione Applicativa di Regione Toscana.
• DBSIS = Anagrafe degli assistibili e dei medici del sistema informativo sanitario di Regione Toscana.
• HL7 = Health Level 7. Standard internazionale per la Sanità.
• NAL = Nodo Applicativo Locale. Punto fisico di accesso all’infrastruttura di cooperazione applicativa CART.
• PDD = Porta di dominio. Componente applicativo installato su NAL che consente l’accesso ai servizi esposti dal sistema regionale e anche da altri sistemi informativi di enti esterni a Regione Toscana che operano come erogatori di servizi.
• RFC = Request For Comments, documento di specifica per i servizi erogati e fruiti attraverso CART.
• MMG = Medico di Medicina Generale
• PLS = Pediatra di Libera Scelta
IL PROCESSO DI HELP-DESK
Nella figura seguente sono schematizzate le relazioni tra i diversi attori che partecipano al processo di gestione delle chiamate Help-Desk relative ai servizi per MMG/PLS: RFC 161 (e-Prescription), RFC 133 (XX.XX.), RFC 207 (NRE), RFC 198 (Esenzioni da Reddito), RFC 98, RFC123, ed RFC 85-87.
Figura 1 - Attori del process HD per Med-Conv
Tale processo è articolato nei passi seguenti:
1. il referente dell’azienda produttrice di sw per MMG/PLS si interfaccia con il 1° Liv. HD attraverso una chiamata al numero verde della Sanità (800.558080) o una mail a xxxxxxx@xxxxxxx.xxxxxxx.xx. La chiamate e le email devono essere opportunamente formulate e strutturate in modo da facilitarne l’identificazione ed il successivo instradamento.
2. Alla ricezione di una chiamata o di una email per i servizi relativi alla medicina convenzionata, il 1° Liv. apre un ticket e ne passa la competenza al 2° Liv.
Nel caso in cui i Xxxxxx, entrati in possesso dei riferimenti diretti, si interfaccino direttamente al servizio HD, il 1° Liv. deve rifiutare la richiesta invitando il medico a veicolare tale richiesta tramite il proprio fornitore.
Contestualmente all’apertura del ticket il referente dell’azienda fornitrice di sw per MMG/PLS riceverà una notifica per email dell’avvenuta apertura del ticket.
3. in seguito all’apertura del ticket, il 2° Liv avvia le operazioni di verifica della segnalazione ricevuta e di eventuale risoluzione dell’anomalia. Per lo svolgimento delle attività il 2° Liv potrà interfacciarsi con i seguenti attori:
a. il CART, per le verifiche e le attività sulla componente infrastrutturale;
b. le ASL/AO per problemi di mancata o errata trasmissione di dati verso il livello centrale;
c. lo staff-tix, ifse-tix ed hostmaster-rt per le verifiche e le attività inerenti la componente sistemistica;
d. il referente del fornitore del sw per MMG/PLS che ha effettuato la segnalazione al 1° Liv per ricevere ulteriori chiarimenti.
Durante le attività di risoluzione del ticket, qualora sia richiesta l’interazione verso uno dei 4 attori elencati, il ticket potrebbe essere posto in uno stato di sospensione, in attesa dei risultati delle verifiche o delle attività loro richieste.
4. Appena il 2° Liv conclude le attività di verifica e di risoluzione della segnalazione ricevuta, chiude il ticket. La chiusura viene notificata in automatico al referente del fornitore del sw MMG/PLS da parte del software di gestione del trouble-ticketing.
Standardizzazione della comunicazione
Al fine di rendere efficiente la gestione dei ticket relativi ai servizi per la Medicina Convenzionata, e’ necessario che le chiamate telefoniche e le email vengano formulate e strutturate secondo le modalità descritte qui di seguito.
Le email devono essere strutturate nel modo seguente :
5. OGGETTO : “[MED-CONV] richiesta di supporto per servizio in %AMBIENTE%”.
Il parametro %AMBIENTE% puo’ assumere i due seguenti valori :
a. “PRODUZIONE”
b. “PRE-PRODUZIONE”
6. nel corpo della mail devono essere presenti le seguenti informazioni :
1. RFC = “%RFC INVOCATA%”
2. CF_MED = “%CODICE FISCALE DEL MEDICO%”
3. DATA_ORA=”%TIMESTAMP DELL’INVOCAZIONE%”
4. DESCRIZIONE = “%DESCRIZIONE SINTENTICA DEL PROBLEMA%”
Si riporta un esempio di email di segnalazione:
FROM : xxx@xxx.xx
TO : HD Sanita <xxxxxxx@xxxxxxx.xxxxxxx.xx>
SUBJECT : [MED-CONV] richiesta di supporto per servizio in PRODUZIONE
RFC = 87
CF_MMG = BBBCCC….. DATA_ORA= 15/10/2011 15:21:32
DESCRIZIONE : mancata autorizzazione durante l’invocazione del servizio
Il contenuto delle chiamate telefoniche deve essere analogo a quello delle email e le informazioni ricevute devono essere riportate nel ticket aperto dal 1° Liv. :
1. identità e contatti (tel, email) del referente dell’azienda fornitrice di sw per MMG/PLS
2. al momento della segnalazione il referente dell’azienda sw per MMG/PLS deve precisare che la chiamata è relativa ai servizi della medicina convenzionata.
3. successivamente il referente deve specificare:
5. la RFC di riferimento;
6. il CF del medico che ha effettuato l’invocazione del servizio;
7. la data e l’ora in cui l’invocazione e’ avvenuta;
8. l’ambiente in cui ha operato: PRE-PRODUZIONE o PRODUZIONE il problema riscontrato