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

March 28 2011

App to dig into epidemiological data wins Practice Fusion challenge award


Congratulations are due to John Schrom, at 26 years old both an
epidemiologist and now a bona-fide hacker can boast of first prize in
Practice Fusion's latest href="http://www.practicefusion.com/pages/pr/disease-control-application-for-doctors-ins-health-2.0-data-challenge.html">challenge
to find a use for their massive health data sets. Schrom, an
employee of Hennepin County Medical Center serving Minneapolis, also
develops code for a company named href"http://www.epicenter.com/">Epicenter, and found a free
weekend to code up a program that displays data in different
groups--by state, by diagnosis, by age range, and so on--and lets the
user quickly find where at-risk populations are. He explains the
purpose and use of the program in a href"http://www.youtube.com/watch?v=y75OK9pqePs&feature=player_embedded#at=116">brief
video, embedded below.

height="390" src="http://www.youtube.com/embed/y75OK9pqePs"<br /> frameborder="0" allowfullscreen></p> <p> <p>This kind of epidemiology is not the disaster kind, like trying to<br /> quickly identify flu outbreaks (which Google found it could do by<br /> totaling up significant search strings). Rather, it answers such<br /> questions as "which age range or racial group should we concentrate on<br /> when promoting preventative measures?" or "how well did our hospital<br /> perform compared to other hospitals facing similar diseases?"</p> <p> <p>Thus, the Epicenter app reflects a recent concern with delivering more<br /> carefully delineated treatments to populations. Genetic testing, for<br /> instance, is starting to identify more precisely who responds to a<br /> particular drug. Whereas up to now doctors could only say, "This seems<br /> to cure 80% of the people we give it to," they are starting to predict<br /> better who falls into that 80% and who is among the 20% for whom the<br /> drug would be a waste. Many institutions--notably the Veterans<br /> Administration, but even a single large hospital--are also learning to<br /> determine which types of patients they are treating well, and where<br /> they fall down, by collecting data on each intervention and running<br /> the stats. Schrom's app fits into this trend.</p> <p> <p>Emily Peters, Director of Communications at Practice Fusion, who was<br /> also a judge in the contest, says, "John comes from the frontlines of<br /> epidemiology and applied his knowledge and experience in building<br /> Epicenter. We love that the concept is so cool and that it offers a<br /> very tangible benefit and practical use for the medical community at<br /> large."</p> <p> <p>The Practice Fusion data is quite detailed while being sufficiently<br /> de-identified (at least according to current standards in the medical<br /> field) to meet privacy requirements. So with Schrom's app you can<br /> drill down through demographic data to the level of a single patient.</p> <p> <p>Schrom told me the app is a preliminary prototype and will be<br /> developed in several ways. Currently you can look at data by state or<br /> by groupings of states that you choose to combine; he would like more<br /> targeted geographic comparisons. He'd like to add lab data and make<br /> the types of comparisons more flexible. Finally, he's aware that the<br /> graphical interface could use a facelift. So check it out, and come<br /> back for more.</p> <div class="feedflare"> <a href="http://feeds.feedburner.com/~ff/oreilly/radar/atom?a=MEhWg9IxEM0:CJoycHpVnzw:V_sGLiPBpWU"><img src="http://feeds.feedburner.com/~ff/oreilly/radar/atom?i=MEhWg9IxEM0:CJoycHpVnzw:V_sGLiPBpWU" border="0" /></a> <a href="http://feeds.feedburner.com/~ff/oreilly/radar/atom?a=MEhWg9IxEM0:CJoycHpVnzw:yIl2AUoC8zA"><img src="http://feeds.feedburner.com/~ff/oreilly/radar/atom?d=yIl2AUoC8zA" border="0" /></a> <a href="http://feeds.feedburner.com/~ff/oreilly/radar/atom?a=MEhWg9IxEM0:CJoycHpVnzw:JEwB19i1-c4"><img src="http://feeds.feedburner.com/~ff/oreilly/radar/atom?i=MEhWg9IxEM0:CJoycHpVnzw:JEwB19i1-c4" border="0" /></a> <a href="http://feeds.feedburner.com/~ff/oreilly/radar/atom?a=MEhWg9IxEM0:CJoycHpVnzw:7Q72WNTAKBA"><img src="http://feeds.feedburner.com/~ff/oreilly/radar/atom?d=7Q72WNTAKBA" border="0" /></a> <a href="http://feeds.feedburner.com/~ff/oreilly/radar/atom?a=MEhWg9IxEM0:CJoycHpVnzw:qj6IDK7rITs"><img src="http://feeds.feedburner.com/~ff/oreilly/radar/atom?d=qj6IDK7rITs" border="0" /></a> </div><img src="http://feeds.feedburner.com/~r/oreilly/radar/atom/~4/MEhWg9IxEM0" height="1" width="1" /></p></p></p></p></p></p>

March 05 2010

Report from HIMMS Health IT conference: building or bypassing infrastructure

Today the Healthcare Information and
Management Systems Society (HIMSS)
conference wrapped up. In
previous blogs, I laid out the href="http://radar.oreilly.com/2010/03/report-from-himms-health-it-co.html">
benefits of risk-taking in health care IT followed by my main
theme, href="http://radar.oreilly.com/2010/03/report-from-himms-health-it-co-1.html">
interoperability and openness. This blog will cover a few topics
about a third important issue, infrastructure.

Why did I decide this topic was worth a blog? When physicians install
electronic systems, they find that they need all kinds of underlying
support. Backups and high availability, which might have been
optional or haphazard before, now have to be professional. Your
patient doesn't want to hear, "You need an antibiotic right away, but
we'll order it tomorrow when our IT guy comes in to reboot the
system." Your accounts manager would be almost as upset if you told
her that billing will be delayed for the same reason.

Network bandwidth

An old sales pitch in the computer field (which I first heard at
Apollo Computer in the 1980s) goes, "The network is the computer." In
the coming age of EHRs, the network is the clinic. My family
practitioner (in an office of five practitioners) had to install a T1
line when they installed an EHR. In eastern Massachusetts, whose soil
probably holds more T1 lines than maple tree roots, that was no big
deal. It's considerably more problematic in an isolated rural area
where the bandwidth is more comparable to what I got in my hotel room
during the conference (particularly after 10:30 at night, when I'm
guessing a kid in a nearby room joined an MMPG). One provider from the
mid-West told me that the incumbent changes $800 per month for a T1.
Luckily, he found a cheaper alternative.

So the FCC is href="http://www.fcc.gov/cgb/rural/rhcp.html">involved in health care
now. Bandwidth is perhaps their main focus at the moment, and
they're explicitly tasked with making sure rural providers are able to
get high-speed connections. This is not a totally new concern; the
landmark 1994 Telecom Act included rural health care providers in its
universal service provisions. I heard one economist deride the
provision, asking what was special about rural health care providers
that they should get government funding. Fifteen years later, I think
rising health care costs and deteriorating lifestyles have answered
that question.

Wireless hubs

The last meter is just as important as the rest of your network, and
hospitals with modern, technology-soaked staff are depending
increasingly on mobile devices. I chatted with the staff of a small
wireless company called Aerohive that aims its products at hospitals.
Its key features are:

Totally cable-free hubs

Not only do Aerohive's hubs communicate with your wireless endpoints,
they communicate with other hubs and switches wirelessly. They just
make the hub-to-endpoint traffic and hub-to-hub traffic share the
bandwidth in the available 2.4 and 5 GHz ranges. This allows you to
put them just about anywhere you want and move them easily.

Dynamic airtime scheduling

The normal 802.11 protocols share the bandwidth on a packet-by-packet
basis, so a slow device can cause all the faster devices to go slower
even when there is empty airtime. I was told that an 802.11n device
can go slower than a 802.11b device if it's remote and its signal has
to go around barriers. Aerohive just checks how fast packets are
coming in and allocates bandwidth on that ratio, like time-division
multiplexing. If your device is ten times faster than someone else's
and the bandwidth is available, you can use ten times as much
bandwidth.

Dynamic rerouting

Aerohive hubs use mesh networking and an algorithm somewhat like
Spanning Tree Protocol to reconfigure the network when a hub is added
or removed. Furthermore, when you authenticate with one hub, its
neighbors store your access information so they can pick up your
traffic without taking time to re-authenticate. This makes roaming
easy and allows you to continue a conversation without a hitch if a
hub goes down.

Security checking at the endpoint

Each hub has a built-in firewall so that no unauthorized device can
attach to the network. This should be of interest in an open, public
environment like a hospital where you have no idea who's coming in.

High bandwidth

The top-of-the-line hub has two MIMO radios, each with three
directional antennae.

Go virtual, part 1

VMware has href="http://www.vmware.com/solutions/industry/healthcare/case-studies.html">customers
in health care, as in other industries. In addition, they've
incorporated virtualization into several products from medical
equipment and service vendors,

Radiology

Hospitals consider these critical devices. Virtualization here
supports high availability.

Services

A transcription service could require ten servers. Virtualization can
consolidate them onto one or two pieces of hardware.

Roaming desktops

Nurses often move from station to station. Desktop virtualization
allows them to pull up the windows just as they were left on the
previous workstation.

Go virtual, squared

If all this talk of bandwidth and servers brings pain to your head as
well as to the bottom line, consider heading into the cloud. At one
talk I attended today on cost analysis, a hospital administrator
reported that about 20% of their costs went to server hosting. They
saved a lot of money by rigorously eliminating unneeded backups, and a
lot on air conditioning by arranging their servers more efficiently.
Although she didn't discuss Software as a Service, those are a couple
examples of costs that could go down if functions were outsourced.

Lots of traditional vendors are providing their services over the Web
so you don't have to install anything, and several companies at the
conference are entirely Software as a Service. I mentioned href="http://www.practicefusion.com/">Practice Fusion in my
previous blog. At the conference, I asked them three key questions
pertinent to Software as a Service.

Security

This is the biggest question clients ask when using all kinds of cloud
services (although I think it's easier to solve than many other
architectural issues). Practice Fusion runs on HIPAA-compliant
Salesforce.com servers.

Data portability

If you don't like your service, can you get your data out? Practice
Fusion hasn't had any customers ask for their data yet, but upon
request they will produce a DVD containing your data in CSV files, or
in other common formats, overnight.

Extendibility

As I explained in my previous blog, clients increasingly expect a
service to be open to enhancements and third-party programs. Practice
Fusion has an API in beta, and plans to offer a sandbox on their site
for people to develop and play with extensions--which I consider
really cool. One of the API's features is to enforce a notice to the
clinician before transferring sensitive data.

The big selling point that first attracts providers to Practice Fusion
is that it's cost-free. They support the service through ads, which
users tell them are unobtrusive and useful. But you can also pay to
turn off ads. The service now has 30,000 users and is adding about 100
each day.

Another SaaS company I mentioned in my previous blog is href="http://www.covisint.com/">Covisint. Their service is
broader than Practice Fusion, covering not only patient records but
billing, prescription ordering, etc. Operating also as an HIE, they
speed up access to data on patients by indexing all the data on each
patient in the extended network. The actual data, for security and
storage reasons, stays with the provider. But once you ask about a
patient, the system can instantly tell you what sorts of data are
available and hook you up with the providers for each data set.

Finally, I talked to the managers of a nimble new company called href="http://carecloud.com/">CareCloud, which will start serving
customers in early April. CareCloud, too, offers a range of services
in patient health records, practice management, and and revenue cycle
management. It was built entirely on open source software--Ruby on
Rails and a PostgreSQL database--while using Flex to build their
snazzy interface, which can run in any browser (including the iPhone,
thanks to Adobe's upcoming translation to native code).upcoming
translation to native code). Their strategy is based on improving
physicians' productivity and the overall patient experience through a
social networking platform. The interface has endearing Web 2.0 style
touches such as a news feed, SMS and email confirmations, and
integration with Google Maps.

And with that reference to Google Maps (which, in my first blog, I
complained about mislocating the address 285 International Blvd NW for
the Georgia World Congress Center--thanks to the Google Local staff
for getting in touch with me right after a tweet) I'll end my coverage
of this year's HIMSS.

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