Health Care 2.0 Challenge announces winners: focus on access to Practice Fusion

In the set of programming
challenges
announced by Health 2.0 a little over two months ago,
Practice Fusion unveiled plans for the first open test of their API.
In fact, according to Matthew Douglass, VP of Engineering of Practice
Fusion, the Practice Fusion API challenge was one of the top
challenges in the series, with over 30 participating teams. The Health
2.0 challenge was partly sponsored by O’Reilly Media and I covered it
in blog
last July
.

Practice Fusion is one of a growing number of software companies who
attack the appalling lack of electronic medical systems in medicine by
letting doctors log into an EMR online. In other words, this is EMR in
the form of Software as a Service. One key enhancement that
distinguishes Practice Fusion from its competition is an API they
started to offer last summer. One could easily see why this would
interest health care geeks and potential value-added resellers, but
why would this be a competitive selling point to doctors? We will see
in the course of this blog.

The challenge and the response

As I reported in my blog on the Health 2.0 challenge, Practice Fusion
challenged developers not to code up a routine data exchange
application, but to find a way to draw the patient into his own
care–a beacon for progressive health care practitioners, who believe
that patients hold the keys to their own health and need to be won
over to treat themselves. Furthermore, Practice Fusion called for
real-time data entry, which raises the reliability of what patients
report and allow instant gratification.

Developers responded with a plethora of applications with clear uses:

  • An application that lets a user type in his current blood pressure,
    valuable for anyone with heart problems or other risks related to
    blood pressure

  • A mood tracker mobile application that presents a list of possible
    words to describe a patient’s mood, useful for people with affective
    disorders

  • An app that lets a patient signal the doctor’s office each time he or
    she takes a medication, useful to track compliance and prompt people
    who are disoriented or forgetful (especially useful because a side
    effect of many meds is to make you disoriented or forgetful)

  • An app that hooks into a scale that can instantly transmit the weight
    registered, and sends the weight back to the doctor’s office, which
    may well be useful for most of us living in America

And the winner is…

Health 2.0 can’t be faulted for lacking a sense of fun, because one of
the six winning applications was a hack in the style of MAKE Magazine. Well, being fair, the
submission consisted of two parts, one of which upheld the lofty and
arcane software quest of interconnecting systems, while the other was
a hack in the style of MAKE Magazine.

I know which one you want to hear about, but I’ll start with the
interconnection project. Practice Fusion has a patient center called
Patient Fusion to which
patients can get accounts if their doctors use Practice Fusion. But
many people prefer another site such as Microsoft HealthVault or Google Health.

Pete Gordon and his staff at Critical
Systems
wrote a .NET web application to sync data between
Microsoft HealthVault and Patient Fusion. Anyone with accounts on
those two systems will be able to login and synchronize data between
the two PHRs at the application
site
. Authentication is through OAuth for Patient Fusion and
OpenID can be used for HealthVault.

Pete, and the Critical Systems team, will register the application as
a full HealthVault production application by the end of the year; it
is now using HealthVault test servers. But for those so inclined and
unable to wait, they can download the source code and web application
from the project’s development
web site on CodePlex
and install the application on their own web
server.

Partly to test the connection and partly just to satisfy an itch Pete
had ever since he started using HealthVault, they then went on to the
hack: hooking up a low-budget body scale to a device that could
transmit the patient’s weight to a computer and on to HealthVault. Of
course, sending your weight to the Internet is already possible with
high-end scales, including BodyTrace eScale (another of the Health 2.0
challenge finalists) and Withings. But Pete liked the idea of
providing this capability to people who don’t want to purchase the
premium scales.

It’s worth mentioning a bit about the winner’s background here. Pete
got his degree from Ohio State University in 1997 and was a Java and
.NET developer for many years before happening upon a health care
company in 2007. Deciding that more and more software jobs would
require specialized domain knowledge, he decided to specialize in
health care IT and started a new company two years ago in that field.

Regardless of the motivation for his Escali monitor, the result is not
something most heart patients will wire up on a weekend. Pete chose an
Escali scale he bought for $45, which contains just barely enough
electronics to pick up the information he wanted on a microprocessor.
You can see the results in a video on the project’s web site.

Unable to get the weight directly from the scale’s processor, Pete and
his team reverse engineered the scale to figure out the format in
which the processor sent information for display on the custom LCD,
and to detect when the LCD was turned on. A serial port connection
connects their processor to a PC.

With this hack, Pete attracted the attention not only of the Health
2.0 team but of the Escali company, which is considering an upgrade
that will incorporate the functionality into their scales through a
more conventional combination of a Zigbee device and a low-power
802.15 wireless connection.

In the set of programming
challenges
announced by Health 2.0 a little over two months ago,
Practice Fusion unveiled plans for the first open test of their API.
In fact, according to Matthew Douglass, VP of Engineering of Practice
Fusion, their API challenge was one of the top challenges in the
series, with over 30 teams working on submissions.

Another finalist of note

Practice Fusion’s Patient Fusion API was also the platform for BodyTrace, another of the Health
2.0 finalists. I talked to Gyula Borbely of BodyTrace about their app
to feed user’s weight into the system.

BodyTrace created the world’s first GSM-enabled bathroom scale. When
the user steps on the scale, it sends out information instantly over
T-Mobile’s network to the BodyTrace web site. No Wi-Fi or Internet
connection is needed, and therefore no technical knowledge or
configuration.

Users can view the course of their weight gain or loss through charts
on the BodyTrace site, or sign up with their account information to
have BodyTrace immediately forward the information to another service.
BodyTrace already has data exchange set up with about ten other
patient record sites, so adding Patient Fusion was fairly easy. Google
Health and Microsoft HealthVault connections are underway.

In addition to giving individuals the encouraging or cautionary data
about their weight over time, BodyTrace is used by health care
professionals, who prescribe the use of the eScale so they can see for
themselves how well their treatment is working. One interesting red
flag that the eScale can help with is a phenomenon that medical
researchers have noticed: people with heart problems tend to suddenly
gain weight in a way unrelated to their eating habits a few days
before a heart attack. BodyTrace is trying to work out a research
study with a major hospital to follow this lead and see what can be
done to intervene with the patient before catastrophe strikes.

It’s interesting to note that BodyTrace talked to Practice Fusion for
some time before a partnership before Practice Fusion release its API.
At the beginning, it wasn’t clear how they could work together. The
release of the API made the relationship almost obvious. It provided
all the technical answers to questions about merging their products.
And as the next section shows, the API creates a business model for
working together as well.

Distribution and payment

Getting an app out to users requires more than a nifty API; a search
and download function has to be built into the service to actually
distribute the apps. So Practice Fusion has added a function like the
Facebook or Apple iPhone store, allowing doctors to download apps and
then, in turn, prescribe them to patients. The doctor may say, for
instance, “You’ve been acting a little more manic lately, so I want
you to install this mood tracker and report your mood every day.”

The contract Practice Fusion signs with the people offering apps
contains requirements for auditing to make sure the developer respects
patient privacy and tests the app for quality. In addition, a rating
service lets doctors indicate which apps they’ve found helpful. Apps
have access only to data that they put into the system for that
particular patient.

Practice Fusion is a free service, supported by advertising. Although
developers can charge for apps, Practice Fusion is encouraging them to
offer the apps cost-free. One way to pay for development is to serve
ads on the app, as iPhone developers now can do. So long as patient
privacy is strictly respected, advertising may be a rich revenue
source because the patient indicates the presence of something within
a range of medical conditions merely by downloading the app.

Other potential sources of payment include the sale of accompanying
devices (such as a scale that transmits the patient’s weight) and
insurance companies who might see the real-time data feeds as a way to
avoid more expensive interventions down the line.

Real-time data from data living that can stave off crises and lower
costs–that’s a pretty good selling point or an API. So while creating
an after-market for their service, Practice Fusion is harnessing
creativity from the field to provide many more features than they
could ever code up themselves, as well as interfaces to devices from
other companies.

Other challenge winners

Six development teams won awards during the Health 2.0 challenge.

Team Videntity won the award for Accelerating
Wireless Health Adoption through a Standardized Social Network
Platform
, sponsored by West Wireless Health Institute. Team
Videntity created a blood pressure meter meeting the challenge to
integrate sensor-derived data with social networks to construct a
personalized wireless health ecosystem.

Team Pain Care @Ringful Health won the Project
HealthDesign Developer Challenge
, sponsored by Robert Wood Johnson
Foundation Pioneer Portfolio and California HealthCare Foundation. The
team developed a mobile app that allows people with chronic diseases
such as diabetes report
and manage
their conditions by sharing data with doctors and
getting real-time advice.

Team Acsys Healthcare won the award for Health
Factor–Using the County Health Rankings to Make Smart Decisions
,
sponsored by Robert Wood Johnson Foundation and University of
Wisconsin Population Health Institute. The team built an augmented
reality mobile application that displays Health Rankings information
for the user’s county based on a GPS reading.

Team Happy Feet from Stanford University won the Move
Your App! Developer Challenge
, sponsored by Catch and HopeLabs.
The team created an app that encouraged people to walk, jog, run,
cycle, or even ski, by providing inspiration through activity
tracking, sharing statistics with friends, and earning achievement
points.

The winner of the Blue
Button Challenge
, sponsored by Markle Foundation and the Robert
Wood Johnson Foundation, will be announced on stage at the Health 2.0
Conference. The challenge asked teams to develop a web-based tool
that uses sample data from Centers for Medicare & Medicaid
Services (CMS) or the VA to help patients stay healthy and manage
their care.

Update, Oct. 12: Alan Viars of Videntity won the award for a
West Wireless Health Institute challenge by designing a platform that
lets users securely share health information over consumer devices
(video demo).

tags: , , , ,
  • http://wellescent.com/health_blog Wellescent Health Blog

    While there is considerable potential for devices that can upload patient data to an EHR on the web in of themselves, part of the real value lies in tightening the feedback loop between patient and doctor such that the doctor can make recommendations in short order. The question that arises with this is whether such systems will adequately support decision making by doctors or whether they will result in an overload of data?

  • http://www.praxagora.com/andyo Andy Oram

    I like the questions from Wellescent Health Blog, because these are
    just the technical (and organizational) issues that the health care
    field and its IT component have got to discuss. I think we’re way
    behind what we need. Everybody–including a lot of patients–would
    like patients to be involved more in their care. Consider the building
    blocks that have to be in place for convenient, patient-doctor
    communication:

    * The doctor’s record system has to authenticate patients and accept
    information from them. Given the wretched state of health
    information exchange between doctors, most institutions are far from
    anything like this.

    * To avoid the information overload mentioned by the commenter, the
    health record needs fields to store patient information in a
    routinized way. I imagine records have standard fields for storing
    common medical questions such as weight and blood pressure, but how
    about mood or whether someone went to the bathroom today?

    * The record system needs a program that can look over historical
    data, note trends, and alert the doctor or patient if something
    alarming is happening, such as the sudden weight gain mentioned in
    my blog.

    * Communication between doctor and patient has to be authenticated and
    secure.

    And going outside the technical arena, we need systems that pay
    doctors for doing this monitoring and communication, instead of
    requiring an office visit. If doctors are remunerated, I think they’ll
    be happy to do small things that avoid more office and ER visits.

    There are systems doing pieces of this now. I recommend the video that
    I point to in the paragraph for Team Pain Care @Ringful Health
    (http://www.projecthealthdesign.org/projects/overview-2006_2008/405516c)
    although it’s sort of a marketing piece. But integrating data in ways
    that other industries have done for a long time–that remains to be
    accomplished.

  • Thomas Lukasik

    Re: Will Doctors Experience Information Overload?

    The answer to that is obviously “Yes” if a doctor were to be directly exposed to the firehose of data generated as patients weigh themselves and take their medications, or just want to tell the doctor every time that they’re sad or dizzy.

    What’s been demonstrated so far is only that we can stream tons of data to a doctor — orders of magnitude more than they can ever consume and get anything else (for example seeing patients) done.

    What needs to happen at the next “Challenge” event is to ask the developers to automate the digestion of all of that “data” in order to provide doctors with “information” in place of raw data.

    This will require heuristics and intelligence that can (for example) enable a doctor to “tune their receivers” to get only the “headlines” with the option of digging into the detailed data as needed, or send critical notifications out based on rules that the doctor can fine tune.

    Getting all of the data to the doctor is trivial, but enabling them to make sense out of it and still leave them enough time to make their rounds is the real challenge.

    TJL