Argonaut in Australia, and the MyHR

Project Argonaut is coming to Australia. That is, at least one major US EHR vendor is planning to make their SMART-on-FHIR EHR extension interface available in Australia during 2018 (discussion about this at Cerner Health Conference where I was last week). HL7 Australia will work with them (and any other vendor) to describe what the Argonaut interface looks like in Australia (short answer: not much different: some different patient extensions, a few terminology changes (not RxNorm), maybe a couple of extensions on prescriptions for Reg24 & CTG). Also, HL7 Australia will be planning to engage with Australian customers of the US EHR vendors to help build a community that can leverage the capabilities of the SMART on FHIR interface.

This is a big deal for Australian EHR vendors that compete with the US vendors – they better start offering the same capabilities based on the same standards, or one of their key market advantages will be consigned to the dust of history. They’ll also find themselves competing with established SMART on FHIR Application vendors too. So I look forward to good engagement with Australian companies as we flesh this out (I know at least one will be deeply involved).

This also offers us an opportunity to consider what to do with the MyHR. The government has spent a great deal of money on this, and results have been disappointing. (Yes, the government publishes regular usage stats which show continuous increase, but these are not the important usage metrics, and they’re not the kind of stats that were hoped for back when we were designing the system). And it’s hardly popular amongst the typical candidate users (see, for example, AMA comments, or for more color, Jeremy Knibb’s comments or even David More’s blog).

But I’m not surprised at this. Back when it was the pcEHR, the intentions were solid, and though the original timeline was impossibly tight, it came together in an amazingly quick time (kudos to the implementers). But as it came together, I knew it was doomed. This is inevitable given it’s architecture:

Salient points about this architecture:

  • The providers push CDA documents to the central document repository
  • Patients can view documents about them
  • Patient’s can write their own documents, but providers won’t see them
  • Patient’s can exert their control only by ‘hiding’ documents – e.g. they can only break the flow of information (reminder, the internet age treats censorship as damage and routes around it)
  • Clinicians can find and read documents
  • Each document is it’s own little snap shot. There’s no continuity between them, no way to reconcile information between them
  • There are no notifications associated with the system

You can’t build any process on that system. You can’t even build any reliable analysis on it (stakeholders worried about the government using it for secondary data analysis shouldn’t, in general, worry about this, it’s too hard to get good data out of most of the CDA documents). These limitations are baked into the design. That’s why I went and developed FHIR – so that when the full reality of the system become evident, we’d have a better option than a document repository.

Well, 10 years later, and we’re still trying to load ever more use into the same broken design, and the government sponsors are still wondering why it’s not ‘working’. (at least we stopped calling it the ‘personally controlled’ EHR, since it’s the government controlled EHR). And as long as it exists and is the focus of all government efforts to make digital health happen, it will continue to hold up innovation in this country – a fact which is terribly evident as I travel and see what’s happening elsewhere.

But it doesn’t have to be like this.

The MyHR is built on a bunch of useful infrastructure. There is good ideas in here, and it can do good things. It’s just that everything is locked up into a single broken solution. But we can break it open, and reuse the infrastructure. And the easiest way I can see to do this is to flip the push over. That is, instead of the source information providers pushing CDA documents to a single repository, we should get them to put up an Argonaut interface that provides a read/write API to the patient’s data. Then, you change the MyHR so that it takes that information and generates CDA documents to go into the MyHR – so no change needed to the core MyHR.

What this does is open up the system to all sorts of innovation, the most important of which is that the patient can authorise their care providers to exchange information directly, and build working clinically functional systems (e.g. GP/local hospital, or coordinated care planning), all without the government bureaucrats having to decide in advance that they can’t be liable for anything like that. That is, an actually personally controlled health record system not a government controlled one. And there’s still a MyHR for all the purposes it does exist for

This alternative looks like this:

