Category Archives: FHIR

Gender Participation in the #FHIR Community

This is post #3 in my series about why to participate in the FHIR standards process.

A few weeks ago, I attended the AIIA awards night at the kind invitation of the eHealth team from CSIRO. One of the speakers was the Victorian Minister for Small Business, the Hon Philip Dalidakis. The presentation was the day after the sad passing away of another Victorian minister, Fiona Richardson, and in her memory, he made an inspired plea for us all to actively consider whether there’s anything that we can or should do to improve the gender imbalance that’s typical in IT.

HL7 – and the FHIR community – does have the gender imbalance that’s characteristic of IT communities – though it’s also a health community, and so the gender divide is not as stark as it is in some communities. But it’s not anywhere close to 50:50, and his words made me wonder whether we/I are in a position to do anything more about that. After the presentation, I spoke to Minister Dalidakis about what levers we might have in an open standards community to encourage more balanced participation – they’re different to those you can/should use in a commercial setting.  He graciously gave me several pieces of advice, and since then I’ve been discussing this with the FHIR team, and particularly with our female leaders in the community.

FHIR and HL7 are great communities to be involved with, and that’s particularly true if you’re a woman – that’s what our female leaders tell me.

They say this is because:

  • We have a strong governance model that is good at managing contention (we have a fair bit of it to manage!)
  • Everyone is treated equally, and mostly treated well (the issues mentioned here are gender neutral)
  • Our discussions are thoughtful and respectful
  • The healthcare vertical is inherently non-confrontational, non-violent

And FHIR is a great place to contribute. Paula Braun says:

Many of the important indicators about our health…e.g., blood pressure, abnormal lab results, etc…are invisible to us. Without access to this data, we and the professionals we entrust to take care of us, are operating in the dark. The older, outdated ways of accessing and exchanging health information have an “I know better than you” feel to them. It was the equivalent of somebody saying, “Hey there girl, don’t worry your pretty little head about how this all works. It’s much too complicated for you.” FHIR is different. FHIR is a community where motivated people self-select to un-break healthcare…at least the IT part of healthcare. I don’t consider myself a “techie” but I choose to participate in the FHIR community because of the possibilities that FHIR enables, the professionalism that is maintained, and, most importantly, because its fun to be part of a movement that is transforming the dominant assumptions and expectations about healthcare

Michelle Miller (who is rightfully one of the Health Data Management’s 2016 Most Powerful Women in Health Care IT) says:

I participate in the FHIR community because:

  • Even with my bright pink “First-Time Attendee” ribbon, I quickly learned that my input was valued.
  • HL7 FHIR has a focus on those who adopt and implement the standard specification, such that implementer involvement and input is very much respected and encouraged.
  • After getting energized by the fantastic collaboration that occurred during the HL7 work group meetings, I started attending weekly work group conference calls to continue the discussion
  • I feel strongly that all changes, big and small, help make the FHIR specification that much better for the next implementer or developer to adopt.  Adoption is what makes a specification a standard because without adoption, we haven’t really achieved interoperability
  • I have been so impressed with the knowledge, collaboration and overall friendliness of the HL7 FHIR community. The discussion is always thoughtful and respectful, such that I have high confidence in FHIR’s ability to maximize interoperability.

In sum, it is energizing for me to collaborate with such knowledgeable experts on a subject (healthcare) that is so meaningful and impactful (bigger than just me, my job, or even my country).  Despite the diversity in our perspectives (country, vendor, government, technical vs clinical etc.), the FHIR community is genuinely interested in reaching the best conclusion because adoption is what makes a specification a standard and achieves interoperability

Michelle has a full write up about her involvement on the Cerner Blog.

So the FHIR community is a great place for women who want to make a difference to contribute. If you’re thinking about it – we’d love to have you involved; please get in contact with me, or one of:

(though there’s many other valued contributers as well).

Still, there’s plenty we can do to improve:

  • One particularly pertinent issue around gender participation is about time requirements. HL7 is both good and bad here – most participation is remote, and really flexible in terms of hours and location – that’s a big deal. But there’s also face to face meetings that require travel – that can be a real problem, and HL7 has struggled to find a practical solution around remote participation (it’s an inherently hard problem).
  • There’s general agreement that we could do a lot better with regard to welcoming, induction, and initial training procedures – these are actually issues for both genders – so that’s something that we’re going to work on
  • We need to communicate better that the FHIR community is not just engineers and hackers (who lean male) – it’s about health, and clinicians and nurses (and business managers) are just as much implementers with valuable contributions to make. Of course, the FHIR community is comprised of both genders across all these roles
  • Good consultative leadership is hard to find, and we need/want more of that
  • We have good leaders – we need to recognize the ones we have.
  • We could keep an eye on statistics around assignment of administrative duties (“housework”) at HL7 – but we don’t

Note that all these are really about maximizing our human capital. So, we have plenty of potential, but we aren’t really capitalizing on it. Increasingly, we are investing in human capital as our community grows, so watch this space.

Btw, this image from the Madrid meeting shows that we can do better on balance (though, in fact, we are on the whole more balanced than this particular photo):

Contributers recognized for contributions way beyond expectations to getting FHIR R3 published – featuring both Melva and Michelle

p.s. A note about the FHIR and HL7 communities: these are tightly related communities with a good % overlap, but they are also different in nature, processes, and composition, so we had to consider them both.

#FHIR and Bulk Data Access Proposal

ONC have asked the FHIR community to add 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.

The background to this requirement is that while FHIR allows for access to data from multiple patients at a time, the Argonaut implementations are generally constrained to a single patient access, and requires human mediated login on a regular basis. This is mainly because the use case on which the Argonaut community focused was patient portal access. If this work is going to be extended to provide support for API based access to a large number of patients in support of provider based exchange, the following questions (among others) need to be answered:

  • how does a business client (a backend service, not a human) get access to the service? How are authorizations handled?
  • How do the client and server agree about which patients are being accessed, and which data is available?
  • What format is the data made available in?
  • How is the request made on a RESTful API?
  • How would the client and server most efficiently ensure the client gets the data it asks for, without sending all data every time?

The last few questions are important because the data could be pretty large – potentially >100000000 resources, and we’ve been focused on highly granular exchanges so far. Our existing solutions don’t scale well.

In response to some of these problems, the SMART team had drafted an initial strawman proposal, which a group of us (FHIR editors, ONC staff, EHR & other vendors) met to discuss further late one night at the San Diego WGM last week. Discussion was – as expected – vigorous. Between us, we hammered out the following refined proposal:


This proposal describes a way of granting an application access to data on a set of patients. The application can request a copy of all pertinent (clinical) access to the patients in a single download. Note: We expect that this data will be pretty large.

Authorizing Access

Access to the data is granted by using the SMART backend services spec.

