Give me a basic overview of NHIN Direct.
NHIN Direct is a project to expand the set of services that are available on the NHIN, but to expand them in a way that is accessible to the majority of providers. Particularly, the majority of the primary care providers practice in practice sizes of five or fewer. The lingua, the interchange, the health information exchange/interchange for those providers currently is fax. The major aims of this project are to create a set of standards that enable those providers to essentially replace the fax with electronic forms of interchange.
There’s really nothing new in the kind of health information exchange that we’re trying to do. We’re not trying to break new ground so much as standardize existing ground. A lot of HIOs get their start in provider-to-provider or lab-to-provider direct communication. Essentially, what we’re trying to do is standardize that and make it easier to plug in EHRs into exchanges and make it easier for HIOs to develop standard services for that kind of direct communication.
I’d also note that level of direct communication aligns very well with the criteria for Meaningful Use; particularly the requirements to exchange information at transitions in care, as well as receive lab data electronically and provide electronic information to the patients.
How would you characterize the differences between NHIN and NHIN Direct in terms of who will use them and for what purpose?
I’m going to carefully separate NHIN, as in the NHIN Exchange, from NHIN, as in the set of standards and services that are available. There’s some confusion about what’s what.
Both define the NHIN Exchange as the network of networks, as the network in the middle with standards that enables large, national health information organizations to exchange data with each other. A great example of where the NHIN Exchange would be useful is in coordination of care between a provider who’s using a state HIO and a patient treated in the VA system or in the DoD system.
All three of those organizations are, essentially, extraordinarily large IDNs. They are nationwide health information organizations because they cross and transcend state boundaries. That’s the core use case for the NHIN Exchange — coordination of care and information discovery across large, nationwide health information organizations. The core standards that are in use are common standards that can also be deployed within an HIO context, so if I wanted to discover where else a patient has been and what information is available about that patient, I would use the core NHIN services. They’re essentially the IHE interoperability stacks, particularly the XDS, XCA; that stack.
The way that I describe it, I’m going to paint two pictures. Picture one says that I’m a provider who is in an exchange that offers both services and I’m referring to a provider who only gets the simpler kinds of services, the direct services. As a provider with access to both services, when a patient presents, I may do a query to find out where that patient has been seen since the last time I saw them, and discover information with the patient’s consent that helps me inform the care of the patient.
Then at the end of that encounter, I might publish the updated physician information into the repository in the sky for future care providers to discover information. Those are great uses of the NHIN specifications and services.
Then, at the conclusion of that encounter, I want to refer the patient over for care. Let’s say it’s for care that isn’t served on the same EHR, where I can’t rely on the EHR’s capabilities to have the chart available. So I want to push a referral transaction over to, let’s say, the cardiologist. Then at the conclusion of the cardiologist’s care, I really want them to push me an update to what happened to the patient.
That transaction, by its very nature, just doesn’t fit the “publish something in the sky and then grab something from the sky” model. I mean, you could do it that way, but the semantics of that transfer are directional. I want to give the referral over to that provider and that provider expects to receive it in his or her inbox. Same thing for a lab. You might publish the lab to a lab repository in the sky so that all people can have access to it, but the ordering provider wants to get that lab result in his or her EHR directly as well. So you’ve got both publish semantics and push-to-provider semantics.
Pretty much all we’re about at the NHIN Direct project is to create the standards, the specifications for that push-to-address case in ways that allow an HIO or lighter weight organization to be able to provide an address for a provider or for a patient, and for the routing of a transaction to go to that address. So, there’s a lot.
Many of the HIEs created their business models around charging for that type of service. Will they use some aspect of NHIN Direct or is this a replacement or a competitor for it?
A lot of HIOs, I think for very good reasons. It drives a lot of business value. You get started with simple direct services. Nothing that NHIN Direct is doing should, or does, conflict with that desire. NHIN Direct will, hopefully, make those services easier to deploy because there will be a set of standards around them, and EHRs, hopefully, will have their standards embedded within the EHR so it will be easier to get services up and running.
Now if your business model is, “Well, this stuff is hard, and so our business model is to do it because nobody else can and we don’t want any competition and anything that makes it easier to do is a threat to our business model,” then sure, it could be a threat to the business model. I don’t believe that. I believe that making it easier, making it more scalable, actually makes it easier to offer those services at a profit for exchange sustainability.
As I said, I think if you look at the example of successful HIOs, they pretty much all solved this problem at the cost of some blood early on, and they’re able to offer these services. NHIN Direct is going to give them a way of scaling that service offering more, but I don’t think they think it’s a threat to their business. I think if you look again, if you look at the example of HIOs that are up and running and doing well, I don’t think any of them are scared by NHIN Direct. In fact, I think they think of this as something that makes their work easier to do.
What about those EHR vendors that have their own exchanges?
A lot of the EHR vendors — and you can go to the NHINDirect.org website and look at the implementation group to look at the current members of the implementation group and you’ll see a number of the leading EHR vendors out there — many of them are participating in this effort. I can’t speak for them, but if you look at the strategic situation, I think many of them would like to offer a set of value-added services on top of their EHRs for simple connectivity.
Many of them are in context where if you look at the state of HIT in the United States, very few providers operate in a service area where it’s all one vendor and where you can mandate and lock down a single vendor model. So, many of these EHR vendors have customers — oftentimes large health systems — who are asking them to enable interoperability within their products, but also across other products.
I think many of these EHR vendors see this as a way to fulfill their customer’s business needs in a way that is standard, and allows them to offer standardized services. I think the EHR vendors, by and large, have looked at this as an opportunity much more than they look at this as a threat.
John Halamka likes the idea of a health URL where individual data can be pushed. Would this support that, or is anybody working on that?
Absolutely. The notion of an address that you can route information to is a core principle of the NHIN Direct project. In fact, John’s recent blog post describes the work of the addressing working group in NHIN Direct. He’s a participant of the implementation group and he references, explicitly, the health URL concept in the context of what we’re trying to do.
What about privacy and security?
I’m going to back up. If you look at the record locator kinds of transactions — where has this patient been, what information is available about this patient — those are the transactions for which specifications and standards currently exist. There is a significant set of policy issues around that because the information holder is receiving a transaction basically requesting information and needs to decide, on the fly, whether that’s an appropriate information request, and whether the PHI disclosure that’s associated with that is proper and legal. Any of those systems that are up and running have put in place consent models and put in place policy models that ensure that data is only provided when it’s legally appropriate to.
In the set of push transactions that NHIN Direct is all about, the information holder and the initiator of that transaction are one in the same person or organization. The best way to think about the NHIN Direct kinds of transactions is that the data are going to flow, regardless. I’m going to send the summary of care to the provider via fax. I’m going to send it via paper. I’d love to be able to send it electronically.
The legal responsibility is pretty clear for this. It’s the information holder’s responsibility to determine whether the disclosure that they’re making is appropriate. Appropriate is defined by any of the HIPAA exemptions, as well as by explicitly getting patient consent to do the transaction.
What we need to make sure of in the transactions and in the policy framework around health information exchange is that if there is a disclosure along the way, that we know exactly where that disclosure originated from, we know who the legal entity responsible for the disclosure was, and also that we protect the health information and make it secure all along the way so it doesn’t inadvertently get exposed. We’ve got a privacy and trust working group that’s focused on those exact issues.
I think John’s post mentioned that it will be the same framework that’s used by the full-scale NHIN, not a lightweight version.
Exactly, so we’re going to be using TLS on both ends. We’re going to be ensuring that all the data are encrypted in transit. We would recommend that HIOs encrypt it at rest as well, and ensure that they’ve got the appropriate security policies.
The other part of this is that we’re just doing the transaction semantics. We’re just doing the specification. Somebody’s got to take those specifications and run them. The organizations that run them need to run those transactions within a policy framework. That policy framework needs to have much more in it than just transaction-level security rights. You absolutely have to encrypt the data in transit, but then you also have to make sure the exchange has the security policies in place; does security audits and remediation, has good quality assurance policies in place; has good operational controls in place to make sure that … you’ve got to secure the entire system and not just the transactions.
There’s a lot of policy work to be done. We’re closely coordinating the technology work that we’re doing with the policy work that’s being done, both at ONC as well as within the NHIN workgroup and the HIT Policy Committee.
Maybe you can expand on that thought because I’m not sure I understand. What you have is a set of policies and practices, but someone has to actually run it.
Exactly. The metaphor that I’ve used is that you’ve got cake? Cake is good stuff. You want to eat cake. Cake adds value.
We’re not making cakes in the NHIN Direct project. Somebody’s got to run a bakery to bake some cake. What we’re doing in the NHIN Direct project is creating a recipe for cake, and we’re making sure that recipe is well-tested and making sure it works across a variety of settings. That you can use a small bakery or a big bakery to make your cake and the cake’s going to taste just as good, regardless of where you bake it.
But, as an organization, our project is to create a recipe. You’re not going to get any cake from the NHIN Direct project. You’ve got to get your cake from a bakery.
Is there any centrally hosted infrastructure or services?
Not so far as we’ve discussed. There has been some belief — which we’re still going to need to explore this — that there are a couple of potential services that the federal government may end up hosting. One might be a central certification body, as well as a certificate authority to make sure that people who operate on the exchange are carrying correct policy frameworks. That’s the one potential role for the federal government.
They are, essentially, assuring trust. That’s a role that the federal government’s already taking on and is actually legally responsible to take on with respect to the NHIN Exchange, to the extent that the NHIN Direct services get incorporated into the NHIN Exchange. The federal government and ONC have a legal responsibility to create a policy framework for that. That’s one role that the federal government could play.
There are potential other roles the federal government could play, particularly around potentially using some of the information that we have around NTI; as well as that CNS is going to have to have a lot of paying providers for Meaningful Use as a way of making directory services that people might offer more valuable. But, we still have yet to explore or decide on those capabilities.
By and large, the NHIN Direct project will exit with a recipe and not so much with infrastructure.
Do you think the EMR products that are out there will be ready to share data once the platform is available?
With everything else in software, there’s a software development life cycle. There’s a set roadmap on capabilities. What I’m encouraged by is that so many of the EHR vendors are participating in the project and have committed to do real-world implementations. Not necessarily full-scale, real-world implementations, but have committed to doing real-world implementations. That encourages me that by 2011 we’ll have exchange capabilities at a broader scale to support.
What this is all about is supporting providers, both in terms of their obligations to get the money for Meaningful Use as well as supporting providers and patients in the quality and efficiency goals that we’ve set out for the HITECH Act. My hope is that given the participation that we’ve got that we’ll get a good amount of support for providers in 2011.
How would you turn all this technology concept into something that patients would understand? What would you say the outcome would be and when will they begin to see it?
As a patient, what we would hope to see is that a patient has interoperable access. Again, I think John Halamka’s posts on the health Internet address called the health URL are as good a place to start in understanding what this is all about. As a patient, I should be able to get a health Internet address. I should be able to give that health Internet address to my provider and say, “Hey, I want my information posted here.” The provider should say, “OK, no problem. I’ve got all the capabilities for doing that.”
As for when that will happen, I expect it will be in essentially limited operations by the end of this year. I would expect us to be in wider-scale operation by the end of next year.The way that I would judge this project being a success would be the number of providers who’ve got an address.
The other side’s the patient experience. That when I get referred over for care, get treated by a specialist, and then go back over to primary care, that the thing that I expect to happen — which is that specialist knows why I’m there and knows my health information necessary for treating me and that my primary care provider knows what happened when I went to the specialist — that all that exchange has happened behind the scenes with my consent, appropriately.
I think those two outcomes would be the way that I would judge the success of this project. My beliefs and hope would be that we’ve got a decent amount of availability to service it by the end of 2011, and then rolling on to wider scalability in 2011-2012.
What also makes me feel good about this is there are a lot of organizations that can do parts of this, and really all we’re doing is taking the best practices that a lot of these organizations are doing, and saying, OK, that’s great. We know how to do it. We know how to do it, even at scale. Well, we don’t know how to do it and do it interoperably so that you can share information between systems, so let’s focus on that.
Any final thoughts?
I think that if you’re asking about the fact that we’re not hosting, we’re not running any services. I think that’s the thing that people get extraordinarily confused by, and understanding that is real useful.
Another common question that comes up is, “What are you doing about content?” The project itself is focused on transport, but we’re sitting and working with all the other work that’s being done around content to make sure that the payloads that people exchange are interoperable payloads; and all the good work that’s in the IFR to help us constrain down to CCR and CCD, but also constrain down to terminology. We’re relying on that work getting better and more stringent over time so that we can share information, but then we can also understand the payloads.