Table of Contents |
---|
Purpose
This WS is designed to create contract request from Legal Entity side by Owner or Admin
Specification
...
id | API_Specification |
---|
...
Link
...
...
Посилання на Apiary або Swagger
...
Resource
...
/api/contract_requests/{{contract_type}}/{{id}}
...
Посилання на ресурс, наприклад: /api/persons/create
...
Scope
...
contract_request:create
...
Scope для доступу
...
Components
...
Contracts
...
Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription
...
Microservices
...
API paragraph not found
...
Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC
...
Protocol type
...
REST
...
Тип протоколу, який використовується запитом, наприклад: SOAP | REST
...
Request type
...
POST
...
Тип запиту API, наприклад: GET, POST, PATCH…
...
Sync/Async
...
API paragraph not found
...
Метод є синхронним чи асинхронним?
...
Public/Private/Internal
...
Public
...
Потрібно зазначити тип методу за ступенем доступності
Preconditions
Before the request is created the documents documents must be uploaded
Logic
Then request can be approved or declined by NHS side.
After that, MSP must approve the request from their side (actual only for Capitation contract).
In case the request was two-side approved, it can be two-side signed.
Using this endpoint a reimbursement contract could be created as well as a capitation contract. The difference between those two types of contract is described here- Reimbursement version Data model
Input parameters
Input is signed data in PKCS7 format. The data must be unpacked and validated using schema (Capitation Contract_request) or JSON schema (Reimbursement Contract_request)
In order to change signed contract contract_number should be send. In this case start_date and end_date are taken from existing contract and should not be present in payload (except in cases of contract prolongation. For these cases, validations are described below).
In case this contract request is changes for another one, the previous contract request id (Create Contract Request#previous_request) should be send in payload.
...
Input parameter
...
Values
...
Type
...
Description
...
Example
...
contract_type
...
CAPITATION
REIMBURSEMENT
...
String
...
Required
...
id
...
String
...
Contract_request ID. Required
...
09106b70-18b0-4726-b0ed-6bda1369fd52
Dictionaries
API paragraph not found
Request structure
Example:
...
title | Request example |
---|
...
Table of Contents |
---|
Purpose
This WS is designed to create contract request from Legal Entity side by Owner or Admin
Specification
Page Properties | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
|
Preconditions
Before the request is created the contract should be initialized the documents must be uploaded.
Logic
After using thit WS request can be approved or declined by NHS side. After that, MSP must approve the request from their side (actually only for Capitation contract).
In case the request was two-sided approved, it can be two-sided signed.
Using this endpoint a reimbursement contract could be created as well as a capitation contract. The difference between those two types of contract is described here- Reimbursement version Data model
Input parameters
Input is signed data in PKCS7 format. The data must be unpacked and validated using schema (Capitation Contract_request) or JSON schema (Reimbursement Contract_request)
In order to change signed contract contract_number should be send. In this case start_date and end_date are taken from existing contract and should not be present in payload (except in cases of contract prolongation. For these cases, validations are described below).
In case this contract request is changes for another one, the previous contract request id (Create Contract Request#previous_request) should be send in payload.
Input parameter | Values | Type | Description | Example |
---|---|---|---|---|
contract_type | CAPITATION REIMBURSEMENT | String | Required | |
id | String | Contract_request ID. Required | 09106b70-18b0-4726-b0ed-6bda1369fd52 |
Request structure
Example:
Expand | ||
---|---|---|
| ||
|
Dummy example (Capitation version):
Expand | ||
---|---|---|
|
Dummy example (Reimbursement version):
Expand | ||
---|---|---|
|
Authorize
Verify the validity of access token
in case of error return 401 ('Invalid access token')
Check user scope contract_request:create in order to perform this action
in case of error generate 401 response ('Invalid access token'
Check user scope contract_request:create in order to perform this action
in case of error generate 401 response ('Invalid access token')
If BLOCK_UNVERIFIED_PARTY_USERS is true, then check party's data match following condition: verification_status != NOT_VERIFIED or (verification_status = NOT_VERIFIED and updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):
in case not match - return 403 ("Access denied. Party is not verified")
Headers
Наприклад:
Content-Type:application/json
...
Validate contract_type:
legal entities with types in (MSP,PRIMARY_CARE) can create only capitation contracts, legal entities with types in (PHARMACY) can create only reimbursement contracts
in case of error 409 - "Contract type "{contract_type}" is not allowed for legal_entity with type "{legal_entity_type}" "
Validate previous_request_id
select id from contract_request where id=$.previous_request_id
in case no data found return 422 ("previous_request does not exist")
Check previous_request status not in ('SIGNED')
in case error return 422 ('In case contract exists new contract request should be created')
Check that contractor_legal_entity_id of previous request is equal to contractor_legal_entity_id of current request
in case of error return 422 ('Previous request doesn't belong to legal entity')
For reimbursement contracts: Check that id_form from $.previous_request_id equal to id_form from request
in case of error return 422 ('Id_form from previous request is not equal to id_form from request')
Validate Validate contractor_divisions
in case capitation contracts:
Check divisions belongs to legal_entity and divisions.status='active'
in case of error return 422 error view $divisions ('Division must be active and within current legal_entity')
Validate each division in array present exactly one time
in case of error return 422 error view $divisions ('Division duplicates')
in case reimbursement contracts return 422 error ('schema does not allow additional properties')
Validate start_date
validate that start_date in a date format (^(\\d{4}(?!\\d{2}\\b))((-?)((0[1-9]|1[0-2])(\\3([12]\\d|0[1-9]|3[01]))?|W([0-4]\\d|5[0-2])(-?[1-7])?|(00[1-9]|0[1-9]\\d|[12]\\d{2}|3([0-5]\\d|6[1-6])))?)?$)
in case of error return 422 error $start_date ('"expected \"<start_date>" to be a valid ISO 8601 date"')
the year in start_date must be equal to current or next year (current+1).
in case of error return 422 error $start_date ('Start date must be within this or next year')
Validate end_date (Note. These validations are applied for cases when the contract_number isn't passed in the request. If the contract_number is passed, validations from 107.g f are applied)
validate that end_date in a date format (^(\\d{4}(?!\\d{2}\\b))((-?)((0[1-9]|1[0-2])(\\3([12]\\d|0[1-9]|3[01]))?|W([0-4]\\d|5[0-2])(-?[1-7])?|(00[1-9]|0[1-9]\\d|[12]\\d{2}|3([0-5]\\d|6[1-6])))?)?$)
in case of error return 422 error $end_date ('"expected \"<end_date>" to be a valid ISO 8601 date"')
the year in $end_date can be next year after 'start_date' if the total period of the contract doesn't exceed 1 year.the $end_date must be greater or equal than the $start_date
in case of error return 422 ('The end_date should be greater or equal than the start_date')
the different between $end_date and $start_date should be no more than one year old (365 or 366 days)than reimbursement(capitation)_contract_max_period_dayglobal param
in case of error return 422 ('The difference between end_date and start_date is more than one year<reimbursement(capitation)_contract_max_period_day> days')
Validate contractor_owner_id
Check employees.employee_id=contractor_owner_id and client_id=employee.legal_entity_id and employee_type in('OWNER', 'ADMIN') and status='APPROVED' and is_active=true
In case of error return 422 Error ('Contractor owner must be an active OWNER or ADMIN and within current legal entity in contract request')
If in request was sent contract_number:
check contract request number structure XXXX-1234-5678-C , where:
XXXX - series: numbers + only some letters (A, E, H, K, M, P, T, X)
1234-5678 - randomly generated numbers and letters A, E, H, K, M, P, T, X.
check there is a contract with such contract_number
in case of error return 422 error ('Contract with such contract number does not exist')
check if contract is not in status 'TERMINATED'
in case of error return 409 error ('Can not update terminated contract')
employee_divisions, start_date,
end_datecan't be updated. If there is an active contract with such contract_number copy start_date,end_dateand contractor_legal_entity_id from existing contract. It's not allowed in response.in case of error return 422 error
check submitted contract_type is the same as in existing contract with number =contract_number
in case of error 409 ('Submitted contract_type does not correspond to previously created content`)
for capitation and reimbursement contract requests:
if $contract_number and $end_date is passed in request:
the year of $end_date must be one year greater or equal then the $start_datein case of error return 422 ('The year of end_date should be one year greater or equal to start_date')
the $end_date should be less than $end_date from the previous contract equal or greater than today and less than or equal to three month from $end_date the previous contract
in case of error return 422 ('The end_date should may be equal or greater than of the previous contract today and less than or equal to three monthsmonth from end_date the previous contract')
if $contract_number w/o $end_date is passed in request:
$end_date is taken from the previous contract.
in case it is reimbursement contract:
check id_form is the same
in case of error 409 ('Submitted id_form does not correspond to previously created content`)
if medical_programs passed - validate them as described at p.13 below
Validate contractor_payment_details:
if payer_account not like ^UA[0-9]{22}$ or ^UA[0-9]{27}$ -> MFO must be required
Validate id_from is from dictionary CONTRACT_TYPE:
in case of error return 422 error ('value is not allowed in enum')
Validate there is no other active (VERIFIED) contract created by this legal_entity_id in this period(contract_request.start_date <= contract.end_date and contract_request.end_date => contract.start_date) by same contract_type and id_form (in case of reimbursement contract)
in case of error return 422 error ('Active contract is found. Contract number must be sent in request')
For capitation contract: Validate external_contractors
Check external_contractors.divisions.id is present in contractor_divisions.id
in case of error return 422 error $divisions ('The division is not belong to contractor_divisions')
Check external_contractors.contract.expires_at>start_date
in case of error return 422 error $contract.expires_at ('Expires date must be greater than contract start_date')
Set external_contractors.legal_entity_id='client_id'
division_id from the external_contractors block must be a part of the legal entity that enters into the capitation contract. In the external_contractors.legal_entity_id must be specify the legal entity that is the counter-party of this division_id.
For capitation contract: Validate external_contractor_flag:
If external_contractors is not null then external_contractor_flag must be
true
If external_contractors is null then external_contractor_flag must be set to false
in case of error return 422 error $external_contractor_flag ('Invalid external_contractor_flag')
If external_contractors wasn't sent in request then set external_contractor_flag to false.
For reimbursement contracts: Validate medical_programs:
Validate that all medical_programs with submitted ids exists
in case of error return 422 error view $medical_programs[...] ('Reimbursement program with such id does not exist')
Validate that medical_programs with submitted id is an active program
in case of error return 422 error view $medical_programs[...] ('Reimbursement program is not active')
Validate that all medical program and with MEDICATION type:
in case of error return 422 error view $medical_programs[...] (‘Program with such id is not a reimbursement program')
Check that medical_programs with submitted id correspond to id_form is in the allowed list:
in case of error return 422 error view $medical_programs[...] ('Medical program is not allowed for this action')
Note. For id_form=INSULIN_1 and PSYCHIATRY two medical programs must be present.in case of error return 409 error view $medical_programs ('The composition of medical programs does not correspond to the allowed composition')
Validate that list of medical programs in array doesn't contain duplicates ids:
in case of error return 409 error view $medical_programs (‘The list of medical programs contains duplicates')
id_form | medical_programs |
---|---|
PMD_1 | REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_ID_DOSTUPNI_LIKY |
INSULIN_1 | REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_IDS_INSULIN |
ND_1 | REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_ID_NETSUKROVYY_DIABET |
PSYCHIATRY | REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_IDS_PSYCHIATRY |
GENERAL | REIMBURSEMENT_CONTRACT_REQUEST_MEDICAL_PROGRAM_IDS_GENERAL |
Note. For GENERAL id_form user can specify any qty of programs (but at least one) from the configuration list. Also user can update list of medical programs using logic from p.7
Dictionaries
CONTRACT_PAYMENT_METHOD
CONTRACT_TYPE
REIMBURSEMENT_CONTRACT_TYPE
ADDRESS_TYPE
COUNTRY
SETTLEMENT_TYPE
STREET_TYPE
PHONE_TYPE
SPECIALITY_TYPE
SPECIALITY_LEVEL
SPEC_QUALIFICATION_TYPE
Processing
Determine parent contract (optional)
...
Get url for contract request upload
Parameter | Source |
---|---|
action | 'GET' |
bucket | 'CONTRACT_REQUEST' |
resource_id | :CONTRACT_REQUEST_ID |
resource_name | :INITIAL_CONTRACT_REQUEST |
timestamp | :TIMESTAMP |
2. Upload signed contract request to media storage.
...
Expand | ||
---|---|---|
| ||
|
Post-processing processes
No
HTTP status codes
Page Properties | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
...