FHIR Dev Days Amsterdam 2017-11-15

welcome to the 4th edition of FHIR DevDays - we have 330 participants from 27 countries and 140 organisations and 50% are here for the first time

What's new in release 4 - FHIR milestones are now named 1,2,3 and 4

a full standard is a normative standard, and commits to non-breaking changes. we have draft standards for trial use

release 4 is due out about the end of next year - it's an 18 month cycle. When we're more stable we may speed up, but for now that is the rate

HL7's goal is to establish FHIR as the primary standard for global health interoperability.

if you look at what data is actually exchanging, not many are using FHIR now, but it is changing as people implement it

FHIR R4 will be the first normative standard - parts will be normative Definition INfrstructure, Data types, xml and json fomrat, restful API, CodeSystem, ValueSet,ConceptMap,StructureDefinition, Patient, Observation

the rest of R4 will be Standard for Trial Use (STU) - Normative parts fall back to STU if they don't pass

Normative ballots can take 5 years - each change will reset the balloting process

we have some challenges in defining what constitutes a breaking change -

We are intorducing FHIR certification - there is proficiency certificate for knowing the spec (R3) - there is a professional certification coming too which requires practical experience. This one is hard, the core team failed it 1st time

We are formalising the Application Launch Protocol as a profile in OAuth /OpenID connect

in RL4 we are paying more attention to supporting multiple versions add a fhir-version to media type application/fhir+json; fhir-version=3.0

we have been working on GraphQL support - we have described how to use it with FHIR - currently supported by test.fhir.org and hapi.fhir.org the R client supports GraphQL

Bulk Data Support - we're expanding the API to support extartion of large data - API for long running request and a format for large amounts of data nd-json and semantics to request it

my servers already support nd-json, so give it a go

Breaking Chnages - renaming ValueSet.compose to ValueSte.definition - that failed

we are proposing switching to github flavoured markdown

there are lots of other breaking changes - look at the inter version maps

we have new content in the specification for case reporting, occupatopnal health, BiologicallyDerivedProduct for blood transfusion

we want to elevate w5 to a formal logical model - we are using RDF for quality and consistencey

we are mapping to more definitional tools eg SNOMED-CT

HL7 develops the FHIR standard; the FHIR foundation supports implementers with guides, collboration groups and runs registry.fhir.org

we need to improve support for national and domain specific adoption programs. Adoption in Europe is mostly informal - plenty of use but no formal requirements

thre is very little use of FHIR in Africa - I'd like to see that change.

We need more support for Aggregate data reporting - we haven't seen this in production yet.

I'd like to broaden cds-hooks - get release 1 out the door then expand it further

there is a lot more that needs to be done with fhir.org

I want a reusable formal review process - like a CKM review or of a national profile as a pattern for multidisicplanary case review

we don't have end point discovery nailed - how do we build a national endpoint registry? What do we need to do to govern and implement these?

Bundle is solid as a rock, everyone has implemented, except the signature part which nobody has used - we need to look at that, maybe drop it

how we measure maturity is a spreadsheet which tracks adoption, maturity, - accessed from the FMG page on the wiki - 50-60 datapoints

this isn't a mathematical safe process, it's a social thing - it is hard to get out of trial use

given that all the fields have minimum cardinality of 0, it is hard to see what is required - not every patient has a name after all

being able to release is conditional on meeting our procedural and technical goals - we can't set a fixed date to meet those.

we have very little experience of signatures on non-static documents

my slides for Java Developers are up at goo.gl/MQVf6s and are creative commons sharealike licensed

code samples are at github.com/furore-fhir/fhirstarters

I'm a software developer and project lead for HAPI, and CTO for Smile CDR, which is built on HAPI

HAPI started in 2001 as a HL7 v2 library and picked up FHIR support in 2012

FHIR has XML and JSON formats, and there is an RDF version in turtle, but nobody has asked for that yet, so HAPI doesn't implement it

