Articolo in evidenza

Le sfide della nuova generazione di sistemi informativi sanitari, puntata #2

Se dovessi sintetizzarla in una frase soltanto direi: “Tutti gli stackeholders autorizzati debbono poter avere garantito l’accesso ai dati sanitari, sempre e da dovunque.”

Sembra semplice, ma non lo è o, quantomeno, non lo è stato fino ad ora. D’ora in avanti dovrà esserlo.

I sistemi sanitari che trattano i dati del paziente per fini di cura debbono garantire l’accesso alle informazioni a tutti i portatori di interesse, attuali e futuri, che intervengono nel processo di cura.

Qualcuno potrà subito commentare che l’affermazione è ovvia, ma la parola chiave è nell’aggettivo “TUTTI”:

Il paziente è un portatore di interesse…
I parenti autorizzati dal paziente, sono portatori di interesse…
I sanitari che intervengono nel processo di cura, sono portatori di interesse…
Gli eventuali consulenti che vengono coinvolti dal paziente per una valutazione di “Second Opinion”, sono portatori di interesse…
I ricercatori degli IRCSS che debbano accedere per fini di ricerche autorizzate ai dati del paziente, sono portatori di interesse…
La comunità scientifica a cui il paziente in veste di “data donor” abbia donato i dati, sono portatori di interesse…
ecc…

E questo deve avvenire in tempi e modi tali da non inficiare il valore di quel patrimonio prezioso che sono i dati di salute del paziente: occorre, al contempo, garantire un efficace percorso di salute, ma anche il rispetto dei diritti fondamentali dell’interessato, anche ai sensi della vigente normativa sulla tutela dei dati personali.

Qualcosa di tutto ciò di certo già facciamo negli attuali sistemi informativi sanitari, ma di certo i nostri attuali sistemi non sono ancora pensati per garantire accesso a tutti gli stackeholders… e, di certo, NON da dovunque.

Quello dell’accessibilità del dato sanitario al di fuori delle canoniche mura dell’azienda sanitaria è un problema che è esploso durante il periodo pandemico, quando i sanitari si trovavano ad operare in luoghi diversi dalla loro sede abituale, ma è destinato a rimanere come esigenza strutturale dei sistemi informativi sanitari di nuova generazione. La cosiddetta “virtualizzazione della sede fisica di lavoro” pone diversi problemi alla attuale generazione di sistemi sanitari, problemi che debbono essere superati in una ottica di evoluzione strutturale dei sistemi. Non siamo, infatti, chiamati ad esporre una singola funzionalità applicativa, ma tutte le funzionalità che permettono di gestire l’intero percorso di cura. Garantire ciò e farlo in sicurezza, sono obiettivi imprescindibili per i sistemi della prossima generazione.

Il terzo e ultimo problema, l’accessibilità dei sistemi informativi sanitari 365 giorni all’anno, 24 ore su 24, è stato tenacemente perseguito nei sistemi sanitari tradizionali e potrebbe essere considerato un obiettivo scontato anche per la prossima generazione di sistemi informativi.

Vale, tuttavia, la pena di considerare che questo obiettivo non è indipendente dai due precedentemente enunciati. In altre parole, dire che le informazioni sanitarie debbono essere accessibili da tutti gli stakeholders, da dovunque e con alti livelli di continuità di servizio significa imporre l’adozione di infrastrutture CLOUD ad alto o altissimo livello di resilienza al guasto e alto o altissimo livello di sicurezza, cosa che poi non è così scontata e semplice da realizzare e da manutenere.

In altre parole: vogliamo che sia facile accedere ai dati sanitari quanto accedere ad una ricerca in GOOGLE, ma che ciò sia sicuro quanto l’accesso all’oro di Fort KNOX.

Semplice, no?

Idee per “Next Generation Healthcare Information Systems“. Questo articolo fa parte di una serie il cui primo è reperibile a questo Link

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

FHIR client CRUDS

FHIR Release 3

In this notebook you can find some snippets of code about accessing a FHIR server for Create, Read, Update, Delete, Search FHIR resources… by means of a FHIR python client.

The FHIR python client used is the “SMART-ON_FHIR/client-py”, more info about it here.

The FHIR python client module is easily installed by issuing the command:

pip3 install fhirclient

FHIRClient CRUDS

Enjoy and let me know if you like it in twitter @pierfghedini.

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

Machine Learning development platform

To dig a mine you need suitable tools, you cannot dig with your bare hands…

To experiment with Machine Learning techniques, you need a suitable platform with all the necessary tools configured and working or you’ll waste your time in trying to set up the tools instead of solving your problem.

In this Jupyter Python Notebook you can find a simple tutorial that will instruct you to set up a suitable platform to work in and an example of use.

The example is the already classic analysis of Titanic shipwreck, we will use the well known RandomForestClassifier to predict the shipwreck survivors.

Download the tutorial at:

https://github.com/pghedini/MLPlatform

Enjoy and let me know if you like it in twitter @pierfghedini.

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

Health Information Technology Cybersecurity – the architecture

The cybersecurity of health information systems is a complex issue that requires a systematic approach.

In this article we will analyze a proposed cybersecurity architecture for a generic Healthcare Authority. Here, Healthcare Authority means a generic Healthcare Organization that deals with primary care, or secondary care, but also home care and community care….

The proposed architecture is designed to fit a University hospital, as well as a country hospital, as well as a local Healthcare Authority with medical outpatients clinics…

We will indicate the generic Healthcare Authority with the acronym HA.

Architecture schema

Health Systems Cybersecurity Schema

The roles

All users can be modeled in only three main roles:

the guests – not authenticated users -;
the professionals – authenticated users who use systems from inside and outside the HA -;
IOTs and other automated systems that needs an interaction with the HA.

The double role of IoT and IoMT

The IoTs – Internet of Things – and the IoMTs – Internet of Medical Things – devices comprehend also medical devices that operate outside the HA.

For simplicity we will map IoTs to unauthenticated users – guests role – if they do not need an access to HA systems – they do not need access to applicative functions -. We will map IoTs to professionals role, if they need access to applicative functions.

The cyber-security architecture

The HA infrastructure is segmented in four zones:

the sandbox zone;
the exposed systems zone;
the untrusted systems zone;
the isolated systems zone.

The sandbox zone is the only zone the guest can access to. From the sandbox zone is not possible to access other zones.

Vice versa from other zones you can access the sandbox zone.

In the sandbox zone there is a restricted access area to which only authenticated users can access to. The datas in this area are crypted and they are accessible also offline. This sandboxes zone can be located on a portable devices in order to make sensitive data available when the used devices are offline.

The exposed system zone is the area where are located the hardenized systems which are accessible by authenticated users, from outside or inside of the HA. The systems in the exposed zone are the only way to reach the systems in the isolated zone or in the untrusted zone.

The isolated zone and the untrusted systems zone are accessible only by authenticated users who have application grants on servers of the exposed zone. Typically in the isolated zone you can find the most sensitive systems and the DB resources. The isolated zone in segmented by sensitivity or level of trust.

The untrusted zone is typical of the healthcare domain and contains the Medical Devices and other systems which cannot be considered hardenized to handle a direct access in the exposed zone. Typically, these systems need a network protection. For the same reasons the most sensitive systems are collocated in the isolated zone.

As the exposed zone, the untrusted zone is logically unique, but physically represents a myriad of connected network areas that include only a few or only one equipment.

Test systems and Maintenance activity

In HA, the maintenance activity is often guaranteed by outside partners. These partners must have access to the systems they manage, but only those. In addition, all their activities must be network logged, because HA cannot trust system logging due to the fact that these partners often have administrative rights over the systems they manage.

Another important issue is the HA need of a test area, or “staging” area, in each zone.

In the test area of each zone there are test systems or pre-production systems. The systems in the test areas cannot access to production systems. The test systems in each zone has the same security restriction and possibilities of analogous production systems. In other words, the test area is specular to the production area, but completely separated.

GDPR orchestration

HA must orchestrate the entire security architecture according the GDPR – GDPR, General Data Protection Regulation, UE 2016/679 – policy and rules. In fact, the GDPR imposes the definition of the security policies the administration has decided to undergo and the periodic verification of the respect of these policies.

Use case

Access to inpatient datas: in the morning, Doctor Alice orders an entire suite of blood exams for inpatient Bob. Later, in the afternoon, doctor Alice is notified the Bob’s results are ready and Alice access to the the results from her home.

When Alice is at work, in the morning, she uses a ward mobile device to order the exams, then uses a POCT – point of care testing – analyzer located in the ward the analyze the Bob’s blood. She takes a look at the values the analyzer gives directly, but she needs the pathology department validation. She receives notification a validation is ready when is at home, in the late afternoon. She receives a SMS that says new pathology results are ready – no sensitive data are sent in the SMS -. Alice take a look at the results with her home computer.

From a security perspective several systems in different zones are involved in the process:

A) in the morning, Alice accesses the Order System that is in the Exposed Systems Zone;

B) the analyzer Alice uses is located in the Untrusted Systems Zone;

C) the Bob’s exams results are collected by the Pathology System which is located in the Exposed Systems Zone;

D) from her home, Alice get accesses to the Clinical Data Repository System in order to get the Pathology report; the Clinical Data Repository is in the Exposed Systems Zone. The DB of the Data Repository is in the Isolated Systems Zone.

Key points

It doesn’t matter if Alice is at work or at home, she uses the same systems; in other words the systems, in exposed zone, are hardenized to be exposed in internet, even if they are only used from inside HA;
the medical device, the POCT, is considered untrusted, by virtu of this the network makes port filtering, web firewalling and so on… the device is isolated in the Untrusted Systems Zone and it can not be directly accessed;
sensitive resources are isolated in Isolated Systems Zone and can not be directly accessed;
Guests interact with HA safely through a Sandbox Zone.

Conclusion

Security architecture is not the solution. In order to achieve a sufficient level of cybersecurity you have to adopt a conspicuous number of different techniques, but without a security architecture it’s difficult to reach the goal.

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

Sul dare fiducia – Trusting Trust –

Ken Thompson

In un mio articolo pubblicato sul numero 3 della rivista “Reputation Today” trattavo del dibattuto tema della catena di fiducia che si deve instaurare fra fornitore e committente al fine di garantire la sicurezza di una qualsiasi installazione informatica. Per chiarire il concetto citavo un famoso attacco informatico ideato da Kenneth Thompson, il “Trusting Trust Attack“.

Il primo a parlare di questo attacco fu lo stesso Thompson, in occasione del discorso che tenne, nel lontano 1983, quando ricevette il Turing Award, uno dei più ambiti premi nella comunità informatica. Da tempo girava voce che Ken, che era uno degli inventori dello Unix, uno dei più diffusi sistemi operativi per computer, potesse entrare in qualsiasi sistema a dispetto del fatto che non possedesse le credenziali di accesso. Per verificare ciò erano state messe in atto analisi anche molto approfondite, ma non si era approdati a nulla e Thompson continuava a sorridere sornione da dietro la sua barba incolta.

Quella sera, nella sala gremita di azzimati professori e di barbuti hacker con camicie a fiori alla moda californiana, Ken spiegò come attraverso un processo di apprendimento progressivo il software potesse inglobare informazioni al proprio interno annegandole in livelli più interni rispetto a quelli che una ordinaria analisi normalmente considera. Le affermazioni di Thompson svelavano, finalmente, come anni di ricerche sul codice sorgente dello Unix non avessero dato esito: semplicemente occorreva andare più a fondo. Ken stava dicendo che il software installato su di una macchina non è semplicemente l’ultimo livello di software installato, ma anche la memoria di tutto quanto si è fatto in precedenza.

Per molti anni da quel lontano ’83, l’attacco di Thompson o “Trusting Trust Attack” sarebbe rimasto senza reali ed effettive contromisure e ancora oggi rappresenta un paradigma concettuale con il quale confrontare la sensatezza dei nostri approcci alla sicurezza informatica.

Ma questi trenta e più anni di storia dell’attacco ci fanno capire che il messaggio di Thompson era forse ancora più sottile: egli ci ha infatti rivelato che il software, come la terra che calpestiamo, ricorda le nostre orme, anche se la pioggia sembra cancellarle. Ogni generazione di software porta con se i lasciti e le tracce di quelle precedenti… Thompson sembra dirci: “Attenzione. Chi è senza memoria è, spesso, anche senza protezione.”

Per una approfondita analisi sul “Trusting Trust Attack” si veda l’articolo “Reflections on Trusting Trust” di Ken Thompson.

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

CAD e dintorni: Regole tecniche in materia di documenti informatici

Agenzia per l’Italia Digitale

Continua la serie di articoli volti ad approfondire gli aspetti del CAD di maggiore interesse per le aziende sanitarie. In questo articolo si dà notizia del recente Decreto del Presidente del Consiglio dei Ministri che tratta di “Regole tecniche in materia di formazione, trasmissione, copia, duplicazione, riproduzione e validazione temporale dei documenti informatici nonché di formazione e conservazione dei documenti informatici delle pubbliche amministrazioni ai sensi degli articoli 20, 22, 23-bis, 23-ter, 40, comma 1, 41, e 71, comma 1, del Codice dell’amministrazione digitale di cui al decreto legislativo n. 82 del 2005.“

Di cosa tratta il decreto?

Il decreto – art. 1 – fornisce una serie di definizioni – allegato 1 – e descrive alcuni formati di documenti utilizzabili – allegato 2 -. Nell’allegato 3 riporta una serie di standard tecnici per la formazione, la gestione e la conservazione dei documenti informatici. Nell’allegato 4 e 5 riporta rispettivamente le specifiche tecniche del pacchetto di archiviazione e dei metadati.

Inoltre – art. 2 – il DPCM detta le regole tecniche per i documenti informatici, per i documenti amministrativi informatici e per il fascicolo informatico.

Quali le principali novità e gli aspetti salienti

Vale la pena di sottolineare una interessante novità riportata al comma 2 dell’art. 10 – Copie su supporto informatico di documenti amministrativi analogici – laddove si dice che “L’attestazione di conformita’ di cui al comma 1, anche nel caso di uno o piu’ documenti amministrativi informatici, effettuata per raffronto dei documenti o attraverso certificazione di processo nei casi in cui siano adottate tecniche in grado di garantire la corrispondenza del contenuto dell’originale e della copia, puo’ essere prodotta come documento informatico separato contenente un riferimento temporale e l’impronta di ogni copia. Il documento informatico prodotto e’ sottoscritto con firma digitale o con firma elettronica qualificata del funzionario delegato.”

Tale enunciate sembra aprire la strada ad una modalità di attestazione della conformità che si basa su una certificazione di processo piuttosto che su una verifica sistematica attuata documento analogico per documento analogico, con ovvie ricadute di migliore efficienza e gestibili del processo.

L’ art. 12 – Misure di sicurezza – afferma che “Il responsabile della gestione documentale ovvero, ove nominato, il coordinatore della gestione documentale predispone, in accordo con il responsabile della sicurezza e il responsabile del sistema di conservazione, il piano della sicurezza del sistema di gestione informatica dei documenti, nell’ambito del piano generale della sicurezza ed in coerenza con quanto previsto in materia dagli articoli 50-bis e 51 del Codice e dalle relative linee guida emanate dall’Agenzia per l’Italia digitale. Le suddette misure sono indicate nel manuale di gestione.”

Ribadendo in questo modo l’obbligatorietà delle misure di Business Continuity e Disaster Recovery dovute in base agli articoli 50-bis e 51 del CAD.

All’ art. 14 – Formazione dei registri e repertori informatici – comma 2, si afferma che “Le pubbliche amministrazioni gestiscono registri particolari informatici, espressamente previsti da norme o regolamenti interni, generati dal concorso di piu’ aree organizzative omogenee con le modalita’ previste ed espressamente descritte nel manuale di gestione, individuando un’area organizzativa omogenea responsabile.”

Ciò sembra autorizzare le pubbliche amministrazioni a gestire registri informatici particolari che danno titolo a modellare flussi informatici che abbiano gestioni particolari rispetto all’ordinario flusso di protocollazione che caratterizza lo scambio di documenti al confine delle PA.

Tempi di attuazione ed adeguamento dei sistemi

All’art. 17 si precisa che “Il presente decreto entra in vigore decorsi trenta giorni dalla data della sua pubblicazione nella Gazzetta Ufficiale della Repubblica italiana – NOTA BENE: il DPCM è stato pubblicato in GU il 12/01/2015 -. Le pubbliche amministrazioni adeguano i propri sistemi di gestione informatica dei documenti entro e non oltre diciotto mesi dall’entrata in vigore del presente decreto. Fino al completamento di tale processo possono essere applicate le previgenti regole tecniche. Decorso tale termine si applicano le presenti regole tecniche. Il presente decreto e’ inviato ai competenti organi di controllo e pubblicato nella Gazzetta Ufficiale della Repubblica italiana.”

NOTA BENE: quanto riportato nel presente articolo è un estratto da norme vigenti e non garantisce la completezza che solo il testo originale può garantire. Le considerazioni dell’autore devono essere considerate alla stregua di opinioni personali e quindi, prima di ogni possibile utilizzo, devono essere confrontate con altre fonti autorevoli e fede facenti. Verificare sempre i testi completi e originali delle norme citate ricorrendo alle fonti ufficiali tenendo conto di ogni possibile modifica o integrazione intervenuta successivamente alla redazione del presente articolo.

PG.

Il testo vigente del CAD è reperibile sul sito di AGID.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

La documentazione clinica nel ventunesimo secolo

Annals Of Internal Medicine

La discussione sulla documentazione sanitaria e sulla sua corretta tenuta precede l’introduzione dell’EHR – Electronic Health Record – e di certo l’avvento delle nuove tecnologie invece che costituirne la fine, l’ha enfatizzata. Uno dei contributi più autorevoli e stimolanti in materia è comparso di recente su Annals of Internal Medicine con il titolo “Clinical Documentation in the 21st Century: Executive Summary of a Policy Position Paper From the American College of Physicians“

L’American College of Physicians – ACP -, in questo lavoro, analizza con spirito critico il tema della documentazione sanitaria allo scopo di comprendere come essa possa meglio rispondere alle necessità dei pazienti e delle loro famiglie e per fare questo si interroga su quali siano le potenzialità, oltre che le principali problematiche, dei sistemi informativi sanitari – EHRs -.

