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: