Introduction

Specification

Apiary

Validations

Authorization

1. Verify the validity of access token
   1. in case of error return 401 ('Access denied')
2. Check user scope service_request:write in order to perform this action
   1. in case of error generate 403 response ('Invalid scopes')

Validate digital signature

Decode content that is encrypted in an electronic digital signature.
Use Digital signature WS. Method checks digital signature and returns result.
See service specification

1. Ensure that digital signature is valid

2. Validate that requester of service request is a current user

2.1. Get token metadata

• Extract user_id, client_id, client_type

2.2. Determine the party_id associated with this user_id

SELECT pu.party_id
FROM party_users pu
WHERE pu.user_id = :user_id;

SELECT e.id
FROM employees e
WHERE e.party_id = :party_id
AND e.legal_entity_id = :client_id;

3. Validate that DS belongs to the requester of encounter

3.1. Determine the party_id associated with requester ($.requester.identifier.value)

SELECT p.tax_id
FROM employees e, parties p
WHERE e.party_id = p.id
AND e.id = :requester;

Validate request using JSON Schema

Return 422 with the 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 service request

1. Validate that service request ID is unique
   1. $.id must be unique
      1. in case of error return 409 - "Service request with such id already exists"
2. Requisition is a common identifier for the group of service requests and it must matches with one of the patient's episode of care number
   1. $.requisition must match with patient's episode of care number
      1. in case of error return 409 - "Incorrect requisition number"
3. Service request category must refer to a valid dictionary
   1. $.category.coding[*].system  == "ehealth/SNOMED/service_request_categories" 
      1. in case of error return 409 "Incorrect service request category"
4. Validate  code as a Reference(service_group/service)
5. Validate that service or group submitted as a code has request_allowed==true
6. Validate category, in case service was submitted as a code
   1. if service.code.identifier.type.coding[].code=="service" than service.code.identifier should reference service from PRM.services where category is empty or equal to service.category
7. Context must be an active encounter
   1. $.context.identifier.type.coding[*].system == "eHealth/resources"
   2. $.context.identifier.type.coding[*].code == "encounter"
   3. $.context.identifier.value refer to existing encounter (status == 'finished')
8. Occurence is a valid date-time in the future
   1. $.occurrenceDateTime 
      1. $.occurrence_date_time - ISO date must be greater current date-time
   2. $.occurrencePeriod.start
      1. $.occurrence_period.start - ISO date must be greater than current date-time
      2. $.occurrence_period.end - ISO date must be greater than current date-time and greater than $.occurrencePeriod.start
9. Authored On is a valid date-time in the past
   1. $.authored_on - ISO date must be less than current date-time
10. Requester must be active employee within current legal entity
    1. $.requester.identifier.type.coding[*].system == "eHealth/resources"
    2. $.requester.identifier.type.coding[*].code == "employee"
    3. $.requester.identifier.value refer to active employee within current legal entity (employee.status == approved and employee.is_active == true and employee.legal_entity_id == token.client_id)
11. Requester is one of current user's employee
    1. in case of error return 422 "User is not allowed to create service request for the employee"
12. Supporting info must refer to a valid medical events object (Episode of Care) within specified patient. 
    1. $.supporting_info.identifier.type.coding[*].system == "eHealth/resources"
       1. in case of error return 409 "Incorrect supporting info"
13. Reason reference must refer to a valid medical events object (Observation, Condition) within specified patient. 
    1. $.reason_reference.identifier.type.coding[*].system == "eHealth/resources"
    2. $.reason_reference.identifier.type.coding[*].code in ("condition", "observation")
       1. in case of error return 409 "Incorrect reason reference"
14. Permitted Episode of care must refer to a valid medical events object (Episode of Care) within specified patient. 
    1. $.permitted_episodes.identifier.type.coding[*].system == "eHealth/resources"
    2. $.permitted_episodes.identifier.type.coding[*].code == "episode_of_care"
       1. in case of error return 409 "Incorrect reason reference"
15. Validate permited peisodes as references - DEPRECATED - Create Service Request V2#Referencevalidation
16. Validate that permitted episodes is not specified in case of category "laboratory"
    1. in case of error 422 "Permitted episodes are not allowed for laboratory category of service request"
17. Validate expiration_date is in future
    1. in case of error return 422 "Expiration date can not be in past"
18. Validate code is an existing service or service group that is allowed to be used in service_request
    1. in case not found or is_active == false return 422 "Service(Service group) not found"
    2. if request_allowed==false return 422 "Service request is not allowed for this service(service_group)"
19. If program was specified, validate it is an existing service program (type=service)
    1. in case not found or is_active==false return 422  "Program not found"
    2. in case type!= service return 422 "Invalid program type"
20. If program was specified, validate that service(or service_group) is an active member of the program
    1. Select request_allowed, is_active from PRM.program_services where service_id(or group_id) == $.signed_content.code.identifier.value and program_id=$.program.identifier.value
       1. if not found or is_active==false return 422 "Service is not included in the program"
       2. if request_allowed==false return 422 "Service request is not allowed for this service(service_group) in this programm"
21. If program was specified, validate that doctor is allowed to create service request with the program for the current patient
    1. Doctor has an active declaration with the patient in current MSP (declaration.legal_entity_id==token.client_id) OR
    2. Doctor works in the same MSP with doctor that has an active declaration with the patient AND doctors employee_type=DOCTOR
       1. in case of error return 409 "Doctor is not allowed to create service request with the program for the patient"
22. Validate service category is equal to service request category in case service was defined as a code (not a service_group)
    1. Select category from PRM.services where id = $.code.identifier.value
       1. if PRM.services.category!=$.category OR PRM.services.category is not NULL  return 422 "Service category does not match with service request category"

Reference validation

1. Validate that $..identifier.value is an existing value from $..identifier.type.coding[0].code collection in DB and it belongs to the patient
   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"

Example:

In this case validate that "9183a36b-4d45-4244-9339-63d81cd08d9c" is an existing episode_of_care from patients collection and it is not entered_in_error.

Service logic

1. Generate requisition number (see Human readable Service request requisition number)
2. Save signed content to media storage
3. Save data to corresponding collection in DB
4. Save link to the signed content in service request storage
5. If program was specified, change program_processing_status to New

Notes

1. Валидация данных из supporting info на вхождение в эпизоды, которые выбраны для организации доступов
2. Валидация данных из reasonReference на вхождение:
   1. в эпизод, к которому относится энкаунтер, на основании которого создан реферрал
   2. в эпизоды, которые выбраны для организации доступов
3. Валидация соответствия пациента в рецепте пациенту в энкаунтере, на основании которого создается рецепт