
The most important API you’ve never heard of - gdeglin
http://rockhealth.com/2015/03/important-api-youve-never-heard/
======
floatrock
ah HL7.

> I hope you like XML documents, flat files, pipes and hats, SOAP, and even
> CORBA.

Completely true. But that's not really the problem. You can download an HL7 or
XML-parsing library and the dirtiness of the representation is converted to
JSON or whatever works for you.

The problem is API loopholes.

HL7 does a pretty fair job defining what concepts get put into which fields.
However, many implementations ignore the computer-readable fields and
literally dump everything as 80-character human-readable console outputs in
the "custom text" fields. Want any structured data? You're gonna have to write
a text parser specific to the hospital's legacy console systems.

There's also a good deal of standardization over how things SHOULD be
presented (ICD-9 etc), but those are ignored. Often times physicians or
pharmacists just type the drug into a free-text box. 5 different spellings of
Ampicillin are the least of your worries -- it gets bad when the dosage is
mixed in with the name, and it gets worse once you get into compounds or
mixes. The standard isn't the problem, its the data mapping problem for all
the human-inputs.

And then you get into fun stuff where billing people use different codes than
everyone else for the same drugs, procedures, admissions, etc (there's a
reason billing admins are so highly paid... it's a black art where you get
creative how you describe things to the insurance companies).

All of this is to say that I would love to see a RESTful, well-modelled API
over HL7 messages, but the problems go far deeper than the protocol spec (and
that's just for technical side of things... the politics and business threats
of open APIs that the article talks about are completely true as well). It's
been a couple of years since I've been in the space and not at all familiar
with these new FHIR specs, but I wish that process all the best. If you're
looking for a real challenge, it's not picking up Clojure or whatever is the
language du jour... a true challenge is doing anything in healthcare.

~~~
JonathonW
The data mapping problem's what we're running into as well, and we're just
trying to consume a tiny fraction of what's in the EMR for a patient
(specifically, we're trying to get medication data into the backend for a
service that does some pretty neat patient-specific stuff based on that data).

The service we're interacting with has all the structure we need, but doctors
and nurses aren't data entry specialists: for the most part, they seem to
ignore all the structured fields that they're given and encode all the
information ("Ampicillin 5mg three times daily") as free text in the
medication's "Description" field.

The problem's not in the protocol spec here (at least, not for our
application). The problem's more a human factors issue-- how do you get the
clinics' staff to provide you with the clean, structured data that you
actually need? Needs to be something that's lower-impedance than just entering
a prescription as plain-text (or they'll continue to circumvent your system),
and it needs to require minimal retraining or you're going to get push-back
from the staff who are expected to use it.

~~~
gearhart
If convincing people to use a more structured UI is difficult but they're
quite happy giving you all the information you need in their own way, why not
just accept the data in the format that they want to give it to you in? It
seems like a pretty simple NLP problem - you've got a known set of drug names
and contractions, a set of timing intervals and a set of dosages. If they're
not bothering to provide some of that information that might be an issue
(depending on how well you can rigorously determine and encode the context-
specific assumptions that they're making), but if they are providing it all to
you like that then parsing your clean data out of the text can be done with
extremely high accuracy. Potentially higher than the accuracy of a doctor
picking from a set of dropdowns, before anyone says "extremely high isn't good
enough for healthcare".

I'm sure it's an avenue you've explored - what's been the major challenge?

~~~
beat
"It seems like a pretty simple problem" is why the startup community makes
more or less zero headway against enterprise problems.

~~~
gearhart
It's a statement that comes from knowing a lot about the tools and not a lot
about the area in which you're applying them. That applies to a lot of
startups, rarely the successful ones, and in this instance it certainly
applies to me, and probably most of the readers of this thread.

The purpose of the comment is to offer up the strawman solution so that we can
hear more about the interesting part of the problem that means it isn't
trivial.

------
perturbation
See also (edit: just noticed that they include some of these links at the end
of the article):
[http://docs.smartplatforms.org/](http://docs.smartplatforms.org/)

SMART on FHIR builds on top of FHIR for cross-EHR applications. In their words
([http://smartplatforms.org/for-developers/](http://smartplatforms.org/for-
developers/)):

"SMART on FHIR takes advantage of a new and powerful set of health data
standards called Fast Healthcare Interoperability Resources, or FHIR. By using
HL7’s FHIR for the clinical data layer, SMART offers a standards-based
platform with broad reach, a rich set of detailed models, and the opportunity
to create population-level as well as patient-level apps. SMART on FHIR also
uses an updated set of authorization and authentication standards including
OAuth2 and OpenID Connect."

and

[http://jamesagnew.github.io/hapi-fhir/](http://jamesagnew.github.io/hapi-
fhir/)

(extension to the HL7 Java API "Hapi" which deals with FHIR and is (IMO) one
of the more full-featured implementations of FHIR)

Disclaimer: I used to work for a major EHR company but no longer do so.

~~~
JoshMandel
Just wanted to chime in here -- I'm the architect for SMART Platforms and
happy to answer any questions. Over the past five years I've gotten much more
deeply involved the healthcare standards development world than I ever would
have imagined. I came at this space from the perspective of wanting to build
applications that plug into real-world systems, but in some ways I've been
digging lower and lower down the stack trying to lay firm groundwork. There's
constant tension between laying groundwork and trying to get "real" work done.

~~~
perturbation
Do you think that there's any chance of getting interop via FHIR (with or
without SMART) as a condition of winning the DHMSM deal? My impression
(rightly or wrongly) is that a lot of vendors are doing a lip service/wait-
and-see approach to FHIR and truly opening up.

~~~
JoshMandel
I'd like to hope so. I think we've seen this kind of interaction play out on a
much smaller scale in the commercial world, and we're seeing more of it. For
example, when Intermountain Healthcare selected a Cerner EHR, they did so as
part of a multi-year partnership [1], under the condition that Cerner would
provide open interfaces to their EHR data so that Intermountain could continue
developing (and begin porting their existing) home-grown decision support
tools. Part of the arrangement was an innovation fund to support development
of the specifications needed. And I think that's actually a great pattern,
since we certainly won't have all the answers right out of the gate. With
respect to DHMSM, the timeline is long enough that it's very hard to name
relevant technologies on the way in, without the concern that they'll be out
of date (or at least out of fashion) by the time implementation hits.

1\.
[http://www.cerner.com/Intermountain_and_Cerner_announce_stra...](http://www.cerner.com/Intermountain_and_Cerner_announce_strategic_partnership/)

------
jbob2000
The one big problem I see with healthcare information is red tape. Independent
developers and small shops do not have the resources to deal with lots of red
tape. We saw with the recent VAT changes in Europe that it's really hard for
anyone who isn't an enterprise company to deal with lots of regulation.

Before we start talking APIs, I want to know the hoops I'm going to have to
jump through before I even git init.

~~~
markolschesky
I wrote up a project plan that details the players and some of the steps to
get HL7 data through the traditional integration methods that exist today.
Check it out: [https://catalyze.io/learn/how-to-integrate-with-epic-or-
any-...](https://catalyze.io/learn/how-to-integrate-with-epic-or-any-ehr)

I think FHIR only helps this process if it standardizes/centralizes security.
So much of the process of setting up integration is getting whitelisted by an
organization and setting up VPNs and other security measures that have nothing
to do with HL7 or FHIR or IHE profiles. If startups have to establish
credibility and integrity at each hospital they go to, the cycle will continue
even with a public API.

------
seanwoods
The problem in healthcare is humans and organizations, not software. There is
no will to conform to standards and foster interoperability.

You can rant about it all you want, but that's the reality. The status quo
exists for a reason.

~~~
gmarx
Except a huge reason they refuse to conform to standards is because you are
asking them to do a lot of extra work for no extra pay. The EMR systems, by
and large, are not good. The user interfaces do not make it easy to conform to
standards. It is not reasonable to expect docs to do it under those
circumstances.

~~~
seanwoods
When I say "they" I don't mean the doctors, I mean the hospital
administration. They operate on a different set of incentives and motivating
factors. The doctors are usually not involved in the process in a very
substantive way. It's this fundamental disconnect, which is so common in
enterprise software, that's brought us to where we are today.

I know people on HN have fire in their breast to change the world but the rock
is harder to move then many think. I tried to do it for almost 5 years and
didn't get very far.

~~~
knightofmars
You need to motivate them where it counts, the almighty $. I want to add I'm
not saying this sarcastically at all. The motivation of hospital
administration comes down to a bunch of numbers on paper. If you can _prove_
that they will have _significant_ gains by implementing one of these standards
they will move. However, most of them have been around long enough to see the
standards come and go and are aware that HL7v2 is still in use 99% of the
time. To them it is truly a case of, "If it ain't broke, don't waste the money
fixing it." My hope is that FHIR and its approach to solving the problem of a
bloated unwieldy standard with extensions will gain ground. If hospital
administrations can be convinced to implement a simpler and cheaper standard
to start, which has the potential for extension in the long-term. It will go
over far better than the current approach of, "We'll implement this new
standard for you that will take nearly 2 years, cause budget overruns, and
never really see adoption." (The only people that end up benefiting are the
consultants implementing the spec.)

Additionally, there's still an emotional component of "You're not getting our
data because we don't trust you know how to secure it properly." From the
personal experience of having worked with the IT staff at various medical
institutions there is often a level of paranoia around their data. Which, in
some regards is fully justified given the regulations (HIPPA, HITECH, etc)
they are required to meet. The issue is that it often moves beyond meeting the
regulations into a place of attempting to exceed the regulations. Which, seems
like a smart move until it is too late and you've only succeeded in adding
extra bureaucracy into your internal processes. These added burdens are then
foisted upon external parties who are attempting to integrate with the system
and therefore, by the nature of the regulations, the processes which have been
previously set forth by the implementing institution.

All of that said, I agree with your statement, "I know people on HN have fire
in their breast to change the world but the rock is harder to move then many
think.". However my take is that we are attempting to move the wrong rock.
Healthcare institutions need to learn the correct way to introduce and enforce
secure yet flexible processes and policies in regards to technology. After
that occurs then the technology rock will be much easier to move.

I'm going to add that I've been a Medical Software Engineer for just shy of 10
years and it has been both an extremely frustrating and also extremely
rewarding ride.

------
ch4s3
This article totally misses the mark. The MPH and non-technical Health IT
folks get super excited over FHIR, but its probably DOA. Its been mired in
committee for years and makes a ton of compromises. If you look at the demo
code, it isn't terrible per se[1], but ordering back to the EHR through FHIR
is locked into order sets. Order sets for those not in the industry amount to
pre set lists of procedure/medication/whatever orders defined on a per
hospital basis. Trying to order a specific thing off order set for an
individual patient is a be messier.

And honestly, the APIs at Allscripts, EPIC, et al are getting a lot better.
The APIs avoid a lot of the free text nonsense that floatrock mentioned. They
aren't great, especially around allergies and immunizations, but I think they
have legs.

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

------
gaius
_you’ll probably be integrating with a 70’s-era MUMPs-based EMR system, which
will be expensive, painful, and slow_

The funny thing is, if you study MUMPS even briefly, you will be struck a
weird sense of deja vu... It's what we call "NoSQL" now. And it was superseded
by RDBMS in the 80's for a reason.

~~~
iolothebard
They were going to switch my local hospital to a MUMPS system for something
like 27m (or was it 127m, I forget). I looked at the technology and almost
cried.

Fortunately they fired that CIO (who literally knew nothing about computers or
IT, but hey, the committee appointed him).

~~~
epmatsw
If you live in the US, it's pretty much standard to use considering that Epic,
VistA, GE, and MEDITECH are all based on it.

~~~
whitten
If you live outside the US, InterSystems is rapidly getting EMR/EHR contracts
with their InterSystems HealthShare® system. I haven't heard how much it uses
FHIR, but find it likely that if there is a market that it will become a part
of solutions available to purchase.

------
bwy
I knew even before I clicked the link that it would be discussing e-health
records :) I worked with them in a small division of McKesson (RelayHealth) a
few summers ago as an intern and the company was described to me as "the
biggest company no one's ever heard of." Hope there's finally some agreement
on the format and information sharing takes off so we can focus on the
important things! So much of my work today seems to involve data munging that
I'm starting to wonder if this is all a career in data science really has to
offer.

~~~
seesomesense
"the biggest company no one's ever heard of." That would be blackrock. Or
perhaps pimco.

------
therealwill
Sadly, I don't see this happening without the government making it a
requirement that EMR adopt the standard. The resilience to change in
healthcare is unimaginable.

~~~
krschultz
Maybe that's because we (software engineers) are not providing them value?

As far as I can tell, the EMR system my surgeons & doctors use is solely a
hindrance to his workflow as compared to paper charts. I'm sure it's easier
for the people/computers processing paperwork and billing on the backend, but
for the doctors and nurses in the room all I've heard so far are complaints.
From my observation, the UI/UX of the whole thing is terrible. I'm actually
embarrassed by it as a member of the profession.

~~~
misthop
Sadly, the EMR is not made for your surgeons - it is made for the people doing
billing. EMRs are good at capturing the data that is needed to get as many
dollars as possible from insurance companies. It is only recently that quality
of care metrics have had any impact on billing (Gross oversimplification -
Under the ACA Medi[care/caid] payments can be limited for low quality care).
Prior to the ACA the increased costs of making good EMR workflows for
providers was a net negative from a hospital revenue perspective.

~~~
tel
This is super true. There's not a lot of proof of business models for
healthcare IT outside of billing. If you try it you'll quickly learn that a
practice or hospital's interaction with insurers is the most important one
they have.

------
dynofuz
We are building our app on FHIR (NavHealth.com) it's great to see so much
interest on hn

------
seesomesense
Don't waste your time. HL7 is a wasteland.

It is a career killer.

------
Zigurd
$10-150k per integration doesn't sound so bad. Ever meet a supposedly modern
allegedly-REST API rife with side effects and asymmetry?

