# Use Case / Прецедент "Подбор КИ" (BUC1)
###### tags: `Типовой проект`

[TOC]

# Document Information/ Информация о документе
| | |
|---|---|
| **Document Title**|UCD Подбора КИ |
| **Document Owner** |Nadezhda Podolskaia |
| **Version** |1.0 |
| **Status** |Draft |
| **Date** |03.06.2022 |

# Brief Description/ Краткое описание
> Insert a 1-2 sentence description of this use case. Be sure to include a starts when / ends when statement to clarify the beginning and ending points of the scope of this process or piece of functionality.

Этот прецедент (сценарий использования) описывает Подбор КИ для онкологического консилиума.

# Actors / Действующие лица / Участники
>List any roles or systems involved with this process or use case. A person or system fulfilling a role will be the actor in one of the steps.

1. Лечащий врач

# Pre-Conditions / Предусловия
> List anything that must be true before this process or functionality begins. Preconditions should be states that a system can validate to be true. A common example is that a specific Actor has logged into the System.

Лечащий врач направляет пациента на онкологический консилиум.

# Basic Flow / Основной путь
> The basic flow is the normal course of events, otherwise called the “happy path.” Ask yourself, what happens most of the time and you’ll discover the steps that belong here. You’ll want your basic flow to cover the full scope of activities between the starts when and ends when.
> Create a numbered list of each step below. I recommend using the Word “numbered list” functionality to automatically number the list.

:arrow_down_small: 1. Врач выбирает источник клинических исследований (см. источники)
:arrow_down_small: 2. Врач запрашивает перечень клинических исследований из источника
:arrow_down_small: 3. Врач сохраняет подходящие клинические исследования из списка

Источники
1) clinicaltrials.gov

# Alternate/Exception Flows / Альтернативные/Исключительные пути
> An alternate flow is a variation from the basic flow. Alternatives can be triggered at any step in the basic flow and often reinsert the actors back into the basic flow.
An exception flow is an error, or a negative condition. When an exception is encountered, it prevents the process from finishing through to its conclusion until it’s addressed.
Number your alternate and exception flows to indicate the step at which the variation occurs. For example, a variation on step 3 could be listed as 3a and a second variation as 3b, and so forth.
Describe the alternate functionality and then identify at what step in the basic flow this variation picks back up. For exception flows that result in the use case ending, simply write, “Use Case Ends.”

2а. Запрошенный источник недоступен

2б. В запрошенном источнике не найдено клинических исследований

3а. Нет подходящих клинических исследований

# Post Conditions
> Post-conditions indicate what must be true of the state of the system after the steps of the use case are complete. These should be true for the basic flow and all alternate flows. Exception flows may have different post-conditions or none at all.

Основной путь
- для пациента сохранены подобранные КИ

Исключительный путь
- врач оповещён о недоступности источника
- врач оповещён об отсутсвии КИ в источнике
- врач прервал подбор из-за отсутствия подходящих исследований

# Supplemental Requirements
> This is a special section I use to hold miscellaneous requirements related to the use case. Often you’ll find BAs including a Business Rules section or other collection of information related to the use case. These may or may not be actual requirements – you’ll want to establish a clear pattern and communicate that clearly and ensure it’s consistent with how your organization documents this type of requirement. I’ve also used this section to capture the most salient decisions and notes so they are stored right with the use case for future consideration.

Необходим подбор клинических исследований с сайта clinicaltrials.gov.

# Visual Model
> Many use cases are enhanced by a visual model. A simple work-flow diagram can be used to visually show the sequence of steps and alternate and exception flows. A user interface mock-up can be used to show a possible representation of these user requirements in an interface (or a desired representation). In some organizations, a more formal UML diagram may be appropriate.

@startuml
start
:1. Врач выбирает источник клинических исследований (см. источники);
:2. Врач запрашивает перечень клинических исследований из источника;
:3. Врач сохраняет подходящие клинические исследования из списка;
stop
@enduml