SWE2027- Knowledge Management Systems

Report Template for Review-2 of Project-based Component

(To be submitted on or before 21st September 2023)

(A) Project Title: Knowledge Extraction for Detection of Diabetes

(B) Project Team
Reg.No. Student Name Signature
20MIS0010 VELAGA LALITH SRINIVAS
20MIS0113 MOGALLAPALLI NAGA VENKATESHWARA
NIKITH
20MIS0134 KUNKU SUJAN PRAJAY KUMAR
(C) Minutes of meetings of the project team are to be attached as annexures to this report
along with weekly activity reports for each team member.

(D) Suggestions given by course faculty and students are to be attached as annexures to this report

(E) Answer the following questions in the space provided for

Q1. Mention various architectural styles or patterns. Which architectural style or pattern did
you use for architectural design of the system pertaining to your chosen project any why?

Answer-1:

Various Architectural styles or patterns:

1. Data-Centric Architecture:
Given the importance of data in diabetes detection, the system's architecture should revolve around
effective data management. This may involve designing a robust data pipeline for collecting and
processing patient data, integrating data from various sources, and ensuring data security and privacy.

2. Client-Server Architecture:
- In this architecture, the system is divided into two main components: the client, which interacts
with the user, and the server, which processes requests, manages data, and performs the core business
logic.
- Recommendation: You could use a client-server architecture to ensure that the payroll system is
easily accessible from various client devices (e.g., web browsers, mobile apps), while centralizing data
and business logic on the server for security and scalability.

3. MVC (Model-View-Controller):
- MVC is a design pattern that separates the application into three interconnected components: Model
(data and business logic), View (user interface), and Controller (handles user input).
- Recommendation: Employing MVC can help you achieve a separation of concerns and
maintainability in your payroll system. The Model can handle payroll calculations, while the View
manages the user interface, and the Controller controls the flow of data and user interactions.
4. Microservices Architecture:
- Microservices break down a monolithic application into a collection of small, independent services
that communicate via APIs. Each service handles a specific business function.
- Recommendation: For a large-scale payroll management system, you might consider a
microservices architecture to achieve scalability, maintainability, and flexibility. Each microservice
can be responsible for specific payroll-related functions (e.g., employee management, payroll
calculation, reporting).

5. Layered Architecture:
- In a layered architecture, the system is divided into distinct layers (e.g., presentation layer, business
logic layer, data access layer) where each layer has a specific responsibility.
- Recommendation: Layered architecture can help you organize your payroll management system
into clear and modular components. It promotes separation of concerns and allows for easier
maintenance and testing.

6. Event-Driven Architecture:
- Event-driven architecture relies on asynchronous communication between components through
events and message queues.
- Recommendation: Consider using an event-driven architecture to handle real-time updates and
notifications in your payroll system. For example, you can use events to trigger payroll processing
when certain conditions are met or to notify employees about their paychecks.

7. RESTful API:
- REST (Representational State Transfer) is an architectural style for designing networked
applications. It uses standard HTTP methods for CRUD (Create, Read, Update, Delete) operations.
- Recommendation: Implementing a RESTful API can make your payroll system accessible over the
web, allowing external integrations and easy consumption by different clients, including web and
mobile applications.

For our project we have chosen RESTFUL API for architectural design of the system pertaining to our
chosen payroll management system. It is because our architectural system responses in such a way that
based on the user request the query is been processed and the response is been reported back to the
user. This can be easily implemented by the RESTful API. So we have chosen the RESTful API.

Q2. Illustrate and briefly discuss the architectural design (i.e. high-level design) of the system
pertaining to your chosen project.

Answer-2:
A simplified architecture based on a three-tiered model: Presentation Layer, Business Logic Layer, and
Data Access Layer.

High-Level Architectural Design:

1. Presentation Layer:
 Components: User Interfaces for Healthcare Professionals and Patients
 Description: The presentation layer is the user-facing part of the system. It provides web-
based interfaces for healthcare professionals and patients to interact with the system.
Healthcare professionals can access patient data, view diagnostic recommendations, and
 perform knowledge searches, while patients can view their health information and receive
recommendations.
2. Application Logic Layer:
 Components: Predictive Modeling, Knowledge Management, User Management, Data
Integration
 Description: The application logic layer contains the core components of the KMS. It
includes:
 Predictive Modeling Component: This component uses machine learning
models to analyze patient data and make diabetes risk assessments.
 Knowledge Management Component: This component extracts, organizes, and
manages medical knowledge from various sources, including literature and
research articles.
 User Management Component: Handles user authentication, access control, and
user account management.
 Data Integration Component: Manages the integration of patient data from
various sources, such as electronic health records (EHRs) and external systems.
3. Data Storage Layer:
 Components: Relational Database (for patient data), Knowledge Base (for medical
knowledge)
 Description: This layer manages the storage of structured patient data, such as medical
histories and test results, in a relational database. Additionally, it maintains a knowledge base
containing extracted and organized medical knowledge and research findings.
4. Security and Compliance Layer:
 Components: Security Services, Compliance Module
 Description: This layer is responsible for ensuring data security, privacy, and compliance
with healthcare regulations. It includes security services for data encryption, access control,
and audit trails, as well as a compliance module to monitor and enforce healthcare data
regulations.
5. Integration Layer:
 Components: External Healthcare Systems, APIs
 Description: The integration layer facilitates communication with external healthcare
systems and data sources. It uses standard healthcare data exchange protocols and APIs to
connect to EHR systems and other relevant external systems.
Discussion:
 Predictive Modeling: The system employs machine learning algorithms to assess patient data
and predict diabetes risk. The predictive modeling component plays a central role in assisting
healthcare professionals in early detection and risk assessment.
 Knowledge Management: The knowledge management component continuously extracts and
updates medical knowledge from literature and research articles. This knowledge assists
healthcare professionals in evidence-based decision-making.
 Data Integration: Integration with EHRs and external healthcare systems ensures that the
KMS has access to comprehensive and up-to-date patient data, supporting accurate diabetes
detection.
 Security and Compliance: Given the sensitive nature of healthcare data, the system includes
robust security measures and compliance mechanisms to protect patient information and ensure
adherence to healthcare data regulations.
 User Interfaces: User interfaces are tailored for healthcare professionals and patients, ensuring
ease of use and accessibility. Healthcare professionals can access patient data and knowledge
resources, while patients can engage in their health management.
  Data Storage: The system uses a relational database for storing structured patient data and a
knowledge base for storing extracted medical knowledge. These storage mechanisms facilitate
efficient data retrieval and management.
 Integration Layer: The system's integration capabilities allow it to interact with existing
healthcare systems and data sources, enhancing its interoperability and data exchange.

Q3. Enumerate the steps taken by you for the detailed design (i.e. low-level design) of the system
pertaining to your chosen project.

Answer-3:

For the detailed design, or low-level design, of a Knowledge Management System (KMS) pertaining
to diabetes detection, several steps need to be taken to specify how the high-level architecture will be
implemented in detail. Here are the steps typically taken in the low-level design process:

1. Refinement of System Components:

 Break down high-level components into smaller, more detailed sub-components. For
example, if you have a "Predictive Modeling Component," break it down into sub-
components for data preprocessing, model training, and inference.
2. Detailed Data Schema Design:
 Define the structure of the relational database for patient data in terms of tables, fields, and
relationships. Specify data types and constraints for each field.
3. Interface Design:
 Design the detailed user interfaces for healthcare professionals and patients. Specify
layouts, navigation, and user interaction elements.
4. Algorithm Selection and Specification:
 Choose specific machine learning algorithms for predictive modeling. Specify the
algorithm parameters, data preprocessing steps, and validation techniques.
5. Knowledge Extraction and Management:
 Specify the natural language processing (NLP) techniques and tools to be used for
knowledge extraction. Detail the process of how medical literature will be processed and
organized in the knowledge base.
6. Security and Access Control Design:
 Define the encryption algorithms, access control mechanisms, and user authentication
methods to be used for data security. Specify how user roles and permissions will be
managed.
7. Data Integration and Interoperability:
 Specify the data exchange protocols and APIs for integrating with external healthcare
systems. Detail the data mapping and transformation processes.
8. Scalability and Performance:
 Plan for scalability by specifying how additional resources and servers will be added as the
system grows. Consider load balancing mechanisms to ensure system performance.
9. Detailed Data Flow Diagrams:
 Create detailed data flow diagrams that illustrate how data and information will flow
through the system. Define the input, processing, and output for each component.
10. API Design:
 If the system offers APIs for integration with external systems or for third-party developers,
specify the API endpoints, data formats, and authentication methods.
11. Testing and Quality Assurance:
 Define the testing approach, including unit testing, integration testing, and user acceptance
testing. Specify test cases, expected outcomes, and testing tools.
12. Error Handling and Recovery:
 Specify how the system will handle errors and exceptions, including logging error
messages, notifying administrators, and implementing recovery mechanisms.
13. Performance Optimization:
 Identify potential performance bottlenecks and specify how they will be optimized, such as
through caching strategies, query optimization, and parallel processing.
14. Documentation:
 Create detailed design documentation that includes architectural diagrams, data models,
algorithms, data dictionaries, and API documentation.

Q4. Illustrate and briefly discuss the detailed design (i.e. low-level design) of the system
pertaining to your chosen project.

Answer-4:

Detailed Design Components:

1. Data Schema Design:
 Define the structure of the relational database for patient data:
 Patient Table: Fields for patient information, including patient ID, name, age,
gender, and contact details.
 Medical History Table: Records patient medical history, including diagnoses,
medications, and treatments.
 Test Results Table: Stores patient test results, such as blood glucose levels, A1C
levels, and lipid profiles.
 Implement referential integrity constraints and data validation rules.
2. User Interfaces Design:
 Design user interfaces for healthcare professionals and patients:
 Healthcare Professional Interface: A dashboard displaying patient profiles,
diagnostic recommendations, and knowledge search.
 Patient Interface: A user-friendly dashboard showing personal health data,
recommendations, and preferences.
3. Predictive Modeling Component:
 Specify the detailed implementation of the predictive modeling component:
 Algorithm Selection: Choose machine learning algorithms (e.g., logistic regression,
decision trees) for diabetes risk assessment.
 Data Preprocessing: Define data preprocessing steps, including data cleaning,
normalization, and feature engineering.
 Model Training: Specify the model training process, including hyperparameter
tuning and cross-validation.
 Inference: Detail how trained models will make diabetes risk predictions for
patients.
4. Knowledge Management Component:
 Specify the knowledge management component for extracting and managing medical
knowledge:
 NLP Techniques: Select NLP tools and libraries for extracting knowledge from
medical literature.
 Knowledge Base Schema: Define the structure of the knowledge base, including
document indexing, tagging, and categorization.
 Update Mechanism: Specify how the system will continuously update the
knowledge base with new research findings.
5. Security and Access Control:
 Detail the security and access control measures:
 Encryption: Specify encryption algorithms (e.g., AES) for protecting patient data at
rest and during transmission.
 Access Control: Define role-based access control (RBAC) mechanisms for user
roles like healthcare professionals, administrators, and patients.
 Authentication: Specify authentication methods, such as username and password,
multi-factor authentication, or biometrics.
6. Data Integration and Interoperability:
 Specify the data integration component:
 Data Sources: List the external healthcare systems and EHRs that the system will
integrate with.
 Data Mapping: Describe how data will be mapped from different sources to the
system's data schema.
 Integration APIs: Specify the APIs and data exchange formats for seamless data
integration.
7. Scalability and Performance:
 Plan for scalability and performance optimization:
 Load Balancing: Specify load balancing mechanisms to distribute traffic efficiently.
 Caching: Implement caching strategies to reduce database load and improve
response times.
 Parallel Processing: Utilize parallel processing for computationally intensive tasks
like predictive modeling.
8. Detailed Data Flow Diagrams:
 Create detailed data flow diagrams illustrating data flow and processing steps for each
component. Define input, processing, and output at a granular level.
9. API Design:
 If the system offers APIs for integration, specify API endpoints, data formats (e.g., JSON,
XML), and authentication methods (e.g., OAuth 2.0).
10. Testing and Quality Assurance:
 Define the testing approach:
 Unit Testing: Specify test cases for individual components.
 Integration Testing: Detail tests for component interactions and data flow.
 User Acceptance Testing: Plan tests involving healthcare professionals and patients
to validate usability.

This detailed design provides a clear blueprint for implementing the Knowledge Extraction for
Detection of Diabetes.
Q5. Enumerate the software development tools chosen by you for the system development
pertaining to your chosen project. State the reasons for choosing each of the above tools.

Answer-5:
1. Programming Language: Python
 Reason: Python is a versatile language with extensive libraries for data science, machine
learning, and web development. It's an excellent choice for developing the predictive
modeling, data analysis, and backend components of the KMS.
2. Web Framework: Flask
 Reason: Django is a high-level Python web framework known for its security features,
scalability, and ease of development. It provides tools for building the user interface and
managing the backend of the KMS.
3. Database Management System: PostgreSQL
 Reason: PostgreSQL is a powerful open-source relational database management system
known for its reliability, scalability, and support for complex data types. Given the
importance of data integrity and security in healthcare, PostgreSQL is a strong choice.
4. Machine Learning and Data Analysis Libraries:
 scikit-learn: scikit-learn is a comprehensive library for machine learning in Python,
providing tools for modeling, classification, regression, and more. It's essential for
developing predictive models for diabetes detection.
 TensorFlow or PyTorch: These deep learning frameworks are crucial for implementing
advanced neural network models, if needed, for more complex tasks in diabetes detection.
 Jupyter Notebooks: Jupyter is an interactive development environment ideal for data
exploration, model development, and documentation. It's valuable for collaborative work
among data scientists and researchers.
5. Version Control: Git and GitHub/GitLab
 Reason: Git is the industry-standard for version control, allowing for collaborative
development and easy tracking of changes. Hosting the project on platforms like GitHub
or GitLab facilitates team collaboration and code sharing.

6. Project Management and Collaboration:

 Jira or Trello: These project management tools can help in tracking tasks, issues, and
project progress.
 Slack or Microsoft Teams: Communication platforms can facilitate team collaboration
and quick information exchange.

Q6. Briefly discuss the functionality of (a) modules developed so far (b) modules to be developed.
You may attach the source code listings for (a) as an annexure to this review-2 document.

Answer-6:

(a) Modules Developed So Far:

1. Data Ingestion and Storage:
 Functionality: This module is responsible for ingesting patient data from various
sources, such as electronic health records (EHRs) and external healthcare systems. It
validates, preprocesses, and stores the data in the relational database. It includes
functions for data cleaning, normalization, and data integrity checks.
 2. User Management and Authentication:
 Functionality: This module handles user authentication and access control. It allows
healthcare professionals, administrators, and patients to log in securely, manage their
profiles, and access the system. Access control mechanisms ensure that users only see
data and features relevant to their roles.
3. Predictive Modeling Component:
 Functionality: The predictive modeling component is designed to assess a patient's
diabetes risk. It uses machine learning models and algorithms to analyze the patient's
medical history and test results. The module provides recommendations and risk scores
for diabetes.
4. Knowledge Management Component:
 Functionality: This component extracts medical knowledge from textual sources, such
as research articles and medical literature. It processes and organizes this knowledge
into a knowledge base. The module supports text mining, keyword extraction, and
indexing of medical information.
5. User Interfaces:
 Functionality: User interfaces have been developed for healthcare professionals and
patients. Healthcare professionals can view patient profiles, access diagnostic
recommendations, and search for medical knowledge. Patients can access their health
data, receive recommendations, and provide preferences.
(b) Modules To Be Developed:
1. External System Integration:
 Functionality: This module will be responsible for integrating with external healthcare
systems, such as EHRs. It will include APIs and data exchange protocols for seamless
data transfer, ensuring that the KMS has access to comprehensive and up-to-date patient
information.
2. Security and Compliance Enhancements:
 Functionality: Enhancements will be made to further strengthen data security and
ensure compliance with healthcare regulations (e.g., HIPAA or GDPR). This includes
encryption, auditing, and compliance monitoring features.
3. Scalability and Performance Optimization:
 Functionality: The system will be optimized for scalability and improved performance
to handle a growing volume of patient data. Load balancing, caching, and parallel
processing mechanisms will be implemented to enhance system efficiency.
4. Interoperability and Data Mapping:
 Functionality: This module will ensure effective interoperability with external
healthcare systems by defining data mapping and transformation processes. It will use
standard healthcare data exchange protocols for seamless integration.
5. Documentation and Reporting:
 Functionality: Develop a module for generating reports and documentation. This will
include auto-generation of documentation for patient profiles, risk assessments, and
knowledge updates.
6. Prototyping and Testing:
 Functionality: Create prototypes or proof-of-concept implementations to validate
design decisions for complex components like predictive modeling. Additionally, this
module will involve extensive testing, including unit testing, integration testing, and
user acceptance testing.
Q7. Briefly discuss the steps taken by you for unit testing pertaining to the system modules
already completed by you. Summarize your test results for the above testing.

Answer-7:
Unit testing is a crucial phase in software development that ensures individual components or modules
work correctly in isolation. Below are the steps typically taken for unit testing pertaining to the system
modules already completed:

1. Test Case Design: For each module, design a set of test cases that cover various scenarios and
edge cases. These test cases should validate the correctness of the module's functions and
methods.
2. Test Environment Setup: Set up a controlled environment for testing. This may involve
creating mock data, configuring the database, and initializing the module under test.
3. Test Execution: Run the designed test cases on the module. Each test case should cover a
specific functionality or feature of the module.
4. Assertion and Validation: For each test case, assert expected outcomes and validate them
against the actual results produced by the module. If the actual result matches the expected
result, the test case passes; otherwise, it fails.
5. Error Handling Testing: Include test cases that intentionally trigger errors or exceptions, such
as invalid input or unexpected behaviors, to ensure that the module handles errors appropriately.
6. Coverage Analysis: Analyze the code coverage achieved by the unit tests to ensure that a
significant portion of the module's code is tested. Tools like code coverage analyzers can be
helpful in this step.
7. Iterative Debugging: If a test case fails, identify the source of the issue and fix it. Continue
running the test cases iteratively until all tests pass.

Summarized Test Results:

The unit testing of the completed system modules has yielded the following results:
1. Data Ingestion and Storage: Unit tests for data ingestion and storage have passed successfully.
The module correctly validates, preprocesses, and stores patient data in the database. Error
handling for data integrity issues is effective.
2. User Management and Authentication: Unit tests for user management and authentication
have passed. The module correctly handles user authentication and access control, ensuring that
users can securely log in and access their respective profiles.
3. Predictive Modeling Component: Unit tests for the predictive modeling component have
passed for typical cases, with the module accurately assessing diabetes risk and providing
recommendations. Error handling for unexpected inputs is effective.
4. Knowledge Management Component: Unit tests for the knowledge management component
have passed, confirming the accurate extraction and organization of medical knowledge from
textual sources. Knowledge is correctly indexed and made available for search.
5. User Interfaces: Unit tests for user interfaces have validated that healthcare professionals and
patients can interact with the system as expected. The interfaces are user-friendly, responsive,
and provide the intended functionality.
Q8. Distinguish between Black-box Testing and White-box testing. Is it necessary to undertake
both of the above testing for your chosen system? Why or why not?

Answer-8:

Black-box testing White-box testing

Black-box testing is a functional testing method White-box testing, also known as structural
that evaluates the system's functionality without testing, examines the internal structure, logic,
examining its internal code or logic. and code of the software system.
Testers do not need knowledge of the system's Testers need access to the source code and must
internal structure, algorithms, or codebase. possess knowledge of the system's internal
workings, algorithms, and data structures.
It can be applied at all levels of testing, including White-box testing is typically applied at lower
unit, integration, system, and acceptance testing. levels of testing, such as unit testing and code
review.
Test cases are designed based on the system's Test cases are designed to evaluate the internal
specifications, requirements, and expected paths, branches, and conditions within the code.
behavior. Testers interact with the system as end- Testers assess how the code responds to different
users, providing inputs and assessing outputs. inputs and conditions.
Black-box testing verifies if the system meets its White-box testing aims to verify the correctness
functional requirements, including its ability to of the code, identify logical errors, and ensure
handle various inputs, produce correct outputs, that all code paths are executed.
and satisfy user expectations.
Examples: Functional testing, usability testing, Examples: Unit testing, code coverage analysis,
acceptance testing, and system testing are and static code analysis are common types of
common types of black-box testing. white-box testing.

Necessity of Both Testing Methods for the Chosen System:

In the context of the Payroll Management System (PMS), it is essential to undertake both black-box
and white-box testing, at different stages of the development process:

1. Black-box Testing (Functional Testing):

 Importance: Black-box testing helps ensure that the PMS functions correctly from an end-user
perspective. It validates that the system meets the specified functional requirements, such as
accurate payroll calculations, tax compliance, and user interface usability.
 Necessity: Black-box testing is crucial to validate the system's overall functionality and to
ensure it meets the needs of HR personnel, administrators, and employees.
2. White-box Testing (Unit Testing and Code Review):

 Importance: White-box testing is vital at the lower levels of development, such as unit testing
and code review, to validate the correctness of the underlying code. It helps identify logical
errors, boundary conditions, and potential vulnerabilities.
 Necessity: White-box testing ensures that the internal logic and algorithms within the PMS
codebase are sound, secure, and efficient. It helps catch issues early in the development process.
Q9. Why integration testing is necessary? Enumerate various approaches for integration testing.
Which approach would you prefer for your chosen system and why?

Answer-9:

Integration testing:

Integration testing is necessary to ensure that the individual modules of a software system work
together as expected. It is a critical step in the software development lifecycle that helps to prevent
defects from being carried over to the next stage of testing.

Integration testing is necessary because:

 It helps to identify and fix defects in the interfaces between modules.

 It ensures that the modules work together as expected to meet the overall system requirements.
 It helps to improve the performance and reliability of the system.
 It reduces the risk of bugs being found by customers.

Approaches for integration testing:

There are four main approaches to integration testing:

1. Top-down approach: This approach starts with the testing of the highest-level modules in the
system and then works down to the lower-level modules.
2. Bottom-up approach: This approach starts with the testing of the lowest-level modules in the
system and then works up to the higher-level modules.
3. Big bang approach: This approach integrates all of the modules in the system at once and then
tests the entire system.
4. Mixed approach: This approach combines elements of the top-down, bottom-up, and big bang
approaches.

I would prefer a mixed approach for a knowledge extraction for detection of diabetes.

The mixed approach is a flexible approach that can be tailored to the specific needs of the project. It is
also a more efficient approach than the big bang approach, which can be difficult and time-consuming
to implement.

Q10. Suggest how we can derive test cases from use cases. Give a few examples of test cases that
you can derive from the use cases already developed by you for your chosen system.

Answer-10:

Deriving test cases from use cases is a fundamental step in software testing. Test cases are designed to
validate that the system functions as intended based on the specified use cases. Here's how you can
derive test cases from the use cases you provided for the Payroll Management System:
Use Case: User Registration
Test Case 1: Successful Registration
 Test Objective: To verify that a user can successfully register in the system.
 Test Inputs: Valid username, password, email, and other required information.
 Expected Result: User account is created, and the user can log in.
Test Case 2: Duplicate Username
 Test Objective: To confirm that the system handles duplicate usernames correctly.
 Test Inputs: An existing username during registration.
 Expected Result: System displays an error message indicating that the username is already in
use.
Use Case: Diabetes Risk Assessment
Test Case 3: Risk Assessment Calculation
 Test Objective: To check if the system accurately calculates a patient's diabetes risk.
 Test Inputs: Sample patient data, including medical history and test results.
 Expected Result: The system provides a risk score based on the data and guidelines.
Test Case 4: Invalid Data Handling
 Test Objective: To ensure the system handles invalid data gracefully.
 Test Inputs: Data with missing or erroneous information.
 Expected Result: The system provides error messages or prompts for valid data.
Use Case: User Login
Test Case 5: Successful User Login
 Test Objective: To verify that a registered user can successfully log in.
 Test Inputs: Valid username and password.
 Expected Result: The system grants access to the user's dashboard.
Test Case 6: Incorrect Password
 Test Objective: To ensure that the system handles incorrect passwords correctly.
 Test Inputs: Valid username and an incorrect password.
 Expected Result: The system displays an error message and does not grant access.
Use Case: Search for Medical Knowledge
Test Case 7: Successful Knowledge Search
 Test Objective: To validate that users can find medical knowledge through the search function.
 Test Inputs: A relevant keyword or query.
 Expected Result: The system displays search results with relevant knowledge articles.
Test Case 8: No Search Results
 Test Objective: To check how the system handles queries with no matching knowledge.
 Test Inputs: A query with no matching keywords.
 Expected Result: The system displays a message indicating no search results.
Use Case: Data Integration from EHR
Test Case 9: Successful EHR Data Integration
 Test Objective: To verify that the system can integrate patient data from an EHR system.
 Test Inputs: Simulated patient data from an EHR.
 Expected Result: The system successfully imports and stores the patient's data.
Test Case 10: Integration Failure
 Test Objective: To test the system's response to a failure in EHR data integration.
 Test Inputs: Simulated EHR data with errors or incomplete information.
 Expected Result: The system logs integration errors and provides appropriate error messages.
Use Case: Patient Profile Viewing
Test Case 11: Viewing Patient Profile
 Test Objective: To confirm that healthcare professionals can view patient profiles.
  Test Inputs: Selection of a patient from the list.
 Expected Result: The system displays the patient's profile with medical history and test results.
Test Case 12: Unauthorized Access
 Test Objective: To ensure that unauthorized users cannot access patient profiles.
 Test Inputs: A user without healthcare professional privileges attempts to access a patient
profile.
 Expected Result: The system denies access and displays an access denied message.
Use Case: Knowledge Update
Test Case 13: Successful Knowledge Update
 Test Objective: To verify that the system can successfully update its knowledge base with new
medical knowledge.
 Test Inputs: A new research article or medical publication.
 Expected Result: The system updates the knowledge base with the new information.
Test Case 14: Knowledge Update Failure
 Test Objective: To test the system's response to a failed knowledge update.
 Test Inputs: An attempt to update the knowledge base with incorrect or unsupported data.
 Expected Result: The system logs the failure and provides an error message.