before you make new profiles, check the FHIR registry (registry.fhir.org) first and reuse where you can. check the extensions list and Simplifier

you can constrain profiles, but not expand them - for example you can't grow the cardinality of a 0..1 resource, but you can set it to 0

SMART began before there was FHIR - asking "how can we plug apps and services into a variety of health record systems?"

apps were interested in accessing EHR, but the EHR vendors were less interested until we approached via standards - hence FHIR

we want to enable apps to plug into different clinical systems. This needs UX integration; Authorization, Single Sign-On and Clinical Data

SMART stands for Substitutable medical applications - the goal is app choice.

this also means that apps can run in systems by different vendors, and in different contexts

the point is to make the EHR into a platform to handle general things so apps can specialise

we use FHIR for data OAuth for authorization and OpenID Connect for single sign on

SMART can launch an app either as an EHR Portal launch - inside an EHR or Standalone - app launches first then user picks EHR

app can ask for authorization, and for identity of the user. This uses the OpenID Connect OAuth profile

when the app launches, it asks for data access with scopes, gets an auth token back and returns display info

SMART Authorization scopes tay what access an app needs - eg patient/Immunization.read - patient/*.read for whole record

you can ask at the single patient/*.read level or at the user/*.read level - to get the same scope as that user has access to

http://docs.smarthealthit.org/fhir-support/ shows what features are supported by which environment

we have app developer libraries for javascript, puthon and swift, but also for Ruby, .Net and Java

we focused on helping app developers, not EHR ones - we have public sandboxes and commercial ones

the FHIR API has some variations on how you can express data - pick one sandbox first then try on others.

you're building a web app, so you can do any web calls, we focus on connecting to EHR

we have sandboxes for you to test in: http://docs.smarthealthit.org/sandbox/ and an App gallery too

the app gallery has a "try it" button to let you run an app in the sandbox

our sandbox supports FHIR 2 and 3 - some apps only support 2 - the auth is the same between versions

if you want to connect to multiple sources you need to auth multiple times - we have seen developers implement this

if you have multiplel EHRs it may make more sense to build a FHIR bridge so the apps can auth once not twice

we have gone a long way with single purpose apps, and people switching between them. we don't have a way for apps to message each other

could you use a national identity service? you could make each system rely on national ID directly, but getting agreement is a challege

we are working to bring the SMART APIs to the HL7 process. Standalone launch is variable

sneak peek of a development tool - we have a smart app launcher set up that wraps up \choices into a service into a FHIR service URL

We're here to talk about Subscriptions - https://www.hl7.org/fhir/subscription.html how many here have implemented Subscriptions? More than a handful

Subscriptions leans on indexing methods - you ask about resources that matcha search criteria - you can get a ping each time it is created or changed

there is a problem with for example emergency departments where you get a ping when patients are admitted but not when discharged

we're planning more here: http://wiki.hl7.org/index.php?title=201801_FHIR_Subscriptions

in the event definition you can specify the trigger and timing, and set SQL or FHIRpath queries http://build.fhir.org/eventdefinition.html

I prefer an event definition based subscription over a search based one

I don't like search because if things fall out you don't get notified; you would have to keep versions

searching is more intuitive for the user

I have implemented something like this elsewhere - as soon as you set a criterion, return all current matches immediately

if the client wants to track all events then you need to fetch the previous ones and get all notifications

if we have eventual consistency we need ordering of the resources - we may not get all of them in the right order

every version that supports subscriptions should support versioning

the server should logically timestamp it's resources

the specification should discuss this

if you have 2 versions of a fhir resources you don't know what order they are in

my server will try 10 tieme over 10 minutes, and if it still gets errors it turns off the subscription

webhooks aren't always good in firewalled environments - can use server-sent events

with a lot of FHIR servers coming up we have a distributed system and need to integrate

we have the History API, and Subscriptions used to propagate state - it's a problme of change detection

bulk updates and system to system is part of this too - append only transaction log eg postgres, kafka API etc replicate

we have almost everything in FHIR to do transaction log - we need a changes feed - snapshot; subscribe changes; replay changes

we need a snapshot method for FHIR - base backup

have a look at the bulk transfer api

we could wrap everything in transaction and serialize them

HL7v2 still provides this - FHIR needs this

we could have a transactionid with a sequence number and you can build based on that

I would like a watch subscription based on the search api - with a transcationid so you get future ones

the history spec almost does this, but transactions aren't explicit in it.

Kevin provided a link to Websub https://www.w3.org/TR/websub/ - we should look at it to see how it maps

assuming we publish an admission trigger definition - can we filter that as well - event with a filter

I'm Rolf Hut - I mainly do sensor design in water management and hydrology - I'm not a programmer

I talk about how technology is always accessible to everyone - I am a tinkerer

you make beautiful applications in the medical world, and thats not a pace where tinkering is appreciated

I wrote my book at my kitchen table - I wanted a fancy standing desk. At IKEA they are 700 Euros, so I did a chapter on making a standing desk fro less than 100 euros

you get 2 ironing boards and 2 bookshelves, and then bolt the bookshelves to the ironing boards and it costs 80 euros

I saw on Dirk Gently a lamp that goes on when you pick it up, and I wanted to make one. I added an adafruit capacitive touch sensor to a lamp to do it

I looked up the datasheet and maxwell's equations and so on, but in the end I found that there were documents saying "we don't know how this works"

Kwell in dutch is more focused than the English word seepage - if you live below sea level then the ground water is under pressure and goes up

an API is ultimately a way for developers to communicate - you're talking to each other without having to see each other's code

when you're having conversations with colleagues in different departments, you have an API

We have come to the point where we need to version our profiles as we are about to change them around

a breaking change to one resource can potentially cascade to the others that reference it

if you had a profile on HumanName then you would have the same issues

if you have a resource that conforms to a canonical URL without a | sign, it will converge tot he current version

in our case the latest version will always be the unstable version - it should go to the latest published version

there is a final or draft version in the structure definition that we could use

you shoudl change the URL if there is a breaking change to the profile - what counts as breaking - if you change the intent or details?

up to this point we have assumed that things should change

there is a task to make all our canonical urls version specific

I put this task in never expecting that we would do that

you can version your structure definition without making breaking changes. You don't want to change the canonical url with non-breaking changes

what we do in the FHR spec is reset everything when we publish a new version

the canonical url should the the url plus the major part of the version element

wherever we put the version number it will still be a breaking change

we have to consider derived profiles too - If I make a derived profile I want to point to a version

we have reference by canonical URL that are unversioned - what do we do? picking newest can have problems

if I have valuesets that are regularly updated - I don't want to change my profile each time it updates

in my profile I would say 'bind to this valueset' and it means all versions of that code set

the classic case is country codes - countries cease to exist, but that doesn't mean you can update them all

adding a category could be seen as a breaking change if it would affect a choice now

we only recommend semver, we didn't require it

if you put the major version in the canonical URL, then breaking changes will need to be tracked

we know from our experience with version 3 and decomposed structures, and users hated it - we have a single milestone release now

I can totally break something without changing the external API

Simplifier presents itself as your registry - everything you put on that can be depended on by somebody else

it could make sense for Simplifier to enforce semver changes

one of the advantages of putting the major version in the canonical URL then you can take minor or major changes

you could take the git approach by taking a hash and that is the version - it's immutable

could we have a version that is |2.* which says we want minor changes

we have a way to redirect references in IG - make HumanName to HumanName.de update to go to HumanName.de|2

what id the reason to derive profiles - inheritance is evil, so why not just copy?

if you derive from version specific url that doesn't change, that is like copying

by not using a version specific URL, I can make the choice

I only want the version specific reference when I freeze and I want to publish

we could declare which version the unversioned ones would resolve to

in this scheme it is "I will take anything" or "i will take nothing" - we need a middle ground