Scenario ePrescription (Ricetta Dematerializzata) V3 – 2024
In Evidenza: introdotti nello scenario la gestione di nuovi campi LEA
N.B. per le indicazioni sull’attivazione degli ambienti e servizi CART consultare il paragrafo “ATTIVAZIONE AMBIENTI STAGE E PRODUZIONE” (vedi fondo pagina)
Il presente scenario rappresenta la definizione della messaggistica informatizzata atta alla gestione dell’intero ciclo prescrittivo riferito alla prescrizione e all’annullamento prescrizione.
il DM 2 novembre 2011, il Ministero dell’Economia e delle Finanze, in adempimento a quanto previsto dall’articolo 50, comma 5 bis, del D.L. 269/2003, introdotto dalla L.296/2006 e dall’art. 11 comma 16 del D.L. 78/2010, ha dato avvio al processo di dematerializzazione della ricetta medica cartacea ed a tutto il suo ciclo di vita.
In attuazione di tali normative, Regione Toscana ha predisposto tutta l’infrastruttura tecnica, atta a consentire al medico prescrittore l’invio della prescrizione elettronica al MEF, agendo direttamente sulla connettività e gli add-on software del prescrittore, sulla infrastruttura centrale e sugli standard regionali.
Il sistema di seguito illustrato rappresenta lo strumento regionale attraverso il quale i medici MMG, PLS ed i medici degli ESTAV, eseguono l’invio, delle prescrizioni ed annullamento prescrizioni in formato elettronico secondo le specifiche HL7 CDA R2, verso i sistemi telematici di Regione Toscana e, di conseguenza, del MEF.
Da un punto di vista organizzativo, la gestione centralizzata a livello regionale, utile a fornire uno strumento unico (il SAR) delegato all’archiviazione dati sulle banche dati regionali e ad interagire con i servizi ministeriali (il SAC), porta a notevoli vantaggi, tra cui:
- Accuratezza delle informazioni;
- Disponibilità immediata delle informazioni;
- Tempestività nella comunicazione fra gli attori e le organizzazioni coinvolte nel processo di cura del paziente
- Maggiore facilità di integrazione fra gli applicativi.
Il processo di prescrizione-erogazione prevede la gestione delle seguenti tipologie di prescrizioni :
- prescrizione di farmaci del Prontuario;
- prescrizione di sostanze ricavate attraverso preparazioni galeniche;
- prescrizione farmaceutica integrativa;
- prescrizione di servizi diagnostici (ad esempio strumentale, per immagini e di laboratorio);
- prescrizione per la richiesta di ricovero;
- prescrizione per visite specialistiche/ambulatoriali;
- prescrizione per la riabilitazione periodica;
- prescrizione per l’acquisizione di dispositivi/ausili/presidi medici;
- prescrizione per richiesta di trasporto;
- prescrizione per cure termali.
Per l’identificazione del paziente, ovvero per avere garanzia della sua identità attraverso i tratti anagrafici ed il codice fiscale, e per il recupero dell’id universale regionale, è necessario utilizzare l’API AnagrafeUnicaRegionale_Accesso v1 (ex RFC249).
Per il recupero delle esenzioni e delle fasce di reddito (quando in vigore secondo normativa) è invece necessario utilizzare l’API FasceDiReddito v1 (ex RFC 198).
Attori
Gli attori coinvolti negli scenari di cooperazione sono:
- Regione Toscana: è l’attore che eroga, attraverso il proprio sistema informativo, i servizi descritti in questo documento.
- Medico / Sostituto : è l’attore che fruisce del servizio erogato da Regione Toscana, svolgendo operazioni di invio ed annullamento prescrizioni verso i servizi regionali e ministeriali.
- Paziente / Delegato: soggetto della prescrizione o suo delegato
Medico Prescrittore: medico di medicina generale / Pediatra di Libera scelta, medico specialista od ospedaliero convenzionato con il SSN abilitato alla prescrizione tramite ricettario SSN/SASN.
[L’attore Medico Prescrittore implementa il ruolo (Application Role) Document Originator RCMR_AR000001]
[L’attore Regione Toscana implementa l’attore (Application Role) Document Recipient RCMR_AR000004 e provvede ad inoltrare i dati ricevuti a SAC (SOGEI) secondo le scadenze definite dalla normativa.]
Operazione – inoltro prescrizione
| Nome servizio WSDL | GestionePrescription_Service |
| Nome operazione WSDL | GestioneInvioPrescrizione |
| Nome messaggio di richiesta | RCMR_IN000002UV02_Message (RFC 123) |
| Nome messaggio di risposta | MCCI_IN000002UV01_Message (ack?) |
| Profilo di collaborazione | Richiesta/Risposta Sincrono |
Operazione – inoltro annullamento prescrizione
| Nome servizio WSDL | GestionePrescription_Service |
| Nome operazione WSDL | GestioneAnnullamentoPrescrizione |
| Nome messaggio di richiesta | RCMR_IN000023UV02_Message |
| Nome messaggio di risposta | MCCI_IN000002UV01_Message |
| Profilo di collaborazione | Richiesta/Risposta Sincrono |
Operazione – inoltro prescrizione Ricetta Bianca
| Nome servizio WSDL | GestionePrescription_Service |
| Nome operazione WSDL | GestioneInvioPrescrizioneRicettaBianca |
| Nome messaggio di richiesta | RCMR_IN000002UV02_Message |
| Nome messaggio di risposta | MCCI_IN000002UV01_Message |
| Profilo di collaborazione | Richiesta/Risposta Sincrono |
Operazione – inoltro annullamento prescrizione Ricetta Bianca
| Nome servizio WSDL | GestionePrescription_Service |
| Nome operazione WSDL | GestioneAnnullamentoPrescrizioneRicettaBianca |
| Nome messaggio di richiesta | RCMR_IN000023UV02_Message |
| Nome messaggio di risposta | MCCI_IN000002UV01_Message |
| Profilo di collaborazione | Richiesta/Risposta Sincrono |
Le operazioni sono descritte formalmente all’interno del documento WSDL (ePrescription.wsdl)
N.B. – la descrizione delle interfacce applicative usate per l’invio delle prescrizioni è contenuta nel documento WSDL RFC123_AR000005UV02.wsdl) allegato alla API StorageGeograficoEventiSanitari v1.
Per eseguire le operazioni previste il client del medico esegue l’accesso al sistema SAR ePrescriptionDM2011 al fine di inviare una prescrizione elettronica. Il sistema SAR, una volta archiviate le informazioni nelle banche dati regionali del SAR, provvede a gestire in modo asincrono rispetto alla ricezione delle prescrizioni da parte dei medici, l’interazione verso, provvede all’inoltro verso i sistemi ministeriali di accoglienza centrale (SAC).
Utilizzo della API
“Richiesta di inoltro ePrescription verso il sistema SAR, UC161.1”
L’attore principale produce un messaggio,“RCMR_IN000002UV02_Message”, contenente le informazioni previste e dettagliate nel documento di guida all’implementazione della prescrizione elettronica. (vd. allegati API)
Attraverso l’operazione “GestioneInvioPrescrizione” il messaggio giunge al sistema regionale il quale una volta ricevuto l’evento, traccia su base dati la richiesta giunta completa di tutte le sue informazioni inoltre applica al messaggio i controlli formali e di congruenza previsti per il tipo di messaggio.
In caso di esito positivo di tali controlli, il sistema procede con alla costruzione del messaggio di risposta da restituire al chiamante (MCCI_IN000002UV01_Message) contenente l’esito dell’elaborazione da parte del SAR
Successivamente (ed in modo asincrono rispetto alla ricezione del messaggio da parte dei medici) il sistema SAR effettua l’interazione verso i servizi del SAC per comunicare loro le prescrizioni presenti sul SAR e non ancora inviate verso il sistema di accoglienza centrale.
In caso di esito negativo dei controlli (messaggio di richiesta non conforme allo schema o attribuzione di valori formalmente non corretti) il servizio risponde al chiamante sempre con un messaggio MCCI_IN000002UV01_Message contenente un codice ed una descrizione dell’errore prodotta dal sistema di accoglienza regionale.
Utilizzo dei Messaggi
Il formato di ciascun messaggio è definito dagli xsd allegati: Schema/CDA_ePrescription.xsd, xsd schema che definisce la grammatica del CDA R2 di HL7;
Si tenga presente che se si sta inviando un evento di prescrizione verso il sistema ePrescriptionDPCM2008 (utilizzando il webservice opportuno, esposto ad un endpoint diverso rispetto a quello relativo al DM2011) il “ClinicalDocument” del CDA R2 di HL7 va codificato in base64 , e la rappresentazione in base64 del CDA dovrà essere usata per valorizzare l’elemento seguente del messaggio RCMR_IN000002UV02:
/RCMR_IN000002UV02/controlActProcess/subject/clinicalDocument/text
mentre se si sta inviando un evento di prescrizione verso il sistema ePrescriptionDM2011 (utilizzando il webservice opportuno, esposto ad un endpoint diverso rispetto a quello relativo al DM2008) , la rappresentazione XML del “ClinicalDocument” del CDA R2 di HL7 dovrà essere utilizzata per valorizzare il seguente elemento messaggio RCMR_IN000002UV02:
/RCMR_IN000002UV02/controlActProcess/subject/clinicalDocument/text/xmlbody
Per tutti i restanti messaggi utilizzati nello scenario di ePrescription fare riferimento agli xsd allegati alla API StorageGeograficoEventiSanitari v1
Per dettagli circa la descrizione dei messaggi usati per l’annullamento della prescrizione si faccia riferimento all’interazione n°9 “Notifica di annullamento dell’indicizzazione di un evento” definita nella API StorageGeograficoEventiSanitari v1.
E’ importante notare che la API StorageGeograficoEventiSanitari v1. contiene due interazioni di annullamento :
- la n° 6 che permette l’annullamento di documenti non ancora rilasciati per la consultazione. Alcuni iter di gestione documentale prevedono infatti fasi di consolidamento o di approvazione precedenti al rilascio del documento per la consultazione. Questa operazione permette l’annullamento del documento prima della fase di validazione pre-rilascio.
- La n° 9 (utilizzata in questo caso) che prevede la possibilità di annullare documenti già a disposizione per la consultazione, anche già firmati digitalmente.
Tale interazione prevede l’utilizzo di un messaggio la cui struttura e’ definita nello schema RCMR_IN000023UV02.xsd, con le specificità elencate nella tabella seguente. Nella tabella gli xpath degli elementi da valorizzati sono relativi a “RCMR_IN000023UV02/controlActProcess/subject”.
Il messaggio, a differenza dell’interazione di invio, non contiene il documento CDA che rappresenta la prescrizione da annullare.
L’elemento univoco che identifica la prescrizione da annullare è l’attributo /ClinicalDocument/relatedDocument/ParentDocument/id@extension che contiene l’NRE ( in caso di Ricetta Bianca l’NRBE) della prescrizione annullata.
In caso di annullamento per idClinicalDocument non sarà presente l’NRE o NRBE come indicato sopra, ma l’Id è riportato nell’attributo ClinicalDocument/id@extension come indicato nella tabella seguente.
__________
Prescrizione Elettronica – 2024
Per le specifiche Tecniche consultare la guida alla implementazione HL7 CDA R2 per documenti di tipo Prescrizione SSN/SASN e non SSN prodotti all’interno dei servizi della Regione Toscana
Prescrizione Elettronica -Profilo Gestione Ricetta Trasporti
Nell’ambito del riordino dell’organizzazione del sistema sanitario relativamente al trasporto sanitario, la Regione Toscana ha ritenuto opportuno procedere con la definizione delle competenze organizzative e l’attribuzione degli oneri del servizio di trasporto sanitario rendendo omogenee, a livello regionale, le modalità operative. A tal fine viene introdotta la prescrizione dematerializzata della ricetta dei trasporti sanitari, definita tramite messaggistica informatizzata atta alla gestione dell’intero ciclo prescrittivo. La tipologia di ricetta Trasporti si configura come prescrizione regionale, al momento, senza interazioni con il SAC.
Request_RCMR_IN000002UV02_ricetta-trasporto
le tabelle delle codifiche ammissibili relative al codesystem HL7
2.16.840.1.113883.2.9.2.90.4.99.07 Codice provvisorio per le condizioni cliniche nella ricetta Trasporti
2.16.840.1.113883.2.9.2.90.4.99.08 Codice provvisorio utilizzato per identificare il motivo/Causa del trasporto
2.16.840.1.113883.2.9.2.90.4.99.09 Codice provvisorio utilizzato per identificare al tipologia di indirizzo di una destinazione di in una ricetta Trasporti
sono reperibili tramite il repository RCT regionale e le procedure pubblicate sul portale Open Data di Regione Toscana.
Prescrizione Trasporti – Condizioni Cliniche
Prescrizione Trasporti – Motivo
Prescrizione Trasporti – Tipologia Indirizzo
ATTIVAZIONE AMBIENTI STAGE E PRODUZIONE
Gli applicativi fruitori si autenticano attraverso l’uso di credenziali TLS, fornite direttamente dal client tramite protocollo HTTPS (MTLS).
L’accesso, mediante protocollo HTTPS, prevede che sussista una relazione di trust tra applicativo fruitore ed API Gateway del CART, che viene preventivamente stabilito in fase di richiesta di adesione al servizio tramite lo scambio dei certificati. Il CART è così in grado di identificare puntualmente l’applicativo ed applicare i criteri di autorizzazione previsti per l’accesso alle API sulla base dell’identità del client fruitore.
Per poter essere abilitati all’uso dei servizi, oggetto del presente documento, è necessario avere fatto esplicita richiesta a Regione Toscana. In particolare è necessario eseguire i seguenti passi:
- Andare sul sito del CART nella sezione configurazione dei servizi https://cart.regione.toscana.it/portale/it/panoramica-cart/la-richiesta-di-adesione-ai-servizi/
- Scaricare il documento nella sezione Adesione API https
- Riempire il documento indicando per i seguenti campi i seguenti valori
| API A CUI SI RICHIEDE L’ADESIONE | Nome API |
| SOGGETTO EROGATORE: | Regione Toscana |
| REFERENTE TECNICO APPLICATIVO (*) | Omar Lorenzini |
| grupposis@regione.toscana.it |
Modalità di invio
Richiesta di Adesione a CART in ambiente stage e produzione
Per l’apertura del canale HTTPS, dipendentemente dal tipo di software, devono essere usate le modalità previste dal CART: va richiesto a (cartdesk@regione.toscana.it)
Richiedere le URL di erogazione dei servizi (specificando l’ambiente stage o produzione) inviando il modulo compilato a: cartdesk@regione.toscana.it
e per conoscenza a;
omar.lorenzini@regione.toscana.it e grupposis@regione.toscana.it
Tracciatura delle comunicazioni
I Gateway del CART, per ogni richiesta gestita introducono alcuni header http, in particolare l’header X-CART-id viene valorizzato con un identificativo unico di transazione generato dal CART che può essere salvato per eventuali verifiche diagnostiche.
Ad ogni invio l’infrastruttura CART restituisce al chiamate l’identificativo della chiamata/transazione. Tale identificativo è restituito nella variabile X-Cart-id posta nell’header HTTP.
Il valore della variabile X-Cart-id deve essere sempre salvato e custodito perché permettere di certificare l’avvenuta comunicazione del messaggio garantendone la tracciabilità all’interno dell’intero sistema. E’ importante osservare che tale identificativo viene sempre restituito dall’infrastruttura sia in caso di accettazione o meno del messaggio.
Un esempio di valore della variabile X-Cart-id è il seguente b7cad8e2-72c4-41ce-ac9a-24ff2b3f72a0.