Note: We discussed this at length, but we didn’t see a need for Group/* or Launch/* kind of scopes – System/*.read will do fine. (or User/*.*, for interactive processes, though interactive processes are out of scope for this work). This means that a user cannot restrict Authorization down to just a group, but in this context, users will trust their agents.

Accessing Data

The application can do either of the following queries:

 GET [base]/Patient/$everything?start=[date-time]&_type=[type,type]
 GET [base]/Group/[id]/$everything?start=[date-time]&_type=[type,type]


  • The first query returns all data on all patients that the client’s account has access to, since the starting date time provided.
  • The second query provides access to all data on all patients in the nominated group. The point of this is that applications can request data on a subset of all their patients without needing a new access account provisioned (exactly how the Group resource is created/identified/defined/managed is out of scope for now – the question of whether we need to do sort this out has been referred to ONC for consideration).
  • The start date/time means only records since the nominated time. In the absence of the parameter, it means all data ever
  • The _type parameter is used to specify which resource types are part of the focal query – e.g. what kind of resources are returned in the main set. The _type parameter has no impact on which related resources are included) (e.g. practitioner details for clinical resources). In the absence of this parameter, all types are included.
  • The data that is available for return includes at least the CCDS (we referred the question of exactly what the data should cover back to the ONC)
  • The FHIR specification will be modified to allow Patient/$everything to cross patients, and to add $everything to Group
  • Group will be added as a compartment type in the base Specification

Asynchronous Query

Generally, this is expected to result in quite a lot of data. The client is expected to request this asynchronously, per rfc 7240. To do this, the client uses the Prefer header:

Prefer: respond-async

When the server sees this return header, instead of generating the response, and then returning it, the server returns a 202 Accepted header, and a Content-Location at which the client can use to access the response.

The client then queries this content location using GET content-location (no prefixing). The response can be one of 3 outcomes:

  • a 202 Accepted that indicates that processing is still happening. This may have an “X-Progress header” that provides some indication of progress to the user (displayed as is to the user – no format restrictions but should be <100 characters in length). The client repeats this request periodically until it gets either a 200 or a 5xx
  • a 5xx Error that indicates that preparing the response has failed. The body is an OperationOutcome describing the error
  • a 200 OK with the response for the original request. This response has one or more Link: headers (see rfc 5988) that list the files that are available for download as a result of servicing the request. The response can also carry a X-Available-Until header to indicate when the response will no longer be available


  • This asynchronous protocol will be added as a general feature to the FHIR spec for all calls. it will be up to server discretion when to support it.
  • The client can cancel a task or advise the server it’s ok to delete the outcome using DELETE [content-location]
  • Other than the 5xx response, these responses have no body, except when the accept content type is ‘text/html’, in which case the responses should have an HTML representation of the content in the header (e.g. a redirect, an error, or a list of files to download) (it’s up to server discretion to decide whether to support text/html – typically, the reference/test servers do, and the production servers don’t)
  • Link Headers can have one or more links in them, per rfc 5988
  • Todo: decide whether to add ‘supports asynchronous’ flag to the CapabilityStatement resource

Format of returned data

If the client uses the Accept type if application/fhir+json or application/fhir+xml, the response will be a bundle in the specified format. Alternatively, the client can use the type application/fhir+ndjson. In this case:

  • The response is a set of files in ndjson format (see
  • Each file contains only resources of a single type.
  • There can be more than one file for each resource type.
  • Bundles are broken up at Bundle.entry.resource – e.g. a bundle is split on Entries so the the bundle json file will contain the bundle without the entry resource, and the resources are found (by id) in the type specific resource files (todo: how does that work for history?)

The nd-json files are split up by resource type to facilitate processing by generic software that reads nd-json into storage services such as Hadoop.


  • the content type application/fhir+ndjson will be documented in the base spec
  • We may need to do some registration work to make +ndjson legal
  • We spent some time discussing formats such as Apache Avro and Parquet – these have considerable performance benefits over nd-json but are much harder to produce and consume. Clients and servers are welcome to do content type negotiation to support Parquet/ORC/etc, but for now, only nd-json is required. We’ll monitor implementation experience to see how it goes

Follow up Requests

Having made the initial request, applications should store and retain the data, and then only retrieve subsequent changes. this is done by providing a _start time on the request.


  • Todo: Is _start the right parameter (probably need _lastUpdated, or a new one)?
  • Todo: where does the marker time (to go into the start/date of the next follow up request) go?
  • clients should be prepared to receive resources that change on the boundary more than once (still todo)


The ONC request included “push of data”. It became clear, when discussing this, that server side push is hard for servers. Given that this applications can perform these queries regularly/as needed, we didn’t believe that push (e.g. based on subscriptions) was needed, and we have not described how to orchestrate a push based on these semantics at this time


It’s time to test out this proposal and see how it actually works. With that in mind, we’ll work to prototype this API on the reference servers, and then we’ll hold a connectathon on this API at the New Orleans HL7 meeting in January. Given this is an ONC request, we’ll be working with ONC to find participants in the connectathon, but we’ll be asking the Argonaut vendors to have a prototype available for this connectathon.

Also, I’ll be creating FHIR change proposals for community review for all the changes anticipated in this write up. I guess we’ll also be talking about an updated Argonaut implementation guide at some stage.


Question: #FHIR Documents and Composition


What is the relationship between FHIR Documents and  composition resources? Meaning, what is the best way to capture/store in FHIR, documents that are not necessarily related to clinical info (file, images, file reference links to external content systems etc)

If I have several documents that need to be associated to a patient and organizations and was looking for your thoughts on best practices you have seen


Documents like this – files, images, reference links to content systems – these are best handled using DocumentReference.  Composition is used for documents that have tightly controlled content. a mix of narrative and data.

Question: Extending systems to deal with non-#FHIR type content


What has your experience been with developers, developing on a FHIR model that requires FHIR resources — but also has a need for non-standard FHIR data (something like supply chain data or Blockchain external hashed data). Is the recommendation to shoe horn this into extensions  or have data models that live side-by-side with FHIR?


There’s no single answer to this question, because it depends on the other kind of data. Generally, there’s 3 approaches I’ve seen:

  1. Use extensions in existing resources (particularly Basic). This approach is only good while the extensions are pretty narrow and limited, and closely related to the existing FHIR functionality
  2. Use some other content model, and figure out how the functionality links. This approach is good where there is another content model. For example, in my server, I use SCIM for managing the user accounts. I use the SCIM content to link a user account to a FHIR resource like “Patient” so that I know which patient the user represents (if any) and I refer to the SCIM user identity in AuditEvent resources (as a URL)
  3. Make up your own content but follow the FHIR patterns – effectively, custom FHIR resources. Use extensions to reference them. This approach is good where you have quite a bit of content/functionality, but there’s no external standard to follow

Which is best depends on what you’re doing.

A note about the custom resources idea: this is legal – you can do whatever you want with the names the FHIR doesn’t define. e.g. [base]/User. And if you choose to put something there, that happens to look a bit like a FHIR resource.. that’s still whatever you want. But things like ‘can I describe it from the CapabilityStatement’ and ‘can I search into the space’ are not technically legal, and there’s always a risk that HL7 will use the name in the next version of FHIR, making your solution locked in to being non-conformant. We’ve investigated making some policy around these questions to make custom resources manageable, but we’ve never managed to get the energy to push agreements over the line.

Why participate in the #FHIR Community? (Individuals & Standards)

This blog is the first of series I’m going to run in the lead up to the HL7 San Diego meeting looking at the question of why to participate in the FHIR community. For this first blog, I’m going to look at the question of why to get involved in standards at all at the individual level. (subsequent entries in the series: The vendor engagement matrix, Gender Balance and Participation, …)

A couple of days ago, I was speaking to a well-known high-profile member of the Australian Health Informatics Community – someone who’s given considerable time to the development of the profession, both academically, and to the community. I asked him why he wasn’t involved in standards development. “Not standards!”, he said, with a definite frown.

Indeed, why be involved in standard development?

In some ways, it’s easier to say why it’s better not to be involved: standards work is slow, and involves arcane and myopic focus on small details in the presence of considerable contention about what should be done. Often must deal with toxic people in difficult circumstances – it’s kind of baked into the process. And progress is slow – actually, it’s often opaque whether you’re making any progress at all. What success you do have is often not appreciated outside the standards community (not appreciated, that is, by the people with money who fund your participation one way or another).


There’s an old saying that anything worth doing is costly… and I think that applies to standards. While the work can indeed be arcane and myopic at times, of all the ways to impact the community, standards development is one of the ways that offers the most leverage. Standards can alter behavior, create entirely new arrangements, and transform industries. In the case of health, good protocols for data exchange – and the data standards that underlie them – can make a substantial difference to health outcomes.

I’d love to have more patient/consumer representatives involved in HL7 (though there’s many other venues where you can contribute to data and protocol standards). But when I talk to potential candidates, most can’t imagine being involved in something with such a long term outlook, where you have to do so much work before you get any outcomes… but that’s how you get really deep and meaningful outcomes. I think that’s sad.

So if you’re interested in contributing to the community, in advocating for change in healthcare: think about playing the long game, the one with the big payoffs, and contribute through the development of standards.



Question: Validity of AllergyIntolerance extension in #FHIR


How to extend severity in AllergyIntolerance resource.  Is the following resource where severity is extended done correctly?

<AllergyIntolerance xmlns="">
  <id value="uWErIN0G0" />
  <recordedDate value="05/10/1980" />
    <reference value="Patient/DFQA_ghn000003" />
    <display value="Newman, Alice Jones" />
      <system value="RxNorm" />
      <code value="1659592" />
    <text value="ampicillin-sulbactam" />
  <status value="confirmed" />
      <coding />
      <text value="urticaria (hives)" />
      <extension url="">
            <system value="" />
            <code value="371923003" />
            <display value="mild to moderate" />


Severity is a code, with cardinality 0..1 and a required binding to mild | moderate | severe. You can replace the code with an extension, as is done here, so that part is valid. But it’s much better to provide both a code out of the defined choices, so that systems that only know those choices can process the information correctly, while those that know the refined list can process the refined list:

    <severity value="mild">
      <extension url="">
            <system value="" />
            <code value="371923003" />
            <display value="mild to moderate" />

Aside: you could map this code to either mild or moderate, yes. Choosing either is better than choosing neither.

There’s several other issues here, though:

  • The URL given that identifies the extension actually identifies the value set, not the extension (aka the data element). The correct thing to do would be to define an extension that use the value set (see at the bottom of the post)
  • According to the value set definition, this is a SNOMED CT code, and the system should be filled out
  • the recorded date format is not a valid XML date
  • the system for RxNorm is not correct
  • manifestation coding can’t be empty

Here it is corrected:

<AllergyIntolerance xmlns="">
  <id value="uWErIN0G0" />
  <recordedDate value="1980-10-05" />
    <reference value="Patient/DFQA_ghn000003" />
    <display value="Newman, Alice Jones" />
      <system value="" />
      <code value="1659592" />
    <text value="ampicillin-sulbactam" />
  <status value="confirmed" />
      <text value="urticaria (hives)" />
      <extension url="">
          <system value="" />
          <code value="371923003" />
          <display value="mild to moderate" />

With an associated Extension definition:

<?xml version="1.0" encoding="utf-8"?>
<StructureDefinition xmlns="">
    <lastUpdated value="2017-07-12T07:05:27.311+10:00" />
  <url value="" />
  <name value="RefinedSeverity" />
  <status value="draft" />
  <date value="2017-07-12T07:02:31.9614187+10:00" />
  <publisher value="Health Intersections" />
  <description value="My definition for FHIR extension" />
  <purpose value="an extension" />
  <fhirVersion value="3.0.1" />
  <kind value="complex-type" />
  <abstract value="false" />
  <contextType value="resource"/> 
  <context value="AllergyIntolerance.event.severity"/> 
  <type value="Extension" />
  <baseDefinition value="" />
  <derivation value="constraint" />
    <element id="Extension">
      <path value="Extension" />
      <definition value="This is a description of the level of the severity of the problem." />
    <element id="Extension.url">
      <path value="Extension.url" />
      <fixedUri value="" />
    <element id="Extension.value[x]:valueCoding">
      <path value="Extension.valueCoding" />
      <sliceName value="Severity" />
        <code value="Coding" />
        <strength value="required" />
        <description value="This is a description of the level of the severity of the problem." />
        <valueSetUri value="" />

Report from joint #openEHR / #FHIR meeting

Last month, the openEHR and FHIR communities met for a day in Norway. From the openEHR community, Ian McNicoll and Silje Ljosland Bakke were present, and from the FHIR community, Ewout Kramer and myself were present, along with a group of Norwegians who are involved in FHIR and/or openEHR. My thanks to HL7 Norway, DIPS (en) and the Direktoratet for e-helse for collaborating to bring the meeting together.

The overall agenda for the day:

  • Welcome, introductions / complaints about the weather (de rigueur, but Norway was lovely, there was even some sun one day)
  • Opening presentations from Ian and myself
  • Discussion on specific model mapping HL7 FHIR – openEHR
  • Discussion on a general form solutions
  • Some general questions on HL7 FHIR – openEHR: Mapping, query, Workflow, Pub/Sub, Terminologies, Modeling

And then drinks afterwards, where we solved all the worlds problems (except for a few big ones).

I enjoyed the day greatly – there was a real positive spirit, based on a recognition that both communities are vibrant productive communities that have much to offer each other. Technically, the FHIR and openEHR communities have different scopes, with some overlap, and there’s plenty of real world problems that FHIR is not attempting to solve that openEHR has invested in – and vice versa. Given good will, and a focus on pragmatic outcomes, we can work well together and both derive benefit from that collaboration.

Given that, most of the day focused on immediate challenges faced by Norwegian implementers today. The most obvious question is ‘I have content described by an archetype, and I want to exchange that using FHIR. How do I go about that?’  Right now, there’s no clean simple answer. There’s several different paths, which work variably well. We discussed some of the issues with a focus on mapping between openEHR and HL7 FHIR of observations like body temperature. The outcome of the discussion is that the place to focus is mapping openEHR templates to/from FHIR Profiles. We’ve created a joint workspace in the openEHR Github repository so we can work together on that (as of today, it’s empty. It’s work in progress and will gradually start to fill up, and hopefully with useful stuff).

The plan is that we’ll automatically convert openEHR archetypes and templates to FHIR Logical models, and then map to FHIR resources using the FHIR Mapping language, and generate profiles and implementation guides from that. If that works well (not yet known), this would establish a single demonstrated path to interoperability. Note that I didn’t say a simple path – to make it simple will require further content reconciliation between the communities – perhaps this will provide the impetus for more investment in that (we’ve done some, but it’s hard work).

Then we discussed the different and similarities of the FHIR and openEHR approaches to forms/questionnaires, and what would be involved to interconvert between the different formats. We agreed to work on this further, including a set of activities on Form Mapping at the FHIR DevDays meeting in Amsterdam in November.

One idea that has been floating around recently is for openEHR to use the FHIR binding syntax and terminology services – we discussed this a little, and hopefully we can work towards a concrete proposal for this in the next few months to see how it flies in the wider openEHR community.

Overall, the meeting created a lot of prospects about what we can do together, but now we actually have to follow up and do them.

p.s. Thanks to Sigurd From from DIPS for keeping notes from the meeting which I used for this report

p.s. Also, thanks to the Norwegians for being great hosts. In addition to Norwegian national day, I enjoyed the fjords greatly. Now I just have to find the right supplier of Fjord Cider here in Australia, and all will be good.

Interconversion between #FHIR and HL7 v2


What advice do you give for introducing FHIR in new software, while continuing to maintain HL7v2 interoperability with client applications that do not speak FHIR?

For example, are FHIR resources the way to go as an internal representation of an application’s health care data?

If yes, is it practical to convert HL7 messages into FHIR resources (e.g. Patient, Practitioner, ProcedureRequest, ReferralRequest, Appointment…)? What open source software do you recommend for converting HL7 messages into FHIR resources (and vice-versa)?

Or is it better to use FHIR for external information exchange only (with outside FHIR clients)?


I’ve worked with several projects rebuilding their products around FHIR resources. Like all development methodologies, this has pros and  cons. What you get out of the box is a highly interoperable system, and you get a lot of stuff for free. But when your requirements go beyond what’s in the specification, it starts to get hard – FHIR is an interoperability standard, that focuses on the lowest common denominator: what everyone agrees with. Whether that’s a net benefit depends on how far beyond common agreement your going to go. (This, btw, is a demonstration of my 3rd law of interoperability).

It is practical to convert HL7 messages to FHIR resources and vice versa, yes. We’ve seen plenty of that going on. But there’s no canned solution, because to do the conversion, you have to do two things:

  • Figure out all the arcane business logic and information variants and code this into the conversion
  • Figure out how to integrate your conversion logic into your application framework

The upshot of this is that you have a programming problem, and most people solve this by taking a open source libraries for v2 and FHIR in the language of their choice (most languages have one of those) and writing the business logic and application integration in their development language of choice. Hence, there’s no particular open source library to do the job other than the parsers etc. There are some commercial middleware engines that include FHIR as one of the formats that can be supported.

In the FHIR spec, we’ve defined a mapping language that tries to abstract this – so you can separate the business logic from the application integration, and a platform independent business logic that has libraries for whatever platform. That’s an idea that is gradually starting to gather some interest, but is still a long way from maturity.

With regard to using FHIR for external exchange only… what I usually say about this that is that it makes sense to implement FHIR for new things first, and then to replace old things only when they become a problem. And most new stuff is on the periphery, where the architectural advantages to FHIR are really big. But internally, v2 will increasingly become a major service limitation in time, and will have to be replaced. The open question is how long that timeline is. We don’t know yet.