NHIN Direct: Getting to the Health Internet, Finally!

I’ve been spending a lot of time involved in several Work Groups of the NHIN Direct Project, being run by ONC/HHS. The Project is aimed at developing secure, affordable, health data exchange over the Internet so more physicians can participate in Meaningful Use. This project has major significance to physicians in primary care, to all doctors in small and medium size medical practices, and for many small hospitals, as it is a potential “game changer” with implications for both the EHR technology industry and quality improvement movement. Here’s some background and explanation about why and how.

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:

  • send data to each other for referral and care coordination purposes;
  • send their patients alerts and reminders for preventive care;
  • offer patients views of their clinical data, such as laboratory results;
  • make clinical summaries available to patients after each visit, and: send quality measurement data to CMS.

Given this new situation, which will dramatically increase the flow of data out of medical practices and hospitals, the really pertinent question is this: “If we can’t use fax machines to deliver these messages, what can we use?”

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 this:

How 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 include:

Assignment 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.

Spread the love

Categories: Uncategorized

38 replies »

  1. Good day very nice web site!! Guy .. Excellent .. Amazing .. I’ll bookmark your website and take the feeds additionally?I’m happy to find a lot of helpful information here within the put up, we want develop more strategies on this regard, thank you for sharing. . . . . .

  2. NHIN Direct is a good replacement for the fax machine to hopefully exchange structured data that can be incorporated into an EMR. It is only a defined transport and package content. It does not replace the need for a better NHIN. An better NHIN is one that does not rely on any manual coordination between entities that are known to each other. NHIN Direct relies on one entity to send information to the other. That means the first entity had to request it. This is why it is nothing more than a better fax machine. It does not create an enironment when all information can be pulled about the patient even if you don’t know who to get it from. That can be necessary in emergencies and with patients with limited ability to communicate. We need a system where the data can be pulled, not just one where we need to know who has it, get them on the phone, and ask them to send it as an email over NHIN Direct. Providers don’t always have that time nor can they get the complete picture of who has inforation on the patient without a more complete NHIN based on RHIOs, HIEs, etc. NHIN Direct has its place in history to fill voids where there is no mature or maturing RHIO/HIE. In areas where there is a mature or maturing HIE, it pulls away from the information available by circumventing the exchange.

  3. My partner and I head two hospitalists groups in the Boston area, one acute care, the other a rehab hospital. For years our handoff communications went through paper mail or fax. We were very diligent about communication. Even so, specialist from acute care settings and primary care physicians in the community complained that our group was like a black box – that they were not getting good communication about the care we were providing. The hospital even setup a physician portal so that any on-staff doctor could log in remotely and access their patient’s information. But this “pull” model never caught on, as most doctors expect data to be “pushed” out to them.
    One of our new physicians suggested we look at Concentrica, which is an online network for secure clinical communication. This is free to physicians to communicate with each other. The national directory of physicians meant that we could quickly send to any physician, without having to know their fax or email. Like an online email system, recipients can reply and forward messages, so now we could get immediate feedback from colleagues in other locations, and in important cases, have a real dialog about patient care. The “Group Discussions” feature allows the specialist in town, the hospitalist, and the PCP to all join in an online dialog about one patient. The application works well on our smartphones.
    When our group wanted to send documents on our behalf, we upgraded to the subscription version, which cost less than paying someone in our office to fax the documents. There is an audit trail so we can see who received their messages. One feature we really liked was that if the message was not accessed online it was faxed, so we knew our clinical work was getting there.
    For our group it made it easy to communicate with other physicians, to get our documents out, gave a way for others to respond, and was cost effective.
    Arthur Williams, MD

  4. Hi Bev —
    What we have tended to do is ball many concepts into one word: insurance. Nate’s trying to fight that, and is strenuously resisted. He is not wrong to do it though.
    I’m a bit of a George Orwell fan — muddled language leads to muddled thinking. And vice-versa. This is often used purposefully, see here:
    This is why Nate is right to attack the politics of the word “insurance”. If we want insurance let us have insurance. If we want something else let us not call it insurance. If we want insurance and something else, then let insurance be insurance, and the something else be something else. I have said as much here on THCB more than once, but I don’t cause the same level of apoplexy Nate does because I approve Orwell’s fine advice more than I follow it.
    Nate’s admitted before that some regulations are necessary:
    If there is going to be more than one payor (I’d personally prefer a number on the order of 50 but that’s another discussion) the ACH idea is a good one.

  5. I wanted to comment on a company that sells health insurance plans in Nevada. They have a system which compares all the health insurance plans in Nevada side by side and gives all the details about each plan.
    It seems when I read more about them they are going to be adding a system which compares the cost of each service and give reviews of doctors and hospitals. I think they are ahead of the bell. I bought my plan online with them YES, I bought it online. Saved my family about 2500 per year. Though my plan is top notch costs 8600 per year but by group plan was 13,890.
    The company is http://www.nevadahealth.com if you want to save some money and your healthy you should look at them that is if you live in Nevada…:)

  6. “…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…”
    Yep. See
    Scroll down. Nice to know I’m not completely crazy, though I would expect Latanya Sweeney and Deborah Peel to have aneurisms over the very idea.

  7. Tom;
    I had the same reaction, LOL! That’s ok; Nate has become a legitimate player, I don’t entirely disagree with some of his (more mild) views . Now we have Karl and maobama or whatever it is…..

  8. > This is one time were the government should
    > take a bigger role.
    Nate? Is that really you, or some dog spoofing you? 😉

  9. Mike: Not true! I think you’re missing the opportunity for patients/individuals to participate in the exchange of health data and information that accompanies NHIN Direct, and, in my opinion, is really not part of the picture in the older NHIN structure. Several of the user stories that NHIN Direct is explicitly designed to enable involve pushing of health data from provider and/or provider organization to the patient/individual. These include:
    * Provider sends patient health information to the patient
    • Hospital sends patient health information to the patient
    • Provider sends a clinical summary of an office visit to the patient
    • Hospital sends a clinical summary at discharge to the patient
    • Provider sends a reminder for preventive or follow-up care to the
    Kind regards, dCK

  10. No, propensity, the Rube Goldberg part is the REST of the NHIN “process”.
    This is incredibly simple, e.g. “simple interoperability”.

  11. David–
    This all sounds excellent–and doable.
    I’m so glad that you are involved in this. It seems to me very important that people like you—rather than Health IT vendors–are leading the Health IT revolution.
    Helth IT is essential to reforming the system, but it must be affordable.

  12. Useful explication, but your interpretation concerning consumers is difficult to understand.
    You say “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.”
    It is hard to understand how NHIN direct makes any contribution to individuals control of their own health data. Certainly it has the potential to help individual physicians, but individual consumers won’t have NHIN direct addresses or addressability. There is simply no obvious path from NHIN direct to consumer access that I can see.
    (In fact, insofar as it limits EHR adoption by enabling physicians to avoid EMR investments in favor of simpler technologies, and thus postpone associated patient portal availability, it could slow the progress of patient access to health information…)
    Do you wish to elaborate?

  13. This is absolutely awesome, and majorly encouraging to those of us who work hard to bring about a widespread, standardized, interoperable HIT infrastructure so necessary for healthcare delivery to catch up with care standards. I appreciate Dr. Kibbe for acknowledging the importance and legitimate role of the RHIOs/ HIEs in parallel with the NHIN-d construct, since the decentralized healthcare environment in the US means both approaches will proceed simultaneously. The trick will be how the ONC will effectively steer this two-tiered process, further complicated by state and regional efforts / authorities, all having to go forward without a firm idea of what the final endgame rules of exchange will be. As with the Internet itself, there remains a key role for the AOLs and Prodigy-s of this space – even in medical Internet, we have Epocrates, UpToDate, E-medicine…all the details and practice standards of both modular EHR and NHIN-d will take years to develop, especially when less than half of providers are EHR-based at present. Hopefully centers of excellence will light the way to streamline the development. But for the present, I am glad there are some AOL-type approaches to help move things along. Because such comprehensive resources exist, I look forward to having my new secure health Internet identity very soon – AND be able to use it effectively. Indeed, would we have the ubiquitous Internet of today had there not been AOL and Prodigy? These formed an essential intermediate step – and still derive some residual value.

  14. “and who exactly is going to pay for the doctors to implement and maintain this?”
    The doctors would be the logical choice but they will most likly cry about the added cost and get tax payor money. When I was forced to upgrade my software to accept EDI I didn’t get a penny from anyone, not even a requirement that doctors actually use what I was forced to buy.
    This is one time were the government should take a bigger role. Model it after the Fed and the ACH/banking system. This is even more relavent as sending money is the next step. THey couldn’t possibly charge more then what WebMD and other clearing houses are already robing people for.
    Running all claims and payment transactions through the health fed would solve two other problems. Data for public health as they could scrub and retain data on all care being rendered and finally and most dear to my heart eliminate damn 1099 requirement. If all payments ran throught the health fed the IRS would have all the data they need and could stop fining me for doctors not knowing how to bill.

  15. Ed: Thanks for the heads up on the broken link. Will let the people at THCB know. The NHIN Direct Project is developing specifications and policy, that can be used by many different organizations and technology companies, and their customers, to make the NHIN Direct a functional system for sending secure health data messages using the Internet. It’s a lot like the way the Internet works now, with organizations like W3C and others developing standards, protocols, and policies that make email, websites, and many features of our Web experience actual. For example, there are trusted digital certificates that come installed in your browser, without your knowing it. They’re used, for example, when you go to Amazon.com to verify that you’re actually at the real Amazon.com, and not someone claiming to be. The browsers and many of these companies, like Amazon.com, are making good security and trust decisions for you, which obviate a lot of work on your part. NHIN Direct will be a set of specifications, that will establish the same kind of trust, most of which will occur in the background, when you use your email or a particular web service, to push health data to a physician or a patient with an NHIN Direct Address. It will be very real, but not necessarily something you pay much attention to after the initial establishment and verification of your NHIN Direct Address. DCK

  16. FYI the link to NHIN DIrect is broken. I did find the sit at http://nhindirect.org/
    On reading there it is not clear whether the plan is to develop a funcitonal site, or just develop guidelines for a site. I hope it is to have a real live functional program.

  17. That’s what I meant by automated, David. I guess the difference between what I was describing and the NHIN Direct is who maintains the credentials and address book. I assume that the NHIN-D presumes that there is some sort of application on both sides of the communication line. If those applications maintain addressing and credentials then we really don’t need a new kind of ISP.
    I think I need to read more about NHIN-D. In any case, I like it much better that the original NHIN.

  18. I am sorry, I admit that I am unable to read the whole piece in detail … are we talking about info exchange PER EXPLICIT REQUEST? For ideal flow of info, a provider should have immediate access to all available information for a patient he/she is treating, without requests or waiting, thus having data access while the patient is still in front of him/her. There are way too many patients who had care out of town or out of state, but they do not remember institution and/or provider and/or time and/or nature of services.
    Initiate a central system like in the VA, that would work best. Health data is exchanged every day via the internet, protected by citrix servers. You just need a central MR. Everyone who does not want it can opt out, but also sharing the risk for poorly coordinated care and/or the cost of duplicate exams.

  19. Thanks, all, for your comments. Let me address them one by one.
    To Jeff: you’ve hit it right on target, it’s all about communications. Will NHIN Direct “get it done” ? My sense is that we’re very near a tipping point at which most health care organizations and health IT/information companies will want to be involved, in order not to lose out on the benefits of NHIN Direct in terms of those communications opportunities you cite, rather than fight against it or stay on the sidelines. Sitting on the sidelines is dangerous when changes of this magnitude are happening, and in this case, the pieces are fitting into place very quickly.
    To angela: my guess is that NHIN Direct will turn out to be the lowest possible cost opportunity for most physicians to engage in health data exchanges. This is really an important point, so sorry I didn’t make that clear enough.
    To Margalit: you almost answered your own question about the current methods of secure email, but not quite, so let me provide a little more detail. Right now, if I use a secure messaging website to send Doctor B some information, she gets a regular email telling her she has go to the website, then she has to log in with ID and password, to retrieve my message. Suppose she doesn’t have time to respond right then, and goes to do some other task. Very likely, she will have to log back on to that website, compose her message, and then the process is repeated with me as the receiver, getting an email that there is a secure message, and so on…
    This scenario is a big work flow headache as far as most busy professional are concerned. Much, much better to be a participant in and NHIN Direct Addressee, which means that my end-user application is part of a Trust Network and I, as an individual, am a trusted identity on that network, so that the work flow overhead in sending health data to another trusted individual’s end-user app is comparatively very small, even tiny . Compose the message, attach the attachment, and it’s done!
    I don’t want to trivialize the design work that needs to go into NHIN Direct to make it work smoothly (which it won’t at first for all participants, we can be sure). But the components of the NHIN Direct Trust Network are all available for use.
    Dave Kirby brings up some excellent ideas and issues, many of which are being discussed within the NHIN Direct Project. It’s very important to map the Stage 1 and Stage 2 provider communications/patient engagement obligations against any system that could be affordable, simple, secure, and implementable on a wide scale, and look for possible problems or contradictions.
    thanks again, DCK

  20. Over the next 2-3 years as many providers seek the incentives and benefits of participation in the Meaningful Use of EHR program I expect the focus in moving health information to turn to doing whatever meets MU standards, is practical to do, and can be done in a timely way. These factors seem to me to favor NHIN Direct as part of the near term solution set, though some additions would help in my opinion. I think that I can explain this best by describing my review of the MU NPRM requirements. I see four categories of extra-mural data sharing required of MUsers in Stage 1:
    1)To/from indirect providers (e.g. labs, e-RX)- The systems for these types of exchanges have pretty well established mechanisms now and don’t seem to me to be likely to be replaced by any new system. I would be surprised to see NHIN Direct to take on these functions.
    2) To public health: Case reporting in Stage 1 under the NPRM would only be required if the relevant public health agencies can receive such messages. Not many public health agencies seem to be in a position to support receiving systems. While there was a recently announced program to support the building of such receiving systems for a few states, I’m not optimistic that these systems will be available as recipients of case reports to very many EPs or hospitals during Stage 1. So, while I think that this is a clear area where more information flow would have benefits, I don’t expect much activity in this area in Stage 1. Perhaps NHIN Direct could be positioned to enlarge its functions after Stage 1 to do this.
    3) To/from Direct Providers: There appears to me to be the only Stage1 objective that requires direct provider-to-provider communication (” Capability to exchange key clinical information (for example, problem list, medication list, allergies, diagnostic test results), among providers of care and patient authorized entities electronically”). At first this sounds like a fulsome requirement that NHIN Direct might address, but the measure of success is only that the MUser have “performed at least one test” of the EHR capacity to do this. MUsers seeking the least burdensome way to meet this measure might do with techniques even simpler than NHIN Direct (e.g. exchanging email Winzip or Acrobat encoded attachments with a few close colleagues who account for a large percentage of their common patients). While I would hope that something more scalable would be used, it seems to me to “fit” with the small providers view to use something very simple and close to home like the Winzip/Acrobat approach. So, it is not clear to me that NHIN Direct can be competitive on this point in the eyes of the typical EP – though these providers might be better positioned for Stage 2 or 3 (or 4?) if they used NHIN Direct.
    4) To the patient: There are several MU Stage 1 objectives that require timely electronic delivery of PHI to patients at some defined level of penetration (e.g. “At least 10% of all unique patients seen by the EP are provided timely electronic access to their health information”) Additionally, the HITECH section 13405(e) requires HIPAA-covered EHR users (whether they are MU program participants or not) to support the fulfillment of a new right: “(1) the individual shall have a right to obtain from such covered entity a copy of such information in an electronic format and, if the individual chooses, to direct the covered entity to transmit such copy directly to an entity or person designated by the individual, provided that any such choice is clear, conspicuous, and specific;” We have not seen the regulations to go with this part of the law (I’m told that OCR is working on this). But, it is hard to imagine a set of regulations that significantly reduces the apparent level of requirement in the law; we’ll see. NHIN Direct could support this if it adds a focus on moving information to patients. For now, there does not seem to be a requirement for MUsers to receive e-data from patients. But, such a requirement would support broad public policy goals to improve health and care (e.g. in ways expressed in RWJ’s HealthDesign Project). Perhaps NHIN Direct could at least prepare for this outcome.

  21. David, I am glad you are working on NHIN Direct because if you are involved, chances are it may make some sense after all. Besides, now I can ask questions… 🙂
    We have means and software products and services today that allow folks to send secure email. The method I like best is the one that sends a plain email to the recipient notifying them that there is a message for them to pick up at a secure (SSL) location (URL).
    In the very short run, why not use something like that? In order to qualify for meaningful use, EHR technology will have to be able to accept CCR/CCD. It is only a small step to automate sending of email notification to the intended other party, be it another provider or even a patient.
    Again, for MU, a provider will need to have some sort of Internet presence for patients. It would be simple to provide the same type of Internet presence for another provider to consume.
    The only difference would be that an initial exchange of credentials needs to occur between providers, or between providers and their patients. After that the entire thing can be automated, including sending/receiving notifications. There is no need for a HISP in this scenario, but I suspect that even with a HISP, there will be at least one step requiring user intervention.
    Actually, if I’m not mistaken, this sort of exchange of documents between providers is already occurring, particularly for referrals.
    So what are the NHIN Direct and HISP advantages? Is it the standardization? Sort of like everybody using the same email client…

  22. It’s about time. As a small practice we have had a secure messaging system to allow us to communicate with patients, but still cannot communicate with other health care providers. Fax is far from secure, wrong numbers happen, etc. This is exciting, though how fast it is accomplished remains to be seen.

  23. If it can be pulled off, NHIN Direct provides an immediately usable and tangible improvement over current technology that helps solve the immediate functional requirements of meaningful use. We will be working for decades to create record-to-record integration. The most transformational aspect of the Internet, in health or any other sector of our economy, is that it is a COMMUNICATIONS medium, something that seems to have been lost in the forest of enterprise HIT, which has become terminally mired in documentation and transactions processing.
    NHIN Direct is a secure communications framework to enable providers to talk to each other and to patients. Get it done!

Leave a Reply

Your email address will not be published. Required fields are marked *