This critique appears to be projecting its author's desire for a solution to the EHR compatibility problem on to Apple. I haven't seen anything from Apple indicating that HealthKit is the answer to this problem.
HealthKit provides a way for iOS devices to integrate health-related device data for use by the iOS device owner, no more, no less.
Apple have not been shy about implying they think it'll be "really big" and have an impact on the actual healthcare system.
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.
I can't believe you're getting downvoted for this. Apple is the one playing at having a "solution" to this problem, and they have been from the moment they showed Epic MyChart in the keynote.
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.
Yes, and this time there is no Steve Jobs to drive a hard bargain.
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.
The only "playing nice" that needs to happen is that Apple needs to keep the HealthKit API around. If an EHR company has an iOS app, they use the HealthKit APIs and they're off to the races.
> HealthKit provides a way for iOS devices to integrate health-related device data for use by the iOS device owner, no more, no less.
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.
I think this is Apple's play into medical devices without having to go through the expensive process of starting through the FDA or messing with these backwards EHR companies. They start consumer and then physical trainers start using iPads and iPhones because they work well for consumers devices. Work up to doctors that pressure the FDA into relaxing regulations to allow them to use Apple devices. The exact same thing happened recently in the airline industry. Apple wins consumer confidence then customized expensive medical apps follow that run on that same hardware. And Apple takes a 30% cut of those sales without having to certify any software, throws the responsibility to the app devs.
I agree. Apple did refer to major healthcare partners but my impression was that this was just to enable users to share fitness and personal monitoring data with their healthcare providers (which the healthcare provider could then add to the EHR). I saw no suggestion that Apple were aiming to attack the professional/enterprise EHR market.
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.
I'm sure Apple is aware of the mess of regulations they would encounter if they advertised the Health app and HealthKit to be a hub for all of your medical data. Not only would the connections between your iDevice and a hospital potentially fall under scrutiny by a variety of health-related state and federal agencies, but the complete iOS to iCloud connection and what it sends and receives would probably start getting heavy analysis and would need to prove to bureaucracies precisely what Apple and third party vendors do and do not transmit.
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.
If Healthkit actually aspires to be just one more silo, you can stop right there and say it's already part of the problem.
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.
> 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.
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!
HL7 is an abomination, and everyone involved in getting it into place and standardizing on a transport format and not a data or semantic layout should be punched in the face.
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
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.
The way I understand HealthKit, it is EHR agnostic. Apple doesn't really want to directly compete in health-care. It's a mess, and it would be incredibly defocusing for them, and frankly, the upside just isn't there. What they want is for other companies to do the leg work and take on the regulatory risk by going through any relevant certifications and clinical trials. They simply want them to use iOS as a platform.
That's kind of my thought on this. Thanks to my FitBit I have a log of most things I ate, how much I excersized, and how much I weighted going back over a year. It's not perfectly accurate (forgetting to weigh in, choosing to slack off on food entry, forgetting my FitBit) but it's a hell of a lot better than I would do otherwise.
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.
> Just gathering sensor data and showing it to your doctor at your next visit could be extremely useful, even with zero EHR integration.
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.
After looking further at HealthKit I agree it solves the dashboard, and sensor calculation methods (to the extent of supported hardware types).
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".
Having worked for an EHR company at one point, the author misses the main reasons for a lack of interoperability: government regulations regarding "meaningful use" that allow physicians and hospital systems to receive financial incentives to offset the costs of the software. The regulations have been ill-defined and incredibly slow in being released.
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.
Having just started work at an EHR company, it is absolutely mind bogging how much more complicated the regulations make the business.
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
Nice! I'm an athenahealth developer in the atlanta office (well... alpharetta, but soon to be atlanta). While I love it here, I can confirm that the Austin office is the best. We sometimes watch your scotch friday meetings, and Jack comes to our neck of the woods for a "scotch tuesday/wednesday" every so often.
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.
I applied for a job with athenahealth in Boston many years ago, but sadly didn't make the cut then. It sounded like a fantastic place to work, where you could make a difference in people's health as well as make good money.
>Having worked for an EHR company at one point, the author misses the main reasons for a lack of interoperability: government regulations regarding "meaningful use" that allow physicians and hospital systems to receive financial incentives to offset the costs of the software.
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 tied to the regulations that also govern the glacially-developing interoperability standards, and is only achieved through certification.
"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.
I don't get the critique. The real value of something like HealthKit is that you have a convenient and potentially cool way to engage more meaningfully with your primary care doctor. Here's my pills, blood pressure over time, etc.
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.
Apple has a LOT of customers and might have enough power to move the needle some.
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.
In the US, at least, there is a legal requirement for them to interface with their competition. That's what HIEs are supposed to be for. Whether they actually meet that requirement is another story, of course.
This critique completely misses the boat. The author explains why HealthKit will likely never share data from an EHR via some sort of HIE. She's right, and that's not the point. Doctors (usually) do not trust health data collected by a patient, patients however are interested in collecting data for themselves. Look at this through the eyes of someone with a chronic disease like T1D or cancer. The more studious among us collect reams of data for our own comfort and understanding, occasionally it is useful to a doctor.
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.
> The author explains why HealthKit will likely never share data from an EHR via some sort of HIE. She's right,....
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.
Although the relation to HealthKit was somewhat tangential, this post did an excellent job of relaying the status of and problems with digitized healthcare. HL7 is absolutely horrendous, and Meaningful Use has no interoperability requirements and weak prospects for getting good ones.
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.
you completely missed the point of HealthKit and what Apple is touting it as and the capabilities your expecting it to pull out of thin air, it's primarily an app that lets you pull in data from multiple fitness devices with limited EHR integration capability as a bonus, what you are expecting is a whole different business
A point the article misses is that many people would use the features offered in HealthKit for preventive purposes and tracking fitness levels, more so than sharing with their providers.
Personally I'd be more interested in monitoring my health so I can stay out of the hospital or doctors office if possible.
There are a few aspects of this and I can only talk from the point of view in healthcare in the UK.
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.
Maybe I'm being naive, but the whole problem of how to model medical data isn't to design your system to do fine grained scheme of every possible problem, I'd think it may be better to find the minimum amount of schema that can define things - i.e. a few tags describing whether it's a lab value, order, medication, etc, and then a plaintext data store. Interpretation could then be passed onto specific clients based on the tags?
I guess there is something to this, as right now all EHR information ends up processed by human beings in the end (?) so there is no need for an overly complicated "type system". Still, a schema for prescription drugs would bring automated interactions detection, for instance.
HealthKit is about quantified self. Aggregating data from services like runkeeper, garmin, mapmyfitness, nike+, withings, myfitnesspal, fitbit, jawbone and all the others. Apple is also clever in the way that they release this api first, making all these provides use their api first, before they release their own iWatch which likekly will have sensors to contribute to healthkit.
Very good article. I don't know what the aspirations of Health Kit truly are, but I would not underestimate Apple. They changed the phone/mobile operator relationship. And similar arguments were made about the enterprise ( too complex, not enough management tools with iOS). But Apple finds a way to get consumers to change the dynamic in a way other companies don't.
well it needs top be appreciated here that Apple has gone ahead with developing such an app. it would certainly help doctors and patients to keep track and pace
HealthKit provides a way for iOS devices to integrate health-related device data for use by the iOS device owner, no more, no less.