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

Seguridad, privacidad y residencia de datos

Cómo se protegen los datos del paciente: residencia de datos en la UE, aislamiento de proyectos, IDs emparejadas, credenciales, consentimiento, procedencia, una auditoría visible para el paciente y los límites de la beta privada.

Los datos médicos son los datos más sensibles que puede contener una aplicación. Esta página enumera cómo Anpheros Platform los protege hoy — solo lo que está implementado — y lo que todavía está limitado durante la beta privada.

Residencia de datos

• Todos los datos de la plataforma se almacenan y procesan en la Unión Europea: el servicio y sus bases de datos en Google Cloud europe-west4 (Países Bajos), la cola de entrega de webhooks en europe-west3 (Fráncfort) y la exportación inmutable del registro de acceso en la ubicación de la UE de BigQuery.
• Región de datos de EE. UU.: disponible bajo solicitud para clientes de producción bajo un acuerdo de asociado comercial de HIPAA (ver más abajo); los datos de pacientes de EE. UU. entonces nunca abandonan la región de EE. UU.
• Los documentos se almacenan en un bucket de almacenamiento de la UE cifrado con una clave de cifrado administrada por el cliente (CMEK). Los originales son inmutables después de su finalización; se registran su suma de verificación SHA-256 y su tamaño.

Aislamiento entre aplicaciones

• Cada clave de API pertenece a un proyecto. Un proyecto solo ve los pacientes que creó, en el sandbox, incluida su propia copia de pacientes sintéticos, que ningún otro proyecto puede ver.
• Identificadores de emparejamiento: cada proyecto recibe su propio id para la misma persona; los ids internos nunca abandonan la plataforma, por lo que los ids no se pueden correlacionar entre aplicaciones.
• Un registro al que no puedes acceder responde 404, nunca 403, por lo que la existencia de un paciente no puede ser sondeada.
• Sandbox y producción son bases de datos separadas. Una clave de sandbox (sk_test_) físicamente no puede acceder a pacientes reales.
• Con el consentimiento del paciente, una organización lee el registro completo, incluido lo que otras organizaciones escribieron, pero solo puede cambiar o eliminar lo que escribió ella misma.

Credenciales

• Las API keys se muestran una vez y se almacenan únicamente como un hash SHA-256. Las claves tienen ámbitos read / write y nunca cruzan su entorno.
• OAuth 2.1 con PKCE obligatorio (S256); el redirect_uri debe registrarse exactamente. Los tokens de acceso duran 30 minutos, los tokens de refresco 30 días y rotan en cada uso.
• Detección de reutilización de refresh-token: presentar un refresh token que ya se ha utilizado revoca toda la cadena de tokens.
• Las respuestas de token llevan Cache-Control: no-store. Los id_token de OpenID Connect se firman con RS256; las claves públicas se publican en /oauth/jwks.

Consentimiento, procedencia y auditoría

• Un paciente otorga a una aplicación acceso en una página de consentimiento alojada, eligiendo el registro y la duración (30, 90, 180 o 365 días). Los ámbitos son por tipo de recurso y acción, opcionalmente filtrados por categoría. Cada concesión se refleja como un recurso FHIR Consent.
• La revocación surte efecto en la siguiente solicitud; la aplicación no puede volver a conectarse.
• Cada escritura produce un recurso Provenance: quién la escribió (paciente, profesional, dispositivo, importación o IA), para qué organización, desde qué sistema de origen.
• Cada lectura se registra y es visible para el paciente, incluidas las lecturas realizadas con la clave API propia de un proyecto, e incluido el contexto creado para modelos de IA.

Seguridad de transporte y web

• Solo HTTPS, con HTTP Strict Transport Security. Las respuestas de la API incluyen una política restrictiva de Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY y una política estricta de referenciador.
• Las entregas de webhooks se firman con HMAC-SHA256 sobre la marca de tiempo y el cuerpo; los receptores deben rechazar firmas con una antigüedad superior a 5 minutos. Los eventos incluyen IDs y versiones, nunca contenido clínico.
• Límites de tasa: 600 solicitudes por minuto por credencial y por IP; cuerpos JSON de hasta 2 MiB; documentos de hasta 25 MiB.

Motores de búsqueda e indexadores de IA

Las páginas públicas (anpheros.com, la presentación de la plataforma y esta documentación) están abiertas a motores de búsqueda e indexadores de IA. La API, el panel de control, las páginas de OAuth y consentimiento, y la aplicación del paciente (app.anpheros.com) están excluidas con las reglas noindex y robots.txt; ninguna de ellas devuelve datos del paciente sin autenticación.

HIPAA (Clínicas de EE. UU.)

Para una clínica en los Estados Unidos, Anpheros es un Socio Comercial. Lo que está implementado, mapeado a la Regla de Seguridad de HIPAA:

Un Acuerdo de Socio Comercial y una región de datos de EE. UU. están disponibles bajo petición para clientes de producción (escriba a [email protected]); la producción de datos de pacientes de EE. UU. se abre después de que se firma el BAA. El sandbox contiene solo pacientes sintéticos, por lo que los desarrolladores en EE. UU. pueden construir hoy sin un BAA. Anpheros no está certificado contra SOC 2 o HITRUST; se planea una auditoría SOC 2 Tipo II cuando un cliente hospitalario lo requiera.

Límites actuales (beta privada)

• Alojamiento en una sola zona sin conmutación por error automática; aún no hay un SLA contractual.
• Las claves de producción se emiten a organizaciones verificadas con un acuerdo de procesamiento de datos firmado; los socios beta comienzan con datos sintéticos.
• El lanzamiento de SMART EHR y el parámetro OpenID nonce aún no son compatibles.

Relacionado

• GDPR y datos de salud para desarrolladores
• Procedencia de datos médicos explicada: quién escribió qué y cómo registrarlo
• Modelo de consentimiento y acceso
• Autenticación y OAuth
• Límites y límites de frecuencia
• Fiabilidad, estado e incidentes: monitorización, copias de seguridad, comunicación de incidentes
• Arquitectura
• El Espacio Europeo de Datos Sanitarios (EHDS) para desarrolladores

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