Table of Contents

minLevel	1
maxLevel	3

Purpose

Pre-qualify service request in order to define whether the medical program could be applied in this particular case or not

Specification

...

Link

...

https://medicaleventsmisapi.docs.apiary.io/#reference/service-requests/manage-service-requests-in-patient-context/prequalify-service-request

...

Resource

...

/api/patients/{{patient_id}}/service_requests/prequalify

...

Scope

...

service_request:write

...

Components

...

Service request

...

Microservices

...

API paragraph not found

...

Protocol type

...

REST

...

Request type

...

POST

...

Sync/Async

...

Async

...

Public/Private/Internal

...

Public

Logic

This method is used to pre-qualify service request in order to define whether the medical program could be applied in this particular case or not

Input parameters

...

Input parameter

...

Values

...

Type

...

Description

...

Example

...

patient_id

...

String

...

Unique patient identifier

...

7075e0e2-6b57-47fd-aff7-324806efa7e5

Request structure

See on Apiary

Example:

...

title	Response example

...

Table of Contents

minLevel	1
maxLevel	3

Purpose

This WS is designed to prequalify Service request: check the ability of create Service request within the Medical program

Specification

Page Properties

Link	https://medicaleventsmisapi.docs.apiary.io/#reference/service-requests/manage-service-requests-in-patient-context/prequalify-service-request
Resource	/api/patients/{{patient_id}}/service_requests/prequalify
Scope	service_request:write
Components	Service request
Microservices	API paragraph not found
Protocol type	REST
Request type	POST
Sync/Async	Async
Public/Private/Internal	Public

Preconditions

must be an active encounter

Logic

This method is used to pre-qualify service request in order to define whether the medical program could be applied in this particular case or not

Input parameters

Input parameter	Values	Type	Description	Example
patient_id		String	Unique patient identifier	`7075e0e2-6b57-47fd-aff7-324806efa7e5`

Request structure

See on Apiary

Example:

Expand

title	Response example

Code Block

{
  "service_request": {
    "status": "active",
    "intent": "order",
    "priority": "routine",
    "based_on": [
      {
        "identifier": {
          "type": {
            "coding": [
              {
                "system": "eHealth/resources",
                "code": "activitycare_plan"
              }
            ]
          },
          "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
        }
      },
    ],  {
  "category": {       "codingidentifier": {
 [         "type": {
            "systemcoding": "eHealth/SNOMED/service_request_categories",[
           "code": "409063005"  {
      }       ]     },
    "code"system": {"eHealth/resources",
      "identifier": {         "typecode": {
 "activity"
        "coding": [     }
       {     ]
         "system": "eHealth/resources" },
              "codevalue": "service9183a36b-4d45-4244-9339-63d81cd08d9c"
         }
  }    }
      ],
    "category": {
  }     "coding": [
        {
          "system": "eHealth/SNOMED/service_request_categories",
          "valuecode": "9183a36b-4d45-4244-9339-63d81cd08d9c"409063005"
        }
      ]
    },
    "contextcode": {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "encounterservice"
            }
          ]
        },
        "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
      }
    },
    "occurrence_period": {
      "start": "2018-08-02T10:45:16.000Z",
      "end": "2018-08-02T11:00:00.000Z"
    },
    "requester_employee": context": {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "employeeencounter"
            }
          ]
        },
        "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
      }
    },
    "requesteroccurrence_legal_entityperiod": {
      "start": "2018-08-02T10:45:16.000Z",
      "end": "2018-08-02T11:00:00.000Z"
    },
    "requester_employee": {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "legal_entityemployee"
            }
          ]
        },
        "value": "75a6d9919183a36b-0bf74d45-476f4244-b3cf9339-bec83f044b2a63d81cd08d9c"
      }
    },
    "reasonrequester_legal_referencesentity": [
      {
        "identifier": {
          "type": {
            "coding": [
              {
 
              "system": "eHealth/resources",
                "code": "conditionlegal_entity"
              }
 
          ]
          },
 
        "value": "9183a36b75a6d991-4d450bf7-4244476f-9339b3cf-63d81cd08d9cbec83f044b2a"
        }
      }
    ],
    "supportingreason_inforeferences": [
      {
        "identifier": {
          "type": {
            "coding": [
              {
                "system": "eHealth/resources",
                "code": "episode_of_carecondition"
              }
            ]
          },
          "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
        }
      }
    ],
    "notesupporting_info": [
"Some notes",     "patient_instruction": "Some patient instructions",
    "permitted_resources": [
      {
        "identifier": {
          "type": {
            "coding": [
              {
                "system": "eHealth/resources",
                "code": "episode_of_care"
              }
            ]
          },
          "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
        }
      }
    ],
    "performernote": {
 "Some notes",
    "identifierpatient_instruction": {"Some patient   instructions",
    "typepermitted_resources": {[
      {
        "codingidentifier": [{
           "type": {
              "systemcoding": [
              {
                "system": "eHealth/resources",
                "code": "legalepisode_of_entitycare"
              }
            ]
          },
          "value": "c5a6d9919183a36b-0bf74d45-476f4244-b3cf9339-bec83f044b2a63d81cd08d9c"
        }
      }
    ],
    "location_referenceperformer": {
      "identifier": {
        "type": {
          "coding": [
            {
              "system": "eHealth/resources",
              "code": "divisionlegal_entity"
            }
          ]
        },
        "value": "c5a6d991-0bf7-476f-b3cf-bec83f044b2a"
      }
    },
    "performerlocation_typereference": {
      "codingidentifier": [
        {
          "systemtype": "SPECIALITY_TYPE",{
          "codecoding": [
"DIETETICS"         }   {
   ]     }   },   "programssystem": ["eHealth/resources",
       {       "identifiercode": {         "type": {"division"
            "coding":}
[          ]
  {      },
        "systemvalue": "eHealth/resources",c5a6d991-0bf7-476f-b3cf-bec83f044b2a"
      }
    },
    "performer_type": {
      "coding":          "code": "medical_program"
            }
          ]
        },
        "value": "9183a36b-4d45-4244-9339-63d81cd08d9c"
      }
    }
  ]
}

Authorize

Verify the validity of access token
- Return (401, 'unauthorized') in case of validation fails
Verify that token is not expired
- in case of error - return (401, 'unauthorized')
Check user scopes in order to perform this action (scope = 'service_request:write')
1. Return (403, 'invalid scopes') in case of invalid scope(s)

Request to process the request using a token in the headers

Headers

Наприклад:

Content-Type:application/json
Authorization:Bearer mF_9.B5f-4.1JqM

Request data validation

Validate request using JSON Schema

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

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 service request

...

Validate that service request ID is unique

$.id must be unique
1. in case of error return 409 - "Service request with such id already exists"

...

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

$.requisition must match with patient's episode of care number
1. in case of error return 409 - "Incorrect requisition number"

...

Service request category must refer to a valid dictionary

$.category.coding[*].system == "eHealth/SNOMED/service_request_categories"
1. in case of error return 409 "Incorrect service request category"

...

Procedure code must refer to a valid dictionary

$.code.coding[*].system == "eHealth/SNOMED/procedure_codes"
1. in case of error return 409 "Incorrect procedure code"

...

Patient must be active

$.patient.identifier.type.coding[*].system == "eHealth/resources"
$.patient.identifier.type.coding[*].code == "patient"
$.patient.identifier.value refer to active MPI (is_active == true and status == 'active')
in case patients.preperson == true
1. check PREPERSON_SERVICE_REQUEST_ALLOWED_CATEGORIES (values from dictionary: eHealth/SNOMED/service_request_categories) configuration according allowed categories for prepersons
  1. in case of error return 422 (Category of service request is not allowed for prepersons)

...

Context must be an active encounter

$.context.identifier.type.coding[*].system == "eHealth/resources"
$.context.identifier.type.coding[*].code == "encounter"
$.context.identifier.value refer to existing encounter (status == 'finished')

...

Occurence is a valid date-time in the future

$.occurrenceDateTime
1. $.occurrence_date_time - ISO date must be greater current date-time
$.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
in case based_on passed in request
1. if care plan activity has detail.scheduled_timing.repeat.bounds_period - validate occurence within bounds_period
2. if care plan activity has detail.scheduled_period - validate occurence within scheduled_period
3. else - validate occurence within care_plan.period

...

Authored On is a valid date-time in the past

$.authored_on - ISO date must be less than current date-time

...

Requester_employee must be active employee within current legal entity

$.requester_employee.identifier.type.coding[*].system == "eHealth/resources"
$.requester_employee.identifier.type.coding[*].code == "employee"
$.requester_employee.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)

...

Requester_legal_enity must be current legal enity

...

Performer type must refer to a valid dictionary

$.performer_type.coding[*].system == "eHealth/SNOMED/service_request_performer_roles"
1. in case of error return 409 "Incorrect service request category"

...

Supporting info must refer to a valid medical events object (Episode of Care) within specified patient.

$.supporting_info.identifier.type.coding[*].system == "eHealth/resources"
1. in case of error return 409 "Incorrect supporting info"

...

Reason reference must refer to a valid medical events object (Observation, Condition) within specified patient.

$.reason_reference.identifier.type.coding[*].system == "eHealth/resources"
$.reason_reference.identifier.type.coding[*].code in ("condition", "observation")
1. in case of error return 409 "Incorrect reason reference"

...

Permitted Episode of care must refer to a valid medical events object (Episode of Care) within specified patient.

$.permitted_episodes.identifier.type.coding[*].system == "eHealth/resources"
$.permitted_episodes.identifier.type.coding[*].code == "episode_of_care"
1. in case of error return 409 "Incorrect reason reference"

...

Validate code is an existing service or service group that is allowed to be used in service_request

in case not found or is_active == false return 422 "Service(Service group) not found"
if request_allowed==false return 422 "Service request is not allowed for this service(service_group)"
in case based_on passed in request
1. If service_requests.code.identifier.value is service, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value
  1. in case error return 422, "Service in activity differs from service in service request"
2. If service_requests.code.identifier.value is service_group, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value
  1. in case error return 422, "Service group in care plan activity differ from service group in service request"
3. if service_requests.code.identifier.value is service/service group, validate $based_on[].activity.code.identifier.value is service/service group
  1. in case error return 422, "Activity referes to '#{service/service group}' but service request refers to '#{service group/service}'"

...

Validate service category is equal to service request category in case service was defined as a code (not a service_group)

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"

For each program validate it is an existing service program (type=service)

...

in case not found or is_active==false write result in Data collection according to apiary

...

in case type!= service write result in Data collection according to apiary - "Invalid program type"

check if medical_programs.medical_program_settings.care_plan_required == true then the request should contain a based_on with care plan and activity that contains the same medical program

...

in case of error return 422 with msg ("Care plan and activity with the same program should be present in request")

...

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

Authorize

Verify the validity of access token
- Return (401, 'unauthorized') in case of validation fails
Verify that token is not expired
- in case of error - return (401, 'unauthorized')
Check user scopes in order to perform this action (scope = 'service_request:write')
1. Return (403, 'invalid scopes') in case of invalid scope(s)

Request to process the request using a token in the headers

Headers

Наприклад:

Content-Type:application/json
Authorization:Bearer mF_9.B5f-4.1JqM

Request data validation

Validate request using JSON Schema

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

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 service request

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"
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"
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"
2. If $.specimens attribute is set, then check the category is in SPECIMEN_SERVICE_REQUEST_ALLOWED_CATEGORIES chart parameter
  1. in case of error - return 422 ("Service request category is not allowed for specimens")
3. If $.requester_employee has ASSISTANT type, then check the category in ASSISTANT_SERVICE_REQUEST_ALLOWED_CATEGORIES chart parameter
  1. in case of error - return 422 (“Service request category is not allowed for a requester_employee with type ASSISTANT“)
Service request code must refer to a valid dictionary
1. $.code.identifier.type.coding[*].system == “eHealth/resources”
  1. in case of error return 422 “value is not allowed in enum”
Patient must be active
1. $.patient.identifier.type.coding[*].system == "eHealth/resources"
2. $.patient.identifier.type.coding[*].code == "patient"
3. $.patient.identifier.value refer to active MPI (is_active == true and status == 'active')
4. in case patients.preperson == true
  1. check PREPERSON_SERVICE_REQUEST_ALLOWED_CATEGORIES (values from dictionary: eHealth/SNOMED/service_request_categories) configuration according allowed categories for prepersons
    1. in case of error return 422 (Category of service request is not allowed for prepersons)
Context must be an active encounter
1. If focus on specimens is set, then context is optional
2. $.context.identifier.type.coding[*].system == "eHealth/resources"
3. $.context.identifier.type.coding[*].code == "encounter"
4. $.context.identifier.value refer to existing encounter (status == 'finished')
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
3. in case based_on passed in request
  1. if care plan activity has detail.scheduled_timing.repeat.bounds_period - validate occurence within bounds_period
  2. if care plan activity has detail.scheduled_period - validate occurence within scheduled_period
  3. else - validate occurence within care_plan.period
Authored On is a valid date-time in the past
1. $.authored_on - ISO date must be less than current date-time
Requester_employee must be active employee within current legal entity
1. $.requester_employee.identifier.type.coding[*].system == "eHealth/resources"
2. $.requester_employee.identifier.type.coding[*].code == "employee"
3. $.requester_employee.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 .rand employee.type=value from list of employee_types in configuration: ALLOWED_SERVICE_REQUEST_REQUESTER_EMPLOYEE_TYPES )
  1. in case of error - 422 “Invalid employee type”
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"
Requester_legal_enity must be current legal enity
Supporting info must refer to a valid medical events object (Episode of Care, Condition, Observation, Diagnostic report) within specified patient.
1. $.supporting_info.identifier.type.coding[*].system == "eHealth/resources"
  1. in case of error return 409 "Incorrect supporting info"
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"
Permitted resources must refer to a valid medical events object (Episode of Care, diagnostic report) within specified patient.
1. $.permitted_resources.identifier.type.coding[*].system == "eHealth/resources"
2. $.permitted_resources.identifier.type.coding[*].code == "episode_of_care", “diagnostic_report”
  1. in case of error return 409 "Incorrect permitted resources"
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)"
3. in case based_on passed in request
  1. If service_requests.code.identifier.value is service, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value
    1. in case error return 422, "Service in activity differs from service in service request"
  2. If service_requests.code.identifier.value is service_group, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value
    1. in case error return 422, "Service group in care plan activity differ from service group in service request"
  3. if service_requests.code.identifier.value is service/service group, validate $based_on[].activity.code.identifier.value is service/service group
    1. in case error return 422, "Activity referes to '#{service/service group}' but service request refers to '#{service group/service}'"
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"
For each program validate it is an existing service program (type=service)
1. in case not found or is_active==false write result in Data collection according to apiary
2. in case type!= service write result in Data collection according to apiary - "Invalid program type"
3. check if medical_programs.medical_program_settings.care_plan_required == true:
  1. the request should contain a based_on with care plan and activity that contains the same medical program
    1. in case of error return 422 with msg ("Care plan and activity with the same program should be present in request")
  2. check that program present in request
    1. in case of error return 422 with msg ("Program from activity should be present in request")
  3. check that program equal to $.activity[].program
    1. in case of error return 422 with msg ("Program from activity should be equal to program from request")