The salient features of this architecture:

  • All healthcare providers make healthcare information services available using the common Argonaut based interface (including write services)
  • Patients can control the flow at the source – or authorise flows globally through myGov (needs new work on myGov)
  • Systems can read and write data between them without central control
  • The MyHR can pull data (as authorised) from the sources and populate the MyHR as it does now
  • Vendors and providers can leverage the same infrastructure to provide additional services (notifications, say)

The patient can exert control (either directly at the provider level, or through mygov as an OAuth provider) and control the flow of information at the source – they can opt-in or -out of the myHR as appropriate, but they can also share their information with other providers of healthcare services directly. Say, their phone’s very personal health store. Or research projects (e,g, AllofUs). Or, most importantly and usefully, their actual healthcare providers, who can, as authorised by the patient, set up bi-directional flows of information on top of which they can build better coordinated care processes.

These features lead to some important and different outcomes:

  • Healthcare providers and/or system vendors can innovate to build distributed care models that provide a good balance between risk and reward for different populations (instead of the one-size suits bureaucrats that we have now)
  • Patient’s can control the system by enabling the care flows that they want
  • Clinicians can engage in better care processes and improve their process and outcomes (though the US process shows clearly that things get worse before they get better, and you have to plan for that)

This isn’t a small change – but it’s the smallest change I know of that we can make that preserves the MyHR and associated investment, and gives us a healthcare system that can innovate and build better care models. But I don’t know how we’ll think about getting there, given that we’re still focused on “make everyone use the MyHR”.

Note: Adapted from my presentation yesterday at the HL7 Australia Meeting

 

11 Comments

  1. david hay says:

    How does this accommodate things like the patients medication list, where there should only be one per patient?

  2. Peter Jordan says:

    Interesting. Might the exclusive use of a constrained set of CDA Documents in the repository limit the potential uses of the data – why not move to FHIR Documents? Either way, it’s still a central repository which, with massively-increased use, might rapidly grow beyond the means of the infrastructure to support it.

    • Grahame Grieve says:

      FHIR Documents would be an improvement – if, that is, governance over persistent identification and consistent encoding and process is dealt with. I suppose in the absence of that, FHIR would still be an improvement over CDA, but not enough to make a big difference. It’s the *document* nature that is the principle issue

  3. Martin Entwistle says:

    Is there a reason Labs does not have a separate repository like Pharmacy? Is it assumed lab data is only collected by GPs and hospitals in the context of their clinical records? Might not be true?

    It would also be prudent to allow for a repository of “PGHD / PRO / Other personal health data” to allow collection and use of data that pertains to an individual, not necessarily in the context of being a patient, to be held, identified to an individual and used appropriately. There are rapidly increasing volumes of these types of data that start with no clinical context, but are increasingly pertinent to clinical management. Think wellness management or collection and use of social determinants of health in senior care.

    • Grahame Grieve says:

      There’s lot of things that might be a good idea… That’s the kind of innovation I’d like to see enabled

  4. Jeffrey Chen says:

    The problem in Australia is the government has spent 20b on the project and the name of the product has been changed from PCEHR to MyHR. So, it is not going to be personally controlled record anymore.
    On the other hand, We have lots smart people but Australian HIT market is much small than other countries. So, it’s really hard for vendor to adopt those things without government, ADHA, AMA and other institutional strong incentive input.
    Hope HL7AU can start talk with ADHA to push step forward on this topic.

  5. Completely agree with what you have written Grahame.

    The Argonaut Project sitting on top of MyHR will create a very valuable platform. With this platform it will enable a viable national resource for use by all involved the delivery of healthcare.

    Due to the limitations in the current system, various other solutions are being implemented around the country which lessen the value of MyHR, i.e. GP interfaces to state run repositories.

    We all need to agree to a single, capable platform so that we can benefit from the implementation of our eMRs as a nation.

  6. Jane Farris says:

    In answer to David’s comment about “one medication list”. The medication list is a point in time “record” made up of constantly changing and very complex elements. Therefore Graham’s comments about moving from a document(point in time publish) to a information service (flow of data)infrastructure also addresses the My Meds perspective 😆

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: