Occupational Health and HR Systems: What Should an Integration Actually Share?

Integrating occupational health software with an HR system is often described as a data-sync project. Decide which fields move, connect two APIs and keep the employee lists aligned.

That description misses the difficult part.

HR and occupational health systems exist for different reasons. They have different users, records and information boundaries. A good integration connects their responsibilities without pretending they are one system.

The aim is not to synchronise everything. It is to move employment context into occupational health and controlled outcomes back to the people who are entitled to act on them.

Define the boundary before the interface

An integration design often begins with the available endpoints. That is too late.

Start by deciding which system is responsible for each piece of information. HR will usually remain authoritative for the employment relationship: the worker's identifier, status, organisation, role, location, manager and employment dates. Occupational health owns the clinical and operational work created in response to a referral, surveillance requirement or assessment.

The distinction sounds straightforward until the same concept appears in both systems. A worker has a job title in HR, but a referral may need to preserve the job and duties described when the request was made. A manager may change while a Case remains open. A site may be corrected after an assessment has taken place.

The integration should not force one value to do two jobs.

Current employment data can update as the organisation changes. Historical occupational health records may need to retain the context used for an earlier decision. Synchronisation without time can quietly rewrite history.

What the HR system can provide

Occupational health teams should not have to retype ordinary employment information for every worker. A controlled inbound feed can establish the person and keep relevant organisational context current.

Depending on the workflow, useful data may include:

• a stable worker identifier;
• name and appropriate contact details;
• employment status and effective dates;
• employing organisation or business unit;
• role, department and work location;
• current manager or authorised HR contact;
• start, transfer and leaving events.

This is not an argument for importing the entire personnel record. Payroll details, performance information and unrelated absence history do not become useful to occupational health merely because the HR API can supply them.

ICO guidance on workers' health information says organisations must not collect more health information than they need for their stated purpose. The same discipline is useful in the other direction: only bring employment information into the occupational health system where it supports a defined workflow.

A smaller interface is usually easier to explain, secure and maintain. More importantly, each field has a reason to be there.

What should remain in occupational health

The occupational health system should remain authoritative for the work it performs. That includes referrals, Cases, clinical appointments, assessment records, medical information, professional interpretation and the history of how an authorised outcome was reached.

Health information is special category data. ICO guidance explains that organisations need an Article 6 lawful basis and a separate Article 9 condition for processing it, together with any applicable safeguards under UK law.

The practical design lesson is not simply to encrypt the integration. It is to avoid creating unnecessary copies in the first place.

A manager may need advice about fitness for work, restrictions, adjustments or review dates. They do not usually need the clinician's notes, test results or the worker's complete medical history. ICO guidance recommends limiting managers' access to the information they need for their responsibilities and, as far as possible, keeping medical details with health professionals.

An HR integration should preserve that boundary. Sending a PDF into a general personnel folder because it is technically convenient may expose more information than the employer-facing process requires.

Outcomes should leave through a controlled route

Some information does need to move from occupational health to the wider organisation. The mistake is to treat that as a reverse copy of the clinical record.

The outbound flow should be designed around the employer action. It might communicate that a referral has been accepted, that an assessment is complete, that an authorised report is available or that a review date has been set. Where appropriate, it may convey defined advice or restrictions to authorised recipients.

Each item needs its own rules:

• Who is allowed to receive it?
• Has the outcome been clinically authorised?
• Does the recipient need the document, a status or a specific data point?
• What should happen if the manager changes before release?
• Can the information be corrected or withdrawn without leaving conflicting copies?

“Send the report to HR” is not an integration specification. It leaves the recipient, purpose, timing and access model unresolved.

A useful design sends the smallest authorised representation of the outcome that supports the next action. The clinical evidence remains where clinicians can use and govern it.

Identity is harder than field mapping

The most damaging integration errors often begin before any health information moves. The two systems fail to agree on who the person is.

Names change. Email addresses are reused or replaced. Payroll numbers may differ across employing entities. Contractors may not exist in the core HR platform at all. A person can leave and return with a new employment record while their occupational health history still matters.

Use a stable identifier where one genuinely exists, but do not assume that a single source covers every population. Define how duplicates, missing identifiers, rehires and contingent workers will be handled. Make uncertain matches visible for review rather than resolving them silently.

Two systems can agree perfectly and still be wrong if they agree on the wrong person.

That is why identity reconciliation needs its own operational process. It is not a one-off technical task completed during implementation.

Starters, movers and leavers are events

HR systems are good at describing organisational change. Occupational health software needs to interpret that change without losing clinical or operational continuity.

A starter event may create a person record, but it should not automatically create every possible assessment. The role and relevant risk information determine which occupational health work is required.

A transfer may change the worker's manager, site or exposure profile. The new values can govern future activity while earlier referrals retain the context in which they were raised.

A leaving event may remove routine access and cancel work that is no longer appropriate. It should not delete the occupational health history or make an outstanding clinical result disappear. Retention and continuing duties depend on the record and its purpose, not simply on whether the person remains active in payroll.

Treating these changes as dated events makes their consequences explicit. Overwriting a row is easier, but it erases the sequence that explains why the system behaved as it did.

Reliability includes visible failure

An integration is not reliable because it worked during a demonstration. It is reliable when routine failures can be found and resolved without guessing.

Employee feeds arrive late. A manager reference points to somebody who has left. An outcome cannot be delivered because the recipient no longer has access. The HR system accepts a message and then rejects one of its fields during later processing.

For each flow, define:

• how failed records are shown and who owns them;
• whether a message can be safely retried without creating duplicates;
• how the systems reconcile after an outage;
• which system wins when values conflict;
• how corrections are logged and replayed;
• how users can tell whether the information is current.

The integration is not complete when a message is sent. It is complete when the receiving system has applied it, or when the failure has become visible work for an identified owner.

APIs do not settle the operating model

Modern APIs, webhooks and event-driven connections can make information move quickly. They cannot decide what the information means or who should receive it.

Those decisions belong to the operating model. The technical interface should implement them in a way that remains understandable when the organisation changes, a new HR platform is introduced or another occupational health pathway is added.

Our occupational health software integrations page describes how Occentra separates identity, HR, occupational health and downstream systems. The same principle runs through the wider occupational health software model: each record should have a clear purpose and relationship to the work around it.

The strongest integration is not the one that moves the most data. It is the one where both systems remain clear about what they know, what they do and where their responsibility ends.