--- # System prepended metadata title: Medical Booking System - 2.0 tags: [BPAS] --- # 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 ![](https://i.imgur.com/ZheE2Q7.png) ## :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. ::: ![](https://i.imgur.com/wIUA6OR.png) ![](https://i.imgur.com/cWqs2sC.png) ## :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 ```plantuml @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 ```plantuml @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 ```plantuml @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 ```plantuml @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 !include 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 ![](https://i.imgur.com/m0nEs8G.png) 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 ![](https://i.imgur.com/jomAcwl.png)