4. if program in service request is set check if $.activity[].program is not null
  1. in case of error return error msg (“Program should not be present in request for this activity“)
For each program 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 write result in Data collection according to apiary - "Service is not included in the program"
  2. if request_allowed==false write result in Data collection according to apiary - "Service request is not allowed for this service(service_group) in this programm"
Validate performer
1. If focus on specimens is set, then performer is optional
2. if category = transfer_of_care,
  1. performer is sent, in case error return 422, "performer is mandatory for category `transfer_of_care`"
  2. performer is real LE with status=Active and is_Active=true, in case error, return 422, "performer is not active legal entity"
3. if category = laboratory_procedure,
  1. performer is optional; if is send - performer is real LE with status=Active and is_Active=true, in case error, return 422, "performer is not active legal entity"
4. else other category and performer is send return 422 error $.performer.identifier.value “Not allowed for this category“
validate LocationReference
1. if category = transfer_of_care,
  1. LocationReference is real division with type in (CLINIC, LICENSED_UNIT,AMBULANT_CLINIC,FAP) and status=Active and is_active=true, in case error return 422, "LocationReference is not an active division"
  2. LocationReference division.legal_entity_id=Performer, in case error return 422, "Division does not belong to performer legal entity"
Validate PerformerType
1. if category = hospitalization
  1. PerformerType is sent, in case error return 422, "PerformerType is mandatory for category hospitalization"
  2. PerformerType is a code from dictionary.SPECIALITY_TYPE and match config file 'SERVICE_REQUEST_HOSPITALIZATION_SPECIALITY_TYPES', in case error return 422, "PerformerType=$PerformerType is forbidden for category hospitalization"
  3. if performer_type value is included in chart variables 'SERVICE_REQUEST_PERFORMER_TYPE_SPECIALITY_TYPES':
    1. define allowed service codes for service_requests.code.identifier.value using a set of chart variables 'SERVICE_REQUEST_<SPECIALITY_TYPE>_PERFORMER_TYPE_CODES', in case of error return 422 “Service does not correspond to performer's speciality for hospitalization“
2. if category = transfer_of_care
  1. if service codes for service_requests.code.identifier.value using a set of chart variables 'SERVICE_REQUEST_TRANSFER_OF_CARE_<SPECIALITY_TYPE>_PERFORMER_TYPE_CODES', performer_type field is mandatory
    1. in case error return 422, "PerformerType is mandatory"
  2. PerformerType is a code from dictionary.SPECIALITY_TYPE and match config file 'SERVICE_REQUEST_TRANSFER_OF_CARE_SPECIALITY_TYPES', in case error return 422, "PerformerType=$PerformerType is forbidden for category transfer_of_care"
  3. if performer_type value is included in chart variables 'SERVICE_REQUEST_TRANSFER_OF_CARE_PERFORMER_TYPE_SPECIALITY_TYPES':
    1. define allowed service codes for service_requests.code.identifier.value using a set of chart variables 'SERVICE_REQUEST_TRANSFER_OF_CARE_<SPECIALITY_TYPE>_PERFORMER_TYPE_CODES', in case of error return 422 “Service does not correspond to performer's speciality for transfer of care“
3. else other category and PerformerType is send return 422 error $.performer_type.coding[0].value "Not allowed for category <category>"
Validate based_on
1. If submitted, check field has array with two values of Reference type: one is valid Care plan resource, another - Activity resource.
  1. in case of error return 422 with msg ("expected a minimum of %{min} items but got %{actual}")
2. Verify Care plan:
  1. It should belong to the same person as set in service request
    1. in case of error return 422 with msg ("Care plan with such id is not found")
  2. It should be in active status
    1. in case of error return 422 with msg ("Care plan is not active")
  3. Care plan's period end (if exist) should be greater than current date or equal.
3. Verify submitted Activity:
  1. It belongs to the Care plan.
    1. in case of error return 422 with msg ("Activity with such id is not found")
  2. It has activity.detail.kind=service_request; activity.detail.product_reference=service_request.code[].value.
    1. in case of error return 422 with msg ("Program from activity should be equal to program from request")
For each program 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 write result in Data collection according to apiary - "Service is not included in the program"
  2. if request_allowed==false write result in Data collection according to apiary - "Service request is not allowed for this service(service_group) in this programm"
For each program validate that doctor is allowed to create service request with the program for the current patient
1. $.requester has an active declaration with the patient OR
2. $.requester 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 write result in Data collection according to apiary - "User is not allowed to create service request with the program for the patient"
Validate based_on
1. If submitted, check field has array with two values of Reference type: one is valid Care plan resource, another - Activity resource.
  1. 1. Invalid activity kind")
  2. It has scheduled, in_progress status
    1. in case of error return 422 with msg ("Invalid activity status")
  3. if quantity was set, then validate remaining_quantity greater then zero:
    1. if quantity.code = PIECE:
      1. select all active service requests based on current activity and calculate previously reserved quantity as sum of SR.quantity.value.
      2. select all medical events based on not active service requests, that relates to current activity, and count their number as used quantity.
      3. calculate reserved at the moment quantity as sum of previously reserved quantity and used quantity, including quantity from current SR
      4. calculate remaining quantity by subtracting reserved at the moment quantity from activity's quantity
      5. Check remaining quantity is greater then or equal to zero
        in case of error return 422 "The number of available services according to the care plan activity has been exhausted"
    2. if quantity.code = MINUTE:
      1. select all active service requests based on current activity and calculate previously reserved quantity as sum of SR.quantity.value
      2. select all procedures based on not active service requests, that based on current activity, and calculate used quantity as sum of procedure durations (calculates from performed_period attribute)
      3. calculate reserved at the moment quantity as sum of previously reserved quantity and used quantity, including quantity from current SR
      4. calculate remaining quantity by subtracting reserved at the moment quantity from activity's quantity
      5. Check remaining quantity is greater then or equal to zero
        in case of error return 422
    with msg ("expected a minimum of %{min} items but got %{actual}")
  Verify Care plan:
  1. It should belong to the same person as set in service request
    It belongs to the Care plan
    1. 1. "The number of available services according to the care plan activity has been exhausted"
    2. if quantity.code is null:
      1. select all medical events based on service requests, that are related to current activity, and count their number as used quantity.
      2. calculate remaining quantity by subtracting used quantity from activity's quantity
      3. Check remaining quantity is greater then zero
        in case of error return 422
      with msg ("Care plan with such id is not found")
  2. It should be in active status
    1. in case of error return 422 with msg ("Care plan is not active")
  3. Care plan's period end (if exist) should be greater than current date or equal.
  Verify submitted Activity:
  1. 1. 1. "The number of available services according to the care plan activity has been exhausted"
