...

5. Продовження / скорочення МВТН

RC_6. Уточнення (preperson -> person) для МВТН

RC_7. Створення МВ “на заміну”

Specification

Logic

...

Input parameters

Request structure

See on SwaggerHub

Request body

Request body with signed Composition. Signed content must match the existing Composition object

...

• Content-Type: application/json

• Authorization: Bearer {token}

• api-key: {secret}

Validation data request

1. Checking the existence of other Composition tasks for signing

   1. Search in task_queue other tasks with SIGN_COMPOSITION type and status isn’t FAILED

      1. In case of error (such task is found) - return 1142 (ANOTHER_SIGN_TASK_ALREADY_EXIST)

2. Encounter.value uniqueness check. Check that such Encounter.value not used in another Composition with the same type, category and in "Final" status

   1. If it used - return 1127 (FINAL_COMPOSITION_FOR_ENCOUNTER_ALREADY_EXISTS)

3. Checking the signing delay

   1. If signing time does not match with value in EMAL_FILTER_SIGN_CREATE_DELAY_DISABILITY, EMAL_FILTER_SIGN_CREATE_DELAY_NEWBORN - return 1124 (CREATE_SIGN_DELAY_EXCEEDED)

4. Verification of signature overlay

   1. The body of the signature in the request

...

1. 1. transfers to the DS service by RPC method “decode_signed_content”

      1. If service:

         1. Returned a null field “content” - return error 1019 (SIGVER_FAILED_NO_PAYLOAD) with explanation "content is null or blank"

         2. Did not return a response (or returned a response of an inappropriate structure) - return error 1099 (SIGVER_FAILED_BAD_CONTENT)

         3. Returned any value in the "validation_error_message" field - return error 1020 (SIGVER_FAILED_BAD_CERT)

         4. Did not return any signature - return error 1021 (SIGVER_FAILED_NO_SIGNATURES)

         5. Returned several signatures - return error 1022 (SIGVER_FAILED_MULTIPLE_SIGNATURES)

   2. For every signatures that were overlayed

      1. Check the value of the "is_valid field" in the RPC service response

         1. If there is at least one invalid signature - return 1023 (SIGVER_FAILED_INVALID_SIGNATURE)

2. Validation of signed content

   1. Checks the status of the signing object

      1. If the status is not equal to PRELIMINARY - return error 1041 (CANT_SIGN_NON_PRELIMINARY_COMPOSITION)

   2. Checks the content in the signed object and compares it to the Composition object

      1. If the content does not match - return 1042 (SIGNING_CONTENT_MISMATCH)

3. Signer Check. The application receives information about the signer from the certificate of qualified electronic signature from the service (the value of the field corresponding to the RNOCPP(individual tax number) from the certificate)

   1. Сompliance check RNOCPP (individual tax number) with data specified in the employee profile (Composition.author)

      1. If employee.party.no_tax_id == true then it is verified that the value of DRFO corresponds to at least one of the documents for employee.party. The rules of transliteration of letters are applied for comparing

         1. If a match isn't found - return 1024 (SIGVER_FAILED_DOCUMENTS_DONT_MATCH)

      2. In all other options - check that the employee.party.tax_id value is equal to the DRFO field in the signer's certificate

         1. if the fields are not equal - return 1025 (SIGVER_FAILED_DRFO_DOESNT_MATCH)

4. Checking the related Composition:

   1. If Composition’s status in target.identifier is “Amended” - return 1184 (CANT_SIGN_INVALID_RELATED_STATUS)

   2. If RelatesTo.code is “appends” or “transforms” and Composition’s status in target.identifier isn’t “Final” - return 1184 (CANT_SIGN_INVALID_RELATED_STATUS)

   3. If RelatesTo.code is “replaces” - check for status change: FINAL-> AMENDED, ENTERED_IN_ERROR -> ENTERED_IN_ERROR

      1. In case of error - return 1184 (CANT_SIGN_INVALID_RELATED_STATUS)

Processing

1. Checking the existence of other Composition tasks for signing. Logic - to check if there are other tasks in the system for the same Composition waiting for signature verification. Such a procedure is necessary to prevent several parallel requests for signing the same Composition.

2. Encounter.value uniqueness check: Check that such Encounter.value not used in another Composition with the same type, category and in "Final" status

3. Checking the signing delay: Check that allowed delay time between the creation of the draft and the direct signing of the Composition match with current configuration.

4. Overlay CheckVerification of signature overlay: Checks that the signature is overlaid correctly and the signature is valid

5. Validation of signed content: checks that the signature was applied to the corresponding Composition’s object record without any modifications after creating the draft

6. Signer Check: Checks the data in the signature certificate against the author data according to Composition.author and Employee data

7. Checking the related Composition: Check that specified in relatesTo Composition exists and has an appropriate status

8. Status update: Changes the Composition status in the database and related Composition’s status (in case of refinement Temporary Disability Composition)

9. Saving Composition: Saves the data of the signed Composition in the object drive (ceph)

10. For Temporary Disability Composition (for tasks that were successfully completed at this stage): Planning CREATE ERLN RECORD task (in PENDING status)

Response structure

See on SwaggerHub

Example:

{
  "data": {
    "eta": "2023-01-17T13:55:12.733Z",
    "id": "0b61fe9e-1841-43ef-9108-e8b43a0fa18e",
    "links": [
      {
        "entity": "eHealth/resources",
        "href": "composition/8c696fa4-6607-4aef-bab7-33cabc2dda2c"
      }
    ],
    "status": "PENDING"
  }
}

...

API paragraph not found

HTTP status codes