Specifiche di Implementazione Della RFC86

Transcript

1 RFC 86 Specifiche di Implementazione 12 aprile 2011 Engineering Ver 2.1 Specifiche di Implementazione Della RFC86 RFC86_specifiche_di_implmentazione_v2.1.doc.doc 1

2 RFC 86 Specifiche di Implementazione 12 aprile 2011 Engineering Ver 2.1 SMMARI 1 ASPETTI GENERALI SCP DELLA RFC INTERVALL DI VALIDITÀ E STRICIZZAZINE DEI DATI DETTAGLI DEL WSDL DELLE INTERAZINI CN RISPSTE MULTIPLE CDICI DI ERRRE CNTENUT INFRMATIV INTESTAZINE DEI MESSAGGI Transmission Wrapper Control Act Wrapper MESSAGGI DI INTERRGAZINE Query : <querybyparameter> Identificativo della query : <queryid> Sesso : < livingsubjectadministrativegender> Indirizzo di nascita: <livingsubjectbirthplaceaddress> Data di nascita: <livingsubjectbirthtime> nome e cognome: <livingsubjectname> Codici: <otheridsscopingrganization> MESSAGGI DI RICHIESTA E RISPSTA Dati anagrafici del Soggetto : <patientperson> Nome e cognome : <name> data di nascita: <birthtime> sesso: <administrativegendercode> data di morte : <deceasedtime> indirizzi: <addr> luogo di nascita: <birthplace> Recapiti: <telecom> Identificativi alternativi: <astherids> cittadinanza: <ascitizen> stato civile: <maritalstatuscode> Dati sanitari del Soggetto Azienda USL di residenza <guarantorrole> Azienda USL di assistenza e data inizio e fine assistenza <careprovision> Data Fine Assistenza SSN Tipologia dell assistenza <administrativebservation> Collegamento con il Medico <assignedprovider> SCENARI RICERCA ASSISTIBILE PER TRATTI ANAGRAFICI ACQUISITI Profilo di collaborazione ed interazioni Dati Gestiti Regole di elaborazione dei messaggi Messaggi di risposta INTERRGAZINE DATI ANAGRAFICI CMPLETI DI UN SGGETT INDIVIDUAT DA CDICE REGINALE Profilo di collaborazione ed interazioni Dati Gestiti RFC86_specifiche_di_implmentazione_v2.1.doc.doc 2

3 3.2.3 Regole di elaborazione dei messaggi Messaggi di risposta INTERRGAZINE IDENTIFICATIVI ALTERNATIVI DI UN SGGETT INDIVIDUAT DA CDICE REGINALE RICHIESTA DI CENSIMENT DI UN NUV ASSISTIBILE IN ANAGRAFE REGINALE Profilo di collaborazione ed interazioni Dati gestiti Regole di elaborazione dei messaggi Messaggi di risposta RICHIESTA DI AGGIRNAMENT DELLA PSIZINE DI UN ASSISTIBILE GIÀ REGISTRAT IN ANAGRAFE REGINALE Profilo di collaborazione ed interazioni Dati gestiti Regole di elaborazione dei messaggi Messaggi di Risposta NTIFICA DI CAMBIAMENT DATI ANAGRAFICI DI UN SGGETT GIÀ REGISTRAT IN ANAGRAFE REGINALE NTIFICA DI RICNCILIAZINE DI PSIZINI ANAGRAFICHE RICHIESTA DI CENSIMENT IN ANAGRAFE REGINALE DI UN NUV RESIDENTE NN ASSISTIT Profilo di collaborazione ed interazioni Dati gestiti Regole di elaborazione dei messaggi Messaggi di risposta RICHIESTA DI AGGIRNAMENT IN ANAGRAFE REGINALE DI UN RESIDENTE NN ASSISTIT Profilo di collaborazione ed interazioni Dati gestiti Regole di elaborazione dei messaggi Messaggi di Risposta RICHIESTA DI CHIUSURA ASSISTENZA DI ASSISTIBILE GIÀ PRESENTE IN ANAGRAFE REGINALE Profilo di collaborazione ed interazioni Dati gestiti Regole di elaborazione dei messaggi Messaggi di Risposta SCHEMA RIASSUNTIV E LINEE GUIDA ALLA CMPILAZINE DCUMENTI DI RIFERIMENT...45

4 ELENC DELLE REVISINI VERSINE DATA REVISINI /04/ inserito lo scenario di chiusura assistenza asl 2. modificato lo scenario di aggiornamento per i casi di chiusura assistenza (tipologia_assistenza={4,5}) 3. data morte obbligatoria con nullflavor

5 1 Aspetti generali Questo documento descrive gli aspetti funzionali e tecnici degli scenari definiti dalla RFC86, fornendo i dettagli relativi alla messaggistica HL7 necessaria all interazione con i servizi esposti. 1.1 Scopo della RFC La finalità della RFC 86 è il censimento/aggiornamento degli assistiti e la comunicazione delle cessazioni di assistenza sanitaria da parte di una Azienda USL. A differenza della RFC85 che consente di gestire soltanto i dati anagrafici relativi alle persone fisiche, questa RFC gestisce anche i dati amministrativi inerenti l assistenza sanitaria. Gli scenari di censimento ed aggiornamento accettano in input tutti i dati che permettono di gestire il legame tra l assistibile e l Azienda USL di iscrizione mentre nelle risposte sono presenti anche le informazioni relative alla scelta del MMG/PLS. 1.2 Intervallo di validità e storicizzazione dei dati Gli intervalli temporali associati alle informazioni presenti nei messaggi HL7, tipicamente specificati attraverso l elemento <effectivetime>, vengono gestiti ed utilizzati per la storicizzazione delle stesse. I dati per cui è prevista una gestione storicizzata sono : Gli indirizzi I recapiti I codici Il tag <effectivetime> non è in generale obbligatorio e può essere impiegato se previsto dallo schema relativo alla specifica interazione utilizzata. Nel caso in cui non venga specificato viene generato un intervallo di validità di default con data inizio pari alla data corrente e data fine pari al Di seguito un esempio : <v3:astherids> <v3:id root=" " extension="abcdef12h21l245s" assigningauthorityname="ministero delle Finanze" displayable="true"/> <v3:statuscode code="active"/> <v3:effectivetime> <v3:low value=" "/> <v3:high value=" "/> </v3:effectivetime> <v3:scopingrganization determinercode="instance" classcode="nat"> <v3:id root=" " assigningauthorityname="ministero delle Finanze"/> </v3:scopingrganization> </v3:astherids>

6 1.3 Dettagli del WSDL delle interazioni con risposte multiple Nelle interazioni che prevedono diverse possibili risposte sincrone a fronte di una stessa richiesta, avendo a disposizione un solo canale di risposta (messaggio di output della operation) si è operato come descritto qui di seguito. E stato definito un tipo di dato come choice delle possibili risposte : <xsd:complextype name="prpa_in201312uv02_in201313uv02"> <xsd:choice> <xsd:element name="prpa_in201312uv02" /> <xsd:element name="prpa_in201313uv02" /> <xsd:element name="mcci_mt000200" /> </xsd:choice> </xsd:complextype> E stato quindi definito un message con una part del tipo precedentemente definito : <message name="prpa_in201312_in201313_message"> <part name="body" type="hl7:prpa_in201312uv02_in201313uv02"/> </message> E stata infine definita una operation che accetta in input il messaggio previsto dall interazione ed in output quello definito come appena descritto. <operation name="prpa_ar201306_prpa_in201311"> <documentation>prpa_in Person Registry Add Request peration</documentation> <input message="hl7:prpa_in201311_message" /> <output message="hl7:prpa_in201312_in101313_message"/> </operation> N.B.: la definizione del wsdl descritta in questo paragrafo non permette una generazione automatica degli stub webservice attraverso gli appositi tools dei diversi linguaggi di programmazione, ma e da intendersi soltanto come una definizione formale delle interazioni supportate dai servizi esposti dall anagrafe regionale. Le interazioni devono essere gestite a livello di messaggio, così come espressamente richiesto dallo standard HL7, in modo da realizzare una completa indipendenza dal protocollo di trasporto utilizzato. Per un esempio di interazione con i servizi condotta a livello di messaggio si faccia riferimento ai frammenti di codice presenti nella sezione File del progetto RFC86, pubblicati sulla piattaforma SCAT di Regione Toscana. 1.4 Codici di Errore Nelle interazioni utilizzate per segnalare una condizione di errore applicativo o infrastrutturale, quale la MCCI_IN000002UV01, vengono utilizzati i tag <code> e <text> contenuti all interno del <detectedissueevent> per specificare rispettivamente un codice ed una descrizione dell errore.

7 Nel caso in cui lo scenario preveda anche una interazione per la trasmissione di un messaggio di rifiuto applicativo, come nel caso del censimento (Add Request Rejected), codice e descrizione della causa sono veicolati attraverso il tag <reasonf> presente all interno del <controlactprocess> del messaggio. Frammento di messaggio di ACK: <v3:acknowledgement> <v3:typecode code="ca"/> <v3:targetmessage> <!-- messaggio a cui fa riferimento l'ack --> <v3:id root=" " extension="idmsg_risp" displayable="true" assigningauthorityname="azienda"/> </v3:targetmessage> <v3:acknowledgementdetail typecode="e"> <v3:code code="interr"/> <v3:text>servizio non Disponibile</v3:text> </v3:acknowledgementdetail> </v3:acknowledgement> Frammento di messaggio di reject, contentuto nel <controlactprocess> : <v3:reasonf typecode="mitgt"> <v3:detectedissueevent moodcode="evn" classcode="alrt"> <v3:code code="codice_errore" codesystem="1.99"/> <v3:text> descrizione Errore </v3:text> </v3:detectedissueevent> </v3:reasonf>

8 2 Contenuto Informativo Nei paragrafi seguenti sono descritte le strutture dai dei messaggi impiegati negli scenari. L obiettivo di questo capitolo e descrivere le modalità in cui le informazioni trattate sono modellate secondo lo standard HL7, per la loro descrizione semantica e le modalità di valorizzazione dei campi si faccia riferimento al Cap Intestazione dei messaggi Transmission Wrapper All interno del Transmission Wrapper vengono specificate le informazioni strettamente necessarie alla conduzione della comunicazione tra sender e receiver. Di seguito un esempio di tale struttura dati <v3:prpa_in201314uv02 ITSVersion="XML_1.0" xmlns:xsi=" xmlns:v3="urn:hl7-org:v3"> <! Id del messaggio --> <v3:id assigningauthorityname="azienda USL6" root=" " extension="abcd12345" /> <! data della trasmissione --> <v3:creationtime value=" " /> <! tipologia dell interazione --> <v3:interactionid root=" " extension="prpa_in201314uv02" /> <! tipologia elaborazione --> <v3:processingcode code="p" /> <! modalità di gestione del messaggio --> <v3:processingmodecode code="t" /> <! modalità di gestione del messaggio di ack --> <v3:acceptackcode code="al" /> <v3:receiver typecode="rcv"> <v3:device classcode="dev" determinercode="instance"> <v3:id assigningauthorityname="regione Toscana" root=" " extension="2" /> </v3:device> </v3:receiver> <v3:sender typecode="snd"> <v3:device classcode="dev" determinercode="instance"> <v3:id assigningauthorityname="azienda USL6" root=" " extension="1" /> </v3:device> </v3:sender>

9 2.1.2 Control Act Wrapper All interno del Control Act Wrapper vengono specificate le informazioni necessarie alla caratterizzazione dell evento da cui e scaturito l interazione tra sender e receiver ed il conseguente invio del messaggio. Di seguito un esempio di tale struttura dati : <v3:controlactprocess classcode="cact" moodcode="evn"> <v3:id root=" " extension="evn12345" /> <v3:code code="prpa_te101314uv02" codesystem=" " codesystemname="hl7triggereventcode"> </v3:code> <v3:effectivetime value=" " /> <v3:subject typecode="subj" contextconductionind="false"> <v3:registrationrequest classcode="reg" moodcode="rq"> <v3:id root=" " extension="req1234" /> <v3:statuscode code="active" /> <v3:subject1 typecode="sbj"> [P A Y L A D]

10 2.2 Messaggi di interrogazione In questo paragrafo e descritta la struttura dati dei messaggi di interrogazione Query : <querybyparameter> Identificativo della query : <queryid> Esempio : Attributo Tipo Valore root ID ID del dominio all interno del quale è stata generata la query extension ST Identificati della query nell ambito del dominio che la ha generata <v3:queryid root=" " extension="qry-abc1234" /> Sesso : < livingsubjectadministrativegender> <v3:livingsubjectadministrativegender > <v3:value code="m" codesystem=" " codesystemname="hl7 AdministrativeGender" codesystemversion="1.0" displayname="maschio"> </v3:value> <v3:semanticstext/> </v3:livingsubjectadministrativegender > Per i codici da utilizzare per specificare il valore del campo sesso sono i seguenti si veda il paragrafo Indirizzo di nascita: <livingsubjectbirthplaceaddress> Questo tag permette di specificare l indirizzo di nascita. Per i dettagli sulla sua struttura si veda il paragrafo

11 <!--Luogo di Nascita. E' una informazione opzionale country:codifica della nazione ISTAT a 3 cifre censustract: codice ISTAT del comune di Nascita Per i nati in Italia, la nazione di nascita puo' anche essere omessa --> <v3: livingsubjectbirthplaceaddress > <v3:value> <v3:country>codice nazione</v3:country> <v3:censustract>codice istat comune</v3:censustract> </v3:value> <v3:semanticstext/> </v3: livingsubjectbirthplaceaddress > Data di nascita: <livingsubjectbirthtime> Attraverso questo tag viene specificata la data di nascita del soggetto, contenuta all interno dell attributo value dell omonimo tag. Il formato e AAAAMMGG. <!--Data di Nascita in formato stringa: aaaammgg --> <v3:livingsubjectbirthtime> <v3:value value=" "/> </v3:livingsubjectbirthtime> nome e cognome: <livingsubjectname> Questo tag contiene il nome e cognome del soggetto da ricercare. Il modello informativo permette l utilizzo di più <personname> ma l implementazione restringe questa cardinalità ad 1. E necessario quindi utilizzare un solo <personname> e nel caso di soggetti con più nomi o cognomi essi dovranno essere inseriti tutti al suo interno, nei rispettivi tag contenenti nome e cognome, come mostrato nell esempio seguente : <v3:querybyparameter> [ ] <v3:parameterlist> [ ] <v3:livingsubjectname> <v3:value> <v3:given>maria Luisa</v3:given> <v3:family>verdi</v3:family> </v3:value> <v3:semanticstext/> </v3: livingsubjectname > [ ] Codici: <otheridsscopingrganization> Questo parametro permette di interrogare l anagrafe utilizzando codici diversi dall Id Universale quali il codice fiscale o la tessera TEAM. <! Codice Fiscale --> <v3:otheridsscopingrganization> <v3:value root=" " extension="abcdef12h21l245s" assigningauthorityname="ministero delle Finanze" displayable="true"/> </v3:otheridsscopingrganization>

12 <! Tessera Team --> <v3:otheridsscopingrganization> <v3:value root=" " extension=" " assigningauthorityname="ministero della Salute" displayable="true"/> </v3:otheridsscopingrganization>

13 2.3 Messaggi di richiesta e risposta Nei paragrafi successivi si riportano i dettagli relativi alla struttura dati dei messaggi utilizzati nelle interazioni sia come richiesta per censimenti ed aggiornamenti che come risposta alle interrogazioni. I tag descritti possono indifferentemente essere presenti all interno dei messaggi di richiesta o di risposta, e l utilizzo definito in questo capitolo è da considerarsi in termini generali. Per gli utilizzi specifici si vedano i paragrafi relativi alla descrizione degli scenari (Cap. 3) Dati anagrafici del Soggetto : <patientperson> Nome e cognome : <name> Per la gestione di questo tag valgono le considerazioni descritte nel paragrafo <v3:name> <v3:family>cognome</v3:family> <v3:given>nome</v3:given> </v3:name> data di nascita: <birthtime> Attraverso questo tag viene specificata la data di nascita del soggetto, valorizzando opportunamente l attributo value. <v3:birthtime value=" "/> sesso: <administrativegendercode> Attraverso l attributo code di questo elemento viene specificato il sesso del soggetto, secondo lo schema riportato qui di seguito : Valore M F UN Descrizione Maschio Femmina Non determinabile <v3:administrativegendercode code="m" codesystem=" " codesystemname="hl7 AdministrativeGender" codesystemversion="1.0"/>

14 data di morte : <deceasedtime> Attraverso questo tag viene specificata la data di morte del soggetto, valorizzando opportunamente l attributo value. Questo dato è presente sia nelle risposte degli scenari di interrogazione sia nelle richieste degli scenari di censimento. In particolare per quest ultimo caso, le specifiche permettono di gestire le seguenti funzionalità: 1. data morte espressa Il soggetto da inviare al censimento è deceduto, quindi la data morte va valorizzata inserendo nell attributo value del tag deceasedtime la data di morte nel formato YYYYMMDD. ES: <v3:deceasedtime value=" "/> 2. data morte non espressa Valorizzando la data morte con un nullflavor di tipo NAV i servizi non apportano nessuna variazione al dato già presente in anagrafe. Questa modalità deve essere quindi utilizzata quando non sono richieste modifiche rispetto a quanto registrato in anagrafe. ES: <v3:deceasedtime nullflavor="nav"/> 3. data morte espressa con valore nullo Valorizzando la data morte con un nullflavor di tipo NI i servizi registreranno in anagrafe un valore nullo della data morte, corrispondente ad un soggetto in vita. Questa modalità deve essere quindi utilizzata quando e necessario rettificare una data morte precedentemente memorizzata in anagrafe.. ES: <v3:deceasedtime nullflavor="ni"/> In nessun caso quindi verranno accettate richieste di censimento/aggiornamento che non prevedano la presenza del tag <v3:deceasedtime/> indirizzi: <addr> Attraverso questo tag possono essere espressi i diversi indirizzi del soggetto. I dati gestiti sono : tipologia di indirizzo : residenza e domicilio nazionalità comune

15 indirizzo (via, piazza, etc.) la tipologia di indirizzo e identificata tramite l attributo use, valorizzato come segue: Valore H HP Descrizione Indirizzo di residenza Indirizzo di domicilio <!--Indirizzo di domicilio della Persona--> <v3:addr use="hp" > <v3:country>100</v3:country> <v3:censustract>015046</v3:censustract> <v3:streetaddressline>via petrella 4</v3:streetAddressLine> </v3:addr> <!--Indirizzo di residenza del Persona--> <v3:addr use="h"> <v3:country>ita</v3:country> <v3:censustract>015046</v3:censustract> <v3:streetaddressline>via petrella 4</v3:streetAddressLine> </v3:addr> luogo di nascita: <birthplace> Attraverso questo tag e possibile specificare il luogo di nascita del soggetto, composto da nazione e comune di nascita. La codifica utilizzata e quella ISTAT, a 3 cifre per la nazionalità. <v3:birthplace> <v3:addr> <v3:country>100</v3:country> <v3:censustract>59004</v3:censustract> </v3:addr> </v3:birthplace> Recapiti: <telecom> Questo tag permette la gestione di diversi tipi di recapiti associati ad un soggetto: telefono fisso (di residenza o di domicilio) telefono mobile fax Per quanto riguarda i primi due tipi di recapiti HL7 prevede gli opportuni codici, cosa che non accade per il fax e l indirizzo . Per permettere la gestione di tutti i recapiti descritti, si è deciso di operare come segue : Il suffisso tel: che precede il valore vero e proprio del recapito indica che si tratta di un recapito telefonico.

