# Infraestructura de registro médico digital

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

Source: https://developers.anpheros.com/es/guides/digital-medical-record

**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](https://developers.anpheros.com/es/guides/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](https://developers.anpheros.com/es/guides/consent)

### 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](https://developers.anpheros.com/es/guides/healthcare-integrations)

### 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:

1. cree un paciente para cada usuario (`POST /v1/patients`) o solicite el consentimiento a un usuario existente de Anpheros;
2. escriba lo que registra el usuario (`/v1/patients/{id}/observations`, `/conditions`, `/medications`, `/documents`);
3. léalo de nuevo como listas o una línea de tiempo (`/v1/patients/{id}/timeline`);
4. 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](https://developers.anpheros.com/es/guides/build-a-healthcare-app).

## Relacionado

- [Expediente médico del paciente](https://developers.anpheros.com/es/guides/patient-medical-record)
- [Backend y base de datos de la aplicación médica](https://developers.anpheros.com/es/guides/medical-app-backend)
- [Seguridad, privacidad y residencia de datos](https://developers.anpheros.com/es/guides/security)
- [Infraestructura de datos médicos](https://developers.anpheros.com/es/guides/medical-data-infrastructure)