Модель даних: Preperson Data Model

У разівиключних ситуаціях, якщо коли медичний персонал не має можливості ідентифікувати персону пацієнта до подання медичних даних у ЦК (наприклад, пацієнт без свідомості або за якихось причин не може назвати свої персональні дані), у ЦК повинна бути заведена картка неідентифікованої персонинеідентифікована персона:

• для забезпечення можливості передачі та відстеження медичних даних такого пацієнта

• для можливості приєднання медичних даних такого пацієнта до запису ідентифікованої персони коли персональні дані неідентифікованого пацієнта будуть однозначно та точно визначені

...

Для неідентифікованих персон діють наступні правила та обмеження стосовно операцій у ЦК відносно правил, існуючих для ідентифікованих персон:

...

Створення неідентифікованої персони

1. Право створення

...

1. неідентифікованої персони мають працівники із типами SPECIALIST, ASSISTANT, RECEPTIONIST у медичних закладах із типами OUTPATIENT та EMERGENCY які мають один чи декілька видів медичних послуг (HealthCare Services) для стаціонарних умов надання за визначеним переліком спеціалізацій (перелік спеціалізацій визначається конфігурацією).

2. Для створення

...

1. неідентифікованої персони, користувач повинен передати до ЦК

...

1. внутрішній ідентифікатор такої персони, за яким він ідентифікується у медичному закладі. Внутрішній ідентифікатор формується за логікою ЄДРПОУ МІС.ЄДРПОУ ЗОЗ.Цифровий ідентифікатор ЗОЗ. Додатково можуть бути переданими відомі користувачеві персональні дані такої персони: стать, прізвище, ім'я, по-батькові, дата народження, контакт для екстреного зв'язку, інформація про законного представника.

2. Після створення для неідентифікованої персони повинен бути переданий мінімальний набір медичних даних

...

1. , а саме спостережень стосовно стану, особливих прикмет неідентифікованої персони (наявність татуювання,

...

1. відсутність зубів, приблизний вік та інші прикмети)

...

TBD

...

1. для забезпечення альтернативної ідентифікації персони.

   1. Перелік та вимоги до надання таких спостережень визначено у розділі “Подання медичних даних для альтернативної ідентифікації персони”

   2. Такі дані неідентифікованого пацієнта повинні бути поданими протягом відведеного на це часу. У разі їх відсутності неідентифікована персона автоматично деактивується процесом Auto termination of preperson

2. Створення неідентифікованої персони не потребує накладення ЕЦП та

...

1. виконується без пошуку дублікатів у ЦК.

API: TBD : Create Preperson

Подання медичних даних для альтернативної ідентифікації персони

Медичні дані для альтернативної ідентифікації надаються у пакеті медичних даних із взаємодією типу “Альтернативна ідентифікація пацієнта” (patient_identity), для якого діють наступні правила та обмеження:

1. Для взаємодії (Encounter):

   1. Повинні бути вказані обов'язкові параметри:

      1. статус

      2. дата

      3. візит

      4. епізод МД

      5. клас

      6. тип

      7. виконавець

      8. Основний діагноз. Система кодів діагнозів визначається класом взаємодії.

   2. Можливе, але не обов'язкове, вказання дій-посилань на послуги або дій за ICPC2 в залежності від класу взаємодії.

   3. Можливе, але не обов'язкове, вказання причин звернення незалежно від класу взаємодії.

   4. За умови можливості вказання даних про госпіталізацію для класу взаємодії, можливе, але не обов'язкове, подання таких даних.

   5. Можливе, але не обов'язкове вказання інших загально необов'язкових параметрів.

2. Для спостережень (Observations)

   1. Обов'язкова наявність всіх спостережень, зазначених як обов'язкові, у розділі “Перелік спостережень”

   2. Можлива наявність тільки наведених у розділі “Перелік спостережень” кодів

3. Для інших об'єктів

   1. Можлива, але не обов'язкова наявність даних. Діють загальні умови подання.

Перелік спостережень

Довідники та вимоги до подання значень спостережень наведені на сторінці Medical Events Dictionaries and configurations - Observations

Offline дедублікація

Offline дедублікація карток неідентифікованих персон не виконується.

Пошук та отримання даних картки неідентифікованої персони

Для отримання даних картки неідентифікованої персони необхідно використовувати її ідентифікатор у ЦК або зовнішній ідентифікатор, за яким така персона ідентифікується у медичному закладі.

API: API. Get Prepersons , API. Get

Отримання даних неідентифікованої персони

1. Отримання даних неідентифікованої персони виконується за її ідентифікатором.

2. Право отримання даних неідентифікованої персони мають працівники із типами SPECIALIST, ASSISTANT, RECEPTIONIST у медичних закладах із типами OUTPATIENT та EMERGENCY

API: Get Preperson by ID

Оновлення

...

неідентифікованої персони

1. Для

...

1. неідентифікованої персони

...

1. можуть бути зміненими чи доповненими будь-які персональні дані, включаючи зовнішній ідентифікатор.

   1. При оновленні дати смерті, оновлений запис автоматично деактивується. Ця дія незворотня.

2. Право оновлення мають працівники із типами SPECIALIST, ASSISTANT, RECEPTIONIST у медичних закладах із типами OUTPATIENT та EMERGENCY які мають один чи декілька видів медичних послуг (HealthCare Services) для стаціонарних умов надання за визначеним переліком спеціалізацій (перелік спеціалізацій визначається конфігурацією).

3. Оновити дані

...

1. неідентифікованої персони може будь-який медичний заклад, якому відомий ідентифікатор такої

...

1. персони у ЦК (наприклад, ідентифікатор буде отриманий при трансфері неідентифікованої персони із одного медичного закладу в інший).

API: API. Update Preperson

...

Деактивація неідентифікованої персони

...

У разі, якщо персону пацієнта ідентифіковано, та картка неідентифікованої персони вже створена і містить дані, необхідно виконати наступні дії:

...

Крок

...

Опис

...

Ідентифікація та пошук пацієнта

...

Виконати пошук пацієнта за наявними персональними даними

...

Створення пацієнта

...

Якщо пацієнта не знайдено, необхідно створити нового пацієнта виконуючи дії процесу Створення пацієнта

...

Запит на зв'язуванння пацієнта із карткою неідентифікованої персони

...

Після того, як пацієнта знайдено або створено, необхідно виконати запит на зв'язуванння пацієнта із карткою неідентифікованої персони. В результаті виконання запиту:

• Створюється запит на зв'язування пацієнта та картки неідентифікованої персони

• Пацієнту, якщо він має за замовчанням електронний метод аутентифікації, надсилається SMS повідомлення, метою якого є:

  • впевнитися, що картка неідентифікованої персони додається до коректно обраного пацієнта

  • отримати від пацієнта згоду на приєднання картки неідентифікованої персони

• Користувач отримує маскований номер телефону, на який було відправлене повідомленння, та перелік наявних у пацієнта методів аутентифікації із аліасами

API: TBD

...

Надіслати повідомлення для підтверждення дії

...

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

API: TBD

...

Підтвердити зв'язування за допомогою SMS-коду або документів

...

Користувач повинен підтвердити дію зв'язування пацієнта та картки неідентифікованої персони за допомогою коду, який міститься у повідомленні, або за допомогою документів пацієнта.

API: TBD

У разі, якщо код не коректний, або підтвердження запиту надійшло пізніше відведеного ліміту часу, такий запит анулюється.

Деактивація картки неідентифікованої персони

...

Деактивація неідентифікованої персони виконується автоматично за відсутності медичних даних, пов'язаних із такою персоною, протягом часу визначеним конфігураційним параметром DAYS_FOR_PREPERSON_VERIFICATION