e.Toscana Compliance 
Request for Comments: 136 rev 2
Del: 01/10/2009 
Categoria: Applicativo
Destinatari: Regione Toscana, Aziende Sanitarie

Carta Sanitaria - Trasmissione referti di radiologia (RIS) secondo lo standard HL7 - CDA Rel 2.0


Indice
================================================================================
1. Contesto di riferimento ed obiettivi
2. Analisi 
2.1. Casi d'uso
2.1.1. Ev01 - Produzione di un referto di radiologia
2.1.2. Ev02 - Produzione di un addendum/revisione ad un referto precedentemente emesso 
2.2. Formato del documento XML CDA
2.2.1. Referto di radiologia
2.2.2. Addendum / revisione ad un referto precedentemente emesso
2.3 Completamento / correzione di informazioni
3. Prodotti attesi	
3.1. WSDL dei servizi 
4. Bibliografia
5. Storico Versioni


1. Contesto di riferimento ed obiettivi
================================================================================
Il contesto in cui si colloca questo documento RFC e' quello della trasmissione dei referti di radiologia prodotti dai sistemi RIS delle Aziende verso il sistema informativo sanitario di Regione Toscana. Nelle successive versioni sar possibile descrivere l'intero processo organizzativo che conduce alla generazione del referto a partire dalla richiesta.

Obiettivo del documento e', in particolare, la definizione del formato adottato per la trasmissione del referto di radiologia, basato sulle specifiche dello standard HL7 - CDA Rel 2.0, scelto come riferimento per la conservazione e lo scambio tra gli attori del dominio sanitario di documenti clinici/amministrativi.
Allo stato attuale  stata effettuata la scelta di inserire il referto come oggetto non strutturato (nonXMLbody) all'interno del documento CDA XML; in prospettiva si prevede, come anche auspicato dalle specifiche tecniche che emergono a livello nazionale, di definire un documento CDA interamente strutturato, in cui quindi anche i dati di refertazione vengono inseriti in un XMLbody, adottando il meccanismo di firma XML (XML signature), preferibilmente nella sua versione 'detached'. In tal caso si prevede di gestire l'operazione di visualizzazione (o 'renderizzazione') del referto mediante l'utilizzo di fogli di stile eventualmente referenziabili. Nella parte di XMLbody saranno inoltre gestite tutte le informazioni cliniche che al momento non trovano spazio nella parte di Header.
Il documento ha inoltre l'obiettivo di descrivere le modalita' con cui le Aziende devono trasmettere i referti di radiologia attraverso l'infrastruttura di cooperazione applicativa di Regione Toscana (CART) per alimentare la Carta Sanitaria Elettronica e consentire anche il monitoraggio delle prestazioni di radiologia erogate dalle Aziende toscane.
Questo comprende la descrizione di scenari e casi d'uso, della tipologia di informazioni scambiate e degli eventi al verificarsi dei quali tali informazioni sono generate e trasmesse.
 

2. Analisi 
================================================================================
In questa sezione e' riportata la descrizione dei casi d'uso rilevanti che caratterizzano il dominio di radiologia e che sono attivati al verificarsi dei seguenti eventi:
 - Ev01 - Produzione di un referto di radiologia
 - Ev02 - Produzione di un addendum/revisione ad un referto precedentemente emesso

