e.Toscana Compliance 
Request for Comments: 78
Del: 2008-03-07
Categoria: Applicativa
Destinatari: Regione Toscana, Aziende Sanitarie, Fornitori Soluzioni ICT per la Sanit

	Servizi per la condivisione dei referti

=>
Modifiche
=======
(1) Aggiunto targetNamespace="http://www.regione.toscana.it/rct/" allo schema XSD

Premessa
=======

RIMUOVERE NELLA VERSIONE FINALE
Versione: Draft Standard for Trial Use

Legenda: Le parti evidenziate da approfondire sono racchiuse fra i simboli => <= (da rimuovere nella versione finale).

<RIMUOVERE NELLA VERSIONE FINALE>

Open Issues
(1) E appropriato il nome dello schema (reportContainer.xsd) ?
(2) Verificare ed estendere la bibliografia

Closed Issues
a) Restringere la condivisione ai soli referti di laboratorio o tenerlo pi generico ?
a.i Servizio Generico
b) Modalit di cooperazione
b.i Messaggio senza risposta
c) Lobbligatoriet di informazioni strutturate viene indicata a livello di RFC o di schema (prevedendo un tag dato strutturato) ?
c.i A livello di RFC utilizzando un unico tag non opzionale con molteplicit N
d) Codifica delle informazioni
d.i base64Binary
e) Approfondire se lattributo mimeType potrebbe dare adito ad incomprensioni dato che lelemento rappresentazione  sempre codificato come binarybase64. Rinominare ? 
e.i OK attributo mimeType.
<==

Indice
======
1	Contesto di riferimento
2	Obiettivi
3	Analisi
4	Prodotti attesi
5	Bibliografia

1 Contesto di riferimento
==========================
Linformatizzazione dei Medici di Medicina Generale e la diffusione di cartelle cliniche informatizzate sono realt oramai consolidate nella nostra Regione, cos come la diffusione allinterno delle aziende sanitarie di soluzioni informatiche per la gestione dei principali processi diagnostici e clinici. Tuttavia, nella realt quotidiana, tranne rare eccezioni, la condivisione di informazioni e documenti risulta essere ancora limitato, con evidenti carenze in termini di efficacia ed efficienza dellintero processo.
I medici informatizzati, per esempio, sono spesso ancora costretti ad aggiornare manualmente le informazioni relative agli accertamenti eseguiti dai propri assistiti: un meccanismo di aggiornamento automatico della propria cartella clinica sarebbe pertanto positivamente valutato sia in termini di risparmio di tempo che di riduzione degli errori di inserimento.
I cittadini percepiscono oramai la risorsa tempo come uno dei parametri prioritari nella valutazione dellefficienza dei servizi pubblici fruiti, come la sempre maggiore diffusione di servizi quali la prenotazione on line, o linvio domiciliare dei referti, dimostra. La condivisione informatica dei referti soddisfa perci questa aspettativa, rendendo inoltre la gestione del processo di distribuzione pi efficace e meno costosa anche per le aziende sanitarie.

I limiti indicati in precedenza diverranno ancora pi critici nel momento in cui, coerentemente con le attuali tendenze in termini di politica socio-sanitaria, si attueranno soluzioni organizzative che presumono una sempre pi forte cooperazione fra territorio ed organizzazioni deputate alla gestione della fase acuta della cura. 

Tenuto conto di questi elementi viene perci proposto un servizio che, tramite linfrastruttura di cooperazione della Regione Toscana, possa favorire la condivisione dei referti.

Il servizio assume che lorganizzazione inviante (e.g. ASL) e quella ricevente (e.g. Sistema informatizzato per la gestione delle Cartelle Cliniche dei MMG) condividano lo stesso dominio anagrafico (i.e. appartengano allo stesso affinity domain) e le anagrafiche di riferimento (e.g. nomenclatori prestazioni).

Sono al di fuori dello scopo di questo RFC la definizione delle modalit di condivisione di tali informazioni.

Non rientra fra le finalit di questo servizio la condivisione dei documenti clinico sanitari, od informazioni ad essi correlati, per la costituzione di un Electronic Healthcare Record (EHR) / FAscicolo Sanitario Personale (FASP).

Sebbene i proponenti di questo servizio siano pienamente a conoscenza dei risultati dei tavoli di lavoro istituzionali (Mattoni SSN, Infrastruttura di Base Sanit Elettronica) e/o di standardizzazione internazionale (HL7, IHE) in questo ambito, valutando lattuale capacit dei sistemi informativi presenti sul territorio,  stato deciso di adottare soluzioni pi conservative per favorire una maggiore diffusione del servizio proposto.

Ulteriori integrazioni potranno essere fatte in futuro per ladozione di soluzioni tecnologiche pi consone rispetto alle esigenze informative e di interoperabilit (e.g. refertazione strutturata basata su CDA HL7 R2 level 2, level 3), soprattutto nellottica di creazione di un FASP.

Il servizio proposto si basa su un modello di tipo push che sfrutta il servizio standard della Porta di Dominio denominato Integration Manager (vedi per dettagli lRFC Interfacce Porta di Dominio, ed i documenti Architettura CART ed SDK CART su http://www.cart.rete.toscana.it/).

2 Obiettivi
=============
Scopo del servizio  quello di consentire la condivisione dei referti  attraverso un meccanismo di invio diretto - fra lorganizzazione fruitore del servizio (e.g. Laboratorio di Analisi ) e possibili erogatori (e.g. Rete di Medici di Medicina Generale).

Non rientra fra le finalit di questo servizio la condivisione dei documenti clinico sanitari, od informazioni ad essi correlati, per la costituzione di un Electronic Healthcare Record (EHR) / FAscicolo Sanitario Personale (FASP).

Il servizio proposto  neutro rispetto al formato standard utilizzato per la condivisione delle informazioni. Gli accordi fra lorganizzazione che invia il referto ed il ricevente definiranno ulteriori vincoli sulle informazioni scambiate.

Ladozione di tale servizio ha immediati benefici per il cittadino in termini di semplificazione delle procedure e riduzione dei disagi; per loperatore sanitario in termini di accuratezza delle informazioni diagnostiche e cliniche e facilit di accesso alle stesse; per le aziende sanitarie in termini di efficacia ed efficienza (minor tempo, minor costi) dei servizi proposti.

In sintesi, i vantaggi sono :
* riduzione dei disagi per il cittadino assistito
* accuratezza delle informazioni / riduzione degli errori di trascrizione
* tempestivit nella comunicazione fra gli attori e le organizzazioni coinvolte nel processo di cura del paziente
* riduzione dei costi di gestione dei referti per le aziende sanitarie
* maggiore facilit di integrazione fra gli applicativi 


3 Analisi
==========
3.1 Attori coinvolti
==================
* Sistema Informativo Locale (SIL) deputato alla spedizione del referto (Produttore) [SIL_Prod]
* Sistema Informativo Locale che riceve il referto (Consumatore) [SIL_Cons]

3.2 Sequenza eventi
==================
La realizzazione del servizio di invio del referto  realizzata attraverso una interazione di tipo oneway (nella terminologia SPCoop messaggio senza replica). Tale scambio  realizzato usufruendo del Web Service di Integrazione (Integration Manager) messo a disposizione dalle porte di dominio.

(1) Il Sistema Informativo che detiene il referto (SIL_Prod) invia una copia al sistema destinatario (SIL_Cons).

(2) Il sistema informativo destinatario (SIL_Cons) consulta il servizio IntegrationManager per verificare la presenza di eventuali referti a lui destinati e  se del caso  li recupera

Esempio di interazione con la PDD attraverso il servizio di Integration Manager sono descritti nel documento SDK-CART pubblicato nel sito della Regione Toscana.

3.2.1 Invio del referto
================================

Il Sistema Informativo che detiene il referto (SIL_Prod) invia una copia al sistema destinatario (SIL_Cons) utilizzando le operazioni messe a disposizione dal servizio Standard IntegrationManager (e.g. attraverso loperazione invocaPortadelegata).

Il fruitore invoca tante volte il servizio per quanti sono i possibili destinatari (SIL_Cons) del referto, e per quanti sono i possibili referti da inviare: i.e. una invocazione = un solo destinatario, un solo referto.

SIL_Prod riceve, per ogni referto inviato, conferma della presa in carico del messaggio da parte dellinfrastruttura; non deve invece essere attesa nessuna informazione di ritorno da parte del sistema ricevente (esempio errori nel processamento del messaggio da parte del SIL_Cons).

Il referto pubblicato, per il successivo recupero da parte del destinatario, viene veicolato attraverso il messaggio definito dallo schema reportContainer.xsd.

Il messaggio pu includere pi forme di rappresentazione del contenuto informativo del referto, in forma strutturata (HL7 2.5, HL7 2.5 XML, HL7 CDA R2) o non strutturata (PDF, p7m)

----------------------------------------------------------------------------------------------------------------------
NB 1: Per consentire al sistema ricevente di poter associare il referto ricevuto alle entit a cui esso fa riferimento (e.g. al paziente), il messaggio DEVE contenere ALMENO una rappresentazione del referto in forma strutturata (HL7 2.5, HL7 2.5 XML, HL7 CDA R2)
----------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------
NB 2: La firma pcks7  prevista SOLO per i documenti pdf
----------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------
NB 3: Sebbene sia consentito dallo standard HL7, per evitare un incapsulemento ricorsivo delle informazioni allinterno del messaggio, si sconsiglia fortemente lincapsulamento di:
	- documenti pdf o CDA allinterno del segmento OBX: OBX-2 Value Type diverso da ED;
	- documenti pdf nellelemento NonXMLBody del CDA: body solo di tipo structuredBody

----------------------------------------------------------------------------------------------------------------------

Il servizio assume che lorganizzazione inviante (e.g. ASL) e quella ricevente (e.g. Sistema informatizzato per la gestione delle Cartelle Cliniche dei MMG) abbiano:
(1) concordato a priori i formati con cui intendono scambiarsi il referto
(2) condiviso lo stesso dominio anagrafico (i.e. appartengano allo stesso affinity domain) e le anagrafiche di riferimento (e.g. nomenclatori prestazioni).

E al di fuori dello scopo di questo RFC la definizione delle modalit di condivisione di tali informazioni.

Per dettagli sullo standard referenziati (HL7, pdf,..)  si faccia riferimento alla documentazione ufficiale pubblicata.

3.2.2 Fruizione (recupero) dei referti
=====================================

Il sistema informativo a cui il referto  destinato consulta il servizio IntegrationManager (e.g. attraverso loperazione getAllMessagesID) per verificare la presenza di eventuali referti da ricevere e  se del caso  ne richiede una copia (e.g. attraverso loperazione getMessage).

Il messaggio contenente il referto  definito dallo schema reportContainer.xsd ed include una rappresentazione in forma strutturata del referto (vedi sezione precedente per dettagli) per consentire al sistema ricevente una corretta associazione del referto alle entit di interesse a cui esso si riferisce (e.g. al paziente), ed eventualmente consentire lestrazione di dati analitici.
Il messaggio pu opzionalmente includere una rappresentazione in formato PDF (eventualmente firmato pcks#7) del referto stesso.

Non  richiesto al SIL_Cons di informare il SIL_Prod circa lavvenuta ricezione, o di notificare eventuali errori di processamento.

3.3  Schemi utilizzati: reportContainer.xsd
======================================
Lo schema XML che definisce il messaggio utilizzato per veicolare il contenuto informativo del referto  il seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2006 sp2 U (http://www.altova.com) by g.cangioli (SAGO) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" targetNamespace="http://www.regione.toscana.it/rct/">
	<xs:element name="referto">
		<xs:annotation>
			<xs:documentation>Include una o pi rappresentazioni - in formato strutturato o non - del referto. referto pu essere un referto generico, di diagnostica per immagini, di laboratorio o di pronto soccorso. tipo di referto gestito  determinabile dall'attributo code.
							</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="rappresentazione" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Include una delle possibili rappresentazioni del referto.
DEVE essere inclusa almeno una forma di tipo strutturata (basata sullo standard HL7) per consentire al ricevente la corretta associazione fra referto e relativa entit correlata (e.g. paziente, ordine, prestazione,....) 
La rappresentazione usata - determinabile dall'attributo mimeType -  codificata base64Binary.
Correlazione fra mimeType e formato:
"text/plain" 										==> HL7 Versione 2.5 separato da pipe (e.g. messaggio ORU^R01) 
"text/xml"   										==> HL7 Versione 2.5 in rappresentazione XML (e.g. messaggio ORU^R01) 
"application/x-hl7-cda-level-one"	==> HL7 CDA Release 2 
"application/pdf"								==> PDF
"application/x-pkcs7-mime"				==> PDF firmato  PKCS7
					</xs:documentation>
					</xs:annotation>
					<xs:complexType>
						<xs:simpleContent>
							<xs:extension base="xs:base64Binary">
								<xs:attribute name="mimeType" use="required">
									<xs:simpleType>
										<xs:restriction base="xs:string">
											<xs:enumeration value="text/plain"/>
											<xs:enumeration value="text/xml"/>
											<xs:enumeration value="application/x-hl7-cda-level-one"/>
											<xs:enumeration value="application/pdf"/>
											<xs:enumeration value="application/x-pkcs7-mime"/>
										</xs:restriction>
									</xs:simpleType>
								</xs:attribute>
							</xs:extension>
						</xs:simpleContent>
					</xs:complexType>
				</xs:element>
			</xs:sequence>
			<xs:attribute name="codeSystem" use="required" fixed="2.16.840.1.113883.6.1"/>
			<xs:attribute name="code" use="required">
				<xs:annotation>
					<xs:documentation>
Referto di Radiologia - 18748-4
Referto Generico - 47045-0
Referto di Laboratorio - 11502-2
Referto Pronto Soccorso 34878-9 
					</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="xs:string">
						<xs:enumeration value="18748-4"/>
						<xs:enumeration value="47045-0"/>
						<xs:enumeration value="11502-2"/>
						<xs:enumeration value="34878-9"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:attribute>
			<xs:attribute name="codeSystemName" fixed="LOINC"/>
			<xs:attribute name="codeSystemVersion" default="2.19"/>
			<xs:attribute name="displayName" type="xs:string">
				<xs:annotation>
					<xs:documentation>
	Referto di Radiologia - 18748-4
	Referto Generico - 47045-0
	Referto di Laboratorio - 11502-2
	Referto Pronto Soccorso 34878-9 
					</xs:documentation>
				</xs:annotation>
			</xs:attribute>
		</xs:complexType>
	</xs:element>
</xs:schema>

3.4 Esempi
==================
Qui di seguito un esempio di come un referto di laboratorio rappresentato dal messaggio HL7 v 2.5 ORU (Observation Report Unsolicited), riportato qui di seguito, possa essere veicolato congiuntamente alla sua rappresentazione pdf firmata pcks7.

MSH|^~\&|LAB-1^^|LAB-1^^|1^^|^^|200704231719||ORU^R01|20070423171928573|P^|2.3
PID||^|00388482^^^&&^^&&|PRVPRV06M70D403W^|PROVA^PROVA^||20060830|F|^||^^^^^|||||||||||||||||||
PV1||O|003^^||||019968^BGNRRT54T02D403V^||||||||||||30095966^^|||||||||||||||||||||||||20070423152700||||||||
OBR|0|^^^|1-30095926-20070423152500^LAB-1^^|Servizi Laboratorio^Servizi Laboratorio^^^^|||20070423152500||^&|^^||^||20070423152500|&|^||||||20070423152500|^|ServiziLaboratorio0||&|&||&||||&&||||||||||
OBX|1|CE|1@2@2@sg^GLUCOSIO (sg)^|R-20070423152500|11^|mg/dL^|65 - 110||||F||||^||
OBX|2|CE|1@5@5@sg^AMILASI PANCREATICA (sg)^|R-20070423152500|55^|U/L^|13 - 53||||F||||^||
OBR|1|^^^|1-30095926-20070423152500^LAB-1^^|Servizi Laboratorio^Servizi Laboratorio^^^^|||20070423152500||^&|^^||^||20070423152500|&|^||||||20070423152500|^|ServiziLaboratorio0||&|&||&||||&&||||||||||
OBX|1|CE|1@4@4@sg^ALDOLASI (sg)^|R-20070423152500|24^|U/L^|0.5 - 7.6||||F||||^||

<?xml version="1.0" encoding="UTF-8"?>
<referto xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi: xsi:schemaLocation="http://www.regione.toscana.it/rct/reportContainer.xsd" code="11502-2" displayName="Referto di Laboratorio" codeSystemVersion="2.19" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" >
	<rappresentazione mimeType="text/plain">TVNIfF5+XCZ8TEFCLTFeXnxMQUItMV5efDFeXnxeXnwyMDA3MDQyMzE3MTl8fE9SVV5SMDF8MjAwMjMxNzE5Mjg1NzN8UF58Mi4zDQpQSUR8fF58MDAzODg0ODJeXl4mJl5eJiZ8UFJWUFJWMDZNUFJPVkFeUFJPVkFefHwyMDA2MDgzMHxGfF58fF5eXl5efHx8fHx8fHx8fHx8fHx8fA0KUFYxfHxPfDAwM15efHx8fDAxOTk2OF5CR05SUlQ1NFQwMkQ0MDNWXnx8fHx8fHx8fHx8OTY2Xl58fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8MjAwNzA0MjMxNTI3MDB8fHx8fHx8KT0JSfDB8Xl5efDEtMzAwOTU5MjYtMjAwNzA0MjMxNTI1MDBeTEFCLTFeXnxTZXJ2aXppIExhyYXRvcmlvXlNlcnZpemkgTGFib3JhdG9yaW9eXl5efHx8MjAwNzA0MjMxNTI1MDB8fF4mfF5eMDQyMzE1MjUwMHwmfF58fHx8fHwyMDA3MDQyMzE1MjUwMHxefFNlcnZpemlMYWJvb3JpbzB8fCZ8Jnx8Jnx8fHwmJnx8fHx8fHx8fHwNCk9CWHwxfENFfDFAMkAyQHNnXkdMVUNPlPIChzZylefFItMjAwNzA0MjMxNTI1MDB8MTFefG1nL2RMXnw2NSAtIDExMHx8fHxGfHx8fF58KT0JYfDJ8Q0V8MUA1QDVAc2deQU1JTEFTSSBQQU5DUkVBVElDQSAoc2cpXnxSLTIwMDcwNDIzXnxVL0xefDEzIC0gNTN8fHx8Rnx8fHxefHwNCk9CUnwxfF5eXnwxLTMwMDk1OTI2xXl58U2Vydml6aSBMYWJvcmF0b3Jpb15TZXJ2aXppIExhYm9yeXnx8fDIwMDcwNDIzMTUyNTAwfHxeJnxeXnx8Xnx8MjAwNzA0MjMxNTI1MDB8JnxefHx8MjAwNzA0MjMxNTI1MDB8XnxTZXJ2aXppTGFib3JhdG9yaW8wfHwmfCZ8fCZ8fHx8JiZ8fHx8fHx8DQpPQlh8MXxDRXwxQDRANEBzZ15BTERPTEFTSSAoc2cpXnxSLTIwMDcwNDIzMTUyXnxVL0xefDAuNSAtIDcuNnx8fHxGfHx8fF58fA0K</rappresentazione>
<rappresentazione mimeType="application/x-pkcs7-mime">MBpw3wYJKiBIIPcNCgEHAqAacNAwGnDMAgEBMQswCQYFKw4DAhoFIDAaacYGCSogSCD3DQoBBwGgBBppdSVQREYtMS40DQol4OHi4w0KNCAwIG9iag0KPDwvRmlsdGVyIC9GbGF0ZURlY29kZQ0K 
	<!-- OMISSIS ....-->
</rappresentazione>
</referto>


4 Prodotti attesi
==================
Per realizzare la comunicazione fare riferimento al WSDL relativo al servizio IntegrationManager allegato alla documentazione dellSDK-CART 

5 Bibliografia
============

[1] Regione Toscana RFC 22 Interfacce Porta di Dominio http://web.rete.toscana.it/eCompliance/portale/mostraRFC?idRev=42&idRfc=22 
[2] http://www.cart.rete.toscana.it 
[2.a] SDK-CART (http://www.cart.rete.toscana.it/portal//files/cart/docs/01/34/78/file_13478.rar )
[2.b] Manuale duso CART
[2.c] Architettura CART
[3] http://www.hl7.org
[4] http://www.hl7italia.org
[5] http://hl7.ifc.cnr.it/hl7/
[6] HL7 Recommendations: Using XML as Supplementary Messaging Syntax for HL7 Version 2.3.1
[7] Specifiche PDF http://www.adobe.com/devnet/pdf/pdf_reference.html
[8] http://www.cnipa.gov.it/site/_contentfiles/00127900/127910_CR%2024_2000.pdf


