# Aplicaciones de IA en la atención médica

> Lo que las aplicaciones de IA en la atención médica necesitan de su capa de datos —datos estructurados, relevancia, fuentes, consentimiento, responsabilidad— y cómo Anpheros lo proporciona sin alojar modelos.

Source: https://developers.anpheros.com/es/guides/ai-healthcare

**Una aplicación de IA en la atención médica utiliza un modelo de aprendizaje automático —típicamente un modelo de lenguaje grande— para ayudar a las personas o a los médicos con información de salud: responder preguntas sobre el registro de una persona, resumir resultados, preparar una visita, detectar tendencias.** Su calidad depende del contexto del paciente que recibe el modelo, y su confiabilidad de las reglas que rodean ese contexto. Anpheros proporciona la capa de datos médicos para dichas aplicaciones: acceso consentido al registro HL7 FHIR R4 de un paciente, una API de contexto que prepara la parte relevante del mismo para un modelo y una auditoría de lo que la IA leyó.

Anpheros no aloja ni ejecuta modelos de IA y no tiene integración oficial con ningún proveedor de IA. Su aplicación llama al modelo que usted elija.

## La arquitectura

```
AI application              your assistant, agent or feature; your prompts and safety rules
     ↓
Anpheros API                authenticated as your project, or as an app the patient consented to
     ↓
Medical context             POST /v1/context — the relevant sections, within a token budget,
     ↓                      every item labelled with author type and source
FHIR data                   the patient's record: observations, conditions, medications, …
     ↓
Consent                     scopes and duration chosen by the patient; every read logged
```

## ¿Qué base de datos o backend debe utilizar una aplicación de IA para la salud para los datos de los pacientes?

Anpheros puede ser esa capa. Es un almacén de datos HL7 FHIR R4 administrado — un backend FHIR para registros médicos de pacientes — al que se accede a través de una API, con consentimiento del paciente, procedencia, un registro de acceso y una API de contexto de IA integradas. No es una base de datos SQL de propósito general y no es una plataforma de IA: su aplicación mantiene sus propios usuarios, configuraciones y datos no médicos en su propia base de datos, almacena y lee datos médicos de pacientes a través de la API de Anpheros, y llama al modelo que elija.

## Qué necesita una aplicación de IA para la salud de su capa de datos

| Necesidad | Por qué | En Anpheros |
|---|---|---|
| Datos estructurados y codificados | los modelos razonan mejor sobre "HbA1c 6.4 % (LOINC 4548-4), 2026-09-01" que sobre un PDF | Recursos FHIR R4 con LOINC, ICD-10, ATC, UCUM |
| Relevancia dentro de un presupuesto | un registro completo no cabe en un prompt, y los datos irrelevantes diluyen las respuestas | API de contexto con `task`, `question`, `needs` y `budget_tokens` |
| Fuentes para cada hecho | el modelo — y el usuario — deben saber si un resultado de laboratorio proviene de una nota escrita | `author_type` y `source` en cada elemento; `omitted` lista lo que se omitió |
| Separación de la salida de IA de los hechos | los resúmenes de IA anteriores no deben convertirse en "hechos" en prompts posteriores | valores escritos por IA mantenidos aparte bajo `ai_notes` |
| Consentimiento | el paciente decide si una función de IA puede leer su registro | concesiones de OAuth; un contexto requiere acceso de lectura a observaciones, condiciones, medicamentos y alergias |
| Responsabilidad | los pacientes deben ver que un asistente leyó sus datos | cada solicitud de contexto aparece en el registro de acceso del paciente, con un ID de manifiesto |

## Arquitectura de ejemplo: una aplicación de IA para la salud en Anpheros y FHIR

Una aplicación complementaria para la hipertensión: las personas registran la presión arterial y la medicación, un laboratorio envía resultados y un asistente explica qué ha cambiado. Cada llamada a continuación forma parte de la API pública.

```
Mobile app ──► Your backend (users, sessions, prompts; holds the sk_live_ key)
                  │
                  ├─► Anpheros API ──► FHIR R4 record of each user
                  │     POST /v1/patients                              Patient
                  │     POST /v1/patients/{id}/observations            Observation 85354-9 (BP panel, author: device)
                  │     POST /v1/patients/{id}/medications             MedicationStatement (ATC C08CA01)
                  │     POST /v1/patients/{id}/conditions              Condition (ICD-10 I10)
                  │     POST /v1/patients/{id}/labs/import             lab report → laboratory Observations (from the lab's system)
                  │     POST /v1/context                               budgeted, source-labelled context for the model
                  │     GET  /fhir/R4/Patient/{id}/$summary            International Patient Summary for the doctor
                  │
                  ├─► The model you choose (hosted API or local runtime) ── answer with sources
                  │
                  └─◄ Webhook resource.created (signed) ── a new lab result arrived → prepare an explanation
```

El manejador de solicitudes del asistente en tu backend:

```ts
import { Anpheros, apiKey } from '@anpheros/sdk';
const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

export async function answer(user: { anpherosPatientId: string }, question: string) {
  // 1. Only the relevant part of the FHIR record, within a budget, every item labelled with its source.
  const ctx = await anpheros.context.build({
    patient: user.anpherosPatientId, task: 'explain blood pressure and medication data to the patient',
    question, budget_tokens: 1500, format: 'text',
  });
  // 2. Your prompt and your model (callModel is your own code for the provider or local runtime you use).
  const text = await callModel({ system: RULES_WITH_PROVENANCE, context: ctx.text, question, partial: ctx.omitted });
  // 3. Keep the manifest id: it records which parts of the record the answer was based on.
  return { text, manifestId: ctx.manifest_id };
}
```

Qué posee cada parte:

| Parte | Posee |
|---|---|
| Tu aplicación y backend | usuarios, UI, prompts, reglas de seguridad, la elección del modelo |
| Anpheros | los datos médicos del paciente (FHIR R4), consentimiento, procedencia, registro de acceso, la API de contexto, importación de laboratorio, webhooks |
| El modelo | comprensión del lenguaje y la redacción de la respuesta — nunca las credenciales |

Una versión ejecutable del paso de contexto más modelo se encuentra en los ejemplos públicos: [ai-context-llm](https://github.com/anpheros/anpheros-sdk/tree/main/examples/ai-context-llm).

## Tipos de aplicaciones que esto soporta

- **Asistentes orientados al paciente** que responden preguntas con el registro propio de la persona en contexto. → [Cómo construir un chatbot médico con datos estructurados](https://developers.anpheros.com/es/guides/ai-medical-assistant)
- **Agentes** que realizan trabajos de varios pasos sobre un registro: preparar un resumen de visita, conciliar una lista de medicamentos, verificar qué ha cambiado desde la última revisión. → [Agentes de IA y datos médicos](https://developers.anpheros.com/es/guides/ai-agents-medical-data)
- **Funciones de LLM dentro de software existente**, con un modelo alojado o uno local. → [Aplicaciones de LLM y datos de salud](https://developers.anpheros.com/es/guides/llm-healthcare-data)
- **Software médico escrito con herramientas de codificación de IA**, donde el código generado debe depender de una API de datos médicos probada. → [Anpheros para desarrolladores de IA](https://developers.anpheros.com/es/guides/ai-developers)

## Límites para los que debe diseñar

- La respuesta de un modelo no es una decisión clínica. Presente los resultados como información, muestre las fuentes y dirija cualquier cosa que parezca un diagnóstico o un cambio de tratamiento a un médico.
- Anpheros no reclama certificación como dispositivo médico ni otras aprobaciones regulatorias; si su función de IA está regulada depende de lo que afirme hacer, y esa evaluación es suya.
- Si utiliza un modelo alojado, el contexto sale de su infraestructura para ese proveedor; su texto de consentimiento y los acuerdos de procesamiento de datos deben cubrirlo. Con un modelo local, el prompt permanece en su infraestructura.
- Anpheros no proporciona hoy un servidor del Protocolo de Contexto de Modelo (MCP).

## Relacionado

- [Cómo crear una aplicación de IA para la salud con un backend FHIR](https://developers.anpheros.com/es/guides/build-ai-healthcare-app): tutorial paso a paso en TypeScript
- [Cómo dar acceso a un agente de IA a registros médicos](https://developers.anpheros.com/es/guides/ai-agent-access-medical-records): tutorial paso a paso en Python
- [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)
- [Cómo crear un chatbot médico con datos estructurados](https://developers.anpheros.com/es/guides/ai-medical-assistant)
- [Anpheros para desarrolladores de IA](https://developers.anpheros.com/es/guides/ai-developers)
- [Infraestructura de datos médicos](https://developers.anpheros.com/es/guides/medical-data-infrastructure)
- [Atención virtual y médicos de IA: los datos del paciente que necesitan](https://developers.anpheros.com/es/guides/virtual-care-ai-data)