Architecture Views specify the software architecture. Views specify elements of software and the relationships between them. A view is a representation of one or more structures present in the software. This document comprises a multi-view approach of the architecture. However, unlike the prescribed set of views advocated by models such as the "4+1 View Model" [Kruchten 1995; see Referenced Materials section], it follows a more modern trend of selecting the most useful views to describe the system at hand. As with much of the architectural documentation of successful open source projects, these views concentrate on components-and-connectors diagrams and sequence diagrams.

The views are organized generically and then by service. Use the links below to navigate.

Generic Component

Description

CONNECT uses the same basic processing for all messages (Patient Discovery, Retrieve Documents, Query for Documents, etc). All messages are audited, policy-checked (if applicable), and then passed off to the NwHIN for outgoing messages or to the adapter layer for incoming messages. At this level, the contents of and type of message has very little do with how the message is handled. By leveraging this property of the specification, a common strategy is used to orchestrate all messages. This reduces code duplication and decreases the cost of modification to this process.

Details

In Figure 1 below, three common components are used: Policy Engine, Auditing, and Connection Manager (or Exchange Manager from CONNECT 5.1 onwards ). These three components represent the security and communication layer for CONNECT. In the middle is the Orchestration component. This component contains the business logic on how each of the three components are used. Each message type component uses the orchestration component. These components are common in all services. The orchestration component is often extended to provide additional functionality specific to a service itself.

Figure 1 - Generic Component Overview Diagram shows that each specific service component has a dependency relationship with the Orchestration component. The Orchestration component also uses the Auditing, Policy Engine, and Connection Manager components

Figure 2 - Generic Message Component Diagram shows all required and provided interfaces  (TODO: UPDATE! No more message proxy)
An adopter is expected to develop the Adapter and Clients for use in their own deployment as these require specific knowledge of the adopter's system.

Every message type provides the same three interfaces: NwHIN, Entity Secured, and Entity. The NwHIN interface is to receive messages from another gateway. Secured Entity and Entity are outbound interfaces, which serves as an entry point for connecting the gateway to a  CONNECT client. All message types also require an AdapterProxy which represents the adapter for the message.

In Figure 2, the generic message component is called Message. It's AdapterProxy required interface is assembled with the Adapter Component. The provided NwHIN interface is assembled with an abstract Message Producer. The provided interfaces EntitySecured and Entity are assembled with a Secure Client and Client respectively.

Figure 3 – Generic Message Component Diagram shows the internal required interfaces
In addition to the external required and provided interfaces, each message component also has four required interfaces: AuditRepositoryProxy, ConnectionManager, PatientCorrelationProxy, and PolicyEngineProxy. These are the main components of the generic orchestration approach. The Audit Repository handles the auditing of messages. Connection Manager manages the information about the NwHIN system and UDDI. The Patient Correlation manages the relationship between the adopter's patient identifiers and other systems' patient identifiers. The Policy Engine handles the validation of the policy. Even though these are considered internal interfaces they can be exposed as WebServices.

Core Interface Catalog

The interface catalog table below, lists the interfaces that are involved in most CONNECT services. As with all interface catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 1 - Core Interface Catalog

Generic Orchestration

Overview

For each inbound and outbound message that is initiated to and from CONNECT, the same sequence of processing is followed: policy check, delegate, and then audit. The message orchestration standardizes how this is done within each message. And there are two levels of orchestration: a top level orchestration that happens in the Entity and NwHIN service layers, and a lower level orchestration within the initial delegation. The top level orchestration has the least amount of variance so a basic strategy is applied where the delegate is the only thing that differs; this orchestration happens within the web service server class. While the abstraction is created at this level to allow for differing approaches, at this time all messages are handled the same. The lower level orchestration is more complex and requires more coordination of classes as it is orchestration based on actual message content. Even though the specifics of orchestration require an understanding of the messaging content, a generic orchestration context is still used. The orchestration at the message content level is the focus of this section.

Details

Orchestration is done for both inbound and outbound processing. While distinct at a high level, they function the same way. The main difference is that for inbound the resulting action calls an adapter proxy, while the outbound calls a message proxy. For simplicity, we will avoid those distinctions for now. Each orchestration has a context. The context contains the strategy and the orchestratable object. The strategy holds the logic about what is done with each orchestratable. This includes when to audit and how to form a success or error message. The orchestratable is similar to a domain object, and the only logic that is contained within it is information about which version to use.

Inbound Orchestration

The communication diagram below describes the order in which each of the parts of the orchestration is called for an inbound message. CONNECTOrchestration represents the common functionality performed in the service endpoint interface (top level of orchestration) before passing off to the internal processing. After auditing and policy checking this request is delegated to orchestration via the orchestration context. And eventually the adapter proxy is called.

Figure 4 - Inbound Orchestration Communication Diagram expresses the process flow of generic inbound orchestrations
The use of the common functionality of the orchestrator is accomplished by each message implementing interfaces defined in the orchestration component. The diagram below describes a NHIN message, a generic inbound CONNECT message that could be Patient Discovery, Query for Documents, or any of the others. In addition to implementing the interfaces described by the orchestration component, the orchestrator must also wire together the Audit Repository, Policy Checker, and Adapter Proxy.
In the diagram below, the "CONNECT NHIN Message" component represents a generic message component but is focusing on the inbound (NwHIN) functionality. (See Generic Component section for a more complete view of all the components in a generic message.) The concept being illustrated in this diagram is that "CONNECT NHIN Message" contains a NHIN-focused component which provides functionality (by implementing interfaces) and expects other interfaces be implemented. This will be specific for implementations for each message. (See Class Diagram below for greater detail on how these classes are organized.)

Figure 5 - Inbound Orchestration Class Diagram shows the interfaces involved in inbound orchestration

Outbound Orchestration

Outbound is much the same as inbound. The major difference is the flow of processing for message aggregation or fan out. After the processing reaches the strategy, the message is delegated to the aggregator. Each outbound message is logged before the web service call is made.

Outbound Orchestration in Pass-Through mode is a little different then Fanout Outbound Orchestration. Please refer to Pass-Through vs Standard.

Figure 6 - Outbound Orchestration Communication Diagram expresses the process flow of generic outbound orchestrations
The use of the common functionality of the orchestrator for outbound messages is accomplished by each message implementing interfaces defined in the orchestration component. The diagram below is describing an Entity message, a generic outbound CONNECT message that could be Patient Discovery, Query for Documents, or any of the others. In addition to implementing the interfaces described by the orchestration component, an adopter must also wire together the Audit Repository, Policy Checker, and Message Proxy.

In the diagram below "CONNECT Entity Message" component represents a generic message component but is focusing on the outbound (Entity) functionality. (See the Generic Component section for a more complete view of all the components in a generic message.) The concept being illustrated in this diagram is that "CONNECT Entity Message" contains an Entity-focused component which provides functionality (by implementing interfaces) and expects other interfaces be implemented. This will be specific for implementations for each message. (See Class Diagram below for greater detail on how these classes are organized.)

Figure 7 – Outbound Orchestration Class Diagram shows the interfaces involved in outbound orchestration

Orchestration Class Diagram

The critical classes to message orchestration are: OrchestrationContext, Orchestratable, OrchestrationStategy, and Delegate. OrchestrationContext relates the interfaces Orchestratable and OrchestrationStategy. Using a context creates a separation between Orchestratable (messages to be orchestrated) and the OrchestrationStrategy (how they are orchestrated). A class that implements Orchestratable can be orchestrated with an OrchestrationStrategy. OrchestrationStrategy is a use of the strategy pattern to provide common functionality orchestrating the processing of a message. The final piece to this puzzle is the interface Delegate. Classes that implement the Delegate interface are destinations for the Orchestratable classes after being orchestrated.

Figure 8 – Orchestration Class Diagram demonstrates the relationships between classes involved in transmitting messages to and from the NwHIN

Generic Variability

Overview

Each of CONNECT's messages can be configured with either compile time configuration or deploy time configuration. The compile time configuration are either properties files or modification of spring configuration files. These configuration and properties files are then packaged with the deployable artifact. The deploy time configurations are not packaged with the deployable artifact but are placed in a configuration directory and override any configuration set with compile time configuration.

Pass-Through vs Standard

CONNECT has the ability to operate in two different modes, Pass-through and Standard. The difference being whether CONNECT manages the SAML headers. Each message can be configured to support pass-through or standard on each of its three provided interfaces; Secure Entity, Entity, and NwHIN. The configuration can be done at compile time or runtime. For compile time configuration each message has a properties file which specifies which orchestrator to use, Standard or PassThrough. This property file is included in the war for that message. For runtime configuration the adopter would modify the gateway.properties setting, the same property name that would be set in the compile time configuration. The setting of the gateway.properties overrides the setting for the compile time configuration.  

Figure 9 - Pass-Through Communication Diagram illustrates how components interact when CONNECT is used in "pass-through" mode

If the standard interface is used, the Entity Orchestration Component manages orchestration. However, the Message Proxy Component participates in the final interaction with the Nationwide Health Information Network to create the SAML assertion in the message.

Proxy Dependency Injection

CONNECT utilizes dependency injection for all proxy components, allowing implementers to control what service component implementation class is used. 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 Spring configuration for the component service to inject the associated service NoOpImpl class.

Service View – Direct

The Direct project specification is to support the scenario where a single person pushes data, commonly a document, to another individual in another organization securely. This functionality is provided within the existing health integration platform of CONNECT.
CONNECT provides support for the Direct project specification by using SMTP, S/MIME, and X.509 certificates to securely transport health information over the Internet. CONNECT identifies other participants in exchange using standard e-mail addresses associated with X.509 certificates. The data is packaged using standard MIME content types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME), and confirmation delivery is accomplished using encrypted and signed Message Disposition Notification. Certificate discovery of endpoints is accomplished through the use of the DNS and LDAP.
CONNECT supports the required elements of the specification: use of Domain Names, Addresses, and Associated Certificates, Signed and encrypted Internet Message Format documents, Message Disposition Notification, Trust Verification, and Certificate Discovery Through the DNS and LDAP.

Service View – Patient Discovery

In order to share patient data within and among organizations, and at times between HIEs and other connected organizations, and in the absence of a single national patient identifier, it is necessary to have mechanisms to match patient identities. The Patient Discovery service meets this need by providing the mechanism for locating patients at other Nationwide Health Information Network-enabled organizations based on demographic information. The service provides the ability for one organization to determine whether other systems have records for a given patient by submitting a set of demographic identifiers that systems can use to match against their own master patient indexes.
The transactions implemented by the Patient Discovery service are described in the documents listed below; see the Referenced Materials section for details and locations:

• IHE IT Infrastructure Technical Framework - Cross-Community Patient Discovery (XCPD) Supplemental Draft for Trial Implementations, dated 10 August 2010
• NwHIN Patient Discovery Web Service Interface Specifications, version 1.0 and version 2.0

A patient query is initiated from one HIE to another to determine whether that patient is known to it. This query includes the patient ID and demographic information about the patient as it is known to the sending HIE. The receiving HIE in turn searches its patient index for matches, using the demographic information sent to it and its own matching algorithms, criteria, and policy. If a match is found, and sharing that patient ID with the other HIE is allowed by policy and patient preferences, the receiving system sends its patient ID and the demographic information as it is known to that system back to the querying organization. Finally, the querying system compares the demographic information returned to it, using its matching algorithms, criteria, and policy, to determine whether it agrees with the match. Fundamental to the Patient Discovery service is that both systems must agree on a match for an exchange to proceed. Authorization assertion(s) are included in the query message as specified by the Authorization Framework specification.
When queried for a match, an HIE can return one of three responses. It can return a match with a patient ID and demographics, a message that there was an ambiguous match and request additional information that might result in a single matching patient, or no match. Returning no match might correspond to a failure to identify any matches or an ambiguous match to multiple patients when a more exact match cannot be expected. An HIE can only return multiple matches if they represent exact matches to multiple institutions within the HIE that are believed to represent a single patient.
This document does not describe the details of implementation of an MPI. Architectural decisions regarding the MPI, such as whether it is centralized or decentralized, are left up to the implementing HIE. At a minimum, it is assumed that whatever the implementation, the MPI can make a match based on a set of demographic data and return an identifier. CONNECT includes a reference implementation of an MPI that may be used by an organization utilizing CONNECT.

CONNECT also supports deferred processing for Patient Discovery. The processing is the same as synchronous, with the exception that the timing of the processing can be delayed after the initial request comes in. According to the Nationwide Health Information Network specifications, deferred processing introduces a new set of services on both the responding gateway and initiating gateway side. On the responding gateway, the service supports the receiving of a deferred Patient Discovery request message, and returns an application acknowledgment of the receipt of the message. At a later time, the responding gateway will process the request and send out the response on a waiting web service on the initiating gateway that is responsible for receiving these delayed responses. That service will send back an application acknowledgment that it has received the response. 

Patient Discovery Components and Orchestration

The Patient Discovery service uses all of the common CONNECT components and orchestrations that other services use.
A detailed discussion of common components can be found in the Generic Component section. In addition to the generic components of the CONNECT gateway, it is worthwhile to note that many CONNECT implementations would not include a Master Patient Index (MPI), which would be specific to Patient Discovery. There are many MPI products on the market, but for the purposes of this discussion, one can define the MPI as simply the data store for patient demographic and identity information. Since Patient Discovery is a query for patient identifiers based on demographics, the MPI component is also required in addition to generic components handling the typical CONNECT features (auditing, policy, etc). The MPI component would integrate to CONNECT via one of the Patient Discovery adapter interfaces.
A detailed discussion of generic orchestration can be found in the Generic Orchestration section. Similar to the relationship between Patient Discovery and the generic components, there is also an extension of generic orchestration specific to Patient Discovery. Patient Discovery (along with Document Query) implement the concept of "fan-out," meaning that a single request from the adapter to the CONNECT gateway can result in multiple messages sent to remote communities. CONNECT implements the fan-out feature in parallel using multi-threading. This divergence from generic orchestration only affects CONNECT as an initiating gateway in that there is additional logic within the Patient Discovery orchestration to perform this fan-out as well as to audit and policy check every message to each remote community.

Patient Discovery Interface Catalog

The interface catalog below lists the interfaces that are involved in the Patient Discovery service. As with all interface catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 2 - Patient Discovery Interface Catalog

For a number of the components, the interface catalog above lists two interfaces, in the form of two WSDLs. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for incoming messages, gateway interfaces for outgoing messages, and interfaces to replaceable components. Both the legacy "unsecured" interfaces and the new "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Patient Discovery Context

For incoming messages, an authorized user such as a provider or other authorized user, uses their Nationwide Health Information Network-enabled system to identify a patient for which health information is desired. That system invokes the Patient Discovery service in its Nationwide Health Information Network gateway, which in turn contacts other gateways on the exchange network. Patient Discovery requests contain patient ID and demographic information and request matching patients in remote systems based on the provided data. The CONNECT gateway and adapter logical components work together to process these requests, including checking policy and authorization of the remote user and responding with the patient ID and demographics of a matching patient if one is found. Returned results are again checked against policy to ensure that the preferences of the patient allow it. Upon receiving the response, the initial system evaluates the returned demographic information and declares a match if and only if it agrees that the demographics constitute a match. Please see the Patient Discovery variability guide for more information of the configuration of this agreement through "trust" and "verify" modes.
For outgoing messages, the user of the existing health system utilizing CONNECT likewise identifies one or more patients for query using his/her existing health system, which uses CONNECT to contact one or more gateways to request patient matches based on demographic information. Likewise, any responses are examined to ensure the returned demographic information constitutes a match.
Both interactions for incoming messages and outgoing messages must agree that the demographic information of the other system constitutes a match based on its own matching algorithms, criteria, and policies.
Patient Discovery allows for pass-through and message proxy modes as describe in the Generic Variability section.
Patient Discovery also provides the configuration of "trust" or "verify" modes. These modes can be configured in the gateway.properties file. These modes were introduced to help CONNECT adopters deal with the possibility of receiving false positive matches to patient demographic queries.

Verify Mode

