HIPAA & security policy_

Surgical Performance Pty Ltd (“SurgicalPerformance,” “we,” “us”)
Last updated: 31 July 2026
This page combines and supersedes our former HIPAA Policy and Data Security Incident & Breach Reporting Policy.
Related: Privacy Policy · Trust Center · Sample BAA

1. Our role: Business Associate
   SurgicalPerformance protects health information under the Australian Privacy Act 1988 and, for US customers, HIPAA and the HITECH Act.
   For US customers, we act as a HIPAA Business Associate: you (the surgeon, practice, or health system) are the Covered Entity, and we create, receive, maintain, or transmit Protected Health Information (PHI) on your behalf to provide outcomes tracking, reporting, and PROMS.
   The Business Associate under our BAA is Surgical Performance Pty Ltd. For US locations, we enter into a Business Associate Agreement (BAA) before PHI is submitted for that location. Acceptance is electronic and required when a US location is created during signup/setup, with a countersigned copy available on request. See our sample BAA.
   
   

2. What is PHI?
   PHI is individually identifiable health information relating to an individual’s health condition, health care, or payment for care. Health information that does not identify (and cannot reasonably identify) a person is not PHI.
   
   HIPAA treats records as identifiable if they include health information plus one or more of the standard identifiers (for example name, date of birth, phone, email, medical record number, and similar). A full list of the 18 identifiers is available from HHS; we treat any such combination as PHI.
   
   

3. PHI within SurgicalPerformance
   The platform is designed for identifiable patient data needed for follow-up and PROMS. That commonly includes:
   - Patient name and date of birth
   - Patient identifier (coded ID, MRN, or other value you enter)
   - Procedure and related clinical dates and outcomes data
   - Contact details for PROMS (phone / email) where you enable messaging
   - Survey responses linked to the patient
   Where your workflow allows, prefer an internal coded identifier as a minimisation practice — not a requirement that data be non-identifiable.
   You must only enter information you are authorised to process and configure PROMS messaging lawfully.
   
   

4. Privacy vs. security
   Privacy — rules about when PHI may be used or disclosed (including as directed by you and the BAA).
   Security — administrative, technical, and physical safeguards that protect electronic PHI (ePHI).
   
   

5. How we safeguard health information
   We maintain safeguards appropriate to the sensitivity of health information, consistent with the HIPAA Security Rule and APP 11 (security of personal information). In plain terms:
   
   Administrative
   - A designated Privacy / Security Officer: Dr Andreas Obermair, CEO
   - Workforce receive privacy and security awareness appropriate to their role
   - Access for our personnel is limited to what they need to operate and support the Services
   - A written incident / breach response process
   - Contractual safeguards with vendors that handle PHI on our behalf (including BAAs where HIPAA requires them)
   
   Technical
   - Unique user accounts for clinicians (credentials must not be shared)
   - Multi-factor authentication (MFA) is available for all clinician accounts
   - Encryption in transit (TLS) for connections to the public Services
   - We monitor and log system activity relevant to security and support of environments that hold health information
   - Application components (clinician App, API, PROMS, Reports) communicate over authenticated channels
   
   Physical / hosting
   - Primary application and clinical databases are hosted on Amazon Web Services in Asia Pacific (Sydney) / ap-southeast-2, including the API and PROMS databases. Physical data-centre security is provided by AWS.
   - We maintain backups of primary data stores.
   - HIPAA does not require US data residency. Supporting vendors (for example SMS, email, support, AI, or error monitoring) may process limited data outside Australia — see the Trust Center and Privacy Policy.
   
   

6. Subcontractors
   Where a subcontractor creates, receives, maintains, or transmits PHI on our behalf, we require written restrictions and safeguards appropriate to that role (including a BAA where HIPAA requires one).
   A vendor summary is in our Trust Center.
   
   

7. Incidents and breach reporting
   A breach (or eligible data breach / Breach of Unsecured PHI) is the loss of, or unauthorised access, modification, use, or disclosure of, personal information or PHI — as defined by applicable law and your BAA.
   
   How to report
   Email [email protected] promptly with when you discovered it, what information may be involved, and what you know about cause and scope.
   Report suspected unauthorised access, lost/stolen devices or credentials, phishing that may have exposed an account, or any other suspected misuse of data.
   
   How we respond
   Our Security Officer and relevant engineering leads form a Response Team to:
   1) Contain the incident and assess it
   2) Evaluate risk
   3) Notify customers, individuals, and regulators as required
   4) Reduce the chance of recurrence
   
   Australia (NDB): We assess whether an eligible data breach must be notified to the OAIC and affected individuals as soon as practicable, following OAIC guidance.
   United States (HIPAA): For a Breach of Unsecured PHI affecting a US customer, we notify that Covered Entity without unreasonable delay, and in all cases within 10 business days of discovery (as set out in our BAA), so you can meet your own HIPAA duties. Under HIPAA, Covered Entities generally must notify individuals within 60 days of discovery; larger breaches have additional HHS (and sometimes media) duties. Stricter state timelines may also apply.
   
   

8. Your responsibilities
   - Accept the BAA when creating a US location, before entering PHI for that location
   - Keep credentials confidential; do not share accounts; complete MFA as required
   - Use PROMS / patient messaging lawfully and minimise identifiers in SMS/email where possible
   - Report suspected incidents promptly
   - Handle patient rights requests in the first instance; we will assist as required under law and the BAA
   
   

9. Account end / offboarding (Patient Data)
   When your subscription ends or you request offboarding, handling of Patient Data follows the Privacy Policy and (for US PHI) the BAA. Typical options:
   1) Export then close — you export your cases / data from the product (or request an export), then close the account.
   2) Deletion request — you ask us (via [email protected] or an in-product control when available) to delete Patient Data we hold for your account, subject to legal retention and backup cycles.
   3) Retention where required — if return or destruction is not immediately feasible (for example backups, or records we must keep by law), we continue to protect that data under the BAA / Privacy Policy and limit further use until it can be destroyed.
   
   

10. Changes
    We may update this policy from time to time. Material changes will update the “Last updated” date and, where required by your BAA or law, will be communicated to customers.
    
    

11. Contact
    Security / breach / privacy / BAA: [email protected]