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

Submit Encounter Package _UA

Owned by Oleg Brizhatiy (Unlicensed)
Last updated: Oct 04, 2024 by Vorona Oksana (NHSU)
23 min read

Вступ

Веб-сервіс "Submit Encounter Package" дозволяє передавати всі дані, зібрані під час взаємодії до бази даних eHealth використовуючи тільки одина даний сервіс. Тобто такі дані, як медичний стан, обстеження, алергія мають бути об'єднані в один масив даних для того, щоб можна було зареєструвати в eHealth.

Специфікація

Apiary

Валідації

Authorization

  1. Перевірити валідність токену доступу

    1. В разі помилки повернути 401 ('Access denied')

  2. Перевірити скоупи користувачів encounter:write на можливість виконання даної дії

    1. В разі помилки згенерувати відповідь 403 ('Invalid scopes')

Перевірка запиту

Примітка: Недозволено оновлені операції. Всі ID, вказані як PK, повинні бути унікальні для eHealth. 

  1. Перевірити статус пацієнта

    1. db.patients.status для пацієнта повинен бути "active"

      1. в разі помилки повернути 409 - "Patient is not active"

  2. Перевірити запит на відповідність схемі JSON

    1. Повернути 422 зі списком помилок валідації в разі їх неуспішності 

  3. Перевірити Visit

    1. $.visit.id унікальний

      1. в разі помилки повернути 422 - "Visit with such id already exists"

    2. $.visit.end заповнено

      1. в разі помилки повернути - "End date of visit must be filled"

    3. Period Validation

  4. Перевірити цифровий підпис

    1. Перевірити, що цифровий підпис належить виконавцю взаємодії

      1. перевірити, що ІПН з цифрового підпису та party.drfo виконавця відповідають

    2. Перевірити, що виконавець взаємодії є поточним користувачем 

      1. перевірити, що один зі співробітників користувача є виконавцем взаємодії

      2. перевірити, що client_id з токену == PRM.performer.legal_entity

  5. Перевірити розкодований підписний контент на відповідність схемі JSON

    1. Повернути 422 з переліком помилок валідації в разі їх неуспішності

Перевірити тип юридичної особи

Перевірити юридичну особу з токену: legal_entities.type повинен бути me_allowed_transactions_le_types та legal_entities.status =='active' 

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

Загальні перевірки

  1. Перевірити, що encounter id це первинний ключ (Primary Key Validation)

  2. Перевірити, що date в рамках допустимих лімітів

    1. $.encounter.date<= current_date

    2. $.encounter.date>=current_date-encounter_max_days_passed

  3. Перевірити, що "episode" це активна взаємодія, яка належить поточному пацієнту

    1. $.encounter.episode.identifier.value є одним з  ME.patinet{patient_id}.episodes{*}.id

      1. в разі помилки повернути 422 "Episode with such ID is not found"

    2. $.encounter.episode.identifier.value це ID взаємодії, яка відповідає вимогам:

      1. ME.patient{patinet_id}.episodes{episode_id}.status = 'active'

        1. в разі помилки повернути 422 "Episode is not active"

      2. ME.patient{patinet_id}.episodes{episode_id}.managing_organization==token.client_id

        1. в разі помилки повернути 422 "Managing_organization in the episode does not correspond to user`s legal_entity"

  4. Перевірити "visit" це візит, який належить поточному пацієнту

    1. $.encounter.visit.identifier.value=$.visit.id  АБО  ID уже існуючого візиту в ME.patient{patient_id}.visit.id

      1. в разі помилки повернути 422 "Visit with such ID is not found"

  5. Перевірити направлення

    1. Як направлення, воно може бути сформовано в електронному варіанті (зареєстроване в системі) АБО паперове направлення на сервіс

    2. Перевірити ($.encounter.incoming_referrals АБО $.encounter.paper_referral) або відсутній у запиті

    3. Перевірити incoming referrals як направлення (Submit Encounter Data Package#Referencevalidation)

    4. Перевірити paper referral як об'єкт (paper_referral)

    5. Перевірити incoming referrals, що посилається на $.encounter.incoming_referrals[*].identifier.value та має:

      1. ..used_by_legal_entity.identifier.value==token.client_id АБО null

        1. в разі помилки повернути 409 "Service request is used by another legal_entity"

      2. ..status==active or program_processing_status=in_progress (будь-який статус валідний в разі program_processing_status= in_progress)

        1. в разі помилки повернути 409 "Invalid service request status"

      3. ..якщо програма визначена, як program_processing_status=new, in_queue or in_progress

      4. перевірити, що service_request містить параметр based_on

        1. в разі based_on наявний в service_request

          1. перевірити care_plan:

            1. Він має бути в статусі active 

            2. Дата періоду плану лікування end (якщо існує) повинна бути більше поточної дати.

          2. перевірити activity:

            1. Якщо має activity.detail.kind=service_request; activity.detail.product_reference=service_id. 

            2. Якщо має статус scheduled, in_progress 

        2. в разі based_on не присутня в запиті, пропустити попередні перевірки.

  6. Перевірити performer

    1. $.encounter.performer.identifier.value це ID існуючого співробітника в PRM.Employees

      1. в разі помилки повернути "There is no Employee with such id"

    2. $.encounter.performer.identifier.value  == PRM.Employees.id де (PRM.Employees.status==`active`)

      1. в разі помилки повернути "Employee is not active"

    3. $.encounter.performer.identifier.value  == PRM.Employees.id де (PRM.Employees.legal_entity== client_id)

      1. "User can not create encounter for this legal_entity"

    4. перевірити тип співробітника відповідно до encounter.class 

      1. в разі помилки повернути 409, "invalid employee type"

  7. division

    1. $.encounter.division.identifier.value повинна відповідати наступним вимогам

      1. PRM.division.status = "ACTIVE"

        1. в разі помилки повернути 409 "Division is not active " 

      2. PRM.division.legal_entity= token.client_id

        1. в разі помилки повернути 409 "User is not allowed to create encouners for this division"

  8. Перевірити supporting_info як посилання (Reference validation)

  9. Перевірити encounter.class  

    1. відповідно до legal_entity.type - використовуй конфігураційний файл (legal_entity_episode_types)

      1. в разі помилки повернути 409, повідомлення "Encounter.class $class is forbidden for your legal entity type"

    2. відповідно до episode.type - використовуй конфігураційний файл (episode_type_encounter_classes)

      1. в разі помилки повернути 409, повідомлення "Encounter.class $class is forbidden for your episode type"

    3. відповідно до employee.type як вказано в класі валідацій для взаємодії

      1. в разі помилки повернути 409, повідомлення "Encounter.class $class is forbidden for your employee type"

  10. Перевірити encounter.type відповідно до encounter.class - використовуй конфігураційний файл encounter_class_encounter_types

    1. в разі помилки повернути 409, повідомлення "Encounter.type $type is forbidden for your encounter class"

  11. Перевірити actions 

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

      1. в разі помилки повернути '422', повідомлення 'TBC'

    2. Defined in the system that corresponds to  encounter class validations

      1. в разі помилки повернути '422', повідомлення 'TBC'

  12. Перевірити action_references 
    Примітка. Для encounter.action_references проходять тільки "service", та не проходять "service_group"

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

      1. в разі помилки повернути '422', повідомлення 'At least one of action references, diagnostic reports or procedures should exist in encounter package'

    2. Перевірити код посилання (Reference validation)

    3. Перевірити action_references наявна в prm.services, має статус ACTIVE та is_active = true

      1. в разі помилки повернути '422', повідомлення 'Service with such ID is not found'

      2. в разі помилки повернути '422', повідомлення 'Service should be active'

  13. Перевірити diagnoses 

    1. Перевірити медичний стан як повилання (Submit Encounter Data Package#Referencevalidation)

    2. Перевірити, що взаємодія має саме один діагноз, де $.encounter.diagnoses[?(@.role.coding[0].code=="primary")]

      1. в разі помилки повернути 422 "Encounter must have exactly one primary diagnosis"

    3. Перевірити condition.id наявна в базі даних або в поточному пакеті взаємодії 

    4. Перевірити, що кожний стан активний (verification_status != entered_in_error)

      1. в разі помилки повернути 409 "Conditions in diagnoses must be active"

    5. Перевірити, що первинний діагноз, вказаний в системі, та який посилається на клас валідацій по взаємодії

      1. в разі помилки повернути "Primary diagnosis should be defined in {$.encounter.diagnoses[*].role.coding[*].system } system"

  14. Перевірити reasons

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

      1. в разі помилки повернути '422', повідомлення 'Validation failed. You can find validators description at our API Manifest: http://docs.apimanifest.apiary.io/#introduction/interacting-with-api/errors .', description 'опис не може бути шаблонним.

  15. Перевірити hospitalization 

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

      1. в разі помилки повернути 422, повідомлення "Hospitalization block is forbidden for encounter.class = $encounter.class" 

    2. Перевірити всі поля відповідно до схеми

      1. destination

      2. discharge_disposition

      3. pre_admission_identifier

      4. admit_source

      5. re_admission

      6. discharge_department

    3. Перевірити, що місце госпіталізації валідне з legal_entity в prm зі статусом ACTIVE та is_active = true

      1. в разі помилки повернути 422, "Legal entity is not active"

  16.  Перевірити patient_id для encounter.type == "patient_identity"

    1. $patient_id має існувати в mpi.prepersons.id, мати статус =='ACTIVE' та is_active = true

      1. в разі помилки повернути 'TBC', msg 'TBC'

  17. Якщо incoming referrals існує та категорія incoming_referral (service request) не в ('transfer_of_care', 'hospitalization') та encounter.class в ("AMB", "INPATIENT") та encounter.type <>  "patient_identity" перевірити сервіс на encounter.actions АБО diagnostic_report.code АБО procedure.code

    1. Якщо service_requests.code.identifier.value це сервіс, перевірити $resourse.code.identifier.value = service_requests.code.identifier.value

      1. в разі помилки повернути 409, "Service in $resourse differ from service in service request"

    2. Якщо service_requests.code.identifier.value це service_group, перевірити $resourse.code.identifier.value в (SELECT service_id from service_inclusions where service_group_id='service_requests.code.identifier.value')

      1. в разі помилки повернути 409, "Service in $resourse differ from services in service request's service_group"

    3. Перевірити $resourse.service.is_active = true

      1. в разі помилки повернути 409, "Service should be active"

18. Якщо пацієнт це person - перевірити статус verification:

  1. Якщо для взаємодії вказано incoming referral з направленням, пропустити дану валідацію.

  2. В іншому випадку перевірити, що verification_status не дорівнює NOT_VERIFIED.

    1. в разі NOT_VERIFIED - повернути помилку 409, "Patient is not verified"

Валідації для класу взаємодії

Важливо

Дані перевірки можуть бути використані для всіх типів взаємодій окрім covid.



Валідація

Первинна медична допомога

Амбулаторія

Стаціонар

Валідація

Первинна медична допомога

Амбулаторія

Стаціонар

employees.type

'DOCTOR'

'SPECIALIST'

'SPECIALIST'

encounter.type

як вказано в файлі конфігурації encounter_class_encounter_types

як вказано в файлі конфігурації encounter_class_encounter_types

як вказано в файлі конфігурації  encounter_class_encounter_types

actions

  • очікується хоча б один

  • з довідника eHealth/ICPC2/actions

відсутній в запиті

відсутній в запиті

diagnoses

diagnoses.primary є станом з кодом з довідника "eHealth/ICPC2/condition_codes"

diagnoses.primary є станом з кодом з довідника "eHealth/ICD10_AM/condition_codes"

diagnoses.primary є станом з кодом з довідника "eHealth/ICD10_AM/condition_codes"

reasons

  • очікується хоча б один

  • з довідника eHealth/ICPC2/reasons

  • опціонально (якщо вказано - має бути з довідника eHealth/ICPC2/reasons)

  • опціонально (якщо вказано - має бути з довідника eHealth/ICPC2/reasons)

hospitalisation

відсутній в запиті

відсутній в запиті

if encounter.type == "discharge" - даний блок є обов'язковим

  • discharge_disposition обов'язковий

  • discharge_department обов'язковий

Для інших типів взаємодій

  • опціонально

action_references

відсутній в запиті

if encounter.type == "patient_identity" 

  • валідації відсутні

Для інших типів взаємодій

  • один з має існувати:

    1. action_references у взаємодії

    2. АБО даігностичний звіт в пакеті

    3. АБО процедура в пакеті

if encounter.type == "patient_identity" 

  • валідації відсутні

Для інших типів взаємодій

  • один з має існувати:

    1. action_references у взаємодії

    2. АБО даігностичний звіт в пакеті

    3. АБО процедура в пакеті

division





Відділення повинне бути заповнене

Перевірити стани

  1. Перевірити id станів як первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст станів це поточна взаємодія

    1. $.conditions[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the condition"

  3. Перевірити залежність коду на клас взаємодії

    1. якщо $.encounter.class = PHC - дозволяються обидва eHealth/ICPC2/condition_codes та eHealth/ICD10_AM/condition_codes

    2. якщо $.encounter.class в (AMB, INPATIENT) - дозволено тільки eHealth/ICD10_AM/condition_codes

  4. Перевірити, що code.coding відповідає кількості кодів

    1. Максимум один код з довідника дозволено (eHealth/ICPC2/condition_codes та eHealth/ICD10_AM/condition_codes)

      1. в разі помилки повернути 422 з повідомленням "Only one code from one dictionary is allowed"

  5. Перевірити, що дата в допустимих лімітах

    1. $.conditions[*].onset_date <= current_date

      1. в разі помилки "Onset date must be in past"

  6. $.condition[*].onset_date>=current_date-condition_max_days_passed

    1. в разі помилки "Onset date must be greater than  {{current_date-condition_max_days_passed}}"

  7. $.conditions[*].onset_date <= current_date

    1. в разі помилки "Onset date must be in past"

  8. $.conditions[*].asserted_date <= current_date

    1. в разі помилки "Asserted date must be in past"

  9. $.conditions[*].evidences[*].detail[*].identifier.value це ID існуючого обстеження в MedicalEvents.Observations або один з $.observations[*]

    1. в разі помилки 409 "Observation with such id is not found"

  10. $.conditions[*].evidences[*].detail[*].identifier.value meet follownig conditions

    1. MedicalEvents.Observation.Patient == patient_id (from url)

      1. Помилка 409 "Evidence can not reference another patient"

    2. MedicalEvents.Observation.Status != "entered_in_error"

      1. Помилка 409 "Observation in "entered_in_error" status can not be used as an evidence"

  11. перевірити asserter. Та додаткова перевірка:

    1. якщо primary_source = true та code має значення довідника eHealth/ICD10_AM/condition_codes:

      1. визначити дозволені спеціалізація для кодів станів ICD10_AM набір перемінних чартів ICD10_AM_<SPECIALITY_TYPE>_SPECIALITY_CONDITIONS_ALLOWED

      2. перевірити, що спецільність asserter дозволена спеціальність, визначена на попередньому кроці

        1. в разі, якщо спеціальність не дозволена для коду станів - повернути помилку 409 ('Asserter has no required speciality to set condition code <ICD10_AM code>')

Перевірити обстеження

  1. Перевірити id обстежень, як первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст обстежень - це поточна взаємодія

    1. $.observations[*].context.identifier.value==$.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the observation"

  3. Перевірити, що дата в допустимих лімітах

    1. $.observations[*].issued <= current_time

      1. в разі помилки повернути "Issued date must be in past"

    2. $.observations[*].issued>=current_date-observation_max_days_passed

      1. в разі помилки повернути "Issued must be greater than  {{current_date-observation_max_days_passed}}"

  4. Перевірити performer(asserter)

  5. Перевірити $.observations[*].components[*].value_period відповідає Period

  6. Перевірити $.observations[*].value_quantity

    1. $.observations[*].value має бути з типом номеру

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

    2. $.observations[*].comparator може мати наступні значення: [">", ">=", "=", "<=", "<"]

      1. в разі помилки повернути "value is not allowed in enum"

    3. $.observations[*].unit може мати значення з довідника eHealth/ucum/units 

      1. в разі помилки повернути "value is not allowed in enum"

  7. Перевірити $.observations[*].value_codeable_concept

    1. $.observations[*].code перевірити, що коди відповідають значенням довідника системи

      1. в разі помилки повернути "Value is not allowed in enum"

  8. Перевірити $.observations[*].value_boolean

    1. $.observations[*].value_boolean має бути типу логічний

      1. в разі помилки повернути "type mismatch. Expected boolean but got {entered type}"

  9. Перевірити $.observations[*].value_string

    1. $.observations[*].value_string має бути типу рядок

      1. в разі помилки повернути "type mismatch. Expected string but got {entered type}"

  10. Перевірити $.observations[*].value_sampled_data

    1. $.observations[*].data має бути типу рядок

      1. в разі помилки повернути "type mismatch. Expected string but got {entered type}"

    2. $.observations[*].origin має бути типу число

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

    3. $.observations[*].period має бути типу число

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

    4. $.observations[*].factor має бути типу число

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

    5. $.observations[*].lower_limit має бути типу число

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

    6. $.observations[*].upper_limit має бути типу число

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

    7. $.observations[*].dimensions має бути типу число

      1. в разі помилки повернути "type mismatch. Expected number but got {entered type}"

  11. Перевірити $.observations[*].value_range

    1. $.observations[*].low має бути типу об'єкт

      1. в разі помилки повернути "type mismatch. Expected object but got {entered type}"

    2. $.observations[*].high має бути типу об'єкт

      1. в разі помилки повернути "type mismatch. Expected object but got {entered type}"

  12. Перевірити $.observations[*].value_ratio

    1. $.observations[*].numerator має бути типу об'єкт

      1. в разі помилки повернути "type mismatch. Expected object but got {entered type}"

    2. $.observations[*].denominator має бути типу об'єкт

      1. в разі помилки повернути "type mismatch. Expected object but got {entered type}"

  13. Перевірити $.observations[*].value_time

    1. $.observations[*].value_time має бути типу рядок

      1. в разі помилки повернути "type mismatch. Expected string but got {entered type}"

  14. Перевірити $.observations[*].value_date_time

    1. $.observations[*].value_date_time має бути типу рядок

      1. в разі помилки повернути "type mismatch. Expected string but got {entered type}"

  15. Перевірити, що діагностичний звіт це один зі звітів поточного пакету

    1. $.observations[*].diagnostic_report.identifier.value == one of $.diagnostic_report[*].identifier.value

      1. в разі помилки повернути "Invalid reference"

  16. Перевірити $.observations[*].reaction_on

    1. перевірити, що відповідний immunizations.status != "entered_in_error"

      1. в разі помилки повернути 409 "Immunization with status ‘entered_in_error’ can not be use"

  17. Перевірити $.observations.code

    1. Якщо observations.code.coding[*].code значення включено в чарт параметри ‘OBSERVATION_CODES_WITH_<VALUE_TYPE>_REQUIRED', <value_type> поле обов’язкове

      1. в разі помилки повернути 422 “This field is required for code = <code>“

Перевірити обстеження для encounter.type == "patient_identity" 

  1. EDP з типом == "patient_identity" має містити список спеціальних обстежень. 

  2. Такий список может містити обмеженний набір кодів, деякі з них обов'язкові

Код

M/O

Код

M/O

height

M

weight

M

sex

M

stature

O

eye_colour

O

hair_ color

O

hair_length

O

beard

O

mustache

O

clothes

O

peculiarity

O

Перевірити щеплення

  1. Перевірити id щеплень як первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст щеплень в поточній взаємодії

    1. $.immunizations[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the immunization"

  3. Перевірити, що дати в допустимих лімітах

    1. $.immunizations[*].date <= current_time

      1. в разі помилки повернути "Date must be in past"

    2. $.immunizations[*].date>=current_date-immunization_max_days_passed

      1. в разі помилки повернути "Date must be greater than  {{current_date-immunization_max_days_passed}}"

  4. Перевірити виконавця відповідно до Rule 

  5. Перевірити, що обстеження вказані, як деталі реакції, для обстеження по поточному пацієнту

    1. $.immunizations[*].reactions[*].detail.identifier.value є ID існуючого обстеження в ME.observations де (ME.observations.patient_id==patient_id з url) АБО один з $.observations[*].id

      1. в разі помилки повернути 422 "There is no observation with such id"

Перевірити алергії

  1. Перевірити id алергій як первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст allergy_intolerances є для поточної взаємодії

    1. $.allergy_intolerances[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the allergy_intolerances"

  3. Перевірити виконавця відповідно до Rule

  4. Перевірити, що дати в допустимих лімітах

    1. $.allergy_intolerances[*].onset_date_time<= current date_time

      1. в разі помилки повернути "Onset date time must be in past"

    2. $.allergy_intolerances[*].onset_date_time>=current_date-allergy_intolerance_max_days_passed

      1. в разі помилки повернути "Onset date time must be greater than  {{current_date-allergy_intolerance_max_days_passed}}"

  5. Перевірити, що дата запису asserted_date в минулому

    1. $.allergy_intolerances[*].asserted_date<= current date_time

      1. в разі помилки повернути "Asserted date must be in past"

  6. Перевірити, що last_occurrence в минулому

    1. $.allergy_intolerances[*].last_occurrence<= current date_time

      1. в разі помилки повернути "Last occurrence must be in past"

Перевірити оцінку ризику

  1. Перевірити id оцінки ризику як первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст risk_assessments по поточній взаємодії

    1. $.risk_assessments[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the risk_assessments"

  3. Перевірити, що asserted_date в допустимих лімітах

    1. $.risk_assessments [*].asserted_date<= current date_time

      1. в разі помилки повернути "Asserted date  must be in past"

    2. $.risk_assessments [*].asserted_date>=current_date-risk_assessment_max_days_passed

      1. в разі помилки повернути "Asserted date must be greater than  {{current_date-risk_assessment_max_days_passed}}"

  4. Перевірити виконавця відповідно до Rule

    1. перевірити, що виконавець це лікар з поточного legal_entity

      1. $..performer.identifier.value is an ID of existing employee in PRM.employee

        1. в разі помилки повернути "Employee with such id is not found"

      2. $..performer.identifier.value == PRM.employees.id where (PRM.employees.status == "APPROVED" та PRM.employees.employee_type=="DOCTOR")

        1. "Employee is not an active doctor"

  5. Перевірити, що тільки одне з полів заповнене: reason_reference , reason_codeable_concept

  6. Перевірити, що reason_reference це посилання(Submit Encounter Data Package#Referencevalidation)

  7. Перевірити базис - це посилання(Submit Encounter Data Package#Referencevalidation)

  8. Перевірити when_period як період (Submit Encounter Data Package#period_validationPeriodValidation)

  9. Перевірити, що тільки одне з полів заповнене: prediction.when_period or prediction.when_range

  10. Перевірити, що тільки одне з полів заповнене: prediction.probability_decimal or prediction.probability_range

Перевірити обладнання

  1. Перевірити id обладнання як первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст обладнання по поточній взаємодії

    1. $.devices[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the device"

  3. Перевірити, що asserted_date в допустимих лімітах

    1. $.devices[*].asserted_date<= current date_time

      1. в разі помилки повернути "Asserted date  must be in past"

    2. $.devices[*].asserted_date>=current_date-device_max_days_passed

      1. в разі помилки повернути "Asserted date must be greater than  {{current_date-device_max_days_passed}}"

  4. Перевірити виконавця відповідно до Rule

  5. Перевірити usage_period як період (Submit Encounter Data Package#period_validationPeriodValidation)

Перевірити прийом лікарських засобів

  1. Перевірити, що id прийому ЛЗ це первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити, що контекст прийому ЛЗ це поточна взаємодія

    1. $.medication_statements[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the medication statement"

  3. Перевірити, що asserted_date в допустимих лімітах

    1. $.medication statements[*].asserted_date<= current date_time

      1. в разі помилки повернути "Asserted date  must be in past"

    2. $.medication statements[*].asserted_date>=current_date-medication statement_max_days_passed

      1. в разі помилки повернути "Asserted date must be greater than  {{current_date-medication statement_max_days_passed}}"

  4. Перевірити виконавця відповідно до Rule

  5. Перевірити based_on є посиланням (Submit Encounter Data Package#Referencevalidation) на OPS.medication_request

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

  1. Перевірити, що id адміністрування ЛЗ це первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити part_of 

    1. перевірити, що процедура або medication_administration відносяться до одного і того ж пацієнта

      1. procedure.patient_id=@person_id

      2. medication_administration.patient_id=@person_id

        1. в разі помилки повернути 409 "Procedure/Medication administration was made for another person"

    2. перевірити, що процедура або medication_administration не в статусі `entered_in_error`

      1. в разі помилки повернути 409, "Procedure/Medication administration is not active"

    3. якщо part_of.identifier.value є валідацією процедури та це процедура з бази даних або в бєклозі

      1. в разі помилки повернути 422, "Procedure with such id is not found"

  3. Перевірити ЛЗ

    1. перевірити, що ЛЗ з типом 'BRAND'

      1. в разі помилки повернути 422, "Medication should be of type brand"

    2. ЛЗ посилається на INNM_DOSAGE ЛЗ з request.medication 

      1. "select count(*) from ingredients where parent_id=‘medication_administration.medication.id’ and medication_child_id = ‘medication_request.medication_id’ " >=1

        1. в разі помилки повернути 422,  "Medication should correspond to the one in request"

  4. Перевірити, що контекст адміністрування ЛЗ в поточній взаємодії

    1. $.medication_administration[*].context.identifier.value == $.encounter.id

      1. в разі помилки повернути "Submitted context is not allowed for the medication administration"

  5. Перевірити performed_date_time <= now()

    1. в разі помилки повернути 422, "performed_date_time should be in the past"

  6. Перевірити виконавця відповідно до Rule

    1. перевірити, що виконавець це активний лікар з поточного legal_entity

      1. $..performer.identifier.value це ID існуючого співробітника з PRM.employee

        1. в разі помилки повернути "Employee with such id is not found"

      2. $..performer.identifier.value == PRM.employees.id where (PRM.employees.status == "APPROVED" та PRM.employees.employee_type в ("DOCTOR","SPECIALIST"))

        1. "Employee is not an active doctor"

  7. перевірити reason_references

    1. перевірити  Condition|Observation|DiagnosticReport як посилання

    2. перевірити Condition|Observation|DiagnosticReportне в статусі "entered_in_error"

      1. в разі помилки повернути 409, "Reason reference should be active"

    3. перевірити Condition|Observation|DiagnosticReport виконані для того ж пацієнта

      1. в разі помилки повернути 409, "Reason reference was made for another person"

    4. перевірити Condition|Observation|DiagnosticReport існує в базі даних або в беклог

      1. в разі помилки повернути 422, "Condition|Observation|DiagnosticReport with such id is not found"

  8. Перевірити request

    1. перевірити medication_request як посилання

    2. перевірити medication_request в активному статусі medication_request.status='ACTIVE' та is_active=true

      1. в разі помилки повернути 409, "medication request is not active"

    3. перевірити medication request is made for the same person

      1. в разі помилки повернути 409, "medication request was made for another person"

    4. перевірити medication_request.started_at < now()

      1. в разі помилки повернути 409, "Medication request started at should be in the past"

  9. Перевірити дозування

Перевірити діагностичний звіт

  1. Перевірити, що id діагностичного звіту це первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  2. Перевірити based_on як посилання (Submit Encounter Data Package#Referencevalidation)

  3. Перевірити, що service_request, посилається на based_on, та є

    1. в статусі active або program_processing_status=in_progress (будь-який статус валідний в разі program_processing_status= in_progress)

      1. в разі помилки повернути 409 "Invalid service request status"

    2. якщо програма вказана, то used_by_legal_entity==token.client_id АБО null

      1. в разі помилки повернути 409 "Service request is used by another legal_entity"

    3. якщо програма вказана, то program_processing_status == new, in_queue або in_progress

    4. перевірити, що service_request містить параметр based_on

      1. в разі наявності based_on в service_request

        1. перевірити care_plan:

          1. він має бути в статусі active 

          2. Період плану лікування end (якщо вказано) повинен бути більше поточної дати або дорівнювати.

        2. перевірити activity:

          1. що має activity.detail.kind=service_request; activity.detail.product_reference=service_id. 

          2. що має статус scheduled, in_progress 

      2. в разі based_on не вказано в запиті - пропустити попередні перевірки.

  4. category

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

      1. $.diagnostic_report.category[?]=PRM.services.category де PRM.services.id=$.diagnostic_report.code.identifier.value

        1. в разі помилки повернути 422 "None of the diagnostic report categories matches with the service category"

  5. Перевірити code

    1. Перевірити код як посилання (Referencevalidation)

    2. Якщо service_requests.code.identifier.value це сервіс, перевірити $diagnostic_report.code.identifier.value = service_requests.code.identifier.value

      1. в разі помилки повернути 409, "Service in diagnostic_report differ from service in service request"

    3. Якщо service_requests.code.identifier.value це service_group, перевірити $diagnostic_report.code.identifier.value в (SELECT service_id from service_inclusions where service_group_id='service_requests.code.identifier.value')

      1. в разі помилки повернути 409, "Service in diagnostic_report differ from services in service request's service_group"

    4. Перевірити diagnostic_report.service.is_active = true

      1. in case error return 409, "Service should be active"

  6. Перевірити effective_period як період (Submit Encounter Data Package#period_validationPeriodValidation)

  7. Перевірити, що issued в допустимих лімітах

    1. $.diagnostic_reports[*].issued<= current date_time

      1. в разі помилки повернути 422 "Asserted date  must be in past"

    2. $.diagnostic_reports[*].issued>=current_date-diagnostic_report_max_days_passed

      1. в разі помилки повернути 422 "Issued must be greater than  {{current_date-diagnostic_report_max_days_passed}}" 

  8. conclusion_code

  9. Перевірити recorded_by це співробітник (Submit Encounter Data Package#Employeevalidation)

  10. Перевірити encounter

    1. $.diagnostic_reports[*].encounter.identifier.value == $.encounter.id

      1. в разі помилки повернути 409 "Invalid reference"

  11. Перевірити performer.identifier це співробітник (Submit Encounter Data Package#Employeevalidation)

  12. Перевірити managing_organization це поточний legal_entity

    1. $.managing_organization.identifier.value==token.client_id

      1. в разі помилки повернути 409 "Managing organization does not correspond to user's legal entity."

  13. Перевірити result_interpreter.identifier це співробітник (Submit Encounter Data Package#Employeevalidation)

  14. Перевірити result_interpreter.identifier це співробітник з employee_type = DOCTOR або SPECIALIST

  15. Перевірити6 що тільки одне з полів заповнене:

    1. $.diagnostic_report[*].results_interpreter.reference АБО $.diagnostic_report[*].results_interpreter.text

    2. $.diagnostic_report[*].performer.reference АБО $.diagnostic_report[*].performer.text

  16. Перевірити primary_source

    1. Якщо primary_source==true, то

      1. Managing organization ПОВИННА бути заповнена

    2. Якщо primary_source==false, то

      1. report_origin АБО performer.text повинен бути заповнений

      2. performer.reference НЕ повинен бути заповнений

      3. results_enterpreter.reference НЕ повинен бути заповнений

Перевірити процедуру

  1. Перевірити за json schema

  2. Перевірити, що id процедури це первинний ключ (Submit Encounter Data Package#Primarykeyvalidation)

  3. Перевірити code

    1. Перевірити код, як посилання (Referencevalidation)

    2. Перевірити, що procedure.service.is_active = true

      1. в разі помилки повернути 409, "Service is not active"

  4. Перевірити, що service_request, має посилання з based_on, та

    1. перевірити, що service_request містить параметр based_on

      1. в разі based_on наявний в service_request

        1. перевірити care_plan:

          1. він має бути в статусі active 

          2. Період плану лікування end (якщо вказано) повинен бути більше поточної дати або дорівнювати.

        2. перевірити activity:

          1. Вона має activity.detail.kind=service_request; activity.detail.product_reference=service_id. 

          2. Вона має статус scheduled, in_progress 

      2. в разі based_on не вказана в запиті - пропустити попередні валідації.

  5. Перевірити encounter

    1. $.procedure[*].encounter.identifier.value == $.encounter.id

      1. в разі помилки повернути 409, "Submitted encounter is not allowed for procedure"

  6. Перевірити performed_date_time

    1.  performed_date_time дійсний

      1. в разі помилки повернути 422, "Performed_date_time in invalid"

    2. performed_date_time <= now

      1. в разі помилки повернути 422 "Procedure cannot be registered in future"

  7. Перевірити recorded_by

    1. Перевірити recorded_by як посилання (Referencevalidation)

    2. $..recorded_by.identifier.value є ID існуючого співробітника в PRM.employee

      1. в разі помилки повернути 422, "Employee with such id is not found"

    3. Перевірити recorded_by це співробітник зі status='APPROVED' та is_active= true та end_date є null або більше поточної дати

      1. в разі помилки повернути 409, "This action is prohibited for current employee" 

    4. Перевірити employees.legal_entity_id=$managing_organization.identifier.value

      1. в разі помилки повернути 409, "Employee should be from current legal entity"

  8. Перевірити asserter

  9. Перевірити division

    1. Перевірити відділення як посилання (Referencevalidation)

    2. $division є ID в PRM.divisions

      1. в разі помилки повернути 422, "Division with such id is not found"

    3. division.status=ACTIVE та is_active=true

      1. в разі помилки повернути 409, "Division is not active"

    4. division.legal_entity_id = $client_id або division.legal_entity_id=$managing_organization.identifier.value

      1. в разі помилки повернути 409, "Division is not in current legal_entity"

  10. Перевірити managing_organization це поточний legal_entity з відповідним типом

    1.  як посилання (Referencevalidation)

    2. $managing_organization є ID в PRM.legal_entities

      1. в разі помилки повернути 422, "Legal entity with such id is not found"

    3. перевірити для managing_organization статус є 'ACTIVE' та is_active=true

      1. в разі помилки повернути 422 ('Legal entity is not active')

    4. перевірити тип legal_entity є в ('PRIMARY_CARE','MSP','MSP_PHARMACY','MSP_PHARMACY') (використати `ME_ALLOWED_TRANSACTIONS_LE_TYPES` з чартів)

      1. в разі помилки повернути 422, "Legal entity with type $legal_entity.type cannot perform procedures"

    5. перевірити $managing_organization.identifier.value = $client_id

      1. в разі помилки повернути 409 "Managing organization does not correspond to user's legal entity."

  11. Перевірити reason_references

    1. Перевірити reason_reference як посилання (Referencevalidation)

    2. Перевірити reason_refernce.identifier.value є станом не в статусі`entered_in_error`

      1. в разі помилки повернути 422, "Condition is canceled"

  12. Перевірити outcome

    1. перевірити висновок як посилання (Referencevalidation)

    2. перевірити outcome.coding.object.system є в довіднику eHealth/procedure_outcomes

      1. в разі помилки повернути 422, "outcome not in dictionary eHealth/procedure_outcomes"

  13. Перевірити complication_details

    1. перевірити complication_details як посилання (Referencevalidation)

    2. перевірити complication_details.identifier.value посилається на стан в тому ж пакеті взаємодії

      1. в разі помилки повернути 422, "complication_details does not correspond to condition in this encounter package"

  14. Перевірити category

    1. відповідно до довідника 'eHealth/procedure_categories' - по схемі

    2. Перевірити, що категорія процедури відноситься до категорії сервісу, що вказана як код процедури

      1. $.procedure.category=PRM.services.category де PRM.services.id=$.procedure.code.identifier.value

        1. в разі помилки повернути 422 "Procedure category does not match with the service category"

  15. Якщо пацієнт це person - перевірити статус verification:

    1. Якщо процедура включає based_on з направленням, то пропустити валідації.

    2. В іншому випадку перевірити, що verification_status не дорівнює NOT_VERIFIED.

      1. в разі NOT_VERIFIED - повернути помилку 409, "Patient is not verified"

Перевірити клінічну оцінку

  1. Перевірити згідно json schema

  2. Перевірити, що клінічна оцінка це первинний ключ (Primarykeyvalidation)

  3. Перевірити status

    1. Перевірити, що код відповідає значенням словника (eHealth/clinical_impression_statuses)

      • в разі помлки - повернути 422 ('value is not allowed in enum')

    2. Перевірити, що значення = completed

      • в разі помлки - повернути 422 ('value is not allowed in enum')

  4. Перевірити code

    1. Перевірити, що код відповідає значенням словника (eHealth/clinical_impression_patient_categories)

      1. в разі помлки - повернути 422 ('value is not allowed in enum')

    2. Перевірити code.coding в залежності від кількості кодів. Максимум один код дозволено

      1. в разі помлки - повернути 422 ('Only one code is allowed')

    3. Перевірити по code.coding[0].code та code.coding[0].system активні правила в rule_engine_rules collection

      1. в разі наявності хочі б одного активного коду - перевірити тільки запит по наступним валідаціям

      2. в разі наявності коду в колекції - перевірити запит з наступними валідаціями та додатковими з налаштувань бізнес-правил

  5. Перевірити description

    1. Перевірити, що тип значення строковий

      1. в разі помилки - повернути 422 ('type mismatch. Expected string but got {entered type}')

  6. Перевірити encounter

    1. Перевірити, що значення є валідним посиланням на ресурс взаємодії

      • Перевірити, що значення це об'єкт з посиланнями типів взаємодій

        • в разі помилки - повернути 422 ('value is not allowed in enum')

    2. Перевірити, що значення є валідним посиланням на ресурс взаємодії

      • Перевірити, що $.clinical_impressions[*].encounter.identifier.value == $.encounter.id

        1. в разі помилки - повернути 422 ('Invalid reference')

  7. Перевірити, що effective_period це період (PeriodValidation)

    1. Перевірити значення в полі $.effective_period

      • Перевірити, що $.effective_period.start <= encounter.date

        • в разі помилки - повернути 422 ('Start date must be in the past')

      • Перевірити, що $.effective_period.end >= $.effective_period.start

        • в разі помилки - повернути 422 ('End date must be greater than or equal the start date')

    2. Перевірити, шо $.effective_period.end в допустимих лімітах

      • Перевірити, що $.effective_period.end <= current_time

        • в разі помилки - повернути 422 ('Date must be in past')

      • Перевірити, що $.effective_period.end >= current_date-clinical_impression_max_days_passed

        • в разі помилки - повернути 422 ('Date must be greater than {{current_date-clinical_impression_max_days_passed}}')

  8. Перевірити effective_date_time

    1. Перевірити, що field $.effective_date_time типу строковий

      1. в разі помилки - повернути 422 ('type mismatch. Expected string but got {entered type}')

    2. Перевірити, що поле $.effective_date_time <= current_time

      1. в разі помилки - повернути 422 ('Date must be in past')

    3. Перевірити, що поле $.effective_date_time >= current_date-clinical_impression_max_days_passed

      1. в разі помилки - повернути 422 ('Date must be greater than {{current_date-clinical_impression_max_days_passed}}')

  9. Перевірити assessor

    1. Перевірити, що автор це посилання (Referencevalidation)

      1. $.assessor.identifier.value це ID існуючого співробітника в PRM.employee

        1. в разі помилки - повернути 422 ('Employee with such id is not found')

    2. Перевірити, що це співробітник зі статусом status='APPROVED' та is_active= true та end_date нуль або більше ніж сьогодні

      1. в разі помилки - повернути 422 ('Invalid employee status')

  10. Перевірити previous

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

      • Перевірити, що значення це об'єкт з посиланням на тип clinical_impression

        • в разі помилки - повернути 422 ('value is not allowed in enum')

      • Перевірити, що клінічна оцінка активна (status не є entered_in_error)

        • в разі помилки - повернути 422 ('Clinical impression in "entered_in_error" status can not be referenced')

      • Перевірити, що клінічна оцінка належить пацієнту ($.subject)

        • в разі помилки - повернути 422 ('Clinical impression with such id is not found')

  11. Перевірити problems

    1. Перевірити, що значення це масив з посиланнями на тип стану

      • в разі помилки - повернути 422 ('value is not allowed in enum')

    2. Перевірити, що кожний стан є активним (verification_status не є entered_in_error)

      1. в разі помилки - повернути 422 ('Condition in "entered_in_error" status can not be referenced')

    3. Перевірити, що стан належить пацієнту ($.subject)

      • в разі помилки - повернути 422 ('Condition with such id is not found')

  12. Перевірити finding

    1. Перевірити, що значення є масив об'єктів

      1. Перевірити item_reference

        1. Перевірити, що значення це об'єкт з посиланнями на ресурси станів, аналізів (далі <Medical event resource>)

          1. в разі помилки - повернути 422 ('value is not allowed in enum')

        2. Перевірити, що <Medical event resource> активний (статус не entered_in_error)

          1. в разі помилки - повернути 422 ('<Medical event resource> in "entered_in_error" status can not be referenced')

        3. Перевірити, що кожне посилання:

          1. валідний ME для визначеного типу вище

          2. належать пацієнту ($.subject)

            1. в разі помилки - повернути 422 (<Medical event resource> with such ID is not found')

        4. Якщо декілька ресурси наявні в активному правилу, перевірити, що вони відповідають зконфігурованим парвилам

          1. в разі помилки - повернути 409 ('Submitted patient category does not correspond to rule engine rule')

      2. Перевірити basis

        1. Перевірити, що значення типу строковий

          1. в разі помилки - повернути 422 ('type mismatch. Expected string but got {entered type}')

  13. Перевірити supporting_info

    1. Перевірити, що знаення це масив посилань типу episode_of_care, procedure, diagnostic report, encounter (further <Medical event resource>)

      1. в разі помилки - повернути 422 ('value is not allowed in enum')

    2. Перевірити, що <Medical event resource> активний (статус не entered_in_error)

      1. в разі помилки - повернути 422 ('<Medical event resource> in "entered_in_error" status can not be referenced')

    3. Перевірити, що кожне посилання:

      1. це валідний ME визначених типів вище

      2. належить пацієнту ($.subject)

        1. в разі помилки - повернути 422 (<Medical event resource> with such ID is not found')

    4. В разі, якщо деякі ресурси наявні в активному правилі, перевірити, що вони відповідають конфігурації по правилу

      1. в разі помилки - повернути 409 ('Submitted patient category does not correspond to rule engine rule')

  14. Перевірити note

    1. Перевірити, що значення типу строковий

      1. в разі помилки - повернути 422 ('type mismatch. Expected string but got {entered type}')

  15. Перевірити patient

    1. В разі, параметри по пацієнту наявні в активному правилі, отримати дані згідно предмету та перевірити, що вони відповідають конфігурації правил

      1. в разі помилки - повернути 409 ('Submitted patient category does not correspond to rule engine rule')

    2. В разі наявності даних по погашенню рецепту в активному правилі, отримати дані погашення рецепту в контексті пацієнта (згідно предмету) та перевірити, що вони відповідають конфігураційним параметрам

      1. в разі помилки - повернути 409 ('Submitted patient category does not correspond to rule engine rule')

Перевірка первинного ключа

  1. Перевірити, що ID всіх вказаних сутностей в масиві унікальні

    1. перевірити, що $.{collection}[*].id з беклогу є всі унікальні серед вказаних

      1. в разі помилки повернути 409 "All primary keys must be unique"  

    2. перевірити, що відсутні сутності з таким id у відповідній колекції медичних подій

      1. в разі помилки повернути 422 "{Entity} with such id already exists"

Перевірка посилань

Дана валадція використовується для перевірки посилання на дані медичних подій з колекції пацієнта. 

  1. Перевірити, що $..identifier.value це існуюче значення з $..identifier.type.coding[0].code в колекції базі даних та він належить пацієнту АБО це значення з відповідної колекції в поточному запиті 

    1. в разі помилки повернути 422 "There is no {$..identifier.type.coding[0].code} with such id"

  2. Перевірити, що дана сутність не в статусі entered_in error

    1. в разі помилки повернути 422 "Could not reference entity in status entered_in_error"

Приклад:

"identifier": { "type": { "coding": [ { "system": "eHealth/resources", "code": "observation" } ] }, "value": "9183a36b-4d45-4244-9339-63d81cd08d9c" } }

В даному разі перевірити, що "9183a36b-4d45-4244-9339-63d81cd08d9c" це існуюче обстеження з колекції пацієнтів та він не в статусі entered_in_error.

Перевірка виконавця

  1. випадок $..primary_source==true

    1. $..performer(or $..asserter) must be filled

      1. в разі помилки повернути "Performer (asserter) must be filled"

    2. $..report_origin must be absent

      1. в разі помилки повернути "Report_origin can not be submitted in case primary_source is true" 

    3. перевріти, що виконавець це валдіне значення з відповідного довідника

      1. $..performer.identifier.type.coding[*].system == "eHealth/resources"

        1. в разі помилки повернути "Submitted system is not allowed for this field"

      2. $..performer.identifier.type.coding[*].code=="employee"

        1. в разі помилки повернути "Submitted code is not allowed for this field"

    4. перевірити, що виконавець є активний лікар з поточного legal_entity

      1. $..performer.identifier.value є ID існуючий співробітник в PRM.employee

        1. в разі помилки повернути "Employee with such id is not found"

      2. $..performer.identifier.value == PRM.employees.id де (PRM.employees.status == "APPROVED" та PRM.employees.employee_type=="DOCTOR" або "SPECIALIST") (в разі обстеження також ASSISTANT)

  2. випадок primary_source==false

    1. $..report_origin повинен бути заповнений

      1. в разі помилки повернути "Report_origin must be filled"

    2. якщо $..primary_source==false то $..performer(asserter) повинен бути відсутній

      1. в разі помилки повернути "Performer(asserter) can not be submitted in case primary_source is false" 

    3. перевірити report_origin

      1. $..report_origin.coding[*].system == "eHealth/report_origins"

        1. в разі помилки повернути "Submitted system is not allowed for this field"

Перевірка періоду

  1. $..period.start <= current_dateTime

    1. в разі помилки повернути 422- "Start date must be in past"

  2. якщо $..period.end заповнено:

    1. $..period.end > visit.period.start

      1. в разі помилки повернути 422 - "End date must be greater than the start date"

Перевірка співробітника

Користувачі не повинні посилатися на співробтіників з різних юридичних осіб. Співробітники не в статусі `approved` також не можуть бути вказані.

  1.  $...identifier.value існує в PRM.employees

    1. в разі помилки 409 "Employee not found"

  2. $...identifier.value == PRM.employees.id де (PRM.employees.status == "APPROVED" та PRM.employees.legal_entity==token.client_id)

    1. в разі помилки 409 "Submitted employee is not an active employee from current legal entity"

Перевірки пов'язаного плану лікування

  1. Якщо сутності (encounter.incoming_referral, procedure.based_on, diagnostic_report.based_on) має посилання на направлення перевірити можливість створення EDP в залежності від service_request[].activity з вказаною кількістю

    1. розрахувати кільксть артефактів, які містяться в $.activity.outcome_reference по service_request.based_on[].activity[].id

    2. розрахувати кільксть артефактів, які містяться в запиті та мають посилання на направлення

    3. порівняти кількість з outcome_reference з кількістю артефактів

    4. перевірити, що різниця більше або дорівнює нулю

      1. в разі помилки повернути 409 "The total amount of the prescribed service quantity exceeds quantity in care plan activity"

Постобробка

  1. Зберегти signed_content до сховища даних

  2. Зберегти дані до відповідної колекції в базі даних

  3. Зберегти посилання на підписний контент до взаємодії

  4. Доповнити encounter.diagnoses:

    1. вибрати condition.code з бази даних по медичим подіям (або з тіла запиту)  де condition.id==diagnoses[@].condition.identifier.value 

    2. встановити diagnoses[@].code = select 1

  5. Зберегти дагнози зі взаємодії до episodes.current_diagnoses

    1. ME.patients.episodes.diagnoses = $.encounter.diagnoses 

  6. Додати запис до ME.patient.episodes{episode_id}.diagnoses_hstr

    1. date = current_date

    2. evidence = reference to encounter  ($.encounter.id)

    3. diagnoses = $.encounter.diagnoses 

  7. Встановити display_value для співробітників для всіх вказаних об'єктів

    1. Вибрати PRM.parties.first_name, PRM.parties.second_name, PRM.parties.last_name з PRM.parties де (PRM.parties.id == (Select PRM.employees.party_id з  PRM.employees де PRM.employees.id== $.care_manager.identifier.value))

    2. ME.patients.encounters{encounter_id}.performer.display== Select 1

    3. ME.conditions{condition_id}.asserter.display == Select 1

    4. ME.observations{observation_id}.performer.display == Select 1

    5. ME.patients.immunizations{immunization_id}.performer.display == Select 1

    6. ME.patients.allergy_intolerance{ai_id}.asserter.display == Select 1

    7. ME.patients.devices{device_id}.asserter.display == Select 1

    8. ME.patients.medication_statements{ms_id}.asserter.display == Select 1

    9. ME.patients.risk_assessment{rs_id}.asserter.display == Select 1

    10. ME.patients.diagnostic_reports{dr_id}.performer.reference.display == Select 1

    11. ME.patients.diagnostic_reports{dr_id}.recorded_by.reference.display == Select 1

    12. ME.patients.diagnostic_reports{dr_id}.results_interpreter.reference.display == Select 1

  8. В разі наявності реакції ($.observations[?].reaction_on) в запиті, оновити вказані щеплення з реакцією:

    1. Встановити в ME.patient.immunization.reaction.detail $.observation.id як посилання
      примітка: $.observations[?].reaction_on should not be saved in observation, only in corresponding immunization

  9. Встановити display_value для legal_entities

    1. ME.patients.diagnostic_reports{dr_id}.managing_organization.display

  10. Встановити managing_organization для вказаних observations, conditions, encounter

    1. ME.conditions{cond_id}.managing_organization=token.client_id

    2. ME.observations{observ_id}.managing_organization=token.client_id

    3. ME.encounters{encounter_id}.managing_organization=token.client_id

  11. В разі encounter.incoming_referral було заповнено, встановити episode_origin до взаємодії

    1. Вибрати візит де id== (вибрати ME.encounter.episode.identifier.value де encounter.id==(вибрати ME.service_requests.context.identifier.value де id==$.encounter.incoming_referral.identifier.value))

  12. В разі diagnostic_reports.based_on було заповнено, встановити episode_origin до дігностичного звіту

    1. Вибрати візит де id== (вибрати ME.encounter.episode.identifier.value де encounter.id==(вибрати ME.service_requests.context.identifier.value де id==$.diagnostic_reports.based_on.identifier.value))

  13. В разі encounter.incoming_referral було заповнено, встановити $.encounter.id та зв'язати $.service_request activity[].outcome_reference

  14. В разі procedures.based_on було заповнено, встановити $.procedures.id та зв'язати $.service_request $.activity[].outcome_reference

  15. В разі diagnostic_reports.based_on було заповнено, встановити $.diagnostic_reports.id та зв'язати $.service_request activity[].outcome_reference

  16. Оновити $ .activity.status до in_progress якщо попередній активний статус було заплановано

  17. Оновити параметр $ .activity.remaining_quantity шляхом віднімання кількості артефактів, які мають посилання на сервіс, що містять $.based_on.[]activity

  18. Збагатити дані взаємодії даними performer speciality:

    1. SELECT speciality -> 'speciality' FROM employees WHERE speciality ->> 'speciality_officio' = 'true' AND id = $.encounter.performer.identifier.value

    2.  Встановити encounter.performer_speciality як тип CodeableConcept системи = SPECIALITY_TYPE

  19. В разі encounter.clinical_impression наповнити даними з $.context_episode_id в моделі даних clinical_impressions (encounters.context.[].episode.value=clinical_impression.context_episode_id)

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