Accounts

September132012

This week has been teaming with health care conferences, particularly in Boston, and was declared by President Obama to be National Health IT Week as well. I chose to spend my time at the second ITdotHealth conference, where I enjoyed many intense conversations with some of the leaders in the health care field, along with news about the SMART Platform at the center of the conference, the excitement of a Clayton Christiansen talk, and the general panache of hanging out at the Harvard Medical School.

SMART, funded by the Office of the National Coordinator in Health and Human Services, is an attempt to slice through the Babel of EHR formats that prevent useful applications from being developed for patient data. Imagine if something like the wealth of mash-ups built on Google Maps (crime sites, disaster markers, restaurant locations) existed for your own health data. This is what SMART hopes to do. They can already showcase some working apps, such as overviews of patient data for doctors, and a real-life implementation of the heart disease user interface proposed by David McCandless in WIRED magazine.

The premise and promise of SMART

At this conference, the presentation that gave me the most far-reaching sense of what SMART can do was by Nich Wattanasin, project manager for i2b2 at Partners. His implementation showed SMART not just as an enabler of individual apps, but as an environment where a user could choose the proper app for his immediate needs. For instance, a doctor could use an app to search for patients in the database matching certain characteristics, then select a particular patient and choose an app that exposes certain clinical information on that patient. In this way, SMART an combine the power of many different apps that had been developed in an uncoordinated fashion, and make a comprehensive data analysis platform from them.

Another illustration of the value of SMART came from lead architect Josh Mandel. He pointed out that knowing a child’s blood pressure means little until one runs it through a formula based on the child’s height and age. Current EHRs can show you the blood pressure reading, but none does the calculation that shows you whether it’s normal or dangerous. A SMART app has been developer to do that. (Another speaker claimed that current EHRs in general neglect the special requirements of child patients.)

SMART is a close companion to the Indivo patient health record. Both of these, aong with the i2b2 data exchange system, were covered in article from an earlier conference at the medical school. Let’s see where platforms for health apps are headed.

In September 2009, the HITECH act (part of the American Recovery and Reinvestment Act) had defined the concept of “meaningful use,” but nobody really knew what was expected of health care providers, because the ONC and the Centers for Medicare & Medicaid Services did not release their final Stage 1 rules until more than a year after this conference. Aneesh Chopra, then the Federal CTO, and Todd Park, then the CTO of Health and Human Services, spoke at the conference, but their discussion of health care reform was a “vision.” A surprisingly strong statement for patient access to health records was made, but speakers expected it to be accomplished through the CONNECT Gateway, because there was no Direct. (The first message I could find on the Direct Project forum dated back to November 25, 2009.) Participants had a sophisticated view of EHRs as platforms for applications, but SMART was just a “conceptual framework.”

So in some ways, ONC, Harvard, and many other contributors to modern health care have accomplished an admirable amount over three short years. But some ways we are frustratingly stuck. For instance, few EHR vendors offer API access to patient records, and existing APIs are proprietary. The only SMART implementation for a commercial EHR mentioned at this week’s conference was one created on top of the Cerner API by outsiders (although Cerner was cooperative). Jim Hansen of Dossia told me that there is little point to encourage programmers to create SMART apps while the records are still behind firewalls.

Keynotes

I couldn’t call a report on ITdotHealth complete without an account of the two keynotes by Christiansen and Eric Horvitz, although these took off in different directions from the rest of the conference and served as hints of future developments.

Christiansen is still adding new twists to the theories laid out in c The Innovator’s Dilemma and other books. He has been a backer of the SMART project from the start and spoke at the first ITdotHealth conference. Consistent with his famous theory of disruption, he dismisses hopes that we can reduce costs by reforming the current system of hospitals and clinics. Instead, he projects the way forward through technologies that will enable less trained experts to successively take over tasks that used to be performed in more high-cost settings. Thus, nurse practitioners will be able to do more and more of what doctors do, primary care physicians will do more of what we current delegate to specialists, and ultimately the patients and their families will treat themselves.

He also has a theory about the progression toward openness. Radically new technologies start out tightly integrated, and because they benefit from this integration they tend to be created by proprietary companies with high profit margins. As the industry comes to understand the products better, they move toward modular, open standards and become commoditized. Although one might conclude that EHRs, which have been around for some forty years, are overripe for open solutions, I’m not sure we’re ready for that yet. That’s because the problems the health care field needs to solve are quite different from the ones current EHRs solve. SMART is an open solution all around, but it could serve a marketplace of proprietary solutions and reward some of the venture capitalists pushing health care apps.

While Christiansen laid out the broad environment for change in health care, Horvitz gave us a glimpse of what he hopes the practice of medicine will be in a few years. A distinguished scientist at Microsoft, Horvitz has been using machine learning to extract patterns in sets of patient data. For instance, in a collection of data about equipment uses, ICD codes, vital signs, etc. from 300,000 emergency room visits, they found some variables that predicted a readmission within 14 days. Out of 10,000 variables, they found 500 that were relevant, but because the relational database was strained by retrieving so much data, they reduced the set to 23 variables to roll out as a product.

Another project predicted the likelihood of medical errors from patient states and management actions. This was meant to address a study claiming that most medical errors go unreported.

A study that would make the privacy-conscious squirm was based on the willingness of individuals to provide location data to researchers. The researchers tracked searches on Bing along with visits to hospitals and found out how long it took between searching for information on a health condition and actually going to do something about it. (Horvitz assured us that personally identifiable information was stripped out.)

His goal is go beyond measuring known variables, and to find new ones that could be hidden causes. But he warned that, as is often the case, causality is hard to prove.

As prediction turns up patterns, the data could become a “fabric” on which many different apps are based. Although Horvitz didn’t talk about combining data sets from different researchers, it’s clearly suggested by this progression. But proper de-identification and flexible patient consent become necessities for data combination. Horvitz also hopes to move from predictions to decisions, which he says is needed to truly move to evidence-based health care.

Did the conference promote more application development?

My impression (I have to admit I didn’t check with Dr. Ken Mandl, the organizer of the conference) was that this ITdotHealth aimed to persuade more people to write SMART apps, provide platforms that expose data through SMART, and contribute to the SMART project in general. I saw a few potential app developers at the conference, and a good number of people with their hands on data who were considering the use of SMART. I think they came away favorably impressed–maybe by the presentations, maybe by conversations that the meeting allowed them to have with SMART developers–so we may see SMART in wider use soon. Participants came far for the conference; I talked to one from Geneva, for instance.

The presentations were honest enough, though, to show that SMART development is not for the faint-hearted. On the supply side–that is, for people who have patient data and want to expose it–you have to create a “container” that presents data in the format expected by SMART. Furthermore, you must make sure the data conforms to industry standards, such as SNOMED for diagnoses. This could be a lot of conversion.

On the application side, you may have to deal with SMART’s penchant for Semantic Web technologies such as OWL and SPARQL. This will scare away a number of developers. However, speakers who presented SMART apps at the conference said development was fairly easy. No one matched the developer who said their app was ported in two days (most of which were spent reading the documentation) but development times could usually be measured in months.

Mandl spent some time airing the idea of a consortium to direct SMART. It could offer conformance tests (but probably not certification, which is a heavy-weight endeavor) and interact with the ONC and standards bodies.

After attending two conferences on SMART, I’ve got the impression that one of its most powerful concepts is that of an “app store for health care applications.” But correspondingly, one of the main sticking points is the difficulty of developing such an app store. No one seems to be taking it on. Perhaps SMART adoption is still at too early a stage.

Once again, we are batting our heads up against the walls erected by EHRs to keep data from being extracted for useful analysis. And behind this stands the resistance of providers, the users of EHRs, to give their data to their patients or to researchers. This theme dominated a federal government conference on patient access.

I think SMART will be more widely adopted over time because it is the only useful standard for exposing patient data to applications, and innovation in health care demands these apps. Accountable Care Organizations, smarter clinical trials (I met two representatives of pharmaceutical companies at the conference), and other advances in health care require data crunching, so those apps need to be written. And that’s why people came from as far as Geneva to check out SMART–there’s nowhere else to find what they need. The technical requirements to understand SMART seem to be within the developers’ grasps.

But a formidable phalanx of resistance remains, from those who don’t see the value of data to those who want to stick to limited exchange formats such as CCDs. And as Sean Nolan of Microsoft pointed out, one doesn’t get very far unless the app can fit into a doctor’s existing workflow. Privacy issues were also raised at the conference, because patient fears could stymie attempts at sharing. Given all these impediments, the government is doing what it can; perhaps the marketplace will step in to reward those who choose a flexible software platform for innovation.

March232011

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.

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
href="http://indivohealth.org/">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
href="http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf">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:
href="http://www.connectopensource.org/">CONNECT and
href="http://wiki.directproject.org/">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
href="http://healthurl.com/www/P4.html">P4 web page.