Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
REST API method / Метод REST API (настанова) (
Info
Note

Сторінка знаходиться в процесі розробки. Інформація на ній може бути застарілою.

Info

/wiki/spaces/EN/pages/17591304241 (remove the link block before publishing the document)

Table of Contents

Properties of a REST API method document

Page Properties
idpage_properties_method_REST API

Document type

Метод REST API

Document title

[Document status] REST API [Назва методу] [ID методуDRAFT] Cancel Diagnostic Report Package [API-007-003-001-0239]

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://ehealthmedicaleventsapimedicaleventsmisapi.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

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 ConfluenceN/A

Dictionaries

N/A

Input parameters

Input parameter

Mandatory

Type

Description

Example

1

2

Request structure

See on API-specification

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

Headers

...

Key

...

Value

...

Mandatory

...

Description

...

Example

...

Content-Type

...

application/json

...

M

...

Тип контенту

...

Content-Type:application/json

...

Authorization

...

Bearer {{access_token}}

...

Authorization:Bearer {{access_token}}

...

API-key

...

{{secret}}

...

Headers

Request data validation

Authorize

Request to process the request using a token in the headers

...

  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

Expand
titleResponse Example
Code Block
languagejson
{
  "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
titleResponse Example
Code Block
languagejson
{
  "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

403

Access denied. Party is not verified

4

403

Invalid scopes

 

5

403

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

6

404

Patient not found

 

7

409

 

Validation failed

8

409

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

9

Специфічні

10

Post-processing processes

Description of actions performed on data after processing

Technical modules where the method is used

List of pages describing technical N/A

Technical modules where the method is used

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

...