¿Qué debería mostrar un portal del paciente?

Un portal no es “hacer público el expediente”

La palabra portal puede ocultar decisiones muy distintas.

Un portal seguro separa:

• lo que el paciente puede ver;
• lo que puede descargar;
• lo que puede subir;
• lo que puede firmar;
• lo que puede corregir o solicitar corregir;
• lo que puede compartir con terceros;
• y lo que permanece únicamente en el entorno clínico.

No uses una sola autorización “portal = todo”. Cada acción necesita su propio alcance.

Qué debería mostrar

Un núcleo razonable puede incluir:

Identidad básica

• nombre;
• datos de contacto relevantes;
• médico o clínica;
• avisos de privacidad vigentes;
• mecanismos para reportar un dato incorrecto.

No permitas que editar el perfil del portal reescriba documentos clínicos históricos ya firmados.

Citas

• fecha y hora;
• sede;
• profesional;
• estado;
• opciones de cancelar o solicitar cambio cuando estén permitidas.

El portal no necesita mostrar el diagnóstico para recordar una cita.

Documentos compartidos

Por ejemplo:

• resumen clínico preparado para el paciente;
• receta/documento que deba conservar;
• orden de estudio;
• constancia;
• documento exportado específicamente para ese fin.

La lista no debe convertirse en un explorador irrestricto de archivos internos del consultorio.

Consentimientos

• documento que se solicita revisar;
• estado de firma;
• versión;
• profesional responsable;
• instrucciones claras para rechazar o pedir aclaración.

Firmar necesita más controles que simplemente leer.

Estudios y resultados

Puede mostrar:

• órdenes pendientes;
• enlaces para subir resultados;
• archivos ya revisados cuando se autorice;
• estado: recibido, pendiente de revisión, aprobado o rechazado.

Un archivo subido por el paciente no debería aparecer como resultado clínico validado hasta que el profesional lo revise.

¿Puede el paciente acceder a su expediente en línea?

Técnicamente sí puede diseñarse un acceso online seguro; eso no significa que un enlace público deba dar acceso al expediente completo.

Para acceso persistente a historia clínica usa:

• cuenta individual;
• autenticación robusta;
• MFA cuando el riesgo lo justifique;
• sesiones limitadas;
• revocación;
• registro de accesos;
• autorización por recurso;
• controles frente a enumeración o cambio de ID en URL.

Un enlace tokenizado puede ser apropiado para una tarea estrecha —firmar un documento o subir un estudio— pero no debería convertirse por accidente en una sesión general de paciente.

Cómo compartir documentos con un paciente

Hay tres patrones frecuentes.

1. Portal autenticado

Adecuado cuando el paciente tendrá acceso recurrente.

Ventajas:

• identidad persistente;
• revocación;
• historial de acceso;
• varios documentos bajo una misma cuenta.

2. Enlace temporal y acotado

Adecuado para un único documento o tarea.

El enlace debería ser:

• impredecible;
• expirable;
• revocable;
• no indexable;
• servido con no-store cuando contiene información sensible;
• limitado al recurso correcto.

Si se reenvía, quien lo recibe puede obtener el mismo poder que el bearer. Para documentos sensibles puede hacer falta un segundo factor.

3. Entrega asistida

El consultorio verifica identidad y entrega la información por un canal controlado.

Puede ser preferible cuando el paciente no tiene cuenta o cuando el tipo de documento exige revisión humana previa.

No pongas datos clínicos en la URL

Evita rutas o parámetros como:

• nombre del paciente;
• CURP;
• diagnóstico;
• motivo de consulta;
• número de expediente predecible.

Los tokens deben actuar como capacidades opacas, no como datos clínicos codificados en texto.

Cómo recibir estudios enviados por el paciente

El flujo más seguro no es “mándamelo por WhatsApp y yo luego lo busco”.

Un upload específico para una orden puede conservar:

• orden/folio;
• estudio al que corresponde;
• fecha de recepción;
• archivo original;
• quién lo subió cuando se proporciona;
• estado de revisión;
• profesional que lo aprobó o rechazó.

Qué hace hoy VITALINK

Cuando el médico crea una orden elegible, VITALINK puede generar un enlace público tokenizado para que paciente o laboratorio suban resultados.

El flujo actual:

• acepta PDF, PNG o JPEG;
• limita el archivo a 10 MB;
• aplica rate limiting;
• limita la cantidad de cargas por orden;
• valida que el contenido del archivo corresponda al tipo declarado;
• responde con Cache-Control no-store;
• deja de aceptar el bearer cuando la orden está completada o el enlace ya no procede.

El archivo subido no entra automáticamente al expediente como resultado aprobado.

La propia pantalla informa:

el médico tiene que revisarlo y aprobarlo antes de que se incorpore al expediente.

El backend mantiene acciones separadas de aprobación y rechazo y las audita.

Cómo evitar que un upload se convierta en una puerta al expediente

El bearer de subida solo necesita ver lo mínimo para completar su tarea.

No debería devolver:

• historia clínica completa;
• diagnósticos ajenos a la orden;
• otros pacientes;
• notas SOAP;
• documentos no relacionados.

El endpoint público de estudios aplica una política de lectura minimizada y no requiere una sesión general del médico.

Qué existe hoy en VITALINK y qué no

A septiembre de 2026, Expediente VITALINK sí tiene varias superficies patient-facing acotadas:

• reserva pública de citas;
• aviso de privacidad/consentimiento remoto;
• consentimiento informado por enlace;
• subida de resultados de estudios por token;
• verificadores públicos de documentos o credenciales con información minimizada.

También existen contratos backend para que un usuario con rol paciente pueda gestionar determinadas solicitudes de acceso.

No se publica todavía una UI general de “Portal del paciente” desde la que cualquier paciente autenticado pueda navegar todo su expediente, consultas, recetas y documentos.

Por eso esta guía no presenta como live:

• descarga self-service de historia completa;
• bandeja general de documentos;
• edición completa de datos por el paciente;
• mensajería patient-portal como fuente única;
• compartir el expediente completo con un clic.

Un portal debería aplicar mínimo privilegio en ambos sentidos

El paciente necesita acceso a su información y a tareas propias, pero eso no obliga a mostrar:

• notas internas administrativas;
• datos de otros pacientes;
• permisos del equipo;
• logs internos;
• borradores que todavía no son parte de un documento final;
• información de terceros cuya entrega necesite revisión.

A la vez, el equipo no debería recibir más información del paciente de la necesaria para la tarea.

Qué medir

Para QA y seguridad:

• enlaces emitidos;
• expirados/revocados;
• intentos fallidos;
• uploads aceptados/rechazados;
• documentos descargados;
• firma completada;
• errores de identidad;
• tiempo hasta revisión de estudios.

No metas el contenido clínico del documento en la telemetría.

Checklist antes de lanzar un portal

Pregunta:

• ¿qué puede ver cada paciente?
• ¿cómo se autentica?
• ¿qué requiere segundo factor?
• ¿cómo se revoca una sesión o link?
• ¿los recursos usan IDs opacos y autorización server-side?
• ¿qué se cachea?
• ¿qué se audita?
• ¿cómo se gestiona un representante?
• ¿cómo se corrige identidad?
• ¿qué pasa si un link se reenvía?
• ¿qué ocurre con un archivo antes de que el médico lo apruebe?

Un buen portal aumenta acceso sin convertir comodidad en exposición.