eHEALTH

SERVE UNA GOVERNANCE?

Stefano Lotti

HL7 International SOA WG Co-Chair (HSSP)

HL7 Italia CTO

Roma
22.02.2017
 HL7 International

 Fondata nel 1987, Health Level

Seven (HL7) International è Modelli funzionali
(e.g. EHR-S, Vital Sign)
l'autorità globale dedicata a fornire
un framework completo e i relativi FHIR resource
standard per lo scambio, HL7v3-CDA 2 Contenuti
l'integrazione, la condivisione e il
recupero delle informazioni sanitarie
HL7 v2 API
elettroniche che supporti la pratica
clinica, la gestione, il delivery e la Servizi (HSSP project con )
valutazione dei servizi sanitari. Servizi
SOAP FHIR (REST)
 Gli standard HL7 sono alla base di
tutti i programmi nazionali e
internazionali rilevanti di sanità
elettronica come, ad esempio,  In italia Il Modello Funzionale standard EHRS FM di HL7 Italia () e’
nell’Unione Europea, Regno Unito, incluso nelle specifiche FSE.
Olanda, Francia, Norvegia, Canada,  L’FSE e’ basato sulle Implementation Guide Standard di HL7 Italia
Australia, USA, etc.
 Sistema sanitario e Ultra Large Scale (ULS) systems

• Un aspetto evidente della sanità è la complessità intrinseca

del sistema:
• Ad esempio, ogni centro medico può avere una media di
venti/trenta programmi software, più quelli nascosti nei
dispositivi medici
• A questi vanno sommati quelli delle unità più piccole (es.
MMG/PLS)
• Questa complessità va moltiplicata per le organizzazioni
del sistema: ASL Ospedali, Residenze, Ambulatori,
MMG/PLS etc.
• A questo si somma l'attività di cura degli assistiti, le politiche e
l’organizzazione che le realizza ed i relativi sistemi software.
• Il risultato sono migliaia di programmi che devono lavorare
insieme tra loro e con migliaia (o milioni) di persone sparse
sul territorio
«La scala cambia tutto»
 Ultra-Large-Scale Systems: caratteristiche

 Gli ULSS sono strutturalmente decentralizzati Questa è una caratteristica

intrinseca degli ULSS

 I requisiti sono intrinsecamente in conflitto, non È quindi necessario

del tutto conoscibili e diversi armonizzarli continuamente

 Sono composti da elementi eterogenei, non Il sistema avrà sempre diversi

consistenti e in cambiamento continuo livelli di sviluppo al suo interno

 Erodono i confini tra persone e sistema Le persone non sono ‘utenti’

del sistema ne sono parte

 I guasti sono normali Un ULSS non sarà mai perfetto

 Richiedono, di conseguenza, nuovi modelli di Acquisizione e governance non

acquisizione e di governo assomigliano a quelli tradizionali
ULSS e API (Application Programming Interface)

 Con un sistema di questo tipo, ancora più che

con i sistemi tradizionali, non possiamo
sperare di avere risultati con linguaggi e dati
inconsistenti.
 le «API» (i linguaggi) devono essere uniformi
ma d’altra parte è illusorio pensare che le
cose funzionino con un approccio banalmente
centralizzato, top-down, all'interoperabilità
 Abbiamo quindi bisogno di un portafoglio di
standard flessibili, un ecosistema,
consistente, di API
 Tecnomagia
«… i dati pubblici saranno
ingeriti in un unico
framework centrale che ne
garantirà standardizzazione,
coerente interconnessione
(sarà possibile legare dati
provenienti da sorgenti e
verticali diversi, ma relativi
a un unico fenomeno o
entità) e coerenza nella
fruizione (API e dashboard
tematiche).» (2017)
 A fianco vediamo un esempio di un approccio che
non tiene conto della natura del sistema.
 Se notate quello che viene detto assomiglia molto
alla vecchia EAI (Enterprise Application Integration)
con un antica topologia hub-and-spoke
 Un unico sistema centrale (?) dovrebbe raccogliere,
standardizzare (come?) e distribuire le informazioni
a tutti tramite «API» e «dashboard» (?)
 È chiaro che questo approccio non è sensato, oltre
ad essere piuttosto obsoleto
 Un API ecosystem

API Economy
 Un ecosistema di standard, ma anche
la «semplice» interoperabilità dei
sistemi sanitari, non nascerà in modo API Standard API
«automagico» dalla tecnologia, ma da
investimenti concreti e progressivi
nella standardizzazione.

API
 La creazione di API/interfacce
condivise non richiede investimenti Operatori
Operatori

enormi ma richiede, principalmente, Operatori

Operatori

costanza, organizzazione e chiarezza Operatori

Ecosistema di
Operatori

su cosa sia un API e come questa può Business

(mercato)
essere creata e fatta evolvere in modo
sensato in un ecosistema.
 Un esempio:

«Un sogno? Il  Fomati dei dati (i.e. definizione di

implica Implementation Guide CDA2 e/o
controllo della FHIR Resource)
spesa sanitaria:
capire quali medici
che si ostinano a
 Terminologie e codifiche (i.e. API
prescrivere farmaci implica SNOMED (?), IDMP (?), ATC, UCUM…)
di marca anziché i
generici, oppure
quali pazienti o
 Servizi (i.e. Provider Identification,
quali farmacie li Patient Identification, Ordering
privilegiano.» implica Service, Terminology Management)
(2017) su tecnologia SOAP e/o FHIR (REST)
Circa un anno fa’: la governace della sanità elettronica

Ora la
situazione è
ulteriormente
peggiorata:
data l’ultima
legge di
bilancio e
l’aggiunta del
Team per la
trasformazione
digitale
Change the Game?

 Sappiamo quindi che un tradizionale approccio top down non

funziona (e noi non abbiamo neanche questo, obiettivamente) e sappiamo
che questo non significa che non serva coordinamento anzi serve un
coordinamento più esteso. Un sistema distribuito richiede più
organizzazione (efficace) di un vecchio sistema gerarchico.
 Gli ULSS in realtà non sono caotici, sono invece molto più strutturati delle
organizzazioni tradizionali (sono complessi).
 Serve definire un architettura enterprise (bussiness+tecnologia) e
serve gestire la sua implementazione progressiva usando i modo
sensato gli standard.
 Esistono tecniche, processi e standard ben conosciuti per questo, ma
vanno effettivamente adottati.
 Legend
Health IT Services Reference Architecture (API Catalog) (v1.1.1) Pop Health [Software]Service

Interface HSSP Standard API

Applications

Personal Clinical Interface (other) API

Population Electronic Health Record Device Interface HSSP API
Health Quality (under development)
Health (EHR/EMR) Monitoring
Record Mgmt
Message
Transport COTS/Off-the-Shelf
PCD (IHE)
(Coordinating)
Composite

Clinical
Immunization Care Scheduling Order Cohort Task
Decision
Coordination Coordination Services Management Management Management
Support
Cross-Paradigm Coord of Care Svc Scheduling Svc Ordering Service Cohort Mgmt Svc CDS Service Task Mgmt Svc
PCC (IHE) Order Catalog Mgmt

Health Identity Data Healthcare

Enabling

Terminolo Unified Record Data Event

Services Managemen Mapping & Management Security
gy Services Comms Locator Retrieval
Directory t Transform Services
CTS2 UCOMMS Svc RLUS IXS RLUS PASS Audit
ServD MDMI Event Pub/Sub Svc
PASS Access Control
SVS (IHE) HPD (IHE) FHIR (HL7) PIX/PDQ (IHE) XD* Suite (IHE) CTS2
XCPD (IHE) FHIR (HL7) ATNA (IHE)
XCPD (IHE) AML
XUA (IHE)
Content HL7 FHIR Resouces HL7 V2 HL7 V3 – CDA 2

Infrastructure
Message Services Authentication Authorization …
Transport Registry
Jointly Developed by HL7 and OMG under the Healthcare Services Specification Project. Reuse with Attribution Permitted.
In questo caso evitare gli “Spaghetti”
 La possibilità di adottare e beneficiare delle nuove
opportunità tecnologie (e.g. big data, supporto alle
decisioni, cloud …) dipendono da una progettazione
sensata, progressiva e coerente degli standard
 Le API dipendono da una governace adeguata e
costante che tenga conto delle caratteristiche di un
sistema Ultra Large Scale (i.e. il fatto di essere
intrinsecamente distribuito), oggi non abbiamo niente
di tutto questo a livello nazionale
 Il «busisness», i processi, l’architettura sono centrali la
tecnologia già la abbiamo, è l’aspetto meno rilevante.
 Abbiamo tutti gli elementi necessari, dobbiamo
solamente cambiare l’approccio obsoleto a cui ci
siamo malamente abituati.
 Atrimenti:
Grazie per l’attenzione
The Healthcare Services Specification Program

 The Healthcare Services Specification Program (HSSP) is an

open, global community focused on improving health
interoperability within and across organizations through the
use of Service-Oriented Architecture (SOA) and standard
services. The intention is to reduce implementation complexity,
promote effective integration, foster marketplace support, and
drive down implementation costs and barriers impacting
healthcare solutions.
 HSSP is also a joint standards development activity occurring in
multiple organizations, including Health Level 7 (HL7), Object
Management Group (OMG), Healthcare Services Platform
Consortium (HSPC), and others