HR-XML's background check ("screening") specifications are an interesting case study in standards adoption. The screening schemas are the largest and arguably the most complex within HR-XML's 2.* series of releases, but they also are among the most widely adopted. Why? This has a lot to do with market need and timing. You can trace the development of HR-XML’s Background Check specification back to discussions that began in 2001. It was a good bet that such integration would take off. Integration provided employers with time savings, policy compliance control, and convenience. For screening service providers, integration meant new distribution channels for their services. For the applicant tracking systems (ATSs) in the middle, integration capabilities became a competitive differentiator, and later as the market matured, a required capability. In 2001, you could see that demand for integrated screening services would take off (even before the tragic events of 9/11). However, consider that when we began to develop the screening standards, there was not yet a lot of industry experience to inform design decisions.
Over the years, integration patterns within the screening industry have emerged. Within the forthcoming 3.0 library, we've taken into account some of the common usage patterns. The 3.0 library also offers a much more flexible, configurable component library for "what comes next."
If you take a look at the Version 3.0 screening drafts, you can see that we reference three basic implementation patterns:
- Order by Package Identifier 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 can be added to what is predefined within a package. Structuring orders using pre-defined packages is the simplest implementation pattern.
- "À La Carte" Under the "à 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 the specific screenings. For example, details such as the type criminal records search to conduct and the number of years the search should cover might be explicitly specified when using the "à la carte" pattern.
- "Order by Package, Plus" A third pattern is termed "Order by Package, Plus". This pattern is a combination of above approaches. Orders are based on a PackageID, but also may include additional screenings on top of the standard package.
With knowledge of these implementation patterns, we made a variety of changes within the version 3.0 specifications (in addition to the extensive top-to-bottom changes necessary to port the prior data model to the new architecture). The way the 2.* BackgroundCheck request was designed, it implied that the requester would take information from a candidate's application and copy it within the separate, associated "Screening" components within the order regardless of whether the "order by package" or "à la carte" approach was used. For example, if employment verification was part of the services ordered you would put the employment history from the candidate's application within the BackgroundCheck/BackgroundSearchPackage/Screenings/SearchEmployment node. The problem with this design is that it doesn't fit the needs of those using the simpler "order by package" approach. It is a better fit with the "à la carte" style, which involves separate specification of the particular screenings ordered. Consider that for those using the "order by package" style, the scope of the search is pre-defined within the package (e.g., verify 5 years of employment). Thus, it would complicate matters for an implementer to try to extract information from the candidate's application at the right level of granularity and copy it within the SearchEducation node (and in similar fashion, to do this with all the other pieces of data required for all the other types of screenings covered by the package). Consequently, some order-by-package style implementers actually chose not to use the HR-XML BackgroundCheck request message and instead used the HR-XML "Candidate" (or the prior "JobPositionSeeker" specification) to send an intact candidate profile over to the screening provider. This allowed the requester to keep the candidate information together and to send it to the screening provider, which would figure out what parts of supplied candidate profile to use based on the rules built-into the agreed-upon package.
Within the Version 3.0 ScreeningOrder specification, the new design accommodates the three implementation approaches in a simpler fashion and removes ambiguity as to what information belongs where in which type of order. In the 3.0 version, the ScreeningSubjectDetails node accommodates the screening subject's complete profile. So those wanting to use a simple "order by package" style no longer need to use the work-around method of using HR-XML's Candidate or JobPositionSeeker. Consider that under the "order by package, plus" pattern, you'd similarly use the full-profile capabilities of ScreeningSubjectDetails, but also use the appropriate "Screening" components to add on the "à la carte" items. Likewise, if the order was completely à la carte, you would include at least minimum required fields within ScreeningSubjectDetails based on the type of screening and populate the appropriate nodes under ScreeningOrderPackage/Screening with the details required to execute the particular screening services being ordered.
So the version 3.0 screening specifications preserve the detail and expressiveness of the 2.* screening schemas, but have been updated so they better fit known industry usage patterns. Furthermore, in recognition that there is a large segment of the market that only uses the "order by package" pattern, the 3.0 library also includes SimpleScreeningOrder, which is an interoperable subset of the full ScreeningOrder. While this post has been all about ScreeningOrder, the most common fulfillment pattern is not to return full results, but to simply return "status" or a summary result and an URL where authorized personnel can log-in to review full results if necessary. To support this simple fulfillment approach, SimpleScreeningReport (an interoperable subset of ScreeningReport) is available.
Take a look at the new drafts and tells us what you think. A feedback form available at the bottom of each page. The above are just a few of the changes. I think those in the industry will find many improvements, including better support for international use.
