Direct exchange describes the push of health information from a sender to a known receiver, similar to a how an email or fax is pushed from one endpoint to another. Details are discussed further in the Direct Overview document.
The Direct Project will help support simple exchange where a sender wants to push health information securely to a receiver. This simple model covers a number of user stories, and in conjunction with other data components may help to satisfy some meaningful use requirements.
The Direct Project was designed to provide support for simple scenarios where a source with data intends to push it to a receiver, which complements the use cases already supported by the National Health Information Network.
No. CONNECT is a software stack that implements health exchange specifications. The Direct Project is a project to create transport specifications for directed exchange. The CONNECT roadmap includes support for the Direct specifications, which will allow any organization using CONNECT to implement the Direct specifications.
While a state-based HIE is not required to support Direct exchange, it can choose to do so, providing services to its members to make it easier for them to send Direct messages to each other and to others outside the HIE. Providers do not need to belong to a state-based HIE in order to send Direct messages.
The Direct Project allows senders to push health information securely to known receivers. This covers a number of important exchange scenarios, but there are important limitations in the Direct Project's scope. For example, the Direct Project does not support discovering places that know about a given patient, or pulling data from organizations where that patient has been seen. More details about the Direct Project's supported scenarios and its limitations can be found in the Direct Overview.
There are two levels of participation. You can contribute to our discussion, offering advice and real-world experience as we continue to design and refine the Direct Project. Suggestions for this level of contribution are outlined in the Direct Project Participation Guidelines. But you might also be interested in getting involved, taking part in actual data exchange. Since the Direct Project is currently still in a pilot phase, you would need to join one of our pilot implementations (and you'll need a lot of patience as we continue to work out the early details). You can learn more about what it takes to participate in a pilot from the pilot participation guidelines checklist.
It's a simple question with many complicated answers. In brief, you'll need to send and receive secure emails, and optionally manage how trust is handled in order to make those messages secure. For further reading, please consult the Direct Overview , Direct Security Overview , Deployment Models, Core Direct Specification, and Conversions from XD* to SMTP.
There are many components to the Direct Project - code to help support its deployment, documentation to explain how it can be implemented technically, and real world pilots to prove and refine the project's specifications. To learn more about our current progress, please refer often to our progress tracker.
In the same way that clinicians currently do not assume that it is safe to fax protected health information to anyone with a fax number, or mail PHI to anyone with a post office address, Direct Project users cannot assume that it is safe to send messages to any Direct Project address. Direct Project users will need to establish real-world trust relationships with other Direct Project users on their own terms, but once they have established this real-world trust, they can be sure that a Direct Project network will securely deliver Direct Project messages to the trusted Direct Project user. This secure transportation of messages is handled through a PKI model, and an overview can be found in the Direct Security Overview document.
Currently, there is no single authority who issues certificates to Direct Project participants. The recommendations for the pilots is documented on the wiki page Digital Certificate Recommendations for Pilots.
A Health Information Service Provider, or HISP, is a logical concept that encompasses certain services that are required for Direct Project exchange, such as the management of trust between senders and receivers. It may be a separate business or technical entity from the sender or receiver, depending on the deployment option chosen by the implementation.
Not necessarily; there are various deployment models that can be used to instantiate a Direct Project implementation. The details of the various options are presented in the wiki page Deployment Models. If you choose a model in which the services performed by the HISP are not provided by a separate business or technical entity, you will have to implement additional capabilities to meet the various Direct Project standards and specifications.
As an HIE, you might choose to provide HISP services to your members to support the types of exchange covered by the Direct Project. As an organization or individual, you might choose to play the role of a HISP in order to avoid needing to establish a separate business relationship with an entity to provide services that you can easily perform yourself. You'll need to balance these advantages with the added responsibility and technical challenges you'll take on by choosing to perform HISP functions.