Properties of a REST API method document

Purpose

This WS is designed to use Service request after providing services.

Logic

Погашення направлення

Service logic

1. Update program_processing_status to "completed" if it was not null

2. Update status to "completed"

3. Depending on changes update a status history and program_processing_status history

4. Save  status_reason to service_request, including status_history

5. Save completed_with, program_service to service_request

6. If the service request is based on activity with quantity:

   1. Recalculate and set remaining_quantity for the activity as described at PreQualify Service Request | Validate service request

Configuration parameters

N/A

Dictionaries

N/A

Input parameters

Request structure

See on API-specification

Headers

Headers

Request data validation

Authorize

• Verify the validity of access token

  • in case of error - return 401 (“Invalid access token”) in case of validation fails

• Verify that token is not expired

  • in case of error - return 401 (“Invalid access token”)

• Check user scopes in order to perform this action (scope = 'service_request:complete')

  • return 403 (“Your scope does not allow to access this resource. Missing allowances: service_request:complete”) in case of invalid scope(s)

Validate legal entity

• Check legal entity type: it has to be in me_allowed_transactions_le_types config parameter, has status = active 

  • in case of error return 409 "Action is not allowed for the legal entity"

Validate request using JSON Schema

Return 422 with the list of validation errors in case validation fails

Validations

1. Validate used_by_legal_entity

   1. ME.service_request.used_by_legal_enity.identifier.value=token.client_id

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

2. Validate program_processing_status                                     

   1. ME.service_request.program_processing_status  == "in_progress"

      1. in case of error return 409 "Invalid program processing status status"

3. Validate completed_with if exist:

   1. $.completed_with as a Reference(encounter| diagnostic_report| procedure)

   2. if ME.service_request.category and resource according to config file

   3. $.completed_with.managing_organization== token.client_id

      1. Could not complete service request with an entity, created by another legal entity

   4. SR could be completed only with resource that referenced this SR

      1. in case error return 422, msg "$completed_with.code is not connected with this SR"

   5. If SR.category in ('hospitalization', 'transfer_of_care') validate resource is encounter.type = discharge

      1. in case error, return 422, "Service request with category $category could not be completed with current resource"

   6. if $.completed_with.identifier.code == “encounter”:

      1. check that episode from encounters.episode has status “active”

         1. in case of error return 422 “Encounter refers to episode that is not active"

   7. Check resource status:

      1. If resource is procedure, check that procedure.status not in (entered_in_error, not_done)

      2. Else check that resource.status != entered_in_error

         1. in case error, return 422, "<Resource> in <status> status can not be referenced"

4. Validate program_service

   1. $.program_service is an existing record from PRM.program_services where is_active=true

      1. in case of error return 422 "Program service does not exist"

   2. $.program_service should be only as a service (check that PRM.program_service.service_id IS NOT NULL)

      1. in case of error return 422 "Program service with service group is not allowed for completing current resource"

5. Validate that service code from completed with and from program service (if both exist) matches (except service requests  where category in ('hospitalization', 'transfer_of_care')):

   1. if completed_with.identifier.type.coding[].code="diagnostic_report" or "procedure" than

      1. completed_with.code.identifier.value==program_service.service_id (enrich from ME and PRM)

   2. else if completed_with.identifier.type.coding[].code="encounter"

      1. if ME.service_request.code.identifier.type.coding[].code="service"

         1. ME.service_request.code.identifier.value==program_service.service_id (enrich from ME and PRM)

      2. if service_request.code.identifier.type.coding[].code="service_group"

         1. there is a record in status active in PRM.service_inclusions where PRM.service_inclusions.service_group_id=ME.service_request.code.identifier.value and  PRM.service_inclusions.service_id=program_service.service_id

   3. in case of error return 409 "Services from program service and completed with does not match"

6. Else, if service request has no program:

7. Validate the service request has been referenced by at least one not entered_in_error procedure/encounter/diagnostic_report.

   1. in case of error - return 409 error ('Service request must be referenced by at least one procedure, encounter or diagnostic_report that is not entered_in_error ')

8. Validate status_reason filled according to eHealth/service_request_complete_reasons dictionary

   1. in case system is another dictionary - return 422 error ('not allowed in enum')

   2. in case code value is not active in corresponding dictionary - return 422 error ("Value is not active")

Validate transition

1. If service request has a program:

   1. Check status is active and program_processing_status is, in_progress.

      1. in case of error - return 409 error ('Service request only in status 'active' and program_processing_status 'in_progress' can be completed')

2. else, if service request has no program:

   1. Check status is ‘active’

      1. in case of error - return 409 error ('Service request only in status 'active' can be completed')

Processing

N/A

Response structure examples

See on API-specification

HTTP status codes

Post-processing processes

N/A

Technical modules where the method is used