Clinician, researcher, and patients working together: progress aired at Indivo conference

Open-source SMART platform and Indivo PHR are increasingly integrated

While thousands of health care professionals were flocking to the BIO International Convention this week, I spent Monday in a small library at the Harvard Medical School listening to a discussion of the Indivo patient health record and related open source projects with about 80 intensely committed followers. Lead Indivo architect Daniel Haas, whom I interviewed a year ago, succeeded in getting the historical 2.0 release of Indivo out on the day of the conference. This article explains the significance of the release in the health care field and the promise of the work being done at Harvard Medical School and its collaborators.

Although still at the early adoption stages, Indivo and the related SMART and i2b2 projects merit attention and have received impressive backing. The Office of the National Coordinator funded SMART, and NIH funded i2b2. National Coordinator Farzad Mostashari was scheduled to attend Monday’s conference (although he ended up having to speak over a video hookup). Indivo inspired both Microsoft HealthVault and Google Health, and a good deal of its code underlies HealthVault. Australia has taken a nationwide PHR initiative inspired by Indivo. A Partners HealthCare representative spoke at the conference, as did someone from the MIT Media Lab. Clayton M. Christensen et al. cited Indivo as a good model in The Innovator’s Prescription: A Disruptive Solution for Health Care. Let’s take a look at what makes the combination so powerful.

Platform and reference implementation

The philosophy underlying this distributed open source initiative is to get clinicians, health researchers, and patients to share data and work together. Today, patient data is locked up in thousands of individual doctors or hospital repositories; whether they’re paper or electronic hardly makes a difference because they can’t be combined or queried. The patient usually can’t see his own data, as I described in an earlier posting, much less offer it to researchers. Dr. Kenneth Mandl, opening the conference, pointed out that currently, an innovative company in the field of health data will die on the vine because they can’t get data without making deals with each individual institution and supporting its proprietary EHR.

The starting point for changing all that, so far as this conference goes, is the SMART platform. It simply provides data models for storing data and APIs to retrieve it. If an electronic health record can translate data into a simple RDF model and support the RESTful API, any other program or EHR that supports SMART can access the data. OAuth supports security and patient control over access.

Indivo is a patient health record (or, to use the term preferred by the conference speakers, a personally controlled health record). It used to have its own API, and the big significance of Monday’s 2.0 release is that it now supports SMART. The RESTful interface will make Indivo easy to extend beyond its current Java and Python interfaces. So there’s a far-reaching platform now for giving patients access to data and working seemlessly with other cooperating institutions.

The big missing piece is apps, and a hackathon on Tuesday (which I couldn’t attend) was aimed at jump-starting a few. Already, a number of researchers are using SMART to coordinate data sharing and computation through the i2b2 platform developed by Partners. Ultimately, the SMART and Indivo developers hope to create an app store, inspired by Apple’s, where a whole marketplace can develop. Any app written to the SMART standard can run in Indivo or any other system supporting SMART. But the concept of an app in SMART and Indivo is different from a consumer market, though. The administrator of the EHR or PHR would choose apps, vetting them for quality and safety, and then a doctor, researcher, or patient could use one of the chosen apps.

Shawn Murphy of Partners described the use of i2b2 to choose appropriate patients for a clinical study. Instead of having to manually check many different data repositories manually for patients meeting the requirements (genetic, etc.), a researcher could issue automated queries over SMART to the databases. The standard also supports teamwork across institutions. Currently, 60 different children’s hospitals’ registries talk to each other through i2b2.

It should be noted i2b2 does not write into a vendor’s EHR system (which the ONC and many others call an important requirement for health information exchange) because putting data back into a silo isn’t disruptive innovation. It’s better to give patients a SMART-compatible PHR such as Indivo.

Regarding Tuesday’s hackathon, Haas wrote me, “By the end of the day, we had several interesting projects in the works, including an app to do contextualized search based on a patient’s Problems list (integration with google.com and MedlinePlus), and app integration with BodyTrack, which displays Indivo labs data in time-series form alongside data from several other open API inputs, such as Fitbit and Zeo devices.”

Standards keep things simple

All the projects mentioned are low-budget efforts, so they all borrow and repurpose whatever open source tools they can. As Mostashari said in his video keynote, they believe in “using what you’ve got.” I have already mentioned SMART’s dependence on standards, and Indivo is just as behold to other projects, particularly Django. For instance, Indivo allows data to be stored in Django’s data models (Python structures that represent basic relational tables). Indivo also provides an even simpler JSON-based data model.

The format of data is just as important as the exchange protocol to interoperability. The SMART team chose to implement several “best-of-breed” standards that would cover 80% of use cases: for instance, SNOMED for medical conditions, RxNORM for medications, and LOINC for labs. Customers using other terminologies will have to translate them into the supported standards, so SMART contains Provenance fields indicating the data source.

The software is also rigorously designed to be modular, so both the original developers and other adopters can replace pieces as desired. Indivo already has plenty of fields about patient data and about context (provider names, etc.), but more can be added ad infinitum to support any health app that comes along. Indivo 2.0 includes pluggable data models, which allow a site to customize every step from taking in data to removing it. It also supports new schemas for data of any chosen type.

The simplicity of Indivo, SMART, and i2b2–so much in contrast with most existing health information exchanges–is reminiscent of Blue Button. Mandl suggested that a Blue Button app would be easy to write. But the difference is that Blue Button aimed to be user-friendly whereas the projects at this conference are developer-friendly. That means that can add some simple structure and leave it up to app developers to present the data to users in a friendly manner.

The last hurdle

Because SMART and Indivo ultimately want the patient to control access to data, trust is a prerequisite. OAuth is widely used by Twitter apps and other sites across the Web, but hasn’t been extensively tested in a health care environment. We’ll need more experience with OAuth to see whether the user experience and their sense of security are adequate. And after that, trust is up to the institutions adopting Indivo or SMART. A couple speakers pointed out that huge numbers of people trust mint.com with their passwords to financial accounts, so when they learn the benefits of access to patient records they should adopt Indivo as well. An Indivo study found that 84% of people are willing to share data with social networks for research and learning.

SMART, Indivo, and i2b2 make data sharing easier than ever. but as many have pointed out, none of this will get very far until patients, government, and others demand that institutions open up. Mandl suggested that one of the major reasons Google Health failed was that it could never get enough data to gain traction–the health providers just wouldn’t work with the PHR. At least the open source standards take away some of the technical excuses they have used up to now.

tags: , , , , ,