By guest author David C. Kibbe.
Background on health data exchange -- why paper and fax no longer suffice
As a means of getting information from point A to point B, the fax machine works pretty well. But there are three big problems with faxing health data and information. One, it's expensive, mostly due to the staff time spent running the machine, changing paper and ink cartridges, and handling paper jams, busy signals, and wrong numbers. Two, faxes contain unstructured text that at best is stored as a document electronically, but usually turns out as paper. Paper is expensive to store compared with digital documents, but the real problem here is that fax data are "non-computable." Data in a fax is almost always unstructured and therefore unavailable for storage as discrete data elements, e.g. name, address, HbA1c level, etc, in a database. In a database, discrete data can be acted upon by software, but in paper format the data just sits there. And third, faxes are not really secure, as anyone walking by an unattended fax during receive mode can attest.
Not a huge issue, perhaps, until we consider that in 2009-10 Congress and agencies of the federal government have created regulations that require physicians and hospitals participating in the ARRA/HITECH incentives awarded for "meaningful use" of EHR technology to
As it turns out, transporting health data electronically isn't so easy. Even for doctors/hospitals who use comprehensive EHRs in their practices. The major problem is meeting basic HIPAA security and the maintenance of patient privacy requirements. E-mail with attachments is a hands-down, no-brainer win over faxes in terms of moving data electronically from Doctor-or-Hospital A to Doctor-Hospital-or-Patient B, especially if those attachments are structured data, like the CCR standard xml files. But the way our email clients (Outlook,Entourage, Apple Mail) and online mail accounts with Google or Yahoo are configured, they're not secure enough for health data transport.
(Why not? Well, for one thing Internet Service Providers (ISPs) and normal email clients don't authenticate, that is, assure the identity of, the sender or receiver. So identity can be spoofed. "On the Internet, no one can tell you're a dog," as the quite famous cartoon has put it. For another thing, most email data attachments aren't encrypted during transport. Email protocols, of course, can perform enable email clients to perform these functions, and we'll return to this potential later in this piece.)
The first iteration of the National Health Information Network, or NHIN, was top down, proprietary, and complex -
Roughly six years ago, the Office of the National Coordinator for HIT, ONC, under David Brailer, came up with the idea of the "National Health Information Network" or NHIN to solve the privacy and secure transport problem. As a solution to moving health data from point-to-point, the NHIN was exactly what you might expect would be proposed by the large enterprises, hospital systems, and their legacy vendors who were called upon by ONC for suggestions. Accordingly, the NHIN was to be a network composed of connected Regional Health Information Networks, RHIOs, now called Health Information Exchanges, or HIEs. These large HIEs would create "bridge technology" so that they could communicate with each other. Two of the biggest health systems in the country, who for years had fought interoperability and data exchange, but by 2005 were committed to the NHIN, are the VA Health System and the Department of Defense. Accordingly, in 2005, ONC/HHS let out grants for 18.5 million dollars for the design of the NHIN, to the likes of Accenture and Northrup Grumman, the latter a big defense contractor.
Now, if you were a doctor in 2005 practicing in a four doctor group in suburban Toledo, Ohio -- or one of her patients -- word of this design for the NHIN and the multi-million dollar contracts never reached you. And if it had, you'd probably wonder about its relevance to you or your colleagues. In part, that was because the feds weren't thinking about you at all. To the NHIN planners of 2005-08, your practice was on the very dark "edge" of the network they were designing, while hospitals and integrated health systems, were at its "core." Connecting the "cores" with each other was at the heart of the NHIN design and the work which continues under its newer name, NHIN Connect .
NHIN and NHIN Connect is a vision for a multi-stage, evolutionary approach to health data connectivity, tightly controlled by large enterprises and HIEs. First come the HIEs, then the HIEs connect to one another, and finally connectivity trickles down to the "edge" providers and practices who have EHRs, as these are required or incentivized to join the nearest HIE. I want to emphasize that there is nothing inherently wrong with this construct. But it does centralize decision-making and power in the hands of an elite few.
Think of the way the Cable TV industry developed in this country, and you're getting close to the old NHIN and NHIN Connect. Most Cable TV operators were given exclusive, monopoly contracts to do business in a community or region, based upon the claimed large start-up costs for laying copper and fiber cable. Which meant that customers who wanted cable TV had to sign up with a monopoly, or go without. Similarly, for the original NHIN, the RHIOs and HIEs are being given monopoly rights to establish private health data exchange networks, one per region, and doctors, hospitals, labs, pharmacies, and others will have to sign up with them in order to be able to send and receive data for various purposes, including those requirements to become a Meaningful User of certified EHR technology under the ARRA/HITECH incentive program -- for making electronic referrals, sending alerts and reminders, and clinical summaries to patients.
Another useful analogy with which to compare the NHIN-as-connected-large-enterprises-and-HIEs is the situation that existed just before the Internet, when private networks like AOL and Prodigy were able to charge customers a monthly fee for basic services such as sending emails and viewing the Web through their own browser. The NHIN as originally planned is essentially a framework for the establishment of multiple, Prodigy-like private Internets, which would use the open source but still very complex NHIN Connect Gateway software to move health data between private networks, in many cases for a fee.
Now, you don't need to be the least bit technically savvy to raise some good, solid questions about this arrangement. For example
Why would we go through the expense and hassle to build and then limit our NHIN experience to monopolistic, Prodigy-like, private health data networks around the country for simple data transport, when the Internet itself is available? Banks, airlines, and e-commerce of all kinds run on secure Internet systems, so why can't health care? HIEs and RHIOs may offer some of their clients much value beyond simple, secure, health data transport, which is fine. But not all of us will need Mac trucks to drive to work. Or:
Isn't this version of the NHIN going to be really, really slow to develop? Physicians and medical practices need to connect their health data by 2011 in order to qualify for Meaningful Use, but the original NHIN design sounds as though it might well take another decade to pull off. Or
What about the doctors, practices, and patients who don't have an HIE in their vicinity? How will they get connected? HIEs are primarily urban and suburban, and formed around large hospitals or consortia of hospital systems. What are the docs going to do in rural and underserved areas? Or, what about thisHow can health IT innovation occur rapidly when health data and their transport are controlled by a relatively few private networks, and a few very large IT vendors?
NHIN Direct explained and illustrated
It is in large part as a way of answering these questions that the NHIN Direct Project has been initiated by ONC and HHS. The aims of the NHIN Direct Project are "to expand the standards and service definitions that, within a policy framework, constitute the NHIN. Those standards and services will allow organizations to deliver simple, direct, secure and scalable transport of health information over the Internet between known participants in support of Stage 1 meaningful use." Implicit in this objective is the inclusion of small and rural medical practices located at the "edge" for full participation in health data exchange within the scope of the expanded NHIN.
Stated even more simply, NHIN Direct is a specification for the use of a set of existing Internet standards and protocols to allow any individual, organization, or organizational health IT system with an NHIN Direct Address to send health data to any other individual, organization, or organizational health IT system with an NHIN Direct Address, and to do so without having to be part of an HIE or other private network. In practice it is likely that most HIEs and private networks will adopt the NHIN Direct protocols, and thus enable their member individuals and organizations to have NHIN Direct Addresses, and therefore be capable of participation in the direct routing of health data. An NHIN Direct Address is very much like an email address or a web address, the difference being that NHIN Direct Addresses are verifiable, "unspoofable," and stored in a directory for updating.
It is important to recognize that NHIN Direct is NOT a means of sending health data "out into the Internet" to unknown individuals, or to anyone with an email address. To avoid "spoofing," NHIN Direct will require that the sender of health data "knows" the identity of the receiver, and that the exchange between Dr. Kibbe and Dr. Smith using NHIN Direct methods will occur ONLY when there is a trusted method of assuring the identity of each.
How is this trust established? NHIN Direct envisions a new kind of Internet Service Provider, or ISP, to be called a Health Internet Service Provider, or HISP. To be connected to the Internet as a citizen or individual requires the use of an ISP, which may be Time Warner Cable, the local telephone company, or one's place of business or employer. In each case, one's ISP is the "first connection" that allows all of the other Internet and Web features to be available, e.g. email, web browsers, e-commerce, online video, etc.
The duties of a HISP are like those of an ISP, but include specific additional services that will permit providers to simply and securely exchange data using NHIN Direct channels. These includeAssignment and listing of organizational and individual NHIN Direct Addresses. HISPs will not need to create completely new email or URI addresses for individuals or organizations. Dr. Kibbe can still maintain his email address as Kibbe@FamilyMedicineUSA.org. What the HISP must do is verify that Dr. Kibbe is in fact a physician licensed in the state of North Carolina, and that this address is accurate and correct. The HISP would be responsible for publishing this address to other qualified HISPs looking to pass along health data addressed to Dr. Kibbe, and to maintain and update this address periodically.
Authentication of senders and receivers at the time of transport. There are a number of ways that client applications such as email or a web browser can create a trust relationship with a server to which data is being sent on the Internet, and similarly, several ways in which HISP servers passing on the data to one another can verify and trust one another. Often, digital signatures or certificates are exchanged at the same time that data are encrypted, and these methods both establish trust and disable "sniffing" of the data in transit by nefarious or criminal parties. Within the NHIN Direct specifications, it will be up to each HISP to set a minimal authentication protocol for client applications using the HISP, and each HISP will need to decide whether or not to trust other HISPs, based on their choices of minimal identity management protocols, which each HISP will be required to publish.
Content packaging of sender's message to assure that receiver can consume and interpret it. For handoffs of health data to be efficient, simple packaging standards need to be employed that both senders and receivers, or their EHR technologies, can understand. The messages that can be sent over NHIN Direct will be limited to a very familiar Internet messaging standard known as multipart-MIME, in which various kinds of attached data formats will be permitted, including the CCR standard, CDA CCD, HL7 flat file, and PDF for unstructured data.
In the drawing below, the physician on the left is identified as the "Source to HISP." He or she is sending a message to the physician at the bottom on the right, identified as "HISP to Destination." The individuals or organizations who are senders and receivers may use a number of "edge protocols," e.g. email clients, to send their messages to the HISP with whom they are associated. The HISPs then use a "backbone protocol" to communicate with each other, until the Destination physician or organization is located, at which point the HISP associated with the receiving physician or organization uses another (may be one of several) "edge protocols" to deliver the message.
This model is essentially the same model, and employs many of the same protocols for message transport, as the Internet itself. Only in the case of NHIN Direct there are additional layers of both technology and policy to establish and enforce a framework of trust and security, to assure privacy and confidentiality.
Final comments on the importance of NHIN Direct
The advantages to small and medium size medical practices of a national system that looks like NHIN Direct are substantial. Medical practices will be able to participate in health data exchange without the requirement to join a formal HIE or RHIO, although they will have the option to do so whenever one is established in their areas and if they provide additional value beyond simple, secure transport. Meaningful Use criteria for data exchange to support care coordination, patient engagement, and submission of quality data will be easier to meet, and at lower cost. In fact, the costs to be part of the NHIN Direct will be initially very minimal, and scale upward only as services beyond simple transport are added and subscribed to.
Beyond these tactical and practical issues, there is an essential tension between the older version of the NHIN and the NHIN Direct. If you believe that health care is fundamentally the business of large provider organizations and their large IT corporate vendors, then you're probably comfortable with the NHIN Connect's system of RHIOs and HIEs controlling health data and its flows. Large enterprises like the VA Health System may find they need the added complexity. But if you believe that medicine and most of health care is still primarily a set of service professions, where relationships between providers and patients count, and that individuals should be given the right to control most, if not all, of their health data, the NHIN Direct will seem preferable, or at least worth a try. A similar "decision" was made for the Internet and World Wide Web at large back in the 1990s, when private networks like AOL and Prodigy fell to the wayside in favor of the more open, simpler to use, and more democratic protocols which have created "net neutrality."
Over the next weeks and months we'll see the extent to which these two visions of health data for a National Health Information Network are successful. With any luck, they'll peacefully co-exist side by side.