Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

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

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

...

View file
nameRHB-D040-P1. UML Class Diagram_MVP_2023.oom

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. Схема переходу між статусами

...

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

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

...

Малюнок 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 

“component”: {CodeableConcept}  MKF qualifier

component

[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

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

...

Малюнок 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

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

...

Малюнок 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

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

...

Малюнок 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

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

...

Малюнок 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


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

...