I’m not a particular fan of Old Testament literality, but Genesis 11:4-9 accurately foretells today’s much discussed and much derided Electronic Health Records and Medical Information Systems:

4 And they said, “Come, let us build ourselves a city, and a tower whose top is in the heavens; let us make a name for ourselves, lest we be scattered abroad over the face of the whole earth.”

5 But the Lord came down to see the city and the tower which the sons of men had built.

6 And the Lord said, “Indeed the people are one and they all have one language, and this is what they begin to do; now nothing that they propose to do will be withheld from them.

7 Come, let Us go down and there confuse their language, that they may not understand one another’s speech.”

8 So the Lord scattered them abroad from there over the face of all the earth, and they ceased building the city.

9 Therefore its name is called Babel, because there the Lord confused the language of all the earth; and from there the Lord scattered them abroad over the face of all the earth.

The only folks who hate today’s hotness, Electronic Health Records (EHR), more than physicians are patients themselves. Log onto the EHR site for each of your potentially dozens of healthcare providers. What you’ll see is a narrow, incomplete, and incredibly inaccurate depiction of some isolated aspect of your healthcare. Have any of your other physicians ever seen it? Is there a billing code for “laughter time?”

EHR systems in the US free-market healthcare system are proprietary, meaning there’s countless different databases, user interfaces, and usage models for patient’s health information. None of them talk to each other in any meaningful way, and most practitioners, who ultimately have a business to run, enter spotty and highly inaccurate records which never are communicated to any other practices which treat the patient. Even if they wanted to share info, EHR has “confused the language of all the earth” and encouraged practices to follow the rule of “garbage in – garbage out.”

And now… a modest proposal that doesn’t involve culinary recipes containing your offspring:

A really useful approach to EHR and medical records systems is a unified national (worldwide?) relational database with a robust set of open APIs, accessible to anyone, and easy ways for future implementers to sandbox data experiments, new relationship models, and expose new data sets and results to anyone who has the chops to work on them. This isn’t a particularly original concept, except that it’s anathema to the power brokers in US healthcare.

The essential elements are a single flexible patient and provider healthcare database that provides both universal access and enforces personal privacy through an open Application Programming Interface (API.) The data and its interrelationships are public goods, easily accessed (by software engineers) through a single universal API that enables individuals, medical practitioners, entrepreneurs, big businesses, public institutions, and researchers straightforward and practical ways to observe, analyze, correct, and update the underlying data.

But, MY PRIVACY, You Cry!

Access is privilege based. The patient has ultimate control of their personalized data. A patient may grant access to their physician(s), either as read-only, or read-write. Patients can enable their physicians to share with specific other physicians… or not. APIs should give patients, through various apps, the power to share/not share information with providers and keep the shared information on a short leash (providers could not share with others without patient permission.) Could be as simple as the thumbprint on your iPhone (maybe with 2 factor authorization to follow.)

The data may also be accessed in anonymized form, i.e. stripped of any personal identifying information, primarily in aggregate form, i.e. groups of patients, by anyone with the chops to code using the API.

The actual use of the database is left to the public and private space through applications (apps) which interact with the database through the only available method: the API.

The Universal Database and API

The idea of a comprehensive unified database with a public API layered on top gives us the best of multiple worlds. If someone (or some company) wants to build an app for care teams, the API makes it simple and straightforward. If someone wants to build an app that helps patients explore their own records, compare them with other groups of patients, log, chart, etc…, the API makes it easy. Want to market the next FitBit? The API is there for you. If someone wants to explore the statistical relationships between specific behaviors and specific disease states, using anonmyized access to the entire database, keyed on whatever selectors the researcher wants, the API supports this. If a researcher wants to try a completely different spin on how the database is organized, the sandbox environment (see below) plus the API makes that possible. Pharma studies in relation to FDA approved drugs should be a matter of public record and go into the database; individual panel members have access to their own participation in the study, and the public has anonymized access, enabling peer review in the context of a large global (or at least national) database.

Apple has taken a swing at the API side of this solution, but it relies on the usual suspects of proprietary database vendors including EPIC, Mayo Clinic, Medopad, Jawbone UP, and RunKeeper. Good job on the API… but unfortunately reliant on the confusion of Babel.

Who Gets To Define It?

Most of this universal approach can be standardized through tech groups that have a wealth of experience in consensus tech standards: IEEE, ANSI, etc… Sort of how the various standards work to enable anyone, anywhere to access the internet in an orderly and consistent way.

How To Make EHR Useful – Everyone Develop On Top Of The Same API

This EHR approach separates presentation and analysis away from the actual data model. The actual presentation, data analysis, and patient data input/output is built on the public side of the API, which acts as a firewall between apps and the actual database. This encourages developers to create user centric apps, the users being: patients, physicians, researchers, payers, pharma companies, public agencies, care centers, rehabs, etc… really anyone with an interest in what the information has to offer.

The key is to make the database and API non-proprietary, but allow entrepreneurs, individuals, big and small companies, and public entities to build on top of the API in whatever way they see fit, except that they can’t cross the firewall and claim ownership or control of the underlying data and API access methods.

The Sandbox

Sandboxing is another term that merits explanation. A software sandbox is a programming and application development environment that duplicates the entire underlying secure database and API in a way that is sterile, immunizing the working database from any damage or changes. Why would we want the public developer community to be able to create sandboxes? It’s a humble admission that the underlying elements of the database and API will have flaws, will have broken or troublesome utility, and must evolve over time. Because of the critical nature of an EHR, we don’t want people tinkering, either innocently or maliciously, with the live system. The sandbox allows developers (any developer) to have their own space to improve the system. Virtually all of the sandbox functionality can be 100% anonymized without compromising anything significant. Useful sandbox trials can be run through levels of standards committee reviews and slowly eased into the production environment.

A Really Small Set Of Rules

There’s rules for what goes into the database. Pharma studies remain proprietary until approved. At that point they become public. Providers must input patient data conforming to the requirements of the underlying database, but HOW they input that data is determined by whatever suite of apps they use. Apps can be proprietary, open source, free, paid, or whatever business model works best. The database even stores the IDs of the apps that sourced each tidbit of information, acting as a deterrent to apps with “bias.”

Rogues

The underlying database self-monitors, detects rogue apps and users, and is self healing. As example, Google does exactly this to ward off black hat search engine optimization attacks.

Credit Where Credit Is Due

Very little of this proposal is technically original. Various aspects (non-medical) have been implemented by quasi-public entities including Wikipedia, and private entities including Google, Facebook, Twitter, Amazon, Ebay, and others. I take heart that the technical hurdles have been largely dealt with, and done in ways that are robust and time tested.

This is not an expensive proposition. The database code and API are not particularly difficult to code. All the front facing (user side) apps are developed by open source contributors, entrepreneurs, and traditional industry players. Each have their own revenue models.

Ongoing operations are moderately expensive, specifically the large redundant server farms and the expense of ongoing security.

But There’s More!

Obviously, there’s much more to making this happen, and more pointedly: Who pays? Who regulates? How are special interest groups held at bay?  But it wouldn’t be fun without a few challenges!