Healthy Skepticism – My Critique of HealthKit as Both iOS Dev and Registered Nurse
Of the many new APIs announced at WWDC this summer, HealthKit has been particularly thought-provoking for me. At the risk of sounding like that guy, I think I have a somewhat priviledged perspective of HealthKit. There can’t be that many former registered nurses who’ve switched to iOS app development and tried to start a healthcare data company.
I’ve devoted the better part of the last four years to understanding the healthcare industry, both its current problems and its possible futures. Along the way I’ve learned many things – some hopeful, some downright depressing. I ought to describe how HealthKit looks from my vantage point.
Before jumping into HealthKit, let’s take a step back and look at the past and present state of healthcare information – what it is, where it’s stored, and how it’s transmitted and used. I’ll limit my description to the US since that is what I’m most familiar with.
Stacks of Paper
When I was a nurse, I worked in critical care. A typical patient at my hospital was brought in via ambulance or helicopter from an outlying urgent care facility. Though I worked at a hospital in Nashville, it was not uncommon for us to admit patients transferred to us from hospitals as far away as Kentucky. A transfer patient would be wheeled out of an ambulance and onto my ward by EMTs hired to ferry patients between hospitals. Tucked into the corner of the mattress, I’d find several fat manila envelopes filled with stacks of paper printouts from the outlying facility’s electronic health record system (EHR). There were so many pages it wasn’t possible to use them as a working reference. Instead, I primarily relied on the verbal report from the EMT to learn a patient’s past and present condition. It was only later, after our doctors had a chance to review the reams of paper printouts, that the full picture would begin to be revealed.
Though the transfer patient may have been in the outlying facility for days or weeks, as far as our EHR was concerned, today was Day Zero. Discontuity between caregivers’ records increases the likelihood of mistakes. Doctors and nurses go through a great deal of training in order to verbally communicate patient data as efficiently and safely as possible. This training helps us offset the risks of fractured medical records. Those stacks of paper became a supplementary reference, secondary to verbal reports. It would take a day or two before our own EHR would be populated with enough of that patient’s data to become a primary reference.
From Paper to EHRs
Until relatively recently, the vast majority of medical records in the US have been recorded on paper. From routine doctor visits to lengthy stays in critical care, every piece of data – lab results, medication orders, progress notes, etc. – were written or typed on paper and stored in massive warehouses. It wasn’t until the 1990s that electronic health records (EHRs) started to gain widespread traction. Doctors and hospitals were under no legal obligation to use EHRs, so the only providers to use them did so for organizational efficiency.
There have been numerous studies of the impact of EHRs on patient care, with mostly positive results. The consensus is that EHRs improve institutional logistics (billing accuracy, resource management, etc.) and help decrease medical errors, if sometimes at the expense of time spent at the bedside. They also contain latent possibilities for medical research and population health management – but only if most doctors and hospitals go fully paperless.
Though there are hundreds of EHR vendors, a mere handful of major players have dominated the market – companies like Epic, Cerner, Allscripts, and Meditech. Every vendor has its own unique software stack, from data storage to caregiver applications. There is no common database linking all these software products together. Every institution’s medical records are trapped within proprietary silos. Any interoperability with other EHRs has been made possible only on an ad hoc basis, at the whimsical discretion of EHR vendors and their customers. In practice, interoperability is virtually nonexistent. Patients are transferred between institutions with a stack of paper printouts, or nothing at all.
There are two main reasons why EHR interoperability hasn’t happened: it would be bad for business, and technical standards are lacking.
Interoperability Would Be Bad for Business
It’s disappointing but unsurprising that EHR vendors would keep medical data trapped inside their silos. If medical data were distributed via a shared database, their products would be reduced to either dumb pipes or thin client apps. Being a dumb pipe is bad for business. Selling thin clients isn’t a great option, either. EHR user interfaces are notorious for their terrible design. As a former registered nurse, I have plenty of interface design horror stories I could share with you. The reason these apps are so poorly designed is simple: they’re enterprise software. The customer is the hospital administrator, not the bedside nurse. The real money is in long-term, multi-million-dollar contracts with institutions who aren’t anyone else’s customers.
Interoperability isn’t in the interests of most healthcare providers, either. As a healthcare provider, you want the other institution to make it easy for you to see their data, so you can make your facility more efficient. But you have a neutral or negative interest in providing the same openness in return. Why would you invest in infrastructure that makes it easy for your patients to go somewhere else? Business models or legal requirements – or both – would have to change in order for EHR vendors and healthcare providers to be willing participants in a world of shared medical information.1
Interoperability Would Be Technically Challenging
There are technical obstacles to interoperability, too. Medical information is incredibly complex to model. It’s edge cases from top to bottom. Even something as simple as defining the possible values for a person’s gender raises difficult questions about biological versus preferred sex. Out of necessity, a number of protocols have been developed over the years that can encapsulate medical data in transit between subsystems within a given institution.
The most commonly used protocol is called HL7 – a gargantuan protocol with many variants. In the real world, no two institutions use the exact same implementation of HL7. Most systems in the US use one of the 2.x versions, which are pipe delimitted, prone to error, and not human-readable. Here’s a typical HL7 message for a lab result:
MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^ ^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520 OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730||||||||| 555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F
Yeah. Right. That’s a far cry from the tidy, readable JSON response from your garden-variety social media API.
There is a newer 3.x series of HL7 that is based on XML, but few EHRs in the US are actually using it. Thus the 2.x sample above is the current state-of-the-art of medical data exchange. Since HL7 2.x is pipe-delimitted, it is easy for implementers to insert data between the wrong pipes, breaking the already weak links between EHR subsystems. This happens so frequently that an entire industry exists just to solve this problem.
The deeper problem with HL7, in my opinion, is that it isn’t designed for persistence. It’s a means to encode ephemeral messages. The actual work of when and how to send messages, and where to store their contents, is left up to each EHR vendor. Linking together EHRs from two different vendors would be an enormous engineering task. A shared repository of private medical records would need something much more readable and resilient than HL7. It would need to look more like the JSON messages used by modern, RESTful web APIs.
HITECH and Meaningful Use
Earlier in this post I wrote that EHRs didn’t begin to gain widespread traction until the 1990s. This was an overstatement of the facts. The reality of EHR usage is that – even as late as 2009 – fifty percent of US hospitals were only only halfway electronic. Most just converted the easy stuff to electronic records, like lab results. Less than one percent (!) of them had completely moved beyond paper records. Many still had no electronic records at all.
The 2009 ARRA act passed by the US Congress included a landmark set of reforms aimed to drag US medical institutions kicking and screaming into the 21st Century – or at least the 20th. Not to be confused with the “Obamacare” reforms, the HITECH Act obligated US healthcare providers to demonstrate “meaningful use” of electronic health records. Meaningful Use, as the program has come to be called, ties Medicare reimbursements to EHR usage. A series of requirements, broken up into stages, will be rolled out over the next decade. Each successive stage unveils more stringent rules. Institutions that meet or exceed the current criteria in a timely fashion will earn bonuses on their Medicare reimbursements. Institutions that don’t will face penalties. Medicare reimbursements are bread-and-butter for healthcare providers, so there is strong motivation to keep up with the demands made by Meaningful Use.
The Meaningful Use criteria are still being defined, but the ones that have already been put into play are praiseworthy. Institutions must be able to electronically transmit a Continuity of Care Document (CCD) upon demand. A CCD is a brief summary of a patient’s past and present medical conditions. This requirement is aimed to solve the “stacks of paper” problem above. The CCD is a glorified PDF, but it’s the next best thing to having truly interoperable EHRs. Other Meaningful Use requirements are aimed at improving patient safety by requiring barcode scanning before administering drugs (BCMA), or requiring doctors to use specially-designed software to write orders instead of pen and paper (CPOE).
The most intriguing part of Meaningful Use is that it places the burden of proof on medical care providers, not EHR vendors. It’s up to each institution to select an EHR that supports Meaningful Use criteria. EHR vendors are in a mad rush to update all their products to meet the minimum requirements in time.
It is not yet known if Meaningful Use will ever require true interoperability between EHRs. If that happens, I would be extremely pleased, as a software developer, a former nurse, and a patient. With congressional lobbying being what it is in the US, I doubt EHR vendors or healthcare providers will ever let true interoperability become a legal obligation.
The False Promise of HealthKit
To a layperson, the introduction of HealthKit at WWDC looks like Apple might hope to provide the foundation for a future of shared medical data. The example use cases looked pretty cool at a glance. According to Apple, your doctor could conceivably have easy access to vital signs obtained by a Withings blood pressure cuff connected to your iPhone. The list of HealthKit partners, like the Mayo Clinic and Epic Systems, was particularly impressive. But I don’t think either HealthKit or Apple is in a strategic position to escape the forces that keep our medical data trapped in the status quo.
The first problem with HealthKit is that it can only model a tiny fraction of the spectrum of medical data. There is a very long list of things it can’t do: track medication doses, doctor’s orders, procedural notes, etc. But let’s assume for sake of argument that HealthKit eventually ships with model classes for every conceivable type of medical data. It still wouldn’t be able to bring about EHR interoperability.
As I discussed above, interoperability is technically challenging no matter who attempts it. Apple clearly has the capacity to tackle the technical issues if it really wanted to. The central problem for interoperability is one of motivation. Who has the power to compel all the hospitals and EHR vendors in the US to open up read/write access to their medical records?
In my estimation, there are only two entities capable of doing so. The first and obvious one is the government. If Meaningful Use ever mandates one-hundred-percent interoperability, then the industry would have no choice but to comply.
The second entity would be a for-profit company that offers healthcare providers a mutually-benefical partnership. This company would compel hospitals to allow them access, but with a carrot instead of a stick. If there was a way that hospitals could benefit from partnering with an open EHR framework, then they might happily allow their siloed data to flow freely between competing institutions.
Unless I am misjudging Apple’s intentions, HealthKit looks like it’s another way to keep high-end customers loyal to the iPhone and other Apple products. As such, it’s against Apple’s interests to make HealthKit available on competing platforms like Android or Windows. But for stored medical data to be of any significant use to healthcare providers, it can’t be limited to just A) patients who own iPhones and use HealthKit apps and B) providers with EHRs configured to access those apps. It’s unreasonable to expect that either healthcare providers or EHR vendors would devote limited engineering resources for the sake of a handful of patients, especially when the laundry list for pending Meaningful Use requirements is still so long.2
In practice, I expect HealthKit will have little or no impact on professional healthcare delivery.3 I think the experimental partnerships between Apple and the companies listed during the WWDC Keynote will remain exactly that: experimental. It will take a lot more than HealthKit to make a dent in the universe of healthcare.