Occupational Health Case Management Software: What Should It Actually Do?

Occupational health case management software should coordinate the work created when an occupational health service accepts a request. It should show what needs to happen, who is responsible and whether the Case can move towards an outcome.

That sounds obvious. In practice, a Case is often treated as though it were the same thing as a Referral, an Appointment, a Form or the final Report. It is none of those things.

A Referral records the request for occupational health input. A Case coordinates the operational and clinical work that follows once the service accepts that request.

A management Referral might follow this sequence:

Referral received → accepted → Case opened → consultation booked → assessment completed → Report produced → follow-up required → Case closed

Every step changes the position of the Case. No single Appointment, Form or Report describes the whole lifecycle.

A Referral is a request. A Case is the work

A management Referral should preserve what the Client asked occupational health to consider. It may contain the reason for Referral, job and absence context, management questions and supporting information.

Before acceptance, the occupational health team may need to check that required information is present, clarify a question or confirm that the requested service is appropriate. Those activities belong to the Referral lifecycle.

In a clear Referral-to-Case model, acceptance provides the boundary. At that point, the service has reviewed the request and takes responsibility for the work in response. The Case becomes the operational record for that work.

• The Referral answers: What was requested, by whom and on what basis?
• The Case answers: What work is being done, who owns it and what remains outstanding?

Our guide to occupational health Referral management examines that boundary in more detail. For Case management, the important point is that the original request should not be rewritten as the work develops.

Suppose a Client asks whether an Employee is fit to return to their substantive role. The practitioner may later request job-demand information and recommend a review after a phased return. Those developments belong to the Case. They do not change the question that arrived in the Referral.

Acceptance and triage should establish the next action

Triage is not merely a label applied before an Appointment. It establishes how the accepted request should proceed.

Depending on the pathway, triage may determine whether more information is required, which service is appropriate, who should own the Case and which initial Tasks should be created. Some providers use defined operational checks for straightforward pathways; others require clinical review.

The software should support legitimate differences without leaving the current position to inference. If the Referral is accepted, that decision should be explicit. The resulting Case should have a clear start, a link to the accepted Referral and a visible next action.

Ownership should identify who moves the Case forwards

Every open Case should have clear responsibility. The owner might be a practitioner, Case manager, operational team or another role appropriate to the provider's model.

An assigned clinician does not always answer the operational question. The clinician may have completed the consultation while an administrator needs to obtain information, a reporting team needs to release the Report or a Case manager needs to arrange follow-up.

Good occupational health management software should therefore distinguish professional involvement from current operational responsibility where necessary. It should also record handovers. Reassigning a Case changes who is accountable for its next step, not just the value in a field.

Outstanding work should be represented as work

Cases stall when the next action exists only in a note, inbox or somebody's memory.

If information must be requested from the Client, an Appointment rearranged or a draft Report reviewed, that action should be visible. A useful Task normally has a clear action, an owner, a state and a due date where appropriate. It should remain connected to the Case and the event that created it.

Not every minor action needs a formal Task. Over-structuring routine work can create more administration than clarity. The test is whether failing to complete the action would prevent, delay or materially change the Case outcome.

A note says that something was discussed. A Task says that something still needs to happen.

Appointments, consultations and Forms are parts of the Case

An Appointment is scheduled time. A consultation is the professional interaction that may take place during it. A Form captures structured information. None of them is the Case itself.

An Employee may cancel or not attend. A consultation may take place but leave information outstanding. A completed Form may allow an assessment to begin without completing it. The Case remains open across those events.

Case management software should make it clear what was booked, what took place, what resulted and whether further contact is required. It should also retain which version of a Form or assessment template was used. Later template changes should not silently change the meaning of an earlier record.

Treating “Appointment completed” or “Form submitted” as “Case completed” hides the work that follows.

A Report can be an outcome without being the end

A Report often answers the questions in a management Referral. Producing it may still involve drafting, review, Employee consent or review where applicable, authorisation and release.

“Report created” is therefore not a sufficiently precise state. The Case should show whether the Report is being prepared, waiting for an action, authorised or released. It should retain the connection between the outcome and the Client's original questions.

Even a released Report may not complete the Case. A practitioner might recommend a follow-up consultation in six weeks or a review of workplace adjustments. The Report is finished, but the agreed work is not.

Follow-up should remain explicit

Consider a Case in which the first Report recommends a phased return and review after four weeks. The Case needs a future action, an owner and a reason it remains open.

The operational team should be able to distinguish between waiting for the Employee, waiting for the Client, follow-up due, further clinical review required, Report awaiting release and all work complete. The names and level of detail can vary between providers. The real position should not require somebody to read the entire record.

Closure should be a decision, not a side effect

A Case should close when the required work has reached a defined endpoint, not merely because a document was generated.

Closure may require confirmation that:

• required consultations and assessments are complete;
• Reports have reached their intended state;
• material Tasks are complete or have an explained resolution;
• planned follow-up is complete or no longer required; and
• the Case outcome is recorded.

The rules should reflect the pathway. Not every Case requires a Report, several Appointments or the same checks.

Closure should not erase unfinished work. If a Task is cancelled because the Client withdraws the request, the record should retain that reason. “Complete” and “no longer required” are different outcomes.

A giant activity log is not Case management

An activity log can show that somebody changed a status, uploaded a document or booked an Appointment. It is useful evidence, but it does not explain the current position by itself.

A long reverse-chronological list makes the reader reconstruct the present from past events. To answer “What is holding this Case up?”, they must work out which actions still matter and which have been superseded.

History and current state serve different purposes:

• Current state shows the owner, position, outstanding work and next action now.
• History explains how the Case reached that position and who did what.

Good software needs both. A tidy dashboard without history is hard to audit. A complete history without clear current state is hard to operate.

Case status should represent operational state

Case status is useful only when staff can predict what it means.

Labels such as “Stage 2”, “Pending” or “In progress” rarely tell a team what is happening. “Awaiting Client information”, “Consultation booked”, “Report in review” and “Follow-up due” describe observable positions and imply a next action.

One status should not encode every detail. Tasks, Appointments, Forms and Reports retain their own states. The Case status should summarise the most important operational position rather than replace the underlying records.

A useful test is to ask three people what a status means. If they give three different answers, it is an administrative label rather than a dependable workflow state.

Transitions should also prevent contradictions. A user should not be able to close a Case while required follow-up remains open. The controls should be proportionate: enough to protect the process, without forcing every exception through one inflexible sequence.

Historical traceability should remain readable

An auditable history should show the accepted Referral, relevant changes in ownership, Tasks and their resolution, Appointment outcomes, completed Forms and assessments, Report progress, follow-up and the reason for closure.

Auditability is not the same as storing every technical field change. A list of values changing may be accurate but operationally unreadable. Meaningful events should use domain language and retain the context needed to interpret them.

The record should be understandable without relying on the memory of the person who managed the Case.

How to evaluate occupational health case management software

Ask a supplier to demonstrate a realistic Case from acceptance to closure, including a change to the expected path. For example, the first Appointment is cancelled, the consultation takes place later, further information is requested, a Report is released and follow-up remains due.

Then ask:

• Can we see the original Referral separately from the Case work?
• Who owns the Case now, and how are handovers shown?
• Which actions are outstanding and who owns them?
• Can an Appointment, Form or Report be complete while the Case remains open?
• Does status describe a real operational position?
• What prevents closure while required work remains?
• Can different pathways vary without losing consistent meaning?
• Could a later reviewer understand what happened without reading every note?

The wider occupational health software guide considers how Cases connect with Employees, Clients, Referrals and other records. You can also see the place of occupational health Referrals within the broader Occentra platform.

Frequently asked questions

What is occupational health case management?

It is the coordination of accepted occupational health work through to an outcome. It covers responsibility, Tasks, Appointments, assessments, Reports, follow-up, closure and the history of how the work progressed.

What is the difference between a Referral and a Case?

A Referral records the request for occupational health input. A Case coordinates the work created when occupational health accepts that request. They remain linked, but they are not the same record.

Is a management Referral the same as a Case?

No. A management Referral is a Client's request for occupational health advice about an Employee. In the Referral-to-Case model described here, the service opens a Case when it accepts that Referral and takes responsibility for the resulting work.

Does every occupational health Case need the same workflow?

No. Providers may use different triage, ownership, assessment, reporting and follow-up processes. Good software allows appropriate variation while keeping core records and operational states clear.

A Case is valuable because it holds the work together. If a system shows the latest activity but cannot say who owns the Case, what remains outstanding and why it is still open, it is preserving events without managing the service.