X12 Document Submission Service Specification v02_08012011x

voraciousdrabSoftware and s/w Development

Dec 14, 2013 (3 years and 10 months ago)

143 views

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
1

of
18











Nationwide Health Information Network (
N
HIN
)



Service
Interface Specification



X12 Document Submission
Service Specifications



V
0
.
3


08
/
01
/20
11

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
2

of
18


Contributors

Name

Organization

Area

Melanie Combs
-
Dyer

CMS

Specification

Daniel Kalwa

CMS

Specification

Manoj Chaganti

CMS/QSSI

Specification

Seonho Kim

CHIC/MEDNET

Specification

Mary Lynn Bushman

Wellpoint

Specification

Donna Jones

CMS/Signature Consulting

Specification

Kevin Castellow

CMS/BNETI

Specification

Raja Kailer

CMS/BNETI

Specification


Document Change History

Version

Date

Changed By

Items Changed Since Previous Version

0.1

07/15/2011

Manoj Chaganti

Initial Draft

0.2

07/26/2011

Manoj Chaganti,
Mary Lynn, Kevin
Castellow, Raja
Kailer, Gary
Beaty, Donna
Jones

Review and updated the standards.

Provided the sample message

Updated the WSDL

Updated the Metadata

0.3

08/01/2011

Raja Kailer, Gary
Beaty, Manoj
Chaganti, Donna
Jones

Reviewed the content a
nd suggested change to schema,
5010, section 3.x




























5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
3

of
18


Document Approval

Version

Date

Approved By

Role






5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
4

of
18


Table of Contents

1

PREFACE

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

5

1.1

I
NTRODUCTION

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

5

1.2

I
NTENDED
A
UDIENCE

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

5

1.3

F
OCU
S OF THIS
S
PECIFICATION

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

5

1.4

R
EFERENCED
D
OCUMENTS AND
S
TANDARDS

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

5

1.5

D
EVIATIONS FROM
S
TANDARDS

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

6

1.6

R
ELATIONSHIP TO
O
THER
NHIN

S
PECIFICATIONS

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

6

2

INTERFACE DESCRIPTIO
N

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

6

2.1

D
EFINITION
................................
................................
................................
................................
.....................

7

2.2

T
RANSACTIO
N
S
TANDARD

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

7

2.3

A
SSUMPTIONS

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

7

2.4

T
ECHNICAL
P
RE
-
CONDITIONS

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

7

2.5

T
ECHNICAL
P
OST
-
CONDITIONS

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

7

3

INTERFACE DEFINITION

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

8

3.1

CAQH

CORE

X12

T
RANSACTION
:

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

8

3.2

M
ULTIPLE
D
OCUMENTS
S
UBMISSION

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

8

3.3

S
YNCHRONOUS
/D
EFERRED
M
ESSAGING

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

8

3.3.1

Synchronous Messaging Workflow

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

8

3.3.2

Deferred Messaging Workflow

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

9

3.4

CORE

M
ETADATA
E
LEMENTS

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

9

3.5

C
ONNECTIVITY
R
ULE

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

10

3.6

SO
AP

+

WSDL

BASED
M
ESSAGE
E
NVELOPE

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

10

3.7

R
EAL
-
TIME
D
EFERRED
M
ODE
(R
EAL
-
TIME
M
ODE
,

R
EAL
-
TIME
P
ROCESSING
M
ODE
)

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

10

3.8

B
ATCH
-
TIME
(B
ATCH
-
TIME
M
ODE
,

B
ATCH
-
TIME
P
ROCESSING
M
ODE
)

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

10

3.9

SAML

A
SSERTION BASED
U
SER
A
UTHENTICATION AND
A
UTHORIZATION

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

10

3.9.1

National Provider Identifier (NPI) Attribute

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

10

3.9.2

NPI Provider Name Attribute

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

11

4

ERROR HANDLING

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

11

5

AUDITING

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

11

APPENDIX A:

SAMPLE MESSAGES

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

12

S
AMPLE
CORE

SOAP

+

WSDL

R
EAL
-
TIME
R
EQUEST

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

12

S
AMPLE
CORE

SOAP

+

WSDL

R
EAL
-
TIME
R
ESPONSE

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

12

APPENDIX B:

WSDL
................................
................................
................................
................................
..........

13

6

CORE PHASE

II COMPLIANT XML SCH
EMA SPECIFICATION

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

16


5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
5

of
18


1

Preface


1.1

Introduction

This NwHIN X12 Document Submission Service Interface Specifications constitute the core services of an
operational Nationwide Health Information Network (NwHIN) with
Accredited Standards Committee (ASC)
ANSI
X12 Transactions. They are intended to provide
a standard set of service interfaces that enable the
exchange of interoperable health information amongst a group of peer nodes referred to Nationwide
Health Information Exchanges (NHIEs).


NwHIN already defines services such as Document Submission servi
ce for IHE XDR Specification. This
specification will add the
Accredited Standards Committee (ASC) ANSI X12

Document Submission
Service in addition to
XDR Document Submission Service and these other services
. It is important to
note that
t
he functional s
ervices of this
specification

rest on a foundational set of defined core services
that includes the following:


1.

NHIN Trial Implementations Message Platform Service Interface Specification,

2.

NHIN Trial Implementations Authorization Framework Service Interfa
ce Specification,

3.

NHIN Trial Implementations Audit Log Query Service Interface Specification,

4.

NHIN Trial Implementations NHIE Service Registry Interface Specification

5.

NHIN Trial Implementations Authorized Case Follow
-
Up Service Interface Specification


1.2

In
tended Audience

The primary audience for the NHIN
X12 Document Submission

Service Interface Specifications is the
individuals responsible for implementing software solutions that realize these interfaces for a NHIE

that
will exchange Accredited Standards C
ommittee (ASC) ANSI X12 transactions
. After reading this
specification, one should have an understanding of the context in which the service interface is meant to
be used, the behavior of the interface, the underlying reference standards and specification
s, the
Web
Services Description Language (
WSDLs) used to define the service, any
Extensible Markup Language

(XML) schemas used to define the content, and what “compliance” means from an impl
ementation testing
perspective.



1.3

Focus of this Specification

This

docume
nt defines the NwHIN X12
Document Submission Service Interface Specification
.

The
purpose of this specification is to provide the ability to “push” data for a given patient from one NHIE to
another via configuration on the
X12
submission side. Thi
s is a different model of exchange than
subscription (see the NHIN Trial Implementations Health Information Event Messaging Service
Specification for details on this approach) 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 (refer to the
Authorization Framework Service Interface Specification).

Also, this is different payload and model of
exchange compare to XDR Document Submission based on ASC X12 Tran
sactions.


1.4

Referenced Documents and Standards

The following documents and standards were referenced during the development of this specification
.
Specific deviations from or constraints upon these standards are
identified below.

1)

Org/SDO name:

CAQH

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
6

of
18


Referenc
e # / Spec Name:

C
AQH C
ORE
Phase
II Connectivity Rule

Version #:

v
2
.2.0 (March 28, 2011
)

NHIN
Deviations or Constraints:




Use of TLS

1.0 as per Messaging Platform Specification



Use of
Base64 encoding of payload
s that have non
-
printable characters

for SOAP Real
-
Time
1



Use of
SAML Assertions

as per
NHIN
Authorization Framewor
k Specification

Underlying Specs:



CAQH CORE Phase I and II
Connectivity
Operating Rules

Link:

http://www.caqh.
org/pdf/CLEAN5010/270
-
v5010.pdf

1.5

Deviations from Standards

S
pecific deviations from or constraints from the above
-
mentioned standards are identified.


This specification adopts the Real
-
Time Request/
Response
transaction Mode. Batch Processing Mode
is
not su
pported

in this specification.

For details, please refer CAQH CORE Phase II Connectivity Rule,
Version 2.2.0


1.6


Relationship to
O
ther NHIN Specifications


In some cases, the data exchanged between NHIEs will involve the communication of individually
identifiable health information (defined in
45 CFR Parts 160, 162, and 164
). When individually identifiable
information is exchanged, then each NHIE must have a

common understanding of the patient’s identity.


This specification is related to
other

NHIN specifications

as described below
:



Messaging Platform


specifies a base set of messaging standards and web service protocols
which must be implemented by each NHIN node and applies to all transactions including this
transaction. All NHIN messages sent between NHIN systems are SOAP messages over HTTP
using we
b services and all messages must be encrypted and digitally signed.



Authorization Framework



defines the exchange of metadata used to characterize each NHIN
request. The purpose of that exchange is to provide the responder with the information needed
to

make an authorization decision for the requested function.



Services Registry


enables computer systems to discover and consume services. For NHIN,
the Service
s

Registry is a UDDI

web
-
se
rvices
registry.

T
his registry lists NHIN services which in
t
his
case will
consist of

a single entry for e
ndpoints that will respond to
X12
messages
as
defined
herein.


2

Interface Description




1

Version 2.2.0 of CORE Connectivity Rule does not have MTOM support for SOAP Real
-
Time.

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
7

of
18


2.1

Definition

In this
i
nterface

specification
,

a

“document”

refers to the format of clinical data as it is transferred between
NHIEs,

and not as it is stored within an NHIE or electronic health record (EHR) system. A NHIE and its
participating organizations may store clinical data in whatever format or repository it chooses. Specifically,
a “document” transferred between NHIEs need not

meet the criteria for persistence, stewardship, etc.

“Initiating NHIE” refers to a document source NHIE that initiates X12 document submission transaction for
one or more available documents
on a particular patient
.

“Receiving NHIE” refers to document re
cipient NHIE that receives X12 document submission transaction.


2.2

Transaction S
tandard

This in
terface identifies the
CAQH CORE Phase II Connectivity Rule

as the standard for

NHIN X12
Document Submission Service Specification
.


2.3

Assumptions


The following assumptions
underlie

this specification:



There is
no central or federated service that performs transactions across multiple HIO
s
/HIHs
.



T
he requesting NHIN Gateway shall be responsible for using the UDDI Service
s

Registry

to
determine which
of these
Service
s

they will call for any specific
X12 transaction

request
message.



Security Assertion Markup Language (
SAML
)

Authorization assertion(s) will be included in the
request

message as specified by the Messaging Platform specification.
.



This specification requires use of CORE
Simple Object Access Protocol (
SOAP
)

+ WSDL
Method
(Envelop
e

Standard B)



This specification does not require use of CORE HTTP MIME Multipart (Envelop
e

Standard A)

2.4

Technical Pre
-
conditions

The following technical
pre
-
conditions exist for this interface specification:



Responding Medicaid HIOs must publish
in the NHIN
U
DDI Services Registry data containing
descriptive and
technical information about their NHIN Medicaid Eligibility Verification service.



The Medicaid
HIO to which the query will be directed have been selected and applicable service
end points have been identified using the NHIN UDDI Services Registry.



The
Requesting
HIO
s ha
ve

a
pre
-
established trust relationship
with the Medicaid HIO they are
calling,
t
hat enables
them to participate in an

eligibility verification data

exchange.



The Initiating
HIO

must include SAML assertion containing user
-
level credentials sufficient to
enable authentication and/or authorization by the receiving Medicaid system.

2.5

Techn
ical Post
-
con
ditions

The following technical post
-
conditions will result after the execution of this interface specification:



Errors encountered will be handled

and included in the response as specified in

CAQH CORE
Phase II Connectivity Rule.



T
he response

to this
request is a payload containing a
n

X12 Transaction

message and some
metadata describing the transaction

such as Payload ID, Sender ID, Receiver ID, etc
.

(required
CORE Metadata will be described in section 3.3.2 in detail
)
.



5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
8

of
18



3

Interface

Definition

3.1

CAQH CORE
X
12 Transaction
:

This transaction is d
escribed in
CAQH CORE Phase II Connectivity Rule

Section
4.
The figure below
illustrates the actors and transaction

(Any Transactions)

involved in

CORE SOAP + WSDL Real
-
time
Request/
Response
transaction.




3.2

Multiple Documents Submission


This interface supports the ability to include multiple documents for a single patient in a single Submission
Transaction


3.3

Synchronous/Deferred
Messaging

Receiving NHIEs
must support synchronous (immediate) document submission transactions; however
deferred document submission transactions may also optionally be supported
, or may restrict
submissions to use either messaging mode based on agreements with its trading partne
rs.

When not restricted by the Receiving NHIE, the Initiating NHIE may choose whether to use synchronous
or deferred interactions.
A
Receiving NHIE

that supports both synchronous and
deferred messaging
modes

would set up two services. One for synchronous

and
other
one for
deferred.

Additionally,

the
Initiating NHIE
would
provide a response service entry point by which the
deferred
response is delivered
from Receiving NHIE
in a separate HTTP Session

to the Initiating NHIE
.

The Synchronous and Deferred
Mess
aging Workflow are defined in the NHIN Messaging Platform Specification document.


3.3.1

Synchronous Messaging Workflow

T
he
Initiating NHIE and Receiving NHIE handle the Document Submission transaction in a single in
-
out
message exchange pattern as defined in th
e NHIN Messaging Platform Specification document
.

In other
words,

I
nitiating
NHIE

sends a
Document submission
request to the
Receiving NHIE

and waits for a
response to come back on the same HTTP connection. The re
ceiving

NHIE

receives the
Document
submissi
on
request and processes it in real
-
time and sends back the response to the
I
nitiating
NHIE

on
that same HTTP connection.

