Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Consentimiento y modelo de acceso

Quién ve qué: aislamiento de proyectos, IDs de par, concesiones, propiedad de escritura, procedencia y lo que el paciente ve sobre cada aplicación con acceso.

Regla: con el consentimiento del paciente, una organización ve el registro completo —incluyendo lo que otras clínicas escribieron— pero solo puede cambiar o eliminar lo que ella misma escribió. Cada versión de cada recurso registra el proyecto que lo escribió y la organización en cuyo nombre se escribió.

Quién ve qué

• Un proyecto (clave API) ve los pacientes que ha creado. Bajo una concesión (token OAuth), una aplicación ve exactamente un paciente, a través de todos los escritores, limitado a los ámbitos concedidos y a los filtros de categoría. Todo lo demás devuelve 404, nunca 403, por lo que los IDs no se pueden sondear.
• IDs de par: cada proyecto recibe su propio ID para la misma persona; los IDs internos nunca salen de la plataforma. Las referencias a pacientes fuera de su ámbito se enmascaran con un token opaco, por proyecto.
• Directorio (Organización, Profesional, Rol de Profesional): legible por ID en todo el plano para que las referencias se resuelvan; solo se puede buscar dentro de su proyecto; utilizable como X-Anpheros-Acting-As / X-Anpheros-On-Behalf-Of solo cuando es suyo.
• Sandbox y producción son bases de datos diferentes. Una clave de sandbox físicamente no puede acceder a pacientes reales.

Escrituras y propiedad

• project_id en cada versión de recurso = el escritor. Actualizar/eliminar por otro proyecto → 403 con una explicación; escribe tu propio recurso en su lugar.
• Provenance.agent.onBehalfOf = la clínica/organización en el momento de la escritura: X-Anpheros-On-Behalf-Of, de lo contrario la organización del PractitionerRole actuante, de lo contrario la organización del proyecto.
• Cada escritura produce un recurso Provenance y una fila de auditoría (quién, qué, cuándo, bajo qué concesión, qué aplicación, desde qué huella digital de origen).

Lo que ve el paciente

/me/patients/{id}/grants enumera cada aplicación con acceso, sus alcances y fecha de caducidad; …/access-log enumera lo que cada uno leyó o escribió — bajo el consentimiento y con la clave propia del proyecto. La revocación surte efecto en la próxima solicitud; la aplicación no puede volver a conectarse. Con format=fhir, el registro de acceso se devuelve como un Bundle de recursos FHIR R4 AuditEvent, con el formato de los Patrones de Registro de Auditoría Básica de IHE (tipo rest, la interacción como subtipo, la aplicación y la persona que actúa a través de ella como agentes, el paciente y el recurso como entidades, sin datos clínicos), de modo que otro sistema pueda fusionarlo en la vista de la persona sobre quién accedió a su registro.

Qué registra cada recurso Provenance y cómo configurarlo: Explicación de la procedencia de los datos médicos.

SMART Health Links (compartir por QR o enlace)

Una persona puede compartir su registro sin una aplicación intermedia: POST /me/patients/{id}/shl crea un SMART Health Link para el subconjunto de emergencia (alergias, medicamentos, problemas, inmunizaciones — sin resultados ni historial) o el Resumen Internacional de Pacientes completo, con una contraseña y fecha de caducidad opcionales. La respuesta transporta la URI shlink:/… (para un código QR) y una dirección del visor en /shl/view, que lo abre en cualquier navegador. Quien lo escanee publica en la URL del manifiesto y recibe el resumen como un JWE (dir + A256GCM) cifrado con la clave dentro del enlace; cualquier lector de SMART Health Link funciona.

• El contenido se genera en cada apertura (bandera L, estado can-change), por lo que una tarjeta guardada en el teléfono se mantiene actualizada.
• Una contraseña (bandera P) se verifica en el servidor; después de 10 intentos erróneos, el enlace deja de funcionar.
• GET /me/patients/{id}/shl lista los enlaces con la frecuencia y cuándo se abrió cada uno; …/shl/{link}/revoke desactiva uno a la vez. Cada apertura queda registrada en el log de acceso.
• El ID interno de la persona nunca sale de la plataforma: el documento los nombra con un seudónimo del enlace.

Los agentes de IA proponen, la persona decide

Bajo el consentimiento de una persona, una escritura de un agente de IA (una aplicación registrada como agente, por ejemplo, un asistente conectado a través de MCP) o cualquier escritura con author_type ai no se aplica de inmediato. La plataforma la valida y responde 202 Accepted con el ID de la propuesta (encabezado Anpheros-Proposal); nada cambia en el registro. La persona lo ve en GET /me/patients/{id}/proposals — qué es, qué aplicación lo envió — y lo acepta o rechaza (…/proposals/{proposal}/accept o …/reject). Una propuesta aceptada se escribe exactamente como se envió, marcada como escrita por IA (HL7 AI Transparency). Los proyectos que pueden ver el registro reciben un webhook delgado proposal.created. Las escrituras realizadas con la clave propia de un proyecto, en registros que el proyecto creó, no se retienen.

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card