The CONNECT architecture is intended to provide a flexible, extensible, cross-platform solution to enable public and private organizations to securely exchange health information over the Internet using the Nationwide Health Information Network (NwHIN) technical specifications that support the exchange of data over networks such as the eHealth Exchange and the Direct Project. The CONNECT architecture is a joint product of the Office of the National Coordinator for Health Information Technology (ONC), the CONNECT Program Management Office, the CONNECT development team, and federal agencies that collaborate with ONC and the Nationwide Health Information Network.

The following sections provide a brief background on the Nationwide Health Information Network and the needs and requirements that CONNECT is intended to address along with an overview of the CONNECT system and architecture.

Goals and Context

This section describes the goals and major contextual factors for the software architecture. The section includes a description of the role software architecture plays in the life cycle, the relationship to system engineering results and artifacts, and any other relevant factors.

The Health Information Technology for Economic and Clinical Health (HITECH) Act, part of the American Recovery and Reinvestment Act of 2009 (ARRA) [Congress 2009, see Reference Materials], establishes programs to improve health care quality, safety, and efficiency through the meaningful use of certified electronic health record (EHR) technology and secure health information exchange. Under HITECH, eligible health care professionals and hospitals can qualify for Medicare and Medicaid incentive payments when they adopt certified EHR technology and use it to achieve specified objectives.

ONC has provided funding for a number of health IT programs, including the development of the NwHIN--a set of standards, services, and policies that enable the secure exchange of health information over the Internet.

CONNECT is an open source software solution that supports health information exchange--both locally and at the national level. CONNECT uses NwHIN standards to make sure that health information exchanges are compatible with other exchanges being set up throughout the country.

This software solution was initially developed by federal agencies to support their health-related missions, but it is now available to all organizations and can be used to help set up health information exchanges and share data using nationally recognized interoperability standards.

The CONNECT project is designed to meet these requirements:

• Open platform. The solution needs to leverage open source communities wherever possible. The solution should be freely available to all, not only Federal agencies, and embrace an open source approach
• Support for multiple operating systems. The federal agencies participating in the Federal Nationwide Health Information Network Consortium have a wide variety of existing health system platforms--Windows, Linux, Solaris, mainframe, etc. Any OS-specific approach would not be viable in this environment. While motivated by participating federal agencies, this applies to non-federal users as well
• Readily extensible. Users will need to develop adapters to integrate existing systems with CONNECT. This means that CONNECT would benefit from an extensible service bus that can incorporate service engines and protocol binding components to meet their specific requirements
• Commercial support available. Despite the desire to leverage an open source approach to maintaining CONNECT, federal partners made it clear that commercially supported implementations of the underlying CONNECT platform are critical for enterprise deployment
• Support security coding best practices and guidelines. The solutions needs to leverage commercial and open source tools which analyze static source code and provide feedback to minimize security, performance, and best practices violations.

To meet the goals of CONNECT, the software must be fully functional out-of-the-box while at the same time being configurable and flexible enough to allow entities to customize it to meet their individual needs and their existing health information systems.

Significant Driving Requirements

This section describes behavioral and quality attribute requirements (original or derived) that shaped the software architecture. Included are any scenarios that express driving behavioral and quality attribute goals.

Support the Nationwide Health Information Network Specifications and Standards for Secure Health Information Exchange

The Nationwide Health Information Network is a set of standards, services, and policies that enable secure health information exchange over the Internet and exchange encompassing a diverse set of organizations, technologies, and approaches. Core capabilities include the ability to:

• Match patients to their data without a national patient identifier
• Find and retrieve health care information within and between health information exchanges and other organizations
• Deliver a summarized patient record to support patient care and to support the patient's health
• Establish feeds of health information between organizations to support disease surveillance and other applications
• Exchange health and health care information between organizations when available without the need for an electronic request for exchange
• Support consumer preferences regarding the exchange of his or her information, including the ability to choose not to participate
• Support secure information exchange
• Support a common trust agreement that establishes the obligations and assurances to which all NwHIN participants agree
• Support harmonized standards that have been developed by voluntary consensus standards bodies for exchange of health information among all such entities and networks

These core capabilities include both technical capabilities and business structures to establish an interoperable infrastructure among distinct networks and systems, allowing for different approaches and implementations while ensuring secure information exchange as needed for patient care and population health.

The services currently defined by the Nationwide Health Information Network and implemented within CONNECT are described in the table below.

Table - CONNECT Services

In addition to the services listed above, the NwHIN also includes a number of specifications that establish the framework for exchange. This framework is described in the table below.

Table - Guiding specifications

This set of NwHIN services, along with the framework specifications, are the basis of the functionality of CONNECT and form the organization for the views found in the Architecture Views section of this document.

Example Scenario

It may be helpful to illustrate the roles and interactions of the core NwHIN services through an example scenario. For our example, a patient is receiving medical care through a VA hospital. However, VA doctors wish to refer him for a consultation to a specialty outpatient facility that is a member of a private-sector Health Information Exchange (HIE). In this scenario, the NwHIN services are identified through boldface. Illustrations are provided for clarity although these are simplifications of the actual message exchanges.

When the VA and HIE agree to participate in the NwHIN, they develop or acquire systems that are able to communicate using web services (Messaging Platform). For the VA, this might be an instance of CONNECT that is interfaced to its existing health care systems. Both organizations agree on their terms of exchange, often by signing a data use and reciprocal support agreement, and have digital certificates that attest to their identity and their right to exchange information with one another (Messaging Platform). These certificates will be used to sign and encrypt all communications between the VA and the HIE.

Organizations that participate in formalized exchanges, such as the Nationwide Health Information Network Exchange, or Healtheway, publish their identities and the list of services they will provide. This information is stored as a catalog in a web service registry (Web Service Registry). They can now discover the existence of each other as well as the set of services each offers. They can likewise now know how to invoke the services of the other. The VA and HIE are now ready to exchange health information with each other and with other network participants.

The clinic staff at the specialty clinic may request a summary of care document from VA for the patient to better inform care. The summary of care provides a synopsis of important medical information, including demographic data, diagnoses, procedures, allergies, medications, and other information. In order to receive any health information for the patient, the HIE must perform three primary steps:

1. Match the patient's identity with VA
2. Determine what relevant health documents exist within VA for the patient
3. Request (and receive) specific health documents for the patient as required

For all of these communications, messages between the HIE and the VA's CONNECT gateway are encrypted to prevent interception and are digitally signed to identify the source of the information and prevent either party from later repudiating their actions (Messaging Platform).

When the patient registers with the specialty clinic, he/she provides a set of demographic information, including full name, date of birth, address, phone numbers, and so on. The clinic uses its NwHIN specification-enabled gateway to request identity matches based on this information from other exchange participants, including the VA (Patient Discovery). In making this request, the clinic asserts that it is entitled to request information on behalf of the patient (Authorization Framework). This assertion is embedded in the request the clinic transmits to the other organizations. Having accepted the assertion, the VA searches the VA patient index to determine whether any patient matches the demographic information the clinic provided. The VA determines that there is a unique match (Patient Discovery). The gateway then consults the profile associated with the patient's identity to determine whether he/she has consented to the sharing of health information with other organizations (Access Consent Policies). If the patient has permitted information sharing, the VA sends back to the clinic the patient ID used by VA systems (Patient Discovery) along with the demographic information it has on file. In turn, the clinic searches confirm the match based on the demographic information sent by the VA and its own matching algorithms (Patient Discovery). Only if both organizations agree that the demographics constitute a match for a single patient does an exchange proceed.

Now that the clinic has obtained a VA patient identification, the clinic uses this ID to ask the VA to provide a list of health documents for the patient that may be relevant for the consult (Query for Documents). In doing so, the clinic can narrow its request for documents to, for example, a specific range of dates or document type, etc. The VA searches its internal document registry to locate documents that match the provided search criteria and returns a list of the documents with VA document IDs for each document in the list. If the clinic queried other organizations for documents in addition to VA, their documents might be aggregated by the clinic into a single list (Query for Documents).

Now that the clinic has obtained a list of potentially useful documents, the staff can scan the list to select the ones that are actually required to perform the consult. The clinic then uses the HIE to request this specific set of documents from the VA using the document identifiers VA provided (Retrieve Documents). The VA CONNECT gateway retrieves the requested documents and transmits them as attachments to the HIE and clinic. In so doing, both the VA and HIE record that the information exchange occurred for later inspection as required. Since the summary of care is an XML document, the clinic can decide how it wishes to utilize the information. It can transform the information into a human-readable report, and it can parse the document fields individually to integrate the information into its existing data systems.

It is important to note that in most circumstances, the sharing of patient information can only occur with the patient's explicit consent. To support this, each organization must establish a profile for patients that articulate with whom they elect to share their personally identifiable health information (Access Consent Policies). Organizations can share these profiles with each other to ensure consumer preferences are honored, but the NwHIN specifications do not require reconciliation of multiple consent profiles into a single, uniform profile that is uniformly applied everywhere.

While the preceding descriptions have focused on the interactions between providers and HIEs to exchange information, it cannot be forgotten that these activities are performed on behalf of a particular patient who plays an important role in health information exchange.

Support the Nationwide Health Information Network Direct Project Specifications and Standards for Secure Health Information Exchange

A new initiative, the NwHIN Direct Project, has been launched to explore the NwHIN standards and services required to enable secure health information exchange at a more local and less complex level. The Direct initiative is an attempt to simplify the exchange of medical information and at its core represents a simple concept, which is that the electronic exchange of patient health information and medical data in general can be accomplished by simply using encrypted email. The Direct initiative is an excellent alternative to those enterprises and medical health practitioners that are not part of more formal HIEs that support the NwHIN Exchange transactions (i.e., PD, QD, RD, etc.). For more information about the NwHIN Direct Project, please visit The Direct Project

CONNECT supports the Direct transport specifications.

Example Scenario

It may be helpful to illustrate the roles and interactions of the Direct services through an example scenario. For our example, a provider is referring a patient to a specialist. The provider and the specialist have agreed to use a Direct compliant email to exchange patient information and use Health Information Service Providers (HISPs) to provide them that service.

A HISP is not necessarily a separate business or technical entity; instead, it is a logical concept that encompasses certain services and components that are required for Direct Project exchange but may be performed or handled by a party other than the sender or receiver, depending on the deployment option chosen by the implementation. These components would be universal addresses, certificate management and discovery, security, trust verification, and information transport.

There are some prerequisites for Direct exchange as discussed below:

• As required by law or policy, the sender has obtained the patient's consent to send the information to the receiver. Therefore, the sender and receiver know that the patient's privacy preferences are being honored
• The sender of a Direct message has determined that it is clinically and legally appropriate to send the information to the receiver through out-of-band means
• The sender has determined that the receiver's address is correct
• The sender has communicated to the receiver, perhaps out-of-band, the purpose for exchanging the information
• The sender and receiver do not require common or pre-negotiated patient identifiers. Similar to the exchange of fax or paper documents, there is no expectation that a received message will be automatically matched to a patient or automatically filed in an EHR

The provider uses some technology, such as an EHR system, to create a summary of care document. Using the address that the specialist has given the provider, the provider sends some textual information about the referral with the attached document to the Direct address of the specialist via some technology, like an email software.

In order to do this, the email software securely pushes the message to the sender's HISP. The HISP validates the email message for all proper MIME content. The sender's private key is discovered and a message signature is generated. The recipient's (or recipients') certificates are discovered and the message and signature are encrypted into an S/MIME envelope. The encrypted message is sent to the recipient's HISP.

The recipient's HISP receives the encrypted message. The HISP discovers the recipient's private keys and the message is decrypted. The sender's certificate is discovered and the message signature is verified. The sender's certificate is checked against the trust store to ensure the sender is from a trusted HISP. The specialist receives the secure referral message in his email inbox . He sees the provider's description of the patient's problems, allergies, and medications and is well briefed for the patient's visit later today.

A Note about the Nationwide Health Information Network Specifications, Healtheway, and Exchange Networks

The NwHIN standards and specifications are used by an exchange network, formerly called the Nationwide Health Information Exchange.

In October 2012, ONC announced the successful transition of the Nationwide Health Information Network (NwHIN) Exchange to eHealth Exchange, a public-private partnership that represents ONC's commitment to support health information exchange innovation in the private sector. The eHealth Exchange is composed of federal agencies and private partners that have implemented nationwide health information network standards and services and executed the Data Use and Reciprocal Support Agreement (DURSA), a legal agreement, in order to securely exchange electronic health information.

ONC continues to establish the national standards that promote interoperable health information exchange (called the Nationwide Health Information Network). ONC will continue to work closely with organizations to ensure the development of secure, effective, and cost-efficient health information exchange standards, services, and policies and provide guidance for their implementation. For more information about the eHealth Exchange, please visit http://sequoiaproject.org/ehealth-exchange/.

The technical specifications that CONNECT implements can be used with the eHealth Exchange, in which many of CONNECT's federal partners participate, or any health information exchange.