It should be noted that the Action names and namespaces in the
synchronous and the deferred versions of the WSDLs would need to be dif
ferent so that code generation
of the web service code in a gateway supporting both do not have conflicts.


SOAP action for Document Submission Request in synchronous mode is:


5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
9

of
18



SOAP action for Document Submission Response in synchronous mode is:



3.3.2

Deferred Messaging Workflow

Deferred Messaging workflow is supported by this specification to solve the issues of extreme latency
involved in processing of Document Submission request and the attached payload(s) associated with the
request.


In a deferred

mode, the Document Submission is a two
-
way message as shown in the diagram below:


3.4

CORE Metadata

Elements

The required CORE Metadata is described in the table below. CORE metadata elements are used in
several ways in NHIN. The primary uses of the metadata

are:



Message routing



Transaction auditing



Transaction Scheduling



Resource Allocation



Backward compatibility



Error handling



Audit logging


Element

Description

Field Name

Optionality

Data Type

Payload Type

The type of payload included within
a request
/response
. This shall be

X12_
xxx
_005
010X092A1”

for
a
request

and



X12_
xxx
_005
010X092A1”

for a

response

Note: xxx is a transaction type

PayloadType

R

Coded Set

Processing
Mode

The mode of processing. This shall
be “
RealTime


ProcessingMode

R

Coded
Set

Payload ID

A payload ID assigned by the
sender. This shall conform to ISO
UUID standards with hexadecimal
notation, generated using a
combination of local timestamp as
well as the hardware (MAC)
address

PayloadID

R

String

Time Stamp

A single coordin
ated Universal
Time (UTC) time stamp including
time zone. This does not require a
shared time server

TimeStamp

R

dateTime

Sender
Identifier

A unique business entity (trading
partner) identifier

SenderID


R

String

Receiver
Identifier

A unique business
entity (trading
partner) identifier

ReceiverID

R

String

CORE Rule
Version

The CORE Rule version that the
envelope is using

CORERuleVersion

R

Coded Set

Error Code

The error code indicating the error
when processing the envelope

ErrorCode

R

Coded Set

Error
Message

Text error message

ErrorMessage

R

String

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
10

of
18



3.5

Connectivity Rule


This

transaction is d
escribed in
detail in
CORE Phase II Connectivity Rule

Version

2.2.0

section
4.2.2.



3.6

SOAP + WSDL based Message Envelope

The
SOAP + WSDL based method requires SOAP version 1.2
as specified by the
NHIN
Messaging
Platform specification.

There is no specific requirement for t
he SOAP header
2
. The SOAP body contains
the remaining metadata defined by CORE Phase II compliant XML Schema

Specification
(see

Appendix
C)
.
The message envelope structure is defined in the CORE Phase II WSDL file. (
see Appendix B)

3.7

Real
-
time

Deferred Mode

(Real
-
time Mode, Real
-
time Processing
Mode
)


Constraint:
For Real
-
time using SOAP envelope, payload
s

(file
s
)
that contain non
-
printable characters
must be Base64 encoded.


3.8

Batch
-
time (Batch
-
time Mode, Batch
-
time Processing Mode)




3.9

SAML Assertion based
U
ser Authentication and
A
uthorization


For submitter authentication/auth
orization
3
, SAML Assertion shall
need to include
additional
<Attribute>
elements required by
HIT

systems.
The
additional
<Attribute> elements required by this specification
include
1
)
National Provider Identifier (
NPI
)

Attribute and
2
) NPI Provider Name Attribute.
Other elements
required by this
specification

include1) User Organization ID Attribute, 2) User Role Attribute and 3)
Purpose of Use Attribute

which are defined in NHIN Authorization Framework Service Interface
Specification
.

User Authentication
will be pe
rformed on
an
NP
I

Attribute and NPI Provider Name Attribute
pair against the NPPES by the
State
Medicaid MMIS system.
State Medicaid system will validate
requests per NPI Attribute, User Role Attribute, and Purpose of Use Attribute.

Details on submitter
au
thentication/authorization by the State Medicaid systems are out of scope of this specification.


3.9.1

National Provider Identifier (NPI)
4

Attribute


This <Attribute> element shall have the Name attribute set to “urn:oasis:names:tc:xs
pa:1.0:subject:
npi”
and
a
N
PI
number
shall be placed
as a string in plain text

in the value of the <AttributeValue> element
.


An example of the syntax of this element is as follows:


<saml:Attribute Name="
urn:oasis:names:tc:x
s
pa:1.0:subject:
npi
">