16 E inoltre possibile qualificare ulteriormente la tipologia di recapito attraverso i seguenti valori attribuiti all attributo use. Attributo H HP MC Valore Residenza Domicilio Mobile <v3:telecom use="h" value="tel:0571/367100"/> <v3:telecom use="hp value="tel: "/> <v3:telecom use="mc value="tel: "/> Usando il suffisso fax: si specifica un fax, mente con mailto: un indirizzo . In questi casi l attributo use non è utilizzato. Nel caso in cui si tenti di specificare uno dei recapiti elencati senza utilizzare una delle regole appena descritte, si otterrà in risposta un messaggio di errore contenente i dettagli della causa. N.B.: I recapiti devono risultare delle URL formalmente valide, dato che vengono espresse in tale forma. Quindi, ad esempio, non possono contenere spazi Identificativi alternativi: <astherids> Per mezzo di questo tag vengono gestiti gli identificativi alternativi del Soggetto, quali codice fiscale, tessera sanitaria e TEAM, codice sanitario, etc. Il codice viene specificato nell attributo extension del tag <id>, mentre nell attributo root viene riportato l oid che permette di individuare la tipologia di codice. Di seguito gli ID da utilizzare : Tipo Valore TESSERA TEAM CDICE FISCALE CDICE SANITARI Attraverso l attributo code del tag <statuscode> si stabilisce la validità del codice specificato : attivo, sospeso, non attivo. Deve essere inoltre indicato un riferimento all ente che ha emesso il codice e che ne ha la responsabilità, ad esempio il MEF nel caso del codice fiscale. A questo scopo si utilizza il tag extension dell tag <id> contenuto all interno di <scopingrganization>. Un esempio di gestione del codice fiscale : <v3:astherids classcode="pat"> <v3:id root=" " extension="cmnvrg77h21l245s" assigningauthorityname="ministero delle Finanze" displayable="true"/> <v3:statuscode code="active"/> <v3:scopingrganization determinercode="instance" classcode="nat"> <v3:id root=" " assigningauthorityname="ministero delle Finanze"/> </v3:scopingrganization> </v3:astherids>

17 Nel caso del codice fiscale, attraverso l attributo code del tag <statuscode> si determina se il codice specificato e o meno certificato MEF: - Il caso code= active corrisponde ad un codice fiscale certificato MEF. - Il caso code= pending corrisponde ad un codice fiscale non ancora sottoposto alla procedura di certificazione MEF (è uno stato transitorio). - Il caso code= cancelled corrisponde ad un codice fiscale NN certificato MEF, quindi non valido rispetto all ente che ne ha la responsabilità. Questa valorizzazione del codice fiscale è valida anche per le risposte alle interrogazioni da parte dei servizi regionali cittadinanza: <ascitizen> Permette di specificare la cittadinanza del soggetto specificando il codice ISTAT a 3 cifre (ES: Italia=100) all interno del tag <code>. <ascitizen> <politicalnation> <code>100</code> <name>italia</name> </politicalnation> </ascitizen> stato civile: <maritalstatuscode> <maritalstatuscode code="s" codesystem=" "/> il tag <maritalstatuscode> permette di esprimere lo stato civile del soggetto, valorizzando opportunamente l attributo code secondo i valori indicati nella tabella seguente. L ID del codesystem deve essere : Esempio : Codice S M L D W Descrizione CELIBE/NUBILE CNIUGAT/A SEPARAT/A DIVRZIAT/A VEDV/A

18 2.3.2 Dati sanitari del Soggetto Azienda USL di residenza <guarantorrole> L Azienda USL di residenza dell assistito è quella territorialmente competente rispetto al comune o circoscrizione di residenza della persona. La classe che identifica la Azienda USL di residenza è il Ruolo di Guarantor. Es: <guarantorrole classcode="guar"> <guarantorrganization classcode="rg" determinercode="instance"> <!-- CDICE AZIENDA USL di Residenza --> <id root=" " extension="090105" assigningauthorityname="ministero della Salute"/> </guarantorrganization> </guarantorrole> Si precisa che tale struttura e utilizzata solo nei messaggi di risposta(censimenti ed interrogazioni) poiche la ASL di residenza e automaticamente ricavata dall indirizzo di residenza Azienda USL di assistenza e data inizio e fine assistenza <careprovision> L Azienda USL di Assistenza rappresenta la Azienda USL a cui il paziente ha affidato il proprio mandato assistenziale, può coincidere o meno con l Azienda USL di residenza ed è l ente designato all invio delle informazioni tramite questa RFC. Le classi di riferimento per indicare il mandato assistenziale di base e la classe per indicare la Azienda USL di Assistenza sono contenute nel CMET A_PrincipalCareProvision. L intervallo di validità dell assistenza e specificato attraverso gli elementi low e high del tag effectivetime. Esempio: <careprovision classcode="pcpr" moodcode="evn"> <code codesystem=" " code="genrl"> </code> <v3:effectivetime> <v3:low value=" "/> <v3:high value=" "/> </v3:effectivetime> <performer typecode="prf"> <assignedprovider classcode="assigned"> <representedrganization> <!-- id dell'azienda USL di assistenza --> <id root=" " extension="030302" assigningauthorityname="ministero della Salute"/> </representedrganization> </assignedprovider </performer> </careprovision> Data Fine Assistenza SSN La data fine Assistenza SSN è modellata attraverso la classe CoverageParty secondo l esempio riportato qui di seguito : <v3:coveredpartyf typecode="cv"> <v3:coveragerecord moodcode="evn" classcode="cv"> <v3:effectivetime> <v3:high value=" "/> </v3:effectivetime> </v3:coveragerecord> </v3:coveredpartyf>

