Table of Contents

tastelessbeachInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 4 χρόνια και 1 μήνα)

134 εμφανίσεις

CONNECT Gateway XDR Service Design Document

Page
1


CONNECT Gateway XDR Service

Design Document


Author:
Kieran Dunne

Date:
7/20/2009


Table of Contents

1

Problem Description & Goals

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

3

2

High Level Design

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

3

2.1

Related Documents

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

4

3

Detail
ed Design

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

4

3.1

Asynchronous/Synchronous Web Service Communications

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

4

3.1.1

Synchronous Communications

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

4

3.1.2

Deferred Service
................................
................................
................................
....................

6

3.2

XDR Request

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

9

3.2.1

XDR Response

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

14

3.2.2

Error Handling

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

15

3.2.3

Reference XDR Adapter Implementation

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

18

3.2.4

CMS Adapter Implementation

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

18

3.2.5

Message Routing

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

18

4

XDR Components

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

19

4.1

Entity

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

20

4.1.1

RespondingGateway_ProvideAndRegisterDocumentSetRequest

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

21

4.2

NHIN Message Orchestration Component

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

23

4.3

NHIN

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

23

4.4

PolicyEngine

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

24

4.5

Audit Changes

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

24

4.6

Configuration Files

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

24

Appe
ndix A: WSDL and Schemas

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

24




CONNECT Gateway XDR Service Design Document

Page
2


Figure 1
-

Initiating Gateway Sequence Diagram

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

5

Figure 2 Responding Gateway Sequence Diagram

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

6

Figure 3
-

Sample XDR Request

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

14

Figure 4
-

RegistryResponse Class Diagram

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

14

Figure 5
-

Sample Successful XDR Response

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

15

Figure 6


RegistryError Class Diagram

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

16

Figure 7
-

Sample XDR Failure Response
................................
................................
................................
.....

18

Figure 8
-

XDR Deployment diagram

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

20

Figure 9
-

EntityXDRSecured.wsdl

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

21

Figure
10
-

RespondingGateway_ProvideAndRegisterDocumentSetRequest

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

22

Figure 11
-

RespondingGateway_ProvideAndRegisterDocumentSetSecured
Request

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

2
3

Figure 12
-

NHINXDR.wsdl

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

23




CONNECT Gateway XDR Service Design Document

Page
3


1

Problem Description & Goals


XDR describes the exchange of a set of a patient’s documents between healthcare providers, such as:
physicians, hospitals, special care networks or other healthcare professionals.

The purpose of the XDR specification
is to provide the ability to “push” data for a given patient from one
NHIE to another via configuration on the submission side. This is a different model of exchange than
because the sender decides who the data should go to and the receiver receives data
on an appropriate
available endpoint from the sources it authorizes.

Where XDS Registry/Repositories are not yet implemented or available for the exchange of information,
XDR is the viable approach.

The XDR Integration Profile is intended only for exchange of patient related medical documents and not
intended to address all cross
-
enterprise EHR communication needs.

This document will outline the implementation of a generic XDR transport mechanism within the
CONNECT Gateway as well as
provide a framework for writing custom XDR implementations within the
CONNECT architecture.

2

High Level Design


The NHIN CONNECT Gatewa
y is comprised of the services and components necessary to connect
the
organization

to the NHIN. For the most part, these components and services are intended to be
used as is without any change.

The Entity component
, which resides on the CONNECT gateway,

provides an interface that is called
by the
organization
. The Entity receives the call, and forwards to the
Message Orchestration Layer
(NHINCProxy). The Message Orchestration Layer is responsible for validating that the caller is
authorized to perform the

transaction, and if authorized forwards the message to the NHIN layer.
The NHIN layer is comprised of the components that face the NHIN.

The NHIN components receive the call from the NHIN, ensure that the transaction is authorized and
forwards to the Ada
pter layer. The Adapter Layer receives the message from the NHIN layer, and
forwards to the local
organization
. The CON
N
ECT team provides a light weight reference
implementation of the adapter layer, but the Adapter Layer is commonly overwritten by the NHI
E.

All communication between the gateway and adapter as well as the gateway and the swappable
core components
are

secured using both SAML and secure socket communication.

CONNECT Gateway XDR Service Design Document

Page
4


2.1

Related Documents

The following documents are referenced in this design document:



Th
e Document Submission Service Interface Specification, Version 1.1.0



Continuity Assessment Record and Evaluation (CARE) Health Information Exchange V 1.1.0

All related documents and supporting materials can be found on the CONNECT portal at
http://www.conn
nectopensource.org

3

Detailed Design

The XDR implementation will be broken into five primary web services


AdapterXDR,
AdapterComponentXDR, EntityXDR, NHINCProxyXDR and NHINXDR. This follows the CONNECT
architectural pattern for implementing NHIN services.

The XDR transaction will be initiated by one
gateway, referred to as the “Initiating Gateway”. The
initiating

gateway will send the document set to
another gateway, referred to as the “Responding Gateway”. The responding Gateway will process the
request
and send a response to the Initiating Gateway.

3.1

Asynchronous
/Synchronous

Web Service Communications


The XDR specification requires responding NHIEs to support both asynchronous and synchronous
communications.

CONNECT implements two versions of the Documen
t Submission Service. One is the Synchronous
version, and the other is a Deferred Service.

3.1.1

Synchronous Communications

3.1.1.1

Initiating Gateway

The sequence diagram depicted in Figure 1 below details the program flow from the Initiating Gateway’s
perspective:

CONNECT Gateway XDR Service Design Document

Page
5



Figure
1

-

Initiating Gateway Sequence Diagram

The Initiating Gateway receives the
RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest message
f
rom the
Organization

on the Entity Interface. The

RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest
Message wraps the IHE defined ProvideAndRegisterDocumentSetRequest
message
, and
contains
information on the NHIN Target
System

the request is to be sent to.

Once the Entity receives the r
equest
, it audits the incoming R
equest message. It then calls out to the
Policy Engine to check if
transaction is authorized
. If

authorized
, the Entity Service calls into the
NHINCProxy service.

There are two authorization requests; the first is if the organiza
tion is authorized
to call the XDR service. The second is whether the organization is authorized to share the particular
patient’s data with the remote organization.


The NHINCProxy service also audits the incoming

request
message
. Next, it queries the UD
DI server (via
Connection Manager) for the endpoint of the NHINXDR service on the target gateway.
A single

target
gateway is specified

in the NHINC Target Community

element in the
Provide

And

Register

Document

Set

Request
message.

CONNECT Gateway XDR Service Design Document

Page
6


3.1.1.2

Responding Gateway

The s
equence diagram in Figure 2 below depicts the program flow from the Responding Gateway’s
perspective.


Figure
2

-

Responding Gateway Sequence Diagram

The NHINXDR service on the local gateway (Responding Gateway) process the
Provi
deAndRegisterDocumentSet
-
b from the NHINCProxyXDR on the Initating Gateway. Upon receipt of
the of the message, the NHINXDR service logs the inbound request to the audit policy. Next it queries
the Policy Engine on the local gateway to see if the inbound r
equest is authorized. If it’s valid, it forwards
the request to the Adapter.
The Adapter will validate the inbound request message. If valid, it will
process message. If invalid, it will send a Rejected message to the Initiator.


3.1.2

Deferred Service


3.1.2.1

Initiat
ing Gateway

The sequence diagram in Figure 3 below depicts the program flow from the Initiating Gateway’s
perspective.


CONNECT Gateway XDR Service Design Document

Page
7



Figure
3

The Initiating Gateway receives the
RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest
message from the Organization
on the Entity Interface. The

RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest
Message wraps the IHE defined ProvideAndRegisterDocumentSetRequest message, and contains
information on the NHIN Target System the requ
est is to be sent to.

Once the Entity receives the request, it audits the incoming Request message. It then calls out to the
Policy Engine to check if transaction is authorized. If authorized, the Entity Service calls into the
NHINCProxy service. There a
re two authorization requests; the first is if the organization is authorized
to call the XDR service. The second is whether the organization is authorized to share the particular
patient’s data with the remote organization.


The NHINCProxy service also
audits the incoming request message. Next, it queries the UDDI server (via
Connection Manager) for the endpoint of the NHINXDRR
equest

service on the target gateway. A single
target gateway is specified in the NHINC Target Community element in the
Provide

A
nd

Register

Document

Set

Request message.

CONNECT Gateway XDR Service Design Document

Page
8


3.1.2.2

Responding Gateway


The sequence diagram in Figure 2 below depicts the program flow from the Responding Gateway’s
perspective.


Figure
4

The NHINXDR
Request

service on the local gateway (
Responding Gateway) process the
ProvideAndRegisterDocumentSet
-
b from the NHINCProxyXDR on the Initating Gateway. Upon receipt of
the of the message, the NHINXDR service logs the inbound request to the audit policy. Next it queries
the Policy Engine on the
local gateway to see if the inbound request is authorized. If it’s valid, it forwards
the request to the Adapter.

The Adapter will process the message.

After the message has been processed, the Adapter will initiate the Response sequence, as depicted in
figure 5 below.

CONNECT Gateway XDR Service Design Document

Page
9



Figure
5

The
Responding Gateway’s
Adapter will
call the EntityXDRResponse service on its local gateway. The
Entity service will audit the incoming message and call the policy engine. If the transaction is authori
zed,
it will forward to the NHINCProxy service. The proxy service will again audit the incoming message, and
query the UDDI for the NHINXDRResponse service of the Initiating Gateway. The Proxy service will then
call the NHINXDRResponse service of the Initi
ating Gateway.

3.2

XDR Request

The Provide and Register ITI
-
41 Request is a collection of metadata and documents transferred between
a Document Source and a Document Recipient using a single ebXML SubmitObjectsRequest.

This request contains:

a)

One XDS Document

Entry Metadata object per document

b)

One XDS Submission Set Metadata object

c)

Zero or more documents; each document is represented by an XDSDocumentEntry object in the
metadata.


Sample XDR Request:

Note, there are two headers present in the sample request,
one for Synchronous and one for
Asynchronous communications
. If implemented as is, this will require two different webservices being
implemented. A request was sent to the Spec Factory group on 1/27/2009 to use the same Action for
both Asynchr
onous and S
ynchronous messages.




<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap
-
envelope"


xmlns:a="http://www.w3.org/2005/08/addressing">


<!
--
The following header applies for a Synchronous Web Services Exchange Request


Please note that a soap message can only have one header section.
--
>


<s:Header>



<a:Action s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
-
b</a:Action>



<a:MessageID>urn:uuid:6d296e90
-
e5dc
-
43d0
-
b455
-
7c1f3eb35d83</a:MessageID
>

CONNECT Gateway XDR Service Design Document

Page
10




<a:ReplyTo>




<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>



</a:ReplyTo>



<a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/IHEXDSRepository.svc</a:To>


</s:Header>


<!
--
The following DISABLED header applies for an

Asynchronous Web Services Exchange
Request


Please note that a soap message can only have one header section.


<s:Header>


<a:Action s:mustUnderstand="1">urn:ihe:iti:2008:ProvideAndRegisterDocumentSet
-
bAsync</a:Action>


<a:MessageID>urn:uuid:6
d296e90
-
e5dc
-
43d0
-
b455
-
7c1f3eb35d83</a:MessageID>


<a:ReplyTo>


<a:Address>http://192.168.2.4:9080/XdsService/DocumentSourceReceiver.svc</a:Address>


</a:ReplyTo>


<a:To s:mustUnderstand="1">http://localhost:2647/XdsService/IHEXDSRepository.s
vc</a:To>


</s:Header>
--
>


<s:Body>


<ProvideAndRegisterDocumentSetRequest



xsi:schemaLocation="urn:ihe:iti:xds
-
b:2007
../../schema/IHE/XDS.b_DocumentRepository.xsd"



xmlns="urn:ihe:iti:xds
-
b:2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema
-
instance"



xmlns:lcm="urn:oasis:names:tc:ebxml
-
regrep:xsd:lcm:3.0"



xmlns:rim="urn:oasis:names:tc:ebxml
-
regrep:xsd:rim:3.0"



xmlns:rs="urn:oasis:names:tc:ebxml
-
regrep:xsd:rs:3.0">



<lcm:SubmitObjectsRequest>



<rim:RegistryObjectList>




<rim:ExtrinsicObject id=
"Document01" mimeType="text/xml"





objectType="urn:uuid:7edca82f
-
054d
-
47f2
-
a032
-
9b2a5b5186c1">





<rim:Slot name="creationTime">






<rim:ValueList>







<rim:Value>20051224</rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Slot name="languag
eCode">






<rim:ValueList>







<rim:Value>en
-
us</rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Slot name="serviceStartTime">






<rim:ValueList>







<rim:Value>200412230800</rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Slot
name="serviceStopTime">






<rim:ValueList>







<rim:Value>200412230801</rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Slot name="sourcePatientId">






<rim:ValueList>







<rim:Value>ST
-
1000^^^&amp;1.3.6.1.4.1.21367.2003.3.9&amp;ISO<
/rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Slot name="sourcePatientInfo">






<rim:ValueList>







<rim:Value>PID
-
3|ST
-
1000^^^&amp;1.3.6.1.4.1.21367.2003.3.9&amp;ISO</rim:Value>







<rim:Value>PID
-
5|Doe^John^^^</rim:Value>







<rim:Va
lue>PID
-
7|19560527</rim:Value>







<rim:Value>PID
-
8|M</rim:Value>







<rim:Value>PID
-
11|100 Main
St^^Metropolis^Il^44130^USA</rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Name>






<rim:LocalizedString value="Physical"/>





</rim:Name>

CONNECT Gateway XDR Service Design Document

Page
11






<rim:Description/>





<rim:Classification id="cl01"






classificationScheme="urn:uuid:93606bcf
-
9494
-
43ec
-
9b4e
-
a7748d1a838d"






classifiedObject="Document01">






<rim:Slot name="authorPerson">







<rim:ValueList>








<rim:Value>Gerald Smitty<
/rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Slot name="authorInstitution">







<rim:ValueList>








<rim:Value>Cleveland Clinic</rim:Value>








<rim:Value>Parma Community</rim:Value>







</rim:ValueList>






</rim:Slot>






<
rim:Slot name="authorRole">







<rim:ValueList>








<rim:Value>Attending</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Slot name="authorSpecialty">







<rim:ValueList>








<rim:Value>Orthopedic</rim:Value>







</rim:ValueList>






</rim:Slot>





</rim:Classification>





<rim:Classification id="cl02"






classificationScheme="urn:uuid:41a5887f
-
8865
-
4c09
-
adf7
-
e362475b143a"






classifiedObject="Document01" nodeRepresentation="History
and Physical">






<rim:Slot name="codingS
cheme">







<rim:ValueList>








<rim:Value>Connect
-
a
-
thon
classCodes</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="History and Physical"/>






</rim:Name>





</rim:Classification>





<rim:Clas
sification id="cl03"






classificationScheme="urn:uuid:f4f85eac
-
e6cb
-
4883
-
b524
-
f2705394840f"






classifiedObject="Document01"






nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101">






<rim:Slot name="codingScheme">







<rim:ValueList>








<
rim:Value>Connect
-
a
-
thon
confidentialityCodes</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="Clinical
-
Staff"/>






</rim:Name>





</rim:Classification>





<rim:Classification id="cl04"






classifi
cationScheme="urn:uuid:a09d5840
-
386c
-
46f2
-
b5ad
-
9c3699a4309d"






classifiedObject="Document01" nodeRepresentation="CDAR2/IHE
1.0">






<rim:Slot name="codingScheme">







<rim:ValueList>








<rim:Value>Connect
-
a
-
thon
formatCodes</rim:Value>







</r
im:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="CDAR2/IHE 1.0"/>






</rim:Name>

CONNECT Gateway XDR Service Design Document

Page
12






</rim:Classification>





<rim:Classification id="cl05"






classificationScheme="urn:uuid:f33fb8ac
-
18af
-
42cc
-
ae0e
-
ed0b0bdb91e1"






cl
assifiedObject="Document01"
nodeRepresentation="Outpatient">






<rim:Slot name="codingScheme">







<rim:ValueList>








<rim:Value>Connect
-
a
-
thon








healthcareFacilityTypeCodes</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="Outpatient"/>






</rim:Name>





</rim:Classification>





<rim:Classification id="cl06"






classificationScheme="urn:uuid:cccf5598
-
8b07
-
4b77
-
a05e
-
ae952c785ead"






classifiedObject="Document01" nodeRepresentation="Gen
eral
Medicine">






<rim:Slot name="codingScheme">







<rim:ValueList>








<rim:Value>Connect
-
a
-
thon
practiceSettingCodes</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="General Medicine"/>






<
/rim:Name>





</rim:Classification>





<rim:Classification id="cl07"






classificationScheme="urn:uuid:f0306f51
-
975f
-
434e
-
a61c
-
c59651d33983"






classifiedObject="Document01" nodeRepresentation="34108
-
1">






<rim:Slot name="codingScheme">







<rim
:ValueList>








<rim:Value>LOINC</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="Outpatient Evaluation
And Management"/>






</rim:Name>





</rim:Classification>





<rim:ExternalIdentifier
id="ei01" registryObject="Document01"






identificationScheme="urn:uuid:58a6f841
-
87b3
-
4a3e
-
92fd
-
a8ffeff98427"






value="SELF
-
5^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO">






<rim:Name>







<rim:LocalizedString
value="XDSDocumentEntry.patientId"/>






</rim:Name>





</rim:ExternalIdentifier>





<rim:ExternalIdentifier id="ei02" registryObject="Document01"






identificationScheme="urn:uuid:2e82c1f6
-
a085
-
4c72
-
9da3
-
8640a32e42ab"






value="1.3.6.1.4.1.21367.2005.3.9999.32">






<rim:Name>







<
rim:LocalizedString
value="XDSDocumentEntry.uniqueId"/>






</rim:Name>





</rim:ExternalIdentifier>




</rim:ExtrinsicObject>




<rim:RegistryPackage id="SubmissionSet01">





<rim:Slot name="submissionTime">






<rim:ValueList>







<rim:Value>200412
25235050</rim:Value>






</rim:ValueList>





</rim:Slot>





<rim:Name>

CONNECT Gateway XDR Service Design Document

Page
13







<rim:LocalizedString value="Physical"/>





</rim:Name>





<rim:Description>






<rim:LocalizedString value="Annual physical"/>





</rim:Description>





<rim:Classification
id="cl08"






classificationScheme="urn:uuid:a7058bb9
-
b4e4
-
4307
-
ba5b
-
e3f0ab85e12d"






classifiedObject="SubmissionSet01">






<rim:Slot name="authorPerson">







<rim:ValueList>








<rim:Value>Sherry Dopplemeyer</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Slot name="authorInstitution">







<rim:ValueList>








<rim:Value>Cleveland Clinic</rim:Value>








<rim:Value>Berea Community</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Slot name="authorRole">







<rim
:ValueList>








<rim:Value>Primary Surgon</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Slot name="authorSpecialty">







<rim:ValueList>








<rim:Value>Orthopedic</rim:Value>







</rim:ValueList>






</rim:Slot>





</rim:Classif
ication>





<rim:Classification id="cl09"






classificationScheme="urn:uuid:aa543740
-
bdda
-
424e
-
8c96
-
df4873be8500"






classifiedObject="SubmissionSet01"






nodeRepresentation="History and Physical">






<rim:Slot name="codingScheme">







<
rim:ValueList>








<rim:Value>Connect
-
a
-
thon
contentTypeCodes</rim:Value>







</rim:ValueList>






</rim:Slot>






<rim:Name>







<rim:LocalizedString value="History and Physical"/>






</rim:Name>





</rim:Classification>





<rim:ExternalIdent
ifier id="ei03" registryObject="SubmissionSet01"






identificationScheme="urn:uuid:96fdda7c
-
d067
-
4183
-
912e
-
bf5ee74998a8"






value="1.3.6.1.4.1.21367.2005.3.9999.33">






<rim:Name>







<rim:LocalizedString
value="XDSSubmissionSet.uniqueId"/>






</
rim:Name>





</rim:ExternalIdentifier>





<rim:ExternalIdentifier id="ei04" registryObject="SubmissionSet01"






identificationScheme="urn:uuid:554ac39e
-
e3fe
-
47fe
-
b233
-
965d2a147832"






value="3670984664">






<rim:Name>







<rim:LocalizedString
val
ue="XDSSubmissionSet.sourceId"/>






</rim:Name>





</rim:ExternalIdentifier>





<rim:ExternalIdentifier id="ei05" registryObject="SubmissionSet01"






identificationScheme="urn:uuid:6b5aea1a
-
874d
-
4603
-
a4bc
-
96a0a7b38446"






value="SELF
-
5^^^&amp;1.3.6
.1.4.1.21367.2005.3.7&amp;ISO">






<rim:Name>







<rim:LocalizedString
value="XDSSubmissionSet.patientId"/>

CONNECT Gateway XDR Service Design Document

Page
14







</rim:Name>





</rim:ExternalIdentifier>




</rim:RegistryPackage>




<rim:Classification id="cl10" classifiedObject="SubmissionSet01"





classificationNode="urn:uuid:a54d6aa5
-
d40d
-
43f9
-
88c5
-
b4633d873bdd"/>




<rim:Association id="as01" associationType="HasMember"





sourceObject="SubmissionSet01" targetObject="Document01">





<rim:Slot name="SubmissionSetStatus">






<rim:ValueList>







<rim:Value>Original</rim:Value>






</rim:ValueList>





</rim:Slot>




</rim:Association>



</rim:RegistryObjectList>



</lcm:SubmitObjectsRequest>



<Document
id="Document01">UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</Document>


</ProvideAndRe
gisterDocumentSetRequest>

</s:Body>

</s:Envelope>

Figure
6

-

Sample XDR Request

3.2.1

XDR Response

The response

from the XDR transaction
is identical to the
RegistryResponse

message specified in
ebRS
.


Figure
7

-

RegistryResponse Class Diagram

The Response contains:

a)

Status: Possible values are: Success | Failure

b)

Zero or more RegistryError elements



Status

RegistryErrorList element

Result

Success

May be present. If present will contain one or more RegistryError
elements with warning severity, none with error severity

All metadata and documents were
successfully registered

Failure

Present, contains one or more RegistryError elements. At least
one has error severity, others may have warning severity.

Metadata and documents not registered

Table
1

-

RegistryResponse Statuses


class Rs
«XSDcompl exType»
RegistryResponse
«XSDel ement»
+
ref_el ement2: Regi stryErrorLi st [0..1]
+
ResponseSl otLi st: ri m:Sl otLi stType [0]
«XSDattri bute»
+
request Id: anyURI
+
status: ri m:referenceURI
CONNECT Gateway XDR Service Design Document

Page
15


Sample Succ
ess

Response:

<
s:Envelope xmlns:s="http://www.w3.org/2003/05/soap
-
envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">


<!
--
The following header applies for a Synchronous Web Services Exchange
Response


Please note that a soap message can only have one head
er section.
--
>


<s:Header>



<a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
-
bResponse</a:Action>



<a:RelatesTo>urn:uuid:6d296e90
-
e5dc
-
43d0
-
b455
-
7c1f3eb35d83</a:RelatesTo>


</s:Header>


<
!
--
The following DISABLED header applies for an Asynchronous Web Services
Exchange 'Reply'


Please note that:


1. An Asynchronous Web Services Exchange 'Reply' is in reality a new
Request sent by the Receiver.


Refer to TF
-
2:Appendi
x V for more information on Asynchronous Web
Services Exchange.


2. A soap message can only have one header section


<s:Header>


<a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
-
bAsyncResponse</a:Action>


<a:Messa
geID>urn:uuid:D6C21225
-
8E7B
-
454E
-
9750
-
821622C099DB</a:MessageID>



<a:RelatesTo>urn:uuid:6d296e90
-
e5dc
-
43d0
-
b455
-
7c1f3eb35d83</a:RelatesTo>



<a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentSourceReceiver.
svc</a:To>


</s:Header>
--
>



<s:Body>



<rs:RegistryResponse
xsi:schemaLocation="urn:oasis:names:tc:ebxml
-
regrep:xsd:rs:3.0
../../schema/ebRS/rs.xsd" status="urn:oasis:names:tc:ebxml
-
regrep:ResponseStatusType:Success" xmlns:rs="urn:oasis:names:tc:ebxml
-
regrep:xsd:rs:3.0" xmlns:xsi="h
ttp://www.w3.org/2001/XMLSchema
-
instance"/>


</s:Body>

</s:Envelope>

Figure
8

-

Sample Successful XDR Response

3.2.2

Error Handling

Error Codes are reported back to the Initiating Gateway through the RegistryError element.
A
RegistryResp
onse can contain zero or many RegistryError elements.


CONNECT Gateway XDR Service Design Document

Page
16



Figure
9



RegistryError

Class Diagram

The
XDS
error codes relevant to this transaction are listed in the following table:


Error Code

Description

XDSMissingDocument

XDSDocumentEntry exists in
metadata with no corresponding
attached document

XDSMissingDocumentMetadata

MIME package contains MIME part with
Content
-
Id header not found in metadata

XDSNonIdenticalHash

Document being
sent

was a duplicate
(uniqueId already in registry) but hash does
not match.

XDSRegistryDuplicateUniqueIdInMessage

A UniqueId value was found to be used
more than once within the submission.

XDSRegistryBusy

Too much activity at the gateway for this
service

XDSRegistryMetadataError

Error detected in metadata. Actor name
indicates where error was detected.

XDSUnknownPatientId

Patient ID referenced in metadata is not
known to the
Receiving NHIE


class Rs
«XSDtopLev...
RegistryErrorList
«XSDcompl exType»
RegistryErrorList::
ComplexTypeClass1
«XSDattri bute»
+
hi ghestSeveri ty: ri m:referenceURI
«XSDel ement»
+
ref_el ement1: Regi stryError [1..*]
«XSDtopLevel El ement»
RegistryError
«XSDcompl exType»
RegistryError::
ComplexTypeClass2
«XSDattri bute»
+
codeContext: stri ng
+
errorCode: stri ng
+
l ocati on: stri ng
+
severi ty: ri m:referenceURI
stri ng
«XSDsi mpl eType»
string
«XSDextensi on»
CONNECT Gateway XDR Service Design Document

Page
17


Error Code

Description

XDSPatientIdDoesNotMatch

XDS specifies where patient IDs must
match between documents,
submission sets, and folders. This
error is thrown when the patient ID is
required to match and does not.

Table
2

-

XDS Error Codes


Sample Failure Response:

<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap
-
envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">


<!
--
The following header applies for a Synchronous Web Services Exchange
Response


Please note that a soap message can only have one header section.

--
>


<s:Header>



<a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
-
bResponse</a:Action>



<a:RelatesTo>urn:uuid:6d296e90
-
e5dc
-
43d0
-
b455
-
7c1f3eb35d83</a:RelatesTo>


</s:Header>


<!
--
The following DISABLED header applies for a
n Asynchronous Web Services
Exchange 'Reply'


Please note that:


1. An Asynchronous Web Services Exchange 'Reply' is in reality a new
Request sent by the Receiver.


Refer to TF
-
2:Appendix V for more information on Asynchronous Web
Services Exchange.


2. A soap message can only have one header section


<s:Header>


<a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
-
bAsync
Response</a:Action>


<a:MessageID>urn:uuid:D6C21225
-
8E7B
-
454E
-
9750
-
821622C099DB</a:MessageID>



<a:RelatesTo>urn:uuid:6d296e90
-
e5dc
-
43d0
-
b455
-
7c1f3eb35d83</a:RelatesTo>



<a:To
s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentSourceReceiver
.
svc</a:To>


</s:Header>
--
>


<s:Body>



<rs:RegistryResponse
xsi:schemaLocation="urn:oasis:names:tc:ebxml
-
regrep:xsd:rs:3.0
../../schema/ebRS/rs.xsd" status="urn:oasis:names:tc:ebxml
-
regrep:ResponseStatusType:
Failure
" xmlns:rs="urn:oasis:names:tc:ebxml
-
regrep:xsd:rs:3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema
-
instance
"
>



<
rs:
RegistryErrorList

highestSeverity="urn:oasis:names:tc:ebxml
-
regrep:ErrorSeverityType:Error">

<
rs:
RegistryError

errorCode="XDSPatientIdDoesNotMatch"

codeContext="Patient
I
D in Document (Document1) does not match Submission Set"

location=""

severity="urn:oasis:names:tc:ebxml
-
regrep:ErrorSeverityType:Error"/>

CONNECT Gateway XDR Service Design Document

Page
18


<
rs:
RegistryError

errorCode="XDSRegistryMetadataError"

codeContext="RegistryPackage (SubmissionSet) is not labeled as
SubmissionSet
or Folder"

location=""

severity="urn:oasis:names:tc:ebxml
-
regrep:ErrorSeverityType:Error"/>

</
rs:
RegistryErrorList>

</

rs:RegistryResponse
>


</s:Body>

</s:Envelope>

Figure
10

-

Sample XDR Failure Response

3.2.3

Reference XD
R
Adapter
Implementation


The CONNECT Development Team will provide a reference implementation of the XDR Adapter. This
adapter will accept the incoming Request, validate the document submission

and log the meta
-
data to
the standard output. (Server.log on

Glassfish Application Servers).

The mimeTypes supported by the local gateway will be defined in adapter.properties under the new key

XDSb
MimeTypes”. This will be a pipe “|” delimited list of supported mime types. The reference XDR
adapter will read this list and compare it against the incoming request.


3.2.4

CMS Adapter Implementation


To accommodate the C
-
HIEP implementation of XDR, the CMS
team will need to create a webservice
that services the wsdl ‘
AdapterComponentXDR.wsdl
’. The internalConnectionInfo.xml file entry for the
adaptercomponentxdr service will need to be updated to point to the overridden service.

The NHIN service will call t
he AdapterComponentXDR service the inbound request message has been
audited, and the transaction authorized. The AdapterComponentXDR service will accept an inbound
ihe:ProvideAndRegisterDocumentSet
-
b_Message

and return an
urn:ihe:iti:2007:ProvideAndRegiste
rDocumentSet
-
bResponse
.

3.2.5

Message

Routing

During the development of Document Submission, a need for the ability to route the Provide and
Register document arose. It was decided to route this information based on the field ‘
intendedRecipient

slot, which is
in the metadata for the ProvideAndRegisterDocument message. The routing functionality
is implemented using Spring Framework.

The reference
implementation

of the XDR adapter automatically looks into the intendedRecipient field.
It then loads configuration
data from the
file XDRConfiguration.xml. This file will link intendedRecipients
to bean implementations. If no match is found, a default bean is returned. Note, it is possible to define
multiple beans for the same intendedRecipient. All XDR Beans will imp
lement the class
gov.hhs.nhinc.xdr.routing
.XDRRouting. The SpringFramework file that defines these beans is
NhinXDRRoutingProxyConfig.xml.

CONNECT Gateway XDR Service Design Document

Page
19


Please refer to the CONNECT Installation and Configuration manual for information on configuring
XDRConfiguration.xm
l



4

XDR Components


CONNECT Gateway XDR Service Design Document

Page
20



Figure
11

-

XDR Deployment diagram

4.1

Entity

The CONNECT Entity service will implement WSDL EntityXDRSecured.wsdl, shown in the diagram below.

CONNECT Gateway XDR Service Design Document

Page
21



Figure
12
-

EntityXDR
Secured
.wsdl

This is
a secured wsdl, that defines a single operation,
RespondingGateway_ProvideAndRegisterDocumentSet
-
b
(). The operation takes in a single parameter of
type
RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest
. It returns the same object
as the XDR transaction,
urn:ihe:iti:2007:ProvideAndRegisterDocumentSet
-
bResponse
.

The purpose of the Entity is to provide an interface that can be called by the Initiating Gateway’s
Organization
. The Entity interface will in t
urn call the NHINCProxyXDR service.

To follow the CONNECT architectural pattern, a proxy that services an unsecured version of the wsdl will
also be provided. The wsdl will allow the initiator to pass in the assertion information via the Assertion
class.
The proxy will then convert the assertion information to a SAML header, and call the secured
version of the wsdl.

4.1.1

RespondingGateway_ProvideAndRegisterDocumentSetRequest


There will be two versions of the CONNECT
ProvideAndRegisterDocumentSetRequest

object
, a secured
and unsecured version. The difference between

the two is the NhincCo
mmon::Assertion element is
present in the unsecured but not in the secured. In the Secured wsdl, the assertion information is
transmitted via the SAML token. Both elements are

present in the CONNECT schema file,
NhincCommonProxy.xsd.

The Assertion type will contain the security credentials that allow the
initiator

of the XDR transaction to
assert that he is authorized to perform the transaction. The NhinTarget
System

will contain the home
community id (HCID) of the target of the XDR transaction
, or optionally the URL to send the request to
.



cmp WSDL/Webservice
«WSDL»
EntityXDRSecured.wsdl
+
Respondi ngGateway_Provi deAndRegi sterDocumentSet-b(Respondi ngGateway_Provi deAndRegi sterDocumentSet-b_Message, Respondi ngGateway_Provi deAndRegi sterDocumentSet-bResponse_Message*)
CONNECT Gateway XDR Service Design Document

Page
22



Figure
13

-

RespondingGateway_ProvideAndRegisterDocumentSetRequest


class RespondingGateway_ProvideAndRegisterDocumentSetRequ...
«XSDcompl exType»
NhincCommon::Assertion
«XSDel ement»
+
authori zed: bool ean
+
dateOfBi rth: stri ng
+
expl anati onNonCl ai mantSi gnature: stri ng
+
haveSecondWi tnessSi gnature: bool ean
+
haveSi gnature: bool ean
+
haveWi tnessSi gnature: bool ean
+
SSN: stri ng
+
uni quePati entId: stri ng [1..*]
«XSDcompl exType»
NhincCommonProxy::RespondingGateway_ProvideAndRegisterDocumentSetRequest
«XSDel ement»
+
asserti on: Assert i on
+
nhi nTargetSystem: Nhi nTargetSystem
+
Provi deAndRegi sterDocumentSetRequest: Provi deAndRegi sterDocumentSetRequest
«XSDcompl exType»
XDS.b_DocumentRepository::
ProvideAndRegisterDocumentSetRequest
«XSDel ement»
+
ext_ref_2: Submi tObj ectsRequest
«XSDcompl e...
NhincCommon::
NhinTargetSystem
«XSDel ement»
+
url: stri ng
«XSDcompl exType»
NhincCommon::
HomeCommunity
«XSDel ement»
+
descri pti on: stri ng
+
homeCommunityId: stri ng
+
name: stri ng
+homeCommunity
1..1
+homeCommunity
1..1
1..1
CONNECT Gateway XDR Service Design Document

Page
23



Figure
14

-

RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest


4.2

NHIN Message Orchestration Component

The purpose of this service is to

accept messages from the Entity, and to

make a direct call to the NHIN.

4.3

NHIN

The NHIN layer
will service the wsdl N
HINXDR.wsdl. NHINXDR.wsdl is a secured version of
XDS.b_DocumentRepository.wsdl
, the wsdl provided by IHE. The wsdl defines two operations,
ProvideAndRegisterDocumentSet
-
b
() and
RetrieveDocumentSet
(). The XDR service will only implement
the operation
ProvideAndRegisterDocumentSet
-
b
().


Figure
15

-

NHINXDR.wsdl

The NHIN layer will receive the
ProvideAndRegisterDocumentSet
-
b
() call from the NHIN. It will audit the
inbound request, and authorize the transaction by calling the Pol
icy engine. If valid, the service will
forward the request on to the Adapter.


class RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequ...
«XSDcompl exType»
XDS.b_DocumentRepository::
ProvideAndRegisterDocumentSetRequest
«XSDel ement»
+
ext_ref_2: Submi tObj ectsRequest
«XSDcompl exType»
NhincCommonProxy::
RespondingGateway_ProvideAndRegisterDocumentSetSecuredRequest
«XSDel ement»
+
nhi nTargetSystem: Nhi nTargetSystem
+
Provi deAndRegi sterDocumentSetRequest: Provi deAndRegi sterDocumentSetRequest
«XSDcompl e...
NhincCommon::
NhinTargetSystem
«XSDel ement»
+
url: stri ng
«XSDcompl exType»
NhincCommon::
HomeCommunity
«XSDel ement»
+
descri pti on: stri ng
+
homeCommunityId: stri ng
+
name: stri ng
+homeCommunity
1..1
1..1

cmp WSDL/Webservice
«WSDL»
NHINXDR.wsdl
+
DocumentReposi tory_Provi deAndRegi sterDocumentSet-b(Provi deAndRegi sterDocumentSet-b_Message, Provi deAndRegi sterDocumentSet-bResponse_Message*)
+
DocumentReposi tory_Retri eveDocumentSet(Retri eveDocumentSet_Message, Retri eveDocumentSetResponse_Message*)
CONNECT Gateway XDR Service Design Document

Page
24


4.4

PolicyEngine

The PolicyEngine is an existing CONNECT component. To accommodate the XDR service, the
PolicyEngine would be modified to transform the incoming
ProvideAndRegister
DocumentSetRequest

to
a CheckPolicyRequest.

The PolicyEngine mapping document, located on the CONNECT portal will be updated to reflect these
changes.

4.5

Audit Changes

The only expected updates to the Audit facility required to implement XDR would be the cr
eation of
additional data transformation methods to convert the
ProvideAndRegisterDocumentSetRequest

message to the generic audit messages that are stored in the Audit Repository.

4.6

Configuration Files

Additional service connections and properties need to be

added to existing files such as
internalConnectionsinfo.xml
, adapter.properties
and gateway.properties in order to support the new
XDR service


Appendix A: WSDL and Schemas

If there are WSDL and schema modifications necessary for this design, include them

below.


NhincCommonProxy.xsd
NhincCommonEntity.xsd
NhincCommonAdapter.xsd

NhincProxyXDRSecured.wsdl
AdapterComponentXDR.wsdl
NhincProxyXDR.wsdl
AdapterComponentXDRSecured.wsdl
EntityXDRSecured.wsdl
EntityXDR.wsdl
NhinXDR.wsdl