| Table of Contents |
|---|
Purpose
This WS is designed to create Device Dispense
Key points
Only authenticated and authorized users with appropriate scope can invoke Create Device Dispense
Device Dispense is created in async way. Successful result of the job should return a link on the created Device Dispense (look at /wiki/spaces/CSI/pages/17467506869 ).
Device Dispense can be created only under active Device Request within valid dispense period
Several devices of different manufacturers with the same code can be dispensed at a time
Multiple dispenses to the same Device Request is not allowed
It is allowed to create Device Dispense for not active or not verified persons (for the same reasons as in the medication reimbursement process)
...
...
???
| Page Properties | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||
|
Logic
Fill in the following fields:
status = IN_PROGRESS
status_reason = null
subject. Set hashed patient_id from URL
performer_legal_entity. Set client_id from token
quantity.unit. Set description according to quantity code and system
inserted_at. Set current date and time
updated_at. Set current date and time
inserted_by. Set current user from token
updated_by. Set current user from token
Save data to device_dispenses collection in MongoDB according to /wiki/spaces/CSI/pages/17467572335
Send
StatusChangeEventto Event Manager
Request structure
See on Apiary
Example:
| Expand | ||
|---|---|---|
| ||
|
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 and client scopes in order to perform this action (scope = 'device_dispense:write')
return 403 (“Your scope does not allow to access this resource. Missing allowances: device_dispense:write”) in case of invalid scope(s)
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")
If BLOCK_DECEASED_PARTY_USERS is true, check that party is not deceased (party_verification record does not equal to: dracs_death_verification_status = VERIFIED and dracs_death_verification_reason = MANUAL_CONFIRMED):
in case of error - return 403 ("Access denied. Party is deceased")
Headers
Request data validation
Validate legal entity
Extract client_id from token
Check legal entity exists and its status is ACTIVE
In case of error - return 409 ('client_id refers to legal entity that is not active')
Validate dispense
Validate performer
Validate value in the field $.performer, Reference on employee resource, required.
...
Check that $.verification_code in request is equal to verification_code in device_request
In case code exists in request - it should match with code in device_request
in case of error - return 403 (message: “Incorrect code“)
Service logic
Fill in the following fields:
status = IN_PROGRESS
status_reason = null
subject. Set hashed patient_id from URL
performer_legal_entity. Set client_id from token
quantity.unit. Set description according to quantity code and system
inserted_at. Set current date and time
updated_at. Set current date and time
inserted_by. Set current user from token
updated_by. Set current user from token
Save data to device_dispenses collection in MongoDB according to /wiki/spaces/CSI/pages/17467572335
- Send
StatusChangeEventto Event Manager
Processing
Response structure
See on Apiary
Example:
| Expand | ||
|---|---|---|
| ||
|
Post-processing processes
HTTP status codes
| Page Properties | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| |||||||||
|