#FHIR Report from Madrid Working Group Meeting

Last week the HL7 Community met for one of our regular working group meetings. This time, we met in Madrid at the Marriott, which was actually a pretty good venue for an HL7 meeting (these are challenging because we want lots of small and medium sized rooms). In particular, the food was excellent. This was also a notable meeting because it’s the last meeting for Lillian Bigham who has organised HL7 meetings for the last 12 years – we’re going to miss her a lot.

As usual, the event kicked off with a connectathon on the Sat/Sun. This meeting set a first for us: this connectathon had fewer participants than the last one – obviously due to the non-US location a lot of regulars didn’t attend.


The connectathon as still very productive, with many happy outcomes for the implementers, and further change requests for the FHIR specification itself. Importantly, the set of functionality that the connectathons test continue to broaden.

Product Planning

For the many different committees that manage the various parts of the FHIR specification, this meeting – coming immediately after publishing Release 3 – was an opportunity to make plans for our next release – what features do want in it?

Here is a list of the major features we plan for Release 4:

  • Normative – see below
  • RDF: prototype a solid ontology binding to evaluate how much benefit this might bring
  • Data Analytics: support for a bulk data analysis bridge format (Apache Avro/Parquet?)
  • API: establish better control over retrieving graphs of resources, and value added query support (tabular format?)
  • Patterns: change the W5 framework to a pattern (logical model), tie the patterns to ontology, and use of patterns to drive more consistency (and how to do this without decreasing quality)
  • Services: more business level services. Some candidates: conformance, appointments, personal health data
  • Deployment: get a clear standards path for smart on fhir / cds-hooks (and alignment with UMA/Heart)
  • FM: work on alignment between FM resources and the rest of FHIR

Note that this list anticipates that our normal maintenance tasks will continue to happen, and there’ll still be ongoing changes across the board in response to implementer experience and internal quality processes. (Also, most of these product priorities are already in progress)

Normative FHIR

One of our key plans is that we are going to ballot some of the specification as normative for Release 4. “Normative” means that the content is now locked in and only forwards compatible changes will be made in the future. This means that applications written for an older version will interoperate with the current version (if, that is, certain rules are followed).

This is the current list of artifacts we plan to take normative in R4:

  • Framework / XML / JSON / RESTful API + Search
  • CodeSystem, ValueSet, and possibly ConceptMap. (But not all operations on those resources)
  • Bundle / OperationOutcome / Parameters / StructureDefinition / SearchParameter / + maybe CapabilityStatement/OperationDefinition
  • Patient, Observation

Note that this list won’t be finalized until January, so there’s plenty of time for discussion about this list. You may see some implementation activities driven by this list, as we encourage the community to look at some aspects of these resources in more detail.

Implementation guides and registries

We’ve nearly got all our tooling in place for implementation guides. The final major piece that is missing is registry.fhir.org. We worked hard on getting http://registry.fhir.org ready this meeting, and I’m hopeful that it will be up and running before the September meeting. We also worked on plans for integrating our existing tooling with the registry, and other additional quality processes.

R3 Publication Recognition

A little while before the Madrid meeting, we published FHIR Release 3. Because we did so much QA work, this turned into a massive project, and a few people helped out beyond the call of duty – being available at all times of the day or night. Since these people gave beyond the call of duty, HL7 recognized their efforts:


From left: Bryn Rhodes, Eric Haas, David Hay, Rob Hausam, Grahame Grieve (me), Lloyd McKenzie, Brian Postlethwaite, Richard Ettema, Melva Peters, and Michelle (Moseman) Miller

Revised terminology process

During the meeting, we agreed to redesign all the HL7 terminology maintenance to a FHIR based tooling solution. This is part of a wider redesign of the terminology maintenance processes. There’ll be more information about this forth coming.

Quality processes

Most of the planning we did at Madrid for Release 4 involved investing in quality and quality processes. As FHIR as a whole is maturing, so is our understanding of what quality processes we need, and where in the process we need them. Additionally, we are starting to see new content in FHIR that hasn’t been so thoroughly analysed in previous standards (HL7 v2, v3, CDA, etc), such as AdverseEvent, and ClinicalImpression. These resources may need additional informatics related quality processes – this is something we are working on

FHIR foundation

Our plans for membership of the FHIR foundation are also maturing. We hope that membership will be open in the next few weeks – that will enable the foundation to actually start performing some of the functions it needs to do that require funds.

Note that FHIR Foundation board minutes are published on the FHIR Foundation web site.

DevDays USA

The HL7 board agreed that HL7 will hold a FHIR DevDays meeting in USA next year (probably June). HL7 will work with Furore, who organise the very successful FHIR DevDays help in Amsterdam in November of each year.


A few significant changes were agreed for R4 while in Madrid:




FHIR report from Baltimore meeting

Last week, HL7 held it’s annual plenary meeting in Baltimore at the Hyatt Regency. As usual, the Hyatt Regency’s odd-ball design generated a few comments, but we were not treated to a repeat of the comic-con the weekend before (provided a colorful backdrop to the last Baltimore meeting). I’m pretty sure I heard that this was HL7’s largest meeting ever. What I can say for sure is – accommodation is increasingly hard to get for HL7 meetings; make sure you get in early for the next one.

For the FHIR project, our main attention was the ballot. Across the core standard, and multiple implementation guides, we received >800 detailed comments as part of the ballot. This represents a slight increase over the last ballot, but there was a clear change in the focus of the comments – there was a significant drop in the number of comments relating to the infrastructure, and much more focus on the domain content, and it’s applicability to real world problems. This is a clear marker of the growing maturity of the standard. We continue to expect that we’ll publish FHIR release 3 at the end of this year.

Most of the meeting was devoted to ballot reconciliation, with a focus on the difficult to resolve items. But we got plenty of other things done as well:

  • The FHIR connectathon was out biggest ever, with more streams, more success, more of everything. Note, that the next meeting, in San Antonio, it’s doubtful we can accomodate that many people, so it’s probably going to be a case of getting in early…
  • The clinicians on FHIR event was also a success – well, what I saw of it. But since we’ve had people asking us about the event, and whether they can run their own, we filmed a documentary about the event – thanks to Kai Heitmann for doing that. We’re not planning to post this publicly; instead, if you’re interested in hosting a clinicians on FHIR event, let me know, and I’ll share it with you when it’s done
  • We (members of the FHIR team) met with several new communities that haven’t previously been part of the FHIR community, and planned how they could get engaged, and share their energy and outputs with us. As always this is a collaborative
    process, and I’ll be making more announcements about this going forward
  • We made some specific decisions to change widely implemented parts of the specifications; consultation with the wider community around these changes is ongoing (see “JSON Comments” and “Logical References“). This is reflective of our process towards normative; some of the next version of FHIR (release 4) will be normative. I’ll be making more announcements about how that’s going to work in the future (when we figure it out).
  • Probably the most significant single decision we made was to take the specification known by the obtuse code word “DAF-core” – that’s the spec based on the Project Argonaut collaboration – and rename it to the US realm Implementation guide, of which it comprise be one section, how to represent the Common Clinical Data Set. Over time, the US realm implementation guide will grow to encompass more than just that. (btw, one decision related to this is that we are working to bring the technical specification from SMART that Argonaut used to HL7 as an appendix to the FHIR specification, named something like the “Application Launch Framework”)
  • Finally, the FHIR foundation continues to take shape as a key part
    of the eco-system to support the implementation process of standards
    (as opposed to the actual development of the standards themselves).
    In particular, it looks like we’ll soon be able to set fhir.registry.org
    live, which is a key piece of the FHIR picture that many people are awaiting.

Overall, the FHIR development team (well, teams – there are many interlaced teams with responsibilities for different parts of the specification, the process, and the community) are happy with a gradual progress. While there is still much to be done across all the specification, the plenary meeting marked our 5th year anniversary, and we are proud of what we’ve achieved in that time.