Interface Design for CMBHS Clinical Data

Texas Automated Registry System
Interface Design Document for CMBHS 1 of 27

Office of Court Administration
Automated Registry (AR)

Interface Design Document for
DSHS - Clinical Management for
Behavioral Health Services
(CMBHS)

August 04, 2009


Contents
1. Revision History 4
2. Introduction 5
2.1 Purpose .......................................................................................................................... 5
2.2 Assumptions and Constraints ........................................................................................ 5
2.3 Requirements ................................................................................................................. 5
3. Implementation Design 6
3.1 Static View ..................................................................................................................... 6
3.2 Dynamic View ................................................................................................................ 7
3.3 Error Handling ................................................................................................................ 8
3.4 Security .......................................................................................................................... 8
3.4.1 Network ................................................................................................................ 8
3.4.2 Authentication ...................................................................................................... 8
3.4.3 Audit Tracking ...................................................................................................... 9
3.4.4 Data Retention ..................................................................................................... 9
4. Data Design 10
4.1 DSHS-CMBHS Transaction ......................................................................................... 10
4.1.1 CMBHS Web Service Methods ......................................................................... 10
4.1.2 Error Message Formats ..................................................................................... 17
4.2 DSHS-CMBHS Code Tables ....................................................................................... 18
4.2.1 Gender ............................................................................................................... 18
4.2.2 Race 18
4.2.3 Match Type ........................................................................................................ 18

5. Deployment Design 21
6. Issues/Questions 21
7. Glossary 22
8. References 23
8.1 CMBHS Webservice File (WSDL) ............................................................................... 24


1. Revision History
Version Date Name Description
0.1 11/26/2008 Faizal Pakrudeen
First Draft Created with Questions based on
the agency meeting 11/13/2008
0.2 04/10/2009 Jeff Corn
Revised draft based on agency meeting
(03/27/2009), provided WSDL, and email
correspondence on specific questions.
1 04/13/2009 Paul Falkenberg Final Edits and Formatting.
1.1 04/13/2009 Thomas Sullivan OCA and DSHS edits
1.2 04/29/2009 Jeff Corn
Accepted the changes/feedback from the
client.
1.3 04/30/2009 Jeff Corn Modified Section 4.2.2 Race Code Table
1.4 08/04/2009 Jeff Corn Modified Section 4.2.2 Race Code Table


2. Introduction
The Interface Design Document provides the details of the DSHS-CMBHS Interface for
Automated Registry (AR) System. The AR System will interface with the DSHS-CMBHS data
source to query the data from the data source mentioned below.
Clinical Management for Behavioral Health Services (CMBHS): A clinical management
system containing information about a consumers mental health treatments. This
information will be used for providing for the continuity of care and/or case management.
The CMBHS system provides mental health information including Most Recent Date of
Treatment, Current Provider, Diagnosis, Mental Health History, Alerts (future capability) and
Drug Treatment.
2.1 Purpose
This document lays out the interface details, including the design aspects of the adapters that
connect to the DSHS-CMBHS data source, details about the needed transactions, data
formats involved in various transactions between the AR System and the DSHS-CMBHS
System and security design aspects of the interface.
2.2 Assumptions and Constraints
The table below lists the Assumptions and Constraints made for the Interface Design for the
DSHS-CMBHS Interface.

Number Assumption/Constraint
01
This document assumes the interface to CMBHS data source will meet
the requirement 2.1.2.10.2.
02
The technical low-level design aspect of the CMBHS Webservice based
Adapter will be part of the AR Software Architecture Document.

2.3 Requirements
This document provides the details of the interface between the AR System and the DSHS-
CMBHS data source, a requirement stated in the OCA Request for Offers for Automated
Registry System (Final Offer).
Number Requirement
2.1.3.10.2

The system must interface with the following mandatory data sources:
The Texas Department of State Health Services CMBHS system


3. Implementation Design
The AR System will query the CMBHS data source using a Webservice based adapter. The
WS Adapters Webservice client will invoke the query request method exposed in the WSDL.
The CMBHS Webservice implementation will process the request message and return the
response message to the AR system.
The interface will request the individual information based on provided search criteria. The
CMBHS will perform the search based on its algorithms and return the request to the AR
System. The AR system will convert the query result to NIEM based XML format and display
the results to the user.
3.1 Static View
The Static View demonstrates the various components involved in the DSHS-CMBHS
Interface.
Authorized
Personnel
ARQuery
Portal
MicrosoftIIS
ASP.NET
ARSecurity
ActiveDirectory
CertificateAuthority
ARIntegrationBroker
MicrosoftBizTalkServer
2006R2
.NET2.0
ARMetaStoreDatabase
BizTalkMessageBox
MicrosoftSQLServer
2005
TXOCA-AutomatedRegistry
C
M
B
H
S
A
d
a
p
t
e
r
W
S
C
l
i
e
n
t
DSHS-
CMBHS
System
MSAD Token
TwoFactorAuthentication
MicrosoftBiztalkServer
C
M
B
H
S
W
e
b
s
e
r
v
i
c
e
s
W
S
D
L

The AR System user will be authenticated using a two-factor authentication mechanism.
Using a token-based authentication, the AR System user will be directed to the AR Login
page. In the AR Query Portal, the user will be authenticated based on an active directory user
ID and Password and the user can issue an Identifier-based query for the allowed query types
for that user. The CMBHS adapters Webservice client will invoke the methods exposed in the
WSDL. The CMBHS Webservice implementation will in turn query the CMBHS Oracle
database and return the results. The AR System will compile the results and display the
Query Responses to the AR System User in a well defined format.

3.2 Dynamic View
The AR Query System will interface to the DSHS-CMBHS data source through the CMBHS
Adapter. This adapter is a webservice based adapter. This distributed query data flow
between the AR and DSHS-CMBHS is explained below.
The following diagram shows the distributed query flow between AR System and the CMBHS
System.
OCA-ARHub
ARQueryPortal
ARMetastore
Database
ARSQLServer
Query
Result
DSHS-CMBHS
DSHS-
CMBHS
ARSecurityActiveDirectory,CA,SSL
AuthorizedUser
WebBrowser
Request
Metadata
ARBizTalkServer
CMBHSAdapter
ReceivePort
2
3
4
5
6
7
8
1
4
SendPort

Step 1: When a user attempts to access the AR Query Portal, a logon page welcomes the
user and presents them with a form to enter their user name and password. The system
validates the users credentials against the central active directory and caches the user
authorization privileges. This information is used throughout the session to define what this
user is allowed to do or what data they are allowed to see. The users role defined in the
Active Directory will specify which systems he or she can query and what data they can see.
The user enters the query criteria and submits the query.
Step 2: The AR Query Portal collects the person query search criteria.
Step 3: The CMBHS Adapters webservice client will call the method exposed in WSDL and
will pass search parameters entered by the user
Step 4: The CMBHS Webservices will process the request and return the result to the receive
port of the WS adapter.
Step 5: The CMBHS adapter will get the results and convert the results to a common format.
Step 6: The CMBHS Adapter writes the response message to the AR meta-store database.

Step 7: The AR Query Portals Web application displays the aggregated query results to the
user.
Step 8: The AR System updates the AR Meta-Store Databases SQL Server table with the
Audit data related to the Query.
3.3 Error Handling
The AR System will have an Error Handling Mechanism that handles the Error Messages from
the DSHS-CMBHS System. If the AR System receives an Error Message as response to a
Query Request, the AR System will clean up the entire transaction that is associated with that
Query.
The CMBHS Webservices will respond with the SOAP Exceptions for the following cases:
Soap Header Authentication failures service account (User ID/Password) incorrect, etc.
Web Method Parameters failures If the parameters passed to the method are not valid,
a data rejected error message will be send by the CMBHS Web service.
CMBHS Application Errors If any application errors behind the CMBHS Webservices
occur (like DB connection failures, timeouts, etc), then an appropriate error message will
be sent by the CMBHS Webservice.
Finally, if the CMBHS Webservice is unable to find a record matching the query criteria then
the CMBHS System will send a response indicating no record found.
3.4 Security
The CMBHS can be accessed through an existing SOAP WS-I Basic Profile. The AR system
will be provided a single service account (user name and password) for all Webservice calls to
the CMBHS system. This service account will passed in SOAP header of every webservice
call. The AR system will access the CMBHS Webservices using an HTTPS connection.
3.4.1 Network
The DSHS-CMBHS System will be accessible from Texas OCA AR System using a public
HTTPS connection. (The Server Name and URL details will be updated later.)

System Server Name URL

3.4.2 Authentication
The AR System will send a single Service Account (user-Id and password) as part of the
SOAP header.

3.4.3 Audit Tracking
The AR System will keep the Audit data related to a query transaction between the AR
System and the DSHS-CMBHS System. The audit records will cover the information
mentioned in the table below.
Data Element Description
User ID The User ID who sent the Query
Reason The Reason for the Query
Date/Time Stamp of Transaction
send
The Date/Time Stamp of the Query Request
Date/Time Stamp of Transaction
received
The Date/Time Stamp of the Query Response
Query String This field will contain the Query Criteria used
for a specific query.
Data Sources Queried The name of the data source
Query Type The AR System Query Type used for the
transaction.

The AR System will maintain the Audit Trail for each transaction. Audit records will be kept for
a minimum of one year.
Finally, the AR System will send the AR User ID (Active Directory User ID) along with the
search criteria to the CMBHS Webservice calls, supporting CMBHS audit trails for users
performing queries.
3.4.4 Data Retention
The AR System will retain the Query Results data while the User Session is active. This
information is stored temporarily and discarded once the user ends the session or the session
times out.


4. Data Design
4.1 DSHS-CMBHS Transaction
This section covers the CMBHS Inquiry message formats and its response formats. The AR
System will access DSHS-CMBHS information through a name based query to obtain a pick
list and then use an identifier to obtain the detailed information. The CMBHS adapter will
aggregate data from the CMBHS Webservices and provide the AR System with a result set.
The details of the request and response data elements are described in the subsections
below.
4.1.1 CMBHS Web Service Methods
The CMBHS Inquiry is used to obtain the mental health information of an individual. The AR
system will collect all query criteria entered by the user and pass them as parameters to a
webservice method exposed in the WSDL and invoke that method.
CMBHS Webservice Methods
ProcessClientMatch (TLETSQueryMessage) : TLETSQueryResponseMessage


4.1.1.1 Web Method ProcessClientMatch
Below are the request and response messages for the webservice method.
4.1.1.1.1 Web Method ProcessClientMatch (Request Message Format)
The following table shows the details of the request methods exposed in the WSDL.

TLETSQueryMessage
Field(s) Data Type(s) Description/Edits
TLETSQueryMessage Complex
Version String Version Information.
Example:
<?xml version=\"1.0\" encoding=\"utf-
8\"?>
<TLETSQueryMessage
xmlns:xsi=\"http://www.w3.org/2001/XML
Schema-instance\"

xmlns:xsd=\"http://www.w3.org/2001/XM
LSchema\"

xmlns=\"http://www.dshs.state.tx.us/cmb
hs/\">
Initiator String Constant value = OCA
Destination String Constant value = DSHS
ControlField String Not used. Leave blank
UserID String AR User ID performing the query

Alphanumeric; Max Length = 255

QueryID String AR Query ID (GUID) associated with
the query


QueryTime DateTime The date and time the query is sent.

Format: CCYY-MM-DDTHH:MI:SS


Example: 2009-03-27T09:02:30

Note: The Hours is 1-24 hour scale.

FacilityName String AR system is not using. Leave Blank
FacilityStreetAddress String AR system is not using. Leave Blank
FacilityCity String AR system is not using. Leave Blank
FacilityZip String AR system is not using. Leave Blank
FacilityCountyCode String AR system is not using. Leave Blank
FacilityContactPersonName String AR system is not using. Leave Blank

FacilityContactPhoneNumber
String AR system is not using. Leave Blank
FirstName String First Name of the Individual


