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

October 20 2011

OSEHRA's first challenge: VistA version control

As I mentioned previously, the VA is making a formal open-source project and governing body for its VistA electronic health record (EHR) system. VistA was developed internally by the VA in a collaborative, open-source fashion, but it has essentially been open source within the VA, with no attention or collaboration with VistA users outside the VA.

There are several challenges that the Open Source Electronic Health Record Agent (OSEHRA) faces, and many of them sit squarely between technical and political issues.

The first question any open-source project must answer is: "Who can commit?" That's almost immediately followed by: "How do we decide who can commit?" But to manage VistA OSEHRA, we must first ask: "How do we commit?" There is no version control system that currently works with VA VistA.

VistA is famously resistant to being managed via version control systems. The reason? Over the course of development of VistA, which predates most modern version control systems, updating was handled by a tool developed specifically for VistA. That system is called KIDS.

The problem with KIDS, and managing version control generally in VistA, is that MUMPS, the language/database that VistA is programmed in, happily lends itself to "source code in the database." MUMPS is a merged database and programming language, and is an intellectual predecessor to modern NoSQL databases. MUMPS is a dominant force in healthcare, and despite comments to the contrary by its numerous critics, it has features that are ideal for healthcare. (This is another excellent place to shamelessly plug "Meaningful Use and Beyond," which discusses the comprehensive use of MUMPS in healthcare.)

To understand the issue with MUMPS and VistA you must:

  • Imagine developing an application using Node.js and MongoDB.
  • Imagine that Node.js and MongoDB are one project.
  • Imagine doing that for 30 years.

Given that in MUMPS the programming language is the database and the database is the programming language, certain problematic historical decisions were made. First, MUMPS' executable code is sometimes included inside the MUMPS database. That makes it pretty impossible to map out what the source code is doing separately from what the database is doing.

Overlay the fact that the KIDS update system (think YUM for VistA) would update both the source code "on disk" at the same time as updating the system "in memory." KIDS is like source code patches and system updates all rolled together.

OSEHRA must find a way to reconcile the KIDS process with a version control system. Without that, there is no way to reconcile a VistA development environment with a given production environment.

Without a modern distributed version control system (DVCS) powering VistA development, OSEHRA will be unable to run VistA development as a meritocracy. The technology enables multiple parties to participate as "core VistA developers."

Without a DVCS, the VA had to rely on a process for software based on "classes" of software. Class I software was released by the national VA office and was the core of the EHR installed at each VA hospital. Class II was software that was used regionally or at several hospitals. Class III software was software that was used locally at one VA hospital.

VistA programmers at each hospital were required to reconcile Class I patches from the national office (which came as KIDS patches) with local instances that included Class III software. Each KIDS patch had the potential for requiring a local hospital programming effort in order to reconcile with local software changes.

With a DVCS, multiple parties could develop "core" changes to VistA, freeing the VA from the top-down VistA development management that prevents outsiders from contributing back. Remember, one of the largest "outsiders" to the VA is the Resource and Patient Management System (RPMS), which is a VistA fork extensively developed and improved by another federal agency, the Indian Health Service (IHS).

The KIDS- and Class-based software deployment model essentially made interagency cooperation between IHS and the VA impossible. There was no way for another "master" copy of the EHR to exist in cooperation.

To solve this problem, OSEHRA is betting heavily on Git and creating a project called SKIDS. From that project's page:

This project will design and implement "Source KIDS" in order to represent VistA software in a source tree suitable for use with modern version control tools. Once deployed, SKIDS will make it possible to exchange source code and globals between VistA instances and Git repositories.

"Globals" in MUMPS means "the database," which is different than most programming languages. With that explained, you can see that this project is intended to address exactly the problem that I have just outlined.

There is no guarantee that OSEHRA will be successful. Not everyone in the VA bureaucracy is keen on the notion of truly open-source VistA. Those of us in the VistA community outside the VA are apprehensive. We want to believe that OSEHRA is for real and will actually become the true seat of VistA development that is friendly to outsiders like us and run as a transparent open-source project. The single most important thing that OSEHRA can do to ensure the success of a truly open-source VistA process is to tackle and handle these challenges well.

The fact that OSEHRA is addressing these problems head-on is a very good sign. The emphasis on Git has been obvious from early days. The new SKIDS project indicates that there is a distinct lack of pointy-haired bosses at OSEHRA. They might be biting off more than they can chew, but there is no confusion about identifying the problems that need solving.

There are other major challenges facing OSEHRA, but almost all of them are manageable if a collaborative development process is created that lets the best ideas about VistA bubble to the top. Most open-source projects simply take for granted the transparency afforded by a version control system, and almost all theory about how to manage a project well are based on the assumption of that transparency. So, this problem really lives "underneath" all of the other potential issues that OSHERA will face. If it can get this one right, or mostly right — or even "leastly" wrong — it will be a long way toward solving all of the other issues.

Meaningful Use and Beyond: A Guide for IT Staff in Health Care — Meaningful Use underlies a major federal incentives program for medical offices and hospitals that pays doctors and clinicians to move to electronic health records (EHR). This book is a rosetta stone for the IT implementer who wants to help organizations harness EHR systems.

Related:

October 19 2011

OSEHRA and the future of VA VistA

Apache Web Server, GNU/Linux Operating System, MySQL Database, Mozilla's Firefox Browser.

All pillars among the open-source community.

Each of these deserves its imminent position as a venerated project. Each has changed the world, and not a little. Moreover, they are the projects that spring to mind when we seek to justify the brilliance of the open-source licensing and development models.

But if this is intended to be a list of the highest-impact and most significant open-source projects, there is a project missing from this list.

VA VistA.

VA VistA is arguably the best electronic health record (EHR) in existence. It was developed over the course of several decades by federal employees in a collaborative, open-source fashion. Because it was developed by the U.S. government, it is available under the Freedom of Information Act (FOIA) in the public domain. VistaA has served as the basis for several open-source and proprietary products.

Anyone with expertise in health IT knows about VistA, but few in the open-source community are aware of the project. This is tragic, because it really is one of the most important examples of an open-source system anywhere, for any reason. Why? Because Veterans Affairs (VA) has been able to use VistA to deliver a system of high-quality healthcare.

That word "system" is important. You will get excellent healthcare at Mayo, Harvard, Cleveland Clinic, etc., but it is difficult to make a "system" that consistently delivers excellent healthcare. The VA has done that, and VistA is basically the health IT "operating system" that has made it possible. (I wrote and maintain the WorldVistA "What is VistA Really?" page if you would like further context on the system.)

Sounds amazing right? And it is. But there's a problem: VistA has been rotting. Development has largely stagnated in the last two decades.

This stagnation is mostly due to VistA's institutionalization at the VA. VistA was not developed as an "approved" project. It was developed as a kind of rebellion against the backward software that was available at the time and a rebellion against the backward ideas held by VA bureaucracy. This rebellion was called the "underground railroad" among VistA insiders.

Once the VA approved the project and started managing the software development using top-down practices, everything slowed to a crawl. Imagine the bazaar being "blessed" and moved into the cathedral.

Several outsiders in open-source health IT have been advocating for the VA to return VistA to its open-source roots. I wrote a proposal to make VistA truly open source, and Rick Marshal blogs about this almost exclusively.

Recently, a new, enlightened leadership at the VA has decided that taking the open-source route is precisely what VA VistA needs. The result is the Open Source Electronic Health Record Agent, or OSEHRA.

OSEHRA faces tremendous challenges. VistA uses a technical stack that makes typical project management very difficult, and there are several thorny political issues involved. But if this transition is successful, it could truly be a revolution for health IT.

If you care about healthcare software and open source, participating in OSEHRA is worth your while.

Meaningful Use and Beyond: A Guide for IT Staff in Health Care — Meaningful Use underlies a major federal incentives program for medical offices and hospitals that pays doctors and clinicians to move to electronic health records (EHR). This book is a rosetta stone for the IT implementer who wants to help organizations harness EHR systems.

Related:

August 19 2010

The software behind the VA health care transformation

Best Care AnywherePhillip Longman's book "Best Care Anywhere," just released in its second edition, had a strong effect on me that cascaded off of several other experiences and encounters I've had recently. The material should have been more familiar to me. The Veterans Administration's quality efforts have become health care industry buzz, and its illustrious VistA software has also often made the news, a couple times for its near-death experiences. But VistA is still not the subject of daily discussion in American public life.

I'm beginning to think our blind spot about the VA and VistA comes
from the sheer magnitude of the whole achievement. Longman's
modest-length book is just an introduction to the swirling mass of
issues that come with this topic: what VA's quality program has to say
about health care, about business motivations, about government, about
software development, even about ordinary people and how they handle
the most important aspects of their own lives.

There's just too much there for us to absorb, and the lessons of VistA
force us to relinquish too many prejudices. I'm beginning to make the
necessary shift to understanding VistA after talking to doctors,
hearing from the people porting it to new environments, and now
reading Longman's book. For other people without so many contacts in
the health care field, his book is a good start. Don't expect it to
answer all your questions, but just to make you uncomfortable enough
to change the way you think -- and act.

I'll focus on the development and technical aspects of VistA in this
blog, because I'm writing for a computer technology website. But we
should recognize the big points made by Longman, a journalist with a
clear public policy agenda:

  • The VA is way ahead of most U.S. providers in quality -- Some of the quality control measures have been in place for 30 years and are incredibly simple, but are still nearly unique to the VA. They also have very sophisticated uses for data, including intensive and routine data mining, and hook-ups of devices in people's homes.
  • The VA provides a model being adopted around the world -- Leading health care institutions in several countries, notably Jordan and Mexico, have implemented or are implementing VistA and its information-driven care model. It's happening in the U.S. too. Adoption is slow to start with because there are only a few small companies actively marketing VistA solutions (and they don't cooperate as well as they should). But the huge provider Kaiser Permanente interoperates with the VA and uses many of its techniques.
  • The mainstream health care industry can't change because of business models -- The culprit to which Longman points is the long-criticized
    fee-for-service model. He cites many private institutions that tried to do the right thing for their patients and provide long-term treatments, including life style changes. All these institutions went bankrupt because they weren't reimbursed for making patients healthier, and could not recoup the cost savings created by keeping patients healthy. He ascribes similar problems to the HMO movement, which began with wonderful ideals and degenerated into one of the most hated businesses in the U.S.
  • Modern health care requires a life-long relationship to the patient -- Longman says that the key to the VA's quality approach was their realization that they would remain responsible for their patients throughout their life spans. Quality controls that didn't make business sense in private institutions did wonders for the VA. But
    this doesn't mean we need socialized medicine (depending on how you define that emotion-laden term) or even a public insurance option. Rather, we should create a national system based on the VA's successes, where doctors are rewarded for following evidence-based medicine.


There's a lot more in this pithy and readable book, such as how to
encourage providers to report errors and how to expand the VA health
care system. I'll let you get the book for yourself to enjoy the
details. I'll turn now to the software-related issues raised by the
book.

Bottom-up development wins big

VistA software was most decidedly a bazaar, not a cathedral. It was conceived by doctors in the late 1970s, and built either by health care providers or by programmers working closely (sometimes having chairs literally side by side) with health care providers. VistA is actually a loosely interconnected system containing over 100 integrated, patient-focused applications.

Distributed development started because many different doctors had
bright ideas at about the same time. The distributed approach
continued despite (perhaps even because of) overt persecution. When
the developers tried to get together to formalize their relationships,
they were discovered and disciplined (through firings or having their
computers confiscated) because they were bucking the official
mainframe-based IT team. The developers' tenuous position was
reflected in the name they picked for themselves, the Hard Hats, and
even more in the name attributed to them later by the head of the VA:
the Underground Railroad.

Conceptually, VistA also emerged in a bazaar-like fashion. No one
originally thought of the comprehensive life-long health management
system VistA has become. Rather, each piece of the system emerged from
a narrow need recognized by a health care provider: keeping track of
diagnoses, analyzing diabetic nutrition, ensuring that medicine was
administered to patients properly, and so on. Eventually, once the VA
administration got on board the railroad, everything was linked
together.

It's a truism that open source software development (and perhaps all
software development ) is best driven by the people who will
ultimately use it. So we can understand why VistA meets certain
essential needs -- such as allowing an emergency room doctor enter an
order within a few seconds -- that are missed by most proprietary
software in the health care field. But I find it surprising that the
system could work so well when each piece was developed in isolation.
Perhaps the software used can provide a clue.

The MUMPS language and database

VistA, like most proprietary products offered for sale to health care
providers, is written in a language called MUMPS, invented at
Massachusetts General Hospital in 1966 and standardized as M by ANSI
and ISO. MUMPS is little more than an interface to a hierarchical,
key-value database (pretty much an associative array). What SQL is for
relational databases, MUMPS is for this hierarchical database. The
rest of the language, to my mind, is just a thin wrapper with
essential language traits such as flow control constructs and string
manipulation.

As a child of the' 60s, MUMPS shares the hippie libertarian trappings
of languages from that time. For instance, it has no concept of
packaging, and certainly no concern for "GOTOs considered harmful."
Instead of formal functions, it lets a programmer jump to a label at
any point in the program, even in another file. However, GOTOs are not
required for MUMPS programs any more than they are for C programs, and
MUMPS has features that modern programmers expect, such as
parameter-passing, localizing variables to particular scopes, block
structure, etc. It also comes with features to write applications that
use multiple, cooperating processes.

Perhaps this extreme open architecture for programs made integration
easy. But tying programs together isn't the only task in integration;
data from one program must also be accessible to others.

Here we turn to the hierarchical database. Persistence in MUMPS is
achieved simply by marking data as "global," which is like tied
variables in Perl. Every read or write to a global variable involves
the file system.

The VA, Department of Defense, and Indian Health Service have
licensed, for use with VistA and its derivatives, a proprietary
database called Caché from the company InterSystems. An open
source implementation of MUMPS, led by K.S. Bhaskar and called GT.M,
is available from FIS, a large public corporation, with support on
commercial terms. GT.M has its own database and is popular for VistA
implementations outside the Federal government.

Most databases assign types to data. If one database calls an ID a
Patient and another calls it a Client, you have to write special
conversion code to tie them together. Things are even harder if
Patient is stored as an integer and Client as a string.

In MUMPS, everything is a string (a choice that was popular with other
scripting languages as well, notably Tcl). MUMPS offers "canonical
numbers," strings that encode numeric values and can be input to
mathematical operations. So there's no such thing as data conversion
problems.

What you do need to do, however, is find the exact path to a data
item. Unlike SQL, you can't simply ask the database to tell you
everything it knows about a patient. You have to know where the
patient is in the hierarchy. MUMPS provides just two simple functions
for retrieving data: you can specify a node in the hierarchy, or start
at an arbitrary point in the hierarchy and cycle through it in order,
somewhat like an SQL cursor.


While it may not be obvious how these very simple operations and data
structures can produce highly interconnected, robust systems, the VA
has proven that it can be done. The key to using such fundamental -- but
powerful -- data structuring and representation is to create
higher-level data abstractions that map real-world information at a
higher level.

Furthermore, you don't need to learn MUMPS unless you want to program
VistA internals. VistA exposes its functionality through remote
procedure calls, and open source wrappers provide access to this
functionality from modern languages such as Python and Java, href="http://medsphere.org/community/project/ovid">OVID from href="http://medsphere.org/">Medsphere being one example.

If you'd like to learn more about VistA, help to add features so it
can become the nation's electronic health record system, or just meet
the fascinating people who work with it, check out the href="http://www.worldvista.org/">WorldVistA community. As Longman
points out, doctors are moving quickly to install electronic record
systems so they can benefit from government funding. To play in this
space, VistA needs both more promotion and (according to one project
leader, Joseph Dal Molin) changes to simplify deployment and
configuration.


Related:

Tags: healthit vista

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.

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.

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