El recurso DiagnosticReport es la piedra angular de la representación de datos de laboratorio en FHIR R4. Sirve como el contenedor que une un paciente, un conjunto de resultados de pruebas, el laboratorio que las realizó y el contexto clínico en una única entidad estructurada. Si estás integrando datos de laboratorio en un sistema HCE, construyendo un visor de resultados o consumiendo la salida de una API de extracción, comprender DiagnosticReport en profundidad es esencial.
Este artículo proporciona un recorrido exhaustivo del recurso DiagnosticReport: sus campos, su ciclo de vida, su relación con otros recursos y los errores comunes que afectan a los implementadores.
Qué representa DiagnosticReport
En el modelo de datos FHIR, un DiagnosticReport representa los hallazgos e interpretaciones producidos por un servicio diagnóstico. Aunque puede representar informes de radiología, patología o pruebas genéticas, su uso más común en informática clínica es representar un informe de laboratorio.
Un único DiagnosticReport corresponde a un informe de laboratorio — el documento que un clínico revisaría para ver los resultados de las pruebas de un paciente. El informe contiene referencias a recursos Observation individuales (uno por resultado de prueba), metadatos sobre cuándo se realizaron las pruebas y cuándo se finalizó el informe, y opcionalmente una referencia al documento original (como PDF o imagen).
DiagnosticReport vs. Observation
La distinción entre DiagnosticReport y Observation es fundamental:
- Observation representa un único resultado de prueba: un analito, un valor, un código LOINC.
- DiagnosticReport representa el informe que agrupa esos resultados. Lleva su propio código LOINC (típicamente un código de panel como
58410-2para hemograma), un estado y referencias a todas las Observations constituyentes.
No puedes tener Observations flotando sin un DiagnosticReport padre en una implementación FHIR bien estructurada. El DiagnosticReport proporciona el contexto clínico — quién solicitó las pruebas, cuándo se recogieron y cuál es la interpretación general.
Recorrido por la estructura de DiagnosticReport
Examinemos cada campo de un DiagnosticReport relevante para datos de laboratorio, con orientación práctica sobre cómo rellenar cada uno.
Tipo de recurso e ID
{
"resourceType": "DiagnosticReport",
"id": "report-cbc-2026-03-01"
}
El id es asignado por el servidor FHIR al crearse. Al enviar mediante un Bundle de Transacción, usa un identificador urn:uuid: en el campo fullUrl.
Status
El campo status rastrea el ciclo de vida del informe. FHIR define los siguientes valores:
| Estado | Significado | Cuándo usarlo |
|--------|-------------|---------------|
| registered | El informe se ha registrado pero los resultados no están disponibles | Solicitud recibida, sin resultados |
| partial | Algunos pero no todos los resultados están disponibles | Resultados preliminares de pruebas rápidas |
| preliminary | Los resultados están disponibles pero no verificados | Resultados auto-publicados pendientes de revisión |
| final | El informe está completo y verificado | Lo más común para salida de extracción |
| amended | El informe fue modificado después de finalizarse | Corrección de un valor previamente reportado |
| corrected | El informe fue corregido (equivalente a amended en la mayoría de implementaciones) | Escenario de corrección |
| appended | Se añadieron resultados adicionales a un informe final | Resultados que llegan tarde |
| cancelled | El informe fue cancelado y debe ignorarse | Solicitud cancelada |
| entered-in-error | El informe se introdujo por error | Error de entrada de datos |
Para pipelines de extracción que procesan informes de laboratorio completados, final es casi siempre el estado correcto. Usa amended si estás actualizando un informe previamente enviado.
Category
La categoría clasifica el tipo de informe diagnóstico. Para datos de laboratorio, usa el código de sección de servicio diagnóstico de HL7 V2:
{
"category": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v2-0074",
"code": "LAB",
"display": "Laboratory"
}]
}]
}
Algunas implementaciones subdividen la categoría. Un panel de bioquímica podría llevar tanto LAB como un código más específico como CH (Chemistry). Sin embargo, la categoría LAB sola es suficiente para la mayoría de los escenarios de integración.
Code
El campo code identifica qué cubre el informe. Para informes de laboratorio, esto es típicamente un código de panel LOINC:
{
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "58410-2",
"display": "CBC panel - Blood by Automated count"
}],
"text": "Hemograma completo"
}
}
El campo text debe llevar el nombre original del panel del documento fuente. Cuando el informe cubre múltiples paneles (p. ej., hemograma + panel metabólico), tienes dos opciones:
- Crear un único DiagnosticReport con un código general (
11502-2, "Laboratory report") y referenciar todas las Observations. - Crear múltiples DiagnosticReports, uno por panel, cada uno con su código de panel específico.
La opción 1 es más simple y es el enfoque que usan la mayoría de los pipelines de extracción. La opción 2 proporciona una organización más granular pero añade complejidad.
Subject
El campo subject referencia al paciente:
{
"subject": {
"reference": "Patient/patient-1",
"display": "Garcia, Maria"
}
}
En escenarios de extracción donde el paciente no está registrado en el servidor FHIR destino, usa una referencia lógica con un identificador:
{
"subject": {
"identifier": {
"system": "http://hospital.example.org/mrn",
"value": "MRN-12345"
},
"display": "Garcia, Maria"
}
}
Fecha efectiva y fecha de emisión
Dos campos temporales son críticos:
- effectiveDateTime: Cuándo se recogió el espécimen o se realizó la prueba. Esta es la fecha clínicamente relevante.
- issued: Cuándo se emitió el informe (se hizo disponible). Es típicamente posterior a la fecha efectiva.
{
"effectiveDateTime": "2026-03-01T08:30:00Z",
"issued": "2026-03-01T14:00:00+01:00"
}
Para la extracción de informes en papel, la fecha efectiva corresponde a la fecha de recogida del espécimen impresa en el informe, y la fecha de emisión corresponde a la fecha del informe. Si solo hay una fecha disponible, úsala para ambos campos.
Performer
El campo performer identifica quién es responsable del informe. Para datos de laboratorio, esto es típicamente el laboratorio que realizó las pruebas:
{
"performer": [{
"reference": "Organization/lab-central",
"display": "Laboratorio Central Hospital Universitario"
}]
}
Referencias a resultados
El array result referencia todos los recursos Observation que forman parte de este informe:
{
"result": [
{ "reference": "Observation/obs-hgb-1", "display": "Hemoglobina" },
{ "reference": "Observation/obs-wbc-1", "display": "Leucocitos" },
{ "reference": "Observation/obs-plt-1", "display": "Plaquetas" },
{ "reference": "Observation/obs-hct-1", "display": "Hematocrito" },
{ "reference": "Observation/obs-rbc-1", "display": "Eritrocitos" }
]
}
En un Bundle de Transacción, estas referencias usan identificadores urn:uuid: que el servidor resuelve a IDs reales de recursos.
Forma presentada
El campo presentedForm puede llevar el documento original como un adjunto:
{
"presentedForm": [{
"contentType": "application/pdf",
"url": "https://storage.example.org/reports/report-2026-03-01.pdf",
"title": "Informe de laboratorio"
}]
}
Esto es valioso para auditoría — los clínicos pueden comparar los datos estructurados contra el documento original. El adjunto puede ser una referencia URL al documento almacenado o una representación inline en base64 (aunque la codificación inline se desaconseja para archivos grandes).
Ejemplo completo de DiagnosticReport
He aquí un DiagnosticReport completamente rellenado para un panel de hemograma:
{
"resourceType": "DiagnosticReport",
"id": "report-cbc-001",
"meta": {
"profile": [
"http://hl7.org/fhir/StructureDefinition/DiagnosticReport"
]
},
"status": "final",
"category": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v2-0074",
"code": "LAB",
"display": "Laboratory"
}]
}],
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "58410-2",
"display": "CBC panel - Blood by Automated count"
}],
"text": "Hemograma completo"
},
"subject": {
"reference": "Patient/patient-1",
"display": "Garcia, Maria"
},
"effectiveDateTime": "2026-03-01T08:30:00Z",
"issued": "2026-03-01T14:00:00Z",
"performer": [{
"reference": "Organization/lab-central",
"display": "Laboratorio Central"
}],
"result": [
{ "reference": "Observation/obs-hgb-1" },
{ "reference": "Observation/obs-wbc-1" },
{ "reference": "Observation/obs-plt-1" },
{ "reference": "Observation/obs-hct-1" },
{ "reference": "Observation/obs-rbc-1" },
{ "reference": "Observation/obs-mcv-1" },
{ "reference": "Observation/obs-mch-1" },
{ "reference": "Observation/obs-mchc-1" }
],
"conclusion": "Todos los valores dentro de los límites normales.",
"presentedForm": [{
"contentType": "application/pdf",
"url": "https://storage.example.org/reports/cbc-001.pdf",
"title": "Informe original de laboratorio"
}]
}
Relación con los recursos Observation
El DiagnosticReport y sus Observations referenciadas forman una relación padre-hijo. Se aplican varios principios de diseño.
Un Observation por resultado de prueba
Cada resultado discreto de prueba (hemoglobina, glucosa, recuento de plaquetas) debe ser un Observation separado. No combines múltiples resultados en un único Observation — esto rompe el modelo de datos FHIR y previene que los resultados individuales sean consultados, trazados en tendencias o referenciados independientemente.
Observation.category
Cada Observation de laboratorio debe llevar la categoría laboratory:
{
"category": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "laboratory"
}]
}]
}
Retrorreferencia desde Observation
Aunque no lo exige la especificación, muchas implementaciones incluyen una referencia desde el Observation de vuelta a su DiagnosticReport padre usando derivedFrom o una extensión personalizada. Esto simplifica las consultas que empiezan desde un Observation y necesitan encontrar su informe contenedor.
Observaciones de panel
LOINC define códigos de panel (como 58410-2 para hemograma) que agrupan códigos miembros individuales. FHIR soporta esto con el campo hasMember en Observation, donde una observación de panel referencia sus observaciones miembros:
{
"resourceType": "Observation",
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "58410-2",
"display": "CBC panel"
}]
},
"hasMember": [
{ "reference": "Observation/obs-hgb-1" },
{ "reference": "Observation/obs-wbc-1" }
]
}
Sin embargo, esta capa adicional es opcional. Muchas implementaciones omiten el Observation de panel y dejan que el DiagnosticReport referencie directamente las Observations individuales.
Errores comunes de implementación
Error 1: Campo status ausente
El campo status es obligatorio (cardinalidad 1..1). Omitirlo causa errores de validación en todo servidor FHIR. Establece siempre el status, incluso si el ciclo de vida del informe es simple y todos los informes son final.
Error 2: URIs de sistema de códigos incorrectas
FHIR es estricto con las URIs de sistemas de códigos. La URI del sistema LOINC debe ser exactamente http://loinc.org (no https://, no http://loinc.org/, no urn:oid:2.16.840.1.113883.6.1). De igual modo, UCUM debe ser http://unitsofmeasure.org. Las URIs incorrectas fallarán en la validación y pueden causar que los sistemas posteriores malinterpreten los códigos.
Error 3: Observations huérfanas
Enviar Observations sin un DiagnosticReport padre crea datos difíciles de interpretar y gestionar. Crea siempre el DiagnosticReport en el mismo Bundle de Transacción que sus Observations.
Error 4: Ignorar la detección de duplicados
Si el mismo informe de laboratorio se envía dos veces (por reintentos de red, reprocesamiento o errores del sistema), el servidor destino creará recursos duplicados. Implementa idempotencia usando creaciones condicionales:
{
"request": {
"method": "POST",
"url": "DiagnosticReport",
"ifNoneExist": "identifier=http://lab.example.org/reports|RPT-2026-001"
}
}
Esto le dice al servidor que omita la creación si ya existe un DiagnosticReport con ese identificador.
Error 5: Formatos de fecha incorrectos
FHIR usa formatos de fecha ISO 8601. El campo effectiveDateTime acepta fechas (2026-03-01), fechas-hora (2026-03-01T08:30:00Z) y fechas-hora con offsets de zona horaria (2026-03-01T08:30:00+01:00). Usar formatos no ISO u omitir la información de zona horaria produce marcas temporales ambiguas.
Error 6: Falta de integridad referencial
En un Bundle de Transacción, cada referencia debe resolverse a un recurso dentro del bundle o a un recurso existente en el servidor. Si un Observation referencia Patient/patient-1 pero ese Patient no existe en el servidor y no está en el bundle, la transacción fallará. Usa referencias condicionales o incluye todos los recursos referenciados en el bundle.
Perfiles y restricciones
El DiagnosticReport base de FHIR es intencionalmente flexible. Los perfiles lo restringen para casos de uso específicos.
IPS (International Patient Summary)
El perfil IPS requiere que DiagnosticReport incluya como mínimo: status, code, subject y al menos una referencia de resultado. El code debe provenir de un conjunto de valores definido que incluye códigos de paneles de laboratorio LOINC.
EU Laboratory Report
El perfil europeo de informe de laboratorio de HL7 Europe añade requisitos específicos para el intercambio transfronterizo europeo:
- El performer debe incluir el identificador organizativo del laboratorio.
- El code debe usar LOINC.
- Los resultados deben referenciar perfiles EU Lab Observation.
- El recurso specimen es obligatorio (no opcional como en la especificación base).
US Core DiagnosticReport for Laboratory Results
El perfil US Core requiere:
- Una
categorydeLAB. - Un
codede un conjunto de valores obligatorio. - Una referencia
subjecta un US Core Patient. - Un
effectiveDateTimeoeffectivePeriod.
Implementar el perfil correcto depende de tu mercado objetivo y requisitos regulatorios. Para despliegues en la UE, el perfil EU Laboratory Report se alinea con los requisitos del EEDS. Para despliegues en EE.UU., US Core es la línea base.
Consultar DiagnosticReports
Los servidores FHIR soportan la búsqueda de DiagnosticReports usando parámetros de búsqueda estándar.
Consultas comunes
Buscar todos los informes de laboratorio de un paciente:
GET /DiagnosticReport?patient=Patient/patient-1&category=LAB
Buscar informes dentro de un rango de fechas:
GET /DiagnosticReport?patient=Patient/patient-1&date=ge2026-01-01&date=le2026-03-31
Buscar informes que contengan una prueba específica (por código LOINC):
GET /DiagnosticReport?result.code=http://loinc.org|718-7
Buscar informes por estado:
GET /DiagnosticReport?patient=Patient/patient-1&status=final
Incluir Observations referenciadas
Para recuperar un DiagnosticReport junto con todas sus Observations referenciadas en una sola solicitud, usa el parámetro _include:
GET /DiagnosticReport?patient=Patient/patient-1&_include=DiagnosticReport:result
El servidor devuelve un Bundle search-set que contiene el DiagnosticReport y todos los recursos Observation referenciados.
DiagnosticReport en el pipeline de extracción
Al construir un pipeline de extracción de datos de laboratorio, el DiagnosticReport es típicamente el último recurso que se ensambla. El flujo de trabajo es:
- Extraer resultados de pruebas del documento (OCR, análisis).
- Mapear cada prueba a un código LOINC.
- Crear un Observation para cada resultado.
- Crear un DiagnosticReport referenciando todas las Observations.
- Envolver en un Bundle de Transacción para envío atómico.
La API de MedExtract maneja todo este flujo de trabajo. Envías un documento de informe de laboratorio y recibes un Bundle de Transacción FHIR R4 con un DiagnosticReport correctamente rellenado y todas las Observations asociadas. La salida se valida contra la especificación R4 base y opcionalmente contra perfiles EU Lab.
Para ver cómo DiagnosticReport encaja en el panorama más amplio de integración FHIR, lee nuestra guía de implementación FHIR R4. Para detalles sobre cómo se asignan los códigos LOINC a las Observations, consulta nuestra guía completa de extracción LOINC.
Para evaluación práctica:
- Revisa la documentación de la API para detalles del formato de salida FHIR
- Solicita una demo para ver la salida DiagnosticReport de tus propios informes de laboratorio
Artículos relacionados
Implementación FHIR R4 para el sector sanitario
Guía práctica para implementar FHIR R4 en sistemas sanitarios: recursos, bundles, endpoints y mejores prácticas de integración.
Guía de integración FHIR R4 para sistemas HCE
Una visión práctica de la integración de recursos FHIR R4 en sistemas HCE, centrada en bundles DiagnosticReport y Observation de datos de laboratorio.
Guía completa de extracción de códigos LOINC
Todo sobre la extracción automatizada de códigos LOINC desde informes de laboratorio: proceso, desafíos, diccionarios y mejores prácticas.