ЕСОЗ - публічна документація
Create Device request
- 1 Purpose
- 1.1 Key points
- 2 Specification
- 3 Logic
- 4 Input parameters
- 5 Request structure
- 6 Authorize
- 7 Request data validation
- 7.1 Validate digital signature
- 7.2 Validate requester
- 7.3 Validate based on
- 7.4 Validate intent
- 7.5 Validate legal entity
- 7.6 Validate Patient
- 7.7 Validate request
- 7.8 Validate status
- 7.9 Validate code or code_reference
- 7.10 Validate quantity
- 7.11 Validate encounter
- 7.12 Validate authored on
- 7.13 Validate occurrence
- 7.14 Validate reason
- 7.15 Validate Package unit and quantity
- 7.16 Validate Medical program
- 7.17 Validate priority
- 7.18 Validate supporting info
- 7.19 Validate performer
- 7.20 Validate parameter
- 8 Response structure
- 9 HTTP status codes
Purpose
This WS is designed to create Device Request
This method allows to create Device Request for a person (or preperson) in 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 Device Request in Media Content Storage if all checks is passed.
Key points
Only authenticated and authorized users with appropriate scope can invoke Create Device Request
Device Request is created in async way. Successful result of the job should return a link on the created Device Request (look at https://e-health-ua.atlassian.net/wiki/spaces/CSI/pages/17467310277/Get+Device+request+details ).
Device Request should be signed with DS. Signed content stores in the media storage.
All validations within Device request attributes should be executed by internal call of PreQualify Device request function
Device Request can be created for a person only
Medical program is optional in the Device Request
Specification
Link | Посилання на Apiary або Swagger | |
Resource | /api/patients/{{patient_id}}/device_requests | Посилання на ресурс, наприклад: /api/persons/create |
Scope |
| Scope для доступу |
Components | Devices | Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription |
Microservices |
| Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC |
Protocol type | REST | Тип протоколу, який використовується запитом, наприклад: SOAP | REST |
Request type | POST | Тип запиту API, наприклад: GET, POST, PATCH… |
Sync/Async | Async | Метод є синхронним чи асинхронним? |
Public/Private/Internal | Public | Потрібно зазначити тип методу за ступенем доступності |
Logic
Save signed content to media storage, in bucket pointed in MEDIA_STORAGE_DEVICE_REQUEST_BUCKET chart parameter
Fill in the following fields:
requisition. Generate requisition number as described at Human readable Medication request number, but based on the Device Request identifier and put it in the field.
signed_content_links. Add string item in the array with a link on saved content in media storage
status = ACTIVE
status_reason = null
subject. Set hashed patient_id from URL
requester_legal_entity. Set client_id from token
quantity.unit. Set description according to quantity code and system
dispense_valid_to. dispense_valid_to. Set (current_date + dispense_period_day) if medical program was set and it has dispense_period_day setting. Otherwise, if medical program was set and it has NO dispense_period_day setting, set the value using device_dispense_period global parameter. Else, if medical program was NOT set dispense_valid_to = null.
Save dispense_valid_to as
datetime
but truncate time to beginning of date (2013-08-02T00:00:00Z
)
verification_code. Generate random 4-digit code if medical program was set
context_episode_id. Set episode from the $.encounter
context_care_plan_id. Get Activity from $.based_on, set activity.care_plan as context_care_plan_id
based_on. Set based_on from the $.based_on
priority. Set priority from the $.priority
parameter. Set parameter from the $.parameter
performer. Set performer from the $.performer
supporting_info. Set supporting_info from the $.supporting_info
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
Send notification to patient:
Determine patient's default authentication method as described at Determination of a default authentication method and return person's active auth_methods
Get program from request and (if provided) get program setting
request_notification_disabled
:if program provided and
request_notification_disabled
== true:do not send SMS notification to patient
if program provided and
request_notification_disabled
== false and OTP defined on patient:generate text according to CREATE_DEVICE_REQUEST_SMS_TEMPLATE and send SMS with verification_code
if program not provided and OTP defined on patient:
check config parameter
DEVICE_REQUESTS_SMS_ENABLED
is set to truegenerate text according to CREATE_DEVICE_REQUEST_SMS_TEMPLATE_WITHOUT_CODE and send SMS without verification_code
Save data to device_requests collection in MongoDB according to RС_[UPD] Device request data model_ENarchived
If device request is based on activity - recalculate and set remaining_quantity for the activity
select all device requests based on current activity and calculate previously reserved quantity as sum of DR.quantity.value.
calculate reserved at the moment quantity as sum of previously reserved quantity and quantity from current DR
calculate remaining quantity by subtracting reserved at the moment quantity from activity's quantity
Update activity set remaining quantity (activity.detail.remaining_quantity)
Send
StatusChangeEvent
to Event Manage
Input parameters
Input parameter | Values | Type | Description | Example |
---|---|---|---|---|
patient_id |
| String | MPI identifier of the person |
|
Request structure
See on Apiary
Example:
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_request:write')
return 403 (“Your scope does not allow to access this resource. Missing allowances: device_request: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")
Request data validation
Validate digital signature
Validate request is signed
in case of error - return 400 (“Invalid signed content”)
Check DS is valid and not expired
Validate that DS belongs to the requester
Check that DRFO from DS and party.tax_id matches
in case of error - return 422 (“Signer DRFO doesn't match with requester tax_id“)
Validate requester
Execute validation as described here
PreQualify Device request | 1. Validate requester
Validate based on
Execute validation as described here
PreQualify Device request | 2. Validate based on
Validate intent
Execute validation as described here
PreQualify Device request | 3. Validate intent
Validate legal entity
Extract client_id from token
Check legal entity status is ACTIVE
In case of error - return 409 ('client_id refers to legal entity that is not active')
Check legal entity type in ME_ALLOWED_TRANSACTIONS_LE_TYPES config parameter
in case of error - return 409 ('client_id refers to legal entity with type that is not allowed to create medical events transactions')
Validate Patient
Get Patient identifier from the URL
Check it exists in persons table (MPI) and has status active
Return 404 ('Person is not found') in case of error
Validate person's verification_status is not equal to NOT_VERIFIED
in case NOT_VERIFIED - return error 409 ("Patient is not verified")
Validate person is not a preperson
in case error - return error 409 ("Forbidden to create device request for a preperson")
Validate request
Validate request using schema.
Invoke validations described at https://e-health-ua.atlassian.net/wiki/spaces/CSI/pages/17467474119/PreQualify+Device+request#Validate-Device-request
If Device Request has a medical program, then in addition execute validations described at https://e-health-ua.atlassian.net/wiki/spaces/CSI/pages/17467474119/PreQualify+Device+request#Validate-Medical-programs . Also, quantity is required in this case
Validate status
The target status value must be submitted in the order of display in the signed content (media storage)
Validate $.status is active
in case of error - return 422 ("value is not allowed in enum")
Validate code or code_reference
Execute validation as described here
PreQualify Device request | 4. Validate code or code_reference
Skip the following validation in case madical_program is not specified in the request
Check that there is at least one active device_definition with the same type (device_definitions.classification_type)
device_definitions.is_active = true
in case of error - return 422 ('No active device_definitions with the same type')
Validate quantity
If medical program is not specified in request then quantity is optional here
If quantity provided in request - execute validation as described here
PreQualify Device request | 5. Validate quantity
Check that $.quantity.system is
device_unit
dictionary, requiredin case of error - return 422 ('value is not allowed in enum')
Check that $.quantity.code comply with $.quantity.system, required
in case of error - return 422 ('value is not allowed in enum')
Check that $.quantity.value is integer, required
in case of error - return 422 ('Value should be an integer')
Validate encounter
Execute validation as described here
PreQualify Device request | 6. Validate encounter
Validate authored on
Execute validation as described here
PreQualify Device request | 7. Validate authored on
Validate occurrence
Execute validation as described here
PreQualify Device request | 8. Validate occurrence
Validate reason
Execute validation as described here
PreQualify Device request | 9. Validate reason
Validate Package unit and quantity
If medical program is not specified in request then skip this step
Execute validation as described here
PreQualify Device request | 5. Validate quantity
Validate Medical program
Validate priority
Execute validation as described here
Validate supporting info
Execute validation as described here
Validate performer
Execute validation as described here
Validate parameter
Execute validation as described here
Response structure
See on Apiary
Example:
HTTP status codes
HTTP status code | Message | What caused the error |
---|---|---|
202 |
|
|
ЕСОЗ - публічна документація