Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Походження медичних даних пояснено
Що записується про походження при кожному записі до FHIR R4 запису — тип автора, особа, організація, вихідна система, версії — як встановити це за допомогою заголовків, як це прочитати, і як це маркує дані, надані моделям ШІ.
Походження — це запис про те, звідки походить частина медичних даних: хто її написав, від імені якої організації, з якої системи, коли, і що змінилося в кожній версії. У записі, який збирає дані від пацієнтів, пристроїв, клінік, лабораторій та ШІ, саме походження робить значення достовірним: показник артеріального тиску, введений вдома, і показник, виміряний у клініці, виглядають ідентично без нього. В Anpheros кожен запис до HL7 FHIR R4 ресурсу автоматично створює FHIR Provenance ресурс. Ця сторінка пояснює, що він містить, як його правильно заповнювати та як його читати.
Чому походження даних має значення
- Клінічна довіра. Лікар по-різному оцінює лабораторний результат порівняно зі значенням, введеним пацієнтом, або числом, витягнутим ШІ з фотографії.
- Безпека ШІ. Модель, якій надано запис, повинна знати, які елементи є фактами, а які — примітками, написаними іншою моделлю. Без міток вона розглядає їх однаково.
- Виправлення та суперечки. Коли значення змінюється, усі повинні знати, яким воно було раніше, хто його змінив і чому.
- Підзвітність. Згідно з GDPR та Європейським простором даних охорони здоров'я, організація повинна мати можливість показати, що вона робила з даними про здоров'я особи.
- Обмін. Коли пацієнт дозволяє другій клініці прочитати його запис, ця клініка повинна знати, які дані написала перша клініка.
Що Anpheros записує під час кожного запису
| Питання | Де це записується | Як це встановити |
|---|---|---|
| Який тип автора? | agent.who.identifier (тип автора) |
author_type в /v1, або X-Anpheros-Author-Type заголовок: patient, practitioner, device, import, ai |
| Яка особа? | agent.who.reference |
X-Anpheros-Author-Ref: Practitioner/<id>, або X-Anpheros-Acting-As |
| Для якої організації? | agent.onBehalfOf |
організація PractitionerRole, або X-Anpheros-On-Behalf-Of: Organization/<id> |
| З якої системи? | entity з роллю source |
X-Anpheros-Source-System: <name> |
| Який запис у цій системі? | origin id | X-Anpheros-Origin-Id: <id> |
| Коли і що сталося? | recorded, activity (CREATE, UPDATE, DELETE) |
автоматично |
| Яка версія? | target вказує на <Resource>/<id>/_history/<version> |
автоматично |
Якщо ви не вказуєте, хто є автором, платформа записує import. Вона ніколи не припускає patient, оскільки значення, помилково приписане пацієнту, гірше, ніж те, що чесно позначене як імпортоване.
Запис із повною історією походження
Кардіолог у клініці записує частоту серцевих скорочень під час візиту через програмне забезпечення клініки:
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"}]}, … }'
Історія походження (Provenance), яку записує платформа:
{"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"}}}]}
Роль лікаря, його клініка, тип автора та вихідна система – усе це є у стандартному форматі FHIR. PractitionerRole має існувати у каталозі вашого проєкту та бути активним. Запит, що називаєPractitioner іншої особи, відхиляється:
{"resourceType": "OperationOutcome", "issue": [{"severity": "error", "code": "invalid",
"diagnostics": "Unknown or inactive Practitioner in X-Anpheros-Acting-As."}]}
Налаштування каталогу описано в Як інтегрувати системи клінік із FHIR-бекендом.
Версії: нічого не перезаписується мовчки
Кожне оновлення створює нову версію ресурсу та новий запис Provenance для нього. Після того, як частота серцевих скорочень вище буде виправлена з 92 до 88:
curl https://platform.anpheros.com/fhir/R4/Observation/$OBS/_history -H "Authorization: Bearer $KEY"
повертає версію 2 (88) та версію 1 (92). REST-представлення узагальнює Provenance кожної версії:
curl https://platform.anpheros.com/v1/patients/$PID/provenance/Observation/$OBS -H "Authorization: Bearer $KEY"
{"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}
Видалення є "м'якими": видалений ресурс зникає з результатів пошуку, але його історія та Provenance залишаються.
Читання provenance
# 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}
Походження в контекстах ШІ
API контексту передає походження до кожного елемента, який він надає моделі, як author_type та source. У текстовій формі:
- 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]
Вимірювання, написані за допомогою author_type: ai, ніколи не з'являються серед цих фактів. Вони перелічені окремо під ai_notes і позначені як неперевірені, тому модель не може сплутати здогадку попередньої моделі з вимірюванням. Повідомте моделі, що означають мітки, і попросіть її цитувати їх; Як створити медичний додаток зі штучним інтелектом з бекендом FHIR показує приклад запиту, який це робить.
Що бачить пацієнт
Походження даних також є тим, що бачить пацієнт. У його записі показано, хто додав кожен елемент, а в списку його зв'язків показано, для кожної програми, хто, що і коли отримував доступ, коли практикуючий лікар діяв ("Д-р Ана Попеску · Клініка Кардіо Норд прочитала ваші результати лабораторних досліджень"). Див. Модель згоди та доступу.
Правила, що роблять походження корисним
- Завжди встановлюйте тип автора. Це коштує одного поля і є найважливішою міткою в записі.
- Вказуйте ім'я особи, коли її написала людина. Використовуйте
X-Anpheros-Acting-Asдля клінічного персоналу. - Вказуйте вихідну систему та передавайте власний ідентифікатор вихідної системи як ідентифікатор походження, якщо він є.
- Виправляйте шляхом оновлення, ніколи шляхом видалення та повторного створення. Оновлення зберігає зв'язок між старим і новим значенням.
- Позначайте вивід ШІ як
ai, включаючи значення, витягнуті моделлю з документа. Значення, отримані з документа, також можуть посилатися на нього за допомогоюderived_from.
Часті запитання
Що таке походження даних у сфері охорони здоров'я?
Документований початок та історія медичних даних: хто їх створив або змінив, від чийого імені, з якої системи та коли. У HL7 FHIR це представлено ресурсом Provenance, який вказує на точну версію ресурсу, що він описує.
Чи походження даних те саме, що й журнал аудиту?
Ні. Походження описує дані: хто написав кожну версію. Журнал аудиту описує доступ: хто читав або писав що, коли, за якою згодою. Anpheros зберігає обидва; пацієнт бачить журнал доступу для кожної програми, підключеної до його запису.
Чи можу я писати власні ресурси Provenance?
Anpheros створює один для кожного створення, оновлення та видалення, тому зазвичай ви цього не робите. Використовуйте заголовки вище, щоб зробити його точним. Provenance, наданий клієнтом, повинен націлюватися на ресурси одного пацієнта.
Пов'язані теми
- Модель згоди та доступу
- Як інтегрувати клінічні системи з FHIR бекендом
- Як нормалізувати медичні дані
- Інтероперабельність медичних даних
- Безпека, конфіденційність та місцезнаходження даних
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card