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.




  1. Thomas Lukasik says:


    I’m just curious as to what level and/or type of activity would be considered “involved” with respect to standards development, and FHIR in particular.

    Is someone who regularly monitors the FHIR mailing list and FHIR implementers chat or joins FHIR Conference Calls whenever time permits, contributing to the conversations whenever they have something constructive to say, considered to be “involved” — or does “involvement” start at a higher level, for example being a dues paying member of the HL7 organization and/or attending Working Group Meetings in person?

    I’m only asking because reading your initial blog post, that question occurred to me, so I thought that if you’re planning a series of blog posts specifically focused on the topic of participation in the FHIR community, it would help readers if you described the types and levels of activity that count as “involvement” — especially for those who may not be active in the FHIR community at any level right now, and have that same question.


    • Grahame Grieve says:

      I would consider ‘involved’ to mean: “i can identify things where I made a difference to the outcome’. Obviously there’s a wide degree of ‘involved’, and many ways to contribute. Everyone makes choices to suit their situation.

  2. Thomas Beale says:

    I documented some of the many reasons to be sceptical about standards in the e-health space years ago, as you remember – https://wolandscat.net/2009/09/17/the-crisis-in-e-health-standards/

    Many SDOs still work this way; some don’t.

    I think a more interesting question is: how should standards actually be developed? My view is that if is that if it is not in a platform / ecosystem mentality, it’s not worth doing. But official SDOs are not arranged like that, so that remains a challenge.

    There are well-known ways to work these days for elaborating technical products from a team-based environment; these have only be sparsely adopted into SDO mentality, which is still very much committee / consensus focussed . Engineering products have to be built by engineering methods. Doubly hard in e-health, since deep clinical knowledge is crucial to success.

    I doubt that you would disagree with this.

    Personally I think the official SDOs have to radically reform themselves in order to remain relevant. The practice of standards being issued with no underlying science or theoretical basis, no implementation ever having taken place, consensus voting by people in meeting rooms who have never read or understood the materials, no design methodology, 3-year cycles, obscure or no issue tracking, little or no technical community and bizarre documentation requirements is irrelevant today. (I’m not primarily thinking of HL7 here, although I think it could improve as well).

    Anyway, if the ‘how’ question were answered in an agreed way, I’m sure many more people would be interested. As it is, the ‘standards’ of today are built as open source products by open source communities, with all the relevant modern methods.

    • Grahame Grieve says:

      On the whole, I agree. There’s a series of things that the SDO has to do to enable this. HL7 is working on it, and making some progress. By and large, other SDOs are too, but the big question for all of them is: how do you match a working business model to a working community infrastructure. That’s an issue for the open source communities as well – having good ideas is not enough. And while I thoroughly believe in open source, the gravitas of a formal standard – with the implications that carries – is required to bring the benefits home. Open source is not enough.

      I’ll plan to make a post in the future about SDO best practices.

      • Thomas Beale says:

        Agree on the open source thing – I was thinking more of the methods of open source, i.e. shared code repos, open licences, public issue trackers etc, than the fact of the code being open source. In any case, code is secondary – it’s the formal specifications and formal artefacts (schemas, models etc) that matter.

        And you are right about the need for the ISO or similar imprimatur – but my question is: why does this need persist, given the utterly out of date methods of such organisations? It’s completely irrational. So there is a problem of (typically) national level orgs like DoH and MoHs that need to get into the real world and stop thinking that orgs like ISO are providing what they need.

        • Grahame Grieve says:

          I didn’t mention code!

          I do think the the governments should think hard about what standards they need, and why, and what kind of standards organizations they should engage with, and how. But the good news is, they are thinking about this indeed.

          That’s actually the subject of my next blog post

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen


%d bloggers like this: