
My Critique of HealthKit as Both iOS Dev and Registered Nurse - zdw
http://blog.jaredsinclair.com/post/89292422325/healthy-skepticism-my-critique-of-healthkit-as-both
======
byteCoder
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.

~~~
XorNot
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.

~~~
tl
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.

~~~
meric
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.

------
chimeracoder
> 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!

~~~
angersock
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.

------
abalone
_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.

~~~
draker
> 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.

~~~
abalone
You should really take a look at HealthKit. It solves all of the problems you
list under #1. I.e. It has a standard simple dashboard for health data.

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

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

[http://www.healthaffairs.org/healthpolicybriefs/brief.php?br...](http://www.healthaffairs.org/healthpolicybriefs/brief.php?brief_id=26)

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.

~~~
ndonnellan
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

\- [http://www.athenahealth.com/cmp/more-disruption/more-
disrupt...](http://www.athenahealth.com/cmp/more-disruption/more-
disruption.php)

\-
[http://www.forbes.com/sites/zinamoukheiber/2014/06/19/a-hand...](http://www.forbes.com/sites/zinamoukheiber/2014/06/19/a-handful-
of-doctors-are-top-users-of-electronic-health-records-and-most-are-
athenahealth-clients/)

~~~
frogstomp19
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.

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

------
jamra
The issue with HL7 is absolutely correct. There are lots of solutions to this
problem. My favorite is
[http://www.interfaceware.com/iguana.html](http://www.interfaceware.com/iguana.html)

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.

~~~
MBCook
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.

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

~~~
x0054
> 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.

~~~
TazeTSchnitzel
Their avatar suggests they are male, too.

~~~
pdpi
"At the risk of sounding like that guy" kind of gives it away ;)

------
Tloewald
Healthkit fails to solve problems it was not intended to solve. Fixing health
records is a political problem more than a technical problem.

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

------
flylib
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

~~~
canadev
From the footnotes:

"The personal fitness industry is another story, however. HealthKit is an
excellent, well, fit there."

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

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

[1]
[http://www.hl7.org/implement/standards/fhir/](http://www.hl7.org/implement/standards/fhir/)

[2]
[https://github.com/KingsCollegeHospital/rassyeyanie](https://github.com/KingsCollegeHospital/rassyeyanie)

------
caycep
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?

~~~
roma1n
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.

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

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

------
mellisarob
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

------
waterfowl
Misread this as "Heathkit" and felt old.

