# Medical Booking System - 2.0

###### tags: `BPAS`

[toc]

:::info
:bulb: **TO-BE Scenario vs 2.0 (Covid-19)**

In this scenario, the **Medical Booking System (MBS)** is autonomous and available 24/7. Patient uses **MBS** to book the appointment without the need of the receptionist.
Doctors are now required to keep their **online calendar** up to date. We will use an existing popular Calendar enterprise web solution
:::

## :memo: To Be workflow model


## :memo: Use Case Model from To-Be Workflow

:::success
* Do not convert **Manual activities** into use cases
* For **interactive activities** (user task) the use cases are in relationship with the human actor. If multiple systems are involved, then they are also related with the other system
* For **automated activities** (system task) the use cases are in relationship with the system actor
* For **integration activities** (automated activities involving 2 systems) we depict two use cases for integration.
:::



## :memo: Modeling use cases

### Step 1: Identify Actors

We identify one actor in the lecture. Mac as a patient. Recall that an actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system.

An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model.

If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Make Appointment figure.

To facilitate collaboration and quick use case modeling do check the [plantuml use case reference](https://plantuml.com/use-case-diagram)

- [ ] Complete the Actors for the Medical Booking System To-Be Scenatio version 2

@startuml
left to right direction
'Complete the Actors for the Medical Booking System Scenatio

actor "Patient" as p
actor "Doctor" as d
actor "MBS" as m
actor "Calendar" as c

@enduml

### Step 2: Identify use cases

* The tasks that each Actor requires the system to perform. This may influence both the description of the Actor and the Use Case.
* Whether each Actor needs to create, read, update, and/or delete any data to/from the system which is commonly referred to as “CRUD”: Create, Read, Update, and Delete.
* If any of the Actors informs the system of any changes.
* If any Actor requires notification of any system occurrences.

- [ ] Complete the use cases for the Medical Booking System Scenatio below

@startuml
left to right direction
'Complete the use cases for the Medical Booking System Scenatio
  (Search for Doctor Availability)
  (Confirm Appointment Selection)
  (Checks Doctor Availability in Calendar)
  (Logins into MBS) 
  (Reserve Appointment in Calendar)
  (Email Appointment Confirmation to Patient)
  (CRUD Calendar)
  (Reply Doctor Availability)
  (Confirm Appointment Reservation)
@enduml

### Step 3: Depict cases in graphical mode
We use the relationship to represent the communication between the actor and the use case
* Depicted by line or double-headed arrow line
* Also called association relationship

## Use case Solution

@startuml
left to right direction

actor "Patient" as p
actor "MBS" as m
actor "Calendar" as c
actor "Doctor" as d
rectangle "Medical Booking System Proposal" {
  (Search for Doctor Availability with MBS) as UC1
  (Confirm Appointment Selection in MBS) as UC2
  (Checks Doctor Availability in Calendar) as UC3
  (Login into MBS) as UC4
  (Reserve Appointment in Calendar) as UC5
  (Email Appointment Confirmation to Patient) as UC6
  (CRUD Calendar) as UC7
  (Reply Doctor Availability to MBS) as UC8
  (Confirm Appointment Reservation with MBS) as UC9  
}
p -- UC1
p -- UC2
p -- UC4
'''UC1 -- m
'''UC2 -- m
UC3 -- m
'''UC4 -- m
UC5 -- m
UC6 -- m
''c -- UC7
c -- UC8
c -- UC9
d -- UC7
@enduml

## :memo: Use Package

@startuml
left to right direction

package "Calendar-CORE" {
  (CRUD Calendar)
}

package "MBS-Integration"{
  (Checks Doctor Availability in Calendar)   
  (Reserve Appointment in Calendar)
}

package "Calendar-Integration" {
  (Reply Doctor Availability)
  (Confirm Appointment Reservation)
}

package "MBS-CORE" {
  (Search for Doctor Availability)
  (Confirm Appointment Selection)
  (Logins into MBS) 
  (Email Appointment Confirmation to Patient)
}

@enduml

## :memo: Function Model

| Function | Use Cases | New/Existing/To be modified | System/Comments
| --------|-----------|-----------|-----------|
| MBS-CORE |Search for Doctor Availability|* |MBS/Patient searchs for his doctor availability |
| MBS-CORE |Confirm Appointment Selection|* |MBS/System acknowledges confirmation of appointment |
| MBS-CORE |Logins into MBS|* |MBS/ Patient is authenticated in the system |
| MBS-CORE |Email Appointment Confirmation to Patient|* |MBS/System acknowledges confirmation via email |
| MBS-Integration |Checks Doctor Availability in Calendar|* |MBS/System integration with Calendar |
| MBS-Integration |Reserve Appointment in Calendar|* |MBS/System integration with Calendar |
| Calendar-Integration |Reply Doctor Availability|* |Calendar/System API Response |
| Calendar-Integration |Confirm Appointment Reservation|* |Calendar/System API Response |
| Calendar-CORE |CRUD Calendar|* |Calendar/Existing Cloud Solution|

## :construction_worker: Complete the form

Work individually, in pairs or trios to [complete the Function Model](https://forms.office.com/r/8ubRSxpiNf)

## Process inovation extension
Work individualy or in teams to brainstorm the different tasks in the process and how they can be augmented using innovative technologies.

See below for a possible solution