Purpose

This WS allows to create rule engine rule from Admin panel. The rule engine rule will be used as additional validation on creation specific medical events.

Key points

1. This is a graphQl method used in Administration panel only.

2. Only authenticated and authorized NHS employee with appropriate scope can create a Rule engine rule.

3. Rule engine rule must be signed with DS.

Specification

...

"""
Input for `createRuleEngineRule` mutation.

User must have a scope **rule_engine_rule:write**
"""
input CreateRuleEngineRuleInput {
  "Signed data to create rule engine set"
  signedContent: SignedContent!
}

"""
Return type for `createRuleEngineRule` mutation.
"""
type CreateRuleEngineRulePayload {
  "Created `RuleEngineRule`."
  ruleEngineRule: RuleEngineRule
}

...

Logic

1. Save signed content to media storage

2. Save data to rule_engine_rules collection (Mongo DB) according to https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17049387155

Request structure*

See on Apiary

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

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

Headers

Request data validation

Validate legal entity

• Extract client_id from token.

• Check client scopes in order to perform this action (scope = 'rule_engine_rule:write')

  • in case of error - return 403 (“Your scope does not allow to access this resource. Missing allowances: rule_engine_rule:write”)

• Check client type (type = NHS)

  • In case of error - return 403 ('You don't have permission to access this resource')

• Check legal entity status (status = ACTIVE)

  • In case of error - return 409 ('client_id refers to legal entity that is not active')

Validate Digital Sign

• Validate request is signed

  • in case of error - return 422 (“document must be signed by 1 signer but contains 0 signatures”)

• Check DS is valid and not expired

• Validate that DS belongs to the user

  • Check that EDRPOU from DS and legal_entities.edrpou of client_id matches

    • in case of error - return 422 (“Signer edrpou doesn’t match with requester edrpou”)

  • Check that DRFO from DS and party.tax_id matches

    • in case of error - return 409 (“Signer DRFO doesn't match with requester tax_id“)

Validate request

• Check name, code and value block is submitted

  • in case of error - return 422 ('required property <property> was not present')

• Check that rule engine rule with code is unique (extract active rule_engine_rule with the same code.system and code.value)

  • in case of error - return 409 ("Rule engine rule with such code and system already exists")

Service logic

...

Save signed content to media storage

...

Processing*

Response structure*

See on Apiary

Post-processing processes*

HTTP status codes*