> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/use-cases/healthcare-clinics-and-allied-health/practitioner-utilisation-model.md).

# Practitioner Utilisation Model

This use case explains how to model practitioner utilisation for healthcare, clinics and allied health practices in Model Reef.

You will:

* Represent clinicians and teams in the branch structure or driver layer.
* Define capacity in hours, sessions or appointments per practitioner.
* Model booked time, no shows and billable utilisation.
* Connect utilisation to revenue, staffing cost and clinic profitability.

Model Reef is not a practice management or booking system. It operates above those tools as a planning and financial modelling engine.

***

## When to use this pattern

Use this pattern when:

* Revenue is driven primarily by clinician time.
* You want to understand capacity, utilisation and throughput per practitioner or per clinic.
* You need to test scenarios such as adding or removing clinicians, changing hours or shifting case mix.
* You want clinical activity wired cleanly into P\&L, cashflow and valuation.

It is often combined with:

* **Clinic Level Profitability**
* **Medicare or Private Billing Forecast**
* **Multi Clinic Consolidation**

***

## Architecture overview

The practitioner utilisation model has four layers:

* **Structure**
  * Branches per clinic, service line or team.
  * Practitioner counts and mix as drivers.
* **Capacity drivers**
  * Available hours or sessions per practitioner.
  * Working days, weeks and holidays.
  * Non clinical time assumptions.
* **Utilisation and booking drivers**
  * Booked time percentage.
  * No show and cancellation rates.
  * Paid time, bulk billed time and gap time.
* **Financial outputs**
  * Billable hours and sessions.
  * Revenue per practitioner and per clinic.
  * Staff and overhead cost per practitioner.
  * Margin per clinic and for the group.

***

{% stepper %}
{% step %}

### Decide how to represent practitioners

Choose a level of detail that is easy to maintain:

* Individual practitioners for small clinics or key personnel.
* Practitioner types (GP, physio, psychologist, specialist) for larger organisations.
* FTE groups by clinic and discipline.

In the Data Library, create drivers such as:

* `FTE Practitioners - GP - Clinic A`.
* `FTE Practitioners - Physio - Clinic B`.
* `FTE Practitioners - Psychologist - Group`.

These will be used to drive capacity and cost.
{% endstep %}

{% step %}

### Define capacity drivers

For each practitioner type and clinic, define capacity assumptions, for example:

* `Clinical Hours per FTE per Week`.
* `Weeks Worked per Year`.
* `Sessions per Hour` (for example short consults versus long consults).
* `Non Clinical Time Percentage` (admin, meetings, training).

Calculate:

* `Gross Available Hours = FTE × Hours per Week × Weeks per Year ÷ Number of Periods`.
* `Clinical Hours = Gross Available Hours × (1 minus Non Clinical Time Percentage)`.

Store these as drivers or variables at clinic or practitioner type level, depending on how you want to report.
{% endstep %}

{% step %}

### Model bookings, no shows and utilisation

Define utilisation drivers for each practitioner type and clinic, for example:

* `Booking Rate Percentage` (share of clinical hours that are booked).
* `No Show Percentage`.
* `Cancellation Fill Rate` (how much of cancelled time is refilled).

Approximate billable hours as:

* `Booked Hours = Clinical Hours × Booking Rate`.
* `Lost Hours to No Shows = Booked Hours × No Show Percentage × (1 minus Cancellation Fill Rate)`.
* `Billable Hours = Booked Hours minus Lost Hours to No Shows`.

If you prefer sessions rather than hours, use:

* `Sessions = Billable Hours × Sessions per Hour`.

These utilisation outputs will drive revenue.
{% endstep %}

{% step %}

### Connect utilisation to revenue

For each practitioner type and billing stream, define revenue drivers such as:

* `Average Fee per Session - Private`.
* `Average Rebate per Session - Medicare or Insurer`.
* `Average Gap Payment per Session`.

Create Revenue type variables per clinic and practitioner group, for example:

* `Revenue - GP - Clinic A`.
* `Revenue - Physio - Clinic B`.

Formulas might look like:

* `Revenue - GP - Clinic A = Billable Sessions - GP - Clinic A × Average Fee per Session - GP - Clinic A`.

If you split bulk billed, private and gap payments, create separate revenue variables per stream and sum them for total revenue.

Because these variables are typed as Revenue, they will flow into P\&L, Balance Sheet timing and Cashflow automatically when you set payment delays.
{% endstep %}

{% step %}

### Link practitioner utilisation to staffing cost

Create Staff type variables for practitioners, for example:

* `Staff - GP Salaries - Clinic A`.
* `Staff - Physio Salaries - Clinic B`.
* `Staff Oncosts - Super, Pension and Payroll Tax`.
* `Locum or Contractor Costs` if you use external clinicians.

Use FTE and salary drivers, for example:

* `Average Salary per FTE - GP`.
* `Average Contract Rate per Hour - Locum`.
* `Oncost Percentage`.

Formulas might look like:

* `Staff Cost - GP - Clinic A = FTE GPs × Salary per FTE × (1 plus Oncost Percentage)`.

This creates a clear view of practitioner revenue and cost that can be used for margin per FTE or per hour analysis.
{% endstep %}

{% step %}

### Build utilisation and margin dashboards

Create dashboards that show:

* Clinical hours versus booked and billable hours per clinic and practitioner type.
* Utilisation percentages and no show rates.
* Revenue and margin per FTE or per billable hour.
* Comparison of performance across clinics or practitioner types.

These dashboards help identify:

* Under utilised practitioners or clinics.
* High performing teams.
* Opportunities to improve booking practices, case mix or scheduling.
  {% endstep %}

{% step %}

### Use scenarios for staffing and demand changes

Clone the base model into scenario models to test different utilisation strategies, for example:

* Adding new practitioners or FTE to a clinic.
* Changing hours of operation or session lengths.
* Improving booking and no show rates with reminders or process changes.
* Shifting case mix between low and high fee services.

In each scenario, adjust:

* FTE and capacity drivers.
* Booking, no show and fill rate assumptions.
* Fee schedules and payer mix if relevant.

Compare scenarios using:

* Revenue and margin per practitioner and per clinic.
* Cash requirements and funding needs.
* Valuation changes, especially for multi clinic groups.
  {% endstep %}
  {% endstepper %}

***

## Check your work

* FTE counts and capacity assumptions align with real rosters and working patterns.
* Utilisation and no show rates look plausible against historical data.
* Revenue per practitioner and per clinic matches recent experience when calibrated.
* The level of detail is sustainable for your team to maintain over time.

***

## Troubleshooting

<details>

<summary>Utilisation appears unrealistically high or low</summary>

Double check that non clinical time is correctly specified and that booking and no show rates are not overlapping or double counted.

</details>

<details>

<summary>Revenue per FTE is far from historical results</summary>

Review average fee, payer mix and utilisation assumptions, and reconcile against recent billing reports.

</details>

<details>

<summary>Model is too detailed for a large group</summary>

Aggregate practitioners into types or FTE bands by clinic and only model key individuals explicitly where they significantly affect results.

</details>

***

## Related guides

* [Build a Forecast from Ticker Fundamentals](/how-tos/data-workflows-and-automation/build-a-forecast-from-ticker-fundamentals.md)
* [Build a Forward Valuation Using Ticker Fundamentals](/how-tos/valuation/build-a-forward-valuation-using-ticker-fundamentals.md)
* [Driver Overview](/help/drivers-variables-and-timing/driver-overview.md)
* [Period Toggle Rules](/syntax/chart-and-table-syntax/period-toggle-rules.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.modelreef.io/use-cases/healthcare-clinics-and-allied-health/practitioner-utilisation-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.