Modernising the MyHR?

On Friday last week, an article by Wendy John was published by Wild Health, in which I’m quoted as saying, regarding the My Health Record and the Strengthening Medicare Taskforce report:

FHIR guru Grahame Grieve has advocated for interoperability standards in healthcare for over two decades. He said it is “hard to be excited about it,” given the trajectory of the implementation of those ideas.   

It’s basically the blueprint that we’ve been waiting for 20 years to be implemented and all we’ve gotten is a rather useless document database in the sky,” he said. Mr Grieve said the challenge will be in turning the report into meaningful outcomes for strengthening Medicare.  

If I did say exactly that I did not mean too. Regardless I regret that those words somehow got into a story and wish to clarify what I meant or should’ve said here. (Aside: lesson learned, pay more attention when talking to journalists).

What I thought I said – and should’ve said – is that the MyHR is a “a document database of limited use”, not “rather useless”. 

It’s a difference that matters. 

There’s two reasons why it’s of limited use. 

The first reason is that doctors don’t upload documents to the MyHR because it’s not worth looking at it because no one uploads documents to the MyHR, and that’s been a problem with it from the start. 

Since Kate Ebrill tells me that no good technical person can write anything at all these days without mentioning chatGPT, I asked chatGPT to explain this for me:

Me: what would you call it if a system wasn’t worth adopting because no one else has adopted it?

ChatGPT: If a system isn’t being adopted because no one else has adopted it, it’s referred to as a “chicken-and-egg problem” or a “network effect.” This occurs when the value of a system or product is dependent on the number of people using it, and thus, it becomes difficult to get people to adopt it because they see no one else using it. This creates a self-reinforcing cycle where the system fails to gain widespread adoption because of a lack of users, and the lack of users prevents the system from gaining value and becoming more attractive to potential users.

The government’s response to this challenge has been to cajole, pay, and force clinical providers to upload documents to the MyHR in the hope that this dynamic can be turned around. So it’s no surprise to find these words in the Medicare taskforce report:

Modernise My Health Record to significantly increase the health information available to individuals and their health care professionals, including by requiring ‘sharing by default’ for private and public practitioners and services, and make it easier for people and their health care teams to use at the point of care. 

(page 9)

As far as I can see, that’s the only concrete action in the whole report. But will it work? 

Well, I’m personally pretty dubious, because of the second problem. See, the MyHR is a list of past documents, records of things that happened – clinical events, prescriptions, dispenses, immunization. A frozen record of the past, with no way to communicate directly with the source system. There’s definitely a place for a historical record like this in healthcare, and a emergency doctor friend told me after reading the article that he does consult the MyHR occasionally in the hope that it has something in it that will give him a clue what’s going on with the patient, in the small number of cases where past records will help, and were the patient does have documents in there (the only documents in mine are my prescription/dispense documents). But only when he really has to – it’s not an efficient way to browse the history (because it’s documents that have to be scanned by a human)

So it’s not rather useless – that’s a definite valid clinical use. But that is a system of limited usefulness.

Because what the MyHR doesn’t have is any sort of workflow collaboration or management, or even simple messaging between patients and providers. I’ve sat in meeting after meeting where clinical teams of various kinds have wanted to do something like interact with the patient to improve efficiency or effectiveness of care, and thought to use the MyHR, but they can’t. Not only does it not have the features that they want, but because of the political risk of a central government run system having problems, the only things that can be done with it are things that have run through multi-million dollar risk assessment processes, ones where the principle risk being managed is that risk of damaging the government’s reputation.

I can’t see the system that we have ever overcoming the network effect. It needs to be redesigned completely. Which brings me to this wording:

> Modernise My Health Record to significantly increase the health information available to individuals and their health care professionals

The big question is what ‘modernising’ means. So far, all the ideas that I’ve seen the Australian Digital Health Agency that runs the MyHR announce have involved modernising the technical infrastructure that runs the MyHR, including transitioning to a FHIR interface (which I’m in favour of) but without redesigning the way the system works, with the attendant cost that would have. 

Five years ago, the Australian Senate held an enquiry into the myHR and I made a submission saying that we needed to redesign it, and adopt a genuinely federated model, an open healthcare system, and that we needed to that federated model to allow clinical teams and providers to use the system to fit to their needs. And I’m far from alone in this view.

Wendy’s article picks up on this:

MHR is a centralised model where, in theory, all health records are uploaded and then distributed as required. However, the advent of cloud-based solutions and consumer demand for real-time data opens possibilities for distributed models, such as those in Denmark and the United States. 

A federated model that we’re thinking of is one where all the clinical systems that treat a patient provide a common API to allow for exchange of clinical notes, diagnostic reports, making and receiving referrals, and collaborating on common patient management. Patients and clinical service providers can decide which systems to connect to, and patients can authorise this is necessary. In most designs, there’s still a role for a central database, kind of a default system of record for all citizens, but it’s not the only game in town.

For the mathematicians amongst us, what creates the network effect is when more participants turns into more connections, and exponentially rising benefits, instead of increasing the load on the central choke point, which eventually yields less benefit per participant.

But for the rest of us, an open federated system is one where your GP, your specialist and the hospital are all seeing synchronised records and communicating with each other seamlessly. And we get seamless care, instead of telling the same story again and again, trying to convince doctors that what happened really happened, and different doctors doing different things because they don’t know what each other is doing or thinking (or even who each other are).

The Senate committee’s response to the idea of a federated system was:

While a federated model may have been preferable if the system was to be designed today. The committee acknowledges that a substantial investment has been made in the current system and that fundamentally redesigning the system would involve additional investment. 

The inevitable outcome of this response is that since then the Australian Digital Health Agency has done what the Senate said and tried to force the healthcare system to find a use for the MyHR we have, rather than trying to build the MyHR into something that the healthcare system will want to use. I sure know what would’ve happened to any company that tried to do the same: they’d go bust. 

The agency isn’t a company, so it can’t go bust, and maybe that’s the only way to solve this problem, but it sure looks like it’s failing the normal government way to fail. And failing us too.

The big problem is that it’s holding the whole country back while it tries to reverse the negative network effect.

The Taskforce report may represent an opportunity to revisit this question; certainly the gap between the capabilities that are starting to be available in other countries that we have not yet even started working on is starting to become quite evident to the experts, and it will eventually become very obvious to the average voter when they can’t get the healthcare they see other people getting on other countries. 

So it really all comes down to “what does modernisation mean”? Like the rest of the report, it’s just high level guidance, things that we should obviously do, but how? Hardly anyone is going to disagree with the substance of what the report says, it’s just going to be a matter of waiting to see what is made of it. 

Once again, though, the report does make one thing crystal clear: digital health, for all its problems, is really the only game in town to transform the healthcare system. 

So it’s time for us to take it seriously. Because we haven’t been for the last fifteen years.

HL7 Australia Webinar: Playing with #FHIR

After she caused plenty of excitement a few weeks ago, I’m please to inform you that Alissa Knight has agreed to appear on an HL7 Australia webinar with John Moehrke to talk about both her new report and the various responses to it.

The webinar will at 10am on Dec 1st 2021. Registration is free – see EventBrite.

I’ll be moderating the webinar on behalf of HL7 Australia, and also New Zealand – our kiwi colleagues are invited to join us as well. We’ll also be talking about what developers and administrators of systems should be doing to secure their systems.

Thanks Alissa (and John) for agreeing to share their knowledge and experience with us here in Australia and New Zealand.

Smart Health Cards at the HL7 Australia Connectathon Nov 2021 (#FHIR)

HL7 Australia is running a virtual connectathon 23-24 November 2021. See https://www.eventbrite.com.au/e/inaugural-hl7-fhir-trans-tasman-connectathon-registration-193185943357 for registration (free!).

One of the tracks will be focused on Smart Health Cards (see my earlier post about that), and I’m leading that track. So here’s a call for participation.

The primary focus of the track will threefold:

  • helping developers who need to produce valid smart health cards do that
  • Helping developers who need to read and verify smart health cards do that

Obviously those two activities will be extremely technical, very much a programming focus. For people who fit into either of those two categories, the two days will be a working session: producing SHCs, and checking they’re valid with the formal tools, and checking reading apps read them correctly. We’ll be focusing on covid vaccination certificates and lab tests, and we’ll primarily be doing exchange of certificates by email.

The fact that our primary exchange will be email, and that some of the tools are consumer ready tools: that means that non-technical people – policy makers, business analysts etc, they can join as well, so:

  • we’ll also have a focus suitable for non-technical people too, around understanding the use of smart health cards

That focus will include tutorials around how to use the consumer tools, understanding what you need to know about what’s going on behind the scenes, and discussing the policy implications of smart health cards. Finally, there’s a group collaboration project: what would the optimal process look like for using smart health cards to smooth entry management at very large events that require vaccination as an entry requirement?

Finally, for everyone in the track, we’ll have Q&A sessions with leading smart health card implementers from both Australia and around the world, and we’ll have panel discussions on the following subjects:

  • Smart health Card revocation
  • Bulk distribution of public keys to ease off-line verification
  • Australian profiles for covid vaccination and lab test cards

See you there!

Further details: https://confluence.hl7australia.com/display/AFR/2021-11+Virtual+Connectathon

Under the hood: Australian International Covid Certificate

I’ve just spent a day looking under the hood at the Australian international covid certificates, and I thought I’d post a few observations here.

You can get these covid Vaccination Certificates in various ways, but I got mine from the medicare express app. In order to get it, you have to enter your passport details, and they have to match government records or your Australian passport or visa. I have at least one friend who can’t get one because he doesn’t have either of those (some people legally here don’t).

What you get is a PDF that contains a QR code. The QR code represents the following JSON (not encoded or encrypted – this is what any bar code scanner will give you):

{{
"data" : {
"hdr" : {
"is" : "AUS",
"t" : "icao.vacc",
"v" : 1
},
"msg" : {
"pid" : {
"dob" : "YYYY-MM-DD",
"i" : "XXXXXXXXX",
"n" : "FAMILY FIRST NAMES",
"sex" : "M"
},
"uvci" : "VA0010262211",
"ve" : [
{
"des" : "XM68M6",
"dis" : "RA01.0",
"nam" : "AstraZeneca Vaxzevria",
"vd" : [
{
"adm" : "General Practitioner",
"ctr" : "AUS",
"dvc" : "2021-06-05",
"lot" : "305592P",
"seq" : 1
},
{
"adm" : "General Practitioner",
"ctr" : "AUS",
"dvc" : "2021-08-28",
"lot" : "308978P",
"seq" : 2
}
]
}
]
}
},
"sig" : {
"alg" : "ES256",
"cer" : "MIIDhDCCAWygAwIBAgICGMkwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCQVUxDDAKBgNVBAoMA0dPVjENMAsGA1UECwwEREZBVDEMMAoGA1UECwwDQVBPMSswKQYDVQQDDCJQYXNzcG9ydCBDb3VudHJ5IFNpZ25pbmcgQXV0aG9yaXR5MB4XDTIxMDkzMDE0MDAwMFoXDTMxMTAzMTEyNTk1OVowHDELMAkGA1UEBhMCQVUxDTALBgNVBAMTBERGQVQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATc5tWUh8cnqT2JMJRqwOb4eqooPo2K36p9r9aXW7A5n_eXLv6c5_TVvDUaX4bslfwmRxtUzzARCuTMo5lcXp_Wo1IwUDAWBgdngQgBAQYCBAswCQIBADEEEwJOVjAVBgNVHSUBAf8ECzAJBgdngQgBAQ4CMB8GA1UdIwQYMBaAFDYXwef1Z5VxLjd1cI5VgzGG6TgOMA0GCSqGSIb3DQEBCwUAA4ICAQBr9XvPP3NRKyLDPQWZjA-_2InLI72SNEiYbwnw4beq4lMl1Y-Oueli44hquwDJD13cxUyunRVcpuKPSThQYkZq6wHLWtAHNTXKF_nAdXGpXV-5RbaqTCfu-1ZQS5LpU62MByUVOmoGKf4uNkUdsMektolQHwAq6PwAG1HpPGDey3ZRbAvuDCi4ovVoffdAxuvuEUkr4_UgdcqfQ35mTx074doYubeCH6CduA_V_Xq76tA5X6CF_wW2TI_npdVL0KCel3L1BKbmXjOAmRVEioOItMAF0RmN4s78CdDBGfsv7dOsCCQl1TWVX6ZqIlkXt5xOU-mDDt8hvsloS9hkUTqfUuBcM13YmYfymKCQ_xMXAzDHH5pI8xn-MyNaYe9V5_BqQ2XOWDh5-VYyRWwyn_zdRdgUo2AboKZzZi34po57Bpkt-_u6sHJxzoqDWn9FxY18hThvFh_EKsY7pr7_gL04bCE17PJzKmbGmKppBEhle0X7K0NF9KyX5T3nzNY0q59JJkfAApXrE207zY6KboJjdc_weAnB8P38Kq8SgY4cc1MiKCM7Pz7uWEEynA1LG6vvAkjchSrLnu5e0QMW2Rc94wccfZOcx0xs9clHydcZ_ITGrRvq6tfgad73pcMJ0GRW9jqq6KCdqYa8h_DXrlyYcJTXqbgw1JIBTdOU6pHT5g==",
"sigvl" : "kOz5jiwN5RZwERz3GWQfWv8yG82QlSWuxHmjQCBzg1-DQtcwQt6J496QXbKlbY4pdloaVQPJllDpOA5Lj4I0cA=="
}
}
}

This, btw, is my real certificate with PHI redacted out. The certificate format here is defined by the ICAO as the “Visual Digital Seal” (VDS) – see here.

The data is pretty straight forward: my name, date of birth, gender, and passport number, and then vaccine, date of vaccinations and assorted supporting information. There’s only really two features to comment on.

The first is the specification says the name should be ‘FAMILY, GIVEN GIVEN etc’, but the Australian certificates have FAMILY GIVEN GIVEN’. Note in particular that there’s two spaces between the family and the given names. I haven’t seen a certificate for someone with a space in their surname, but I presume the two spaces thing is reliable for that, and have coded accordingly.

The other feature of interest is that the vaccine code is “des” : “XM68M6”, “dis” : “RA01.0”, “nam” : “AstraZeneca Vaxzevria” – that’s pretty interesting. That’s two ICD-11 codes: XM68M6 = generic code for any covid-19 vaccine, and RA01.0 is the code for Covid-19, the disease. As far as I can tell, the code for the disease doesn’t add any value – it’s implied by XM68M6 and just wastes bytes. There must be some underlying reason (I know specs, and there’ll be some reason, but I can’t infer what it is). The odd thing about this is that there is ICD-11 codes for the specific vaccines (e.g. XM4YL8 for Astrazeneca), but they’re not used. This, btw, is a feature of the specification – while ‘des’ is documented as a “Vaccine or vaccine sub-type (ICD-11 Extension codes)”, all the examples use the generic code XM68M6.

This means that if you need to figure out which vaccine was given – and most processors probably will – you’ll have to read the name field. So far, I’ve seen the values “AstraZeneca Vaxzevria” and “Pfizer Comirnity” in there.

Moving on to the certificate: the data is signed by an X509 certificate per the specification. That X509 certificate is signed by the master (self-signed) certificate issued by the Australian Government (with CRL etc). It all verifies and validates ok. It’s super good that the certificate is signed, btw. Internal Australian vaccination certificates aren’t signed – I’ll come back to this issue in a later post.

So it’s possible to generate smart health cards (SHC) from these certificates. And I wrote a service to do just that, just for interest and to help people interested in playing around with SHCs. Go to https://test.fhir.org/icao/process, upload your covid certificate or an image of the QR code, and you’ll get back a signed SHC you can load into your favourite SHC app (eg. Apple Wallet). Note that the card is signed (properly) by https://test.fhir.org, and Apple etc (rightly) don’t recognise test.fhir.org as a real healthcare service, so they’ll tell you it’s not a trusted certificate. Also note that the service has problems with some QR codes – I’ve had to get a screen shot of the screen shot of the QR code and send that instead (don’t know why, it’s the industry standard ZXing library running on the server).

For those really interested… you can also use this an API service: POST a QR code as an image/png or the text as application/json to https://test.fhir.org/icao/process, and set the Accept header to one of image/png, application/jwt, or application/smart-health-cards, and you’ll get back a smart health card.

Update: in an earlier version of this post I hadn’t found the certificate page, and didn’t know how to verify the certificate. Fixed now.

Security Vulnerabilities in FHIR implementations

There’s a new report out that finds lots of security vulnerabilities in FHIR implementations, both client and server. This is useful work from Alissa Knight – thanks.

Unforunately, the media write up isn’t entirely accurate:

In fact, every tested FHIR app enabled API access to patient health data belonging to other individuals. And over 60% of the tested apps and APIs had flaws that enabled unauthorized access to data outside of the authorized users’ scope.

In fact, the report explicitly notes that no vulnerabilities were found or are documented in the EHR FHIR implementations themselves. That’s reassuring, and a little more note should be taken about that.

Nevertheless, lots of vulnerabilities were found. All of them are very basic house-keeping stuff well covered in the OWASP top ten risks. All of them are things we’ve talked about in the FHIR project, and agreed that OWASP handles them well, so we don’t need to say anything about them. And indeed, if you’re handling patient data, you need to do this stuff, and get it right.

All the vulnerabilities were found in the aggregated data space. What isn’t clear to me from reading the report is which side of the fence the vulnerabilities were found – were they on the institution side of the fence, where the data is shared by the care provider with the aggregator, and the system is covered by HIPAA and business associate agreements, or is it patient side aggregators, where the patient got the data directly from the provider, and then shared it with a an aggregator?

That makes a real difference, because the second space is only generally covered by FTC, and provider institutions cannot block sharing data with the patient, or make it conditional on patients only sharing it with their approved 3rd party handlers. That means that any security issues in systems that patient shares their data with are not the providers problem. But on the HIPAA side… a big deal.

Nevertheless several people have contacted me concerned that this report will help delay the provision of data to patients because of the catch-all ‘security concerns’, just the way that HIPAA – the portability act – is used as a catch all reason to prevent data portability.

I have thought for a while that additional regulation is needed over 3rd party aggregators that get their data from the patient. Viewed in isolation, who cares what they get from the patient? – it’s the patient’s business. But viewed at amazonian scale… they’re suddenly a significant player, and regulation will be needed at many levels to deal with their systemic impact.

HL7 Australia Webinar: Smart Health Cards

SMART HEALTH CARE CARDS WEBINAR – 5 OCTOBER 2021
Register Here: https://lnkd.in/gQj77KMF

The Board of HL7 Australia invites you to join a free Webinar on Tuesday 5 October 2021 at 09:00 AEDT to hear from key thinkers and implementors of SMART Health Cards and FHIR resources.

The subject of verifiable COVID immunisation and lab certificates is a very fast-moving subject here in Australia and New Zealand.

In the USA, Canada, and elsewhere, government immunisation registries, healthcare providers, EHR vendors, private employers, and technology companies are building an infrastructure based on SMART Health Cards and FHIR resources.

This work is coordinated through the VCI consortium (https://vci.org/), supported by HL7. Come and listen to the panel of key thinkers and implementors for this work, including leaders from the Health IT community in USA. They’ll describe their intent, how the specification works, and how it’s been adopted in the Apple and Android ecosystems. This technology is in production today.

For full details and to register go to:
https://lnkd.in/gQj77KMF

#FHIR DevDays & LMICS Discounts

FHIR DevDays Amsterdam/Europe edition is coming up soon: November 17-20.

Although DevDays is purely online this time, and potentially accessible anywhere in the world, it actually is the European edition in a meaningful way – it’s loaded and rich with European content. And, of course, it’s in the european timezone, though there’s also a session specially scheduled for a friendly time in Asia/Pac.

This will be the second DevDays that is online, and it will build on the success of the last one, and be even better because of the feedback from the first online one.

So I’m really looking forward to it. Register today!

LMICs discount

I didn’t just write this blog post to flog the DevDays event, much as I love it. No, I want to raise the profile of the special discount that arrangements for the lower/middle income countries.

We (I and Firely, the organisers of the event) understand that it’s very difficult for FHIR community members from lower and middle income countries to attend a normal FHIR DevDays – the combination of the event cost itself, the travel and accommodation mounts up (I know!).

Virtual DevDays are a great opportunity for people from LMICs countries to attend, with a reduced cost of registration, and no travel costs. But we recognise that even that reduced cost is still very difficult for lower income countries. For that reason, Firely have partnered with HL7 India, my good friends at Standards and Interoperability lab in the Philipines and myself to offer significant discounts for LMICs countries.

A ticket for people from Africa is € 50 all-in. The ticket fee for other low and lower middle income countries is € 100 euro.

(from the registration page at https://www.devdays.com/november-2020/registration-november/).

I think this is a great opportunity, and it hasn’t had much uptake yet. I encourage you, my readers, to spread the news and encourage attendance from the LMICs countries.

An alternative approach for resolving the Secure Messaging dilemma in Australia

Earlier this year, just as Covid-19 was getting going, I was talking to Nathan Pinskier about the many challenges fixing GPs at this time. Nathan asked me whether there was an alternative approach to solving the secure messaging problem – which is a consistent pain point for medical practitioners, especially this year.

I thought about it and wrote up a brief description of an alternative approach that I believed would offer a way forward. For me, it was most important to solve 2 inter-related problems:

  • There needs to be a clear business rationale for all parties to get involved (vendors, GPs, specialists, hospitals, public health authorities)
  • We need to solve the directory problem – how do you pay for maintaining it? (or who pays – it’s a key stumbling block)

A wider context is that the whole secure messaging concept as dying anyway – I already posted about that. These were the design inputs I considered when I wrote the document, and reviews from selected friends were enthusiastic.

However I did not want to derail the existing SMD project that the agency was running (or be seen to try to do that). If there was any chance that it would deliver, I thought that would be a better outcome even if it was a sub-optimal approach. But six months later, it seems clear that this program has run out of steam without actually making any difference to market outcomes, and there are participants out there looking for a different approach.

So here’s my proposal:

Note that this is just a rough outline – a lot of water needs to go under the bridge before it’s a solid proposal. I’m publishing it to stimulate thinking, and to suggest directions to various technical teams already thinking about this.

I want to thank Nathan Pinskier for starting me thinking about this (and also writing the first draft of the introduction), Brett Esler for technical input, and also Reuben Daniels and Andy Bond for review and comments.