<saml:AttributeValue>
1467433888
</sa
ml:AttributeValue>

</saml:Attribute>




2

CORE Phase II Connectivity Rule requires that
WS
-
Security Username and Password token
must

be added to the SOAP Header
in the request

for user authentication/authorization. This requirement is replaced with SAML Assertion based user
authentication/authorization described in section 3.6 in this specification.

3

CORE Phase II Connectivity Rule

specifies two methods
for submitter authenti
cation:
1) Username/Password based
authentication and 2) X.509 Certificate based authentication over SSL.
This specification will use SAML Assertion.

4

NPI is a US Government issued unique provider identifier required for all Health Insurance Portability
and Accountability Act
(HIPAA) Privacy Disclosure Accounting transactions.

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
11

of
18




3.9.2

NPI Provider Name Attribute


This <Attribute> element shall have the Name attribute set to “
urn:nhin:names:saml:
npiProviderName

and a provider name
, which is

associated with
an

identifier provided in NPI <Attribute>,

shall be placed
as
a string in plain text

in the value of the <AttributeValue> element
.


An example of the syntax of this
element is as follows:


<saml:Attribute Name="
urn:nhin:names:saml:
npiProviderName
">


<saml:AttributeValue>Family Medical Clinic<
/saml:AttributeValue>

</saml:Attribute>


4

Error Handling

This section follows error handling specified in the section 4.3.3 of the CORE Phase II Connection Rule.
The error codes relevant to the
Medicaid Eligibility Verification

are listed in the following t
able:


Error Codes

Description

<FieldName>Illegal

Illegal value provided for <FieldName>.

<FieldName>Required

The field <FieldName> is required but was not provided.

<FieldName>NotUnderstood

The field <FieldName>

is not understood at the receiver. In
the case of SOAP, this error is returned as a NotUnderstood
SOAP fault.

VersionMismatch

The version of the envelope sent is not acceptable to the
receiver. If the SOAP version is not valid at the receiver, a
SOAP f
ault is returned with this fault code.

UnAuthorized

The username/password or Client certificate could not be
verified.

Sender

The envelope sent by the sender did not conform to the
expected format. In the case of SOAP, this error should be
sent as a SOAP fault with “Sender” fault code.

剥o敩v敲e

T桥 m敳s慧攠e潵l搠湯琠扥 灲潣敳s敤⁦潲⁲敡s潮s
慴arib畴ubl攠瑯tt桥⁒散敩v敲eE攮e⸬.
u灳瑲敡m⁰牯 敳s⁩s 琠
r敡c桡bl攩⸠e渠nh攠e慳攠ef⁓lAmⰠI桩s 敲e潲⁳桯畬搠d攠e敮琠
as a SOAP fault with “Receiver” fault code.

5

Auditing

This transaction shall be audited as specified in the section 4.3.4 of the CORE Phase II Connection Rule.



5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
12

of
18


Appendix A:

Sample
Messages


Sample

CORE SOAP + WSDL Real
-
time Request


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


<soapenv:Header>



<wsse:Security



xmlns:wsse="http://docs.oasis
-
open.org/wss/2004/01/oasis
-
200401
-
wss
-
wssecurity
-
secext
-
1.
0.xsd" soapenv:mustUnderstand="true">




<wsse:UsernameToken




xmlns:wsu=http://docs.oasis
-
open.org/wss/2004/01/oasis
-
200401
-
wss
-
wssecurity
-
utility
-
1.0.xsd wsu:Id="UsernameToken
-
21621663">





<wsse:Username>bob</wsse:Username>





<wsse:Password Type
="http://docs.oasis
-
open.org/wss/2004/01/oasis
-
200401
-
wss
-
username
-
token
-
profile
-
1.0#PasswordText">bobPW</wsse:Password>




</wsse:UsernameToken>




</wsse:Security>


</soapenv:Header>


<soapenv:Body>



<ns1:COREEnvelopeRealTimeRequest



xmlns:ns1="ht
tp://www.caqh.org/SOAP/WSDL/
CORERule2.2.0.xsd

">




<PayloadType>X12_270_004010X092A1</PayloadType>




<ProcessingMode>RealTime</ProcessingMode>




<PayloadID>f81d4fae
-
7dec
-
11d0
-
a765
-
00a0c91e6bf6</PayloadID>




<TimeStamp>2007
-
08
-
30T10:20:34Z</TimeStam
p>




<SenderID>HospitalA</SenderID>




<ReceiverID>PayerB</ReceiverID>




<CORERuleVersion>
2.2.0
</CORERuleVersion>




