Versions Compared

Key

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

...

...

...

...

...

...

...

...

...

...

...

...

Table of Contents
minLevel1
maxLevel3

Purpose

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

Specification

Page Properties

Link

https://medicaleventsmisapi.docs.apiary.io/#reference/medical-events/procedures/cancel-procedure

Resource

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

Scope

procedure:cancel

Components

Episode of Care

Microservices

API paragraph not found

Protocol type

REST

Request type

PATCH

Sync/Async

Async

Public/Private/Internal

Public

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)

Request structure

See on Apiary

...

Authorization

...

Example:

Expand
titleRequest example
Code Block
{
  "signed_data": "ew0KICAicGVyaW9kIjogew0KIC..."
}

Authorize

Request to process the request using a token in the headers

  • Verify the validity of access token

...

    • return 401 in case validation fails

  • Verify token is not expired

    • in case error - return 401 

...

  • Check user scopes in order to perform this action (scope = 'procedure:write')

...

    • return 403 in case invalid scope(s)

Headers

Наприклад:

  • Content-Type:application/json

  • Authorization:Bearer {{access_token}}

  • API-key:{{secret}}

Request data validation

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==$

...

    1. .performer.identifier.value))

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

  1. 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,

...

    1.  status_reason and explanatory_letter )

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

...

  1. Validate status_reason

...

  1. is in dictionary eHealth/procedure_status_reasons

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

  2. 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

...

      1. 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

See on Apiary

Example:

Expand
titleResponse example
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"
  }
}

Post-processing processes

API paragraph not found

HTTP status codes

Page Properties

HTTP status code

Message

What caused the error

 202

 

 

401

Access denied

 

403

Invalid scopes

 

404

Patient not found

409

 

Validation error

422

 

Validation error