LastName String Last Name of the Individual


SSN String Social Security Number

Num(9) - Numeric values only converted
to a string data type.

Example: 999999999

DateofBirth DateTime Date of Birth


Example: 2009-03-27T0000:00

Note: The time portion will be zeros.

Gender String See Code Table values (Section 4.2)

CMBHS value will be sent and received.


Race String See Code Table values (Section 4.2)


4.1.1.1.2 Web Method ProcessClientMatch (Response Message Format)
The response message will be in SOAP based XML format. The response message will have
a SOAP header and followed by the response data elements.

TLETSQueryResponseMessage
Field(s) Data Type(s) Description/Edits
TLETSQueryResponseMessa
ge
Complex
Version String Version Information.
Example:
<?xml version=\"1.0\" encoding=\"utf-
8\"?>
<TLETSQueryResponseMessage
xmlns:xsi=\"http://www.w3.org/2001/XML
Schema-instance\"

xmlns:xsd=\"http://www.w3.org/2001/XM
LSchema\"

xmlns=\"http://www.dshs.state.tx.us/cmb
hs/\">
Initiator String Constant value = OCA
Destination String Constant value = DSHS
ControlField String Not used. Leave blank
UserID String AR User ID performing the query


QueryID String AR Query ID (GUID) associated with
the query


QueryTime DateTime The date and time the query is sent.



Example: 2009-03-27T09:02:30

Note: The Hours is 1-24 hour scale.

FacilityName String AR system is not using. Leave Blank
FacilityStreetAddress String AR system is not using. Leave Blank
FacilityCity String AR system is not using. Leave Blank
FacilityZip String AR system is not using. Leave Blank
FacilityCountyCode String AR system is not using. Leave Blank
FacilityContactPersonName String AR system is not using. Leave Blank

FacilityContactPhoneNumber
String AR system is not using. Leave Blank





Num(9) - Numeric values only converted
to a string data type.

Example: 999999999



Example: 2009-03-27T0000:00



ErrorMessage String If any errors occur on the CMBHS
WebService, the error messages will be
sent back in this field.


BusyMessage String CMBHS is not using this field.
TLETSResponse ArrayOfPerson See below complex XML Element
ArrayOfPerson Complex
CMBHSID Int CMBHS Unique ID for Person Record

AR System is not using.

MatchType String See Code Table values (Section 4.2)






MiddleName String Middle Name of the Individual



Format: Num(9) - Numeric values only
converted to a string data type

Example: 999999999




Example: 2009-03-27T0000:00






County String County of the individual


FacilityName String The Facility where the Individual is/was
located.


PhoneNumber String Phone Number

Numeric; Max Length = 10

CaseID String The Case Number associated with the
Individual.



4.1.2 Error Message Formats
The Error Message formats that will be used to handle the various Exceptions during the
transactions are mentioned below. The errors will be sent back to the AR System in the
returned XML (TLETSQueryResponse ErrorMessage field).

4.1.2.1 Error Message Formats (Response Error Messages)
Some example error messages are in the table below.

Response Fields Description/Edits
ErrorMessage User not authenticated or not successfully loaded from DB
ErrorMessage
Authentication header needs to be provided for
authorization
ErrorMessage Gender in the request has to be 'male' or 'female'.

4.2 DSHS-CMBHS Code Tables
This section covers the CMBHS Code Table values used in the request and/or response
message exchanges. The tables below contain the CMBHS values and Descriptions. Any
message exchanges requiring these code values between AR & CMBHS will be translate the
system specific values as required.
Note: The AR & CMBHS Code Table value translations will be defined in the Use Case as
some code tables may be used across multiple interfaces. This document will only define the
CMBHS values.
The details of the request and response data elements are described in the subsections
below.
4.2.1 Gender
The Gender code table has different types of individual genders supported by the CMBHS
System. Please see the Use Case for system to system value translations.
CMBHS Value Description
male Male
female Female

