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

Infraestructura de expediente médico digital

La infraestructura que necesita un expediente médico digital — estructura, historial, documentos, aislamiento, consentimiento, auditoría, intercambio — y por qué se mantiene separada de la aplicación para el paciente.

Un registro médico digital necesita dos cosas diferentes: una aplicación orientada al paciente que las personas usan a diario y la infraestructura subyacente que almacena, protege y comparte el registro. Anpheros proporciona lo segundo: el almacenamiento, control de versiones, identidad, consentimiento, auditoría e intercambio del registro, a través de una API. La aplicación orientada al paciente puede ser Anpheros Daily o una que usted construya.

Aplicación versus infraestructura

	Aplicación orientada al paciente	Infraestructura de datos médicos
Qué es	pantallas, notificaciones, recordatorios, gráficos, un asistente	el registro en sí y las reglas que lo rodean
Cambia a menudo	sí — diseño, características, plataformas	raramente — debe permanecer estable y compatible
Ejemplos de trabajo	un diario de síntomas, un recordatorio de medicación, un calendario familiar	Almacenamiento FHIR, historial de versiones, consentimiento, procedencia, auditoría, importación de laboratorio, webhooks
En Anpheros	Anpheros Daily (Android, macOS, web)	Anpheros Platform (`platform.anpheros.com`)

Mantenerlos separados permite que un registro sobreviva a cualquier aplicación individual y se comparta entre varias. Anpheros Daily sigue esta división: lo que las personas registran en la aplicación se escribe en la plataforma a través de la misma API pública que utiliza cualquier otra aplicación, por lo que está disponible — con el consentimiento del paciente — para otras aplicaciones en el mismo formato FHIR.

Lo que la infraestructura debe proporcionar

Estructura

Un registro solo es útil si otro software puede entenderlo. Anpheros lo almacena como recursos HL7 FHIR R4 — 26 tipos — con códigos estándar (LOINC, ICD-10, ATC, UCUM) y mantiene el texto original junto a cada código. Plataforma FHIR

Historial

Los datos médicos se corrigen, no se sobrescriben. Cada actualización crea una nueva versión, legible a través de /fhir/R4/{type}/{id}/_history; las actualizaciones condicionales con If-Match evitan que dos escritores se sobrescriban entre sí (una versión obsoleta responde 412).

Documentos

Los escaneos y PDF se almacenan como DocumentReference con el archivo original: cargados a través de la plataforma o directamente al almacenamiento, y luego finalizados con una suma de verificación SHA-256 y tamaño. Después de la finalización, el original no se puede cambiar; los valores extraídos de él apuntan de nuevo a él (derived_from). Los archivos se conservan en un bucket de almacenamiento de la UE cifrado con una clave administrada por el cliente, hasta 25 MiB cada uno.

Identidad y aislamiento

Cada aplicación funciona dentro de un proyecto y solo ve a sus propios pacientes (más aquellos que le han otorgado acceso), bajo sus propios identificadores mutuos. Un registro fuera de su alcance no existe para ella (404).

Consentimiento

Un paciente otorga a una aplicación acceso por un período (30–365 días), a tipos de recursos y acciones específicos, opcionalmente limitados a una categoría. Las concesiones se reflejan como recursos FHIR Consent y se pueden revocar en cualquier momento. Modelo de consentimiento y acceso

Procedencia y auditoría

Cada escritura registra quién la escribió (paciente, profesional, dispositivo, importación o IA), para qué organización y desde qué sistema. Cada lectura se registra y se muestra al paciente por aplicación.

Intercambio

El registro se puede exportar en su totalidad (Patient/$everything), resumido en el formato International Patient Summary (Patient/$summary), alimentado por laboratorios (CSV, HL7 v2 ORU^R01, JSON) y supervisado a través de webhooks firmados. Integraciones sanitarias

Residencia y eliminación

Los datos se almacenan y procesan en la Unión Europea. La eliminación de un paciente elimina todos los recursos del registro.

Creación de su propia aplicación para pacientes

Si está creando la capa de la aplicación, puede concentrarse en la experiencia y utilizar Anpheros para el registro:

cree un paciente para cada usuario (POST /v1/patients) o solicite el consentimiento a un usuario existente de Anpheros;
escriba lo que registra el usuario (/v1/patients/{id}/observations, /conditions, /medications, /documents);
léalo de nuevo como listas o una línea de tiempo (/v1/patients/{id}/timeline);
suscríbase a webhooks para actualizar las pantallas cuando un laboratorio o clínica agregue algo.

El recorrido completo se encuentra en Crear una aplicación de salud.

Relacionado

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