Al verificarsi di un evento, l'informazione ad esso relativa deve essere inviata dai sistemi RIS delle ASL/ASO (attore primario del caso d'uso) a Regione Toscana (attore secondario del caso d'uso). 

L'invio della informazione avviene attraverso messaggi XML definiti secondo il formato della busta 'Dati comuni eventi sanitari' [7] al cui interno viene trasferito, come contenuto applicativo, il documento HL7 CDA. 

Il documento HL7 CDA utilizzato per la trasmissione dei referti di radiologia comprende due sezioni:

 - una 'intestazione' che contiene le informazioni strutturate che consentono l'identificazione dell'assistito e del medico che ha firmato il referto. Esso contiene inoltre informazioni che ne consentono l'indicizzazione con criteri diversi, quali ad esempio la data di refertazione e la struttura in cui e' stato prodotto il referto. Nel caso di documento interamente strutturato dovranno essere previste le ulteriori informazioni necessarie per la corretta riproduzione del referto, garantendone l'autoconsistenza. L'intestazione pu inoltre contenere l'indicazione della prestazione eseguita, e se ne raccomanda la valorizzazione secondo il Catalogo unico delle prestazioni radiologiche di Regione Toscana approvato con Decreto Dirigenziale n.3509 del 22/07/2009.
 
 - un 'corpo' che contiene il referto in formato non strutturato. Per il caso descritto da questo RFC e' prevista la trasmissione del referto in formato PDF firmato (PKCS#7) [8] e codificato Base64 [9]. I dettagli sulle modalit di formattazione sono riportati nelle sezioni successive. 

I documenti xml schema che definiscono il formato adottato, conforme allo standard HL7 CDA Rel 2.0, sono riportati in allegato a questo RFC.
Gli xml schema adottati rappresentano una 'specializzazione' dello standard HL7 CDA Rel. 2.0, introdotta per compatibilita' rispetto alle specifiche che emergono dal Tavolo di sanita' Elettronica  del Dipartimento per l'Innovazione e le Tecnologie [2]; in particolare, la 'specializzazione' introduce acune obbligatorieta' e un restrigimento del contenuto di alcuni elementi. In ogni caso, un documento valido rispetto agli xml schema adottati risulta automaticamente valido anche rispetto agli schemi standard HL7 CDA Rel. 2.0.
Per la specifica dello standard HL7 CDA Rel 2.0 si fa riferimento alla documentazione ufficiale HL7, e in particolare alla normative edition 2008.

Il documento CDA  inviato con l'utilizzo di servizi erogati da Regione Toscana ed esposti alle Aziende dall'infrastruttura di cooperazione applicativa CART. Il dettaglio sulla modalita' di interfacciamento con la infrastruttura e' descritto in [4] e [5]. 

Quando Regione Toscana riceve un messaggio da parte di un'Azienda, restituisce una conferma di ricezione (messaggio di Acknowledge) che riporta un codice che indica se il messaggio e' stato correttamente elaborato o se si sono verificati errori.

Per la specifica della busta di trasporto si rimanda all'RFC e.Toscana n.98 "Dati comuni eventi sanitari" [7].  

Nelle sezioni successive sono descritti in dettaglio i casi d'uso e, attraverso esempi commentati, il formato dei documenti HL7 CDA scambiati nelle interazioni descritte dai casi d'uso.  


2.1. Casi d'uso
================================================================================
2.1.1. Ev01 - Produzione di un referto di radiologia
--------------------------------------------------------------------------------
L'evento si verifica quando viene prodotto, firmato e archiviato all'interno del sistema RIS aziendale un referto relativo ad una prestazione di radiologia. 

Al verificarsi dell'evento, l'Azienda invia a Regione Toscana un messaggio HL7 CDA che contiene le seguenti informazioni: 
 - Dati di identificazione dei soggetti che partecipano in ruoli diversi alla prestazione.
 - Data dell'evento 
 - Eventuale riferimento al codice dell'order entry.
 - Codice della prestazione effettuata (opzionale ma raccomandata)
 - Referto PDF firmato (PKCS#7) codificato "Base 64". 

Si osserva che per l'identificazione dell'assistito e del medico si invia l'identificativo univoco regionale, se disponibile, perche' dall'identificativo univoco si ricavano, tramite l'anagrafe sanitaria regionale, tutte le altre informazioni anagrafiche.

Se l'identificativo univoco non e' disponibile, si invia un codice identificativo alternativo assegnato da un'istituzione competente (vedi poi per il dettaglio). Si osserva tuttavia che questa seconda opzione e' deprecata, e dovra' essere abbandonata in favore della prima in conseguenza del processo di integrazione delle Aziende con l'anagrafe regionale.

Il formato del messaggio CDA che trasporta un referto di radiologia e' riportato in sezione 2.2.1. in cui e' anche descritto il significato dei singoli campi che lo compongono.


2.1.2. Ev02 - Produzione di un addendum/revisione ad un referto precedentemente emesso 
--------------------------------------------------------------------------------
L'evento si verifica quando viene prodotto, firmato e archiviato, all'interno del sistema RIS aziendale, un addendum ad un referto relativo ad una prestazione di radiologia oppure quando ne viene prodotta una nuova versione. 

 - Un addendum e' un documento che fornisce un'aggiunta un referto precedentemente emesso, estendendo o alterando le informazioni presenti al suo interno.
 - Una revisione e' invece una nuova versione di un referto precedentemente emesso. La revisione sostituisce completamente il vecchio referto che viene comunque mantenuto in uno stato di obsolescenza. 

Al verificarsi dell'evento, l'Azienda invia a Regione Toscana un messaggio HL7 CDA che contiene le seguenti informazioni: 
 - dati di identificazione dei soggetti che partecipano in ruoli diversi alla prestazione (l'assistito e il medico firmatario).
 - Data dell'evento 
 - Eventuale riferimento al codice dell'order entry.
 - Referto PDF firmato (PKCS#7) codificato "Base 64". 
 - Riferimento al referto originario con l'indicazione della tipologia di relazione con esso. In particolare, il documento CDA riporta un'informazione che lo qualifica come addendum / revisione di un referto precedentemente emesso.   

La gestione descritta di documenti di addendum/revisione  mutuata e conforme allo standard HL7; la gestione operativa delle modifiche ad referto pu variare significativamente in Aziende diverse, per cui allo stato attuale, per ragioni di omogeneit, di suggerisce di utilizzare sempre la modalit di revisione, ossia la sostituzione del referto originario con un referto aggiornato/modificato comunque autoconsistente. 

In sezione 2.2.2. sono descritte le caratteristiche di messaggio HL7 CDA di addendum/revisione.


2.1.3. Messaggio di Acknowledge
--------------------------------------------------------------------------------
A seguito della ricezione, elaborazione e archiviazione del referto, il ricevente (Regione Toscana) restituisce, in maniera asincrona rispetto alla spedizione, un messaggio di acknowledge che puo' riportare l'indicazione di corretta ricezione ed elaborazione del messaggio o una lista di codici di errore.

Tale messaggio e' descritto nel documento RFC 98 [7] che ne include anche la specifica XML Schema del formato. 

Si osserva che nel caso in cui il messaggio sia sintatticamente non valido (in particolare non valido rispetto al formato del CDA Rel 2.0 riportato nella normative edition HL7 del 2008), l'Azienda non ricevera' un messaggio di Acknowledge asincrono ma ricevera' in modo sincrono una segnalazione di errore attraverso un 'SOAP Fault'.   

 

2.2. Formato del documento XML CDA
================================================================================
2.2.1. Referto di radiologia
--------------------------------------------------------------------------------
Il formato del messaggio HL7 CDA Rev 2.0, conforme alla versione HL7 normative edition 2008 e al documento IBSE [2], che dovra' essere utilizzato per l'invio dei referti di radiologia  riportato in allegato, per mezzo dei documenti xml schema . Ai fini delle presente RFC verr elaborato dal destinatario (Regione Toscana) soltanto un sottoinsieme dei dati previsti dallo schema.

Di seguito e' riportato un esempio di documento contenente il sottoinsieme dei dati individuati, e il significato e l'obbligatorieta' degli elementi che lo costituiscono.   

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="CDA.xsl"?>
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd" xmlns="urn:hl7-org:v3">

	<realmCode code="IT" />
	<typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3" />
	<templateId root="2.16.840.1.113883.2.9.10.2.10" extension="ITPRF_REF_RADIO-001" />
	<id extension="CodiceSTS11.CodiceRadiologia.IdUnicoInternoDominioApplicativo" 
	         root="2.16.840.1.113883.2.9.2.90101" />
	<code code="18748-4" codeSystem="2.16.840.1.113883.6.1"
		codeSystemName="LOINC" codeSystemVersion="2.19"
		displayName="Study Report Diagnostic Imaging"/>
	<effectiveTime value="20090605134500" />
	<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"
		codeSystemName="Confidentiality" />
	<languageCode code="ita-ITA" />
	<setId extension="CodiceSTS11.CodiceRadiologia.IdUnicoInternoDominioApplicativo" 
	            root="2.16.840.1.113883.2.9.2.90101" />
	<versionNumber value="1" />

	<recordTarget>
		<patientRole>
			<id assigningAuthorityName="Ministero Economia e Finanze"
				extension="XXXYYY99A01W111K" root="2.16.840.1.113883.2.9.4.3.2" />
			<id assigningAuthorityName="Regione Toscana" extension="REG999999200800000001234"
				root="2.16.840.1.113883.2.9.2.90.4.1" />

			<patient>
				<name>
					<given>Mario</given>
					<family>Rossi</family>
				</name>
				<administrativeGenderCode code="M"
					codeSystem="2.16.840.1.113883.5.1" />
				
				<birthTime value="19701231"/>
				
				<birthplace>
					<place>
						<addr>
							<city>Firenze</city>
							<country>ITA</country>
							<censusTract>048017</censusTract>
						</addr>
					</place>
				</birthplace>
			</patient>
		</patientRole>
	</recordTarget>

	<author>
		<time value="20090605134500" />
		<assignedAuthor>		    
			<id assigningAuthorityName="Ministero Economia e Finanze"
				extension="XXXYYY99A01T222K" root="2.16.840.1.113883.2.9.4.3.2" />
			<id assigningAuthorityName="Regione Toscana" extension="REG999999200800000005678"
				root="2.16.840.1.113883.2.9.2.90.4.2" />
		</assignedAuthor>
	</author>

	<custodian>
		<assignedCustodian>
			<representedCustodianOrganization>
			    <!-- Codice OID dell'Azienda, come da registro HL7 Italia -->
				<id root="2.16.840.1.113883.2.9.2.90101" />
			</representedCustodianOrganization>
		</assignedCustodian>
	</custodian>

	<legalAuthenticator>
		<time value="20090605134500" />
		<signatureCode code="S" />
		<assignedEntity>
			<id assigningAuthorityName="Ministero Economia e Finanze"
				extension="XXXYYY99A01T222K" root="2.16.840.1.113883.2.9.4.3.2" />
		</assignedEntity>
	</legalAuthenticator>

	<inFulfillmentOf>
		<order>
			<id extension="xxx" root="2.16.840.1.113883.19.5.27" />
		</order>
	</inFulfillmentOf>


	<documentationOf>
		<serviceEvent>
		    <!-- Nomenclatore tariffario nazionale -->
			<code code="codice_esame" codeSystem="2.16.840.1.113883.2.9.6.1.11"
				codeSystemName="Nomenclatore Tariffario Nazionale Prestazioni Sanitarie" 							codeSystemVersion="1" displayName="nome esame">
			
				<!-- Nomenclatore tariffario regionale -->
				<translation code="codice_regionale_esame" codeSystem="2.16.840.1.113883.2.9.2.90.6.11"
					codeSystemName="Nomenclatore Tariffario Prestazioni Sanitarie Regione Toscana"
					codeSystemVersion="1.0" displayName="nome esame"/>
			</code>
		</serviceEvent>
	</documentationOf>

	<documentationOf>
		<serviceEvent>
		    <!-- Catalogo prestazioni regionale -->
			<code code="codice_esame" codeSystem="2.16.840.1.113883.2.9.2.90.6.33.1"
				codeSystemName="Catalogo unico delle prestazioni radiologiche Regione Toscana" 							codeSystemVersion="1" displayName="nome esame">
				
				<!-- Nomenclatore tariffario nazionale -->
				<translation code="codice_esame" codeSystem="2.16.840.1.113883.2.9.6.1.11"
				codeSystemName="Nomenclatore Tariffario Nazionale Prestazioni Sanitarie" 							codeSystemVersion="1.0" displayName="nome esame"/>
					
				<!-- Nomenclatore tariffario regionale -->
				<translation code="codice_regionale_esame" codeSystem="2.16.840.1.113883.2.9.2.90.6.11"
					codeSystemName="Nomenclatore Tariffario Prestazioni Sanitarie Regione Toscana"
					codeSystemVersion="1.0" displayName="nome esame"/>
			</code>
		</serviceEvent>
	</documentationOf>

	<documentationOf>
		<serviceEvent>
		    <!-- Nomenclatore tariffario regionale -->
			<code code="codice_esame" codeSystem="2.16.840.1.113883.2.9.2.90.6.11"
				codeSystemName="Nomenclatore Tariffario Prestazioni Sanitarie Regione Toscana" 							codeSystemVersion="1" displayName="nome esame">
			
				<!-- Nomenclatore tariffario nazionale -->
				<translation code="codice_regionale_esame" codeSystem="2.16.840.1.113883.2.9.6.1.11"
					codeSystemName="Nomenclatore Tariffario Nazionale Prestazioni Sanitarie"
					codeSystemVersion="1.0" displayName="nome esame"/>
			</code>
		</serviceEvent>
	</documentationOf>


	<relatedDocument typeCode="RPLC">
		<parentDocument>
			<id extension="xxx" root="yyyy" />
		</parentDocument>
	</relatedDocument>

	<component>
		<nonXMLBody>
			<text mediaType="application/x-pkcs7-mime" representation="B64">JVBERi0xLjQKJcOkw7zDtsOfRU9GCg==</text>
			<languageCode code="ita-ITA" />
		</nonXMLBody>
	</component>
</ClinicalDocument>


==> Elemento "/ClinicalDocument/realmCode"
Elemento OBBLIGATORIO che indica il dominio di appartenenza del documento. Il  documento DEVE contenere uno elemento 'realmCode' con valore dell'attributo 
code uguale ad 'IT'.


==> Elemento "/ClinicalDocument/typeId"
Elemento OBBLIGATORIO che indica che il documento e' strutturato secondo le 
specifiche HL7-CDA Rel 2.0 e piu' precisamente secondo lo schema della "CDA, Release Two Hierarchical Description". 
Il tag <typeId> e' un valore del tipo HL7 Instance Identifier ed e' composto da un attributo 'root' che riporta un codice OID, un attributo 'extension' che riporta un codice specifico. I valori di 'root' ed 'extension' sono costanti e valorizzati come nell'esempio, anche in conformita' con quanto specificato nel documento IBSE [2].  


==> Elemento "/ClinicalDocument/templateId"
Elemento OBBLIGATORIO che indica il template di riferimento per il documento corrente. Il tag <typeId> e' un valore del tipo HL7 Instance Identifier ed e' composto da un attributo 'root' che riporta un codice OID, un attributo 'extension' che riporta un codice specifico. I valori di 'root' ed 'extension' sono costanti e valorizzati come nell'esempio (per i referti di radiologia), in conformita' con quanto riportato anche nel documento IBSE [2].  


==> Elemento "/ClinicalDocument/id" 
Elemento OBBLIGATORIO che rappresenta l'identificativo unico del documento composto dalle seguenti informazioni: 'root': codice OID del dominio rilasciato da HL7 che rappresenta il codice OID della ASL/ASO inviante. 'extension': e' un campo che identifica univocamente il documento all'interno del dominio ASL/ASO. 
Per questo, si assume una strutturazione del campo 'extension' come concatenazione del codice STS11 della struttura, codice della radiologia (interno alla struttura) e codice identificativo univoco all'interno della radiologia: 
  
  CodiceSTS11.CodiceRadiologia.IdUnicoInternoDominioApplicativo

Nell'esempio, il caso di un id assegnato dalla ASL 1 (identificata dal codice 2.16.840.1.113883.2.9.2.90101). I codici OID che identificano le Aziende toscane sono riportati nel registro HL7 Italia.

 <id root="2.16.840.1.113883.2.9.2.90101"  
   extension="CodiceSTS11.CodiceRadiologia.IdUnicoInternoDominioApplicativo"/>
 
 
==> Elemento "/ClinicalDocument/code"
Elemento OBBLIGATORIO che indica la tipologia di documento. Gli attributi dell'elemento sono fissi per un documento di radiologia e devono essere cosi' valorizzati:
codeSystem = 2.16.840.1.113883.6.1 (OID sistema di codifica LOINC)
code = 18748-4 
codeSystemName = LOINC (Nome del vocabolario)
codeSystemVersion = 2.19 (Versione del vocabolario)
displayName = Study Report Diagnostic Imaging 

 
==> Elemento "/ClinicalDocument/effectiveTime" 
Data di generazione del referto. OBBLIGATORIO. Il formato della data e' 4 cifre anno, 2 di mese, 2 di giorno, ore (formato su 24 ore), minuti e secondi. 


==> Elemento "/ClinicalDocument/confidentialityCode"
Elemento OBBLIGATORIO che indica la riservatezza del documento.
Nel caso del referto il tag deve essere cos valorizzato: 
code="N" 
codeSystem="2.16.840.1.113883.5.25" 
codeSystemName="Confidentiality"


==> Elemento "/ClinicalDocument/languageCode"
Elemento OBBLIGATORIO che indica la lingua in cui  redatto il documento.
Nel caso del referto il tag deve essere cos valorizzato: 
code="ita-ITA"


==> Elemento "/ClinicalDocument/setId": elemento OBBLIGATORIO che rappresenta un codice comune a tutte le revisioni del documento. 'setID' resta costante tra le diverse versioni del medesimo documento. Nella prima versione coincide con l'elemento 'id'. Per l'uso del campo in presenza di revisioni si faccia riferimento alla sezione successiva.


==> Elemento "/ClinicalDocument/versionNumber": Numero di versione. Elemento OBBLIGATORIO. Alla prima trasmissione, il valore  1. 


==> Elementi "/ClinicalDocument/recordTarget/patientRole/id": identificativo dell'assistito. Il documento CDA deve contenere un elemento "id" che puo' essere il codice identificativo univoco regionale o un ulteriore codice identificativo assegnato dall'istituzione competente 
(codice fiscale/numero tessera TEAM/codice STP). Si osserva tuttavia che l'uso di codici alternativi al codice regionale e' deprecato (salvo i casi in cui
sia impossibile fare diversamente), e dovra' essere abbandonato in favore del codice identificativo regionale (in conseguenza del processo di integrazione con l'anagrafe regionale). 

Ogni elemento "id" e' caratterizzato da un attributo "root" che rappresenta il dominio di identificazione e "extension" che contiene l'identificativo vero e proprio dell'assistito. 

Per il codice fiscale in particolare si usa:
root="2.16.840.1.113883.2.9.4.3.2" extension="CODICE_FISCALE_DELL_ASSISTITO" 

Per il codice id univoco regionale si usa invece:
root="2.16.840.1.113883.2.9.2.90.4.1" extension="CODICE_ID_REGIONALE"

Per il numero tessera TEAM si usa invece:
root="2.16.840.1.113883.2.9.4.3.7" extension="[STATO ESTERO].[NUMERO SERIALE]"
dove: 
[STATO ESTERO] e' la sigla di identificazione dello stato che rilascia la tessera secondo il codice ISO 3166-1 a 3 caratteri (es. Francia=FRA)
[NUMERO SERIALE] e' il numero di identificazione della tessera TEAM.

Per il codice STP si usa invece:
root="2.16.840.1.113883.2.9.2.[REGIONE].4.1.1" extension="STP[CODICE IDENTIFICATIVO STP ASSEGNATO]"
dove:
[REGIONE] Codice della regione. Per Regione Toscana = '90'


==> Elemento "/ClinicalDocument/recordTarget/patientRole/patient/name": Informazioni anagrafiche sul paziente OBBLIGATORIE. Se la prestazione e' erogata in regime di anonimato, 'name' e' presente ma vuoto e con l'attributo nullFlavor='MSK'. Non  ammesso alcun utilizzo ulteriore del campo 'nullFlavor'. E' inoltre ammessa una sola occorrenza degli elementi 'family' e 'given'.

   <patient>
    <name>
     <given>Mario</given>
     <family>Rossi</family>
    </name>


==> Elemento "/ClinicalDocument/recordTarget/patientRole/patient/administrativeGenderCode": Sesso del paziente OBBLIGATORIO. Dal documento IBSE [2], e' possibile che il campo assuma valore M (maschio) o F (femmina). 
    
   <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" />


==> Elemento "/ClinicalDocument/recordTarget/patientRole/patient/birthTime": Data di nascita OPZIONALE del paziente in formato yyyyMMdd.
      
      <birthTime value="19701231"/>
      
      
==> Elemento "/ClinicalDocument/recordTarget/patientRole/patient/birthplace" 
Luogo di nascita OPZIONALE. 
Se presente, l'elemento deve contenere almeno l'elemento 'censusTract'.
L'elemento 'country' riporta il codice della nazione ISO-3166-1 a 2 oppure 3 caratteri.
L'elemento 'censusTract' se presente, deve riportare il codice ISTAT del comune (se nato in territorio italiano) o della nazione (se nato all'estero). 
Se la prestazione e' erogata in regime di anonimato, birthPlace e' presente ma vuoto e con l'attributo nullFlavor='MSK'.

      <birthplace>
        <place>
          <addr>
              <country>Nazione</country>
              <city>Citta'</city>
              <censusTract>Codice ISTAT della NAZIONE o del COMUNE</censusTract>
          </addr>
        </place>
      </birthplace>


==> Elemento "/ClinicalDocument/author/time"
Data di chiusura del referto. OBBLIGATORIO. Il formato e' 4 cifre per l'anno, 2 cifre mese, 2 cifre giorno, ore (su 24 ore), minuti e secondi per un totale di 14 cifre.


==> Elemento "/ClinicalDocument/author/assignedAuthor"
Informazioni sul medico che ha firmato il referto. L'elemento e' OBBLIGATORIO ed e' strutturato come l'elemento "/ClinicalDocument/recordTarget/patientRole/patient". Per l'identificazione del medico valgono le stesse regole esposte in precedenza per gli elementi "/ClinicalDocument/recordTarget/patientRole/id". 


==> Elemento "/ClinicalDocument/custodian"
Elemento OBBLIGATORIO che identifica l'azienda che mantiene il referto. L'azienda e' identificata tramite il codice contenuto nell'elemento "root".
Nell'esempio, il codice assegnato alla ASL 1 (identificata da 2.16.840.1.113883.2.9.2.90101). I codici OID che identificano le Aziende toscane sono riportati nel registro HL7 Italia.

  <custodian>
   <assignedCustodian>
    <representedCustodianOrganization>
     <id root="2.16.840.1.113883.2.9.2.90101"/> 
    </representedCustodianOrganization>
   </assignedCustodian>
  </custodian>


==> Elemento "/ClinicalDocument/legalAuthenticator"
Firmatario del documento. OBBLIGATORIO. La struttura dell'elemento e' analoga a quanto visto per 'author'. In particolare devono OBBLIGATORIAMENTE essere contenuti:
 - un elemento 'id' cosi' valorizzato: assigningAuthorityName="Ministero   
   Economia e Finanze", extension="codice fiscale del firmatario" 
   root="2.16.840.1.113883.2.9.4.3.2" />
 - 'time' che rappresenta l'ora in cui e' avvenuta la firma del documento (in 
   formato AAAAMMGGHHmmss, con HH su 24 ore) 
 - 'signatureCode' code = "S" che indica che il documento e' firmato 
   digitalmente. 


==> Elemento "/ClinicalDocument/inFulfillmentOf"
Tag OBBLIGATORIO nel caso ci sia un order placer funzionante. L'attributo "extension" va valorizzato con Placer Order Group Number = Placer Order Number, 
che rappresenta la richiesta di prestazione generata dall'applicativo che gestisce la richiesta di esame. Puo' essere valorizzato con il codice dell'impegnativa relativa alla prestazione.

 <inFulfillmentOf>
  <order>
   <id extension="xxx" root="2.16.840.1.113883.19.5.27"/>
  </order>
 </inFulfillmentOf>


==> Elemento "/ClinicalDocument/documentationOf"
Elemento OPZIONALE che fa riferimento alla prestazione effettivamente eseguita. Se l'elemento "documentationOf" e' presente, al suo interno deve essere riportato un "serviceEvent" che contiene l'identificativo delle prestazioni secondo il catalogo delle prestazioni e (opzionalmente) la traduzione dello stesso codice secondo un altro catalogo di riferimento.

In particolare si indicano 3 possibili valorizzazioni,come riportato nel documento di esempio :
1. Valorizzazione del "serviceEvent" con il codice secondo il Nomenclatore Tariffario Nazionale e sua transcodifica 
secondo il Nomenclatore Tariffario di Regione Toscana;
2. Valorizzazione del "serviceEvent" con il codice secondo il Catalogo unico delle prestazioni radiologiche di Regione Toscana e sua transcodifica secondo il Nomenclatore Tariffario di Regione Toscana e/o secondo il Nomenclatore Tariffario Nazionale; 
3. Valorizzazione del "serviceEvent" con il codice secondo il Nomenclatore Tariffario di Regione Toscana e sua (opzionale) transcodifica secondo il Nomenclatore Tariffario Nazionale;

Sebbene l'elemento "documentationOf" sia opzionale se ne raccomanda la valorizzazione, e si raccomanda di valorizzarlo nella modalit n.2, riportando cio il codice della prestazione secondo il Catalogo unico delle prestazioni radiologiche di Regione Toscana.

Il Catalogo unico delle prestazioni radiologiche di Regione Toscana  stato approvato con Decreto Dirigenziale n.3509 del
22/07/2009, assieme alla tabella di transcodifica verso il Nomenclatore Tariffario Regionale.

 <documentationOf>
  <serviceEvent>
   <code code="CODICE_ESAME_SECONDO_CATALOGO_UNICO_REGIONALE" 
      codeSystem="2.16.840.1.113883.2.9.2.90.6.33.1"
      codeSystemName="Catalogo unico delle prestazioni radiologiche Regione Toscana"
      codeSystemVersion="1" displayName="NOME_ESAME">
   <translation code="CODICE_ESAME_SECONDO_NOMENCLATORE_TARIFFARIO_REGIONALE" 
      codeSystem="2.16.840.1.113883.2.9.2.90.6.11"
      codeSystemName="Nomenclatore Tariffario Prestazioni Sanitarie Regione Toscana"
      codeSystemVersion="1.0" displayName="NOME_ESAME"/>
   </code>
  </serviceEvent>
 </documentationOf>


==> Elemento "/ClinicalDocument/component/nonXMLBody"
Elemento OBBLIGATORIO contenente, all'interno dell'elemento figlio "text", il referto. Il referto deve essere fornito come documento PDF firmato e codificato Base 64.

	<component>
		<nonXMLBody>
			<text mediaType="application/x-pkcs7-mime" 
   representation="B64">JQERQER343QER34VBEUlRU9GCg==</text>
			<languageCode code="ita-ITA" />
		</nonXMLBody>
	</component>



2.2.2. Addendum / revisione ad un referto precedentemente emesso
--------------------------------------------------------------------------------
La struttura di un messaggio HL7 CDA Rev 2.0 che rappresenta una revisione o un addendum ad un referto precedentemente inviato, e' analoga a quanto descritto nella precedente sezione. Essa differisce dal caso precedente per la presenza dei seguenti elementi:

==> Elemento "/ClinicalDocument/relatedDocument"
Riferimento OBBLIGATORIO al documento CDA sostituito/integrato tramite addendum. 
 
 <relatedDocument typeCode="RPLC">
  <parentDocument>
   <id extension="xxx" root="yyyy" />
  </parentDocument>
 </relatedDocument>
 
In un messaggio di "revisione", gli attributi assumono i valori seguenti: typeCode='RPLC' (replacement) indica che questo documento CDA sostituisce il precedente; extension e root sono gli stessi dell'elemento "/ClinicalDocument/id" del documento sostituito.

In un "addendum", gli attributi assumono i valori seguenti: typeCode='APND' (append); extension e root sono gli stessi dell'elemento "/ClinicalDocument/id" del documento cui l'addendum si riferisce.


==> Elemento "/ClinicalDocument/setId" 
la revisione/addendum ha un elemento "/ClinicalDocument/id" diverso da quello del referto sostituito/integrato. 
Per quanto riguarda l'elemento "/ClinicalDocument/setId": nel caso di revisione, il campo "setId" resta invariato rispetto al documento cui la revisione si riferisce; nel caso di addendum, al campo "setId" deve essere invece assegnato un nuovo valore.


==> Elemento "/ClinicalDocument/versionNumber": nel caso di revisione, il campo "versionNumber" viene incrementato di 1 rispetto al documento cui la revisione si riferisce. Nel caso di addendum, il numero di versione resta invece invariato. 



2.3 Completamento / correzione di informazioni
--------------------------------------------------------------------------------
Il completamento o la correzione di informazioni trasmesse con un messaggio 
e' effettuato unicamente con l'invio di un nuovo messaggio di addendum o di revisione, come descritto nella precedente sezione. 

Nel caso di una revisione, le informazioni contenute in questo nuovo messaggio sostituiscono in toto quelle contenute nel messaggio precedente. Vale cioe' la regola per cui le informazioni valide sono quelle contenute nell'ultimo messaggio di revisione ricevuto. 

Nel caso di un addendum, le informazioni contenute nel messaggio si aggiungono o aggiornano quelle contenute nel messaggio a cui l'addendum si riferisce.
 

3. Prodotti attesi	
================================================================================

3.1. WSDL dei servizi 
--------------------------------------------------------------------------------
Il documento HL7 CDA deve essere inviato dalle Aziende a Regione Toscana utilizzando la busta "Dati comuni eventi sanitari" descritta nel documento RFC e.Toscana n.98 [7]. Si rimanda a questo documento per la specifica WSDL delle interfacce di servizio.


4. Bibliografia
================================================================================
[1] CDA per il dominio di radiologia di Regione Toscana, bozza, versione 2.1

[2] Specifiche tecniche per la creazione del "Documento di Referto" secondo lo standard HL7-CDA Rel.2, 
Progetto Rete Generale dei MMG/PLS, IBSE, Dipartimento per l'Innovazione e le Tecnologie, RC1, 22/04/2009

[3] Clinical Document Architecture (CDA) Rel. 2, Sezione Header, Specifica di Localizzazione Italiana, 
HL7 Italia V3it TC Versione 1.0, Settembre 2008

[4] "Manuale d'Uso Infrastruttura CART", Regione Toscana, 
Versione 1.01 del 03/12/2007 

[5] "SDK-CART", Regione Toscana, Versione 1.1 del 20/04/2008 

[6] "XML Schema", W3C Recommendation 28 October 2004, 
http://www.w3.org/XML/Schema 

[7] "Busta dati comuni eventi sanitari", RFC e.Toscana n.98 rev. 5 o successive. 

[8] "PKCS #7: Cryptographic Message Syntax" Version 1.5, Request for Comments: 2315 RSA Laboratories, East, Marzo 1998 http://tools.ietf.org/rfc/rfc2315.txt

[9] "The Base16, Base32, and Base64 Data Encodings", S. Josefsson, Ed., Request for Comments: 3548, Luglio 2003, http://tools.ietf.org/rfc/rfc3548.txt



5. Storico versioni
================================================================================
[rev 2 - 01/10/2009]
 - Terza versione
Modificata la struttura del valore del campo 'extension' per gli elementi 'id' e 'setId'. 
Modificato il codice OID dell'identificativo 'AssignedAuthor': si utilizza il codice OID del ramo operatori. 
Modificato il codice OID dell'attributo 'codeSystem' dell'elemento '/ClinicalDocument/documentationOf/serviceEvent/translation'
Inseriti gli elementi opzionali 'birthTime' e 'birthPlace' (modificata anche la parte descrittiva).
Modificata la descrizione dell'utilizzo del campo 'setId' in caso di addendum.
Arricchita la parte relativa all'elemento 'documentationOf' ed introdotto il codice OID 2.16.840.1.113883.2.9.2.90.6.33.1
(non ancora registrato) per il Catalogo unico delle prestazioni radiologiche di Regione Toscana. 
 
 
[rev 1 - 08/09/2009]
 - Seconda versione
Introdotta 'specializzazione' degli xml schema, modificata parte descrittiva del 'Contesto' e dettagliata la parte anagrafica dell'assistito

[rev 0 - 26/08/2009]
 - Prima versione
 