19 Tipologia dell assistenza <administrativebservation> Questo elemento specifica la tipologia dell assistibile ed e obbligatorio sia per gli scenari di censimento che per quelli di aggiornamento. E inoltre presente all interno dei messaggi di risposta di tutti gli scenari. La classe HL7 di riferimento e Administrativebservation. I valori ammessi, rilevati dall attributo code del tag <code>, sono i seguenti : Codice Descrizione 1 assistibile non a termine 2 assistibile a termine per straniero con permesso di soggiorno 3 assistibile a termine per motivo diverso da straniero con permesso di soggiorno 4 deceduto 5 irreperibile o emigrato ES: <administrativebservation classcode="bs" moodcode="evn"> <code code="2" codesystem=" " /> <value xsi:type="cd" code="2.1 " codesystem=" " /> </administrativebservation> N.B.: Nel caso in cui vengano specificati i valori 2 o 3 e necessario che la data fine assistenza SSN venga valorizzata con una data < 31/12/ Collegamento con il Medico <assignedprovider> Nell ottica di restituire tramite la RFC86 un quadro completo dell assistenza sanitaria di un soggetto afferente a Regione Toscana, nelle interazioni di risposta che lo prevedono (scenari di interrogazione, scenari di aggiornamento soggetti già esistenti in anagrafe) vengono restituiti l identificativo regionale e la tipologia del medico associato ad un dato assistito, nonché l intervallo temporale di validità del collegamento con lo stesso medico. La classi di riferimento sono contenute nel CMET A_PrincipalCareProvision, e vanno ad arricchire le informazioni relative alla usl di assistenza contenute nello stesso CMET. In particolare, le informazioni riguardo la tipologia del medico, la asl del medico e l intervallo temporale di validità dell associazione con il paziente sono contenute nel <perfomer> associato al careprovision del CMET A_PrincipalCareProvision.

20 ES: <careprovision classcode="pcpr" moodcode="evn"> <code codesystem=" " code="genrl"> </code> <!-- intervallo temporale collegamento con la asl di assistenza --> <effectivetime> <low value=" " /> <high value=" " /> </effectivetime> <performer typecode="prf"> <assignedprovider classcode="assigned"> <!-- identificativo regionale del medico --> <id extension="reg " root=" " /> <!-- tipologia del medico --> <code code="mmg" codesystem=" " codesystemname="dizionario classificazione ruoli medici HL7.it" /> <!-- intervallo temporale collegamento con il medico --> <effectivetime> <low value=" " /> <high value=" " /> </effectivetime> <assignedperson classcode="psn" determinercode="instance"> <name /> <ashealthcareprovider classcode="prv" /> <asrolether classcode="rl"> <id /> <!-- identificativo NSIS dell' AZIENDA USL del medico --> <scopingrganization classcode="state" determinercode="instance"> <id extension="090110" root=" " /> </scopingrganization> </asrolether> </assignedperson> <representedrganization> <!-- identificativo NSIS dell'azienda USL di assistenza --> <id root=" " extension="030302" assigningauthorityname="ministero della Salute" /> </representedrganization> </assignedprovider> </performer> </careprovision>

21 3 Scenari 3.1 Ricerca Assistibile per tratti anagrafici acquisiti Questo scenario permette di eseguire una ricerca sull Anagrafe Regionale specificando un certo insieme di tratti anagrafici Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRPA_AR PRFIL DI CLLABRAZINE richiesta/risposta sincrona RICHIESTA Patient Registry Find Candidates Query(PRPA_IN201305UV02) RISPSTA Request Accepted Patient Registry Find Candidates Query Response (PRPA_IN201306UV02) RISPSTA Request Rejected RISPSTA DI ERRRE Accept Ack (MCCI_IN000002UV01) Dati Gestiti ID UNIVERSALE INPUT/ UTPUT RICHIEST/ PZINALE NME I/ R CGNME I/ R SESS I/ R DATA NASCITA I/ R DATA MRTE CDICE FISCALE CDICE SANITARI TESSERA TEAM STAT CIVILE CITTADINANZA CMUNE NASCITA STAT NASCITA IND. RESIDENZA CMUNE RESIDENZA I/ R (in alternativa ai tratti)

22 STAT RESIDENZA IND. DMICILI CMUNE DMICILI STAT DMICILI AZIENDA USL RESIDENZA AZIENDA USL ASSISTENZA DATA INIZI ASSISTENZA DATA FINE ASSISTENZA DATA FINE ASSISTENZA SSN TIPLGIA MEDIC ID UNIVERSALE MEDIC DATA INIZI CLL. MEDIC DATA FINE CLL. MEDIC ASL DEL MEDIC TIPLGIA ASSISTENZA Regole di elaborazione dei messaggi La ricerca viene effettuata considerando i tratti forniti come relativi ad un soggetto unico, quindi : I tratti (compreso il codice fiscale) sono considerati in AND logico La ricerca è effettuata per corrispondenza esatta e non sono accettati operatori quali LIKE o wildcards come * o %. I parametri hanno una cardinalità massima pari ad Messaggi di risposta Lo scenario prevede due possibili risposte, veicolate dalle due seguenti interazione HL7: 1. PRPA_IN201306UV02: nel caso in cui la richiesta sia andata a buon fine. La risposta contiene tutti i soggetti che soddisfano i parametri di ricerca specificati. 2. MCCI_IN00002UV01 : nel caso in cui la richiesta non possa essere presa in carico, per cause legate agli sia aspetti infrastrutturali/sistemistici che applicativi, come la mancanza dei dati minimi previsti, il motivo e specificato nel tag <acknowledgementdetail> (si veda il par. 1.3).

23 3.2 Interrogazione dati anagrafici completi di un soggetto individuato da codice regionale Lo scenario permette il recupero dei dati anagrafici relativi ad un soggetto censito in anagrafe regionale attraverso l identificativo regionale (id universale) Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRPA_AR PRFIL DI CLLABRAZINE richiesta/risposta sincrona RICHIESTA Patient Registry Get Demographics Query(PRPA_IN201307UV02) RISPSTA Request Accepted Patient Registry Get Demographics Query Response (PRPA_IN201308UV02) RISPSTA Request Rejected RISPSTA DI ERRRE Accept Ack (MCCI_IN000002UV01) Dati Gestiti INPUT/ UTPUT RICHIEST/ PZINALE ID UNIVERSALE I/ R NME CGNME SESS DATA NASCITA DATA MRTE CDICE FISCALE CDICE SANITARI TESSERA TEAM STAT CIVILE CITTADINANZA CMUNE NASCITA STAT NASCITA IND. RESIDENZA CMUNE RESIDENZA STAT RESIDENZA IND. DMICILI

