My Critique of HealthKit as Both iOS Dev and Registered Nurse
blog.jaredsinclair.com
blog.jaredsinclair.com
HealthKit provides a way for iOS devices to integrate health-related device data for use by the iOS device owner, no more, no less.
This author is pointing the myriad of actual reasons why "your personal medical data" is stunningly uninteresting to healthcare providers and not at all a simple problem to solve.
The reality is that HealthKit is going to be a victim of Apple's inability to play nicely with others, in addition to its other technical limitations also described in the post. However, Apple has positioned it so that when it does flop, they can play off as the big bad medical industry refusing to embrace change.
EDIT: This is not snark. It's an observation. Recall last time with iTunes Steve Jobs managed to get all the music industry players on board even though the deal wasn't in their favor. I doubt Apple will be able to achieve the same in the health industry without Steve Jobs at the helm.
I don't know if there could be a progressive expansion of capability and then an attack on the EHR market but Apple hasn't signalled that and it isn't currently intended for that.
There be bureaucratic dragons.
Agreed with the other commenters here, although I do appreciate the original blog post for pointing out concrete examples of backwards technology use in health care. It is a good reminder that pretty much every industry (perhaps outside of tech companies with tech customers interoperating with each other) has major dysfunction and underutilization of current technologies.
Perhaps he didn't state this so explicitly, but the subtext in his post is that that he believes HealthKit not going to have an impact on care delivery without EHR integration.
He did mention this, albeit towards the end:
> In practice, I expect HealthKit will have little or no impact on professional healthcare delivery.
There are a lot of interesting things that can be done in the world of health-tech that don't qualify as "healthcare delivery". On the other hand, most of the parts that people talk about "disrupting" do. Care delivery tends to be the most expensive (though also the highest yield, dollar-for-dollar) component of health.
You remember the scenario the author sketches out - a critical care patient arrives and you're handed a packet and given a verbal description. Now someone is saying some more crucial information is just lurking on the patient's iPhone? Yeah, either you waste crucial minutes finding that or that info is lost (most likely). Thanks Apple.
This understates how awful HL7 is. It's true that it's a non-standard "standard" (the only common thing about it between implementations is the name). Many implementations are both pipe-delimited and fixed-width, which makes generating a valid HL7 message for a single client absolute hell. Multiple clients? You might as well start from scratch each time. (And people wonder why innovation in health tech is so slow...).
I remember one brainstorming meeting I had with the CIO of a major, reputable hospital. I casually made some reference to setting up a webserver to receive HTTPS requests. I will never forget his expression. He sheepishly informed me that no, they can't use HTTP (even with SSL). Instead, the process involves creating a dedicated tunnel, setting up a tcp connection within the tunnel, and then reading each "chunk" of data off the wire. Each datum comprises a variable number of packets[0], so you essentially have to buffer the stream manually so you can virtually "push" packets back on the stream if it turns out you weren't supposed to read them.[1]
This is not a dig at the CIO; he clearly knew what he was doing. Unfortunately, he also knew the state of the systems he had to maintain internally, as well as the external ones he had to interoperate with, and the realities of what was feasible and what was not.
[0] If you're having trouble picturing what I'm saying, imagine you're in a foreign city and ask someone which bus stop you need to get off at. He responds, "Watch which stop I get off at, and you want the one four stops before that"
[1] Now imagine doing this with broken Unicode implementations!
That's really not true. Just gathering sensor data and showing it to your doctor at your next visit could be extremely useful, even with zero EHR integration.
If some healthcare providers have apps that serve as an API into their backend EHR system, that's a bonus. But it's super-useful just for a doctor to be able to look a hyper-detailed health log book that patients bring with them.
I can see, objectively, if I seem to be getting more or less exercise, or if I'm gaining or losing weight. Having every measurement of someone's glucose if they are diabetic has got to be very useful.
Not everyone will keep records, not everyone who does will use it. But in the cases where someone does it seems like it should be beneficial in more than a few cases.
I disagree. The two problems with this would be primarily from the doctor's perspective.
1. Doctor arrives to exam room, "Doc I have been using XYZ app, take a look at this data."
- Doctor has to figure out interface if s/he hasn't used before.
- Has to locate the meaningful data in this "hyper-detailed log book" and interpret.
- Doctor has to assess whether this information is valid; does this app use proper calculation methods (algorithms, formulas, significant digits) and are the sensors accurate.
- Doctor has to adjust schedule to account for time to interpret this new data, as s/he has no ability to review prior.
2. Assuming no problems with the first point. Doctor has this data and identifies a trend, let's say high blood pressure. Doctor prescribes medication and sends you on your way. The doctor has a huge liability as a medication has been prescribed and there is no documentation of the data used to make the diagnosis. If there is an adverse reaction and a malpractice suit is filed, the burden of proof is on the physician.
The physician review of this data would still take time from the visit. While this can be corrected with changes to the consultation procedure, that in itself has side-effects (longer consultation -> fewer appointments/day -> longer time until next available appointment && increased cost).
If the API integrates with the EHR backend and the doctor can receive this data prior to your appointment and have this data stored in the EHR then these problems are mitigated. Though, these issues still stand, "with zero EHR integration".
http://www.healthaffairs.org/healthpolicybriefs/brief.php?br...
This page gives some background to the issues but basically, the federal government has held the process up, while many companies are champing at the bit to make a lot of money regardless of interoperability which everyone agrees will be a good thing.
This is not necessarily a criticism: I wouldn't expect a nurse/iOS dev to be familiar with the regulatory background governing EHR standards. It's unfortunate that they definitively lay the blame on profit motives or technical challenge. No offense to the author but there are some very intelligent people who have been working on this problem for some time.
Shameless plug: said company is athenahealth and we're hiring in Austin (and also other places, but this office is the best), and we've also got a budding API program looking for startups to interact with. Email me at my HN username at athenahealth.com
- http://www.athenahealth.com/cmp/more-disruption/more-disrupt...
- http://www.forbes.com/sites/zinamoukheiber/2014/06/19/a-hand...
In more relevant news, the CEO (Jonathan Bush) just wrote a book ("wrote", he joked) that's a semi-right-wing take on the problem posed in this article (lack of EHR interoperability). Solid read though regardless of politics.
Also, the MDP program (the API you're referring to) is more designed to allow third party developers to build functionality onto athenanet that we don't have the specialization or capacity to build. It's not really a means of sharing health data (to my knowledge). However! We have been making the sharing of EHR data a priority, or at least seeming to, with the formation of the CommonWell Health Alliance (members including most major EHR creators... except Epic, because they're Epic). Additionally, we're working on some stuff with athenaCommunicator to help hospitals talk to labs, and stuff with Coordinator that I think involves the Austin crew too... but I don't know what of Coordinator we're allowed to talk about yet so I'll probably shut up on that matter.
Ha! "Meaningful Use" is not the reason for lack of interoperability. The lack of interoperability existed before "Meaningful Use". My pet theory: The individual companies don't really want it. Oh sure, at conferences and trade-shows everybody says the right things, but in their heart of hearts, they want to be firmly in control of data in order to make it as painful as possible for the customer (i.e. hospital) to move away from them, or even integrate a competing product.
"Meaningful Use" is tied to the regulations that also govern the glacially-developing interoperability standards, and is only achieved through certification. What "meaningful use" actually means is still not very well defined from what I know (I'm now in the financial industry so I haven't kept abreast of the current state of EHR regs.) So even if the industry settled on a standard themselves, they can't be sure adopting it or the non-existent government decreed standards would meet certification even for meaningful use. And meaningful use and interoperability are the result of HIPAA from 1996.
Doctors and hospital systems are hesitant to adopt any EHR solution because they will receive huge subsidies from the federal government in the form of tax-breaks as long as they are using a certified solution, which is the only way many smaller practices will be able to afford adopting EHR systems. There is a lot of uncertainty around committing to an EHR solution because the practitioners can't be convinced that the EHR systems will meet cert, so they're dragging their feet, which really retards the growth and revenue of the industry.
I think if there was a standard for interoperability that everyone knew would meet cert (which ties into "meaningful use"), we wouldn't be having most of this conversation.
"Meaningful Use" is largely agnostic to the underlying standards. It rewards (or punishes) outcomes but its aim is to increase electronic patient record usage.
>So even if the industry settled on a standard themselves, they can't be sure adopting it or the non-existent government decreed standards would meet certification even for meaningful use.
That's not really an issue. The standards are the way they are because there are no dominant players that can push through a standard unilaterally, and as I've said, the big players just don't care enough about standards outside of marketing, and they downright hate them if it means an easier time for a competitor to supplant them on-site. The interoperability mess is not due to MU in any 'meaningful' way. It was there before MU, it's there today, and it'll be there after MU.
Integration with EHR in any way doesn't make sense, because you don't choose your doctor based on the software stack they are using -- it's based on perception of quality and whether the practice is in your insurance network. Google tried to take that route, and that product faded away quickly.
The situation described in the critical care world is more likely to be "improved" (from a consistency standpoint) by the waves of medical consolidation being driven by Obamacare (which drive outpatient and primary care), cuts to Medicare reimbursement (making hospital operations less lucrative), and Medicaid moving to a managed care model. (again, less hospital)
IMO, if you want to make sure that YOU get good care, keep a clueful relative with you when you get sick.
The issue with a truly shared electronic medical record is hugely important. Apple is trying to give the user the ability to have their medical issues listed so that they can receive proper care in the case of emergency.
I believe that Apple intends to integrate with devices that record health information. The problem that the author brings up is how to integrate this into the systems that hospitals are currently using to provide patient care based on the app's data. In other words, how can this data be transferred to the healthcare provider?
I believe that no third party solution can be implemented due to the fact that the largest EMR systems don't want to interface with their competition.
Could this end up like the iPhone in the enterprise? Maybe no healthcare company wants to work with iPhones, but their customers (doctors/hospitals) may push to get integration. There is also plenty of PR/political incentive to at least look like you're trying to improve things and demonstrably working with Apple (even though it's a limited circumstance/benefit compared to true EMRs) may bring positive side-effects.
Let's put it this way: Apple will get customers to use their software, and even if it just ends up aggregating a few FitBit like devices that could be good for the consumer (ease of use).
Apple may be able to leverage that to improve healthcare or at least get some good PR (and push the Cerners of the world) trying.
Apple could not make a difference by just trying to make a new EMR system and enter that market directly.
Apple won't make things worse. Seems to me that worst case with HealthBook is that it ends up like Passbook and is useful to a few people but otherwise ignored.
When my daughter had cancer, the doctors didn't come to me for the results of her last CBC, they looked in their own computer. No doctor would have trusted my interpretation or recollection a CBC anyway. My wife and I did track those numbers very closely, and we did so that we could make day to day quality of life choices for our daughter. These choices usually did not involve a doctor.
Oddly enough there was a kind of data that originated from us that the doctors did rely upon. When you're dealing with a disease that has a 30% (or less) survival rate it's unsettling how often you hear a doctor say "we've never seen that happen before", especially when you are hearing it from the top doc in the country for that disease. During our multi-month hospital stays my wife and I traded off in shifts collecting information at 15 minute intervals of everything that went on with our daughter in the hospital room. Often times the situation was very dynamic and the nurse was obviously not standing at the bed side 24/7, and the doctors usually did rounds only once a day. Additionally the nurse's acute care flow sheet only tracks a handful of very specific data points. What we discovered was that while the doctors took oral anecdotes with a grain of salt, when they saw I had written notes they got into the habit of simply asking for my notes and then wrote down what they needed and then our discussion of her state began from there.
I apologize for the messy stream of consciousness here. While I'm not a health care professional I've invested a considerable amount of time learning the inside of hospitals, and I've also built a handful of software products for the healthcare industry including a proprietary HIE. If I learned anything from those experiences it's that there is data the doctors want, and there is data the patients want, and they don't always overlap and they don't always trust each other. If there's going to be a revolution in patients taking ownership for their health information, care plan, etc... it's going to start with the patients collecting the data for themselves through various devices and manual means and it will not be the results of scans, labs (or imagine this... HIV test results) being streamed to the patient's phone from the hospitals EHR.
I might be wrong, but I do believe the author, Jared Sinclair, is a guy. It's funny how we see "nurse" and we instantly think "girl." I thought that too. But than I thought "programer=guy, but nurse=girl, does not compute!" So I checked the name on the article. I don't mean to critique, as those who live in glass houses should not throw stones. Just found it interesting how ingrained those stereotypes are.
I think the Continuity of Care Document (CCD), though, is a bigger deal than he realizes. The View Download Transmit (VDT) requirement that requires the CCD is, in practice, making a HL7 3.x XML document available electronically. This opens a great opportunity to build real interoperability between EHRs.
Shameless plug: PicnicHealth (picnichealth.com) is working on taking advantage of precisely this opportunity. We're rolling out our alpha product. If you're interesting in what we're doing please reach out.
"The personal fitness industry is another story, however. HealthKit is an excellent, well, fit there."
In the care settings Apple has been able to pull at the hearts and minds of care providers and I’ve seen a pull from doctors about making use of apple hardware (and software) whether it has a use/or is a supported platform.
If Apple went for the care settings market they could very easily disrupt the incumbents (in the same way that they did with portable media and the mobile phone) because it quite frankly isn’t that hard. There are many examples of a technically superior product [0] gaining market share in a short period in healthcare and a technology company could easily do that.
However in practice I’m pretty sure that EHR (and care records in general) are going to move to a patient owned model. This would probably mean some provider outside actually owning and storing the data but patients being mindful of their right to have access to general data (not only have access to but act on).
Things that patients could quite easily take from the care settings and make good use of are blood work, actual infection names (most infections result in antibiotics prescribed without the patient being told which organism it is), height/weight, all of their vital signs etc.
In terms of HL7 v2 — it’s not ideal however it is super lightweight — XML (i.e. HL7 v3) is not a good fit for high throughput transactional data (outside of healthcare see BSON, protobufs etc.) HL7 v2 largely suffers from issues around interpretation. There’s a great initiative called FIHR [1] which could help a lot when it comes to CCD.
Kings College Hospital have opened up their HIE [2] which uses a few off the shelve open source components to make working with HL7 very easy.
[0] EMIS/INPS vs TPP in the UK comes to mind. The TPP product pushed EMIS (and more recently INPS) to really up their game.