Introduction

СТОРІНКА ВТРАТИЛА АКТУАЛЬНІСТЬ ЧЕРЕЗ ЗМІНИ ЗА ЗАПИТОМ https://e-health-ua.atlassian.net/browse/CR-213

This page describes requirements, configurations and validations of encounter data package specific for type COVID

All medical cases related to COVID-19 (suspicion, laboratory investigations, ambulatory etc) must be submitted to eHealth system via Encounter Package with type covid

Specification

Apiary. Submit Encounter Data Package

Key features

Validations

Authorization

1. Verify the validity of access token

   1. in case of error return 401 ('Access denied')

2. Check user scope encounter:write in order to perform this action

   1. in case of error generate 403 response ('Invalid scopes')

Request validation

Note: No update operations are allowed. All IDs, submitted as PK, should be unique for eHealth. 

1. Validate patient status

   1. db.patients.status for this patient must be "active"

      1. in case of error return 409 - "Patient is not active"

2. Validate request according to JSON Schema

   1. Return 422 with list of validation errors in case validation fails 

3. Validate Visit

   1. $.visit is optional in request. You can create new or reference existing one in encounter object

   2. If $.visit is present in request

      1. $.visit.id is unique

         1. in case of error return 422 - "Visit with such id already exists"

      2. $.visit.end is filled

         1. in case of error return - "End date of visit must be filled"

   3. Period Validation

4. Verify signed content and signer

   1. Verify signed content

   2. Validate that Signer belongs to the managing_organization

      1. validate that there is at least one employee in managing_organization with such drfo (Signer DRFO)

5. Validate encoded signed content according to JSON Schema (link)

   1. Return 422 with list of validation errors in case validation fails

Validate Legal Entity Type

Validate legal entity from token: legal_entities.type should be in me_allowed_transactions_le_types and legal_entities.status =='active' 

Validate encounter

1. Validate encounter id as a primary key

2. Validate that the date is within acceptable limits

   1. $.encounter.date is required

   2. $.encounter.date <= current_date

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

3. Validate "episode" is an active episode that belongs to the current patient

   1. $.encounter.episode is required

   2. $.encounter.episode.identifier.value is one of  ME.patinet{patient_id}.episodes{*}.id

      1. in case of error return 422 "Episode with such ID is not found"

   3. $.encounter.episode.identifier.value is an ID of an Episode that meets the requirements:

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

         1. in case of error return 422 "Episode is not active"

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

         1. in case of error return 422 "Managing_organization in the episode does not correspond to user`s legal_entity"

4. Validate "visit" is a visit that belongs to the current patient

   1. $.encounter.visit is required

   2. $.encounter.visit.identifier.value=$.visit.id  OR  ID of already existing Visit in ME.patient{patient_id}.visit.id

      1. in case of error return 422 "Visit with such ID is not found"

5. Validate referrals

   1. As a referral it can be referenced electronic (registered in the system) OR paper service request

   2. Validate ($.encounter.incoming_referrals OR $.encounter.paper_referral) or none in request

   3. Validate incoming referrals as  References

   4. Validate paper referral as Object (paper_referral)

   5. Validate incoming referrals that corresponds to $.encounter.incoming_referrals[*].identifier.value have:

      1. ..used_by_legal_entity.identifier.value==token.client_id OR null

         1. in case of error return 409 "Service request is used by another legal_entity"

      2. ..status==active or program_processing_status=in_progress (any status is valid in case program_processing_status= in_progress)

         1. in case of error return 409 "Invalid service request status"

      3. ..if program is defined program_processing_status=new, in_queue or in_progress

6. Validate performer

   1. $.encounter.performer is required

   2. $.encounter.performer.identifier.value is an ID of existing employee in PRM.Employees

      1. in case of error return "There is no Employee with such id"

   3. $.encounter.performer.identifier.value  == PRM.Employees.id where (PRM.Employees.status==`active`)

      1. in case of error return "Employee is not active"

   4. $.encounter.performer.identifier.value  == PRM.Employees.id where (PRM.Employees.legal_entity== client_id)

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

7. Validate division

   1. $.encounter.division is required

   2. $.encounter.division.identifier.value must meet the following requirements

      1. PRM.division.status = "ACTIVE"

         1. in case of error return 409 "Division is not active " 

      2. PRM.division.legal_entity= token.client_id

         1. in case of error return 409 "User is not allowed to create encounters for this division"

8. Validate supporting_info as References

9. Validate encounter.class 

   1. according to legal_entity.type - use config file (legal_entity_episode_types)

      1. in case error return 409, msg "Encounter.class $class is forbidden for your legal entity type"

   2. according to episode.type - use config file (episode_type_encounter_classes)

      1. in case error return 409, msg "Encounter.class $class is forbidden for your episode type"

10. Validate encounter.type == covid

11.  Validate diagnoses 

    1. $.encounter.diagnoses is required

    2. Validate conditions as  References

    3. Validate encounter has exactly one diagnosis where $.encounter.diagnoses[?(@.role.coding[0].code=="primary")]

       1. in case of error return 422 "Encounter must have exactly one primary diagnosis"

    4. Validate condition.id is in DB or in current Encounter package 

    5. Validate that each condition is active (verification_status != entered_in_error)

       1. in case of error return 409 "Conditions in diagnoses must be active"

    6. Validate that primary diagnosis defined in the system that corresponds to encounter class validations

       1. in case of error "Primary diagnosis should be defined in {$.encounter.diagnoses[*].role.coding[*].system } system"

12. Validate reasons

    1. $.encounter.reasons is required

    2. Validate that reasons are defined in the eHealth/ICPC2/reasons system

13. Validate service presence according to encounter class validations

    1. in case error return 409, msg "At least one of action references, diagnostic reports or procedures should exist in encounter package"

14. Validate incoming referrals. If incoming referrals exists and encounter.class =='AMB" and encounter.type <>  "patient_identity" validate service for encounter.actions OR diagnostic_report.code OR procedure.code

    1. If service_requests.code.identifier.value is service, validate $resourse.code.identifier.value = service_requests.code.identifier.value

       1. in case error return 409, "Service in $resourse differ from service in service request"

    2. if service_requests.code.identifier.value is service_group, validate $resourse.code.identifier.value in (SELECT service_id from service_inclusions where service_group_id='service_requests.code.identifier.value')

       1. in case error return 409, "Service in $resourse differ from services in service request's service_group"

    3. Validate $resourse.service.is_active = true

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

Validate actions and action_references

Validate Immunizations

See validations on submit encounter data package page

Validate Allergy Intolerances

See validations on submit encounter data package page

Validate Risk Assessments

See validations on submit encounter data package page

Validate Devices

See validations on submit encounter data package page

Validate Medication Statement

See validations on submit encounter data package page

Validate Medication Administration

See validations on submit encounter data package page

Validate Diagnostic Report

See validations on submit encounter data package page

Validate Procedures

See validations on submit encounter data package page

Primary key validation

1. Validate that IDs of all submitted entities in the array are unique

   1. validate that $.{collection}[*].id from the payload are all unique among themselves

      1. in case of error return 409 "All primary keys must be unique"  

   2. validate there is no entity with such id in the corresponding Medical events collection

      1. in case of error return 422 "{Entity} with such id already exists"

Reference validation

This validation is used to validate references to medical events data from patient's collection. 

1. Validate that $..identifier.value is an existing value from $..identifier.type.coding[0].code collection in DB and it belongs to the patient OR it is a value from corresponding collection in the current request 

   1. in case of errror return 422 "There is no {$..identifier.type.coding[0].code} with such id"

2. Validate that this entity is not in status entered_in error

   1. in case of errror return 422 "Could not reference entity in status entered_in_error"

Performer(asserter) validation

1. case $..primary_source==true

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

      1. in case of error "Performer (asserter) must be filled"

   2. $..report_origin must be absent

      1. in case of error "Report_origin can not be submitted in case primary_source is true" 

   3. validate performer(asserter) is a valid value from corresponding dictionary

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

         1. in case of error "Submitted system is not allowed for this field"

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

         1. in case of error "Submitted code is not allowed for this field"

   4. validate performer(asserter) is a active employee from current legal_entity

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

         1. in case of error "Employee with such id is not found"

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

2. case primary_source==false

   1. $..report_origin must be filled 

      1. in case of error "Report_origin must be filled"

   2. if $..primary_source==false then $..performer(asserter) must be absent

      1. in case of error "Performer(asserter) can not be submitted in case primary_source is false" 

   3. validate report_origin

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

         1. in case of error "Submitted system is not allowed for this field"

Employee validation

Users can not reference employees between different legal entities. Employee that is not in status `approved` can not be referenced as well.

1.  $...identifier.value exists in PRM.employees

   1. in case of error 409 "Employee not found"

2. $...identifier.value == PRM.employees.id where (PRM.employees.status == "APPROVED" and PRM.employees.legal_entity==token.client_id)

   1. in case of error 409 "Submitted employee is not an active employee from current legal entity"

References

1. https://e-health-ua.atlassian.net/wiki/x/BwAnMw