Architecture and Workflow Diagrams

joeneetscompetitiveSecurity

Nov 3, 2013 (3 years and 7 months ago)

149 views

FOUO

Supporting VLER Phase 1a

Architecture and Workflow Diagrams

Please note that these diagrams are “early drafts” that
have not been validated with all stakeholders.


The intent of distributing these documents is to have a
foundation upon which to discuss and formulate the
final version.

-

Steve Steffensen

FOUO

CDR

Adapter

PAWS

Gateway

AHLTA Inbox

Middle Tier

Application Tier

VLER Phase 1a:

Basic Tiered Structure

Data Tier

FOUO

DATA TIER

Central Data Repository (CDR
)

PAWS

Windows 2008 Server

LCS Configuration / IIS

Dell R710 Server

Services
:


.NET web services

Licenses
:


Windows 2008 Server


Norton Anti
-
virus



:


:

SSL Certificate (DISA)

HP
-
UX Superdome

.NET web services

via AHLTA Data Layer

and XML Proxy

Services
:


Oracle database


CDR+ (ODBC)


3M HDD


3M data model schema


Master Member Index (MMI)


e*Gate


Tuxedo


XML Proxy


:


:

FOUO

2.1 Gateway

Red Hat Linux

Open ESB/Glassfish

Dell R710 Server

Adapter

Red Hat Linux

Open ESB/Glassfish

Dell R710 Server

PAWS

Windows 2008 Server

LCS Configuration / IIS

Dell R710 Server

Services
:


CAL (Common Access Layer)


Assembly Service


Template Manager Service


Template Repository Service


Policy Engine


Identity Management Service


BOS (Bus Orchestration Service)


Document Cache

Services
:


Subject Discovery


Document Query


Document Retrieve


Subscription Management


Subscription Repository


UDDI Update Manager


Patient Correlation Repository


Audit Repository/Reporting


Connection Manager

Licenses
:


Red Hat Linux


FHA/
DoD

Adapter (BSD Open Source)


Sun Open ESB (CDDL Open Source)


Sun Glassfish (CDDL/GNU Open Source)


Sun
MySQL

(GNU Open Source)


OpenSSO

(CDDL Open Source)


JSF 1.2 (Open Source)


Jericho PDP (Open Source)

Licenses
:


Red Hat Linux


FHA Gateway (BSD Open Source)


Sun Open ESB (CDDL Open Source)


Sun Glassfish (CDDL/GNU Open Source)


Sun
MySQL

(GNU Open Source)

Services
:


.NET web services

Licenses
:


Windows 2008 Server


Norton Anti
-
virus



:


:

MIDDLE TIER

AHLTA Inbox
html code

r
unning on Adapter

NHIN
-
defined API

PAWS
-
defined API

non
-
SAML

HTTP

SSL

SSL Certificate (ONC/FHA)

SSL Certificate (ONC/FHA)

SSL Certificate (DISA)

DMZ

FOUO

APPLICATION TIER

Adapter

Red Hat Linux

Open ESB/Glassfish

Dell R710 Server

Services
:


CAL (Common Access Layer)


Assembly Service


Template Manager Service


Template Repository Service


Policy Engine


Identity Management Service


BOS (Bus Orchestration Service)


Document Cache

Licenses
:


Red Hat Linux


FHA/
DoD

Adapter (BSD Open Source)


Sun Open ESB (CDDL Open Source)


Sun Glassfish (CDDL/GNU Open Source)


Sun
MySQL

(GNU Open Source)


OpenSSO

(CDDL Open Source)


JSF 1.2 (Open Source)


Jericho PDP (Open Source)

SSL Certificate (ONC/FHA)

AHLTA Inbox

HTTP Interface

Programming Environment
:


HTML


JavaScript


Java

Code physically resides

on Adapter server

with direct access via

link in AHLTA client.

EUD Required File Updates
:

C:
\
Program Files
\
CH2CW
\
Bin
\
Dod.CHCSII.DataLayer.Mappers.dll

C:
\
Program Files
\
CH2CW
\
Bin
\
ExternalApps.config

C:
\
Program Files
\
CH2CW
\
Bin
\
GenericWebBrowser.config


FOUO

VLER Phase 1a

Patient Consent & Correlation

Early Draft Version

FOUO

VLER Phase 1a: Initial DoD Correlation of DoD Consenting Patients

Paper
-
based

NHIN consent

NMCSD

provider

Pre
-
selected

SD patient

XACML

Conversion of

Paper
-
based consent

to XACML XML document

XACML

Adapter

XDS

Repo.

XACML document is

stored in the adapter

XDS repository

PIX ID of the patient from the

external facility is correlated and

stored with the DoD PIX ID

for each responding external facility

External

PIX ID

Gateway

“acknowledge”

message is

returned to DoD

No matching and/or

consenting patient found

KP

DoD announcement to NHIN

gateways of updated XDS data entry

Gateway

Adapter

DoD

1

2

3

4

5

Gateway

Internal PIX ID of

matching patient

is returned to DoD

Matching patient found

with positive consent

VA

5

6

Data fields sent for correlation can be site
-
specific. For Phase 1a, the DoD will send
the following information:


First Name


Last Name


Social Security Number


Gender


Date of Birth

Although manual process is shown
above, for Phase 1a, it is expected that
HPA&E will identify and pre
-
select a
small group of patients for the project.
This small number of patients will need
to be contacted and consent obtained.
Consent for Phase 1a will be “Opt In” or
“Opt Out” without granularity.

TRICARE office in coordination with
HPA&E office will need to provide a list
of consenting patients to development
team in order to create appropriate
XACML documents prior to 11/30/2009.

Now the DoD can exchange information via the
NHIN with VA, but not KP. If the patient later
consents at KP, then KP will send an NHIN
announcement and

assuming patient
consented at DoD to allow KP to view DoD
data

a correlation is made within DoD.
Thereafter, DoD and KP will be able to
exchange information via NHIN on that patient.

VA will perform #6 internally to
VA systems as well.

The gateway PIX will be checked each
time an NHIN request is made. If there is
a match, the request is forwarded to the
Adapter. If no match, the gateway
returns “Acknowledge” response.




Gateway

PIX

FOUO

Gateway

DoD

1

DoD receives NHIN announcement

from KP wishing to correlate patient

Gateway

2

DoD validates if patient exists in the CDR
using PAWS, then validates consent in
Gateway XDS repository. If patient
exists and has consented to exchange
information with KP, gateway PIX is
updated.

Adapter

PAWS

CDR

Gateway

DoD

3

DoD sends KP the PIX ID

that correlates with patient in CDR

VLER Phase 1a: Initial DoD Correlation of KP Consenting Patients

From now on, every time KP makes a
request of DoD for that patient, they will
send the above PIX ID. The Adapter
policy engine will confirm correlation still
exists between KP
-
DoD in the gateway
PIX and send full request to Adapter for
dynamic assembly of documents.

KP announcement

of patient data

sent to DoD for

correlation

FOUO

VLER Phase 1a

NMCSD Provider Workflow

FOUO

CDR

DISA

Multiple External

NHIN
-
compliant

Gateways

proxy service

proxy service

LCS

Adapter

NMCSD

DMZ

PAWS

SSL

HTTP/S

3.3 EUD

VLER Phase 1a: NMCSD Workflow

Step 1

Step 1:

Dr. Smith at NMCSD clicks the “VLER
Documents” link located in the menu tree
of AHLTA under the patient’s folder list.
This triggers an HTTP request to the LCS.
The LCS redirects request to the adapter
via a secure tunnel to DISA. This request
delivers the NHIN document search page
back to the Generic Web Browser in
AHLTA.


Assumptions:

1.
Adapter will host web pages required
for AHLTA Inbox.

2.
Adapter will check the following
permissions (in order):

