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

December 20 2010

Why web services should be released as free software

Previous section:

Why clouds and web services will continue to take over computing

Let's put together a pitch for cloud and web service providers. We have two hurdles to leap: one persuading them how they'll benefit by releasing the source code to their software, and one addressing their fear of releasing the source code. I'll handle both tasks in this section, which will then give us the foundation to look at a world of free clouds and web services.


Cloud and web service providers already love free software

Reasons for developing software as open source have been told and
retold many times; popular treatments include Eric S. Raymond's
essays in the collection

The Cathedral and the Bazaar
(which O'Reilly puts out
in print),
and Yochai Benkler's Wealth of Networks
(available online as a
PDF
as well as the basis for a
wiki,
and published by Yale University Press). But cloud and web service
companies don't have to be sold on free software--they use it all the
time.

The cornucopia of tools and libraries produced by projects such as the
open source Ruby on Rails make it the first stop on many
services' search for software. Lots of them still code pages in
other open source tools and languages such as PHP and jQuery. Cloud
providers universally base their offerings on Linux, and many use open
source tools to create their customers' virtual systems.
(Amazon.com currently bases its cloud offerings on href="http://www.xen.org/">Xen, and
KVM, heavily backed
by Red Hat, is also a contender.) The best monitoring tools are also
free software. In general, free software is sweeping through the
cloud. (See also

Open Source Projects for Cloud on Rise, According to Black Duck Software Analysis
).

So cloud and web service providers live the benefits of free software
every day. They know the value of communities who collaborate to
improve and add new layers to software. They groove on the convenience
of loading as much software they want on any systems without
struggling with a license server. They take advantage of frequent
releases with sparkling new features. And they know that there are
thousands of programmers out in the field familiar with the software,
so hiring is easier.

And they give back to open source communities too: they contribute
money, developer time, and valuable information about performance
issues and other real-life data about the operation of the software.

But what if we ask them to open their own code? We can suggest that
they can have better software by letting their own clients--the
best experts in how their software is used--try it out and look
over the source for problems. Web service developers also realize that
mash-ups and extensions are crucial in bringing them more traffic, so
one can argue that opening their source code will make it easier for
third-party developers to understand it and write to it.

Web and cloud services are always trying to hire top-notch programmers
too, and it's a well-established phenomenon that releasing the
source code to a popular product produces a cadre of experts out in
the field. Many volunteers submit bug fixes and enhancements in order
to prove their fitness for employment--and the vendors can pick
up the best coders.

These arguments might not suffice to assail the ramparts of vendors'
resistance. We really need to present a vision of open cloud computing
and persuade vendors that their clients will be happier with services
based on free software. But first we can dismantle some of the fear
around making source code open.

No reason to fear opening the source code

Some cloud and web providers, even though they make heavy use of free
software internally, may never have considered releasing their own
code because they saw no advantages to it (there are certainly
administrative and maintenance tasks associated with opening source
code). Others are embarrassed about the poor structure and coding
style of their fast-changing source code.

Popular methodologies for creating Web software can also raise a
barrier to change. Companies have chosen over the past decade to
feature small, tight-knit teams who communicate with each other and
stakeholders informally and issue frequent software releases to try
out in the field and then refine. Companies find this process more
"agile" than the distributed, open-source practice of putting
everything in writing online, drawing in as broad a range of
contributors as possible, and encouraging experiments on the side. The
agile process can produce impressive results quickly, but it places an
enormous burden on a small group of people to understand what clients
want and massage it into a working product.

We can't move cloud and SaaS sites to free software, in any case, till
we address the fundamental fear some of these sites share with
traditional proprietary software developers: that someone will take
their code, improve it, and launch a competing service. Let's turn to
that concern.

If a service releases its code under the GNU Affero General Public
License, as mentioned in the
previous section,
anyone who improves it and runs a web site with the improved code is
legally required to release their improvements. So we can chip away at
the resistance with several arguments.

First, web services win over visitors through traits that are
unrelated to the code they run. Traits that win repeat visits include:


  • Staying up (sounds so simple, but needs saying)

  • The network effects that come from people inviting their friends or
    going where the action is--effects that give the innovative
    vendor a first-mover advantage

  • A site's appearance and visual guides to navigation, which
    includes aspects that can be trademarked

  • Well-designed APIs that facilitate the third-party applications
    mentioned earlier

So the source code to SaaS software isn't as precious a secret
as vendors might think. Anyway, software is more and more a commodity
nowadays. That's why a mind-boggling variety of JavaScript
frameworks, MVC platforms, and even whole new programming languages
are being developed for the vendors' enjoyment. Scripting
languages, powerful libraries, and other advances speed up the pace of
development. Anyone who likes the look of a web service and wants to
create a competitor can spin it up in record time for low cost.

Maybe we've softened up the vendors some. Now, on to the
pinnacle of cloud computing--and the high point on which this
article will end--a vision of the benefits a free cloud could
offer to vendors, customers, and developers alike.

Next section:
Reaching the pinnacle: truly open web services and clouds.

December 17 2010

Why clouds and web services will continue to take over computing

Series

What are the chances for a free software cloud?

  • Resolving the contradictions between web services, clouds, and open source (12/13)
  • Defining clouds, web services, and other remote computing (12/15)
  • Why clouds and web services will continue to take over computing (12/17)
  • Why web services should be released as free software (12/20)
  • Reaching the pinnacle: truly open web services and clouds (12/22)

Additional posts in this 5-part series are available here.

Previous section:

Definitions: Clouds, web services, and other remote computing

The tech press is intensely occupied and pre-occupied with analyzing the cloud from a business point of view. Should you host your operations in a cloud provider? Should you use web services for office work? The stream of articles and blogs on these subjects show how indisputably the cloud is poised to take over.

But the actual conclusions these analysts reach are intensely
conservative: watch out, count up your costs carefully, look closely
at

regulations and liability issues
that hold you back, etc.
The analysts are obsessed with the cloud, but they're not
encouraging companies to actually use it--or at least
they're saying we'd better put lots of thought into it
first.

My long-term view convinces me we all WILL be in the cloud.
No hope in bucking the trend. The advantages are just too compelling.

I won't try to replicate here the hundreds and hundreds of
arguments and statistics produced by the analysts. I'll just run
quickly over the pros and cons of using cloud computing and web
services, and why they add up to a ringing endorsement. That will help
me get to the question that really concerns this article: what can we
do to preserve freedom in the cloud?

The promise of the cloud shines bright in many projections. The
federal government has committed to a "Cloud First" policy in its
recent

Information Technology reform plan
.
The companies offering IaaS, and Paas, and SaaS promulgate
mouth-watering visions of their benefits. But some of the advantages I
see aren't even in the marketing literature--and some of them, I bet,
could make even a free software advocate come around to appreciating
the cloud.

Advantages of cloud services

The standard litany of reasons for moving to IaaS or PaaS can be
summarized under a few categories:

Low maintenance

No more machine rooms, no more disk failures (that is, disk failures you know about and have to deal with), no more late-night calls to go in and reboot a critical server.

These simplifications, despite the fears of some Information
Technology professionals, don't mean companies can fire their system
administrators. The cloud still calls for plenty of care and
feeding. Virtual systems go down at least as often as physical ones,
and while the right way to deal with system failures is to automate
recovery, that takes sophisticated administrators. So the system
administrators will stay employed and will adapt. The biggest change
will be a shift from physical system management to diddling with
software; for an amusing perspective on the shift see my short story

Hardware Guy
.


Fast ramp-up and elasticity

To start up a new operation, you no longer have to wait for hardware to arrive and then lose yourself in snaking cables for hours. Just ask the cloud center to spin up as many virtual systems as you want.

Innovative programmers can also bypass IT management, developing new
products in the cloud. Developers worry constantly whether their
testing adequately reproduces the real-life environment in which
production systems will run, but if both the test systems and the
final production systems run in the cloud, the test systems can match
the production ones much more closely.

The CIO of O'Reilly Media, citing the goal of directing

60 percent of IT spending into new projects
,
has made internal and external cloud computing into pillars of

O'Reilly's IT strategy
.

Because existing companies have hardware and systems for buying
hardware in place already, current cloud users tend to come from
high-tech start-ups. But any company that wants to launch a new
project can benefit from the cloud. Peaks and troughs in usage can
also be handled by starting and stopping virtual systems--you
just have to watch how many get started up, because a lack of
oversight can incur run-away server launches and high costs.

Cost savings

In theory, clouds provide economies of scale that undercut anything an individual client could do on their own. How can a private site, chugging away on a few computers, be more efficient than thousands of fungible processors in one room under the eye of a highly trained expert, all strategically located in an area with cheap real estate and electricity?

Currently, the cost factor in the equation is not so cut and dried.
Running multiple servers on a single microprocessor certainly brings
savings, although loads have to be balanced carefully to avoid slowing
down performance unacceptably. But running processors constantly
generates heat, and if enough of them are jammed together the costs of
air conditioning could exceed the costs of the computers. Remote
computing also entails networking costs.

It will not take long, however, for the research applied by cloud
vendors to pay off in immense efficiencies that will make it hard for
organizations to justify buying their own computers.


Elasticity and consolidation make IaaS so attractive that large
companies are trying to build "private clouds" and bring all the
organization's server hardware into one department, where the
hardware is allocated as virtual resources to the rest of the company.
These internal virtualization projects don't incur some of the
disadvantages that this paper address, so I won't consider them
further.

Advantages of web services

SaaS offers some benefits similar to IaaS and PaaS, but also
significant differences.

Low maintenance

No more installation, no more upgrades, no more incompatibilities with other system components or with older versions of the software on other people's systems. Companies licensing data, instead of just buying it on disks, can access it directly from the vendor's site and be sure of always getting the most recent information.


Fast ramp-up and elasticity

As with IaaS, SaaS frees staff from running every innovation past the IT group. They can recreate their jobs and workflows in the manner they want.


Feedback

To see what's popular and to prioritize future work, companies love to know how many people are using a feature and how long they spend in various product functions. SaaS makes this easy to track because it can log every mouse click.

Enough of the conventional assessment. What hidden advantages lie in clouds and web services?

