You may use this brief for informational, non-commercial purposes with credit attribution: The Global Health Delivery Project, GHDonline.org, Jul 19, 2016. Please see our Terms of Use for more information.

Australian Interoperability Project Spotlight: Learnings from the last decade

Added on 19 Jul 2016

Authors: Joaquin A. Blaya, PhD; Reviewed by Terry J. Hannan, MBBS, FRACP, FACHI, FACMI

As more health information systems become implemented, the focus becomes interoperability, how these systems can communicate between them to integrate data. One of the components is standards which have existed for decades including HL7, SNOMED, RxNorm, and LOINC among others. Further, organizations have been created to help organizations and countries implement these most notably OpenHIE.

Australia formally started their eHealth interoperability about 10 years ago. More than technical integration, this was an effort to establish layers of policy, workflow, semantics, and technology to support agreements on what these organizations will collaborate and on which things they won't. Australia currently has a range of clinical communities electronically interacting with varying degrees of policy support, behavior consistency, semantic agreement, and technical integration.

This Project Spotlight provided an overview of the Australian experience with the viewpoint of what other countries and organizations implementing eHealth interoperability could learn.

Key Points
  • Data sharing agreements happen in clinical, public health/reporting, and financial agreements. They don't seem to adhere to a consistent model of healthcare, but it helps in recognizing why interoperability is critical to a complex, evolving system working together over time with no single point of control.
  • Currently, the amount of interoperability is mixed. There have been bottom-up and top-down initiatives, which have achieved mixed results. It's rather idiosyncratic what does and doesn't work.
    • Within hospitals there are usually electronic systems using HL7 v2 for patient management, lab results, medication management and sometimes scheduling.
    • Between hospitals and their local community, some use the electronic system for discharge summaries, but others are still using letters or faxes. Referrals are less likely to be down electronically, and even less likely between GPs and specialists.
  • Additionally, there's a national Personally Controlled Electronic Health Record (PCEHR) system called My Health Record, where individuals can opt-in to having a record that they control. Healthcare providers are able to upload health summaries, event summaries, referrals, and prescription and dispense records to an individual's personal record, and then the individual (or their designated agent) can share these record with other healthcare providers. This is a national HIE using XDS+CDA, with a layer of patient control added.
    • It started on July 2012, but is entirely new culturally, so it hasn't had wide spread adoption yet. Just over 10% of the population currently has a record. Approximately 8,000 provider organizations are connected with the ability to send and view clinical documents. About 50% of public hospitals and health services are connected, and about 15% of private hospitals and health services. Around 10,000 clinically curated documents are sent to the system each week, and this number is growing quickly.
    • There have been no large benefits except reduced administrative burden for hospitals and GPs. It's on the cusp of doing useful things, but there's a lot of detailed reconciliation needed.
    • There are major problems with poor data quality where you can have high quality, structured, CDA level 3b, SNOMED coded data that still represents poor clinical practice and (for example) a contra-indicated list of medications for a patient. Further, it is seen as a large burden on clinician despite them uploading a small part of their patients. The Australian government just made it a requirement for clinicians to upload at least 5 patients per quarter.
  • A major lesson has been that “clinical interoperability” as a clinical problem rather than an IT problem. Until Australia can establish that high-quality clinical documentation is a clinical task, not an administrative task, all efforts at meaningful interoperability will fail. To do this will require:
    • Systems that make producing high-quality clinical documentation easy. Currently, a large number of clinical systems don't get this.
    • Clinicians aware of the value that data adds to their ability to be a diagnostician or how to manage the problems in front of them.
    • Financial incentives for clinicians to do this work.
    • Stronger (automated) data quality. This is relatively easy to do for the structural quality of the data e.g. CDA conformance level, but hard to do for clinical content quality.
  • We did some work in Kenya as a proof of concept on data exchange and unique patient a couple of years ago. You can find some info here, https://sites.google.com/site/oeckenya
  • For any system starting out with interoperability, one recommendation was to analyze how much agreement do you have amongst clinical providers around what kind of data sharing agreements (both in regard to the nature of the data, and the accountability processes around the sharing). If you have good agreement (though it's hard to tell, because early on, no one wants to be nay-sayer, so they just shut up), then you can set up data sharing agreements, and use FHIR. If you don't, then all you can build is a pile of documents that everyone will be suspicious of, using CDA/XDS, like Australia did.
  • One successful experience is that of the northern territory because they had a very aligned approach driven by consolidated governance and investment.
  • Many of the challenges don't have an off the shelf solution but one day hopefully they might. We need to acknowledge the co-existence of things that work today, things that we think we know how to invest in for tomorrow, and things that need some clever minds to try novel solutions, potentially fail, but give us insight into ways that we can move those problem into quantifiable investments.
  • An interoperable solution without a sound business model, in all senses of the word, is not a sound model for moving forward.

Key Resources

Download: Australian_Interoperability_Project_Spotlight-_Learnings_from_the_last_decade.pdf (127.6 KB)