Compliance direction

Compliance is a product requirement, not a claim.

MediFlow is being built around organization isolation, server-side access control, PHI-safe audit foundations, data minimization, and controlled AI handling. Certification and legal readiness stay tied to evidence, provider agreements, and review.

Review RBAC View audit foundations

Pillars

Compliance pillars

01
Organization isolation
every subscription maps to an organization workspace; data is scoped to that organization.
02
Server-side access control
sensitive access and PHI mutations are authorized through Functions and use cases, not client checks.
03
Audit foundations
patient, document, appointment, billing, membership, AI, and admin changes are modeled as audit events.
04
Data minimization
logs, URLs, and audit metadata avoid PHI by construction.
05
AI governance
AI requests run server-side, feature-flagged, quota-aware, PHI-minimized, human-reviewed.

Regulatory direction

HIPAA / BAA

Direction

Unique user identities, MFA as a launch gate, least-privilege roles, audit controls, PHI-safe metadata, transmission security, subprocessor review, and BAAs wherever ePHI is created, received, maintained, or transmitted.

Unique user identity and MFA at launch.
Least-privilege organization roles.
PHI-safe audit metadata.
Transmission and storage security.
BAAs where ePHI flows.

GDPR

Direction

Transparency at onboarding, lawful-basis documentation, data minimization, correction and export workflows, deletion workflows, audit retention policy, secure processing, and an EU-first data residency strategy.

Onboarding transparency and lawful basis.
Data export and rectification flows.
Right-to-deletion workflow.
Audit retention policy.
EU-first residency strategy.

Launch gate

Evidence-based launch gate

Before a production release, each critical control maps to evidence: test outputs, audit export samples, agreement status, runbooks, retention policy, owner assignments. A control is not done because it is named. It is done because it is shown.

Implemented
Server-side RBAC enforcement
Function-boundary checks for PHI and membership mutations.
Implemented
Organization workspace isolation
Appwrite Teams modeled per organization.
Implemented
PHI-safe audit metadata schema
Reject-list on obvious PHI-bearing keys.
In progress
MFA as a launch gate
Onboarding flow integration in review.
Blocked
BAA with hosting tier
Awaiting Appwrite HIPAA tier confirmation.
In progress
Right-to-deletion workflow
Workflow drafted; legal review pending.
Planned
Subprocessor inventory and DPA
Owner assigned; due before pilot expansion.
Planned
Penetration test
Scheduled after BAA tier confirmation.

Sample audit row

Illustrative only · synthetic values · not from any real workspace

actor_type	actor_id	org_id	action	target	timestamp	ip	user_agent	mutation_class
organization_user	usr_•••cf1d	org_•••87a2	patient.vitals.update	patient · pt_•••3a90	2026-05-26T14:32:11Z	•••.•••.41.7	Chrome / macOS	phi
organization_user	usr_•••a812	org_•••87a2	org.invite.send	invitation · inv_•••0c4	2026-05-26T14:48:02Z	•••.•••.41.7	Firefox / Windows	membership
system	svc_ai_runner	org_•••87a2	ai.summary.complete	patient · pt_•••3a90	2026-05-26T14:51:33Z	internal	ai-runner/0.4	phi (read)

No PHI in any field. Names, addresses, document bodies, and AI prompts are rejected at the metadata layer.

Compliance pages

Continue the evidence trail.

Five pages, three with current direction, two still in preparation. Status is honest.

Compliance directionCompliance is a product requirement, not a claim.Direction RBACAccess control designed around real clinic teams.Direction Audit foundationsAn audit log row, not a compliance slogan.Direction Security overviewEvidence by request.Coming soon Compliance statusCompliance status coming soon.Coming soon