How we protect medical data
Saying "your data is safe" isn't enough. Here we explain exactly which technologies we use, how they work, and which regulations we comply with. No marketing — just verifiable technical facts.
Security layers
AES-256-GCM encryption
Data at rest- Sensitive patient fields (ID number, contact details, diagnoses and clinical notes) are encrypted individually with AES-256-GCM
- Every record has its own initialization vector (IV) — none are reused
- HMAC-based blind indexes enable searches without decrypting the full value
- The encryption key is stored in server environment variables, never in code or the database
Row-Level Security (RLS)
Data isolation- More than 25 tables with RLS enabled in PostgreSQL: patients, appointments, clinical records, prescriptions, payments, invoices, and more
- Every query is automatically filtered by organizationId — accessing another practice's data is impossible
- Enforced at the database level, not just in the application — defense in depth
- withSecureContext() guarantees every operation passes through the security filter
Immutable WORM audit log
Legal traceability- Write-Once, Read-Many: every action is recorded permanently for 15 years
- SHA-256 integrity hash per record + chained hashing (each record references the previous record's hash)
- No one can modify or delete audit records — not even administrators
- Meets clinical-record retention requirements under patient-rights regulations
PHI-Zero anonymization (SENTINEL AI)
Privacy-first AI- Sensitive data (names, ID numbers, addresses, phone numbers) is replaced with tokens before any AI processing
- The AI model never sees identifiable patient data
- Google Vertex AI does not train models on your patients' data. Before any Sentinel query is sent to the model, patient identifiers are replaced with tokens by our PHI-Zero pipeline.
- Every SENTINEL query is recorded in the immutable audit log
- Voice dictation works differently: the doctor's voice is transcribed by xAI (United States), and the audio—which may contain PHI mentioned while dictating—is automatically deleted after 30 days and is not used to train models. Clinical fields are then extracted from the transcript with Google Vertex AI, and you review everything before saving.
Authentication and access control
Identity- NextAuth v5 with bcrypt password hashing
- MFA with TOTP (Google Authenticator, Authy): optional to sign in, mandatory to sign and issue e-prescriptions
- Granular roles: MEDICO (doctor), SECRETARIA (front desk), PACIENTE (patient), ADMIN, SUPERADMIN
- Sessions with automatic expiration and revocation
Infrastructure and network
Perimeter protection- Enforced HSTS with a 1-year max-age (includes subdomains)
- Content Security Policy in enforce mode — blocks unauthorized scripts and resources
- Per-IP rate limiting: 5 req/min for auth, 60 req/min for the API, 150 req/min for public pages
- Cloudflare R2 for file storage — no direct access to the database
E-prescriptions with electronic signature
Law 27.553- Platform approved by Argentina's national Ministry of Health in the ReNaPDiS registry (registration No. 292, MEDICAI S.A.S, type: e-prescription platform, HL7 FHIR standard); the Electronic Prescription Registry file number RL-2026-75170116-APN-SSVEIYES#MS is printed at the bottom of every prescription
- Electronic signature with a SHA-256 seal covering all the prescription data, plus signing date and time on the document (not a digital signature issued by a licensed certification authority)
- MFA is mandatory to prescribe: signing and issuing a prescription requires the professional's TOTP second factor, and only professionals whose license has been verified against the REFEPS registry can do it
- QR code, traceability identifier and barcode on every prescription, with public verification at medicai.com.ar/verificar-receta that exposes no patient data
Regulatory compliance matrix
Your data is yours
MedicAI offers FHIR export (Fast Healthcare Interoperability Resources) — the international standard for exchanging clinical data. If you decide to leave, you take everything with you. No lock-in, no trapped data.
Patient data is encrypted at rest and accessible only to each organization's authorized professionals. Not even the MedicAI team can read encrypted clinical data without the server key.
Security FAQ
Are MedicAI's e-prescriptions valid?
Yes. MedicAI is a platform approved by Argentina's national Ministry of Health in the ReNaPDiS (National Registry of Digital Health Platforms), registration No. 292, legal entity MEDICAI S.A.S, type: e-prescription platform, HL7 FHIR standard: the requirement Law 27.553 sets for e-prescription platforms. Every prescription is signed by a professional with a verified license, using an electronic signature (SHA-256 seal covering all the prescription data, with date and time) and a mandatory second authentication factor, and carries a QR code anyone can verify at https://www.medicai.com.ar/verificar-receta. Official list: https://www.argentina.gob.ar/salud/digital/renapdis/plataformas-aprobadas-por-el-ministerio-de-salud-de-la-nacion
Who can read my patients' clinical data?
Only the authorized professionals in your organization. Sensitive data is encrypted at rest with AES-256-GCM, every database query is filtered by organization with Row-Level Security, and front-desk staff manage the agenda and appointments without accessing clinical content. Not even the MedicAI team can read encrypted clinical data without the server key.
Can I take my data with me if I leave MedicAI?
Yes. You export your data in the FHIR R4 standard (patients, consultations, diagnoses, vital signs and prescriptions) whenever you want. No lock-in: the data belongs to the patient and the professional, not to the software.