Category Archives: HL7

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 Video Contest

We work hard to ensure that the FHIR specification is as easy to understand as possible. For example, we have several ‘getting started’ guides for different audiences. But never-the-less, getting orientated with the specification, and/or the FHIR connectathon process can still be a challenge. So today, HL7 is announcing a competition.

Contest entrants must post a video to Youtube that helps implementers ‘get started’ with the FHIR specification and/or the FHIR connectathons. Videos should be less than 5 minutes long, and be posted to Youtube by November the 1st.

Video entries will be judged by Ed Hammond (don’t know Ed? He’s “Mr HL7” is anyone is – see this award), and the winner will get free registration (or refund etc) for their next HL7 meeting.

Ed and I will be awarding some prizes for additional categories, including a ‘community preference’ award.

#FHIR and the Gartner Hype Cycle

As FHIR product director, I get plenty of comments about the hype associated with FHIR. And there is plenty of hype. Here’s the Gartner hype curve:

Where are we on that curve, people want to know? Well, my answer is that as far as I can tell, the rate of increase of hype is still increasing, so it seems as though we’re still in the initial rocket phase.

What’s the hype?

For me, hype is beyond enthusiasm – it’s when people make wildly inflated claims about what is possible, (wilfully) misunderstand the limitations of the technology, and evangelise the technology for all sorts of ill judged applications (about where block chain in healthcare is right now).

So what things do I see that I think are hype? Well there are many symptoms, but one fundamental cause: there’s an apparently widely held view that “FHIR will solve interoperability”.

It’s not going to.

FHIR is 2 things: a technology, and a culture. I’m proud of both of those things. I think both of those will make a huge contribution towards solving the problems of interoperability in healthcare. But people who think that problem will be solved anytime soon don’t understand the constraints we work under.

HL7 is an IT standardisation Organization. We have severely limited ability to standardise the practice of healthcare or medicine. We just have to accept them as they are. So we can’t provide prescriptive information models. We can’t force vendors or institutions to do things the same way. We can’t force them to share particular kinds of information at particular times. All we can do is describe a common way to do it, if people want to do it.

FHIR is good for sharing information out of an EHR – but confirming to FHIR doesn’t prove anything; there’ll have to be some policy layer above that. More generally, if you have 2 teams (departments, vendors, governments, whatever) that don’t see eye to eye, forcing them to adopt FHIR as a technology isn’t going to change anything. Getting them to adopt the FHIR culture – that will. But you cannot impose that.

So what can we do about that?

What we – the FHIR team – can do is to make sure the fundamentals are in place. Good governance, solid processes, well tested specifications, an open and inclusive engagement framework. If we can get that right – and it’s a work in process – then the trough of despair won’t be as deep as it might, and we can focus on our task: getting the standards out of the way of solving problems in people’s healthcare.

Follow up: have you read my 3 laws of interoperability?


Question: Entering the #FHIR Bandwagon


HL7 v1 came first, followed by V2, followed by CDA, V3. For newer entrants into Standards and Interoperability is the central dogma of S&I is something like Learn V2 first, then CDA, then V3 and then FHIR and then SMART on FHIR and then Newer or a person can just straightaway buy an FHIR textbok or Collect all FHIR blogs at one place and start reading from scratch?


V2, CDA, FHIR+Smart on FHIR are all different approaches to solving various healthcare interoperability problems. If you’re deeply invested in the standards process, then learning all of v2, CDA, and FHIR will give you deeper perspective about what has and hasn’t worked, and what ideas last across the various specifications. But if you’re just solving a particular problem, then you just pick one, learn it, and give into the job.

Which one to learn? 

  • Actually, this is simple. If you have to use one, because of legal requirements, or because your trading partners have already chosen one – that’s by the far the most likely situation – then you don’t have to decide. Otherwise, you’d use FHIR

How to learn? From a previous post, these are the books I recommend:

None of these cover FHIR. But, in fact, Tim invited me to join with him for the forthcoming 3rd edition of his book, to cover FHIR, and this should be available soon. In the meantime, as you say, there’s the FHIR blogs.

#FHIR Product Director

While in Orlando last week, HL7 appointed me The “FHIR Product Director”. This is a new position that has been created by HL7 in accordance with the HL7 BAM (“Business Architecture Model” – can you tell that HL7 likes acronyms and ‘models’?). For HL7, appointing me to FHIR Product Director role achieves two important goals:

  • It’s a step on the path towards sustainability for the FHIR project
  • It formalises HL7’s business arrangements around the FHIR project


The FHIR project has done amazingly well – that is, I’m astonished at how well it’s done. The growth of the community is an order of magnitude bigger than our most confident projections when we started working on it. While we’re obviously delighted about that, it’s brought some challenges with it, principally around scaling up the team that develops the specification, and supports the implementation community. That direct FHIR team includes a lot of people (>100) playing a variety of roles:

  • Evangelism
  • Requirements gathering
  • Standards design and Consensus building
  • Editing the specification
  • Developing implementation tools and libraries
  • Answering Implementer questions
  • Arranging connectathons
  • Developing Implementation Guides
  • Using FHIR in prototype and production applications

All of these roles are critical, and greatly appreciated. But it’s just not feasible to continue running with a team this size, having the impact it’s having, without some formal arrangements for management and co-ordination in the team. Appointing an HL7 Product Director is a part of that, though more will be required.

HL7 Business Arrangements

Obviously, FHIR is a critical part of HL7’s future business plans. Like any business (HL7 is a business, though a not-for-profit one), HL7 has to do normal product management – continuity, managing, planning, building relationships etc. We’ve been doing those things, but the FHIR Product Director position creates a formal basis for these, and offers HL7 the opportunity to define the formal and informal arrangements around the project.

Product Director Role

Several people asked me exactly what it means for the FHIR project. The position of “FHIR Product Director” is new, so we don’t really know the answers. What I agreed with the HL7 Executive Committee is that I will be accountable for the following:

  • Liaise with all parts of the FHIR community (including committees, HL7 management, stakeholders, members) to ensure continued development of FHIR product and community
  • Work with existing management and governance structures to build FHIR product and community
  • Work with TSC to formalize the role and develop a job description
  • Run the FHIR balloting and publishing process, and ensure business continuity around these arrangements (including documenting FHIR processes and procedures)
  • Work with HL7 and the FHIR community to create the FHIR Foundation (
  • Produce a monthly report documenting FHIR Product Director activities, issues and concerns

There’s one item in this list that will be new for a lot of people: the FHIR foundation. I’ll blog about this in the near future.

Generally, from the perspective of the FHIR project, formalising the role of the FHIR Product Director doesn’t really change very much. In terms of formal management, I’ve resigned from the FHIR governance board, and will instead join both the governance board and the management group as a non-voting member in an ex-officio role. Further, a few activities around documenting policies and procedures that hadn’t been getting timely attention will be addressed.

In addition, I’ll be creating a FHIR Product Director blog to address the public side of some of these. I’ll continue to blog here for anything that’s not official Product Director business.

Note: The Product Director is a part time position. I’ll continue to work for my existing customers helping them to integrate healthcare systems, and to make the best use of HL7 and other standards.

Question: Solutions for synchronization between multiple HL7-repositories?


In the area of using HL7 for patient record storage, there are use cases to involve various sources of patient information who are involved in the care for one patient. For these people, we need to be able to offer a synchronization between multiple HL7-repositories. Are there any implementations of a synchronization engine between HL7 repositories?


There is no single product that provides a solution like this. Typically, a working solution like this involves a great deal of custom business logic, and such solutions are usually solved using a mixture of interface engines, scripting, and bespoke code and services developed in some programming language of choice. See Why use an interface engine?

This is a common problem that has been solved more than once in a variety of ways with a myriad of products.

Here’s an overview of the challenge:

If by synchronization we mean just “replication” from A to B, then A needs to be able to send and B needs to receive messages or service calls. If by synchronization we mean two-way “symmetric” synchronization then you have to add logic to prevent “‘rattling” (where the same event gets triggered back and forth). An integration engine can provide the transformations between DB records and messages, but in general the concept codes and identifiers must still be reconciled between the systems.

For codes, an “interlingua” like SNOMED, LOINC, etc. is helpful if one or both of the systems uses local codes. The participants may implement translations (lookups) to map to the other participant or to the interlingua (it acts as the mediating correlator) The interface engine can call services, or perform the needed lookups. “Semantic” mapping incorporates extra logic for mapping concepts that are divided into their aspects (like LOINC, body system, substance, property, units, etc. Naturally if all participants actually support the interlingua natively the problem goes away. For identifiers, a correlating EMPI at each end can find-or-register patients based on matching rules. If a simplistic matching rule is sufficient and the receiving repository is just a database, then the integration engine alone could map the incoming demographic profile to a query against the patients table and look up the target patient – and add one if it’s new.

But if the target repository has numerous patients, with probabilistic matching rules (to maximize the rate of unattended matches, i.e. not bringing a human registrar into the loop to do merges), then the receiving system should implement a service of some kind (using HL7/OMG IXS standard, OMG PIDS (ref?), or FHIR), and the integration engine can translate the incoming demographic into a find-or-register call to that service. Such a project will of course require some analysis and configuration, but with most interface engines, there will be no need for conventional programming. Rather, you have (or make) trees that describe the message segments, tables, or service calls, and then you map (drag/drop) the corresponding elements from sources to targets.

An MDM or EMPI product worth its salt will implement a probabilistic matching engine and implement a web-callable interface (SOAP or REST) as described. If the participants are organizationally inside the same larger entity (a provider health system), then the larger organization may implement a mediating correlator just like the interlingua for terminology. The “correlating” EMPI assigns master identifiers in response to incoming feeds (carrying local ids) from source systems; Then that EMPI can service “get corresponding ids” requests to support the scenario you describe. An even tighter integration results if one or both participants actually uses that “master” id domain as its patient identifiers.

Here’s some example projects along these lines:

  • dbMotion created a solution that would allow a clinical workstation to access information about a common patient from multiple independent EMRs. It accomplished this by placing an adapter on top of EHR that exposed its data content in a common format (based upon the RIM) that their workstation application was able to query and merge the patient data from all the EMR into a single desktop view. The actual data in the source EHR were never modified in any way. This was implemented in Israel and then replicated in the US one RHIO at a time. (Note: dbMotion has since been acquired by Allscripts)
  • California State Immunization created a solution that facilitated synchronization of patient immunization history across the nine different immunization registries operating within the state. The solution was based upon a family of HL7 v2 messages that enabled each registry to request patient detail from another and use the query result to update its own record. This solution was eventually replaced by converting all the registries to a common technical platform and then creating a central instance of the system that served all of the regional registries in common (so synchronization was no longer an issue now that there was a single database of record, which is much simpler to maintain).
  • LA County IDR is an architecture put in place in Los Angles County to integrate data from the 19+ public health information system both as a means of creating a master database that could be used for synchronization and could be used as a single source to feed data analytics. The Integrated Data Repository was built using a design that was first envisioned as part of the CDC PHIN project. The IDR is a component of the CDC’s National Electronic Disease Surveillance System (NEDSS) implemented in at least 16 state health departments.

The following people helped with this answer: Dave Shaver, Abdul Malik Shakir, Jon Farmer

#FHIR Report from the Paris Working Meeting

I’m on the way home from HL7’s 2015 May Working Group Meeting. This meeting was held in Paris. Well, not quite Paris – at the Hyatt Regency at Charles De Gaulle Airport.


A sad and quite unexpected event occurred at this meeting – Helmut Koenig passed away. Helmut Koenig was a friend who had attended HL7 and DICOM meetings for many years. Recently, he had contributed to the DICOM related resources, including ImagingStudy and ImagingObjectSelection resources.

Helmut actually passed away at the meeting itself, and we worked on resolving his ballot comments the next day. Links:

Ballot Summary

The FHIR community continues to grow in leaps and bounds. That was reflected in the FHIR ballot: we had strong participation and many detailed comments about the specification itself. Once all the ballot comments had been processed and duplicates removed, and line items traded amongst the various FHIR related specifications, the core specification had 1137 line items for committees to handle. You can see them for yourself on HL7’s gForge.

This is a huge task and will be the main focus of the FHIR community for the next couple of months as we grind towards publication of the second DSTU. At the meeting itself, we disposed of around 100 line items; I thought this was excellent work since we focused on the hardest and most controversial ones.


We had about 70 participants for the connectathon. Implementers focused on the main streams of the connectathon: basic Patient handling, HL7 v2 to FHIR conversion, Terminology Services, and claiming. For me, the key outcomes of the connectathon were:

  • We got further feedback about the quality of specification, with ideas for improvement
  • Many of the connectathon participants stayed on and contributed to ballot reconciliation through the week.

The connectathons are a key foundation of the FHIR Community – they keep us focused on making FHIR something that is practical and implementer focused.

We have many connectathons planned through the rest of this year (at least 6, and more are being considered). I’ll announce them here as the opportunity arises.


Another pillar of the FHIR Community is our collaborations with other health data exchange communities. In addition to our many existing collaborations, this meeting the FHIR core team met with Continua, the oneM2M alliance, and the IHE test tools team. (We already have a strong collaboration with IHE generally, so this is just an extension of this in a specific area of focus).

With IHE, we plan to have a ‘conformance test tools’ stream at the Atlanta connectathon, which will test the proposed (though not yet approved) TestScript resource, which is a joint development effort between Mitre, Aegis, and the core team. We expect that the collaboration with Continua will lead to a joint connectathon testing draft FHIR based Continua specifications later this year. Working with oneM2M will involve architectural and infrastructural development, and this will take longer to come to fruition.

FHIR Infrastructure

At this meeting, the HL7 internal processes approved the creation of a “FHIR Infrastructure” Work group. This work group will be responsible for the core FHIR infrastructure – base documentation, the API, the data types, and a number of the infrastructure resources. The FHIR infrastructure group has a long list of collaborations with other HL7 work groups such as Implementation Technology, Conformance and Implementation, Structured Documents, Modelling and Methodology, and many more. This just regularises the existing processes in HL7; it doesn’t signal anything new in terms of development of FHIR.

FHIR Maturity model

One of the very evident features of the FHIR specification as it stands today is that the content in it has a range of levels of readiness for implementation. Implementers often ask about this – how ready is the content for use?

We have a range – Patient, for instance, has been widely tested, including several production implementations. While the content might still change further in response to implementer experience, we know that what’s there is suitable for production implementation. On the other hand, other resources are relatively newly defined, and haven’t been tested at all. This will continue to be true, as we introduce new functionality into the specification; some – a gradually increasing amount – will be ready for production implementation, while new things will take a number of cycles to mature.

In response to this, we are going to introduce a FHIR Maturity model grading based on the well known CMM index. All resources and profiles that are published as part of the FHIR specification will have a FMM grade to help implementers understand where content is.

FHIR & Semantic Exchange

I still get comments from some parts of the HL7 community about FHIR and the fact that it is not properly based on real semantic exchange. I think this is largely a misunderstanding; it’s made for 2 main reasons:

  • The RIM mappings are largely in the background
  • We do not impose requirements to handle data properly

It’s true that we don’t force applications to handle data properly. I’d certainly like them to, but we can’t force them to, and one of the big lessons from V3 development was that we can’t, one way or another, achieve that. Implementers do generally want to improve their data handling, but they’re heavily constrained by real world constraints, including cost of development, legacy data, and that the paying users (often) don’t care.

And it’s true that the RIM mappings have proven largely of theoretical value; we’ve only had one ballot comment about RIM mappings, and very few people have contributed to them.

What we do instead, is insist that the infrastructure is computable; of all HL7 specifications, only FHIR consistently has all the value sets defined and published. Anyone who’s done CCDA implementation will know how significant this is.

Still, we have a long way to go yet. A key part of our work in this area is the development of RDF representations for FHIR resources, and the underlying definitions, including the reference models, and we’ll be putting a lot of work into binding to terminologies such as LOINC, SNOMED CT and others.

There’s some confusion about this: we’re not defining RDF representations of resources because we think this is relevant to typical operational exchange of healthcare data; XML and JSON cover this area perfectly well. Where RDF representations will be interface between operational healthcare data exchange and analysis and reasoning tools. Such tools will have applications in primary healthcare and secondary data usage.

Question: PRD segment in ORM and ORU messages?


Can the PRD segment be included in the HL7 ORM message and ORU messages?This would allow clear identification of Referring Provider and Consulting Provider.


The PRD segment is not part of the base HL7 definition for either the ORM or ORU messages.

I think that the intent is that you’d exchange the full details of Referring and Consulting Providers via some other means of transfer, such as Master File Messages (see chapter 8 of the HL7 v2 standard).

Of course, that kind of approach won’t work for some of the ways in which ORM and ORU messages are used – e.g. where the sender and receiver aren’t tightly bound in a single institution. So you can add the PRD segement if you want, but you’ll have to ensure that all the parties involved in the exchange know that it will be there and why it’s there. I’d add it after the ORC segment.


#FHIR Updates

A round of links and news about progess with FHIR

Draft For Comment Posted

I have just finished posting the final version on which the current draft for comment is based:

This version of FHIR is our first serious look at what we plan to release as DSTU2 for FHIR. From here, this candidate will undergo a round of comment and testing, including the HL7 “draft for comment”, where HL7 members can comment on the content of the ballot, and also will be tested through several connectathons and other implementation projects. Following that, we will gather all the feedback, and prepare the second candidate, which will be published around the start of April. This will get another cycle of testing, and then we’ll make further changes in response. We’re planning to publish the final version of DSTU 2 around the end of June.

DSTU 2 is clearly going to be a landmark release for FHIR; it will be the first full version that has relatively complete coverage of the healthcare space, and I know that a number of large vendor consortiums, national programs and standards projects are planning on using it for real. Our current plan is that the next version after that will be a full normative ballot. Given the amount of interest FHIR has attracted, and the size of the implementation pool FHIR will have, we expect getting full consensus for the first normative version to be a slow process.

So what I’m saying is that any work people put into reviewing this version of FHIR will be time well invested.

Btw, there are 3 main versions of FHIR posted now:

  1. – DSTU1, the current version of the DSTU
  2. – the draft for comment source, which is also the stable version for connectathons from Jan – March
  3. – the rolling current version; it runs about 20 minutes behind version control

Project Argonaut

If you’re interested in FHIR, but been living under a rock, you may not have heard about Project Argonaut. The original press release caused a great deal of excitement. My own comments, for the HL7 worker community, got posted to the public at least here and here. I’ll post more information here or elsewhere as it’s available.

Project Argonaut represents a significant validation of the FHIR project, and I thank the leaders of that group (particularly John Halamka, Aneesh Chopra, Arien Malec, Micky Tripathi, and most of all, Dave McCallie) for their willingness to stick their neck out and also – we definitely appreciate this bit – contribute real resources to our project. This kind of validation has certainly made everyone sit up and take notice, and it seems likely that the FHIR community will grow some more in both breadth and depth in the next few months.

FHIR for executives

Rene Spronk has prepared a very useful high level summary of FHIR for executives. (now all we need to do is complete the “FHIR for Clinicians” document – it’s in progress).




HL7 Australia #FHIR Forum and Connectathon

On Thursday & Friday 6-7 November 2014 Hl7 Australia is holding a FHIR Forum and Connectathon in Melbourne.

Day 1 is focused on education:

Keynote: FHIR in context … a step forward for patients Andrew Yap, Alfred Hospital Melbourne
FHIR – A US perspective David McCallie, CMIO, Cerner
Implementing FHIR for Australian GP Systems Brett Esler, Oridashi
FHIR / openEHR collaboration Heather Leslie, Ocean
FHIR & the Telstra eHAAS design Terry Roach, Capsicum / Telstra
Introduction to SMART on FHIR Josh Mandel, Smart / Boston Childrens
Using Terminologies with FHIR Michael Lawley, CSIRO
Using FHIR in new and unexpected ways – actually including the Patient in the system Brian Postlethwaite, Telstra (DCA)
Clinical records using FHIR David Hay, Orion Healthcare
Panel: What are the prospects for FHIR Adoption in Australia?

  • Grahame Grieve, Health Intersections (FHIR Project)
  • Richard Dixon Hughes, DH4 (Standards)
  • Tim Blake, Semantic Consulting / DOH (Government)
  • Peter Young, Telstra  – DCA (Industry)
  • Malcom Pradhan – Alcidion (Clinical)


Im really pleased about this program: it’s a great line up of speakers from Australia and New Zealand talking about what they’re actually doing with FHIR. Also, I’m really pleased to welcome David McCallie, the CMIO for Cerner, who’ll be joining us from USA by video to discuss Cerner’s plans for FHIR and discuss the broader prospects for the adoption of FHIR in the USA. Finally, we’re really lucky and extremely pleased to have Josh Mandel from Boston Children’s Hospital Informatics Program present. Josh will be talking about SMART on FHIR, and describing how that works as an EHR extensibility framework.

On Day 2, we’ll be holding a connectathon. We’ll have 3 streams of activity:

  • Basic Patient Stream – this is suitable for any developer with no prior experience of FHIR necessary – all you need is a working development environment of your choice
  • Smart on FHIR – this is for EHR vendors who want to experiment with using Smart n FHIR as a plug-in framework for their system, or for anyone who’s interested in writing an EHR plug-in – as many clinical departments will be
  • Clinical Connectathon – this is for non-developers who still want hands on experience with FHIR – use the clinical connectathon tools to learn how real world clinical cases are represented in FHIR resources

I hope to see all of you there. To register, go to, or you can see the formal program announcement.

p.s. it doesn’t say so on the program, but there’ll be a conference dinner on the Thursday night.