1) Introduzione  

L'Obiettivo di costruire una banca dati integrata, a partire da flussi informativi amministrativo-sanitari di diversa natura, che abbia nel paziente/assitito l’unità elementare di riferimento presuppone la possibilità di individuare nei dati a disposizione quegli elementi informativi che consentano di ricondurre al medesimo soggetto osservazioni raccolte in tempi distinti e provenienti da flussi diversi. E' chiaro che una tale operazione risulta fortemente condizionata dalla completezza e qualità del dato: questo, per sua natura, è affetto da errori vari, dovuti per lo più ad inappropriatezza ed approssimazione, che in fasi successive e per cause molteplici finiscono per deteriorarne la qualità e comprometterne l'attendibilità, fino a renderlo nei casi estremi totalmente inutilizzabile. Quando ciò avviene nella componente anagrafica dell'informazione, ossia in quei campi quali il nome e cognome, il codice sanitario, quello fiscale, la data di nascita, il sesso e il comune di nascita, è facilmente comprensibile come lo sforzo di individuare il soggetto sulla base di elementi di identificazione comuni può risultare, se non vano, comunque di difficile attuazione. Se si considera, poi, che proprio perché trattasi di informazioni che riguardano l'identità del soggetto e quindi sottoposte ai vincoli e alle restrizioni previste da quella parte della legislazione che mira a garantire la tutela della privacy, molto spesso queste informazioni sono volutamente, in toto o in parte, non riportate e dunque non disponibili. Lo scenario informativo con cui ci si deve confrontare è quindi, da questo punto di vista, molto spesso non proprio favorevole: la griglia dei riferimenti anagrafici è composta da molti campi vuoti, da altri parzialmente compilati, da altri ancora riempiti in maniera approssimativa; solo poche variabili sono attendibili e utilizzabili ai fini del processo di identificazione del soggetto di riferimento. È chiaro che quella descritta è una situazione che può variare da caso a caso: a volte realtà particolari, grazie magari anche allo scrupolo dell'operatore che archivia il dato, offrono scenari migliori e più favorevoli; in linea di massima, però, si può affermare che, soprattutto andando a ritroso negli anni, quando il supporto dei sistemi di gestione informatizzata del dato era ancora limitato se non inesistente, la precarietà dell'informazione di cui si dispone fa sì che il meccanismo di attribuzione di una osservazione ad un soggetto non sia mai banale né tanto meno immediato.

2) Clustering - Linkage - Validazione.  

Una banca dati amministrativa, qual che sia la sua natura (schede di dimissione ospedaliera, prescrizioni farmaceutiche, prestazioni specialistiche, schede di morte, esenzioni ticket, registri di patologie, ecc.), si configura generalmente come una raccolta di informazioni dove l'unità informativa elementare (record - osservazione) non è quasi mai il soggetto (paziente - assistito), ma la griglia di dati che riguardano il suo ricovero, la sua ricetta, la sua visita specialistica. Poiché, come è facile immaginare, l'evento associato allo stesso paziente non è unico e irripetibile, c'è da aspettarsi che nel medesimo archivio vi sia più di un record riconducibile allo stesso soggetto o, ancora più verosimilmente, che in ciascuna delle diverse banche dati figuri almeno un'osservazione attribuibile al medesimo assistito. Quindi, risalire dall'informazione legata all'evento a quella legata al soggetto equivale, di fatto, sulla base di dati di identificazione comuni a raccogliere, raggruppare, accomunare i diversi records assegnandoli in clusters di appartenenza "anagraficamente" omogenei. Si tratta, a tutti gli effetti, di una vera e propria operazione di partizionamento della banca dati, sulla base di una relazione di equivalenza applicata ai records e definita dalla "similarità informativa" dei campi anagrafici: le classi di equivalenza generate costituiscono i clusters di pazienti. Analogamente, si può accostare l'operazione di clustering a quella di analisi fattoriale, applicata però non sulle colonne del database (variabili), ma sulle righe (records) e in cui i fattori individuati rappresentano non gli assi del nuovo spazio a dimensione ridotte, ma l'insieme (meno denso) dei nuovi punti (clusters - pazienti) in esso collocati.
Il concetto di clusterizzazione resta valido anche quando le banche dati su cui si intende operare sono più d'una, anche se, in generale, la loro diversa natura impone una sua applicazione "sincronizzata", "parallela" e "coerente", in quanto, in questo caso, l'obiettivo non è più semplicemente solo quello di individuare in ciascuno di essi i clusters, ma di identificarli in modo da poterne riconoscere la diversità o la coincidenza nei vari flussi informativi. In altri termini, l'integrazione di basi di dati di diversa natura in un sistema centralizzato basato sul paziente richiede un processo di data-linkage che va oltre quello di semplice data-clustering, a cui accanto alla fase di individuazione del soggetto va affiancata quella, fondamentale, di identificazione. Quest'ultimo aspetto introduce una complicazione non trascurabile nel percorso di risalita dall'evento al paziente. Infatti sia che si proceda alla clusterizzazione che al linkage è necessario definire delle chiavi su cui imperniare il processo di aggregazione. Ciò comporta la scelta di quei campi anagrafici che più si prestano, nella situazione contingente e nell'ambito della problematica legata alla qualità del dato, al raggiungimento dell'obiettivo. A questo proposito è abbastanza superfluo ricordare come i diversi flussi informativi, proprio per la loro diversa natura e il loro diverso percorso di raccolta, risultano a volta disomogenei e a volta addirittura incompatibili in termini di tracciato records e di struttura e formato dell'informazione. Questo determina, nell'ambito del processo di linkage, una consistente riduzione del numero di campi anagrafici candidabili ad essere selezionati come chiavi di join: infatti, se da una parte la procedura di clustering opera in maniera autonoma e asincrona sulle variabili anagrafiche di cui si dispone, o in ogni caso elette a chiavi, nell'ambito dell'unica banca dati in questione, la procedura di linkage non può che operare, in sincronia, su quel gruppo di campi (o parte di essi) comuni ai due o più basi di dati da integrare. La griglia di dati su cui attuare il linkage è dunque di norma più ristretta che nel clustering e, nei casi peggiori, può capitare che essa si riduca proprio a quelle variabili qualitativamente meno affidabili e potenzialmente più affette da errori, rendendo di fatto inapplicabile il join e di conseguenza inattuabile l'integrazione dell'informazione. Risulta indispensabile in questi casi la disponibilità di un archivio di riferimento, quale può essere l'Anagrafe Assistiti, o di qualunque altro possa svolgere le funzioni di supporto informativo anagrafico. In questa evenienza, auspicabile anche nel caso del solo clustering, si può arrivare ad un miglioramento qualitativo e di completezza dell'informazione, grazie al contributo di recupero, correzione ed integrazione del dato che un tale archivio può fornire. Questo, consentendo il "riconoscimento" del paziente, permette di correggere il dato laddove risulta non conforme a quanto riscontrato nell'archivio Anagrafe, di recuperarlo in corrispondenza di quei campi nei quali risulta mancante, ma soprattutto di integrare i flussi informativi originari con quelle variabili anagrafiche che risultano assenti e che possono tornare utili nella costruzione delle chiavi di linkage. Di fatto, il passaggio per un archivio di riferimento garantisce una sorta di validazione dell'informazione e, anche dal punto di vista metodologico e procedurale, rende equivalente il linkage al clustering, nel senso che l'identificazione del paziente consente di operare la clusterizzazione in maniera asincrona sui singoli archivi per poi effettuare, anche in tempi diversi, il linkage come semplice join tra i pazienti riconosciuti identici.

