Looking for Interoperability in All the Wrong Places

Looking for Interoperability in All the Wrong Places

4
SHARE

To achieve interoperability, simply reduce the cost of interfaces. The economic value will follow.

Vendors, hospitals, patients and the states are all the wrong places to look for interoperability. Vendors prefer to lock-in their customers, differentiate their product and derive revenue from interfaces. Hospitals prefer to lock in their patients, differentiate their service and derive revenue from pricing power in the marketplace that results from consolidation. Patients confused by the technical nature of interoperability are easily misled into erecting privacy barriers that obscure quality and cost transparency. Finally, the states spend federal money designed to seed interoperability following established bureaucratic and political paths dominated by unchallenged input from vendors, hospitals and misinformed patients.

The cost of interfaces is the sum of Identity, Consent, Transport, Software and Opportunity. Reducing the cost of all five to near zero is possible and relatively easy. The Web and DICOM interfaces to radiology systems demonstrate many of the details at a large scale and for over a decade.

Identity can be free and easy if it’s voluntary to the person or system being identified. On the Web, identity is an email address. Email is free and available to all, even if they have to go to the library to use it. Email IDs are voluntary, you can use one or another as you choose without prejudice or permission. For a system example, DICOM interface IDs are IP (Internet Protocol) Addresses. They too are free and voluntary. The Direct Project is healthcare’s version of a free and voluntary ID for people and for systems. For both patient and clinicians, Direct Project identity is based on email addresses. Patients can already get a free Direct email ID from Microsoft HealthVault. Doctors can get one from Surescripts/AAFP for $15/month and free options are sure to follow. Free, voluntary identity eliminates one of the major costs of health information exchange: the Master Patient Index (MPI). MPI is one of those technologies that costs more the larger it gets. It’s time we abandon MPI as a path to interoperability.

Consent can be free and easy when the patient makes the connection directly. On the Web, consent is typically handled by the OAuth protocol. It allows you as a subscriber to the New York Times to grant The Times limited access to your list of friends on Facebook. In healthcare, DICOM interface consent is handled by an administrator entering the same application name into two or more systems. Neither OAuth nor the DICOM consent systems involve the software vendor and there is no interface charge. OAuth has already been recognized by both the Markle Foundation and the ONC HIT Standards Committee Power Team. It eliminates the paper and much of the cost of managing consent in a proven and scalable way.

Transport is an obvious requirement for interoperability. Internet transport is the foundation for the Web, DICOM, the Direct Project and the Markle Blue Button Download Capability. Internet transport is basically free because it’s hard to put up pay walls. By comparison, transport that requires Health Information Exchanges is costly and probably unsustainable. HIEs can have a role in interoperability but assuming them as a transport layer raises the cost of Identity, Consent, Software and Opportunity. As HIEs struggle to find a sustainable business model, transport paywalls are a shaky foundation to build upon.

Software can (and some say should) be Free. This is particularly important for interfaces. Free software is at the core of both Web and DICOM. Free email and Direct Project software is readily available and in clinical use. Unfortunately, additional software for healthcare interoperability is hamstrung by a tradition of standards such as HL7 that pose a barrier to small open source software developers. Interoperability will require free and open standards compatible with free and open source software. In healthcare, open source software could also be a matter of ethics.

The fifth major factor driving interoperability is the Opportunity cost of interfaces. This is the cost of increased competition seen by hospitals and lost revenue streams seen by vendors. This cost seems large in the short term. In the long run, increased competition and interoperability are essential to our health and to the health of our economy.

The right place to look for interoperability is on the Web with patients and individual doctors in control using open source interfaces. Let’s all urge the current cast of stakeholders, the vendors, hospitals and public servants, to look beyond the paywall and move on for the health of us all.

Adrian Gropper, MD is a founder of MedCommons and consulting on health services strategy at HealthURL.com. He is driven by the vision of doctors and patients collaborating around shared health records on the Web.

Leave a Reply

4 Comments on "Looking for Interoperability in All the Wrong Places"


Guest
Feb 29, 2012

Please visit the website for more details

Guest

More 30 years after we started to use Microcomputers in medicine there is still only one large group of people in Britain who have a fully inter-operative medical record! ( JRSM Oct 2011 for a full review)

However every person in the whole of the K.K. in this group has a totally inter operative medical record whereby any health care worker anywhere worldwide can access all the medical history and all the laboratory and imaging results and all the information about any recent hospital admission.

This magical breakthrough in IT technology started in the 80s here in Milton Keynes and is now the norm for very patient in this group in the whole country. What is this major breakthrough?

It is called the Pregnancy Health Record which is possessed by every expectant mother in our country.This hand held record is now the master copy with all electronic records being secondary being based on photographs of the paper master copy of the record It does not matter that the West Midlands pregnancy Notes are differently designed from the Scottish Pregnancy Record or the Welsh PHR

Guest
Arno
Nov 8, 2011

This is an interesting post, in particular I find the part on HL7 true and others have already started attempts to simplify this problem see http://www.healthintersections.com.au/rfh/introduction.htm.

The part I disagree, as a developer, is that using Open Source will reduce your cost as there is no licensing. If it were true projects like OSCAR would be dominating our industry — but the reality is these projects have a lot of configuration and you still bring in the experts for support and training (the only advantage it gives you a little amount of flexibility on choosing who you are going to call as multiple experts can support the same open source product).

To really bring down software costs the real element to address this configuration which for hospitals can take weeks if not months (as each hospital tends to have their own software eco-system).

Interoperability only addresses only one piece of the configuration puzzle. Alone as seen in other industries it is not sufficient — few middleware companies exist today. Configuration also includes customization, localization, authorizations and testing which take more time than interoperability.

The wining vendors will be the ones that provide solutions that facilitate all aspects of configuration. Making system deployments come down from weeks and months to days will be a real winner. And when you winners they become the standards.

Guest
Rafael Richards
May 25, 2012

Agreed completely. We must move forward and away from both antiquated and proprietary systems and standards, and into both open source and web-centric technology for our healthcare information infrastructure.

Open, modern web standards:
HL7 is one of the biggest barriers to moving forward with healthcare interoperability. HL7 is over 35 years old, which predates the internet and any of our networking, transport (TCP/IP, etc.) or security protocols (SSL) It lacks any intrinsic capability to provide semantic interoperability. HL7 is simply a one-way instant message protocol that blindly broadcasts data over a port. It is like a radio station that you can tune into and listen. If you don’t happen to understand the language spoken, you are out of luck.
Yes, a ridiculously complex reference information model has been tacked on to HL7 (as a result not one hospital in the U.S. that has adopted this). But this does not change the fact that at its core, it is far too simplistic for today’s healthcare data needs. It is also proprietary, which means you can’t freely move data around the internet without paying a license fee to the consortium.

Contrast this to the modern web standard for data, which is the RDF standard. This data standard is a W3C (world wide web consortium) standard for a global securely accessible semantic web of data that is machine processible. It is called the Semantic Web, or Web 3.0. Google Tim Berners-Lee and his TED talk on Linked Data and learn about this. The US Goverment is now publishing all its OpenGov databases in this form, and liberating all this goverment for anyone to query. In the long run, this is the only way we can create a web of healthcare data that is securely exchanged throughout the US – no cost, no license, no vendor, no HIE, no central database: just point to point secure semantic exchange of data directly from one physician’s office to another.

Open-source:
One has only to see the success of Apache (#1 web applicaiton server), Linux (#1 operating system driving the internet) and the W3C (world wide web consortium) that develops the open standards of the internet that this enables ubiquitous access to data.

However, open-source is not about technology. It is about TRUST and COMMUNITY. The licensing enables a community to trust and grow.

Licensing is only a tiny fraction of the cost of software, and is not the differentiating factor between proprietary and open-source. Where software companies make thier money is in support and maintenance. In fact, over 80% of the TCO of any enterprise software is in the support and maintenance; only 20% is the initial cost and license.

Currently the EHR marketplace is skewed by large subsidies paid by the government of the US and Canda to encourage adoption of EHRs. What happens when these subsidies go away in a few years? The $27B on offer in the US expires in 2014. This is what many are calling the “HIT Bubble”. Then the real cost of EHRs will be apparent, and hospitals and medical practice groups will be stuck with very expensive proprietary systems that they are locked into and unable to change without paying extortionate consultancy fees to their vendor to maintain.

The alternative is open source, where all the hospitals using a given EHR are actually *sharing* all their code, developments, and enhancements with the community and each other, reducing the total cost for everyone involved, and reducing duplication of development efforts at each institution.

Right now, with the subsidies in place, the vendors are matching the cost of their software with the subsidy.

In Ontario, Canada (where OSCAR started), the cost of the leading primary care EHR is $700/month/physician. When the subsidies went down to $400/month/physician last year, suddenly the EHR cost went to $400/month. In orther words, 100% of the subsidy went to the vendor. So who is this EHR incentive intended for? The physicans adopting the system? Or the vendors?

As testimony to how well-liked OSCAR is in Canada, it has grown in adoption in by over 700% in the past two years, and now is the #3 most adopted certified EHR in Ontario, with twice as many physician users outside of Ontario where it was initially intented and certified for use. This is in spite of the fact that all of OSCAR’s competitors are far more expensive.

The OSCAR user base has increased from a very small one at McMaster University five years ago to now 25% of all primary care physicians offices in Ontario. Now just wait for the subsidies to go away, and this exponential growth in OSCAR use will very soon put it at the #1 spot in Canada.

Out of curiosity I downloaded and installed OSCAR to give it a spin. It used to be quite complicated to set up the web server and all its dependencies, and required a programmer to do this. The OSCAR team has listened to their community and made the installation and configuration completely automated. It took me only 15 minutes to download, install, and configure a fully functional OSCAR system. So much for the comment that OSCAR requires configuration.