Supporting Materials

Recommendation, 2007 April 15

Editor:

Kim Bartkus, HR-XML

Contributors:

Tim Farlow, Authoria

Kim Bartkus, HR-XML

Paul Kiel, HR-XML

Drew Cox, ePredix

Matt Tobiasen, Sterling Testing Systems

Craig Corner, First Advantage/Hirecheck

Abstract

This document describes the transfer of supporting materials. The schema is part of the HR-XML Consortium effort to define an XML vocabulary to support business transactions in the Human Resource domain.

Table of Contents

1 Overview.. 3

1.1 Objective. 3

1.1.1 Domain Issues. 3

1.1.2 Business Reasons. 3

1.2 Design Requirements. 3

1.3 Scope. 4

1.3.1 Major Components. 4

1.3.2 Items within the Design Scope. 4

1.3.3 Items Outside of Design Scope. 4

2 Supported Business Processes. 4

2.1 Trading Partner Roles. 4

2.2 Use Case Scenarios. 5

3 Schema Design. 6

3.1 Supporting Materials Diagram.. 6

3.2 Supporting Materials Elements Explained. 6

3.3 Metadata Diagram.. 10

3.4 Metadata Elements Explained. 10

4 Implementation Considerations. 12

4.1 Data Privacy. 12

4.2 Digital Signatures. 13

5 Appendix A - Document Version History. 13

6 Appendix B – Related Documents. 14

7 Appendix C – References. 14

8 Appendix D – Examples. 15

8.1 Embedded Data – Encoded Content 15

8.2 Embedded Data – Non-encoded Content 15

8.3 Referenced Information. 19

8.4 Attached Information. 20

1 Overview

Supporting materials are commonly passed with HR transactions. Examples may include a picture associated with a resume, a copy of a driver’s license sent as part of a background check, proof of good health sent with a life insurance enrollment, a copy of diploma or license, or a copy of a pay stub. Supporting materials may also include visual/audio media and binary data.

Some workgroups have constructed schema to pass supporting materials. This project would create a generalized structure to replace these structures.

1.1 Objective

The objective of this project is to create schema reusable across workgroups for passing miscellaneous documents by reference or by value. The project will also specify how workgroups can handle element values with images and other hard to code data types.

1.1.1 Domain Issues

Many transactions need to include, attach, or point to supporting documentation. This may affect numerous HR domains such as screening, enrollment and recruiting. Since this is cross-domain issue, the project will be undertaken by the CPO workgroup.

1.1.2 Business Reasons

At a minimum, this object will support existing schemas for business processes in assessment, recruiting (resume) and background checking. It also will support any other HR business process that needs a general way of specifying supporting materials, such as SIDES, enrollment, and payroll.

1.2 Design Requirements

Security - for attached documents, it may be important to include some sort of mechanism to guarantee the integrity of contents of the attachment to the client. The document may pass through several systems, negating any reliance on simple transport layer encryption (e.g. HTTPS).
Authentication - when providing access to externally linked reports or services, the vendor should require authentication. Ideally this would be through some sort of single sign-on facility, although simpler mechanisms are probably also required.
Identification - when a document includes multiple Supporting Material attachments and/or links, they probably need to include some sort of identify information such as type and description to allow them to be managed by an applicant tracking system.
Performance - if a document includes large file attachments, resending these attachments for every document may have performance implications. Implementation guidelines should be provided.
Change Control - the contents of these documents and linked resources may change over time, how should this be handled? We need to consider incorporating information about their creation and expiry times.

1.3 Scope

Supporting materials come in many different data formats, including text, formatted text, images, MS Word documents, PDFs, etc. They are very much like e-mail attachments. We need to handle at least 80% of common cases.

Supporting materials are sometimes just a reference to an existing document on line somewhere, but sometimes the document itself needs to be included in the structure. This may be embedded or attached to the document. The specification will handle all three types of supporting materials.

1.3.1 Major Components

Embedded Data
Attachments
References
Metadata
Access Credentials
Digital Signatures

1.3.2 Items within the Design Scope

This standard is designed to handle electronic documents associated with common human resources transactions. Examples include formatted resumes, pictures of job applicants, and images of official records. These items may be electronically signed.

1.3.3 Items Outside of Design Scope

Items outside of the design scope for this standard are supporting materials that cannot be either referenced with a URL, attached via electronic envelope, or practically embedded with base64 encoding. For example, this standard is not designed to send a physical object, to track a separate physical mailing, or to send a terabyte-sized database as base64 embedded data.

While this standard can pass copyright information, it has no direct support for digital rights enforcement.

2 Supported Business Processes

2.1 Trading Partner Roles

Because this is a Cross-Process Object, and not a transaction itself, the roles of trading partners in using this specification will be those of the business processes that pass supporting materials. Some of the common patterns for trading partner use of these entities are outlined in the use cases in the next section.

2.2 Use Case Scenarios

Supporting materials may be included in a variety of business transactions.

Recruiting:

Hard copy of resume
Picture of candidate
Proof of competency: certificate, license, or other document.

Assessments:

The hard skills assessment vendor provides an online facility where a suitably authorized user can drill down into full details of an applicant's responses to the assessment questions. This facility is accessed via a URL link.
A soft skills assessment vendor provides additional recruiting tools based on an applicant's assessment scores. For each applicant they produce a customized Interview Guide formatted as a PDF document attached to the AssessmentResult instance. This document is printed by the recruiter and taken into the in-person interview for the applicant.

Screening:

Storage of signed information. They need an entire signed package. For example, an arrest record with an image of the record.

Signed and in many cases notarized release forms. These forms are signed by the applicant or employee authorizing the release of the information contained in the driving records, credit files, etc.
Fingerprint cards - some agencies require fingerprint cards before they will release any criminal information. This typically occurs when there is insufficient information to identify the search subject.
Hardcopies of job applications.
Copies of letters to be returned to the client. This typically occurs in the case of sanction reports where the client or applicant requests a copy of the sanction for the agency issuing the sanction.

3 Schema Design

3.1 Supporting Materials Diagram

3.2 Supporting Materials Elements Explained

Elements and Attributes [Global types listed alphabetically in following table.]	ContentModel* Data type Occurrence: Sequence \| Choice \| All (minOccurs/maxOccurs) Attributes	Definition
/ SupportingMaterials	- SupportingMaterialsType - (1/1)	Allows the exchange of supporting information. [BusinessRule(s): Supporting materials may also include visual/audio media and binary data. ] [Example(s): A picture associated with a resume, a copy of a driver’s license sent as part of a background check, proof of good health sent with a life insurance enrollment, a copy of diploma or license, or a copy of a pay stub. ]
/ SupportingMaterials/ Id	- EntityIdType - S (0/*)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ SupportingMaterials/ EffectiveDate	StartDate - AnyDateTimeNkNaType - S (1/1) EndDate - AnyDateTimeNkNaType - S (0/1)	Date or time interval on or during which information or events are effective. Annotation: How long this supporting material is valid. [BusinessRule(s): It is recommended that all EffectiveDate elements contain at least a StartDate subelement. This date is inclusive. Dates are represented in accordance with ISO 8601. ]
/ SupportingMaterials/ EffectiveDate/ StartDate	- AnyDateTimeNkNaType - S (1/1)	Contains the (inclusive) date, period, or interval the event becomes active or begins. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ]
/ SupportingMaterials/ EffectiveDate/ EndDate	- AnyDateTimeNkNaType - S (0/1)	Contains the (inclusive) date, period, or interval the event becomes inactive or ends. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601.
/ SupportingMaterials/ ExtendedMetadata	dc:creator - [see include/import] - S (0/1) dc:subject - [see include/import] - S (0/1) dc:description - [see include/import] - S (0/1) dc:publisher - [see include/import] - S (0/1) dc:contributor - [see include/import] - S (0/1) dc:date - [see include/import] - S (0/1) dc:type - [see include/import] - S (0/1) dc:identifier - [see include/import] - S (0/1) dc:source - [see include/import] - S (0/1) dc:language - [see include/import] - S (0/1) dc:relation - [see include/import] - S (0/1) dc:coverage - [see include/import] - S (0/1) dc:rights - [see include/import] - S (0/1)	Contains additional information used to describe the data. [BusinessRule(s): This data is defined by Dublin Core.]
/ SupportingMaterials/ EmbeddedData	Content - xsd:string - C (1/1) EncodedContent - xsd:base64Binary - C (1/1) OriginalFileName - xsd:string - S (0/1)	Contains textual or formatted data. [BusinessRule(s): For multi-page items, each page would be a separate instance of this element. ]
/ SupportingMaterials/ EmbeddedData/ Content	- xsd:string - C (1/1)	Contains the content of the embedded data in text format. [BusinessRule(s): Note that the data COULD be inside a CDATA section. ]
/ SupportingMaterials/ EmbeddedData/ EncodedContent	- xsd:base64Binary - C (1/1)	Contains embedded data in Base64Binary format.
/ SupportingMaterials/ EmbeddedData/ OriginalFileName	- xsd:string - S (0/1)	The original name of the file. [BusinessRule(s): This name is assigned by the originator. In cases where the file name is lost during transport, this allows the parties to track the original file name. ]
/ SupportingMaterials/ AttachmentInfo	AttachmentId - EntityIdType - S (0/1) OriginalFileName - xsd:string - S (0/1)	Contains an attached document or file. [BusinessRule(s): For multi-page items, each page would be a separate instance of this element. ]
/ SupportingMaterials/ AttachmentInfo/ AttachmentId	- EntityIdType - S (0/1)	An identifier for one attachment associated with a transaction. [BusinessRule(s): Note that this element is mandatory – if you are sending a document as an attachment you must have an AttachmentId for it. ] [Example(s): A URI referencing a SOAP attachment part. ]
/ SupportingMaterials/ AttachmentInfo/ OriginalFileName	- xsd:string - S (0/1)	The original name of the file. [BusinessRule(s): This name is assigned by the originator. In cases where the file name is lost during transport, this allows the parties to track the original file name. ]
/ SupportingMaterials/ ReferenceInfo	InternetWebAddress - [see include/import] - S (0/1) OriginalFileName - xsd:string - S (0/1)	Contains reference information for the supporting materials.
/ SupportingMaterials/ ReferenceInfo/ OriginalFileName	- xsd:string - S (0/1)	The original name of the file. [BusinessRule(s): This name is assigned by the originator. In cases where the file name is lost during transport, this allows the parties to track the original file name. ]
/ SupportingMaterials/ AccessInfo	AccessCredential - AccessCredentialType - S (0/*) Instructions - xsd:string - S (0/1) UserArea - [see include/import] - S (0/1)	Contains Information necessary for accessing a document.
/ SupportingMaterials/ AccessInfo/ AccessCredential	- AccessCredentialType - S (0/*)	Information required to login to an account or document. [Example(s): Username, Password, Token, Account ]
/ SupportingMaterials/ AccessInfo/ Instructions	- xsd:string - S (0/1)	Provides directions to access a particular file or document.
/ SupportingMaterials/ UsageRestrictions	- xsd:string - S (0/1)	Provides any restrictions or disclosures related to the usage or access of the document. [Example(s): "File should only be accessed by manager level 2 and above." ; "Access to this file assumes the following liability". ]
/ SupportingMaterials/ Comments	- xsd:string - S (0/1)	Describes the contextual information relating to a group of elements. Annotation: What's in it, what to do with it once you have opened it or general comments.

Global types (alphabetically listed)	ContentModel* Data type Occurrence: Sequence \| Choice \| All (minOccurs/maxOccurs) Attributes	Definition
/ [AccessCredentialType]	xsd:extension base: xsd:string type - ExtendedAccessCredentialType -	Globally scoped data type. See element or attribute declaration for definition.
/ [AccessCredentialType] / type	- ExtendedAccessCredentialType -	Further defines the associated element in the context provided. [BusinessRule(s): Additional values are permitted if preceded by an x: ] [Example(s): PersonName/Affix context examples: type=”aristocraticTitle”..type=”formOfAddress”, type=”generation”, type=”qualification”. Contains the letters used to describe academic or other type qualifications held by a person and/or the distinctions conferred. ]
/ [AccessCredentialTypeType]	xsd:restriction base: xsd:string [Enumerations]: UserName, Password, Token, Account	Globally scoped data type. See element or attribute declaration for definition.
/ [ExtendedAccessCredentialType]	- [Union]: AccessCredentialTypeType, xStringPatternExtensionType	Globally scoped data type. See element or attribute declaration for definition.

3.3 Metadata Diagram

3.4 Metadata Elements Explained

These elements are defined in Section 2: The Dublin Core Metatdata Element Set of the following Dublin Core document: http://dublincore.org/documents/dcmi-terms/

Although Title and Format are outside the ExtendedMetaData section, they are defined here along with the other Dublin Core elements.

Element	Definition	Business Rule	Example
Title	A name given to the resource. Typically, a Title will be a name by which the resource is formally known.
Format	The physical or digital manifestation of the resource. Typically, Format may include the media-type or dimensions of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource.	Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types [MIME] defining computer media formats).	Examples of dimensions include size and duration.
Creator	An entity primarily responsible for making the content of the resource. Typically, the name of a Creator should be used to indicate the entity.		Examples of a Creator include a person, an organization, or a service.
Subject	The topic of the content of the resource. Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource.	Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
Description	An account of the content of the resource. Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.
Publisher	An entity responsible for making the resource available. Typically, the name of a Publisher should be used to indicate the entity.		Examples of a Publisher include a person, an organization, or a service.
Contributor	An entity responsible for making contributions to the content of the resource. Typically, the name of a Contributor should be used to indicate the entity.		Examples of a Contributor include a person, an organization, or a service.
Date	A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource.	Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format.
Type	The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content.	Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMI Type Vocabulary [DCMITYPE]). To describe the physical or digital manifestation of the resource, use the Format element.
Identifier	An unambiguous reference to the resource within a given context.	Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system.	Example formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL)), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).
Source	A reference to a resource from which the present resource is derived. The present resource may be derived from the Source resource in whole or in part.	Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.
Language	A language of the intellectual content of the resource.	Recommended best practice is to use RFC 3066 [RFC3066], which, in conjunction with ISO 639 [ISO639], defines two- and three-letter primary language tags with optional subtags.	Examples include "en" or "eng" for English, "akk" for Akkadian, and "en-GB" for English used in the United Kingdom.
Relation	A reference to a related resource.	Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.
Coverage	The extent or scope of the content of the resource. Coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity).	Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and that, where appropriate, named places or time periods be used in preference to numeric identifiers such as sets of coordinates or date ranges.
Rights	Information about rights held in and over the resource. Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights.	If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource.

4 Implementation Considerations

4.1 Data Privacy

Human resources data, by its very nature, is personal data. The laws of many jurisdictions as well as codes of fair information practice require organizations to handle personal data in a way that protects individuals from loss of privacy.

The data exchange specifications developed by the HR-XML Consortium are designed to be useful across many jurisdictions and within a variety of business contexts. It is not feasible for the HR-XML Consortium to develop specific privacy guidance for every jurisdiction or business context in which the Consortium's specifications might be implemented. When implementing data exchanges using the HR-XML Consortium's data definitions (or, for that matter, using any other type of data exchange mechanism), organizations are advised to examine the privacy protections that may be required under applicable law and codes of fair information practice.

For information on protecting personal data, general references include: European Union Data Protection Directive (95/46/EC); the Association Computing Machinery Code of Ethics (1992); Canadian Standards Association Model Code for the Protection of Personal Information (1995 – PIPEDA); and U.S.-EU Safe Harbor Principles and FAQs (2000).

5 Appendix A - Document Version History

Date	Description
2004-02-26	Initial draft
2004-03-15	Updated diagrams, tables. Added Examples
2004-03-25	Added Dublin Core definitions.
2004-04-20	Added guidelines for digital signature use.
2004-05-13	Made changes based on TSC feedback.
2004-May-24	Added 2 more examples.
2004-Jun-03	Changed Credential schema to AccessCredential schema. Updated any usage or reference.
2004-Jun-10	Moved AccessCredential schema into SupportingMaterials schema and updated documentation as needed.
2006-Feb-28	Approved by Consortium
2007-Apr-15	Approved by Consortium

6 Appendix B – Related Documents

Reference	Link
Supporting Materials Schema	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/SupportingMaterials.xsd
Supporting Materials Examples	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/SM_EmbeddedDataEncoded.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/SM_EmbeddedDataNotEncoded.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/SM_AttachmentInfo.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/SM_ReferenceData.xml
DateTimeDataTypes	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/DateTimeDataTypes.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/DateTimeDataTypes.xsd
Entity Identifiers	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EntityIdentifiers.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EntityIdType.xsd
User Area	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/HRXMLExtension.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/UserArea.xsd
TSC Extension	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/HRXMLExtension.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/xStringPatternExtensionType.xsd
Online Address	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/ContactMethod.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/ContactMethod.xsd
Digital Signatures	http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd

7 Appendix C – References

The schema is located at: http://dublincore.org/schemas/xmls/simpledc20021212.xsd

About the xml:

http://dublincore.org/documents/dc-xml-guidelines/

About the element set semantics:

http://dublincore.org/documents/dces/

http://dublincore.org/documents/dcmi-terms/

8 Appendix D – Examples

8.1 Embedded Data – Encoded Content

This example includes an encoded, embedded interview questionnaire in pdf format. It also includes the pass code necessary to access the encoded pdf file.

<SupportingMaterials xmlns="http://ns.hr-xml.org/2007-04-15" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.hr-xml.org/2007-04-15

..\CPO\SupportingMaterials.xsd">

</Id>

</EffectiveDate>

<dc:title>Interview Questionnaire</dc:title>

<dc:format>application/pdf</dc:format>

<dc:subject>Robert Jones</dc:subject>

<dc:publisher>ePredix Inc</dc:publisher>

<dc:date>2004-03-08</dc:date>

</ExtendedMetadata>

<EncodedContent>VGhpcyBhIHNhbXBsZSBIUi1YTUwgZW5jb2RlZCByZXBvcnQu</EncodedContent>

</EmbeddedData>

<Instructions>Access the embedded Adobe PDF file with the supplied password credential.</Instructions>

</AccessInfo>

<UsageRestrictions>ePredix Client confidential. Access restricted to authorized parties only.</UsageRestrictions>

<Comments>This interview guide is relevant for use with the specified subject only.</Comments>

</SupportingMaterials>

8.2 Embedded Data – Non-encoded Content

This example includes test results embedded as CDATA.

SupportingMaterials.xsd">

</Id>

</Id>

</EffectiveDate>

<dc:title>STSR1680002.html</dc:title>

<dc:format>text/html</dc:format>

<dc:creator>Sterling Testing Systems</dc:creator>

<dc:subject>Mark Smith</dc:subject>

<dc:date>2004-05-04</dc:date>

</ExtendedMetadata>

<Content><![CDATA[

<html>

<head>

<title>Results for Mark Smith</title>

</head>

<body>

<tr>

</tr>

<tr>

Subject Profile

</td>

</tr>

<tr>

ORDER#:

</td>

<td>

1380001</td>

</tr>

<tr>

COMPNAY NAME:

</td>

<td>

Put name of your company here.

</td>

</tr>

<tr>

SOC.SEC.NUMBER:

</td>

<td>

111-11-2859</td>

</tr>

<tr>

NAME:

</td>

<td>

Smith,

Mark</td>

</tr>

<tr>

CURRENT ADDRESS:

</td>

<td>

<tr>

<td>

</td>

<td>

1111 West County Road 550 South,

Franklin,

46131

</td>

</tr>

</table></td>

</tr>

<tr>

DOB:

</td>

<td>

1962-08-21</td>

</tr>

</table>

</center>

<tr>

</tr>

<tr>

Criminal Results

</td>

</tr>

<tr>

The criminal information reported on this website appears exactly as it is received from the local jurisdictions and may contain information which would be prohibited for use in making hiring decisions. Therefore, it is advisable to consult your corporate counsel prior to making any adverse hiring decisions.

</td>

</tr>

<tr>

<tr>

COUNTY:

JOHNSON

</td>

STATE:

IN

</td>

ZIP:

46131

</td>

CITY:

FRANKLIN

</td>

</tr>

</table>

</td>

</tr>

<tr>

<td/>

</tr>

<tr>

Screening Status:

</td>

<td>

Completed

</td>

</tr>

<tr>

<td>

Screening Alert:

</td>

<td>

Clear

</td>

</tr>

<tr>

Open Date:

</td>

Dec 11 2003 10:46AM

</td>

</tr>

<tr>

Close Date:

</td>

Dec 12 2003 11:22AM

</td>

</tr>

<tr>

<td/>

</tr>

<tr>

Screening Result:

</td>

</tr>

<tr>

No criminal convictions found.

</pre>

</td>

</tr>

</table>

</center>

</body>

</html>

]]></Content>

</EmbeddedData>

<Comments>This HTML may be displayed withing a frame or a separate browser window.</Comments>

</SupportingMaterials>

8.3 Referenced Information

This example includes a URL to an Assessment report. The username and password necessary to access the URL are also included.

..\CPO\SupportingMaterials.xsd">

</Id>

</EffectiveDate>

<dc:title>Assessment Detailed Narrative Report</dc:title>

<dc:format>text/html</dc:format>

<dc:subject>Robert Jones</dc:subject>

<dc:publisher>ePredix Inc</dc:publisher>

<dc:date>2004-03-08</dc:date>

</ExtendedMetadata>

<InternetWebAddress>https://integrate.epredix.com/hrxml/report/detail?sk=197e23sa</InternetWebAddress>

</ReferenceInfo>

<AccessCredential type="UserName">partner25</AccessCredential>

<Instructions>Request the referenced report from the included URL. Use the supplied username and password credentials.</Instructions>

</AccessInfo>

<UsageRestrictions>ePredix Client confidential. Access restructed to authorized parties only.</UsageRestrictions>

<Comments>The referenced HTML report may be displayed in a frameset.</Comments>

</SupportingMaterials>

8.4 Attached Information

This example contains the information necessary for an attachment.

SupportingMaterials.xsd">

</Id>

</Id>

</EffectiveDate>

<dc:title>123456789.tif</dc:title>

<dc:format>image/tiff</dc:format>

<dc:creator>Sterling Testing Systems</dc:creator>

<dc:subject>Consent and Disclosure Form for Mark Smith</dc:subject>

<dc:date>2004-05-04</dc:date>

</ExtendedMetadata>

</AttachmentId>

</AttachmentInfo>

<UsageRestrictions>This Consent and Disclosure form is only to be used for the candidate within this transaction</UsageRestrictions>

<Comments>Consent and Disclosure form required for Education Verification</Comments>

</SupportingMaterials>