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

Aplicación de registro de salud personal (PHR) con FHIR

Tutorial: el backend de un PHR conectado en FHIR R4 — datos de personas, laboratorios, documentos y dispositivos, una línea de tiempo, un IPS para compartir, consentimiento. Código probado.

Una aplicación de registro de salud personal (PHR) mantiene la información de salud de una persona — resultados, mediciones, diagnósticos, medicamentos, documentos — en un registro que la persona controla, recopilada de muchas fuentes en lugar de un solo hospital. Las partes difíciles no son las pantallas: son obtener datos de laboratorios, clínicas y dispositivos en una forma utilizable, hacer un seguimiento de dónde provino cada elemento y permitir que la persona comparta el registro sin perder el control sobre él. Este tutorial construye el backend de un PHR en HL7 FHIR R4 con el SDK de Anpheros TypeScript; el código a continuación se ejecutó contra una instancia local de la plataforma con una clave de sandbox.

PHR (Registros de Salud Personales) anclados, no anclados y conectados

Tipo	Dónde residen los datos	Limitación
Anclado (un portal del paciente de un hospital)	El EHR del proveedor	Muestra solo los datos de ese proveedor; cambia cuando la persona cambia de médico
No anclado (una aplicación independiente o un cuaderno)	La propia base de datos de la aplicación	La persona escribe todo; los datos rara vez salen de la aplicación
Conectado	Un registro estándar que las aplicaciones, laboratorios y clínicas leen y escriben con el consentimiento de la persona	Requiere estándares, consentimiento y procedencia subyacentes

Un PHR conectado es el que vale la pena construir hoy. También es hacia dónde se dirige la política: en los Estados Unidos, los EHR certificados deben ofrecer a los pacientes acceso a la API basado en FHIR a sus datos (US Core), y en la Unión Europea, el Espacio Europeo de Datos Sanitarios otorga a las personas el derecho a acceder a sus datos de salud electrónicos y a compartirlos con los proveedores de su elección, implementado gradualmente a partir de 2029.

De dónde provienen los datos de un PHR

La persona: mediciones caseras, síntomas, medicamentos que toma, afecciones que conoce. Márquelos como reportados por el paciente.
Informes de laboratorio: la mayoría de las personas reciben PDFs; algunos laboratorios pueden enviar HL7 v2 o CSV. Cada resultado debe convertirse en una Observación codificada (API de resultados de laboratorio).
Documentos: cartas de alta, informes de imágenes, recetas. Conserve el archivo original, sin cambios, junto a los datos estructurados.
Dispositivos y wearables: pasos diarios, frecuencia cardíaca, sueño, presión arterial de Apple Health o Health Connect (datos de wearables en FHIR).
Proveedores: en EE. UU., APIs FHIR de acceso para pacientes de hospitales y aseguradoras, a las que se accede con SMART on FHIR; en otros lugares, principalmente documentos y resúmenes como el Resumen Internacional del Paciente (IPS).

Cada fuente escribe en el mismo registro. Lo que lo mantiene confiable es que cada elemento registra quién lo escribió y de qué sistema (procedencia de datos médicos).

La arquitectura

 person ──► your PHR app (mobile / web) ──► your backend ──► Anpheros: one FHIR R4 record per person
                                               │                 ├─ Observations, Conditions, Medications, Documents…
   lab report, PDF, device data ───────────────┘                 ├─ Provenance on every write
                                                                 ├─ access log the person can see
   other apps, doctors, AI assistants ◄── consent (OAuth) ───────┴─ $summary (IPS) to share

Tu backend contiene la clave del proyecto (sk_test_… en el sandbox, nunca en la app). Tu app inicia sesión con tu propia autenticación y se comunica con tu backend; el backend mapea cada usuario a un registro de paciente.

Paso a paso

Instale el SDK (npm install @anpheros/sdk) y obtenga una clave de sandbox gratuita desde el panel. La muestra utiliza un panel de lípidos HL7 v2 de dos resultados (lipid-panel.hl7) y cualquier PDF (report.pdf).

import { readFile } from 'node:fs/promises';
import { Anpheros, apiKey } from '@anpheros/sdk';

const anpheros = new Anpheros({ auth: apiKey(process.env.ANPHEROS_KEY!) });

// 1. One record per person who signs up in your PHR app
const jane = await anpheros.patients.create({ given: 'Jane', family: 'Doe', birth_date: '1984-07-19', gender: 'female' });

// 2. Something the person measured at home
await anpheros.observations.create(jane.id, {
  code: '85354-9', category: 'vital-signs', effective_at: '2026-10-01T08:30:00-05:00', author_type: 'patient',
  components: [{ code: '8480-6', value: 128, unit: 'mm[Hg]' }, { code: '8462-4', value: 82, unit: 'mm[Hg]' }],
});

// 3. A diagnosis and a medication the person reports
await anpheros.conditions.create(jane.id, { code: 'E11.9', system: 'http://hl7.org/fhir/sid/icd-10',
  display: 'Type 2 diabetes mellitus without complications', clinical_status: 'active', onset: '2021-03-15', author_type: 'patient' });
await anpheros.medications.create(jane.id, { code: 'A10BA02', display: 'Metformin 500 mg', status: 'active',
  dosage: '500 mg twice a day', start: '2021-03-20', author_type: 'patient' });

// 4. A lab report the person received, as the lab sent it (HL7 v2)
const lab = await anpheros.labs.importHl7(jane.id, await readFile('lipid-panel.hl7', 'utf8'), { sourceSystem: 'springfield-lis' });

