Required parameters are marked with "*"
Якщо інформації по відповідному параметру немає, потрібно зазначити: “API paragraph not found”.
Purpose*
This method must be used to register new Service Request in the eHealth.
Specification*
Logic*
This method must be used to register new Service Request in the eHealth. Method receives signed message (pkcs7) that consists of signed content, digital signature and signer public key. All signature fields will be validated (including signer certificate authority). Service will store signed copy of Service Request in Media Content Storage if all checks is passed.
Signed content consists of JSON object with Service Request data.
It can be processed in both sync and async methods depends on Server decision.
Input parameters
Input parameter | Values | Type | Description | Example |
---|---|---|---|---|
patient_id | String | Unique patient identifier |
|
Request structure*
See on Apiary
Example:
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')
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
api-key:aFBLVTZ6Z2dON1V
Request data validation*
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
Ensure that digital signature is valid
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; |
2.3. Determine employees related to this party_id in current MSP
WHERE pu.user_id = :user_id; AND e.legal_entity_id = :client_id; |
2.4 Ensure that $.requester.identifier.value matches with user employees
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
Validate that service request ID is unique
$.id must be unique
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 encounter number
$.requisition must match with patient's encounter of care number
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"
in case of error return 409 "Incorrect service request category"
in case service was defined as a code (not a service_group) validate service_request.category=service.category from $code.identifier.value
in case error return 422, "Category mismatch"
if category in (hospitalization, transfer_of_care), do not validate service_request.category=service.category from $code.identifier.value
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')
check if patients.preperson == true
check PREPERSON_SERVICE_REQUEST_ALLOWED_CATEGORIES (values from dictionary: eHealth/SNOMED/service_request_categories) configuration according allowed categories for prepersons
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')
if category = transfer_of_care,
validate encounter.hospitalization.Discharge_Disposition='transfer_general', in case error return 422, "Context is not valid for service request with type $type"
Occurence is a valid date-time in the future
$.occurrenceDateTime
$.occurrence_date_time - ISO date must be greater current date-time
$.occurrencePeriod.start
$.occurrence_period.start - ISO date must be greater than current date-time
$.occurrence_period.end - ISO date must be greater than current date-time and greater than $.occurrencePeriod.start
in case based_on passed in request
if care plan activity has detail.scheduled_timing.repeat.bounds_period - validate occurence within bounds_period
if care plan activity has detail.scheduled_period - validate occurence within scheduled_period
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 and employee.type=value from list of employee_types in configuration: ALLOWED_SERVICE_REQUEST_REQUESTER_EMPLOYEE_TYPES )
Requester is one of current user's employee
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) within specified patient.
$.supporting_info.identifier.type.coding[*].system == "eHealth/resources"
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")
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"
in case of error return 409 "Incorrect permitted episode"
Validate that permitted episodes is not specified in case of category "laboratory_procedure"
in case of error 422 "Permitted episodes are not allowed for laboratory category of service request"
Validate expiration_date is in future
in case of error return 422 "Expiration date can not be in past"
Validate code is an existing service or service group that is allowed to be used in service_request
Note. For service_request.code pass "service", "service_group"in case not found or is_active == false return 422 "Service(Service group) not found"
if request_allowed==false return error 422 "Request is not allowed for this service"
in case based_on passed in request
If service_requests.code.identifier.value is service, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value
in case error return 409, "Service in care plan activity differ from service in service request"
If service_requests.code.identifier.value is service_group, validate $based_on[].activity.code.identifier.value = service_requests.code.identifier.value
in case error return 409, "Service group in care plan activity differ from service group in service request"
If program was specified, validate it is an existing service program (type=service)
in case not found or is_active==false return 422 "Program not found"
in case type!= service return 422 "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")
check that program equal to $.activity[].program
in case of error return 422 with msg ("Program from activity should be equal to program from request")
If program was specified, validate that service(or service_group) is an active member of the program
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
if not found or is_active==false return 422 "Service is not included in the program"
if request_allowed==false return 422 "Service request is not allowed for this service(service_group) in this programm"
Validate performer
if category = transfer_of_care,
performer is sent, in case error return 422, "performer is mandatory for category `transfer_of_care`"
performer is real LE with status=Active and is_Active=true, in case error, return 422, "performer is not active legal entity"
validate LocationReference
if category = transfer_of_care,
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"
LocationReference division.legal_entity_id=Performer, in case error return 422, "Division does not belong to performer legal entity"
Validate PerformerType
if category = hospitalization
PerformerType is sent, in case error return 422, "PerformerType is mandatory for category hospitalization"
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"
if performer_type value is included in chart variables 'SERVICE_REQUEST_PERFORMER_TYPE_SPECIALITY_TYPES':
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“
if category = transfer_of_care
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
in case error return 422, "PerformerType is mandatory"
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"
if performer_type value is included in chart variables 'SERVICE_REQUEST_TRANSFER_OF_CARE_PERFORMER_TYPE_SPECIALITY_TYPES':
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“
Validate based_on
If submitted, check field has array with two values of Reference type: one is valid Care plan resource, another - Activity resource.
in case of error return 422 with msg ("expected a minimum of %{min} items but got %{actual}")
Verify Care plan:
It should belong to the same person as set in service request
in case of error return 422 with msg ("Care plan with such id is not found")
It should be in active status
in case of error return 422 with msg ("Care plan is not active")
Verify submitted Activity:
It belongs to the Care plan.
It has activity.detail.kind=service_request; activity.detail.product_reference=service_request.code[].value
in case of error return 422 with msg ("Invalid activity kind")
It has scheduled, in_progress status
in case of error return 422 with msg ("Invalid activity status")
If activity.program submitted than $.service_request.program with equal value should be present in request
in case of error return 409 with msg ('Program from activity should be present in request')
if activity.quantity was set, then validate activity.remaining_quantity greater then zero:
in case of error return 409 "The number of available services according to the care plan activity has been exhausted"
Validate patient's verification status:
If SR has based_on with valid activity, then skip this validation.
Else check patient's verification_status is not equal to NOT_VERIFIED.
in case of error return 409, "Patient is not verified"
Processing*
Service logic
Generate requisition number (see Human readable requisition number) based on encounter id
Save signed content to media storage
Save data to corresponding collection in DB
Save link to the signed content in service request storage
If program was specified, change program_processing_status to New
Send SMS notification
If patient's default authentication method determined by Determination of a default authentication method and return person's active auth_methods is OTP or third_person.OTP, send SMS to that patient with requisition number
In order to optimize the costs, only one sms should be sent within one encounter. So that send sms only for the first service request for specific encounter
Search for service requests with the same requisition number
if there is at least one service request with such number - do not send sms
if no service requests found - send sms to the patient
Response structure*
See on Apiary
Example:
Post-processing processes*
API paragraph not found