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".
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.