It’s Personal

Fixing the EHR, Part IV

Image is a composite of Google Maps and a webcam screenshot from Tembe

This post continues my series on Fixing Health IT.¹ Elephants may be involved.

Years ago, near the end of my medical student training, I did a ten-week ‘elective’ at a rural hospital in the northeastern part of South Africa. KwaZulu. We saw and treated conditions that I’ll surely never see again.² For example, there was a man with two broken femurs. An elephant stepped on him as it destroyed his hut. At the time, there was an ongoing feud to the West, between the local elephants and villagers trying to protect their crops.

But the really interesting thing for me was the record keeping system. There were no centralised records then, as they simply lacked administrators. Every family kept their own records in folders, and even if your hut was destroyed by an elephant, you made damn sure you recovered your records. That man came in clutching his notes. The paper record was usually all there was, and it was pretty universally acknowledged to be valuable. It was treasured.

Might we learn from this? I think we can. A word of caution, though. This is difficult stuff. It’s easy to stray and bump into angry elephants. Don’t expect a glib, complete solution in one post.

EHRs

It’s pretty clear that current electronic health records (EHRs) are clunky. They often have thousands of database tables,³ where a couple of hundred would do the trick. In a recent post,^⌘ we encountered incoherent terminology. Major EHRs don’t converse^⌘ well. Even time^⌘ is badly handled.

And here’s the thing: there is no technical reason why you can’t have your entire health record close to your heart at all times. You can and should be able to put it all on your smartphone, which has quite enough computing power and storage.

So what are the obstacles? Not hardware. The obvious issue is how the information is structured: a software problem. I cannot emphasise how important this foundation is. It will take several posts to get this right, even as a sketch.

But hasn’t this all been tried before? The ‘Personal Health Record’ (PHR), portable and available to you wherever you are?

Prior art

The road to the PHR is littered with the corpses of giants that failed. Google tried. Microsoft tried. Apple’s initial effort was a bust. Numerous health systems now offer something vaguely like a PHR—but there are catches, irritations, and huge stumbling blocks.

We can learn from failure. Google Health came out in 2008. It was generally crappy, as illustrated above, and died in 2012. Microsoft’s HealthVault was launched in 2007 and died a grim death in 2019, with added flaws: dependence on corporate partners supplying compatible gadgets, the ill-fated Microsoft Band, and so on. Apple started with the disastrous HealthKit in 2014—bug-infested and clumsy.

There were obvious defects: front ends were unfriendly. Most data entry was manual. And health care providers clung grimly to your data, and wouldn’t let go.

Apple had a second bite in 2018 with the launch of Health Records, which used the Apple Watch as a trojan into the user’s consciousness, and added access to some rather gappy and badly-structured health care data, using FHIR.^⌘ The catch here is that you’re firmly welded to Apple, even for these fragments.

With data, possession is pretty much all of the law.

Doing better

Now we’re seeing moves towards ‘patient portals’ and ‘shared digital records’: windows on your health information. Issues remain. I can see two. A huge issue is that you still mostly don’t have free access to all of your data. Big health providers hold on.

But I’d suggest that the really big problems are structural. They always were. This is difficult. Giant corporations and even entire countries have stuffed this up repeatedly. They still do. And if you don’t get the structure right—if you don’t join up the data properly—then you’ll never get the upper layers right.

So long before we describe how your grandmother Dorothy can access her data in the way she wants to, we need to drill down to that underlying foundation, and make sure its solid. We’ve met the fundamental principle already: loose coupling between the functional layer and the underlying information layer^⌘ means that we can continually improve what people see and how they see and use it, without having to go back and re-design the foundation. The functional layer should be a distinct, secondary issue.

First we need to get the information layer right. And once we’ve done that, there’s no reason why you shouldn’t have a a full copy on your cellphone. A PHR! Doing what you want.

And here’s a thought. We’ve recently seen major outages crashing substantial parts of the Internet for hours or more. Azure, Cloudflare, and the whole of Iran. Tough if you need your portal then. If you have your PHR on your phone, no problem.

Does it synch?

Previously, I talked about representational adequacy.^⌘ If you’re going to pull information using e.g. FHIR, then your source of information must represent the information adequately, and the transfer mustn’t degrade it.

So even if we regard a ‘PHR’ as simple, the underlying data representation must be adequate. Then only can we talk about whether the presentation of the data synchs with your expectations.

There’s a tricky balance here. When I started writing this post, at this point I spent a lot of effort and words talking about user expectations. And then I realised that I’d taken a false step. There are two ways we can use our understanding of what people need. One is to inform our design of the information layer. Another is to inform our design of the functional layer. Both are important, but it’s wrong to now digress about function. That follows later. Much later.

So let’s not digress. We have design work to do. There are several more obstacles.

International rules

There’s a lot of badness and unreason out there. Foremost is the US: although the HIPAA law of 1996 mandated creation of a unique health ID for every American, Section 510 bans just this, by denying funding. Nuts.⁴

In contrast, the French have their own interesting approach built around their common health ID (Numéro de Sécurité Sociale, NSS). Their Public Health Code (Articles R1111-8-8 to R1111-11) mandates Hébergeur de Données de Santé (HDS) certification. You must show that health data are kept separate from all other data, with personal identifiers stored in their own, separate, high-security silo. Only trusted third parties can link data and identity. There are big gotchas: it’s ferociously expensive, killing innovation and small players. Maintenance is also a bugger, cross-disciplinary research is crippled, and re-identification may still be possible.

These are just two extreme examples. Several countries have pretty robust ID systems that work reasonably well: Estonia, Denmark, Sweden, and Singapore. We can get things right with the right basics and the right level of trust.

