CONNECT

moodusroundoSoftware and s/w Development

Aug 15, 2012 (5 years and 1 month ago)

523 views


CONNECT

Soft
ware Architecture




Software Release 2.
2

Document Version 2.
2


29

September

2009


CONNECT Release 2.2

Page
ii

Document Version 2.2

REVISION RECORDS

REVISIO
N

DATE

DESCRIPTION

A013.001, A042.001

28 January 2009

Initial
Release.

A013.002, A042.002

31 March 2009

Document enhanced and reformatted to describe Release
2.0
.

A013.003, A042.003

7 July 2009

Revised to describe Release 2.1, including all core NHIN
services and Enterprise
Service
Components.

A013.004, A042.004

29 September 2009

R
evised to describe Release 2.2 which incorporates SAML
and message encryption in
additional
interfaces
.












































CONNECT Release 2.2

Page
iii

Document Version 2.2

Table of Contents

Table of Contents

................................
................................
................................
...............

iii

List of Figures

................................
................................
................................
....................

vi

List of Tables

................................
................................
................................
.......................
x

Executive Summ
ary

................................
................................
................................
.................
1

1

Document Roadmap

................................
................................
................................
..........
5

1.1

Document Management and Configuration Control Information

..............................
5

1.2

Purpose and Scope

................................
................................
................................
......
6

1.3

How this Document Is Organized

................................
................................
...............
7

1.4

Stakeholder Representation

................................
................................
........................
9

1.5

How a View Is Documented

................................
................................
.....................
10

1.6

Relationship to Other Documents

................................
................................
.............
12

1.7

Process for Updating this Document

................................
................................
........
12

2

Architecture Background

................................
................................
................................
14

2.1

Problem Background

................................
................................
................................
14

2.1.1

Goals and Context

................................
................................
.........................
14

2.1.2

Significant Driving Requirements

................................
................................
15

2.2

Solution Background

................................
................................
................................
21

2.2.1

System Overview

................................
................................
..........................
21

2.2.2

Architectural Approaches

................................
................................
.............
29

2.2.3

Analysis Results

................................
................................
............................
31

2.2.4

Requirements Coverage

................................
................................
................
32

2.2.5

Summary of Background Changes Reflected in Current
Version

................................
................................
................................
..........
33

2.3

Product Line Reuse Conside
rations

................................
................................
..........
35

3

Architecture Views
................................
................................
................................
...........
37

3.1

Architecture Overview

................................
................................
..............................
40

3.
1.1

Pass
-
through Modes

................................
................................
......................
50

3.1.2

Enabling Services
................................
................................
..........................
52

3.2

Service View


Subject Discovery

................................
................................
...........
54

3.2.1

View Description

................................
................................
..........................
54

3.2.2

Component and Sequence Diagrams

................................
............................
56

3.2.3

Element Catalog

................................
................................
............................
62

3.2.4

Context Diagram

................................
................................
...........................
64

3.2.5

Variability Guide

................................
................................
..........................
65

3.2.6

Architectural Background

................................
................................
.............
66


CONNECT Release 2.2

Page
iv

Document Version 2.2

3.3

Service View


Query for Documents

................................
................................
......
67

3.3.1

View Description

................................
................................
..........................
67

3.3.2

Component and Sequence Diagrams

................................
............................
68

3.3.3

Element Catalog

................................
................................
............................
71

3.3.4

Context Diagram

................................
................................
...........................
74

3.3.5

Variability Guide

................................
................................
..........................
75

3.3.
6

Architectural Background

................................
................................
.............
76

3.4

Service View


Retrieve Documents

................................
................................
........
77

3.4.1

View Description

................................
................................
..........................
77

3.4.2

Component and Sequence Diagrams

................................
............................
78

3.4.3

Element Catalog

................................
................................
............................
81

3.4.4

Context Diagram

................................
................................
...........................
83

3.4.5

Variability Guide

................................
................................
..........................
85

3.4.6

Architectural Background

................................
................................
.............
86

3.5

Service View


Query Audit Log

................................
................................
.............
87

3.5.1

View Description

................................
................................
..........................
87

3.5.2

Component and Sequence Diagrams

................................
............................
88

3.5.3

Element Catalog

................................
................................
............................
92

3.5.4

Context Diagram

................................
................................
...........................
95

3.5.5

Variability Guide

................................
................................
..........................
96

3.5.6

Architectural Background

................................
................................
.............
97

3.6

Service View


Authorized Case Follow
-
up

................................
............................
98

3.6.1

View Description

................................
................................
..........................
98

3.6.2

Component and Sequence Diagrams

................................
............................
99

3.6.3

Element Catalog

................................
................................
..........................
101

3.6.4

Context Diagram

................................
................................
.........................
103

3.6.5

Variability Guide

................................
................................
........................
104

3.6.6

Architectural Background

................................
................................
...........
105

3.7

Service View


Health Information Event Messaging

................................
...........
106

3.7.1

View Description

................................
................................
........................
106

3.7.
2

Component and Sequence Diagrams

................................
..........................
108

3.7.3

Element Catalog

................................
................................
..........................
116

3.7.4

Context Diagram

................................
................................
.........................
120

3.7.5

Variability Guide

................................
................................
........................
121

3.7.
6

Architectural Background

................................
................................
...........
122

3.9

Enterprise Service Component


Policy Engine

................................
.....................
123

3.9.1

Component Description

................................
................................
..............
123

3.9.2

Sequence Diagrams

................................
................................
.....................
125

3.9.
3

Element Catalog

................................
................................
..........................
127

3.9.4

Variability Guide

................................
................................
........................
129

3.9.5

Architectural Background

................................
................................
...........
130

3.10

Enterprise Service Component


Audit Log

................................
...........................
131

3.10.1

Component Description

................................
................................
..............
131

3.10.2

Sequence Diagrams

................................
................................
.....................
132

3.10.3

Element Catalog

................................
................................
..........................
133


CONNECT Release 2.2

Page
v

Document Version 2.2

3.10.4

Variability Guide

................................
................................
........................
134

3.
10.5

Architectural Background

................................
................................
...........
134

3.11

Adapter Interfaces and Service Bus Components

................................
...................
136

3.12

NHIE Service Registry

................................
................................
...........................
140

4

Referenced Materials

................................
................................
................................
.....
141

5

Di
rectory

................................
................................
................................
.........................
144

5.1

Glossary

................................
................................
................................
..................
144

5.2

