Archivi categoria: eHealth

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

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

Le sfide della nuova generazione di sistemi informativi sanitari

AI and Healthcare

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

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

FHIR client CRUDS

FHIR Release 3

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

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

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

Health Systems Cybersecurity Schema

The  roles

All users can be modeled in only three main roles:

  1. the guests – not authenticated users -;
  2. the professionals – authenticated users who use systems from inside and outside the HA -;
  3. 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

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

FHIR CLI updated to 1.4.0

FHIR_3

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

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

FHIR® resource validation

FHIRIn HL7 FHIR ® is quite easy to validate – to check the syntactic correctness – a resource by means of a FHIR server.

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.

Validation of a resource in XML format

Start FHIR CLI typing in a python interpreter…

from client import *
cli = init_client()

Store the resource in a variable called “res”

res = '''<Patient xmlns="http://hl7.org/fhir">
<id value="pat1"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">

<p>Patient Donald DUCK @ Acme Healthcare, Inc. MR = 654321</p>

</div>
</text>
<identifier>
<use value="usual"/>
<type>
<coding>
<system value="http://hl7.org/fhir/v2/0203"/>
<code value="MR"/>
</coding>
</type>
<system value="urn:oid:0.1.2.3.4.5.6.7"/>
<value value="654321"/>
</identifier>
<active value="true"/>
<name>
<use value="official"/>
<family value="Donald"/>
<given value="Duck"/>
</name>
<gender value="male"/>
</Patient>'''

Now execute the FHIR validate operation

resp = validate(cli, resource="Patient", par=res, format_acc="xml")

See the response code in order to check the operation result

resp.resp_code()

or simply type the variable name “resp” to display the output of the command

resp

You will see something like this:

<?xml version="1.0" encoding="UTF-8"?><OperationOutcome xmlns="http://hl7.org/fhir"><text><status value="generated"/><div xmlns="http://www.w3.org/1999/xhtml"><p><b>Operation Outcome for :Validate resource </b></p><p>All OK</p></div></text></OperationOutcome>
POST Url: http://fhir3.healthintersections.com.au/open/Patient/$validate?async=false
Output code: 200

The operation “POST Url: http://fhir3.healthintersections.com.au/open/Patient/$validate?async=false” was All OK
The resource is validated.

Validation of a resource in json format

In this example we will build a resource using the resource constructor (Patient()), but, if you prefer, you can store directly the json object in a variable and validate it in the previously seen way.

pa = Patient({"resourceType":"Patient", "id": "pat1", "name":[{"family":["Donald"],"given":["TestName"],"use":"official"}]})
# check the content of pa simply entering pa variable
pa

and validate it.
Pay attention: to obtain the json representation from Patient resource stored in “pa” variable, use pa.json

resp = validate(cli, resource="Patient", par=pa.json, format_acc="json")

See the response code in order to check the operation result

resp.resp_code()

Pierfrancesco Ghedini

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

Give my health data back!

Question

Question

In a short time a huge part of our health datas will be scattered on the servers of many different companies around the internet. How are you going to have them back? How will you be able to consolidate them on one single EMR?

The lack of adequate standards and the lack of will to do so will prevent us to get them back.

We expect a hard work.

PG.

 

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

Le 5 dimensioni dell’EMR

Dimensioni dell'EMR

Dimensioni dell’EMR

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

  1. UTILITÀ PER IL PAZIENTE;
  2. UTILITÀ PER IL PROFESSIONISTA;
  3. VALENZA SOCIALE;
  4. SEMANTICA;
  5. 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.

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

Non solo luci nell’IT sanitario, ma attendiamo un grande 2015

www.politico.com

www.politico.com

L’informatica sanitaria non è una strada lastricata di facili successi: chiunque se ne occupi lo sa.

Leggendo gli impietosi resoconti che ci giungono da oltre oceano a proposito della riforma da 30 miliardi di dollari voluta dalla Amministrazione Obama, ci si rende conto che le difficoltà in cui si dibattono i colleghi americani, sono le stesse di tutti.

In un recente articolo intitolato “High noon for federal health records program?” si afferma che:

  • fin dal 2011 i medici e gli ospedali statunitensi hanno dovuto dimostrare di utilizzare sistemi informatizzati per prescrivere, per prenotare esami e per lo scarico dei dati sanitari in rete; fin da allora, chi voleva beneficiare dei finanziamenti ha dovuto dare prova di gestire informaticamente dati come la pressione sanguigna o lo stato di fumatore del paziente;
  • quando il programma di finanziamenti prese l’avvio solo il 12 percento dei medici possedeva  un sistema informatizzato di gestione dei dati clinici, ora il 60% dei medici ne dispone e la quasi totalità degli ospedali; nessuno dichiara di volere tornare indietro, ma non tutto funziona;
  • i medici che hanno in cura pazienti che aderiscono al programma Medicare possono attendersi finanziamenti federali che possono arrivare a $43,720, ma possono essere assoggettati a penalizzazioni nei pagamenti che possono arrivare al 5%, se non rispondono a tutti i requisiti del programma in termini di informatizzazione;
  • nel primo anno in cui sono state applicate le penali, 250.000 medici hanno avuto penalizzazioni dell’1% nei pagamenti di Medicare;
  • ultimo, ma non meno importante aspetto, si dichiara che i medici hanno impiegato un’ora di lavoro al giorno in più ad inserire dati e quindi hanno visitato meno pazienti con potenziali conseguenti potenziali minori ricavi.

Leggendo questa impietosa analisi, mi è venuto spontaneo pensare che molte delle considerazioni che vengano fatte a proposito della situazione americana, ben potrebbero applicarsi alla nostra realtà.

Potrebbero, forse, essere comuni anche gli antidoti da utilizzare contro il male della cattiva informatizzazione:

  • lavorare in maniera incessante sulla usabilità degli applicativi sanitari e fare in modo che l’informatizzazione sia di ausilio al PDTA – Percorso Diagnostico Terapeutico Assistenziale -piuttosto che una fonte di inefficienza e faccia solo perdere tempo nella digitazione dei dati;
  • lavorare sulla integrazione degli applicativi sanitari per fare in modo che non si debbano inserire più volte le stesse informazioni in contesti diversi;
  • integrare i sistemi informativi dei medici di medicina generale con quelli degli specialisti e delle strutture ospedaliere;
  • riportare il paziente al centro del processo di cura, valorizzando attraverso l’informatizzazione il ruolo dei diversi attori del processo sanitario – che non sono solo i medici -, facendo in modo che l’aggiornamento delle informazioni sia uniformemente distribuito su tutte le figure coinvolte.

Il 2015 sarà un grande anno, un anno cruciale, ne sono certo: sarà l’anno della svolta.

Buon 2015 a tutti i protagonisti dell’informatica sanitaria e BUON LAVORO.

PG.

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

Benessere, stili di vita e dispositivi medici personali: quello che vedremo nel 2015

Logo CNN

Logo CNN

Benessere, salute, corretti stili di vita, prevenzione delle malattie, dispositivi medici personali… quali saranno le tendenze più significative del 2015 nell’ambito dell’Healthcare?

Vedo e prevedo

Indipendentemente dal fatto che si stia consultando una seriosa e paludata rivista medica o il sito più gossipparo di consigli medici a buon mercato, non ci si salva. È fine anno e il gioco che va più di moda è quello della previsione selvaggia.

E chi siamo noi per sottarci a questo gioco?

Le 5 principali tendenze del 2015 secondo la CNN

Nell’articolo 5 digital health trends you’ll see in 2015 vengono citate 5 tendenze principali:

  • i dispositivi indossabili da portare all’orecchio;
  • le strisce che, analizzando il sudore, ci avvisano di potenziali problemi di salute;
  • le custodie per cellulari che fungono anche da dispositivi medici – da misuratori del battito cardiaco, da elettrocardiografi portatili, ecc… -;
  • le app utilizzabili solo dietro prescrizione medica;
  • sorgenti luminose più salutari e che meno disturbano il ritmo sonno veglia – ad esempio tablet che meno dovrebbero interferire con il prendere sonno alla sera grazie a emissioni più rispettose delle nostre reazioni fisiologiche -.

Sono assolutamente conscio che molti lettori, già a questo punto, si saranno fatti delle grasse risate leggendo un tale elenco, ma non sarebbe successo lo stesso se qualcuno prima dell’uscita dell’iPad della Apple ci avesse raccontato che avrebbe avuto un enorme successo un computer che non aveva nemmeno la tastiera e sarebbe stato costituito dal solo schermo.

Posto che non mi interessa molto se il prossimo dispositivo medico personale sarà da cingere al polso o da portare all’orecchio e che la striscia che analizza il mio sudore per dirmi se ho il diabete non mi sembra poi così drammaticamente innovativa, la tendenza che mi intriga maggiormente è la APP che dovrà essere prescritta dal medico. L’articolo, come esempio, cita una applicazione che potrebbe essere di supporto ai pazienti diabetici. Essa raccoglierà dati preziosi riguardo allo stile di vita adottato e, in questo modo, potrà fornire un aiuto prezioso al medico nella personalizzazione della terapia.

Il punto della questione

Forse il punto è proprio questo: nel 2015 assisteremo ad una incredibile fioritura di applicazioni che ci metteranno in grado di raccogliere i dati più disparati: ma chi li leggerà questi dati? chi saprà dare un senso a questa mole di informazioni?

Se sarà un medico ad organizzare questa raccolta e a trarne un senso compiuto forse tutto ciò sarà davvero una piccola rivoluzione. Forse anche chi si sa spiegare peggio di un altro avrà le stesse opportunità di cura di chiunque altro: penso agli anziani, penso a chi ha problemi mentali o di espressione…

Sono fiducioso, attendo con ansia il 2015.

PG.

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