Health Data Protection Notice

Version 2026-07-26 · Effective 26 July 2026

This notice describes the technical and organisational measures AirSpire Health actually has in place to protect patient health data, and how that data is used inside the service. It is the security companion to the Privacy Policy, which covers what we collect and your rights over it.

1. How your health data is used inside AirSpire

• Treatment. Your symptom logs, peak-flow readings, and questionnaire scores feed the zone engine, which maintains your action plan and raises an alert to your physician when your control deteriorates. Your assigned physician can read your chart, write consultation notes, and issue prescriptions.
• Safety. If your readings put you in the red zone, the app shows a full-screen emergency prompt on every page and can email a red-zone alert. This is automated risk flagging, not a diagnosis.
• Payment. Consultation fees and shop orders are charged through Paystack, and physicians are paid their share through a Paystack subaccount. Payment records are linked to appointments and orders, not to your clinical notes.
• Fulfilment. Where an order needs a prescription, the pharmacy partner dispensing it receives that prescription along with your delivery details.
• Operations and compliance. Our operations team can view records to support you, investigate a problem, or meet a legal obligation. The records-access log captures designated physician chart access and selected clinical and operations actions; it does not yet capture every operations page view.

We do not use your health data for marketing, do not sell it, and do not use it to train machine-learning models.

2. What is implemented today

Each item below is a control that exists in the running application, not an aspiration.

Encryption in transit

All traffic is served over HTTPS with HTTP Strict Transport Security, so browsers refuse to fall back to an unencrypted connection.

Encryption at rest for sensitive free text

The clinical free-text fields most likely to contain sensitive detail are encrypted with AES-256-GCM before they are written to the database, and are decrypted only for the roles entitled to read them. Specifically:

• Consultation notes — subjective, objective, assessment, plan, follow-up, and referral notes.
• Prescription notes and per-medication instructions.
• Your symptom-log triggers and notes.
• The action a physician recorded against an alert.
• Your order delivery address, delivery notes, pharmacy notes, and internal admin notes.

Being specific also means being clear about the boundary: structured clinical values — peak-flow numbers, severity scores, zone status, questionnaire scores — and your profile fields are not individually encrypted at rest. They are protected by the access controls below and by the security of the underlying platform, not by field-level encryption.

Role-based and row-level access control

Every data table declares, per operation, who may read and write it. Patients can read only their own rows. Two-party clinical data is not exposed through generic data endpoints at all: a physician reaches a patient’s chart only through a server-side route that verifies the patient is assigned to them, so changing an identifier in a request does not reveal someone else’s record. Patients cannot write the fields that would let them alter clinical meaning — the patient a reading belongs to, the calculated zone, whether a questionnaire has been reviewed, or the amount and payment status of an appointment are all set by the server.

Records-access audit log

Designated physician chart access and selected clinical and operations actions are written to an append-only audit table: who acted, in what role, on which record, what they did, why, and when. The log does not yet capture every operations page view. Entries are written by the server, cannot be written by ordinary users, and cannot be edited or deleted through the application by anyone — including our own operations team. The one exception is a right-to-erasure request, which unlinks that patient’s past entries from them rather than removing the entries. Patients can review their own access history under Settings → Recent Access. (For historical reasons the underlying table is named hipaa_access_logs; the name is an internal identifier and does not imply HIPAA coverage.)

Append-only consent ledger

Every consent decision is stored as an immutable, dated entry recording the consent type, whether it was granted or withdrawn, and the document version it applied to. During ordinary account use entries are never edited or deleted — withdrawing consent adds a new entry — so neither you nor we can quietly rewrite the history of what was agreed. A verified right-to-erasure request deletes the subject’s consent ledger with the rest of their identifiable record. Consent can only be recorded by the signed-in person it belongs to, through a single server-side route that takes the identity from the session and stamps the document version itself, so a consent record cannot be forged or back-dated onto a superseded version.

The ledger is also enforcing, not decorative: if there is no active health-data-collection consent on record, the server refuses to store new symptom, peak-flow, or questionnaire entries and returns an explicit error.

Account security

Passwords are stored only as one-way hashes and must be at least eight characters combining upper and lower case with a special character. Five failed sign-ins lock an account for 15 minutes. Sessions use HttpOnly cookies that JavaScript cannot read, expire after 24 hours, and every state-changing request carries a cross-site request forgery token. Time-based one-time password two-factor authentication is mandatory for physician and administrator accounts and is available to patients.

Video visits

Consultations run peer-to-peer between the two browsers, encrypted in transit, and are not recorded. Only the two parties to an appointment can join its room; the server checks that before issuing connection details.

Vendor agreements

AirSpire maintains an internal vendor-agreement register and explicitly checks agreement coverage for payments, transactional email, and platform hosting. Missing, pending, and expired agreements are flagged to our operations team; a vendor appearing in the register does not by itself mean an agreement has been executed.

3. What we do not claim

Security claims are only worth anything if the gaps are stated too. As of this version:

• We hold no HIPAA, ISO 27001, SOC 2, or NDPC certification, and we have not been independently audited or penetration-tested by a third party.
• Field-level encryption at rest covers the free-text clinical fields listed above, not every column.
• Deletion at the end of a retention period is performed by our operations team, not by an automated retention job.
• The consent ledger records the time, document version, and decision. It does not record the IP address or device the consent came from: the application’s server-side request context does not expose either value to the routine that writes the entry, and we would rather leave those fields empty than fill them with a figure the browser supplied about itself, which anyone could fabricate.
• Right-to-erasure requests are executed by our operations team on request rather than by a self-service button in your account.

If any of that changes, this notice gets a new version and you will be asked to review it.

4. If something goes wrong

If personal data we hold is breached, we notify the NDPC within 72 hours of becoming aware of it, as section 40 of the NDPA requires, and we tell affected patients directly and without undue delay where the breach is likely to put them at high risk.

If you believe your record has been accessed improperly, or you have found a security problem in this service, email [email protected]. Reports about security are welcome and will not be held against you. You can also complain to the NDPC directly at any time.