What particularly should entice free and open software software advocates is web services' prospects for making money. Although free software doesn't have to be offered cost-free (as frequently assumed by those who don't know the field), there's no way to prevent people from downloading and installing it, so most of the money in free software is made through consulting and additional services. Web services allow subscriptions instead, a much more stable income. Two popular content management systems exemplify this benefit: WordPress offers hosting at wordpress.com and Drupal at drupalgardens.com, all while offering their software as open source.

But I find another advantage to web services. They're making
applications better than they ever have been in the sixty-year history
of application development.

Compare your own experiences with stand-alone software to web sites. The quality of the visitor's experience on a successful web site is much better. It's reminiscent of the old cliché about restaurant service in capitalist versus socialist economies.

According to this old story, restaurants in capitalist countries
depend on repeat business from you and your friends, driving the
concern for delivering a positive customer experience from management
down to the lowest level of the wait staff. In a socialist economy,
supposedly, the waiters know they will get paid no matter whether you
like their service or not, so they just don't try. Furthermore,
taking pains to make you happy would be degrading to them as heroes of
a workers' society.

I don't know whether this phenomenon is actually true of restaurants,
but an analogous dynamic holds in software. Web sites know that
visitors will vanish in half a second if the experience is not
immediately gripping, gratifying, and productive. Every hour of every
day, the staff concentrate on the performance and usability of the
site. Along with the business pressure on web services to keep users
on the page, the programmers there can benefit from detailed feedback
about which pages are visited, in which order, and for how long.

In contrast, the programmers of stand-alone software measure
their personal satisfaction by the implementation of complex and
sophisticated calculations under the product's surface. Creating
the user interface is a chore relegated to less knowledgeable staff.

Whatever the reason, I find the interfaces of proprietary as well as
free software to be execrable, and while I don't have statistics to
bolster my claim. I think most readers can cite similar experiences.
Games are the main exception, as well as a few outstanding consumer
applications, but these unfortunately do not seem a standard for the
vast hoards of other programmers to follow.

Moving one's aching fingers from stand-alone software to a web
service brings a sudden rush of pleasure, affirming what working with
computers can be. A bit of discipline in the web services world would
be a good cold bath for the vendors and coders.


Drawbacks of clouds and web services

So why are the analysts and customers still wary of cloud computing? They have their reasons, but some dangers are exaggerated.

Managers responsible for sensitive data feel a visceral sense of vulnerability when they entrust that data to some other organization. Web services have indeed had breaches, because they are prisoners of the twin invariants that continue to ensure software flaws: programmers are human, and so are administrators. Another risk comes when data is transmitted to a service such as Amazon.com's S3, a process during which it be seen or even in theory altered.

Still, I expect the administrators of web and cloud services to be better trained and more zealous in guarding against security breaches than the average system administrator at a private site. The extra layer added by IaaS also creates new possibilities. An article called "Security in the Cloud" by Gary Anthes, published in the November 2010 Communications of the ACM, points to research projects by Hewlett-Packard and IBM that would let physical machines monitor the virtual machines running on them for viruses and other breaches of security, a bit like a projectionist can interrupt a movie.

A cloud or web service provider creates some risk just because it
provides a tasty target to intruders, who know they can find thousands
of victims in one place. On the other hand, if you put your data in
the cloud, you aren't as likely to lose it to some drive-by
trouble-seeker picking it up off of a wireless network that your
administrator failed to secure adequately, as famously happened to
T.J. Maxx (and they weren't alone).

And considering that security experts suspect most data breaches to be
internal, putting data in the cloud might make it more secure by
reducing its exposure to employees outside of the few programmers or
administrators with access rights. If the Department of Defense had
more systems in the cloud, perhaps it wouldn't have suffered such a
sinister security breach in 2008 through a

flash drive with a virus
.

In general, the solution to securing data and transactions is to
encrypt everything. Encrypting the operating systems loaded in IaaS,
for instance, gives the client some assurance that no one can figure
out what it's doing in the cloud, even if another client or even the
vendor itself tries to snoop. If some technological earthquake
undermines the integrity of encryption technologies--such as the
development of a viable quantum computer--we'll have to rethink the
foundations of the information age entirely anyway.

The main thing to remember is that most data breaches are caused by
lapses totally unrelated to how servers are provisioned: they happen
because staff stored unencrypted data on laptops or mobile devices,
because intruders slipped into applications by exploiting buffer
overflows or SQL injection, and so on. (See, for instance, a
U.S. Health & Human Services study saying that
"Laptop theft
is the most prevalent cause of the breach of health information
affecting more than 500 people.
")

Regulations such as HIPAA can rule out storing some data off-site, and
concerns about violating security regulations come up regularly during
cloud discussions. But these regulations affect only a small amount of
the data and computer operations, and the regulations can be changed
once the computer industry shows that clouds are both valuable and
acceptably secure.

Bandwidth is a concern, particularly in less technologically developed
parts of the world (like much of the United States, come to think of
it), where bandwidth is inadequate. But in many of these areas, people
often don't even possess computers. SaaS is playing a major role
in underdeveloped areas because it leverages the one type of computer
in widespread use (the cell phone) and the one digital network
that's widely available (the cellular grid). So in some ways,
SaaS is even more valuable in underdeveloped areas, just in a
different form from regions with high bandwidth and universal access.

Nevertheless, important risks and disadvantages have been identified
in clouds and web services. IaaS and PaaS are still young enough (and
their target customers sophisticated enough) for the debate to keep up
pretty well with trends; in contrast, SaaS has been crying out quite a
while for remedies to be proposed, such as the
best practices
recently released by the Consumer Federation of America. This article
will try to raise the questions to a higher level, to find more
lasting solutions to problems such as the following.

Availability

Every system has down time, but no company wants to be at the mercy of a provider that turns off service, perhaps for 24 hours or more, because they failed to catch a bug in their latest version or provide adequate battery backup during a power failure.

When Wikileaks was forced off of Amazon.com's cloud service, it sparked outrage whose echo reached as far as a Wall Street Journal blog and highlighted the vulnerability of depending on clouds. Similarly, the terms of service on social networks and other SaaS sites alienate some people who feel they have legitimate content that doesn't pass muster on those sites.

Liability

One of the big debates in the legal arena is how to apportion blame when a breach or failure happens in a cascading service, where one company leases virtual systems in the cloud to provide a higher-level service to other companies.


Reliability

How can you tell whether the calculation that a service ran over your corporate data produced the correct result? This is a lasting problem with proprietary software, which the free software developers argue they've solved, but which most customers of proprietary software have learned to live with and which therefore doesn't turn them against web services.

But upgrades can present a problem. When a new version of stand-alone
software comes out, typical consumers just click "Yes" on the upgrade
screen and live with the consequences. Careful system administrators
test the upgrade first, even though the vendor has tested it, in case
it interacts perniciously with some factor on the local site and
reveals a bug. Web services reduce everyone to the level of a passive
consumer by upgrading their software silently. There's no
recourse for clients left in the lurch.


Control

Leaving the software on the web service's site also removes all end-user choice. Some customers of stand-alone software choose to leave old versions in place because the new version removed a feature the customers found crucial, or perhaps just because they didn't want the features in the new version and found its performance worse. Web services offer one size to fit all.

Because SaaS is a black box, and one that can change behavior without
warning to the visitors, it can provoke concerns among people
sensitive about consistency and reliability. See my article

Results from Wolfram Alpha: All the Questions We Ever Wanted to Ask About Software as a Service
.

Privacy

Web services have been known to mine customer data and track customer behavior for marketing purposes, and have given data to law enforcement authorities. It's much easier to monitor millions of BlackBerry messages traveling through a single server maintained by the provider than the messages bouncing in arbitrary fashion among thousands of Sendmail servers. If a customer keeps the data on its own systems, law enforcement can still subpoena it, but at least the customer knows she's being investigated.

In the United States, furthermore, the legal requirements that investigators must meet to get data is higher for customers' systems than for data stored on a third-party site such as a web service. Recent Congressional hearings (discussed on O'Reilly's Radar site highlighted the need to update US laws to ensure privacy for cloud users).


These are knotty problems, but one practice could tease them apart:
making the software running clouds or web services open source.

A number of proponents for this viewpoint can be found, such as the Total Information Outsourcing group, as well as a few precedents. Besides the WordPress and Drupal services mentioned earlier, StatusNet runs the microblogging site identi.ca and opens up its code so that other people could run sites that interoperate with it. Source code for Google's AppEngine, mentioned earlier as a leading form of IaaS, has been offered for download by Google under a free license. Talend offers data integration and business intelligence as both free software and SaaS.

The Free Software Foundation, a leading free software organization that provides a huge amount of valuable software to Linux and other systems through the GNU project, has created a license called the GNU Affero General Public License that encourages open code for web services. When sites such as StatusNet release code under that license, other people are free to build web services on it but must release all their enhancements and bug fixes to the world as well.

What problems can be ameliorated by freeing the cloud and web service software? Can the companies who produced that software be persuaded to loosen their grip on the source code? And what could a world of free cloud and web services look like? That is where we will turn next.

Next section:
Why web services should be released as free software.

December 15 2010

Defining clouds, web services, and other remote computing

Series

What are the chances for a free software cloud?

  • Resolving the contradictions between web services, clouds, and open source (12/13)
  • Defining clouds, web services, and other remote computing (12/15)
  • Why clouds and web services will continue to take over computing (12/17)
  • Why web services should be released as free software (12/20)
  • Reaching the pinnacle: truly open web services and clouds (12/22)

Additional posts in this 5-part series are available here.

Technology commentators are a bit trapped by the term "cloud," which has been kicked and slapped around enough to become truly shapeless. Time for confession: I stuck the term in this article's title because I thought it useful to attract readers' attention. But what else should I do? To run away from "cloud" and substitute any other term ("web services" is hardly more precise, nor is the phrase "remote computing" I use from time to time) just creates new confusions and ambiguities.

So in this section I'll offer a history of services that have
led up to our cloud-obsessed era, hoping to help readers distinguish
the impacts and trade-offs created by all the trends that lie in the
"cloud."

Computing and storage

The basic notion of cloud computing is simply this: one person uses a
computer owned by another in some formal, contractual manner. The
oldest precedent for cloud computing is therefore timesharing, which
was already popular in the 1960s. With timesharing, programmers could
enter their programs on teletype machines and transmit them over
modems and phone lines to central computer facilities that rented out
CPU time in units of one-hundredth of a second.

Some sites also purchased storage space on racks of large magnetic
tapes. The value of storing data remotely was to recover from flood,
fire, or other catastrophe.

The two major, historic cloud services offered by the
Amazon.com--Elastic Compute Cloud (EC2) and Simple Storage Service
(S3)--are the descendants of timesharing and remote backup,
respectively.

EC2 provides complete computer systems to clients, who can request any
number of systems and dismiss them again when they are no longer
needed. Pricing is quite flexible (even including an option for an
online auction) but is essentially a combination of hourly rates and
data transfer charges.

S3 is a storage system that lets clients reserve as much or as little
space as needed. Pricing reflects the amount of data stored and the
amount of data transferred in and out of Amazon's storage. EC2 and S3
complement each other well, because EC2 provides processing but no
persistent storage.

Timesharing and EC2-style services work a bit like renting a community
garden. Just as community gardens let apartment dwellers without
personal back yards grow fruits and vegetables, timesharing in the
1960s brought programming within reach of people who couldn't
afford a few hundred thousand dollars to buy a computer. All the
services discussed in this section provide hardware to people who run
their own operations, and therefore are often called
Infrastructure as a Service or IaaS.

We can also trace back cloud computing in another direction as the
commercially viable expression of grid computing, an idea
developed through the first decade of the 2000s but whose
implementations stayed among researchers. The term "grid"
evokes regional systems for delivering electricity, which hide the
origin of electricity so that I don't have to strike a deal with
a particular coal-burning plant, but can simply plug in my computer
and type away. Similarly, grid computing combined computing power from
far-flung systems to carry out large tasks such as weather modeling.
These efforts were an extension of earlier cluster technology
(computers plugged into local area networks), and effectively
scattered the cluster geographically. Such efforts were also inspired
by the well-known
SETI@home program,
an early example of Internet crowdsourcing that millions of people have
downloaded to help process signals collected from telescopes.

Another form of infrastructure became part of modern life in the 1990s
when it seemed like you needed your own Web site to be anybody.
Internet providers greatly expanded their services, which used to
involve bare connectivity and an email account. Now they also offer
individualized Web sites and related services. Today you can find a
wealth of different hosting services at different costs depending on
whether you want a simple Web presence, a database, a full-featured
content management system, and so forth.

These hosting services keep costs low by packing multiple users onto
each computer. A tiny site serving up occasional files, such as my own
praxagora.com, needs nothing that
approaches the power of a whole computer system. Thanks to virtual
hosting, I can use a sliver of a web server that dozens of other sites
share and enjoy my web site for very little cost. But praxagora.com
still looks and behaves like an independent, stand-alone web server.
We'll see more such legerdemain as we explore virtualization and
clouds further.

The glimmer of the cloud in the World Wide Web

The next great breakthrough in remote computing was the concept of an
Application Service Provider. This article started with one
contemporary example, Gmail. Computing services such as payroll
processing had been outsourced for some time, but in the 1990s, the
Web made it easy for a business to reach right into another
organization's day-to-day practice, running programs on central
computers and offer interfaces to clients over the Internet. People
used to filling out forms and proceeding from one screen to the next
on a locally installed program could do the same on a browser with
barely any change in behavior.

Using an Application Service Provider is a little like buying a house
in the suburbs with a yard and garden, but hiring a service to
maintain them. Just as the home-owner using a service doesn't
have to get his hands dirty digging holes for plants, worry about the
composition of the lime, or fix a broken lawnmower, companies who
contract with Application Service Providers don't have to
wrestle with libraries and DLL hell, rush to upgrade software when
there's a security breach, or maintain a license server. All
these logistics are on the site run by the service, hidden away from
the user.

Early examples of Application Service Providers for everyday personal
use include blogging sites such as blogger.com and wordpress.com.
These sites offer web interfaces for everything from customizing the
look of your pages to putting up new content (although advanced users
have access to back doors for more complex configuration).

Interestingly, many companies recognized the potential of web browsers
to deliver services in the early 2000s. But browsers' and
JavaScript's capabilities were too limited for rich interaction.
These companies had to try to coax users into downloading plugins that
provided special functionality. The only plugin that ever caught on
was Flash (which, of course, enables many other applications). True
web services had to wait for the computer field to evolve along
several dimensions.

As broadband penetrated to more and more areas, web services became a
viable business model for delivering software to individual users.
First of all, broadband connections are "always on," in
contrast to dial-up. Second, the HttpRequest extension allows browsers
to fetch and update individual snippets of a web page, a practice that
programmers popularized under the acronym AJAX.

Together, these innovations allow web applications to provide
interfaces almost as fast and flexible as native applications running
on your computer, and a new version of HTML takes the process even
farther. The movement to the web is called Software as a
Service
or SaaS.

The

pinned web site feature introduced in Internet Explorer 9

encourages users to create menu items or icons representing web sites,
making them as easy to launch as common applications on their
computer. This feature is a sign of the shift of applications from
the desktop to the Web.

Every trend has its logical conclusion, even if it's farther
than people are willing to go in reality. The logical conclusion of
SaaS is a tiny computer with no local storage and no software except
the minimal operating system and networking software to access servers
that host the software to which users have access.

Such thin clients were already prominent in the work world
before Web services became popular; they connected terminals made by
companies such as Wyse with local servers over cables. (Naturally,
Wyse has

recently latched on to the cloud hype
.)
The Web equivalent of thin clients is mobile devices such as iPhones
with data access, or
Google Chrome OS,
which Google is hoping will wean people away from popular software
packages in favor of Web services like Google Docs. Google is planning
to release a netbook running Chrome OS in about six months. Ray
Ozzie, chief software architect of Microsoft, also speaks of an
upcoming reality of
continuous cloud services delivered to thin appliances
.
The public hasn't followed the Web services revolution this far,
though; most are still lugging laptops.

Data, data everywhere

Most of the world's data is now in digital form, probably in some
relational database such as Oracle, IBM's DB2, or MySQL. If the
storage of the data is anything more formal than a spreadsheet on some
clerical worker's PC (and a shameful amount of critical data is still
on those PCs), it's probably already in a kind of cloud.

Database administrators know better than to rely on a single disk to
preserve those millions upon millions of bytes, because tripping over
an electric cable can lead to a disk crash and critical information
loss. So they not only back up their data on tape or some other
medium, but duplicate it on a series of servers in a strategy called
replication. They often transmit data second by second over
hundreds of miles of wire so that flood or fire can't lead to
permanent loss.

Replication strategies can get extremely complex (for instance, code
that inserts the "current time" can insert different
values as the database programs on various servers execute it), and
they are supplemented by complex caching strategies. Caches are
necessary because public-facing systems should have the most commonly
requested data--such as current pricing information for company
products--loaded right into memory. An extra round-trip over the
Internet for each item of data can leave users twiddling their thumbs in
annoyance. Loading or "priming" these caches can take
hours, because primary memories on computers are so large.

The use of backups and replication can be considered a kind of private
cloud, and if a commercial service becomes competitive in reliability
or cost, we can expect businesses to relax their grip and entrust
their data to such a service.

We've seen how Amazon.com's S3 allowed people to store
data on someone else's servers. But as a primary storage area,
S3 isn't cost-effective. It's probably most valuable when
used in tandem with an IaaS service such as EC2: you feed your data
from the data cloud service into the compute cloud service.

Some people also use S3, or one of many other data storage services,
as a backup to their local systems. Although it may be hard to get
used to trusting some commercial service over a hard drive you can
grasp in your hand, the service has some advantages. They are actually
not as likely as you are to drop the hard drive on the floor and break
it, or have it go up in smoke when a malfunctioning electrical system
starts a fire.

But data in the cloud has a much more powerful potential. Instead of
Software as a Service, a company can offer its data online for others
to use.

Probably the first company to try this radical exposure of data was
Amazon.com, who can also be credited for starting the cloud services
mentioned earlier. Amazon.com released a service that let programmers
retrieve data about its products, so that instead of having to visit
dozens of web pages manually and view the data embedded in the text,
someone could retrieve statistics within seconds.

Programmers loved this. Data is empowering, even if it's just
sales from one vendor, and developers raced to use the application
programming interface (API) to create all kinds of intriguing
applications using data from Amazon. Effectively, they leave it up to
Amazon to collect, verify, maintain, search through, and correctly
serve up data on which their applications depend. Seen as an aspect of
trust, web APIs are an amazing shift in the computer
industry.

Amazon's API was a hack of the Web, which had been designed to
exchange pages of information. Like many other Internet services, the
Web's HTTP protocol offers a few basic commands: GET, PUT, POST,
and DELETE. The API used the same HTTP protocol to get and put
individual items of data. And because it used HTTP, it could easily be
implemented in any language. Soon there were libraries of programming
code in all popular languages to access services such as
Amazon.com's data.

Another early adopter of Web APIs was Google. Because its
Google Maps service exposed
data in a program-friendly form, programmers started to build useful
services on top of it. One famous example combined Google Maps with a
service that published information on properties available for rent;
users could quickly pull up a map showing where to rent a room in
their chosen location. Such combinations of services were called
mash-ups, with interesting cultural parallels to the
practices of musicians and artists in the digital age who combine
other people's work from many sources to create new works.

The principles of using the Web for such programs evolved over several
years in the late 1990s, but the most popular technique was codified
in a 2000 PhD thesis by HTTP designer Roy Thomas Fielding, who
invented the now-famous term REST (standing for Representational State
Transfer) to cover the conglomeration of practices for defining URLs
and exchanging messages. Different services adhere to these principles
to a greater or lesser extent. But any online service that wants to
garner serious, sustained use now offers an API.

A new paradigm for programmers

SaaS has proven popular for programmers. In 1999, a company named VA
Linux created a site called
SourceForge
with the classic SaaS goal of centralizing the administration of
computer systems and taking that burden off programmers' hands. A
programmer could upload his program there and, as is typical for free
software and open source, accept code contributions from anyone else
who chose to download the program.

VA Linux at that time made its money selling computers that ran the
GNU/Linux operating system. It set up SourceForge as a donation to the
free software community, to facilitate the creation of more free
software and therefore foster greater use of Linux. Eventually the
hardware business dried up, so SourceForge became the center of the
company's business: corporate history anticipated cloud
computing history.

SourceForge became immensely popular, quickly coming to host hundreds
of thousands of projects, some quite heavily used. It has also
inspired numerous other hosting sites for programmers, such as
Github. But these sites don't
completely take the administrative hassle out of being a programmer.
You still need to run development software--such as a compiler
and debugger--on your own computer.

Google leapt up to the next level of programmer support with
Google App Engine,
a kind of programmer equivalent to Gmail or
Google Docs.
App Engine is a cocoon within which you can plant a software larva and
carry it through to maturity. Like SaaS, the programmer does the
coding, compilation, and debugging all on the App Engine site. Also
like SaaS, the completed program runs on the site and offers a web
interface to the public. But in terms of power and flexibility, App
Engine is like IaaS because the programmer can use it to offer any
desired service. This new kind of development paradigm is called
Platform as a Service or PaaS.

Microsoft offers both IaaS and PaaS in its
Windows Azure
project.

Hopefully you now see how various types of remote computing are alike,
as well as different.

December 13 2010

Resolving the contradictions between web services, clouds, and open source

Series

What are the chances for a free software cloud?

Additional posts in this 5-part series are available here.

Predicting trends in computer technology is an easy way to get into trouble, but two developments have been hyped so much over the past decade that there's little risk in jumping on their bandwagons: free software and cloud computing. What's odd is that both are so beloved of crystal-gazers, because on the surface they seem incompatible.

The first trend promises freedom, the second convenience. Both freedom and convenience inspire people to adopt new technology, so I believe the two trends will eventually coexist and happily lend power to each other. But first, the proponents of each trend will have to get jazzed up about why the other trend is so compelling.

Freedom is promised by the free and open source software movement. Its
foundation is the principle of radical sharing: the knowledge one
produces should be offered to others. Starting with a few
break-through technologies that surprised outsiders by coming to
dominate their industries--the GNU C compiler, the Linux kernel,
the Apache web server--free software has insinuated itself into
every computing niche.

The trend toward remote computing--web services and the vaguely
defined cloud computing--promises another appealing kind of
freedom: freedom from having to buy server hardware and set up
operations, freedom from installations and patches and upgrades,
freedom in general from administrative tasks. Of course, these
advantages are merely convenience, not the kind of freedom championed
by the free software movement.

Together with the mobile revolution (not just programs on cell phones,
but all kinds of sensors, cameras, robots, and specialized devices for
recording and transmitting information) free software and remote
computing are creating new environments for us to understand
information, ourselves, and each other.

The source of the tension

Remote computing, especially the layer most of us encounter as web
services, is offered on a take-it-or-leave-it basis. Don't like
Facebook's latest change to its privacy settings? (Or even where
it locates its search box?) Live with it or break your Facebook habit
cold turkey.

Free software, as we'll see, was developed in resistance to such
autocratic software practices. And free software developers were among
the first to alert the public about the limitations of clouds and web
services. These developers--whose ideals are regularly challenged
by legal, social, and technological change--fear that remote
computing undermines the premises of free software. To understand the
tension, let's contrast traditional mail delivery with a popular
online service such as
Gmail, a textbook example of a web
service familiar to many readers.

For years, mail was transmitted by free software. The most popular
mail server was Sendmail, which could stand with the examples I listed
at the beginning of this article as one of earliest examples of free
software in widespread use. Sendmail's source code has been
endlessly examined, all too often for its many security flaws.

Lots of organizations still use free software mail servers, even
though in the commercial world, Microsoft's closed-source
Exchange is the standard. But organizations are flocking now to Gmail,
which many people find the most appealing interface for email.

Not only is Gmail closed, but the service would remain closed even if
Google released all the source code. This is because nobody who uses
Gmail software actually loads it on their systems (except some
JavaScript that handles user interaction). We all simply fire up a
browser to send a message to code running on Google servers. And if
Google hypothetically released the source code and someone set up a
competing Gmail, that would be closed for the same reason. A web
service runs on a privately owned computer and therefore is always
closed.

So the cloud--however you define it--seems to render the notion of
software freedom meaningless. But things seem to get even worse. The
cloud takes the client/server paradigm to its limit. There is forever
an unbreachable control gap between those who provide the service and
those who sign up for it.

And this is apparently a step backward in computing history. Closed,
proprietary software erected a gateway between the all-powerful
software developers and the consumers of the software. Free software
broke the gate down by giving the consumers complete access to source
code and complete freedom to do what they wanted. Amateurs around the
world have grabbed the opportunity to learn programming techniques
from free software and to make it fit their whims and needs. Now, once
again, software hidden behind a server commands the user to relinquish
control--and as the popularity of Gmail and other services show,
users are all too ready to do it.

Cloud computing is leading to the bifurcation of computing into a
small number of developers with access to the full power and
flexibility that computers can offer, contrasted with a world full of
small devices offering no say in what the vendors choose for us to
run, a situation predicted in Jonathan Zittrain's book

The Future of the Internet
.

Tim Berners-Lee, inventor of the World Wide Web, as part of a major
Scientific American article,

criticized social networks like Facebook
as silos that commit the
sin of hoarding data entered by visitors instead of exposing it openly
on the Internet. Ho, Sir Berners-Lee, that's exactly why many visitors
use social networks: to share their personal thoughts and activities
with a limited set of friends or special-interest groups. Social
networks and their virtual walls therefore contribute to the potential
of the Internet as a place to form communities.

But Berners-Lee was airing his complaint as part of a larger point
about the value of providing data for new and unanticipated
applications, and his warning does raise the question of scale. If
Facebook-type networks became the default and people "lived" on them
all the time instead of the wider Web, opportunities for
interconnection and learning would diminish.

Complementary trends

But one would be jumping to conclusions to assume that cloud computing
is inimical to free software. Google is one of the world's great
consumers of free software, and a supporter as well. Google runs its
servers on Linux, and has placed it at the core of its fast-growing
Android mobile phone system. Furthermore, Google submits enhancements
to free software projects, releases many of its peripheral
technologies as open source, and runs projects such as
Summer of Code to develop
new free software programs and free software programmers in tandem.

This is the trend throughout computing. Large organizations with banks
of servers tend to run free software on them. The tools with which
they program and administer the servers are also free.

A "free software cloud" may seem to be an oxymoron, like
"non-combat troops." But I believe that free software and
remote computing were made for each other; their future lies together
and the sooner they converge, the faster they will evolve and gain
adoption. In fact, I believe a free software cloud--much more
than the "open cloud" that
many organizations are working on--lies
in our future. This series will explore the traits of each trend and
show why they are meant to join hands.

October 19 2010

Nationwide Health Information Network hackathon: Direct Project reaches milestone

When the Direct Project (a component of the Nationwide Health Information Network) announced its first hackathon yesterday I felt personally gratified as well as excited to see the achievement of this milestone. The hackathon will take place on October 27 and 28 and can benefit from the participation of any programmers using Java and C#.

The Nationwide Health Information Network is the U.S. government's
major open source initiative in health care. You could argue that
VistA, from the U.S. Department of Veterans Affairs, is more important
(it certainly is a vastly bigger code base), but VistA so far is
sparsely adopted outside the government, whereas the Nationwide Health
Information Network is positioned to become the platform for all
hospitals, clinics, doctors' offices, and other health care
institutions to exchange information throughout the country.

The basic goal of this network is to allow health care providers to
exchange data on patients who move from one institution to another.
This could be an everyday occurrence such as a referral, or an
emergency situation such as a patient's ER visit during travel. The
network will also facilitate the collection of data to government
agencies that do important work in health care statistics and
evidence-based medicine. What makes this all hard is the strict
privacy requirements that call for careful authentication and secure
data transfer; that's why special code is necessary. Intermediaries
are also required to help health care providers authenticate each
other, and help providers that don't have special security-enhanced
software to encrypt their data exchanges.

The original network rested a complex SOAP implementation that had
only scattered implementations and required most institutions to hire
consultants. The Direct Project will reimplement the security and
authentication through simpler protocols, starting with garden-variety
email.

Doctors span a wide range of technical capabilities. Some are barely
storefront operations who consider themselves lucky to have PCs with
consumer-grade email clients. Others can afford special software that
supports S/MIME for encryption. The Direct Project has to encompass
all these participants. So the interface presented to health care
providers will be as simple as possible, but the implementations have
to be sophisticated and flexible.

This project has been conducted with the highest degree of openness
from the start. Anyone who's interested can join a working group (I
dropped in on the Documentation and Testing group to review documents)
and a wide range of volunteers from major health care providers and
EHR vendors have been collaborating. From the conference calls and
email I've been on, things look very collegial and orderly. The
upcoming hackathon is the natural next stage in this open process.