24 CMUNE DMICILI STAT DMICILI AZIENDA USL RESIDENZA AZIENDA USL ASSISTENZA DATA INIZI ASSISTENZA DATA FINE ASSISTENZA TIPLGIA MEDIC ID UNIVERSALE MEDIC DATA INIZI CLL. MEDIC DATA FINE CLL. MEDIC ASL DEL MEDIC DATA FINE ASSISTENZA SSN TIPLGIA ASSISTENZA Regole di elaborazione dei messaggi Il tag <patientidentifier>, che contiene l id universale del soggetto da ricercare, ha una cardinalità massima (prevista dal modello HL7 di riferimento) maggiore di 1. Nel caso in cui siano quindi presenti più identificativi, si procederà all individuazione dell id universale all interno della lista (identificato attraverso il suo ID) e si procederà alla ricerca utilizzando tale codice. Se fossero presenti più id universali verrebbe utilizzato il primo in ordine di occorrenza nel messaggio Messaggi di risposta Lo scenario prevede due possibili risposte, veicolate dalle due seguenti interazione HL7: 1. PRPA_IN201308UV02: nel caso in cui la richiesta sia andata a buon fine. La risposta contiene tutti i soggetti che soddisfano i parametri di ricerca specificati. 2. MCCI_IN00002UV01 : nel caso in cui la richiesta non possa essere presa in carico, per cause legate agli sia aspetti infrastrutturali/sistemistici che applicativi, come la mancanza dei dati minimi previsti, il motivo e specificato nel tag <acknowledgementdetail> (si veda il par. 1.3).

25 3.3 Interrogazione identificativi alternativi di un soggetto individuato da codice regionale Il servizio relativo a questo scenario è sospeso.

26 3.4 Richiesta di censimento di un nuovo Assistibile in anagrafe regionale Questo scenario permette il censimento di un soggetto nell anagrafe regionale e l ottenimento del relativo identificativo univoco (Id Universale) Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRFIL DI CLLABRAZINE RICHIESTA RISPSTA Request Accepted RISPSTA Request Rejected RISPSTA DI ERRRE PRPA_AR richiesta/risposta sincrona Patient Registry Add Request(PRPA_IN201311UV02) Patient Registry Add Request Accepted(PRPA_IN201312UV02) Patient Registry Add Request Rejected(PRPA_IN201313UV02) Accept Ack (MCCI_IN000002UV01) Dati gestiti ID UNIVERSALE INPUT/ UTPUT RICHIEST/ PZINALE NME I/ R CGNME I/ R SESS I/ R DATA NASCITA I/ R DATA MRTE I/ R (vedi par ) R CDICE FISCALE I/ ( se età>30gg) CITTADINANZA I/ TESSERA TEAM I/ CDICE SANITARI I/ STAT CIVILE I/ CMUNE NASCITA I/ R STAT NASCITA I/ R IND. RESIDENZA I/ R

27 CMUNE RESIDENZA I/ R STAT RESIDENZA I/ R IND. DMICILI I/ CMUNE DMICILI I/ R STAT DMICILI I/ R (deve essere ITALIA) AZIENDA USL RESIDENZA ASL ricavata a partire dal codice del comune di residenza AZIENDA USL ASSISTENZA ASL che invia l evento DATA INIZI ASSISTENZA I/ R DATA FINE ASSISTENZA I/ R DATA FINE ASSISTENZA SSN I/ R TIPLGIA ASSISTENZA I/ R Regole di elaborazione dei messaggi Lo scenario permette il censimento di un assistito in anagrafe regionale e la generazione del relativo identificativo univoco (Id Universale). La condizione necessaria affinchè la richiesta venga accettata è che il mittente del messaggio corrisponda ad un ente che risulti abilitato ad effettuare tale operazione (Azienda USL) e che il suo Livello di Certificazione risulti adeguato. Il livello di certificazione è individuato a partire dalle informazioni sul mittente del messaggio presenti nell attributo root del tag <sender>, contenuto nel Transmission Wrapper (si veda par ). Lo stato di domicilio, per gli assistitibili, puo essere soltanto l Italia, per cui nel caso in cui venga specificato uno stato diverso il messaggio viene scartato con una Reject. La richiesta di censimento viene accettata ed elaborata solo nel caso in cui superi la fase di validazione articolata nei seguenti passi : 1. verifica della presenza dei dati minimi previsti. 2. verifica della validità sintattica del codice fiscale (compresa omocodia), se presente 3. verifica della corrispondenza delle codifiche utilizzate (Comuni, Nazioni, etc) con quelle presenti nel catalogo regionale. 4. verifica attraverso il codice fiscale che il soggetto non sia già presente nell anagrafe Messaggi di risposta Lo scenario prevede due possibili risposte ed un messaggio di errore, veicolate dalle seguenti interazioni HL7: 1. PRPA_IN201312UV02 (Response Accepted): nel caso in cui la richiesta sia andata a buon fine. La risposta conterrà tutti i dati accettati dall anagrafe regionale e l id universale. 2. PRPA_IN201313UV02 (Response Rejected): con questo messaggio si gestisce il rifiuto della richiesta di censimento, per motivi legati al contenuto informativo delle richiesta (dati minimi mancanti, codice fiscale formalmente non corretto, livello di certificazione del mittente insufficiente per il censimento di un soggetto,..)

28 In questo caso, utilizzando il tag <DetectedIussueEvent>, verrà specificato il motivo del rifiuto con un opportuno codice e descrizione. Si veda a tale proposito il paragrafo MCCI_IN00002UV01 : nel caso in cui la richiesta non possa essere presa in carico, per cause legate agli sia aspetti infrastrutturali/sistemistici che applicativi, come la mancanza dei dati minimi previsti, il motivo e specificato nel tag <acknowledgementdetail> (si veda il par. 1.3).

29 3.5 Richiesta di aggiornamento della posizione di un Assistibile già registrato in anagrafe regionale Lo scenario prevede la possibilità di modificare/aggiornare informazioni relative ad un dato soggetto identificato in anagrafe regionale dal proprio id universale. Questo scenario può essere utilizzato anche per effettuare la cessazione dell assistenza da parte di una ASL, specificando un opportuno motivo di chiusura (ad esempio in caso di decesso) Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRFIL DI CLLABRAZINE RICHIESTA RISPSTA Request Accepted RISPSTA Request Rejected RISPSTA DI ERRRE PRPA_AR richiesta/risposta sincrona Patient Registry Revise Request(PRPA_IN201314UV02) Patient Registry Revise Request Accepted(PRPA_IN201315UV02) Patient Registry Revise Request Rejected(PRPA_IN201316UV02) Accept Ack (MCCI_IN000002UV01) Dati gestiti INPUT/ UTPUT RICHIEST/ PZINALE ID UNIVERSALE I/ R NME I/ R CGNME I/ R SESS I/ R DATA NASCITA I/ R DATA MRTE I/ R (vedi par ) R CDICE FISCALE I/ ( se età>30gg) CDICE SANITARI I/ TESSERA TEAM I/ STAT_CIVILE I/

30 CITTADINANZA I/ CMUNE NASCITA I/ R STAT NASCITA I/ R IND. RESIDENZA I/ R CMUNE RESIDENZA I/ R STAT RESIDENZA I/ R IND. DMICILI I/ CMUNE DMICILI I/ R STAT DMICILI I/ R DATA INIZI ASSISTENZA I/ R DATA FINE ASSISTENZA I/ R TIPLGIA MEDIC ID UNIVERSALE MEDIC DATA INIZI CLL. MEDIC DATA FINE CLL. MEDIC ASL DEL MEDIC DATA FINE ASSISTENZA SSN I/ R TIPLGIA ASSISTENZA I/ R Regole di elaborazione dei messaggi Le regole di gestione dei messaggi sono del tutto analoghe a quelle implementate per lo scenario 4 eccetto che per la particolarità descritta qui di seguito. Nel caso in cui lo scenario venga utilizzato per effettuare una chiusura di assistenza, ovvero il campo TIPLGIAASSISTENZA sia 4 o 5, le uniche informazioni prese in considerazione nel messaggio di richiesta sono le seguenti: - stato del mandato assistenziale valorizzato a CMPLETED : tale dato è mappato a livello hl7 tramite il CareProvision.statusCode della classe CareProvision - TIPLGIA ASSISTENZA = 4 (deceduto) o 5 (irreperibile o emigrato) - Data morte valorizzata nel caso di TIPLGIA ASSISTENZA = 4 - Intervallo temporale del mandato assistenziale (DATA INIZI ASSISTENZA e DATA FINE ASSISTENZA) - DATA_FINE_ASSISTENZA_SSN L esito della richiesta di aggiornamento sarà quella di chiudere il collegamento con la asl di assistenza secondo le informazioni della richiesta descritte sopra lasciando inalterate le restanti informazioni anagrafiche/sanitarie associate all assistibile in esame Messaggi di Risposta Lo scenario prevede due possibili risposte oltre ad un messaggio di errore, veicolate dalle seguenti interazione HL7: 1. PRPA_IN201315UV02(Response Accepted): nel caso in cui la richiesta sia andata a buon fine. La risposta conterrà tutti i dati accettati dall anagrafe regionale e l id universale.

31 2. PRPA_IN201316UV02 (Response Rejected): con questo messaggio si gestisce il rifiuto della richiesta di censimento, per motivi legati al contenuto informativo delle richiesta ( codice fiscale formalmente non corretto, incoerenza tra la tipologia di assistenza e le date di fine assistenza, incoerenza tra la data morte e le date di fine assistenza, etc..) In questo caso, utilizzando il tag <DetectedIussueEvent>, verrà specificato il motivo del rifiuto con un opportuno codice e descrizione. Si veda a tale proposito il paragrafo MCCI_IN00002UV01 : nel caso in cui la richiesta non possa essere presa in carico, per cause legate agli sia aspetti infrastrutturali/sistemistici che applicativi, come la mancanza dei dati minimi previsti, il motivo e specificato nel tag <acknowledgementdetail> (si veda il par. 1.3).

32 3.6 Notifica di cambiamento dati anagrafici di un soggetto già registrato in anagrafe regionale Il servizio relativo a questo scenario è sospeso.

33 3.7 Notifica di riconciliazione di posizioni anagrafiche Il servizio relativo a questo scenario è sospeso.

34 3.8 Richiesta di censimento in anagrafe regionale di un nuovo residente non assistito Questo scenario permette il censimento di un soggetto residente nel territorio di competenza di una ASL ma non iscritto ad essa e che non abbia espresso la scelta di un MMG/PLS Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRFIL DI CLLABRAZINE RICHIESTA RISPSTA Request Accepted RISPSTA Request Rejected RISPSTA DI ERRRE PRPA_AR201306_residenti richiesta/risposta sincrona Patient Registry Add Request(PRPA_IN201311UV02) Patient Registry Add Request Accepted(PRPA_IN201312UV02) Patient Registry Add Request Rejected(PRPA_IN201313UV02) Accept Ack (MCCI_IN000002UV01) Dati gestiti ID UNIVERSALE INPUT/ UTPUT RICHIEST/ PZINALE NME I/ R CGNME I/ R SESS I/ R DATA NASCITA I/ R DATA MRTE I/ R (vedi par ) R CDICE FISCALE I/ ( se età>30gg) CDICE SANITARI I/ TESSERA TEAM I/ STAT_CIVILE I/ CITTADINANZA I/ CMUNE NASCITA I/ R STAT NASCITA I/ R IND. RESIDENZA I/ R

35 CMUNE RESIDENZA I/ R STAT RESIDENZA I/ R IND. DMICILI I/ CMUNE DMICILI I/ R STAT DMICILI I/ R AZIENDA USL RESIDENZA TIPLGIA ASSISTENZA I/ Regole di elaborazione dei messaggi Lo scenario permette il censimento di un residente non assistito (senza scelta del medico) in anagrafe regionale e la generazione del relativo identificativo univoco (Id Universale). La condizione necessaria affinchè la richiesta venga accettata è che il mittente del messaggio corrisponda ad un ente che risulti abilitato ad effettuare tale operazione (Azienda USL), ovvero che il suo Livello di Certificazione sia adeguato. Il livello di certificazione è individuato a partire dalle informazioni sul mittente del messaggio presenti nell attributo root del tag <sender>, contenuto nel Transmission Wrapper (si veda par ). Lo stato di domicilio, per gli assistitibili, puo essere soltanto l Italia, per cui nel caso in cui venga specificato uno stato diverso il messaggio viene scartato con una Reject. La richiesta di censimento viene accettata ed elaborata solo nel caso in cui superi la fase di validazione articolata nei seguenti passi : 1. verifica della presenza dei dati minimi previsti. 2. verifica della validità sintattica del codice fiscale (compresa omocodia), se presente 3. verifica della corrispondenza delle codifiche utilizzate (Comuni, Nazioni, etc) con quelle presenti nel catalogo regionale. 4. verifica attraverso il codice fiscale che il soggetto non sia già presente nell anagrafe Messaggi di risposta Lo scenario prevede due possibili risposte oltre ad un messaggio di errore, veicolate dalle seguenti interazione HL7: 1. PRPA_IN201312UV02 (Response Accepted): nel caso in cui la richiesta sia andata a buon fine La risposta conterrà tutti i dati accettati dall anagrafe regionale e l id universale. 2. PRPA_IN201313UV02 (Response Rejected): con questo messaggio si gestisce il rifiuto della richiesta di censimento, per motivi legati al contenuto informativo delle richiesta (dati minimi mancanti, codice fiscale formalmente non corretto, livello di certificazione del mittente insufficiente per il censimento di un soggetto,..) In questo caso, utilizzando il tag <DetectedIussueEvent>, verrà specificato il motivo del rifiuto con un opportuno codice e descrizione. Si veda a tale proposito il paragrafo MCCI_IN00002UV01 : nel caso in cui la richiesta non possa essere presa in carico, per cause legate agli sia aspetti infrastrutturali/sistemistici che applicativi, come la mancanza dei dati minimi previsti, il motivo e specificato nel tag <acknowledgementdetail> (si veda il par. 1.3).

