Un servidor FHIR almacena y sirve recursos FHIR. Una plataforma FHIR es lo que realmente necesitas para lanzar un producto de salud: el servidor, más identidad, consentimiento, procedencia, aislamiento entre clientes, webhooks, documentos, terminología y alguien que lo mantenga funcionando bajo el RGPD. Esta guía expone la diferencia y describe cómo Anpheros Platform cubre cada vacío, para que puedas decidir si construir sobre ella o ejecutar la tuya propia.
Versión técnica para desarrolladores: Plataforma de API de atención médica · Comparación de servidores FHIR en developers.anpheros.com, con solicitudes, respuestas y límites. Esta página es la versión en lenguaje sencillo.
Servidor versus plataforma
Los servidores FHIR de código abierto (HAPI, por ejemplo) son excelentes en la parte FHIR: recursos, búsqueda, validación, historial. Lo que te dejan a ti es todo lo demás:
| Necesidad | Un servidor FHIR | Una plataforma FHIR |
|---|---|---|
| Almacenamiento de recursos, búsqueda, historial | sí | sí |
| Quién puede leer qué paciente | tu código | consentimiento integrado |
| Quién escribió cada valor | tu código | Procedencia en cada escritura |
| Varios clientes en un solo sistema | tu código | aislamiento de proyectos, IDs emparejadas |
| Pantalla de consentimiento para el paciente | tu código | OAuth 2.1 + SMART on FHIR |
| Notificaciones a tu aplicación | sondeo | webhooks firmados |
| Datos de prueba realistas | tus fixtures | 30 pacientes sintéticos por sandbox |
| Alojamiento, copias de seguridad, RGPD, DPA | tu equipo de operaciones | incluido |
Si tienes un equipo de operaciones, un oficial de cumplimiento y seis meses, ejecutar tu propio servidor es una buena opción. Si tienes un producto que lanzar, una plataforma es más rápida.
Cómo está construida Anpheros Platform
Un registro FHIR R4 por paciente. 26 tipos de recursos, codificados con LOINC, ICD-10 y ATC, validados al escribir. La API FHIR estricta se encuentra en /fhir/R4, con una CapabilityStatement en /fhir/R4/metadata, y una API REST sencilla en /v1 sirve los mismos datos con los mismos IDs.
Aislamiento de proyectos e IDs emparejadas. Un proyecto (una clave API) solo ve los pacientes que ha creado. Cada proyecto recibe su propio ID para la misma persona; los IDs internos nunca salen de la plataforma. Las referencias a pacientes fuera de tu alcance se enmascaran con un token opaco por proyecto.
El consentimiento decide las lecturas, la propiedad decide las escrituras. Con el consentimiento del paciente, una organización ve el registro completo, incluido lo que otras clínicas escribieron, pero solo puede cambiar o eliminar lo que ella misma escribió. Cada versión de cada recurso registra el proyecto que la escribió; una escritura por otro proyecto se rechaza con una explicación.
Procedencia y auditoría en cada escritura. Provenance.agent.onBehalfOf nombra la clínica u organización en el momento de la escritura; una fila de auditoría registra quién, qué, cuándo, bajo qué concesión, desde qué aplicación. El paciente puede leer su registro de acceso, también como recursos FHIR AuditEvent.
Webhooks delgados y firmados. Los eventos transportan IDs y versiones, nunca contenido clínico; lees el recurso a través de la API. Las entregas se firman con HMAC-SHA256 y se reintentan con retroceso hasta por 24 horas.
Sandbox y producción son bases de datos separadas. Una clave sk_test_ no puede acceder a un paciente real. El sandbox es gratuito y de autoservicio.
Residencia en la UE. Cloud Run en europe-west4, con un acuerdo de procesamiento de datos para organizaciones de producción.
Lo que deliberadamente no está ahí
- No hay soporte de decisiones clínicas. La plataforma almacena, codifica y comparte; no diagnostica ni recomienda tratamiento.
- No hay una base de datos completa de medicamentos con interacciones. Los medicamentos se codifican con ATC, y un subconjunto combinado de ATC y LOINC está disponible para consulta, pero la verificación de interacciones es tu componente o un servicio con licencia.
- No hay un bus de mensajería HL7 v2 de grado hospitalario. Hay una importación de HL7 v2 ORU^R01 para informes de laboratorio; no hay gestión de ADT u órdenes.
Conocer estos límites de antemano ahorra una semana de descubrimiento.
Cuándo ejecutar tu propio servidor en su lugar
- Debes alojar dentro de tu propia red hospitalaria, sin procesador externo.
- Necesitas FHIR R5 o perfiles que la plataforma no implementa.
- Tu producto es el propio servidor FHIR.
En todos los demás casos, comienza en el sandbox, mide y decide con datos. La primera hora se describe en developers.anpheros.com/guides/first-hour; la referencia completa de la API está en platform.anpheros.com/docs.
Preguntas frecuentes
¿Es Anpheros un servidor FHIR?
Contiene uno: una API FHIR R4 con 26 tipos de recursos, búsqueda, historial, operaciones $everything, $summary, $validate y de terminología. A su alrededor hay consentimiento, procedencia, aislamiento, webhooks y alojamiento, que es lo que la convierte en una plataforma.
¿Qué versión de FHIR?
FHIR R4 (4.0.1), la versión requerida por la regulación de la UE y EE. UU. e implementada por la mayoría de los sistemas. La conformidad se verificó con Inferno; consulta las notas de conformidad IPS.
¿Pueden varias clínicas compartir el registro de un paciente?
Sí, ese es el objetivo. Con el consentimiento del paciente, cada clínica lee el registro completo y escribe sus propios recursos, cada uno marcado con su procedencia. Ninguna clínica puede alterar lo que otra escribió.
¿Hay un backend FHIR gratuito para desarrollo?
Sí. El sandbox es gratuito, de autoservicio y viene con 30 pacientes sintéticos por proyecto. Consulta Servidor FHIR gratuito: el sandbox.
¿Cómo puedo migrar si necesito hacerlo?
Todo es FHIR R4 y exportable: Patient/{id}/$everything devuelve el registro completo de un paciente como un Bundle. No hay un formato propietario que desentrañar.
Lleva tu historial médico contigo
Anpheros Daily guarda síntomas, análisis, medicamentos y documentos en un solo lugar, en formato estándar y bajo tu control. El plan Basic es gratuito.