Archivio dell'autore: Pierfrancesco Ghedini

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.

Sul dare fiducia – Trusting Trust –

Ken_Thompson

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

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

HP Prime – The missing command

HP Prime Calculator

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:

SchermoPrime

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

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

FHIR® $everything operator

FHIRIn 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

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

FHIR® Document production from Resource Composition

FHIRAs FHIR documentation says “FHIR resources can be used to build documents that represent a composition: a set of coherent information that is a statement of healthcare information, particularly including clinical observations and services. A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices. Documents built in this fashion may be exchanged between systems and also persisted in document storage and management systems, including systems such as IHE XDS. Applications claiming conformance to this framework claim to be conformant to FHIR documents”

The FHIR Document Operator produces a document from a given composition.

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 document operator

Start FHIR CLI typing in a python interpreter…

from client import *
cli = init_client()

Create a document from a Composition Resource…

resp = document(cli, "Composition/example")
# resp is a bundle to decode
bu = Bundle(resp.obj())
# Now loop over bundle entries
for ent in bu.entry:
    print(html2text(ent.resource["text"]["div"]))

Tying the “resp” variable you can see the executed command

GET Url: http://fhir3.healthintersections.com.au/open/Composition/example/$document?persist=false
Output code: 200

if you want to make the document persistent, set “persist” attribute to True

resp = document(cli, "Composition/example", persist=True)

If you inspect the returned resp variable, you will see something like this

GET Url: http://fhir3.healthintersections.com.au/open/Composition/example/$document?persist=true
Output code: 201

The document was produced and the output code is 201 (OK)

 

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.

HL7® FHIR® CLI – Command Line Interface

FHIRAre you looking for an easy to use Command Line Interface to HL7 FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – ?

If you answered “YES”, take a look at this python project.

You are not required to be a programmer in order to experiment with FHIR or to test a FHIR server you are implementing.

Read the “README” file for a lot of examples and CLI usage.

Enjoy.

Pierfrancesco Ghedini

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

CAD e dintorni: Regole tecniche in materia di documenti informatici

Agenzia per l'Italia Digitale

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.

Licenza Creative Commons

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

La documentazione clinica nel ventunesimo secolo

Annals Of Internal Medicine

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:

  1. 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;
  2. la documentazione gestita negli EHR deve supportare il processo cognitivo del sanitario durante la fase di redazione della documentazione;
  3. 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;
  4. per quanto possibile, non si deve richiedere l’inserimento della conferma di azioni effettuate  quando l’effettuazione di queste risulti chiaro dalla documentazione presente;
  5. 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.

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.