<Payload><![CDATA[ISA*00* *00* *ZZ*NEHEN780 *ZZ*NEHEN003 ...IEA*1*000000031]]></Payload>



</ns1:COREEnvelopeRealTimeRequest>


<
/soapenv:Body>

</soapenv:Envelope>


Sample
CORE SOAP + WSDL Real
-
time
Response


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


<soapenv:Body>



<ns1:COREEnvelopeRealTimeResponse



xmlns:ns1="http://www.caqh.org/SOAP/WSDL/
CO
RERule2.2.0.xsd
">





<PayloadType>X12_271_004010X092A1</PayloadType>





<ProcessingMode>RealTime</ProcessingMode>





<PayloadID>a81d44ae
-
7dec
-
11d0
-
a765
-
00a0c91e6ba0</PayloadID>





<TimeStamp>2007
-
08
-
30T10:20:34Z</TimeStamp>





<SenderID>PayerB</S
enderID>





<ReceiverID>HospitalA</ReceiverID>





<CORERuleVersion>
2.2.0
</CORERuleVersion>





<Payload><![CDATA[ISA*00* *00* *ZZ*NEHEN780 *ZZ*NEHEN003 ...IEA*1*000000031]]></Payload>





<ErrorCode>Success</ErrorCode>





<ErrorMessage></ErrorMessa
ge>



</ns1:COREEnvelopeRealTimeResponse>


</soapenv:Body>

</soapenv:Envelope>



5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
13

of
18


Appendix B:

WSDL

CAQH CORE Phase II Connectivity Rule provides a WSDL definition
5


.
<?xml version="1.0" encoding="UTF
-
8"?>

<wsdl:definitions
xmlns:CORE="http://www.caqh.org/SOAP/WSDL/"



xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"



xmlns:xsd="http://www.w3.org/2001/XMLSchema"



xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"



xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"



xmlns
:CORE
-
XSD="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd"



xmlns="http://schemas.xmlsoap.org/wsdl/"



name="CORE"



targetNamespace="http://www.caqh.org/SOAP/WSDL/">


<wsdl:types>


<xsd:schema xmlns="http://schemas.xmlsoap.org/wsdl/"





elementF
ormDefault="qualified"





targetNamespace="http://www.caqh.org/SOAP/WSDL/">


<xsd:import namespace="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd"

schemaLocation="CORERule2.2.0.xsd"/>


</xsd:schema>


</wsdl:types>


<wsdl:message name="RealT
imeRequestMessage">


<wsdl:part name="body" element="CORE
-
XSD:COREEnvelopeRealTimeRequest"/>


</wsdl:message>


<wsdl:message name="RealTimeResponseMessage">


<wsdl:part name="body" element="CORE
-
XSD:COREEnvelopeRealTimeResponse"/>


</wsdl:message>


<wsdl:message name="BatchSubmissionMessage">


<wsdl:part name="body" element="CORE
-
XSD:COREEnvelopeBatchSubmission"/>


</wsdl:message>


<wsdl:message name="BatchSubmissionResponseMessage">


<wsdl:part name="body" element="CORE
-
XSD:COREEnvelopeBa
tchSubmissionResponse"/>


</wsdl:message>


<wsdl:message name="BatchSubmissionAckRetrievalRequestMessage">


<wsdl:part name="body"


element="CORE
-
XSD:COREEnvelopeBatchSubmissionAckRetrievalRequest"/>


</wsdl:message>


<wsdl:message na
me="BatchSubmissionAckRetrievalResponseMessage">


<wsdl:part name="body"


element="CORE
-
XSD:COREEnvelopeBatchSubmissionAckRetrievalResponse"/>


</wsdl:message>


<wsdl:message name="BatchResultsRetrievalRequestMessage">


<wsdl:part name
="body"


element="CORE
-
XSD:COREEnvelopeBatchResultsRetrievalRequest"/>


</wsdl:message>


<wsdl:message name="BatchResultsRetrievalResponseMessage">


<wsdl:part name="body"


element="CORE
-
XSD:COREEnvelopeBatchResults
RetrievalResponse"/>


</wsdl:message>


<wsdl:message name="BatchResultsAckSubmissionMessage">


<wsdl:part name="body" element="CORE
-
XSD:COREEnvelopeBatchResultsAckSubmission"/>


</wsdl:message>


<wsdl:message name="BatchResultsAckSubmissionResponseM
essage">


<wsdl:part name="body" element="CORE
-
XSD:COREEnvelopeBatchResultsAckSubmissionResponse"/>


</wsdl:message>


<wsdl:portType name="CORETransactions">