Setting the CONNECT gateway to verify mode affects the way in which Patient Discovery responses are processed. When a response comes from a remote community, the gateway will parse the response for the patient demographics and will construct a query to the local MPI based on the received results. The gateway will then query the local MPI and compare the results of the local MPI to the remote community results in order to verify that the patients match. If the patients do match, the gateway will respond to the initiating adapter with the results from the remote community.

Trust Mode

Setting the CONNECT gateway to trust mode simply skips over the logic that was described in verify mode. A gateway in trust mode simply assumes that the response from the remote gateway is a correct patient match and does not do any verification to determine whether or not the remote community's match was a false positive.

Patient Discovery Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Patient Discovery is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes. It is also designed to support deferred processing of patient discovery.
Beginning with Release 2.3, Patient Discovery replaced the Subject Discovery service that was part of the Nationwide Health Information Network Trial Implementations and all previous releases of CONNECT. The Patient Discovery service outlines transactions that are more in line with current practice within HIEs and is therefore thought more appropriate for HIE-to-HIE interactions.

Service View - Patient Discovery Deferred

Patient Discovery supports deferred message processing where the responding gateway can respond to the request at a later time. Being capable of processing latent responses is the driving factor to implement the deferred messaging mechanism for Patient Discovery.
Potential use cases for latent responses are stated below:

• Responding gateway receives a query for a patient and begins to process the message. Some condition is realized around multiple matches and human intervention is required to resolve which matches should and should not get returned to the initiating gateway
• Responding gateway receives a query for a patient and processes the message. Results are discovered, but the responding gateway needs human intervention to analyze a non-machine readable authorization statement or document before returning the results

Patient Discovery Deferred Components

The Patient Discovery Deferred services uses all of the common CONNECT components and orchestrations that other services use.
A detailed discussion of common components can be found in Generic Component. Deferred processing contrasts to synchronous Patient Discovery in terms of the timing of the processing of the message. However, the components involved in processing the message are the same. Please see the Patient Discovery Components and Orchestration section for more details.
A detailed discussion of generic orchestration can be found in the Generic Orchestration section. As stated, deferred processing contrasts to synchronous Patient Discovery in terms of the timing of the processing of the message. However, the orchestration algorithms involved in processing the message are the same.

Patient Discovery Deferred Interface Catalog

The interface catalog below lists the interfaces that are used for the Patient Discovery Deferred service. As with all interface catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 3 - Patient Discovery Deferred Interface Catalog

The Patient Discovery Deferred transaction is nearly identical to the Patient Discovery transaction with the exception that this transaction supports deferred processing which means that it can now be delayed after the initial request comes in. According to the Nationwide Health Information Network specifications, deferred processing will introduce a new set of services on both the responding gateway and initiating gateway side. On the responding gateway the new service will support the receiving of a deferred patient discovery request message, and it will return an application acknowledgment of the receipt of the message. At a later time, the responding gateway will process the request and send out the response to a waiting web service on the initial initiating gateway. That service will send back an application acknowledgment that it has received the deferred response.

Patient Discovery Deferred Context

Please see the Patient Discovery Context section. Functionally, Patient Discovery serves the same purpose whether using synchronous or deferred messaging. However, operating in deferred mode allows for additional workflow options. For example, using deferred messaging a responding gateway could allow for a manual intervention and "eyes on" processing of a set of results before allowing a response to be sent to the requesting gateway. This scenario would not be possible in the case of synchronous messaging due to typical operational HTTP timeouts.

Patient Discovery Deferred Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Patient Discovery Deferred is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.

Service View - Patient Location Query

The Patient Location Query supports the ability for an Initiating Gateway to query the Responding Gateway for a list of communities which may have relevant health data about particular patients specified in the request.

Patient Location Query Interface Catalog

Patient Location Query Context

For incoming messages, an authorized user uses their Nationwide Health Information Network-enabled system to identify a patient for which they would request to know which communities may have information about said patient. That system invokes the Patient Location Query service in its Nationwide Health Information Network gateway, which in turn contacts other gateways on the exchange network. Patient Location Query requests contain patient ID and the assigning authority of the patient ID. 
For outgoing messages, the user of the existing health system utilizing CONNECT likewise identifies one or more patients for query using his/her existing health system. Any correlation matches should be returned in the response of the message
Patient Location Query is pass-through only.

Patient Location Query Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Patient Location Query is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.

Service View - Query for Documents

The Query for Documents service provides the mechanism by which one exchange partner locates electronic health information associated with a specific patient. The service allows one system to acquire a list of documents for a given patient that exists at another HIE or system, based on a set of search criteria. The service can be viewed as receiving incoming query requests, to which it must respond, and sending outgoing queries in order to locate a patient's health information.
The transactions implemented by the Query for Documents service are described in the documents listed below; see the Referenced Materials section for details and locations:

• IHE IT Infrastructure Technical Framework - Cross Gateway Query (XCA) Supplement Draft for Trial Implementations dated 15 August 2007
• NwHIN Query for Documents Web Service Interface Specification, versions 2.0 and 3.0

Note that the XCA specification has been relaxed within the Nationwide Health Information Network to support the query for, and retrieval of, dynamically generated document content.
A query is initiated from one system to another, requesting a list of available documents meeting a given set of query parameters for a particular patient for later retrieval. This query includes criteria such as a patient identifier, made available through the Patient Discovery service, as well as document metadata such as a date range, etc. Authorization assertion(s) are included in the query message as specified by the Authorization Framework specification.
The response to this query is a collection of document references referring to available documents and metadata describing each document. These references may be used in the Retrieve Documents service to access the data. The document list is returned if, and only if, the patient has been registered at one or more facilities in the HIE that is initiating the query via the Patient Discovery service, has provided consent to share data, and has had identity determined by both the initiating and responding HIEs. In this context, a "document" refers to the form of electronic health information as it is transferred between HIEs or systems, not as it is stored in an HIE or system.
CONNECT includes services to query an exchange partner(s) for documents and respond to a incoming query as well as a reference implementation of the document registry that contains the metadata against which received queries operate.
CONNECT includes services to query exchange partner(s) for documents and respond to a query as well as a reference implementation of the document registry that contains the metadata against which queries received from will operate.

Query for Documents Component and Orchestration

The Query for Documents service uses all of the common CONNECT components and orchestrations that other services use.
A detailed discussion of common components can be found in the Generic Component section. In addition to the generic components of the CONNECT gateway, Query for Documents includes a Patient Correlation component that queries and matches patient identifiers based on the given community id. This component translates the patient id from the local home community to the targeted community id and is performed before a request is sent out to the NwHIN to ensure that the responding gateway will process the correct patient. CONNECT integrates this Patient Correlation component using one of the adapter interfaces.
A detailed discussion of generic orchestration can be found in the Generic Orchestration section. Similar to the relationship between Document Query and the generic components, there is also an extension of generic orchestration specific to Document Query. Document Query implements the concept of "fan-out," meaning that a single request from the adapter to the CONNECT gateway will result in multiple messages to remote communities. CONNECT implements the fan-out feature in parallel using multi-threading. This divergence from generic orchestration only affects CONNECT as an initiating gateway, in that there is additional logic within the Document Query orchestration to perform this fan-out as well as to audit and policy check every message to each remote community.

Query for Documents Interface Catalog

The interface catalog below lists the interfaces that are involved in the Document Query service. As with all interface catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 4 - Query for Documents Interface Catalog

For a number of the components, the interface catalog lists two interfaces in the form of two WSDLs. When present, the first of the pair containing the "Secured" designation represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for incoming messages, gateway interfaces for outgoing messages, and interfaces to replaceable components. Both the "unsecured" interfaces and the "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Query for Documents Context

For incoming messages, an authorized user, such as a provider or other authorized user, uses their Nationwide Health Information Network-enabled system to identify a subject for which health information is desired. That system invokes the Query for Documents service in its Nationwide Health Information Network gateway, which in turn contacts other gateways on the exchange network. Query for Documents requests contain document identifiers for any documents that exist for the identified patient if that patient has agreed to share health information and the user is authorized to view them. The CONNECT gateway and adapter logical components work together to process these query requests, including checking policy, authorization of the remote user, and preferences of the patient, and respond with a list of document identifiers that match the query if they exist and access is allowed. That list of documents is then returned to the remote gateway and its associated health system.
For outgoing messages, the user of the existing health system utilizing CONNECT likewise identifies one or more patients for query using their existing health system, which uses CONNECT to contact one or more HIE gateways to request document identifiers for any documents that exist for the identified patient. Likewise the responses from possibly multiple gateways are returned to CONNECT, aggregated, and the resulting document list is presented to the user.
Although only one remote health system and gateway are illustrated in the context diagram, queries can be sent to multiple gateways on the exchange network.

Query for Documents Variability Guide

Query for Documents allows for pass-through and message proxy modes as described in the Generic Variability section.
Query for Documents also provides CONNECT adopters the ability to use their own patient correlation component using dependency injection. The gateway uses this component to correlate the patient id from the local home community to the targeted community id for all outbound requests. This configuration can be made by modifying the relevant references defined in the Spring proxy files.

Query for Documents Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Query for Documents is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.
A more complete discussion of the evolution of the CONNECT architecture is included in the Summary of Background Changes Reflected in Current Version section.
Patient Discovery is a prerequisite for the Query for Documents service. Query for Documents is a prerequisite for the Retrieve Documents service. There are no assumptions concerning the Query for Documents service.

Service View - Retrieve Documents

The Retrieve Documents service provides a mechanism to retrieve the electronic health information. It is used in conjunction with the Query for Documents service, which returns a list of document references that Retrieve Documents uses to retrieve patient records. The service can be viewed as receiving document requests to which it must respond, and sending outgoing requests in order to retrieve patient health information. Sequence diagrams are included for messages in each direction.
The transactions implemented by the Retrieve Documents service are described in the documents listed below; see the Referenced Materials section for details and locations:

• IHE IT Infrastructure Technical Framework - Cross Community Access (XCA) Supplement Draft for Trial Implementations dated 15 August 2007
• The use of this profile is included in HITSP TP13 Manage Sharing of Documents Transaction Package [HITSP TP13]
• The Nationwide Health Information Network Retrieve Documents Web Service Interface Specification v2.0 and v3.0

Through the Query for Documents service, an HIE may receive one or more references to documents for patient records that satisfied query parameters for a given patient. The Retrieve Documents service allows an HIE to use that list of references to request individual documents or sets from the list as a single action and allows the responder to securely return the document to the requester and audit the retrieval of the document.
In this context, a "document" refers to the form of electronic health information as it is transferred between HIEs, not as it is stored in an HIE. Any HIE may store health information in whatever format or repository it chooses so long as the HIE can respond to queries and retrieve document requests. Specifically, a document transferred between HIEs or systems need not meet the criteria for persistence, stewardship, etc., as identified by the HL7 Structured Documents committee. The primary expected use in the context of the Nationwide Health Information Network is that these documents are formatted as XML data following the HL7 Clinical Document Architecture standard, but nothing precludes this interface from being used to query for other kinds of documents.
HIEs or systems that generate documents dynamically on demand by aggregating data from multiple sources must ensure that the generated document remains available, unaltered, once a document has been retrieved once. Specifically:

• A document reference may "expire" after a Query for Documents request has been received and responded to if and only if no subsequent Retrieve Documents request has been received and responded to for that document
• For documents that have been shared with another HIE or system via a Retrieve Documents service, the document reference and the document itself must remain available for future Retrieve Documents requests

CONNECT includes services to retrieve documents and respond to requests for documents as well as a reference implementation of the document repository and a document cache that may be used for documents created dynamically on demand.
For incoming messages, an authorized user, such as a provider, uses his or her Nationwide Health Information Network-enabled system to identify documents from those previously returned by a Query for Documents request that are relevant to the patient encounter and for which they are authorized. That system invokes the Retrieve Documents service in its Nationwide Health Information Network gateway, which in turn contacts gateways that contain or provide access to those documents, including CONNECT, requesting the document or documents as attachments. The CONNECT gateway and adapter logical components work together to process the request, including checking policy, authorization of the initiator, and preferences of the patient, and respond with the documents as attachments, if they exist and access is allowed. Those documents are returned to the remote gateway and its associated health system, which may render the documents for viewing, incorporating the information in data repositories on the remote system or otherwise processing the information.
For outgoing messages, the user of the existing health system utilizing CONNECT likewise identifies one or more documents for retrieval, which uses CONNECT to contact HIE or entity gateways to request documents that exist on those respective systems. Likewise the responses from one or multiple gateways are aggregated by CONNECT and the result provided back to the existing health system where the documents may be rendered for viewing or the data incorporated into the existing system data repositories.
Note that retrieval requests can be sent to multiple gateways on the exchange network.

Retrieve Documents Components and Orchestration

The Retrieve Documents service uses all of the common CONNECT components and orchestrations that other services use.
A detailed discussion of common components can be found in the Generic Component section. The NHIN interfaces send these document requests to organizations based on document references of a given patient that exists within the system. These HIES or systems have their own repository and the Document Repository component which handles these requests queries for the existence of documents based on the references provided. The Document Repository component does a look-up in the document service of the HIE or system and responds to the initiator with the document itself, if it exists.
A detailed discussion of generic orchestration can be found in the Generic Orchestration section. The Document Request within Document Retrieve Request can have one or multiple document requests, and these requests are identified by the requesting gateway. The gateway sends these requests individually based on home community IDs. The responses from the remote communities are orchestrated in the Entity interface like any other service of CONNECT as described in in the Generic Orchestration section.

Retrieve Documents Interface Catalog

The interface catalog below lists the elements for the Retrieve Documents service. As with all element catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 5 - Retrieve Documents Interface Catalog

For a number of the components, the interface catalog lists two interfaces in the form of two WSDLs. When present, the first of the pair containing the "Secured" designation represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for messages from the NwHIN, gateway interfaces for messages to the NwHIN, and interfaces to replaceable components. Both the legacy "unsecured" interfaces and the new "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Retrieve Documents Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Retrieve Documents is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.
A more complete discussion of the evolution of the CONNECT architecture is included in the Summary of Background Changes Reflected in Current Version section.
Query for Documents is a prerequisite for the Retrieve Documents service. There are no assumptions concerning the Retrieve Documents service.

Service View - Document Submission

The Document Submission service provides a mechanism to send documents to another organization, unsolicited by a call to the Query for Documents service or other mechanism, and therefore implementing a "push" exchange pattern. The service can be viewed as submitting document(s) that must be processed or stored by the receiving system and sending document(s) including health information to exchange partners.
The transactions implemented by the Document Submission service are described in the documents listed below; see the Referenced Materials section for details and locations:

• IHE IT Infrastructure Technical Framework Supplement 2009-2010 - Cross-Enterprise Document Reliable Interchange (XDR) dated 10 August 2009 [IHE XDR]. As part of CONNECT 3.0, XDR now has support for deferred processing
• NwHIN Document Submission Emergence Pilot Specification v1.1.1 and Document Submission Production Specification v2.0

The Document Submission service provides the ability for one organization to "push" identified health information for a given patient from one system to another, triggered by events at the submitting organization. Document Submission provides a different model of exchange than the publish and subscribe model implemented by Health Information Event Messaging as the sending organization determines what organizations should receive the information and what information to send, and the receiving organization receives that information on appropriate and available endpoints from sources it authorizes.
The Document Submission service allows a system to send an individual document or sets of documents to other organizations and allows the responder to receive the submission, audit the submission, and process the document as appropriate. In this context, a "document" refers to the form of electronic health information as it is transferred between systems, not as it is stored in an HIE or system. Any HIE or system may store health information in whatever format or repository it chooses.
Document Submission normally requires that the patient ID of the receiving organization be known, and therefore the Document Submission service may be used in conjunction with the Patient Discovery service to retrieve the patient ID of matching patients.
CONNECT includes services to receive documents in response to requests and to submit documents to other organizations.

Document Submission Components and Orchestration

The Document Submission service uses all of the common CONNECT components and orchestrations that other services use. See the Generic Component section and the Generic Orchestration section for details.

Document Submission Interface Catalog

The interface catalog below lists the elements that are included in the component diagram and sequence diagrams for the Document Submission service. As with all element catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 6 - Document Submission Interface Catalog

The Message Proxy Document Submission Component is appropriately listed in the element catalog above. Referencing the Generic Component and Generic Orchestration sections, when CONNECT is not acting in pass-through mode, the interactions for outgoing messages appear as illustrated in the sequence diagram, except that the interaction between the Entity Orchestration Component and the exchange network (remote gateway) is actually handled by the Message Proxy Component, properly addressing the SAML security layer, and not the Entity Orchestration Component directly. The interaction was simplified by removing the Message Proxy Component from the sequence diagram to reduce the complexity of the illustrations.
See the Generic Variability section's description of pass-through mode for a generic illustration of the Message Proxy Component.
For a number of the components, the element catalog above lists two interfaces, in the form of two WSDLs. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for incoming messages, gateway interfaces for outgoing messages, and interfaces to replaceable components. Both the "unsecured" interfaces and the "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Document Submission Context

For incoming messages, a Nationwide Health Information Network-enabled system under control of an authorized user, such as a provider, identifies and sends one or more documents to a receiving system without a previous request for that information. The sending system invokes the Document Submission service in its Nationwide Health Information Network gateway, which in turn contacts other gateways that are identified as recipients of the document(s), including CONNECT. The CONNECT gateway and adapter logical components work together to process submitted documents, including checking policy, authorization of the user, and patient identity and preferences of the patient, and process the submitted document if it conforms to policy. The receiving system may render the document(s) for viewing or more likely incorporate the information in data repositories on the remote system or otherwise process the information.
For outgoing messages, the existing health system utilizing CONNECT likewise identifies one or more documents for submission, which uses CONNECT to contact gateways that serve the recipients of the document(s). Likewise, the recipients of possibly multiple gateways receive and process the document(s) as appropriate.

Figure 10 – Context Diagram describes actors, components, and interactions to support Document Submission
Note that to aid with context, the interaction that establishes the identity of a patient on the remote system is using Patient Discovery. Strictly speaking, that interaction is part of the Patient Discovery service and not the Document Submission service. It is illustrated here for completeness as the Document Submission service requires that the patient ID in the receiving system be known and that identity may be obtained using Patient Discovery or some other method.
Also note that the actor, a provider or other user, is explicitly illustrated in the context diagram. This illustrates how the user might be involved in identifying health information to be submitted to another system, which might include the result of a referral or other medical documentation. The system might also initiate the submission of health information automatically as a result of normal work flow without the action of a user.
Although only a provider system and gateway are illustrated in the context diagram, a number of different system types may be using Document Submission to exchange health information, such as lab information systems, diagnostic imaging center systems, etc.

Document Submission Variability Guide

Document Submission allows for pass-through and message proxy modes as describe in the Generic Variability section.

Document Submission Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Document Submission is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.
Patient Discovery may be a prerequisite for the Document Submission service as the service normally requires that the patient ID within the receiving organization be known. Patient Discovery is not a prerequisite if some other method for obtaining the patient ID is available, such as a previous order. There are no assumptions concerning the Document Submission service.

Service View - Document Submission Deferred

The Document Submission services, both deferred and synchronous, allow a gateway to push a document to another gateway without being solicited for the document. See the Document Submission service description for more details. As with synchronous Document Submission, both versions 1.1 and 2.0 of the Nationwide Health Information Network Document Submission specifications are supported.
The Document Submission Deferred messaging is a set of two request and acknowledgement message pairs. The first pair of messages begins the Document Source sending a ProvideAndRegisterDocumentSet-b request, and a RequestAccepted message typically returns from the Document Recipient. The second pair of messages initiate on an entirely new http session and begin with a ProvideAndRegisterDocumentSet-bResponse, which is responded to with a ResponseAccepted message. This messaging pattern is conceptually a split of the synchronous Document Submission in which the two messages from the synchronous implementation are each sent in their own http session and each are followed by an acknowledgement. The deferred request and response are supported by their own services that are separate from each other and from synchronous Document Submission.

Document Submission Deferred Components and Orchestration

The Document Submission service uses all of the common CONNECT components and orchestrations that other services use. See the Generic Component section and the Generic Orchestration section for details.

Document Submission Deferred Interface Catalog

The interface catalog below lists the elements that are used for the Document Submission Deferred service. As with all element catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 7 - Document Submission Interface Catalog

The Document Submission Deferred transaction is nearly identical to the Document Submission transaction with the exception that this transaction supports deferred processing which means that the processing of a Document Submission request can now be delayed. According to the Nationwide Health Information Network specifications, deferred processing will introduce a new set of services on both the responding gateway and initiating gateway side. On the responding gateway the new service will support the receiving of a deferred document submission request message, and it will return an application acknowledgment of the receipt of the message. At a later time, the responding gateway will process the request and send out the response on a waiting web service on the initiating gateway that is responsible for receiving these delayed responses. That service will send back an application acknowledgment that it has received the response.
See Document Submission Interface Catalog notes for other details that also apply to Document Submission Deferred.

Document Submission Deferred Context

See the Document Submission Context section for a complete description.

Document Submission Deferred Variability Guide

As stated, Document Submission Deferred is a change in the timing of the processing of a Document Submission message. All information stated in the Document Submission (synchronous) Variability Guide still applies. Please see the the Document Submission Variability Guide for more details.

Document Submission Deferred Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Document Submission Deferred is implemented as a set of services using reusable components within the gateway and adapter. As outlined in the Variability Guide, it was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.
A more complete discussion of the evolution of the CONNECT architecture is included in the Summary of Background Changes Reflected in Current Version section.

Service View - Core X12 Document Submission (RealTime)

The CORE X12 Document Submission service provides a mechanism to exchange ASC X12 Administrative Transactions between one or more organizations via the Internet using the Phase II CAQH CORE Connectivity Rule web services over SOAP envelope. This service uses a different payload ie., ASC X12 payloads and model of exchange compared to IHE XDR payload based Document Submission transaction. The sender decides to whom the data should go and the receiver receives data on an appropriate available endpoint from the sources it authorizes. This service implements both a synchronous (aka Real Time) and a Deferred (aka Generic Batch mode) to support the use cases.

The transactions implemented by the CORE X12 Document Submission service are described in the documents listed below; see the Referenced Materials section for details and locations:

1. CAQH CORE X12 Document Submission Service Interface Specification v 1.0 March 2012

Core X12 Document Submission Components and Orchestration

The Core X12 Document Submission service uses all of the common CONNECT components and orchestrations that other services use. See the Generic Component section and the Generic Orchestration section for details.

Core X12 Document Submission Interface Catalog

The interface catalog below lists the elements that are included in the component diagram and sequence diagrams for the Core X12 Document Submission service. As with all element catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture. Currently Core X12 Document Submission services are supported only on Pass-Through mode.

Table 8 - Core X12 Document Submission Interface Catalog

See the Generic Variability section's description of pass-through mode for a generic illustration of the Message Proxy Component. For a number of the components, the element catalog above lists two interfaces, in the form of two WSDLs. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for incoming messages, gateway interfaces for outgoing messages, and interfaces to replaceable components. Both the "unsecured" interfaces and the "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Core X12 Document Submission Context

For incoming messages, a Nationwide Health Information Network-enabled system under control of an authorized user, such as a provider, identifies and sends payload(multiple documents as a single payload) to a receiving system without a previous request for that information. The sending system invokes the Core X12 Document Submission service in its Nationwide Health Information Network gateway, which in turn contacts other gateways that are identified as recipients of the document(s), including CONNECT. The CONNECT gateway and adapter logical components work together to process submitted documents. The receiving system may render the document(s) for viewing or more likely incorporate the information in data repositories on the remote system or otherwise process the information. Currently for outgoing messages, the existing health system utilizing CONNECT likewise identifies one or more documents for submission, which uses CONNECT to contact gateways that serve the recipients of the document(s). Likewise, the recipients of possibly multiple gateways receive and process the document(s) as appropriate.

Core X12 Document Submission Variability Guide

Currently Core X12 Document Submission is supported only for pass-through mode as describe in the Generic Variability section.

Core X12 Document Submission Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Core X12 Document Submission is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization for gateway Pass-Through mode.

Service View - Core X12 Document Submission Deferred (Generic Batch)

Core X12 Document Submission Deferred Components and Orchestration

The Core X12 Document Submission service uses all of the common CONNECT components and orchestrations that other services use. See the Generic Component section and the Generic Orchestration section for details.

Core X12 Document Submission Deferred Interface Catalog

The interface catalog below lists the elements that are included in the component diagram and sequence diagrams for the CORE X12 Document Submission service. As with all element catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.

Table 9 - Core X12 Document Submission Deferred Interface Catalog

See the Generic Variability section's description of pass-through mode for a generic illustration of the Message Proxy Component. For a number of the components, the element catalog above lists two interfaces, in the form of two WSDLs. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for incoming messages, gateway interfaces for outgoing messages, and interfaces to replaceable components. Both the "unsecured" interfaces and the "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Core X12 Document Submission Deferred Context

See the Core X12 Document Submission Context section for a complete description.

Core X12 Document Submission Deferred Variability Guide

As stated, Core X12 Document Submission Deferred is a change in the timing of the processing of a Core X12 Document Submission message. All information stated in the Core X12 Document Submission (synchronous) Variability Guide still applies. Please see the the Core X12 Document Submission Variability Guide for more details.

Core X12 Document Submission Deferred Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Core X12 Document Submission Deferred is implemented as a set of services using reusable components within the gateway and adapter. As outlined in the Variability Guide, it was designed to support both coarse-grained and fine-grained customization for gateway Pass-Through mode.

A more complete discussion of the evolution of the CONNECT architecture is included in the Summary of Background Changes Reflected in Current Version section.

Service View - Document Data Submission

The Document Data Submission (DDS) service provides a mechanism to send document metadata information to a target organization without the target organization having to run a Query for Document request on the source organization. This allows organizations to push document metadata, without the document binaries, towards other organizations without having to query for the entire document.

Document Data Submission Interface Catalog

Document Data Submission Context

For incoming messages, a Nationwide Health Information Network-enabled system under control of an authorized user identifies and sends request (multiple documents' metadata for a given patient in a single request) to a receiving system. The sending system invokes the Document Data Submission service in its Nationwide Health Information Network gateway, which in turn contacts the recipient gateways of the documents' metadata. The CONNECT gateway and adapter logical components then process the submitted document metadata and store the metadata via the adapter. 

Document Data Submission Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Document Data Submission is implemented as a set of services using reusable components within the gateway and adapter. As outlined in the Variability Guide, it was designed to support both coarse-grained and fine-grained customization for gateway pass-through mode.

Service View - Administrative Distribution

The NwHIN Administrative Distribution Web Service is intended to provide a mechanism for NHIOs to exchange non-patient specific data using a "push" mechanism. The Administrative Distribution transaction will be initiated by one gateway, referred to as the "Initiating Gateway," and will send an AD message to another gateway, referred to as the "Receiving Gateway." The Receiving Gateway will then process the request. The Administrative Distribution transaction is a one way transaction, meaning there is no application-level response. 
The AD message, also called the Send Alert Message Request, is a collection of metadata and documents or structured XML data transferred between a Message Sender and a Message Receiver. This request contains:

1. One EDXLDistribution metadata element
2. Zero or more contentObjects
3. Zero or more nonXMLContent or XMLContent objects (a child of contentObjects)

The transactions implemented by the Administrative Distribution service are described in the documents listed below; see the Referenced Materials section for details and locations:

• HITSP Emergency Message Distribution Element transaction, dated 8 July 2009
• OASIS Emergency Data Exchange Language Distribution Element (OASIS EDXL-DE), v 1.0, which defines the metadata included in each message, dated 1 May 2006
• NwHIN Administrative Distribution Service Interface Specifications v1.0 and v2.0; see v2.0, section 3.4 for further constraints placed on the elements, dated 17 May 2011

As part of the payload, the Send Alert Message Request supports the ability to include multiple documents in a single request.
The specification allows for the same alert to be sent to multiple agencies. This is accomplished by adding a NhinTargetCommunities element to the Entity Administrative Distribution interface. See the Generic Orchestration section for further information on fan-out.
Administrative Distribution is constrained to the SOAP1.2/HTTP transport. OASIS EDXL-DE does not define a response; therefore, no aggregation is required and this specification defers to the underlying HTTP specification. A successful response will be an HTTP 200.

Administrative Distribution Components and Orchestration

The Administrative Distribution service uses all of the common CONNECT components and orchestrations that other services use.
A detailed discussion of common components can be found in the Generic Component section.
A detailed discussion of generic orchestration can be found in the Generic Orchestration section. Through the entity interface, Administrative Distribution uses a "fan-out" implementation to send the alert message to multiple targets. The entity interface utilizes the message proxy interface where the outbound request will be audited for each target endpoint. As noted, Administrative Distribution is a one-way transaction; therefore, this transaction varies slightly from the provided diagrams. First, there will not be additional audit logging on the response message, and second, there will be no aggregator for the response.

Administrative Distribution Interface Catalog

The interface catalog below lists the interfaces that are involved in the Administrative Distribution service. As with all interface catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 10 - Administrative Distribution Interface Catalog

For a number of the components, the interface catalog lists two interfaces in the form of two WSDLs. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions. The components with two interfaces represent the adapter interfaces for incoming messages, gateway interfaces for outgoing messages, and interfaces to replaceable components. Both the legacy "unsecured" interfaces and the new "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Administrative Distribution Context

Messages received on the NwHIN Exchange Administrative Distribution interface are processed by the CONNECT gateway and then handed off to the adapter interface for CONNECT adopter-specific processing. Messages sent out via the NwHIN Exchange AD interface are targeted to remote systems using the TargetSystems element. The EDXL payload is not patient specific, meaning there is no metadata element which requires a single specific patient id. This flexibility makes AD the ideal choice for pushing aggregate patient or administrative data. The CONNECT gateway and adapter logical components work together to process the requests, including checking policy, authorization of the user, and auditing the transactions.

Administrative Distribution Variability Guide

Administrative Distribution allows for pass-through and message proxy modes as described in the Generic Variability section.

Administrative Distribution Architectural Background

As with all core Nationwide Health Information Network services implemented by CONNECT, Administrative Distribution is implemented as a set of services using reusable components within the gateway and adapter. It was designed to support both coarse-grained and fine-grained customization through component replacement or through bypassing of standard CONNECT orchestration processes.
A more complete discussion of the evolution of the CONNECT architecture is included in the Summary of Background Changes Reflected in Current Version section.

Service View - Health Information Event Messaging

The Health Information Event Messaging, or HIEM, refers to the Nationwide Health Information Network specification for Nationwide Health Information Network-enabled systems to initiate subscriptions for information with other Nationwide Health Information Network-enabld systems and subsequently to deliver notifications when data matching subscription criteria is available.

HIEM is not supported in CONNECT 4.x+. Reference older Software Architecture Documents for details. 

Service View - Web Services Registry

Prior To CONNECT 5.1 

The Web Services Registry interface specification provides for registry servers that enable Nationwide Health Information Network-enabled health organizations to discover the existence and connection information for other Nationwide Health Information Network-enabled health organizations, utilizing UDDI.
This service includes the following components and interfaces:
The internal UDDI Update Manager core gateway component is used to periodically pull the connection information from a Nationwide Health Information Network UDDI server and to cache that information locally within the gateway. The information is stored in uddiConnectionInfo.xml. The periodicity is configurable and set within a properties file. Since the component does a periodic pull, there is no need for a web service interface. However, a component has been created that provides a mechanism for forcing a pull from the UDDI server. The interface for this component is described by the NhincComponentUDDIUpdateManager WSDL.
The internal UDDI Update Manager core gateway component also provides the capability to filter query results based on a state, service, and/or home community id.
The CONNECT web services registry implementation is a reference implementation for the NwHIN Web Services Registry Specification, versions 2.0 and 3.0. See the Referenced Materials section for details and locations.

CONNECT 5.1

With CONNECT 5.1, Web Services Registry component has changed drastically. CONNECT is, now, capable of pulling connection information for other Nationwide Health Information Network-enabled health organizations using FHIR Directory and UDDI.  The FHIR Directory is based on  HL7 FHIR(STU3)  specifications.

The Web Service Registry comprises of following components:

1. Exchange Scheduler
2. Transformer

The Exchange Scheduler periodically pulls information from both the UDDI Web Services Registry and FHIR Directory. This  is configurable through exchangeInfo.xml. User, inaddition to pull interval, can also enable/disable an exchange in order to stop pulling connection information. 

In order to be scalabale and easily incorporate future Web Service sources, transformers were introducecd that take in UDDI and FHIR Directory data and convert it into CONNECT specific schema. This  transformed data is then used through out CONNECT.

Enterprise Service Component - Audit Log

As of CONNECT 4.6, the Audit Log functionality is redesigned to implement IHE ATNA logging profile, details of which can be found /wiki/spaces/CONNECTWIKI/pages/8585256. The Audit Log functionality is comprised of three separate components: AsyncEJB, AuditTransformers,  and AuditRepository. The complete auditing functionality, including transformation and storage, is done by AsyncEJB employing asynchronous mechanism that does audit logging in the background without effecting the actual request processing. All CONNECT messages, except AD, presented to the AuditTransformers are translated into ATNA compliant audit log messages. These audit messages are then sent to AuditRepository service which stores the audit messages in database and/or file. The Audit Log functionality can be turned on/off for each service. This is configured through audit.properties file. For a comprehensive Audit logging design, please refer to /wiki/spaces/CONNECTWIKI/pages/8585256.

Audit Log Component and Communication Diagrams

The component diagram below illustrates the general design of the Audit Log.

Figure 11 – The Audit Log Component Diagram illustrates the components involved in audit logging

The sequence diagram below illustrates the Audit Log Store operation that implements the generic service for CONNECT gateway and adapter components to create entries in the Audit Repository. 

Figure 12 – Sequence Diagram demonstrates flow of interactions in audit logging

Audit Log Interface Catalog

The interface catalog below lists the elements that comprise the Audit Log. As with all element catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 11 - Audit Log Interface Catalog

While the Audit interface is not included in the component diagram or the sequence diagram, it is included in the interface catalog for reference purposes. As described above, the Audit component acts as a generic surrogate for the Audit Log Enterprise Service Component in all of the component diagrams and sequence diagrams elsewhere in this document.
The interface catalog above lists two interfaces, in the form of two WSDLs, for some components. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions associated with replaceable components. Both the "unsecured" interfaces and the "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Audit Log Variability Guide

See also the Generic Variability section.

Audit logging is redesigned to configure auditing on/off for each service. Additionally, audit logging  can be configured to log either in database or file or both. This configuration option is available through the audit properties file.

Also the Audit Repository, a significant component of the Audit Log, is a replaceable component. Repositories other than the one provided as part of this release of CONNECT can be substituted as long as the replacement implements the required NhincComponentAuditRepository WSDL interface.

Audit Log Architectural Background

Unlike other Enterprise Service Components that are part of CONNECT, the Audit Log does not make use of any significant enterprise-class open source software component except for the relational database provided by MySQL. Instead, its functionality was found to be simple enough to develop using other tools already part of the CONNECT gateway and adapter framework--WildFly, MySQL, etc. As a result, the Audit Log is implemented as a set of services, reusing some components within the gateway and adapter that were created to support the core NwHIN.

Enterprise Service Component – Policy Engine

The Policy Engine service is responsible for determining whether any message, either inbound or outbound, should be processed by CONNECT, allowing for uniform access policy application at the organizational level. Policies may be patient specific (e.g., based on the patient's consent for a specific information exchange) or organization specific (e.g., based on hours of operation, user role, etc.).
The component diagram illustrates the various components that comprise the Policy Engine. The implementation of the Policy Engine follows the model outlined by the extensible access control markup language (XACML), which defines the key services and their responsibilities. The Policy Enforcement Point (PEP) is responsible for orchestrating processing of messages to the Policy Engine. The PEP makes calls to the Policy Information Point (PIP) to retrieve any data that it needs to format the XACML request message based on the OASIS Cross-enterprise Security and Privacy Authorization (XSPA) profile [OASIS 2008, see Reference Materials]. Once the PEP formats the request message with the appropriate data, it makes a secure call (using SAML) to the Policy Decision Point (PDP) for a decision as to whether the operation should be allowed, i.e., whether the message should be processed as requested. The PDP takes the request, applies a set of rules, also defined using XACML, and returns a response. Within the response is a decision that could contain one of four values: Permit, Deny, Indeterminate, and Not Applicable. It may also contain a number of Obligations to which the PEP would be required to conform; however, CONNECT currently ignores the obligations section. If the PDP returns a decision of Permit, then the message will be processed by the CONNECT gateway and adapter. If the decision is Deny, Indeterminate, or Not Applicable, the message will not be processed.
As an adjunct to the Policy Engine, the Consumer Preferences Profile GUI provides a web application included with CONNECT that allows patient access and redaction information to be stored by accessing the PIP, if the Spring configuration is first changed in the AdapterPIPConfig.xml file to provide a PIP-accessing implementation class. Information is formatted according to the IHE Basic Patient Privacy Consents (BPPC) profile specification and stored in the document repository within the CONNECT gateway. Allowed data elements include patient consent-specific items that have been defined in the XSPA profile. See the Nationwide Health Information Network Access Consent Policies Specification v1.0 dated 29 January 2010 for more information on patient consent [ONC 2010-8], the Cross-Enterprise Security and Privacy Authorization (XSPA) Profile for more information on the XSPA profile [OASIS 2008], and the IHE IT Infrastructure Technical Framework Supplement 2007-2008 Basic Patient Privacy Consents (BPPC) draft for Trial Implementation dated August 15, 2007, for more information on BPPC [IHE BPPC].
In addition to the Consumer Preferences Profile GUI, CONNECT also provides a Redaction Engine that can be used with the Query For Documents and Retrieve Documents Services. Based on consumer preferences, patients may decide not to share certain documents. The Redaction Engine resides on the adapter service bus and is called by the adapter software. This application will modify Document Query and Document Retrieve response messages to remove documents that should not be shared based on a consumer preference profile for a patient.
The Policy Engine implements a greater level of granularity than just the opt-in/opt-out options supported in early releases of CONNECT. Detailed patient consent specifications are persisted in the document repository and may be used more completely in determining access policy in future releases of CONNECT that may make use of a more fine-grained patient consent capability.

Policy Engine Component and Sequence Diagrams

The component diagrams below illustrates the various components that comprise the Policy Engine.

Figure 13 – Component Diagram of the policy engine enterprise service component describes how components interact around policy engine activities

Figure 14 – Component Diagram for the redaction engine orchestration expresses the components used to operate redactions in Document Query

Figure 15 – Component Diagram for the redaction engine orchestration expresses the components used to operate redactions in Retrieve Documents

The sequence diagrams below illustrate the interactions when a message is received and is processed by the CONNECT gateway and adapter and when a message is sent from the CONNECT adapter.

Figure 16 – Sequence Diagram shows how CONNECT uses the policy engine component to process incoming messages

Figure 17 – Sequence diagram shows how CONNECT uses the policy engine component to process messages to be sent

Figure 18 – Sequence Diagram shows how Document Query messages are processed by the redaction engine

Figure 19 – Sequence Diagram shows how Retrieve Documents messages are processed by the redaction engine

Within the sequence diagrams, individual services that make up the Nationwide Health Information Network Orchestration Components, Entity Orchestration Components, Core Components, and Message Proxy Components are represented as single lifelines to simplify the diagram. Each grouped lifeline could represent any of the individual components that participate in the corresponding architectural layer.
The following sequence diagram interactions are used by the Consumer Preferences Profile GUI tool to manage the persistence of patient consent information within the document repository.

Figure 20 – Sequence Diagram demonstrates how patient consent is managed by the policy engine component

Policy Engine Interface Catalog

The interface catalog below lists the elements that comprise the Policy Engine. As with all interface catalogs in this document, the interfaces included in this table are limited to those that are public or that are part of customizable or replaceable components in the architecture.
Table 12 - Policy Engine Interface Catalog

Within the interface catalog above, Nationwide Health Information Network Orchestration Components, Entity Orchestration Components, Message Proxy Components, and Core Components represent the corresponding families of components present within the CONNECT gateway and adapter used in the processing of messages. The Adapter Policy service is the primary service used by the gateway and adapter to access the Policy Engine, accessing it through the AdapterPolicyEngine WSDL interface.
The interface catalog above lists two interfaces, in the form of two WSDLs, for some components. When present, the first of the pair, containing the "Secured" designation, represents the secured service interface that utilizes TLS for encrypted transport and SAML authorization assertions associated with replaceable components. Both the "unsecured" interfaces and the "secured" interfaces are supported. For simplicity, the component diagram lists only the legacy WSDLs by name.

Policy Engine Variability Guide

CONNECT no longer uses OpenSSO as the client bridge between the PEP and the PDP. A new component interface has been created that enables each site to customize the call to the PDP. Sites no longer need to set up OpenSSO along with the circle of trust information to integrate a different PDP. 
The Policy Engine is a replaceable component. The implementation included in this release of CONNECT can be replaced with an alternative implementation as long as the interface conforms to the AdapterPolicyEngine WSDL.
A Redaction Engine component has been added to support the Document Query and Document Retrieve Services. This component is a replaceable component. The implementation included in this release of CONNECT can be replaced with an alternative implementation as long as the interface conforms to the AdapterComponentRedactionEngine WSDL.

Policy Engine Architectural Background

An interim CONNECT Policy Engine implementation established the interfaces between the CONNECT gateway and adapter and provided an implementation that verified patient opt-in/opt-out consent before allowing a message to be processed. However, the interim solution was very specific to the messages being processed and did not make use of a generalized policy engine.
Later, a generalized Policy Engine was introduced although the interfaces used by the CONNECT gateway and adapter remained as previously implemented. However, the adapter now takes that message, transforms it into an XACML message that is based on the OASIS Cross-enterprise Security and Privacy Authorization (XSPA) profile, adds in any additional necessary data, and sends it to a generalized policy engine for processing.
A more fine-grained processing of the patient consent directives, beyond the simple opt-in/opt-out processing supported previously, was introduced. This more fine-grained approach will continue in future releases.
A Redaction Engine was added for the Document Query and Document Retrieve Services in order to remove documents from the response messages for these services based on a consumer preference profile.
The OpenSSO client was removed. It is no longer used to bridge between the PEP and the PDP. Now organizations wishing to implement their own PDP will override the PDP component interface.

Adapter Interfaces

The "adapter" represents the software used by an organization to communicate bi-directionally with the CONNECT gateway by abstracting an organization's existing system. It must implement a specific set of interfaces defined by CONNECT and documented in this section. These interfaces are used by the CONNECT gateway to send messages to the adapter and to receive responses back from it. A CONNECT adopter can create any implementation underneath the interface that is required, a reference implementation is provided that may be used as a basis for implementation. There are two levels of adapter interfaces in CONNECT. First there are the adapter interfaces, which integrate directly into the CONNECT gateway. Secondly there are the adapter components, also known as Enterprise Service Components, which integrate with the CONNECT adapter implementations. CONNECT provides reference adapter implementations for both sets of interfaces.
The CONNECT adapter interfaces include:

• The Patient Discovery adapter interface is responsible for servicing the patient discovery requests from the gateway in pass-through mode. The CONNECT adopter is responsible for implementing this interface only if the adopter will respond to patient discovery messages from the NwHIN. The Patient Discovery service provides for both the synchronous and deferred methods of messaging. The interface is described by the AdapterPatientDiscovery WSDL for synchronous messaging and the AdapterPatientDiscoveryAsyncReq and AdapterPatientDiscoveryAsyncResp WSDLs for deferred messaging
• The Patient Location Query adapter is responsible for looking up any correlations for the requested patient's identifier and returning any communities that may have healtcare information on the requested patient.  The interface is described by the AdapterPatientLocationQuery and AdapterPatientLocationQuerySecured WSDLs.
• The MPI adapter interface is provided by the adapter to enable the gateway to retrieve patient demographic information from the master patient index. This interface is used when orchestrating Patient Discovery messages. The interface is described by the AdapterMPI WSDL
• The Query for Document adapter interface is responsible for servicing document query requests from the gateway. This interface is used both for pass-through as well as normal processing, and the CONNECT adopters must implement this adapter interface if the adopter wishes to share health information using the Query for Document specification. The interface is described by the AdapterDocQuery WSDL
• The Retrieve Document adapter interface is responsible for servicing document retrieve requests from the gateway. This interface is used both for pass-through as well as normal processing, and the CONNECT adopters must implement this adapter interface if the adopter wishes to share health information using the Retrieve Document specification. The interface is described by the AdapterDocRetrieve WSDL
• The Policy adapter interface provides the gateway the ability to check policies before orchestrating an incoming message. This interface is based on XACML 2.0 and is described by the AdapterPolicyEngine WSDL
• The Subscription Management adapter interface is responsible for servicing subscription management requests from the gateway. This interface is used both for pass-through as well as normal processing, and the adapter must implement this interface if the existing health system will provide patient health information based on the HIEM specification. The interface for this component is described by the AdapterSubscriptionManagement WSDL
• The Notification Processing adapter interface is responsible for servicing notification requests from the gateway. This interface is used both for pass-through as well as normal processing, and the adapter must implement this interface if the existing health system will provide patient health information based on the HIEM specification. The interface for this component is described by the AdapterNotificationConsumer WSDL
• The Document Submission adapter interface is responsible for servicing Document Submission Requests from the gateway. This interface is used both for pass-through mode as well as normal processing. The CONNECT adopters must implement this adapter interface if the adopter wishes to share health information using the Document Submission specification. The Document Submission service supports both the synchronous and deferred methods of messaging. The interface is described by the AdapterComponentXDR WSDL for synchronous messaging. The interface is described by the AdapterXDRRequest and AdapterXDRResponse WSDLs for deferred messaging
• The Document Data Submission adapter is responsible for processing requests to store document metadata into the document registry.The interface is described by the AdapterDDS and AdapterDDSSecured WSDLs.
• The Core X12 Document Submission adapter is responsible for servicing Core X12 Realtime/Batch Document Submission Requests from the gateway. This interface is used only for pass-through mode. The CONNECT adopters must implement this adapter interface if the adopter wishes to share health information using the CAQH Core X12 Document Submission specification. The Core X12 Document Submission service supports both the synchronous (Realtime) and deferred (batch) methods of messaging. The interface is described by the AdapterCORERule2.2.0RealTime WSDL for synchronous (Realtime) messaging and the AdapterCORERule2.2.0GenericBatch WSDL for deferred (Batch) messaging

The adapter components highlighted below represent a set of components that are most likely to be extended or replaced by CONNECT adopters. Previously mentioned reference implementations allow CONNECT to run "out-of-the-box" but still be flexible to an adopter's needs. To customize an adapter service component for the particular needs of an existing health information system, an organization can either replace or update the component with a custom solution that implements the same interface.
The CONNECT adapter component interfaces include:

• The Document Repository adapter component is responsible for handling document repository messages. The web service interface is based on XDS.b and is described by the AdapterComponentDocRepository WSDL
• The Document Registry adapter component is responsible for handling document registry messages. The web service interface is based on XDS.b and is described by the AdapterComponentDocRegistry WSDL
• The MPI adapter service bus component represents the implementation of an organization's MPI. This is the interface that will be used by the adapter service bus to communicate to the MPI. To customize the MPI, an organization should wrap an existing MPI with an implementation of this interface. This interface is based on HL7v3 and the interface is described by the AdapterComponentMpi WSDL
• The Policy Engine adapter component represents the implementation of an organization's policy and redaction engine. This is the interface that will be used by the adapter service bus to communicate with the policy and redaction engine. To customize the policy and redaction engine, an organization should wrap an existing policy and redaction engine with an implementation of this interface. The interface for this component is described by the AdapterPolicyEngine WSDL. In addition, the CONNECT reference adapter for the policy engine interface contains multiple other interfaces. Please see the Policy Engine enterprise service view for more information
• The Subscription Repository adapter component is used to store subscription information in the adapter. For the most part, it is the same component as the subscription repository component within the gateway core components. It has a separate WSDL so that both can be deployed on the same server. The interface for this component is described by the AdapterComponentSubscriptionRepository WSDL