HR-XML Integration WG Notes & Use Case Outline

[Darran Rolls <Darran.Rolls@Sun.COM>]

The following notes taken from the HRXML WG Meeting  2/22/2005

Attendees
=======
Darran Rolls - Sun
Matt Tobiasen - Sterling Testing Systems
Gary Cole - Sun
Mary McRae- OASIS

Notes taken by Gary & Darran
=====================
- Matt joined the call from the Screening Workgroup to explain the 
models and use cases that operate there
- The Screening Workgroup is focused on pre employment screening and the 
exchange of information between Applicant Tracking Systems (ATS) 
integrated Screening Systems (SS).  Example ATS's are Oracle iRecruit, 
PeopleSoft eRecruit and Recruitsoft, Sterling Testing Systems is an 
example SS.
- The ATS needs to create identities within the SS.  Two types of 
identities need to be created, those for users of the SS system (such as 
a new recruiter that will make new requests for screening) and those 
that represent the candidate (so that the candidate may sign into and 
directly use the SS to add/manage personal information
- Certain use cases may exist that require a session level SSO type 
exchange best suited to something like SAML.  Others (and those under 
consideration here) are around the creation and life-cycle management of 
these identities
- Background checking seems to be a well adopted area for HRXML and 
ideal for use of SPML

Outline Use Case Notes
================
- DR to draft strawman use case from the following:

Use Case scenario involves three actors:
- company "A"
- partners with (or uses) an Applicant Tracking System vendor "ATS"
- which partners with a Screening Vendor "SS".

1) *recruiter* identities from Company "A", for which
   -- the vendor "ATS" must maintain appropriate permissions
       --- different recruiters can see and do different things
   -- the vendor "SS" must maintain appropriate permissions
       --- different recruiters can see and do different things
2) applicant or *candidate* identities from Company "A", for which
   -- the vendor "ATS" must maintain appropriate confidentiality
   -- the vendor "SS" usually sees only as order data,
       UNLESS the candidate must log in to "SS system
       in order to review/correct the data used in the background check.
       In this case, the candidate is temporarily treated as an identity
       (e.g., given a temporary login to use on SS web site).

Company "A" (or "ATS" on behalf of A) orders a background check from "SS"
on dear old JoeBob, who has progressed from an 'applicant' to a 
'candidate' based on:
- application
- 1st and 2nd calls
- 1st and 2nd interviews
- skills assessment
Company A may hire JoeBob contingent on his passing a background check.
SS synchronously acknowledges the initial order for a background check.
SS asynchronously replies to ATS and/or Company A with status updates.
SS eventually returns results of background check to ATS and/or Company A.