The Nationwide Health Information Network has held hackathons before,
but this one is the first for the Direct subproject and shows that
it's reaching a viable stage. A reference implementation for the
platform is nearly ready, but that's only one node in a fairly
complicated architecture. For doctors to connect to the network,
client software and other mediators are needed.

So if you're a programmer with an interest in health care, check out
the hackathon. It's a chance to see where health care is going in the
United States, and help make it happen.

July 27 2010

Wrap-up of the health care IT track at O'Reilly's Open Source convention

The first health care track to be included in an O'Reilly conference covered all three days of sessions at last week's Open Source convention and brought us 22 talks from programmers, doctors, researchers, corporate heads, and health care advocates. We grappled throughout these three days--which included two popular and highly vocal Birds of a Feather gatherings--with the task of opening up health care.

It's not surprising that, given this was an open source conference,
the point we heard from speakers and participants over and over again
was how critical it is to have open data in health care, and how open
source makes open data possible. Like most commercial fields, health
care is replete with managers and technologists who don't believe open
source software can do the job of powering and empowering busy
clinicians in high-risk situations. Some of the speakers spent time
challenging that view.

I decided over the course of the week that the health care industry
has two traits that make it more conservative than many fields. On the
one hand, the level of regulation and certification is mind-boggling.
Hardly any technical job can be taken without a particular course of
training and a certificate. Privacy regulations--which are interpreted
somewhat differently at every clinic--get in the way of almost anyone
doing anything new. Software has to be certified too, not something
that software firms in most domains are accustomed to. All these
controls are in place for good reason, and help you feel safe
proffering your arm for a needle or popping the pills each day your
doctor told you to take.

Paradoxically, though, the health care field is also resistant to
change because the actors in it are so independent. Health care is the
most fragmented industry in the country, with 80% of medical practices
consisting of one or two physicians.

Doctors don't like to be told what to do. A lot of them are not
persuaded that they should supplement their expert opinion with the
results of evidence-based medicine and clinical decision support, the
big campaigns right now among health care researchers and leaders
within the Administration, notably the recent appointee Donald Berwick
at the Centers for Medicare and Medicaid Services.

And even medical researchers are hard to gather around one set of
standards for data, because each one is looking for new ways to cut
and crunch the results and believes his or her approach is special.

So these are the conditions that software developers and vendors have
to deal with. Beckoning us forward are the Administration's
"meaningful use" criteria, which list the things a health care record
system should do to improve health care and cut costs.

Open source definitely needs more commercial champions to bridge the
classic gap in packaging and support between the developer community
and the not-so-computer-savvy health care teams. We heard from three
such companies at the conference: href="http://www.mirthcorp.com/">Mirth, href="http://www.vxvista.org/">vxVistA, and href="http://medsphere.org">Medsphere.

Of the major projects in electronic health records presented at the
conference --VistA, Tolven,
and openEMR--two were developed for
purposes outside the mainstream U.S. health care industry (VistA for
the Veterans Administration and openEMR for developing countries).
Although all these projects can point to successful installations in
mainstream organizations, they haven't hit the critical mass that
makes inherently conservative health care practices feel comfortable
adopting them.

But in this specific area of electronic records, I think the
proprietary software vendors are equally challenged to show that they
can meet the nation's needs. After some thirty years, they have become
common only in large hospitals and penetrated only a small number of
those small providers I mentioned before. The percentage of health
care providers who use electronic health records is between 18 and the
low 20's.

Licensing can easily be $15,000 per year per doctor, which small
practices just don't have. I won't harp on this, because converting
old records costs more than the licenses, and converting your whole
workflow and staff behavior is harder still. More disturbing is that a
large number of providers who go through the strain of installing
electronic records find that they don't produce cost savings or other
benefits.

