Yesterday and today I spent once again at the 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 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 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 3M, offer products that capture clinicians' notes, which can be a job in itself, particularly through speech recognition. 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 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, 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 n² different transformations.

Reasons for these blocks to 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 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 OpenMRS, the Veterans Administration's VistA, and the 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 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 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 Axial Exchange, which creates open source libraries and tools to work with the system, and the 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, 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. One participant, 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. I was told 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 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 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 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.