Skip to main content

​
Overview

The Patient Mobile Access system (AccesoMovil) provides patients with secure, read-only access to their personal dental records through a mobile-friendly interface. This feature enhances patient engagement and reduces administrative burden by allowing patients to self-serve basic information.
Patient access is optional and must be explicitly created by clinic staff. Not all patients will have mobile access by default.

​
Key Characteristics

Mobile-First Design

Optimized for smartphone and tablet access

Read-Only Access

Patients can view but not modify their records

Token-Based Auth

Secure authentication using tokens with expiration

Self-Service Portal

View appointments, treatments, and personal information

​
Database Schema

Patient access credentials are stored in the acceso_movil table:
FieldTypeDescription
id_accesoINT (PK)Primary key
id_pacienteINT (FK)Foreign key to patient record
usuario_movilVARCHARPatient’s username for mobile login
passwordVARCHARHashed password (hidden)
tokenVARCHARSession token for API access (hidden)
fecha_expiracionDATETIMEToken expiration date
estatusENUM’activo’ or ‘inactivo’
created_atTIMESTAMPAccount creation date
updated_atTIMESTAMPLast modification date
Source: app/Models/AccesoMovil.php:10

​
Model Relationships

// AccesoMovil belongs to one Patient
public function paciente()
{
    return $this->belongsTo(Paciente::class, 'id_paciente', 'id_paciente');
}

// Patient has one AccesoMovil (optional)
public function accesoMovil()
{
    return $this->hasOne(AccesoMovil::class, 'id_paciente', 'id_paciente');
}
Source: app/Models/AccesoMovil.php:33, app/Models/Paciente.php:57

​
Security Features

​
Password Hashing

Passwords are automatically hashed when set: 
public function setPasswordAttribute($value)
{
    $this->attributes['password'] = Hash::make($value);
}
Source: app/Models/AccesoMovil.php:39

​
Hidden Fields

Sensitive fields are hidden from JSON responses: 
protected $hidden = [
    'password',
    'token'
];
Source: app/Models/AccesoMovil.php:26

​
Token Expiration

Access tokens have an expiration date (fecha_expiracion) to ensure sessions don’t remain active indefinitely.
Tokens should be regenerated periodically and expired tokens should be rejected during authentication.

​
What Patients Can Access

Read-only access to:
  • Name and demographics
  • Contact information (phone, address)
  • Date of birth and age
  • CURP and identification
Cannot modify: Patients cannot edit their own information; changes must be requested through the clinic
Can view:
  • Upcoming appointments (date, time, dentist)
  • Past appointment history
  • Appointment status (scheduled, completed, cancelled)
Cannot do:
  • Schedule new appointments (must call clinic)
  • Cancel or reschedule appointments
  • View other patients’ appointments
Can view:
  • Active treatment plans
  • Completed treatments
  • Treatment descriptions and procedures
  • Treatment dates
Cannot access:
  • Detailed clinical notes from dentists
  • Internal diagnosis codes
  • Pricing information (optional, depends on implementation)
Limited access to:
  • Basic medical history they provided
  • Allergies and medications
  • General health questionnaire responses
Cannot view:
  • Dentist’s private notes
  • Detailed diagnostic evaluations
  • X-ray interpretations
  • Treatment recommendations (unless explicitly shared)

​
Permission Boundaries

Strict Read-Only Access

Patients can only view their own data. They cannot:
  • Modify any personal information
  • Edit treatment plans
  • Add or remove appointments
  • Access other patients’ data
  • View clinic staff information
  • Access administrative functions

​
Data Scope Restrictions

All patient queries must be filtered by id_paciente to ensure patients only see their own data: 
// Example: Get patient's appointments
$citas = Cita::where('id_paciente', $patient->id_paciente)->get();

// Example: Get patient's treatments
$tratamientos = Tratamiento::where('id_paciente', $patient->id_paciente)->get();
Critical Security Rule: Always verify that the authenticated patient’s id_paciente matches the requested resource before returning any data.

​
Creating Patient Access

Patient access accounts should be created by clinic staff (Dentist or Assistant) when:
  • A patient requests mobile access
  • The clinic wants to provide digital records
  • The patient needs to monitor their treatment progress

​
Account Creation Process

1

Verify Patient Record

Ensure the patient exists in the paciente table and belongs to your clinic
2

Generate Credentials

Create a unique usuario_movil (username) and secure password
3

Set Expiration

Define token expiration date (e.g., 90 days, 1 year, or never)
4

Activate Account

Set estatus to ‘activo’
5

Provide Credentials

Securely deliver username and temporary password to patient
Consider using a consistent format for patient usernames:
  • Email address: juan.perez@email.com
  • Phone number: 5551234567
  • Custom format: paciente_12345 or jperez_clinic123

​
Authentication Flow

​
Account Status Management

​
Active Status

Patients with estatus = 'activo' can log in and access their data.

​
Inactive Status

Patients with estatus = 'inactivo' cannot log in. Use this to:
  • Temporarily disable access
  • Suspend patients who haven’t paid
  • Deactivate accounts for patients who left the clinic

​
Reactivation

Clinic staff can toggle the status back to ‘activo’ at any time.

​
Privacy & Compliance

HIPAA/Privacy Considerations

When implementing patient mobile access:
  • Data Encryption: Use HTTPS/TLS for all API communications
  • Access Logs: Track when patients access their records
  • Password Requirements: Enforce strong passwords
  • Session Timeouts: Auto-logout after inactivity
  • Two-Factor Auth: Consider adding 2FA for sensitive data

​
Best Practices

  1. Token Rotation: Regenerate tokens periodically (e.g., every 90 days)
  2. Password Reset: Provide a secure password reset mechanism
  3. Session Management: Implement proper session timeout (e.g., 15-30 minutes of inactivity)
  4. Audit Trail: Log all patient access to sensitive data
  5. Data Minimization: Only expose necessary information; hide internal codes and staff notes
  6. Terms of Service: Require patients to accept terms before first access

​
Mobile App Features

The patient mobile app (when developed) should include:

Dashboard

  • Next appointment
  • Recent activity
  • Pending treatments

Appointments

  • View upcoming appointments
  • See appointment history
  • Get directions to clinic

Treatments

  • Active treatment plans
  • Treatment progress
  • Completed procedures

Profile

  • Personal information
  • Contact details
  • Medical history

​
API Endpoints (Future)

When the mobile API is implemented, typical endpoints will include: 
POST   /api/patient/login
POST   /api/patient/logout
GET    /api/patient/profile
GET    /api/patient/appointments
GET    /api/patient/appointments/{id}
GET    /api/patient/treatments
GET    /api/patient/treatments/{id}
POST   /api/patient/password/reset

​
Error Handling

Response: 401 UnauthorizedMessage: “Invalid username or password”Action: Limit login attempts to prevent brute force
Response: 403 ForbiddenMessage: “Your account has been deactivated. Please contact the clinic.”Action: Direct patient to call clinic
Response: 401 UnauthorizedMessage: “Your session has expired. Please log in again.”Action: Redirect to login page

​
Comparison with Staff Roles

FeatureSuper AdminDentistAssistantPatient
Access ScopeAll clinicsOwn clinicOwn clinicOwn data only
Data ModificationFullFull (clinic)LimitedNone
View Clinical NotesStats onlyFullNoLimited
AppointmentsStatsFullSchedulingView only
AuthenticationWeb portalWeb portalWeb portalMobile app
PlatformDesktopDesktopDesktopMobile

Build docs developers (and LLMs) love

Get started for freeTalk to us