Why We Started Building Occentra

Occupational health software rarely becomes complex all at once.

Bespoke complexity is almost never commissioned as such. It arrives one reasonable request at a time.

A client asks for an extra question on a referral form. Another needs a different approval before a report can be released. A new service requires its own case status. An integration needs information that the system was never designed to hold.

Every change solves a real problem. Taken together, they create a system in which apparently similar cases behave differently, fields have several meanings and nobody can change an old rule without first discovering who still depends on it.

That pattern matters more than the age of the software or the length of its feature list. It is the main reason we started building Occentra.

Occupational health changed around its systems

Occupational health has evolved. Providers support complex contracts across more delivery models. Assessments take place in clinics, by telephone and by video. Referrals arrive through portals and integrations as well as email. Reports pass between clinicians, employees and employers under rules that may vary by service.

The work is also expected to be more visible. Employers want to know what is happening with a referral. Operational teams need to see where cases are waiting. Clinical leads need a dependable record of review and release. Data needs to move into other systems without someone explaining that a field means one thing for Client A and another for Client B.

The basic domain has not become unrecognisable. A referral requests occupational health input. A case organises the work. An assessment records a clinical activity. A report communicates advice.

What changed is the number of ways in which that work can be commissioned, delivered and connected.

Established systems responded as working systems often do: by adding what was needed. Many now contain years of valuable operational knowledge. They also carry the cost of representing new variation through old structures.

The problem is not that they failed to evolve. It is that repeated change without a stable model eventually makes further change unsafe.

A system can have every screen and still lose the workflow

Most occupational health platforms can receive referrals, book appointments, record clinical information, generate documents and produce reports. Buying another module rarely fixes the underlying difficulty.

Consider a management referral. The manager’s questions are captured in one form, then copied into an assessment because the clinician cannot see them in context. The report is generated inside the system, but the employee’s request to review it is managed through an inbox. An administrator sends the final document and updates a case status that still says “in progress”.

Every feature exists. The workflow does not.

The missing part is not another screen. It is a shared account of what is happening: why the case exists, which stage it has reached, what decision is needed next and who is responsible for it.

This weakness often presents itself as a reporting request. A provider wants a dashboard showing cases awaiting a report, only to find that “awaiting report” means different things across services or that the real state is stored in a note.

The dashboard is the easy part. The hard part is giving the underlying work a consistent meaning.

The smallest exception may carry the largest cost

Occupational health providers cannot avoid variation. Different clients commission different services, ask different questions and agree different reporting arrangements.

Bespoke development offers an understandable response. Change the software for this client, contract or pathway, and leave everybody else untouched.

Sometimes that is the right answer. A genuinely unusual requirement may not belong in a shared product. The mistake is to make custom development the normal way the system learns anything new.

Each local rule creates an assumption that future changes must preserve. Testing expands. Training becomes client-specific. A general improvement cannot be released until its effect on private variations is understood.

The most expensive customisation is not always the most complicated. It may be a five-line rule written years ago for one client. The code is easy to read. What is difficult is knowing whether a contract, a report template or an administrator’s daily routine now relies on it.

Code records what the system does. It rarely records why an exception was introduced or when it can be removed.

That is how a small request becomes a permanent constraint.

Configuration needs boundaries

Replacing bespoke development with unlimited configuration would reproduce the same problem through a different interface.

If every client can invent statuses with unrelated meanings, provider-wide queues become unreliable. “Clinical review”, “with clinician” and “awaiting sign-off” may describe the same point in the work, or three different points. A configurable label has quietly changed the operational model.

Useful configuration separates stable meaning from legitimate variation.

A provider may configure referral questions, assessment templates, approval steps and report recipients. Those choices can vary without changing what a referral, assessment or report is. Workflow states can have appropriate labels while retaining a common operational meaning.

Configuration is not the ability to make everything different. It is the ability to express known differences without losing the shared model.

That model also creates consistency without forcing sameness. A health surveillance recall and a management referral should not follow the same pathway. Both should still have a clear current state, a defined next action and an identifiable owner.

The same principle applies to audit history.

Many audit logs can prove that somebody clicked “save”. They cannot explain what changed, which report was approved or what was released to the employer.

A useful case history records meaningful events: referral submitted, assessment completed, consent changed, report approved, document released. When those events also drive the workflow, traceability is produced by normal work rather than reconstructed after a complaint.

The philosophy behind Occentra

Occentra began with the view that occupational health software needs a clearer foundation, not another layer of features.

We prefer configuration to customer-specific code, but configuration within clear boundaries. We keep referrals, cases, assessments and reports distinct so that changing one does not quietly change the meaning of another. We treat workflow and audit history as two views of the same events.

The aim is not to eliminate complexity. Occupational health is complex because the work carries clinical, operational and employment consequences. Hiding that complexity would produce software that is tidy and wrong.

The aim is to represent complexity deliberately, so that a new requirement can become a supported variation rather than another private version of the product.

Occentra is not trying to reinvent occupational health. The clinical expertise and working practices already exist. We are building the software the industry should have had all along.

The real test of that software is not how much it can be made to do today. It is whether it can accept tomorrow’s reasonable request without making the request after that harder.