Archivi tag: mHealth

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.

Le APP mediche nella normativa statunitense ed europea

L’FDA – Food and Drug Administration – fornisce importanti indicazioni sullo sviluppo di APP Mobili in particolare quando queste abbiano anche la caratteristica di essere dispositivi medici.

È possibile trovare tutte le necessarie informazioni a questo indirizzo:

http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/ConnectedHealth/MobileMedicalApplications/ucm255978.htm

Una sintesi dei principali documenti in materia è rintracciabile anche a questo indirizzo: “Developing mobile apps as medical devices: Understanding U.S. government regulations

Una sintesi delle normative applicabili a livello europeo è rintracciabile al seguente indirizzo:

Guidance on medical device stand-alone software (including apps)

PG.
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.

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.

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

Immagine da diagnostica PET

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.

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