Archivio della categoria: HL7

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® $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® 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.

FIHR, HL7 reinventato

HL7 Italia Logo

HL7 Italia

Magari non sarà la specifica più pulita che si sia mai vista nel mondo degli standard sanitari, ma FIHR sembra pensato per incuriosire ed intrigare.

Consiglio, anche a chi voglia solo avere una idea di cosa si sta parlando, una semplice navigazione nella documentazione messa a disposizione sul sito ufficiale – http://www.hl7.org/implement/standards/fhir/index.html -. Ancora più illuminante può essere partire dai principali concetti che è possibile modellare in FIHR – ad esempio dal concetto di paziente – e da lì navigare sui diversi link che il chiaro schema UML riassume.

Ad esempio cliccando sul primo attributo identifier è possibile consultare la definizione di “identificatore paziente”, cliccando invece su name si nota che è di tipo HumanName e, se lo si desidera, si possono visualizzare anche possibili esempi di codifica.

Se poi si è curiosi di sapere che cosa è possibile collegare all’entità paziente, basta consultare l’elenco riportato: AdverseReactionAlertAllergyIntoleranceCarePlanCompositionConditionDeviceDeviceObservationReportDiagnosticOrderDiagnosticReportDocumentManifestDocumentReferenceEncounterFamilyHistoryGroupImagingStudyImmunizationImmunizationRecommendationListMediaMedicationAdministrationMedicationDispenseMedicationPrescriptionMedicationStatementObservationOrderOtherProcedureQuestionnaireRelatedPersonSecurityEventSpecimen e Supply.

Qualora volessimo sapere come si modella il legame fra un paziente è, per esempio, un ordine, basterà cliccare su Order. Dal chiaro diagramma UML che verrà visualizzato, sarà facile verificare come il paziente sia il “subject” a cui eventualmente l’odine fa riferimento.

Non ci sono scuse, più chiaro di così…

PG.

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

Il modello di consenso previsto nel FSE

HL7logo

AGID

 

Con la emanazione delle “Linee guida per la presentazione dei piani di progetto regionali per il FSE” da parte di AgID e Ministero della Salute – così come previsto dalla Legge n°98/2013, conversione del DL 179/2012 – si è posto un importante tassello non solo per la costituzione del Fascicolo Sanitario Elettronico, ma anche per la modellazione dei sistemi informativi sanitari conferenti informazioni alle infrastrutture di FSE.

Detta linea guida trae le mosse da due importanti lavori pubblicati nella apposita sezione del sito di HL7 Italia:

In questo articolo, in particolare, viene preso in esame il modello di consenso privacy previsto in questi documenti e le ricadute che un tale modello può avere per i sistemi informativi delle aziende sanitarie che dovranno conferire dati e documenti alla infrastruttura regionale di FSE.

Le linee guida prevedono diversi livelli di consenso, di seguito descritti.

Consenso alla alimentazione dell’FSE

Il FSE può essere alimentato solo con consenso esplicito, libero e informato reso dall’assistito o di chi lo rappresenta a seguito della visione della relativa informativa. Il consenso all’alimentazione del FSE, anche se manifestato unitamente a quello previsto per il trattamento dei dati a fini di cura all’interno dell’Azienda Sanitaria, deve essere autonomo e specifico. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

NOTA BENE: occorre tenere presente che il cittadino deve poter acconsentire, o meno, anche al caricamento nell’FSE di dati pregressi alla fornitura di questo consenso, per cui – nella pratica – occorrerà chiedere al cittadino se intende autorizzare l’alimentazione dell’FSE da quel momento in avanti, ma anche se intende permettere il caricamento dei dati pregressi al consenso. PG.

Consenso alla consultazione dell’FSE

La consultazione dei dati e dei documenti presenti nel FSE, da parte dei MMG/PLS o degli operatori e professionisti sanitari e socio-sanitari che abbiano necessità di trattare i dati per finalità di cura, può avvenire solo previo consenso libero ed informato espresso dell’assistito. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Accesso all’FSE in emergenza

Deve essere garantito l’accesso in emergenza. Nello specifico, un professionista sanitario o del sociale, anche se non ricopre il ruolo per il quale è stata abilitata la consultazione (sulla base delle policy di visibilità indicate dall’assistito), può consultare le informazioni rese visibili dall’assistito, ossia, i dati e documenti non devono essere stati oscurati o essere stati anonimizzati da parte dell’assistito. Per ogni accesso in emergenza, il professionista deve fornire esplicita dichiarazione sottoscritta. Resta inteso che l’accesso in emergenza può essere effettuato solo se l’assistito ha espresso il consenso alla consultazione del FSE.  (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Consenso per minore o sottoposto a tutela

Nel caso di assistito di minore età o sottoposto a tutela, sia il consenso all’alimentazione sia il consenso alla consultazione devono essere espressi dal soggetto che esercita la potestà o da colui che lo rappresenta legalmente, in qualità di tutore, amministratore di sostegno o altra legittimazione. Al raggiungimento della maggiore età, sia il consenso all’alimentazione che il consenso alla consultazione devono essere confermati da un’espressa dichiarazione di volontà del neo- maggiorenne, da rilasciarsi dopo aver preso visione dell’informativa. I consensi precedentemente resi devono essere automaticamente invalidati in attesa che il neo-maggiorenne esprima i nuovi consensi. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Consenso per dati a maggior tutela dell’anonimato

I dati e i documenti sanitari e socio-sanitari a maggior tutela dell’anonimato – dati relativi a sieropositività, interruzione volontaria di gravidanza, violenza, assunzione di sostanze stupefacenti/psicotrope/alcool, servizi offerti da consultori familiari – possono essere resi visibili previo consenso esplicito reso dall’assistito. E’ responsabilità dei professionisti o degli operatori sanitari che erogano la prestazione acquisire l’esplicito consenso dell’assistito. Inoltre, se l’assistito sceglie di ricorrere alle prestazioni in anonimato, tali dati e documenti non devono confluire nel FSE. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Oscuramento di dati e documenti

L’assistito può decidere, nel momento dell’accettazione, in sede di refertazione oppure in una fase successiva all’alimentazione, se e quali dati e documenti, creati in occasione delle singole prestazioni erogate, non devono essere resi visibili (ossia oscurati) nel proprio FSE senza che vi sia evidenza di tale scelta in fase di consultazione (oscuramento dell’oscuramento). I dati e i documenti oscurati devono essere consultabili solo dall’assistito e dal titolare che lo ha generato (ossia, l’autore del dato/documento). L’assistito ha comunque facoltà di rendere nuovamente visibile un dato o documento precedentemente oscurato. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Revoca dei consensi

Le forme di consenso precedentemente citate possono essere revocate. La revoca del consenso all’alimentazione determina l’interruzione dell’alimentazione del FSE senza conseguenze rispetto all’erogazione delle prestazioni del servizio sanitario e dei servizi socio-sanitari. Se il paziente revoca il consenso alla alimentazione e successivamente esprime un nuovo consenso (reso in forma esplicita, libera ed informata), vengono resi nuovamente visibili nel FSE i dati e i documenti che lo hanno alimentato fino alla precedente revoca del consenso alla alimentazione, in accordo con le regole di visibilità precedentemente impostate dall’assistito. Il FSE viene comunque alimentato da eventuali correzioni dei dati e dei documenti che lo hanno composto fino alla revoca del consenso, da parte degli organismi sanitari che li hanno generati e che mantengono la titolarità. I dati e documenti prodotti durante il periodo di revoca del consenso alla alimentazione del FSE non sono automaticamente inseriti a seguito del nuovo consenso. La revoca del consenso alla consultazione determina invece l’interruzione dell’accesso per la consultazione dei dati e documenti presenti nel FSE da parte dei MMG/PLS e degli operatori sanitari e socio-sanitari, inclusi gli operatori in emergenza. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Schema riassuntivo delle diverse casistiche di consenso

Consenso all’alimentazione

Revoca del consenso all’alimentazione

Consenso alla consultazione

Il FSE viene alimentato.
Il FSE può essere consultato dall’assistito e dagli operatori il cui ruolo rispetta le policy di visibilità indicate dallo stesso. In caso di emergenza, l’accesso alle informazioni rese visibili dall’assistito – non oscurate o non anonimizzate – è consentito a tutti gli operatori che devono comunque esprimere esplicita dichiarazione di necessità di consultazione.

Il FSE non viene più alimentato, salvo per eventuali correzioni di dati e documenti che hanno composto il FSE prima della revoca.

Dati e documenti che hanno composto il FSE prima della revoca possono essere consultati dall’assistito e dagli operatori il cui ruolo rispetta le policy di visibilità indicate dallo stesso. In caso di emergenza, l’accesso alle informazioni rese vinili dall’assistito è consentito a tutti gli operatori che devono comunque esprimere esplicita dichiarazione di necessità di consultazione.

Revoca del consenso alla consultazione

Il FSE viene alimentato.
Il FSE può essere consultato solo dall’assistito e non può essere consultato dagli operatori sanitari e socio-sanitari, neanche in caso di emergenza.

Il FSE non viene più alimentato, salvo per eventuali correzioni di dati e documenti che hanno composto il FSE prima della revoca.

Dati e documenti che hanno composto il FSE prima della revoca possono essere consultati dall’assistito.
Il FSE non può essere consultato dagli operatori sanitari e socio-sanitari, neanche in caso di emergenza.

NOTA BENE: lo schema sopra riportato è stato ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica.

E’ quindi plausibile che le applicazioni aziendali che raccolgono dati e documenti che devono essere conferiti all’FSE – in cooperazione applicativa – debbano gestire questi consensi:

  1. consenso al trattamento specifico per l’episodio di cura – o recepimento della volontà del cittadino di oscurare/anonimizzare l’episodio sul sistema informativo aziendale -;
  2. consenso al conferimento all’FSE; NOTA BENE: di base tale consenso al conferimento dovrà essere negato per i dati soggetti a maggior tutela dell’anonimato, salvo diversa intenzione del cittadino; il cittadino potrà oscurare un qualsiasi conferimento all’FSE che di base sarebbe autorizzato per dati sensibili ordinari;
  3. eventuale verifica della policy di accesso al dato su FSE da parte del professionista nel caso l’accesso all’FSE avvenga in cooperazione applicativa; VEDI NOTA del successivo punto 2. dell’FSE;
  4. consenso all’accesso in emergenza all’FSE con raccolta della motivazione fornita dal professionista.

L’FSE – che sia in cooperazione applicativa con una certa realtà aziendale – dovrà invece gestire i seguenti consensi:

  1. consenso all’alimentazione dell’FSE e consenso all’eventuale caricamento dei dati sensibili esistenti pregressi alla fornitura del consenso alla alimentazione;
  2. consenso alla consultazione dell’FSE da parte di specifiche categorie di professionisti sanitari che operino dall’interno dell’azienda; NOTA BENE: la verifica delle policy di consultazione dell’FSE da parte dei professionisti potrebbe essere demandata ai sistemi informativi della aziende sanitarie che siano connessi in cooperazione applicativa;
  3. oscuramento/anonimizzazione di dati precedentemente conferiti.

Entrambi gli ambiti dovranno poter gestire la revoca dei consensi precedentemente forniti e i consensi per minori e i soggetti sottoposti a tutela.

Pur da una rapida analisi come quella sopra proposta, lo scenario complessivo risulta non di semplice realizzazione e gestione e non privo di ricadute per i sistemi informativi aziendali che debbano interoperare con un FSE.

PG.

Dopo la assai resistibile ascesa della V3 ecco aprirsi in HL7 l’era di FHIR

HL7logoLa documentazione di FHIR, che si pronuncia FIRE come fuoco in inglese, annuncia, non senza una certa retorica, che il Fast Healthcare Interoperability Resources è lo standard per scambiarsi informazioni sanitarie in formato elettronico. Nulla di meno: come se i tentativi fatti fino ad ora e che hanno visto generazioni di tecnici arrabattarsi ad usare le diverse versioni 2.X in attesa di un sempre annunciato, e mai concretizzato, avvento della mitica V3 non volesse dire nulla.

Ora che cominciavamo a pensare di aver finalmente capito quel modo di lavorare, ecco che HL7 partorisce un altro pargoletto che già urla forte e si fa sentire nelle ovattate e un po’ sonnolente fabbriche del software sanitario.

È un pargoletto ancora in fasce il nuovo nato, ma dalle grandissime ambizioni se dal confronto con i precedenti standard – si veda a questo proposito http://www.hl7.org/implement/standards/fhir/comparison.html – emerge che:

  • FHIR può soddisfare le necessità che erano precedentemente coperte dagli standard di interoperabilità HL7 (V2, V3, CDA);
  • FHIR fornisce benefici in termini di facilità di interoperabilità e quindi esiste la possibilità che esso gradualmente sostituisca alcuni o tutti i propri predecessori.

La medesima fonte precisa, tuttavia, che non è chiaro quanto rapido sarà questo processo di migrazione, per cui è possibile che per un certo periodo questo nuovo standard conviverà con i propri predecessori.

Fra gli innegabili vantaggi di FHIR vi è sicuramente la leggibilità e se ad esso abbiniamo i possibili vantaggi derivanti dall’impiego della tecnologia di trasporto REST probabilmente siamo davvero di fronte ad una possibile rivoluzione.

Speriamo sia davvero così.

PG.

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