Acronyms

................................
................................
................................
................
147



CONNECT Release 2.2

Page
vi

Document Version 2.2

List of Figures

Figure 1
-
1

Template for documenting a view as used in this document, comprising a
view description, graphical primary presentation, element catalog,
graphical context diagram, variability guide, and architecture background.

.........
11

Figure 2
-
1

Conceptual grouping of core NHIN services into groups of infrastructure
services, exchange services, and consumer services.

................................
............
22

Figure 2
-
2

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

..................
23

Figure 2
-
3

High
-
level view of the CONNECT release 2.0 architecture for a message
received from the NHIN.

................................
................................
.......................
24

Figure 2
-
4

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

................................
................................
................................
...
25

Figure 2
-
5

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

................................
.................
29

Figure 2
-
6

High
-
level view of the CONNECT release 0.5, 0.75, and 1.0 architecture
for a message received from the NHIN.

................................
................................
34

Figure 2
-
7

High
-
level view of the CONNECT release 0.5, 0.75, and 1.0 architecture
for a message sent to the NHIN.

................................
................................
............
34

Figure 3
-
1

Summary component diagram, a union of all of the component diagrams
of the NHIN Gateway service views included in this document.

..........................
43

Figure 3
-
2

Summary context diagram for CONNECT, illustrating its interaction with
other entities.

................................
................................
................................
..........
50

Figure 3
-
3

Component diagram illustrating the components involved in pass
-
through
mode for messages from the NHIN utilizing the pass
-
through mode of the
NHIN Orchestration Component.

................................
................................
..........
51

Figure 3
-
4

Sequence diagram illustrating the interactions of services in pass
-
through
mode for messages from the NHIN utilizing
the pass
-
through mode of the
NHIN Orchestration Component.

................................
................................
..........
51

Figure 3
-
5

Component diagram illustrating the components involved in

pass
-
through
mode for messages to the NHIN utilizing a generic Message Proxy
Component rather than the Entity Orchestration Component.
...............................
52


CONNECT Release 2.2

Page
vii

Document Version 2.2

Figure 3
-
6

Sequence diagram illustrating the interactions of services in pass
-
through
mode for messages to the NHIN utilizing a generic Message Proxy
Component rather than the Entity Orchestration Component.
...............................
52

Figure 3
-
7

Component diagram for the Subject Discovery set of services.

............................
56

Figure 3
-
8

Sequence diagram for the Subject Discovery



Add Subject service for
messages from the NHIN.

................................
................................
......................
57

Figure 3
-
9

Sequence diagram for the Subject Discovery



Add Subject service for
messages to the NHIN. Note that this is the same sequence diagram for as
the Revise Subject service for messages to the NHIN.

................................
..........
58

Figure 3
-
10

Sequence diagram for the Subject Discovery



Revise Subject service for
messages from the NHIN.

................................
................................
......................
59

Figure 3
-
11

Sequence diagram for the Subject Discovery



Revoke Subject service for
messages from the NHIN.

................................
................................
......................
60

Figure 3
-
12

Sequence diagram for the Subject Discovery



Revoke Subject service for
messages to the NHIN.

................................
................................
..........................
61

Figure 3
-
13

Context diagram for the Subject Discovery service, illustrating
CONNECT and an existing system interacting primarily with provider
systems on the NHIN.

................................
................................
............................
64

Figure 3
-
14

Component diagram for the Query for Documents service.

................................
..
68

Figure 3
-
15

Sequence diagram for the Query for Documents service for messages from
the NHIN.

................................
................................
................................
...............
69

Figure 3
-
16

Sequence diagram for the Query for Documents service for messages to
the NHIN.

................................
................................
................................
...............
70

Figure 3
-
17

Context diagram for the Query for Documents service, illustrating
CONNECT and an existing system interacting with provider systems,
consumer systems, and a variety of public
-
sector s
ystems that access
clinical information on the NHIN.

................................
................................
.........
74

Figure 3
-
18

Component diagram for the Retrieve Documents service.

................................
....
78

Figure 3
-
19

Sequence diagram for the Retrieve Documents service for messages from
the NHIN.

................................
................................
................................
...............
79

Figure 3
-
20

Sequence diagram for the Retrieve Documents service for messages to the
NHIN.
................................
................................
................................
.....................
80


CONNECT Release 2.2

Page
viii

Document Version 2.2

Figure 3
-
21

Context diagram for the Retrieve Documents service, illustrating
CONNECT and an existing system interacting with provider systems,
consumer system
s, and a variety of public
-
sector systems that access
clinical information on the NHIN.

................................
................................
.........
84

Figure 3
-
22

Component diagram for the
Query Audit Log service.

................................
.........
88

Figure 3
-
23

Sequence diagram for Audit Log Store operation that is part of the normal
process for stor
ing auditable records.

................................
................................
....
89

Figure 3
-
24

Sequence diagram for the Query Audit Log service for messages from the
NHIN.
................................
................................
................................
.....................
90

Figure 3
-
25

Sequence diagram for the Query Audit Log service for messages to the
NHIN.
................................
................................
................................
.....................
91

Figure 3
-
26

Context diagram for the Query Audit Log service, illustrating CONNECT
and an existing system interacting with provider systems, consumer
systems, and a variety of
public
-
sector systems that create audit log entries
or query for audit log reports.

................................
................................
................
95

Figure 3
-
27

Component diagram for the Auth
orized Case Follow
-
up service.

........................
99

Figure 3
-
28

Sequence diagram for the Subject Reidentification service for messages
from the NHIN
.

................................
................................
................................
....
100

Figure 3
-
29

Sequence diagram for the Subject Reidentification service for messages to
the NHIN.

................................
................................
................................
.............
100

Figure 3
-
30

Context diagram for the Authorized Case Follow
-
up service, illustrating
CONNECT and an existing system interacting public health systems on
th
e NHIN.

................................
................................
................................
.............
103

Figure 3
-
31

Component diagram for the Health Information Event Messaging
subscription management service.

................................
................................
.......
108

Figure 3
-
32

Component diagram for the Health Information Event notification
processing service.

................................
................................
...............................
109

Figure 3
-
33

Sequence diagram for subscribing to receive notifications for a specific
information type using the Health Information Event Messaging service
f
or messages from the NHIN.

................................
................................
..............
110

Figure 3
-
34

Sequence diagram for receiving notifications of available data using the
Health Inform
ation Event messaging service for messages from the NHIN.

......
111


CONNECT Release 2.2

Page
ix

Document Version 2.2

Figure 3
-
35

Sequence diagram for unsubscribing to a subscription usi
ng the Health
Information Event Messaging service for messages from the NHIN.

.................
112

Figure 3
-
36

Sequence diagram for subscribing to
receive notifications for a specific
information type using the Health Information Event Messaging service
for messages to the NHIN.

................................
................................
...................
113

Figure 3
-
37

Sequence diagram for receiving notifications of available data using the
Health Information Event messaging service for messages to the NHIN.

..........
114

Figure 3
-
38

Sequence diagram for unsubscribing to a previous subscription using the
Health Information Event Messaging service for messages to the NHIN.

..........
115

Figure 3
-
39

Context diagram for the Health Information Event Messaging service: for
messages from the NHIN (top) and messages to the NHIN (bottom).

................
120

Figure 3
-
40

Component diagram for the Policy Engine Enterprise Service Component.
.......
123

Figure 3
-
41

Sequence diagram for processing messages from the NHIN implemented
by the Policy Engine Enterprise Service Component.

................................
.........
125

Figure 3
-
42

Sequence diagram for processing messages to the NHIN implemented by
the Policy Engine Enterprise Service Component.

................................
..............
126

Figure 3
-
43

Sequence diagram for patient consent management implemented by the
Policy Engine Enterprise Service Component.

................................
....................
127

Figure 3
-
44

Component diagram for the Audit Log Enterprise Service Component.
.............
131

Figure 3
-
45

Sequence diagram for Audit Log Store operation, the primary set of
interactions for the Audit Log Enterprise Service Component.

...........................
132

Figure 3
-
46

High
-
level view of the CONNECT adapter architecture for messages
received from the NHIN.

................................
................................
.....................
136

Figure 3
-
47

High
-
level view of the CONNECT adapter architecture for messages
received from the NHIN, highlighting the adapter service bus components.

......
138

Figure 3
-
48

High
-
level view of the CONNECT adapter architecture for messages
received from the NHIN, highlighting the SDK Services.

................................
..
139



CONNECT Release 2.2

Page
x

Document Version 2.2

List of Tables

Table 1
-
1

Stakeholders in the architecture and their concerns that might be addressed
by this software architec
ture documentation.

................................
..........................
9

Table 2
-
1

List of the core NHIN services and interface specifications that make up
the NHIN.

................................
................................
................................
...............
17

Table 2
-
2

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

................................
................................
................................
............
26

Table 2
-
3

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

...................
30

Table 3
-
1

List of core NHIN services implemented in the NHIN Gateway that
provide the primary functionality for CONNECT.

................................
................
37

Table 3
-
2

List of Enterprise Service Components included as reference
implementations in CONNECT to support NHIN Gateway services.

...................
38

Table 3
-
3

Catalog of all of the elements (i.e., components) contained in the summary
component diagram in Figure 3
-
1.

................................
................................
.........
44

Table 3
-
4

Catalog of all of the elements contained in the component and sequence
diagrams for the Subject Discovery set of services, along with the WSDL
interface(s) fo
r each.

................................
................................
..............................
62

Table 3
-
5

Catalog of all of the elements contained in the component and sequence
diagrams for the Query for Documents
service, along with the WSDL
interface(s) for each.

................................
................................
..............................
71

Table 3
-
6

Catalog of all of the elements contained in the component and se
quence
diagrams for the Retrieve Documents service, along with the WSDL
interface(s) for each.

................................
................................
..............................
81

Table 3
-
7

Catalog of all of the
elements contained in the component and sequence
diagrams for the Query Audit Log service, along with the WSDL
interface(s) for each.

................................
................................
..............................
92

Table 3
-
8

Catalog of all of the elements contained in the component and sequence
diagrams for the Authorized Case Follow
-
up service, along with the
WSDL interface(s) for each.

................................
................................
................
101

Table 3
-
9

Catalog of all of the elements contained in the component and sequence
diagrams for the Health Information Event Messaging service, along with
the WSDL interface(s) for each.

................................
................................
..........
116


CONNECT Release 2.2

Page
xi

Document Version 2.2

Table 3
-
10

Catalog of all of the elements that comprise the Audit Log Enterprise
Service Component, along with the WSDL interface(s) for e
ach.

......................
127

Table 3
-
11

Catalog of all of the elements that comprise the Audit Log Enterprise
Service Component, along with the WSDL
interface(s) for each.

......................
133




CONNECT Release 2.2

Page
1

Document Version 2.2

Executive Summary

CONNECT implements a
flexible, open
-
source gateway solution that enables healthcare ent
i-
ties



Federal agencies or private
-
sector health organizations or networks



to connect their exis
t-
ing health information systems to the NHIN. CONNECT is fully functional out
-
of
-
the
-
box, wh
ile
at the same time configurable and flexible to allow organizations to customize it to meet their
needs and those of their existing health information systems.

CONNECT is based on service
-
oriented
-
architecture design principles and

web service interfa
c-
es
.

This
architecture
enables
individual components

to be replaced by custom solutions

as long
as they adhere to the defined web service interface specifications
.

It also
allows implementations
to be
host
ed

on different hardware
and software platforms,
as we
ll as
services to be implemented
using
different programming languages.

CONNECT
is designed to
su
p-
port

the NHIN architecture. Its
web services are based on a
Me
s
saging, Security, and Pr
i-
vacy Foundation that describes
the underlying protocols and
capabilities necessary to send
and secure messages between
participants

on the NHIN. It
implements the
core
NHIN
Services that define the inte
r-
faces used to discover and e
x-
change health
and health
-
related
information. These se
r-
vices
provide the framework
for NHIN Profiles, which d
e-
scribe how to implement and combine services to support specific domains, such as consumer
preferences for information sharing or biosurveillance.

The CONNECT
architecture is broken down logically into two sections: a gateway and an adap
t-
er, each with corresponding services and components. The adapter incorporates those comp
o-
nents most likely to be customized or replaced by an organization to meet the requiremen
ts of its
existing systems, with the gateway incorporating those components most likely to remain u
n-
changed. In its default configuration, the gateway takes on responsibility for orchestrating the
processing of messages sent to the NHIN and messages receiv
ed from the NHIN, usually by i
n-
voking a sequence of gateway and adapter services. However, it can be configured so that an o
r-
ganization can take on the role of orchestration so that the gateway provides the glue that co
n-
nects an organization’s system to th
e NHIN. Alternatively, an organization may utilize the o
r-
chestration provided by the gateway, and replace specific components, such as an existing MPI.

NHIN Profiles
Consumer Preferences Profile

Store and exchange consumer
preferences for sharing of personal health
information
Other Profiles
Such as
biosurveillance
.
NHIN Services
Discovery Services

Subject Discovery

Authorized Case Follow
-
up

Query for Documents

NHIE Service Registry
Information Exchange Services

Retrieve Documents

Query Audit Log

Health Information Event Messaging
Messaging, Security, and Privacy Foundation
Messaging

Message Transport

Service Definition
Security

Public Key Infrastructure

Encryption

Digital Signature
Authorization Framework

Requestor Authentication

Requestor Authorization

CONNECT Release 2.2

Page
2

Document Version 2.2

The web services implemented by
CONNECT
comprise

a set

of
APIs.
For exchanges

over the
NHIN,

the API com
prises

the
core NHIN
S
ervices and con
tent, specified by the NHIN service
interface specifications and conventions. All NHIEs and other NHIN
-
enabled systems commun
i-
cate and exchange information with each other using this API.

To facilitate creating
the

adap
ter, CONNECT defines another API, to be used to communicate
with the existing health information system that will use the CONNECT gateway. Where poss
i-
ble, this API
mirrors

the externally
-
facing

API used by the
gateway


i.e.,
implementing
the
NHIN specific
ations and conventions
.


In general, each component within the CONNECT gateway is implemented as a deployed web
service. Some of these web services are exposed externally facing the NHIN, while others are
exposed externally facing the adapter. Many web se
rvices are exposed only internally to the ot
h-
er gateway components. The interface between the gateway and adapter is decomposed into mu
l-
tiple web services based on functionality and conforming to the NHIN message specifications.
However, web services at th
e component level inside the gateway and adapter may use separate,
simplified formats.

The view of the CONNECT architecture differs for handling messages from the NHIN versus
messages that originate
in
an organization’s existing system and are targeted for

delivery to the
NHIN. The following two diagrams illustrate the CONNECT architecture from the point of view
of messages received from the NHIN and sent to the NHIN, respectively.

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
3

Document Version 2.2



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 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
4

Document Version 2.2

For messages to the NHIN, an existing organization’s system is responsib
le for initiating the
message, perhaps as the result of a request by a provider using an application, or generated a
u-
tomatically upon an admission or the access or storage of patient data. The triggering event for
sending the message is completely controll
ed by the organization’s systems, but the handling and
orchestration of the message is primarily under the control of the CONNECT gateway.

The CONNECT gateway supports two mechanisms for bypassing the built
-
in orchestrated pr
o-
cessing of messages normally
performed by the gateway. For messages to the NHIN, the gat
e-
way supports a pass
-
through mechanism. Interfaces to some internal components are exposed
externally and can therefore be accessed directly by an adapter that wishes to send a message to
the NHIN,

but manage orchestration itself. In this case, “proxy components” accept the assertion
passed through the pass
-
through interface and convert it to a SAML assertion, and pass the me
s-
sage on to the NHIN. For messages from the NHIN, the gateway also supports

a mechanism for
bypassing orchestration. This functionality is implemented using a set of internal components
that work together, as illustrated at the right.
A message receiver receives the inbound
message from the NHIN, and calls the a
p-
propriate orchest
ration component in the
default configuration, or takes the message
SAML assertion information and passes
them directly to the adapter wit
h
out orche
s-
tration.


Interfaces exposed externally and used by NHIN to send messages to the CONNECT gateway
include: S
ubject Discovery to maintain subject correlation, Document Query and Document R
e-
trieve to locate and access patient information, Subscription Management and Notification Pr
o-
cessing to manage the publish/subscribe mechanism, Audit Reporting to access audit
records for
requests and information access, and UDDI Update Manager which receives change notifications
from the NHIN UDDI server as part of managing service endpoints. Interfaces exposed externa
l-
ly by the gateway and facing the adapter include: Patient C
orrelation to provide access to patient
correlations, Subject Discovery, Document Query and Document Retrieve, Subscription Ma
n-
agement and Notification Processing, Audit Reporting, and “Pass Through” implemented as a set
of interfaces that provide access t
o the pass
-
through mechanism that bypasses orchestration. The
UDDI Update Manager is not implemented in this release of CONNECT.

Internal NHIN
Message Orchestrator
NHIN Message
Receiver
Adapter Interface
Pass
-
Through
Choice of path
based on configuration.

CONNECT Release 2.2

Page
5

Document Version 2.2

1

Document

Roadmap

Each new reader of
the
CONNECT

Software Architecture

should begin at this
Document

Roadmap
. For both new and returning readers, the Roadmap describes how the
document

is o
r-
ganized so that a reader with specific interests can f
ind the desired information quickly and d
i-
rectly, without having to read the
document

cover
-
to
-
cover.

A gray box with distinctive type containing a “
CONTENTS OF THIS SECTION
” description is pr
o-
vided at the beginning of most sections and subsections through
out this document. The contents
of these brief notes serve as a quick
-
reference overview, both for readers of the document and
maintainers that may be adding material to it, correcting content or updating entries.

1.1

Document Management and Configuration Cont
rol Information

CONTENTS OF THIS SECTION:

This section identifies the version, release date, and other relevant
management and configuration control information associated

with the current version of this document
.
A document change history and/or an overv
iew of significant changes might be added to this section in
the future, but is not included at this time.

Revision

Released

Purpose

Scope

1.0

28 Jan 2009

Initial revision for software R
e-
lease

1.0
.

Entire document.

2.0

31 Mar 2009

Initial revision for
software R
e-
lease

2.0
.

Entire document.

2.1

7 Jul

2009

Revised to describe R
e-
lease

2.1, including all core
NHIN services and Enterprise
Service Components
.

Section

3

Architecture Views
.

2.2

29 Sep 2009

Revised to describe Release

2.2
which incorporates SAML and
message encryption in
add
i-
tional interfaces
.

Diagrams in Section


2.2.1

System
Overview
, and
minor
description

changes

and WSDL additions

throughout Section

3

Architecture
Views
.


CONNECT
Release

2.
2

provides an additional

interface between the adapter and gateway

and to
replaceable components

that

include
s

SAML assertions

and utilize
s

TLS

for message encryption
.
Release

2.2
of the
CONNECT Software Architecture

includes updates to the archi
tecture di
a-
grams,

and

descriptions
of the interfaces

and WSDLs
to reflect those changes
.

There are no other
architectural changes.


CONNECT Release 2.2

Page
6

Document Version 2.2

This
document encom
passes items A013 and A042
from the
Contract Data Requirements List
.

1.2

Purpose and Scope

CONTENTS OF THIS SECTION:

The section explains this

document
’s overall purpose and scope, the
criteria for deciding which design decisions are
architectural (and therefore documented in th
is doc
u-
ment
), and which design decisions are non
-
architectural (and therefore documented elsewhere).

The
CONNECT Software Architecture

specifies the software architecture for Release

2.
1

of
the NHIN CONNECT gate
way and adaptor (hereafter referred to as CONNECT). This document
is meant to be all
-
inclusive. That is, all information regarding the software architecture may be
found in this document, with only minimal information being incorporated by reference to oth
er
documents. This organization is meant to simplify the reader’s access to the necessary info
r-
mation, as well as the writer’s task in maintaining this information, without having to reference a
large number of separate documents.

At the same time, this do
cument is meant to be minimalistic. It is not exhaustive in presenting all
of the
Unified Modeling Language

(UML) diagra
ms that might be included in software archite
c-
ture documentation
or associated software design documentation. Instead, it includes only
the
most important of views and diagrams that will enable the developer to sufficiently understand
the software architecture to work with it.

This document is also a living document. As CONNECT evolves through future releases, and as
it
makes its way into

the open source community, it will undergo changes that may include
changes to its architecture. This
document

will evolve with CONNECT to reflect thos
e changes.

Finally, this document is targeted at the stakeholder



management, architect, and developer



to
aid in developing a high
-
level familiarity with the CONNECT architecture as well as a more d
e-
tailed understanding to support implementation and development of the appropriate adapter to
existing health systems. To this end, it references some additiona
l materials that make up the
software development kit.

S
oftware architecture
.

The software architecture for a system is its structure, comprising sof
t-
ware elements, the externally
-
visible properties of those elements, and the relationship among
them [Bass
2003]. The concept of “externally visible” is meant to identify the assumptions d
e-
velopers, and the software elements they create, can make of an element that is part of the arch
i-
tect. Those assumptions might include the services the element provides, perf
ormance characte
r-
istics, fault handling, shared resource usage, and so on.

This definition provides the basic litmus test for what information is included in this
document
,
and what information is relegated to downstream documentation. Software design info
rma
tion
often finds its way into architecture documentation
. This
document

attempts to incorporate only
architectural information.

Elements and relationships.

The software architecture first and foremost embodies information
about how software elements rel
ate to each other. This means that this
document

specifically

CONNECT Release 2.2

Page
7

Document Version 2.2

omits details about elements that do not pertain to their interaction. Elements interact with each
other by means of interfaces that are partitioned into public and private parts. Software archi
te
c-
ture is concerned with the public side of this division, and the public interfaces will be doc
u-
mented in this
document

accordingly. On the other hand, private details of elements



details
having to do solely with internal implementation



are not archi
tectural and will not be doc
u-
mented here
.

Within the later sections of this
document
, these elements and relationships are
presented

prima
r-
ily using component diagrams and sequence diagrams. In addition, the Web Services Description
Language (WSDL) descrip
tions and XML schemas referenced in this
document

make up the full
description of the interfaces among elements.

Multiple views.

Systems can, and often do, comprise a complex structure best illuminated by
considering differing perspectives that illustrate
different properties. All perspectives are inhe
r-
ently related, and
taken
together describe the architecture as a whole. This
document

follows the
principle that documenting software architecture is a matter of documenting the relevant views
and then docume
nting information that applies to more than one view.

This
document

uses the primary services
and enterprise components
of CONNECT as the gui
d-
ance for its views. While this may not align with more traditional concepts associated with
views, it perhaps best

illustrates how the CONNECT product fits into the larger Nationwide
Health Information Network (NHIN). It therefore provides a convenient method for segmenting
the architecture into “functional views” that must be understood to use the corresponding se
r-
vi
ces.

None of the

services

alone
fully define

the architecture, although they all convey archite
c-
tural information

conveniently segmented into structures that are somewhat self
-
contained and
self
-
consistent.

These structures

will be represented
as services
and enterprise service components
in the views
of the software architecture that are provided in Section

3
,
Architecture Views
.

Behavior.

Although software architecture tends to focus on struc
tural information, behavior of
each element is part of the software architecture insofar as that behavior can be observed or di
s-
cerned from the point of view of another element. This behavior is what allows elements to i
n-
teract with each other, which is cl
early part of the software architecture and will be
documented
here as such
.

Behavior is documented
through the sequence diagram and
in the element catalog of each view.

1.3

How this Document Is Organized

CONTENTS OF THIS SECTION
: This section provides a narra
tive description of the major sections of
th
is document

and the overall contents of each. Readers seeking specific information can use this section
to help them locate it more quickly.

The organization of
the
CONNECT Software Architecture

is modeled after
that described by
the Software Engineering Institute (SEI) in
Documenting Software Architectures: Views and B
e-

CONNECT Release 2.2

Page
8

Document Version 2.2

yond

[Clements 2003]. The so
-
called V&B approach comprises descriptions of a set of relevant
views of architecture, along with information that ap
plies to more than one view or to the set of
as a whole. It is consistent with the
IEEE Recommended Practice for Architectural Description
of Software
-
Intensive Systems

[IEEE 2000], keeping in mind the desire to be all
-
inclusive and
minimalistic.

This
docu
ment

is organized into the following sections:



Executive Summary

contains a high
-
level overview of the system and its architecture d
e-
signed primarily
for the executive or less
-
technical reader, providing a high
-
level unde
r-
standing of the goals of the project and the most important architectural features.



Section

1
,
Document

Roadmap

(this section),
provides a roadmap and overview for this
document.

Every reader who wishes to find information relevant to the software archite
c-
ture should

begin by reading the Roadmap, which

describes how the document is org
a-
nized, how stakeholders are expected to use it, and where information may be found. The
Roadmap also provides information about the views that are used by this
document

to
communicate the software architecture.



Section
2
,
Architecture

Background
, explains why the

architecture is what it is. It
pr
o-
vides a system overview, establishing the context and goals for the architecture develo
p-
ment. It describes the background and rationale for the software architecture, explains the
constraints and influences that led to th
e current architecture, and describes the major a
r-
chitectural approaches that have been utilized in the architecture. It also includes info
r-
mation about evaluation or validation performed on the architecture to provide assurance
it meets its goals.



Section
3
,
Architecture Views
,
specifies
the software architecture.

Views specify el
e-
ments of software and the relationships between them. A view is a representation of one
or more structures present in the software (see Section

1.2
,
Purpose and Scope
).

This
document

comprises a multi
-
view approach of the architecture. However, unlike th
e
prescribed set of views advocated by models such as the “4+1 View Model” [Kruchten
1995], 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 s
e-
quence diagrams.



Section
4
,
Referenced Materials
, and
Section
5
,
Directory
, provide reference info
r-
mation for the reader. Section

4

provides look
-
up informatio
n for documents that are ci
t-
ed elsewhere in this
document
. Section

5

includes a glossary of terms

and

an acronym list
us
ed in this
document
.


CONNECT Release 2.2

Page
9

Document Version 2.2

1.4

Stakeholder Representation

CONTENTS OF THIS SECTION
: The list of stakehold
ers for the architecture
. ANSI/IEEE 1471
-
2000 r
e-
quires that at least the following stakeholders be considered: users, acquirers, developers, and maintai
n-
ers.

Eac
h stakeholder of a software system



customer, user, project manager, coder, analyst, tester,
and so on



is concerned with different characteristics of the system that are affected by its sof
t-
ware architecture.
Table
1
-
1

lists the stakeholders for CONNECT, along with their concerns that
may be addressed by information in this
document
.

Table
1
-
1

Stakeholder
s in the architecture and their concerns
that might be
addressed by this software architecture documentation
.

Acquirers

Federal Agencies

All Federal agencies involved in creating or using health
-
related information and
exchanging it, either as providers or

consumers of information, on the NHIN.

Concerns include whether the solution is flexible enough to be adapted to their e
x-
is
t
ing health information systems, and whether the system can be implemented on
budget and on schedule.

A
cquirers

Private Sector

Hosp
itals, integrated delivery networks (IDNs), regional and state health info
r-
mation exchanges, and non
-
geographic health information networks.

Concerns are largely the same as for Federal agencies. However, these organizations
may not have an existing health

information system and may be considering CO
N-
NECT during acquisition

or development

of a larger project.

Users

Providers (physicians, nurses, and their staff) and other individuals involved in the
delivery of health care; public health professionals and
other health professionals
involved in population health, including drug and device safety; consumers and p
a-
tients.

Concerns include, most importantly, that the system is reliable and available, and
that information is accurate when provided and remains se
cure during exchange,
with some concern on rapid response time.

Developers

and
M
aintainers

CONNECT project development staff as well as the open source community co
n-
tributing to the open source code base and/or implementing CONNECT for their
organizations
.

Concerns include whether the user and acquirer goals can be met, with an emphasis
on flexibility and extensibility.

Consumers

Private individuals with health information that is exchange
d

on the NHIN.

Concerns include those already listed as a user, wit
h a specific overriding concern
on security
and privacy
of their health information.



CONNECT Release 2.2

Page
10

Document Version 2.2

Within the NHIN, there are two organizations that
have been

convened to, collectively, represent
their stakeholders:



NHIN Collaborative

is a

collaborative, consensus
-
based group to facilitate development
of identified deliverables for the
Limited Production phase of the NHIN
. Participants i
n-
clude awardees of the NHIN Trial Implementation contracts, the Healthcare Information
Technology Standar
ds Panel (HITSP), the Certification Commission for Healthcare I
n-
formation Technology (CCHIT), Office of the National Coordinator for Health Info
r-
mation Technology (ONC), and National Institute of Standards and Technology (NIST).



Federal NHIN Consortium

is
a

cross
-
agency,
Federal Health Architecture

(FHA)
co
l-
laboration to create solutions to be used by the
Federal
agencies for health information
exchange inside and outside the
F
ederal
G
overnment. Members include all federal age
n-
cies involved in creating or u
sing health related information, with varying levels of pa
r-
ti
c
ipation in the solution delivery workgroups and funding the activities.

1.5

How a View Is Documented

CONTENTS OF THIS SECTION
: This section describes how the documentation for a view, found later in

this
document
, is structured and organized.

No matter the view, the documentation for it is placed into a standard organization, or template,
comprising six parts as described below. For the purposes of this
document
, each view is stru
c-
tured around a serv
ice. Taken together, all services describe the full functionality of CONNECT,
and their views the complete CONNECT architecture.
Figure
1
-
1

illustrates the standard te
m-
plate that is used for each view.

Each view includes:

1.

A
View Description

provides a brief overview of the service or enterprise component
described by this view an
d the functionality it provides. In some cases, a high
-
level se
r-
vice may be broken down into a number of services, and this overview describes that
breakdown and how these services relate to each other.

2.

The
Primary Presentation

shows the elements associate
d with a service or component
and the relationships among them. The primary presentation for each service in this
do
c-
ument

compri
ses a component

diagram as a static view the architecture and one or more
sequence diagrams as dynamic views of the architectur
e. The primary presentation for
e
n
terprise components may differ to best describe the component.

3.

The
Element Catalog

details the elements

depicted in the
component

and sequence di
a-
grams that make up the primary presentation, along with their properties and

interfaces. If
there are any elements or relationships that cannot reasonably be represented in the di
a-
grams making up the primary presentation, they are introduced and explained in this cat
a-
log.


CONNECT Release 2.2

Page
11

Document Version 2.2

4.

A
Context Diagram

shows how the portion of the system depic
ted in this view relates to
its environment and/or the rest of the system.

5.

A
Variability Guide

shows how one might exercise any of the variation points that are
part of the service or enterprise component shown in this view. In particular,
with
in this
docu
ment
, this variability might include the so
-
called “pass
-
through” mode for some se
r-
vices that is described in Section

2.2

Solution Background

below, or how to replace e
n-
terprise components.

6.

An
Architecture Background

or rationale explains why the design reflected in the view
came to be.


Figure
1
-
1

T
emplate for documenting a view as used in this
document
, comprising
a view description, graphical primary presentation, element catalog,
graphical context diagram, variability guide, and architecture bac
k-
ground.

1.
View
Description
2.
Primary Presentation
3.
Element
Catalog
Elements and Their Properties
Relations and Their Properties
Element Interf aces
Element
Behavior
4.
Context Diagram
5.
Variability
Guide
6.
Architecture Background
Design Rationale
Assumptions

CONNECT Release 2.2

Page
12

Document Version 2.2

In this
document
, the individual views of the architecture are preceded by a summary
component

diagram

and a summary context diagram
.
Th
e
s
e

diagram
s

comprises the union of the
component

diagrams of all the views documented
here

and an enterprise
-
level cont
ext for CONNECT, r
e-
spectively
,
to
provid
e

a reference context for each view.

1.6

Relationship to Other Documents

CONTENTS OF THIS SECTION:

This section describes the relationship between this
document

and ot
h-
er architecture documents, both system and software.

It also describes the relationship to other doc
u-
ments that can be found in the CONNECT SDK.

There are no other
architecture document
s that describe the CONNECT architecture.

However,
t
here are other documents that one would generally classify as part of s
oftware design docume
n-
tation that should b
e considered together with the architecture
in order to gain a full understan
d-
ing of how to implement CONNECT for your organization.
As of this release of this document
,
these documents

include:



CONNECT Release 2.
2

Interface Description Document (IDD)

that describe
s

the
web

services implemented by CONNECT

[FHA 2009
-
1
]
.



The Enterprise Architect UML model for CONNECT
Release 2.
2

that

functions as the u
l-
timate software
design document,

and captures the full architecture of CONNECT

[FHA
2009
-
2]
.

There may be additional documents that describe the architecture for or otherwise document the
open
-
source reference implementations of the enterprise service components that have been co
n-
tribute
d and integrated with CONNECT. They are not included or referenced in this document.

1.7

Process for Updating this Document

CONTENTS OF THIS SECTION:

This section describes the process a reader should follow to report di
s-
crepancies, errors, inconsistencies, or

omissions from this
document
.
It

describes how error reports are
handled,
necessary contact information for submitting a report, and
how and when a submitter will be n
o-
tified of the issue’s disposition.

CONNECT exists primarily to support the health infor
mation exchange needs of all Federal
agencies with an interest in healthcare. The Federal Health Architecture program within the O
f-
fice of the National Coordinator for Health Information Technology
and its federal partners
co
n-
ti
nue

to contribute to the CON
NECT development in collaboration with the open source co
m-
munity. The CONNECT Program Management Office that oversees the development of CO
N-
NECT anticipates providing periodic releases that incorporate new development and new fun
c-
tionality as the need is i
dentified by members of the Federal NHIN Consortium. This effort will
be informed by open source community development, in some cases borrowing from that deve
l-
opment to incorporate new functionality, correct errors, and take advantage of other enhanc
e-
ments
.


CONNECT Release 2.2

Page
13

Document Version 2.2

FHA will maintain this document as well, releasing revisions and enhancements corresponding
to new releases of CONNECT.
D
iscrepancies, errors, inconsistencies, and omissions
in this do
c-
ument can be reported in the User Forum or Federal Partner Forum, as
appropriate, on the
CONNECT Community Portal at
http://www.connectopensource.org
. Questions and omissions
may be addressed in the comments to topics raised in the Forums. An attempt will be made to
address e
rrors i
n each subsequent release of this document
.


CONNECT Release 2.2

Page
14

Document Version 2.2

2

Architecture

Background

The CONNECT

architecture
is intended to provide a flexible, extensible
,

cross
-
platform solution
to enable

public and private organizations

to participate in the
Nationwide Health In
formation
Network
. The
CONNECT

architecture is a joint product of the CONNECT Program Manag
e-
ment Office, the
CONNECT
development team
,

and
Federal Partners

included in the Federal
NHIN Consortium
.

The following sections provide a very brief background on t
he NHIN and the needs that CO
N-
NECT is intended to address. They also describe the evolution of the architecture to that found in
this release and documented
here

to orient the reader concerning decisions.

2.1

Problem Background

CONTENTS OF THIS SECTION
: The su
b
-
parts of this section explain the constraints that provided the
significant influence over the architecture.

2.1.1

Goals and Context

CONTENTS OF THIS SECTION
: This section describes the goals and major contextual factors for the
software architecture. The
section includes a description of the role software architecture plays in the life
cycle, the relationship to system engineering results and artifacts, and any other relevant factors.

The Nationwide Health Information Network is being developed to provide
a secure, nationwide,
interoperable health information infrastructure that will connect providers, consumers, and others
involved in supporting health and healthcare. This critical part of the national health IT agenda
will enable health information to fol
low the consumer, be available for clinical decision making,
and support appropriate use of healthcare information beyond direct patient care so as to improve
health.

The NHIN seeks to achieve these goals by:



developing capabilities for standards
-
based, se
cure data exchange nationwide;



improving the coordination of care information among hospitals, laboratories, physicians
offices, pharmacies, and other providers;



ensuring appropriate information is available at the time and place of care;



ensuring that con
sumers’ health information is secure and confidential;



giving consumers new capabilities for managing and controlling their personal health
records as well as providing access to their health information from electronic health re
c-
ords (EHRs) and other sour
ces;


CONNECT Release 2.2

Page
15

Document Version 2.2



reducing risks from medical errors and supporting the delivery of appropriate, evidence
-
based medical care; and



lowering healthcare costs resulting from inefficiencies, medical errors, and incomplete
patient information.

To promote a more effective
marketplace, greater competition, and increased choice through a
c-
cessibility to accurate information on healthcare costs, quality, and outcomes, ONC is advancing
the NHIN as a “network of networks” which will connect diverse entities that need to exchange
health information, such as state and regional health information exchanges, integrated delivery
systems, health plans that provide care, personally
-
controlled health records, Federal agencies,
and other networks as well as the systems to which they, in tu
rn, connect.

The goal of CONNECT is to enable Federal agencies
,

and
potentially
other organizations
,

to
connect to and exchange health information with the NHIN by

leveraging their existing health
information systems
. The CONNECT project is being sponsored

by FHA to create a flexible,
open
-
source software solution that will enable both government and private entities to become
NHIN health information exchanges (NHIEs) or otherwise NHIN
-
enabled.

The CONNECT project was created primarily to support participat
ion of Federal agencies in the
NHIN. However, the solution is being released into the open source community to encourage its
use by other organizations as well.

2.1.2

Significant Driving Requirements

CONTENTS OF THIS SECTION
: This section describes behavioral an
d quality attribute requirements
(original or derived) that shaped the software architecture. Included are any scenarios that express dri
v-
ing behavioral and quality attribute goals.

The NHIN is built upon a core set of capabilities to enable nationwide hea
lth information e
x-
change encompassing a diverse set of organizations, technologies, and approaches. Core capabi
l-
ities include:



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



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



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



support se
cure information exchange;



support a common trust agreement that establishes the obligations and assurances to
which all NHIN participants agree;


CONNECT Release 2.2

Page
16

Document Version 2.2



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



support of harmonized stand
ards, which have been developed by voluntary consensus
standards bodies for exchange of health information among all such entities and ne
t-
works.

The core capabilities of the NHIN include both technical capabilities and business structures to
establish an i
nteroperable infrastructure among distinct networks and systems that allows for di
f-
ferent approaches and implementations, while ensuring secure information exchange as needed
for patient care and population health.

In addition to the core capabilities, the

Trial Implementation of the NHIN was required to su
p-
port a set of use cases as recommended by the American Health Information Community (AHIC)
in order to address key priority areas. These key priority areas include:



Consumer Empowerment


Registration an
d Medication History

to deploy a pre
-
populated, consumer
-
directed, and secure electronic registration summary, along with a
pre
-
populated medication history linked to it.



Consumer Access to Clinical Information

to allow a consumer the ability to receive
an
d access their clinical information, create provider lists, establish provider permissions,
and manage and transfer their personal health information between consumer
-
managed
repositories, providers, and/or other individuals and/or organizations which they

have
designated.



EHR


Lab Results Reporting

to deploy standardized, widely available, secure sol
u-
tions for accessing laboratory results and interpretations in a patient
-
centric manner for
clinical care.



Quality

to allow for the integration of data to sup
port quality measurement, feedback,
and reporting into EHRs, to allow the use the quality measures to support clinical dec
i-
sion making, and to allow the aggregation of quality information across multiple provi
d-
ers and entities to support public reporting o
f healthcare quality.



Medication Management

to provide exchange of necessary patient medication and a
l-
lergy information for providers, pharmacists, and consumers when healthcare is sought
and delivered.



Biosurveillance

to transmit essential ambulatory care

and emergency department visit,
utilization, and lab result data from electronically enabled health care delivery and public
health systems in standardized and anonymized format to authorized Public Health
Agencies in a timely manner.



Emergency Responder
EHR

to provide an emergency responder with an electronic
health record, comprising at a minimum demographic, medication, allergy, and problem
list information, that can be used to support emergency and routine health care activities.


CONNECT Release 2.2

Page
17

Document Version 2.2

More information on th
e NHIN and the priority use cases established by the AHIC can be found
at
http://www.hhs.gov/healthit/healthnetwork/background/
.

The core capabilities and use cases listed above drove th
e formalization of a set of ten core
NHIN services and interface specifications that must be supported by every organization wishing
to become an NHIE and participate in the NHIN. Those services are listed in
Table
2
-
1
.

Table
2
-
1

List of the core NHIN services and interface specifications that
make up the NHIN.

Service or

Interface Specification

Description

Subject
Discovery

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

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 for electronic health information and make this
log available to patients.

Authorization Framework

Articulate the justification for requesting electronic health
information for a patient.

Consumer Preferences Profile

Enable patients and their families or care providers (i.e., “co
n-
sumers”) to specify with whom they wish to share their ele
c-
tronic health
information.

Messag
ing

Platform

Provide secure messaging services for all communications
between NHIN
-
enabled health organizations.

Authorized Case Follow
-
up

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

Health Information
Event Messaging

Provide a publish

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


CONNECT Release 2.2

Page
18

Document Version 2.2

Service or

Interface Specification

Description

NHIE Service Registry

Registry services that enable NHIN
-
enabled health
organiz
a-
tions to discover the existence and connection information for
other NHIN
-
enabled health organizations.


This set of ten core NHIN services and interface specifications are the basis of the functionality
of CONNECT, and form the organization for t
he views found in Section

3
,
Architecture Views
,
of this
document
.

The CONNECT project was formed to support Federal agency participation in the NHIN. Initial
feedback to the project, primarily from
Federal Partners

of the Federal NHIN Consortium, esta
b-
lished the following additional requirements for the platfor
m:



Open platform.

The solution needs to leverage open source communities wherever po
s-
sible. The solution should be freely available to all, not only Federal agencies, and e
m-
brace an open
-
source approach.



Support for multiple operating systems.

The Federal agencies participating in the Fe
d-
eral NHIN Consortium have a wide variety of existing health system platforms


Wi
n-
dows, Linux, Solaris, mainframe, etc. Any OS
-
specific approach would not be viable in
this environment. While motivated by parti
cipating Federal agencies, this applies to non
-
Federal users as well.



Readily extensible.

Users will need to develop adapters to integrate existing systems
with CONNECT. This means that CONNECT would benefit from an extensible service
bus that can incorpor
ate service engines and protocol binding components to meet their
specific requirements.



Commercial support available.

Despite the desire to leverage an open
-
source approach
to maintaining CONNECT,
Federal Partners

made it clear that commercially
-
supported

implementations of the underlying CONNECT platform are critical for enterprise d
e-
ployment.

To meet the goals of CONNECT, the software must be fully functional out
-
of
-
the
-
box, while at
the same time being configurable and flexible to allow entities to cust
omize it to meet their ind
i-
vidual needs and their existing health information systems.

Additional use cases and priorities were established by the Federal NHIN Consortium and drove
demonstrations during the Trial Implementation of the NHIN. Some of the spe
cific agency prio
r-
ities NHIN might include



“Wounded Warrior”,



disability and long term care,


CONNECT Release 2.2

Page
19

Document Version 2.2



continuity of care across federal, tribal and community
-
based health providers,



pandemic and other natural disasters,



situational awareness,



post
-
market surveillan
ce of drugs and durable medical goods,



biosurveillance,



submission of evidence for disability and claims processing,



anonymized clinical data to support research,



quality metrics for determining value in health care, or



emergency response.

These use cases
again depend upon the core capabilities of the NHIN as a whole. Therefore, the
core NHIN services and interface specifications listed in
Table
2
-
1

remain the defining, high
-
level requirements for CONNECT.

It may be helpful to illustrate the roles and interactions of the core NHIN services through an e
x-
ample scenario. For our example, a
patient is receiving medical care through a VA hospital.
However, VA doctors wish to refer him for a consultation to a specialty outpatient facility that is
a member of a private
-
sector HIE. In the description of this scenario, the NHIN services are ide