The CONNECT architecture establishes a gateway between health information systems and organizations that support the Nationwide Health Information Network (NwHIN) Exchange specifications and standards and acts as a Health Information Service Provider (HISP) for organizations that support NwHIN Direct Project Secure Health Transport.
CONNECT is based on service-oriented-architecture design principles and web service interfaces. The CONNECT solution exposes all of these services as web services described by WSDLs and schemas referenced in the elements catalog accompanying each view later in this document. Furthermore, the architecture provides reference adapters that can be can be customized by the organization implementing CONNECT. These adapter components can be changed and/or entirely replaced to meet the needs of an organization or the existing systems it wishes to support.
At a technical level, the architecture is most easily understood if broken down logically into two sections: a gateway and an adapter. The gateway handles communication between different organizations' health information systems, and the adapter adapts the gateway to an organization's EMR, HIS, or back-end system. This architecture enables individual components to be replaced by custom solutions as long as they adhere to the defined service interface. This also allows implementations to be hosted on different hardware and software platforms and allows services to be implemented using different programming languages. CONNECT also utilizes dependency injection for all service components, allowing implementer's to control what service component implementation class is loaded at runtime through configuration files. This allows a service component implementation class to be easily substituted by a custom implementation class or changed from one implementation, such as the default web service implementation, to another, such as a local java implementation. In addition, any service component can be disabled by setting the appropriate NoOpImpl class in the configuration.
The CONNECT gateway includes the services and components necessary to connect the existing health information system(s) of an organization to any other entity. Gateway services provide mechanisms for receiving messages and passing them to the adapter as well as for receiving messages from the adapter and sending them to other entities using the NwHIN Exchange and Direct Project specifications. In addition to supporting the core NwHIN services, components in the gateway also provide services to manage the NwHIN connection endpoint URL data, patient correlation, the System Administration Module and a variety of other supporting services. The CONNECT adapters include services that interface with the existing health information system of an organization as well as reference implementations of interchangeable adapter components such as an XDS registry and repository.
The externally facing gateway interface is an implementation of the NwHIN specifications and standards. For the most part, the components and services in the CONNECT gateway are intended to be used as-is without any modification. The CONNECT adapter comprises the services that are most likely to be customized by an implementing organization to integrate into their environment and work flow. In order to provide a solution that works out-of-the-box, reference implementations of CONNECT adapter services are included in the adapter. An organization may use the reference implementations directly as-is or replace one or more of them with their own custom implementations. They may also use the reference implementations as a starting point for creating their own custom solutions.
It should be noted that while these reference adapters work as-is and out-of-the-box, their use is discouraged in production environments. The adapters will likely need to be modified in almost all use cases in order to accommodate existing database schemas and/or external systems. Please refer to the Implementing CONNECT section for more information on how to accomplish this.
In general, each component in CONNECT is implemented as a component proxy which may be a deployed web service or some other implementation. Component proxies utilize dependency injection, allowing implementers to control what service component implementation class is loaded at runtime through Spring configuration files. This allows a service component implementation class to be easily substituted by a custom implementation class or changed from one implementation, such as the default web service implementation, to another, such as a local java implementation. Since the gateway web services conform to the NwHIN specifications, which requires them to be secured web services, only the secured web service implementation is provided. In addition, it should be noted that any service component can be disabled by setting the Spring configuration for the component service to inject the associated service NoOpImpl class.
The services that manage the interaction between the gateway and the adapter are based on but do not necessarily conform to the NwHIN specifications. Services at the individual component layer inside the gateway or the adapter are exposed internally only and are implemented as component proxies. Although these interfaces are defined for the reference implementation in the adapter, they are not static and can be changed by the implementing organization.
The two exhibits below express the overall CONNECT architecture, including separation between gateway and adapter, and identify the components most likely to be customized or replaced by an implementing organization. The following two diagrams are high-level views of the CONNECT architecture for a message sent securely over the Internet and a message received securely over the Internet.
Diagram - CONNECT Outbound Transactions.
Diagram - CONNECT Inbound Transactions
When sending messages to trading partners, the existing health information systems of the organization implementing CONNECT are responsible for initiating the interaction. Therefore, the number of reference components in the adapter is much smaller, and it is more difficult to identify commonality across the various organizations that may implement CONNECT, be they Federal agencies or private-sector organizations. However, the handling and orchestration of the outbound message is primarily the responsibility of the CONNECT gateway. Once a message is generated and passed to the gateway for processing, the services are common for most implementations.
Diagram - Deployment diagram
CONNECT consists of an application server and database server, and communicates with the adopter's health systems via adapter webservices. The adopter initiates messages to Exchange Partners and Direct participants using the entity webservices. CONNECT processes these messages and then sends them to the Exchange Partners using NwHIN Exchange webservices and to the Direct participants using Direct secure health transport .
The element catalog below lists the elements defined in both the CONNECT gateway and adapter, for both the view of messages from organizations using the NwHIN specifications and messages to NwHIN entities, as they are illustrated in the architecture figures above.
Table - Element catalog
Element | Description |
|---|---|
CONNECT Gateway | An encapsulation of services that represent the CONNECT core gateway |
Orchestration Components | An encapsulation of services that send and receive messages and orchestrate the processing of those messages |
Document Query | The service responsible for orchestrating and processing a document query as part of the Query for Documents core service |
Document Retrieve | The service responsible for orchestrating and processing the retrieval of patient documents as part of the Retrieve Documents service |
Document Submission | The service responsible for orchestrating the processing the submission of patient documents as part of the Document Submission service |
| Document Data Submission | The pilot service responsible for submitting document metadata without the document body to a recipient. |
Patient Discovery | The service responsible for orchestrating and processing patient discovery as part of the Patient Discovery service |
| Patient Location Query | The service responsible for finding which communities may have healthcare information for a given requested patient. |
Administrative Distribution | The service responsible for orchestrating the processing the submission of non-patient-specific documents as part of the Administrative Distribution service |
Core Components | An encapsulation of components that are core to the CONNECT gateway. Most of these services are integral to the gateway and are used with orchestrating messages |
Audit Repository | A repository used to store audit information. The reference implementation uses MySQL but may be replaced by an organization |
Connection Manager | For CONNECT 5.0 and older, a service that manages endpoint URLs to other systems as well as the URL for some of the services within the gateway. It combines both UDDI-configured service endpoint information (stored in uddiConnectionInfo.xml) as well as internally defined service endpoint information (stored in internalConnectionInfo.xml) |
| Exchange Manager | For CONNECT 5.1 and higher, a service that manages endpoint URLs from both UDDI and HL7 FHIR Directory web sevrices registry, stored in exchangeInfo.xml. |
| Internal Exchange Manager | A service that is used to define internal services (adapters) endpoint information, stored in internalExchangeInfo.xml. |
Patient Correlation Repository | A repository used to manage the correlation of patient IDs from the implementing organization and other systems. The reference implementation can be replaced by the implementing organization |
UDDI Update Manager | Prior to CONNECT 5.1, a component that receives updates from a NwHIN UDDI server and updates locally cached service endpoint URL information and also provides a UDDI data pull mechanism that retrieves the UDDI connection information from the UDDI server |
| ExchangeScheduler | For CONNECT 5.1 and higher, a component that is responsible for downloading and maintinaing web service registry information from both NwHIN UDDI server and the HL7 FHIR Directory. |
Entity Orchestration Components | Contains the components that receive messages from the adapter and orchestrates the sending of messages to exchange partners and aggregation/processing of the responses |
CONNECT Adapter | An encapsulation of the software that must be implemented by an organization to connect the gateway to existing health systems, receive incoming messages, and initiate outgoing messages |
Document Registry | A document registry that manages and stores the metadata associated with patient documents, plugged into the adapter service bus using the XDS.b interfaces. The open source reference implementation in the adapter may be replaced by the implementing organization |
Document Repository | A document repository that manages and stores patient documents, plugged into the adapter service bus using XDS.b interfaces. The open source reference implementation may be replaced by the implementing organization |
Master Patient Index (MPI) | An index that manages and stores patient demographic information for the organization. The open source reference implementation may be replaced by the implementing organization |
Policy Engine | An engine used to manage policies regarding access to patient information for the implementing organization. The open source reference implementation may be replaced by the implementing organization |
Direct | Implementation of the Direct Project standards and specifications required to enable secure, directed health information exchange |
| Core X12 Document Submission | The service responsible for orchestrating the processing the submission of patient related administrative documents as part of the Core X12 Document Submission service |
| System Administration Module (Admin GUI) | This module is a web based Graphical User Interface (GUI) application that allows administrative users to manage CONNECT Gateway configuration, monitor gateway statistics etc,. |
The CONNECT gateway also supports two different mechanisms for bypassing the built-in orchestration processing of both outbound messages to the NwHIN and inbound messages from the NwHIN, detailed below.
Diagram - Message path.
These two mechanisms taken together allow an adapter to completely override any orchestration within the gateway, replacing it with a process more suited to the organization's existing systems or organizational policies.
Summary of Background Changes Reflected in Current Version
CONNECT 4.0 replaces the Metro (JAX-WS RI) web service stack with ApacheCXF web service stack. The Metro web service stack was a limitation as it does not explicitly document or support methodologies to deploy to other application servers beyond GlassFish. This version of CONNECT removes this explicit dependency.
CONNECT 4.0 supports the streaming of large payloads (payloads over the size of 1GB). Previous versions of CONNECT were specifically limited by the amount of memory that could be allocated to the Java process. In supporting this the audit service no longer attaches the payload when making an audit request to the audit adapter.
CONNECT 4.0 can send and receive messages using the Direct Project standards and specifications required to enable secure, directed health information exchange. To facilitate this new functionality CONNECT integrates with a mail server via SMTP and IMAP protocols using the javamail API.
CONNECT 4.4 supports CAQH CORE X12 Document Submission services (feature requested by CMS) for accepting CAQH Core compliant transactions with Accredited Standards Committee (ASC) X12 submission payload.
CONNECT 4.6 supports IHE ATNA profile for Patient Discovery (synchronous and deferred), Query For Documents, Document Retrieve, Document Submission(synchronous and deferred) and CORE-X12. The System Administrative module can now be used to search and view audit messages.
CONNECT 4.7 includes upgrading Hibernate from version 3.2.5 to the 5.1.0, addressing event logging bugs, improving security for the System Administration Module, migrating the automated test environment to utilize WildFly application server, and providing instructions on configuring WildFly for FIPS compliance.
CONNECT 5.0 includes a major web stack upgrade (CXF from 2.7.3 to 3.1.9), adding customizable HTTP headers to outgoing NwHIN requests, adding a time stamp to the eHealth Exchange UDDI, an audit.properties file editor, configurable TLS versions for UDDI updates, and code updates to allow CONNECT to be compiled with JDK 1.8.
CONNECT 5.1 includes a new Certificate Manager GUI, Load Test Data GUI, Exchange Manager GUI, database-less deployment, enforcing SAML compliant messages and incorporating of FHIR Directory web service registry.
CONNECT 5.2 includes two new services: Patient Location Query and Document Data Submission.
CONNECT 5.3 includes new Import Wizard GUI, multiple certificate support using Server Name Indication (SNI) and configurable Secure Hash Algorithm (SHA) versions.