HR-XML 3.0 Standards, 2009 September 23.
Menu: [ Home | Guidelines | BODs | Nouns | Global elements | WSDL | Packages | Code Lists | Master Index ]
Trace back: » pr01 | ch32 | pt02 | index | ch24s03 »
Several different implementation patterns have emerged in using HR-XML to manage orders for screening services. These are reviewed below.
The most common pattern for handling screening orders is for trading partners to structure orders on the basis of a "Package ID." Under this approach, collections of screening services are predefined within "packages" ordered by referencing an associated Package ID. No options are permitted beyond what is predefined within a package.
Structuring orders using pre-defined packages is the simplest implementation pattern. Implementers using this pattern exclusively will be able to use a simplified package that is interoperable with the full HR-XML screening specification, but is restricted to exclusively supporting the order-by-package implementation package.
Under the "a la carte" implementation pattern, the composition of services ordered is not pre-defined within a package, but rather is set at the time of the order. The customer specifies individual screenings within the order as well as any meta data necessary to execute specific screenings. For example, details such as the type criminal records search to conduct and the number of years the search should cover usually would be explicitly specified when using the "a la carte" pattern. In contrast, these details usually would be pre-defined under the order-by-package-identifier implementation pattern.
A third pattern might is termed "Order by Package, Plus". This pattern is combination of above two approaches. Orders are based on a PackageID, but also may include additional screenings on top of the standard package.
A single screening order typically encompasses multiple screenings (driver motor vehicle records, criminal records, employment verification, etc.). These might be encapsulated within a referenced "package" or might be separately specified under the "a la carte" style of order creation (see the section called “Screening Order Patterns”) which might be separately fulfilled when complete. So for any ScreeningOrder, there may be multiple associated ScreeningReport messages.
This is not always the case. For instance, another pattern might be for the screening provider to hold and aggregate individual screening results until all were available and then submit a consolidated report to the customer.
The authorized recipient of a screening report can vary depending on result content. For example, reports indicating that screenings had been completed without the discovery of potentially disqualifying information would likely be integrated directly back into the ATS or recruiting system so that the recruiter or hiring manager could proceed to the next step in hiring or other workflow. Where potentially disqualifying information is discovered, the recruiter or hiring manager typically would not be granted direct access to such information, but might receive some sort of associated status (e.g., "report pending review," "in progress," or "on hold"). A designated HR representative, compliance manager, or risk manager typically would be alerted of the material needing review and usually would log directly into the screening service provider's system to evaluate the findings. For additional information on this pattern, see the section called “Screening Report: Supported Processes”. Also see Chapter 9, Manage User Account. The User Account noun was developed in contemplation of this screening report use case, where the screening service provider system needs to be pre-provisioned with information about the authorized scope of work of users and the notification mechanisms associated with different events.
Further detail can be found in the separate documentation for the topics below: