Monthly Archives: July 2013

Why attend the Australian FHIR Connectathon?

So this week, while I was at HIC 2013, I spoke to a number of vendors about the FHIR connectathon to be held in Sydney in late October in association with the IHIC 2013 meeting. Most of the vendors have heard of FHIR, and expect that it will have a major impact on them at some stage, but are still unsure about attending the connectathon.

They all asked me pretty much the same set of questions:

  • When will FHIR be a reality for me?
  • How much will the connectathon cost?
  • What makes this worth attending?

Note that the same general logic applies to the question of attending the general FHIR connectathon in Boston on Sept 20-21, though the specific details differ.

When will FHIR be a reality for me?

This is an open question. When we started working on FHIR, we expected that during the trial use period, FHIR would primarily be used where there wasn’t already existing solutions, particularly in the mobile / social web space (SMAC!), where the shared technology base makes it a compelling solution. We didn’t expect that large enterprises, regional projects, or national programs would use it seriously until there were some real runs on the board. And indeed, that’s pretty much what a recently released Gartner report says (no public link I can find).

But in practice, adoption is going to go a lot faster than that. The trial use period won’t start until early next year, but already a number of these programs are doing pre-production analysis and trials on projects that will come to fruition long before the trial period ends. And the most significant adoption will be if IHE adopts FHIR for the Mobile Health Documents – as it seems likely to do. For Australia, this would place FHIR squarely in the future path of the pcEHR development cycle, and there’s already some (very preliminary) work around this. So I do expect FHIR to start impacting on many Australasian vendors sometime next year.

How much will the connectathon cost?

I don’t know about the registration side of things, but there’ll be travel and accomodation, of course (if you aren’t based in Sydney). Beyond that, there’s the preparation question. Each connectathon, we get someone who walks into the room, tells us that they’ve heard about FHIR and the connectathon, sits down, and asks where the specification can be found. They’ve done no preparation at all. That works ok – in effect, the connectathon is just a hands on self-guided tutorial with experts ready to answer any questions. They’ve all ended up exchanging content by the end of the first day. (Just make sure that the development environment is sorted, though, you could waste a lot of hours on that). But we also get people coming to the connectathon who are at the end of their development cycle, and what to nail down the loose ends.

So how much the connectathon costs is up to you – it depends how much preparation you want to do. The minimum cost is travel + accomodation + 2 days labour + registration costs if there are any. The maximum – it can be a lot…

A related question is what kind of people should attend? The connectathon is hands on – so you need to be able to do development of some kind. That can mean a mix of light scripting with javascript and a browser, up to a full blown server developer using a 3GL. We do get observers who are just watching and learning, who don’t participate like this, but it’s not the same…

What makes this worth attending? 

The FHIR connectathon is worth attending because:

  • It’s the best way for techie folks to really get a feel for how FHIR works – it’s as good as a tutorial, if not better 
  • It’s a lot of fun – a great retainment strategy (for some kinds of developers), and leads to great connections within the industry (really good for troubleshooting interoperability problems)
  • Issues that arise from connectathons really make a difference to the final spec. And this connectathon will be the last to be able to influence the trial use version of FHIR
  • It looks likely that NEHTA and the National Infrastructure Operator will be there prototyping future services, seeking to gain input from the community. This would be a great way to make practical contributions early in the process, rather than suffering from the difficult change processes that kick in later in the process
  • You’ll be signifying your vendor’s interest in the ongoing development of eHealth, since all the evidence says that FHIR is going to have a big impact eventually
  • This is likely to be only FHIR connectathon in Australia in the near term

Personally, I reckon that these reasons justify at least the minimum cost easily.

Question: FHIR Versioning


Can you tell me roughly when FHIR 1.0 is scheduled for? Is that the DSTU version? or is that the post-DSTU version?


We’ve never formally discussed versioning for FHIR. At present, I’ve upped the minor version whenever we reach some kind of publishing milestone – typically, I up the version when we enter a connectathon freeze, and again afterwards when changes recommence. We’ve not had any policy discussion about it. I’m inclined to target 1.0 as the first full normative release. So the DSTU would be 0.5 maybe.

In terms of change control, we have stable periods in the lead up to connectathons – usually 4 -6 weeks. These have corresponded to ballots, and we’re shortly going to enter another one. Once DSTU is published, that will be stable for a long period – at least 12 months. We haven’t yet discussed how we’re going to handle further development post DSTU.


