Partendo dal progetto TraumaTracker, `e in seguito emersa la possibilit`a di portare il tutto ad un livello pi`u ampio. TraumaTracker `e un’applicazio- ne rivolta ad una singola necessit`a, ma in futuro potrebbe rivelarsi necessario implementare altre applicazioni smart. Oltre alle problematiche relative allo sviluppo delle applicazioni in s`e, in campo medico spesso `e necessario interagire e interfacciarsi con servizi, sistemi informativi ed apparati presenti all’inter- no dell’ospedale. Per questa ragione non avrebbe senso che ogni applicazione sviluppata debba sviluppare da zero la parte di interfacciamento ai sistemi esistenti. La visione relativa all’infrastruttura riguarda la costruzione di un livello che si ponga sopra ai sistemi esistenti e che si occupi di interfacciarsi con essi. In questo modo le applicazioni non devono interfacciarsi direttamente con i sistemi ma possono interagire con questo livello. Quindi si `e pensato di sviluppare una piattaforma che permetta di fungere da punto centrale per le varie applicazioni smart all’interno dell’ospedale e che provveda a fornire loro i dati in un formato ben preciso, in modo da facilitare lo sviluppo di nuove app e l’integrazione tra esse. Ad esempio, se `e necessario recuperare i parametri vitali dei pazienti tramite il gateway di Draeger, per evitare che ogni applica- zione debba interfacciarsi con esso, `e opportuno sviluppare ci`o che serve una volta sola e inserire l’implementazione all’interno dell’infrastruttura, rendendo disponibile un’interfaccia standard per tutte le applicazioni che lo necessitino. Si `e deciso di utilizzare un’approccio a microservizi, in modo tale da rendere indipendenti i vari componenti dell’infrastruttura. Tramite questo approccio ogni componente pu`o essere sviluppato, distribuito e aggiornato indipenden- temente dagli altri, senza dovere aggiornare l’intera infrastruttura quando le modifiche concernono solo una parte ristretta di essa. I microservizi utilizze- ranno l’architettura REST in modo tale da fornire delle API standardizzate alle applicazioni di terze parti che avranno la necessit`a di consumarle. I dati saranno scambiati in formato JSON. Di seguito viene mostrata un’immagine che sintetizza i concetti appena espressi (figura 2.4).
– Servizi: l’infrastruttura `e composta da diversi microservizi indipen- denti tra loro che si occupano di fornire delle funzionalit`a e se ne- cessario di interagire con i macchinari e sistemi dell’ospedale, in modo da evitare che siano le applicazioni a farlo direttamente. Per la natura dei microservizi, questi potrebbero essere sviluppati in tecnologie diverse
– Db: ogni servizio potrebbe usufruire di un database. Per la natura dei microservizi e per il fatto che essi sono indipendenti tra loro, anche i database potrebbero essere costruiti con tecnologie diverse • Ospedale:
– Dispositivi: dispositivi (che possono essere sia fissi sia mobili) su cui vengono eseguite le applicazioni che vengono quindi utilizzate dagli operatori dell’ospedale (o anche dai pazienti)
– Sistemi/macchinari ospedalieri: dispositivi, macchinari e sistemi in- formativi che sono presenti nell’ospedale, con i quali le applicazioni potrebbero avere la necessit`a di interagire. Per nascondere loro la complessit`a dell’interazione con questi servizi, essi interagiscono di- rettamente con la piattaforma, che quindi si occupa di fornire i dati necessari alle applicazioni con una interfaccia standardizzata
GatewayService
Di seguito verr`a illustrato nel dettaglio il sistema per il recupero ed il trac- ciamento dei parametri vitali del paziente sviluppato. Il sistema `e composto da alcune parti:
• HL7SubSystem: applicativo che si occupa dell’interfacciamento con il ga- teway di Draeger per il recupero dei parametri vitali dei pazienti collegati ai monitor
• GatewayService: servizio che utilizza HL7SubSystem per recuperare i parametri vitali dei pazienti collegati ai monitor e renderli disponibili tramite un’interfaccia standardizzata e semplice alle applicazioni esterne, nascondendo loro la complessit`a dell’interfacciamento con il gateway di Draeger
• GatewayViewer : applicazione web che permette di manipolare i monitor salvati nel sistema (in modo tale che a fronte delle richieste ricevute Ga- tewayService possa sapere che gateway interrogare sulla base del monitor richiesto dalle applicazioni) e di visualizzare da remoto i parametri vitali associati ai monitor
Per quanto riguarda lo sviluppo, ci si `e concentrati per il momento principal- mente sugli aspetti legati ai requisiti e alle funzionalit`a del sistema al fine di poter essere utilizzato in modo fruibile, ponendo attenzione anche ad aspetti legati alle performance. Tuttavia questo non basta per ottenere un prodot- to che possa inserirsi in un contesto delicato come l’healthcare. A tal scopo bisogner`a lavorare su altri punti, descritti in 3.4. Infine `e opportuno anche affrontare il problema della privacy dei dati. In questo caso il servizio non colleziona, distribuisce o condivide informazioni relative ai pazienti, perci`o il problema non sussiste. Il gateway di Draeger fornisce nel messaggio solamen- te il nome e cognome del paziente (di cui non `e nemmeno certa la presenza,
in quanto il paziente viene collegato al monitor solamente all’arrivo al pronto soccorso), ma questi dati non vengono salvati (e nemmeno letti) dal servizio, che fornisce alle applicazioni solo i dati relativi ai parametri vitali.
Figura 3.1: Architettura del sistema
Il software che verr`a sviluppato verr`a utilizzato inizialmente solamente dal progetto TraumaTracker. Il software sviluppato sar`a in seguito anche posto all’interno di un quadro pi`u ampio, ovvero l’infrastruttura GT2, che ha l’o- biettivo di costruire un livello che si pone al di sopra dei sistemi software e hardware che convivono all’interno dell’ospedale.