La considerazione chiave da cui parte l’ACP è che la documentazione clinica ha come scopo principale quello di registrare le condizioni del paziente e le azioni e i pensieri del curante al fine di condividerle con gli altri attori del processo di cura. Nel tempo molti portatori di interesse hanno caricato la documentazione sanitaria di necessità diverse che poco hanno a che fare con il fine originario. L’ACP afferma anche che l’introduzione dei computer e dell’EHR non ha portato solo vantaggi, ma ha anche introdotto nuove complessità e nuove sfide.

Non solo: alcuni medici hanno evidenziato che taluni sistemi informatizzati sono inadeguati al fine della gestione della documentazione clinica.

Nel documento, l’ACP fornisce delle raccomandazioni per la progettazione dei futuri sistemi EHR:

i sistemi EHR devono facilitare la gestione del paziente durante tutto l’arco della sua vita – longitudinal care delivery – supportando l’operato dei sanitari che spesso si trovano ad operare in team per percorsi di cura che coprono anche lunghi periodi;
la documentazione gestita negli EHR deve supportare il processo cognitivo del sanitario durante la fase di redazione della documentazione;
i sistemai EHR devono favorire l’atteggiamento “scrivi una volta, usa molte volte” – write once, reuse many times – e deve supportare l’uso di TAGS – identificativi – che permettano di registrare la fonte originale delle informazioni quando queste siano riutilizzate in fasi successive;
per quanto possibile, non si deve richiedere l’inserimento della conferma di azioni effettuate quando l’effettuazione di queste risulti chiaro dalla documentazione presente;
i sistemi EHR devono favorire l’integrazione dei dati generati dal paziente mantenendo evidenziata la fonte del dato.

L’ACP pone l’accento su alcuni dei temi che saranno chiave per lo sviluppo dei sistemi informativi del prossimo triennio.

In particolare:

la necessità di rendere sempre evidente la fonte di una certa informazione presente nella documentazione clinica – ad esempio se una informazione è stata conferita direttamente dal paziente, piuttosto che raccolta in maniera automatica da un dispositivo medico o certificata da un medico attraverso un certificato o un referto, ecc… -; raccomandazioni 3 e 5;
la necessità di minimizzare le interazioni a basso contenuto informativo con il sistema al fine di aumentare l’usabilità complessiva dei sistemi informatici; raccomandazione 4;
la necessità di disporre di sistemi informativi di reale valore per il professionista sanitario e per il paziente, cioè in grado di supportare il processo di cura e di redazione della documentazione sanitaria; raccomandazioni 1 e 2.

Le raccomandazione dell’American College of Physicians dovranno essere prese in seria considerazione, se questo non avverrà, si correrà il rischio che i futuri sistemi EHR siano un ostacolo invece che un aiuto alla pratica sanitaria.

PG.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

Big Data in sanità?

BigData Image

Prendo spunto da questo interessante articolo apparso su www.fiercehealthit.com per fare qualche considerazione sul tema dei BIG DATA – o Analytics – in Sanità.

Quello dei BIG Data è un tema assai di moda oggi e viene usato come sostanziale sinonimo del termine più tecnico “analytics”. Wikipedia dichiara che “Analytics is the discovery and communication of meaningful patterns in data”. Fra gli addetti ai lavori molto si discute, da un po’ di tempo a questa parte, su come i BIG DATA possano essere di aiuto in ambiti come la valutazione dell’efficacia delle cure, la ricerca epidemiologica o il contenimento dei costi attraverso l’analisi dell’efficienza del processo erogativo.

Effettivamente cominciano ad essere disponibili informazioni sull’utilizzo dei BIG DATA in sanità, ma siamo di fronte ad una vera rivoluzione o ad una semplice moda?

Se infatti ci fermiamo un attimo a pensare, ci accorgiamo che ciò che chiamiamo BIG DATA, altro non sono che le banche dati sanitarie classiche:

le SDO – schede di dimissione ospedaliera – che assieme agli accessi di PS non seguiti da ricovero che rappresentano la dimensione ospedaliera dell’assistenza;
l’ASA – la banca dati dell’erogato relativo alla specialistica ambulatoriale e alla diagnostica – che assieme ad altre banche dati accessorie come l’ADI – Assistenza Domiciliare Integrata – ci permette di indagare alcuni aspetti della dimensione territoriale dell’assistenza;
l’AFT – banca dati della Farmaceutica Territoriale – che permette di conoscere quali farmaci siano forniti attraverso il SSN ai pazienti;
ecc…

Se questi sono i BIG DATA della sanità, allora gli Analytics sanitari non sono poi una novità così stravolgente, stante che negli ultimi anni queste banche dati sono state esaminate in lungo e in largo probabilmente in tutti i modi possibili.

Tuttavia sarebbe semplicistico liquidare in questo modo l’intera questione. Mi sembra che vada colta la sollecitazione che viene dai colleghi stranieri che vedono nella nascita di nuove figure professionali dedicate alla analisi delle grandi banche dati sanitarie come il fattore chiave. Nell’articolo citato si sottolinea l’importanza della nascita di figure come il chief data officer e il chief analytics officer che possono contribuire alla valorizzazione delle informazioni annegate all’interno dei BIG DATA.

Io credo che ci sia della verità in tutto ciò: in fondo i dati non parlano se non a chi sa ascoltarli. Avere dei professionisti che siano in grado di scovare le preziose informazioni che sono annegate in montagne di dati senza valore e che siano in grado di evidenziarle in sintesi significative per le direzioni sanitarie e per i professionisti coinvolti nel processo erogativo è molto probabilmente la mossa vincente.

Speriamo che le direzioni aziendali e regionali investano in questa direzione, ciò che manca in questo momento non sono le informazioni, ma le persone che sanno leggerle.

PG.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

Le 5 dimensioni dell’EMR

Dimensioni dell’EMR

Ogni implementazione di un EMR – Electronic Medical Record – dovrebbe essere valutata secondo 5 principali dimensioni:

UTILITÀ PER IL PAZIENTE;
UTILITÀ PER IL PROFESSIONISTA;
VALENZA SOCIALE;
SEMANTICA;
TECNOLOGIA.

La prima dimensione è in relazione con il fatto che ogni EMR è di proprietà del paziente e deve essere di utilizzato a suo vantaggio. In particolare valutare questa dimensione comporta il riportare su una metrica il grado di utilità dell’EMR per il paziente. Occorre anche misurare il grado di gestibilità dell’EMR da parte del paziente stesso: ad esempio può essere valutata la facilità con la quale il paziente può oscurarne determinate parti al fine di tutelare la propria privacy o rendere disponibili parti dell’EMR a determinati professionisti sanitari e non ad altri.

La seconda dimensione è in relazione con il fatto che L’EMR è un fondamentale strumento di lavoro per il professionista sanitario che ha in cura il paziente. Il professionista ha il dovere di tenere costantemente aggiornato l’EMR per le parti di propria competenza, ma ha al contempo il diritto di consultare le informazioni rilevanti per la pratica professionale che non siano state oscurate dal paziente. Questa dimensione misura quindi il grado di utilità dell’EMR per il professionista.

Oltre che per il paziente e il professionista, l’EMR può essere prezioso per l’istituzione sanitaria che ha l’onere della valutazione dei servizi sanitari forniti alla popolazione. Gli EMR possono fornire informazioni aggregate, anonime e non per personali che permettono valutazioni di tipo epidemiologico, oltre che azioni di prevenzione e di governo della salute pubblica mediante la misura dei risultati – outcome – delle cure. La dimensione VALENZA SOCIALE misura l’utilità di una certa implementazione dal punto di vista dell’ISTITUZIONE SANITARIA.

I contenuti dell’EMR possono assumere diverse forme, ma saranno tanto più fruibili e gestibili informaticamente quanto più avranno una forma strutturata: ad esempio un referto di laboratorio analisi sarà assai più utile se riporterà in forma numerica i valori delle analisi contenute, piuttosto che la sola immagine – scannerizzazione o PDF – della copia cartacea. È, infatti, del tutto evidente che il valore del documento sarà tanto più elevato quanto più saranno le informazioni riportate gestibili informaticamente: di certo non sarò in grado di selezionare i referti che riportano un valore di glicemia anomalo se i referti sono sotto forma di copia scannerizzata. La DIMENSIONE SEMANTICA misurerà il grado di strutturazione dell’EMR e quindi la sua utilizzabilità con tecniche informatiche.

L’ultima ma non meno importante dimensione è quella tecnologica. Essa attiene al fatto che una certa implementazione dell’EMR risponderà più o meno brillantemente a domande del tipo:

è interoperante con i diversi sistemi tecnologici in uso in ambito sanitario e nella sfera personale?
è idonea all’uso in mobilità e su diversi tipi di dispositivi compresi i wearable e l’IOT?
è scalabile in ambiti diversi da quelli meramente personali ?
ecc…

Misurare le diverse implementazioni dell’EMR secondo queste caratteristiche e farlo secondo metriche che siano comuni e condivise sarà sicuramente la sfida più importante dell’immediato futuro.

PG.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

La stima dei tempi operatori e gli applicativi per la pianificazione dell’attività chirurgica

BMJ: Predicting operating Time

Un recente studio apparso sul BMJ conclude che la difficoltà dei clinici di preventivare il tempo necessario per le diverse procedure chirurgiche è una componente significativa dei ritardi operatori – “The inability of clinicians to predict the necessary time for a procedure is a significant cause of delay in the operating theatre” -.

Lo studio sancisce con rigore scientifico quella che è una difficoltà ormai riconosciuta e che è necessario superare se si vuole ottenere maggiori gradi di efficienza nell’utilizzo di una risorsa critica come la sala operatoria.

I limiti del registro operatorio informatizzato

Appare sempre più pressante l’esigenza di superare i tradizionali strumenti di monitoraggio a posteriori dei tempi operatori con strumenti che forniscano un aiuto anche sotto il versante della pianificazione dell’attività chirurgica.

È bene precisare che, ad oggi, la quasi totalità dei dati sull’utilizzo delle sale operatorie deriva dal registro operatorio informatizzato, che in maniera più o meno completa, più o meno dettagliata, fornisce informazioni sull’ora di inizio delle vari fasi (pre o post)operatorie, sul tipo di procedure attuate, sugli operatori coinvolti, sul tipo di materiali e kit impiegati, ecc…

Questa messe di dati è tuttavia spesso carente ai fini della valutazione degli scostamenti dalla programmazione e non è certamente di aiuto nella programmazione del setup della sala e nelle attività di pianificazione dei kit operatori necessari alle varie procedure chirurgiche.

Gli applicativi di pianificazione dell’attività chirurgica

Si stanno diffondendo sistemi informatizzati di gestione dell’attività chirurgica che integrano il tradizionale registro informatizzato di sala operatoria con funzionalità di pianificazione.

L’adozione di applicativi di questo tipo nasce dalla esigenza di pianificare l’allestimento delle sale operatorie o di predisporre in anticipo gli opportuni kit chirurgici, ma una interessante ricaduta positiva riguarda anche la stima dei tempi chirurgici. Si è, infatti, notato che l’impego di strumenti di questo tipo può progressivamente favorire una più oggettiva valutazione della durata delle diverse procedure. L’uso ha dimostrato che i tempi standard delle procedure, che vengono inizialmente derivati dalla letteratura o stimati a priori, possono essere corretti in base a valutazioni medie ricavabili dalla casistica effettiva di un determinato team. Ciò porta ad una tempificazione più aderente al vero delle diverse procedure chirurgiche e quindi ad una programmazione più efficiente dell’uso delle sale.

PG.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

L’esplosione del numero dei devices connessi metterà in crisi le nostre politiche di sicurezza

Immagine tratta da diagnostica PET

Pur diffidando in genere delle previsioni, tendo a dar credito a coloro che preannunciano una esplosiva crescita dei dispositivi connessi in internet nei prossimi anni.

Gartner stima che entro il 2020 saranno presenti in internet 26 miliardi di dispositivi e il 15% di questi avrà a che fare con il mondo sanitario. Le nostre politiche di sicurezza attuali sono in grado di gestire reti di qualche migliaio di dispositivi: per le organizzazioni sanitarie di maggiori dimensioni si parla di reti in grado di gestire qualche migliaio di stazioni di lavoro e diverse centinaia di dispositivi medici ed è pensabile che con i sistemi attuali si possa arrivare a gestire qualche decina di migliaia di dispositivi. Tuttavia, è opinione comune fra gli addetti ai lavori che non sia possibile gestire in maniera efficiente e sicura reti di centinaia di migliaia di dispositivi.

In particolare appare particolarmente sfidante la necessità di gestire in un contesto di rete dispositivi wearable, o comunque portatili, che non si possono considerare stabilmente collocati in contesti di rete protetti, come i contesti aziendali, nei quali è normalmente possibile operare un controllo perimetrale dai malware attraverso tecniche di firewalling o comunque di filtering.

Fra pochissimi anni esisteranno centinaia di migliaia di dispositivi che saranno stabilmente collocati fuori dal dominio di sicurezza aziendale che comunque saranno parte integrante di un ecosistema che scambia dati sanitari con l’organizzazione sanitaria e con i professionisti ad essa afferenti – medici di medicina generale, specialisti, ecc… -.

Appare sempre più evidente che non sarà possibile gestire numeri così elevati di dispositivi senza una accurata progettazione delle politiche di sicurezza. La sicurezza dell’ecosistema dovrà necessariamente essere fondata su di una corretta identificazione dei dispositivi: che dovrà essere garantita anche in caso di colloqui instaurati in contesti di rete non sicuri. L’identità del dispositivo dovrà essere garantita attraverso tecniche crittografiche che dovranno impedire una fraudolenta impersonificazione. Se questo avverrà, allora non sarà necessario verificare ulteriormente la liceità della comunicazione con il professionista sanitario: in altri termini diminuirà fortemente la necessità di identificare la persona, in quanto l’identità del paziente sarà derivabile dall’identità del dispositivo che esso indossa o possiede. Naturalmente questo varrà nel caso il dispositivo sia impiantato sul paziente o nel caso il dispositivo non sia dissociabile dalla persona: il dispositivo potrebbe semplicemente cessare di funzionare se allontanato dal paziente a cui è associato. A garanzia di ciò il dispositivo dovrebbe poter essere associabile ad una caratteristica biometrica unica della persona.

In definitiva quindi, ogni dispositivo che indosseremo dovrà essere unico, unico come la persona a cui sarà accanto. Questa è la sfida che ci aspetta.

PG.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Articolo in evidenza

Che cosa vogliono i pazienti dalle app sanitarie?

Lascia una risposta

What Do Patients and Carers want from Health Apps?

Una delle ricerche più interessanti che mi sia capitato di leggere di recente si pone l’obiettivo di indagare che cosa gli utilizzatori di app sanitarie si aspettino maggiormente da esse.

La ricerca condotta da PatientView, MyHealthApp e Health2.0 ha evidenziato che il 58% di coloro che hanno risposto dichiara di essere affetto da una patologia, o di prendersi cura di qualcuno affetto da patologia, da 10 o più anni. Il 74,3% di essi ha 41 o più anni.

Dalle risposte fornite risulta poi chiaro che la maggior parte dei partecipanti all’indagine, pur essendo interessata alle campagne informative sui temi della salute che hanno luogo in internet – 47% – non è costituita da addetti ai lavori – ben 38% dichiara di non essere coinvolta nel blogging sanitario o nella pubblicazione di informazioni sanitarie -. E questo dà certamente valore alla ricerca, in quanto meglio esprime il comune sentire del tipico utilizzatore di app sanitarie.

Un aspetto interessante che emerge è che l’uso di APP al confronto della navigazione di internet è ancora minoritario: il 91% dei rispondenti dichiara infatti di fruire di servizi sanitari attraverso il browser e solo il 22% dichiara di utilizzare app per il medesimo scopo.

Si indaga poi su quali siano gli utilizzi più significativi delle app sanitarie: il 44% dichiara di utilizzarle per trovare informazioni sanitarie, il 33% per un supporto a stili di vita più sani, il 31% le utilizza per connettersi con persone nella stessa condizione, nel 28% dei casi la APP aiuta, invece, gli utilizzatori a far fronte alla loro condizione di salute. Per il 23% dei rispondenti la APP aiuta a mettersi in rete con i propri familiari e persone di supporto. Solo con percentuali staccate compaiono poi la necessità di comunicare con il proprio medico e infermieri, l’esigenza di fare commenti sui servizi sanitari ricevuti e vivere la porpria situazione in maniera indipendente.

A mio modo di vedere risulta anche significativo il dato che gli utilizzatori desiderano che le app li aiutino a capire meglio le proprie condizioni mediche e le alternative di trattamento – 61% – e che forniscano un aiuto pratico , ad esempio nella pianificazione delle attività – 55% -.

La ricerca indaga poi quali siano i fattori che maggiormente impediscono lo scarico di una app: per il 37 l’ostacolo maggiore è costituito dall’alto numero di alternative esistenti, troppe app apparentemente simili portano alla confusione il potenziale utilizzatore.

A proposito invece dei fattori che possono favorire un uso regolare delle app sanitarie troviamo: il fatto che esse forniscano informazioni affidabili e accurate – 69% –, che esse siano facili da utilizzare e siano ben disegnate – 66% -, che forniscano garanzie che il dato gestito sia sicuro – 62% -, che siano gratuite e senza pubbllicità – rispettivamente 56% e 51% -.

Le cose si fanno più sfumate quando si chiede di scegliere il servizio che si ritiene più importante fra i principali fornibili da una app: il 23% risponde che ciò che ci si attende maggiormente è che essa fornisca informazioni comprensibili sui sintomi e sulle condizioni mediche. Il 17%, invece, ritiene che vorrebbe essere aiutato a comunicare con il medico e l’infermiere.

La ricerca conclude quindi che coloro che usano app sanitarie sono alla ricerca di informazioni affidabili che li aiutino a capire meglio i loro sintomi e la loro condizione e vorrebbero comunicare meglio attraverso le app con i professionisti della salute – medici e infermieri -, ma al contempo sono frenati e confusi dalla ricchezza dell’offerta.

Mi sembra che i risultati della ricerca siano assai significativi e condivisibili e rendano ragione delle esigenze che sempre più di frequente riscontriamo: come la richiesta di un maggiore accesso alle risorse professionali – medici e infermieri – attraverso applicazioni informatiche ben progettate e smart – app preferibilmente – al fine di superare alcune limitazioni intrinseche delle applicazioni WEB che in qualche caso abbiamo cominciato ad offrire.

La strada mi sembra tracciata.

PG.

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Le sfide della nuova generazione di sistemi informativi sanitari

Pixabay source: Pixabay (Creative Common free for use

Un direttore di unità operativa, uno di quelli che hanno passato la propria vita a curare i pazienti e che ancora pensano che sia giusto e doveroso farlo, un po’ di tempo fa mi diceva: “Vorrei avere più tempo… queste fantastiche diavolerie che mi proponete, mi fanno perdere tempo. Io devo stare al letto dei pazienti.”

Avrei voluto dirgli che si sbagliava, che quelle “diavolerie” non erano certo la ragione per cui aveva meno tempo per i suoi pazienti… Purtroppo, so bene che ha ragione.

Il problema più rilevante che oggi ci troviamo ad affrontare è che abbiamo raggiunto il limite di informazione gestibile per singolo paziente da parte del singolo operatore. E non è un problema di quanti click richiede la singola applicazione, il problema è più drammatico.

Quando l’informazione a disposizione è superiore alla capacità di gestione del percettore, tutto rischia di diventare rumore e la reale utilità della comunicazione scema fino a rasentare l’inutilità.

È un fenomeno che gli informatici e gli esperti di teoria delle comunicazioni conoscono bene: quando il rumore sovrasta il segnale, il segnale diventa non più trattabile per il ricevente. Non si riesce più a estrarre il segnale utile dal CAOS del rumore casuale.

Ma fra la messe infinita di informazioni che oggi si generano durante un episodio di cura (sia esso un accesso di minore entità quale un accesso ambulatoriale o un episodio di cura di maggiore peso, quale ad esempio un ricovero in acuzie), quale è l’informazione da enfatizzare e quale è il rumore da limitare, perché non nasconda il senso di ciò di cui il sanitario abbisogna per poter correttamente interpretare il quadro clinico?

Ho l’impressione che siamo di fronte a sfide inedite: temo che non possiamo più limitarci a dire che i sistemi che implementiamo debbono essere usabili e completi di tutte le informazioni disponibili, questo è ormai scontato, anche se non semplice da garantire… Ciò che mettiamo a disposizione deve anche essere “utile”.

Ciò significa che: pur non avendo ancora vinto la sfida delle doppie imputazioni di dati – a causa della scarsa o inesistente cooperazione applicativa che riusciamo a garantire -, pur non riuscendo ancora a garantire una adeguata usabilità applicativa – a causa di una scarsa ergonomia degli strumenti che ancora appartengono ad ere tecnologiche precedenti l’attuale -, siamo già costretti a combattere la battaglia delle significativa delle informazioni. Non riusciamo a far galleggiare l’informazione utile sul mare dei dati inutili, tutto è indistinto, parte del CAOS randomico di troppe informazioni scarsamente rilevanti.

Quali siano i dati “utili” rispetto al rumore, lo dovremo di certo definire sul campo, aiutati dalle tecniche che stanno prepotentemente emergendo grazie all’egregio lavoro che stanno facendo i “Data Scientists” che mettono a punto ogni giorno armi affilate per sfidare il CAOS.

Se dovessimo definire una priorità in base alla quale modellare il progetto dei sistemi informativi della prossima generazione, questa debba essere la priorità principale: creare sistemi completi ed usabili, ma che siano focalizzati sui bisogni dei singoli professionisti, quindi meno “time consuming” di quelli attuali.

Penso che ricontatterò il mio amico medico e gli dirò: “Parliamone, è ora di trovare una qualche soluzione…”

Idee per “Next Generation Healthcare Information Systems“.

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Digging Twitter Users with Python

Tanks to the powerful Twitter REST API, it is easy with few lines of python code to extract useful information from the Twitter Engine.

The tool is written in python – it works in Python 2.7 and Python 3 – and it is quite handy to dig Twitter users, in particular it deals with Followers and Friends of a Twitter Account. You can download the code from https://github.com/pghedini/twitter_users

Features

The tool, by means of Twitter REST API, gets Followers and Friends of a given user. it provides the New followers and the Lost followers since the previous run.

It gives also the Not Following Friends: the Friends not following the given user.

Tot: 520 follower.
New follower: 10
Lost follower: 1
Unchanged follower: 509

Tot: 795 friends.
Friends not following: 355

In verbose mode, the tool gives the lists of New Followers, of Lost Followers and Not Following Friends.

Conclusion

The code is straightforward and you will be able to modify it to custom its features.

Enjoy and let me know if you like it in twitter @pierfghedini.

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

FHIR CLI updated to 1.4.0

Now FHIR CLI is STU 3 compliant. The easy to use Command Line Interface to HL7 FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – now supports also the latest version of the standard.

In order to use it, download the libraries from GITHUB: https://github.com/pghedini/fhir-cli and follow the instructions to use the STU 3 compliant client.

Let’s see an example session:

# Import the version STU 3 Candidate compliant
In [1]: from client_v3 import *

In [2]: cli = init_client()
Using FHIR Server: http://fhir3.healthintersections.com.au/open/
Verbosity LOW
No logging file.
No console logging.

# let's see the supported resources

In [3]: RESOURCES

In [3]: RESOURCES
Out[3]: 
[u'Account',
 u'AllergyIntolerance',
 u'Appointment',
 u'AppointmentResponse',
 u'AuditEvent',
 u'Basic',
 u'Binary',
 u'BodySite',
 u'Bundle',
 ...
 u'Patient',
 ...]

# and how much are they
In [4]: len(RESOURCES)
Out[4]: 114

# or make a query
resp = read(cli, "Patient/example")
# ...

HL7® and FHIR® are registered terms of the subject having right (HL7 organization).

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

HP Prime – The missing command

HP Prime Calculator

The HP Prime Missing Command

Frequently I must inspect the values that a function takes in a list of points or I have to take some samples of the function in a neighborhood of a point X0.

With HP Prime I can enter the function in “Function App” and plot it. I can also inspect the numerical value it assumes by means of NUM, but it isn’t an easy way to do my job…

So I wrote down some lines of code to make my life easier. I write down – my – missing HP Prime command.

My missing command takes three forms: FORCALC, LISTCALC and FORCALCFORM

FORCALC and LISTCALC use the function stored in F0 function variable. in FORCALCFORM you can enter the function you want to sample directly in an input form.

FORCALC takes three parameters in input:

X_FR – X FROM Value; the start value of the interval to sample;
X_TO – X TO Value; the end value of the interval to sample;
X_STEP – the increment to add at each loop.

Usage: FORCALC(1,5,0.2)

Output: FORCALC samples the function stored in F0 variable from X=1,to X=5, 20 times (0.2 increment at each loop)

Source code:

EXPORT FORCALC(X_FR,X_TO,X_STEP)
BEGIN
LOCAL OUT={};
 FOR X FROM X_FR TO X_TO STEP X_STEP DO
 MSGBOX("X="+X+" F0="+F0(X));
 CONCAT(OUT,F0(X))▶OUT;
 END;
RETURN(OUT);
END;

LISTCALC takes one parameter in input:

LL – List of value to test. The list contains the points you want to sample.

Usage: LISTCALC({1.0, 1.5, 10.0})

Output: LISTCALC samples the function stored in F0 variable in tree points 1.0, 1.5, 10.0.

Source code:

EXPORT LISTCALC(LL)
BEGIN
LOCAL OUT={};
 FOR I FROM 1 TO SIZE(LL) DO
 MSGBOX("X="+LL(I)+" F0="+F0(LL(I)));
 CONCAT(OUT,F0(LL(I)))▶OUT;
 END;
RETURN(OUT);
END;

FORCALCFORM combines the two tools in one.

It takes no parameters in input, but it shows an input form:

In FN you have to input the function to sample, in X_FR the start value of the interval to sample, in X_TO the end value of the interval to sample, in X_STEP the increment to add at each loop. In POINT_LIST you can enter the list of points to sample. If you insert something different from {} in POINT_LIST, X_FR, X_TO, X_STEP will be ignored.

Source code:

EXPORT FORCALCFORM()
BEGIN
// Pay attention, it overwrites the variable F0
LOCAL OUT={};
LOCAL FN="";
LOCAL X_FR=0;
LOCAL X_TO=0;
LOCAL X_STEP=0;
LOCAL POINT_LIST={};
INPUT({FN,X_FR,X_TO,X_STEP,POINT_LIST});
 FN▶F0;
IF SIZE(POINT_LIST)==0 THEN
 FOR X FROM X_FR TO X_TO STEP X_STEP DO
 MSGBOX("X="+X+" F0="+F0(X));
 CONCAT(OUT,F0(X))▶OUT;
 END;
ELSE
 FOR I FROM 1 TO SIZE(POINT_LIST) DO
 MSGBOX("X="+POINT_LIST(I)+" F0="+F0(POINT_LIST(I)));
 CONCAT(OUT,F0(POINT_LIST(I)))▶OUT;
 END;
END;
RETURN(OUT);
END;

Simple and useful.

Enjoy.

You may find interesting also this post: http://informaticasanitaria.it/2014/12/06/hacking-hp-prime/

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

FHIR® $everything operator

In HL7 FHIR ® is present a useful operator to retrieve all information related to Patients and Encounters.

In order to keep this example simple we will use the FHIR CLI (Command line interface) to build the resources and to interact with the FHIR server.

Use of $everything operator

The $everything operator is used to return all the information related to the resource on which this operation is invoked, Encounter and Patient. The response is a bundle of type “searchset”. At a minimum, the patient/encounter resource itself is returned, along with any other resources that the server has that are related to the patient/encounter, and that are available for the given user. The server also returns whatever resources are needed to support the records – e.g. linked practitioners, medications, locations, organizations etc

Two input parameters are:

start_date -> The date range relates to care dates, not record currency dates – e.g. all records relating to care provided in a certain date range. If no start date is provided, all records prior to the end date are in scope.
end_date -> The date range relates to care dates, not record currency dates – e.g. all records relating to care provided in a certain date range. If no end date is provided, all records subsequent to the start date are in scope.

Let’s see operator in action

Start FHIR CLI typing in a python interpreter…

from client import *
cli = init_client()

And now, execute the command…

# Basic invocation on a Patient instance
# 
resp = everything(cli, "Patient/example")

If the resource instance “Patient/example” exists will be returned an out put like this:

POST Url: http://fhir3.healthintersections.com.au/open/Patient/example/$everything
Output code: 200

Other possible invocations are:

# Invocation on all Patient resources
# 
resp = everything(cli, "Patient")

# Basic invocation on an Encounter instance 
resp = everything(cli, "Encounter/example")
# Invocation on all Encounter resources
resp = everything(cli, "Encounter")

Pierfrancesco Ghedini

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Twitter

Facebook

Google

Informatica Sanitaria e Software Medico

Il BLOG della tecnologica applicata alla pratica sanitaria

Le sfide della nuova generazione di sistemi informativi sanitari, puntata #2

FHIR client CRUDS

Machine Learning development platform

Health Information Technology Cybersecurity – the architecture

Architecture schema

The roles

The double role of IoT and IoMT

The cyber-security architecture

Test systems and Maintenance activity

GDPR orchestration

Use case

Key points

Conclusion

Sul dare fiducia – Trusting Trust –

CAD e dintorni: Regole tecniche in materia di documenti informatici

Di cosa tratta il decreto?

Quali le principali novità e gli aspetti salienti

Tempi di attuazione ed adeguamento dei sistemi

La documentazione clinica nel ventunesimo secolo

Big Data in sanità?

Le 5 dimensioni dell’EMR

La stima dei tempi operatori e gli applicativi per la pianificazione dell’attività chirurgica

I limiti del registro operatorio informatizzato

Gli applicativi di pianificazione dell’attività chirurgica

L’esplosione del numero dei devices connessi metterà in crisi le nostre politiche di sicurezza

Che cosa vogliono i pazienti dalle app sanitarie?

Le sfide della nuova generazione di sistemi informativi sanitari

Digging Twitter Users with Python

Features

Conclusion

FHIR CLI updated to 1.4.0

HP Prime – The missing command

FHIR® $everything operator

Use of $everything operator