eHealth Interoperability Conference, Sydney, Sept 12


On Sept 12th I will speaking about the FHIR project at the eHealth Interoperability Conference.

This presentation will be aimed at CIO / management folks, and provide a very consumer focused view of what FHIR is and means. I’ll also be looking at some of the change management issues associated with the project.


  • Why HL7 needs a fresh approach
  • Leveraging web technologies in core healthcare business
  • How FHIR will drive down the costs of integration
  • Market consequence of changes in standards

It looks like a very interesting conference to me – a bunch of much more interesting and influential speakers then me will be presenting, including HL7’s CEO Chuck Jaffe.

I’ll also be taking part in a Panel on the subject “Open Standards, Technology Transparency, And Interoperability: How Best To Ensure Collaboration And Consistency?”. FHIR is one of  number of activities I’ve been involved with around using open standards, and transparency to foster collaboration and interoperability.


I’d love to see as many of my readers there as possible:


Do vendors like standards or not?

Quoting from discussion on David More’s blog:

“[Vendors] basically saw the standards as having the potential to erode the significant barriers to entry they had put around their little proprietary walled gardens”

This is something I hear a lot, but the reality is much more nuanced than that.

To illustrate, consider the example of a service provider who makes a living by selling the provision of a service. The actual service doesn’t matter – it could be selling software that manages a clinical data repository (i.e. EHR), selling communications (Vodafone etc), or a surgeon who does open heart surgery.

Roughly, their activities can be broken into 3 different types

  • Core: The service that they provide – the exact service, the balance between quality and cost, their customer base is built around that. For a surgeon, this is his professional service, the way he does operations, etc. For an EHR vendor, this is their information models, their UI, their value adds around decision support, etc
  • Ancillary: The support things that are part of the service, but subsidiary. For a surgeon, this is his infection control procedures, his practices with regard to visting and billing patients, etc. For an EHR vendor, this is the way they expose data for exchange, the integration points they have etc
  • Plumbing: The necessary things that have to be done that aren’t of value. For a surgeon: choosing instruments, keeping up with literature. For an EHR vendor – security, audit, database backup

(Obviously there is a big overlap in these things, but the general principle holds)

When it comes to standardisation, most service providers are totally in favour of standardising the last set of their activities – the plumbing – of course. There’s no profit in being different, it’s just overhead. So standardising this is just good business sense.

On the other hand, for the Core activities – standardising these is a direct attack on their livelihood. It can destroy their market, their living. Commoditising their service is not something that they can openly embrace. That’s nothing to do with whether it’s a good thing or not – creative destruction is going to happen, and while standards can vary the economic pressure point at which it does (in either direction), it’s only a small contribution. But irrespective of what is good for the economy, there is no way that a service provider can support commoditising their core service – unless they are a bit player in the market that think they can win the competitions based on price for a fixed service. And there’s no point expecting a service provider to do anything different – either the surgeon or the vendor.

Where it get’s interesting is in the Ancilliary activities – different service providers feel differently about the pro’s and con’s of this, and make different decisions. Some have an open culture, and a focus on their core business – these are more likely to want to standardise these support activities. Other service providers take an antagonistic view of the world, and actively resist it. Personally, I’m very much in the first camp, and I think that leaders that pursue the second option will destroy their business in the longer term.

if you look at the support or otherwise from Vendors for the various Australian government initiatives over the last few years, you’ll see that by and large, vendors are simply following the predictable model above, or based on their established culture. Some things, they are completely in favour of, some they aren’t, and others, reaction is mixed. Whether the initiatives themselves are good or bad has nothing to do with whether the vendors are in favour either – that’s something that will only become evident in the history books.

From a consumer’s point of view, looking at service providers, it’s hard to tell whether the price of an activity is simply extracting rent, or a fair price to pay for services provided. Generally, we’ve settled on competition as the answer to this, but this is an imperfect answer (it’s too hard to ensure real competition exists, and the purchaser is never fully informed, particularly in healthcare. By it’s nature, too, healthcare service provision – even by the vendors – has a real element of coercion). It’s even harder to tell whether lack of standardization is going to help reduce the price, or not. A standard might just end up being overhead (which is probably why so many standards fail in practice).