<wsdl:operation name="RealTimeTransaction">


<
wsdl:input message="CORE:RealTimeRequestMessage"/>


<wsdl:output message="CORE:RealTimeResponseMessage"/>


</wsdl:operation>


<wsdl:operation name="BatchSubmitTransaction">


<wsdl:input message="CORE:BatchSubmissionMessage"/>


<wsdl:ou
tput message="CORE:BatchSubmissionResponseMessage"/>


</wsdl:operation>




5

Since Batch Processing Mode
is not supported

in this specification
, some of this WSDL (i.e. Batch Submission) shall not be used.
The original
CORE
Phase II Connectivity WSDL can b
e downloaded
at
http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.wsdl
.

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
14

of
18



<wsdl:operation name="GenericBatchSubmissionTransaction">


<wsdl:input message="CORE:BatchSubmissionMessage"/>


<wsdl:output message="CORE:BatchSubmissionResponseMessag
e"/>


</wsdl:operation>


<wsdl:operation name="BatchSubmitAckRetrievalTransaction">


<wsdl:input message="CORE:BatchSubmissionAckRetrievalRequestMessage"/>


<wsdl:output message="CORE:BatchSubmissionAckRetrievalResponseMessage"/>


</wsdl
:operation>


<wsdl:operation name="BatchResultsRetrievalTransaction">


<wsdl:input message="CORE:BatchResultsRetrievalRequestMessage"/>


<wsdl:output message="CORE:BatchResultsRetrievalResponseMessage"/>


</wsdl:operation>


<wsdl:operati
on name="BatchResultsAckSubmitTransaction">


<wsdl:input message="CORE:BatchResultsAckSubmissionMessage"/>


<wsdl:output message="CORE:BatchResultsAckSubmissionResponseMessage"/>


</wsdl:operation>

<wsdl:operation name="GenericBatchRetrievalTr
ansaction">


<wsdl:input message="CORE:BatchResultsRetrievalRequestMessage"/>


<wsdl:output message="CORE:BatchResultsRetrievalResponseMessage"/>


</wsdl:operation>


<wsdl:operation name="GenericBatchReceiptConfirmationTransaction">


<
wsdl:input message="CORE:BatchResultsAckSubmissionMessage"/>


<wsdl:output message="CORE:BatchResultsAckSubmissionResponseMessage"/>


</wsdl:operation>


</wsdl:portType>


<wsdl:binding name="CoreSoapBinding" type="CORE:CORETransactions">


<soa
p12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>


<wsdl:operation name="RealTimeTransaction">


<soap12:operation soapAction="RealTimeTransaction" style="document"/>


<wsdl:input>


<soap12:body use="literal
"/>


</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsdl:output>


</wsdl:operation>


<wsdl:operation name="BatchSubmitTransaction">


<soap12:operation soapAction="BatchSubmitTransaction" style="document"/>



<wsdl:input>


<soap12:body use="literal"/>


</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsdl:output>


</wsdl:operation>

<wsdl:operation name="GenericBatchSubmissionTransaction">


<soap12:operation


soapAction="GenericBatchSubmissionTransaction" style="document"/>


<wsdl:input>


<soap12:body use="literal"/>


</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsdl:output>


<
/wsdl:operation>


<wsdl:operation name="BatchSubmitAckRetrievalTransaction">


<soap12:operation


soapAction="BatchSubmitAckRetrievalTransaction" style="document"/>


<wsdl:input>


<soap12:body use="literal"/>



</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsdl:output>


</wsdl:operation>


<wsdl:operation name="BatchResultsRetrievalTransaction">


<soap12:operation


soapAction="BatchResultsRe
trievalTransaction" style="document"/>


<wsdl:input>


<soap12:body use="literal"/>

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
15

of
18



</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsdl:output>


</wsdl:operation>


<wsdl:operation name="BatchResultsAck
SubmitTransaction">


<soap12:operation


soapAction="BatchResultsAckSubmitTransaction" style="document"/>


<wsdl:input>


<soap12:body use="literal"/>


</wsdl:input>


<wsdl:output>


<
soap12:body use="literal"/>


</wsdl:output>


</wsdl:operation>


<wsdl:operation name="GenericBatchRetrievalTransaction">


<soap12:operation


soapAction="GenericBatchRetrievalTransaction" style="document"/>


<w
sdl:input>


<soap12:body use="literal"/>


</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsdl:output>


</wsdl:operation>


<wsdl:operation name="GenericBatchReceiptConfirmationTransaction">


<soap12:op
eration


soapAction="GenericBatchReceiptConfirmationTransaction"
style="document"/>


<wsdl:input>


<soap12:body use="literal"/>


</wsdl:input>


<wsdl:output>


<soap12:body use="literal"/>


</wsd
l:output>


</wsdl:operation>


</wsdl:binding>


<wsdl:service name="Core">


<wsdl:port name="CoreSoapPort" binding="CORE:CoreSoapBinding">


<soap12:address location="http://URL_OF_WEB_SERVICE"/>


</wsdl:port>


</wsdl:service>

<
/wsdl:definitions>



5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
16

of
18


6

CORE Phase II compliant XML Schema Specification
6


.

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd"
targetNamespace="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd">


<xs:element name="COREEnvelopeRealTimeRequest">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:
element name="ProcessingMode" type="RealTimeMode" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>



<xs:element name="Payload" type="xs:string" minOccurs="1" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelopeRealTimeResponse">


<xs:complexType>


<xs:sequence>


<
xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="RealTimeMode" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>



<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>



<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="Payload" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="ErrorCode" type="xs:string" minOccurs="1" maxOccurs="1"/>



<xs:element name="ErrorMessage" type="xs:string" minOccurs="1" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelopeBatchSubmission">


<xs:complexType>


<xs:sequence>


<xs:element name="
PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="BatchMode" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element nam
e="PayloadLength" type="xs:int" minOccurs="1" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="R
eceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CheckSum" type="xs:string" minOccurs="1" maxOccurs="1"/>


<
xs:element name="Payload" type="xs:base64Binary" minOccurs="1" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelopeBatchSubmissionResponse">


<xs:complexType>


<xs:sequence>


<xs:element

name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="BatchMode" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:elem
ent name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element
name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>




6

Since Batch Processing Mode
is not supported

in this specification
, some of this schema (i.e. Batch Submission) shall not be
used.
The schema specification file is available at

http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd
.

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
17

of
18



<xs:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:elemen
t name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>


<xs:element name="ErrorCode" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ErrorMessage" type="xs:string" minOccurs="1" maxOccurs="1"/>


</xs:sequ
ence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelopeBatchSubmissionAckRetrievalRequest">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<
xs:element name="ProcessingMode" type="BatchMode" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>



<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs
:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelopeBatchSubmissionAckRetrievalResponse">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>



<xs:element name="ProcessingMode" type="BatchMode" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>



<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>



<xs:element name="ErrorCode" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ErrorMessage" type="xs:string" minOccurs="1" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<
xs:element name="COREEnvelopeBatchResultsRetrievalRequest">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="BatchMode" minOccurs=
"1" maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1"

maxOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="
1" maxOccurs="1"/>


<xs:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:e
lement name="COREEnvelopeBatchResultsRetrievalResponse">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="BatchMode" minOccurs="1"

maxOccurs="1"/>


<xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1" ma
xOccurs="1"/>


<xs:element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<
xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>

5

NHI
N X12 Document Submission Service Interface Specification

v 0.
3







Page
18

of
18




<xs:element name="ErrorCode" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ErrorMessage" type="xs:string" minOccurs="1" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelo
peBatchResultsAckSubmission">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="BatchMode" minOccurs="1" maxOccurs="1"/>


<x
s:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:e
lement name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs
:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:element name="COREEnvelopeBatch
ResultsAckSubmissionResponse">


<xs:complexType>


<xs:sequence>


<xs:element name="PayloadType" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ProcessingMode" type="BatchMode" minOccurs="1" maxOccurs="1"/>


<
xs:element name="PayloadID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="PayloadLength" type="xs:int" minOccurs="0" maxOccurs="1"/>


<xs:element name="TimeStamp" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:
element name="SenderID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="ReceiverID" type="xs:string" minOccurs="1" maxOccurs="1"/>


<xs:element name="CORERuleVersion" type="xs:string" minOccurs="1" maxOccurs="1"/>


<x
s:element name="CheckSum" type="xs:string" minOccurs="0" maxOccurs="1"/>


<xs:element name="Payload" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/>


<xs:element name="ErrorCode" type="xs:string" minOccurs="1" maxOccurs="1"/>


<x
s:element name="ErrorMessage" type="xs:string" minOccurs="1" maxOccurs="1"/>


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:simpleType name="RealTimeMode">


<xs:restriction base="xs:string">


<xs:pattern value="RealTime"/>


</
xs:restriction>


</xs:simpleType>


<xs:simpleType name="BatchMode">


<xs:restriction base="xs:string">


<xs:pattern value="Batch"/>


</xs:restriction>


</xs:simpleType>

</xs:schema>