Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

July 16 2012

May 17 2011

Sponsored post

October 07 2010

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

In the set of programming
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 href="">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

  • 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 href="">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 href="">Microsoft HealthVault or href="">Google Health.

Pete Gordon and his staff at Critical
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
. 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

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 href="">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
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 href="">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

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 href="">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 href="">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 href="">report
and manage their conditions by sharing data with doctors and
getting real-time advice.

Team Acsys Healthcare won the award for href="">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 href="">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

The winner of the href="">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.

August 18 2010

Four short links: 18 August 2010

  1. BBC Dimensions -- brilliant work, a fun site that lets you overlay familiar plcaes with famous and notable things so you can get a better sense of how large they are. Example: the Colossus of Rhodes straddling O'Reilly HQ, the Library of Alexandria vs the Google campus, and New Orleans Mardi Gras began at the headquarters of Fred Phelps's Westboro Baptist Church. (via this piece about its background)
  2. Podapter -- simple plug that takes mini-USB and goes into an iPod or iPhone. (via Tuesday product awesomeness)
  3. New NexusOne Radio Firmware -- a glimpse of the world that's sprung up sharing the latest goodies between countries, carriers, and developers. For everyone for whose products the street has found a new use, the challenge is to harness this energy, enthusiasm, knowledge, and devotion. In terms of cognitive surplus, this far exceeds the 1 LOLCAT minimum standard unit. (via YuweiWang on Twitter)
  4. Echoes Nest Remix API -- access to database of song characteristics and tools to manipulate tunes. See the Technology Review article for examples of what it's capable of. (via aaronsw on Twitter)

August 11 2010

The power of informal contracts

Before releasing elmcity as
an open source project,
it had to be reviewed by a team of Microsoft lawyers. They found no
patentable invention in the code and gave me the green light. Which is
funny in a way, because I'm sure I couldn't ever create a patentable
software invention. I'm just not that talented as a programmer.
Writing code, for me, is mainly a way to explore ideas and illustrate
possibilities. In this case, it's the idea that we can manage data
in a social way by participating in networks of syndicated feeds. And
it's the possibility that a lone developer, modestly capable but
empowered by languages, libraries, tools, and cloud services, can
bring that idea to life.

What is innovative about my project, I claim, is the network-oriented
way of thinking and acting that it embodies and promotes. The
approach is based on a set of principles that we have yet to fully
articulate, never mind teach along with the proverbial three R's.
Almost everybody learns the rules of reading, writing, and
arithmetic. But almost nobody learns the laws that govern the
structure and flow of information in networks, and that enable us to
make effective use of those networks.

We don't need software innovation to solve the problem that the
elmcity project addresses. Our perpetual inability to merge personal
and public calendar data can't be blamed on a lack of standard,
broadly-available software and services. We have all the stuff we
need, and have had for quite some time, and it all interoperates
pretty well. But we haven't internalized why, and how, to
use it in a network-oriented way.

One of the crucial ingredients is something that I'll call the
Principle of Informal Contracts. Here's an example from the early
blogosphere: RSS auto-discovery. It's the mechanism that associates the
pages of a website with a corresponding feed. Back in
2002 a remarkable collaboration brought it
into existence, summarized href="
t_change_to_the_link_tag">here by Mark Pilgrim who concluded:

Thank you to everyone who has been working on making this come together in the past few days. It has been surprisingly painless and friction-free. Together, we have come up with a new standard that is useful, elegant, forward-thinking, and widely implemented. In 4 day.

Thanks to that consensus, it has ever since been easier to subscribe to
blogs. But what about before then? The blogosphere's feed ecosystem was already
bootstrapped and thriving. RSS, implemented by various feed
publishers and feed readers, was the obvious enabler. But there was also an
informal contract. It went something like this:

My blog publishes a feed at a URL that I will tell you about one way or another. Maybe I'll use an orange icon, maybe I'll use a subscribe link, maybe both, maybe something else. By whatever means, I promise to produce a flow of new items at that URL. The feed itself might be one or another flavor of RSS. Whichever it is, your feed reader can count on finding certain things in a predictable way: a title, a link, a description.

That was enough to get things started in a big way. Here's a more contemporary
example: the contract that's implied by choosing a tag at the beginning of a
conference. It says:

We, the organizers, promise to bind the online resources that we produce for this conference to this tag. And we invite you, the attendees, to do the same. We do not promise to collect all the resources discoverable by means of this tag, dump them into a bucket, and assert authority over (or assume liability for) the contents of the bucket. We just want to be able to find all the stuff, yours and ours, and use it as needed. We want you to be able to do the same. And we think the virtual network routed by that tag can be valuable to everybody.

Members of a certain tribe, which you most likely belong to if you're
reading this, take that contract for granted. For you, the word "camp"
does not connote outdoor recreation, but rather a new kind of
conference that's co-created by the organizers and by the attendees.
One of the organizers' roles is to declare a tag for the conference.
I've watched newcomers to the tribe encounter this practice for the
first time, and then immediately adopt it. So I know the idea is
catching on.

But we haven't yet spelled out the underlying principle of informal
contracts. And we've got to do that, because we're living in a world
where networks of people and data can fruitfully use such contracts. They're easy to
create if you know how and why. Here's the contract for the ecosystem
of calendar feeds that I'm trying to bootstrap:

Anybody who wants to promote a series of public events agrees to publish a feed that transmits certain facts about events in a predictable way: the title, the starting date and time, a link back to the authoritative source. Anybody who wants to curate a view of sets of feeds made available in this way can do so by making a list of them.

Within the project itself, there are some other contracts. Here's one:

To make the lists of feeds that define these curated views, we'll agree to use the delicious social bookmarking service in a particular way. The elmcity service will define the extensible set of delicious accounts used for this purpose. We'll agree that users of those accounts will follow certain practices that define the settings for their instances of the service, and the lists of feeds they trust to flow through their hubs.

That agreement in turn enables another. Because every action in
delicious is a database query that produces an RSS feed, the
acquisition of a new calendar feed by a curator sends a message on a
virtual channel that can be read and reacted to. The service that
reads and reacts, in this case, is FriendFeed. Here's the contract:

Curators can subscribe to a project feed that's aggregated by an instance of the FriendFeed service. Items flowing through its Atom feed are significant events in the life of the project. They include:

  • The posting of a forum message or reply.

  • The posting elsewhere of a tweet, blog item, or other resource bound to the
    project tag.

  • The discovery of a new (and trusted) iCalendar resource by any hub's curator.

  • Like delicious, FriendFeed can support this kind of contract by empowering
    users to define sets of online resources and share them as feeds.

    With these kinds of contracts in place, interesting possibilities
    arise. Here's one that tickles me: The elmcity service doesn't yet
    need to implement its own system of user registration. If my approach
    to decentralized event curation takes off, I might someday need to create a
    registration system and require curators to use it. But for now it's
    trivial for me to bookmark a delicious account and tag it as one that
    the service regards as authoritative for a hub.

    Likewise, the folks who provide the feeds trusted by curators and
    aggregated by hubs don't yet have to register with the service. For
    now, providers need only make feeds known to curators, one way or
    another. And curators who deem those feeds worthy of inclusion need
    only bookmark and tag them.

    These are the kinds of workflows that can arise when informal
    contracts are in place. They're cheap to create and easy to evolve.
    Here's a final example. If you're a curator who adds a new feed to a
    hub, you naturally want to see your new events merged into the hub as soon
    as possible. Normally you'd have to wait until the next aggregation
    cycle, which might be as long as eight hours. So I had to come up with a way for
    a curator to send an authenticated message to the service, telling it to
    short-circuit the wait and gather new events right away.

    My first thought was that here, finally, was the reason I'd need to build my
    own user registration system and require curators to use it. My second
    thought was,
    hang on, I already trust their delicious accounts, why not use those accounts as
    channels for authenticated messages? That's doable, but I didn't find
    a graceful way to do it. My third thought was: What about Twitter?
    Hence the Twitter contract:

    Among the settings that a curator conveys to the elmcity service, by way of a trusted delicious account, is the Twitter account to be used in connection with that curator's elmcity hub. The service will follow the curator at that Twitter account. By doing so, it enables the curator to send authentic messages to the service. The vocabulary used by those messages will initially be just a single verb: start. When the service receives the start message from a hub, it will reaggregate the hub's list of feeds.

    In a companion how-to article on O'Reilly Answers, I
    show how this piece of the service works. What's relevant here is that
    the code doesn't have to do very much. That's because the informal
    contract makes it possible to reuse Twitter in a novel way, as a
    channel for authenticated messages.

    In a world full of services like delicious, FriendFeed, and Twitter --
    services that can route feeds of data based on user-defined
    vocabularies -- you don't have to be a programmer to create useful
    mashups. You just have to understand, and find ways to apply, the
    Principle of Informal Contracts.


    June 29 2010

    Four short links: 29 June 2010

    1. The Diary of Samuel Pepys -- a remarkable mashup of historical information and literature in modern technology to make the Pepys diaries an experience rather than an object. It includes historical weather, glosses, maps, even an encyclopedia. (prompted by Jon Udell)
    2. The Tonido Plug Server -- one of many such wall-wart sized appliances. This caught my eye: CodeLathe, the folks behind Tonido, have developed a web interface and suite of applications. The larger goal is to get developers to build other applications for inclusion in Tonido’s own app store.
    3. Wikileaks Fails "Due Diligence" Review -- interesting criticism of Wikileaks from Federation of American Scientists. “Soon enough,” observed Raffi Khatchadourian in a long profile of WikiLeaks’ Julian Assange in The New Yorker (June 7), “Assange must confront the paradox of his creation: the thing that he seems to detest most-power without accountability-is encoded in the site’s DNA, and will only become more pronounced as WikiLeaks evolves into a real institution.” (via Hacker News)
    4. Yahoo Style Guide -- a paper book, but also a web site with lots of advice for those writing online.

    May 07 2010

    Four short links: 7 May 2010

    1. Flash is Not a Right (Ian Bogost) -- I worry that we're losing a sense of diversity in computation. This seems to be happening at both the formal and informal levels. Georgia Tech's computer science bachelor's degree doesn't require a language survey class, for example (although one is offered as an elective). This year in the Computational Media curriculum committee, we've been discussing the idea of creating a history of programming languages course as a partial salve, one that would explain how and why a number of different languages and environments evolved. Such a course would explicitly focus on how to learn new languages and environments, since that process is not always obvious. It's a wonderful and liberating feeling to become familiar with and then master different environments, and everyone truly interested in computing should experience that joy.
    2. What Every Developer Should Know About URLs -- a lot of detail of how the pieces hook together. (via bengebre on Delicious)
    3. Ryzom is an Open Source MMORPG -- existing game, now GNU Affero licensed code for server, client, and tools, with CC-BY-SA licensed assets. (via Slashdot)
    4. Remix American High Style with Polyvore -- the greatest challenge to heritage institutions is irrelevance, not penury. Brooklyn Museum is unsurpassed in creating relevance for its collections and its existence, and they do it by reaching out, where people are and not expecting them to come directly to us. If you're at a gallery, museum, library, or archive and your first reaction is to protect what you've got, you're doing it wrong. Report to Brooklyn for make-up classes. (via auchmill on Twitter)

    November 21 2009

    Jetzt live: iRights in der Sendung Trackback von Radio Fritz

    Von 18-20 Uhr gibt es heute bei Radio Fritz wieder die Sendung Trackback. In dieser geht es um aktuelle Fragen die das Netz oder die Blogosphäre betreffen. Ich bin heute zu Gast und werde auch etwas zum geforderten Leistungsschutzrecht für Presseverlage sagen. Dazu geht es um das zugespielte und vor wenigen Tagen von uns veröffentlichte Gutachten des wissenschaftlichen Dienstes des Bundestages zum Leistungsschutzrecht. Zu Gast in der Sendung sind auch Rechtsanwalt Thomas Stadler der etwas über Abmahnungen sagt, Constanze Kurz vom Chaos Computer Club, Ben Stiller der über Mashups und Urheberrecht spricht sowie der Blogger K37 der “ein hermetisches Cafe” betreibt. Was immer das auch ist. Eine Beschreibung der Sendung sowie der Podcast der Sendung findet sich auf der Trackback-Website.

    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.
    No Soup for you

    Don't be the product, buy the product!

    YES, I want to SOUP ●UP for ...