Privacy Policy

Common Bond Pty Ltd (ACN 694 840 394) ("we", "us", "our") operates the Receptor workforce management platform. Receptor helps healthcare organisations manage worker rostering, preferences, and workforce allocation.

We are bound by the Privacy Act 1988 (Cth) and the Australian Privacy Principles ("APPs") as an APP entity that handles health-related personal information. This Privacy Policy explains how we collect, hold, use, and disclose your personal information when you interact with the Receptor platform.

This policy satisfies the requirement in APP 1.3 to make our APP privacy policy available free of charge and in an appropriate form.

This policy applies to:

• Workers — medical interns, PGY2 trainees, PGY3+ registrars, and other healthcare workers whose information is managed through Receptor
• Workforce administrators — hospital and health-service staff who use Receptor for rostering and allocation
• Visitors — individuals who visit our website or contact us

If your employer or contracting organisation ("Customer") uses Receptor, we handle your personal information in accordance with arrangements set out in the Data Processing Agreement ("DPA") between us and your Customer. Under the Privacy Act 1988 (Cth) both we and your Customer are APP entities bound by the Australian Privacy Principles in respect of the personal information we each hold. Your Customer determines the purposes for which your personal information is collected and used through the Platform; we handle that information on your Customer's behalf.

3.1 Information Provided by You or Your Organisation

3.2 Information We Collect Automatically

3.3 Health Information

In the course of workforce allocation, Receptor may collect or receive information that constitutes health information as defined in s 5 of the Health Records and Information Privacy Act 2002 (NSW) ("HRIP Act") and s 3 of the Health Records Act 2001 (Vic) ("HRA"). This information is also sensitive information within the meaning of s 6(1) of the Privacy Act 1988 (Cth) and is subject to the heightened collection requirements of APP 3.3 and the Health Privacy Principles ("HPPs") under both state Acts.

