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.
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)
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.
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
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.
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:
- ProcedureRequest and ReferralRequest will be merged
- DataElement will be dropped (use Logical Model Structure Definitions instead)
- The JSON-LD format will be dropped, leaving us with just the one JSON format, and focusing on Turtle for RDF