CLAP - A MyHealthRecord add-on app

1. Architectural Design
a. System Context and Architecture

The goal of this project is to make it easier for professionals to access a patient's records
and medical information. A database of patient records with each patient's patient ID, visit
history, medication information, and other details is expected to be part of the project.
Additionally, the physicians will be able to create a list of patients who need to be followed
up with, schedule that follow-up, and add treatment information and medications. In layman's
words, the CLAP initiative is designed to make it possible for clinicians to manage and
retrieve patient data.
With CLAP, professionals should be able to obtain the right patient medical information, add
prescriptions for new checkups and treatment information, and prepare a summary report
using their preferred criteria.
CLAP shall interface with the following classes of users:
1. System Administrator - Most likely a government-appointed expert who has specific
access rights to drive and control data and system initialisation.
2. Registered Patient - a citizen of Australia who is enrolled and has access to their own
patient record in the database of patient records.
3. Clinician - A licenced medical professional who is registered with the Australian
Medical Practices has the authority to add new prescriptions, treatments, and patient
conditions as well as update patient conditions and create new treatment records by
amending current records.

4. Non-Registered Clinician - National Healthcare Management offers options for first-
time users to access its services, followed by a login page.

5. Non-Registered Patient - Connecting to pertinent identifying documents in order to
create a profile and access the government's maintained database of medical
records. After verification, the non-registered user will receive a temporary ID before
receiving their original Patient ID from the Patient's Records.
The system context is described below.
The architecture is described after that using box-and-line diagrams. The used context is
described as a legend for understanding purposes.

b. Justification of design decisions

The architectural design of CLAP is described using 3 of users - clinicians, administrators,
and patients/citizens.

We have identified that one of the problems people face while authenticating their Identity-
related documents is, malpractice. To avoid this, we have added an interface for adding

necessary proofs.
Non-functional requirements such as availability, consistency and security are given priority
over performance, since the data being fed into the system if leaked, would harm the citizens
of Australia, and make the country prone to cyber-attacks and attacks of other sorts. Also,
consistency must be maintained, since it deals with patient records, so in order to

understand and make decisions on basis of data for a patient, it must be consistently
updated everywhere.
Reusability of parts - classes is also given importance. Sections such as search and
summarize for all actors will be reused. The classes for actors may be deduced from an
object "person"; hence, inheritance is also given importance while designing.

2.Conceptual Model (Conceptual Class Diagram)

3.Use-case Level Behaviour Design

a. Process Description

The SRS document contains the results of the use case identification procedure. A website's
login page is the first place where users can access data and information. By allowing users
to authenticate themselves and be authenticated by the website, users are allowed to travel
to other portals or their own web pages. After the database has compared users' logins,
users can retrieve the data they need. In order to extract data, hospitals and other sources
use the same database. Events-driven models such as system sequence have been made
for the CLAP web application.

b. System Sequence Diagram

c. Partial design class diagram

d. Object interaction diagram