Community Consultation: URLs vs References

In an earlier post, I asked for community for comment on changing some elements from uri to Reference:

For the conformance resources, change all elements of type uri where they will always point to a Conformance resource to type Reference(XX).  This will include changes to StructureDefinition (GF#12902)

We received some feedback, and have just revisited the issue. The feedback made it clear that there are 2 different issues on the table here:

  • When you refer to content outside the resource, must the content refer to an actual FHIR resource? or is it allowed to refer to something else (like a PDF)?
  • When you follow the reference, should you actually look it up like a URL? or should you treat it as a canonical reference and look it up by URL on a terminology service or a registry?

After considerable discussion, we agreed to make a set of changes that are much more pervasive to the specification, but actually make less change to implementations. Specifically, we propose:

  • Define two new types of URI called “canonical” and “url”.
  • canonical is an URI (IRI, URL, absolute or relative that refers to a FHIR resource by it’s canonical URL (e.g. that has a .url element). This type allows allows version (using canonical versions)
  • url is always a literal reference (used in a few places including Attachments)
  • References don’t contain canonical URLs anymore (currently this allowed)
  • Canonical works like reference in that: you can specify aggregation, targetProfile, and _include (which means that you’d see canonical(PlanDefinition|ActivityDefinition))
  • uri would still be used where the target of a reference might not be a URL. The Lookup pathway is unspecified (either canonical or literal)

The following elements would have their types changed:

  • StructureDefinition.baseDefinition = canonical
  • ElementDefinition.type.code = uri
  • ElementDefinition.type.profile = canonical
  • ElementDefinition.type.targetProfile = canonical
  • ElementDefinition.constraint.source = canonical
  • ElementDefinition.binding.valueSet[x] = canonical, uri
  • CodeSystem.valueSet = canonical
  • CodeSystem.supplements = canonical
  • ValueSet.include.valueSet = canonical
  • ImplementationGuide.package.resource.source[x] = [think about it]
  • ImplementationGuide.package.resource.exampleFor = canonical
  • = canonical
  • CapabilityStatement.instantiates = canonical
  • CapabilityStatement.implementationGuide = canonical
  • = canonical
  • = canonical
  • = canonical
  • = canonical
  • = canonical
  • CapabilityStatement.messaging.supportedMessage.definition = canonical
  • CapabilityStatement.document.profile = canonical
  • SearchParameter.derivedFrom = canonical
  • SearchParameter.component.definition = canonical
  • OperationDefinition.targetProfile = canonical
  • OperationDefinition.binding.valueSet[x] = uri | canonical
  • OperationDefinition.base = canonical
  • OperationDefinition.inputProfile = canonical
  • OperationDefinition.outputProfile = canonical
  • OperationDefinition.param.binding.valueSet = uri | canonical
  • QuestionnaireResponse.questionnaire = canonical
  • Questionnaire.derivedFrom = canonical
  • Questionnaire.options = canonical
  • MessageDefinition.base = canonical
  • MessageDefinition.parent = canonical
  • MessageDefinition.replaces = canonical
  • MessageDefinition.focus.profile = canonical
  • MessageDefinition.allowedResponse.message = canonical
  • GraphDefinition.profile = canonical
  • = canonical
  • Meta.profile = canonical
  • ExampleScenario.workflow = canonical
  • ConceptMap.source[x] = uri | canonical
  •[x] = uri | canonical
  • ConceptMap.unmapped.url = canonical
  • TerminologyCapabilities.expansion.definition = canonical
  • TerminologyCapabilities.expansion.profile = canonical.

(note that this list only includes changes to infrastructure resources – other resources will also be affected)

Given that this is the second consultation on this issue, and that time is running tight, we’ll only open this consultation for a week – comments must be in by CoB Monday 26th February

Report – January 2018 meeting + Community Consultation

The January HL7 WGM was held last week in New Orleans. I found this a very laid back and cool meeting – perhaps it was a New Orleans thing? I’m sure that the HL7 Parade helped – but we did get plenty done – connectathon, ballot reconciliation, clinicians on FHIR, planning for normative, and more.

Girls on FHIR

We had really cool swag this meeting:


That’s a riff on a Hunger games t-shirt, and also a way for us to celebrate our many female contributors, though we didn’t want to leave the guys out – they could get the same t-shirt with “HL7 on FHIR” on it.

Ballot Outcome / Normative FHIR

The first ballot in the release 4 cycle for FHIR closed just before the HL7 meeting. We had excellent participation for a draft-for-comment ballot: 40 affirm, 81 negative and 51 abstain (for those not familiar with HL7 balloting, those are pretty good numbers, and we would expect most of the negatives to be withdrawn, though that’s not actually required for draft-for-comment ballot).

There were plenty of line items (319) – including a number that focused on Normative process issues, and some that caused significant debate.

The main take-away from the meeting is that we expect the normative ballot to go ahead as planned, though we are taking the opportunity to do some formal consultation around a few contentious issues – see below.

Clinical Notes

There was plenty of discussion at the meeting about how to best represent ‘Clinical Notes’ in FHIR. One of the problems with this is just what is a clinical note? there’s such a wide array of meanings for ‘clinical note’ from a few sentences written into a record, to a carefully constructed narrative letter to a fellow clinician, through to a fully structured
data rich transfer of care.

It’s clear how some of these things are represented in resources, but not all of them, and there’s no single coherent picture – though it’s not clear whether there should be. We had a lot of circular discussion, and we didn’t come to any strong conclusions, but we did agree that we will construct a connectathon track around this question to further investigate the optimal solution.


We’re seeking comments about how to understand record keeping around the relationships between mother and child. The health, treatment, and records of mother and child are deeply linked, but there is real variation between jurisdictions and institutions about how privacy is maintained, and how the links are represented. There’s some previous work in HL7 on this, and in other organizations – we’ll be revisiting
this subject, and seeking comment, and making a proposal for how these links should be represented in FHIR Resources.

Community Consultation

There are 4 items for which we are seeking community consultation on the basis that they represent breaking changes to FMM4-5 level artifacts. Comment is sought from anyone who has implementations that are impacted by the following changes.

Note about this: if we’ve gone to the trouble of making breaking changes and then seeking feedback about them, you should assume that they are potentially pretty significant, and investigate. Don’t regret not paying attention later.

Note also that we could just ballot these as part of the normative ballot, and call that the formal consultation, but we’d rather get comments on them immediately in case they change our mind about what to take to ballot.

Please submit formal feedback to by CoB Friday 23rd Feb. (or join discussion at

1. Removal of default values

A series of gForge tasks and ballot items related to the practical implications of missing values, and in particular default values. After long discussion at the New Orleans meeting (3 whole quarters!) we propose to make the following changes prior to ballot:

  • Remove ElementDefinition.defaultValue[x]
  • Clarify that ElementDefinition.meaningWhenMissing should only be documented when it says something of substance
  • advise committees not to create models where meaningWhenMissing is important (where possible)
  • Committees will review elements that currently have default values with a view to making them mandatory

This actually has fairly far reaching impacts. To help reviewers, here’s the current list of elements
that have a default value assigned:


… quite a lot, as you can see. This is a significant change. GForge task 15121

2. Addition of Reference.type

The FHIR-Infrastructure committee has decided to bring back an element that we removed very early in the FHIR process: Reference.type, it will be a code, bound to ResourceType, with a cardinality of 0..1. If present, it has to be consistent with the actual reference. Adding Type like this may have unexpected consequences, so while this isn’t strictly a breaking change, we want to seek opinions on this. GForge 13543

3. Removing Patient.animal

We have received a few items of feedback regarding the inclusion of the animal part of the Patient resource which the Patient Administration workgroup would like some additional feedback from the FHIR community prior to making a final decision for the normative definition of Patient.

There is no argument that the animal component is not part of the 80% (as per normal FHIR guidelines) and has been an intentional exception to the rule, the desire being to make a definitive statement that veterinary usage is a part of the scope of FHIR.

Most systems will either be all human, or all animal (veterinary), and not both. However systems like lab and pharmacy do handle both human and animal content.

So what’s the issue then?

  1. The Patient resource is going normative, and this part of the resource has not been adequately tested/verified with real systems (which is a part of the FMM progression scales)
  2. The current backbone element is marked as a modifier element, which isn’t a modifier like anywhere else in FHIR. Other properties that are modifiers impact how to interpret the resource itself. For Patient, it impacts how you might interpret other resources.
  3. Patient Administration is missing feedback from the many sides of veterinary – domestic and agricultural. The content we currently have appears to satisfy the domestic side of things (pets etc) but not clear how this would work with herds or exotic species.

Resources: GForge Tasks: 14880 Move Patient.animal to a standard extension and 14393 Patient.animal needs a meaning when absent &  Discussion

4. URLs vs References

We previously sought comment about gForge task #12902. Feedback from implementers has caused us to revisit this proposal again – look out for a post about this on my personal blog.

FHIR R4 Ballot & Community Consultation

The first of the R4 ballots is about to open. This is an important release cycle for the FHIR Communtity: it’s the first normative ballot cycle, and some of the FHIR content will be balloted as normative. Notes of interest:

  • This particular ballot is the first of three ballots to lead to the normative parts of R4
  • Once the parts finally become normative, there can be no breaking changes in those parts (well, it’s kind-of possible, but it takes multiple cycles and years)
  • Any substantive change during ballot reconciliation requires reballot – therefore committees balloting normative content will be highly motivated to refuse proposals for change
  • After this draft for ballot, there is no way to change what is selected to be balloted as normative or not for the rest of this cycle, nor to make substantiative changes to it

So we are looking for good review on this draft for comment ballot on the following things:

  • What content has been selected for normative
  • How the normative status is presented (clearly, hopefully)
  • The technical content of the normative material
  • Any suggestions for content that needs further implementation experience in the next few months

If you want to join in, and you haven’t already signed up, well, the ballot sign-up closes today. If you missed out, you can still comment through gForge.

Here’s some of the significant changes that have come with the introduction of normative content:

  • Every page has a clearly marked status now
  • There’s colors and markers for status (see here, herehere, and here for examples)
  • The ballot introduction explains the division of the FHIR specification into different packages, and the concept of ‘mixed status resources’

Along with the publication of the First R4 ballot, it’s time to do another round of consultation about proposed breaking changes to FMM4/5 content – almost all of which is slated to go normative in R4. Here’s a list of the change proposals:

  1. Include the PractitionerRole as an alternative target type for the Patient.generalPractitioner reference (GF#14224)
  2. Change the URL of the brithplace extension from ‘’ to (GF#12974)
  3. Change ElementDefinition.type.targetProfile from 0..1 to 0..* (GF#12465)
  4. For the conformance resources, change all elements of type uri where they will always point to a Conformance resource to type Reference(XX).  This will include changes to StructureDefinition (GF#12902)
  5. Add ElementDefinition.isModifierReason (0..1 string)  and possible replace .isModifier (GF#13065)
  6. Rename OperationDefinition.parameter.profile to OperationDefinition.parameter.targetProfile (to be consistent with ElementDefinition) (GF#13561)

If you’re an implementer who is affected by one of more of these changes, and you want to express an opinion, then send an email about the change to, describing your implementation, how the change impacts on you, and your opinion on it. Notes that some of these are pretty arcane things only of interests to a few toolsmith type people, so if you don’t know what they, that’s not a problem. Also, strictly, #2 is not a FMM=4+ change, but the PA work group wanted to seek opinions anyway. Given where we are in the ballot cycle, and holidays etc, this comment period is open until Friday Jan 26 (noon Eastern) – close in time for the HL7 Workgroup meeting.

Btw, outcomes from the last round of consultations:

  • Renaming ValueSet.compose: Community input was negative, and the committee didn’t make the change (we’re going to rename $compose instead)
  • Use of Observation.related and types: Community input was muted but leaned positive, and the change is included in this ballot publication
  • Adopting GitHub Flavored Markdown: community input was positive, and this change will be adopted (but hasn’t been applied to the specification and tools yet)




Proposed Breaking changes for FHIR R4

According to the FHIR maturity model that is part of the FHIR development process, we must consult the community if we are going to make breaking changes to artefacts that are labelled level 4 or 5 maturity (though there’s some lack of clarity as to what exactly is a breaking change, and what the right process should be).

At the recent meeting in San Diego, a number of breaking changes to maturity 4/5 resources were proposed, and we are seeking feedback on these:

  • Rename ValueSet.compose to ValueSet.definition (Vocab)
  • Question on the use of related types with Observation (OO)
  • Proposal to adopt GitHub Flavored Markdown (FHIR-I)

In addition, while we are consulting, we are seeking feedback on an additional change:

  • Proposal to remove ImagingManifest (II)

Each of the changes is described below, along with the proposed justification. If you have already implemented systems that will be impacted by these changes, and you’d like to have your say, please send an email to by Friday 20th October that details your implementation, the impact the change will have, and your opinion about the change.

Note: if you don’t have an actual implementation, and you still have an opinion, we’d still like to hear it – you can let us know through one of our normal channels (see

Renaming ValueSet.compose

ValueSet.compose is a verb — “compose the value set this way”, but that’s not language that connects with the wider community as well as ValueSet.definition would – “this is the definition of the value set content” (which is the “Content Logical Definition”) in the Vocab work group’s wider value set work). Also, ValueSet.definition matches ValueSet.expansion grammatically. Finally, ValueSet.compose overlaps in name with the $compose operation.

For these reasons, the work group would like to rename .compose to .definition. There’s no other semantic changes – it’s just a straight rename, to reduce confusion.

Note that ValueSet is planned for normative in R4 – there won’t be any other chance to make this change.

Use of Observation.related and types

Are you using Observation.related? how? The Orders and Observations Work considering removing .related and replacing it with:

  • member : Observation 0..*   type: Reference(Observation)
  • derived: Observation 0..*  type: Reference(Observation)

The other things related does would be relegated to extensions, or to the Provenance resource. The task proposing this (GForge #10118) was discussed at the Sept WGM by the Orders and Observations Work Group and is the direct result of internal FHIR methodology review and discussion which resulted in a proposal to substantially change the .related structure. This would simplify the structure of Observation, but the OO work group has been hesitant to make a significant change without meaningful implementer input.

Because our past attempts to get implementer feedback by reaching out to the FHIR community did not result in any response, the work group has deferred this tracker several times. As the Observation resource approaches normative status, there is increasing concern regarding making substantive changes. Implementer feedback is sought regarding whether that perceived benefits of this proposal is outweighed by the costs it imposes on implementation.

Adopting GitHub Flavored Markdown

Currently, the markdown data type specifies that the content is Gruber’s original markdown syntax, with an STU note soliciting feedback about adopting CommonMark instead. Feedback on this has generally been in favor of adopting commonmark, except that it doesn’t support tables, and it allows raw HTMlL. The community has indicated a strong preference for GitHub Flavored Markdown (GFM), and we propose to adopt this as a replacement. Note that the table extension in GFM are likely to find their way into commonmark, which would mean that we’d be using CommonMark with a profile that says ‘no HTML’

In practice, this will mean updating some existing code – e.g. a different markdown processing engine, and different generation, though the markdown syntaxes are somewhat compatible, and markdown degrades gracefully anyway.

Note, again, that the markdown data type is slated to be normative next time, so there’ll be no more opportunity to make this change. (though we could settle for pure CommonMark if the GFM extensions are brought into CommonMark – that would be a non-substantiative change). For further discussion, see

Proposal to remove ImagingManifest

The II committee (joint between DICOM and HL7) would like to remove the ImagingManifest resource. It’s a little hard for most implementers to differentiate between ImagingStudy and ImagingManifest, and the DICOM use cases for which ImagingManifest was defined (XDS-I) have been replaced by MHD-I which uses WIA (Web Image Access), leaving the use case for ImagingManifest somewhat obscure.

Hence the proposal is to remove ImageManifest and ensure that ImagingStudy can meet the identified needs.

Note that this is not a change that affects a maturity >=4 resource, so community consultation is not needed. However the committee asked for wider feedback. For further discussion, see

FHIR Product Director’s Report from 2017 Sept (San Diego) Meeting

Last week, the HL7 and FHIR communities met for the annual Plenary WGM. This time, the meeting was held at the Hyatt Regency La Jolla, which was a great facility for the HL7 meeting. Thanks to Mary Ann Boyle, who’s taking over from Lillian in organizing the WGMs – they are a big event to organize.

HL7 Formal Strategy

The HL7 Board announced its core strategic goals during the Plenary session:

  • Enhance the public image and achieve recognition by stakeholders as the leading SDO for worldwide health data interoperability standards
  • Secure long-term sustainable revenue to realize the vision and improve customer experiences (internal and external)
  • Establish FHIR as the primary standard for global health data interoperability
  • Enhance and maintain quality of and accessibility to HL7 standards in current use

With regard to the FHIR specific goal, the board provided these strategic objectives:

  1. Increase understanding of FHIR usage and value of usage worldwide (Immediate)
  2. Achieve symbiotic link of brand and financial benefit between HL7 and FHIR.(Immediate)
  3. Demonstrate the value of FHIR in enabling interoperability (Midterm)
  4. Ensure resources are most effectively focused to enhance FHIR (Midterm)

As you can see, FHIR is front and center… I guess we’re all going to be busy in the coming year making this strategy a reality. At a later time I’ll blog about how we can realize these goals.

FHIR Foundation

The FHIR Foundation is now ready to take members. You can sign up here. The annual fee for individual members at this time is US$250. For that, you get:

  • The knowledge that you’re helping maintain the viability of the FHIR ecosystem
  • Access to the Product Director’s monthly report summarizing the FHIR community progress
  • Access to member’s forum (discuss future of the FHIR Foundation)
  • Access to the member’s market place where job/contract opportunities are
    publicized (and these are starting to flow)

We’ll be adding new additional benefits in the future, as discussed with members. We’re hoping that individual memberships will cover the basic year to year costs of keeping the FHIR Foundation viable (legal/accounting fees etc).

The FHIR Foundation isn’t yet ready to open for organizational members, but it’s our intent that we will be soon. We believe that any company or institution selling services related to FHIR (consulting, middleware, implementation tools etc) will want to be part of the FHIR Foundation, and we’re working on services related to  that now. Note that this is not the same as providing healthcare services using FHIR interfaces, though of course we’ll be building membership benefits for those kind of organizations too.

One again, the FHIR Foundation thanks Google for providing the cloud infrastructure on which the services are hosted.


The meeting started with the biggest connectathon we’ve had to date – we had over 218 attendees. It’s become clear that we need to rework the way connectathons are managed – we need more organization and more preparation, as they continue to grow. With that in mind, we’ve asked whether anyone is interested in taking on a formal role as the event organizer (If you’re interested, contact me directly).

There were 22 proposed connectathon tracks for this connectathon. At least 2 of them didn’t get enough participants to get off the ground when it came to it, but most did. Each track provided a very brief summary presentation of outcomes, some of you can find in the links below.

As always, the connectathon is very important to us as a way to validate how the specification works. We will continue to add new streams as our community interests broaden. I plan to blog about some of the streams individually, and some streams have already blogged.

Reports and Blogs:

Clinicians on FHIR

The meeting closes with the Clinicians on FHIR event, where we engage Clinicians by working with ClinFHIR to record real clinical cases with the purpose of identifying gaps or deficiencies in the FHIR specification. This was our 10th event. The organizers of the CoF are developing processes to more clearly document clinical scenarios, testing, and feedback to the FHIR development process, and as part of that, we held a new breakout session for Beginners to help get them up to speed on the process.

The Clinicians on FHIR is another important way for us to validate how the specification works.

SMART App Launch Ballot

The Smart App Launch Specification was balloted in the lead up to this meeting. We received plenty of ballot comments, which is great. We’re confident that we’ll be able to publish the first STU for this specification later this year. Most of the comments related to clarification and clarity in the specification, though we’ll be noting some open issues to work on for future versions of the specification.

Community Consultation

Part of the FHIR Maturity Process is that once an artifact is at level 4/5, breaking changes require formal community consultation. In the next week, I’ll be issuing requests for comment on (at least) the following breaking changes:

  • ValueSet.compose, rename to ValueSet.definition (Vocab)
  • Question on the use of related types with Observation (OO)
  • (II) Proposal to remove ImagingManifest
  • (FHIR-I) Proposal to adopt GitHub Flavored Markdown

Notifications on these will be provided in the following places:

Normative Plans

Overall, our plans are unchanged from last time, though we’ve clarified the
time lines. High points:

  • Draft for comment, Dec/Jan: lining up for ballot
  • Mixed normative/STU, Apr/May: Main normative ballot
  • 2nd Normative + STU, Aug/Sept: 2nd chance ballot
  • Publication Mid-Dec

Those are pretty firm deadlines – we’ll slip normative content back to STU rather than hold up the timeline, since various jurisdictions and consortium initiatives are synchronizing their timelines to this (though HL7 can never provide any firm promises in this regard – we have to follow our processes)

A few additional resources are being considered candidates for normative. Last call for comments about which resources should be candidates will be in November (watch this space). After the draft for comment goes out, resources can be dropped from the normative list, but not added.

Bulk Data

The US ONC has asked to work on adding new capabilities to the FHIR specification to increase support for API-based access and push of data for large number of patients in support of provider-based exchange, analytics and other value-based services. This is a high priority work item for them this year. See write up of plans for further information regarding our proposal – this should lead to a connectathon track at HL7’s January meeting in New Orleans, at which all are welcome.

Tooling EcoSystem

The FHIR tooling ecosystem is starting to fill out quite nicely. In particular, the FHIR registry is now entering pilot mode. Please feel free to use, and (for now) provide feedback through

We’ve been working on documenting the tools we have and need – see the HL7 wiki for further information. This is still draft work, and we’re looking for further feedback and community participation.


The FHIR Proficiency Certification process was trialed at the San Diego meeting. So far, preliminary results show that we’re broadly on the right track. We still plan to have the certification fully available for the January meeting in New Orleans. Congratulations to

Yunwei Wang, IMO

who was the first person to pass the certification. Intending candidates should note that the test aims to ensure that you are familiar with the scope and shape of the full FHIR specification. Knowing the RESTful API and the resources is not enough for proficiency certification (people who know this stuff well from the connectathons/other implementations will still need to read up on the rest of the specification – terminology, intent, licensing, maintenance procedures, etc).

New Areas for the specification

The HL7 technical committees are taking up new areas of functionality and
adding them to the FHIR Specification as draft/STU for the forthcoming
release 4:

  • Public Health Case Reporting and Reportability Responses (PHER)
  • Occupational Data for Health (PHER)
  • Laboratory Test Catalog (OO)
  • BiologicallyDerivedProduct ( blood transfusion, and hematopoietic cell transplant material.) (OO)
  • Medical Device Nomenclature/Vocabulary Service (Dev)
  • Insurance Plans (FM)

If you’re interested in any of these, please get in contact with the relevant committees.

Forthcoming Events


#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 We worked hard on getting 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 Release 3 Posted

HL7 is pleased to announce that Release 3 of FHIR has just been published.

The FHIR community invested a huge amount of work in this release – hundreds of people have contributed to the specification, and there have been thousands of Change Proposals processed (>2400). Most of these change proposals arose from 3 different places:

  • Implementation Experience (Trial use is working)
  • Alignment with other standards
  • Internal Quality Review processes

Some of the key changes:

  • Added support for Clinical Decision Support and Clinical Quality Measures
  • Broadened functionality to cover key clinical workflows
  • Further development of Terminology Services, and support for Financial Management
  • Defined an RDF format, and how FHIR relates to Linked Data
  • Incremental improvements and increased maturity of the RESTful API and conformance framework

The FHIR specification is very much the living record of the community of users who share the experience of trying to solve problems with it. It’s getting ever more difficult to provide meaning recognition to all the people and organizations who contribute. Still, we’ve tried – see the FHIR credits page.

In addition to FHIR Release 3, today we’ve also published the first release of the US Core Implementation Guide. This generalizes the lessons of learnt through the Argonaut process, and publishes the agreements as a base profile for all use of FHIR in the US context. ONC and other (e.g. HSPC) implementation guides will build on this, and the Core Implementation Guide will provide a general base for consistency across all these contexts.

We expect that the FHIR specification will continue to evolve in the future as we responds to the interoperability needs of the robust FHIR implementation community. Our priority is to advance the well tested platform parts of the FHIR standard to a full ANSI-approved normative standard. I will post more about this later.


FHIR Product Roadmap January 2017

R3 plans

The FHIR project is presently finalising “STU3” (Standard for Trial Use, release 3). This 3rd major milestone is currently close to completion. We’ve been meeting in San Antonio this week to finalise ballot reconciliation, perform testing and quality activities, and we are now focusing on preparing the final publication package. Following our publication plan we expect to be publishing release 3 on or about Mar 20.

R4 plans

Once R3 is published, we will start working on release 4. The various committees that manage the different parts of Release 4 have been discussing their scope of work for R4, and planning their engagement and implementation activities to support that this week.

Some of the major things under consideration for Release 4:

  • Improvements across all domains
  • Cds-hooks integrated in FHIR Specification
  • Query language framework
  • Support for integrating research and clinical practice

The most significant change is that R4 is expected to be the first ‘normative version’. It’s important to understand what that means. We will continue to follow our overall maturity model, where content gradually matures through testing and implementation activities that demonstrate success in the real world. The end of the process is “normative” (“FMM level 6”), where the standard becomes stable, and breaking changes are no longer considered.

Only some portions of the specification are candidates for being normative. We are currently considering balloting the following parts of the specification as normative:

  • Infrastructure (API, data types, XML/JSON formats, conformance layer resources like StructureDefinition and ValueSet)
  • Administration (amongst others Patient, Organization, Practitioner)

We will continue to seek and receive comments about this. Some clinical resources may be considered, depending how implementation experience unfolds this year.

Overall planned R4 timeline:

  • Dec 2017: publish first draft of R4 for comment (finalise plans for normative sections)
  • Jan 2018: first R4 based connectathon(s)
  • April 2018: ballot R4
  • May – Sept 2018: ballot reconciliation
  • Oct 2018: publish FHIR R4

We will conduct a round of market consultations in Aug/Sept 2017 to seek comment on this timeline from the FHIR community.

Note that this timelines anticipates that we publish R4 in October 2017 irrespective of the outcome of the normative ballot. Anything that has not passed normative ballot will continue to published as STU. We are still working on preparation, quality and balloting processes to support the normative FHIR ballot.

Longer term, we anticipate following R4 with a roughly 18 month publication cycle, with increasing normative content.

Implementation Progress

FHIR is a specification for a common API for exchanging healthcare data between information systems. Any information system supporting the healthcare system can choose to implement the common API, and exchange data following the rules. FHIR enables a ‘healthcare web’ to exist, but doesn’t actually create it.

HL7 is pleased to work on the FHIR specification with many hundreds of partners, who are all implementing the specification to exchange data in service of the healthcare needs to their enterprises, their customers, and, ultimately, patients. HL7 does not ‘implement’ the specification (other than various prototype/test services) – our partners and other healthcare services do.

Argonaut Project

One particularly important sub-group of the FHIR community is the Argonaut project, which is a joint project of major US EHR vendors to advance industry adoption of FHIR and we’ve had many questions about the Argonaut implementation timeline for EHR access. With regard to the Argonaut community:

  • The Argonaut STU2 specification for Common Clinical Data Set elements is close to being finalized and will be announced shortly.  The Argonaut STU3 specification for Provider Directory will be published after final balloting of STU3
  • Most Argonaut members who are certifying an API with ONC are using the Argonaut specification; most certifications are expected in Q1/Q2 2017
  • Software roll-outs have commenced — progress will vary depending on the vendor
  • It is presently unknown what the adoption rate by provider institutions will be — MU and MACRA in the US provide incentives to make a patient-facing API available by the end of 2017
  • Some of the Argonaut interfaces provide additional functionality not yet described in the Argonaut specification, but there is considerable appetite for additional services beyond what is currently available. The Argonaut project will be making announcements about its future plans shortly which will be announced in a press release, through collaboration channels, and at


New FHIR Milestone Publications

HL7 is is pleased to announce that yesterday, the FHIR team published of a new set of Milestone releases. Included in this release:

FHIR Specification

This release is the Candidate version for the 3rd release of FHIR – technical, STU3. We’ve done much of the reconciliation following the September ballot, and this is in effect, the candidate for STU3 for technical review post ballot. In addition, this publication serves as:

  • The stable base for the upcoming connectathon in San Antonio
  • The stable base for the open ballots on implementation guides (see below)

We’ll take QA and implementation feed back on this version, apply a new round of edits, and publish the final version of release 3 towards the end of February 2017.

Alert readers may note that out original plan was that we’d publish the final Release 3 at the end of this year, but during October it become clear that the cumulative load of ballot (1500 comments) and continuing change proposals from implementers (averaging 3-4/day long term), we could only meet that timeline by sacrificing quality, and – after consultation – the FHIR community preferred for us to hold off till February. But we still needed to publish the candidate release now for the other goals above.

We encourage all the FHIR implementers, current and future, to have a good look at this candidate version, and preferably, prototype systems against it (the change notes may help).Then tell us about any issues that you find. Use gForge (and/or, because this content is not open for ballot this cycle. Note, though, that this is transient version that won’t be supported by tools and reference implementations etc going forward, so make sure migration is part of your plan if you implement against this version.

Implementation Guides

This set of publications marks a significant maturation of the US realm FHIR implementation guides. We’ve taken the core content specifications out of DAF (previously known as DAF-Core) and moved them into a new US-Core implementation guide. This is the base implementation guide for all uses of FHIR in the US Realm. It’s presently heavily driven by the Common Clinical Data Set (CCDS) and other Meaningful Use Program requirements, but it’s going to be more than that – it’ll be the one place for all general US Realm rules about how to use FHIR, including:

  • Identifiers and Code Systems
  • Common Patient Demographics
  • Profiles on common clinical content (as now, per Meaningful use)
  • Standard Consent Profiles

On top that, there’ll be a series of domain/solution focused implementation guides. This ballot cycle, we are balloting the following US implementation guides that build on the US-Core:

  • DAF-Research: A specific set of profiles for research access to EHR data, developed in association with the PCORI project and others
  • CCDA: a set of profiles that make it clear how to implement the parts of CCDA not covered by US-Core using FHIR documents. This will be important for sharing the full patient record (not just CCDS)
  • Medications Maturity Project: a draft set of specifications that initiate a project to bring the Medications module in FHIR to maturity at least for US usage (also, many other countries are just launching into the same kind of project)

All these are open for ballot, and you are invited to participate if you’re an HL7 member (also, non-HL7 members can participate in HL7 ballots, for a small fee)

Note that these are all US specific implementation guides. If you’re an HL7 member, but not a US based implementer, you can still participate, but it’s better to do so through gForge directly rather  Other HL7 affiliates are also welcome to publish their content under[2-letter-country-code] but as yet none have asked to do so.

Summary Report from SNOMED Meeting

Last week, IHTSDO held their main annual business meeting and SNOMED CT Expo in Wellington, New Zealand. I attended, along with a number of other key players from the FHIR terminology community, and we took advantage of the opportunity to hold a joint meeting between the FHIR community and the IHTSDO community.

From the FHIR community’s point of view, this was an important meeting because many of the FHIR stakeholders make extensive use of SNOMED CT and we still have a long way to go before we’ve truly mastered all the issues associated with using SNOMED CT. From IHTSDO’s point of view, FHIR is a very important implementation mechanism by which SNOMED CT content is used in production, and their stake holders have identified working well with FHIR as a priority.

The joint meeting was split into 2 parts – a general exploration of the known issues, and a technical exploration of some of them. During those 2 meetings, we discussed the following issues:

  • Progress since Montreal. In the HL7 working meeting in Montreal (May 2016), the HL7 Vocabulary WG (on behalf of IHTSDO) asked the FHIR project to make several changes around the way the FHIR Publication tools handle SNOMED CT editions, versions, copyright statements, and mappings. These were almost all completed prior to the the Wellington meeting, but we’ve been unable to transition fully to the International Edition for the base FHIR specification because of some specific value sets using US specific content. We agreed that we will change to the International Edition once this content has been promoted to the International Edition.
  • Terminology Service Implementation Guide for SCT. The Terminology service API published as part of FHIR has a very active community, and we’ve been testing the API with SNOMED CT content since we first started using it (it’s already in production in Australia). However our work has primarily focused on the API, and there’s an opportunity for us to improve the service for consumers by being more consistent in how SNOMED CT structures and semantics are exposed through the API. To that end, it was recommended that HL7 and IHTSDO should collaborate on a set of detailed rules about how the SNOMED CT concepts are exposed on the terminology servers. Most of these are things that the server providers have already discussed and agreed on informally, but it would be useful to get formally documented agreement around this. IHTSDO will also look at the feasibility of providing a reference FHIR terminology server.
  • Versioning – IHTSDO is planning to move towards a more continuous release cycle. While the details of this aren’t worked out yet, it may present some issues to the way we use SNOMED CT in FHIR – though FHIR is not special in this regard: all users will have the same challenges and opportunities. We agree that we will have to consider the impact this would have on the FHIR eco-system
  • Cross-Edition support – Presently, the SNOMED CT implementation space is divided by the national release center system – many affiliates have their own edition, with additional concepts, descriptions, relationships, and reference sets. As long as all records come from within the same jurisdiction, this is ok, because you just choose an edition. But if your records cross jurisdictions – which is something that will happen for many systems implementing patient focused record support, then there is currently no specific guidance to support this. IHTSDO agreed that this is something that implementers will need.
  • Value set review – IHTSDO has performed a review of a number of SNOMED CT value sets in the FHIR specification and provided feedback to HL7 on the results. IHTSDO has also developed a reproducible review process that may be applied to other SNOMED CT value sets. It was agreed that the review of SNOMED CT value sets in the FHIR specification should be completed, and that additional SNOMED CT value sets may be identified. IHTSDO has also previously offered to provide HL7 international with a set of SNOMED CT concepts that may be used for free in its international products. Part of the value set review will include looking at opportunities where this might be useful for the FHIR specification.
  • Binding/Mapping progress / Implementation Advice – Linda Bird from IHTSDO has been working on bindings and mappings (both words are used slightly differently across IHTSDO and HL7) between SNOMED CT and FHIR resources, both a simple attribute mapping, and a more complete template binding. So far, we’ve looked at Condition, AllergyIntolerance, Observation, Procedure, Goal and Family Member History. This has identified a number of issues in terms of gaps between the relevant SNOMED CT concepts and the design of the FHIR resources. Some of these may be flaws in the FHIR resources, or in the SNOMED CT content, or they may just be inevitable results of different perspectives – that’s yet to be resolved. We need to work on this jointly, and that might lead to changes to either FHIR or SNOMED CT, or implementation guidance for FHIR implementers that use SNOMED CT, or a formal FHIR Implementation Guide. We’re not sure where that will end up yet.
  • Simplification – we also discussed an idea for providing a framework for sharing additional views on SNOMED CT as a way for helping implementers. We agreed to pursue ideas around making SNOMED CT easier to use for beginning implementers informally for now. The draft SNOMED CT Machine Readable Concept Model (MRCM) currently out for community review ( may allow these simplified views to be created automatically.

A small group of IHTSDO and HL7 participants has been selected to form a joint project group to turn all these ideas into a working project plan. We’d welcome further comment from people who are interested in this area who weren’t at the joint meeting. On the HL7 side, contact me. For the IHTSDO perspective, contact Jane Millar. We’ll be working on this over the next few months.