n-
ti
fied in context through
boldface
. Illustrations are provided for clarity, although these are si
m-
plifications of the actual message exchanges.

When the VA and HIE agree to participate in the NHIN, they develop or acquire systems that are
able to communicate

using
web

services (
Messaging Platform
). For the VA, this might be an
instance of CONNECT that is interfaced to its existing healthcare systems. Both organizations
sign data use and reciprocal support agreements with the governing body for the NHIN and ar
e
accredited as conforming to the NHIN standards. As a result, they receive digital certificates that
attest to their identity and their right to participate in the NHIN (
Messaging Platform
). These
certificates serve as the technical basis of trust between

NHIN participants, since they were i
s-
sued by a certification authority that all participants trust. Later on, these certificates will be used
to sign and encrypt all communications between the VA and the HIE, now an NHIE.

Like any organization joining the

NHIN, the VA and NHIE must both publish their identities and
the list of NHIN services they will provide. This information is stored as a catalog in an NHIN
service registry (
NHIN Service Registry
). They can now discover the existence of each other, as
we
ll as the set of the NHIN services each offers. They can likewise now know how to invoke the
services of the other. The VA and NHIE are now ready to exchange health information with each
other, and with other NHIN participants.

The clinic staff at the spec
ialty clinic may request a summary of care document from VA for the
patient to better inform care. The summary of care provides a synopsis of important medical i
n-
formation, including demographic data, diagnoses, procedures, allergies, medications, and othe
r
information. In order to receive any health information for the patient, the NHIE must perform
three primary steps:

1.

Match the patient’s identity with VA;


CONNECT Release 2.2

Page
20

Document Version 2.2

2.

Determine what relevant health documents exist within VA for the patient; and

3.

Request (and receive)
specific health documents for the patient as required.

For all of these communications, messages between the NHIE and the VA’s CONNECT gateway
are encrypted to prevent interception, and are digitally signed to identify the source of the info
r-
mation and pre
vent either party from later repudiating their actions
(Messaging Platform)
.

When the patient registers with the specialty clinic, he/she provides a set of demographic info
r-
mation, including full name, date of birth, address, phone numbers, and so on. The
clinic uses its
NHIE gateway to request identity matches based on this information from other NHIEs, inclu
d-
ing the VA (
Subject Discovery
). In making this request, the clinic asserts that it is entitled to
request information on behalf of the patient (
Autho
rization Framework
). This assertion is e
m-
bedded in the request the clinic transmits to the other NHIEs. Having accepted the assertion, the
VA CONNECT gateway searches the VA patient index to determine whether any patient matc
h-
es the demographic information

the clinic provided. The VA determines that there is a unique
match (
Subject Discovery)
. The gateway then consults the profile associated with the patient’s
identity to determine whether he/she has consented to the sharing of health information with ot
h-
er

NHIEs (
Consumer Preference Profile
). If the patient has permitted information sharing, the
VA sends back to the clinic the patient ID used by VA systems (
Subject Discovery)
.

Now that the clinic has obtained a VA patient identification, the clinic uses thi
s ID via the NHIE
to ask the VA to provide a list of health documents for the patient that may be relevant for the
consult (
Query for Documents)
. In doing so, the clinic can narrow its request for documents to,
for example, a specific date range of dates,
etc. The VA CONNECT gateway searches its internal
document registry to locate documents that match the provided search criteria and returns a list
of the documents, with VA document IDs for each document in the list. If the clinic queried ot
h-
er NHIEs for d
ocuments in addition to VA, their documents would be aggregated by the NHIE
into a single list (
Query for Documents)
.

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

While the preceding descriptions have focused on the interactions between

providers and NHIEs
to exchange information, it cannot be forgotten that these activities are performed on behalf of a
particular patient who plays an important role in the NHIN.

First, and most importantly, in most circumstances the sharing of patient in
formation can only
occur with the patient’s explicit consent. To support this, each NHIE must establish a profile for
patients that articulate with whom they elect to share their personally identifiable health info
r-

CONNECT Release 2.2

Page
21

Document Version 2.2

mation
(Consumer Preferences Profile)
. NH
IEs can share these profiles with each other to e
n-
sure consumer preferences are honored.

Finally, the patient is entitled to determine who has requested his/her health information, and
with whom it has been shared. To facilitate this, NHIEs are required to

maintain a log of activity
associated with the exchange of patient health information and make this accessible to the co
n-
sumer (
Audit Log Query)
.

Importantly, the NHIN initiative includes the development of a set of data and technical stan
d-
ards and intero
perability specifications as the foundation for interoperability between systems.
The Healthcare Information Technology Standards Panel was charged by ONC with

harmoni
z-
ing and integrating standards that will meet clinical and business needs for sharing inf
ormation
among organizations and systems
, consistent with the core NHIN services and supporting the use
cases
.

The work products of the HITSP are published as a set of Interoperability Specifications,
Transactions, Transaction Packages, Components, and Tec
hnical Notes. These materials are d
e-
veloped by HITSP technical committees, and reviewed and released by the HITSP for impleme
n-
tation. They are also presented to the Secretary of the Department of Health and Human Services
(HHS). Standards recognized by the

Secretary of HHS must be used in Federal health info
r-
mation systems.

The NHIN Trial Implementations and Limited Production phases, as well as other ongoing
NHIN activities including the CONNECT development project, act to inform HITSP on the sui
t-
ability o
f its interoperability specifications when reduced to practice. These activities also esta
b-
lish additional standards, most notably the NHIN Messaging Framework and NHIE Service I
n-
terface Specifications, which go beyond the activities of HITSP. CONNECT must

therefore co
n-
form to these additional standards developed during the Trial Implementations as well.

More information on the HITSP and a complete and up
-
to
-
date set of Interoperability Specific
a-
tions, Transactions, Transaction Packages, Components, and Tec
hnical Notes can be found at
http://www.hitsp.org
.

2.2

Solution Background

CONTENTS OF THIS SECTION
: The sub
-
parts of this section provide a description of why the archite
c-
ture is the way that it is, and a convincing argume
nt that the architecture is the right one to satisfy the b
e-
havioral and quality attribute goals levied upon it.

2.2.1

System Overview

CONTENTS OF THIS SECTION
: This section describes the general function and purpose for the system
or subsystem whose architecture

is described in this
document
.

The CONNECT architecture establishes a gateway between existing health information systems
and the NHIN. It supports the standards
-
based core NHIN services and interoperability specific
a-
tions that are a requirement to
becoming an accredited NHIN participant (i.e., an NHIN health
information exchange).


CONNECT Release 2.2

Page
22

Document Version 2.2

To date, ten core NHIN services have been defined as listed in
Table
2
-
1
, although

others may
emerge in the future. While they are not formally grouped into categories at this time, it may be
helpful to think of them in three categories: infrastructure, information exchange, and consumer
services, as illustrated in
Figure
2
-
1
.


Figure
2
-
1

Conceptual grouping of core NHIN services into groups of infrastru
c-
ture services, exchange services, and consumer s
ervices.

The CONNECT solution implement
s

all of these services using
web

services described by
WSDLs and schemas referenced in the elements catalog accompanying each view later in this
document
.

Further, the architecture provides components that can, and i
n most cases should, be
used as
-
is out
-
of
-
the
-
box, components that can be replaced with customized solutions by the o
r-
ganization implementing CONNECT, and components that can be changed and/or replaced to
meet the needs of an organization or the existing s
ystems they wish to support.

At a technical level
,

the architecture is most easily understood if broken down logically into two
sections: a gateway and an adapter. The CONNECT gateway comprises the services and comp
o-
nents necessary to connect the existing
health information
system
(
s
)

of an organization to the
NHIN. Gateway services provide mechanisms for receiving messages from the NHIN and pas
s-
ing them to the adapter, as well as for receiving messages from the adapter and sending them to
the NHIN. In addit
ion to supporting the core NHIN services, components in the gateway also
provide services to manage NHIN connection endpoint URL data, patient correlation, and a var
i-
ety of other
supporting
services. The CONNECT adapter comprises the software that interfac
es
the existing health information system of an organization to the
CONNECT
gateway.

CONNECT implements
a set

of standard
a
pplication
p
rogram
ming interfaces
,

or APIs, in the
form

of these

web services.
This API view of CONNECT is illustrated in
Figure
2
-
2
.
For inter
-
organizational exchanges

over the NHIN,

the API comprises

the
core NHIN
services and co
n-
tent,
specified

by the

NHIN service interface specificat
ions and conventions
. This API is
often
referred to as
gateway’s externally
-
facing API. All NHIEs and other NHIN
-
enabled systems
communicate and exchange information with each other using this API.

Consumer
Preferences Profile
Query Audit Log
Subject
Discovery
Retrieve
Documents
Query for
Documents
NHIE Services
Registry
Authorization
Framework
Messaging Platform
Health Information
Event Messaging
Authorized Case
Follow
-
up
Consumer
Services
Information
Exchange Services
Infrastructure
Services

CONNECT Release 2.2

Page
23

Document Version 2.2

To facilitate creating
an adapter, CONNEC
T defines an
other

API
, also based on web services,

to
be used to communicate with
the existing health information system that will use the CONNECT
gateway to communicate with other system on the NHIN. Where possible, this API approximates

the externally
-
facing

API used by
the
gateway



i.e., the NHIN specifications and conventions
.


Figure
2
-
2

Application programming interfaces implemented by CONNECT to en
a-
ble communication with other systems on the NHIN and with existing
health information systems that will utilize the CONNECT gateway.

Within
Figure
2
-
2
, the externally
-
facing gateway API maps to the core NHIN services and su
p-
porting conventions. Patient location is
implemented

by the Subject Discovery service, locating
and retrieving health documents by Query for Documents and Retrieve Documents services,
pu
b
lish and subscribe by the Health Information Event Messaging service,

and retrieving discl
o-
sure history by Query Audit Log service. The exchange of patient privacy preferences is ma
n-
aged through the Health Information Event Messaging service using the Consumer Preferences
Profile
,

and discovery of health systems and service
s on the NHIN through
the NHIE Service
Registry.

For the most part, the components and services in the CONNECT gateway are intended to be
used as
-
is without any modification. The CONNECT adapter comprises the services that are
most likely to be changed by
an implementing organization. In order to provide a solution that
Adapter
Your Health Organization
Future
Services

Terminology Mapping

Document Viewers

Clinical Decision Support

Other
Patient
Identity
Health
Data
Exchange
Decision
Disclosure
History
Locate
Patient
Locate
Health Documents
Retrieve
Health Documents
Publish / Subscribe
to Data Feed
Retrieve
Disclosure History
Exchange Patient
Privacy Preferences
Locate
Patient
Locate
Health Documents
Retrieve
Health Documents
Publish / Subscribe
to Data Feed
Retrieve
Disclosure History
Exchange Patient
Privacy Preferences
Locate Health
Systems / Services
Locate Health
Systems / Services
Proprietary
API
Proprietary
API
Proprietary
API
Proprietary
API
NHIN
Conventions
Other Health
Organizations
CONNECT Gateway
Health
Information
Audit Log
Exchange
Policy
Person
Index
Your Existing Health
Information System
External NHIN API
Internal CONNECT API
Internal “proprietary” API

CONNECT Release 2.2

Page
24

Document Version 2.2

works out
-
of
-
the
-
box, reference implementations of CONNECT adapter services are included in
the adapter. An organization may use the reference implementations directly as
-
is, or replace one
or more of them with their own custom implementations. They may also use the reference i
m-
plementations as a starting point for creating their own custom solutions.

In general, each component in CONNECT is implemented as a deployed web service. Gateway
serv
ices that comprise the externally
-
facing API conform to the NHIN specifications. The se
r-
vices that manage the interaction between the gateway

and the adapter
conform to NHIN specif
i-
cations as well. Web services at the individual component layer inside the
gateway or the adapter
are exposed internally only, and may use separate, simplified formats. Although these interfaces
are defined for the reference implementation in the adapter, they are not static and can be
changed by the implementing organization.

Figure
2
-
3

illustrates a high
-
level view of the CONNECT architecture for messages received
from the NHIN. This illustration includes the separation between gateway and
adapter, and ide
n-
tifies the components most likely to be customized or replaced by an implementing organization.


Figure
2
-
3

High
-
level view of the CONNECT release
2.0
a
rchitecture
for a m
essage
received
fro
m
the
NHIN
.

The architecture for messages to the NHIN is significantly different than from the NHIN, as i
l-
lustrated in
Figure
2
-
4
.

Subject
Discovery
MPI
Query for
Documents
Retrieve
Documents
Policy
Subscription
Management
Notification
Processing
Audit
Reporting
Subject
Discovery
Query for
Documents
Retrieve
Documents
UDDI Update
Management
Subscription
Management
Notification
Processing
Audit
Reporting
NHIN
CONNECT Components
Customizable Components
Replaceable Components
CONNECT Adapter
Adapter Service Bus
Document
Repository
SDK Services
Data
Transforms
Terminology
Services
Others
Others
Document
Registry
MPI
Policy Engine
Subscription
Repository
Re
-
Identification
Adapter Service Bus
CONNECT Gateway
NHIN Orchestration Components
CONNECT Core Components
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
UDDI Update
Management
Patient
Correlation
Repository
Audit
Repository
Document
Cache
Connection
Manager
Subscription
Repository
Others
Others

CONNECT Release 2.2

Page
25

Document Version 2.2


Figure
2
-
4

High
-
level view of the CONNECT release 2.0 architecture for a message
sent to the NHIN.

When sending messages to the NHIN, the existing health information systems of the organiz
a-
tion implementing CONNECT are responsible for initiat
ing the interaction. Therefore, the nu
m-
ber of reference components in the adapter is much smaller, and it is more difficult to identify
commonality across the various organizations that may implement CONNECT, be they Federal
agencies or private
-
sector orga
nizations. However, the handling and orchestration of the message
is primarily the responsibility of the CONNECT gateway. Once a message is generated and
passed to the gateway for processing, the services are common for most implementations.

For outgoing m
essages, the interfaces between the adapter and gateway are as close as possible
to those used by the NHIN. In many cases, the interface is identical
. As of Release

2.2 of CO
N-
NECT, all interfaces between the adapter and gateway, and all interfaces to
replaceable comp
o-
nents within the gateway
support a

Security Assertion Markup Language (SAML) assertion
wit
h
in NHIN messages

and message encryption using t
ransport
l
ayer
s
ecurity (TLS)
.

Table
2
-
2

lists the elements defined in both the CONNECT gateway and adapter, for both the
view for messages from the NHIN and the messages to NHIN, as they are illustrated in
Figure
2
-
3

and
Figure
2
-
4
.

CONNECT Adapter
Entity Integration Software
CONNECT Gateway
Message Proxy Components
CONNECT Core Components
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
Patient
Correlation
Repository
Audit
Repository
Document
Cache
Subscription
Repository
UDDI Update
Management
Others
Others
SDK Services
Data
Transforms
Terminology
Services
Others
Others
Patient
Correlation
Subject
Discovery
Query for
Documents
Retrieve
Documents
Notification
Processing
Audit
Reporting
Notification
Processing
Pass
Through
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
NHIN
CONNECT Components
Customizable Components
Replaceable Components
Entity Orchestration Components
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
Connection
Manager

CONNECT Release 2.2

Page
26

Document Version 2.2

Table
2
-
2

Elements included in the high
-
level views of the CONNEC
T release
2.0 architecture.

Element

Description

CONNECT
Gateway

An encapsulation of services that represent the CONNECT core gateway.

Orchestration
Components

An encapsulation of services that receive messages from the NHIN and orche
s-
trate the processing

of those messages.

Message Proxy
Components

An encapsulation of
services

that send messages to the NHIN. The encapsulated
version of each component take
s

an NHIN message prepared by orchestration
components in the gateway or prepared by the adapter in pa
ss
-
through mode,
along with authorization information, and prepare the SAML assertion and pr
o-
cess the message on the NHIN.

Secure Service
Proxy
Components

Not shown in the architecture diagrams and so named to support security between
components
implemented on separate machines, an encapsulation of services that
receive messages bi
-
directionally between the gateway and adapter or to replac
e-
able components that utilize SAML assertions, and translate authorization info
r-
mation to the assertion class
used by other components.

Audit Reporting

The audit reporting service responsible for orchestrating the processing of audit
reporting messages as part of the Query Audit Log core service.

Document Query

The service responsible for orchestrating and proce
ssing a document query, as
part of the Query for Documents core service.

Document
Retrieve

The service responsible for orchestrating and processing the retrieval of patient
documents, as part of the Retrieve Documents core service.

Notification
Processin
g

The service responsible for orchestrating and processing notification processing
messages.

Subject
Discovery

The service responsible for orchestrating and processing subject discovery, as
part of the Subject Discovery core service.

Subscription
Management

A service responsible for orchestrating and processing subscription management
messages.

Core
Components

An encapsulation of components that are core to the CONNECT gateway. Most
of these services are integral to the gateway and are used with o
rchestrating r
e-
ceived messages.


CONNECT Release 2.2

Page
27

Document Version 2.2

Element

Description

Audit Repository

A repository used to store audit information. The reference implementation uses
MySQL, but may be replaced by an organization.

Connection
Manager

A service that manages connections to services on other NHI
Es, as well as the
URL for some of the services within the gateway. It combines both UDDI
-
configured service endpoint information as well as internally
-
defined service
endpoint information.

Document Cache

A document cache provided by the gateway to enhanc
e performance or provide a
data store for documents assembled in real time by the adapter, but which must
be stored for audit reasons. The reference implementation can be replaced by the
implementing organization.

Patient
Correlation
Repository

A reposito
ry used to manage the correlation of patient IDs from the implementing
organization and other NHIEs. The reference implementation can be replaced by
the implementing organization.

Subscription
Repository

A service that manages, stores, and retrieves
subscription information persisted
within the gateway.

UDDI Update
Manager

A component that receives updates from the NHIN UDDI server and updates l
o-
cally
-
cached service endpoint URL information, and also provides a UDDI data
pull mechanism that retrieves

the UDDI connection information from the UDDI
server.

Entity
Orchestration
Components

An encapsulation that contains the components which receive messages from the
adapter and orchestrate the sending of that message to the NHIN.

CONNECT
adapter

An encap
sulation of the software that must be implemented by an organization to
connect the gateway to existing health systems, receiving information from the
NHIN and initiating message to the NHIN.

Adapter Service
Bus

An enterprise service bus that manages adap
ter services. The adapter can be cu
s-
tomized by replacing adapter components, or by modifying the service bus itself.

Document
Registry

A document registry that manages and stores the metadata associated with patient
documents, plugged into the adapter ser
vice bus using the XDS.b interfaces. The
open
-
source reference implementation in the adapter may be replaced by the i
m-
plementing organization.


CONNECT Release 2.2

Page
28

Document Version 2.2

Element

Description

Document
Repository

A document repository that manages and stores patient documents, plugged into
the adapter se
rvice bus using XDS.b interfaces. The open
-
source reference i
m-
plementation may be replaced by the implementing organization.

Master Patient
Index (MPI)

An index that manages and stores patient demographic information for the orga
n-
ization. The open
-
source
reference implementation may be replaced by the i
m-
plementing organization.

Policy Engine

An engine used to manage policies regarding access to patient information for the
implementing organization. The open
-
source reference implementation may be
replaced
by the implementing organization.

Subscription
Manager

A repository that manages and stores subscriptions within the adapter. The open
-
source reference implementation may be replaced by the implementing organiz
a-
tion.

SDK Services

An encapsulation of a se
t of services that are provided as reference implement
a-
tions in the CONENCT adapter, but may be replaced by the implementing orga
n-
ization.

Data Transforms

A set of transformation services provided as part of the adapter SDK to perform
data structure conve
rsions necessary for communication with the CONNECT
gateway.

Terminology
Services

A set of terminology services provided as part of the adapter SDK to perform
terminology mediation. Terminology Services are not included in this release, but
are included i
n this depiction for completeness, and will be included in a future
release of CONNECT.

Organization
Integration
Software

The software than an organization create to initiate message to the NHIN, likely
to be substantially different for each organization
and existing health system.


The CONNECT gateway also supports two mechanisms for bypassing the built
-
in orchestrated
processing of messages normally performed by the gateway.

For messages to the NHIN, the gateway supports a pass
-
through mechanism.
Interfaces to some
internal components in the gateway

that would normally only be exposed internally, identified in
Figure
2
-
4

as “proxy components”, are exposed exte
rnally instead. These components can ther
e-
fore be accessed directly by an adapter that wishes to send a message to the NHIN, but manage
orchestration itself. In this case, the proxy components simply take the assertion passed through

CONNECT Release 2.2

Page
29

Document Version 2.2

the pass
-
through inter
face and convert it to a SAML assertion

if necessary
, and pass the message
on to the NHIN.

For messages from the NHIN, the gateway also supports a mechanism for bypassing orchestr
a-
tion. The gateway message orchestration components comprise a set of process
es responsible for
accepting messages from the NHIN and processing them, usually by invoking a series of CO
N-
NECT gateway service components or adapter services. They are identified in
Figure
2
-
3

as o
r-
chestration components. These components may also be configured to work in pass
-
through
mode, where they take the message along with the SAML information and pass
them

directly to
the adapter without orchestration. To implement this mode, a set of internal components work
together. The first is a message receiver, which implements the public NHIN WSDL interface
and is responsible for handling the orchestration of the co
mponent. The message may then be
processed in two ways. The normal mechanism is through gateway orchestration, in which case
the message receiver calls the appropriate orchestration components to accomplish processing of
the message. When pass
-
through mode

is used, the gatew
ay simply receives the message
and
passes the message directly to the adapter for processing.
Figure
2
-
5

illustrates this simple pr
o-
cess. Once the m
essage receiver is configured to operate in standard or pass
-
through mode, it is
responsible for calling the appropriate component to provide orchestration.


Figure
2
-
5

NHIN message orchestration component d
etail, illustrating how pass
-
through mode is managed by a message receiver.

These two mechanisms taken together allow an adapter to completely override any orchestration
within the gateway, replacing it with a process more suited to the organization’s exis
ting systems
or organizational policies.

2.2.2

Architectural Approaches

CONTENTS OF THIS SECTION
: This section provides a rationale for the major design decisions embo
d-
ied by the software architecture. It describes any design approaches applied to the software a
rchitecture,
including

the use of architectural styles or design patterns, when the scope of those approaches tran
s-
cends any single architectural view. The section also provides a rationale for the selection of those a
p-
proaches. It also describes any signi
ficant alternatives that were seriously considered and why they were
ultimately rejected. The section describes any relevant COTS issues, including any associated trade stu
d-
ies.

CONNECT implements all of core NHIN services as
w
eb
s
ervice interfaces describ
ed by the
WSDLs and schemas referenced in Section

4
,
Referenced Materials
. This approach enables the
web services to be replaced by custom solutions by the acquiring organization. It also enables the
Internal NHIN
Message Orchestrator
NHIN Message
Receiver
Adapter Interface
Pass
-
Through
Choice of path
based on configuration.

CONNECT Release 2.2

Page
30

Document Version 2.2

flexibility of hosting implementations on different hardware or operating system platforms, as
well as creating t
he implementations in different programming languages.

CONNECT uses at its heart an enterprise service bus (ESB) approach to provide an abstraction
layer on top of an enterprise messaging system. This allows developers an easy mechanism to
exploit the valu
e of the messaging system. The foundation of an ESB approach lends itself well
to organization around the set of core NHIN services which comprise the base functionality of
the solution, broken up into their constituent parts with distributed deployment if

needed, and
working in harmony as necessary. While the ESB does not itself necessarily implement a se
r-
vice
-
oriented architecture (SOA), it provides the features with which one may be implemented.
The CONNECT project chooses to use the ESB to implement an
SOA comprised of
w
eb se
r-
vices.

Based on the requirements for the system, and on discussions with
Federal Partners

in the Fede
r-
al NHIN Consortium, this release of CONNECT was implemented using the stack for develo
p-
ment and deployment listed in
Table
2
-
3
.

Future releases of CONNECT may support additional
or alternative platforms for deployment, such as additional database systems, alternative applic
a-
tion serv
ices, and/or alternative operating systems.

Table
2
-
3

Software components and platforms selected for implementing the
CONNECT archtiecture and included in this release of CONNECT.

Software
Component

Development
Platform

Comments

Integrated
Development
Environment

NetBeans

6.5.1

NetBeans offers a comprehensive and well integrated Java
IDE with deep support for SOA and ESB development,
including visual designers. NetBeans 6 also include int
e-
grated UML
modeling with round trip engineering and
direct support for popular version control system such as
CVS and Subversion.

Application
Server

GlassFish
Enterprise
Server

2.1

Glass
F
ish is an open
-
source Java EE server that provides
robust support for the EE
platform, and integrates with
NetBeans and OpenESB. Sun Java System Application
Server is the commercially
-
supported version of the pro
d-
uct.

Enterprise
Service Bus

OpenESB

OpenESB is Sun's implementation of the Java Business
Integration (JBI)/JSR208 speci
fication. OpenESB is su
p-
ported by a large community that has developed a wide
variety of service engines and binding components to
popular protocols, including HL7 messaging (V2.x).


CONNECT Release 2.2

Page
31

Document Version 2.2

Software
Component

Development
Platform

Comments

Relational
Database
Management
System

MySQL

Community

5.
1

MySQL Community

Edition is a freely downloadable ve
r-
sion of a popular open
-
source database that is supported
by an active open
-
source community. MySQL Enterprise
Server is the commercially
-
supported version provided
Sun Microsystems.

Deployment
Operating
System

Windows

XP

SP2

Solaris

10

Linux

Windows

XP is the primary development platform, but
deployment is tested on Solaris

10 (on Sparc hardware
only) and Linux as well.

Community
Portal

Confluence
Enterprise Wiki

Confluence is a simple but powerful wiki that allows
com
munity members to create and share pages, doc
u-
ments, and rich content.


Several CONNECT components can be exchanged by users for alternative components of their
own choosing


components that are already implemented in their existing environments or with
which they have significant familiarity


as described in Section

2.2.1
,
System Overview
. Add
i-
tionally, some functionality that CONNECT provides can be bypassed allowing users to take on
the responsibility for that functionality themselves.

Therefore, CONNECT provides a flexible
platform for connecting to the NHIN to lower the bar for participating information exchange
with other NHIN participants.

2.2.3

Analysis Results

CONTENTS OF THIS SECTION
: This section describes the results of any quantitative or qualitative ana
l-
yses that have be
en performed that provide evidence that the software architecture is fit for purpose. If an
Architecture Tradeoff Analysis Method evaluation has been performed, it is included in the analysis se
c-
tions of its final report. This section refers to the results

of any other relevant trade studies, quantitative
modeling, or other analysis results.

FHA anticipates conducting an independent software architecture evaluation using the Archite
c-
ture Tradeoff Analysis Method
SM

(ATAM
SM
), organized and completed by the So
ftware Eng
i-
neering Institute that developed that methodology.
1

That evaluation has not yet been completed.
Its results will be included in a future release of this
document
.




1

The Architecture Tradeoff Analysis Method and ATAM are service marked by the Software
Engineering Institute.


CONNECT Release 2.2

Page
32

Document Version 2.2

2.2.4

Requirements Coverage

CONTENTS OF THIS SECTION
: This section describes the require
ments (original or derived) addressed
by the software architecture, with a short statement about where in the architecture each requirement is
addressed.

CONNECT has been developed using an agile software methodology driven by a backlog of d
e-
tailed require
ments that are developed, reviewed, and prioritized in small, rapid cycles concu
r-
rent with ongoing development. As a result, no formal requirements document, consistent with
more traditional waterfall software lifecycle methodologies, exists. A complete an
alysis of the
full requirements for CONNECT is beyond the scope of
documentation included in
this release
,

but will likely be incorporated in the next release.

However, as discussed in Section

2.1.2
,
Significant Driving Requirements
, an analysis of the core
capability requirements of the NHIN and the use cases re
commended by the AHIC led to the d
e-
velopment of a set of core NHIN services, listed in
Table
2
-
1
. These core services and interface
specifications make up the primary

high
-
level requirements of CONNECT.

The CONNECT architecture implements all of the core NHIN services: Subject Discovery, Qu
e-
ry for Documents, Retrieve Documents, Query Audit Log, Authorization Framework, Consumer
Preferences Profile, and Authorized Case
Follow
-
up. Section

3
,
Architecture Views
, is organized
using these services as views, and illustrates in detail how the architecture addresses each of
these service requirements. Likewise, the CONNECT architecture implements all of
the core
NHIN interface specifications: Messag
ing

Platform, Health Information Event Messaging, and
NHIE Service Registry. Taken together, these services provide:



ability to match patients to their data without a national patient identifier;



ability to fin
d and retrieve healthcare information within and between health information
exchanges and other organizations;



ability to deliver a summarized patient record to support patient care and to support the
patient’s health;



ability to support consumer preferenc
es regarding the exchange of his or her information,
including the ability to choose not to participate; and



support secure information exchange.

As listed in Section

2.1.2
, these are the key information exchange requirements of the NHIN that
are supported by CONNECT. In addition, the CONNECT architecture and the services it pr
o-
vides support the harmonized standards developed by the HITSP.

A key to success of the NHI
N is technical support for a common trust agreement that establishes
the obligations and assurances to which all NHIN participants agree. While the agreement itself
is outside the scope of any technical architecture, the CONNECT architecture supports it by

i
n-
corporating a certificate
-
based security structure that provides not only for encryption and non
-

CONNECT Release 2.2

Page
33

Document Version 2.2

repudiation, but a mechanism by which NHIE can be assured that an organization is accredited
as properly implementing the NHIN standards for information exc
hange, including protection of
patient privacy and implementation of patient profiles to enforce their restrictions on the e
x-
change of personal health information.

2.2.5

Summary of Background Changes Reflected in Current Version

CONTENTS OF THIS SECTION
: For versions of the
architecture

after the original release, this section
summarizes the actions, decisions, decision drivers, analysis and trade study results that became dec
i-
sion drivers, requirements changes that became decision drivers, and how these

decisions have caused
the architecture to evolve or change.

The architecture illustrated in Section

2.2.1
,
System Overview
, represents the second major rev
i-
sion of the CONNECT architecture (i.e., Release 2.0 described by this
document
). CONNECT
progressed through a set of initial architectures during early develo
pment, culminating in the 1.0
architecture that was demonstrated as part of the NHIN Trial Implementations. With the exper
i-
ence gained during the Trial Implementations, it became more apparent which services would be
used out
-
of
-
the
-
box and which component
s were most likely to be customized or replaced by an
organization implementing CONNECT.

The experience also prompted discussions regarding the need for flexibility at a coarse
-
grained
or fine
-
grained level. At a coarse
-
grained level, an organization may d
esire to take on the role of
full orchestration of the NHIN message. Used in this manner, CONNECT would simply be the
glue that connects the organization to the NHIN. Responsibility of processing the message would
be in the hands of the organization. At a
fine
-
grained level, an organization may want a default
way of orchestrating the message where only specific components are replaced. For example, an
organization may have its own

master patient index

and may want to use it.

In order to meet both of these n
eeds, it was determined that a clear separation needed to be crea
t-
ed between the CONNECT gateway and CONNECT adapter software. Components and services
in the gateway would represent the core components that would not change from implementation
to implement
ation, as well as a small set of components that unlikely to change, but could be r
e-
placed in some instances if necessary. Components and services in the adapter are more likely to
be changed from implementation to implementation.
Figure
2
-
3

and
Figure
2
-
4

illustrate this
separation between gateway and adapter, as well as the compon
ents most likely to be customized
or replaced in each.

In the CONNECT implementation for the Trial Implementations, the interface between the
gateway and adapter comprised a single, simplified
web

service. The 2.0 release decomposes the
interface into mult
iple
web

services, based on functionality, that conform to the NHIN specific
a-
tions. This decomposition better facilitates the pass
-
through mode and replacement of comp
o-
nents, and simplifies the overall interface specification for CONNECT without creating a

new
message specification.

For organizations that may be migrating from an earlier release of CONNECT, the architecture
for release 0.5, 0.75, and 1.0 used in the Trial Implementations demonstration are illustrated in
Figure
2
-
6

and
Figure
2
-
7
.


CONNECT Release 2.2

Page
34

Document Version 2.2


Figure
2
-
6

High
-
level view of the CO
NNECT release 0.5, 0.75, and 1.0

a
rchitecture
for a m
essage
received
from
the
NHIN
.


Figure
2
-
7

High
-
level view of the CONNECT release 0.5, 0.75, and 1.0

a
rchitecture
for a m
essage
sent to the NHIN.

CONNECT Adapter
CONNECT Gateway
External
-
Facing Services
Internal / Utility Services
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
Connection
Manager
Others
Others
Internal / Utility Services
Data
Transforms
Others
Others
Adapter
Adapter
Subscriptions
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
NHIN
CONNECT Components
Customizable Components
SAML
Non
-
SAML
MPI /
Correlation
Repository
Audit
Repository
Subscription
Management
External
-
Facing Services
Adapter
Adapter
Subscription
Document
Repository
Document
Registry
CONNECT Adapter
CONNECT Gateway
NHIN Message Processing Components
Internal / Utility Services
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
Connection
Manager
Others
Others
Entity Integration Components
Data
Transforms
Others
Others
Entity
Entity
Subscriptions
Subject
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
NHIN
CONNECT Components
Customizable Components
SAML
Non
-
SAML
MPI /
Correlation
Repository
Audit
Repository
Subscription
Management
External Adapter
-
Facing Services
Entity
Subscription
Entity

CONNECT Release 2.2

Page
35

Document Version 2.2

The name
s and descriptions of components within the gateway and adapter are similar to those in
the release 2.0 architecture, and are not described here. See
Table
2
-
2

for an
approximate d
e-
scription of the components described in
Figure
2
-
6

and
Figure
2
-
7
. As illustrated in these fi
g-
ures, most of the components and services resided within th
e CONNECT gateway, and the inte
r-
face between the gateway and adapter comprised a single
web

service.

The current architecture represented by release 2.0 provides a more flexible and more easily
maintained separation of customizable and replaceable componen
ts to the adapter. It also simpl
i-
fies the specification of the gateway/adapter interface to use the NHIN message specifications.

2.3

Product Line Reuse Considerations

CONTENTS OF THIS SECTION
: This section details how the software covered by this
document

is
p
lanned or expected to be reused in order to support the product line vision. In particular, this section i
n-
cludes a complete list of the variations that are planned to be produced and supported. "Variation" refers
to a variant of the software produced thro
ugh the use of pre
-
planned variation mechanisms made avail
a-
ble in the software architecture. It may refer to a variant of one of the modules identified in this
document
,
or a collection of modules, or the ent
ire system or subsystem
. For each variation, the

section identifies the
increment(s) of the software build in which (a) the variation will be available; and (b) the variation will be
used. Finally, this section describes any additional potential that exists to reuse one or more of the mo
d-
ules or their i
dentified variations, even if this reuse is not currently planned for any increment.

CONNECT was created primarily to support the health information exchange needs of Federal
agencies with an interest in healthcare


currently more than 20 in number. To ma
nage such a
large and diverse community of stakeholders, CONNECT has established a consortium of Fede
r-
al agencies, each of whom provides representatives to the initiative, and a Leadership and Co
m-
munications Workgroup comprising senior executives from each

participating agency that meets
regularly to provide strategic direction to the CONNECT team.

Requests for specific features and functionality for CONNECT are captured on a regular basis
through meetings and discussions with agency representatives, and ar
e prioritized quarterly by
the agencies in a CONNECT Product Managers Meeting. A definition of each new feature, its
benefit, and the estimate the complexity and level of effort associated its implementation are d
e-
tailed as part of this process. New functi
onality is then developed by the CONNECT develo
p-
ment team sponsored through the FHA.

CONNECT was designed to be extensible to meet the health information exchange needs of non
-
Federal organizations as well. The open source release of CONNECT supports the g
oal of aiding
private
-
sector organizations in connecting to the NHIN and exchanging health information with
other NHIEs, including Federal agencies.

The architecture for CONNECT was designed with course
-

and fine
-
grained customizability in
mind. The logica
l separation of gateway and adapter services and interfaces encapsulates, in the
adapter, those components that are most likely to be customized or replaced by an implementing
organization. The architecture is as modular as possible, abstracting and separa
ting components,
especially within the adapter, to facilitate customization and replacement. However, any comp
o-

CONNECT Release 2.2

Page
36

Document Version 2.2

nent, including core components encapsulated within the gateway, can be replaced with custom
implementations if the SOAP interfaces are honored.

CONNECT was also designed specifically to enable clinical information exchange, identified
and de
-
identified, on the NHIN. It is compliant with NHIN interface specifications and impl
e-
ments NHIN messaging protocols. However, the architecture and components
within this release
of CONNECT may be suited for other applications of health information exchange as well



supporting non
-
clinical exchange applications, as well as regional or state
-
wide exchanges that
might desire to implement some or all of the NHIN s
tandards.

It is not anticipated that CONNECT will be released in different variations. Instead, CONNECT
is being developed as a flexible and extensible product that can be implemented on an array of
platforms and operating systems. The flexibility is suppo
rted through its pass
-
through mode,
proxy components that allow bypassing of gateway orchestration, use of open
-
source platforms,
incorporation of replaceable reference implementations, and architectural separation of the gat
e-
way services and adapter servi
ces.


CONNECT Release 2.2

Page
37

Document Version 2.2

3

Architecture Views

CONTENTS OF THIS SECTION
: The sub
-
parts of Section 3 specify the views of the architecture. The
structure of this section is documented in Section 1.5.

This section documents the selected views of the software architecture and their

relationships to
each other. As such, this section is the documentation of the software architecture. Traditionally,
a view is a representation of a whole system from the perspective of a related set of concerns
[IEEE 2000]. Concretely, a view shows a par
ticular type of

software architectural elements

that
occur in a system, their properties, and the relations among them.

The CONNECT solution provides three related component layers to enable organization to co
n-
nect to the NHIN:

1.

The
NHIN Gateway

implements
the core NHIN services and NHIN service interface
specifications;

2.

The
Enterprise Service Components

provide robust, enterprise
-
class reference impl
e-
mentations for indexing patient identities, maintaining patient health documents, impl
e-
menting business rule
s for authorizing the release of medical information, and maintai
n-
ing auditable access logs, as
components of an SDK enabling developers to create adap
t-
ers for edge systems
; and

3.

The
Universal Client Framework

implements a client framework for developers to

cr
e-
ate applications that use the Enterprise Service Components.

This release of CONNECT includes an implementation of the NHIN Gateway and
four
Ente
r-
prise Service Components, which are documented
in this section
. V
iews are organized around
the

core NHIN services implemented by the

NHIN
Gateway
that comprise the functionality of
CONNECT
,

and
the

E
nterprise
S
ervice
C
omponents

that support those services
.
Table
3
-
1

i
n-
cludes a listing of the
core NHIN

s
ervices

that may be implemented by any NHIN
-
enabled health
organization

and are included in the
NHIN
Gateway
.

Table
3
-
2

lis
ts the Enterprise Service Co
m-
ponents currently included
as replaceable reference implementations
in CONNECT to support
the
NHIN
Gateway
s
ervices.

Table
3
-
1

L
ist of core NHIN services
implemented in the

NHIN
Ga
teway
that
provide
the primary
functionality for

CONNECT.

NHIN
Gateway Service

Description

Subject Discovery

A set of services for locating patients (i.e., “subjects”) based
on demographic information.


CONNECT Release 2.2

Page
38

Document Version 2.2

NHIN
Gateway Service

Description

Query for Documents

Locate electronic health
information, represented by doc
u-
ments, associated with a specific subject that conforms to a set
of query criteria.

Retrieve Documents

Retrieve specific electronic health information as documents
associated with a subject.

Query Audit Log

Log requests fo
r electronic health information and make this
log available to patients.

Authorized Case Follow
-
up

Re
-
identify pseudonymized patient records when legally pe
r-
mitted for public health case investigations.

Health Information Event Messaging

Provide a
publish

/ subscribe capability for ongoing feeds of
electronic health information between NHIN
-
enabled health
organizations.


While
Table
2
-
1

found in Section

2.1.2
,
Significant Driving Requirements
, listed a set of ten co
re
NHIN services and interface specifications that are often referred to as “
the
ten core NHIN se
r-
vices”, only the six items listed in
Table
3
-
1

are actual services, and only those six documented
as vi
ews in this section as
NHIN
Gateway s
ervices. The other “services”


Authorization
Framework, Consu
mer Preferences Profile, Messaging

Platform, and NHIE Service Registry


are frameworks and capabili
ties that support many, if not all, of these services
and
are doc
u-
mented within the context of each service.

Table
3
-
2

List of
Enterprise Service Components included as reference i
m-
plementations

in CONNECT to
support
NHIN
Gateway s
ervices.

Enterprise Service
Component

Description

Master Patient Index (MPI)

An index that stores patient demographic information and mana
g-
es searching of that index to identify patients based on those d
e-
mographics.

Document
Registry /

Repository

A document repository that stores documents associated with cli
n-
ical patient
information

and a registry that stores the metadata a
s-
sociated with those
documents that

supports the XDS.b specific
a-
tion.


CONNECT Release 2.2

Page
39

Document Version 2.2

Enterprise Service
Component

Description

Policy Engine

An engine used to m
anage and implement policies regarding a
c-
cess to patient information for the implementing organization that
supports the XSPA
profile
.

Audit Repository

A repository used to store audit information

for messages pr
o-
cessed by the gateway or adapter
.


To orient the reader, this section also includes a summary component diagram formed as a union
of the
component

diagrams found in the views that follow. This diagram is, of necessity, quite
complex and may be of little use in isolation. However, it provide
s an orienting picture of the
entire CONNECT solution that can be used as a reference when considering the
component

di
a-
gram of each service.

This section also includes an overall context diagram that comprises an
enterprise
-
level view of the interaction of CONNECT with other systems and entities. Each se
r-
vice view illustrates its place within this context using a separate, service
-
specific, co
ntext di
a-
gram as well.

Following this summary component
and context
diagram
s
, the
core NHIN services supported by
the
NHIN
Gateway
and
the
Enterprise Service Components

are docu
mented. The view of e
ach
core NHIN service

includes a
component

diagram and one

or more

sequence diagram
s
, along
with descriptions of each element found in these diagrams, a context diagram, a description of
variations, and the rational for the architecture.

The view of the

Enterprise Service Component

varies from component to compon
ent. It is b
e-
yond the scope of this
document

to fully
describe

the internal architecture of these components
.

Instead, three general approaches are utilized:

1.

For Enterprise Service Components that are taken directly from enterprise
-
class open
source implem
entations, documentation of the component
’s architecture

is limited to
that
provided by the open source project supporting the component.

That documentation is
not included in this document, but may be referenced by it.

2.

For Enterprise Service Components th
at make use of an open source solution, but add
features or other components to fully realize the reference implementation, the view of
the Enterprise Service Component includes a
component

diagram and sequence diagrams
to illustrate interactions between t
he open source solution and additional components.

3.

For Enterprise Service Components that were developed as part of CONNECT, the view
likewise includes a
component

diagram and sequence diagrams to describe the comp
o-
nent.

In all cases, interactions with the

Enterprise Service Components to realize core NHIN services
are documented within the architecture views of the core NHIN services.


CONNECT Release 2.2

Page
40

Document Version 2.2

The reader may also find it useful to reference the high
-
level discussions of the overall archite
c-
ture found in Section

2.2.1
,
System Overview
, and illustrated in
Figure
2
-
3

and
Figure
2
-
4
. These
are not component diagrams
per se
, but provide a conceptual view of all architectural comp
o-
nents at a higher level than depicted in this section. Especially readers that are interested

in a
high
-
level understanding of the architecture only should concentrate on that section rather than
the views presented here.

3.1

Architecture Overview

The overall architecture of the CONNECT software can be logically broken down into two se
c-
tions: a gatewa
y with corresponding services and components, and an adapter with correspon
d-
ing adapter services and components. Core NHIN services and Enterprise Service Components
may be part of either or both of these logical sections. This separation is especially use
ful for the
developer that is implementing CONNECT, as the gateway comprises components and services
that are most likely to be used as
-
is without any modification, while the adapter comprises co
m-
ponents and services that are most likely to be customized o
r replaced. This organization is d
e-
picted clearly in Section

2.2.1
,
System Overview
.
To make the material more readable, this div
i-
sion of components into gateway and adapter encapsulations is also illustrated in the service
views that follow, as well as in the summary component diagram of
Figure
3
-
1
.

The components and services that comprise CONNECT can be separated into a few major types.

NHIN Orchestration Components

comprise a set of gateway processes responsible for accep
t-
i
ng messages from the NHIN and processing them, usually by invoking a series of core service
components or adapter services. These NHIN Orchestration Components may also be configured
to work in pass
-
through mode, in which case they accept the message from
the NHIN along with
the enclosed SAML information, and pass them directly to the adapter without orchestration. See
Section

3.1.1
,
Pass
-
through Modes
, below for more information on how the pass
-
through mode
works within NHIN Orchestration Components.

The generic pattern is to have one or more orchestration compo
nents for a given core NHIN se
r-
vice responsible for receiving messages from the NHIN.

Entity Orchestration Components

are implementations of the services called by the adapter to
communicate with the NHIN. These components are responsible for orchestrating the request
and ultimately sending the message to the NHIN through the Message Proxy Components.

The interfaces for
the Entity Orchestration Components are based on the NHIN specifications
with a slight modification


as well as an interface utilizing SAML per the NHIN specifications,
they
incorporate an interface that does
not utilize SAML. Instead,
this secondary inte
rface

take
s

the SAML
-
related assertion information in the form of an assertion object. This object is then
used by the Message Proxy Components to construct a valid message that utilizes SAML.

Like the NHIN Orchestration Components, the generic pattern is
to have one or more orchestr
a-
tion components for a given core NHIN service responsible for sending messages to the NHIN.


CONNECT Release 2.2

Page
41

Document Version 2.2

Message Proxy Component
s

facilitate sending messages to the NHIN, with the primary pu
r-
pose being to properly handle the SAML security
layer. The input parameters of these comp
o-
nents comprise the NHIN message and an assertion object containing the information needed to
construct a SAML assertion. The Message Proxy Component takes the NHIN message and the
assertion data and creates a compl
iant SAML message, which is then sent to the NHIN. It r
e-
ceives the response from the NHIN and, after extracting the returned SAML data, passes this i
n-
formation back to the caller.

There is one Message Proxy Component for each exposed NHIN interface specifi
cation. Note
that the components at this layer are proxies. They process a single message and they do not ex
e-
cute any orchestration. See Section

3.1.1
,
Pass
-
through Modes
, below for a generic description
of how Message Proxy Components are used as a pass
-
through.

Secure Service
Proxy Component
s

facilitate
receivi
ng messages bi
-
directionally between the
gateway and adapter, and with replaceable components in the gateway
, with the primary purpose
being to properly handle the SAML security layer.
They are so named as they facilitate an alte
r-
nate interface to componen
ts with appropriate security (i.e., utilizing TLS and SAML assertions)
should they be implemented on separate machines.
The input parameters of these components
com
prise a

message

containing a SAML assertion.
The
Secure Service

Proxy Component takes
the me
ssage
and separates the SAML information into a separate assertion object
, which
are

then
sent to the
appropriate component.

The Secure Service Proxy Components are not shown in component or sequence diagrams that
follow, but are listed as if implemented a
s a separate WSDL interface to other components. Like
the Message Proxy Components,

these
components are proxies. They process a single message
and they do not execute any orchestration.

Core Components

represent lower
-
level components used to support the
CONNECT

functiona
l-
ity. While the NHIN and Entity Orchestration Components manage workflow, these Core Co
m-
ponents are the actual engines that process the data used by the system. While the Orchestration
Components generally expose coarse
-
grained business
-
ce
ntric services, the Core Components
expose fine
-
grained data
-
centric services.

Although it is intended that these components be internal to the gateway, there are a small nu
m-
ber that may be candidates for customization. If an organization wishes to customi
ze one of these
components, they must match the WSDL interface exactly.

Adapter Service Components

represent a set of “service components” that exist outside of the
CONNECT gateway in the adapter


the software used by an organization to communicate bi
-
directionally with the CONNECT gateway by wrapping an organization’s existing system. The
adapter mus
t implement a specific set of interfaces used by the gateway to send messages to the
adapter and to receive responses back from it. Therefore, the adapter service components are ty
p-
ically an organization’s existing sub
-
system wrapped in a web service, simi
lar to the NHIN se
r-
vice components.


CONNECT Release 2.2

Page
42

Document Version 2.2

A reference implementation of each component is provided by CONNECT that may be used as a
basis for implementation, along with the Enterprise Service Components


enterprise
-
class,
open
-
source reference implementations i
ncluded with CONNECT that may be used if desired.

Figure
3
-
1

provides a summary
component

diagram for the
core NHIN

services that are d
e-
scribed in more detail in Sect
ions

3.2

through
3.7
. Each of the later
sections includes a
comp
o-
nent

di
agram that describes only the components involved in that service. This diagram therefore
establishes a reference point for how these services relate to each other.

The component diagram of
Figure
3
-
1

does not depict all of the components that make up CO
N-
NECT. Such a diagram would be almost impossible to decipher, and therefore provide little va
l-
ue. Instead, this diagram includes the most important components and conne
ctions for unde
r-
standing the overall organization of the CONNECT software components and the patterns that
are repeated in the views that follow. In particular, connections between the Adapter and Me
s-
sage Proxy Components that support pass
-
through, detaile
d later in Section

3.1.1
,
Pass
-
through
Modes
, are omitted,

and only the default behavior utilizing Entity Orchestration Components.
Likewise, connections to the Aggregator, Property Accessor, and Connection Manager are not
illustrated in this figure, but are included in the component diagrams within each view tha
t fo
l-
lows.

Table
3
-
3

lists all elements (i.e., components) contained within the summary component diagram
in
Figure
3
-
1
. Li
ke the component diagram, these elements are also included in the individual
element catalogs for the NHIN Gateway services that are described in more detail in Sections

3.2

through
3.7
. The interfaces selected and included in these tables are limited to those that are pu
b-
lic, or that are part of customizable or replaceable c
omponents in the architecture.

As of Release

2.2, two interfaces, in the form of two WSDLs, are listed for many of the comp
o-
nents in
Table
3
-
3
. The first of the pair,

containing the “Secured” designation, represents the s
e-
cured service interface that utilizes TLS for encrypted transport and SAML authorization asse
r-
tions. The components with two interfaces represent the
adapter interfaces for messages from the
NHIN, gat
eway interfaces for messages to the NHIN, and interfaces to replaceable components.
Both the legacy, “unsecured” interfaces and the new “secured” interfaces are supported. For
simplicity, the component diagram in
Figure
3
-
1

lists only the legacy WSDLs by name. This
same pattern



listing legacy interface WSDLs in the component diagram but both interface
WSDLs in the element table



is used throughout this document.

With
in
Table
3
-
3
, components are separated into a few major types. These component types are
described in the
Interface Description Document
[FHA 2009
-
1
]

as well as in the material that
follows. The views within this section continue to separate components into these major types to
help develop an understanding of the logical architecture of the NHIN Gateway services.


CONNECT Release 2.2

Page
43

Document Version 2.2


Figure
3
-
1

Summary component diagram, a union of all of the
component

di
a-
grams of the
NHIN
Gateway
s
ervice views included in this
document
.


CONNECT Release 2.2

Page
44

Document Version 2.2

Table
3
-
3

Catalog of all of the elements (i.e., component
s) contained in the
summary
component

diagram in
Figure
3
-
1
.

Element

Description

Interfaces

Remote Gateway

Generic representation of a remote system
on
the NHIN, which may or may not implement
CONNECT as its gateway solution but co
n-
forms to NHIN standards for interoperability.


NHIN
Orchestration Components

NHIN Orchestration
Audit Reporting
Component

Service that orchestrates processing of requests
from the NHIN to process queries for audit log
reports on the existing system(s) serviced by
CONNECT.

NhinAuditLogQuery
WSDL

NHIN Orchestration
Document Query
Component

Service that orchestrates processing of requests
from the NHIN to locate electronic he
alth i
n-
formation associated with a specific patient on
the existing system(s) serviced by CONNECT
that may be retrieved by the Retrieve Doc
u-
ments service.

NhinDocQuery WDL

NHIN Orchestration
Document Retrieve
Component

Service that orchestrates processing

of requests
from the NHIN to retrieve documents contai
n-
ing patient health information on the existing
system(s) serviced by CONNECT that were l
o-
cated by the Query for Documents service.

NhinDocRetrieve WSDL

NHIN
Orchestration
Notification
Processing
Component

Service that orchestrates processing of notific
a-
tions from the NHIN of information available to
existing system(s) serviced by CONNECT as a
result of subscriptions to that message type.

Nhin
Subscription

WSDL

NHIN Orchestration
Subscription
Manag
ement
Component

Service that orchestrates processing of requests
from the NHIN to manage HIEM subscriptions
on the existing system(s) serviced by CO
N-
NECT.

NhinSubscription WSDL

NHIN Orchestration
Subject Discovery
Component

Service that orchestrates proce
ssing of requests
from the NHIN to locate subjects on the existing
system(s) serviced by CONNECT.

NhinSubjectDiscovery
WSDL


CONNECT Release 2.2

Page
45

Document Version 2.2

Element

Description

Interfaces

Entity
Orchestration Components

Entity Orchestration
Audit Reporting
Component

Service that orchestrates processing of requests
from existing system(s) service by CONNECT
to process queries for audit log reports on r
e-
mote systems on the NHIN.

EntityAuditLogQuery
-
Secured WSDL

EntityAuditLogQuery
WSDL

Entity Orchestration
Document Query
Component

Service that orchestrates processing

of requests
from existing system(s) serviced by CONNECT
to locate electronic health information, repr
e-
sented as documents, associated with a specific
patient on remote systems on the NHIN to be
retrieved by the Retrieve Documents service.

EntityDocQuery
Secured

WSDL

EntityDocQuery WSDL

Entity Orchestration
Document Retrieve
Component

Service that orchestrates processing of requests
from existing system(s) serviced by CONNECT
to retrieve documents containing patient health
information that were located on

remote systems
on the NHIN by the Query for Documents se
r-
vice.

EntityDocRetrieve
-
Secured WSDL

Entity
DocRetrieve WSD
L

Entity Orchestration
Notification
Processing
Component

Service that orchestrates processing of notific
a-
tions from existing system(s)
serviced by
CONNECT of available information to remote
systems on the NHIN that have subscribed to a
specific message type.

Entity
-
NotificationConsumer
-
Secured WSDL

Entity
-
Notification
Consumer
WSDL

Entity Orchestration
Subscription
Management
Component

Se
rvice that orchestrates processing of request
from existing system(s) serviced by CONNECT
to manage HIEM subscriptions on remote sy
s-
tems on the NHIN.

Entity
-
SubscriptionManagement
-
Secured WSDL

Entity
-
SubscriptionManagement
WSDL

Entity Orchestration
Subject Discovery
Component

Service that orchestrates processing of requests
from existing system(s) serviced by CONNECT
to locate subjects on remote systems on the
NHIN based on demographic information.

EntitySubjectDiscovery
-
Secured WSDL

Entity
SubjectDis
covery
WSDL


CONNECT Release 2.2

Page
46

Document Version 2.2

Element

Description

Interfaces

Message Proxy Components

Message Proxy
Audit Reporting
Component

Service that facilitates sending messages to the
NHIN to process audit log queries, properly
handling the SAML security layer, used in pass
-
through mode and by the Entity Orches
tration
component.

NhincProxy
-
AuditLogQuerySecured
WSDL

NhincProxy
-
AuditLogQuery WSDL

Message Proxy
Document Query
Component

Service that
facilitates sending messages to the
NHIN

to locate electronic health information
represented

as documents, properly handling the
SAML security layer
.

NhincProxyDocQuery
-
Secured WSDL

NhincProxyDocQuery

WSDL

Message Proxy
Document Retrieve
Component

Service that
facilitates sending messages to the
NHIN
to retrieve documents containing patient
heal
th information
, properly handling the
SAML security layer
.

NhincProxyDocRetrieve
-
Secured WSDL

NhincProxy
DocRetrieve

WSDL

Message Proxy
Notification
Processing
Component

Service that facilitates sending message to the
NHIN to process notifications on
remote sy
s-
tems, properly handling the SAML security la
y-
er, used in pass
-
through mode and by the Entity
Orchestration component.

NhincProxy
-
NotificationConsumer
-
Secure WSDL

NhincProxy
-
NotificationConsumer
WSDL

Message Proxy
Subscription
Management
Componen
t

Service that facilitates sending message to the
NHIN to manage HIEM subscriptions on remote
systems, properly handling the SAML security
layer, used in pass
-
through mode and by the
Entity Orchestration component.

NhincProxy
-
SubscriptionManagement
-
Secured

WSDL

NhincProxy
-
Subscription
Management
WSDL

Message Proxy
Subject Discovery
Component

Service that facilitates sending messages to the
NHIN to locate subjects on remote systems,
properly handling the SAML security layer.

NhincProxy
-
SubjectDiscoverySecure
d
WSDL

NhincProxy
-
SubjectDiscovery WSDL


CONNECT Release 2.2

Page
47

Document Version 2.2

Element

Description

Interfaces

Core Components

Aggregator

Service that aggregates multiple documents r
e-
trieved from the existing system(s) serviced by
CONNECT into a single response as a result of
a Retrieve Documents request for multiple do
c-
uments.

NhincComponent
-
Aggregator WSDL

Audit

Service that coordinates the transformation of
message traffic into auditable i
nformation, and
st
ores that information in the Audit Repository
,
a surrogate for the Audit Recorder Façade b
e-
low used in most diagr
ams
with
in this
doc
u-
ment
.

NhincComponent
-
AuditRepositorySecured
WSDL

NhincComponent
-
AuditRepository WSDL

Audit Log DTE

Service interface to the data translation engine
that transforms specific messages from CO
N-
NECT components into generic messages suit
a-
bl
e for storage in the Audit Repository.

NhincComponent
-
AuditLogDte

WSDL

Audit Recorder
Façade

Service that coordinates the transformation of
message traffic in
to auditable information, and
st
ores that information in the Audit Repository
,
the actual
implementation of the Audit comp
o-
nent above
.

NhincComponent
-
Internal
AuditRepository

WSDL

Audit Repository

Service acting
as an interface
to
the repository
used to
store and retrieve audit information on
messages processed by the CONNECT gateway
or
adapter.

NhincComponent
-
AuditRepositorySecured
WSDL

NhincComponent
-
AuditRepository WSDL

Connection Manager

Service that resolves remote Gateway endpoints,
as well as some internal services within the
CONNECT gateway or adapter.

NhincComponent
-
ConnectionMa
nager
WSDL

Patient Correlation

Service that manages the correlation of patient
IDs from existing system(s) serviced by CO
N-
NECT and other NHIEs.

NhincComponent
-
PatientCorrelationSecured
WSDL

NhincComponent
-
PatientCorrelation WSDL


CONNECT Release 2.2

Page
48

Document Version 2.2

Element

Description

Interfaces

Patient Correlation
Façade

Service providing a simplified interface for the
Patient Correlation service, responsible for
translating a simplified patient correlation me
s-
sage to the more complex HL7
-
based messages
used by the Patient Correlation service, and
looking up the dyn
amic endpoint for Patient
Correlation and invoking it.

NhincComponent
-
Internal
Patient
-
CorrelationFaçade WSDL

Property Accessor

Service that exposes CONNECT gateway co
n-
figuration parameters, from sources such as co
n-
figuration files, to the other gateway c
omp
o-
nents and services.

NhincComponent
-
PropAccessor WSDL

Subscription
Repository

Service acting as an interface to a repository
storing subscriptions to health information e
x-
change messages.

NhincComponent
-
SubscriptionRepository
WSDL

CONNECT Adapter Serv
ices

Adapter

Encapsulation of the CONNECT adapter used to
represent it in the initiation of messages to the
NHIN in sequence diagrams that follow.


Adapter Document
Query

Encapsulation of the CONNECT adapter service
interface that processes requests to
locate ele
c-
tronic health information documents on the e
x-
isting system(s) serviced by CONNECT.

AdapterDocQuerySecured
WSDL

AdapterDocQuery WSDL

Adapter Document
Retrieve

Encapsulation of the CONNECT adapter service
interface that processes requests for
electronic
health information documents on the existing
system(s) serviced by CONNECT.

AdapterDocRetrieve
-
Secured WSDL

AdapterDocRetrieve
WSDL

Adapter MPI

Service that acts as the proxy to the production
master patient index (MPI) service, a custom
i-
zable
or replaceable service within the adapter.

AdaptorMPISecured
WSDL

AdaptorMPI WSDL


CONNECT Release 2.2

Page
49

Document Version 2.2

Element

Description

Interfaces

Adapter Notification
Processing

Service acting as an interface to HIEM notific
a-
tion processing within the existing system(s)
serviced by CONNECT.

Adapter
-
NotificationConsume
r
-
Secured WSDL

Adapter
-
NotificationConsumer

WSDL

Adapter Policy

Service acting as an interface to an enterprise
policy engine used to manage policies regarding
access to patient information located on the e
x-
isting system(s) serviced by CONNECT.

AdapterPol
icyEngine
-
Secured WDL

AdapterPolicyEngine
WDL

Adapter
Reidentification

Service acting as an interface to a store of ma
p-
pings from pseudonym identifies to real ident
i-
fiers for a patient.