# Medical Booking System - 2025

###### 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 single-headed arrow line from Human Actor to Use Case
* Depicted by double-headed arrow line to denote Integration of **IT Information Systems**

## Use case Solution

@startuml
left to right direction

actor "Customer Service Officer" as CSO
actor "Marketing Officer" as MO
actor "RAS" as RAS
actor "IMS" as IMS

rectangle "UEN Gov Website" {
    usecase "Verify customer's UEN in Gov website" as UC2
}

rectangle "IMS System" {
    usecase "Send match results to RAS" as UC10
    usecase "Update customer selection sent by RAS" as UC11
}

rectangle "RAS System" {
    usecase "Enter customer requirements in RAS" as UC1
    usecase "View industrial spaces" as UC12
    usecase "Update rental application rejection in RAS" as UC3
    usecase "Update RAS of customer rejection" as UC14
    usecase "View rental requirements in RAS" as UC4
    usecase "Reserve customer selection in RAS" as UC13
    usecase "Send customer request email to MO" as UC5
    usecase "Send customer request SMS to MO" as UC6
    usecase "Send customer application approval request email to LM" as UC7
    usecase "Send match request to IMS" as UC8
    usecase "Send customer selection to IMS" as UC9
}

CSO --> UC1
CSO --> UC2
CSO --> UC3
CSO --> UC4

UC12 <-- MO
UC13 <-- MO
UC14 <-- MO
UC4 <-- MO

UC8 <--> IMS
UC9 <--> IMS

UC10 <--> RAS
UC11 <--> RAS

' Invisible layout hints to force horizontal pairing
UC1 -[hidden]-> UC12
UC4 -[hidden]-> UC13
UC3 -[hidden]-> UC14
UC6 -[hidden]-> UC9
UC5 -[hidden]-> UC8

' Invisible layout hint to place IMS at the same level as UEN
UC2 -[hidden]-> UC10

@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)

@startuml
set separator none
title Software System - System Context

left to right direction

!include <C4/C4>
!include <C4/C4_Context>

Person(User, "User", $descr="", $tags="", $link="")
System(SoftwareSystem, "Software System", $descr="", $tags="", $link="")

Rel(User, SoftwareSystem, "Uses", $techn="", $tags="", $link="")

SHOW_LEGEND(true)
@enduml

## 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