Presentazione Hl7 Italia ad Exposanità nel convegno "l'Interoperabilità dei Sistemi Informativi Sanitari" del 26 Maggio 2010 organizzato da School of Management - Politecnico Di Milano

1. L'uso pratico degli standard.
Architetture e Working Interoperability
Stefano Lotti
HL7 Italia Chair
Workshop: “L’Interoperabilità dei Sistemi Informativi in Sanità”, 26 maggio 2010
c/o Bologna 26 ‐ 29 maggio 2010
c/o Bologna 26 ‐ 29 maggio 2010

2. Trasformazione
«Il mondo è tutto ciò che accade»
Ludwig Wittgenstein

3. • L’informatica, nasce come strumento
Le origini
per automatizzare
• Il primo computer digitale (UK 1943)
serviva a decriptare in poche ore i
messaggi cifrati tedeschi (a mano
richiedeva settimane). Ha
probabilmente ridotto la durata della
guerra di due anni e fu secretato fino
agli anni 70. L’ENIAC (USA) seguì nel
1946.
Colossus 1943 (UK)
• Fondamentalmente tutta l’era dei
mainframe aveva questa struttura:
vi è un organizzazione data,
vi è un CED (un pezzo
dell’organizzazione) a cui viene
affidata l’elaborazione delle
informazioni (con il computer)
I risultati sono stampati su tabulati
che vengono consegnati
all’organizzazione
• L’informatica è quindi un aggiunta ENIAC 1946 (USA)
all’organizzazione così come essa è.

4. Dal PC ad Internet
• A partire dall’75 comincia ad emergere l’informatica
contemporanea: appare il PC e si diffonde sempre più
velocemente Internet
• L’evoluzione tecnologica e la sua diffusione nelle
organizzazioni è incredibilmente rapida. (nasce
l’”internet time”: un anno internet è uguale a sette
vecchi anni)
• Tuttavia la cultura organizzativa rimane
sostanzialmente ferma, anche se dalla seconda metà
del secolo le organizzazioni sono divenute sempre più
estese e parcellizzate con procedure e processi
sempre più complessi
• Come osserva Finkelstein: «I processi sono stati
automatizzati, ma abbiamo preso i processi manuali
e li abbiamo automatizzati essenzialmente AS‐IS:
senza molti cambiamenti. Cosi i processi
automatizzati sono eseguiti nello stesso modo dei
processi manuali ma più velocemente e più
accuratamente. Facendo così’ siamo passati dal caos
manuale … al caos automatizzato!»
(C. Finkelstein, Enterprise Architecture for Integration, 2006)
• Ancora oggi si sente spesso parlare di “supporto
informatico” Altair 1975

5. L’impasse
• Nonostante l’evoluzione tecnologica
fondamentalmente l’approccio rimane lo
stesso delle origini:
identificazione dei task da
automatizzare
Definizione dei requisiti
Realizzazione di un applicazione che
automatizzi lo specifico task o parte Genera
di un processo
• L’IT delle organizzazioni diviene un
accumulo di “silos” applicativi che
disordinatamente supportano gli specifici
task
• Gli sprechi economici (funzioni replicate in
più applicazioni, disallineamento dei dati,
difficoltà di integrazione, continuo
rifacimento delle soluzioni) e le difficoltà di
gestione (le organizzazioni in genere non
sanno più nemmeno quante sono le loro
applicazioni) appaiono sempre più evidenti
• Tuttavia emerge progressivamente la
consapevolezza che non sono questi
problemi dell’ex‐CED ad essere centrali “accidental architecture”
(anche se hanno un importante impatto
economico)

6. • Progressivamente è divenuto
evidente che l’informatica ha oramai
«Cyberspace is always a social space» (F. Flores 1997)
pervaso le organizzazioni al punto che
non è più considerabile come “un
aggiunta”
• Con la rete, l’informatica si trasforma
in un nuovo medium di
comunicazione (uno spazio sociale
vitale per le persone e gli affari) non
serve più ‘solo’ a fare elaborazione di
dati
Mappa di internet 2005
• Ivar Jacobson definisce un sistema
complesso come una: «collezione di
risorse organizzate in una gerarchia
verticale multilivello in cui la
produzione di valore è il risultato
dell’esecuzione di processi orizzontali
che attraversano il confini
organizzativi verticali»
(The Object Advantage)
• La sanità è un sistema complesso di
questo tipo e non riesce a
sopravvivere nel “caos
automatizzato” (anche se spesso è
vicino ancora al “caos manuale”).
D’altro lato le tecnologie hanno
simultaneamente raggiunto una
maturità tale da cambiare
l’approccio tradizionale

7. • Progressivamente è divenuto
evidente che l’informatica ha oramai
«Cyberspace is always a social space» (F. Flores 1997)
pervaso le organizzazioni al punto che
non è più considerabile come “un
aggiunta”
• Con la rete, l’informatica si trasforma
in un nuovo medium di
comunicazione (uno spazio sociale
vitale per le persone e gli affari) non
serve più ‘solo’ a fare elaborazione di
dati
Mappa di internet 2005
• Ivar Jacobson definisce un sistema
complesso come una: «collezione di
risorse organizzate in una gerarchia
verticale multilivello in cui la
produzione di valore è il risultato
dell’esecuzione di processi orizzontali
che attraversano il confini
organizzativi verticali»
(The Object Advantage)
• La sanità è un sistema complesso di
questo tipo e non riesce a
sopravvivere nel “caos
automatizzato” (anche se spesso è
vicino ancora al “caos manuale”…).
D’altro lato le tecnologie hanno
simultaneamente raggiunto una
maturità tale da cambiare
l’approccio tradizionale

8. L’organizzazione come software
• Il principale punto di
cambiamento è
considerare le tecnologie
non più come strumento
per “automatizzare” ma
come medium e parte
della rete di impegni
(network of commitment)
che costituisce un
organizzazione
• Cambia in modo radicale il
modo in cui vediamo
“l’informatica” (che
diventa nel frattempo
Information Technology).
• L’idea di realizzare
applicazioni ce risolvono
singoli task e poi integrarle
(Liberamente tratto, con modifiche, da: Thomas Erl, SOA Principles of Service Design, 2008)
tratto, modifiche, da: Erl, Design,
task per task rende i
sistemi ingovernabili,
fragili, costosi ed inefficaci
«Le routines che qui parevano tanto solide si scioglieranno
(non risultano
come lacrime … se le abbracceremo, ci scioglieremo con esse» effettivamente allineati ai
(Bruce Sterling, Schismatrix, 1985) processi).

9. SOA
• Le SOA permettono, da un lato, di
integrare le applicazioni esistenti (è la
loro forza) e da un altro lato tendono a
dissolvere i concetto di applicazione in
termini tradizionali
• Quello che l’utente percepisce come
UN applicazione è una composizione di
servizi interni ed esterni
(Tratto da, D.Krafzig – D. Slama - K.Banke,
da, K.Banke,
all’organizzazione Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004)
Service- Practices,
• “Un tempo” si definiva un
organizzazione e poi si realizzavano una
serie di applicazioni di supporto
indipendenti.
• Oggi il disegno dell’organizzazione e
quello delle architetture software
divengono esplicitamente parte dello
stesso sistema (design partnership).
• Il software è una rappresentazione
diretta dell’organizzazione (anzi ha
poco senso parlare di
“rappresentazione”)‫‏‬
• L’allineamento tra IT ed
organizzazione diviene indispensabile

10. Standard & cambiamenti culturali
• Gli standard assumono in
un ruolo diverso dalla
tradizione:
• Sempre più spesso non
sono più ex post (si fanno
dopo che una situazione di
routine si è stabilizzata) ma
sempre più ex‐ante
• Sono organizzati in famiglie
interrelate e complementari
(Tratto da HL7- SAIF, 2010)
HL7- SAIF,
• Usare un singolo standard/specifica (per il trasporto, per un certo messaggio, per un
linguaggio) non è del tutto inutile ma da risultati modesti. L’obiettivo è infatti la cosiddetta
Working Interoperability
• Il punto di vista rilevante non è più l’”applicazione” ed il singolo task ma l’organizzazione ed i
rapporti tra organizzazioni (→ le interfacce).
• Gli standard, in questo contesto, diventano parte del funzionamento del sistema (o almeno
di un sistema che funzioni) non sono qualcosa da rispettare per dovere o per gusto estetico
ma da usare, e bene, per necessità.
«E’ importante sottolineare che per parlare di Sanità Elettronica non è sufficiente
disporre di applicazioni informatiche standalone, ma è necessario che le
applicazioni siano tra loro interoperabili e permettano quindi l’effettivo passaggio
delle informazioni tra attori, senza interruzioni»
(da: TSE, Strategia Architetturale per la Sanità Elettronica)

11. Standard
«... il rigido all’indefinito,
il flessibile al compatto»
Vassily Kandinsky

12. Working
SAIF Working Interoperability: Stairway to Heaven
Interoperability Platform Specific
Model
Platform Independent
Model
Computational
Independent Model
Services-Aware
Interoperability
(Tratto da HL7- SAIF, 2010)
HL7- SAIF,
Framework
• Se l’interoperabilità non è più vista come singola integrazione deve venir realizzata da un
insieme di standard (di processo, di modellazione, sintattici, tecnologici) che generano
l’interoperabilità “nativa” in un sistema sociotecnico
• Non esiste alternativa visto che è evidente che, se non si adottano procedure e modelli
comunicabili, semplicemente si ottengono i soliti accumuli di silos ognuno con le proprie
interfacce, inconsistenti tra di loro.
• HL7‐SAIF (Services‐Aware Interoperability Framework) è un esempio di come costruire ed
organizzare, in modo sensato, le specifiche supportando l’architettura enterprise delle
organizzazioni (il SAIF è in corso di sviluppo avanzato e già utilizzato dal DOD, Canada
Infoway, National Cancer Insitute USA, NHS ed altri)
«The system IS the enterprise»
(John Zachman)

13. Enterprise Architecture Framework • Gli standard hanno un
SAIF ed EA
(es. OpenGroup TOGAF)
effettivo significato se
utilizzati in un architettura
enterprise
Es.
OpenGroup • Un applicazione che si
TOGAF 9 interfacci in modo standard
è completamente utile se è
inserita in un sistema
complessivo, sembra ovvio,
ma normalmente si fa il
contrario:
Usa
Si applica (se va bene)
un qualche standard in
un interfaccia e ci si
Services-Aware
Interoperability
Framework
attende che,
magicamente, questo
implichi che il sistema
stia insieme
Come se il fatto che i
mattoni abbiano più
meno la stessa
dimensione faccia, di
per se, far stare in
piedi un palazzo.

14. Enterprise Architecture & SAIF
EA Framework SAIF
The OpenGroup Architectural Framework (es.)
ADM ADM Modeling Levels Model Driven Reference Model
Archuitecture of Open Distributed
Processing
A
B
B
C
D
B
C
D
B
E
C
All
D
E
UML, BPMN, SoaML
• SAIF è progettato per integrarsi con framework di Enterprise
Architecture (es TOGAF) e prevede di utilizzare come riferimento
linguaggi di modellazione standard (UML, BPMN, SoaML)

15. • Le soluzioni nel mondo reale
sono parte di un architettura
Architetture
che non è meramente
tecnologica
• L’uso degli standard ha
realmente senso se riferito ed
organizzato rispetto
all’architettura del mondo
reale
• Architettura di Business,
Architettura dei Sistemi,
Architettura Tecnologica sono
“punti di vista” di un unico
sistema
• E’ evidente che senza un
approccio organizzato e
standardizzato
(tratto da: Mahesh Dodani: «Aligning IT to Business Through Architecture»,
da: Dodani: Architecture»
in Journal of Object Technology, vol. 7. no. 6, 2008)
Technology, (→ comunicabile) non
abbiamo speranza di ottenere
risultati sostenibili nel tempo.
• Un aspetto centrale è lo
“SOA as an initiative needs to be owned spostamento del centro dalla
tecnologia al business (la
by the business and not the IT”
tecnologia è vista come una
(OMG/HL7 HSSP, Practical Guide to SOA in Health Care,)
trasformazione
conseguente)

16. Stack di specifiche SAIF
es. EA Framework
+ SAIF
• In questo modo è effettivamente possibile avere uno stack di specifiche coerenti
ed i sistemi possono effettivamente funzionare ed evolvere in modo organizzato
sfuggendo agli insostenibili limiti dell’approccio task per task.

17. SAIF
Struttura del SAIF
• Lo schema seguente illustra (in modo semplificato) la struttura di SAIF
• Il framework permette quindi di organizzare in una “Unified field theory”
composta di standard diversi (non solo HL7) come OMG, ISO, OASIS, W3C
e di essere utilizzato in congiunzione con framework di Enterprise
Atchitecture (Togaf, Zachman, DODAF etc.)
• In un certo senso “le cose” sono le stesse (computer, programmi e
persone) ma il contesto è radicalmente cambiato.

18. Conclusioni
«Welcome to the real world»
Matrix

19. La struttura di una “Rivoluzione Scientifica” (Kuhn)
• Spesso tendiamo ad avere una immagine progressiva e continua del
cambiamento, tendiamo pensare che la questione sia solo la sua velocità.
• Nell’IT in generale (ma il discorso è ancor più vero, se possibile, in sanità) siamo
invece immersi in una Rivoluzione Scientifica nei termini di Thomas Kuhn
(vedi il noto “La Struttura delle Rivoluzioni Scientifiche”)
• E’ cambiato, radicalmente, il paradigma dell’IT contemporaneo: il centro non è
l’automatizzazione dei task ma l’organizzazione nel suo complesso e le sue
interfacce.
• Parliamo delle stesse cose ma in modo diverso ed il concetto di applicazione è
spinto verso la periferia delle nostre preoccupazioni (es. prima si fa
un’”applicazione” e dopo si vede come e dove “integrarla” caso per caso)
• Emergono approcci diversi e pratiche che un tempo erano secondarie
• I metodi e le pratiche si centrano invece sulle architetture e sulle loro interfacce
interne ed esterne (è la "services awareness“ di SAIF)
• E’ letteralmente un mondo diverso da quello tradizionale che richiede metodi
adeguati ed implica oggetti adeguati sia che siano nuovi o che siano una
riconsiderazione dei vecchi nel nuovo contesto reale.

20. Semiserio: Resistance is futile
«Strength is irrelevant. Resistance is futile. We wish to
improve ourselves. We will add your biological and
technological distinctiveness to our own. Your culture
will adapt to service ours.»
(Star Trek, The Next Generation, episode: "The Best of Both Worlds" )
HL7 Italia: www.hl7italia.it
HL7 Europe: www.hl7.eu
HL7 International: www.hl7.org