Ресурс FHIR ”Пацієнт”: ідентифікатори, імена, демографічні дані та зв'язки, з дійсним прикладом

Коротка відповідь: Patient — це ресурс FHIR, який описує особу, що отримує медичну допомогу: хто вона з адміністративної точки зору, а не що з нею не так. Він містить ідентифікатори (номери медичних карток, національні посвідчення), імена, контактні дані telecom, адміністративну стать (gender), дату народження (birthDate), адресу (address), сімейний стан (maritalStatus), інформацію про спілкування (мови) (communication), лікаря (generalPractitioner), організацію, що веде пацієнта (managingOrganization) та посилання на інші записи Patient для тієї ж особи. Усі ресурси Observation, Condition, Encounter або MedicationStatement посилаються на нього через subject або patient. Клінічні факти ніколи не зберігаються в Patient; вони знаходяться в ресурсах, які на нього посилаються.

Валідний приклад FHIR R4

Валідний ресурс FHIR R4 Patient потребує лише resourceType, але на практиці містить щонайменше один ідентифікатор із системою та значенням, ім'я з частинами прізвища та імені, адміністративну стать та дату народження. Наведений нижче приклад також заявляє профіль IPS Patient у meta.profile та додає контактні дані, адресу, бажану мову, головного лікаря та організацію, що керує.

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {"profile": ["http://hl7.org/fhir/uv/ips/StructureDefinition/Patient-uv-ips"]},
  "identifier": [{
    "use": "usual",
    "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR"}]},
    "system": "https://hospital.example.org/mrn",
    "value": "MRN-00012345"
  }],
  "active": true,
  "name": [{"use": "official", "family": "Doe", "given": ["Jane", "Marie"], "prefix": ["Ms"]}],
  "telecom": [{"system": "email", "value": "[email protected]", "use": "home"}],
  "gender": "female",
  "birthDate": "1980-05-23",
  "address": [{"use": "home", "line": ["12 High Street"], "city": "Leeds", "postalCode": "LS1 4AB", "country": "GB"}],
  "communication": [{"language": {"coding": [{"system": "urn:ietf:bcp:47", "code": "en-GB"}]}, "preferred": true}],
  "generalPractitioner": [{"reference": "Practitioner/gp-42"}],
  "managingOrganization": {"reference": "Organization/hospital"}
}

Важливі елементи

Елементи Patient, які є найважливішими для сумісності, це: ідентифікатор (із системою, значенням та типом), ім'я (з використанням, прізвищем та ім'ям), адміністративна стать, дата народження, статус смерті, активність, контактні дані та зв'язок. Ідентифікатори та імена визначають відповідність між системами, стать та дата народження є адміністративними фактами, а зв'язок записує, як головний індекс пацієнтів пов'язав дублікати записів однієї особи.

• identifier — це список, кожен елемент якого містить system (хто видав) та value. Поле type вказує, що це за ідентифікатор: MR — номер медичної картки, NI — національний ідентифікатор, PPN — паспорт, SS — номер соціального страхування, згідно з таблицею HL7 0203. Зазвичай пацієнт має кілька ідентифікаторів; номер медичної картки лікарні та національний ідентифікатор є дійсними, і системи зіставляють їх.
• name — це також список з полем use: official (офіційне), usual (звичайне), nickname (прізвисько), maiden (дівоче), old (старе). family — це один рядок; given — це список. Скрипти, транслітерації та порядок імен залишаються на розсуд керівництва з впровадження країни.
• gender — це адміністративна стать із чотирма значеннями: male (чоловіча), female (жіноча), other (інша), unknown (невідома). Це те, що зазначено в записі, і використовується для зіставлення та заповнення форм. Клінічна стать, гендерна ідентичність та займенники вказуються в розширеннях (extensions) або в ресурсах Observation, що було формалізовано в FHIR R5 та проєкті Gender Harmony.
• birthDate — це дата, опціонально тільки рік або рік-місяць, коли точна дата невідома. Розширення patient-birthTime додає час народження для новонароджених.
• deceased[x] — це булеве значення або дата-час. Значення active false позначає запис, який більше не повинен використовуватися (дублікат, переміщено), без його видалення.
• contact — список осіб для зв'язку (найближчі родичі, опікуни) з кодом відношення; самі по собі вони не є ресурсами Patient. Батько, який також є пацієнтом, є RelatedPerson, що посилається на обох.
• link — з'єднує записи Patient, що стосуються однієї особи: replaced-by та replaces після об'єднання, refer — посилання на авторитетний запис, seealso — посилання на запис в іншій системі. Саме так майстер-індекс пацієнтів висловлює свої рішення у FHIR; див. Зіставлення пацієнтів.

Що додають національні профілі

Національні та міжнародні профілі FHIR перетворюють нечітко визначений базовий ресурс Patient на щось придатне для використання, роблячи елементи обов'язковими та додаючи розширення, специфічні для країни. US Core вимагає ідентифікатор, ім'я та стать, а також додає розширення раси, етнічної приналежності та статі при народженні; профіль IPS Patient вимагає ім'я, стать та дату народження; національні профілі визначають системи ідентифікаторів та формати адрес.

Базовий ресурс робить майже все необов'язковим. Профілі роблять його придатним для використання:

Запис, який буде перетинати кордон, повинен відповідати профілю з обох сторін, що на практиці означає наявність як національного ідентифікатора, так і MRN, повного офіційного імені та повної дати народження. Див. Керівництва з впровадження FHIR.

Операції, які ви будете використовувати

Операції FHIR, які найчастіше використовуються з Patient, це пошук за ідентифікатором або демографічними даними (GET /Patient з параметрами ідентифікатора, прізвища або дати народження), операція $everything, яка повертає пацієнта та всі ресурси, що посилаються на нього, та $match, яка запитує алгоритм відповідності сервера щодо ймовірних дублікатів. Операція $merge стандартизується у FHIR R5.

• GET /Patient?identifier=https://hospital.example.org/mrn|MRN-00012345 знаходить пацієнта за ідентифікатором; ?family=doe&birthdate=1980-05-23 — за демографічними даними.
• GET /Patient/{id}/$everything повертає пацієнта та всі ресурси, що на нього посилаються, з розбивкою на сторінки; це спосіб експорту повного запису.
• $match (де підтримується) запитує алгоритм зіставлення сервера щодо ймовірних дублікатів; $merge стандартизується в R5.

Помилки, що псують записи пацієнтів

Помилки, які найчастіше псують записи FHIR Patient, це: зберігання національного посвідчення особи в resource id замість identifier, пропуск identifier.system, через що значення з різних лікарень конфліктують, введення повного імені в text без частин прізвища та імені, використання адміністративної статі замість клінічної статі, а також редагування об'єднаного запису на місці замість його зв'язування та деактивації.

• Розміщення національного посвідчення в id. id ресурсу належить серверу і може змінюватися під час імпорту; ідентифікатори належать до identifier.
• Один name з усім текстом у полі text і без family/given, що призводить до збоїв у пошуку за прізвищем.
• Використання gender для клінічної статі або встановлення значення unknown, оскільки в формі не було відповідного поля.
• Відсутність identifier.system, що призводить до конфлікту значень MRN-1 від двох лікарень.
• Редагування Patient на місці після об'єднання замість посилання та деактивації.

В Anpheros

Anpheros представляє кожну особу, власника облікового запису та кожен сімейний профіль як ресурс FHIR Patient на платформі Anpheros, і кожен запис, який клініка додає через API, посилається на цього Patient. Ідентифікатори клінік зберігаються як додаткові ідентифікатори з власною системою клініки, а демографічні дані, які вводить особа, залишаються адміністративними даними, з яких не робиться жодних клінічних висновків.

Коли клініка надсилає власний ідентифікатор, він зберігається як додатковий identifier із системою клініки, щоб ту саму особу можна було знайти з будь-якого боку. Демографічні дані, які особа ввела в додаток, є usual ім'ям та адміністративними даними; запис ніколи не робить з них жодних клінічних висновків.

Пов'язані сторінки

• Зіставлення пацієнтів та майстер-індекс пацієнтів
• Керівництва з впровадження FHIR
• FHIR Encounter пояснено
• FHIR Condition пояснено
• Пошук FHIR пояснено
• Приклад Patient на сайті для розробників

Джерела

• HL7 FHIR R4: Patient
• HL7 FHIR R4: Patient $everything
• HL7 Terminology: identifier type codes (v2-0203)
• HL7 US Core: Patient profile
• HL7 IPS: Patient profile

Поширені запитання

Чи Patient те саме, що Person у FHIR?

Ні. Person — це адміністративний ресурс, який пов'язує одну й ту саму людину в різних ролях (тут Пацієнт, там Практикуючий лікар, деінде Пов'язана особа). Клінічні ресурси посилаються на Patient, а не на Person.

Де зберігаються алергії та стани?

У ресурсах AllergyIntolerance та Condition, які посилаються на Patient. Сам Patient містить лише адміністративні дані.

Як записати новонародженого без імені?

З іменем, використання якого є temporary (тимчасове) або порожнім, birthDate з розширенням patient-birthTime, та link до запису матері через RelatedPerson або розширення patient-mothersMaidenName, як це передбачено національними профілями.

Чи може один ресурс Patient використовуватися двома лікарнями?

Кожна система зберігає власний ресурс Patient зі своїм id; вони діляться ідентифікаторами (національний ID) і можуть пов'язувати записи. Зіставлення між системами — це завдання майстер-індексу пацієнтів, а не ресурсу.

Anpheros Platform

Спробуйте безкоштовно в пісочниці

Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.

Створити безкоштовну пісочницюЧитати посібники для розробників →

Безкоштовно · 30 синтетичних пацієнтів · без картки

Написано

Команда Anpheros

Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.

Про Anpheros →