SMART challenge and P4: open source projects look toward the broader use of health records

In a country where doctors are still struggling to transfer basic
patient information (such as continuity of care records) from one
clinic to another, it may seem premature to think about seamless data
exchange between a patient and multiple care organizations to support
such things as real-time interventions in patient behavior and better
clinical decision support. But this is precisely what medicine will
need for the next breakthrough in making patients better and reducing
costs. And many of the building blocks have recently fallen into
place.

Two recent open source developments have noticed these opportunities
and hope to create new ones from them. One is the SMART Apps for Health
contest at Challenge.gov, based on the SMART Platform that is one
of the darlings of Federal
CTO Aneesh Chopra
and other advocates for health care innovation.
The other development is P4, the brainchild of a
physician named Adrian Gropper who has recognized the importance of
electronic records and made the leap into technology.

SMART challenge: Next steps for a quickly spreading open source
API

I’m hoping the SMART Platform augurs the future of health IT: an open
source project that proprietary vendors are rushing to adopt. The
simple goal of SMART is to pull together health data from any
appropriate source–labs, radiology, diagnoses, and even
administrative information–and provide it in a common,
well-documented, simple format so any programmer can write an app to
process it. It’s a sign of the mess electronic records have become
over the years that this functionality hasn’t emerged till now. And
it’s a sign of the tremendous strides health IT has made recently that
SMART (and the building blocks on which it is based) has become so
popular.

SMART has been released under the GPL, and is based on two other
important open source projects: the INDIVO health record system and
the I2B2 informatics system. Like
INDIVO, the SMART project was largely developed by Children’s Hospital
Boston, and was presented at a meeting I attended today by Dr. Kenneth
D. Mandl, a director of the Intelligent Health Laboratory at the
hospital and at Harvard Medical School. SMART started out with the
goal of providing a RESTful API into data. Not surprisingly, as Mandl
reported, the team quickly found itself plunged into the task of
developing standards for health-related data. Current standards either
didn’t apply to the data they were exposing or were inappropriate for
the new uses to which they wanted to put it.

Health data is currently stored in a Babel of formats. Converting them
all to a single pure information stream is hopeless; to make them
available to research one must translate them on the fly to some
universally recognized format. That’s one of the goals of the report
on health care
released in December 2010 by the President’s
Council of Advisors on Science and Technology. SMART is developing
software to do the translation and serve up data from whatever desired
source in “containers.” Applications can then query the containers
through SMART’s API to retrieve data and feed to research and clinical
needs.

Justifying SMART, Mandl presented solid principles of modern data
processing that will be familiar to regular Radar readers:

Data as a platform

Storage should be as flexible and free of bias as possible, so that
innovators can easily write new applications that do surprising and
wonderful things with it. This principle contrasts starkly with most
current health records, which make the data conform to a single
original purpose and make it hard to extract the data for any other
use, much less keep it clean enough for unanticipated uses. (Talk to
doctors about how little the diagnoses they enter for billing purposes
have to do with the actual treatments patients need.)

An “Appstore for health”

New applications should be welcome from any quarter. Mandl is hoping
that apps will eventually cost just a few dollars, like a cell phone
app. (Note to Apple: Mandl and the audience tended to use the terms
“iPhone” and “Appstore” in a casual manner that slid from metaphors to
generic terms for mobile devices and program repositories.) Mandl said
that his teams’ evaluation of apps would be on the loose side, more
like Android than iPhone, but that the environment would not be a
“Wild West.” At each hospital or clinic, IT staff could set up their
own repositories of approved apps, and add custom-built ones.

A “learning health system”

Data should be the engine behind continuous improvement of our health
care system. As Mandl said, “every patient should be an opportunity to
learn.”

Open source and open standards

As we’ve seen, standards are a prerequisite for data as a platform.
Open source has done well for SMART and the platforms on which is
based. But the current challenge, notably, allows proprietary as well
as open source submissions. This agnosticism about licensing is a
common factor across Challenge.gov. Apparently the sponsors believe
they will encourage more and better submissions by allowing the
developers to keep control over the resulting code. But at least most
Challenge.gov rules require some kind of right to use the app the
SMART challenge is totally silent on rights. The danger, of course, is
the developers will get tired of maintaining an app or will add
onerous features after it becomes popular.

An impressive list of electronic record vendors have promised support
for SMART or integrated it into products in some way: Cerner, Siemens,
Google, Microsoft, General Electric, and more. SMART seems to be on
its way to a clean sweep of the electronic health care record
industry. And one of its projects is aimed at the next frontier:
integrating devices such as blood glucose readers into the system.

P4: Bringing patients into the health record and their own
treatment

SMART is a widely championed collaboration among stellar institutions;
P4 is the modest suggestion of a single doctor. But I’m including P4
in this blog because I think it’s incredibly elegant. As you delve
into it, the concept evolves from seeming quite clever to completely
natural.

The project aims to create a lightweight communication system based on
standards and open source software. Any device or application that the
patient runs to record such things as blood pressure or mood could be
hooked into the system. Furthermore, the patient would be able to
share data with multiple care providers in a fine-grained way–just
the cholesterol and blood pressure readings, for example, or just
vaccination information. (This was another goal of the PCAST report
mentioned in the previous section.)

Communicating medical records is such a central plank of health care
reform that a division of Health and Human Services called the Office
of the National Coordinator created two major open source projects
with the help of electronic health record vendors: CONNECT and Direct. The latter is more
lightweight, recently having released libraries that support the
secure exchange of data over email.

Vendors will jump in now and produce systems they can sell to doctors
for the exchange of continuity of care records. But Gropper wants the
patients to have the same capabilities. To do that, he is linking up
Direct with another open source project developed by the Markle
Foundation for the Veterans Administration and Department of Defense:
Blue Button.

Blue Button is a patient portal with a particularly simple interface.
Log in to your account, press the button, and get a flat file in an
easy-to-read format. Linked Data proponents grumble that the format is
not structured enough, but like HTML it is simple to use and can be
extended in the future.

Blue Button is currently only a one-way system, however. A veteran can
look at his health data but can’t upload new information. Nor can
multiple providers share the data. P4 will fix all that by using a
Direct interface to create two-way channels. If you are recovering
from a broken leg and want to upload your range-of-motion progress
every day, you will be able to do this (given that a format for the
data is designed and universally recognized) with your orthopedic
surgeon, your physical therapist, and your primary care provider. P4
will permit fine-grained access, so you can send out only the data you
think is relevant to each institution.

Gropper is aiming to put together a team of open source coders to
present this project to a VA challenge. Details can be found on the P4 web page.

tags: , , , , , , ,