1 Purpose
2 Specification
3 Logic
- 3.1 General
4 Dictionaries
5 Request structure
6 Authorize
7 Headers
8 Request data validation
- 8.1 Validate location
- 8.2 Validate addresses
- 8.3 Validate phone
- 8.4 Validate email
- 8.5 Validate type
9 Processing
- 9.1 Create new division
- 9.2 Additional
10 Response structure
11 HTTP status codes

Purpose

This method must be used to create new division in the system.

Note that different legal entity types can register specific division types and address types accordingly More details can be found here

Specification

Link	https://ehealthmisapi1.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/divisions/create-division	Посилання на Apiary або Swagger
Resource	/api/divisions	Посилання на ресурс, наприклад: /api/persons/create
Scope	division:write	Scope для доступу
Components	Divisions	Зазначається перелік бізнес компонентів, які використовують цей метод, наприклад: ePrescription
Microservices	il/api	Перелік мікросервісів, які використовує метод API, наприклад: Auth, ABAC
Protocol type	REST	Тип протоколу, який використовується запитом, наприклад: SOAP \| REST
Request type	POST	Тип запиту API, наприклад: GET, POST, PATCH…
Sync/Async	Sync	Метод є синхронним чи асинхронним?
Public/Private/Internal	Public	Потрібно зазначити тип методу за ступенем доступності

Logic

General

Each legal entity can manage its own divisions:

add new division
view existing divisions and its details
edit some information on existing division
deactivate division

Only users of this legal entity with specific scopes can manage divisions

Editable information on division:

name
addresses
phones
email
add the gps-coordinates attributed to the division
working hours

Note: Exclude legal_entity_id from Divisions Request Payload in Public API's. Legal_entity_id must be set by GW using user access token.

Note: Calculate mountain group for each new Divisions based on division address

Acceptance criteria:

Configured Public GET, POST, PATCH methods on GW
Successful response with correct authorization and appropriate scopes
401 error on invalid authorization
403 error on invalid scopes
Legal entity id is missing in request
Legal entity id is set as header by GW
Created divisions saved to DB
Mountain group calculated

Dictionaries

Dictionary ADDRESS_TYPE
Dictionary PHONE_TYPE
Dictionary SETTLEMENT_TYPE
Dictionary STREET_TYPE
Dictionary DIVISION_TYPE
Dictionary COUNTRY

Request structure

Example:

{
  "name": "Бориспільське відділення Клініки Ноунейм",
  "addresses": [
    {
      "type": "RESIDENCE",
      "country": "UA",
      "area": "Житомирська",
      "region": "Бердичівський",
      "settlement": "Київ",
      "settlement_type": "CITY",
      "settlement_id": "b075f148",
      "street_type": "STREET",
      "street": "вул. Ніжинська",
      "building": "15",
      "apartment": "23",
      "zip": "02090"
    }
  ],
  "phones": [
    {
      "type": "MOBILE",
      "number": "+380503410870"
    }
  ],
  "email": "email@example.com",
  "working_hours": {
    "mon": [
      [
        "08.00",
        "12.00"
      ],
      [
        "14.00",
        "18.00"
      ]
    ],
    "tue": [
      [
        "08.00",
        "12.00"
      ]
    ],
    "wed": [
      [
        "08.00",
        "12.00"
      ]
    ],
    "thu": [
      [
        "08.00",
        "12.00"
      ]
    ],
    "fri": [
      [
        "08.00",
        "12.00"
      ]
    ]
  },
  "type": "CLINIC",
  "legal_entity_id": "c8aadb87-ecb9-41ca-9ad4-ffdfe1dd89c9",
  "external_id": "3213213",
  "location": {
    "latitude": 30.1233,
    "longitude": 50.32423
  }
}

Authorize

Verify the validity of access token
Check user scope (scope = 'division:write') in order to perform this action
- in case error - generate 401 response
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")

Headers

Content-Type:application/json
Authorization:Bearer {{access_token}}
API-key:{{secret}}

Request data validation

Validate location

Location is required for divisions related to legal entity with type PHARMACY

Check that location exists in request for legal entity with type PHARMACY
1. In case of error - generate 422 response

Validate addresses

Check that addresses.type exists in dictionaries.
1. In case error generate 422 "value is not allowed in enum"
Check that addresses.area exists in Uaddresses.areas
1. in case error generate 422 "invalid area value"
Check that addresses.settlement exists in Uaddresses.settlements
1. in case error generate 422 "invalid settlement value"
Check that addresses.settlement_type exists in dictionaries.
1. in case error generate 422 "value is not allowed in enum"
Check that addresses.settlement_id exists in Uaddresses.settlements
1. in case error generate 422 "settlement with id = <id> does not exist"
Check that addresses.street_type exists in dictionaries.
1. In case error generate 422 "value is not allowed in enum"
Check that addresses.zip in "^[0-9]{5}$" format.
1. In case error generate 422 "string does not match pattern \"^[0-9]{5}$\""
Check mapping legal_entity_type, division_type and address_type and its obligation. See validation rules here: Validation rules on Divisions
1. in case error generate 422 response

Validate phone

Check that phone type exists in dictionaries. PHONE_TYPE required (MOBILE,LAND_LINE)
1. in case error generate 422 response
Check phone number is valid according to "^\\+38[0-9]{10}$"
1. in case error generate 422 response

Validate email

Check that email is valid according to "~r/^[\\w!#$%&'*+\\/=?`{|}~^-]+(?:\\.[\\w!#$%&'*+\\/=?`{|}~^-]+)*@(?:[A-Z0-9-]+\\.)+[A-Z]{2,6}$/i"
1. in case error generate 422 response

Validate type

Check that type exists in dictionaries.
1. in case error generate 422 response
Check mapping of legal_entity_type and division type. See validation rules here: Validation rules on Divisions
1. in case error generate 422 response

Processing

Create new division

Parameter	Source

Parameter	Source
action	`PUT`
id
external_id	$.external_id
name	$.name
type	$.type
mountain_group
addresses	$.addresses
phones	$.type, $.number
email	$.email
inserted_at	:timestamp
Updated_at	:timestamp
legal_entity_id	take from token
Location	$.latitude, $.longitude
status	ACTIVE
is_active	true
working_hours	$.working_hours

Additional

Add new mapping for "division_type" & Legal_entity_type
1. Check that prm.legal_entities.status = active or suspended and prm.legal_entities.is_active = true for legal entity to which division is added
Add new validation for verification of usage division_type in Legal_entity_type at Create_division process.
There is no other specific logic for new division types.

Response structure