HR-XML: Enabling Pervasive HR e-Business

1. What is HR-XML?

The HR-XML Consortium is an independent, non-profit association dedicated to the development and promotion of a standard suite of XML specifications to enable e-commerce and the automation of human resources-related data exchanges.

The mission of the HR-XML Consortium is to spare employers and vendors the risk and expense of having to negotiate and agree upon data interchange mechanisms on an ad-hoc basis. By developing and publishing open data exchange standards based on Extensible Markup Language (XML), the Consortium aims to provide the means for any company to transact with other companies without having to establish, engineer, and implement many separate interchange mechanisms.

HR-XML has a global orientation. HR-XML members are located around the world - North America, Latin America, Asia, and Europe. HR-XML's members include many large multi-national organizations that require durable, robust data models that are useful in moving data among and between many different country contexts.

2. The Human Resources Management Problem Domain

Human resources management encompasses a diverse range of business processes. For instance, human resources management includes such diverse processes as advertising open positions, filing reports and notifications to government agencies, enrolling employees and their dependents within benefit plans, and ensuring that promotions, demotions, terminations and other changes in employee or dependent status are recorded appropriately in internal information systems as well as the systems of external partners and service providers. Although human resources management encompasses a remarkably disparate range of business processes, the processes are bound together by the need to synchronize HR data across internal and external systems. Consider the scenario depicted in Figure 1. A simple employee name change could require updates to an internal human resource information system (HRIS) as well as the systems of an external payroll service bureau and one or more benefit plan providers or administrators.

Figure 1: Data Synchronization in the HR Domain

2.1. HR Transactions Today

Today, there are significant obstacles to seamless, real-time synchronization between an employer's HRIS or payroll system and the systems of external service providers. The strong interest among employers in integrating with "best-of-breed" vendor solutions and the rapid proliferation of a wide-range of innovative hosted HR services exacerbates these problems and has motivated employers and vendors to work toward solutions.

The scenario depicted in Figure 2 illustrates some of the obstacles to efficient data interchange. Figure 2 depicts integration between several payroll systems and a third-party benefits plan administrator.

Figure 2: "Point-to-Point" Integration Between Payroll and DC/DB Administrator

This particular scenario involves the export of participant information for defined contribution plans (US-based plans, such as 401(k), 403(b), and 457, are depicted) and defined benefit pension plans. While this scenario involves benefits administration, the obstacles to data interchange in this scenario are typical of those encountered in countless other HR transactions. Those obstacles are:

• "Point-to-point" integration. Today, integration between systems of HR trading partners usually requires "point-to-point" custom integration. In other words, the integration of any two vendors systems usually requires the development of a custom interface. In Figure 2, tracing each unique integration path from a payroll system to the third-party administrator results in a complex "spider web" of custom integrations.

• Diversity in data formats. Because each pairing of vendor systems usually involves custom integration, there is great diversity in the format of the data exchanged. Comma separate values (CSV), ad hoc and custom flat-file formats, variants of electronic data interchange (EDI)transaction sets, and vendor-specific XML, are common ways data are formatted. Obviously, the lack of a common format for these transactions makes it impossible to repurpose programming code or to access data through a standard application programming interface.

• "Batch orientation." The lack of agreed upon transactional protocols is another key barrier to pervasive, real-time transactions. In the HR domain, the predominant way that data is updated or synchronized between systems is in batch mode. Moving to real-time transactions requires trading partners to have a shared understanding of the actions to be performed, success and error cases, transaction identifiers, and other implementation detail.

• Reliability/response mechanisms. Whether an HR transaction is accomplished in batch mode or interactively, the originator of the transaction wants to know that information was not only received, but "posted" or made effective within the receiving system. Again, the lack of agreed upon protocols for data exchanges makes it difficult to provide this type of response in a standard way. Consider for example, a corporate recruiting manager at a medium to large employer that posts 200 or more job openings to eight different job boards in the period of a week. The recruiter has an interest in knowing that the 200 job postings were received and deployed within the eight different recruiting venues. However, in some cases the recruiting manager may only receive this assurance by visiting the job board as a user to "eyeball" the postings.

2.2. HR Transactions Tomorrow

How will HR transactions be accomplished in the near future? By developing and publishing open data exchange standards, the HR-XML Consortium aims to provide the means for one trading partner to interact with others without having to establish, engineer, and implement many separate interchange mechanisms. Figure 3 depicts how transactions based on HR-XML standards might be accomplished.

Figure 3: Integration Between Payroll and DC/DB Administrator Via HR-XML

Integration via the HR-XML standard is accomplished through the "loose coupling" of trading partner systems. To integrate with any of the third party administrators shown on the left side of Figure 3, the payroll system vendors need only support a single interface to the HR-XML standard. Likewise, the benefits administrators need only to support a single interface from the HR-XML standard to move data into their benefits systems. By using the HR-XML standard, costly and time-consuming "point-to-point" integration can be avoided.

3. HR-XML Process and Methodology

HR-XML develops Document Type Definitions (DTDs) and XML schemas defining messages for key HR transactions. HR is a large and complex problem domain. The number of HR transactions that could be supported through standard messaging is enormous. How does HR-XML decide where to focus its efforts and how does it ensure consistency across its specifications? Some of the principles that are driving the work of the HR-XML Consortium are briefly reviewed below:

• Member-driven project priorities. The work of the HR-XML Consortium is member-driven. Members decide what projects the Consortium will undertake. This helps ensure that the Consortium's investments of time and money are spent on the members' most pressing data interchange problems. By keeping standardization efforts member-driven and transaction oriented, useful standards are likely to emerge more rapidly than if the Consortium's work was driven by a more academic, "top-down" analysis of the entire HR management problem domain. The process for initiating a project is simple. A member must complete a standard project proposal template. This template requires information such as the identification of the supported business processes, a business case rationale, a description of the problem domain, and information on any other related standards activities inside and outside the Consortium. Proposals must be sponsored by at least three member organizations and must undergo review by the Consortium's business steering committee.

• Management of "Cross-Process Objects." There are many advantages to dividing the Consortium's work into projects focusing on specific transaction areas - for example, recruiting and staffing, benefits enrollment, payroll, time and expense reporting, etc. However, one risk of dividing the work is that certain data models will be needlessly reinvented by different workgroups. Consequently, HR-XML has created the "Cross-Process Objects" workgroup, which is responsible for developing durable, reusable models for objects that are shared across many types of processes. Examples of cross-process objects (CPOs) are Person Name, Postal Address, Contact Information, Government Identification Code, etc. In addition to developing models for CPOs, the Cross-Process Objects workgroup is responsible for reviewing the work of the process-specific workgroups.

• Proceeding from a common reference model and glossary. The Consortium's Glossary Project supports the Consortium's various workgroups by developing a baseline system of knowledge, terms, and concepts to be extended throughout the work of HR-XML. The Glossary Project also is developing an high-level model of the key objects within the HR domain. The reference model and glossary are intended to provide important context to the Consortium's process-specific workgroups. For instance, HR-XML workgroups are unlikely to define a monolithic DTD or schema describing a "Human Resource." Nevertheless, DTDs and Schemas will incorporate many attributes of Human Resource. Therefore it is important that the workgroups proceed with a common definition of what a Human Resource is and know how the Human Resource object relates to other key objects within the domain.

3.1. HR-XML Deliverables

What exactly does the HR-XML Consortium produce? Simply stated, the HR-XML Consortium produces DTDs and Schemas that support data exchange between HR trading partners - for example, employers and job boards. HR-XML focuses on specifications for the payload of XML messages. HR-XML specifications are offered independent of specific messaging technology or transport. Other standards groups such as ebXML and the W3C's XML Protocol workgroups are developing specifications related to the transport and routing of XML messages. HR-XML does not duplicate or compete with standards work focused on developing XML messaging infrastructure.

In addition to the payload DTDs and schemas, HR-XML's specifications also will include important context on how the DTDs and schemas can be deployed. In general, there are three tiers of contextual information:

1. Models of events that trigger business processes. In the human resources management realm, it is important to understand how business and life events are related to business processes. A business event such as the termination of an employee's employment, triggers a wide variety of processes, such as messages to payroll and benefit providers as well as legally mandated notices to the employee. Similarly a life event, such as a name change resulting from marriage or divorce or the addition of a dependent child, triggers a variety of HR processes. The Consortium's models of business and life events provide context for understanding relationships between business processes and an avenue for discovering the Consortium's DTDs and schemas and the business processes they support.

2. Models of "reference" business processes. HR-XML does not attempt to standardize business processes. However, models of "reference" business processes are important in helping implementors understand how HR-XML DTDs and schemas can be deployed. The purpose of modeling business processes is to identify the actors involved in the business process and to identify the points in the process where they need to exchange information. It is possible that HR-XML members and groups of other HR trading partners may want to develop ebXML (see http://www.ebxml.org) Collaboration Protocol Profiles (CPP) based on the reference business processes published by HR-XML. For further information on modeling reference processes, see .

3. Interaction definitions. Interaction definitions provide a level of detail just below the reference business process. The reference business process identifies points in a process where trading partners exchange information. An interaction definition provides details on the requirements at the point of information exchange. For instance, an interaction definition would reference the DTD or schema for the payload to be exchanged, an action to be performed (for example, "Create", "Update," or "Delete"), and codes and an explanation relating to the type success and error cases.

3.1.1. Provisional Envelope

Although the HR-XML Consortium is focusing its efforts on the development of appropriate message payloads, it has published a "provisional envelope" intended to allow business partners to implement HR-XML in the absence of either de facto or de jure standards for routing and transport. The Consortium's provisional envelope specification specifies an envelope that can be used with an HTTP "simulated form post" as transport. The intention is to provide interested parties with a lowest-common denominator transport and routing approach that they can use with HR-XML specifications.

3.1.2. Reference Implementation

For each messaging specification developed by HR-XML, the Consortium will endeavor to publish a reference implementation. A reference implementation is a simple example application that proves that the messaging specification meets the objectives set for it by HR-XML members. Source code for reference implementations typically would be available to all member organizations.

3.2. Workgroup Methodology

The HR-XML Consortium currently has almost a dozen active workgroups. Developing meaningful data interchange standards is a multi-disciplinary exercise that requires expertise within the HR management problem domain as well as modeling expertise. Figure 4 depicts the recommended workgroup methodology:

Figure 4: Recommended Workgroup Methodology

The steps within this methodology are briefly reviewed below.

3.2.1. Study Problem/Define Project Scope

The input of domain experts, the review of any existing legacy data exchange formats, and the rapid prototyping of XML exchanges are useful for understanding the problem domain. The outcome of this step should be the identification of the business processes to be supported.

3.2.2. Model the Business Process

As discussed in , the purpose of modeling business processes is to identify the actors involved in the business process and to identify the points in the process where they need to exchange information. This modeling sets the context for further examinations of interactions between trading partners. The purpose is not to standardize the business process.

Models are developed as Unified Modeling Language (UML) activity diagrams that include a 'swim lane' for each trading partner involved in the business process. The points at which the flow of the business process crosses the 'swim lanes' are interaction points examined in later steps. The outcome of this step should be a UML activity diagram (see Figure 5) and the identification of inter-partner interaction points

Figure 5: Example Model of Supported Business Process

3.2.3. Create Interaction Definition

For each interaction point identified in the business process, an interaction definition is created. An interaction definition sets out the requirements necessary to execute the interaction. The interaction definition should specify the action to be accomplished, responses for successful and unsuccessful transactions, and other any requirements (for example, an approach for locally or globally unique transaction IDs) necessary to execute the interaction.

3.2.4. Define Interaction Content/Identify or Draft DTDs/Schemas

A DTD or schema is drafted to set appropriate constraints on the structure and content of the payload required to execute a particular interaction. Certain elements within the message payload may be unique to the business process being supported. However, many elements will be 'cross-process objects' that are used by a wide-variety of HR-related business processes. The output of this phase is a set of candidate DTDs. Note that this step and the previous one usually happen in parallel. It is difficult to separate the modeling of message exchanges without defining their content at the same time.

Often at this phase there exist prototype/proof-of-concept implementations of various parts of the business process. Working groups are encouraged to validate their thinking in practical ways. Some groups may prefer to model and then implement a prototype, while others may prefer to prototype then formally define the model.

3.2.5. Develop Reference Implementation

A reference implementation is a simple example application that proves that the candidate messaging specification meets the objectives set out in the project proposal. Source code for reference implementations typically would be available to all member organizations. Note that this reference implementation will often be little more than a refinement of various proof-of-concept exercises performed in preceding steps.

3.3. Initial Targets for Standardization

As discussed in , HR-XML's projects are member driven. The number of projects HR-XML is pursuing has grown rapidly and continues to grow. The sections below identify the Consortium's active workgroups and briefly describes their deliverables and statuses. The final section also speculates about new projects that may be launched later this year.

3.3.1. Recruiting and Staffing

Much of the Consortium's initial work focused on Recruiting and Staffing. On Oct. 17, 2000, the Consortium approved Staffing Exchange Protocol (SEP)Version 1.0, the first specification from the Recruiting and Staffing Workgroup.

The purpose of SEP Version 1.0 is to provide a simple protocol applicable to many common types of Internet-based recruiting and staffing data exchanges. Future versions of SEP may support a broader range of transactions, staffing models, and functionality. However, the guiding design principle in Version 1.0 was to limit the scope to a narrow range of transaction types that account for the majority of Internet-based recruiting and staffing transactions today.

SEP supports three types of transactions:

• JobPositionPosting. The JobPositionPosting exchange provides a standard method for a hiring company to electronically post a job or position to a job board or staffing company. The actors in this transaction are a JobPositionPosting Supplier (JPPS), which is typically a hiring company and a JobPositionPosting Consumer (JPPC), which is typically a job board or staffing company.

• JobPositionSeeker. The JobPositionSeeker exchange provides a standard method to transmit JobPositionSeeker information between the supplier and consumer. The participants of this transaction are the JobPositionSeeker Supplier, typically a job board or staffing company, and the JobPositionSeeker Consumer, typically the hiring company.

• JobPositionSeekerFeedback. The purpose of the JPSF is to allow the JobPositionSeeker Consumer to give feedback to the JobPositionSeeker Supplier about how appropriate a particular JobPositionSeeker (JPS) is relative to a particular JobPositionPosting. This might be done for several reasons:

  • To inform a contingency supplier that the JPSC would like further information on a JPS.

  • To accept or decline a JPS from a temporary staffing firm.

  • To supply a job board with a detailed evaluation appropriateness so that future matches can be more accurate.

  .

The Recruiting and Staffing Workgroup is finalizing its proposal for SEP 1.1, which will be DTD-based. The Workgroup also has identified priorities for SEP 2.0, which will use XML Schema to define message constraints. One of the major enhancements planned for SEP 1.1 is explicit support for the procurement of contract and temporary staffing.

3.3.2. Benefits Enrollment

The Benefits Enrollment workgroup is developing a single schema that can be used for transmitting enrollment information for a variety of benefit plan types, including tier-based, rate-based and FSA plan types. This work began in June 2000.

The Benefits Enrollment Workgroup's objective is to provide a single, standard schema for communicating benefits enrollment information between employers, insurance carriers, plan administrators, and other interested parties. Today, insurance carriers and administrators have their own specifications for accepting employee enrollment information from external systems. As a result, numerous proprietary enrollment specifications exist today. Consequently, trading partners are forced to develop several interfaces to support the requirements of each carrier or plan administrator even though the content of the information is similar.

In the United States, regulations issued under the Health Insurance Portability Protection Act (HIPPA) will require insurance carriers and certain self-insured employers to transmit enrollment data using certain ANSI X12 EDI transaction sets. One of the priorities for the Benefits Enrollment workgroup has been to ensure that the single enrollment schema maps to, and is interoperable with, the HIPPA-mandated transaction sets. The Benefits Enrollment Workgroup will illustrate this interoperability as part of a proof-of-concept demonstration scheduled for April 18, 2001 before the annual conference of the Workgroup for Electronic Data Interchange.

After the April proof-of-concept demonstration, the Workgroup will make further refinements to the schema, including the addition of components required for financial plan enrollments. A candidate version of the enrollment specification could be ready for a membership vote as early as the 3Q 2001.

3.3.3. Payroll

The mission of the Payroll Workgroup is to develop schemas to support a comprehensive range of interfaces into and out of payroll. The workgroup's first priority is focused on one-way integration from HR and Benefits systems to Payroll systems, including the transfer of basic HR information, payroll-related information, and benefits deductions.

The Payroll Workgroup is currently developing several draft schemas and specifications. While most of the initial work is focused on one-way integration from HR and benefits systems to payroll systems, the Workgroup also has a draft schema designed to support the export of defined contribution plan participant data from payroll systems to third-party administrators. The Payroll Workgroup is scheduled demonstrate the draft of its defined contribution plan export specification at the Society of Professional Administrators and Recordkeepers's (SPARK) Forum, Palm Beach Florida, Nov. 4 to Nov. 6, 2001.

In general, the many models being developed by the Consortium workgroup's have been constructed so that they are relevant across many country contexts. However, in some cases, country or region specific profiles make sense. Because tax laws vary dramatically from country to country, the Payroll Workgroup is developing country-specific profiles for certain tax components. The workgroup's initial plans are to develop tax profiles for the United States, UK, Canada, and Germany.

3.3.4. Competencies

The Competencies Workgroup was formed in Oct. 2000. The mission of this Workgroup is to develop a model of competencies that will provide a way to reference competency taxonomies developed by third parties.

Differing definitions of skills and the use of different skills taxonomies are a barrier to data interchange in the recruiting and staffing field. Employers use a variety of taxonomies to describe skills, as do job boards, recruiters, and staffing firms. Because of the great diversity in the way different recruiting venues classify skills and competencies, there are a number of firms that are well-established as job posting middleman. One of the main ways these firms deliver value to employers is handling the mapping between an employer's competency classifications and those used by the different job boards. A standard model for competencies will enable "plug-and-play" skills taxonomies and easier mapping between different taxonomies.

3.3.5. Cross-Process Objects

The Cross-Process Objects (CPO) Workgroup has three related roles within the HR-XML Consortium:

• Developing a common HR vocabulary and model for the Consortium.

• Developing schemas for common HR objects used across the Consortium's domain-specific workgroups (Recruiting and Staffing, Benefits Enrollment, Payroll, etc.)

• Reviewing the specifications produced by other HR-XML Workgroups for appropriate use of common HR objects.

The CPO's current projects are described below:

• The Glossary Project is focused on developing a common HR vocabulary and model for use by other Consortium workgroups.

• The CPO oversees teams that work on models and schemas for common HR objects, such as the many attributes of the Person object that must be handled consistently by different HR processes. The first two objects defined by the CPO and approved by the HR-XML Consortium's membership are PersonName and PostalAddress. The CPO is currently working on Version 1.1 of PersonName and PostalAddress and Version 1.0 of ContactInfo.

• The CPO also is devising a standard way to reference effective dates within HR-XML specifications.

• The CPO's Job/Position project is in the process of developing generalized, reusable models for the Job and Position objects.

3.3.6. New Projects

Proposals for a variety of other projects are being prepared. Two likely areas for standardization are listed below:

• Time and Expense Reporting. There are many circumstances under which organizations may need to exchange data regarding working hours. For instance, in an organization in which human resource and payroll functions have been outsourced, employee timesheet data would be approved, compiled, and transmitted to the outside HR/payroll administrator so payrolls could be calculated. Vendor companies also are sometimes required to provide working hour details to the clients to which they provide services. The schema produced by the project would include a framework to classify working hours and types of leave. However, the project would not undertake the standardization of any classification codes. Business Case Rationale - ROI Examples A simple, generalized schema for reporting working hours and absences from work could reduce the costs of integrating timekeeping and time recording systems with payroll and HR systems.

• Background Checking. Background checking has become a very formalized procedure compared to its beginnings when it was as simple as asking a friend or associate if they ever heard of your new applicant. Today's litigious society has driven the industry to new heights, and drives more and more employers into background checking programs every year. The current HR systems, customer systems, and the background checking vendors systems are unable to universally exchange information.

  The Background Checking Workgroup will research and model the specific processes to be supported. At a minimum, the workgroup will develop DTDs/schemas to support background checks requests from employers (or more generically BGCheckConsumers) as well as DTDs/schemas to support the return of background check reports from vendors of background check services (BGCheckSuppliers). The DTDs/Schemas will be developed to support a variety of types of background checks, such as checks relating to criminal records, education, employment history, and credit worthiness.

Design and Development by deepX Ltd.