2. Verify activity period:
  1. If it has scheduled_timing:
    1. if bounds_period.end defined then check it greater than current date or equal.
  2. If it has scheduled_period:
    1. if scheduled_period.end defined then check it greater than current date or equal.
Validate patient's verification status:
1. If SR has based_on with valid activity, then skip this validation.
2. Else check patient's verification_status is not equal to NOT_VERIFIED.
  1. in case of error return
    422 with msg ("Activity with such id
    409, "Patient is not
    found
    verified"
    )
    It has activity.detail.kind=service_request; activity.detail.product_reference=service_request.code[].value.
  2. ELSE, if program meets the requirements write status "Valid" according to apiary.

25. Validate quantity

Check it is SimpleQuantity type, $.quantity.value is not empty, fractional and greater than zero
1. in case of error return 422
  with msg ("Invalid activity kind")It has scheduled, in_progress status
  schema validation error
Check $.quantity.system is SERVICE_UNIT dictionary and $.quantity.code belongs to it
1. in case of error return 422
  with msg ("Invalid activity status")if quantity was set, then validate remaining_quantity greater then zero:
  schema validation error
In case based_on passed in request and activity there has a quantity attribute:
1. Validate that system and code in activity's quantity isn’t null
  1. in case of error return 422
    , "The number of available services according to the care plan activity has been exhausted"
2. Verify activity period:
  1. If it has scheduled_timing:
    1. if bounds_period.end defined then check it greater than current date or equal.
  2. If it has scheduled_period:
    1. if scheduled_period.end defined then check it greater than current date or equal.
Validate patient's verification status:
1. If SR has based_on with valid activity, then skip this validation.
2. Else check patient's verification_status is not equal to NOT_VERIFIED.
  1. in case of error return 409, "Patient is not verified"

...

1. 1. (“A service request is not allowed to have a quantity attribute if the quantity in the related activity has no units”)
2. Validate that system and code in activity's quantity match to the system and code in the service request's quantity.
  1. in case of error return 422 ("The quantity units must not differ from the quantity units in the activity"

26. Validate focus, if submitted:

Check field is array with elements of Reference type on Specimen resource
1. in case of error return 422 “not allowed in enum”
Check there is at least one Specimen and it matches those pointed in specimens field:
1. in case of error return 422 “Specimen does not match what is indicated in the specimens field.“

Processing

API paragraph not found

Response structure

See on Apiary

Example:

Expand

title	Response example

Code Block

{
  "meta": {
    "code": 200,
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "data": [
    {
      "program_id": "59781de0-2e64-4359-b716-bcc05a32c10f",
      "program_name": "Fee-For-Service",
      "status": "INVALID",
      "rejection_reason": "Service is not included in the program"
    }
  ],
  "urgent": {
    "authentication_method_current": {
      "type": "OTP",
      "number": "+38093*****85"
    }
  }
}

Expand

title	Response example

Code Block
{ "meta": { "code": "422", "url": "http://example.com/resource", "type": "object", "request_id": "req-adasdoijasdojsda" }, "error": { "type": "unverified", "message": "Patient is not active" } }

Post-processing processes

API paragraph not found

HTTP status codes

Page Properties

HTTP status code	Message	What caused the error
200
422		Validation failed
409		Validation failed

Versions Compared

Old Version 28

New Version Current

Key

Purpose

Specification

Logic

Input parameters

Request structure

Purpose

Specification

Preconditions

Logic

Input parameters

Request structure

Authorize

Headers

Request data validation

Validate request using JSON Schema

Validate legal entity

Validate service request

Authorize

Headers

Request data validation

Validate request using JSON Schema

Validate legal entity

Validate service request

Processing

Response structure

Post-processing processes

HTTP status codes

Page Comparison

Versions Compared

Old Version 28

New Version Current

Key

Purpose

Specification

Logic

Input parameters

Request structure

Purpose

Specification

Preconditions

Logic

Input parameters

Request structure

Authorize

Headers

Request data validation

Validate request using JSON Schema

Validate legal entity

Validate service request

Authorize

Headers

Request data validation

Validate request using JSON Schema

Validate legal entity

Validate service request

Processing

Response structure

Post-processing processes

HTTP status codes