Data Submission and Technical Specifications (PDF - CCIM

Community Care Information Management (CCIM) 

IAR Data Submission 

` 

` 

Data Submission and Technical 

Specifications 

Project: Integrated Assessment Record 

Phase: Provincial Solution Rollout 

Community Care Information Solutions Group 

May 2010 

Version 1.0 

Prepared by: 

IAR Project Team 

Security Classification: Medium Sensitivity 

1



` 

Copyright 

` 

This document is the property of Community Care Information Management and is copyrighted, 

and all rights are reserved by Community Care Information Management. No part of this 

publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or 

translated into any language or computer language, in any form or by any means, electronic, 

mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of 

Community Care Information Management. 

Disclaimer 

This document is current as of June 04, 2010 and any changes to all related applications after 

that date will be incorporated into the next version of this document. 

Security Notice 

This material and the information contained herein are proprietary to Community Care Information 

Management and may not be used, reproduced, stored in electronic retrieval systems, or 

disclosed to others, in any form or by any means, except as specifically permitted in writing by 

creator of the document. The recipient of this information, by its retention and use, agrees to 

protect it from any loss, theft or compromise. Please contact the creator of this document if you 

wish to share this document with organizations outside of Community Care Information 

Management. 

This document has a Medium Sensitivity Classification 

2



` 

` 

Document Details 

Revision History 

Version Comments Author Date 

1.0 Initial Release IAR Project Team June 4, 2010 

Intended Audience 

Vendors will use this document along with all of the supporting documents to develop data feed 

for submitting assessment data to the IAR Provincial solution. The project team is available 

throughout the implementation phase via teleconferences for clarifications and questions about 

these requirements as needed. Any additional questions can be sent to the project team through 

the Support Centre. 

Organizations should read and understand this document and all the supporting documents that 

make up the data submission requirements. Organizations are responsible for ensuring that their 

vendor delivers a solution that meets these requirements. 

Organizations and vendors should understand that this requirement package is designed for the 

purpose of submitting assessment data to the IAR application. Requirements for automating and 

supporting the individual assessment model are provided by the corresponding assessment 

standard. 

Documentation 

The following documents represent the data submission requirements for the IAR Provincial 

solution: 

1. Data Submission and Technical Specifications (PDF – This document) 

2. IAR Submission Schema, (XSD, IARSubmissionDefinitions _version.xsd) 

3. PHI Submission Schema, (XSD, CCIMSubmissionPHI_version.xsd) 

4. Web Service Definition, (WSDL, IAR_Submission_version.wsdl) 

3



` 

Table of Contents 

` 

1 IAR Overview .......................................................................................................................... 5 

1.1 What is IAR................................................................................................................... 5 

1.2 What IAR is Not .............................................................................................................. 5 

1.3 What will be stored in IAR .............................................................................................. 5 

1.4 IAR Benefits.................................................................................................................... 5 

2 Data Submission Requirements.............................................................................................. 7 

2.1 General Information........................................................................................................ 7 

2.2 Submission Process ....................................................................................................... 7 

2.3 Rejections, Corrections and Resubmissions.................................................................. 8 

2.4 Technical Requirements................................................................................................. 9 

2.4.1 Submission Characteristics........................................................................................ 9 

2.4.1.1 Submission Header Elements ......................................................................... 11 

2.4.1.2 Submission Content Elements ........................................................................ 12 

2.4.2 Encoding .................................................................................................................. 13 

2.4.3 Submission Methods................................................................................................ 13 

2.4.3.1 Automated Submission – Web Service ........................................................... 13 

2.4.3.2 Manual Submission ......................................................................................... 14 

2.4.4 File Naming Convention........................................................................................... 14 

2.5 Submission Rules......................................................................................................... 15 

2.6 Testing Process............................................................................................................ 16 

2.7 IAR PHI Validation Tables ............................................................................................ 16 

3 Roadmap............................................................................................................................... 17 

Appendix A - Assessment Specific Requirements .................................................................... 18 

OCAN Assessment Requirements ......................................................................................... 18 

RAI-MH Assessment Requirements....................................................................................... 18 

Appendix B - IARSubmissionService-Client-side ...................................................................... 19 

4



` 

1 IAR Overview 

1.1 What is IAR 

` 

The Integrated Assessment Record (IAR) is an initiative within CCIM to allow assessment 

information to be viewed by health service providers within a client’s circle of care in a secure 

manner. 

As an application, it can be used to access and view assessment information that is centrally 

housed at a Health Information Network Provider (HINP) identified by the LHIN Steering 

Committee. 

As a central repository for collected data it is a means to share assessments across community 

mental health organizations, hospital emergency departments, primary care and hospital mental 

health in-patient teams to share assessments with one another in order to provide improved 

quality care. 

1.2 What IAR is Not 

The Integrated Assessment Record (IAR) is not a clinical system of record. This means that the 

source systems feeding IAR with assessment data will always be relied upon as the integral 

source for person information. In its design, no provisions have been made to permit data 

changes to occur from the IAR application; meaning it has been specifically designed to be a 

“Read Only” system to view patient assessments. 

1.3 What will be stored in IAR 

The Integrated Assessment Record (IAR) will capture common assessment information 

pertaining to RAI-MH©, OCAN, and will over time grow to include assessments from other 

community care sectors including addictions and problem gambling assessments, as well as 

assessment information from the Long Term Care Homes, Community Care Access Centres and 

Community Support Services sectors. Three immediate priorities are: 

1. OCAN: The Ontario Common Assessment of Need (OCAN) is a standardized, consumerled 

decision making tool that allows key information to be electronically gathered in a 

secure and efficient manner. 

2. RAI-MH©: The Resident Assessment Instrument - Mental Health is a comprehensive, 

standardized instrument for evaluating the needs, strengths, and preferences of patients 

in designated adult inpatient mental health beds. 

3. ADAT: The Addictions assessment package - is a set of nine assessments that allow 

service providers to track their client from intake to discharge using a common set of 

assessment tools and shared language. 

1.4 IAR Benefits 

IAR facilitates a common understanding of a client’s needs and helps to improve the continuity of 

care across community and hospital settings. Anticipated benefits of the IAR for clients, health 

service providers and the health care system include: 

• Identifying other providers within the client’s circle of care and providing access to their 

most recent assessment 

• Improving the quality and reliability of information sharing 

5



` 

` 

• Ensuring a secure exchange of personal health information 

• Providing data for health service planning to healthcare providers and LHINs 

• Supporting networks and learning opportunities across organizations 

• Providing the basis for coordinated community-based care planning, and assisting 

organizations to identify service overlaps and gaps 

6



` 

` 

2 Data Submission Requirements 

2.1 General Information 

This section provides data and technical specifications for use by organizations and their 

assessment tools vendors in the development of interfaces for data transmission to IAR. 

A data transmission to IAR is defined in this and subsequent sections as a submission. A 

submission contains extracted assessment records and these records may or may not be stored 

in a file. 

This section includes: 

Submission Process 

Rejections, Corrections and Resubmissions 

Technical Requirements 

Submission Rules 

Testing Process 

IAR PHI Validation Tables 

2.2 Submission Process 

Organizations have independent control of submission tracking and are responsible for ensuring 

that all assessment records are accounted for and available in their source systems. It is 

expected that organizations will use due diligence to ensure that an accurate and complete 

account of assessment records are successfully transmitted to the IAR repository as regularly as 

daily. 

IAR maintains an organization profile for the purpose of receiving submissions and 

communicating with the organization. Figure 1 - Overview of Assessment Submission Process 

presents a high-level view of the process for submitting assessment records for an organization. 

IAR handles received submissions in two steps as followed: 

Step 1 - Once a submission is sent to IAR, the submitting organization receives a status 

indicating if the submission was successfully received and queued for further processing in the 

IAR. IAR processes submissions in the order they are received and the processing may not 

happen immediately following the successful transmission. 

Step 2 - Schema validations such as XML structure, mandatory fields and values, expected 

values and referential integrity validations are performed on the queued submissions at the time 

of processing. These validations could lead to a rejection of a submission or individual 

assessment records in a submission for which the submitting organization received a status in 

step 1 indicating that the transmission to IAR was successful. 

7



` 

` 

Figure 1 – Overview of Assessment Submission Process 

Assessment records in a submission must meet data quality edit checks and adhere to the predefined 

business rules required by the source system. IAR assumes that these requirements are 

met and does not duplicate any content validations. 

2.3 Rejections, Corrections and Resubmissions 

IAR will reject an entire submission or individual record in a submission if the entire submission or 

the individual records do not pass validations at the time of processing. No records in the 

submission will be processed if the entire submission is rejected. 

In the event that submission rejection or individual record rejection occurs, the submitting 

organization will be contacted by the IAR Support Center with details on the nature of the error(s) 

and the actions to be taken for the record(s) to be accepted by IAR. 

IAR requires that rejected records be corrected at source given that source systems are 

considered the systems of record for IAR. This requirement has the added benefit of ensuring 

that source systems and IAR hold consistent data, with all elements completed and records 

submitted in the correct format. 

The submitting organization is not contacted if IAR does not generate an error during the 

submission processing 

In cases where submissions are not successful due to technical issues (transmission, network or 

connectivity failure) extracted records need to be resubmitted with no change by the submitting 

organization. 

Resubmission of records that were previously rejected or that were not successfully received 

(the submitting organization received a status indicating that the transmission was not successful 

or the submission failed due to technical issues) is the responsibility of the submitting 

organization. 

8



` 

` 

2.4 Technical Requirements 

2.4.1 Submission Characteristics 

IAR will only accept assessment data in formats that conform to standards specified by the 

corresponding assessment. Formats specified by the Canadian Institute for Health Information 

(CIHI) for RAI-MH assessment data for example will be accepted as will be formats specified in 

OCAN. Assessment data in the original format must be enclosed in a UTF-8 encoded XML 

envelope – see Documentation [2] IAR Submission Schema - to be accepted by IAR. The 

following diagram illustrates the structure of the submission envelope where assessment data 

contains Personal Heath Information (PHI) e.g. OCAN 2.0. 

Submission Envelope 

Submission Header 

Assessment Data: 

(Conforms to assessment standard e.g. 

OCAN) 

The header includes 

submission ID, 

organization, export time 

stamp and assessment 

type, application ID and 

other attributes 

This represents the 

transmission envelope and 

must conform to IAR 

Submission Schema 

Submission Structure 1: IAR Submission Schema 

The assessment data must 

conform to formats specified in 

assessment standard e.g. OCAN 

Submission XML Schema or 

OMHRS Submission XML 

Schema 

In Cases where assessment data do not contain PHI e.g. RAI-MH or OCAN 2.1, IAR requires 

corresponding PHI data to be provided in addition to the assessment data and both PHI and 

assessment data must be included in the same submission envelope. Each PHI record is linked 

to assessment record by the corresponding assessment ID and there must be a PHI record to 

accompany each assessment record. The structure of the submission envelope containing 

assessment and PHI data is shown in the following diagram. 

9



` 

` 



The header includes 

submission ID, 

organization, export time 

stamp and assessment 

type, application ID and 

other attributes 

PHI Data 

Assessment 

Data 

This represents the 

transmission envelope and 

must conform to IAR 


Submission Structure 2: IAR Submission Schema 

The assessment data must 

conform to formats specified in 

assessment standard e.g. OCAN 

Submission XML Schema or 

OMHRS Submission XML 

Schema 

The PHI data must 

conform to CCIM PHI 


The XML structure (XSD) for the submission envelope is defined in Documentation [2] - 

Submission Schema - and the XML structure (XSD) for Personal Health Information is defined in 

Documentation [3] - PHI submission schema. Sample XML files are included in the requirements 

package. 

The following charts outline the content of the IAR Submission envelope. 

10



` 

` 

2.4.1.1 Submission Header Elements 

Element Type Values Description 


1 *submissionId xsd:string 

2 organization 

Complex, 

attributes 

3 *exportTimestamp xsd:dateTime 

4 *assessmentType xsd:string 

5 Application 

Complex, 

attributes 

*name, xsd:string 

*id, xsd:string 

OCAN, RAI-MH, ADAT, 

RAI_MDS_2.0,CIAT, RAI 

HC 

Name, xsd:string 

*Id, xsd:string 

Version, xsd:string 

Vendor, xsd:string 

Elements with * are mandatory. All other elements are optional. 

The submission Id is used to uniquely 

identify submission record 

Submitting organization id (number) 

and name 

Date and time when export was 

generated from the source system 

Assessment type of submission. Must 

be one of supported assessment types. 

Assessment version is indicated in the 

version attribute of the Record element 

of submission content element. 

Submitting application id, name, 

version and vendor 

The value of the submitting organization id is dependent upon the assessment type and/or 

version: 

- In the case of OCAN 2.0 this value is represented by the submitting organization number 

field, and for OCAN 2.1 and OCAN 1.0.2 it is represented by the service organization 

field from an assessment record. 

- In the case of RAI-MH it represents the 3 to 4-digit Facility Number from the Ministry of 

Health and Long-Term Care (MOH) Master Numbering System not the 4-digit Master 

Number that is transferred in the Facility Number field of a RAI-MH assessment record. 

11



` 

` 

2.4.1.2 Submission Content Elements 

Element Type Values Description 

Submission Content 

*recordType, xsd:string 

Indicates what kind of content is stored 

in the record. The wrapper can contain 

up to two records. 

PersonalInformation indicates a file 

containing PI as specified in 

CCIMSubmissionPHI. Assessment 

indicates a file containing assessment 

data as specified by the corresponding 

assessment standard. The assessment 

file may or may not contain PI. 

1 Record [1..2] 

Complex, 

attributes 

version, xsd:string 

Version of record schema, i.e. 1.0.2 for 

OCAN Assessment. This represents 

the value of version attribute in OCAN 

schema or the year of CIHI schema 

edition for RAI-MH e.g. 2010 for the 

2010-2011 fiscal year. 

Indicates the data format of data 

record: 

text 

1.1 *RecordType OR 

binary 

xsd:string 

base64Binary 

*mimeType, xsd:string 

delimiter, xsd:string 

Attribute 

compressionType with 

possible values: 

application/zip(default if 

not specified) 

or 

none – no compression 

Elements with * are mandatory. All other elements are optional. 

text/xml - XML, 

text/x-non xml – other format (commaseparated 

values or variable length) 

Used if other data format (mimetype) is 

specified 

XML or other data format to be 

enclosed within CDATA section 

Base64 encoded for binary 

(compressed) data. 

12



` 

` 

2.4.2 Encoding 


The submission envelope format must use UTF-8 encoding. 

Assessment Data 

The assessment data can be either UTF-8 or UTF-16 encoded, in accordance with assessment 

standard. For example, OCAN 2.0 must be UTF-8 encoded and OCAN 1.0.2 must be UTF-16 – 

encoded. UTF-8 encoded data can be stored in either [CDATA] element or base64 

. However, UTF-16 encoded data can only be stored within content element. 

Note that according to XML W3C standard the stream encoded in UTF-16 should contain byte 

order mark (BOM). For more information about byte order mark please visit 

http://www.w3.org/TR/REC-xml/#charencoding and http://www.opentag.com/xfaq_enc.htm. 

PHI Data 

The PHI data must be UTF-8 encoded 

Please refer to the XSD of the submission envelope for additional information. 

2.4.3 Submission Methods 

IAR offers two secure methods for transmission of electronic assessment records to its repository 

as illustrated in figure 1. An organization must have the ability to connect to the internet. 

The solution supports an automated method using a web service and a manual transmission 

method using Microsoft Internet Explorer or Mozilla Firefox. . . 

2.4.3.1 Automated Submission – Web Service 

The automated submission method supported by IAR exposes a web service provider interface 

that is available to any participating organization over the internet through HTTPS protocol. 

Clients must adhere to the following description in order to consume this web service. 

Endpoint 

IAR Assessment Submission Web Service endpoint URL will be provided to organization at the 

implementation time. 

Operation 

IAR Assessment Submission Web Service defines a single SubmitAssessment operation with the 

following parameters: 

• input: SubmissionInput 

• output: SubmissionResponse 

SubmissionInput is defined by the XML schema see Documentation [2] - IAR Submission 

Schema - and described in the “Submission file structure definition” section. 

SubmissionResponse is defined in WSDL – see Documentation [4], Web Service Definition - as 

complex type SubmissionResultType that has three elements: 

• Result – of type Boolean that indicates if the operation executed successfully (value 

TRUE) or with errors (value FALSE) 

13



` 

` 

• TransactionId – an attribute of Result element, this is the internal IAR tracking Id that will 

be used for support purposes 

• ErrorCode – optional, used when Result = FALSE, contains error code defined by IAR 

• ErrorMessage – optional, used when Result = FALSE, contains error description returned 

by IAR 

IAR handles HTTP specific status codes in the way prescribed in WS-I Basic Profile 1.1 Second 

Edition (http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAPHTTP), section 3.4. The following 

http response status codes can be returned by IAR to a web service client: 

200 OK 

202 Accepted 

400 Bad Request 

405 Method Not Allowed 

415 Unsupported Media Type 

500 Internal Server Error 

Security requirements are supported by transport level encryption (SSL) through HTTPS protocol. 

IARSubmissionService is WS-Security compliant. The authentication credentials (user name and 

password) are sent in SOAP header. 

Following is an example of a SOAP Header that contains user credentials in WS-Security 

compliant format: 

 

 

 

uploaduser 

uploadpasswd 

 

 

 

Communications between each web service client and the web service provider will be encrypted 

using SSL/TLS over HTTP to prevent authentication credentials to be compromised during 

transmissions. 

Appendix B describes how the web service client can be implemented in Java. 

2.4.3.2 Manual Submission 

The manual submission method allows users who have been authorized and authenticated to 

upload submission files that meet the specifications described in this document through the IAR 

secure web application. The user receives a message indicating if the file transmission was 

successful. 

Transmission of data can occur 24 hours a day, seven days a week. Once the initial set-up for an 

organization has been put into place, authorized and authenticated users of this organization can 

submit data to IAR at their convenience. 

2.4.4 File Naming Convention 

For submissions that are delivered in files, names must be standardized to facilitate the tracking 

of the assessment submission. The file-naming convention must be followed to ensure that the 

file is accepted by the IAR application. 

14



` 

` 

The Assessment submission file will be in the format: 

[Assessment Type]..xml 

Where: 

[Assessment Type], possible values are ‘OCAN’, ‘RAI-MH’, ‘ADAT’ - for addictions; 

YYYYYMMDD – the date when the export process started; 

HHMM - time when the export process started (note 24 hour clock is used); 

OOOO – organization ID, or parent organization id used in assessment application in 

multi-site environments (in case of OCAN); 

ZZ - target system suffix, ‘IA’ for Integrated Assessment; 

999 - file sequence number, a sequence number of extracted file if export is broken into 

multiple parts, default value 001. 

For example, if Organization 1234 is submitting a single part OCAN assessment file on the 1 st of 

July 2009, at 5:05 PM the file name will look like this: 

OCAN2009070117051234IA.001.xml 

For example, if organization 5067 is submitting a single part RAI-MH assessment file on the 21 st 

of July 2009, at 6:15 PM the file names will look like this: 

RAI-MH2009072118155067IA.001.xml 

2.5 Submission Rules 

1. Each submission must contain at least one assessment record. 

2. As assessments are completed, updated or deleted in the source systems, they must be 

submitted to IAR as regularly as nightly. 

3. The source system must ensure that a submission does not include duplicate records. 

Duplicate is defined as two identical records. 

4. Each submission must have a unique organization ID and can only contain assessment 

record(s) for this organization. 

5. Each assessment record must have a unique record ID; and record IDs must be unique 

across the submitting organization. 

6. A maximum number of 500 assessment records will be accepted per submission. 

7. Each submission must conform to the submission schema [2] and be able to past validation 

against the XSD files provided as part of the requirements without any errors. 

8. Assessment records in each submission must conform to specifications provided by the 

corresponding assessment standard. 

9. The source system must provide the ability to resubmit individual assessment records or 

complete submissions. 

10. The source system must track successful and failed submissions as well as web service 

communications (attempts and responses) and store the logs for at least 30 days. 

11. Each web service client should be configured to make at least two additional attempts in 15 

minutes intervals to consume the web service if the first attempt fails due to connectivity 

errors such as connection failure or timeout. If these attempts are not successful, the 

submission must be transmitted by the next possible submission cycle. 

15



` 

2.6 Testing Process 

` 

IAR’s policy is to only accept submissions that conform to specifications provided to vendors and 

organizations. IAR will not accept live data until organizations’ vendors have successfully 

completed the standard testing process. A successful test is a submission that conforms to the 

specified schemas. 

The primary objectives of the standard testing process are to validate: 

• XML structure to ensure that it adheres to the specified XSD 

• All mandatory fields/values to ensure that they are populated 

• All expected values to ensure that they validate against expected value lists 

• Network Connectivity / ability to establish access to IAR environment 

IAR provides an Implementation Validation toolkit that includes test scenarios. Using the 

Implementation Validation toolkit, testing will be conducted in 2 phases (vendor testing and User 

Acceptance Testing) for each organization that uses a vendor external to the organization. If an 

organization uses an in-house vendor system, the vendor will be considered part of the 

organization and testing will be conducted in a single phase. 

Organizations using automated submission method: 

1. Once the interface is completed and tested by the vendor, vendors will generate and submit 

XML test file(s) to be validated by the IAR project team. 

2. Once the web service client is completed by the vendor and the XML structure (XSD) is 

validated, vendors will transmit test submissions in the IAR test environment using the web 

service client. 

3. Once the solution is delivered to the organization, a User Acceptance Testing (UAT) phase 

will be conducted to ensure that business requirements are met and assessment data can be 

sent to the IAR data repository. 

Organizations using manual submission method: 

1. Once the interface is completed and tested by the vendor, vendors will generate and submit 

XML test file(s) to be validated by the IAR project team 

2. Once the solution is delivered to the organization, a User Acceptance Testing (UAT) phase 

will be conducted to ensure that business requirements are met and assessment data can be 

sent to the IAR data repository. 

2.7 IAR PHI Validation Tables 

CCIM PHI 

Data Element Type Status 

Client ID (e.g. Chart Number) xsd:string Mandatory 

First Name xsd:string Mandatory 

Last Name xsd:string Mandatory 

Phone Number xsd:string Optional 

Health Card Number xsd:string Optional 

Country of Residence xsd:string Mandatory 

Province/Territory Issuing Health Card Number xsd:string Optional 

Gender xsd:string Optional 

Date of Birth(DOB) xsd:date Optional 

Estimated Birthday xsd:string Optional (“Yes” is estimated 

“No” otherwise 

16



` 

` 

Country of Residence Values 

Country 

Canada 

USA 

Other 

Unknown 

Valid Code 

CA 

US 

OTH 

UNK 

Province/Territory Issuing Heath Card Number Values 

Province/Territory 

Valid Code 

Alberta 

AB 

British Columbia 

BC 

Manitoba 

MB 

Newfoundland and Labrador 

NL 

New Brunswick 

NB 

Nova Scotia 

NS 

Northwest Territories Saskatchewan SK NT 

Nunavut 

NU 

Ontario 

ON 

Prince Edward Island 

PE 

Quebec 

QC 

Saskatchewan 

SK 

Yukon 

YT 

Unknown -70 

Not Applicable -90 

Gender Values 

Gender 

Male 

Female 

Other 

Unknown 

Valid Code 

M 

F 

O 

O 

3 Roadmap 

The following items are being considered as potential future enhancements of the submission 

interface and will be reflected in future revisions of this document: 

1. Adding date-time stamp to each assessment record within Submission Data 

2. Enhanced WS-Security implementation 

17



` 

` 

Appendix A - Assessment Specific Requirements 

OCAN Assessment Requirements 

IAR supports the following versions of OCAN: 2.1 (CMHCA), 1.0.2 and 2.0. Detailed structure of 

submissions was provided by the OCAN project team. 

The schema version is stored in the version attribute of root element of submission XML file. This 

attribute allows IAR to validate the content of submitted record based on the XML schema. 

In the case of OCAN 2.1 IAR requires corresponding client’s personal health information in addition 

to assessment data. The PHI data must conform to the schema defined in Documentation [3] - PHI 

submission schema and both PHI and assessment data must be included in the submission 

envelope as illustrated in submission structure 2. 

Organizations using OCAN 1.0.2 may submit assessment data to the IAR repository in UTF-16 

encoding without using the submission envelope. 

RAI-MH Assessment Requirements 

RAI-MH assessment data layout is based on existing Ontario Mental Health Reporting System 

(OMHRS) technical specifications. This specification defines XML that conforms to OMHRS 

Submission XML Schema and single ASCII file containing variable record length as approved 

formats. IAR supports the following versions of the Canadian Institute for Health Information (CIHI) 

submission specifications: 2008, 2009 and 2010 

In addition to assessment data IAR requires corresponding client’s personal health information. The 

PHI data must conform to the schema defined in Documentation [3] - PHI submission schema and 

both PHI and assessment data must be included in the submission envelope as illustrated in 

submission structure 2. 

The submission header fields – FiscalYearOfSubmission and DateOfSubmission will indicate the 

schema version of assessments in the file as described in the chart below. 

Date of Submission 

(not current date) 

April 1- May 31 

Fiscal year for which data is being submitted 

Previous fiscal year 

Current fiscal year 

Schema Version 

Previous fiscal year schema 

Current fiscal year schema 

June 1 – March 31 Previous or current fiscal year Current fiscal year schema 

For example the schema version will be defined as follow for submissions that are sent during 

fiscal year 2010: 

FiscalYearOfSubmission 2009 2010 2009 2010 

DateOfSubmission 

Apr 1, 2010 - 

May 31,2010 

Apr 1, 2010 - 

May 31,2010 

June 1, 2010 - 

Mar 31,2011 

Apr 1, 2010 – Mar 

31,2011 

Schema version 2009 2010 2010 2010 

18



` 

` 

Appendix B - IARSubmissionService-Client-side 

Technology Document 

This appendix is intended for vendors’ developers and should be used for information purposes 

only. It provides an example of how web service clients can be generated using Java. Vendors 

are free to choose their implementation as long as it meets the specifications. 

The SubmissionService client Web service stub was built and tested with the following 

technologies: 

1. JDK 1.6.x (http://java.sun.com/javase/downloads/widget/jdk6.jsp) 

2. Eclipse Galileo (Java IDE) 

(http://www.eclipse.org/downloads/download.phpfile=/technology/epp/downloads/releas 

e/galileo/SR2/eclipse-jee-galileo-SR2-win32.zip) 

3. Rampart (http://ws.apache.org/axis2/modules/rampart/1_0/security-module.html) 

4. Apache Axis2-1.4.1 (http://ws.apache.org/axis2/download/1_4_1/download.cgi) 

5. WSDL file (IAR_Submission_v1.1.wsdl) 

6. Apache Tomcat 5.5.27 (http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.27/bin/) 

Creating the Client stub code 

The following Web service Eclipse-Axis2 tutorial was used to auto-generate the client stub code: 

http://www.eclipse.org/webtools/community/tutorials/BottomUpAxis2WebService/bu_tutorial.html 

Customization to Client stub code 

Customization was necessary in the client code to incorporate the WS-Security requirement. 

Since the auto-generation by Eclipse does not incorporate WS-Security features out-of-the-box, 

Rampart is the WS-Security module that is made to plug into Axis2. A pre-defined WS-Security 

client Policy is needed in order for the client stub code to make a proper request. At this time the 

credentials (username and password) are being sent as plain text only. A different Security Policy 

will have to be used if these requirements were to change i.e. if the password is digested 

(encrypted). The following is the current Security Policy used by Axis2: 

 

 

 

 

 

 

 

 

19



` 

` 

 

 

 

 

The following Java snippet shows how the Security Policy is loaded into the client and a request 

being initiated: 

public SubmissionServiceStub() throws org.apache.axis2.AxisFault, 

XMLStreamException { 

//Web Service end point 

this("http://localhost:8181/IAR_Webservice5/services/SubmissionService" 

); 

Options options = _serviceClient.getOptions(); 

//loading client-plain-text-security-policy 

options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,Policy.loadPo 

licy("plain-policy-client.xml")); 

//setting credentials 

options.setUserName("libuser"); 

options.setPassword("books"); 

//engaging Rampart WS-Security engine 

_serviceClient.engageModule("rampart"); 

} 

Testing 

In order to confirm that the client side stub code has been configured correctly; the actual endpoint 

i.e. the web service needs to be deployed on a server that is accessible to the client stub. 

For local testing, an application server like Tomcat is suitable. The server side web service 

needs to be deployed as a standard Java web application archive file (*.WAR). Once the WAR 

file has been deployed, the web service will be active and be listening for incoming client 

requests. 

A typical request will look like this: 

 

 

 

 

libuser 

books 

 

 

 

 

 

 

20



` 

` 

8899 

my organization 

2009-10-10T12:00:00-05:00 

OCAN 

 

 

 

 

 

 

 

 

 

 

A sample response when the user is authenticated is: 

 

 

 

true 

 

 

 

A sample response when the user is not authenticated is: 

 

 

 

wsse:InvalidSecurity 

The security token could not be authenticated or authorized; nested 

exception is: 

javax.security.auth.callback.UnsupportedCallbackException: check failed 

 

 

 

 

Summary 

The above technologies outlined how a client stub can be configured to access a web service 

defined through a WSDL file. The use of auto-generation in Eclipse aid in producing client code 

quickly that is reliable and testable. Please refer to the technology links outlined in the start of 

this document for further information on the respective technologies. Additionally, the Web 

service Eclipse-Axis2 tutorial (link above) was helpful in implementing client and server side code 

for the web service. 

21

Data Submission and Technical Specifications (PDF - CCIM

Create successful ePaper yourself

Delete template?

Save as template?