Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

REST API method / Метод REST API (настанова) (remove the link block before publishing the document)

...

Page Properties
idpage_properties_method_REST API
Sync/

Document type

Метод REST API

Document title

[Document status] REST API [Назва методу] [ID методу]

Guideline ID

GUI-0011

Author

@

Document version

1

Document status

DRAFT

Date of creation

ХХ.ХХ.ХХХХ (дата фінальної версії документа – RC або PROD)

Date of update

ХХ.ХХ.ХХХХ (дата зміни версії)

Method API ID

API-001007-001009-001-00010305

Microservices (namespace)

MPIME

Component

AuthProcedure

Component ID

COM-001007-001009

Link на API-специфікацію

https://ehealthmisapi1ehealthmedicaleventsapi.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/manage-client-configuration/get-client-detailsevents/procedures/cancel-procedure

Resource

{{host}}//api.ehealth.gov.ua/api/patients/id/encounter_package

Scope

Protocol type

Request type

api/patients/{{person_id}}/procedures/{{id}}/actions/cancel

Scope

procedure:write

Protocol type

REST

Request type

PATCH

Sync/Async

Async

Public/Private

Public

Purpose

Describe the purpose of the API method, add Key points (if necessary)

Logic

...

This WS allows to cancel procedure in case they were entered in error.

Logic

This WS allows to cancel existing procedure and change its status to entered_in_error in case of any mistake. The new correct procedure could be created instead. 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)

Important

  1. Signed content of procedure must be equal to procedure stored in DB. See Get Procedure by search params

  2. status_reason and explanatory_letter (optional) must be added to signed content

Відкликання процедури (entered in error)

Configuration parameters

Description of the configuration parameters that are used when processing a request in the system

Dictionaries

Provides a list of links to dictionaries that are available in Confluence

Input parameters

Description of input parameters

Input parameter

Mandatory

Type

Description

Example

1

composition_id

 M

String ($uuid) (path)

Composition object ID

 89678f60-4cdc-4fe3-ae83-e8b3ebd35c59

2

Request structure

See on Apiary

See on API-specification (посилання на сторінку з API-специфікацією)

Description of the REST API request structure, example

Expand
titleExample
Code Block
{
  "signed_data": "ew0KICAicGVyaW9kIjogew0KIC..."
}

Headers

Key

Value

Mandatory

Description

Example

1

Content-Type

application/json

M

Тип контенту

Content-Type:application/json

2

Authorization

Bearer c2778f3064753ea70de870a53795f5c9

M

Перевірка користувача

{{access_token}}

Authorization:Bearer c2778f3064753ea70de870a53795f5c9{{access_token}}

3

API-key

{{secret}}

API-key:{{secret}}

Request data validation

Describe the process of checking the input data transmitted in the request for compliance with the given rules and restrictions set in the API

Processing

A list of processes related to receiving, changing or transmitting data according to the logic defined in the REST API

Response structure examples

Description of the REST API response structure, example

...

titleExample

...

Validate legal entity

  • Validate procedure belongs to the legal entity where the current user works

    • ME.procedure.managing_organization==token.client_id

      • in case of error return 409 "Managing_organization in the procedure does not correspond to user`s legal_entity"

Validate patient

  • Validate patient is active

    •  ME.patient.status=="active" and is_active=true

      • in case of error return "Patient is not active"

Validate User

  • Extract user_id and client_id from token

  • Get list of APPROVED employees with this user_id in current Legal Entity

  • Check that for user one of the conditions is TRUE:

    • user has an employee that specified as author of the procedure ($.procedure.recorded_by.identifier.value is in the list of APPROVED employees)

    • OR check that user has an employee which has approval granted by the patient with access_level:write for this procedure resource ($.approvals.granted_resources.identifier.value==$.procedure._id AND $.approvals.granted_to.identifier.value==PRM.employees.id AND $.approvals.access_level='write')

    • OR user has an employee which has MED_ADMIN employee type

    • otherwise, return error 409  "Employee is not performer of procedure, don't has approval or required employee type"

  • If BLOCK_UNVERIFIED_PARTY_USERS is true, then check user's party 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")

Request validation

  1. Validate digital signature

    1. ds.drfo == PRM.parties.tax_id where (PRM.parties.id==PRM.employees.party_id where (PRM.employees.id==$.performer.identifier.value))

      1. in case of error - return 409 ("Signer DRFO doesn't match with requester tax_id")

  2. Compare signed_content to previously created content

    1. select procedure, select * from procedures context.identifier.value=procedure_id and compare to signed_content (do not include status, status_reason and explanatory_letter )

      1. in case of inconsistencies return "Submitted signed content does not correspond to previously created content"

  3. Validate status_reason is in dictionary eHealth/procedure_status_reasons

    1. in case error return 422, "status_reason not in a dictionary eHealth/procedure_status_reasons"

  4. Validate user performs action with procedure that belong to his legal entity

    1. ME.patient{patinet_id}.procedures{procedure_id}.managing_organization==token.client_id

      1. in case of error return 422 "Managing_organization in the procedure does not correspond to user`s legal_entity"

Processing

  1. Save signed_content to Media Storage

  2. Set status `ENTERED_IN_ERROR` for procedure

  3. Set cancellation_reason

  4. Set explanatory_letter 

Response structure examples

See on Apiary

See on API-specification (посилання на сторінку з API-специфікацією)

Expand
titleExample
Code Block
{
  "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

5

Response code

HTTP Status code

Message

Internal name

Description

1

Базові

2

202

 

 

3

401

Access denied

 

4

401

Unauthorized

Помилка підтвердження

5

403

Access denied. Party is not verified

6

403

Invalid scopes

 

7

1000

404

Composition not found

COMPOSITION_NOT_FOUND_404

Не знайдено медичний висновок

3

401

Unauthorized

Помилка підтвердження

4

Специфічні

8

404

Patient not found

 

9

409

Employee is not performer of procedure, don't has approval or required employee type

10

409

Managing_organization in the procedure does not correspond to user`s legal_entity

11

409

Signer DRFO doesn't match with requester tax_id

12

409

 

Validation error

13

422

 

Validation error

14

422

Managing_organization in the procedure does not correspond to user`s legal_entity

15

422

status_reason not in a dictionary eHealth/procedure_status_reasons

16

17

Специфічні

18

422

Only for active MPI record can be created medication request!

Post-processing processes

Description of actions performed on data after processing

Technical modules where the method is used

List of pages describing technical modules where the method is used

Page Properties Report
headingsID ТМ, Статус
cqllabel = "tr-mis"

...