3) La routine ReClust.  

Da quanto detto finora si evince che la procedura di clustering e, per estensione, quella di linkage, richiedono oltre alla individuazione e alla selezione dei campi anagrafici su cui incentrare il meccanismo di aggregazione dei records, la definizione precisa e rigorosa dei "criteri di appartenenza" di una osservazione ad un cluster, ossia la scelta delle regole e delle specifiche in base alla quali sia possibile assegnare in maniera deterministica e univoca un record nel proprio cluster di competenza. Si tratta, per usare le analogie algebriche e statistiche citate prima, di definire la relazione di equivalenza da applicare sulla banca dati in esame in modo da partizionarne i records in classi di equivalenza "anagraficamente" omogenee, oppure, equivalentemente, di fissare l'algoritmo di fattorizzazione che generi i fattori più idonei a raccogliere e sintetizzare le caratteristiche anagrafiche comuni ai vari records. Mentre la fase di scelta delle chiavi di clustering è diversa da caso a caso e legata alla disponibilità e alla qualità del dato, quella di definizione dei criteri di appartenenza va standardizzata e automatizzata in modo da garantire, a parità delle condizioni iniziali, la riproducibilità dei risultati. È quanto ci si è proposto di realizzare ideando e sviluppando la routine ReClust, un algoritmo di clusterizzazione implementato in linguaggio SAS e che, basato su una logica iterativa e a passi successivi, mira a raggruppare i records secondo una logica di prevalenza nelle corrispondenze e nel matching tra le varie chiavi di aggregazione. Le poche varianti di funzionamento previste sono legate da una parte alla disponibilità o meno di banche dati anagrafiche di riferimento e, in quest'ultima ipotesi, alla scelta e/o alla necessità di effettuare in maniera asincrona o meno la clusterizzazione dei diversi archivi (nell'eventualità del data linkage), dall'altra all'esigenza di intervenire nel flusso naturale del programma, per alterare il peso e la priorità assegnata alle chiavi di clustering onde favorire la generazione di un numero inferiore di classi, ma più “ampie” dal punto di vista della numerosità dei propri elementi. In ogni caso, ReClust opera simulando o, più propriamente, riconducendo i vari scenari a quello classico della clusterizzazione: anche quando i flussi informativi sono più di uno e, pur disponendo di un supporto informativo anagrafico, si preferisce rendere sincrona la procedura di aggregazione nei diversi archivi, l'algoritmo fonde le varie banche dati facendo perno sulla griglia di variabili anagrafiche comuni selezionate come chiavi e, rendendo sequenziali i records di diversa origine, agisce in una sola fase, fatta di più passi, ma comunque unica nei suoi tempi di espletazione, sull'unico mega-archivio così costruito. Con questa logica di esecuzione ReClust adempie alla duplice necessità, propria del linkage, di individuare il cluster, ma, nello stesso tempo, di identificarlo: si tratta di una identificazione relativa e non assoluta, ma più che sufficiente per riconoscere in fase di output, quando gli archivi originari vengono restituiti nella loro forma separata, i clusters facenti capo allo stesso soggetto (e dunque concettualmente linkati grazie allo stesso codice di identificazione) da quelli che figurano in maniera mutuamente esclusiva in uno solo dei flussi informativi. La presenza di un archivio "validante", invece consente di distinguere e differire le fasi di clusterizzazioni, ossia di forzare la procedura di clustering (perché sempre di essa si tratta) a procedere in maniera asincrona: si tratta di una scelta obbligata, se si selezionano chiavi di aggregazioni non coincidenti per i vari archivi, facoltativa, se il set di variabili anagrafiche responsabili del clustering sono comuni ai diversi databases. In ogni caso, l'algoritmo di clustering opera tanti cicli di clusterizzazione quanti sono i flussi informativi da integrare, ma il linkage tra le classi è comunque assicurato dall'identificazione "assoluta" che l'archivio anagrafico consente di ottenere grazie all'attribuzione univoca del codice paziente all'atto del riconoscimento dello stesso in seno all'archivio validante. Ricapitolando:

A sua volta, la procedura di clustering, a prescindere dallo scenario in cui è chiamata ad operare, consta di passi ben definiti, alcuni dei quali si ripetono ciclicamente, altri condizionabili in misura più o meno forte dall'esterno, altri ancora eseguiti solo in presenza o assenza di un archivio di riferimento. Di fatto si tratta di operazioni sostanzialmente riconducibili ai seguenti 5 steps:

  Scelta dei campi di clustering;

  Definizione delle chiavi di clustering;

  Applicazione della procedura di Soundex;

  Assegnazione dei codici di chiave;

  Individuazione e identificazione del cluster.

3.1) Scelta dei campi di clustering  

La selezione delle variabili anagrafiche su cui applicare la procedura di clusterizzazione è ovviamente un'operazione che non compete all'algoritmo ReClust, ma precede cronologicamente il lancio della routine. Si tratta di uno step che è affidato all'utente-analista e alla sua conoscenza della situazione reale circa la disponibilità del dato e la qualità del contenuto informativo di ciascun campo anagrafico. Come si è avuto modo di anticipare più volte in precedenza, la precarietà e l'incompletezza dell'informazione non lasciano molti margini alla fantasia dell'operatore, nel senso che tutto ciò che concerne la "descrizione anagrafica" del soggetto va preso in considerazione e, magari con i dovuti adeguamenti e raffinamenti, reso disponibile per le fasi successive del clustering. I campi che solitamente vanno esaminati per valutarne l'idoneità all'uso possono essere quelli amministrativi come codice fiscale e codice di tessera sanitaria, oppure quelli prettamente anagrafici come nome e cognome, data di nascita, sesso e comune di nascita, e, quando si rivela necessario per ristrettezza di informazioni, anche quelli che descrivono la situazione sociale dell'individuo come comune di residenza, stato civile, professione, titolo di studio, ecc. (l'uso di questi campi, ovviamente, va ponderato con estrema attenzione, perché essi, non definendo, in generale, una condizione "costante" e duratura nel tempo del soggetto, possono risultare tanto più inappropriati per la sua individuazione quanto più è ampio l'arco temporale a cui fanno riferimento i flussi informativi esaminati). Come già anticipato, l'unico vincolo imposto dalla procedura di clusterizzazione alla scelta dei campi deriva dalla necessità di dover lavorare su una griglia di variabili comuni agli archivi da linkare, quando non è disponibile una banca dati anagrafica che consenta di rendere asincrono il processo, e dunque, in questa ipotesi, vanno esclusi dalla selezione quei campi non sempre presenti in tutti gli archivi, anche se ottimali, laddove figurano, dal punto di vista della qualità del dato. Inoltre, può capitare a volte che nell'ambito delle variabili scelte possano comparire valori che non rientrano nel range di quelli attesi o consentiti: si tratta molto spesso di valori convenzionali che vengono malauguratamente inseriti come indicativi di "dato mancante". È buona norma, in questi casi, procedere alla rimozione di questi valori, cancellandoli e lasciando vuoto il contenuto del campo, in modo da evitare che essi possano condizionare negativamente l'andamento dell'operazione di clustering con l'individuazione di classi solo in apparenza "anagraficamente" omogenee. Un'altra regola fondamentale a cui attenersi in fase di preparazione e ripulitura del dato è quella di codificare in maniera opportuna e coerente (adottando o un proprio sistema di codifica o uno proposto a scopo amministrativo) quei campi che per loro natura non lo sono (ad esempio sesso, stato civile, professione, ecc.) o per i quali è stata preferita una descrizione per esteso (comune di nascita, data di nascita, ecc.). Ciò evidentemente serve a rendere uniforme il contenuto informativo delle variabili e ad evitare che l'originaria disomogeneità delle stesse possa minare e compromettere in partenza il buon esito della procedura di clusterizzazione. Allo stesso scopo, è consigliabile per quelle variabili per le quali non è possibile introdurre una rappresentazione codificata, quali ad esempio nome e cognome, adottare un formato omogeneo (tutto maiuscolo o minuscolo) evitando l'uso di apostrofi, lettere accentate, caratteri separatori, ecc. Infine, l'intervento dell'operatore può risultare auspicabile e lungimirante, in previsione degli steps successivi della routine ReClust, se è finalizzato da una parte alla conversione in formato alfanumerico di variabili (come la data di nascita) che si intende sottoporre alla procedura di Soundex e dall'altro alla creazione di nuove variabili, risultanti dalla composizione di campi originariamente distinti (quali ad esempio cognome e nome), che contribuirebbero, come si vedrà, a rendere maggiormente "stabile" ed efficace la procedura di Soundex.
Ricapitolando, la fase di selezione dei campi anagrafici è riconducibile ai seguenti punti:

  Scelta di variabili comuni agli archivi in esame;

  Cancellazione di valori convenzionali;

  Codifica dei campi descrittivi;

  Omogenizzazione delle stringhe alfanumeriche;

  Conversione in stringhe delle variabili da sottoporre alla procedura di Soundex;

  Creazione di campi composti da sottoporre alla procedura di Soundex.

3.2) Definizione delle chiavi di clustering  

Dopo la scelta dei campi, il passo più delicato dell'intera fase di preparazione, predisposizione e configurazione dei parametri che regolano il funzionamento dell'algoritmo ReClust è probabilmente quello di definizione delle chiavi di clustering, ossia della combinazione delle singole variabili selezionate in sets di uno o più campi che individuano la griglia informativa su cui poi la procedura di clustering opererà l'aggregazione dei records in classi omogenee. Da questa scelta dipende la composizione dei clusters finali e soprattutto il loro livello di omegeneità: è dunque fondamentale una definizione delle chiavi appropriata e coerente, in funzione di quello che è l'obiettivo della clusterizzazione, ossia l'individuazione di classi di records che abbiano la caratteristica comune di essere attribuibili al medesimo soggetto-paziente. Il criterio base che deve guidare nella definizione delle chiavi è dettato dalla esigenza di tendere il più possibile a individuare chiavi primarie o univoche, come lo sono per loro natura, ad esempio, il codice fiscale e il codice sanitario: ciò significa combinare in maniera opportuna i singoli campi (utilizzando, se necessario, più volte lo stesso campo in più patterns) in modo da costruire chiavi multicampo che somiglino o si comportino come chiavi primarie. Mettere insieme, ad esempio, nome, cognome, sesso, data di nascita e comune di nascita significa costruire una chiave a 5 dimensioni che, almeno nel contesto in cui si opera, può essere ritenuta di fatto equivalente al codice fiscale e, quindi, a tutti gli effetti, univoca. A tal proposito, va tenuto presente che un pattern di variabili può costituire in pratica una chiave primaria, anche se non lo è in teoria, se applicato in uno scenario informativo particolare, quale può essere, ad esempio, quello delle schede di dimissione ospedaliere nell'ambito di una patologia rara. In questo contesto una chiave tridimensionale composta da cognome, nome e data di nascita ha in effetti valenza di univocità, se non altro perché si può ritenere che i casi di omonimi coetanei siano da escludersi a priori proprio grazie all'ambito particolare in cui si opera.
Dall'altro canto, nella logica di funzionamento di ReClust, una variabile, coinvolta nella costruzione di una chiave di clustering, perde la sua identità singola nel momento in cui confluisce nel pattern multicampo e trasferisce ad esso il suo contributo informativo; analogamente la chiave multidimensionale eredita da ciascuno dei campi che la compongono la qualità del dato, compresa, e questo è da non sottovalutare, l'eventuale incompletezza informativa. Ciò, in altri termini significa che in corrispondenza di un record il valore della chiave è considerato mancante se almeno uno dei suoi campi non riporta il dato: pertanto la fase di definizione delle chiavi di clustering porta con sè, come effetto collaterale, la problematica legata all'estensione, alla propagazione e all'amplificazione della incompletezza informativa. Di questo effetto si deve tener conto in fase di costruzione della chiave: se è vero che maggiore è la sua dimensione (ossia il numero di campi che la compongono) più la sua incidenza è assimilabile a quella di una chiave primaria, è altrettanto vero che più campi si coinvolgono nella sua definizione, maggiore è la probabilità di ingenerare perdita di informazione. Dunque, una chiave di clustering deve essere il risultato di un giusto mix tra l'esigenza di individuare un pattern di variabili capace di assicurare alla fine clusters omogenei e la necessità di salvaguardare la quantità del contenuto informativo, elemento primario per il conseguimento di tale risultato.
Altro aspetto determinante per il raggiungimento dell'obiettivo finale è l'attribuzione del livello di priorità a ciascuna chiave di clustering. Si tratta sostanzialmente di stabilire l'ordine con cui ciascuna chiave e ciascuna combinazione di chiavi dovranno intervenire nella fase ciclica dell'algoritmo ReClust per assegnare i records nei diversi clusters che vengono individuati nel corso del processo iterativo. Senza entrare nel dettaglio tecnico del funzionamento della routine, va detto che la procedura esegue un numero di cicli legato esponenzialmente al numero di chiavi: in ciascuna iterazione viene stabilita l'appartenenza dei records alle varie classi in base al matching o, più semplicemente, all'equivalenza informativa degli stessi in corrispondenza di un set di chiavi, il cui numero dal valore massimo scende progressivamente con l'eliminazione sequenziale e alternata delle chiavi con più basso livello di priorità. In particolare, se si utilizzano 3 chiavi K1, K2 e K3 con priorità rispettivamente alta, media e bassa, il numero di cicli sarà pari a 2³ - 1 = 7 e il pattern su cui iterativamente verrà eseguito il confronto informativo sarà composto nell'ordine dalle seguenti chiavi:

La regola da seguire per l'attribuzione dei livelli di priorità è diretta conseguenza di quanto detto in precedenza riguardo al grado di univocità e completezza delle chiavi: è buona norma privilegiare quelle che danno maggiori garanzie in termini sia di capacità di individuazione di cluster omogenei che di qualità e presenza del dato.
Molto spesso può risultare utile per diversi motivi, come ad esempio l'inaffidabilità o l'elevata incompletezza del dato in corrispondenza di chiavi primarie a cui si è attribuito priorità massima, innalzare in qualche misura il peso delle chiavi secondarie senza però modificare l'ordine di intervento nella procedura di clusterizzazione. Mediante una opportuna configurazione dei parametri di input della routine ReClust è possibile influenzare la costruzione dei clusters, ritardando l'attribuzione di alcuni records in determinate classi fino all'iterazione che coinvolge singolarmente la chiave a cui si è deciso di attribuire peso maggiore. Agendo in maniera simultanea sul peso di tutte le chiavi di clustering, l'effetto finale non è quello di ripristinare l'iniziale rapporto di priorità, bensì di accrescere l'effetto nella clusterizzazione dei cicli con pattern di una sola chiave: il risultato è l'individuazione di classi più “voluminose” in termini di numero di records raggruppati e di conseguenza meno numerose come effetto della partizione.
Ricapitolando, la fase di definizione delle chiavi di clustering deve tener conto dei seguenti aspetti:

  Scelta di chiavi il più possibile univoche;

  Limitazione della perdita della completezza informativa;

  Assegnazione del livello di priorità delle chiavi;

  Eventuale innalzamento del peso delle singole chiavi.

3.3) Applicazione della procedura di Soundex  

Scelti i campi anagrafici, definite le chiavi di clustering, stabilito il loro livello di priorità, per l'avvio della clusterizzione vera e propria rimane da fissare i criteri e le specifiche con cui si debba operare il confronto informativo tra i records e per mezzo dei quali sia possibile non solo cogliere la correlazione tra i dati, ma misurarne in qualche maniera l'equivalenza informativa. Accomunare dei records e assegnarli ad una classe di equivalenza significa, per prima cosa, rilevare il matching e la coincidenza dei dati in corrispondenza del pattern di chiavi su cui si opera. Ciò può sembrare addirittura banale quando il processo di aggregazione si impernia su campi nei quali il contenuto informativo è rappresentato da un codice. È abbastanza evidente che quando le variabili in gioco sono chiavi, per di più primarie, come il codice fiscale o il codice sanitario, due o più records si possono attribuire allo stesso soggetto solo e quando c'è perfetta coincidenza tra i valori delle due stringhe: anche un solo carattere diverso, per la natura e il significato stesso dei codici, deve far supporre che si tratti di individui distinti. Ma quando si lavora con campi il cui contenuto informativo ha un formato "descrittivo", come è nei casi di nome e cognome, è necessario ribaltare i termini del discorso e chiedersi: fino a che punto la discrepanza o la non "sovrapponibilità" delle stringhe è da imputarsi ad una effettiva e reale distinzione dei soggetti a cui si riferiscono? Oppure, viceversa, in che misura si possono tollerare "divergenze" nell'informazione anagrafica e ritenere due osservazioni riconducibili allo stesso paziente, senza incorrere nell'errore di identificare due soggetti di fatto distinti? È necessario, allora, a questo scopo introdurre il concetto di "metrica" e di "distanza fonetica" tra le stringhe e definire una funzione che sia in grado di misurare la verosimiglianza di due parole. Nella procedura di Soundex è stato appunto implementato un algoritmo che fa uso della funzione spedis (SAS/BASE), capace di valutare la "spelling distance" come un costo normalizzato risultante da una serie di operazione sulle lettere (cancellazione, inserimento, sostituzione, raddoppio, ecc.) da effettuare in sequenza per convertire uno dei due termini di confronto (keyword) nell'altro (query word). In dettaglio, per determinate coppie di records da confrontare (può trattarsi di due osservazioni dell'unico mega-archivio aggregato da clusterizzare, in caso di clustering sincrono, o di un osservazione proveniente da una delle banche dati da linkare e di un'altra presente nell'archivio validante nella quale si tenta il "riconoscimento" del paziente, in caso di clustering asincrono), la procedura di Soundex, tenendo fissa una delle due voci, genera per l'altra una sequenza di voci derivate, ottenute permutando in tutti i modi possibili le sottostringhe di cui è composta. Quindi valuta le distanze di spelling tra la prima voce e ciacuna di quelle derivate dalla seconda: la distanza minima viene considerata la misura di verosimiglianza tra i due records. L'esempio seguente illustra il concetto appena esposto:

Misura di verosimiglianza fonetica tra R1 e R2 = distanza minima = d(R1,R2₅) = 7

A questo punto, una volta definito il concetto di distanza tra due records in corrispondenza di uno o più campi, è possibile introdurre un valore di cut-off con cui discriminare i records "vicini" da quelli "lontani". Così facendo, in pratica, per ogni record viene definito un intorno circolare di raggio pari al valore di cut-off: tutti i records che da esso hanno una distanza inferiore a questo valore soglia e dunque cadono all'interno del suddetto cerchio vengono considerati dal punto di vista informativo, correlati ed equivalenti al record di riferimento e, quindi, sono candidati a finire nel suo stesso cluster di appartenenza; tutti gli altri che ne rimangono fuori, invece, sono da ritenere ad esso non omogenei e, quindi, potenzialmente, riconducibili a soggetti distinti.

Con questa logica, di fatto, il concetto di matching viene esteso ed assume un connotato meno rigido: il join tra due voci avviene non più solo quando c'è perfetta corrispondenza, ma anche quando la discrepanza tra di esse si mantiene entro limiti accettabili.
Dalla logica di funzionamento della procedura di Soundex appena descritta, risulta chiaro che i campi a cui essa è applicabile devono avere un formato alfanumerico, come si è già avuto modo di precisare in precedenza. La funzione SAS spedis esegue le sue manipolazioni sulle lettere o, più in generale, sui caratteri delle stringhe e, dunque, non è pensabile che possa agire su variabili numeriche: se si ritiene utile e vantaggioso applicare il Soundex a campi come la data di nascita, è necessario accertarsi che questa figuri come una stringa e, se così non fosse, è indispensabile provvedere alla necessaria riconversione di formato. Come detto, inoltre, la distanza fonetica è una grandezza normalizzata e il termine di standardizzazione è rappresentato dalla lunghezza della stringa: ciò appare anche abbastanza naturale dal momento che è plausibile che cambiamenti di lettere in parole brevi abbiano un peso superiore rispetto alle medesime variazioni in stringhe più lunghe. Proprio per far fronte a ciò, onde poter accettare anche minime discrepanze tra stringhe corte, senza per questo dover aumentare eccessivamente il valore della distanza di cut-off (con il rischio, che ciò comporterebbe, di "appiattimento" dell'informazione), può risultare consigliabile, quando ciò non accada già in origine, comporre campi singoli, come nome e cognome, in uno combinato ed unico e riferirsi a questo come variabile da utilizzare, in generale, nell'ambito dell'intera procedura di clusterizzazione ed, in particolare, in seno alla procedura di Soundex. Tornando all'esempio precedente, se il nome fosse stato considerato separatamente, la distanza minima tra i due records, ossia la misura di verosimiglianza fonetica, sarebbe quasi raddoppiata:

Non si tratta ancora di una distanza particolarmente rilevante, ma di fronte a livelli di cut-off minimi, questi due records sarebbero valutati come potenzialmente non correlati. In generale l'uso di campi combinati e, dunque, la presenza di stringhe medio-lunghe conferiscono alla procedura di Soundex caratteristiche di maggiore "stabilità".
Un ultimo aspetto importante di cui bisogna tenere conto perché questo algoritmo possa operare con efficacia senza produrre effetti spuri indesiderati riguarda l'individuazione del set di records su cui operare il confronto mediante la procedura di Soundex. È chiaro che confrontare tutte le possibili coppie di records, oltre che essere improponibile dal punto di vista della complessità computazionale e dei tempi di calcolo difficilmente gestibili soprattutto con archivi di enormi dimensioni, è alquanto pericoloso dal momento che porterebbe ad “incrociare”, tra l'altro, stringhe molto vicine tra di loro anche se relative, senza ombra di dubbio, a soggetti diversi, come illustrato dal seguente esempio:

Allora la procedura di Soundex limita la ricerca dei records su cui valutare le reciproche distanze in quel set di osservazioni che le chiavi con più alto livello di priorità (rispetto a quella in cui figura il campo sul quale si sta applicando l'algoritmo) hanno già segnalato come potenzialmente correlate dal loro contenuto informativo e la cui eventuale vicinanza fonetica, quindi, andrebbe interpretata legittimamente come un'ulteriore conferma del loro grado di apparentamento. Questo evidenzia, allora, l'importanza di limitare l'uso della procedura di Soundex ai campi di quelle chiavi che non solo abbiano le caratteristiche finora descritte, ma che, per loro natura, non denotino un carattere di univocità, e, per ruolo svolto nell'ambito della procedura di clusterizzazione, abbiano un livello di priorità di secondo piano. Il Soundex, quindi, si rivela uno strumento estremamente potente, ma, allo stesso tempo, delicato, che va usato col dovuto equilibrio, bilanciando in maniera opportuna i parametri di input messi a disposizione dalla routine ReClust (scelta della variabile da sottoporre a Soundex, attribuzione del livello di priorità della corrispondente chiave, definizione della distanza di cut-off).
Ricapitolando, i concetti basilari su cui poggia la procedura di Soundex sono i seguenti:

  Nozione di metrica e distanza di spelling;

  Misura di verosimiglianza fonetica;

  Distanza di cut-off;

  Scelta di campi combinati, alfanumerici e non univoci da sottoporre a Soundex;

  Attribuzione di un basso livello di priorità alle corrispondenti chiavi.

3.4) Assegnazione dei codici di chiave  

Una volta selezionate le chiavi e, soprattutto, definite le modalità con cui esse intervengono nell'individuazione del legame informativo tra i records, per raggiungere lo scopo finale di partizionamento delle osservazioni in classi di equivalenza, è necessario attribuire loro dei codici numerici che, in qualche maniera, rappresentino l'effetto, momentaneo e parziale, dell'azione clusterizzante operata singolarmente e autonomamente da ciascuna chiave. Tali codici, con il loro valore, costituiscono, in altri termini, il marchio che ogni chiave lascia sul record come risultato dell'operazione di matching che la routine ReClust affida a ciascun pattern multicampo: sulla base di questo responso, ogni singolo record, di fatto viene potenzialmente assegnato a dei raggruppamenti temporanei che rappresentano il punto di partenza per l'attribuzione ai clusters finali, che avverrà solo attraverso l'azione combinata e alternata delle chiavi, regolata dai loro livelli di priorità, descritta nel paragrafo 3.2. L'assegnazione dei codici di chiave ai records non è, come può sembrare, un'operazione superflua o ridondante: infatti, essa non consiste semplicemente nell'attribuire lo stesso valore del codice di chiave esclusivamente alle sole osservazioni che presentano il medesimo responso informativo in corrispondenza di quel pattern di variabili; al contrario, coerentemente alla novità interpretativa (introdotta dalla procedura di Soundex) del concetto di matching, inteso non più solo come coincidenza tra voci, ma come equivalenza tra stringhe, il medesimo valore del codice di chiave viene esteso anche a tutti quei records che, seppur discordanti, si rivelano non eccessivamente distanti in termini di verosimiglianza fonetica e, quindi, secondo i criteri dell'algoritmo di Soundex, annoverabili nello stesso raggruppamento. Nello schema seguente viene illustrato con un esempio l'idea appena descritta:

L'assegnazione del codice di chiave viene ripetuta, come è logico, per ciascuna delle chiavi che sono state definite, a partire da quella con più alto livello di priorità, per finire con quella a cui è stata assegnata priorità inferiore. Alla fine, quindi, ciascun record è contraddistinto da tanti codici quante sono le chiavi ed è prevedibile che i raggruppamenti che ciascuno di essi individua non si sovrappongano mai in maniera coerente, cosa che avverrebbe solamente nella situazione puramente teorica ed ideale di banche dati dal contenuto informativo completo e qualitativamente perfetto. In ogni caso, una volta generati i codici di chiave, la routine ReClust abbandona definitivamente l'uso dei campi anagrafici su cui aveva finora lavorato e prosegue da questo momento nell'operazione di clusterizzazione affidandosi solo ed esclusivamente a questi codici, i quali racchiudono in sé, dal punto di vista informativo, tutto ciò che è necessario e indispensabile per poter raggiungere l'obiettivo finale.
L'assegnazione dei valori dei codici di chiave viene realizzata, inoltre, in modo da discriminare i records non solo in base al raggruppamento in cui vengono inseriti, ma anche in funzione del contributo e dell'attendibilità informativa che essi possono garantire nella fase di generazione dei clusters finali. A questo scopo, viene utilizzato il valore nullo per contraddistinguere le osservazioni che presentano valore mancante nella chiave multicampo a cui il codice si riferisce: queste, dunque, sono raccolte in un'unica classe (contrassegnata dal valore 0) nella quale sono accomunate non dalla omogeneità informativa, ma piuttosto dall'incompletezza del dato e, quindi, dall'impossibilità di influenzare l'attribuzione ad un determinato cluster almeno attraverso la chiave in questione. Col valore negativo, nel solo caso in cui si utilizzi una banca dati con funzione di supporto informativo anagrafico a cui si affida la funzione di riconoscimento e validazione del dato, viene, invece, contraddistinto il record che attraverso la chiave in questione non trova riscontro in seno a questo archivio, né in termini di verosimiglianza fonetica né tantomeno mediante un matching completo. Questa volta, però, assegnando un diverso valore (< 0) del codice di chiave per i diversi raggruppamenti di records, accomunati solo dal fatto di non essere riconosciuti nell'archivio validante, ma comunque distinti dal punto di vista del contenuto informativo, si continua a salvaguardare la distinzione tra le varie classi di appartenenza: il segno negativo del codice di chiave "segnala" semplicemente che quel raggruppamento con quella chiave non è stato identificato dalla banca dati anagrafica, ma il suo valore assoluto ne consente in ogni caso l'individuazione. Quest'ultimo aspetto evidenzia, inoltre, come le modalità di assegnazione dei valori dei codici di chiave siano diverse a seconda che si disponga o meno di un archivio validante ed è proprio in ragione di ciò che poi, all'atto della costruzione dei clusters finali, si avrà, a seconda dei casi, una identificazione assoluta o relativa del paziente. Nel caso di indisponibilità di una banca dati anagrafica di riferimento, la routine ReClust, come si è detto, agisce in generale sul mega-archivio ottenuto disponendo in sequenza i flussi informativi da linkare ed è sull'insieme di questi records che provvede alla generazione dei valori dei codici in corrispondenza di ciascuna chiave. Molto semplicemente, per ogni pattern multicampo un indice numerico positivo viene progressivamente incrementato ogni qual volta risulta individuato, secondo la logica ampiamente descritta in precedenza, un raggruppamento omogeneo di osservazioni e il valore ottenuto viene così assegnato ad ogni singolo record: fanno eccezione come anticipato le sole osservazioni che presentano valore mancante in corrispondenza della chiave, per le quali il codice assume sistematicamente valore nullo. Alla fine del processo iterativo, composto da tanti cicli quante sono le chiavi, ogni record ha associato un numero corrispondente di codici, ciascuno di valore diverso, che determinano la sua appartenenza ai vari raggruppamenti individuati dalle singole chiavi. Riprendendo l'esempio precedente e assumendo di lavorare su due archivi (DB=1 e 2) e di avere scelto le tre chiavi Codice sanitario (K₁), Codice fiscale (K₂) e Cognome e nome - Data di nascita - Sesso (K₃), una possibile situazione finale non si discosterebbe di molto dal seguente schema:

Nel caso, invece, in cui si disponga di una banca dati anagrafica utilizzata per la validazione dei flussi informativi in esame, il processo di assegnazione dei codici di chiave, a prescindere dalla modalità sincrona o meno della procedura di clusterizzazione, avviene all'atto del confronto tra il singolo record e l'archivio validante. Nell'ipotesi in cui esso venga "riconosciuto" o perché foneticamente simile alla voce presente nell'anagrafe di riferimento o addirittura attraverso un matching completo con essa, l'osservazione "eredita" in corrispondenza della chiave, in quel momento in azione, il codice paziente che preventivamente, in fase di inizializzazione, la routine ReClust ha provveduto ad assegnare in maniera univoca ad ogni record dell'archivio validante. Solo nell'eventualità contraria in cui il record non trovi riscontro nell'anagrafe, allora, all'osservazione viene assegnato il valore corrente di un indice numerico, questa volta negativo, che, nel frattempo, si procede opportunamente a decrementare per ogni nuovo raggruppamento omogeneo non identificato nell'archivio validante. Ciò avviene per tutti quei records nei quali il dato è presente in corrispondenza della chiave in questione; per tutti gli altri, invece, caratterizzati da incompletezza informativa, il valore del codice di chiave, così come accadeva in precedenza, viene impostato automaticamente a 0. Anche adesso l'operazione è ripetuta ciclicamente tante volte quante sono le chiavi, così da attribuire a ciascuna osservazione un corrispondente numero di codici di chiave: ora, però, ed è questa la novità rispetto al caso in cui non si disponeva di supporto informativo anagrafico, se ciascuna chiave ha assicurato attraverso l'archivio validante un riconoscimento coerente ed univoco, i valori dei codici di chiave coincideranno tra di loro, creando così le premesse per l'identificazione assoluta del cluster. Se nell'esempio precedente si fosse utilizzato un archivio validante applicato in maniera asincrona ai due databases, si sarebbe ottenuto un risultato molto simile a quanto illustrato nello schema seguente:

In entrambi i casi, come già anticipato, i codici di chiave così ottenuti condensano tutto il contenuto informativo necessario per procedere alla individuazione (relativa o assoluta) dei clusters finali e permettono in tal modo alla routine ReClust di abbandonare l'uso dei campi anagrafici che da questo momento in poi non intervengono più nella procedura di clusterizzazione.
Ricapitolando, i punti salienti che caratterizzano la logica di generazione e assegnazione dei codici di chiave sono i seguenti:

  Attribuzione di valori in base alla omogeneità informativa dei records;

  Generazione di valori nulli o negativi per records incompleti o non riconosciuti;

  Creazione di tanti codici quante sono le chiavi in uso;

  Assegnazione di codici assoluti o relativi in presenza o meno di archivio validante;

  Abbandono dell'uso dei campi anagrafici nel prosieguo della clusterizzazione.

3.5) Individuazione e identificazione del cluster  

Una volta valutato l'effetto clusterizzante attribuibile all'azione autonoma e separata di ogni singola chiave, la routine ReClust può finalmente procedere alla costruzione dei clusters finali in cui raccogliere i vari records sulla base del responso derivante dall'azione combinata, concomitante e alternata, delle chiavi. Secondo quanto già descritto nel paragrafo 3.2, in base al livello di priorità assegnato loro, le chiavi, attraverso i loro codici, da cui, a questo punto, sono contraddistinte, sono chiamate a fornire l'indicazione definitiva su come ripartire le osservazioni in classi, operando, questa volta, in maniera simultanea e secondo delle regole e priorità che ne disciplinano l'intervento. Si è detto in precedenza che l'attribuzione dei records ai clusters avviene in modo iterativo nel corso di cicli ricorsivi il cui numero complessivo è legato esponenzialmente a quello delle chiavi. In ciascuno di essi è chiamato ad operare un pattern diverso sia per dimensione (numero di chiavi) che per costituzione (identità delle chiavi coinvolte): in particolare se N indica il numero delle chiavi, in corrispondenza del generico ciclo la struttura del pattern è la seguente:

    ciclo i-esimo

dove m varia regressivamente da N a 1 e il generico indice può assumere valore compreso tra 1 e N. Considerando che per ogni valore di m (iterazione principale) è possibile individuare    patterns m-dimensionali (iterazioni secondarie), alla fine si hanno 2^N- 1 cicli in cui si susseguono tutte le possibili combinazioni a gruppi di m delle N chiavi. In ciascuno di essi la routine ReClust prende in esame i raggruppamenti di records individuati nella fase precedente da ognuna delle m chiavi coinvolte e ne valuta la rispettiva congruità e corrispondenza: quelle classi che risultano perfettamente "allineate" sulle m chiavi, nelle quali, cioè, ciascun codice di chiave (con valore positivo) si mantiene costante per tutte e sole le osservazioni in corrispondenza delle quali lo sono tutti gli altri codici, vengono elette automaticamente a cluster in quanto rappresentano chiaramente aggregazioni omogenee di records che tutte le m chiavi in gioco hanno saputo coerentemente riconoscere (individuazione del cluster). La sua identificazione, invece, cioè l'attribuzione di un codice d'identità, in base alla stessa logica seguita a suo tempo per i codici di chiave, avviene con modalità diverse a seconda che si disponga o meno del supporto informativo di un archivio validante: in caso negativo, così come allora, viene assegnato come codice di cluster il valore di un indice positivo, appositamente incrementato ogni volta che viene identificata una nuova classe, con il quale è possibile ottenere l'identificazione relativa del cluster; nell'eventualità in cui, invece, si utilizzi una banca dati di riferimento anagrafico, allora, per quanto è stato detto in precedenza, i vari codici di chiave, che hanno ereditato dall'archivio validante un valore univoco rappresentativo del paziente, non solo risultano costanti sul cluster in questione, ma presentano un valore comune perfettamente identico che, quindi, automaticamente viene trasferito alla classe appena individuata (identificazione assoluta del cluster). Nello schema seguente, viene illustrata con un'esempio questa duplice possibilità (si suppone di operare in corrispondenza dell'iterazione che coinvolge un pattern bidimensionale costituito dalle chiavi K₁ e K₃):

Una possibile variante al meccanismo di identificazione del cluster appena descritto può essere introdotta innalzando il peso di alcune chiavi a cui si ritiene utile affidare una "forza clusterizzante" superiore a quella che si riuscirebbe a garantire loro attraverso il solo livello di priorità: in questo modo, senza alterare l'ordine di intervento delle chiavi nel processo iterativo, si ammette che una chiave "valorizzata" possa intervenire, seppure con un contributo passivo ed esterno, anche in tutti i passi del processo ricorsivo in cui essa rimane esclusa dal pattern m-dimensionale a cui è affidato il ruolo attivo di definizione delle classi. In particolare, se il cluster potenzialmente individuato dal gruppo delle m chiavi chiamate ad operare raccoglie un gruppo di osservazioni di numerosità inferiore rispetto al raggruppamento in cui la chiave valorizzata è riuscita singolarmente ed autonomamente ad aggregarle, allora essa, appellandosi ad una sorta di "diritto di veto" conferitole con l'innalzamento del suo peso relativo, ha la facoltà di bloccare l'identificazione di quel cluster (e quindi di salvaguardare l'integrità del suo raggruppamento) differendolo, nella migliore delle ipotesi, al ciclo successivo:

Nello schema precedente viene illustrata con un semplice esempio una tipica situazione che comunemente si presenta nel processo di clusterizzazione. Si supponga di disporre di 3 chiavi K₁, K₂ e K₃, con priorità rispettivamente alta media e bassa, di trovarsi nel quinto dei 7 cicli previsti, quando è il turno della chiave K₁ (pattern monodimensionale) ad intervenire nella definizione dei clusters e di aver attribuito alla sola chiave K₃ un peso relativo superiore; allora, il pattern costituito dalla chiave K₁, agendo dal canto suo secondo i criteri di sua competenza, sarebbe indotto a costruire 4 clusters, il primo comprendente il record R₁, il secondo i records R₂, R₃ e R₄, il terzo il record R₅ e il quarto il record R₆: si tratterebbe, però, di tutti clusters di numerosità inferiore ai due raggruppamenti che la chiave valorizzata K₃ saprebbe garantire in corrispondenza dei sei records. Allora in virtù del potere conferitole, la chiave K₃ non dà il via libera all'individuazione dei 4 clusters, ma, e questo è importante, non ha neppure la facoltà di imporre i suoi due raggruppamenti come clusters finali, perché ciò significherebbe un ribaltamento del livello di priorità delle chiavi e, dunque, del loro ordine di intervento nel processo di clusterizzazione (che, in generale, è inviolabile e, in particolare, non modificabile da un peso relativo superiore): pertanto, l'aggregazione dei sei records è rimandata al ciclo successivo, quando è chiamata ad intervenire la chiave K₂, la quale, riuscendo a prospettare una classe unica capace di raccogliere addirittura tutte e sei le osservazioni, ottiene semaforo verde dalla chiave valorizzata K₃ e, dunque, procede all'individuazione del cluster; solo nell'ipotesi in cui neppure in questo passo si fossero configurate le condizioni necessarie per l'aggregazione dei records, sarebbe stato necessario rimandare tutto all'iterazione finale, quando, essendo il suo turno, la chiave K₃ risulterebbe, solo allora, pienamente legittimata a proporre ed ottenere la promozione a clusters dei suoi due raggruppamenti.
Terminata la fase iterativa costituita dai 2^N - 1 cicli, la maggior parte dei records risultano raggruppati nei loro clusters di competenza. È possibile, però, che una minoranza di osservazioni non risulti attribuita a nessuna classe, in quanto, presumibilmente, durante il processo ricorsivo vincoli stringenti e veti incrociati non hanno creato i presupposti indispensabili per definire in maniera netta ed incontrovertibile la loro appartenenza. Queste osservazioni, dette records residuali, a seconda del segno dei valori dei codici di chiave, possono essere di varia natura e corrispondentemente, avranno un trattamento diverso nel momento in cui andrà stabilito il loro destino. Si possono avere tre diverse categorie di records residuali:

a) records con valore positivo in almeno uno dei codici di chiave;

b) records con valore nullo in tutti i codici di chiave;

c) records con valori negativi o nulli dei codici di chiave.

Nel caso a) si tratta di osservazioni che sono rimaste escluse da tutti i clusters finora creati perché evidentemente in nessuno dei cicli della fase iterativa hanno saputo soddisfare i criteri e le specifiche prima descritte che regolano la ripartizione dei records in classi: molto probabilmente sono quelle osservazioni, parzialmente incomplete dal punto di vista informativo, che derivano dalla "frammentazione" dei raggruppamenti inizialmente individuati dalle chiavi a più basso livello di priorità, che, per effetto dell'azione combinata e preminente di patterns di chiavi con priorità superiore, si sono "frantumati" liberando records spuri che successivamente nessuna altra chiave o pattern di chiavi è stato in grado di raccogliere e aggregare:

In quest'esempio il pattern bidimensionale di chiavi K₁, K₂ aggrega in un unico cluster i records R₁ e R₂ lasciando spaiato il record R₃, che la chiave K₃ aveva, invece, inserito in un unico raggruppamento temporaneo insieme con R₂: quindi, R₃ non può più essere recuperato, almeno durante questa fase iterativa, né dalle chiavi K₁ e K₂ che, nei passi successivi del processo ricorsivo, chiamati ad agire come patterns monodimensionali, non sono in grado di assegnarlo ad un nuovo cluster a causa della incompletezza informativa dell'osservazione, né dalla chiave K₃ che si ritrova il suo raggruppamento, originariamente individuato, ormai frammentato (R₂ è stato già assegnato) e quindi non più proponibile ad essere eletto come cluster finale. Allora, records residuali come questo, alla fine della fase iterativa, vengono ridistribuiti nei clusters già costruiti in base alla comunanza informativa che mostrano di avere con quelle osservazioni che, al contrario, vi hanno già trovato collocazione: la ricerca dei records “apparentati” e, quindi, indirettamente, delle classi più idonee ad accogliere i residuali, avviene, ancora una volta, attraverso una procedura ciclica costituita da un numero variabile di passi, non superiore, in ogni caso, al numero delle chiavi, durante la quale, procedendo secondo l'ordine stabilito dal livello di priorità delle chiavi, si prova ad individuare il record o i records che in corrispondenza del codice di chiave in esame abbiano lo stesso valore (positivo) del residuale. Una volta trovata la corrispondenza, il processo ricorsivo si interrompe e l'osservazione residuale, come in una specie di effetto domino, viene assegnata al cluster di appartenenza del record a cui è accomunato, acquisendo, a pieno titolo, il diritto di cittadinanza in quella classe, di cui eredita il codice identificativo. Nell'esempio precedente, dopo i due tentativi affidati alle chiavi K₁, K₂ e risultati vani per l'incompletezza informativa su quei campi del record residuale R₃, è K₃ che, rilevandone il legame con R₂ in corrispondenza del suo codice di chiave, estende i confini del cluster precedentemente definito dal pattern bidimensionale K₁, K₂ e comprendente già R₁ e R₂ e ne crea uno più ampio capace di abbracciare anche il nuovo elemento R₃.
Nel caso b), invece, si ha a che fare con tutte quelle osservazioni che sono incomplete, dal punto di vista informativo, in corrispondenza di tutti i gruppi di campi scelti per la procedura di clusterizzazione, e che, quindi, essendo prive dell'elemento basilare per il conseguimento di qualunque obiettivo di aggregazione, ossia il dato, risultano irrimediabilmente escluse da ogni tentativo di raggruppamento. Pertanto, ad esse non viene assegnato nessun valore del codice di cluster che, dunque, resta indefinito e, di conseguenza, non consente alcun coinvolgimento di questi records nella successiva eventuale fase di linkage e di integrazione dell'informazione.
Il caso c) si può verificare, per quanto detto in precedenza, solo nell'eventualità in cui nella procedura di clustering intervenga una banca dati anagrafica alla quale si assegni funzioni di archivio validante. In questa ipotesi, quando un record non viene riconosciuto in seno a tale base di dati di riferimento attraverso nessuna delle chiavi di clustering, tutti i corrispondenti codici di chiave assumono valori negativi o, tutt'al più, nulli in caso di assenza del dato. Le osservazioni con queste caratteristiche non vengono prese in considerazione nel processo iterativo di individuazione e identificazione dei clusters affidato all'azione combinata e alternata delle chiavi, nel quale ad essere esaminati sono i soli records contraddistinti da almeno un valore positivo nei corrispondenti codici: infatti, solo in questo caso, tale valore, essendo rappresentativo del soggetto ed essendo stato ereditato dall'archivio validante, può essere così trasferito al cluster al momento della sua individuazione e utilizzato come codice di identificazione assoluto. I records residuali, caratterizzati, invece, da codici di chiave negativi, non possono garantire un meccanismo di aggregazione e soprattutto di identificazione basato su questo principio; essi, segno negativo a parte, possono semmai essere regolati in fase di clusterizzazione da criteri simili a quelli che disciplinano e governano la ripartizione in classi in assenza di banca dati validante, quando le osservazioni sono contraddistinte da valori dei codici di chiave ottenuti attraverso l'incremento di un indice progressivo e, quindi, non derivanti da una fonte oggettiva e assoluta e, in quanto tali, utilizzabili solo per un'identificazione relativa del cluster. Allora, per l'aggregazione di questi records residuali si procede con una nuova applicazione del processo iterativo affidato ancora ai diversi patterns di chiavi e regolato da modalità del tutto analoghe a quelle che non prevedono, appunto, l'uso di un archivio di riferimento: il risultato finale consiste, diversamente dal punto a), non nella semplice ridistribuzione delle osservazioni residuali in classi già costruite, ma nella produzione di nuovi clusters che, però, rispetto a quelle di prima generazione, risultano non validate: è per questo motivo che, proprio per rimarcarne la diversa origine e differente valenza, si preferisce non assegnare loro un codice identificativo, ma ci si limita a segnalarne l'identificazione. Va detto, infine, che i records residuali che anche dopo questa fase risultino non assegnati ad alcuna classe, vengono, questa volta, ridistribuiti, secondo le modalità descritte nel punto a), tra i clusters appena creati o, su preciso input esterno, anche nell'ambito di quelli di prima generazione.
Terminata finalmente la fase vera e propria di clusterizzazione, la routine ReClust provvede a fornire anche uno strumento per poter valutare il livello di affidabilità, qualità e completezza dei clusters così ottenuti. Anche in questo caso, lo scenario è diverso a seconda che si disponga o meno di un archivio validante. Quando non si utilizza un supporto informativo anagrafico di riferimento, l'algoritmo si limita a qualificare la composizione di ogni singolo cluster individuato e, in particolare, per ciascuna chiave che ha contribuito al clustering viene fornita l'indicazione di omogeneità, disomogeneità, completezza o incompletezza informativa della classe; in dettaglio:

  col simbolo 1 è indicata perfetta omogeneità del cluster, nel senso che il valore del codice di chiave si mantiene costante su tutta la classe;

  col simbolo 0 è indicata disomogeneità più o meno spiccata, nel senso che il valore del codice di chiave varia nella classe, assumendo valore diverso in corrispondenza di due o più records;

  col simbolo X è indicata assenza totale d'informazione (su quella chiave) e il corrispondente codice assume valore nullo;

  col simbolo Y è indicata incompletezza informativa parziale, nel senso che in alcuni records del cluster il dato è mancante (valore del codice nullo), mentre nelle rimanenti osservazioni è omogeneo (valore del codice costante).

In presenza, invece, di una banca dati di riferimento, l'informazione fornita non è solo relativa alla composizione del cluster, bensì è indicativa anche del livello di appropriatezza dell'appartenenza del generico record a quella classe e, quindi, misurando, oltre che la completezza informativa, anche il grado di congruità dell'appartenenza dell'osservazione in corrispondenza di ciascuna chiave, si configura più come una grandezza specifica del record che del cluster; in dettaglio:

  col simbolo 1 è contrassegnato il record che legittimamente è inserito in quella classe, nel senso che esso, attraverso la chiave di riferimento, è stato riconosciuto nell'archivio validante proprio nel soggetto con cui poi viene identificata la classe (valore del codice di chiave uguale al valore del codice di cluster);

  col simbolo 0 è contraddistinto il record che, attraverso la chiave di riferimento, non ha avuto riscontro in seno all'archivio validante e, dunque, è inserito in quella classe solo per l'effetto dell'azione delle altre chiavi (valore del codice di chiave negativo e, quindi, necessariamente diverso dal valore del codice di cluster);

  col simbolo Ø è indicato il record che appartiene illegittimamente a quella classe, nel senso che nell'archivio validante è stato riconosciuto in un soggetto diverso da quello con cui, per effetto delle altre chiavi, è stata identificata la classe (valore del codice di chiave positivo, ma, comunque, diverso dal valore del codice di cluster);

  col simbolo X è contrassegnato il record che è caratterizzato da incompletezza del dato in corrispondenza della chiave di riferimento e la cui appartenenza alla classe è stata decretata dal contributo informativo delle altre chiavi (valore del codice di chiave nullo).

A questo punto la routine ReClust è in grado di restituire in output, nella loro forma originaria e in maniera del tutto trasparente, gli archivi che sono stati sottoposti alla sua azione clusterizzante. L'informazione aggiuntiva rappresentata dal codice di cluster consente di individuare all'interno di ogni banca dati il soggetto-paziente a cui si può far risalire ciascun record-evento e, in più, grazie alla sua natura di codice identificativo, esso assume il ruolo di chiave di linkage per l'integrazione dei diversi flussi informativi. Non solo: proprio per effetto della sua caratteristica di univocità, tale codice consente di eliminare nei sistemi integrati ottenuti qualunque riferimento anagrafico al paziente e, nel pieno rispetto delle norme che mirano alla salvaguardia della privacy, assicura il totale anonimato del soggetto di riferimento.