// 5. A PDF they want to keep with the record
const doc = await anpheros.documents.upload(jane.id,
  { title: 'Chest X-ray report', kind: 'imaging_report', content_type: 'application/pdf', date: '2026-10-03' },
  await readFile('report.pdf'));

// 6. One timeline for the home screen
const timeline = await anpheros.timeline.list(jane.id, { limit: 10 });

// 7. A summary to share with a new doctor: the International Patient Summary
const ips = await anpheros.fhir.summary(jane.id);

// 8. Who else can read this record (empty until the person consents to another app)
const grants = await anpheros.grants.of(jane.id);

Impreso de esa ejecución:

lab:       created 2, unmapped []
document:  final
timeline:  2026-10-03  document    Chest X-ray report
           2026-10-02  observation Cholesterol in HDL [Mass/volume] in Serum or Plasma
           2026-10-02  observation Cholesterol [Mass/volume] in Serum or Plasma
           2026-10-01  observation Blood pressure panel
           2021-03-20  medication  Metformin 500 mg
           2021-03-15  condition   Type 2 diabetes mellitus without complications
IPS:       Allergies, Medications, Problems, Results, Vital signs
grants:    0

Todo lo anterior se almacena como FHIR R4 — Patient, Observation, Condition, MedicationStatement, DocumentReference — por lo que el mismo registro puede ser leído con cualquier cliente FHIR (GET /fhir/R4/Patient/{id}/$everything) y trasladado a otro lugar intacto. Las llamadas /v1 en el SDK son una vista más simple de los mismos recursos; la API de datos médicos las enumera.

Compartir sin perder el control

Un PHR existe para ser compartido, en los términos de la persona:

Con un médico: el International Patient Summary ($summary) es un documento FHIR hecho para clínicos — problemas, medicamentos, alergias, resultados — que su aplicación puede mostrar, imprimir o enviar. Plataforma FHIR describe $summary y $everything.
Con otra aplicación: la otra aplicación solicita consentimiento a través de OAuth 2.1 y SMART on FHIR; la persona elige qué datos (por ejemplo, solo resultados de laboratorio) y por cuánto tiempo, y puede revocarlo en cualquier momento. Cómo implementar el consentimiento del paciente con SMART on FHIR lo explica.
Con un asistente de IA: POST /v1/context crea un resumen presupuestado y etiquetado por fuente del registro para un modelo, y la lectura aparece en el registro de acceso (Cómo crear una aplicación de IA para la salud).
Transparencia: cada lectura y escritura, por cualquier aplicación, se registra por aplicación, y la persona puede ver el registro y las concesiones activas.

Familias

Muchos PHR son mantenidos por una persona para varios miembros: hijos, pareja, padres mayores. Asigne a cada persona su propio registro y vincúlelo al tutor, en lugar de mezclar los datos de todos en uno. El consentimiento se otorga entonces por registro. Registro médico del paciente describe el modelo.

Qué construir usted mismo y qué no

Usted construye la experiencia: incorporación, cómo se explican los resultados, recordatorios, gráficos, el idioma que lee la persona. Anpheros proporciona el registro, los formatos estándar, el consentimiento, la procedencia, el registro de acceso y las operaciones de laboratorio, documentos y resúmenes.

Lo que Anpheros no hace hoy para un PHR: no inicia sesión en portales de pacientes de hospitales o APIs de acceso para pacientes de EE. UU. en nombre de la persona (su aplicación puede hacerlo con un cliente SMART on FHIR y escribir lo que recibe), no lee informes en PDF a través de la API, y no da consejos médicos. La propia aplicación PHR de Anpheros, Anpheros Daily, se basa en esta misma API.

Preguntas frecuentes

¿Qué es un registro de salud personal (PHR)?

Un registro de la información de salud de una persona que la persona mantiene y controla, recopilada de varias fuentes —sus propias entradas, laboratorios, clínicas, dispositivos— en lugar de ser mantenida por un único proveedor.

¿Cuál es la diferencia entre un PHR y un EHR?

Un EHR es mantenido por una organización de atención médica y cubre lo que sus proveedores registraron. Un PHR es mantenido por la persona y puede combinar datos de todos sus proveedores y dispositivos. Un PHR "tethered" (vinculado) es una ventana a un EHR de un proveedor; un PHR "connected" (conectado) utiliza estándares para unir varias fuentes.

¿Debería un PHR usar FHIR?

Si los datos se van a compartir alguna vez con un médico, otra aplicación o un asistente de IA, sí: FHIR R4 proporciona recursos codificados y versionados que otros sistemas ya entienden, y es el formato de las API de acceso al paciente en los EE. UU. y del resumen de paciente europeo.

¿Cómo obtiene una aplicación PHR datos de los hospitales?

En los EE. UU., a través de las API de acceso al paciente FHIR que exponen los EHR certificados y muchas aseguradoras, utilizando SMART on FHIR para permitir que la persona autorice la aplicación. En otros lugares, son principalmente documentos y resúmenes, importados y almacenados junto a datos estructurados.

¿Dónde debería una aplicación PHR guardar las claves de API?

En su servidor. Una clave de proyecto puede leer cada registro que su proyecto creó, por lo que nunca debe incluirse dentro de una aplicación móvil o web; la aplicación se comunica con su backend, y las aplicaciones de otras personas utilizan OAuth con el consentimiento de la persona.

Relacionado

Crea una aplicación de salud: el recorrido general
Expediente médico del paciente: qué contiene el expediente y quién puede acceder a él
Infraestructura de expedientes médicos digitales
Datos de wearables en FHIR: Apple Health, Health Connect y Samsung Health
API de resultados de laboratorio
SDKs

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