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

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.

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 y un agente consentido en Agentes de IA y datos médicos. Detalles: Agentes de IA y datos médicos, Aplicaciones LLM y datos de salud.

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

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