1.
Physician has permission to view
VLER documents. If not, “access
denied” page will be displayed.

2.
Patient is part of pilot and has
consented to have record
transmitted on NHIN. If not,
“access denied” page will be
displayed.

firewall

firewall

hub/router

hub/router

firewall

2.1 Gateway

NHIN

AHLTA 3.3 Client

“VLER Documents”

Main NHIN Search Screen

Provider view

outbound

inbound

FOUO

CDR

LCS

Adapter

NMCSD

DMZ

PAWS

SSL

HTTP/S

3.3 EUD

VLER Phase 1a: NMCSD Workflow

Step 2

Step 2:

Dr. Smith clicks “Search” and a request is
made to the adapter which passes the
request to the gateway. The gateway
makes several requests for documents to
all sites in which the patient has been
previously correlated. Metadata on the
documents requested is passed back for
Dr. Smith to review.


Assumptions:

1.
The gateway is responsible for making
multiple requests to all NHIN
participants where the patient has
been previously correlated.

2.
Currently, communication between
adapter and gateway is HTTP. May
require VPN tunnel to make secure
until HTTPS can be implemented at a
later date.

3.
DoD B2B functionality will exist in the
NHIN gateway. There is no
requirement for additional DoD B2B
hardware to be installed by external
NHIN partners.

firewall

firewall

hub/router

hub/router

Multiple External

NHIN
-
compliant

Gateways

DISA

AHLTA 3.3 Client

“VLER Documents”

Search Results Screen

Provider view

-

SAML / SSL

proxy service

firewall

2.1 Gateway

-

Non
-
SAML / HTTP

NHIN

proxy service

multiple requests to all external gateways

where patient has been previously correlated

outbound

inbound

FOUO

CDR

DISA

LCS

Adapter

NMCSD

DMZ

PAWS

SSL

HTTP/S

3.3 EUD

VLER Phase 1a: NMCSD Workflow

Step 3

Step 3:

Dr. Smith clicks on desired C32 document.
A second request is sent to the
adapter/gateway which redirects to the
specific external partner to retrieve the
C32 document for Dr. Smith to review.


Assumptions:

1.
All documents retrieved will be stored
in the Adapter cache. Future versions
of NHIN may require this document be
sent to HAIMS repository or CDR.

firewall

firewall

hub/router

hub/router

AHLTA 3.3 Client

“VLER Documents”

C32 View & Results

Provider view

-

SAML / SSL

proxy service

firewall

2.1 Gateway

-

Non
-
SAML / HTTP

NHIN

proxy service

Specific External

NHIN
-
compliant

Gateway (e.g. VA)

single request to external gateway

containing document requested by Dr. Smith

outbound

inbound

FOUO

VLER Phase 1a

VA/KP Provider Workflow

FOUO

CDR

Step 1:

VA provider initiates NHIN query for
specific patient. Patient has been
previously correlated and is known to exist
in DoD. Adapter dynamically assembles
and stores C32, calculates hash total, and
returns only metadata (of those
documents) to VA.


Assumptions:

1.
Gateway will know all previously
correlated patients in this pilot and will
permit adapter access only if patient in
above scenario has been correlated.

2.
Adapter will leverage PAWS to
dynamically compile C32 from data in
CDR tables.

3.
Adapter will compile C32 but not send
until specifically requested by VA (C32
will be temporarily held in adapter
cache).

4.
Temporarily stored C32 will remain in
the adapter cache for 72 hours unless
retrieved by requesting organization.
Any C32 that is sent will need to be
stored longer than 72 hours.

VLER Phase 1a: VA/KP Workflow

Step 1

NHIN

Specific External

NHIN
-
compliant

Gateway (e.g. VA)

-

SAML / SSL

VistaWeb

Client

“VLER Documents”

Search Results Screen

Provider view

DISA

Adapter

DMZ

PAWS

proxy service

firewall

2.1 Gateway

-