This information is collected from your Customer (or directly from you at your Customer's direction) for the primary purpose of workforce allocation and rostering.

Secondary use — ML training. Where health information in the categories above is used for machine learning model training (a secondary purpose), we obtain your explicit opt-in consent under HPP 9 (HRIP Act) and HPP 10 (HRA). We do not rely on the reasonable-expectation exception for secondary use of health information. You will be asked to consent separately and specifically before any of your health information enters the ML training pipeline. In particular, AHPRA registration numbers transit the ML training pipeline as an intermediate identifier and are pseudonymised (replaced with random per-run values) before any model training occurs — they do not appear in any ML training dataset in identifiable form (see §5.5.3 for the full pseudonymisation methodology). Consent is voluntary — declining has no adverse effect on your access to the platform or your allocation outcomes. For details of the de-identification methodology applied to ML training data, see §5.2.

3.4 Information We Do Not Collect

Receptor is a workforce allocation tool, not a clinical system. We do not collect:

• Patient health records or clinical data (diagnosis, treatment, medication records)
• Medicare numbers or individual healthcare identifiers (IHIs)
• Racial or ethnic origin, political opinions, religious beliefs, sexual orientation, or criminal records

We use your personal information for the following purposes:

We do not use your personal information for:

• Direct marketing (unless you separately consent)
• Profiling for purposes unrelated to workforce allocation
• Automated decision-making that produces legal effects — allocation outputs are recommendations to your Customer, not binding employment decisions
• Sale to third parties — we never sell personal information

5.1 Allocation methodology — deterministic optimisation, not generative AI

Receptor's allocation and rostering engine uses deterministic mathematical optimisation — specifically mixed-integer linear programming (MILP) — a deterministic optimisation framework, not a generative AI system, large language model, or neural network. It does not "learn" from your data to generate recommendations.

• What the optimiser does: Takes the scheduling constraints, preferences, and availability data you and your Customer provide, and solves for an allocation that satisfies the constraints and maximises preference satisfaction.
• What the optimiser does not do: Make binding employment, clinical, or disciplinary decisions. All allocation outputs are recommendations presented to your Customer's workforce administrators, who make the final allocation decisions. The optimiser is also not used for any form of automated profiling under the Privacy Act 1988 (Cth).

5.2 Three-tier data use

How Receptor uses your Personal Information in the optimiser and for supporting analytics is set out in the Customer DPA §3.4. In summary:

• Operational use on identifiable data: your preferences and availability are used in identifiable form to generate the allocation outputs for your Customer, and to produce the reports your Customer consumes. This is the primary purpose of the Platform.
• Pseudonymised run data (De-identified Run Data): to support continuous improvement of matching quality — including by generating affinity matrices used as statistical inputs to future allocation runs, and by training and evaluating machine-learning models that improve allocation outcomes — we may create De-identified Run Data from each allocation run. This data has direct identifiers replaced with randomly generated per-run values (unique to each run and not linkable across runs), applies a k ≥ 5 small-cohort suppression rule (any cohort of fewer than 5 workers is suppressed before export), and is not linked across runs. Despite these minimisation controls, De-identified Run Data constitutes pseudonymised personal information under s 6(1) of the Privacy Act 1988 (Cth) — because the patterns remain linked to your individual activity. Australian Privacy Principles (including APPs 6, 8, 11, and 12) apply to this data. It is retained for up to 10 years. Where De-identified Run Data is used to train machine-learning models, we do so only for workers who have opted in — see §5.5 for the opt-in mechanism, how to change your preference, and confirmation that opting out has no consequence for your allocation.
• Aggregated statistical derivatives: we may publish aggregated statistics (for example, cohort-level preference-satisfaction rates or year-over-year trends) externally — in marketing materials, research publications, or customer references. Any external publication applies a k ≥ 5 suppression threshold on every cell, category, and row.

5.3 No generative AI sub-processor in the allocation pipeline

No generative artificial intelligence service receives your Personal Information from the Receptor allocation pipeline. The optimiser does not send your data to Anthropic, OpenAI, Google's Gemini, or any other large language model provider as part of generating an allocation. Common Bond's public sub-processor list in clause 7 reflects this — it lists only the infrastructure suppliers that actually receive Platform data.

5.4 Common Bond's internal AI tooling

Common Bond uses generative AI tools (including Anthropic's Claude API via internal engineering agents, and Google's Antigravity coding assistant) for internal purposes only — software engineering, code review, documentation, compliance monitoring, and company operations. These tools do not have access to your personal information, Customer Data, or allocation inputs and outputs. Access is limited to infrastructure, code repositories, and internal governance registers. This separation is architectural and is enforced through access controls.

5.5 Machine-learning model training — opt-in consent

We use De-identified Run Data (described in §5.2) — which is pseudonymised personal information under the Privacy Act 1988 (Cth) — to train machine-learning models that improve the quality of future workforce allocation recommendations — for example, by generating affinity matrices that better predict worker-allocation compatibility. This is a secondary purpose under APP 6 of the Privacy Act 1988 (Cth). Rather than relying on the related-purpose exception in APP 6.2(a), we obtain your affirmative consent under APP 6.1 before including your pseudonymised data in any machine-learning training dataset.

5.5.1 How consent works

• Opt-in at registration. When you first create a Receptor account, you are asked whether you consent to your de-identified allocation data being used for ML model training. You must affirmatively select the opt-in option — the default is not opted in. No data from your allocation runs will be included in any machine-learning training dataset unless you have opted in.
• Change your preference at any time. You can update your ML training preference through the Data Preferences page in your account settings. A change to opt out takes effect from the next allocation run — data that was already de-identified and exported before the change is not retrospectively removed (because the de-identification process is irreversible and the exported data cannot be linked back to you), but no further data from your runs will be exported for ML training purposes after you opt out.
• Withdraw consent without consequence. You may withdraw your consent at any time with the same ease as giving it, consistent with the requirements of APP 6.1.

5.5.2 No consequence for allocation

Your opt-in or opt-out choice has no effect on how the Receptor allocation engine processes your preferences, generates your allocation recommendations, or treats you relative to other workers. The allocation engine operates identically regardless of your ML training preference. No worker receives more favourable or less favourable allocation outcomes based on their ML training consent choice.

5.5.3 What data is used

Only pseudonymised data (De-identified Run Data as defined in the MSA — direct identifiers replaced with per-run random UUIDs, with k ≥ 5 suppression) is used for ML model training. Despite the minimisation steps below, this data remains personal information under the Privacy Act 1988 (Cth) because the patterns retain linkage to your individual activity. The pseudonymisation process:

1. replaces all direct identifiers (your name, worker ID, AHPRA registration number, and other identifying information) with randomly generated values unique to each export — there is no persistent mapping between your identity and the training data;
2. applies a k ≥ 5 small-cohort suppression rule — if your combination of generalised qualification level and allocation-run dates would identify a group of fewer than five workers, the records are suppressed entirely and are not included in the training dataset; and
3. does not link data across allocation runs — each export uses fresh random identifiers, so your training data from one run cannot be connected to your data from another.

The resulting De-identified Run Data is pseudonymised personal information under the Privacy Act 1988 (Cth). Machine-learning models trained on this data are trained on statistical patterns and do not receive, store, or reproduce your name, worker ID, AHPRA registration number, or other direct identifiers — but the patterns do reflect your individual allocation activity.

5.5.4 Retention of ML training data

De-identified training data is retained for up to 10 years from the end of the allocation run to which it relates, consistent with the retention schedule in §10 and the Customer DPA §3.4.

5.5.5 Third-party ML processing

De-identified training data used for ML model training may be shared with a third-party machine-learning provider only where:

1. the provider has executed a Data Processing Agreement (DPA) or equivalent contractual protection consistent with the Customer DPA;
2. the provider is listed on our sub-processor register (see §7) and Customers have been given the required notice under §7; and
3. any cross-border transfer complies with APP 8 and the safeguards described in §8.

The de-identification commitments in §5.5.3 apply regardless of whether model training is performed internally or by a third-party provider. No generative AI service — including Anthropic, OpenAI, or Google Gemini — receives De-identified Run Data or any derivative of it as part of the ML model training process. At the time of this policy version, all model training is performed internally using Common Bond's own infrastructure hosted in Australia (see §7).

We do not sell your personal information. We may disclose it to:

We will not disclose your personal information to any other third party without your consent, unless required by law.

We use the following third-party service providers ("sub-processors") to operate the Receptor platform:

We maintain contractual protections (DPAs or equivalent) with each sub-processor requiring them to handle data consistently with the APPs.

We will give at least 30 days' notice to Customers before engaging a new sub-processor that handles personal information. The current sub-processor list is also maintained in the Data Processing Agreement.

Your primary data (identity, contact, employment, scheduling preferences, allocation outputs) is stored and processed within Australia — in Sydney (Supabase/AWS) and Melbourne (Google Cloud).

Some limited data may be processed outside Australia by the sub-processors listed in clause 7:

For these sub-processors, we have assessed the cross-border disclosure under APP 8 and are satisfied that:

• The data processed offshore is limited to technical/operational metadata and does not include direct personal identifiers, or
• The sub-processor is bound by contractual protections consistent with the APPs, or
• The sub-processor is subject to a law or binding scheme substantially similar to the APPs (s 16C of the Privacy Act).

We will not move your primary data (stored in Supabase or processed in Cloud Run) outside Australia without your Customer's prior written consent.

We take the security of your personal information seriously and implement measures appropriate to the sensitivity of the information and the risk of harm, including:

• Encryption in transit — all data transmitted to and from the platform is encrypted using TLS 1.2 or higher
• Encryption at rest — database storage is encrypted using AES-256 (via Supabase/AWS managed encryption)
• Access control — Row-Level Security (RLS) policies ensure that each Customer can only access their own data; role-based access controls restrict access within each Customer's organisation
• Authentication — Supabase Auth with JWT-based session management; multi-factor authentication for administrative access
• Monitoring — application-level error logging and security event monitoring
• Vulnerability management — automated dependency scanning and regular security audits
• Business continuity — point-in-time recovery with a Recovery Point Objective (RPO) of 24 hours and Recovery Time Objective (RTO) of 4 hours
• ISMS — we are working toward ISO 27001:2022 certification and maintain an Information Security Management System

We retain your personal information only for as long as necessary for the purposes described in this policy or as required by law.

After the retention period, we delete or de-identify your personal information in accordance with the Data Processing Agreement (clause 8).

11.1 Access to Your Personal Information (APP 12)

You have the right to request access to the personal information we hold about you. Under the Privacy Act:

• If your organisation uses Receptor: contact your employer or contracting organisation (the "Customer") first. They are the controller of your data and can access most of your information directly through the platform.
• If you want to contact us directly: send a written request to the contact details in clause 14. We will redirect your request to your Customer within 5 business days and assist them in responding within 15 business days.
• If you are not associated with a Customer: send a request directly to us and we will respond within 30 days.

We will provide access free of charge for the first request per 12-month period. We may charge a reasonable administrative fee for subsequent requests in the same period, and will notify you of any fee before processing the request.

Access to ML training records (APP 12.3 position): If you request access to your individual records in the ML training store (De-identified Run Data), we are unable to fulfil such a request. Access is not technically feasible because the de-identification process replaces your direct identifiers with per-run random UUIDs and does not retain a re-identification key — we cannot identify which training records relate to you. We treat this as technically infeasible / unreasonable effort under APP 12.3(c). You may exercise your right to opt out of future ML training data use at any time (see §11.3 and §5.5) — this is the practical remedy available to you for training data concerns.

We may refuse access only on the grounds permitted by APP 12.3 (for example, if the request is frivolous or vexatious, or if providing access would unreasonably impact the privacy of other individuals).

11.2 Correction of Your Personal Information (APP 13)

You have the right to request correction of personal information that is inaccurate, out of date, incomplete, irrelevant, or misleading. Your Customer's workforce administrators can correct most information directly through the platform's administrative interface.

If you believe information held by us is incorrect and your Customer cannot correct it through the platform, contact us at the details in clause 14.

11.3 ML Training Preference

You have the right to opt in to or opt out of the use of your de-identified allocation data for machine-learning model training at any time. You can view and change your preference through the Data Preferences page in your Receptor account settings. For details on how the opt-in mechanism works, what data is used, and confirmation that your choice has no effect on your allocation, see §5.5.

11.4 Complaints

If you believe we have breached the APPs or mishandled your personal information, you may lodge a complaint with us using the contact details in clause 14. We will:

1. Acknowledge your complaint within 5 business days;
2. Investigate the complaint and provide a written response within 30 days; and
3. If you are not satisfied with our response, inform you of your right to lodge a complaint with the Office of the Australian Information Commissioner (OAIC).

For complaints about our handling of health information under the HRIP Act (NSW) or HRA (VIC), see also the state complaint pathways in §11.5.4.

11.5 Access to and Correction of Your Health Information (State Law)

This section describes your rights in respect of health information (as described in §3.3) under the Health Records and Information Privacy Act 2002 (NSW) ("HRIP Act") and the Health Records Act 2001 (Vic) ("HRA"). These rights apply alongside your rights under the Commonwealth APPs described in §11.1 and §11.2. Where you make a request that engages both federal and state law, we will handle it under whichever regime provides you the stronger protection.

Common Bond is not a health service provider as defined in s 6 of the HRIP Act or s 3 of the HRA — it is a B2B workforce allocation software provider. Accordingly, the stricter access and correction obligations that apply to health service providers under HPP 14 and HPP 15 of each Act do not apply to us. The general organisation-level obligations under HPP 6–8 apply and are described below.

11.5.1 Access to your health information (HPP 6)

You have the right to request access to health information we hold about you under HPP 6 of the HRIP Act and HPP 6 of the HRA.

• How to request. Send a written request to the Privacy Officer at the contact details in §14. Specify that you are requesting access to your health information and describe the information you are seeking.
• Timeframe. We will respond within 30 days of receiving your request. This is the shorter of the two statutory periods (HRIP Act: 30 days; HRA: 45 days) and we apply it regardless of which state's legislation governs your information.
• Fees. We do not charge a fee for providing access to your health information. This aligns with the HRA position (s 30) and is more favourable than the HRIP Act (which permits a reasonable charge under s 23 but not for the making of the request itself).
• Customer-mediated requests. If your organisation uses Receptor, we recommend contacting your Customer first — they can access most of your health information directly through the platform (see §11.1). If your Customer cannot provide the information you need, contact us directly.
• ML training store. The technical infeasibility position described in §11.1 applies equally to health information in the ML training store. The pseudonymisation process replaces your direct identifiers with per-run random values and does not retain a re-identification key — we cannot determine which training records relate to you. You may opt out of future ML training data use at any time (see §11.3 and §5.5).
• Grounds for refusing access. We may refuse access only on the grounds permitted under the HRIP Act (s 22) or HRA (s 29) — for example, where providing access would pose a serious threat to the life, health, or safety of any individual, or where the request is frivolous or vexatious. If we refuse access, we will provide you with written reasons and advise you of your right to complain to the relevant state body (see §11.5.4).

11.5.2 Amendment of your health information (HPP 7)

You have the right to request that we amend health information we hold about you if it is inaccurate, incomplete, out of date, or misleading, under HPP 7 of the HRIP Act and HPP 7 of the HRA.

• How to request. Send a written request to the Privacy Officer at the contact details in §14, identifying the information you believe is incorrect and the amendment you are seeking.
• Timeframe. We will respond within 30 days of receiving your request.
• Customer-mediated amendments. Your Customer's workforce administrators can amend most health information directly through the platform's administrative interface (for example, updating registration status or screening records). Contact your Customer first if the correction relates to information they provided.
• If we refuse. If we decline to amend your health information, we will: (a) provide you with written reasons for the refusal; (b) at your request, associate a statement of the amendment sought with the relevant record so that the statement is apparent to anyone who subsequently accesses the record; and (c) advise you of your right to complain to the relevant state body (see §11.5.4).

11.5.3 Data quality (HPP 8)

We take reasonable steps to ensure that the health information we hold is accurate, up to date, complete, and not misleading at the time it is used for workforce allocation. In practice, this means:

• relying on data provided and maintained by your Customer through the platform;
• providing tools for your Customer to update health-related records (registration status, screening compliance, rostering exclusions) directly; and
• processing amendment requests under §11.5.2 promptly.

11.5.4 Complaints about health information handling

If you believe we have breached the Health Privacy Principles in handling your health information, you may:

1. Lodge a complaint with us using the internal process described in §11.4; and
2. If not satisfied with our response, lodge a complaint with the relevant state body:
   • NSW: Information and Privacy Commission NSW (IPC NSW) — www.ipc.nsw.gov.au | 1800 472 679
   • VIC: Health Complaints Commissioner — www.hcc.vic.gov.au | 1300 582 113

These state complaint pathways are in addition to the OAIC complaint pathway described in §11.4 and §14.

12.1 General notification

If we become aware of a data breach (as defined in Part IIIC of the Privacy Act 1988 (Cth)) involving your personal information, we will:

1. Notify your Customer without undue delay and, in any event, no later than 72 hours after becoming aware of the breach, consistent with clause 9.1 of the Customer DPA;
2. Cooperate with your Customer's assessment of whether the breach is an eligible data breach under Part IIIC and with any required notification to the Office of the Australian Information Commissioner (OAIC) and affected individuals; and
3. Take reasonable steps to contain and remediate the breach.

Your Customer is responsible for notifying the OAIC and affected individuals under Part IIIC. If you become aware of a potential data breach involving your Receptor account, please notify your Customer's administrator or contact us directly.

12.2 Breaches involving health information

Health information (as described in §3.3) is sensitive information within the meaning of s 6(1) of the Privacy Act 1988 (Cth). Under s 26WG(c) of the Privacy Act, the sensitivity of the information is a relevant factor in assessing whether an eligible data breach is likely to result in "serious harm" to affected individuals. A breach involving health information is therefore more likely to meet the serious harm threshold and to trigger the notification obligations under Part IIIC.

In addition to the general obligations in §12.1, where a breach (or suspected breach) involves health information held by us:

1. We will identify the affected health information categories — our breach notification to your Customer will specifically describe which categories of health information (see §3.3) are involved, so that your Customer can accurately assess the risk of serious harm under s 26WG;
2. We will notify you directly where we are independently required to do so — where we hold the affected health information as an APP entity in our own right and an eligible data breach has occurred, we will notify you directly in addition to notifying your Customer, as required by Part IIIC; and
3. We will cooperate with state health privacy regulators — the health information described in §3.3 may also be subject to the Health Records and Information Privacy Act 2002 (NSW) ("HRIP Act") and the Health Records Act 2001 (Vic) ("HRA"). While neither Act imposes a standalone breach notification scheme equivalent to Part IIIC, each confers investigative jurisdiction on the relevant state commissioner. Where a breach involves health information of workers in New South Wales or Victoria, we will cooperate with any investigation by:
   • the Information and Privacy Commission NSW under the HRIP Act; or
   • the Health Complaints Commissioner (Victoria) under the HRA.

12.3 How you will be notified

Where we are required to notify you directly of an eligible data breach involving your health information (whether under Part IIIC of the Privacy Act or at your Customer's direction), we will:

• contact you using the email address associated with your Receptor account;
• describe the nature of the breach, the categories of health information affected, and the steps we have taken or propose to take to contain and remediate the breach; and
• provide this notification as soon as practicable after completing our assessment under s 26WH of the Privacy Act.

Where your Customer is responsible for notifying you (as is the default under the Customer DPA), we will provide your Customer with the information necessary to notify affected workers promptly.

12.4 Regulatory notification and complaints

For eligible data breaches involving health information:

• OAIC — under the Customer DPA, your Customer (as Controller) is generally responsible for assessing and notifying the OAIC under Part IIIC. Where we hold health information as an APP entity in our own right, we will notify the OAIC directly as required.
• State commissioners — the HRIP Act (NSW) and HRA (Vic) do not impose a standalone breach notification scheme, but the relevant state commissioner may investigate complaints about health information handling. You may lodge a complaint with the Information and Privacy Commission NSW (for health information held under the HRIP Act) or the Health Complaints Commissioner (Victoria) (for health information held under the HRA), in addition to your rights under §11.4 and §14.

We may update this Privacy Policy from time to time. We will:

• Publish the updated policy on the Receptor platform and our documentation site;
• Notify Customers of material changes at least 30 days before they take effect; and
• Update the version number and "Last updated" date at the top of this document.

Your continued use of the platform after the effective date of a revised policy constitutes acceptance of the revised terms.

For privacy enquiries, access requests (APP 12 / HPP 6), correction requests (APP 13 / HPP 7), health information requests (§11.5), or complaints:

If you are not satisfied with our handling of your enquiry or complaint, you may lodge a complaint with:

For complaints about health information handling under state law, you may also contact: