FHIR Dev Days Amsterdam

Overview over security in FHIR / security labels

Grahame Grieve:

OAuth is about delegating authorisation, but most non server devs think it is about authentication. That's because you have to work out who it is before what they can do.

In corporate environments, the user will likely not see the authentication as it is an organisational choice

2 layer OAuth is when you separate the authentication from the authorisation - eg logging in with Facebook, then separately making permission choices

This means that the server doesn't have to handle passwords. I have an option where I can give you a token directly over Skype so you don't have to authenticate [this sounds like indieauth]

HL7 publishes a profile of OAuth hl7.org/fhir/smart-app-launch - you should use this

SMART on FHIR defines a set of scopes class/type.mode eg patient/*.read

These scopes are easy to understand for a server dev, but hard to explain to the user

We need a good set of research on this to explain what is comprehensible to the user and useful for the server

More recently we have looked at a consent model where the patient creates a consent agreement with the server, and updates these over time. This may be tested in January

How we manage the process of consent is hard - the scopes are too simple please now, but making them clear is hard

The OAuth scopes interact with access control - scopes, what data, what scopes are allowed what other consents are applicable

FHIR does not specify the access control layer - you can use SCIM Gwent should discuss whether we should to this further

As part of security you should maintain an extremely comprehensive audit trail. AuditEvent is how we model this typically is create only append. Consider signing the audit trail - putting the hash in a public blockchain could be good

The most skilled insider attacks involve hacking the data and then hacking the audit trail too

The Provenance resource gives information about the source of information - who what when where and why

This information is demoralised as lots of servers don't track provenance, but we should do this more

We have a Signature resource that covers digital signature, scans of physical signatures and more. You can use this to carry a png of a paper signature or a digital one

We have canonicalisation of resources so that you can sign a resource that survives format transformations

Bundle has a signature that signs the resources in the bundle, given canonical rules

There is not much point signing an individual resource, as the related resources matter too.

If you move resources between servers it will reidentify the resources, changing the canonical structure and breaking the signature

Security labels are for resources that need special handling - vip patients, confidential records etc. Every resource has a slot for a security label.

This labelling is to help the access control layer. You can also label an http request - eg break the glass protocol to get emergency access

We have defined some core labels: purpose of use (treatment, research, legal, claims)

There are confidentiality codes unrestricted, normal, restricted, very restricted

There is also a "delete after use" label

You should use markdown processors that ignore html

There is another spec called UMA but it still means that the resource server needs to do the token management

Whenever you talk about data ownership you are still talking about the person you are authenticating

FHIR usage in countries


Alexander Henket:

In the Netherlands MedMij is about creating an EHR environment without developing an EHR - an exchange for digital health data between patients and professionals

Trust is vital for this goal MedMij is not a network in itself, it uses existing networks - the national spine uses FHIR to bridge the patient domain and the healthcare domain

the healthcare domain is a v3 CDA model so we have some challenges in building this

we have ZorgDomein that handles lab requests, referalls and consultation - they are now switching this to have aFHIR api

Koppeltaal is working on serious gaming for healthcare mainly for autism spectrum - they use SMART on FHIR

what happens if everyone is building profiles all over the place - we have put together a HL7 NL FHIR council and team to share profiles using Simplifier

we have large scale investments in FHIR STU3 - not planned 4 transition yet. links: medmij.nl zorgdomein.nl koppeltaal,nl


Oliver Egger:

In Switzerland there is not yet much adoption of FHIR 0 we are focusing on IHE XDS/CDA-CH V2

in HL7 Switzerland we have a FHIR group that meets regularly and developing profiles

we have a lot of primary systems that connect to each other - connecting cloud to local systems - these primary systems are staring to use FHIR to exchange data

the immunization database is CDA based but is also building a FHIR interface

the IHE ORF Profile for form exchange was not working so we are modelling this in FHIR as Questionnaire and we want to bring this to standard

eMediplan on FHIR is for making a current medication list for patients - we make a MedicationPlan bundle of MedicationPlans


Simone Heckmann:

we founded the German hl7 fhir committee about 3 years ago - we wanted to gather the German community first

we have a German stream on Zulip, which is the living room for the German community

we are using Simplifier to host our german based profiles, and use the webhook to a github repository for issues, and link these from Zulip

we published an Implementation Guide too and are gathering feedback

we have the Medication plan that @oliveregger already described - with a printed list and a barcode to scan to get the data

we have a simplifier hosted profile to describe that medication plan


Josh Mandel:

I want to talk about FHIR n the US realm bit.ly/us-realm-devdays

Argonaut is a project of EHR vendors, HL7 and others - part fo this was the way of launching apps in SMART

we now have a FHIR US Core and now an International model

we are defining a common data set of 20 types that are now US Core profiles in FHIR

in 2017 we have focused on Scheduing and clinical decision support

hl7.org/fhir/us/core defines minimum conformance requirements for accessing patient data - this is built on STU3

most of these profiles are locking down vocabularies and coding systems

the sync for science protocol lets research participants share EHR with researchers bit.ly/s4s-overview-2017

Dav Vinci Project is encouraging the shift from pay for treatment to pay for outcome - we need clinical data not procedural data

we need a common approach for measuring clinical data so that we can compare outcomes

we have ONC funded improvement to FHIR infrastructure, including bulk data access

we are working to integrate CIMI clinical models with FHIR and dealing with terminology management and integration

we are working to use FHIR to model clinical trials and representing drug products and substances


Lloyd Mackenzie:

FHIR has been slowet than the us as we wore ourselevs out adopting HL7 v3, but it is picking up now

Ontario had issues that delayed v3, so they are adopting FHIR instead

we have a FHIR Working Group which is the most active - building Use cases for business drivers

we also have URI strategy and tooling groups

we are analysing requirements for e referrrals but not implementations yet

Ontario had immunisations on FHIT in 2016 and prescribing and consultation in 2017 - working on patient, organisation and practitioner registries

we have a national FHIR registry on Simplifier, and are mapping terminology services to FHIR

we are also mapping OIDs frim version 3 to URIs for FHIR

Advanced Java API


this is the HAPI FHIR advanced session, covering various aspects see goog.gl/MQVf6s

fhirtest.uhn.ca is our webpage test overlay - it will let you search for patients and other resources - this isn't using special hooks, it uses the HAPI FHIR model

you can talk to any FHIR server you want using the test page overlay, its not HAPI specific

It loads the FHIR capability statement from the server and uses it that way

if you're trying to solve any real world problem you probably have extra requirements - eg adding eye color for opthalmology

you can add extensions by AddExtension with a URI and a value, or you can do it with custom classes which gives you compile time checking

Validation is an age old question - how strict to be; whether to reject invalid data on the way in, potentially causing data loss

The Parser Error Handler catches structural errors and calls the hook on Error. The Semantic Validator checks invariants and required resources too

The Schama and Schematron validators check cardinality, optionality, Required bindings Datatype rules

Profile validation uses the StructureDefinition, ValueSet and CodeSystem resources that tighten resource definitions - eg require name

it can also constrain to allow only certain codes in the system - eg LOINC subsets

to get help documentation is at http://hapifhir.io We also have a Google Group / Mailing List https://groups.google.com/d/forum/hapi-fhir

we really welcome pull requests and issue requests on HAPI FHIR https://github.com/jamesagnew/hapi-fhir

Keynote - Google Brain

Eyal Oren:

I'm a product manager on the Brain team at google that works on machine learning with FHIR - I don't have to explain FHIR to this audience

there are other teams at google working on healthcare data as well as Brain

a lot fo people search medical conditions on google - we curate content with medical expert to provide high quality results

Deepmind is part of Google in the UK - you may know them for being the world's best Go player - they also build an app called Streams built on FIHR

Verily is a sister company of Google that works on life sciences - there is precision medicine initiative and they use FHIR too

The Google Cloud platform has BigQuery, Dataflow and Datasets - this is HIPAA compliant and lot of healthcare datasets are on google cloud

The Brain team focuses on deep learning with neural nets I'm going to build a net onstage to explain this

A classic example is having a lot of spammy emails and good emails, and deciding how to categorise them

say we count capital letters and the amount of money mentioned, would they divide the set

go to playground.tensorflow.org and train this model with me

what do we use this for? we use it for finding cats and dog on YouTube

the vast majority of emails sent are spam - gmail now uses a neural net for spam; we use them to translate languages too

the last example is Smart Reply for Inbox - we autogenerate 3 replies to choose from, and people pick these about 10% of the time

as well as using this for products, we release the code - Tensorflow is the #1 machine learning repository on github

we also release models as well as code

one in four patients have an adverse event in hospital - something that could have been prevented

90% of us hospitals use EHRs but most of this is never used; almost all models ignore notes, and have poor accuracy

most predictive models don't use much of the data in the EHR. Our goal is to use the entire EHR to make accurate predictions

the problem is that the data is really messy

data is in many different schemas; there are many coding systems - there are also a lot of variables to look at as well

we looked at lots of medical records, and decide to use FHIR internally and translate into it

Standards work is hard -if you do it right, nobody notices your work; if you do it wrong, nobody uses it and doesn't see your work

any term like glucose or levophed has many different ways of spelling it, including "levoped"

deep learning can place words in a vector space and give you examples of related mappings eg country to capital

I did the smae for disease and drug - diabetes - metformin hypertension - metprolol

we can also find nearest neighbours eg hd/crrt/hemo/cvvhd/esrd

how we handle data: convert data schemas to FHIR; many coding systems and codes - keep all and learn embeddings

we like that FHIR has lots of possible coding systems, so we like having all of them to correlate

internally at Google we use Protocol buffers for everything, so we mapped FHIR into Protobufs

we translate the structure definitions for all STU3 resources into protobuffers, and we intend to open source these in months

we loaded a lot of this data in protobufs and can run BigQuery over it - we have a publicly available deidentified data set

having protobufs means we can manipulate FHIR data in memory in python, Go etc

we added 2 extensions to FHIR - Labels to say what to train against and Predictions for what the model says

we would like to share these extensions with other developers

we think Deep Learning can be relevant for EHR data; we use FHIR as core data internally and built tools that we want to share


what is easier to process - the codes or the text?

Eyal Oren:

we look at the data as a timeline of events that occur to the patient. Notes normally describe things that happened earlier

the timestamp of the note is not the timestamp of the observation

machine generated readings have more accurate timestamps and are more often

coded data has value but not because it has coded so much as because it is automated


the tools for turning data into FHIR - could those speed up our processes for this too?

Eyal Oren:

we have those tools available, we would like to make them available, but we use internal infrastructure so need to work out how to share

we have a lot of infrastructure at google for changing data from one format to another, so we could help that


what about privacy?

Eyal Oren:

this is all deidentified medical records from research partners, not google customer data. it's all encrypted and kept safe

the BigQuery I showed ran on encrypted data, decrypting as we read it and returning the result


Sander Laverman:

I built the R on FHIR library to pull FHIR data into R for manipulation

I'm connecting to the http://vonk.furore.com public data and reading an example patient into a dataframe

the resources are all nested - we are looking at how to flatten this into useful tables

we support Read and Search interactions, not writing data back


in the google talk they talked about applying extensions for labels and predictions to the FHIR data, and we'd like that

Sander Laverman:

At the moment we don't write back, but that could be an extension

The R on FHIR project is on github - do send us issues there: https://github.com/furore-fhir/RonFHIR


can it do auth?

Sander Laverman:

not yet, but that is on the list

See IndieNews