ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

1. Структура моделі даних сутностей у побудові циклу індивідуального реабілітаційного плана 

1.1 Загальна схема

1.2 Сутність Episode

1.2.1 Модель даних

Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence.

FHIR v.4.3

Name in ESOZ

Type

M/O

Опис

Правило заповнення / Нотатки

“identifier”: {Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

“name”:{} // Human readable name of the episode

name

string

M

Human readable - найменування епізоду

вручну користувачем

“status”: {code} // active | closed | entered-in-error

status

string

M

Статус епізоду

вручну користувачем при запиті на створення (active), автоматично при закритті (closed), або скасуванні (entered_in_error)

eHealth/episode_statuses

“status_reason”:{} // Reason for ending or canceling the episode

status_reason

codeable_concept

O

Причина завершення або відміни епізоду

вручну користувачем при закритті, або скасуванні

eHealth/closing_reasons,eHealth/cancellation_reasons

“explanatory_letter”:{} // Description of the current episode of rehabilitation

explanatory_letter

string

O

Опис причини завершення або відміни поточного епізоду реабілітації

вручну користувачем при скасуванні

“closing_summary”:{} // A description of the closure of the current rehabilitation episode

closing_summary

string

O

Опис закриття поточного епізоду реабілітації 

вручну користувачем при скасуванні

"statusHistory" : {BackboneElement } //History of episode statuses

status_history

[status_history]

M

Історія статусів епізоду

формується автоматично при змінах статусів

“type”: { CodeableConcept} // specialist referral | disease management | …

type

CodeableConcept

M

тип епізоду - REHAB 

вручну користувачем з довідника eHealth/episode_types

“current_diagnoses”:{} //  diagnoses ( [ICD10_AM]) 

current_diagnoses

[diagnoses]

M

Діагнози  ([ICD10_AM]) 

автоматично при фіксації користувачем взаємодії з блоком diagnoses

“diagnoses”:[{Reference(diagnoses)}] //The list of diagnoses relevant to this episode of care

diagnoses_history

[diagnoses_hstr]

M

Включено всі діагнози з поточного етапу (current_diagnoses) і всі діагнози з попередніх етапів

автоматично 

“managingOrganisation”: {Reference(Organization)} // Organization that assumes care

managingOrganisation

Reference (organization)

Установа, в межах якої зроблено епізод

автоматично 

“period”: {Period} // Interval during responsibility is assumed

period

Period

Інтервал надання реабілітаційної допомоги

вручну користувачем

«careManager» : {Reference(Practitioner)}, // Care manager/care coordinator for the patient

careManager

Reference (employee)

M

Лікар ФРМ

вручну користувачем

1.2.2 Модель статусів сутності Episode active | closed | entered-in-error

Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус

1

active

Діючий

встановлюється вручну користувачем у запиті create-episode

Ні

2

closed

Завершений

встановлюється автоматично Системою при успішному виконанні запиту close-episode

Так

3

entered-in-error

Внесений помилково

встановлюється автоматично Системою при успішному виконанні запиту cancel-episode

Так

Малюнок 1. Схема переходу між статусами

1.3 Сутність Encounter 

1.3.1 Модель даних

Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence.

FHIR v.4.3

Name

type

M/O

Опис

Правило заповнення

“Identifier”:{Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

«status» : {code} // entered-in-error | finished

status

string

M

Статус взаємодії. Виходимо з концепції фіксації взаємодії по факту її завершення.

вручну користувачем при запитах на створення (finished), скасування (entered_in_error)

eHealth/encounter_statuses

«period» //The start and end time of the encounter

period

Period

M

Період, в який проведено взаємодію

вручну користувачем при запиті на створення 

«class» : {Coding}, // inpatient | outpatient | ambulatory 

class

code

M

Клас взаємодії 

вручну користувачем при запиті на створення 

eHealth/encounter_classes

«type» : {CodeableConcept}, // Specific type of encounter

type

CodeableConcept

M

Тип взаємодії 

вручну користувачем при запиті на створення 

eHealth/encounter_types

«priority» : {CodeableConcept}, // Indicates the urgency of the encounter

priority

CodeableConcept

O

Пріоритет за взаємодією 

вручну користувачем при запиті на створення 

eHealth/encounter_priority

«episodeOfCare» : { Reference (EpisodeOfCare) }, // Episode of care that this encounter should be recorded against

episode

Reference (EpisodeOfCare)

M

Епізод реабілітаційного процесу

вручну користувачем при запиті на створення

“visit”:{Reference(visit)} // UA-eHealth original entity

visit

Reference(visit)

M

Візит (технічна обов’язкова сутність) 

автоматично з боку МІС (технічна сутність)

“performer”:{Reference(Employee)} // Reference(Employee) = FRM | Specialist

 

performer

Reference(Employee)

M

Виконавець

автоматично з боку МІС. Зазначається ідентифікатор автора взаємодії. (Лікар ФРМ, фахівець з реабілітації)

“diagnoses”:[ICD10_AM] //The list of diagnoses relevant to this encounter

diagnoses

[Diagnosis]

O

Включено всі діагнози  [ICD10_AM] поточного Encounter

вручну користувачем

“prescriptions”:{string} // Field to store prescriptions and recommendations made by the doctor during the encounter

prescriptions

string

O

Текстовий опис або коментарі лікаря щодо сутностей поточногої взаємодії

вручну користувачем

 

«supporting_info» : [{Reference(Observation|Diagnostic_report | Condition) }], // The patient’s main care process conditions

supporting_info

[Reference (Observation|Diagnostic_report | Condition) ]

O

Посилання на пов’язану інформацію

вручну користувачем

“explanatory_letter”:{string} // A description of the current interaction

explanatory_letter

string

O

Текстовий опис причини відміни поточної взаємодії 

вручну користувачем при запиті на скасування 

«cancellation_reason» : {CodeableConcept} // Another Encounter this encounter is part of

cancellation_reason

CodeableConcept

O/M

Кодування причини відміни взаємодії

вручну користувачем при запиті на скасування 

eHealth/cancellation_reasons

1.3.2 Модель статусів сутності Encounter entered-in-error | finished

Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус

1

finished

Завершений

встановлюється автоматично Системою при успішному виконанні запиту submit-encounter-package

Ні

2

entered-in-error

Внесений помилково

встановлюється автоматично Системою при успішному виконанні запиту cancel-encounter-package

Так

Малюнок 2. Схема переходу між статусами

1.4 Сутність Observation

1.4.1 Модель даних


Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence.

FHIR v.4.3

Name

type

M/O

Опис

Правило заповнення

“identifier”: {Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

«status» : {code} // valid| entered-in-error 

status

string

M

Статус обстеження

автоматично при запитах на створення (valid, скасування (entered_in_error)

eHealth/observation_statuses

“category”: {CodeableConcept} // exam | survey | vital-signs // Classification of observation service

categories

CodeableConcept

Класифікація обстеження

Для реабілітації: default = survey

Автоматично eHealth/observation_categories 

“code”: {CodeableConcept} MKF code

code

CodeableConcept

M

Код з довідника МКФ = НК 030-2022 Класиф функціонування та обмеження

вручну користувачем

НОВИЙ довідник eHealth/ICF/observation_codes 

“value”: {ValueCodeableConcept}  MKF qualifier

value

CodeableConcept

M

Значення кваліфікатора з довідника МКФ = НК 030-2022 Класиф функц та обмеження (оцінка фахівця)

вручну користувачем

НОВИЙ довідник eHealth/ICF/qualifier

"context" : { Reference(Encounter) }, // Encounter which observation belong to

context

Reference (Encounter)

Пов'язана взаємодія — Encounter data package поточного обстеження

автоматично МІС в запиті на створення

“effectiveDateTime”: {dateTime} // When the observation was performed

performed_DateTime

dateTime

Коли відбулося обслуговування 

вручну користувачем 

“issued”: {dateTime} // When the observation was made available

issued

dateTime

Коли обстеження стало доступно

автоматично МІС в запиті на створення

“primary_source”: {boolean} // true | false

primary_source

boolean

M

Статус першоджерела інформації

вручну користувачем

“performer”: {Reference(Employee)} // 

performer

Reference (Employee)

M

Виконавець обстеження

автоматично МІС, або вручну користувачем (якщо виконавцем є інший фахівець цього закладу)

"note" : [{ Annotation }] //Additional information on methods of determining the patient's condition 

comment

[string]

O

Опис (масив) методів визначення стану відповідно вимогам ведення НК 030-2022 + Додаткова інформація

вручну користувачем

1.4.2 Модель статусів сутності Observation entered-in-error | finished

Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус

1

finished

Завершений

встановлюється автоматично Системою при успішному виконанні запиту submit-encounter-package

Ні

2

entered-in-error

Внесений помилково

встановлюється автоматично Системою при успішному виконанні запиту cancel-encounter-package

Так

Малюнок 3. Схема переходу між статусами

1.5 Сутність Care Plan

1.5.1 Модель даних


Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence

FHIR v.4.3

Name

type

M/O

Опис

Правило заповнення

“identifier”: {Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

“based_on”: {Reference(CarePlan)} // Reference on parent Care plan

based_on

Reference(CarePlan)

O

Посилання на первинний / попередній План лікування

вручну користувачем

“category”: {CodeableConcept} // Category of the care plan

category

CodeableConcept

M

Категорія Плану лікування: нові значення - “Реабілітація у гострому періоді”;

вручну користувачем

ehealth/care_plan_categories 

“title”: {string} // Human readable title

title

string

M

Заголовок Плану лікування

вручну користувачем

“description”: {string} // Description of the care plan

description

string

O

Опис Плану лікування

вручну користувачем

“period”: {period} // Period when care plan starts and ends

period

period

M

Період дії Плану лікування 

вручну користувачем

“supporting_info”:[{Reference(Any)}] // Reference on supporting medical events

supporting_info

[Reference(Any)]

O

Посилання на попередні медичні записи

вручну користувачем

“note”:{string} // Comments about the plan, [ISO 9999] as needed

note

string

O

Коментарі, в т.ч. примітки по використанню допоміжних засобів згідно класифікації довідника ISO 9999

вручну користувачем із можливістю доповнення значеннями з eHealth/ISO_9999

“managingOrganisation”: {Reference(Legal Entity)} // Where the procedure happened

managing_Organization

Reference (Legal Entity)

М

Організація (юридична особа), яка несе відповідальність за поточний план лікування

автоматично

“Intent”: {string} // By default is order

intent

string

M

По-замовчуванню - order/ CarePlan вноситься по факту отриманої згоди на надання реабілітаційної допомоги

вручну користувачем, або автоматично МІС

 

“encounter”: { Reference(Encounter) } // Reference on encounter

encounter

Reference (Encounter)

M

Посилання на взаємодію лікаря ФРМ, за якою створюється Care Plan

автоматично

“addresses”: [{ CodeableConcept}] // Diagnose [ICD10_AM]

addresses

[CodeableConcept]

M

Діагнози поточного циклу реабілітаційної допомоги

автоматично

«status» : {code} // new | active | completed | cancelled | terminated

status

string

M

Статус Плану лікування

автоматично Системою в залежності від ендпоінту.

“status_reason”:{CodeableConcept} // Reason for ending or canceling

status_reason

CodeableConcept

O

Причина завершення або відміни Плану лікування

вручну користувачем eHealth/care_plan_complete_reasons, eHealth/cancellation_reasons

"statusHistory" : {BackboneElement } // History of care plan statuses

status_history

[status_history]

M

Історія статусів Плану лікування

автоматично

“author”:{Reference(Employee)} // Who authored the content

author

Reference(Employee)

M

Посилання на співробітника, який створив План лікування

автоматично

“terms_of_service”: {CodeableConcept} // Providing condition of care plan

terms_of_service

CodeableConcept

M

Умови супроводження плану лікування. 

вручну користувачем,dictionaries?name= PROVIDING_CONDITION

1.5.2 Модель статусів сутності Care Plan new | active | completed | cancelled | terminated

Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус

1

new

новий

Встановлюється при створенні плану лікування. Автор ще не отримав схвалення від пацієнта.

Ні

2

active

активний

Встановлюється автоматично після створення активності для плану лікування. Статус описує, що цей план лікування діє зараз, тому інші плани лікування для цього пацієнта з таким самим діагнозом (атрибут addresses) повинні бути припинені. Автор має дозвіл на роботу з планом догляду.

Ні

3

completed

виконаний

Фінальний статус, встановлюється вручну. Говорить про те, що план лікування був успішно завершений.

Так

4

cancelled

скасований

Фінальний статус. Встановлюється вручну у випадку, коли план лікування був відхилений з будь-якої причини або по плану лікування була отримана помилка (відповідна причина помилки повинна бути отримана)

Так

5

terminated

припинений

Фінальний статус. Встановлюється автоматично, коли створено новий  активний план лікування з тими ж діагнозами (атрибут addresses).

Так

Малюнок 4. Схема переходу між статусами

1.6 Сутність Activity 

1.6.1 Модель даних

Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence

FHIR v.4.3

Name

type

M/O

Опис

Правило заповнення

“identifier”: {Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

“care_plan”: {Reference(Care_plan)} // Reference on the Care plan to which activity has been related

care_plan

Reference(Care_plan)

M

Посилання на План лікування, з яким пов'язана активність.

передається МІС в запиті на створення, формат UUID

“author”:{Reference(Employee)} // Who authored the content

author

Reference(Employee)

M

Посилання на співробітника, який створив активність

передається МІС в запиті на створення

“outcomeReference”:[{Reference (Encounter | Procedure )}] // Reference on resources which represents result of the activity

outcome_Reference

[Reference( Encounter | Procedure )] 

O

Посилання на ресурси, які відобразять результат активності

Посилання на ресурси, які відобразять результат активності (атрибут outcome_Reference), заповнюються автоматично під час створення цих сутностей (Procedure)

outcomeCodeableConcept”: {CodeableConcept} // Descriptions of the activity result

outcome_Codeable_Concept

CodeableConcept

Опис результату активності

Обирається вручну користувачем з довідникаeHealth/care_plan_activity_outcomes Передається під час запитів complete-care-plan-activity та cancel-care-plan-activity

“kind”: {string} // MedicationRequest | ServiceRequest | DeviceRequest 

kind

string

M

Тип активності

вручну користувачем, передається у запиті на створення

 

“reasonCode”: [{CodeableConcept}] // Diagnose [ICD10_AM]

reason_Code

[CodeableConcept]

Діагнози поточного циклу реабілітаційної допомоги

вручну користувачем

“reasonReference”: [{Reference(Observation)}] // Observations with MKF codes + qualifiers 

reason_Reference

[Reference(Observation)]

Посилання на реабілітаційні обстеження в рамках епізоду реабілітації

вручну користувачем 

“goal”: {CodeableConcept} // A goal of the activity. 

code

CodeableConcept

Ціль активності. Значення вибирається з довідника. Default ==patient_maintaince: "Підтримка стану пацієнта"

вручну користувачем eHealth/care_plan_activity_goals

“status”: code // scheduled | in-progress | completed | cancelled

status

string

M

Статус активності

передається МІС у запиті на створенні із значенням scheduled, змінюється автоматично по інших запитах АРІ

“status_reason”: {CodeableConcept} // Reason for current status 

status_reason

CodeableConcept

O

Причина завершення або відміни активності. Значення вибирається з довідника.

вручну користувачем eHealth/care_plan_activity_complete_reasons eHealth/care_plan_activity_cancel_reasons

“quantity”: {SimpleQuantity} // How long to run (in minutes)

quantity

SimpleQuantity

M

Кількість необхідного часу на реабілітаційні процедури 

вручну користувачем

“scheduledPeriod”: {Period} // When activity is to occur

scheduled_Period

Period

O

Опис запланованого періоду активності

вручну користувачем

“location”: {Reference(Location)} // Where it should happen

location

Reference(Location)

O

Посилання на підрозділ виконавця

вручну користувачем

“performer”: [{Reference(Employee | CareTeam)}] // Reference on employee who will perform the activity.

performer

[Reference(Employee | CareTeam)]

O

Посилання на співробітника, який виконує активність.

Не використовується для MVP реабілітації. На майбутне планується використання із сутністю CareTeam

“productReference”: {Reference(Service)} // What will be administered

product_Reference

Reference(Service Group | Service Code)

M

Посилання на Сервіс, що підлягає виконанню

вручну користувачем

eHealth/services 

“dailyAmount”: {SimpleQuantity} // Quantity of medication, procedures to be consumed a day (in minutes)

daily_Amount

SimpleQuantity

O

Кількість процедур, які повинні надаватися за день, у хвилинах

вручну користувачем

“description”: {string} // Text description of the activity

description

string 

O

Опис активності

вручну користувачем

“program”: {Reference(Program)} // What will be administered

program

Reference(Program)

O

Посилання на Программу Медичної Допомоги

вручну користувачем

“remaining_quantity”: {SimpleQuantity} // Quantity of procedures allowed to Service Request (in minutes)

remaining_quantity

SimpleQuantity

O

Залишок кількості часу на процедури. Він обчислюється як різниця між quantity і кількістю відповідних запланованих процедур

автоматично при створенні сутностей Service Request на підставі поточної активності

1.6.2 Модель статусів сутності Activity scheduled | in-progress | completed | cancelled

Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус?

1

scheduled

запланований

Встановлюється автоматично по-замовчуванню при створенні активності.

Ні

2

in-progress

в процесі

Встановлюється автоматично, коли перший результат активності був заданий (перший outcome_reference).

Ні

3

completed

виконаний

Фінальний статус. Встановлюється вручну по рішенню лікаря.

Так

4

cancelled

скасований

Фінальний статус. Встановлюється вручну, коли по активністі отримана помилка або активність більше не актуальна (відповідна причина помилки повинна бути отримана).

Так

Малюнок 5. Схема переходу між статусами

1.7 Сутність ServiceRequest 

1.7.1 Модель даних

Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence

FHIR v.4.3

Name

type

M/O

Опис

Правило заповнення

“identifier”: {Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

“basedOn”: {Reference(CarePlan + Activity)} // What request fulfills

based_On

Reference(CarePlan + Activity)

O

План/активність що виконується цим запитом.

вручну користувачем або автоматично МІС (при обраному користувачем CarePlan  та активності)

“requisition”: {Identifier} // Composite Request ID (Human Readable)

requisition

string

M

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

автоматично

“status”: code // active | completed | entered-in-error | recalled

status

string

M

Статус запита

передається значення “active” при запиті на створення

“status_reason”: {CodeableConcept} // Reason for current status 

status_reason

CodeableConcept

M

Причина завершення або відміни запита

вручну користувачем при скасуванні, або відкликанні 

“status_history”: [{status_history}] // History of care service request statuses 

status_history

[status_history] 

M

Історія статусів запита

автоматично формується Системою 

“explanatory_letter”: {string} // Closing description

explanatory_letter

string 

Опис причини завершення або відміни поточного запиту

вручну користувачем при скасуванні, або відкликанні

“Intent”: {code} // Whether the request is a proposal, plan, an original order = order - always !

intent

string

M

намір (характер обов'язковості направлення). Значення за замовчуванням = order

автоматично 

“priority”: {string} // routine | urgent 

priority

string

M

Пріоритет виконання запиту. Значення за замовчуванням = routine

вручну користувачем SERVICE_REQUEST_PRIORITY

“category”: {CodeableConcept} // Classification of service

procedure | rehabilitation

category

CodeableConcept

Класифікація запиту — процедури у  Стаціонарі / Амбулаторна Реабілітація

автоматично eHealth/SNOMED/service_request_categories 

“code”: {CodeableConcept} // What is being requested/ordered = (Service | ServiceGroup code - may be group)

code

CodeableConcept

Код запиту на сервіс / групу сервісів відповідного напрямку реабілітації

вручну користувачем

eHealth/services 

“context”: {Reference(Encounter)} // Encounter during which request was created

context

Reference(Encounter) 

M

Encounter, відповідно до якого якого було створено запит

вручну користувачем, при запиті на створення

“occurrenceDateTime”: {dateTime} // When service should occur = One of: dateTime or Period

 “occurrenceDatePeriod”: {Period} // When service should occur

occurrence_DateTime

dateTime

Коли має відбуватися обслуговування (Обов’язкове одне з: дата/час або період)

вручну користувачем 

occurrence_DatePeriod

Period

Коли має відбуватися обслуговування (Обов’язкове одне з: дата/час або період)

вручну користувачем 

“requesterEmployee”: {Reference(Employee)} // Who initiated the request and has responsibility for its activation

requester_Employee

Reference(Employee)

M

Хто ініціював запит і несе відповідальність за його активацію

автоматично з боку МІС при запиті на створення

“requesterLegalEntity”: {Reference(Legal_entity)} // Organisation for service providing

requester_Legal_Entity

Reference(Legal_entity)

M

Організація, де виконується запит 

автоматично з боку МІС при запиті на створення

“performerType”: {CodeableConcept} // 

performer_Type

CodeableConcept

Спеціальність виконавця

Speciality type - Performer role - CareTeam using only ???

Не використовується для MVP реабілітації.  На майбутне планується використання із сутністю CareTeam

“performer”: {Reference(Employee)} // 

performer

Reference(Employee)

Виконавець запиту 

Employee - CareTeam using only ???

  Не використовується для MVP реабілітації. На майбутне планується використання із сутністю CareTeam

“reasonReference”: [{Reference(Observation)}] // 

reason_Reference

[Reference(Observation)]

Посилання нареабілітаційні обстеження в рамках епізоду реабілітації

вручну користувачем, або автоматично з боку МІС із вибором діагнозу з activity.reason_reference

“supportingInfo”: [{Reference(Any)}] // Additional clinical information 

supporting_Info

[Reference(Any)]

Посилання на попередні медичні записи

вручну користувачем

“note”: {string} // Comments, notes about Service Request

note

string 

Додаткова інформація по замовленому сервису

вручну користувачем 

“patientInstruction”: {string} // Comments for Performer / Patient

patient_Instruction

string 

Рекомендації пацієнту

вручну користувачем 

“program”: {Reference(Medical Program)} // What will be administered

program

Reference(Medical Program)

O

Посилання на Программу Медичної Допомоги

вручну користувачем

“quantity”: {SimpleQuantity} // Quantity of procedures, encounters or diagnostic_reports  = NEW field !

quantity

SimpleQuantity

Запланований об’єм реабілітаційної послуги поточного запиту

вручну користувачем 

“remaining_quantity”: {SimpleQuantity} // Remaining Quantity of procedures, encounters etc = NEW field !

remaining_quantity

SimpleQuantity

Залишок кількості реабілітаційної послуги поточного запиту

Автоматично, під час реєстрації виконання послуг 

1.7.2 Модель статусів сутності Service Request active | completed | entered-in-error | recalled

Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус?

1

active

активний

Підписаний і активний сервісний запит

ні

2

completed

виконаний

Запит на послугу успішно виконаний 

так

3

entered_in_error

введений помилково

Запит на послугу скасовано через людську помилку в процесі створення

так

4

recalled

відкликаний

Запит на обслуговування відкликано через відсутність необхідності/автоматичний термін дії та інші причини (наприклад, шахрайство)

так

Малюнок 6. Схема переходу між статусами

1.8 Сутність Procedure

1.8.1 Модель даних


Поточний повний опис моделі даних в ЕСОЗ надано на сторінці Confluence.

FHIR v.4.3

Name

type

M/O

Опис

Правило заповнення

“identifier”: {Identifier} // Unique identifier

id

uuid

M

Системний Ідентифікатор

передається МІС в запиті на створення, формат UUID 

“basedOn”: {ServiceRequest)} // A request for this procedure

based_On

Reference(ServiceRequest)

O

Запит, що виконується цією процедурою

вручну користувачем, передається в запиті на створення

“status”: code // completed | entered-in-error 

status

string

M

Статус процедури

передається значення “COMPLETED” в запиті на створення

eHealth/procedure_statuses

“status_reason”: {CodeableConcept} // Reason for current status 

status_reason

CodeableConcept

O

Причина завершення або відміни процедури

вручну користувачем при запиті на скасування 

eHealth/procedure_status_reasons

“explanatory_letter”: {string} // Procedure test description = 

explanatory_letter

string 

Опис причини завершення або відміни поточного процедури mandatory for enterred_in_error

вручну користувачем при запиті на скасування 

“category”: {CodeableConcept} // Classification of service

category

CodeableConcept

Класифікація процедури 

автоматично eHealth/procedure_categories 

“code”: {CodeableConcept} // What was performed = (Service)

code

CodeableConcept

Код виконаного сервісу 

вручну користувачем

eHealth/services 

“encounter”: { Reference(Encounter) } // Reference on encounter resource

encounter

Reference(Encounter)

Посилання взаємодію, в рамках якої було надано реабілітаційну допомогу

автоматично з боку МІС при запиті на створення

“performedDateTime”: {dateTime} // When the procedure was performed

performed_DateTime

dateTime

O

Коли відбулося обслуговування 

вручну користувачем 

“performedPeriod”: Period // Volume of rehabilitation service provided = NEW field !

performedPeriod

Period

O

Об'єм наданої реабілітаційної послуги (в хвилинах)

вручну користувачем

"recorded_by" : {Reference(Employee) }, // Who recorded this procedure = 

recorded_by

Reference (Employee) 

Фахівець | Лікар ФРМ

Автоматично МІС при запиті на створення

“primarySource”: {boolean} // true | false

primary_source

boolean

M

Чи сам фахівець виконав процедуру ?

вручну користувачем при запиті на створення

“report_origin”: {CodeableConcept} // should be filled, if primary_source=false

report_origin

CodeableConcept

О

Джерело інформації по процедурі. Заповнюється, якщо primary_source=false

вручну користувачем при запиті на створення

eHealth/report_origins

“performer”: {Reference(Employee)} // 

performer

Reference(Employee)

M

Виконавець послуги

автоматично МІС, або вручну користувачем (якщо виконавцем є інший фахівець цього закладу)

“division”: {Reference(Location)} // Where the procedure happened

division

Reference(Location)

Підрозділ юридичної особи, де проводилася процедура

вручну користувачем у запиті на створення

“managingOrganisation”: {Reference(Legal Entity)} // Where the procedure happened

managing_Organization

Reference(Legal Entity)

М

Організація (юридична особа), яка несе відповідальність за поточну процедуру

Автоматично МІС у запиті на створення

“reasonReference”: [{Reference(Observations)}] // From  service_request. reasonReference

reason_Reference

[Reference(Observations)]

Посилання на Observations, зафіксоване у відповідному service_request. reasonReference

Автоматично  

“outcome”: {CodeableConcept} // The result of procedure

outcome

CodeableConcept

О

Результат процедури - чи вирішив він причини проведення процедури.

вручну користувачем з довідника eHealth/procedure_outcomes

“note”:{string} // Additional information about the procedure 

note

string

O

Будь-які інші примітки та коментарі щодо процедури, не вказані у відповідних атрибутах

вручну користувачем

“usedCode”: [{CodeableConcept}] // ISO 9999 - devices used  = NEW field !

usedCode

[CodeableConcept]

О

Перелік використаних допоміжних засобів згідно ISO 9999.

вручну користувачем із можливістю доповнення масиву значеннь з довідника eHealth/ISO_9999

1.8.2 Модель статусів сутності Procedure completed | entered-in-error


Таблиця можливих статусів 

№ з/п

Статус 

Переклад

Опис

Термінальний статус?

1

completed

виконаний

Процедура успішно виконана

Так

2

entered-in-error

введений помилково

Відміна помилково заведеної процедури

Так

Малюнок 7. Схема переходу між статусами

  • No labels