# Arquitectura de aplicaciones sanitarias

> Diagramas y flujos de datos: del paciente a la aplicación, a la API de Anpheros, al registro FHIR y servicios externos, y del agente de IA a la API de contexto a datos autorizados.

Source: https://developers.anpheros.com/es/guides/architecture

Anpheros es la capa de datos médicos entre su aplicación (o agente de IA) y el registro del paciente. Su aplicación mantiene su propia interfaz de usuario y lógica de negocio; el registro médico, el consentimiento, la procedencia y la auditoría residen en Anpheros y se accede a ellos a través de una API.

```
  Your application, backend or AI agent
  (mobile app, web app, clinic system, lab system, LLM-based assistant)
                        │  HTTPS · API key (sk_test_ / sk_live_) or OAuth token (at_…)
                        ▼
  Anpheros Platform API
  ├─ /v1        simplified REST: patients, observations, conditions, medications,
  │             documents, timeline, provenance, context, labs, webhooks
  ├─ /fhir/R4   strict FHIR R4: 26 resource types, search, history, transactions,
  │             $everything, $summary (IPS), $validate
  └─ /oauth     OAuth 2.1 + PKCE, SMART on FHIR, OpenID Connect
                        │  every request: project isolation · scopes · rate limits
                        ▼
  One FHIR R4 record per patient
  ├─ versions of every resource (history)   ├─ Provenance for every write
  ├─ Consent resources for every grant      └─ access log visible to the patient
                        │
                        ▼
  Events out: signed webhooks to your server (ids only, never clinical content)
```

## La vista del paciente: de persona a servicios externos

```
Patient
   ↓   uses an app, chooses what to share, sees every access
Healthcare application          Anpheros Daily, or your own app
   ↓   REST v1 / FHIR R4 over HTTPS, API key or OAuth token
Anpheros API
   ↓   isolation, scopes, idempotency, provenance
FHIR medical data               the patient's record: 26 resource types, every version kept
   ↓   only what the patient allowed, only for as long as allowed
External healthcare services    laboratories (lab import), clinics (directory, acting-as),
                                other apps (OAuth / SMART), your backend (webhooks)
```

## La vista de IA: del agente a los datos autorizados

```
AI agent or LLM application     runs the model you choose — hosted or local
   ↓   POST /v1/context  {patient, task, question, budget_tokens}
Medical context API             plans which parts of the record matter, fits them into the budget,
   ↓                            labels every item with author type and source, records a manifest
Authorised medical data         only records the project created or the patient granted;
                                the read appears in the patient's access log
```

El modelo nunca recibe credenciales y nunca llama directamente a Anpheros; tu aplicación solicita el contexto y decide qué enviar al modelo. Dos ejemplos completos con las llamadas a la API: una aplicación de salud con IA en [Aplicaciones de salud con IA](https://developers.anpheros.com/es/guides/ai-healthcare) y un agente consentido en [Agentes de IA y datos médicos](https://developers.anpheros.com/es/guides/ai-agents-medical-data). Detalles: [Agentes de IA y datos médicos](https://developers.anpheros.com/es/guides/ai-agents-medical-data), [Aplicaciones LLM y datos de salud](https://developers.anpheros.com/es/guides/llm-healthcare-data).

## El registro

Cada paciente tiene un registro compuesto por recursos FHIR R4: `Observation` para signos vitales, resultados de laboratorio, síntomas y resúmenes de actividad diaria, `Condition` y `EpisodeOfCare`, `MedicationStatement` y `MedicationAdministration`, `DocumentReference`, `Immunization`, `AllergyIntolerance` y otros — 26 tipos en total, listados en tiempo real en la CapabilityStatement (`GET /fhir/R4/metadata`). No hay un esquema propietario que aprender: la API REST es una vista más simple de los mismos recursos, con los mismos ids.

Nada se sobrescribe silenciosamente. Cada actualización crea una nueva versión (`/fhir/R4/{type}/{id}/_history`), y cada versión registra el proyecto que la escribió y la organización en cuyo nombre se escribió.

## Dos formas de acceso

| | Clave API | Token de acceso OAuth |
|---|---|---|
| Aspecto | `sk_test_…` / `sk_live_…` | `at_…` |
| Utilizado por | su servidor | una aplicación que actúa en nombre de un paciente |
| Ve | los pacientes que su proyecto creó | exactamente un paciente, dentro de los ámbitos que el paciente otorgó |
| Uso típico | el backend de su propia aplicación, un sistema de laboratorio, una integración clínica | una aplicación de terceros o un asistente de IA que accede a un registro que el paciente ya tiene |

Un proyecto nunca ve los pacientes de otro proyecto a menos que el paciente otorgue acceso. Cada proyecto obtiene su propio identificador para la misma persona (IDs de emparejamiento), por lo que los IDs no se pueden correlacionar entre aplicaciones, y un registro fuera de su alcance responde `404`, nunca `403`.

## Dos entornos

El sandbox y el entorno de producción son bases de datos separadas. Una clave de sandbox (`sk_test_`) físicamente no puede acceder a pacientes reales; cada proyecto de sandbox recibe su propia copia de 30 pacientes sintéticos, que puede modificar libremente y restablecer. Las claves de producción (`sk_live_`) se emiten a organizaciones verificadas.

## Flujos de datos

**Tu aplicación escribe.** `POST /v1/patients/{id}/observations` con una `Idempotency-Key`. La plataforma almacena un `Observation` FHIR, escribe un `Provenance` (tipo de autor: paciente, profesional, dispositivo, importación o IA), registra el acceso y envía un webhook `resource.created` a los puntos finales suscritos.

**Otra aplicación lee con consentimiento.** El paciente lo aprueba en la página de consentimiento alojada (`/oauth/authorize`), eligiendo el registro y la duración (30-365 días). La aplicación intercambia el código por tokens y lee solo lo que los ámbitos permiten. El paciente ve la aplicación, sus ámbitos y cada lectura en su registro de acceso, y puede revocarlo en cualquier momento.

**Un laboratorio entrega resultados.** `POST /v1/patients/{id}/labs/import` con un informe CSV, HL7 v2 ORU^R01 o JSON; cada resultado se convierte en un `Observation` de laboratorio con códigos LOINC cuando se conocen, y reenviar el mismo informe es seguro.

**Un modelo de IA necesita contexto.** `POST /v1/context` devuelve las partes del registro relevantes para una tarea, dentro de un presupuesto de tokens, cada elemento etiquetado con su origen; la llamada se registra con un ID de manifiesto. El modelo en sí se ejecuta donde tú elijas.

## Dónde encaja Anpheros en comparación con crearlo tú mismo

| Preocupación | Crearlo tú mismo | Con Anpheros |
|---|---|---|
| Modelo de datos médicos | diseñar tablas para cada tipo de registro | Recursos FHIR R4, 26 tipos |
| Interoperabilidad | formatos de exportación personalizados | FHIR R4, International Patient Summary, SMART on FHIR |
| Consentimiento | crear lógica de concesión, alcance, caducidad y revocación | Concesiones de OAuth 2.1 reflejadas como FHIR `Consent` |
| Auditoría | crear registro y una forma de mostrárselo a los pacientes | cada lectura y escritura registrada y visible para el paciente |
| Integración de laboratorio | analizar el formato de cada laboratorio | Importación CSV, HL7 v2 ORU y JSON |
| Contexto de IA | escribir código de recuperación y resumen | API de contexto con presupuesto de tokens y etiquetas de procedencia |

## Relacionado

- [¿Qué es Anpheros?](https://developers.anpheros.com/es/guides/what-is-anpheros)
- [Desarrollo de software para la salud](https://developers.anpheros.com/es/guides/healthcare-software)
- [Backend y base de datos de aplicaciones médicas](https://developers.anpheros.com/es/guides/medical-app-backend)
- [Crea una aplicación de salud](https://developers.anpheros.com/es/guides/build-a-healthcare-app)
- [Modelo de consentimiento y acceso](https://developers.anpheros.com/es/guides/consent)
- [Seguridad, privacidad y residencia de datos](https://developers.anpheros.com/es/guides/security)