Electronic records have been a success at huge providers like Partners
in Massachusetts and Kaiser Permanente in California, but one speaker
reported that Kaiser had to spend one billion (yes, that's a "b")
dollars to implement the kinds of data exchange and quality control
functions specified by the meaningful use criteria.

But we have to look pass the question of who would win the race to
digitize the offices of doctors in the U.S.--and around the world--and
envision a more open health care system where data can drive
high-quality care. I covered the first two days of the health care
track in the following blogs:

href="http://radar.oreilly.com/2010/07/day-one-of-the-health-care-it.html">
Day one of the health care IT track at O'Reilly's Open Source
convention

href="http://radar.oreilly.com/2010/07/vista-scenarios-and-other-cont.html">
VistA scenarios, and other controversies at the Open Source health
care track

and I'll summarize the tracks from day 3 here.

Open source for the things that keep you alive


Karen Sandler, a lawyer from the Software Freedom Law Center,
spoke
about the hundreds of thousands of devices--pacemakers,
insulin delivery devices, defibrillators, and others--that are
implanted in people's bodies each year. These devices fail sometimes,
and although reports do not classify which failures are caused by
software problems, some of them pretty clearly are.

The FDA does not audit software as part of the approval process for
devices, although it occasionally requires the manufacturer to show it
the software when failures are reported. Devices are also controlled
by unencrypted messages over ordinary wireless connections. (The
manufacturers avoid encryption in order to spare the device's
battery.) In short, software with control over life and death is being
installed in millions of people with essentially no regulation.

Sandler's key policy call is to force the source code open for
auditing purposes. She also would like to see open hardware and give
the patients the right to alter both hardware and software, although
these are more remote possibilities. Sandler's talk, based both on
careful research and painful personal health experiences, drew a
sizeable audience and excited fervent sympathy. The talk was aptly
timed just as the SFLC released a href="http://www.softwarefreedom.org/news/2010/jul/21/software-defects-cardiac-medical-devices-are-life-/">report
on this issue.

HealthVault and open data on the web

Two brief talks from Microsoft programmers, href="http://www.oscon.com/oscon2010/public/schedule/detail/15292">
Vaibhav Bhandari and href="http://www.oscon.com/oscon2010/public/schedule/detail/14952">Teddy
Bachour, did a nice job of introducing key standards in the health
care field and showing how flexible, carefully designed tools could
turn those standards into tools for better patient and doctor control
over data.

I felt that standards were underrepresented in our health care track,
and scheduled a BOF the night before where we discussed some of the
general issues making standards hard to use. Bhandari showed a few of
the libraries that Microsoft HealthVault uses to make standards useful
ways to store and manipulate health data. Bachour showed the use of
Microsoft toolkits, some open source in CodePlex.

As an example of what programmers can do with these libraries and
toolkits, the Clinical Documentation Solution Accelerator enhances
Microsoft Word enhanced so that, as a doctor enters a report of a
patient visit, Word can prompt for certain fields and offer a
selection of valid keywords for such fields as diagnoses and
medications.

Data mining with open source tools

David Uhlman, who had spoken on Thursday about VistA and his company
ClearHealth, ended the
health care track with a href="http://www.oscon.com/oscon2010/public/schedule/detail/15242">dazzling
tour applying neural network analysis, genetic algorithms,
visualization, and other tools to basic questions such as "How many of
my patients are likely to miss their visits today?" and common tasks
such as viewing multiple lab results together over time.

Every conference has to have a final session, of course, and every
final session suffers from decreased attendance. So did Uhlman's
scintillating talk, but I felt that his talk deserves more attention
because he goes to the heart of our job in health care IT: to take the
mounds of new data that electronic records and meaningful use will
generate and find answers to everyday problems bedeviling
practitioners.

Luckily, Uhlman's talk was videotapes--as were all the others that I
reported in my three blogs--and will be put on the Web at some point.
Stay tuned, and stay healthy.

July 23 2010

VistA scenarios, and other controversies at the Open Source health care track

The history and accomplishments attributed to VistA, the Veterans
Administration's core administrative software, mark it as one of the
most impressive software projects in history. Still, lots of smart
people in the health care field deprecate VistA and cast doubt that it
could ever be widely adopted. Having spent some time with people on
both sides, I'll look at their arguments in this blog, and then
summarize other talks I heard today at the href="http://www.oscon.com/oscon2010">Open Source Convention
health care track.

Yesterday, as href="http://radar.oreilly.com/2010/07/day-one-of-the-health-care-it.html">I
described in my previous blog, we heard an overview of trends in
health care and its open source side in particular. Two open source
free software projects offering electronic health records were
presented, Tolven and href="http://www.oemr.org/">openEMR. Today was VistA day, and
those who stayed all the way through were entertained by accolades of
increasing fervor from the heads of href="http://www.oscon.com/oscon2010/public/schedule/detail/15291">vxVistA,
href="http://www.oscon.com/oscon2010/public/schedule/detail/15255">Medsphere,
and ClearHealth. (Anyone
who claims that VistA is cumbersome and obsolete will have to explain
why it seems to back up so many successful companies.) In general, a
nice theme to see today was so many open source companies making a go
of it in the health care field.

VistA: historical anomaly or the future of electronic medical systems?

We started our exploration of VistA with a href="http://www.oscon.com/oscon2010/public/schedule/detail/15274p">stirring
overview by Phillip Longman, author of the popular paperback book,
Best Care Anywhere: Why VA Health Care is Better Than
Yours
. The story of VistA's development is a true medical
thriller, with scenes ranging from sudden firings to actual fires
(arson). As several speakers stressed, the story is also about how the
doctors at the VA independently developed the key aspects of open
source development: programming by the users of the software, loose
coordination of independent coders, freedom to fork, and so on.

Longman is convinced that VistA could and should be the basis of
universal health records in the U.S., and rains down omens of doom on
the comprehensive health care bill if it drives physicians to buy
proprietary health record systems.

VistA is much more than an electronic health record system, and even
bigger than a medical system. It is really a constellation of hundreds
of applications, including food preparation, library administration,
policing, and more.

The two main objections to VistA are:


That it is clunky old code based on an obsolete language and database technology

As a project begun by amateurs, VistA probably contains some fearsome
passages. Furthermore, it is written in MUMPS (standardized by ANSI as
simply M), a language that dates from the time of LISP and
COBOL. Predating relational databases, MUMPS contains a hierarchical
database based on a B*-tree data structure.

Supporters of Vista argue that anything qualifying as "legacy code"
can just as well be called "stable." They can also answer each of
these criticisms:

  • The code has been used heavily by the VA long enough to prove that
    it is extendable and maintainable.

  • It is strangely hypocritical to hear VistA's use of MUMPS criticized
    by proprietary vendors when so any of them are equally dependent on
    that language. Indeed, the best-known vendors of proprietary health
    care software, including Epic and InterSystems, use MUMPS. Need I
    remind readers that we put a man on the moon using 1960s-style
    FORTRAN?

    It's interesting to learn, however, that ClearHealth is migrating
    parts of VistA away from MUMPS and does most of its coding in
    higher-level languages (and many modern programmers would hardly offer
    praise for the language chosen for ClearHealth's interface, PHP).

  • Similarly, many current vendors use the Cache hierarchical
    database. Aspersions concerning pre-relational databases sound less
    damning nowadays in an age of burgeoning interest in various NoSQL
    projects. Still, Medsphere and the community-based href="http://www.worldvista.org/">WorldVistA project are
    creating a SPARQL interface and a mechanism for extracting data from
    VistA into a MySQL database.


That it works well only in the unique environment of the Veterans Administration

This critique seems to be easier to validate through experience. The
VA is a monolithic, self-contained environment reflected in VistA. For
instance, the critical task of ordering prescriptions in VistA depends
on the pharmacy also running VistA.

Commercial pharmacies could theoretically interact with VistA, but it
would require effort on the part of those companies, which in turn
would depend on VistA being adopted by a substantial customer base of
private hospitals.

Several successful deployments of VistA by U.S. hospitals, as well as
adoption by whole networks of hospitals in several other countries,
indicate that it's still a viable option. And the presence of several
companies in the space shows that adopters can count on support.

On the other hand, the competing implementations by vxVistA,
Medsphere, and ClearHealth complicate the development landscape. It
might have been easier if a single organization such as WorldVistA
could have unified development as the Apache or GNOME foundation does.

vxVistA has come in for particular criticism among open source
advocates. In fact, the speakers at today's conference started
out defensive, making me feel some sympathy for them.

vxVistA's developers, the company DSS, kept their version of VistA
closed for some time until they had some established customers.
Speaker Deanne Clark argued that they did this to make sure they had
enough control over their product to produce some early successes,
warning that any failure would hurt the image of the whole VistA
community. I don't know why a closed development process is necessary
to ensure quality, but I'll accept her explanation. And DSS seems to
be regarded highly for its quality work by everyone, including those
who embroil

More galling to other open source advocates is that when DSS did
release vxVistA as open source, they did so under an Eclipse license
that is incompatible with the GPL used by WorldVistA.

I wouldn't dare guess whether VistA will continue as a niche product
or will suddenly emerge to eat up the U.S. market for electronic
medical systems. But I think it's definitely something to watch.

The odd position of the VA as the source for new versions of VistA, as
well as its role as VistA's overwhelmingly largest user, could also
introduce distortions into the open source development pattern outside
the VA. For instance, commercial backers of VistA are determined to
get it certified for meaningful use so that their clients can win
financial rewards from the Department of Health and Human
Services. But the VA doesn't have to be certified for meaningful use
and doesn't care about it. (As David Uhlman of ClearHealth pointed
out, nearly everything in the meaningful use criteria was done thirty
years ago by the VA using VistA.)

The VA even goes through periods of refusing bug fixes and
improvements from the outside community. Luckily, the VA lets some of
its programmers participate on WorldVistA forums, and seems interested
in getting more involved.

Other presentations

Attendance varies between 30 and 70 people for today's health care
session. Roni Zeiger of Google brought out a big crowd for his href="http://www.oscon.com/oscon2010/public/schedule/detail/15272">discussion
of Google's interest in health care, with a focus on how its API
accepts data from devices.

Zeiger pointed out that we lead most of our lives outside doctor's
offices (unless we're very unlucky) and that health information should
be drawn from everyday life as well. A wide range of devices can
measure everything from how fast we walk to our glucose levels. Even
if all you have is a smart phone, there are a lot of things you can
record. Collecting this kind of data, called Observations of Daily
Living, is becoming more and more popular.

  • One app uses GPS to show your path during a run.

  • Another app uses the accelerometer to show your elevation during a
    bike ride.

  • One researcher uses a sensor, stuck into an inhaler, to feed data to a
    phone and collect information on where and when people have asthma
    attacks. If we collect a lot of data from a lot of people over time,
    we may learn more about what triggers these attacks.

  • On the fun side, a Google employee figured out how to measure the
    rotation of bike pedals using the magnet in an Android phone. This
    lets employees maintain the right aerobic speed and record what how
    fast and their friends are peddling.

You can set up Google Health to accept data from these
devices. Ultimately, we can also feed the data automatically to our
doctors, but first they'll need to set up systems to accept such
information on a regular basis.

Will Ross href="http://www.oscon.com/oscon2010/public/schedule/detail/14944">described
a project to connect health care providers across a mostly rural
county in California and exchange patient data. The consortium
found that they had barely enough money to pay a proprietary vendor of
Health Information Exchange systems, and no money for maintenance. So
they contracted with
Mirth
Corporation
to use an open source solution. Mirth supports
CONNECT, which I described in
href="http://radar.oreilly.com/2010/07/day-one-of-the-health-care-it.html">yesterday's
blog, and provides tools for extracting data from structured
documents as well as exchanging it.

Nagesh Bashyam, who runs the large consulting practice that Harris
Corporation provides to CONNECT, href="http://www.oscon.com/oscon2010/public/schedule/detail/15267">talked
about how it can lead to more than data exchange--it can let a doctor
combine information from many sources and therefore be a platform for
value-added services.

Turning to academic and non-profit research efforts, we also heard
today from href="http://www.oscon.com/oscon2010/public/schedule/detail/15279">
Andrew Hart of NASA's Jet Propulsion Laboratory and some colleagues at
Children's Hospital Los Angeles. Hart described a reference
architecture that has supported the sharing of research data among
institutions on a number of large projects. The system has to be able
to translate between formats seamlessly so that researchers can
quickly query different sites for related data and combine it.

Sam Faus of Sujansky & Associates href="http://www.oscon.com/oscon2010/public/schedule/detail/15275">recounted
a project to create a Common Platform for sharing Observations of
Daily Living between research projects. Sponsored by the Robert Wood
Johnson Foundation to tie together a number of other projects in the
health care space, Sujansky started its work in 2006 before there were
systems such as Google Health and Microsoft Health Vault. Even after
these services were opened, however, the foundation decided to
continue and create its own platform.

Currently, there are several emerging standards for ODL, measuring
different things and organizing them in different ways. Faus said this
is a reasonable state of affairs because we are so early in the
patient-centered movement.

I talked about standards later with David Riley, the government's
CONNECT initiative lead. HHS can influence the adoption of standards
through regulation. But Riley's office has adopted a distributed and
participatory approach to finding new standards. Whenever they see a
need, they can propose an area of standardization to HHS's
specification advisory body. The body can prioritize these
requests and conduct meetings to hammer out a standard. To actually
enter a standard into a regulation, however, HHS has to follow the
federal government's rule-making procedures, which require an
eighteen-month period of releasing draft regulations and accepting
comments.

It's the odd trait of standards that discussions excite violent
emotions among insiders while driving outsiders to desperate
boredom. For participants in this evening's Birds of a Feather
session, the hour passed quickly discussing standards.

The 800-pound gorilla of health care standards is the HL7 series,
which CONNECT supports. Zeiger said that Google (which currently
supports just the CCR, a lighter-weight standard) will have to HL7's
version of the continuity of care record, the CCD. HL7 standards have
undergone massive changes over the decades, though, and are likely to
change again quite soon. From what I hear, this is urgently
necessary. In its current version, the HL7 committee layered a
superficial XML syntax over ill-structured standards.

A major problem with many health care standards, including HL7, is the
business decision by standard-setting bodies to fund their activities
by charging fees that put standards outside the reach of open source
projects, as well as ordinary patients and consumers. Many standards
bodies require $5.00 or $10.00 per seat.

Brian Behlendorf discussed the recent decision of the NHIN Direct
committee to support both SOAP versus SMTP for data exchange. Their
goal was to create a common core that lets proponents of each system
do essentially the same thing--authenticate health care providers and
exchange data securely--while also leaving room for further
development.

July 22 2010

Day one of the health care IT track at O'Reilly's Open Source convention

I think the collective awe of health care aficionados at the href="http://www.oscon.com/oscon2010">Open Source Convention came
to a focal point during our evening Birds of a Feather session, when
open source advocate Fred Trotter, informally stepping in as session
leader, pointed out that the leaders of key open source projects in
the health care field were in the room, including two VistA
implementors (Medsphere and href="http://www.worldvista.org/">WorldVistA), href="http://www.tolvenhealth.com/">Tolven, and href="http://wwwf.oemr.org/">openEMR--and not to forget two other
leading health care software initiatives from the U.S. government, href="http://www.connectopensource.org">CONNECT and href="http://nhindirect.org/">NHIN Direct.

This meeting, which drew about 40 doctors, project leaders,
programmers, activist patients, and others, was the culmination of a
full day of presentations in the first track on health care at an
O'Reilly conference. The day's sessions unveiled the potential of open
source in health care and how dedicated implementors were making it a
reality, starting with an scene-setting talk by Tim O'Reilly that
attracted over 75 people and continuing through the next seven hours
until a dwindling hard core delayed drinks and hors d'oeuvres for half
an hour to hear a final late talk by href="http://www.oscon.com/oscon2010/public/schedule/detail/13943">Melanie
Swan on DIYgenomics.

Nine talks representing the breadth of a vital programming area can't
be summarized in one sentence, but for me the theme of the day was
open source advocates reaching out to solve pressing problems that
proprietary vendors will not or cannot address.

Tim O'Reilly's talk laid out key elements of the health care
revolution: electronic records, the quantified self (measuring one's
bodily activities), and the Internet of things that allows one to track
behavior such as whether a patient has taken his medicine.

Talk to me

We were honored to have key leaders from Health and Human Services
speak at today's conferences about its chief open source projects. href="http://www.oscon.com/oscon2010/public/schedule/detail/13257">David
Riley and Brian Behlendorf (known best for his work on Apache)
came from the Office of the National Coordinator along with lead
contractor href="http://www.oscon.com/oscon2010/public/schedule/detail/15304">Arien
Malec to show us the current status and--most exciting--the future
plans for CONNECT and NHIN Direct, which are key pieces of the
Administration's health care policy because they allow different
health care providers to exchange patient information securely.

I have href="http://radar.oreilly.com/2010/07/health-and-human-services-fina.html">written
recently about "meaningful use" for health care records. Malec
provided a homespun and compelling vision of the problems with the
current health care system: in contrast to the old days where doctors
knew every patient personally, modern health care is delivered as
episodic interventions. As Fred Trotter said in his talk, we've
reached the limit of what we can achieve through clinical efforts.
Doctors can do miracles compared to former times, but the problems we
suffer from increasingly call for long-range plans. Malec said that
health care systems need to remember us. That's what
electronic health records can do, combined with the data exchange
protocols provided by NHIN.

Riley, in what is likely to be one of the most revisited talks of the
conference--yes, we recorded the sessions and will put them
online--rapidly laid out the architecture of CONNECT and what's
planned for upcoming releases. Requests between agencies for health
care data have gone from months to minutes with CONNECT. Currently
based on SOAP, it is being refactored so that in the future it can run
over REST, XMPP, and SMTP.

NHIN Direct, the newer and more lightweight protocol, is also based on
digital certificates and uses S/MIME with SMTP over TLS. Parties can
do key exchange themselves or work through a trusted third party. It
seems to me, therefore, that CONNECT and NHIN Direct will eventually
merge. It is as if the NHIN Direct project was started to take a big
step back from CONNECT, look at what it achieved for the government
agencies that produce or consume health care and how the same benefits
could be provided to health care providers all over the country, and
to formalize an architecture that would become the new CONNECT.

NHIN is an even more impressive case of open government and
collaborative development than CONNECT. The public was involved from
the earliest design stage. Some people complained that established
vendors bent the process to preserve their advantages, but they
probably had less success this way than if HHS followed normal
government procedures. NHIN already has reference implementations in
Java and C#. If you're inspired to help bring health records to the
public, you can read the wikis and attend some training and contribute
reference implementations in your language of choice.

In addition to supporting the NHIN Direct protocol, some of the
upcoming features in CONNECT include:

  • Identity management services. This will probably be based on a
    voluntary patient identifier.

  • Support for meaningful use criteria.

  • Support for structured data, allowing the system to accept input in
    standards such as the CCR or CCD and populate documents. One feature
    enabled by this enhancement will be the ability to recognize sensitive
    health data and remove it before sending a record. (CONNECT can be
    used for all health-related data, not just personal medical records.)

  • Moving to the Spring Framework.

Riley has done some pretty rigorous cost analysis and determines that
careful management--which includes holding costs down and bringing
multiple agencies together to work on CONNECT--has reduced development
costs from over 200 million dollars to about 13 million dollars.
Recent code sprints drew heavily from community volunteers: 4 or 5
volunteers along with 12 contractors.

In an href="http://www.oscon.com/oscon2010/public/schedule/detail/15296">overview
talk, Deborah Bryant of OSU Open Source Lab raised the issue
continuity in relation to NHIN and CONNECT. Every open source project
has to figure out how to keep a community of volunteers interested so
that the project continues to evolve and adapt to changing
circumstances. Government-backed projects, she admitted, provide
funding over a sustained period of time, but this does not obviate the
need for community management.

In addition, CONNECT is run by a consulting firm with paid contractors
who have to learn how to accept community input and communicate with
outsiders. Behlendorf said that simple things like putting all code
in Subversion and all documentation on a wiki helps. Consultants are
also encouraged to request feedback on designs and to talk about the
goals of sprints as far as possible in advance.

IntraHealth International manages the basic health care resource: people

The problems of the developing world were represented most directly by
the open source human resource information system href="http://www.intrahealth.org/">IntraHealth International,
presented by href="http://www.oscon.com/oscon2010/public/schedule/detail/15268">
Carl Leitner. IntraHealth International helps many Sub-Saharan and
South Asian countries manage one of their most precious and dwindling
resources: health care professionals. The system, called iHRIS lets
individual hospitals as well as whole nations determine where their
most pressing staffing needs lie, break down staff by demographic
information such as age and gender (even language can be tracked), and
track their locations.

Training is one of the resources that must be managed carefully. If
you know there's a big gap between the professionals you need and ones
you have, you can direct scarce funding to training new ones. When
iHRIS records expenditures, what do countries often find? Some
administrator has splurged on sending himself to the same training
program over and over, just to get the per diem. Good information can
expose graft.

Open source is critical for a system like iHRIS, not just because
funds are scarce, but because localization is critical. Lots of
languages whose very existence is hidden from proprietary vendors need
to be supported. Each country also has different regulations and
conditions. IntraHealth International holds regular unconferences,
mentoring, and other forms of training in its target countries in the
hope of (in Leitner's words) putting themselves out of business. Of
course, trained IT staff tend to drift into higher-paying jobs, so the
organization tries to spread the training over many people.

OpenEMR and Tolven

The overarching challenge for any electronic health record system, if
its developers hope it to be taken seriously over the next couple
years in the United States, is support for meaningful use criteria.
Proprietary systems have, for several decades, met the needs of large
institutions with wads of cash to throw at them. And they will gain
certification to support meaningful use as well. But smaller providers
have been unable to afford these systems.

The need for an open source solution with meaningful use certification
is pressing, and two project leaders of OpenEMR devoted href="http://www.oscon.com/oscon2010/public/schedule/detail/14893">their
talk to their push to make their system ready. They estimate that
they have implemented about 80% of the required functionality, but
more slowly than expected. Extraordinary measures were required on
many fronts:

  • Medical experts had to read thousands of pages of specifications as
    they came out, and follow comments and debates to determine which
    requirements would likely be dropped or postponed, so as not to waste
    development time.

  • Contractors were hired to speed up the coding. Interestingly, the
    spike in productivity created by the contractors attracted a huge
    number of new volunteers. At one point openEMR became number 37 on
    SourceForge in terms of activity, and it is still up around 190. The
    project leaders had to upgrade some of their infrastructure to handle
    an increased number of commits. They also discovered that lack of
    documentation was a hindrance. Like the CONNECT team, they found that
    maintaining a community required--well, maintenance.


  • Project leaders had to go to Washington and argue with government
    bureaucrats to change requirements that would have essentially made it
    impossible for open source projects to meet the meaningful use
    requirements. They succeeded in removing the offending clauses, and
    believe they were also responsible for winning such accomplishments as
    allowing sites to certify modules instead of entire stand-alone
    systems. Nevertheless, some aspects of certification require
    contracts with proprietary vendors, such as lab interface, which is
    done through a proprietary company, and drug-to-drug and
    drug-to-allergy interactions, which require interaction with expensive
    databases.

Tony McCormick pointed out that the goal of meaningful use
certification provided a focus that most open source projects lack.
In addition, the government provided tests (called scripts) that
served as a QA plan.

Meaningful use, as much as it represents an advance over today's
health information silos, does not yet involve the patient. The
patient came to the fore in two other talks, one by href="http://www.oscon.com/oscon2010/public/schedule/detail/13943">Melanie
Swan on her company DIYgenomics and the other by href="http://www.oscon.com/oscon2010/public/schedule/detail/15051">Tom
Jones on Tolven.

Swan summarized the first two generations of DNA sequencing (which
went a bit above my head) and said we were on the verge of a third
generation that could bring full genome sequencing down to a cost that
consumers could afford. A part of the open science movement,
DIYgenomics helps patients combine with others to do research, a
process that is certainly less rigorous than controlled experiments
but can provide preliminary data that suggests future research. For
many rare conditions, the crowdsourced approach can fill a gap that
professional researchers won't fill.

In addition to providing access to studies and some other useful
apps--such as one that helps you evaluate your response to
drugs--DIYgenomics conducts its own longitudinal studies. One current
study checks for people who do not absorb vitamin B12 (folic acid)
properly, a condition to which up to half the population is
vulnerable. Another study, for which they are seeking 10,000
participants, covers aging.

Jones's talk centered on privacy, but spread its tent to include the
broader issues of patient-centered medicine. Tolven simultaneously
supports records held by the doctor (clinical health records) and by
the patient (personal health records).

In a system designed especially for the Netherlands--where privacy
laws are much stricter and better specified than in the United
States--Tolven stores medical records in large, centralized
repositories because it's easier to ensure security that way. However,
strict boundaries between doctors prevent them from viewing each
other's data. Even more significantly, data is encrypted during both
transmission and storage, and only the patient has the key to unlock
it. Audit trails add another layer of protection.

In this architecture, there are no release forms. Instead, the patient
explicitly approves every data transfer. (Patients can designate
special repositories to which their relatives have access, in case of
emergencies when they're not competent to make the transfer.)

That was one day of health care at OSCon--two more are coming up. We
started our evening BOF with introductions, but more and more people
kept coming in the room, and everyone was so interesting that the
introductions ended up taking the entire hour allocated for the BOF.
The sense that our health care system needs to change radically, and
the zeal expressed to take part in that change, brought energy into
the room. This was a great place to meet like-minded people.

July 19 2010

Report from 2010 Community Leadership Summit

It's hardly pertinent to summarize an unconference, because it's all
over the map by (lack of) design. Anyway, you don't need me to tell
you about the the topics at this year's href="http://www.communityleadershipsummit.com/">community leadership
summit because you can view the wiki pages for the href="http://www.communityleadershipsummit.com/wiki/index.php/Saturday_Session_Board">Saturday
and href="http://www.communityleadershipsummit.com/wiki/index.php/Sunday_Session_Board">Sunday
sessions. What I like each year is the little space we all create for
ourselves at CLS in a forlorn corner of an overwhelming, cold
conference locale that makes it very hard to feel community.

This CLS is the third in a series, and the second to be presented
before O'Reilly's Open Source
convention
, which is why it's in a huge convention center. The one
in Portland, Oregon is one of the more pleasant convention centers
I've been in but it still makes me feel confined the moment I enter a
room and lost whenever I go into a hallway. Despite this, by the
second day of CLS we turned the center into our lounge. We even had a
little folk music jam.

The topics we covered were deep and serious: how to prod established
community members to leave room for new ones and encourage their
growth, how to involve women and minorities in technical projects, how
to raise funds and whom to accept funds from. The conference could
also get personal. Talks about fund-raising brought out a lot of
personal stories about screw-ups and taking on risk.

Like last year, we had well over a hundred people the first day,
substantially fewer on the second. An interesting influx of new people
provided new energy on the second day, but there was enough continuity
to produce the living-room feeling.

Most impressive, maybe, was the number of people who came long
distances just to spend the weekend here for this summit, without even
attending OSCon or staying for other activities in Portland.

Most of the topics concerned communities of all types, not just
technical communities. But open source definitely ran through the
conference. It kind of took over the session I led, href="http://www.communityleadershipsummit.com/wiki/index.php/2010_Session-B10">Talking
to your government.

It was an exciting session that attracted about twenty people over the
course of just half an hour, about four times as many as the similar
session I led last year. The eagerness to make a difference in
government policy was evident among the participants. And their
commitment has been stimulated, in turn, by recent initiatives in
government to release data and issue requests for free software using
that data.

I pitched the session in a basically non-technical context, as how to
get people to work together in groups so that they could respond
effectively to open government efforts. Developer communities are of
particular importance, I pointed out, because they are the ones
creating the new apps the governments want to promote participation.
But the same principles apply to everyone who can contribute to
policy.

The role of developer communities was the theme taken up with the most
gusto, and soon we were discussing all the barriers to having
government adopt open source software. I reminded the fifteen
attendees once that we were drifting away from the theme of community,
but I realized that the prospects of open source is what excited them
most, and while we lost a couple people, this topic met the needs of
the majority.

The size of this gathering was comfortable and the experience of the
attendees brought many insights, but we could still use a greater
diversity and more attendees. As a free conference, it should be
attracting a lot of people from communities that could benefit from a
better understanding of leadership, and could bring their
understanding to us. So let's see even more people next year.

May 19 2010

What I like about the health care technology track at the Open Source convention

OSCON Conference 2010The href="http://www.oscon.com/oscon2010/public/schedule/topic/Health">list
of sessions at the Open Source convention's health care track was
published this week. We found it wonderfully gratifying to get so many
excellent submissions in the brief three weeks that the Request for
Proposals was up. Although the credentials of the presenters cover a
lot of impressive accomplishments, my own evaluation focused on how
the topics fit into four overarching areas we're following at
O'Reilly:

  • Patient-centered records, education, and activity

  • Mobile devices to collect and distribute health care information

  • Administrative efficiencies, which could range from automating a
    manual step in a process to revising an entire workflow to eliminate
    wasteful activities

  • The collection, processing, and display of statistics to improve
    health care

Our OSCon track has something to say in all these areas, and lots
more. Here's what I like about each of the proposals we chose.

  • Nobody sees just one doctor or stays in just one hospital. So one of
    the pressing needs in health care is to remove the barriers to
    exchanging patient records, while ensuring they go only to authorized
    recipients. A project called the Nationwide Health Information Network
    (NHIN), currently run by the U.S. Department of Health and Human
    Services, acts as a broker for the authorizations and data exchanges
    between health care providers.

    NHIN has taken on a new excitement over the past couple years for two
    reasons involving the two great motivators in policy work: people and
    money. The people-based motivator came when HHS opened up key parts of
    the NHIN software and actively built a nationwide community to make it
    more usable. The money-based motivator came from the federal stimulus
    bill, which allocated billions to promote electronic records and data
    exchange.

    HHS's Office of the National Coordinator handles implementation of the
    stimulus bill. Their schedule for payments (and penalties too, in the
    case of providers accepting Medicare and Medicaid) is aggressively
    short, making progress urgent. NHIN work includes two major
    initiatives taking on the challenge of data exchange.

    The first initiative is NHIN CONNECT, a platform for interconnecting
    the patient health data systems of hospitals, health care providers,
    and federal health agencies. David Riley and Brian Behlendorf,
    contractors to HHS on this project, href="http://www.oscon.com/oscon2010/public/schedule/detail/13257">will
    recount the steps in creating a robust community around
    CONNECT. Will Ross will give us the view from the ground, as a href="http://www.oscon.com/oscon2010/public/schedule/detail/14944">regional
    Health Information Exchange sets up and carries out data transfers
    among clinics in a rural area. Nagesh Bashyam will give more href="http://www.oscon.com/oscon2010/public/schedule/detail/15267">insight
    into the CONNECT development process.

    The second initiative is a new project called href="http://nhindirect.org/">NHIN Direct, which is focused on a
    more "push"-oriented approach to secure messaging in the healthcare
    industry. Its core principles include "rough consensus and running
    code", and is on a breakneck pace to get from user stories to
    production implementation by the end of the year. Arien Malec, a
    health IT industry entrepreneur who leads the NHIN Direct effort as a
    contractor to HHS, will describe href="http://www.oscon.com/oscon2010/public/schedule/detail/15304">the
    history and mission of the project.

  • The Veterans Administration went over a ten- or fifteen-year period
    from being one of the least satisfactory health care providers in the
    US to one of the most highly praised. Its classic electronic medical
    system, VistA, is a key component of that success, and VistA has been
    open source for several years. None of the leading-edge initiatives
    mentioned earlier in this blog can be accomplished without an
    electronic medical system, and proprietary ones have the disadvantages
    not only of high cost but of being silo'd. Open source systems
    facilitate both innovative enhancements and data exchange.

    Ben Mehling href="http://www.oscon.com/oscon2010/public/schedule/detail/15255">will
    introduce VistA, its open source distributions, and how community
    contributors are adapting it to civilian use. Joseph Dal Molin
    will show href="http://www.oscon.com/oscon2010/public/schedule/detail/15274">how
    it improves patient care and the health care delivery
    process. David Uhlman will continue the discussion with href="http://www.oscon.com/oscon2010/public/schedule/detail/15252">lessons
    from working with VistA code.

  • OpenEMR is one of the most
    ambitious projects started by an open source community in health care.
    Like VistA, OpenEMR is being prepared for certification along the
    "meaningful use" criteria defined by HHS, so doctors can get federal
    funds for using it. Tony McCormick and Samuel Bowen href="http://www.oscon.com/oscon2010/public/schedule/detail/14893">will
    talk about advances in OpenEMR.

  • In an age where people are talking back to the experts and striving to
    gain more control as consumers, citizens, and patients, we can no
    longer treat health care as a one-way delivery system administered by
    omniscient, benevolent providers. Sam Faus will describe a href="http://www.oscon.com/oscon2010/public/schedule/detail/15275">open
    source system for maintaining and delivering data to
    patients. Teddy Bachour will cover href="http://www.oscon.com/oscon2010/public/schedule/detail/14952">APIs
    and open source toolkits from Microsoft for clinical documentation and
    sharing of patient records
    , and Roni Zeiger will cover href="http://www.oscon.com/oscon2010/public/schedule/detail/15272">how
    Google Health's API facilitates interactions with mobile devices,
    thus supporting one of the key trends in health care mentioned earlier
    in this blog.

  • Scientific research can deliver almost futuristic advances in health
    care, although the gap between promising lab results and effective
    treatments is always frustrating and difficult to bridge. In addition,
    statistics are critical for clinical decision support, now popularized
    under the term "evidence-based medicine."

    Melanie Swan shows how to href="http://www.oscon.com/oscon2010/public/schedule/detail/13943">bring
    ordinary people into the research process in genetics. Chris
    Mattmann, David Kale, and Heather Kincaid will describe a href="http://www.oscon.com/oscon2010/public/schedule/detail/15279">partnership
    between NASA and Children's Hospital Los Angeles to master and
    harness the recalcitrant mass of clinical data and data formats.
    Thomas Jones will talk about an href="http://www.oscon.com/oscon2010/public/schedule/detail/14931">open
    source system to link patient information with research to improve
    care.

  • Medicine is moving from coarse-grained, invasive treatments such as
    surgery and drugs to subtler, data-driven interventions using a
    variety of devices. Karen Sandler will describe a href="http://www.oscon.com/oscon2010/public/schedule/detail/13978">personal
    experience that led her to a campaign for open source medical
    devices.

  • Privacy is one of the touchiest subjects in health care. Few of us
    risk real harm--such as losing our jobs or having our names splayed
    across tabloid headlines--from privacy breaches, but there have been
    instances of snooping and embarrassing breaches that make us skittish.

    Thomas Jones will describe
    efforts to secure patient records in the Netherlands
    and how they
    can apply to US needs. The talk shows the potential that comes from
    giving patients access to their records, as well as the the advanced
    state of some foreign initiatives in health care are.

  • While we argue over access and costs in the US, most of the world has
    trouble seeing a doctor at all. Dykki Settle and Carl Leitner will
    describe href="http://www.oscon.com/oscon2010/public/schedule/detail/15268">tools
    that can help underserved areas recruit and manage critical health
    care staff. The talk will be a sobering reminder of the state of
    health care across continents, and a ray of hope that technology
    offers even in situations of great deprivation. The talk is also an
    illustration of the use of technology to improve an administrative
    process.

  • Fred Trotter, a long-time leader in open source health care, and open
    source advocate Deborah Bryant will provide overviews of href="http://www.oscon.com/oscon2010/public/schedule/detail/14856">open
    source health care IT. David Uhlman summarizes href="http://www.oscon.com/oscon2010/public/schedule/detail/15242">open
    source technologies for interpreting health care data.

The health care track takes a proud place as part of a href="http://www.oscon.com/oscon2010/public/schedule/grid">huge,
diverse conference program at this year's Open Source
convention. I'm sure discussions at the sessions and BOFs will
reveal connecting threads between health care IT and the other classic
open source topics at the conference.

May 10 2010

Notes from the Politics of Open Source conference

Small conferences are often the best, especially when there's a high concentration of really well-educated and personally committed people sharing a room for two days. That's what I found at the Politics of Open Source conference at the University of Massachusetts Amherst on Friday. (I could attend only the second day.)

Gov 2.0 Expo 2010The conference was the brainchild of the Journal of Information Technology & Politics, which will publish articles based on conference talks in an upcoming issue. The editors have agreed to release the papers under an open license, and drafts are up on the web now -- for instance, the draft of my paper Promoting Open Source Software in Government: The Challenges of Motivation and Follow-Through.

Along with celebrity keynoters -- Eric Von Hippel and Clay Johnson -- the
presenters as well as the attendees could boast a lot of real-world
experience, a lot of serious academic achievement, and occasionally
even a combination of the two.

They covered a lot in two days, too. A conference organizer summarized
the main themes as:

  • The politics of open source software and content. Topics included the
    movement's openness to women and the international impacts of open
    source.

  • How open source influences other domains: political activism, peer
    production such as Wikipedia (there is still no touchstone for the
    peer production movement to compare with Wikipedia), and the kinds of
    customer-driven innovation href="http://web.mit.edu/evhippel/www/">described by Von Hippel
    throughout his work.

  • Government policies in relation to open source. This was the category
    embracing my talk, and I'll spend the rest of the blog on these
    issues.

My main goal was to expose the daunting challenges in getting open
source software into government. Prospects have improved with supple,
low-barrier initiatives such as href="http://www.appsfordemocracy.org/">Apps for Democracy and href="http://sunlightlabs.com/contests/appsforamerica/">Apps for
America, but the gargantuan machinery of most government agencies
creaks along with scarcely a trace of light from the free software
movement.

But people used to "configure/make/make install" or other everyday
uses of free software shouldn't cluck our tongues and mutter about the
backwardness of bureaucrats. There are real barriers to change,
barriers that even a manager sincerely devoted to change can't remove
with a wave of the hand.

For uncertain administrators looking for a smooth installation and
maintenance process, proprietary products make life easy in ways that
vendors do for few free software projects. (I owe some of the
following observations to Joe Reddix, founder of the href="http://www.reddixgroup.com/">Reddix Group.) Proprietary
vendors sit with a manager to carry out a sale. They often send a
technician to install the software. If they don't actually do the
installation themselves, they provide a convenient installation
package.

And as managers love to say, the proprietary vendor offers one throat
to choke when something goes wrong. I find it hard to imagine a
nastier metaphor for a relationship between client and vendor, but
Reddix tells me many IT managers form personal relationships with
staff from software vendors, making it even harder psychologically to
consider switching.

How many free software projects offer these amenities? A few major
projects such as GNU/Linux and Apache are backed by prominent firms,
and desktops offer have convenient packaging and automatic updates,
but most IT managers want to update software at times of their own
choosing, and the wealth of smaller projects that could meet
government needs force the users to get their hands dirty.

Naturally, free software has plenty of its own rewards to make up for
the lack of fancy packaging. Users can get support from developers and
fellow users, and can determine the future of the software through
discussion and code contributions. But IT and agency managers need to
experience these benefits to love them. And they have an
uphill battle persuading their department superiors as well as their
staff that the new way of life is worth the change.

My paper lays out prerequisites for a successful conversion to open
source software:

  • A strategic commitment to open source -- perhaps even an explicit
    political set of goals involving open source.

  • Managers who have lived with open source and appreciate its strengths
    and weaknesses. An ideological preference for open source, while
    valuable, is no replacement for experience.

  • A set of rational, formal reasons for moving to open source, which
    provide an intellectual bulwark for the strategic commitment. Cost
    savings are often one of the reasons, but are sometimes surprisingly
    hard to prove and are rarely enough to motivate a migration to open
    source.

  • Practical need often triggers change, and an investigation into the
    state of a government's software may begin for some reason totally
    unrelated to open source but end with the decision to migrate to open
    source.

  • Buy-in at the start from funders or other high-level leadership who
    can otherwise squash a migration.

  • Thick skin and grit, to stand up to the pressures to abandon the
    migration that will issue from staff, partners, and proprietary
    vendors.

Two other speakers presented intense research -- involving
questionnaires, visits, and historical background -- on open source
migration: href="http://politicsofopensource.jitp.net/sites/politicsofopensource.jitp.net/files/papers/Cassell_0.pdf">Mark
Cassell (PDF) and href="http://politicsofopensource.jitp.net/sites/politicsofopensource.jitp.net/files/papers/Shaw_1.pdf">Aaron
Shaw (PDF). Their research bears out my points, I think. Mark added
several more points based on his research in three German cities:

  • Change should be done incrementally, but with a comprehensive,
    long-term plan to make sure departments keep progressing.

  • Winning over staff at low levels is just as important as winning over
    management. Bringing union representatives into decision-making and
    project promotion can help accomplish this goal.

  • Centralized control removes barriers among local departments and helps
    the migration go faster.

The third point may seem surprising -- given how much good press
decentralization is getting -- but it makes sense when you consider that
local experts often like to preserve the status quo because it fits
comfortably with their expertise. Harsh as it sounds, progress often
requires breaking the power of local elites. Furthermore, there's a
practical reason for centralization: software integration. The
software used by one department often has to exchange data with
another, so development has to be coordinated.

Shaw also had some unique points to make. He investigated in Brazil
how free software satisfied some goals of Workers Party activists who
came into government with Lula, at the same time as it was being
pushed by IBM, a major vendor in Brazil, and was coveted by the
administrators of the state banks for practical reasons. Rising to key
points of influence in government, a loosely coordinated set of free
software advocates put migration on the agenda and empowered
departments to make the shift, especially among the banks.

The draft I've written will accumulate more detail and get beefed up
with the insights I get from Cassell, Shaw, and anyone on the ground
doing these migrations whom I can get in touch with.

March 26 2010

Why health care is coming to the Open Source convention

This year for the first time, O'Reilly's Open Source convention
contains a track on health care IT. The href="http://www.oscon.com/oscon2010/public/cfp/108">call for
participation just went up, soliciting proposals on nine broad
areas of technology including health data exchange, mobile devices,
and patient-centered care.

One correspondent asked a bit timidly whether it would be all right to
submit a proposal if her company didn't use open source software.
Definitely! The Open Source convention has always been about a wide
range of computing practices that promote openness in various ways.
Open source software is a key part of the picture but not the whole
picture. Open data, standards, and collaborative knowledge sharing are
also key parts of the revolution in today's health care.

This new track is as much a response to urgings from friends and
colleagues as it is an O'Reilly initiative. We could use help
spreading the word, because the deadline for proposals is tight. In
this blog I'll explain why we created the track and why OSCon is a
promising venue for trends that will move and shake health care in
positive ways.

The obvious draw is that there's a huge opportunity for open source
software and open data initiatives to make a difference in how
electronic medical records are stored and shared. Last year's Federal
stimulus bill (the American Recovery and Reinvestment Act) included
$20 billion dollars in payments to hospitals, doctors, and medical
practices if they demonstrate "meaningful use" of electronic health
records.

Apart from the opportunity to make a difference, this huge infusion of
money means that there's financial opportunity in Health IT. IT specialists
and programmers across the country who have lost their employment or
are just seeking new challenges will naturally be wondering what
health care IT is and how they can get into it. A health care track at
OSCon is, to start with, a natural way to serve our core audience.

But we want the track to be much more.

Health care IT is burgeoning, but the standards and technologies
aren't yet up to the challenge:

  • The government is paying doctors to adopt electronic records, but they
    have the devil of a time sending those records to other doctors--quite
    a problem if your primary care doctor makes a referral to a specialist
    or if you feel chest pains and go to an ER while visiting a strange
    city.

  • A wonderful range of specialized mobile devices, as well as popular
    applications for cell phones, let doctors enter data right at the
    patient's bed side or while walking down the hall. Even voice-to-text
    translation is available. But once in the system, these notes are hard
    to parse and process.

  • Patients are learning to take charge of their own health data, and
    lots of health care providers, not to mention Google and Microsoft,
    offer them access to such data. But getting data in and out is hard.
    Google and Microsoft provide APIs, but both the calls and the formats
    are incompatible. Most systems don't have APIs. Security standards and
    best practices are also lacking.

  • Evidence-based medicine is the white knight of current proponents for
    reducing errors and costs. But because of the incompatibilities
    already mentioned, systems can't share data in secure and
    easy-to-program ways.

So the U.S.--and the rest of the world, including areas with
heretofore inadequate health care--is currently on the cusp of an
unimaginably large revolution in health care IT, but it's tripping
over basic roadblocks in data exchange.

The flip side of each challenge, of course, is an opportunity. Open
standards and open APIs will attract a broad range of IT talent and
help lead to more flexible technologies that stand up better as the
environment evolves. O'Reilly as a company, and our Open Source
convention in particular, have been involved with many of the
innovations made by open source developers, and we are excited to
bring more of this community and this experience into health care IT.

O'Reilly was one of the early promoters of the term "open source" (and
the recognized leaders in documentation for free software long before)
as well as the originators of the term Web 2.0 and organizers of
conferences on transparency in government and "government as a
platform," or Government 2.0. People trying to use APIs and open
source software to create open platforms flock to OSCon. It's a major
industry venue for announcements and a place where people talk
together to come up with new technical ideas.

We believe that advances in APIs, giving data to patients, open source
software, and interactive mobile devices will free health care IT. We
don't know precisely which technologies will win out or how the whole
thing will fit together--so we want to use OSCon to help figure that
out.

Help us make OSCon a platform for developing platforms. Submit
proposals, tell your friends, and make your travel plans for Portland
in July.

March 04 2010

Report from HIMMS Health IT conference: toward interoperability and openness

Yesterday and today I spent once again at the href="http://www.himss.org/">Healthcare Information and Management
Systems Society (HIMSS) conference in Atlanta, rushing from panel
session to vendor booth to interoperability demo and back (or
forward--I'm not sure which direction I've been going). All these
peregrinations involve a quest to find progress in the areas of
interoperability and openness.

The U.S. has a mobile population, bringing their aches and pains to a
plethora of institutions and small providers. That's why health care
needs interoperability. Furthermore, despite superb medical research,
we desperately need to share more information and crunch it in
creative new ways. That's why health care needs openness.

My href="http://radar.oreilly.com/2010/03/report-from-himms-health-it-co.html">blog
yesterday covered risk-taking; today I'll explore the reasons it's
so hard to create change.

The health care information exchange architecture

Some of the vendors I talked to boasted of being in the field for 20
years. This give them time to refine and build on their offerings,
but it tends to reinforce approaches to building and selling software
that were prominent in the 1980s. These guys certainly know what the
rest of the computer field is doing, such as the Web, and they reflect
the concerns for interoperability and openness in their own ways. I
just feel that what I'm seeing is a kind of hybrid--more marsupial
than mammal.

Information exchange in the health care field has evolved the
following architecture:

Electronic medical systems and electronic record systems

These do all the heavy labor that make health care IT work (or fail).
They can be divided into many categories, ranging from the simple
capturing of clinical observations to incredibly detailed templates
listing patient symptoms and treatments. Billing and routine workflow
(practice management) are other categories of electronic records that
don't strictly speaking fall into the category of health records.
Although each provider traditionally has had to buy computer systems
to support the software and deal with all the issues of hosting it,
Software as a Service has come along in solutions such as href="http://www.practicefusion.com/">Practice Fusion.

Services and value-added applications

As with any complex software problem, nimble development firms partner
with the big vendors or offer add-on tools to do what health care
providers find too difficult to do on their own.

Health information exchanges (HIEs)

Eventually a patient has to see a specialist or transfer records to a
hospital in another city--perhaps urgently. Partly due to a lack of
planning, and partly due to privacy concerns and other particular
issues caught up in health care, transfer is not as simple as querying
Amazon.com or Google. So record transfer is a whole industry of its
own. Some institutions can transfer records directly, while others
have to use repositories--paper or electronic--maintained by states or
other organizations in their geographic regions.


HIE software and Regional Health Information Organizations
(RHIOs)

The demands of record exchange create a new information need that's
filled by still more companies. States and public agencies have also
weighed in with rules and standards through organizations called
Regional Health Information Organizations.

Let's see how various companies and agencies fit into this complicated
landscape. My first item covered a huge range of products that
vendors don't like to have lumped together. Some vendors, such as the
Vocera company I mentioned in yesterday's blog and href="http://solutions.3m.com/wps/portal/3M/en_US/3M_Health_Information_Systems/HIS/">3M,
offer products that capture clinicians' notes, which can be a job in
itself, particularly through speech recognition. href="http://emdeon.com/">Emdeon covers billing, and adds validity
checking to increase the provider's chances of getting reimbursed the
first time they submit a bill. There are many activities in a doctor's
office, and some vendors try to cover more than others.

Having captured huge amounts of data--symptoms, diagnoses, tests
ordered, results of those tests, procedures performed, medicines
ordered and administered--these systems face their first data exchange
challenge: retrieving information about conditions and medicines that
may make a critical difference to care. For instance, I saw a cool
demo at the booth of Epic, one of
the leading health record companies." A doctor ordered a diuretic that
has the side-effect of lowering potassium levels. So Epic's screen
automatically brought up the patient's history of potassium levels
along with information about the diuretic.

Since no physician can keep all the side-effects and interactions
between drugs in his head, most subscribe to databases that keep track
of such things; the most popular company that provides this data is href="http://firstdatabank.com/">First DataBank. Health record
systems simply integrate the information into their user interfaces.
As I've heard repeatedly at this conference, the timing and delivery
of information is just as important as having the information; the
data is not of much value if a clinician or patient has to think about
it and go searching for it. And such support is central to the HITECH
act's meaningful use criteria, mentioned in yesterday's blog.

So I asked the Epic rep how this information got into the system. When
the physicians sign up for the databases, the data is sent in simple
CSV files or other text formats. Although different databases are
formatted in different ways, the health record vendor can easily read
it in and set up a system to handle updates.

Variations on this theme turn up with other vendors. For instance, href="http://www.nextgen.com/">NextGen Healthcare contracts
directly with First DataBank so they can integrate the data intimately
with NextGen's screens and database.

So where does First DataBank get this data? They employ about 40
doctors to study available literature, including drug manufacturers'
information and medical journals. This leads to a constantly updated,
independent, reliable source for doses, side-effects,
counterindications, etc.

This leads to an interesting case of data validity. Like any
researchers--myself writing this blog, for instance--First DataBank
could theoretically make a mistake. Their printed publications include
disclaimers, and they require the companies who licence the data to
reprint the disclaimers in their own literature. But of course, the
disclaimer does not pop up on every dialog box the doctor views while
using the product. Caveat emptor...

Still, decision support as a data import problem is fairly well
solved. When health record systems communicate with each other,
however, things are not so simple.

The challenges in health information exchange: identification

When a patient visits another provider who wants to see her records,
the first issue the system must face is identifying the patient at the
other provider. Many countries have universal IDs, and therefore
unique identifiers that can be used to retrieve information on a
person wherever she goes, but the United States public finds such
forms of control anathema (remember the push-back over Read ID?).
There are costs to restraining the information state: in this case,
the hospital you visit during a health crisis may have trouble
figuring out which patient at your other providers is really you.

HIEs solve the problem by matching information such as name, birth
date, age, gender, and even cell phone number. One proponent of the
federal government's Nationwide
Health Information Network
told me it can look for up to 19 fields
of personal information to make a match. False positives are
effectively eliminated by strict matching rules, but legitimate
records may be missed.

Another issue HIEs face is obtaining authorization for health data,
which is the most sensitive data that usually concerns ordinary
people. When requesting data from another provider, the clinician has
to log in securely and then offer information not only about who he is
but why he needs the data. The sender, for many reasons, may say no:

  • Someone identified as a VIP, such as a movie star or high-ranking
    politician, is automatically protected from requests for information.

  • Some types of medical information, such as HIV status, are considered
    especially sensitive and treated with more care.

  • The state of California allows ordinary individuals to restrict the
    distribution of information at the granularity of a single institution
    or even a single clinician, and other states are likely to do the
    same.

Thus, each clinician needs to register with the HIE that transmits the
data, and accompany each request with a personal identifier as well as
the type of information requested and the purpose. One service I
talked to, Covisint, can query
the AMA if necessary to verify the unique number assigned to each
physician in the us, the Drug Enforcement Administration (DEA) number.
(This is not the intended use of a DEA number, of course; it was
created to control the spread of pharmaceuticals, not data.)

One of the positive impacts of all this identification is that some
systems can retrieve information about patients from a variety of
hospitals, labs, pharmacies, and clinics even if the requester doesn't
know where it is. It's still up to them to determine whether to send
the data to the requester. Currently, providers exchange a Data Use
and Reciprocal Support Agreement (DURSA) to promise that information
will be stored properly and used only for the agreed-on purpose.
Exchanging these documents is currently cumbersome, and I've been told
the government is looking for a way to standardize the agreement so
the providers don't need to directly communicate.

The challenges in health information exchange: format

Let's suppose we're at the point where the owner of the record has
decided to send it to the requester. Despite the reverence expressed
by vendors for HL7 and other
standards with which the health care field is rife, documents require
a good deal of translation before they can be incorporated into the
receiving system. Each vendor presents a slightly different challenge,
so to connect n different products a vendor has to implement
n2 different transformations.

Reasons for this interoperability lie at many levels:

Lack of adherence to standards

Many vendors created their initial offerings before applicable
standards existed, and haven't yet upgraded to the standards or still
offer new features not covered by standards. The meaningful use
criteria discussed in yesterday's blog will accelerate the move to
standards.

Fuzzy standards

Like many standards, the ones that are common in the medical field
leave details unspecified.

Problems that lie out of scope

The standards tend to cover the easiest aspect of data exchange, the
document's format. As an indication of the problem, the 7 in HL7
refers to the seventh (application) layer of the ISO model. Brian
Behlendorf of Apache fame, now consulting with the federal government
to implement the NHIN, offers the following analogy. "Suppose that we
created the Internet by standardizing HTML and CSS but saying nothing
about TCP/IP and DNS."

Complex standards

As in other fields, the standards that work best in health records are
simple ones. There is currently a debate, for instance, over whether
to use the CCR or CCD exchange format for patient data. The trade-off
seems to be that the newer CCD is richer and more flexible but a lot
harder to support.

Misuse

As one example, the University of Pittsburgh Medical Center tried to
harmonize its problem lists and found that a huge number of
patients--including many men--were coded as smoking during pregnancy.
They should have been coded with a general tobacco disorder. As Dr.
William Hogan said, "People have an amazing ability to make a standard
do what it's not meant to do, even when it's highly specified and
constrained."

So many to choose from

Dell/Perot manager Jack Wankowski told me that even though other
countries have digitized their health records far more than the U.S.
has, they have a lot fewer published standards. It might seem logical
to share standards--given that people are people everywhere--but in
fact, that's hard to do because diagnosis and treatment are a lot
different in different cultures. Wankowski says, "Unlike other
industries such as manufacturing and financial services, where a lot
can be replicated, health care is very individual on a country by
country basis at the moment. Because of this, change is a lot slower."

Encumbrances

The UPMC coded its problem lists in ICD-9-CM instead of SNOMED, even
through SNOMED was far superior in specificity and clarity. Along with
historical reasons, they avoided SNOMED because it was a licensed
product until 2003 whereas ICD-9-CM was free. As for ICD-9-CM, its
official standard is distributed as RTF documents, making correct
adoption difficult.

Here are a few examples of how vendors told me they handle
interoperability.

InterSystems is a major
player in health care. The basis of their offerings is Caché,
an object database written in the classic programming language for
medical information processing, MUMPS. (MUMPS was also standardized by
an ANSI committee under the name M.) Caché can be found in all
major hospitals. For data exchange, InterSystems provides an HIE
called HealthShare, which they claim can communicate with other
vendors' systems by supporting HL7 and other appropriate standards.
HealthShare is both communications software and an actual hub that can
create the connections for customers.

Medicity is another key
HIE vendor. Providers can set up their own hubs or contract with a
server set up by Medicity in their geographic area. Having a hub means
that a small practice can register just once with the hub and then
communicate with all other providers in that region.

Let's turn again to Epic. Two facilities that use it can exchange a
wide range of data, because some of its data is not covered by
standards. A facility that uses another product can exchange a
narrower set of data with an Epic system over href="http://www.epic.com/software-interoperability.php">Care
Everywhere, using the standards. The Epic rep said they will move
more and more fields into Care Everywhere as standards evolve.

What all this comes down to is an enormous redundant infrastructure
that adds no value to electronic records, but merely runs a Red
Queen's Race to provide the value that already exists in those
records. We've already seen that defining more standards has a
limited impact on the problem. But a lot of programmers at this point
will claim the solution lies in open source, so let's see what's
happening in that area.

The open source challengers

The previous sections, like acts of a play, laid out the character of
the vendors in the health care space as earnest, hard-working, and
sometimes brilliantly accomplished, but ultimately stumbling through a
plot whose bad turns overwhelm them. In the current act we turn to a
new character, one who is not so well known nor so well tested, one
who has shown promise on other stages but is still finding her footing
on our proscenium.

The best-known open source projects in health care are href="http://openmrs.org/">OpenMRS, the Veterans Administration's
VistA, and the href="http://www.connectopensource.org/">NHIN CONNECT Gateway. I
won't say anything more about OpenMRS because it has received high
praise but has made little inroads into American health care. I'll
devote a few paragraphs to the strengths and weaknesses of VistA and
CONNECT.

Buzz in the medical world is that VistA beats commercial offerings for
usability and a general fit to the clinicians' needs. But it's
tailored to the Veterans Administration and--as a rep for the href="http://www.vxvista.org/">vxVistA called it--has to be
deveteranized for general use. This is what vxVistA does, but they are
not open source. They make changes to the core and contribute it back,
but their own products are proprietary. A community project called href="http://www.worldvista.org/">WorldVistA also works on a
version of VistA for the non-government sector.

One of the hurdles of adapting VistA is that one has to learn its
underlying language, MUMPS. Most people who dive in license a MUMPS
compiler. The vxVistA rep knows of no significant users of the free
software MUMPS compiler GT.M. VistA also runs on the Caché
database, mentioned earlier in this article. If you don't want to
license Caché from InterSystems, you need to find some other
database solution.

So while VistA is a bona fide open source project with a community,
it's ecosystem does not fit neatly with the habits of most free
software developers.

CONNECT is championed by the same Office of the National Coordinator
for Health Information Technology that is implementing the HITECH
recovery plan and meaningful use. A means for authenticating requests
and sending patient data between providers, CONNECT may well be
emerging as the HIE solution for our age. But it has some maturing to
do as well. It uses a SOAP-based protocol that requires knowledge of
typical SOA-based technologies such as SAML.

Two free software companies that have entered the field to make
installing CONNECT easier are href="http://www.axialexchange.com/">Axial Exchange, which creates
open source libraries and tools to work with the system, and the href="http://www.mirthcorp.com/">Mirth Corporation. Jon Teichrow
of Mirth told me how a typical CONNECT setup at a rural hospital took
just a week to complete, and can run for the cost of just a couple
hours of support time per week. The complexities of handling CONNECT
that make so many people tremulous, he said, were actually much easier
for Mirth than the more typical problem of interpreting the hospital's
idiosyncratic data formats.

Just last week, href="http://www.healthcareitnews.com/news/nhin-direct-launched-simpler-data-exchange">the
government announced a simpler interface to the NHIN called NHIN
Direct. Hopefully, this will bring in a new level of providers
who couldn't afford the costs of negotiating with CONNECT.

CONNECT has certainly built up an active community. href="http://agilex.com/">Agilex employee Scott E. Borst, who is
responsible for a good deal of the testing of CONNECT, tells me that
participation in development, testing, and online discussion is
intense, and that two people were recently approved as committers
without being associated with any company or government agency
officially affiliated with CONNECT.

The community is willing to stand up for itself, too. Borst says that
when CONNECT was made open source last year, it came with a Sun-based
development environment including such components as NetBeans and
GlassFish. Many community members wanted to work on CONNECT using
other popular free software tools. Accommodating them was tough at
first, but the project leaders listened to them and ended up with a
much more flexible environment where contributors could use
essentially any tools that struck their fancy.

Buried in href="http://www.healthcareitnews.com/news/blumenthal-unveils-proposed-certification-rule-himss10">a
major announcement yesterday about certification for meaningful
use was an endorsement by the Office of the National Coordinator
for open source. My colleague and fellow blogger Brian Ahier href="http://ahier.blogspot.com/2010/03/meaningful-certification.html">points
out that rule 4 for certification programs explicitly mentions
open source as well self-developed solutions. This will not magically
lead to more open source electronic health record systems like
OpenMRS, but it offers an optimistic assessment that they will emerge
and will reach maturity.

As I mentioned earlier, traditional vendors are moving more toward
openness in the form of APIs that offer their products as platforms.
InterSystems does this with a SOAP-based interface called Ensemble,
for instance. Eclipsys,
offering its own SOAP-based interface called Helios, claims that they
want an app store on top of their product--and that they will not kick
off applications that compete with their own.

Web-based Practice Fusion has an API in beta, and is also planning an
innovation that makes me really excited: a sandbox provided by their
web site where developers can work on extensions without having to
download and install software.

But to a long-time observer such as Dr. Adrian Gropper, founder of the
MedCommons storage service,
true open source is the only way forward for health care records. He
says we need to replace all those SOAP and WS-* standards with RESTful
interfaces, perform authentication over OpenID and OAuth, and use the
simplest possible formats. And only an enlightenment among the major
users--the health care providers--will bring about the revolution.

But at this point in the play, having explored the characters of
electronic record vendors and the open source community, we need to
round out the drama by introducing yet a third character: the patient.
Gropper's MedCommons is a patient-centered service, and thus part of a
movement that may bring us openness sooner than OpenMRS, VistA, or
CONNECT.

Enter the patient

Most people are familiar with Microsoft's HealthVault and Google
Health. Both allow patients to enter data about their own health, and
provide APIs that individuals and companies alike are using to provide
services. A Journal of Participatory
Medicine
has just been launched, reflecting the growth of interest
in patient-centered or participatory medicine. I saw a book on the
subject by HIMSS itself in the conference bookstore.

The promise of personal health records goes far beyond keeping track
of data. Like electronic records in clinicians' hands, the data will
just be fodder for services with incredible potential to improve
health. In a lively session given today by Patricia Brennan of href="http://www.projecthealthdesign.org/">Project HealthDesign,
she used the metaphors of "intelligent medicines" and "smart
Band-Aids" that reduce errors and help patients follow directions.

Project HealthDesign's research has injected a dose of realism into
our understanding of the doctor-patient relationship. For instance,
they learned that we can't expect patients to share everything with
their doctors. They get embarrassed when they lapse in their behavior,
and don't want to admit they take extra medications or do other things
not recommended by doctors. So patient-centered health should focus on
delivering information so patients can independently evaluate what
they're doing.

As critical patient data becomes distributed among a hundred million
individual records, instead of being concentrated in the hands of
providers, simple formats and frictionless data exchange will emerge
to handle them. Electronic record vendors will adapt or die. And a
whole generation of products--as well as users--will grow up with no
experience of anything but completely open, interoperable systems.

February 05 2010

One hundred eighty degrees of freedom: signs of how open platforms are spreading

I was talking recently with Bob Frankston, who has a href="http://frankston.com/public/Bob_Frankston_Bio.asp">distinguished
history in computing that goes back to work on Multics, VisiCalc,
and Lotus Notes. We were discussing some of the dreams of the Internet
visionaries, such as total decentralization (no mobile-system walls,
no DNS) and bandwidth too cheap to meter. While these seem impossibly
far off, I realized that computing and networking have come a long way
already, making things normal that not too far in the past would have
seemed utopian.



Flat-rate long distance calls

I remember waiting past my bedtime to make long-distance calls, and
getting down to business real quick to avoid high charges.
Conventional carriers were forced to flat-rate pricing by competition
from VoIP (which I'll return to later in the blog). International
calls are still overpriced, but with penny-per-minute cards available
in any convenience store, I don't imagine any consumers are paying
those high prices.



Mobile phone app stores

Not that long ago, the few phones that offered Internet access did so
as a novelty. Hardly anybody seriously considered downloading an
application to their phones--what are you asking for, spam and
fraudulent charges? So the iPhone and Android stores teaming with
third-party apps are a 180-degree turn for the mobile field. I
attribute the iPhone app store once again to competition: the href="http://www.oreillynet.com/onlamp/blog/2008/01/the_unflappable_free_software.html">uncovering
of the iPhone SDK by a free software community.



Downloadable TV segments

While the studios strike deals with Internet providers, send out
take-down notices by the ream, and calculate how to derive revenue
from television-on-demand, people are already getting the most popular
segments from Oprah Winfrey or Saturday Night Live whenever they want,
wherever they want.



Good-enough generic devices

People no longer look down on cheap, generic tools and devices. Both
in software and in hardware, people are realizing that in the long run
they can do more with simple, flexible, interchangeable parts than
with complex and closed offerings. There will probably always be a
market for exquisitely designed premium products--the success of Apple
proves that--but the leading edge goes to products that are just "good
enough," and the DIY movement especially ensures a growing market for
building blocks of that quality.


I won't even start to summarize Frankston's own href="http://frankston.com/public/">writings, which start with
premises so far from what the Internet is like today that you won't be
able to make complete sense of any one article on its own. I'd
recommend the mind-blowing href="http://frankston.com/public/?n=Sidewalks">Sidewalks: Paying by
the Stroll if you want to venture into his world.

But I'll mention one sign of Frankston's optimism: he reminded me that
in the early 1990s, technologists were agonizing over arcane
quality-of-service systems in the hope of permitting VoIP over
ordinary phone connections. Now we take VoIP for granted and are
heading toward ubiquitous video. Why? Two things happened in parallel:
the technologists figured out much more efficient encodings, and
normal demand led to faster transmission technologies even over
copper. We didn't need QoS and all the noxious control and overhead it
entails. More generally, it's impossible to determine where progress
will come from or how fast it can happen.

January 25 2010

Four short links: 23 January 2010

  1. WikiLeaks Fundraising -- PayPal has frozen WikiLeaks' assets. Interesting: they need $600k/yr to run.
  2. The Great Australian Internet Blackout -- online protest to raise awareness about the Great Firewall of Australia.
  3. HTML5 Video: Problems Ahead -- YouTube and Vimeo won't support a free codec (file format). The web is undeniably better for Mozilla having entered the browser market, and it would have been impossible for us to do so if there had been a multi-million-dollar licensing fee required for handling HTML, CSS, JavaScript or the like. It's not just a matter of Mozilla licensing formats such as H.264 for browsers and their users: sites would have to license to distribute content.
  4. History of the World in 100 Objects (BBC) -- a radio show, telling the history of humanity in 100 objects from the British Library. Exquisitely high quality commentary (available in original audio and in textual transcript), hi-resolution images, maps, timelines, and more. It's growing day by day as episodes air, and shows how a quintessentially offline place like a museum can add to the online world.

January 07 2010

Pew Research asks questions about the Internet in 2020

Pew Research, which seems to be interested in just about everything,
conducts a "future of the Internet" survey every few years in which
they throw outrageously open-ended and provocative questions at a
chosen collection of observers in the areas of technology and
society. Pew makes participation fun by finding questions so pointed
that they make you choke a bit. You start by wondering, "Could I
actually answer that?" and then think, "Hey, the whole concept is so
absurd that I could say anything without repercussions!" So I
participated in their href="http://www.pewinternet.org/Reports/2006/The-Future-of-the-Internet-II.aspx"
2006 survey and did it again this week. The Pew report will
aggregate the yes/no responses from the people they asked to
participate, but I took the exercise as a chance to hammer home my own
choices of issues.

(If you'd like to take the survey, you can currently visit

http://www.facebook.com/l/c6596;survey.confirmit.com/wix2/p1075078513.aspx

and enter PIN 2000.)

Will Google make us stupid?

This first question is not about a technical or policy issue on the
Internet or even how people use the Internet, but a purported risk to
human intelligence and methods of inquiry. Usually, questions about
how technology affect our learning or practice really concern our
values and how we choose technologies, not the technology itself. And
that's the basis on which I address such questions. I am not saying
technology is neutral, but that it is created, adopted, and developed
over time in a dialog with people's desires.

I respect the questions posed by Nicholas Carr in his Atlantic
article--although it's hard to take such worries seriously when he
suggests that even the typewriter could impoverish writing--and would
like to allay his concerns. The question is all about people's
choices. If we value introspection as a road to insight, if we
believe that long experience with issues contributes to good judgment
on those issues, if we (in short) want knowledge that search engines
don't give us, we'll maintain our depth of thinking and Google will
only enhance it.

There is a trend, of course, toward instant analysis and knee-jerk
responses to events that degrades a lot of writing and discussion. We
can't blame search engines for that. The urge to scoop our contacts
intersects with the starvation of funds for investigative journalism
to reduce the value of the reports we receive about things that are
important for us. Google is not responsible for that either (unless
you blame it for draining advertising revenue from newspapers and
magazines, which I don't). In any case, social and business trends
like these are the immediate influences on our ability to process
information, and searching has nothing to do with them.

What search engines do is provide more information, which we can use
either to become dilettantes (Carr's worry) or to bolster our
knowledge around the edges and do fact-checking while we rely mostly
on information we've gained in more robust ways for our core analyses.
Google frees the time we used to spend pulling together the last 10%
of facts we need to complete our research. I read Carr's article when
The Atlantic first published it, but I used a web search to pull it
back up and review it before writing this response. Google is my
friend.

Will we live in the cloud or the desktop?

Our computer usage will certainly move more and more to an environment
of small devices (probably in our hands rather than on our desks)
communicating with large data sets and applications in the cloud.
This dual trend, bifurcating our computer resources between the tiny
and the truly gargantuan, have many consequences that other people
have explored in depth: privacy concerns, the risk that application
providers will gather enough data to preclude competition, the
consequent slowdown in innovation that could result, questions about
data quality, worries about services becoming unavailable (like
Twitter's fail whale, which I saw as recently as this morning), and
more.

One worry I have is that netbooks, tablets, and cell phones will
become so dominant that meaty desktop systems will rise in the cost
till they are within the reach only of institutions and professionals.
That will discourage innovation by the wider populace and reduce us to
software consumers. Innovation has benefited a great deal from the
ability of ordinary computer users to bulk up their computers with a
lot of software and interact with it at high speeds using high quality
keyboards and large monitors. That kind of grassroots innovation may
go away along with the systems that provide those generous resources.

So I suggest that cloud application providers recognize the value of
grassroots innovation--following Eric von Hippel's findings--and
solicit changes in their services from their visitors. Make their code
open source--but even more than that, set up test environments where
visitors can hack on the code without having to download much
software. Then anyone with a comfortable keyboard can become part of
the development team.

We'll know that software services are on a firm foundation for future
success when each one offers a "Develop and share your plugin here"
link.

Will social relations get better?

Like the question about Google, this one is more about our choices
than our technology. I don't worry about people losing touch with
friends and family. I think we'll continue to honor the human needs
that have been hard-wired into us over the millions of years of
evolution. I do think technologies ranging from email to social
networks can help us make new friends and collaborate over long
distances.

I do worry, though, that social norms aren't keeping up with
technology. For instance, it's hard to turn down a "friend" request
on a social network, particularly from someone you know, and even
harder to "unfriend" someone. We've got to learn that these things are
OK to do. And we have to be able to partition our groups of contacts
as we do in real life (work, church, etc.). More sophisticated social
networks will probably evolve to reflect our real relationships more
closely, but people have to take the lead and refuse to let technical
options determine how they conduct their relationships.

Will the state of reading and writing be improved?

Our idea of writing changes over time. The Middle Ages left us lots of
horribly written documents. The few people who learned to read and
write often learned their Latin (or other language for writing) rather
minimally. It took a long time for academies to impose canonical
rules for rhetoric on the population. I doubt that a cover letter and
resume from Shakespeare would meet the writing standards of a human
resources department; he lived in an age before standardization and
followed his ear more than rules.

So I can't talk about "improving" reading and writing without
addressing the question of norms. I'll write a bit about formalities
and then about the more important question of whether we'll be able to
communicate with each other (and enjoy what we read).

In many cultures, writing and speech have diverged so greatly that
they're almost separate languages. And English in Jamaica is very
different from English in the US, although I imagine Jamaicans try
hard to speak and write in US style when they're communicating with
us. In other words, people do recognize norms, but usage depends on
the context.

Increasingly, nowadays, the context for writing is a very short form
utterance, with constant interaction. I worry that people will lose
the ability to state a thesis in unambiguous terms and a clear logical
progression. But because they'll be in instantaneous contact with
their audience, they can restate their ideas as needed until
ambiguities are cleared up and their reasoning is unveiled. And
they'll be learning from others along with way. Making an elegant and
persuasive initial statement won't be so important because that
statement will be only the first step of many.

Let's admit that dialog is emerging as our generation's way to develop
and share knowledge. The notion driving Ibsen's Hedda Gabler--that an
independent philosopher such as Ejlert Løvborg could write a
masterpiece that would in itself change the world--is passé. A
modern Løvborg would release his insights in a series of blogs
to which others would make thoughtful replies. If this eviscerated
Løvborg's originality and prevented him from reaching the
heights of inspiration--well, that would be Løvborg's fault for
giving in to pressure from more conventional thinkers.

If the Romantic ideal of the solitary genius is fading, what model for
information exchange do we have? Check Plato's Symposium. Thinkers
were expected to engage with each other (and to have fun while doing
so). Socrates denigrated reading, because one could not interrogate
the author. To him, dialog was more fertile and more conducive to
truth.

The ancient Jewish scholars also preferred debate to reading. They
certainly had some received texts, but the vast majority of their
teachings were generated through conversation and were not written
down at all until the scholars realized they had to in order to avoid
losing them.

So as far as formal writing goes, I do believe we'll lose the subtle
inflections and wordplay that come from a widespread knowledge of
formal rules. I don't know how many people nowadays can appreciate all
the ways Dickens sculpted language, for instance, but I think there
will be fewer in the future than there were when Dickens rolled out
his novels.

But let's not get stuck on the aesthetics of any one period. Dickens
drew on a writing style that was popular in his day. In the next
century, Toni Morrison, John Updike, and Vladimir Nabokov wrote in a
much less formal manner, but each is considered a beautiful stylist in
his or her own way. Human inventiveness is infinite and language is a
core skill in which we we all take pleasure, so we'll find new ways to
play with language that are appropriate to our age.

I believe there will always remain standards for grammar and
expression that will prove valuable in certain contexts, and people
who take the trouble to learn and practice those standards. As an
editor, I encounter lots of authors with wonderful insights and
delightful turns of phrase, but with deficits in vocabulary, grammar,
and other skills and resources that would enable them to write better.
I work with these authors to bring them up to industry-recognized
standards.

Will those in GenY share as much information about themselves as they age?

I really can't offer anything but baseless speculation in answer to
this question, but my guess is that people will continue to share as
much as they do now. After all, once they've put so much about
themselves up on their sites, what good would it do to stop? In for a
penny, in for a pound.

Social norms will evolve to accept more candor. After all, Ronald
Reagan got elected President despite having gone through a divorce,
and Bill Clinton got elected despite having smoked marijuana.
Society's expectations evolve.

Will our relationship to key institutions change?

I'm sure the survey designers picked this question knowing that its
breadth makes it hard to answer, but in consequence it's something of
a joy to explore.

The widespread sharing of information and ideas will definitely change
the relative power relationships of institutions and the masses, but
they could move in two very different directions.

In one scenario offered by many commentators, the ease of
whistleblowing and of promulgating news about institutions will
combine with the ability of individuals to associate over social
networking to create movements for change that hold institutions more
accountable and make them more responsive to the public.

In the other scenario, large institutions exploit high-speed
communications and large data stores to enforce even greater
centralized control, and use surveillance to crush opposition.

I don't know which way things will go. Experts continually urge
governments and businesses to open up and accept public input, and
those institutions resist doing so despite all the benefits. So I have
to admit that in this area I tend toward pessimism.

Will online anonymity still be prevalent?

Yes, I believe people have many reasons to participate in groups and
look for information without revealing who they are. Luckily, most new
systems (such as U.S. government forums) are evolving in ways that
build in privacy and anonymity. Businesses are more eager to attach
our online behavior to our identities for marketing purposes, but
perhaps we can find a compromise where someone can maintain a
pseudonym associated with marketing information but not have it
attached to his or her person.

Unfortunately, most people don't appreciate the dangers of being
identified. But those who do can take steps to be anonymous or
pseudonymous. As for state repression, there is something of an
escalating war between individuals doing illegal things and
institutions who want to uncover those individuals. So far, anonymity
seems to be holding on, thanks to a lot of effort by those who care.

Will the Semantic Web have an impact?

As organizations and news sites put more and more information online,
they're learning the value of organizing and cross-linking
information. I think the Semantic Web is taking off in a small way on
site after site: a better breakdown of terms on one medical site, a
taxonomy on a Drupal-powered blog, etc.

But Berners-Lee had a much grander vision of the Semantic Web than
better information retrieval on individual sites. He's gunning for
content providers and Web designers the world around to pull together
and provide easy navigation from one site to another, despite wide
differences in their contributors, topics, styles, and viewpoints.

This may happen someday, just as artificial intelligence is looking
more feasible than it was ten years ago, but the chasm between the
present and the future is enormous. To make the big vision work, we'll
all have to use the same (or overlapping) ontologies, with standards
for extending and varying the ontologies. We'll need to disambiguate
things like webbed feet from the World Wide Web. I'm sure tools to
help us do this will get smarter, but they need to get a whole lot
smarter.

Even with tools and protocols in place, it will be hard to get
billions of web sites to join the project. Here the cloud may be of
help. If Google can perform the statistical analysis and create the
relevant links, I don't have to do it on my own site. But I bet
results would be much better if I had input.

Are the next takeoff technologies evident now?

Yes, I don't believe there's much doubt about the technologies that
companies will commercialize and make widespread over the next five
years. Many people have listed these technologies: more powerful
mobile devices, ever-cheaper netbooks, virtualization and cloud
computing, reputation systems for social networking and group
collaboration, sensors and other small systems reporting limited
amounts of information, do-it-yourself embedded systems, robots,
sophisticated algorithms for slurping up data and performing
statistical analysis, visualization tools to report the results of
that analysis, affective technologies, personalized and location-aware
services, excellent facial and voice recognition, electronic paper,
anomaly-based security monitoring, self-healing systems--that's a
reasonable list to get started with.

Beyond five years, everything is wide open. One thing I'd like to see
is a really good visual programming language, or something along those
lines that is more closely matched to human strengths than our current
languages. An easy high-level programming language would immensely
increase productivity, reduce errors (and security flaws), and bring
in more people to create a better Internet.

Will the internet still be dominated by the end-to-end principle?

I'll pick up here on the paragraph in my answer about takeoff
technologies. The end-to-end principle is central to the Internet I
think everybody would like to change some things about the current
essential Internet protocols, but they don't agree what those things
should be. So I have no expectation of a top-to-bottom redesign of the
Internet at any point in our viewfinder. Furthermore, the inertia
created by millions of systems running current protocols would be hard
to overcome. So the end-to-end principle is enshrined for the
foreseeable future.

Mobile firms and ISPs may put up barriers, but anyone in an area of
modern technology who tries to shut the spiget on outside
contributions eventually becomes last year's big splash. So unless
there's a coordinated assault by central institutions like
governments, the inertia of current systems will combine with the
momentum of innovation and public demand for new services to keep
chokepoints from being serious problems.

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.

Don't be the product, buy the product!

Schweinderl