# Procedencia de datos médicos explicada

> Qué registros de procedencia en cada escritura a un registro FHIR R4 — tipo de autor, persona, organización, sistema de origen, versiones — cómo configurarlo con encabezados, cómo leerlo y cómo etiqueta los datos proporcionados a los modelos de IA.

Source: https://developers.anpheros.com/es/guides/medical-data-provenance

**La procedencia es el registro de dónde provino un dato médico: quién lo escribió, en nombre de qué organización, desde qué sistema, cuándo y qué cambió en cada versión.** En un registro que recopila datos de pacientes, dispositivos, clínicas, laboratorios e IA, la procedencia es lo que hace que un valor sea confiable: una lectura de presión arterial escrita en casa y una medida en una clínica se ven idénticas sin ella. En Anpheros, cada escritura a un registro HL7 FHIR R4 produce automáticamente un recurso FHIR `Provenance`. Esta página explica qué contiene, cómo rellenarlo correctamente y cómo leerlo.

## Por qué la procedencia es importante

- **Confianza clínica.** Un médico sopesa un resultado de laboratorio de manera diferente a un valor que el paciente ingresó o un número que una IA extrajo de una foto.
- **Seguridad de la IA.** Un modelo al que se le da un registro debe saber qué elementos son hechos y cuáles son notas que escribió otro modelo. Sin etiquetas, los trata igual.
- **Correcciones y disputas.** Cuando un valor cambia, todos necesitan saber cuál era antes, quién lo cambió y por qué.
- **Responsabilidad.** Bajo el GDPR y el Espacio Europeo de Datos de Salud, una organización debe poder demostrar qué hizo con los datos de salud de una persona.
- **Compartir.** Cuando un paciente permite que una segunda clínica lea su registro, esa clínica necesita saber qué datos escribió la primera clínica.

## Qué registra Anpheros en cada escritura

| Pregunta | Dónde se registra | Cómo lo configuras |
|---|---|---|
| ¿Qué tipo de autor? | `agent.who.identifier` (tipo de autor) | `author_type` en `/v1`, o encabezado `X-Anpheros-Author-Type`: `patient`, `practitioner`, `device`, `import`, `ai` |
| ¿Qué persona? | `agent.who.reference` | `X-Anpheros-Author-Ref: Practitioner/<id>`, o `X-Anpheros-Acting-As` |
| ¿Para qué organización? | `agent.onBehalfOf` | la organización del `PractitionerRole`, o `X-Anpheros-On-Behalf-Of: Organization/<id>` |
| ¿Desde qué sistema? | `entity` con rol `source` | `X-Anpheros-Source-System: <name>` |
| ¿Qué registro en ese sistema? | id de origen | `X-Anpheros-Origin-Id: <id>` |
| ¿Cuándo y qué sucedió? | `recorded`, `activity` (CREATE, UPDATE, DELETE) | automático |
| ¿Qué versión? | `target` apunta a `<Resource>/<id>/_history/<version>` | automático |

Si no indicas quién es el autor, la plataforma registra `import`. Nunca asume `patient`, porque un valor atribuido erróneamente al paciente es peor que uno etiquetado honestamente como importado.

## Una escritura con procedencia completa

Un cardiólogo en una clínica registra una frecuencia cardíaca durante una visita, a través del software de la clínica:

```bash
curl -X POST https://platform.anpheros.com/fhir/R4/Observation -H "Authorization: Bearer $KEY" \
     -H "Content-Type: application/fhir+json" \
     -H "X-Anpheros-Author-Type: practitioner" \
     -H "X-Anpheros-Acting-As: PractitionerRole/$ROLE" \
     -H "X-Anpheros-Source-System: ccn-emr" \
     -d '{ "resourceType": "Observation", "status": "final", "code": {"coding": [{"system": "http://loinc.org", "code": "8867-4"}]}, … }'
```

La procedencia que escribe la plataforma:

```json
{"resourceType": "Provenance",
 "target": [{"reference": "Observation/8660eb7c-…/_history/1"}],
 "recorded": "2026-10-12T20:41:47.469000Z",
 "activity": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation", "code": "CREATE"}]},
 "agent": [{"type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type", "code": "author"}]},
            "who": {"reference": "PractitionerRole/e6d8c227-…",
                    "identifier": {"system": "https://anpheros.com/fhir/CodeSystem/author-type", "value": "practitioner"}},
            "onBehalfOf": {"reference": "Organization/c3a56a4b-…", "display": "Clinica Cardio Nord"}}],
 "entity": [{"role": "source", "what": {"identifier": {"system": "ccn-emr"}}}]}
```

El rol del médico, su clínica, el tipo de autor y el sistema de origen están ahí, en FHIR estándar. El `PractitionerRole` debe existir en el directorio de su proyecto y estar activo. Se rechaza una solicitud que nombre a un profesional que no sea el suyo:

```json
{"resourceType": "OperationOutcome", "issue": [{"severity": "error", "code": "invalid",
  "diagnostics": "Unknown or inactive Practitioner in X-Anpheros-Acting-As."}]}
```

La configuración del directorio se cubre en [Cómo integrar sistemas de clínicas con un backend FHIR](https://developers.anpheros.com/es/guides/integrate-clinic-systems-fhir).

## Versiones: nada se sobrescribe silenciosamente

Cada actualización crea una nueva versión del recurso y una nueva Provenance para él. Después de que la frecuencia cardíaca anterior se corrige de 92 a 88:

```bash
curl https://platform.anpheros.com/fhir/R4/Observation/$OBS/_history -H "Authorization: Bearer $KEY"
```

devuelve la versión 2 (88) y la versión 1 (92). La vista REST resume la Provenance de cada versión:

```bash
curl https://platform.anpheros.com/v1/patients/$PID/provenance/Observation/$OBS -H "Authorization: Bearer $KEY"
```

```json
{"data": [
  {"version": 1, "activity": "CREATE", "recorded": "2026-10-12T20:41:47.469000Z", "author_type": "practitioner", "author": "PractitionerRole/e6d8c227-…", "source_system": "ccn-emr", "fhir": "Provenance/6ed91529-…"},
  {"version": 2, "activity": "UPDATE", "recorded": "2026-10-12T20:41:47.500000Z", "author_type": "practitioner", "fhir": "Provenance/3fbf270f-…"}],
 "total": 2}
```

Las eliminaciones son lógicas: un recurso eliminado desaparece de las búsquedas, pero su historial y Provenance permanecen.

## Lectura de la procedencia

```bash
# who wrote this resource (all versions)
GET /fhir/R4/Provenance?target=Observation/{id}
# everything a practitioner recorded
GET /fhir/R4/Provenance?agent=PractitionerRole/{id}
# the same, summarised, per resource
GET /v1/patients/{pid}/provenance/Observation/{id}
```

## Procedencia en contextos de IA

La [API de contexto](https://developers.anpheros.com/es/guides/llm-healthcare-data) lleva la procedencia a cada elemento que proporciona a un modelo, como `author_type` y `source`. En formato de texto:

```
- Type 2 diabetes mellitus (E11), active, onset 2024-10-15 [import/anpheros-sandbox]
- Metformin 1000 mg 1 tablet twice daily with meals, active [patient/anpheros-sandbox]
- Glucose [Mass/volume] in Blood: 2026-09-16: 140.0 mg/dL [device/anpheros-sandbox]
```

Las mediciones escritas con `author_type: ai` nunca aparecen entre estos hechos. Se enumeran por separado en `ai_notes` y se marcan como no verificadas, para que un modelo no pueda confundir la suposición de un modelo anterior con una medición. Indique al modelo qué significan las etiquetas y pídale que las cite; [Cómo crear una aplicación de atención médica con IA con un backend FHIR](https://developers.anpheros.com/es/guides/build-ai-healthcare-app) muestra un prompt que lo hace.

## Lo que ve el paciente

La procedencia es también lo que ve el paciente. Su registro muestra quién añadió cada elemento, y su lista de conexiones muestra, para cada aplicación, quién accedió a qué, por nombre cuando un profesional estaba actuando ("Dr. Ana Popescu · Clinica Cardio Nord leyó sus resultados de laboratorio"). Ver [Modelo de consentimiento y acceso](https://developers.anpheros.com/es/guides/consent).

## Reglas que hacen útil la procedencia

1. **Siempre establezca el tipo de autor.** Cuesta un campo y es la etiqueta más importante en el registro.
2. **Nombre a la persona cuando la escribió una persona.** Use `X-Anpheros-Acting-As` para el personal clínico.
3. **Nombre el sistema de origen** y pase el propio ID del origen como ID de origen cuando exista uno.
4. **Corrija actualizando, nunca eliminando y volviendo a crear.** Una actualización mantiene el enlace entre el valor antiguo y el nuevo.
5. **Etiquete la salida de IA como `ai`**, incluidos los valores que un modelo extrajo de un documento. Los valores derivados de un documento también pueden apuntar de nuevo a él con `derived_from`.

## Preguntas frecuentes

### ¿Qué es la procedencia de datos en la atención médica?
El origen y el historial documentados de un dato de salud: quién lo creó o modificó, en nombre de quién, desde qué sistema y cuándo. En HL7 FHIR, se representa mediante el recurso `Provenance`, que apunta a la versión exacta del recurso que describe.

### ¿La procedencia es lo mismo que un registro de auditoría?
No. La procedencia describe los datos: quién escribió cada versión. Un registro de auditoría describe el acceso: quién leyó o escribió qué, cuándo, bajo qué consentimiento. Anpheros mantiene ambos; el paciente ve el registro de acceso de cada aplicación conectada a su historial.

### ¿Puedo escribir mis propios recursos de Procedencia?
Anpheros escribe uno por cada creación, actualización y eliminación, por lo que normalmente no es necesario. Utilice las cabeceras anteriores para hacerlo preciso. Una Procedencia proporcionada por el cliente debe dirigirse a recursos de un solo paciente.

## Relacionado

- [Modelo de consentimiento y acceso](https://developers.anpheros.com/es/guides/consent)
- [Cómo integrar sistemas de clínicas con un backend FHIR](https://developers.anpheros.com/es/guides/integrate-clinic-systems-fhir)
- [Cómo normalizar datos médicos](https://developers.anpheros.com/es/guides/normalize-medical-data)
- [Interoperabilidad de datos de salud](https://developers.anpheros.com/es/guides/interoperability)
- [Seguridad, privacidad y residencia de datos](https://developers.anpheros.com/es/guides/security)