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

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-001004-001004-00010253

Microservices (namespace)

MPIME

Component

AuthEDP

Component ID

COM-001007-001004

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

https://ehealthmisapi1ehealthmedicaleventsapi.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/manage-client-configuration/get-client-detailsevents/episode-of-care/cancel-encounter-package

Resource

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

Scope

encounter:cancel

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

Description of the working algorithm of the API method and the interaction of services with each other add Service logic (if necessary)This web service allows to cancel encounter and other components of Data Package such as conditions, observations, allergy_intolerances and immunizations in case they were entered in error.

Note

Note : You have only one attempt to cancel each package via API. In case you signed and cancelled package partly and now you need to cancel more entities from this package - appeal to eHealth administrator.

Note

Note: Current diagnoses on the episode will be replaced automatically with the last accurate diagnoses in case encounter was cancelled.

Logic

This web service allows to cancel encounter and other components of Data Package they were entered in case 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 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

3

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

...

{{access_token}}

3

API-key

{{secret}}

API-key:{{secret}}

Request data validation

  1. Validate digital signature

    1. ds.drfo == PRM.parties.tax_id where PRM.parties.id==PRM.employees.party_id where:

      1. PRM.employees.id==$.encounter.performer.identifier.value)

      2. OR PRM.employees.id==$.approval.granted_to.identifier.value ($.approvals.granted_resources.identifier.value==$.encounter_id AND $.approvals.access_level='write')

      3. OR PRM.employees.employee_type==MED_ADMIN

  2. Compare signed_content to previously created content

    1. select encounter, select * from observations, conditions, immunizations, allergy_intolerances where context.identifier.value=encounter_id and compare to signed_content (do not include statuses to comparation, cancellation_reason and  explanatory_letter )

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

  3. Validate diagnoses still valid

    1. if ($.encounter.status!="entered_in_error") validate ($.conditions[?(@.verification_status=="entered_in_error")].id is not IN $.encounter.diagnoses[*].condition.identifier.value)

      1. in case of error "The condition can not be canceled while encounter is not canceled" 

  4. Validate cancellation_reason

    1. $.cancellation_reason.coding[*].system == "eHealth/cancellation_reasons"

  5. Validate entities are not canceled yet (status!= "entered_in_error")

    1. in case of error "Invalid transition"

  6. Validate at least one entity in the request marked as "entered_in_error"

    1. in case of error "At least one entity should have status "entered_in_error""

  7. Validate user performs action with an episode that belong to his legal entity

    1. ME.patient{patinet_id}.episodes{episode_id}.managing_organization==token.client_id

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

  8. Validate reasons (eHealth/ICPC2/reasons dictionary)

    1. is case is_active = false return error 422 “value is not allowed in enum

 

Validate legal entity

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

    • ME.episode.managing_organization==token.client_id

      • in case of error return 409 "User is not allowed to perform actions with an episode that belongs to another legal entity"

Validate patient

  • Validate patient is active

    •  ME.patient.status=="active"

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

Validate User

  • Extract user_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 encounter ($.encounter .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 encounter resource ($.approvals.granted_resources.identifier.value==$.encounter_id AND $.approvals.granted_to.identifier.value==PRM.employees.id AND $.approvals.access_level='write')

    • OR user has an employee has MED_ADMIN employee type

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

Processing

  1. Save signed_content to Media Storage

  2. Set status `entered_in_error` for objects, submitted with status `entered_in_error`

  3. Set cancellation_reason

  4. Set explanatory_letter 

  5. Deactivate corresponding diagnoses in the episode in case encounter was entered_in_error

    1. Find episode where id == encouners{encounter_id}.context.identifier.value

    2. Find record in episodes{episode_id}.diagnoses_hstr.evidence.identifier.value==encounter_id

    3. Set is_active = false for this record

  6. Replace current diagnoses 

    1. Set in episodes.current_diagnoses the last record from diagnoses_history where is_active==true

Response structure examples

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

See on Apiary

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"
  }
}
Expand
Code Block
{
  "meta": {
    "code": 404,
    "url": "http://example.com/resource",
    "type": "object",
    "request_id": "req-adasdoijasdojsda"
  },
  "error": {
    "type": "NOT_FOUND",
    "message": "Patient not found"
  }
}

HTTP status codes

5

Response code

HTTP Status code

Message

Internal name

Description

1

Базові

2

202

 

 

3

401

 

Access token validation failed

4

401

Invalid access token

5

401

Unauthorized

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

6

403

Access denied. Party is not verified

7

403

 

Invalid scope

8

1000

404

Composition not found

COMPOSITION_NOT_FOUND_404

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

3

401

Unauthorized

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

4

Специфічні

9

404

 not found

 

10

409

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

11

422

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

12

422

User is not allowed to perform actions with an episode that belongs to another legal entity

13

422

value is not allowed in enum

14

Специфічні

15

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"

...