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

Backend y base de datos de aplicaciones médicas

Qué debe manejar un backend de aplicación médica y su base de datos, qué partes proporciona Anpheros como base de datos sanitaria gestionada, qué queda en tu backend, tres formas de conectar y cómo mantenerse sincronizado con webhooks.

Un backend de aplicación médica es el lado del servidor de una aplicación sanitaria: almacena datos del paciente, aplica quién puede verlos, mantiene un historial de cambios y se comunica con laboratorios, clínicas y otros servicios. Con Anpheros, la parte médica de ese backend —la base de datos sanitaria que contiene el registro de cada paciente, con su historial, consentimiento, procedencia, auditoría, importación de laboratorio y eventos— es proporcionada por la plataforma a través de una API, y su propio backend solo conserva lo que es específico de su producto.

Qué debe manejar un backend médico

Lo que permanece en tu backend

• tus usuarios y cuentas, y el mapeo de cada usuario a su ID de paciente de Anpheros (el ID de emparejamiento que ve tu proyecto);
• datos del producto que no son médicos: configuraciones, suscripciones, contenido, horarios de recordatorios;
• reglas de negocio: qué miembros de tu personal pueden ver qué paciente en tu producto;
• la clave API, que nunca debe incluirse dentro de una aplicación móvil o web.

Tres formas de conectar

1. Su backend almacena la clave API (más común). Su aplicación llama a su backend; su backend llama a Anpheros con una clave sk_live_ y ve los pacientes que creó su proyecto.

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

// GET /api/me/vitals in your backend, after your own authentication
export async function myVitals(user: { anpherosPatientId: string }) {
  const page = await anpheros.observations.list(user.anpherosPatientId, { category: 'vital-signs', limit: 50 });
  return page.data;
}

2. La aplicación actúa en nombre del paciente con OAuth. Para personas que ya tienen un registro en Anpheros, una aplicación móvil o web es un cliente OAuth público con PKCE: la persona consiente en la página alojada y la aplicación recibe un token de acceso de 30 minutos y un token de actualización rotatorio para ese único registro. Los SDK implementan el flujo (OAuthFlow).

3. Socios de servidor a servidor. Un cliente confidencial (con un secreto, guardado en un servidor) puede usar el flujo de código de autorización, o client_credentials, que se comporta como una clave API para ese proyecto.

Mantener tu backend sincronizado

Suscríbete a webhooks en lugar de hacer polling. Las entregas están firmadas (Anpheros-Signature, HMAC-SHA256 sobre timestamp y body), se entregan al menos una vez y posiblemente fuera de orden; desduplica por ID de evento e ignora versiones obsoletas.

import { verifyWebhookSignature } from '@anpheros/sdk';

app.post('/anpheros/hook', express.raw({ type: 'application/json' }), async (req, res) => {
  const ok = await verifyWebhookSignature({ secret: process.env.ANPHEROS_WEBHOOK_SECRET!, header: req.header('anpheros-signature'), body: req.body });
  if (!ok) return res.status(400).end();
  const event = JSON.parse(req.body.toString());   // ids and versions only — read the resource if you need it
  res.status(204).end();
});

Manejo de errores y límites

• Trate 404 como "no visible para usted", nunca como prueba de que un registro no existe.
• 403 significa que la credencial existe pero puede que no haga esto — un ámbito faltante, o un recurso escrito por otra organización.
• 429 viene con Retry-After; los SDKs esperan y reintentan automáticamente, como lo hacen para 5xx.
• Guarde los Anpheros-Request-Id de las llamadas fallidas para soporte.

Errores · Límites y límites de tasa

Preguntas frecuentes

¿Qué base de datos debe usar una aplicación médica?

Una que mantenga los datos médicos en un formato estándar y versionado, y que controle el acceso por paciente. Anpheros es una base de datos sanitaria gestionada construida sobre HL7 FHIR R4: el registro de cada paciente está versionado y es consultable, cada escritura lleva la procedencia, y una aplicación solo ve a un paciente si creó el registro o si el paciente dio su consentimiento. Su propia base de datos almacena el resto de los datos de su producto: cuentas, facturación, contenido. Para conocer las ventajas y desventajas de diseñar sus propias tablas en su lugar, consulte FHIR vs. una base de datos médica personalizada.

¿Existe una base de datos gratuita para aplicaciones médicas?

Sí. El sandbox de Anpheros es gratuito: inicie sesión con Google, obtenga una clave con un solo clic y su proyecto obtendrá sus propios 30 pacientes sintéticos y hasta 10 000 escrituras al día. La producción comienza en 99 € al mes para 2.500 pacientes, con el primer mes gratuito; el acceso a producción es para organizaciones verificadas con un acuerdo de procesamiento de datos firmado. Consulte Precios.

¿Puedo mantener datos reales de pacientes en el sandbox gratuito?

No. El sandbox es solo para datos sintéticos: cada proyecto de sandbox obtiene sus propios pacientes sintéticos, y las claves del sandbox no pueden acceder a producción. Los registros reales de pacientes pertenecen a un proyecto de producción.

Relacionado

• FHIR vs. una base de datos médica personalizada: cuándo diseñar sus propias tablas y cuándo usar FHIR
• Cómo crear una API de salud con TypeScript: tutorial paso a paso con Express
• Cómo crear una aplicación de salud con Flutter: tutorial paso a paso con el SDK de Dart
• Desarrollo de software de salud
• Crear una aplicación de salud
• Arquitectura
• API de datos médicos
• SDKs

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