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 used as-is out-of-the-box or can be customized by the organization implementing CONNECT. The architecture also contains These adapter components that 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 Electronic Medical Record (EMR), Hospital Information System (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 run time 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 adapter includes the 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.
| Info |
|---|
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.
...
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,. |
...