36 3.9 Richiesta di aggiornamento in anagrafe regionale di un residente non assistito Lo scenario prevede la possibilità di modificare/aggiornare informazioni relative ad un dato soggetto identificato in anagrafe regionale dal proprio id universale, residente non assistito e senza effettuare la scelta del MMG/PLS. Questo scenario puo essere utilizzato dalle ASL per comunicare l inizio o la fine della residenza di un cittadino non assistito nel proprio territorio di competenza, utilizzando opportunamente il campo tipologia assistenza Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRFIL DI CLLABRAZINE RICHIESTA RISPSTA Request Accepted RISPSTA Request Rejected RISPSTA DI ERRRE PRPA_AR201306_residenti richiesta/risposta sincrona Patient Registry Revise Request(PRPA_IN201314UV02) Patient Registry Revise Request Accepted(PRPA_IN201315UV02) Patient Registry Revise Request Rejected(PRPA_IN201316UV02) Accept Ack (MCCI_IN000002UV01) Dati gestiti INPUT/ UTPUT RICHIEST/ PZINALE ID UNIVERSALE I/ R NME I/ R CGNME I/ R SESS I/ R DATA NASCITA I/ R DATA MRTE I/ R (vedi par ) R CDICE FISCALE I/ ( se età>30gg) CDICE SANITARI I/

37 TESSERA TEAM I/ STAT_CIVILE I/ CITTADINANZA I/ CMUNE NASCITA I/ R STAT NASCITA I/ R IND. RESIDENZA I/ R CMUNE RESIDENZA I/ R STAT RESIDENZA I/ R IND. DMICILI I/ CMUNE DMICILI I/ R STAT DMICILI I/ R AZIENDA USL RESIDENZA TIPLGIA ASSISTENZA I/ Regole di elaborazione dei messaggi Le regole di gestione dei messaggi sono del tutto analoghe a quelle implementate per lo scenario Messaggi di Risposta Lo scenario prevede due possibili risposte oltre ad un messaggio di errore, veicolate dalle seguenti interazioni HL7: 1. PRPA_IN201315UV02(Response Accepted): nel caso in cui la richiesta sia andata a buon fine La risposta conterrà tutti i dati accettati dall anagrafe regionale e l id universale. 2. PRPA_IN201316UV02 (Response Rejected): con questo messaggio si gestisce il rifiuto della richiesta di censimento, per motivi legati al contenuto informativo delle richiesta (dati minimi mancanti, codice fiscale formalmente non corretto, livello di certificazione del mittente insufficiente per il censimento di un soggetto,..). In questo caso, utilizzando il tag <DetectedIussueEvent>, verrà specificato il motivo del rifiuto con un opportuno codice e descrizione. Si veda a tale proposito il paragrafo MCCI_IN00002UV01 : nel caso in cui la richiesta non possa essere presa in carico, per cause legate agli sia aspetti infrastrutturali/sistemistici che applicativi, come la mancanza dei dati minimi previsti, il motivo e specificato nel tag <acknowledgementdetail> (si veda il par. 1.3).

38 3.10 Richiesta di Chiusura Assistenza di assistibile già presente in anagrafe regionale. Lo scenario di Chiusura dell assistenza permette di specificare la data di termine dell assistenza da parte della ASL ed il relativo motivo. L evento di chiusura dell assistenza viene gestito dallo stesso servizio che prende in carico gli eventi di aggiornamento (scenario 5), dato che la discriminazione delle due tipologie di evento puo avvenire sulla base del campo statuscode della classe CareProvision, secondo il seguente schema : CareProvision.statusCode = CMPLETED -> Chiusura Assistenza ASL ; CareProvision.statusCode = ACTIVE o non presente -> Aggiornamento Dati dell Assistito ; Profilo di collaborazione ed interazioni I dettagli relativi al servizio che implementa lo scenario sono qui riassunti : SERVIZI PRFIL DI CLLABRAZINE RICHIESTA RISPSTA Request Accepted RISPSTA Request Rejected RISPSTA DI ERRRE PRPA_AR richiesta/risposta sincrona Patient Registry Revise Request(PRPA_IN201314UV02) Patient Registry Revise Request Accepted(PRPA_IN201315UV02) Patient Registry Revise Request Rejected(PRPA_IN201316UV02) Accept Ack (MCCI_IN000002UV01)

39 Dati gestiti INPUT/ UTPUT RICHIEST/ PZINALE ID UNIVERSALE I/ R se TIPLGIA_ASSISTENZA=4 DATA MRTE allora R, altrimenti. CDICE FISCALE CDICE SANITARI TESSERA TEAM STAT_CIVILE CITTADINANZA CMUNE NASCITA STAT NASCITA IND. RESIDENZA CMUNE RESIDENZA STAT RESIDENZA IND. DMICILI CMUNE DMICILI STAT DMICILI AZIENDA USL RESIDENZA ASL ricavata a partire dal codice del comune di residenza AZIENDA USL ASSISTENZA ASL che invia l evento DATA INIZI ASSISTENZA I/ R DATA FINE ASSISTENZA I/ R DATA FINE ASSISTENZA SSN I/ R TIPLGIA ASSISTENZA I/ R Ammessi i valori 4 (deceduto) e 5 (Irreperibile o emigrato) Regole di elaborazione dei messaggi La richiesta di censimento viene accettata ed elaborata solo nel caso in cui superi la fase di validazione articolata nei seguenti passi : 1. verifica dati minimi previsti dallo scenario 2. verifica esistenza assistibile in anagrafe regionale associato all id universale passato in richiesta 3. verifica coerenza informazioni della richiesta (opportuna valorizzazione del CareProvision.statusCode, del codice motivazione fine assistenza, intervallo temporale dell assistenza da chiudere ed eventuale data di morte.) La fine dell elaborazione dell evento sancirà la chiusura del collegamento con la asl di assistenza per l assistibile in esame.