FHIR Foundation Report for November 2018

FHIR Event: DevDays Amsterdam

The main (only) event this month was FHIR DevDays in Amsterdam. This was the 5th meeting, and once again it was bigger than ever before, and sold out.

Each year, I sing the praises of the DevDays meeting, and I feel the same way again:

  • Great keynotes to set the wider stage around what we trying to achieve
  • Really interesting reports of how FHIR is being used across Europe, and the issues the implementations raise
  • Fabulous tutorials about the specification and the eco-system around it
  • really interesting informal sessions about open issues in the community.

But I write about this every year, so I thought I'd share Ewout's thoughts (For those of you who don't know Ewout, he's the intellectual driver behind DevDays):

For us [= the organizers] this DevDays edition presented a significant shift from mainly having sessions about how to use the FHIR standard to the broader scope of how to use FHIR to change the way information is distributed and used. Personal stories from both speakers and participants provided the background for what we can achieve once systems start talking to each other. Both the number of new participants and this new breadth and depth of the community around FHIR made it clear to us that FHIR is on the brink of becoming mainstream.

Another striking aspect of this edition was the overwhelming presence of big tech (Google, Microsoft, Amazon, Apple), both among the speakers and among the participants. FHIR is bringing in new players into healthcare.

FHIR R4

We're really close now!

  • QA is mostly done
  • R3 / R4 conversion work is nearly done (thanks Vadim Peretokin and Kenneth Myra for assistance)
  • we have two unwithdrawn ballots:
    • one, we cannot contact the balloter even though the issue is resolved (that's an HL7 process problem that's never come up before and we'll fix in the future)
    • one that may be withdrawn yet
    • so we need to do one or two special "recirculation": ballots to check that the ballot pool is ok with us publishing in the face of the unwithdrawn negatives. This will take 2 weeks, and will open soon
  • once the recirculation ballots are done, final build processes will begin, and will take several days
  • we are still planning to release before the end of the year

FHIR Community

The FHIR specification(s) and community are so big - now. There's such a huge amount of work going on by so many people - so many people give their personal time to see us across the line (no fair that I get the media credit too often):

  • balloters / QA reviewers
  • editors / committee co-chairs / minute takes
  • process support / secretariat / ANSI compliance
  • testers / implementers who give feedback or help others
  • regulators / advocates

The next report should be cover the release of R4. One of our the last things to do before publishing is to update the Credits page, but this is a bit daunting - who to list? Feedback is welcome (to me directly, or chat.fhir.org.

Packages

One big topic of conversation at DevDays was packages. The FHIR community is moving to use NPM packages and NPM package distribution for managing the technical side of the specifications. Whether you author specifications through simplifier or publish implementation guides through HL7 or the FHIR foundation, or whatever other way, we are looking to distribute the processible content using NPM packages. We have a profile on the NPM package spec describing how we use packages.

Many of the common tools in the community (validators, publishers, toolkits etc) have already been converted to use packages, and registry.fhir.org is migrating to be a package based repository (as part of an overall effort to bring registry.fhir.org to production usefulness, which it is not at this time). Packages have been generated for all the IGs that HL7 or the FHIR foundation have ever published (and also for the base FHIR specifications as well). The package infrastructure will soon be fully functional, and if you have any tooling that makes use of the any of the processible content, it should migrate to accessing that content by the package.

Which FHIR versions are supported?

Although HL7 and the FHIR foundation host all the versions of the FHIR specification that have ever been published, the fact that they are made available on the web does not mean that they are supported. "Supported" here means that HL7 considers the specification suitable for use, and/or that the validator / other tools / reference libraries / test servers etc implement that version.

The following versions are "supported":

  • DSTU2
  • STU3
  • R4 (once released)
  • The current build (not suitable for use, but supported by many tools)

Notes:

  • DSTU1 is not on the list due to disuse. No one has asked us about it for a long time.
  • Each tool in the FHIR eco-system has it's own policy that flows from the business and technical context of the way the tool is provided, so many tools don't support all these versions
  • By commercial arrangement, the version at http://hl7.org/fhir/2016May is still supported by some tools, to support a production community using it.

Forthcoming events


An HL7 Website - Powered by Google