ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

Properties of a REST API method document

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-007-003-001-0239

Microservices (namespace)

ME

Component

Diagnostic Report Data Package

Component ID

COM-007-003

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

https://ehealthmedicaleventsapi.docs.apiary.io/#reference/medical-events/diagnostic-report-data-package/cancel-diagnostic-report-package

Resource

{{host}}/api/patients/{{id}}/diagnostic_report_package

Scope

diagnostic_report:cancel

Protocol type

REST

Request type

PATCH

Sync/Async

Async

Public/Private

Public

Purpose

This web service allows to cancel diagnostic report and observations, crated as a part of Diagnostic Report Data Package, in case they were entered in error.

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.

Logic

Відкликання діагностичного звіту

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

 Example
{
  "signed_data": "'ew0KICAicGVyaW9kIjogew0KIC...'"
}

Headers

Key

Value

Mandatory

Description

Example

1

Content-Type

application/json

M

Тип контенту

Content-Type:application/json

2

Authorization

Bearer {{access_token}}

Authorization:Bearer {{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 (PRM.employees.id==$.diagnostic_report.reported_by.identifier.value))

  2. Compare signed_content to previously created content

    1. select encounter, select * from observations where diagnostic_report.identifier.value=$.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 entities are not canceled yet (status!= "entered_in_error")

    1. in case of error "Invalid transition"

  4. 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""

Validate legal entity

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

    • $.diagnostic_report.managing_organization==token.client_id

      • in case of error return 403 "User is not allowed to perform actions with an enity 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 diagnostic report ($.diagnostic_report.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 diagnostic_report resource ($.approvals.granted_resources.identifier.value==$.diagnostic_report._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 diagnostic report, don't has approval or required employee type"

  • 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")

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 

Response structure examples

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

Description of the REST API response structure, example

 Response Example
{
  "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"
  }
}
 Response Example
{
  "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

Response code

HTTP Status code

Message

Internal name

Description

1

Базові

2

202

 

 

3

401

Unauthorized

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

4

403

Access denied. Party is not verified

5

403

Invalid scopes

 

6

403

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

7

1000

404

Composition not found

COMPOSITION_NOT_FOUND_404

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

8

404

Patient not found

 

9

409

 

Validation failed

10

409

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

11

Специфічні

12

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

  • No labels