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

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Purpose

This WS is designed to complete Device Dispense

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 Dispense in Media Content Storage if all checks are passed.

Key points

  1. Only authenticated and authorized users with appropriate scope can invoke Complete Device Dispense

  2. Device Dispense is completed in async way. Successful result of the job should return a link to the existing Device Dispense (look at /wiki/spaces/CSI/pages/17467506869 )

  3. Complete request must be signed with Digital Signature. So, all the Device dispense data must be signed and submitted.

Specification

Link

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/device-dispenses/complete-device-dispense/complete-device-dispense

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

Resource

/api/patients/{{patient_id}}/device_dispenses/{{device_dispense_id}}/actions/complete

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

Scope

device_dispense:complete

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_DISPENSE_BUCKET chart parameter

  • Fill in the following fields:

    • signed_content_links. Add string item in the array with a link(s) to saved content in media storage

    • status = COMPLETED

    • updated_at. Set current date and time

    • updated_by. Set current user from token

  • Save (update) data to device_requests collection in MongoDB according to /wiki/spaces/CSI/pages/17467375685 : set device_requests.status = COMPLETED (as all its quantity has been provided by Device dispense)

  • Send StatusChangeEvent to Event Manager for Device Dispense and related Device Request

Input parameters

Input parameter

Values

Type

Description

Example

patient_id

String

Unique patient identifier

aff00bf6-68bf-4b49-b66d-f031d48922b3

device_dispense_id

String

Unique device dispense identifier

aff00bf6-68bf-4b49-b66d-f031d48922b3

Request structure

See on Apiary

 Request example
{
  "signed_data": "ew0KICAicGVyaW9kIjogew0KIC..."
}

Authorization

  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 scopes in order to perform this action (scope = 'device_dispense:complete')

    • return 403 (“Your scope does not allow to access this resource. Missing allowances: device_dispense:complete”) in case of invalid scope(s)

Headers

  • Content-Type:application/json

  • Authorization:Bearer mF_9.B5f-4.1JqM

  • api-key:aFBLVTZ6Z2dON1V

Request data validation

Validate digital signature

  • Validate request is signed

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

  • Validate that DS is valid and not expired

  • Validate that DS belongs to the user

    • Check that DRFO from DS and party.tax_id matches

      • in case of error - return 422 (“Does not match the signer drfo“).

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')

Validate Device dispense

  • Get Device dispense identifier from the URL

    • Check Device dispense exists in DB (ME DB)

      • in case of error - Return 404 ('not_found')

    • Check Device dispense belongs to the same legal entity

      • in case of error - Return 404 ('not_found')

  • Validate payment_amount

    • Check it is present if program was set

      • in case of error - Return 422 (Required property payment_amount was not present)

  • Validate when_handed_over

    • Check that when_handed_over is in period specified in Device request (when_handed_over = current_date() and when_handed_over <= device_request.dispense_valid_to)

      • in case of error - return 409 error ('Invalid dispense period')

  • Validate status

    • As target status value must be submitted in the order of display in the signed content, check $.status is completed

      • in case of error - return 422 ("value is not allowed in enum")

Validate Device request

Validate value in the field $.based_on ($.based_on.identifier.value), Reference on device request, required.

  • Сheck that Device request is_active = true and status == 'ACTIVE'

    • in case of error - return 409 error ('Device request is not active')

Validate User

  • Extract user_id from token

  • Check that device dispense is completed by the same user who created it

    • User from token must match with device_dispense.inserted_by

      • in case of error - Return 409 ('Employee is not an author of device dispense')

Validate signed content

  • Check that signed content is equal to device dispense stored in DB

    • Do not compare:

      • payment_amount field

      • payment_id field

      • status

      • when_handed_over

  • in case error return 422 ("Signed content does not match to previously created dispense")

Validate transition

  • Get status of Device dispense by $.id in ME DB. Check that Device dispense is in status ‘IN_PROGRESS’

    • in case of error - return 409 ("Device dispense in {status} cannot be completed")

For more information look at Device dispense status model

Response structure

See on Apiary

 Request example
{
  "data": {
    "status": "pending",
    "eta": "2018-08-02T10:45:16.000Z",
    "links": [
      {
        "entity": "job",
        "href": "/Jobs/NBXk9EyErUZv1RhXgyvgg"
      }
    ]
  },
  "meta": {
    "code": 202,
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  }
}

HTTP status codes

HTTP status code

Message

What caused the error

 202

 

 

  • No labels