⚠️The next two sections are a little technical.⚠️
If you feel your eyes glazing over, skip to the Paranoia section near the end!
It’s just below the cartoon.

Starting simply with people

It will take several posts for me to tie together what we need in the underlying information architecture. A good place to start is with people, and their personal information. Modern health records often get this wildly wrong.

For example it may seem ‘reasonable’ to have separate tables for STAFF and PATIENTS. One catch is the designers often seem to forget that clinicians and other staff can fall ill. So even answering the managerial question “How many of my staff have been admitted?” can be fraught. People are people. They take on roles.

It’s easy to get other things wrong too. Take the case of a person represented in a ‘PEOPLE’ table. They have a unique, external health ID. It’s tempting to store this in PEOPLE. Why is this a mistake? Let’s take a practical example.

In New Zealand, we have the NHI (for National Health Index) number, a unique, personal ID. It’s moderately cunning: seven-characters with a built-in checksum. But shit happens, so people sometimes acquire more than one NHI. Can you now see why the preceding storage is a mistake? Yep, the ‘primary’ NHI obliterates the ‘secondary’ one. Or you end up with multiple fields. Etc. Messy. Wrong.

Good design can fix this. We need two tables. Very few basic facts belong in the PEOPLE table: an internal unique identifier (the primary key), information about when each row was made and updated, the person’s date of birth, and space for when they die.⁵

The PERSONAL table links to PEOPLE, each row describing a single attribute of that person—their current given name, their family name, their gender, health care identifier(s), and lots of other personal information that can change over time.

It’s easy to get this sort of basic information storage wildly wrong. For example, that 15-digit French NSS contains a hard-coded representation of your sex: male or female, and that’s it. Even before we get to any database, we have a big area of representational inadequacy that has major implications for infants born with ambiguous genitalia, transgender people, and perhaps even the women in the following picture,^⌘ who have an XY genotype, SRY positivity, and ‘male’ testosterone levels.

Trouble over time

We’re not done with time.^⌘ Almost all modern health records are episodic. They are built around intermittent interactions between ‘patients’ and the health care system. This can generally be considered defective.

There are two issues. The first is that the complex structure of such ‘episodes’ is often recorded badly. The second is the widespread belief that episodes can simply be joined up into long-term structures, after the event. Like beads on a string.

I have a better way that’s also simple. It has just 3 moving parts. At the bottom is an ‘epoch of care’⁶ between a patient and a care giver. It contains:

• The identity of a single patient

• The identity of a single caregiver⁷

• A defined start and end (Using our familiar timestamps).

• A reference to a larger process.

To represent the complexity of multiple processes, both during an episode of care and outside of one, we have more general PROCESSES. These can be short, but they have the potential to extend for the lifetime of a patient.

For example, someone might have an operation. That’s a process. We hope that for the duration of the operation, they underwent anaesthesia—another process. You can see how various people in various roles can participate, each with their subsidiary epoch of care linked to the relevant process.

Which brings us to the third moving part. We need to be able to link two processes together—this is a bit ‘meta’, so we might call it a meta-process. And that’s it: a pretty flexible solution that doesn’t involve building great big, hierarchical table structures.

Doubtless you have a better way, and if you do, let’s hear it!

xkcd: Security

Paranoia

It may be worth talking briefly about security. Ownership carries responsibility, and this is difficult. It may be tricky to protect your data against elephants. The above XKCD cartoon is big in cryptocurrency, these days. Coercion is indeed scary, but the greatest vulnerability you have is in trusting the wrong people. Social engineering is the most potent way of accessing secured information. They also save $5 on the wrench.

It’s tempting to relinquish control to some larger entity, especially one that has more resources, and that can provide better security. But elephants can be virtual too. Trust, again.

The sad thing here is that we often don’t realise the greatest value of our information. It’s when huge amounts of anonymised information are used to improve our society. If we understand the background processes and fix them using the principles of Shewhart^⌘ and Deming,^⌘ we’re onto a winner.

We need to get back to those basic principles: building right, controlling our personal information, and trust.⁸ If we own our information, trust its storage, and identify trustworthy people who will use it well, then it becomes sensible to start sharing—especially for the good of others.

Simple solutions

Health records are currently so crappy that I often meet patients (or their caregivers) who keep a folder full of pictures of the important problems and reports on their smartphone. Which is not too different from the elephant man at the start, come to think of it!

Can we do better? We’ve started with five simple concepts that can be turned into data tables: people, personal information, processes with meta-process information, and documented, one-to-one interactions between individual providers of health care and recipients. We need a lot more before we start building software that lives in the functional layer.

We need further solid building blocks in our information layer. Remember the original, multi-dimensional SNOMED?^⌘ Soon, we’ll move on and put those multiple dimensions to good effect.⁹ But first, let’s build that information structure.

My 2c, Dr Jo.

^{⌘ This symbol is used to indicate posts where I’ve discussed the flagged topic in more detail.}

1. Part I touched on data and FHIR,^⌘ Part II^⌘ did SNOMED, and Part III was about time.^⌘

2. Like the still unexplained Mseleni joint disease.

3. Or the equivalent: Epic’s Clarity has over 18,000 tables when their B-tree structure is turned into SQL.

4. This is the country that allowed Musk’s DOGE to run wild with personal data.

5. It’s difficult to have more than one correct date of birth, or death.

6. Call it what you wish.

7. And this can even be reflexive: the patient can ‘self-care’!

8. Perhaps trying to avoid the French excesses. Better is what they built in Hong Kong: if someone new accesses your data, you get a text message there and then.

9. In my first (emailed) version, I said that this would be next. But wise minds prevailed, hence the current link to ‘A faster horse’.