ЕСОЗ - публічна документація

Create Device request

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

  1. Only authenticated and authorized users with appropriate scope can invoke Create Device Request

  2. 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 ).

  3. Device Request should be signed with DS. Signed content stores in the media storage.

  4. All validations within Device request attributes should be executed by internal call of PreQualify Device request function

  5. Device Request can be created for a person only

  6. Medical program is optional in the Device Request

 

Specification

Link

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/device-requests/create-device-request/create-device-request

Посилання на Apiary або Swagger

Resource

/api/patients/{{patient_id}}/device_requests

Посилання на ресурс, наприклад: /api/persons/create

Scope

device_request:write

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

Input parameters

Input parameter

Values

Type

Description

Example

Input parameter

Values

Type

Description

Example

patient_id

 

String

MPI identifier of the person

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

 

Request structure

See on Apiary

Example:

{ "signed_data": "ew0KICAicGVyaW9kIjogew0KIC..." }

 

Authorize

  1. Verify the validity of access token

    • in case of error - return 401 (“Invalid access token”) in case of validation fails

  2. Verify that token is not expired

    • in case of error - return 401 (“Invalid access token”)

  3. 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)

  4. 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):

    1. in case not match - return 403 ("Access denied. Party is not verified")

  5. 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):

    1. in case of error - return 403 ("Access denied. Party is deceased")

 

Request data validation

Validate digital signature

  1. Validate request is signed

    1. in case of error - return 400 (“Invalid signed content”)

  2. Check DS is valid and not expired

  3. Validate that DS belongs to the requester

    1. Check that DRFO from DS and party.tax_id matches

      1. 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

  • Validate person is not preperson (patients.preperson == false)

    • in case of error - return 409 ('Forbidden to create device request for preperson')

 

Validate request

Validate request using schema.

Validate status

The target status value must be submitted in the order of display in the signed content (media storage)

  1. Validate $.status is active

    1. 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, required

    • in 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

Execute validation as described here

PreQualify Device request | 5. Validate quantity

Validate Medical program

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17573085395/PreQualify+Device+request#10.-Validate-Medical-programs

Validate priority

Execute validation as described here

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17573085395/PreQualify+Device+request#11.-Validate-priority

Validate supporting info

Execute validation as described here

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17573085395/PreQualify+Device+request#12.-Validate-supporting-info

Validate performer

Execute validation as described here

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17573085395/PreQualify+Device+request#13.-Validate-performer

Validate parameter

Execute validation as described here

https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17573085395/PreQualify+Device+request#14.-Validate-parameter

 

Response structure

See on Apiary

Example:

 

 

HTTP status codes

HTTP status code

Message

What caused the error

HTTP status code

Message

What caused the error

 202

 

 

 

ЕСОЗ - публічна документація