Non
-
SAML / HTTP

proxy service

outbound

inbound

FOUO

Step 2:

VA provider selects DoD C32 from list of
documents returned from NHIN. VA
gateway initiates request to DoD gateway.
DoD gateway forwards request to DoD
adapter which dynamically assembles C32
(again) and compares hash total to
previously assembled C32. Regardless,
the newly assembled version of the C32
document is sent to the VA and is stored in
the adapter cache. (if hash totals match
between the two documents that were
assembled


between step 1 and 2


then
the new document does not have to be
stored because the same version already
exists in adapter cache).


Assumptions:

1.
Adapter cache will store any sent C32
for specific amount of time (as defined
by NHIN standards).

VLER Phase 1a: VA/KP Workflow

Step 2

Specific External

NHIN
-
compliant

Gateway (e.g. VA)

VistaWeb

Client

“VLER Documents”

C32 Viewer and Results

Provider view

CDR

NHIN

-

SAML / SSL

DISA

Adapter

DMZ

PAWS

proxy service

firewall

2.1 Gateway

-

Non
-
SAML / HTTP

proxy service

outbound

inbound

FOUO

VLER Phase 1a

Handoff Sequence

FOUO

Box A:

Initial Development &
Integration


Leveraging the TATRC
Congressional Special Interest (CSI)
project with Conemaugh Health
System as well as the TATRC
Common Development Environment
(CDE) contracts, Northrop Grumman
has been contracted to support DoD
NHIN activity.


Specific Tasks
:

Integrate, test , and document FHA
CONNECT Gateway (
ver

2.1) with
TATRC DoD adapter, AHLTA Inbox
GUI, and PAWS.

Box B:

JMIS Functional Testing



The Joint Medical Information
System (JMIS) office will test a series
of functional use cases to ensure
initial development/integration efforts
produce expected outcomes.


Specific Tasks
:

Functional testing based on pre
-
defined use
-
cases and
recommended workflows.


Operating under a best
-
case
scenario, functional testing should
occur in parallel to the FHA
DIACAP/Security testing. It is hoped
that JMIS can use the same
environment in Box A located at
TATRC/NGIT.

Box C:

FHA/TMA IA
DIACAP/Security Testing


The Federal Health Architecture
Group (FHA) will work coordinate
with the TMA Information Assurance
(IA) office to perform all necessary
DIACAP and security testing and
provide supporting documentation as
required by TMA IA. TMA IA office
will accept this testing and
documentation and facilitate over
-
the
-
shoulder review during FHA
testing timeline.


Specific Tasks
:

DIACAP/Security testing and
validation. TMA IA will perform over
-
the
-
shoulder validation and
acceptance of FHA DIACAP
certification process.

Box D:

DHIMS/DISA Installation &
Implementation


DHIMS will coordinate handoff of
completed NHIN/VLER product from
FHA/TMA IA to DISA Montgomery for
installation & implementation.
DHIMS/DISA will also coordinate
with NMCSD (Balboa Navy Hospital)
to facilitate appropriate installation &
implementation. DHIMS will
coordinate with DISA to ensure long
-
term support and sustainment of
completed product.


Specific Tasks
:

Coordinate installation,
implementation, support, and
sustainment of completed
NHIN/VLER product.

NHIN/VLER Phase 1a: Product Handoff

A

B

C

D

1

1

2

redundant

backup

FOUO

1

NHIN/VLER Phase 1a: Hardware Locations

A

B

C

D

1

2

FHA Gateway (2.1)

DoD Adapter

PAWS

QA CDR

NGIT Chantilly

FHA Gateway (2.1)

DoD Adapter

PAWS

FHA Gateway (2.1)

DoD Adapter

PAWS

FHA Gateway (2.1)

DoD Adapter

PAWS

DISA CDR

Montgomery

VPN

VPN

undefined location

redundant

backup

Chantilly, VA

Chantilly, VA

Montgomery, AL

TATRC/NGIT Environment?