← Back to portal

Compliance & Regulatory

GDPR, HIPAA, and healthcare data handling requirements. How we implement audit logging, consent flows, and data residency rules.

GDPR Article 9: Special Category Data

Blood pressure measurements are classified as health data under GDPR Article 9(1): "processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of identifying a natural person, health data or data concerning a person's sex life or sexual orientation" requires explicit consent and heightened safeguards.

Core Requirements

Explicit Legal Basis Required. You cannot process health data without one of the lawful bases in Article 9(2). For HCP-managed devices, the legal basis is typically contract performance (Article 9(2)(h) with consent, or medical purposes). For patient-managed devices, it's explicit consent (Article 9(2)(a)).
Requirement: GDPR-01
Consent Recording & Audit Trail

What: Every explicit consent to process health data must be recorded with timestamp, consent type, version of consent text, and signature.

Implementation: Create patient_consent table with columns: id, patient_id, consent_type (e.g., "hcp_access_hcp_managed"), consent_text_version, given_at, revoked_at, ip_address, user_agent. Hash and store consent text separately to allow version tracking.

Why: GDPR Article 7 requires you to be able to prove that the individual gave consent. If questioned by regulators, you must produce the exact consent form they saw, timestamp, and method.

Requirement: GDPR-02
Right to Erasure ("Right to be Forgotten")

What: Patients can request deletion of all their health data. You must be able to erase all BP measurements, device assignments, and consent records within 30 days.

Implementation: Design data model so that erasing a patient does not cascade-delete audit logs (needed for compliance). Create a deleted_at soft-delete column on patients table. Archive audit logs separately. Support bulk deletion jobs with progress tracking.

Why: GDPR Article 17. Patients have a legal right to be forgotten. Your system must support this without manual database intervention.

Requirement: GDPR-03
Data Processing Agreement (DPA)

What: If Hilo processes health data on behalf of the HCP (Data Controller), a signed Data Processing Agreement must be in place.

Implementation: This is a legal document, not a technical one. But the system must support it via a dpa_signed_at field on the organizations table, and must enforce that no health data is accessible until DPA is signed.

Why: GDPR Article 28 requires a contract between Controller and Processor. Without a DPA, processing is non-compliant. The HCP (controller) cannot use Hilo (processor) legally without it.

Data Residency & Geographic Requirements

EU Data Residency (GDPR)

If any patient is a natural person resident in the EU (or their data is processed in the EU), that data must remain within EU borders. This applies to:

Requirement: GDPR-04
EU vs US Data Segregation

What: If serving both EU and US patients, you must enforce strict data isolation.

Implementation:

Why: GDPR prohibits transferring EU resident data outside the EU without explicit adequacy decisions. Violating this is a reportable breach.

US Data Residency (State Laws)

Several US states (CA, TX, VA) have state-level privacy laws (CCPA, TDPSA, VMPPA). Additional requirements:

Recommendation: Implement EU compliance first. US state laws are less strict, so treating all US data to EU standards (with minor additions) is practical.

HIPAA Requirements (if US-based Healthcare Entity)

If the HCP is a US-based healthcare provider (subject to HIPAA), processing patient health data triggers HIPAA obligations:

Core HIPAA Rules

Requirement: HIPAA-01
Encryption in Transit & at Rest

What: All health data must be encrypted both when transmitted (in transit) and when stored (at rest).

Implementation:

Why: HIPAA Security Rule requires encryption. It's also the #1 defense against data breaches.

Requirement: HIPAA-02
Comprehensive Audit Logging

What: Every access to health data must be logged: who accessed it, when, what data, from where, and why.

Implementation:

Why: HIPAA Security Rule §164.312(b). Audit logs are your proof of compliance during audits. They also help detect breach patterns.

Requirement: HIPAA-03
Access Controls & Least Privilege

What: Users should only have access to the minimum data needed for their role.

Implementation:

Why: HIPAA Security Rule §164.308(a)(4). Limits exposure if an account is compromised.

Requirement: HIPAA-04
Business Associate Agreement (BAA)

What: If Hilo (as a Business Associate) creates, receives, or maintains health data on behalf of a HIPAA-covered entity, a BAA must be signed.

Implementation: This is legal (not technical). But track: baa_signed_at on organizations table. Enforce that US HCPs cannot use the dashboard until BAA is signed.

Why: HIPAA §164.502(e). Without a BAA, the HCP cannot legally use a third-party service to handle health data. Violation is a significant fine (~$100-$250k per incident).

Implementation Patterns

Audit Logging Architecture

GET /api/v1/patients/:id/measurements
  ↓
[Authentication Middleware]
  Validate JWT token
  Extract user_id, org_id
  ↓
[Authorization Middleware]
  Check role has permission to "read:measurements"
  ↓
[Scope Resolution]
  Determine what data user can access
  For hcp_user: check if patient_id is assigned
  For hcp_admin: check if patient.org_id == user.org_id
  ↓
[Query]
  SELECT measurements FROM physiological
  WHERE patient_id = :patient_id AND data_residency = user.data_residency
  ↓
[Audit Log]
  INSERT INTO audit_log (user_id, action, resource_type, resource_id, patient_id, ip_address, timestamp)
  VALUES (:user_id, 'read_measurements', 'physiological', :measurement_id, :patient_id, :ip, NOW())
  ↓
[Response]
  Return data to user

Consent Flow (Patient-Managed Device)

  1. Patient initiates sharing: "Allow HCP John to see my data"
  2. System creates consent record: INSERT INTO patient_consent (patient_id, hcp_user_id, consent_type, consent_text_version, given_at)
  3. Patient receives email: "You granted John access to your BP data on [date]"
  4. HCP can now query: Backend allows HCP to see this patient only after consent is recorded
  5. Patient revokes consent: UPDATE patient_consent SET revoked_at = NOW()
  6. HCP can no longer access: Query includes WHERE revoked_at IS NULL check

Explicit consent is required: Patient must proactively grant access. Default is "no access". This satisfies GDPR Article 9(2)(a) and HIPAA consent requirements.

Data Residency Enforcement

// Backend middleware, run BEFORE any query

const userDataResidency = user.data_residency; // "EU" or "US"
const regionConfig = {
  EU: { db: postgresEU, vault: vaultEU },
  US: { db: postgresUS, vault: vaultUS },
};
const selectedDb = regionConfig[userDataResidency].db;

// All queries now use selectedDb, not a shared connection
// This prevents EU data from leaking to US queries

Regulatory Testing Checklist

Test How to Verify GDPR/HIPAA Requirement
Consent is recorded Grant consent, verify patient_consent table has a row with correct timestamp GDPR Article 7, HIPAA
Consent revocation works Revoke consent, verify HCP can no longer query patient data (401) GDPR Article 21, HIPAA
Audit log captures access Access patient data, verify audit_log has a row within 1 second HIPAA Security Rule
EU/US data segregation Create EU patient, verify US query returns 401 or empty result GDPR Article 44
Encryption in transit Run: curl -I https://api.example.com, verify TLS version and HSTS header HIPAA Security Rule
Encryption at rest Verify Postgres TDE is enabled: SELECT * FROM pg_stat_user_tables WHERE encrypted = true HIPAA Security Rule
RBAC enforced (not bypassed) As hcp_user, try to access patient outside assigned list, verify 403 HIPAA Security Rule
Right to erasure works Delete patient, verify all physiological rows are gone but audit_log remains GDPR Article 17

Open Questions for Legal

These decisions are non-technical but block implementation:

Deployment Checklist

Before launching to any production environment: