Versions Compared

Key

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

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Тип правила

Опис

Based on declaration

Лікар з активною декларацією має доступ до всіх даних пацієнта.

Based on managing organization

Користувач може переглядати сутності, створені в даній MSP

Based on context episode

Користувач може переглядати дані, які створені в рамках епізоду лікування, до яких користувач має доступ.

Based on diagnostic report

Користувач може переглядати дані, які є складовою діагностичного звіту, який керується юридичною особою користувача.

Based on origin episode

Лікар може переглядати дані, які бути створені як частина діагностичного звіту або епізоду лікування, до яких користувач має доступ.
Епізод лікування, що містить запит на даний сервіс,  розглядається як унікальний епізод в даному випадку. 

Based on care plan

Користувач з діючим дозволом на план лікування може переглядати та редагувати дані на основі даного плану лікування

Правило

На чому основано

Ресурс

Посилання

Контекст

Логіка

Джерело контенту

@rule_-2

@read @episode @encounter @observation @condition @allergy_intolerance @immunization @risk_assessment @device @medication_statement @service_request @diagnostic_report @procedure @medication_administration @care_plan @activity

Scenario: NHS employee can read patient’s data if he has Justification for monitoring 

Given Justification on monitoring patient's data given by the user (works only from Admin panel, graphql api)

When I require read access

Then I can read

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

by id

patient_id

Це активний токен

by search params

Це активний токен

@rule_-1

@read @allergy_intolerance @immunization @risk_assessment @device @medication_statement

Scenario: Employee can read insensitive patient’s data

Given User access token with client_type not equal to cabinet

When I require read access

Then I can read

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

by id

 

Це активний токен

by search params

Це активний токен

@rule_0

@read @episode @encounter @observation @condition @allergy_intolerance @immunization @risk_assessment @device @medication_statement @service_request @diagnostic_report @procedure @medication_administration @care_plan @activity

@clinical_impression

Scenario: Patient can read it's own data 

Given Patient has access_token given by Cabinet

When I require read access

Then I can read

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

by id

patient_id

Це активний токен наданий до кабінету пацієнта

by search params

@rule_1

@read @episode @encounter @observation @condition @service_request @diagnostic_report @procedure @medication_administration @care_plan @activity @approval@clinical_impression

Scenario: Doctor with active declaration can read all patient data

Given Active declaration with patient

And declaration from the same MSP

When I require read access

Then I can read

На основі декларації

 

 

 

 

 

 

 

 

 

episode

by id

patient_id

 

 

 

 

 

 

 

 

 

Це активна декларація між пацієнтом та лікарем OPS

patient_id from URL

 

 

 

 

 

 

 

 

by search params

encounter

 

by id

by search params

by id in episode context

by search params in episode context

observation

 

by id

by search params

by id in episode context

by search params in episode context

condition

by id

by search params

by id in episode context

by search params in episode context

service_request

by id

by search params

diagnostic_report

by id

by search params

care_plan

by id

by search params

activity

by id

by search params

approval

by id

by search params

clinical_impression

by id

by search params

@rule_2

@read @episode @service_request @diagnostic_report @procedures

Scenario: Doctor can read entity created in the doctors MSP

Given Entity has been created on my MSP

When I require read access

Then I can read

 

 

 

 

 

 

На основі керуючої організації

 

 

 

episode

by id

episode

managing_organization==token.client_id

 

 

DB.episode.managing_organization

by search params

search param {managing_organization} from URL

service_request

by id

service request

DB.service_request.managing_organization

by search params

search param {requester_legal_entity} from URL

diagnostic_report

by id

diagnostic_report

DB.diagnostic_report.managing_organization

by search params

search param {managing_organization} from URL

procedures

by search params

managing_organization

search param {managing_organization} from URL

@rule_3

@read @encounter @observation @condition @service_request @diagnostic_report @device @medication_statement @immunization @risk_assessment @medication_administration @procedure @allergy_intolerance@clinical_impression

Scenario: Doctor can read all the data of episodes created in the doctors MSP

Given Episode context has been created on my MSP

When I require read access

Then I can read

На основі контексту епізоду

encounter

by id

episode

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

episode.managing_organization==token.client_id

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DB.encounter.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

observation

by id

DB.observation.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

condition

by id

DB.condition.episode

by search params

search param {episode_id} from URL

by is in episode context

episode_id from URL (path)

by search params in episode context

service_request

by id

DB.service_request.encounter.episode.managing_organization

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

diagnostic_report

by id

DB.diagnostic_report.encounter.episode.managing_organization

by search params

context_episode_id from URL (path)

medication_statement

by id

IF context is encounter THEN:
DB.medication_statements.context.episode.managing_organization

by search params

search param {episode_id} from URL

immunization

by id

IF context is encounter THEN:
DB.immunizations.context.episode.managing_organization

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

device

by id

IF context is encounter THEN:
DB.devices.context.episode.managing_organization

by search params

search param {episode_id} from URL

risk_assessment

by id

IF context is encounter THEN:
DB.risk_assessments.context.episode.managing_organization

by search params

search param {episode_id} from URL

medication_administration

by id

IF context is encounter THEN:
DB.medication_administrations.context.episode.managing_organization

by search params

search param {episode_id} from URL

procedure

by id

DB.procedures.encounter.episode.managing_organization

by search params

search param {episode_id} from URL

allergy_intolerance

by id

IF context is encounter THEN:
DB.allergy_intolerances.context.episode.managing_organization

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

clinical_impression

by id

DB.clinical_impression.episode

by search params

search param {episode_id} from URL

@rule_4

@read @episode @encounter @observation @condition @allergy_intolerance @immunization @risk_assessment @device @medication_statement @service_request @diagnostic_report @medication_administration

Scenario: Doctor with active approval can read all the data of specified in approval patient

Given Active approval on patient

When I require read access

Then I can read

Не реілазовано

@rule_5

@read @episode @encounter @observation @condition @allergy_intolerance @immunization @risk_assessment @device @medication_statement @service_request @diagnostic_report @procedure @medication_administration@clinical_impression

Scenario: Doctor with active approval can read all the data of specified in approval episodes

Given Active approval on episode

When I require read access

Then I can read

На основі контексту епізоду

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

episode

by id

episode

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Наявний активний дозвіл на епізод виданий співробітником (одним із співробітник користувача) в MongoDB

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DB.episode.id

encounter

 

by id

DB.encounter.episode

Тип правила

Опис

Based on declaration

Лікар з активною декларацією має доступ до всіх даних пацієнта.

Based on managing organization

Користувач може переглядати сутності, створені в даній MSP

Based on context episode

Користувач може переглядати дані, які створені в рамках епізоду лікування, до яких користувач має доступ.

Based on diagnostic report

Користувач може переглядати дані, які є складовою діагностичного звіту, який керується юридичною особою користувача.

Based on origin episode

Лікар може переглядати дані, які бути створені як частина діагностичного звіту або епізоду лікування, до яких користувач має доступ.
Епізод лікування, що містить запит на даний сервіс,  розглядається як унікальний епізод в даному випадку. 

Based on care plan

Користувач з діючим дозволом на план лікування може переглядати та редагувати дані на основі даного плану лікування

Based on care patient

Користувач з діючим дозволом на дані пацієнта може переглядати дані пацієнта

 

Rule: @rule_-2 | Action: @read | (GraphQL only)

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

NHS employee can read patient’s data if he has Justification for monitoring 

 

Given Justification on monitoring patient's data given by the user (works only from Admin panel, graphql api)
When I require read access
Then I can read

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

episode

JustificationFilter schema

patient_id

person_id from JustificationFilter schema

 Є активний токен & та активне підтвердження 

encounter

observation

condition

allergy_intolerance

immunization

risk_assessment

device

medication_statement

medication_request

medication_dispense

service_request

diagnostic_report

procedure

medication_administration

care_plan

activity

 

Rule: @rule_-1 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read insensitive patient’s data
Given User access token with client_type not equal to cabinet

When I require read access

Then I can read

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

allergy_intolerance

by id
by search params

 

 

Є активний токен для client_type.name != CABINET

immunization

risk_assessment

device

medication_statement

Rule: @rule_0 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Patient can read it's own data 
Given Patient has access_token given by Cabinet

When I require read access

Then I can read

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

episode

by id
by search params

patient_id

patient_id from URL 

Є активний токен виданий пацієнту з Cabinet

encounter

observation

condition

allergy_intolerance

immunization

risk_assessment

device

medication_statement

service_request

diagnostic_report

procedure

medication_administration

care_plan

activity

clinical_impression

Rule: @rule_1 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active declaration can read all patient data
Given Active declaration with patient
And declaration from the same MSP

When I require read access

Then I can read

На основі декларації та токену користувача

episode

by id

person_id

person_id from URL

Це активна декларація між пацієнтом та лікарем OPS того ж MSP з токену

by search params

encounter

by id

by search params

by id in episode context

by search params in episode context

observation

by id

by search params

by id in episode context

by search params in episode context

condition

by id

by search params

by id in episode context

by search params in episode context

service_request

by id

by search params

diagnostic_report

by id

by search params

procedure

by id

by search params

medication_administration

by id

by search params

care_plan

by id

by search params

activity

by id

by search params

approval

by id

by search params

clinical_impression

by id

by search params

medication_request_request 

by id

by search params

medication_request

by id

by search params

medication_dispense

by id

by search params (Search Medication dispenses by Medication request ID)

Rule: @rule_2 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read entity created in the employee's MSP
Given Entity has been created on my MSP

When I require read access

Then I can read

На основі керуючої організації

service_request

by id

requester_legal_entity 
+ patient_id

DB.service_request.managing_organization

managing_organization==id

by search param

search param {managing_organization} from URL

managing_organization (requester_legal_entity, )==token.client_id

episode
diagnostic_report
procedures
encounter
condition
observation

by id

managing_organisation + patient_id

DB.episode.managing_organization OR DB.diagnostic_report.managing_organization

managing_organization==id

by search param

search param {requester_legal_entity} from URL

managing_organization (requester_legal_entity, )==token.client_id

medication_request_request

by id

legal_entity + patient_id

search param {legal_entity_id} from URL

legal_entity_id==id

by search param

legal_entity_id ==token.client_id

medication_request

by id

legal_entity + patient_id

search param {legal_entity_id} from URL

legal_entity_id==id

by search param

legal_entity_id ==token.client_id

medication_dispense

by id

legal_entity + patient_id

search param {legal_entity_id} from URL

legal_entity_id==id

by search param (Search Medication dispenses by Medication request ID)

legal_entity_id ==token.client_id

Rule: @rule_3 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read all the data of episodes created in the employee's MSP

Given Episode context has been created on my MSP

When I require read access

Then I can read

На основі контексту епізоду

encounter

by id

episode

DB.encounter.episode

episode.managing_organization==token.client_id

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

observation

by id

episode

DB.observation.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

condition

by id

episode

DB.condition.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

service_request

by id

episode

DB.service_request.encounter.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

diagnostic_report

by id

episode

DB.diagnostic_report.encounter.episode

by search params

context_episode_id from URL (path)

procedure

by id

episode

DB.procedures.encounter.episode

by search params

search param {episode_id} from URL

medication_administration

by id

episode

IF context is encounter THEN:
DB.medication_administrations.context.episode

by search params

search param {episode_id} from URL

device

by id

episode

IF context is encounter THEN:
DB.devices.context.episode

by search params

search param {episode_id} from URL

risk_assessment

by id

episode

IF context is encounter THEN:
DB.risk_assessments.context.episode

by search params

search param {episode_id} from URL

medication_statement

by id

episode

IF context is encounter THEN:
DB.medication_statements.context.episode

by search params

search param {episode_id} from URL

immunization

by id

episode

IF context is encounter THEN:
DB.immunizations.context.episode

by search params

search param {episode_id} from URL

allergy_intolerance

by id

episode

IF context is encounter THEN:
DB.allergy_intolerances.context.episode

by search params

search param {episode_id} from URL

medication_request

by id

episode

DB.medication_request.context_episode_id

by search params

search param {episode_id} from URL

medication_dispense

by id

episode

DB.medication_request.context_episode_id

by search params (Search Medication dispenses by Medication request ID)

search param {episode_id} from URL

medication_request_request

by id

episode

DB.medication_request_request.context_episode_id

by search params

search param {episode_id} from URL

clinical_impression

by id

episode

DB.clinical_impression.context_episode_id

by search params

search param {episode_id} from URL

Rule: @rule_4 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval can read all the data of specified in approval patient

Given Active approval on patient

When I require read access

Then I can read

На основі patient_id

 

 

 

 

 

episode

by id

 patient_id

 

 

 

 

patient_id з URL

 

 

 

 

Наявний активний дозвіл на дані пацієнта, який наданий співробітнику (одниз зі співробітників користувача) в MongoDB

 

by search params

active diagnosis

short episodes by search params

by patient_id in observation context

by patient_id in condition context

by patient_id in procedure context

by patient_id in diagnostic_report context

encounter

by id

by search params

by id in episode context

by search params in episode context

short encounters by search params

short encounters by ID

observation

by id

by search params

short observations by search params

short observation by id

condition

by id

by search params

short conditions by search params

short conditions by id

service_request

list in episode context

by search params

by id in episode context

by id

by requisition

procedure

by id

by search params

short procedures by id

short procedures by search params

diagnostic_report

 by id

by search params

approved by patient_id

short diagnostic_reports by search params

by patient_id in observation context

short diagnostic_reports by id

care_plan

by id

by search params

by requisition

by activity id

activity

by id

by search params

clinical_impression

by id

by search params

medication_request_request

by id

by search params

medication_request

by id

by search params

medication_dispense

by id (details in person context)

by search params (by medication request id)

by search params

search param {

Rule: @rule_5 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval OR to the legal_entity (one of legal_entity's employee) can read all the data of specified in approval episodes

Given Active approval on episode

When I require read access

Then I can read

На основі контексту епізоду

episode

by id

 

http://DB.episode.id

Наявний активний дозвіл на епізод виданий співробітником (одним із співробітників користувача) в MongoDB

encounter

by id

episode

DB.encounter.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

observation

by id

episode

DB.observation.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

condition

by id

episode

DB.condition.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

service request

by id

episode

DB.service_requset.encounter.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

diagnostic_report

by id

episode

DB.diagnostic_report.encounter.episode

by search params

search param {episode_id} from URL

medication_administration

by id

episode

IF context is encounter THEN:
DB.medication_administrations.context.episode

by search params

search param {episode_id} from URL

procedure

by id

episode

DB.procedures.encounter.episode

by search params

search param {episode_id} from URL

medication_request

by id

episode

DB.medication_request.context_episode_id

by search params

search param {episode_id} from URL (can be used with {encounter_id} search param for sort by encounter)

medication_dispense

by id

episode

DB.medication_request.context_episode_id

by search param (Search Medication dispenses by Medication request ID)

search param {episode_id} from URL (can be used with {encounter_id} search param for sort by encounter)

medication_request_request

by id

episode

DB.medication_request_request.context_episode_id

by search params

search param {episode_id} from URL (can be used with {encounter_id} search param for sort by encounter)

clinical_impression

by id

episode

DB.clinical_impression.context_episode_id

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

observation

 

by id

DB.observation.episode

by search params

search param {episode_id} from URL

by id in episode context

episode_id from URL (path)

by search params in episode context

condition

 

by id

DB.condition.episode

(can be used with {encounter_id} search param for sort by encounter)

Rule: @rule_6 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read entity originated by episode created in the employee's MSP

Given Entity has been originated by mine MSP episode

When I require read access

Then I can read

На основі первинного епізоду

encounter

by id

origin_episode

DB.encounter.origin_episode

origin_episode.managing_organization==token.client_id

by search params

Search param {origin_episode_id} from URL

diagnostic repost

by id

in episode context

service request

by id

episode_id from URL (path)

by search params in episode context

origin_episode

DB.

service

diagnostic_

requset

report.

encounter.

origin_episode

by search params

search param diagnostic report

Search param {origin_episode_id} from URL

by id in episode context

episode_id from URL (path)

procedures

by id

origin_episode

DB.

diagnostic_report

procedures.encounter.episode

by search params

search param {episode_id} from URL

procedure

by id

DB.procedures.encounter.episode

by search params

search param {episode_id} from URL

clinical_impression

by id

DB.clinical_impression.episode

by search params

search param {episode

Rule: @rule_7 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read all the data of diagnostic report originated by episode created in the employee's MSP

Given Diagnostic report context has been originated by mine MSP episode

When I require read access

Then I can read

На основі первинного епізоду

observation

by id

diagnostic_report

DB.observation.diagnostic_report.origin_episode

origin_episode.managing_organization==token.client_id

by search params

Search param {diagnostic_report_id} from URL

Rule: @rule_

6

@read @diagnostic_report @encounter @procedure

Scenario: Doctor can read entity

8 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read all the data of encounter originated by episode created in the

doctors

employee's MSP

Given

Entity

 Encounter context has been originated by mine MSP episode

When

I

 I require read access

Then

I

 I can read

На основі первинного епізоду

 

 

encounter

by id

origin_episode

 

 

origin_episode.managing_organization==token.client_id

 

DB.

observation

by id

encounter

DB.observation.context.origin_episode

origin_episode.managing_organization==token.client_id

by search params

Search param {encounter_id} from URL

condition

by id

encounter

DB.condition.context.origin_episode

by search params

Search param {encounter_id} from URL

diagnostic_report

by id

encounter

DB.diagnostic_report.encounter.origin_episode

by search params

Search param {

origin

encounter_

episode_

id} from URL

diagnostic repost

medication_administration

by id

encounter

IF context is encounter THEN:
DB.

diagnostic

medication_

report.origin_

administrations.context.encounter

by search params

search param {encounter_id} from URL

procedure

by id

encounter

DB.procedures.encounter.episode

by search params

Search param 

search param {

origin

encounter_

episode_

id} from URL

procedures

medication_request

by

search params

id

encounter

DB.

diagnostic

medication_

report.origin_episode

@rule_7

@read @observation

Scenario: Doctor can read all the data of diagnostic report originated by episode created in the doctors MSP

Given Diagnostic report context has been originated by mine MSP episode

When I require read access

Then I can read

На основі первинного епізоду

observation

by id

diagnostic_report

origin_episode.managing_organization==token.client_id

DB.observation.diagnostic_report.origin_episode

by search params

Search param {diagnostic_report

request.context

by search params

search param {encounter_id} from URL

medication_request_request

by id

encounter

DB.medication_request_request.context

by search params

search param {encounter_id} from URL

Rule: @rule_

8

@read @observation @condition @allergy_intolerance @immunization @risk_assessment @device @medication_statement @service_request @diagnostic_report @procedure @medication_administration@clinical_impression

Scenario: Doctor can read all the data of encounter originated by episode created in the doctors MSP

Given Encounter context has been originated by mine MSP episode

When I

9 | Action: @read | NOT IMPLEMENTED YET

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval can read data, originated by the episode Given Active approval on patient

When I require read access

Then

I can read

На основі первинного епізоду

observation

by id

encounter

 

 

 

 

 

 

origin_episode.managing_organization==token.client_id

 

 I can read

 

encounter

 

 

 

 

 

DB.

observation

.context.origin_episode

by search params

Search param {encounter_id} from URL

condition

by id

DB.condition.context.origin_episode

by search params

Search param {encounter_id} from URL

service request

by id

DB.service_request.encounter.origin_episode

by search params

Search param {encounter_id} from URL

diagnostic_report

by id

DB.diagnostic_report.encounter.origin_episode

by search params

Search param {encounter_id} from URL

procedure

by id

DB.procedure.origin_episode

by search params

Search param {encounter_id} from URL

@rule_9 

@read  @encounter @observation @condition @service_request @diagnostic_report

Scenario: Doctor with active approval can read data, originated by the episode

Given Active approval on episode

When I require read access

Then I can read

Не реалізовано

@rule_10 

@read @observation

Scenario: Doctor

 

 

 

 

 

condition

 

 

 

 

 

service_request

 

 

 

 

 

diagnostic_report

 

 

 

 

Rule: @rule_10 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee can read all the data of diagnostic report created in the

doctors

employee's MSP

Given

Diagnostic

 Diagnostic report context has been originated by mine MSP

When

I

 I require read access

Then

I

 I can read

На основі діагностичного звіту

observation

by id

diagnostic_report

DB.observation.diagnostic_report.managing_organization

==token.client_id

DB.observation.

diagnostic_report.managing_organization==token.client_id

by search params

Search param {diagnostic_report_id} from URL

Rule: @rule_

11 

@read @observation

Scenario: Doctor

11 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval can read all the data of specified in approval diagnostic report

Given

Active

 Active approval on diagnostic report

When

I

 I require read access

Then

I

 I can read

На основі діагностичного звіту

observation

by id

diagnostic_report

DB.observation.diagnostic_report.managing_organization

Наявний активний дозвід на діагностичний звіт наданий співробітником (одним з співробітників користувача) в MongoDB

DB.observation.diagnostic_report

by search params

Search param {diagnostic_report

_id} from URL

@rule_12 

@read @care_plan @activity @medication_request @medication_request_request

Scenario: Doctor

_id} from URL

Rule: @rule_12 | Action: @read 

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval can read the data associated with the care plan

.

Given

Active

 Active approval on care_plan

When

I

 I require read access

Then

I

 I can read

На основі плану лікування

care_plan

by id

care_plan

 

+ patient_id

DB.care_plan.id=approvals.granted_resources[].value

Наявний активний

дозвіл

апрувал (access_level=read)

 на

на care_plan, наданий

співробітнику (одним з співробітників користувача) в MongoDB

 

DB.care_plan.id=approvals.granted_resources[].value

пацієнтом співробітнику (один з співробітників користувача) в MongoDB

activity

by id

care_plan + patient_id

from URL (path)

DB.activities.

care_plan

[].id=approvals.granted_resources[].value

_id & patient_id from URL (path) 

by search params

medication_request_

requests

request

by

search params

id

care_plan + patient_id

from URL (path)

DB.medication_request_requests.based_on.

care_plan

[].id=approvals.granted_resources[].value

_id & patient_id from URL (path) 

by search params

medication_

requests

request

by

search params

id

care_plan + patient_id

care_plan_id & patient_id from URL (path)

DB.medication_requests.based_on.care_plan[].id=approvals.granted_resources[].value

@rule_13 

@write @care_plan @activity @medication_request @medication_request_request

Scenario: Doctor

 

by search params

medication_dispense

by id

care_plan + patient_id

care_plan_id & patient_id from URL (path) 

by search params (Search Medication dispenses by Medication request ID)

Rule: @rule_13 | Action: @write

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval can write the data associated with the care plan

.

Given Active

Given Active approval on care_plan

When

I

 I require write access

Then

I can write

 I can write

На основі плану лікування

care_plan

by id

care_plan + patient_id

DB.care_plan.id=approvals.granted_resources[].value

Наявний активний дозвіл (access_level=write) на care_plan наданий співробітнику (одним з співробітників користувача) в

MongoDBDB.

MongoDB

activity

by id

care_plan + patient_id

care_plan

.id=approvals.granted_resources[].value

complete

cancel

activity

_id & patient_id from URL (path) 

by search params

medication_request_request

by id

care_plan + patient_id

from URL (path)

DB.activities.

care_plan

[].id=approvals.granted_resources[].value

_id & patient_id from URL (path) 

by search params

create

complete

cancel

medication_request

_requests

by

search params

id

care_plan + patient_id

care_plan_id & patient_id from URL (path)

DB.medication_request_requests.based_on.care_plan[].id=approvals.granted_resources[].value

medication_requests

by search params

 

by search params

medication_dispense

by id

care_plan + patient_id

care_plan_id & patient_id from URL (path)

DB.medication_requests.based_on.care_plan[].id=approvals.granted_resources[].value

@rule_14 

@read @service_request @encounter @diagnostic_report @procedure @medication_dispense

Scenario: User

 

by search params (Search Medication dispenses by Medication request ID)

Rule: @rule_14 | Action: @read

Правило

На чому основано

Ресурс

Посилання

Контекст

Джерело контенту

Логіка

Employee with active approval on the care plan can read the data based on this care plan

.

Given Entity When I

Given Entity based on care_plan

And Active approval on care_plan

When I require read access

Then

I can read

На основі плану лікування

service_request

by id

care_plan

 I can read

На основі плану лікування

service_request

by id

care_plan (based_on)  + patient_id

DB.service_request.based_on.care_plan[].id=approvals.granted_resources[].value

Наявний активний дозвіл (access_level=read/write

) на

) на care_plan наданий співробітнику (одним з співробітників користувача) в MongoDB

by search params

care_plan + patient_id

care_plan_id from URL (search param) & patient_id from path 

encounter

by id

patient_id ->.  care_plan

наданий співробітнику (одним з співробітників користувача) в MongoDB

 

DB.

(based_on service_request)

DB.encounter.based_on.service_request.based_on.care_plan[].id=approvals.granted_resources[].value

by search params

care_plan_id from URL (search param)

DB

OR DB.diagnostic_report.based_on.service_request.based_on.care_plan[].id=approvals.granted_resources[].value

encounter

by id

care_plan_id from URL (search param)

DB

OR DB.procedure.based_on.service_

requests

request.based_on.care_plan[].id=approvals.granted_resources[].value

diagnostic_report

by id

procedure

by id

  • - Для всіх ресурсів повинен бути вказаний patient_id в контексті додаткого параметру