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

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 Next »

Introduction

Web service "Submit Activity Type Package" allows to transmit activity type, its related data and legal entity licenses to e-Health system. 

Specification

TBC

Validation

Authorization

  1. Verify the validity of access token
    1. in case of error return 401 ('Access denied')
  2. Check user scope activity_type:write in order to perform this action
    1. in case of error generate 403 response ('Invalid scopes')

Request validation

Note: All IDs, submitted as PK, should be unique for eHealth. 

Validate digital signature

  1. Validate signature 
  2. Extract signer Certificate details

Validate encoded signed content according to JSON Schema

  1. Return 422 with list of validation errors in case validation fails

Validate Legal Entity

  1. Check that legal_entities.is_active = true and legal_entities.status = active for current legal entity
    1. in case of error return 409 - "legal entity is not active"
  2. token.Client_id must match current legal entity
    1. in case of error return 422 
  3. EDRPOU for token.client_id must match EDRPOU $.legal_entity.edrpou
    1. in case of error return 422 

Validate Tax ID

  1. Check that EDRPOU in Certificate details exists and not empty
    1. Check that EDRPOU in Certificate details is valid according to ^[0-9]{8,10}$
    2. Check that EDRPOU in Certificate details is equal to $.legal_entity.edrpou  
      1. In case validation fails - generate 422 error
  2. If EDRPOU in Certificate details is empty check that DRFO exists and not empty
    1. Check that DRFO in Certificate details is valid according to ^[0-9]{9,10}$
    2. Check that DRFO in Certificate details is equal to $.legal_entity.edrpou 
      1. In case validation fails - generate 422 error
  3. In case EDRPOU and DRFO is empty return error 422, msg "EDRPOU and DRFO is empty in digital sign"

Validate Owner

  1. Check that one of token.user_id employees is OWNER of current legal_entity 
    1. in case validation fails - generate ???

Validate  Activity Type

  1. Validate $.activity_type.id as unique
  2. Check $.activity_type.activity_type license obligation and license type needed (via configuration)
    1. If license is a must:
      1. check that $.activity_type.license_id is not empty
        1. in case validation fails - generate ???
      2. check that license with $.activity_type.license_id exists in payload and $.license.type is of needed type OR (license with $.activity_type.license_id exists in prm.licenses for current legal entity and prm.licenses.expiry_date is empty or more than today AND prm.licenses.type is of needed type
        1. in case validation fails - generate ???
  3. Search for current legal entity activity type in prm.activity_types where is_active=true and type = $.activity_type.type
    1. If record is found then check that its id is equal to $.activity_type.id
      1. in case validation fails - generate ???

Validate Licenses

  1. Validate $.license.id as unique
  2. Search for current legal entity license in prm.licenses where is_active = true and type = $.license.type
    1. If record is found then check that its id is equal to $.license.id

Request Processing

  1. Save signed_content to Media Storage
  2. Save data to corresponding collections in DBs
  3. Save link to the signed content to the activity type


  • No labels