Your SlideShare is downloading. ×
HL7 - S. Lotti - exposanità - L'uso pratico degli standard. architetture e working interoperability
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

HL7 - S. Lotti - exposanità - L'uso pratico degli standard. architetture e working interoperability

2,298
views

Published on

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

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,298
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
56
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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