Graham Grieve counters the case for smart eHealth cards with the argument that smartphones would work better.
Several experts that presented to the senate panel investigating the My health Record in 2019 argued that instead of a central data repository, Australia should instead, invest in a smart card based infrastructure to store consumers’ health care records.
These experts proposed an approach where each individual carries their own smart card, and healthcare providers load information to and read information from the card during encounters with health care providers.
The experts claimed that using smart cards avoids the central problem of the My Health Record system: a single consolidated record of all health information, with dual consequences:
- All patients are held to a single set of policy choices about how their information is shared and managed
- The single repository is a large, attractive target for hackers and any successful hacks may yield many records.
Most of the focus was on the second point – a single gathering of such a large amount of healthcare information is a natural target for hackers of various kinds.
Note that although the central system is highly secure and run by a security-focused team with high-discipline, provisioned to be able to make a rapid response to emerging issues, the same cannot be said of the many access points authorised to access data from the system.
A hacker gaining control of such an access point (or, a legitimate user misusing the endpoint, as in the Medicare number breach in 2017) would have access to all the records, though the more indiscriminately the access is used, the more quickly it would be detected.
The experts claimed that these problems could be resolved by using smart cards instead.
SMART CARD EVALUATION
It’s certainly true that smart cards would not have the same security challenge – hacking a single smart card, or even the system by which smart cards are accessed/updated would only grant access to the subset of smart cards encountered by the hacked system(s) during the time of the hack, since there is no central database to hack and get global access to.
However, smart cards do not make any difference to the rest the of problems a system faces; they simply move them around. The problems of security, integrity, access control and security still arise in any architecture.
The challenges for a smart card based approach are:
- Who has the right to read information on the smart card?
- How can a patient control how much information is accessed?
- Who has the right to put information on the smart card? And how is existing information reconciled with new information? Can systems updating records overwrite existing patient information?
- How do you secure smart cards against non-authorised readers, and still allow for back up?
- How do you incentivise consumers to keep track of their health smart cards so they don’t lose them? (and how do you incentivise them to backup their information?)
- If they lose information, is it stored somewhere else like a new central store?
- How much information can you fit securely on a smart card? (And how much does the system cost?)
Overseas, health smart cards generally store very little information – usually, enough to automatically identify the consumer that carries the card and to connect to a patient record stored elsewhere. In other words, it’s a token that provides access to a central record store. This does not avoid the problems of a central repository.
All of these have possible solutions, but because the smart card itself is passive, the solutions must be imposed through rules made about the software that interacts with the smart card. Which means, in effect, the smart card system would hold patients to a single set of policy choices about how their information is shared and managed; at least to the degree that the government can impose a single set of rules.
But the patient doesn’t have any say about this – only the providers of the software to healthcare do.
The current arrangements around the My Health Record – with the running problems related to certificates that the agency is not in a position to solve, but is still being held accountable for in public – demonstrate that a single organisation, or the health software ecosystem, cannot solve all these problems.
Finally, using smart cards raise a real problem inherited from the “Australia Card” debacle – people are suspicious of government supplied cards that have an identifier. In fact, this is such a serious perceptual problem that this might be the most important question:
- Would Australians accept any kind of smart card from the government? (even if it doesn’t serve as an identifying card)
A patient controlled record will only truly be patient controlled when the patient holds the information. Unfortunately, smart cards will not get us there.
A REALLY 'SMART CARD'
All of these questions already have an answer; it’s called the smartphone. Smartphones are the correct package for acting as ‘local store’ for a patient’s information:
- 89 per cent of consumers already carry a smartphone
- Consumers part with their smartphones reluctantly
- Most consumers backup their smartphones often and generally keep a close watch on them
- Smartphone vendors invest billions of dollars in making both a secure and usable smartphone ecosystem
- Rather than building a static framework, the government can specify the API formats used to exchange data between smartphones and the rest of the system, and let innovation bloom in the consumer space. The same APIs can be reused for other purposes in healthcare
- Applications on smartphones can manage storage/access/reconciliation/ownership issues to the degree that the consumer wants without a central authority having to make all their decisions for them
- Smartphones typically have plenty of storage space (note: it’s not known how much consumers would allocate to health, but the smartphones can proactively manage this question)
- Other countries (most notably the US) are already building ecosystems based on APIs that serve smartphones, with active support from the providers of the ecosystems.
In fact, it would be cheaper to buy the remaining 10 per cent of the population a smartphone than invest in a smart card ecosystem. Though many of that Australian population is not in a position to hold and use smartphones – mostly elderly patients and children under the age of two – they can depend on other people to manage their healthcare information. This is yet another challenge to resolve for smart cards.
For this reason, the Australian Government should pay careful attention to the foundations of a healthcare information ecosystem to ensure that all consumers, not just digital literati, can leverage any API based system.
And it should ensure a robust framework is set up for assessing policy and technical conformance for the APIs (though this no magic bullet).
Of course, some consumers won’t want to use smartphones to store their health records at all. Others might want to take advantage of a centrally provided secure repository. The strong benefit of a web/API based framework is that consumers can choose how to engage with the system.
As such, future developments for the My Health Record system should move away from the current document repository approach towards a web/API based ecosystem.
Grahame Grieve is the Principal of Health Intersections, and a healthcare Interoperability consultant and developer.
