Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Plataforma FHIR: FHIR R4 gestionado con consentimiento del paciente
Una plataforma FHIR R4 gestionada: 26 tipos de recursos, búsqueda, historial, transacciones, $everything, IPS, lanzamiento SMART probado por Inferno, consentimiento y procedencia, además de una API REST simple. Sandbox gratuito.
Anpheros es una plataforma FHIR — una base de datos FHIR gestionada (almacén de datos) que las aplicaciones utilizan como su backend FHIR: almacena cada registro de paciente de forma nativa como recursos HL7 FHIR R4 (4.0.1) y los expone en https://platform.anpheros.com/fhir/R4, con consentimiento, procedencia y auditoría añadidos sobre el estándar. Las aplicaciones que ya entienden FHIR pueden usarlo directamente; las que no, pueden usar la API REST más sencilla (/v1), que lee y escribe los mismos recursos con los mismos IDs.
Para aplicaciones de IA, esto convierte a Anpheros en el backend FHIR del que proviene el contexto de un modelo: véase Aplicaciones LLM y datos sanitarios.

¿Qué es HL7 FHIR?
FHIR (Fast Healthcare Interoperability Resources) es el estándar de HL7 para intercambiar datos de salud a través de la web. Define:
- recursos — documentos JSON (o XML) pequeños y tipados para cada concepto clínico: un
Patient, unObservation, unCondition, unMedicationStatement; - referencias entre ellos (
"subject": {"reference": "Patient/123"}), de modo que un registro es un grafo de recursos en torno a un paciente; - una API REST para leer, buscar, crear, actualizar y eliminar recursos, con parámetros de búsqueda estándar;
- bundles para enviar varios recursos a la vez (transacciones) o como un documento (como un resumen de paciente);
- enlaces de terminología, para que los valores lleven códigos de sistemas como LOINC o ICD-10;
- perfiles — restricciones para un caso de uso o un país, como el International Patient Summary.
R4 (versión 4.0.1) es la versión más implementada hoy en día. Usar FHIR como modelo de almacenamiento — no solo como formato de exportación — significa que no hay una capa de traducción entre lo que una aplicación escribe y lo que otro sistema FHIR lee.
{
"resourceType": "Observation",
"status": "final",
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
"code": {"coding": [{"system": "http://loinc.org", "code": "4548-4", "display": "Hemoglobin A1c"}]},
"subject": {"reference": "Patient/…"},
"effectiveDateTime": "2026-09-01T08:00:00Z",
"valueQuantity": {"value": 6.4, "unit": "%", "system": "http://unitsofmeasure.org", "code": "%"}
}
Declaración de capacidades
GET /fhir/R4/metadata devuelve la CapabilityStatement: los tipos de recursos compatibles, sus parámetros de búsqueda y las operaciones. Es pública y es la lista autorizada; la tabla a continuación la refleja al 28 de septiembre de 2026.
Los 26 tipos de recursos
Patientone record per personObservationDiagnosticReport
ConditionEpisodeOfCareProcedureCarePlanGoalServiceRequestCareTeamFamilyMemberHistory
MedicationStatementMedicationAdministrationImmunizationAllergyIntolerance
DocumentReferenceQuestionnaireResponse
EncounterAppointment
OrganizationPractitionerPractitionerRole
ConsentProvenance
RelatedPersonBasic
Cada tipo con ámbito de paciente pertenece al compartimento del paciente, por lo que Patient/{id}/$everything, los ámbitos de OAuth a nivel de paciente y los filtros de consentimiento se aplican a todos ellos. Los recursos de directorio (Organization, Practitioner, PractitionerRole) no tienen paciente; son legibles en todos los proyectos del mismo entorno y solo modificables por el proyecto que los creó.
Interacciones y operaciones
- CRUD + searchEvery type; unknown search parameters refused with 400
- History_history for every version; If-Match for safe updates
- TransactionsBundles of type transaction or batch
- $everythingThe whole compartment of one patient
- $summaryAn International Patient Summary document
- Read, search, create, update, delete en cada tipo soportado; los parámetros de búsqueda por tipo se listan en la CapabilityStatement. Los parámetros de búsqueda desconocidos son rechazados con
400en lugar de ser ignorados silenciosamente. - History:
GET /fhir/R4/{type}/{id}/_historydevuelve cada versión; las actualizaciones se pueden hacer condicionales conIf-Match(un error de coincidencia de versión responde con412). - Transactions and batches:
POST /fhir/R4con unBundlede tipotransactionobatch. Patient/{id}/$everything: todo el compartimento de un paciente.Patient/{id}/$summary: un documento International Patient Summary (IPS)Bundle, en inglés o rumano (?lang=).Observation/$validate?profile=eu-lab: informa cómo un resultado de laboratorio se compara con las reglas de informe de laboratorio de HL7 Europe.- Paging:
_counthasta 200;_revincludedevuelve como máximo 1 000 recursos. - Idempotency: las solicitudes
POSTaceptan unIdempotency-Key; repetir una solicitud con la misma clave devuelve la misma respuesta y no crea nada.
# latest HbA1c results of one patient, strict FHIR
curl "https://platform.anpheros.com/fhir/R4/Observation?patient=$PID&code=http://loinc.org|4548-4&_sort=-date" \
-H "Authorization: Bearer $KEY"
# the patient's International Patient Summary
curl "https://platform.anpheros.com/fhir/R4/Patient/$PID/\$summary?lang=en" -H "Authorization: Bearer $KEY"
FHIR y la API REST simplificada
/v1 existe para desarrolladores que no desean trabajar directamente con recursos FHIR. Cubre pacientes, observaciones, condiciones, medicamentos, documentos, una línea de tiempo cronológica y procedencia, además de las características de la plataforma (contexto, importación de laboratorio, webhooks, terminología). Cada objeto /v1 lleva su referencia fhir, por lo que una aplicación puede comenzar con /v1 y cambiar a FHIR para las partes donde necesite el modelo completo.
Estándares en torno a FHIR
$summary produce un Resumen Internacional de Paciente validado con el validador oficial de HL7 (0 errores); los resultados de laboratorio se verifican con las reglas de laboratorio de HL7 Europe (actualmente son consultivas); las aplicaciones de terceros se conectan a través del lanzamiento independiente de SMART on FHIR; se aceptan mensajes de laboratorio HL7 v2 ORU^R01 como entrada. Los formatos, niveles y patrones de intercambio se describen en Interoperabilidad de datos de salud; los sistemas de códigos por tipo de recurso en Sistemas de códigos FHIR.
Preguntas frecuentes
¿Qué es una plataforma FHIR?
Un servicio que almacena datos de salud como recursos HL7 FHIR y los expone a través de la API REST FHIR estándar, añadiendo lo que las aplicaciones necesitan alrededor del estándar: autorización, consentimiento, auditoría, historial y operaciones como $everything y $summary. Anpheros es una plataforma FHIR R4 gestionada: la llamas en lugar de ejecutar un servidor FHIR.
¿Cuál es la diferencia entre un servidor FHIR y una plataforma FHIR?
Un servidor FHIR implementa la API FHIR sobre una base de datos. Una plataforma FHIR la ejecuta por ti y añade la capa que la rodea — consentimiento del paciente, procedencia, registros de acceso, SDKs, webhooks, importación de laboratorios y un sandbox — para que las aplicaciones no tengan que construir esas partes.
¿Qué versión de FHIR soporta Anpheros?
FHIR R4 (4.0.1), con 26 tipos de recursos listados en la CapabilityStatement pública en /fhir/R4/metadata.
¿Se prueba la plataforma FHIR de Anpheros de forma independiente?
El grupo "Standalone Launch" de SMART App Launch STU2 del kit de pruebas de código abierto Inferno supera 22 de 22 pruebas (ejecución del 28 de septiembre de 2026), y el International Patient Summary se valida sin errores en el validador oficial de HL7. El lanzamiento de EHR y la exportación de datos masivos aún no son compatibles.
¿Puedo usar la plataforma FHIR de forma gratuita?
Sí. El sandbox es gratuito e incluye 30 pacientes sintéticos por proyecto; la producción comienza en 99 € al mes con el primer mes gratis.
¿Tengo que usar FHIR para usar Anpheros?
No. Una API REST más sencilla (/v1) lee y escribe los mismos recursos con los mismos IDs, por lo que una aplicación puede empezar con JSON plano y cambiar a FHIR donde necesite el modelo completo.
Relacionado
- Sandbox FHIR: un servidor de pruebas FHIR R4 privado y gratuito
- International Patient Summary (IPS) en FHIR
- Procedencia de datos médicos explicada: quién escribió qué y cómo registrarlo
- Cómo almacenar historiales médicos usando FHIR R4: tutorial paso a paso con curl
- FHIR vs. una base de datos médica personalizada: cuándo diseñar sus propias tablas y cuándo usar FHIR
- Base de datos y sandbox FHIR gratuitos
- Cómo se compara Anpheros con otros servidores FHIR
- Interoperabilidad de datos de salud
- Sistemas de código FHIR
- API de datos médicos
- Crear una aplicación de salud
- Referencia de la API (OpenAPI)
- DICOM vs FHIR: dónde termina FHIR y comienza la imagen médica
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card