4.2.2 Race
The Race code table has different ethnic types listed and supported by the CMBHS System.
Please see the Use Case for system to system value translations.
American Indian or Alaskan Native American Indian or Alaskan Native
Asian Asian
Black or African American Black or African American
Native Hawaiian or Pacific Islander Native Hawaiian or Pacific Islander
White White
Unknown Unknown

4.2.3 Match Type
The Match Type code table will have values that indicate whether the individual search found
the person or not. These matches will vary depending on the search criteria. Please see the
Use Case for system to system value translations.
E An Exact match was found.
*** See Match Rules below.
P A Probable match was found.

*** See Match Rules below.

Match Rule Definition(s) Logic performed by CMBHS WebService
Exact Match Data Inquiry matches the following combination:
o Combination # 1
Last Name
First Name
Date of Birth
Gender
Social Security Number
Race
Probable Match Data Inquiry matches on one of the following combinations:
o Combination # 1
Last Name
First Name Initial
Date of Birth
Gender
o Combination # 2
Last Name
First Name Initial
Date of Birth Year only (will extract from input DOB)
Gender
o Combination # 3
Last Name First 3 letters
First Name Initial
Date of Birth Year & Month only (will extract from input DOB)
Gender
o Combination # 4
Last Name (Note: Matches to any others found)
First Name Initial (Note: Matches to any other found)
Date of Birth (Note: current Age calculation is within 5 years)
Gender
Social Security Number (Note: Matches to any others found)

Note: AR System will always pass the entire DOB, not partials. The CMBHS Service will
extract Year, Month, etc as required to perform the search as outlined in logic above.

5. Deployment Design
The OCA will host the AR System in various environments and communicate with the DSHS-CMBHS
over public HTTPS connection. The following table will outline the various environments.

Environment AR (IP Address / Port) CMBHS System (URL / Port)
Integration
System Test
Pilot
User Acceptance
Production

6. Issues/Questions

# Issue/Question Status


7. Glossary
Term Definition
AR System Automated Registry System
CMBHS Clinical Management for Behavioral Health Services
OCA Office of Courts Administration
DSHS Department of State Health Services
SOAP Simple Object Access Protocol
WS Webservice
WSDL Webservice Definition Language


8. References
This section provides a complete list of all documents referenced elsewhere in the Interface
Design Document.
No. Reference Title Version
[1] OCA Request for Offers for Automated Registry System (Final
Offer).

[2] WDSL provide by CMBHS agency (see below)


8.1 CMBHS Webservice File (WSDL)
<?xml version="1.0" encoding="utf-8" ?>
- <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://www.dshs.state.tx.us/cmbhs/" xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
targetNamespace="http://www.dshs.state.tx.us/cmbhs/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
- <wsdl:types>
- <s:schema elementFormDefault="qualified" targetNamespace="http://www.dshs.state.tx.us/cmbhs/">
- <s:element name="ProcessClientMatch">
- <s:complexType>
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="TLETSQueryMessageRequest"
type="tns:TLETSQueryMessage" />
</s:sequence>
</s:complexType>
</s:element>
- <s:complexType name="TLETSQueryMessage">
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Version" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Initiator" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Destination" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="ControlField" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="UserID" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="QueryID" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="QueryTime" type="s:dateTime" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityStreetAddress" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityCity" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityZip" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityCountyCode" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityContactPersonName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityContactPhoneNumber" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FirstName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="LastName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="SSN" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="DateofBirth" type="s:dateTime" />
<s:element minOccurs="0" maxOccurs="1" name="Gender" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Race" type="s:string" />
</s:sequence>
</s:complexType>
- <s:element name="ProcessClientMatchResponse">
- <s:complexType>
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="ProcessClientMatchResult"
type="tns:TLETSQueryResponseMessage" />
</s:sequence>
</s:complexType>
</s:element>
- <s:complexType name="TLETSQueryResponseMessage">
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Version" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Initiator" type="s:string" />

<s:element minOccurs="0" maxOccurs="1" name="Destination" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="ControlField" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="UserID" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="QueryID" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="QueryTime" type="s:dateTime" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityStreetAddress" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityCity" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityZip" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityCountyCode" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityContactPersonName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FacilityContactPhoneNumber" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="TLETSResponse" type="tns:ArrayOfPerson" />
<s:element minOccurs="0" maxOccurs="1" name="ErrorMessage" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="BusyMessage" type="s:string" />
</s:sequence>
</s:complexType>
- <s:complexType name="ArrayOfPerson">
- <s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="Person" nillable="true" type="tns:Person" />
</s:sequence>
</s:complexType>
- <s:complexType name="Person">
- <s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="CMBHSID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="MatchType" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="MiddleName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="County" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="PhoneNumber" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="CaseID" type="s:string" />
</s:sequence>
</s:complexType>
<s:element name="CMBHSAuthenticationHeader" type="tns:CMBHSAuthenticationHeader" />
- <s:complexType name="CMBHSAuthenticationHeader">
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="CMBHSUserName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="CMBHSPassword" type="s:string" />
</s:sequence>
<s:anyAttribute />
</s:complexType>
</s:schema>
</wsdl:types>
- <wsdl:message name="ProcessClientMatchSoapIn">
<wsdl:part name="parameters" element="tns:ProcessClientMatch" />
</wsdl:message>

- <wsdl:message name="ProcessClientMatchSoapOut">
<wsdl:part name="parameters" element="tns:ProcessClientMatchResponse" />
</wsdl:message>
- <wsdl:message name="ProcessClientMatchCMBHSAuthenticationHeader">
<wsdl:part name="CMBHSAuthenticationHeader" element="tns:CMBHSAuthenticationHeader" />
</wsdl:message>
- <wsdl:portType name="ClientMatchServiceSoap">
- <wsdl:operation name="ProcessClientMatch">
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Process generic request for data
from CMBHS</wsdl:documentation>
<wsdl:input message="tns:ProcessClientMatchSoapIn" />
<wsdl:output message="tns:ProcessClientMatchSoapOut" />
</wsdl:operation>
</wsdl:portType>
- <wsdl:binding name="ClientMatchServiceSoap" type="tns:ClientMatchServiceSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
<soap:operation soapAction="http://www.dshs.state.tx.us/cmbhs/ProcessClientMatch" style="document"
/>
- <wsdl:input>
<soap:body use="literal" />
<soap:header message="tns:ProcessClientMatchCMBHSAuthenticationHeader"
part="CMBHSAuthenticationHeader" use="literal" />
</wsdl:input>
- <wsdl:output>
<soap:body use="literal" />
<soap:header message="tns:ProcessClientMatchCMBHSAuthenticationHeader"
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
- <wsdl:binding name="ClientMatchServiceSoap12" type="tns:ClientMatchServiceSoap">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
<soap12:operation soapAction="http://www.dshs.state.tx.us/cmbhs/ProcessClientMatch"
style="document" />
- <wsdl:input>
<soap12:body use="literal" />
<soap12:header message="tns:ProcessClientMatchCMBHSAuthenticationHeader"
</wsdl:input>
- <wsdl:output>
<soap12:body use="literal" />
<soap12:header message="tns:ProcessClientMatchCMBHSAuthenticationHeader"
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
- <wsdl:service name="ClientMatchService">
- <wsdl:port name="ClientMatchServiceSoap" binding="tns:ClientMatchServiceSoap">
<soap:address
location="http://cmbhsdataexchange.dshs.state.tx.us/CMBHSWebService/Service/ClientMatchServi
ce.asmx" />
</wsdl:port>
- <wsdl:port name="ClientMatchServiceSoap12" binding="tns:ClientMatchServiceSoap12">
<soap12:address
location="http://cmbhsdataexchange.dshs.state.tx.us/CMBHSWebService/Service/ClientMatchServi
ce.asmx" />
</wsdl:port>

</wsdl:service>
</wsdl:definitions>

Interface Design for CMBHS Clinical Data

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Interface Design for CMBHS Clinical Data

Uploaded by

Copyright:

Available Formats

Texas Automated Registry System

Interface Design Document for CMBHS 1 of 27

You might also like