DAWOOD UNIVERSITY OF ENGINEERING AND TECHNOLOGY

M.A JINNAH ROAD KARACHI-74800 (PAKISTAN)

FACULTY OF INFORMATION SCIENCES & HUMANITES

DEPARTMENT OF ARTIFICIAL INTELLIGENCE

Title: Report (Database Systems Project)

Submitted by:
Syed Muhammad Sarim (23-AI-57)
Ali Murtaza (23-AI-81)
Muhammad Raza (23-AI-49)

Submitted to:
Miss. Noor ul Huda
Lecturer
Department of Artificial Intelligence

Chapter 1
Case Question:
1. The goal of Mountain View Community Hospital is to provide high-quality, cost-effective health-
care services for the surrounding community in a compassionate, caring, and personalized manner.
Give some examples of how the use of databases in the hospital might improve health-care quality or
contain costs. How else could a well-managed database help the hospital achieve its mission?
Ans) Improving Healthcare Quality and Cost Management through Databases: Databases play a
crucial role in improving healthcare quality and cost management at Mountain View Community Hospital
(MVCH). Some key examples include:
 Patient Record Management: A centralized database ensures quick access to complete and updated
patient records, reducing errors in treatment and diagnosis.
 Resource Optimization: Real-time monitoring of resources such as beds, medical equipment, and
staff availability reduces unnecessary costs and enhances operational efficiency.
 Inventory Control: Databases help in tracking medical supplies, preventing overstocking or
understocking, and ensuring cost-effective purchasing.
 Data Analytics: Patterns in patient admissions, treatment outcomes, and resource utilization can be
analyzed to make informed decisions.
 Billing and Insurance: Automated billing systems integrated with patient records reduce billing
errors and streamline insurance claim processes.
A well-managed database can also enhance communication across departments, reduce duplicate testing,
and support personalized patient care plans.

2. How can database technology be used to help Mountain View Community Hospital comply with the
security standards of the Health Insurance Portability and Accountability Act of 1996 (HIPAA)? HIPAA
requires health-care providers to maintain reasonable and appropriate administrative, technical, and physical
safeguards to ensure that the integrity, confidentiality, and availability of electronic health information they
collect, maintain, use, or transmit is protected. (For more details on HIPAA, visit www.hhs.gov/ocr/privacy.)

Ans) Database Technology and HIPAA Compliance: To comply with HIPAA security standards, MVCH
can utilize database technology in the following ways:
 Access Control: Implement role-based access control (RBAC) to ensure only authorized personnel
can view or modify sensitive data.
 Data Encryption: Encrypt patient records both at rest and in transit to prevent unauthorized access.
 Audit Trails: Maintain comprehensive logs of database access and modifications for accountability.
 Backup and Disaster Recovery: Regular backups and disaster recovery plans ensure data
availability during unexpected events.
 Authentication Protocols: Use multi-factor authentication (MFA) for secure database access.
These measures help MVCH protect patient privacy and ensure data integrity and availability.

3. What are some of the costs and risks of using databases that the hospital must manage carefully?
Ans) Costs and Risks of Database Usage: While databases offer significant benefits, they also come with
costs and risks:
 Implementation Costs: High initial costs for database setup, hardware, and software.
 Maintenance Costs: Regular updates, security patches, and hardware maintenance require
continuous investment.
 Data Breaches: Security vulnerabilities can lead to unauthorized access to sensitive data.
  Downtime Risks: Database failures or server downtimes can disrupt hospital operations.
 Training Requirements: Staff must be adequately trained to handle database systems.
Proper planning and resource allocation are essential to mitigate these risks.

4. How critical are data quality requirements in the hospital environment? For which applications might
quality requirements be more restrictive?
Ans) Importance of Data Quality in Hospitals: Data quality is critical in healthcare, as inaccurate or
incomplete data can lead to life-threatening consequences. Applications requiring strict data quality
include:
 Patient Diagnosis and Treatment Records: Accurate records are essential for proper diagnosis
and treatment.
 Medication Management Systems: Errors in medication dosages can be fatal.
 Billing and Insurance Claims: Incorrect data can result in claim rejections or financial losses.
 Emergency Services: Real-time and accurate data is vital in critical care situations.
Ensuring data accuracy, consistency, and completeness is non-negotiable in these areas.

Q5) At present, Mountain View Community Hospital is using relational database technology. Although this
technology is ppropriate for structured data, such as patient or accounting data, it is less well-suited to
unstructured data, such as graphical data and images. Can you think of some types of data maintained by a
hospital that fit this latter category? What types of database technology rather than relational might be better
suited to these data types?
Ans) Handling Unstructured Data with Appropriate Database Technology: Hospitals often deal with
unstructured data types, including:
 Medical Images: X-rays, MRIs, CT scans.
 Patient Notes: Doctors' handwritten or digital notes.
 Audio and Video Data: Recorded consultations or surgical procedures.
While relational databases are suitable for structured data, unstructured data can be better managed
using:
 NoSQL Databases: MongoDB or Cassandra for flexible schema design.
 Object-Oriented Databases: Ideal for multimedia data storage.
 Data Lakes: For handling vast amounts of unstructured healthcare data.
These technologies offer scalability, flexibility, and better performance for unstructured data.

Q6) How could the hospital use Web-based applications? What are some of the benefits and risks associated
with Web based applications for the hospital?
Ans) Web-Based Applications in MVCH: Web-based applications can streamline hospital operations
and improve patient experience through:
 Patient Portals: Allow patients to access test results, book appointments, and communicate
with doctors.
 Telemedicine Services: Facilitate remote consultations and follow-ups.
 Inventory Management Systems: Real-time inventory tracking and supplier communication.
 Benefits:
 Improved accessibility and convenience.
 Enhanced patient engagement.
 Real-time data synchronization.
 Risks:
  Cybersecurity threats.
 Downtime and technical issues.
 Dependence on internet connectivity.
 Proper security protocols and regular updates can mitigate these risks.

Q7) The case description lists 10 business rules. The study team used these rules to develop MVCH Figure
1-3. Are there any other business rules implied by or depicted in that figure? What are they?
Ans) Additional Business Rules from the ER Diagram: The case lists 10 business rules, but additional
implied rules include:
 A physician can work in multiple wards.
 A staff member can be assigned to one or more patients.
 A vendor can supply multiple supply items.
 A patient can have multiple orders for tests or medications.

Case Exercise:
Q1) The relational databases at Mountain View Community Hospital contain a number of tables. Two of
these tables, with some sample data, are shown in MVCH Figure 1-4. The PATIENT table contains data
concerning current or recent patients at the hospital, whereas the PATIENT CHARGES table contains data
describing charges that have been incurred by those patients. Interestingly, the PATIENT CHARGES table is
not captured in the preliminary enterprise data model shown in Figure 1-3.
a. Using the notation introduced in this chapter, draw a diagram showing the relationship between the
entities PATIENT and PATIENT CHARGES.
b. Develop a metadata chart for the data attributes in the PATIENT and PATIENT CHARGES tables using
(at minimum) the columns shown in Table 1-1. You may include other metadata characteristics that you
think are appropriate for the management of data at Mountain View Community Hospital.

Ans) Relationship Between PATIENT and PATIENT CHARGES:

a. Entity Relationship Diagram (ERD):
 PATIENT (Primary Key: Patient Number)
o 1:M relationship with PATIENT CHARGES
 PATIENT CHARGES (Foreign Key: Patient Number)
o Each charge entry is linked to one patient.
b. Metadata Chart:
Data Default
Table Name Attribute Name Description Required Constraints
Type Value
Unique patient
PATIENT Patient Number Integer Yes None Primary Key
identifier
Patient Last Last name of the
Varchar Yes None None
Name patient
Patient First First name of the
Varchar Yes None None
Name patient
Patient Address Varchar Residential address Yes None None
PATIENT Description of the
Item Description Varchar Yes None None
CHARGES charge
Item Code Integer Unique item code Yes None None
Patient Number Integer Linked patient Yes None Foreign Key
 identifier
Amount Decimal Charge amount Yes None None

Q2) One of the important outputs from the “bill patient” business function is the Patient Bill. Following is a
highly simplified version of this bill (MVCH Figure 1-5). a. Using the data from MVCH Figure 1-4, add
missing data that would typically appear on a patient bill. b. Using your result from part a), verify that the
enterprise data model in MVCH Figure 1-3 contains the data necessary to generate a patient bill. Explain
what you have to do to perform this verification. What did you discover from your analysis?
Ans) Patient Bill Analysis:
 a. Sample Patient Bill:
 Patient Name: Selena Dimas
 Patient Address: 617 Valley Vista
 Services Rendered:
o Room Semi-Priv: $1600
o EEG Test: $300
 Total Charges: $1900
 b. Verification with Enterprise Data Model:
 Both PATIENT and PATIENT CHARGES tables contain sufficient data for generating a patient bill.
 Relationships between entities align with the requirements.
 Additional validation can be performed by cross-referencing charge details with the PATIENT table.

Q3) Using the notation introduced in this chapter, draw a single diagram that represents the following
relationships in the hospital environment. • A HOSPITAL has on its staff one or more PHYSICIANs. A
PHYSICIAN is on the staff of only one HOSPITAL. • A PHYSICIAN may admit one or more PATIENTs. A
PATIENT is admitted by only one PHYSICIAN. • A HOSPITAL has one or more WARDs. Each WARD is
located in exactly one HOSPITAL. • A WARD has any number of EMPLOYEEs. An EMPLOYEE may
work in one or more WARDs.
Ans) Hospital Environment ERD:
 HOSPITAL (1) ↔ (M) PHYSICIAN
 PHYSICIAN (1) ↔ (M) PATIENT
 HOSPITAL (1) ↔ (M) WARD
 WARD (1) ↔ (M) EMPLOYEE
 EMPLOYEE (M) ↔ (M) WARD
 FACILITY (1) ↔ (M) WARD
 WARD (1) ↔ (M) STAFF
 PHYSICIAN (1) ↔ (M) PATIENT
 PATIENT (1) ↔ (M) MEDICAL/SURGICAL ITEM
 PATIENT (1) ↔ (M) SUPPLY ITEM
 SUPPLY ITEM (1) ↔ (M) VENDOR
 ORDER (1) ↔ (M) TEST/DRUG

04) Using a DBMS suggested by your instructor, such as Microsoft Access or SQL Server, you may begin to
prototype a database for Mountain View Community Hospital. Here are some suggestions to guide you:
a. Develop a metadata chart for an EMPLOYEE table similar to Table 1-1.
b. What types of relationships (1:1, 1:M, or M:N) are likely to exist between your PATIENT table and other
tables in the database? How did you determine that?
c. MVCH hospital administrators regularly need information about their patient population. Based on the
distinction between data and information discussed in this chapter, explain why a printout of a PATIENT
table will not satisfy these information needs.
d. Create a report that organizes the data from your PATIENT table to provide hospital administrators with
useful information about the patient population at MVCH.
Ans) Database Prototyping:
 a. EMPLOYEE Table Metadata Chart:
Attribute Name Data Type Description Required Constraints
Employee ID Integer Unique identifier Yes Primary Key
Employee Name Varchar Full name of employee Yes None
Ward Assigned Integer Ward ID No Foreign Key
 b. Relationships:
 PATIENT ↔ PHYSICIAN (1:M)
 PATIENT ↔ PATIENT CHARGES (1:M)
 PHYSICIAN ↔ ORDER (1:M)
 c. Data vs Information:
 A simple table printout is raw data.
 Information requires data to be aggregated, analyzed, and presented meaningfully.
 d. Patient Data Report Example:
Patient Number Patient Name Total Charges
8379 Selena Dimas $1600
4238 Mark Dolan $750
3047 Annette Larreau $800

05) Earlier in this chapter, we showed an SQL query that displays information about computer desks at Pine
Valley Furniture Company: SELECT * FROM Product WHERE ProductDescription=“Computer Desk”;
Following this example, create an SQL query for your PATIENT table that displays information about the
outpatients.
Ans) SELECT *
FROM PATIENT
WHERE PatientNumber IN (
SELECT PatientNumber
FROM PATIENT_CHARGES
WHERE ItemDescription = 'Outpatient Service'
);
06) The manager of the risk management area, Ms. Jamieson, is anxious to receive computerized support for
her activities. The hospital is increasingly facing malpractice claims and litigation, and she does not believe
she can wait for improved information services until the information systems and database plans are set.
Specifically, Ms. Jamieson wants a system that will track claims, legal suits, lawyers, judges, medical staff,
disbursements against claims, and judgments. How would you proceed to deal with this request for
improved information services? What methodology would you apply to design or acquire the systems and
databases she needs? Why?
Ans) Risk Management System Proposal:
 Use a structured approach such as System Development Life Cycle (SDLC).
 Stages:
 1. Requirement Gathering
2. System Design
3. Database Design
4. Development and Testing
5. Implementation
6. Maintenance

07) . Consider again the request of the manager of risk management from Case Exercise 6. On what tier or
tiers would you recommend the system and database she needs be developed? Why?
Ans) System Tier Recommendation:
 Three-Tier Architecture:
1. Presentation Tier: User interfaces for entering and accessing claims.
2. Application Tier: Business logic for claim validation and processing.
3. Database Tier: Secure storage and retrieval of claims data.
This architecture ensures scalability, security, and easier maintenance of the system.

Project Assignment:
P1. The study team’s activities described in this case study are still in the very early stages of information
system and database development. Outline the next steps that should be followed within the Information
Systems unit to align current systems and databases to the future information systems needs of the hospital.
Ans) Next Steps for Information System and Database Development
The following steps should be followed within the Information Systems (IS) Unit to align the current
systems and databases with the future information systems needs of Mountain View Community Hospital
(MVCH):
1. Requirement Analysis and Feasibility Study:
o Conduct detailed interviews and workshops with stakeholders (doctors, nurses,
administrators, and staff) to gather specific requirements.
o Evaluate the feasibility of proposed enhancements in terms of cost, time, and resources.
2. System Design:
o Develop Logical Design to define data flow diagrams (DFDs) and ER diagrams.
o Create Physical Design focusing on database schema, indexing, and relationships between
entities.
3. Data Integration Plan:
o Identify redundant data across systems and develop strategies for data integration.
o Plan a centralized data repository to reduce data duplication.
4. Technology and Platform Selection:
o Choose the appropriate DBMS platform (e.g., Microsoft SQL Server, Oracle).
o Evaluate technologies for handling unstructured data such as medical images and test
results.
5. Implementation Plan:
o Develop and test system modules incrementally.
o Implement the system in phases (e.g., billing, records, diagnostics).
6. Data Migration:
o Safely transfer existing data into the new database.
o Verify data integrity post-migration.
7. Security and Compliance Checks:
o Ensure HIPAA compliance.
 o Implement encryption, access controls, and regular security audits.
8. Training and Documentation:
o Train staff and stakeholders in using the new system.
o Provide user manuals and technical documentation.
9. System Testing and Quality Assurance:
o Perform unit testing, integration testing, and user acceptance testing (UAT).
10. Monitoring and Maintenance:
 Continuously monitor system performance and security.
 Plan for regular updates and backups.

P2. The patient bill is an example of a view that would be of interest in a hospital environment. Identify and
list other user views that could occur in a hospital environment.
Ans) User Views in a Hospital Environment
Different departments and roles within a hospital require unique data views to perform their functions
efficiently. Below are examples of user views:
1. Physician View:
o Patient medical history
o Lab test results
o Diagnosis and treatment plans
2. Nursing Staff View:
o Patient medication schedules
o Vital signs records
o Care plan details
3. Billing and Accounts View:
o Patient billing details
o Payment status
o Insurance claims
4. Administrative View:
o Staff attendance and scheduling
o Resource allocation reports
o Departmental performance metrics
5. Pharmacy View:
o Drug inventory
o Prescription details
o Restocking alerts
6. Radiology and Diagnostic View:
o Imaging results (X-rays, MRIs)
o Diagnostic test results
7. Patient Portal View:
o Personal health records
o Appointment schedules
o Billing and payment options
8. IT Department View:
o System performance metrics
o Security logs
o Backup and recovery status
P3. Carefully read through the case description, exercises, and questions again and: a. Modify the enterprise
data model shown in MVCH Figure 1-3 to include any additional entities and relationships that you identify.
b. Modify the list of business rules from the case description to include the additional entities and
relationships you identified. c. Draw a context diagram of MVCH’s improved information system similar to
the one for a burger restaurant shown in MVCH Figure 1-6. A context diagram provides the highest-level
view of a system and shows the system boundaries, external entities that interact with the system, and major
information flows between the entities and the system.
Ans) Improvements to the Enterprise Data Model, Business Rules, and Context Diagram
a. Enhanced Enterprise Data Model:
New Entities and Relationships Identified:
1. EMPLOYEE – Tracks hospital staff details.
2. WARD – Tracks patient ward allocation.
3. SUPPLY ITEM – Tracks hospital supplies.
4. VENDOR – Tracks suppliers of medical supplies.
5. DIAGNOSTIC REPORT – Stores results from medical tests.
6. APPOINTMENT – Manages patient visits and consultations.
New Relationships:
 PATIENT ↔ WARD (M:1)
 PATIENT ↔ DIAGNOSTIC REPORT (1:M)
 WARD ↔ EMPLOYEE (M:N)
 SUPPLY ITEM ↔ VENDOR (M:1)
 PHYSICIAN ↔ APPOINTMENT (1:M)

b. Additional Business Rules:

1. Each Patient must be assigned to one Ward during admission.
2. Each Diagnostic Report must be linked to one Patient.
3. Supplies must be procured from an approved Vendor.
4. Each Physician can have multiple Appointments with Patients.
5. Employees may work in multiple Wards.

c. Context Diagram for MVCH Information System:

Below is a textual representation of the context diagram:
 External Entities:
1. Patient
2. Physician
3. Nurse
4. Pharmacy
5. Billing Department
6. Insurance Provider
7. Vendor
8. Hospital Administrator
 System Boundaries:
o MVCH Information System
 Major Information Flows:
1. Patient ↔ Appointment Scheduling
2. Physician ↔ Patient Diagnosis and Reports
3. Nurse ↔ Patient Care Data
4. Pharmacy ↔ Prescription Orders
 5. Billing ↔ Patient Charges and Insurance Claims
6. Vendor ↔ Supply Orders
7. Administrator ↔ Performance and Compliance Reports

Chapter 2
Case Questions:
1. Why would Mountain View Community Hospital want to use E-R modeling to understand its data
requirements? What other ways might the hospital want to model its information requirements?
Answer:
Mountain View Community Hospital would want to use E-R modeling because:
 Visual Clarity: E-R modeling provides a visual representation of the hospital's data, making it easier
to understand how entities (like patients, physicians, and care centers) are related.
 Accurate Data Representation: It helps identify the key attributes of each entity and ensures that the
relationships between them are clearly defined.
 Avoiding Redundancy: By designing the database correctly using E-R diagrams, unnecessary
duplication of data can be avoided, which reduces storage issues and improves data integrity.
 Ease of Communication: It acts as a bridge between the database developers and stakeholders (such
as hospital administrators), ensuring that everyone understands the structure and purpose of the
database.
Other ways to model the hospital’s information requirements include:
 Relational Schema Modeling: Focuses on representing the database in tables with relationships
between them.
 Hierarchical Data Modeling: Represents data in a tree-like structure, which could be useful for
organizing hospital departments and sub-departments.
 UML (Unified Modeling Language): This can be used for system design, especially when modeling
workflows and processes alongside the data structure.

2. Is Mountain View Community Hospital itself an entity type in the data model? Why or why not?
Answer:
No, Mountain View Community Hospital itself is not an entity type because it is not a discrete data object
that needs to be stored or managed in the database.
 The hospital serves as the context or environment where various other entities (like patients,
physicians, beds, etc.) exist and interact.
 Entities in the database represent specific data objects that require attributes and relationships. The
hospital, as a whole, does not meet these criteria.
Instead, the database would focus on entities such as care centers, which are subunits of the hospital, and
patients, who interact with these care centers.
3. Do there appear to be any of the following in the description of the hospital's data requirements?
a. Weak Entities
Yes, weak entities exist in the form of beds.
 Beds depend on care centers for their identification. For example, a bed number like "Room 101,
Bed 2" cannot exist without referencing the specific care center it belongs to.
b. Multivalued Attributes
Yes, there are multivalued attributes, such as employees working in multiple care centers.
 An employee may have assignments in more than one care center, requiring multiple associations for
the same attribute (care center ID).
c. Multiple Relationships
Yes, multiple relationships are evident, such as:
 Physicians diagnosing patients.
 Physicians performing treatments on patients.
 Patients being assigned beds.
 Employees working in various care centers.

4. What is the significance of the business rule stating that some patients are assigned to beds while
outpatients are not?
Answer:
This business rule highlights the difference between inpatients and outpatients:
 Inpatients are assigned beds because they stay at the hospital for longer durations and require a
specific location to receive care. The database must track this assignment to manage bed availability
and patient records.
 Outpatients receive treatment without being admitted to a care center. Since they do not require beds,
the system needs to account for this by distinguishing between these two types of patients in the
patient entity.
This distinction ensures that bed assignment data is not unnecessarily linked to outpatients,
simplifying database queries and reducing the risk of errors.

5. Should Items be split into two entities: reusable and non-reusable? Why or why not?
Answer:
Yes, splitting Items into reusable and non-reusable entities is a good idea because:
 Different Characteristics: Reusable items (e.g., surgical tools) and non-reusable items (e.g., syringes)
have different management requirements. Reusable items need tracking for inventory and cleaning
cycles, while non-reusable items are one-time use.
 Billing Clarity: Billing processes differ for reusable and non-reusable items. For example, reusable
items may incur rental fees, while non-reusable items are directly charged.
  Inventory Management: Separating these items makes it easier to track and manage stock levels
accurately.

6. What quality checks would you perform to ensure the E-R model meets user needs?
Answer:
The following quality checks can be performed:
 Normalization: Ensure that the database is normalized to reduce redundancy and improve data
integrity.
 Relationship Validation: Confirm that all relationships between entities accurately reflect real-world
scenarios, such as ensuring that each patient is linked to their treatments.
 User Query Simulation: Run sample queries to verify that the database can handle typical user
requests, such as finding a patient's treatment history or tracking available beds.
 Test Scenarios: Create test cases for common operations, like admitting a patient, assigning a bed,
and generating bills, to ensure the model supports them seamlessly.

Case Exercises:
1. Additional Questions to Clarify Data Requirements
Answer:
 What specific information is recorded for each patient diagnosis?
 Are multiple physicians allowed to perform treatments on the same patient at the same time?
 How are outpatients' treatments recorded if they are not assigned to a bed?
 Are there any items (e.g., in-room TVs) that are billed differently based on their use?

2. E-R Diagram
An E-R diagram will include the following entities and relationships:
Entities:
1. Patient (Patient_ID, Name, Address, Patient_Type)
2. Physician (Physician_ID, Name, Specialty)
3. Care Center (Care_Center_ID, Name)
4. Bed (Bed_ID, Room_Number)
5. Item (Item_ID, Name, Cost, Reusable)
6. Treatment (Treatment_ID, Description)
Relationships:
 Patients are assigned Beds (if inpatients).
  Physicians diagnose and perform Treatments on Patients.
 Items are linked to Patients or Rooms.
Assumptions:
 Each patient has a unique Patient_ID.
 Each room and bed combination is unique.

3. Can Items include in-room TVs as billable items?

Answer:
Yes, the Item entity can include in-room TVs. To handle this, attributes such as Item_Type and Billable can
be added to distinguish between regular items and billable ones.

4. Composite Attribute for Bed Number

If Bed Number is a composite attribute, it will consist of:
 Care Center ID
 Room Number
 Bed Number (within room)
The Bed entity would be restructured to include these attributes instead of a single Bed_ID.

5. Adding Room-Item Relationship

To include items billed to a room, add a relationship:
 Room contains many Items.
 Items can be billed to Patients assigned to that Room.

6. Handling Multiple Physicians for a Single Treatment

To allow multiple physicians to perform a treatment on a patient simultaneously:
 Add a new associative entity, Treatment_Record, with Physician_ID, Patient_ID, Treatment_ID, and
Timestamp.

7. Handling Repeated Treatments by the Same Physician

To allow the same treatment to be performed more than once by the same physician for the same patient:
 Include a Session_ID or Timestamp attribute in Treatment_Record to differentiate multiple instances.
Project Assignment:
P1. E-R Diagram Development
P2. Business Rules:
1. Each patient has a unique Patient_ID.
2. Patients can either be Inpatients (assigned to a Bed) or Outpatients (not assigned to a Bed).
3. Each Care Center has multiple Rooms, and each room has multiple Beds.
4. Each Bed is uniquely identified by Care_Center_ID, Room_Number, and Bed_ID.
 5. Physicians can perform multiple treatments, and patients can undergo multiple treatments.
6. A treatment can involve multiple physicians performing it on the same patient simultaneously.
7. Items (e.g., reusable or non-reusable) may be billed to patients or rooms.
8. All treatments have a unique Treatment_ID and are associated with a specific cost.
9. Treatment records maintain a history of all treatments, including the patient, physician, and
timestamp.

P3. Questions to Clarify Business Rules and Data Requirements:

1. Are there any restrictions on how many beds a single room can have in a Care Center?
2. Can patients be treated in multiple care centers at the same time, or are they restricted to one care
center?
3. Are reusable items charged differently (e.g., maintenance fees or rental)?
4. Should there be a mechanism to identify if an item is assigned to a specific room or directly to a
patient?
5. Can physicians perform treatments for outpatients, or are they strictly limited to inpatients?
6. What information is needed to differentiate Inpatients from Outpatients in the database?
7. Are treatments tracked by individual sessions or overall courses?
8. How should overlapping treatments involving multiple physicians for the same patient be handled in
the model?
9. Are there group treatments where multiple patients undergo the same treatment together?
10. What specific details about each treatment (e.g., equipment used, duration) should be stored?

Chapter 3
Case Questions:
1. Is the ability to model supertype/subtype relationships important in a hospital environment
such as MVCH? Why or why not?
Answer: Yes, the ability to model supertype/subtype relationships is critically important in a hospital
environment such as MVCH. This is because the hospital deals with several groups of people (e.g.,
employees, physicians, patients, and volunteers) that share common attributes like name, address, phone
number, and email, while also having distinct attributes specific to their roles. For instance, physicians have
pager numbers and DEA numbers, while patients have emergency contact and insurance information.
Supertype/subtype modeling allows for the efficient organization of shared attributes in a supertype (e.g.,
"Person") and the differentiation of specific attributes in subtypes (e.g., "Employee," "Volunteer"). This
approach ensures flexibility, minimizes redundancy, and provides clarity in managing complex relationships
and data integrity in the hospital’s system.
2. Are there any weak entities, multivalued attributes, or multiple relationships in the description
of the data requirements in this case segment? If so, what are they?
Answer: Yes, there are several examples of weak entities, multivalued attributes, and multiple
relationships in the data requirements:
 Weak Entities:
o A "Bed" can be considered a weak entity since its identification (Bed ID) depends on the
Room# and Bed# within a care center.
o "Emergency Contact" for patients is another example, as it depends on the patient entity for
context.
 Multivalued Attributes:
o "Skills and Interests" of volunteers represent multivalued attributes because a volunteer can
have multiple skills and interests recorded.
o Technicians’ specific competencies or certifications are also multivalued attributes since a
technician may be skilled in multiple areas.
 Multiple Relationships:
o There are multiple relationships between entities such as:
 "Physician" and "Patient": A physician can be responsible for multiple patients, and a
patient must have exactly one physician.
 "Volunteer" and "Supervisor": A volunteer is supervised by either an employee or a
physician, establishing two separate relationships.
 "Nurses" and "Care Center": Nurses may be assigned to one or more care centers over
time.
3. Can you think of any other business rules (other than the one explicitly described in the case)
that are likely to be used in a hospital environment? Can these be represented on an EER
diagram for MVCH?
Answer: Yes, there are additional business rules that can be applied in a hospital environment:
 Shift Schedules: Each employee, nurse, or technician may have assigned shifts, including start and
end times, which can be represented as an entity related to employees and care centers.
 Room Availability: The status of a room (occupied, unoccupied, under maintenance) could be
tracked and represented as an attribute of the room entity.
 Equipment Usage: Specialized equipment in care centers may have usage logs that track which
technicians operate them and when.
 Training Records: Employees and volunteers may need to undergo regular training sessions, which
can be linked to their roles and responsibilities.
 These business rules can be represented on an EER diagram by introducing entities such as "Shift,"
"Room Status," "Equipment," and "Training" with relationships connecting them to relevant entities
(e.g., "Employee," "Technician," "Care Center").
4. Are there any universal data models that can be reused as a starting point for modeling
MVCH’s data requirements? Would you recommend using such as model for the MVCH
project? Why or why not?
Answer: Yes, universal data models for healthcare systems are available and can serve as a starting point
for modeling MVCH’s data requirements. These models typically include predefined entities and
relationships for common healthcare processes, such as patient management, employee records, and care
center operations.
Case Exercise:
1. Draw an EER diagram to represent the requirements described in this case segment carefully
following the notation from this chapter.
Answer: We’ll create an Enhanced Entity-Relationship Diagram (EER) based on the requirements:
 Entities:
o Person (Generalized entity for employees, volunteers, patients, physicians).

o Employee (specialized into Nurse, Technician, and Staff).

o Volunteer

o Patient (specialized into Resident Patient and Outpatient).

o Physician

o Care Center

o Bed

o Visit

 Attributes and Relationships:

o Each Patient is assigned to one Physician.

o Each Resident Patient is assigned a Bed in a Care Center.

o Volunteers are supervised by Employees or Physicians.

o A Nurse can be a Nurse-in-Charge for a Care Center.

o Employees and Physicians can supervise multiple Volunteers.

ERD Diagram:

2. Suppose each care center had two nurses-in-charge, one for the day shift, and another one for
the evening shift. How would that change the diagram you developed in Case Exercise 1?
Answer:

3. Develop definitions for each of the following types of objects in your EER diagram from Case
Exercise 1. Consult with some member of the hospital or health-care community (if one is
available); do some research on the Internet, or otherwise make reasonable assumptions based
on your own knowledge and experience. a. Entity types b. Attributes c. Relationships
Answer: Definitions for Entity Types, Attributes, and Relationships
Let me define these for your report:
a. Entity Types
 Person: General entity representing all individuals in the hospital.
 Employee: A person hired by MVCH, further specialized into Nurse, Technician, and Staff.
 Volunteer: A person offering unpaid services to the hospital.
 Patient: A person receiving medical services, specialized into Resident Patient and Outpatient.
 Physician: A medical professional responsible for patients.
 Care Center: A unit or department in the hospital.
 Bed: A physical bed in a care center for resident patients.
 Visit: An outpatient's scheduled visit.
b. Attributes
 Person: Name, Address, Phone, Email, Date of Birth.
 Employee: Date Hired.
 Volunteer: Skills, Interests, Hours Worked.
 Patient: Contact Date, Emergency Contact Details.
 Physician: Pager Number, DEA Number.
 Care Center: Name, Location.
 Bed: Bed ID, Room Number.
 Visit: Visit ID, Date, Time.
c. Relationships
 Supervision: Volunteers are supervised by Employees or Physicians.
 Assignment: Resident patients are assigned to beds in care centers.
 Responsibility: Patients are assigned a primary physician.
 Nurse-in-Charge: Care centers have designated nurses for shifts.

4. Figure 3-17 shows the following entity types in a universal data model: PARTY, PARTY
ROLE, PARTY RELATIONSHIP, EVENT, PRIORITY TYPE, STATUS TYPE, EVENT
ROLE, and ROLE TYPE. How would these apply to the MVCH case? Give examples of each
entity type based on the information provided in the case descriptions up to this point.
Answer: The entities from Figure 3-17 can be applied to MVCH as follows:
a. PARTY
Represents a generalized entity for all individuals or organizations in the hospital. In this case, it
corresponds to Person.
b. PARTY ROLE
Defines specific roles a person or organization can have, such as Volunteer, Employee, Physician, or
Patient.
c. PARTY RELATIONSHIP
Describes relationships between parties, such as a Patient's Emergency Contact, a Physician Supervising
a Volunteer, or an Employee Reporting to a Supervisor.
d. EVENT
Represents activities or occurrences, such as Visits by Outpatients or Volunteer Work Periods.
e. PRIORITY TYPE
Indicates the urgency or importance of an event. For example:
 A visit could have a priority type (e.g., Emergency or Routine).
 A task assigned to a volunteer could have a priority type.
f. STATUS TYPE
Tracks the current state of an event or entity. For example:
 A visit might have a status such as Scheduled, Completed, or Cancelled.
 A bed could have a status like Occupied or Available.
g. EVENT ROLE
Describes the role a party plays in an event. For example:
 A Physician is a provider in a visit.
 A Volunteer performs a task in a work unit.
h. ROLE TYPE
Specifies the type of role, such as:
 Nurse, Technician, or Staff for an Employee.
 Resident or Outpatient for a Patient.

5. Derive and clearly state the business rules that are implicit in the volunteer application form
shown in MVCH Figure 3-1.
Answer: Business Rules from Volunteer Application Form
Business Rules:
1. Personal Information: Volunteers must provide their name, address, phone numbers, email, and
date of birth.
2. References: Volunteers must list at least two non-relative references, including their contact details.
3. Employment History: Volunteers must provide details of their current or last employment.
4. Prior Volunteer Service: Volunteers must indicate if they have volunteered at MVCH or elsewhere
before.
5. Interests and Availability: Volunteers must provide their skills, hobbies, preferred working hours,
and the reason they want to volunteer.
6. Supervision: Volunteers will be supervised by an Employee or Physician.

Project Assignment:
P1. Revise the list of business rules you developed in Chapter 2 in light of the information provided
in this case segment and your insights from the Case Exercises.
Answer: Based on the new insights, the following are the revised business rules for MVCH:
1. Person Groups: Every person in the system belongs to at least one of the following groups:
Employee, Physician, Patient, or Volunteer. A person can belong to multiple groups simultaneously.
2. General Person Attributes: All persons in the system share common attributes: Name, Address, City,
State, ZIP, Phone, Email, and Date of Birth.
3. Employees:
o Employees are categorized into Nurses, Technicians, and Staff.

o Each nurse has a certificate (RN or LPN), a Colorado nursing license, and may have
certifications in specialized fields.
o Technicians have job-specific competencies depending on their role.

o Staff members have a job classification and are assigned to a work unit.

4. Care Center and Beds:

o Care centers have a name, location, and assigned beds.

o Each resident patient must be assigned to a bed in a care center.

5. Volunteers:
o Volunteer Services records skills, interests, availability, and hours worked.

o Volunteers are supervised by an employee or physician.

o Volunteer recognition occurs annually based on hours worked.

6. Patients:
o Patients can be outpatients or resident patients.

o Outpatients are scheduled for zero or more visits.

o Each patient has a primary physician and emergency contact information.

7. Physicians:
o Physicians are identified by a DEA number and pager number.

o Each physician is responsible for zero or more patients.

8. Visits:
o Each outpatient visit has a unique identifier, date, and time.

o A visit cannot exist without an associated outpatient.

P2. Following the notation from this chapter, merge your Chapter 2 E-R diagram with the EER
diagram you developed for Case Exercises 1 and 2 to represent the data requirements for MVCH’s
new system.
Answer: Merging Chapter 2 E-R Diagram with the Updated EER Diagram
To merge the diagrams:
1. Entity Consolidation:
o Combine Person entities in the E-R diagram with the generalized Person in the EER diagram.

o Add specific sub-entities for Employee, Volunteer, Patient, and Physician as in the EER
diagram.
2. Attributes:
 o Extend the attributes of each entity to include specific details like Pager Number (Physician),
Certifications (Nurse), etc.
3. Relationships:
o Integrate Supervision relationships for Volunteers, linking them with either Employees or
Physicians.
o Add the Visit entity and associate it with Outpatients.

o Include the Bed entity for resident patients.

4. Specialization:
o Use specialization for Employees (Nurse, Technician, Staff) and Patients (Resident Patient,
Outpatient).

P3. Document and explain the decisions you made during merging.
Answer: Decisions Made During Merging
1. Generalization:
o Introduced a generalized Person entity to handle shared attributes, reducing redundancy and
improving structure.
2. Specialization:
o Divided the Employee and Patient entities into specialized sub-entities to represent real-world
roles more accurately.
3. New Relationships:
o Added relationships like Nurse-in-Charge and Visit to reflect newly identified requirements.

4. Entity Removal:
o Removed any duplicate entities from the E-R diagram that were generalized into the EER
model (e.g., Volunteer details were integrated into the new Volunteer entity).
5. Attributes Expansion:
o Expanded attribute sets for entities to reflect specific requirements (e.g., skills and
certifications for Technicians and Nurses).
Rationale
 Efficiency: Generalization and specialization simplify the diagram and eliminate duplication.
 Realism: The changes reflect the complex roles and interactions in MVCH’s system.
 Clarity: The updated model is easier to interpret and better aligned with the real-world hospital
structure.

Chapter 4
Case Questions:
1. Should MVCH continue to use relational technology for its systems development? Why or why not?
Yes, MVCH should continue using relational technology for its systems development because:
 Proven Reliability: Relational databases have a long history of reliability, robustness, and
scalability, making them ideal for handling sensitive and mission-critical data like patient records and
treatment details.
 Standardization: Relational technology is highly standardized (SQL is a widely adopted standard),
ensuring compatibility and ease of integration with other systems.
 Data Consistency: Relational databases enforce strict constraints like entity integrity and referential
integrity, ensuring the hospital’s data remains consistent and accurate.
 Scalability: Relational systems can be optimized to handle increasing amounts of data, which is
essential as the hospital grows.
 Support for Complex Queries: The relational model efficiently handles complex queries, enabling
MVCH to analyze patient data, physician schedules, and treatment outcomes effectively.
However, MVCH should continue exploring newer technologies like object-oriented and XML databases for
specific use cases, such as managing unstructured data or supporting interoperability with external systems.

2. Should MVCH use normalization in designing its relational databases? Why or why not?
Yes, MVCH should use normalization for designing its relational databases because:
 Reduces Redundancy: Normalization minimizes data duplication, saving storage space and
improving performance.
 Prevents Update Anomalies: Properly normalized databases reduce the risk of update, insertion,
and deletion anomalies.
 Improves Data Integrity: Normalization ensures the integrity of data by organizing it into logical,
related tables.
 Simplifies Maintenance: A well-normalized database is easier to maintain and adapt to future
requirements.
However, MVCH should carefully balance normalization with performance, as overly normalized designs
may require complex joins, which could slow down query performance in time-critical operations like
patient care.

3. Why are entity integrity constraints important to the hospital? Which attributes may be null?
Entity integrity constraints are crucial for MVCH because:
 Uniqueness: They ensure that every record (e.g., patient, physician, treatment) can be uniquely
identified, which is essential in healthcare to avoid misidentification and potential medical errors.
 Data Consistency: By enforcing non-null primary keys, the database ensures that every table has
complete and consistent data.
Attributes that may be null:
 Middle name of a patient or physician.
  Discharge date in the case of an ongoing treatment.
 Secondary contact number for patients.
 Insurance claim numbers for uninsured patients.

4. Why are referential integrity constraints important to the hospital?

Referential integrity constraints ensure that relationships between tables remain consistent. At MVCH, this
is critical because:
 Prevents Orphan Records: For example, a treatment record should not exist without an associated
patient or physician.
 Ensures Data Accuracy: Referential integrity enforces valid relationships, ensuring that only
existing entities (e.g., valid PhysicianID) can be referenced.
 Improves Trust in Data: In a healthcare setting, data accuracy is vital to avoid life-threatening
errors.

5. Which attribute should be used as the primary key for the PHYSICIAN relation? Why?
Recommended Primary Key: PhysicianID
 Uniqueness: It is unique within the hospital’s database, avoiding conflicts or duplicates.
 Consistency: Unlike external identifiers (e.g., Social Security number), it is hospital-assigned and
under MVCH’s control.
 Privacy: Using PhysicianID avoids exposing sensitive personal information like Social Security
numbers.
Attributes not recommended:
 Social Security Number (SSN): Privacy concerns and potential for theft or misuse.
 License Number: Not guaranteed to be unique across multiple jurisdictions.
 DEA Registration Number: Only applies to physicians who prescribe controlled substances,
leaving gaps.

6. Why is an enterprise key important in a hospital setting like MVCH?

An enterprise key, which is unique across the entire database, is critical because:
 Data Integration: Ensures consistent identification of entities (e.g., patients, physicians) across
multiple systems.
 Avoids Duplication: Prevents creating duplicate records when integrating data from different
departments or branches.
 Improves Interoperability: Facilitates data exchange with external systems like insurance providers
or government health databases.
For example, using a hospital-wide unique PatientID ensures that patients visiting multiple departments are
consistently identified.

7. Why might you revisit and potentially modify the EER model during the logical design phase?
Revisiting the Enhanced Entity-Relationship (EER) model during logical design is necessary because:
 Normalization: The EER model may need adjustments to meet normalization requirements and
optimize the relational structure.
 Constraint Implementation: Logical design requires translating high-level EER concepts (e.g.,
generalization, specialization) into implementable constraints.
 Performance Optimization: During logical design, it may become evident that some relationships
or attributes need restructuring to improve query performance.
 Business Rule Changes: As MVCH refines its understanding of requirements, the EER model may
need updates to align with new business rules or policies.
For instance, a “Patient” entity in the EER model may need to be split into multiple relational tables (e.g.,
Patient, Admission, and Treatment) during normalization.

Case Exercise:
Question 1:
Normalization for MVCH Case Exercise
Patient Bill (MVCH Figure 4-1)
Table Attributes Primary Key (PK) Foreign Key (FK)
Patient Patient#, Patient#
PatientName,
PatientAddress,
DateAdmitted,
DateDischarged
Invoice InvoiceDate, InvoiceDate, Patient#
AccountNumber, AccountNumber
DueDate
BillDetail AccountNumber, AccountNumber, AccountNumber,
Code, Charge Code Code
Service Code, Description Code
Room Utilization Report (MVCH Figure 4-2)
Table Attributes Primary Key (PK) Foreign Key (FK)
Room Location, Accom Location
PatientRoomAssignment Patient#, Location, Patient#, Location
 ExpDischargeDate
Patient Patient#, Patient#
PatientName
Patient Display (MVCH Figure 4-3)
Table Attributes Primary Key (PK) Foreign Key (FK)
Patient Patient#, Patient#
PatientName,
PatientAddress,
City-State-Zip,
DateAdmitted,
DateDischarged
RoomAssignment Location, Extension Location, Extension
Insurance Insurance, Patient# Insurance Patient#
Daily Physician Report (MVCH Figure 4-4)
Table Attributes Primary Key (PK) Foreign Key (FK)
Physician PhysicianID, PhysicianID
PhysicianName
TreatmentRecord Patient#, TreatmentDate Patient#,
PhysicianID, PhysicianID
TreatmentDate,
TreatmentName
Merged 3NF Relations
Table Attributes Primary Key (PK) Foreign Key (FK)
Patient Patient#, Patient#
PatientName,
PatientAddress,
City-State-Zip,
DateAdmitted,
DateDischarged,
Insurance
Invoice InvoiceDate, InvoiceDate, Patient#
AccountNumber, AccountNumber
DueDate, Patient#
BillDetail AccountNumber, AccountNumber, AccountNumber,
Code, Charge Code Code
Service Code, Description Code
Room Location, Accom Location
RoomAssignment Location, Extension Location, Extension
 PatientRoomAssignment Patient#, Location, Patient#, Location
ExpDischargeDate
Physician PhysicianID, PhysicianID
PhysicianName
TreatmentRecord Patient#, TreatmentDate Patient#,
PhysicianID, PhysicianID
TreatmentDate,
TreatmentName

Question 2:
Case: MS Center Daily Physician Report

a. Primary Key Suggestion

For the given table, the Primary Key would be a composite key consisting of:
 PhysicianID + Patient# (combined together) because:
o A physician may treat multiple patients.

o A patient may be treated by multiple physicians.

So, PhysicianID and Patient# together will uniquely identify each record in this report.

b. Is This Table a Relation? Why or Why Not?

This table is not a valid relation in relational database terms because:
1. Redundancy: There is redundancy in the data (Physician information and Patient information is
repeated across multiple rows).
2. Atomicity: The data is not atomic. For example, Procedure could be described in more detail, and
the phone number field may have more than one value for a physician (if multiple contact numbers
are included).
3. No Clear Normalization: The data has not been normalized. This causes insertion, deletion, and
update anomalies.
Thus, it violates the First Normal Form (1NF) as well, which requires atomic values (no repeating groups).

c. Problems with Table Structure & Anomalies

1. Insertion Anomaly:
o If a new physician or patient is added, you can't insert their information without a treatment
record (unless you allow NULLs for the Procedure field).
 2. Deletion Anomaly:
o If a physician or patient's last treatment is deleted, you would lose important details (like
PhysicianName, PatientName, etc.), which might still be needed elsewhere.
3. Update Anomaly:
o If a physician's phone number changes, it would need to be updated in every row where that
physician is referenced, potentially causing inconsistencies.

d. Diagram of Functional Dependencies

 PhysicianID → PhysicianName, PhysicianPhone
 Patient# → PatientName
 PhysicianID, Patient# → Procedure
This means:
 PhysicianID determines PhysicianName and PhysicianPhone.
 Patient# determines PatientName.
 The combination of PhysicianID and Patient# determines the Procedure.

e. 3NF Relations (Normalization)

We need to normalize this data into 3NF (Third Normal Form), which eliminates redundancy and satisfies
the following conditions:
1. It is in 2NF (i.e., it must be in 1NF and have no partial dependencies).
2. It has no transitive dependencies.
Steps to normalize:
Step 1: Create Relations for Each Entity
1. Physician:
o PhysicianID (PK), PhysicianName, PhysicianPhone

2. Patient:
o Patient# (PK), PatientName

3. Procedure:
o ProcedureCode (PK), ProcedureDescription

4. TreatmentRecord:
o PhysicianID (FK), Patient# (FK), ProcedureCode (FK), TreatmentDate (PK)

f. Relational Schema & Referential Integrity Constraints

Here is the relational schema, showing primary keys (PK) and foreign keys (FK):
1. Physician
o PhysicianID (PK)

o PhysicianName

o PhysicianPhone

2. Patient
o Patient# (PK)

o PatientName

3. Procedure
o ProcedureCode (PK)

o ProcedureDescription

4. TreatmentRecord
o PhysicianID (FK)

o Patient# (FK)

o ProcedureCode (FK)

o TreatmentDate (PK)

Referential Integrity:
 TreatmentRecord.PhysicianID references Physician.PhysicianID
 TreatmentRecord.Patient# references Patient.Patient#
 TreatmentRecord.ProcedureCode references Procedure.ProcedureCode

g. CREATE TABLE Commands

Here are the SQL CREATE TABLE commands for each relation:
-- Create Physician table
CREATE TABLE Physician (
PhysicianID INT PRIMARY KEY,
PhysicianName VARCHAR(255),
PhysicianPhone VARCHAR(15)
);

-- Create Patient table

CREATE TABLE Patient (
 Patient# INT PRIMARY KEY,
PatientName VARCHAR(255)
);

-- Create Procedure table

CREATE TABLE Procedure (
ProcedureCode VARCHAR(10) PRIMARY KEY,
ProcedureDescription VARCHAR(255)
);

-- Create TreatmentRecord table

CREATE TABLE TreatmentRecord (
PhysicianID INT,
Patient# INT,
ProcedureCode VARCHAR(10),
TreatmentDate DATE,
PRIMARY KEY (PhysicianID, Patient#, ProcedureCode, TreatmentDate),
FOREIGN KEY (PhysicianID) REFERENCES Physician(PhysicianID),
FOREIGN KEY (Patient#) REFERENCES Patient(Patient#),
FOREIGN KEY (ProcedureCode) REFERENCES Procedure(ProcedureCode)
);

Question 3:
3. MS Clinic Management System Worksheet
a. Functional Dependencies & 3NF Relations
Assuming that the worksheet in MVCH Figure 4-6 contains the following attributes:
 Patient#, PatientName, DateAdmitted, Diagnosis, ProcedureCode, ProcedureDescription,
PhysicianID, PhysicianName, TreatmentDate
The functional dependencies might be:
 Patient# → PatientName, DateAdmitted, Diagnosis
 ProcedureCode → ProcedureDescription
 PhysicianID → PhysicianName
 PhysicianID, Patient#, TreatmentDate → ProcedureCode
Now, to develop 3NF relations, we proceed as follows:
1. Patient
o Attributes: Patient# (PK), PatientName, DateAdmitted, Diagnosis

2. Physician
o Attributes: PhysicianID (PK), PhysicianName

3. Procedure
o Attributes: ProcedureCode (PK), ProcedureDescription

4. TreatmentRecord
o Attributes: PhysicianID (FK), Patient# (FK), TreatmentDate, ProcedureCode (FK)

b. Relational Schema with Referential Integrity Constraints

1. Patient
o Patient# (PK), PatientName, DateAdmitted, Diagnosis

2. Physician
o PhysicianID (PK), PhysicianName

3. Procedure
o ProcedureCode (PK), ProcedureDescription

4. TreatmentRecord
o PhysicianID (FK), Patient# (FK), TreatmentDate, ProcedureCode (FK)

Referential Integrity:
 TreatmentRecord.Patient# references Patient.Patient#
 TreatmentRecord.PhysicianID references Physician.PhysicianID
 TreatmentRecord.ProcedureCode references Procedure.ProcedureCode

c. Visio Diagram
For the Visio diagram, you can create a visual representation using entities for each table and relationships
between the tables based on the foreign key constraints.
You will need to:
1. Draw entities for Patient, Physician, Procedure, and TreatmentRecord.
2. Link the entities using lines to show relationships and foreign keys.
3. Label the foreign key constraints to demonstrate referential integrity.
Project Assignment:
Table 1: Patient

MRN# Patient Name Sex DOB Stage Date Printed

7885 Michael J Olsen M June 16, 1949 Secondary Progressive MS 07 July 2010

9844 John Miller M 10/1/2008 - -

4211 Sheryl Franz - 1/3/2009 - -

8766 Juan Ortega - 2/2/2009 - -

Table 2: Visit

Visit Level of
VisitID MRN# Visit Date Reason for Visit New Symptoms
Time Pain

Severe leg pain for past 2

1 9844 10/11/2009 2:30 PM Severe leg pain 4
days

Follow-up, also need flu

2 9844 10/18/2009 11:30 AM None 2
shot

3 9844 1/3/2010 10:00 AM Routine None 0

4 4211 2/11/2010 9:00 AM - - 0

5 8766 2/2/2010 9:30 AM Blurred vision in right eye Follow-up 0

Table 3: Medication

MedicationID MRN# Medication Name Dosage Frequency

1 7885 Aspirin 325 mg QD

2 7885 Simvastatin 40 mg QHS

3 7885 Baclofen 10 mg TID

4 7885 Betaseron 250 mcg QOD, sc

5 7885 Amantadine 100 mg BID

Table 4: Clinical Data

DataID MRN# Lipid Profile LDL Triglycerides HDL Cholesterol Date

1 7885 54 214 27 183 06/23/2010

2 7885 54 325 24 217 03/16/2010

3 7885 62 200 24 166 12/13/2010

DataID MRN# Lipid Profile LDL Triglycerides HDL Cholesterol Date

Table 5: Radiology Data

RadiologyID MRN# MRI Type MRI Date Lesion Status

1 7885 Brain MRI 05/23/2010 No new lesions

Table 6: Advisory

AdvisoryID MRN# Advisory Date Advisory Details

1 7885 06/07/2010 Suggested follow-up lipid profile in 2 weeks

Suggested follow-up for Triglycerides > 300, consider titrating

2 7885 05/20/2010
Simvastatin

Relational Schema (SQL Commands)

Here are the SQL commands that would be used to create the database tables:
-- Table for Patient
CREATE TABLE Patient (
MRN INT PRIMARY KEY,
PatientName VARCHAR(255),
Sex CHAR(1),
DOB DATE,
Stage VARCHAR(255),
DatePrinted DATE
);

-- Table for Visit

CREATE TABLE Visit (
VisitID INT PRIMARY KEY,
MRN INT,
VisitDate DATE,
VisitTime TIME,
ReasonForVisit VARCHAR(255),
 NewSymptoms TEXT,
LevelOfPain INT,
FOREIGN KEY (MRN) REFERENCES Patient(MRN)
);

-- Table for Medication

CREATE TABLE Medication (
MedicationID INT PRIMARY KEY,
MRN INT,
MedicationName VARCHAR(255),
Dosage VARCHAR(255),
Frequency VARCHAR(50),
FOREIGN KEY (MRN) REFERENCES Patient(MRN)
);

-- Table for Clinical Data

CREATE TABLE ClinicalData (
DataID INT PRIMARY KEY,
MRN INT,
LipidProfileLDL INT,
Triglycerides INT,
HDL INT,
Cholesterol INT,
Date DATE,
FOREIGN KEY (MRN) REFERENCES Patient(MRN)
);

-- Table for Radiology Data

CREATE TABLE RadiologyData (
RadiologyID INT PRIMARY KEY,
MRN INT,
MRIType VARCHAR(100),
 MRIDate DATE,
LesionStatus VARCHAR(255),
FOREIGN KEY (MRN) REFERENCES Patient(MRN)
);

-- Table for Advisory

CREATE TABLE Advisory (
AdvisoryID INT PRIMARY KEY,
MRN INT,
AdvisoryDate DATE,
AdvisoryDetails TEXT,
FOREIGN KEY (MRN) REFERENCES Patient(MRN)
);

P2: Functional Dependencies and 3NF Analysis

Functional Dependencies:
 Patient:
o MRN# → PatientName, Sex, DOB, Stage, DatePrinted

 Visit:
o VisitID → MRN#, VisitDate, VisitTime, ReasonForVisit, NewSymptoms, LevelOfPain

o MRN# → PatientName (implied)

 Medication:
o MedicationID → MedicationName, Dosage, Frequency

o MRN# → PatientName (implied)

 ClinicalData:
o DataID → MRN#, LipidProfileLDL, Triglycerides, HDL, Cholesterol, Date

 RadiologyData:
o RadiologyID → MRN#, MRIType, MRIDate, LesionStatus

 Advisory:
o AdvisoryID → MRN#, AdvisoryDate, AdvisoryDetails

3NF Analysis:
 All relations are in 3NF because:
 o The attributes depend on the primary key (no transitive dependencies).

o No partial dependencies exist (all attributes are fully functionally dependent on the primary
key).
o All relations have been broken down into individual entities, satisfying 1NF, 2NF, and 3NF.

P3: Enterprise Keys and Redefining Relations

Enterprise keys have already been established as the primary keys for each relation (e.g., MRN#, VisitID,
MedicationID, etc.). There’s no need for further changes unless additional constraints are required for
unique identifiers across relations (e.g., SocialWorkerID for social workers, MedicationID for
medications).
The relational schema remains the same as defined above, with referential integrity already built into the
foreign key constraints.

P4: Revisiting the EER Model

 If necessary, revisit the EER model developed in Chapter 3. The model may need to be modified
based on:
o New insights gained during the mapping to a relational schema.

o Adjustments in the relations (e.g., adding new entities, modifying attributes) after analyzing
the functional dependencies.
In this case, the EER model seems to fit well with the given data, but you might want to check if any
additional relationships or attributes need to be captured (such as relationships between medications and
specific diagnoses, etc.).

Chapter 5
Case Questions:
1. What additional kinds of information do you need for the physical database design of the MVCH
database besides the 3NF relations you developed earlier for this case in Chapter 4?
Answer: Besides the 3NF relations, the following additional information is needed:
1. Storage Requirements: Determine the size of data to estimate storage space (e.g., VARCHAR(50) vs.
VARCHAR(255)).
2. Indexes: Decide which columns need indexing for performance optimization.
3. Data Distribution: Understand how data will be accessed and updated to determine partitioning and
optimization.
4. Transactions and Concurrency: Analyze the level of concurrency (e.g., multiple users querying
simultaneously).
5. Backup and Recovery Plan: Decide how data backups will be handled to prevent loss.
 6. Performance Requirements: Identify performance metrics like response time for queries.
7. Security and User Roles: Define access controls for data security.

2. What different types or forms of clinical data are collected at a hospital such as MVCH? Can you
identify data that may not be easily accommodated by the standard data types provided by a DBMS?
How would you handle that?
Answer: Clinical Data Types at MVCH:
1. Patient Demographics (Name, DOB, Address, etc.)
2. Medical Records (e.g., Treatment Plans, Progress Notes, Prescriptions)
3. Diagnostic Results (e.g., X-rays, MRIs)
4. Operational Data (e.g., Bed Assignments, Appointments)
 Challenging Data:
 Images (e.g., X-rays, MRIs): Not handled by standard DBMS types.
Solution: Use BLOB (Binary Large Object) for storage or integrate with a file system.
 Unstructured Data (e.g., Doctor's Notes): May not fit traditional schemas.
Solution: Use a hybrid DBMS or text-search tools like Elasticsearch.
 Time-series Data (e.g., Vitals over time): Standard DBMS types may be inefficient.
Solution: Use specialized time-series databases or optimize for time-stamp indexing.

3. Are there opportunities for horizontal or vertical partitioning of this database? If you are not sure,
what other information would you need to answer this question with greater certainty?
Answer: Opportunities for Partitioning:
1. Horizontal Partitioning: Divide data by patient categories (e.g., outpatients vs. resident patients).
2. Vertical Partitioning: Separate frequently accessed columns (e.g., Patient ID, Name) from less
frequently accessed ones (e.g., Insurance Details).
Additional Information Needed:
 Query patterns: Which tables and columns are accessed most frequently?
 Data size and growth rate: Are certain tables growing faster than others?
 Usage trends: How are different hospital departments accessing the database?
4. Do you see an opportunity for using a join index for this database? Why or why not?
Answer: Yes, a join index can optimize queries where data is frequently joined between large tables.
 Example: Queries joining Patients and Physicians on the treating physician.
 Benefit: Reduces the need for full table scans during joins, improving performance.
 Implementation: Create a join index on commonly joined columns, such as Patients.PhysicianID and
Physicians.ID.
5. Consider the following query against the MVCH database: For each treatment ordered in the past
two weeks, list by treatment ID and date (in reverse chronological order) the number of times a
physician performed that treatment that day, sorted alphabetically by physician name. a. Which
secondary key indexes would you suggest to optimize the performance of this query? Why? Make any
assumptions you need in order to answer this question. b. Following the examples in this chapter,
write the SQL statements that create these secondary key indexes.
Answer: To optimize the query’s performance, the following secondary indexes are suggested:
1. Index on Treatment Table:
o Columns: Treatment_ID, Treatment_Date

o Reason: This index helps efficiently retrieve records for treatments within the past two weeks
and allows sorting by Treatment_Date in reverse chronological order.
2. Index on Physician Table:
o Columns: Physician_Name

o Reason: Sorting the output alphabetically by physician name requires a quick lookup for
physicians.
3. Composite Index on Join Key:
o Columns: Physician_ID, Treatment_ID

o Reason: Optimizes join operations between the Physicians and Treatments tables.

4. Index on Date Filters:

o Columns: Treatment_Date

o Reason: To filter results quickly for treatments in the past two weeks.

CREATE INDEX idx_treatment_date ON Treatments (TreatmentDate DESC);

CREATE INDEX idx_physician_name ON Physicians (Name ASC);
CREATE INDEX idx_treatment_id ON Treatments (TreatmentID);
6. This chapter describes the 2002 Sarbanes-Oxley Act, which is not focused on not-for-profit
providers such as many community hospitals. a. Can you see how MVCH could benefit from
voluntarily complying with SOX? b. Specifically how can proper physical database design help with
compliance and the following: • Improving accuracy and completeness of MVCH data • Eliminating
duplicates and data inconsistencies • Improving understandability of MVCH data.
Answer: Sarbanes-Oxley Act (SOX) Compliance
a. Data Integrity: Better control over data accuracy and completeness.
 Accountability: Improved audit trails for medical and operational records.
 Trust: Enhances the hospital’s reputation by demonstrating commitment to governance standards.
b. Role of Physical Design in Compliance:
1. Accuracy and Completeness: Use constraints (e.g., NOT NULL, UNIQUE) to enforce data rules.
2. Eliminating Duplicates: Design indexes and use primary/foreign keys.
3. Improving Understandability: Normalize tables and use descriptive column names.

Case Exercise:
1. In Case Exercise 2 in Chapter 4, you wrote CREATE TABLE commands for each relation of
Dr. Z’s small database, which was to be created in Microsoft Access. Since then, Dr. Z has
decided to use Microsoft SQL Server, consistent with other databases at MVCH. Reconsider
your previous CREATE TABLE commands in answering the following questions: a. Would you
choose different data types for any fields? Why? b. Are any fields candidates for coding? If so,
what coding scheme would you use for each of these fields? c. Which fields require data values?
Are there any fields that may take on null values? d. Suppose the reason for a visit or the
patient’s social worker are not entered. What procedures would you use for handling these
missing data? Can you and should you use a default value for this field? Why or why not? e.
Using Microsoft Visio (or other tool required by your instructor), draw the physical data model
that shows the data types, primary keys, and foreign keys.
Answer:
a.Data Types
Yes, you would choose different data types because Microsoft SQL Server has a more comprehensive set
of data types compared to Microsoft Access. For instance:
 Dates: Use DATE or DATETIME for date fields instead of text fields.
 Numbers: Use INT, BIGINT, or DECIMAL for numeric fields based on expected values instead of
generic NUMBER.
 Strings: Use VARCHAR or NVARCHAR for text fields to allow variable-length storage.
b. Coding Candidates
Fields suitable for coding:
 PHYSICIAN ID, PATIENT ID, and ORDER ID can be coded as unique identifiers. A simple
numeric or alphanumeric sequence such as PHY001, PAT001, etc., can be used to reduce input errors
and make entries concise.
c. Required and Nullable Fields
 Required fields: Primary keys (e.g., PHYSICIAN ID, PATIENT ID, etc.) must have values.
 Nullable fields: Fields like SOCIAL_WORKER or VISIT_REASON might take null values if they
are not available initially.
d. Handling Missing Data
 For missing data like VISIT_REASON or SOCIAL_WORKER:
o Use a default value such as "Unknown" or "N/A".

o Alternatively, allow nulls and implement application-level validation to prompt users for
missing data when feasible.
e. Physical Data Model
You should draw an ER diagram showing:
 Data types for each field.
 Relationships with primary and foreign keys.

2. In Case Exercise 3 from Chapter 4, you developed the relational schema for Dr. Z’s Multiple
Sclerosis (MS) Clinic Management System. a. Do you see any opportunities for user-defined data
types? Which fields? Why? b. Are any fields candidates for coding? If so, what coding scheme
would you use for each of these fields? c. Are there any fields that may take on a null value? If so,
which ones? d. Do you see any opportunities for denormalization of the relations you designed in
Chapter 4? If not, why not? If yes, where and how might you denormalize? e. Do you see an
opportunity for using a bitmap index for this database? Why or why not? f. Can you think of a
situation with this set of tables where you might want to use a join index?
Answer: a. User-Defined Data Types
 Define custom types for:
o ICD-9 codes: A fixed-length CHAR(10) type for consistency.

o Phone numbers: Create a standardized format, e.g., VARCHAR(15).

b. Coding Candidates
 ICD-9 Procedure Codes: Create a structured coding scheme based on categories.
 ORDER DETAIL IDs and PATIENT IDs: Use numeric or alphanumeric codes for efficiency.
c. Nullable Fields
 Fields like SOCIAL_WORKER and VISIT_REASON may allow nulls if they aren't always relevant
or available.
d. Denormalization Opportunities
 No major denormalization is recommended since normalized tables improve consistency.
 Minor denormalization, such as combining frequently accessed fields, can be considered for
performance gains.
e. Bitmap Index Usage
 Bitmap indexes could be used for columns with low cardinality, such as GENDER or ICD-9 MAJOR
CATEGORY.
f. Join Index Opportunities
 A join index can optimize queries involving PHYSICIAN, ORDER, and ORDER DETAIL because
they are often accessed together.

3. MVCH Figure 5-1 shows a portion of the data model for MVCH’s database that represents a set
of normalized relations based on the enterprise model shown in MVCH Figure 1-1 and additional
business rules provided in the Chapter 2 case segment. Recall that TREATMENT refers to any test
or procedure ordered by a physician for a patient and that ORDER refers to any order issued by a
physician for treatment and/or services such as diagnostic tests (radiology, laboratory)
 Using the information provided below regarding data volume and access frequencies, and
following the example provided in Figure 5-1, modify the E-R model shown in MVCH Figure
5-1 to create a preliminary composite usage map. a. Data volume analysis: • Recall from an
earlier case segment that the hospital performs more than a million laboratory procedures and
more than 110,000 radiology procedures annually. Add these two figures to arrive at the
number of records for the ORDER DETAIL table. • There are approximately 250
PHYSICIANS, 20,000 PATIENTS, and 200,000 physician ORDERS in this database. • ICD-9
procedure codes for treatments (lab procedures, radiology procedures, etc.) fall into
approximately 3,500 major categories. Use this number to approximate the number of
TREATMENT records. b. Data access frequencies per hour: • Across all applications that use
the MVCH database, there are approximately 100 direct accesses to PHYSICIAN, 35 to
ORDER, 200 to PATIENT, and 150 to TREATMENT. • Of the 200 accesses to PATIENT, 30
accesses then also require ORDER data, and of these 30, there are 20 subsequent accesses to
PHYSICIAN, and 30 accesses to ORDER DETAIL. • Of the 35 direct accesses to ORDER, 10
accesses then also require PHYSICIAN data, and 20 require access to PATIENT data, ORDER
DETAIL data, and TREATMENT data. • Of the 100 direct accesses to PHYSICIAN, 20 also
access ORDER, ORDER DETAIL, and TREATMENT data. • Of the 150 direct accesses to
TREATMENT, 10 also access ORDER DETAIL data and associated ORDER and PHYSICIAN
data.
Answer:
a. Data Volume Analysis
Based on the data provided:
 ORDER DETAIL: Approximately 1.11 million records (1 million lab procedures + 110,000
radiology procedures).
 PHYSICIANS: Around 250 records (based on hospital size).
 PATIENTS: Around 20,000 records.
 ORDERS: Approximately 200,000 orders made annually.
 TREATMENT: About 3,500 records (based on ICD-9 major procedure categories).
b. Data Access Frequencies
The composite usage map includes the following relationships:
1. Direct Access:
o 100 accesses to PHYSICIAN per hour.
o 35 accesses to ORDER.
o 200 accesses to PATIENT.
o 150 accesses to TREATMENT.
2. Subsequent Access Patterns:
 o 30 of the 200 PATIENT accesses also access ORDER, 20 access PHYSICIAN, and 30 access
ORDER DETAIL.
o 10 of the 35 ORDER accesses also access PHYSICIAN, and 20 require PATIENT, ORDER
DETAIL, and TREATMENT data.
o 20 of the 100 PHYSICIAN accesses also include ORDER, ORDER DETAIL, and
TREATMENT data.
o 10 of the 150 TREATMENT accesses also include ORDER DETAIL, ORDER, and
PHYSICIAN data.

4. In Case Exercise 3, you created a composite usage map for part of the MVCH database, based
on MVCH Figure 5-1. Referring to that composite usage map, do you see any opportunities for
clustering rows from two or more tables? Why or why not? Is the concept of clustering tables
supported in SQL Server? Does it differ from Oracle’s implementation? If so, how?
Answer:
a. Opportunities for Clustering Rows
 Clustering rows involves storing rows from two or more related tables together on disk to improve
query performance, especially for tables frequently joined in queries.
 Opportunities for clustering in MVCH:
1. ORDER and ORDER DETAIL:
 These are frequently accessed together, so clustering can reduce disk I/O.
2. PATIENT and related VISIT_REASON (if included as a separate table):
 These are commonly queried together, making clustering beneficial.
3. PHYSICIAN and ORDER:
 Since many queries access these two tables together, clustering rows can improve
performance.
b. SQL Server Support for Clustering
  In SQL Server, clustering is implemented using clustered indexes. The rows in a table are physically
stored in the order of the clustered index, typically based on the primary key.
 Unlike Oracle, where clustering often refers to table clustering (storing data blocks for multiple
tables together), SQL Server's clustering focuses on indexes and how they organize data for efficient
retrieval.
c. Difference from Oracle
 Oracle allows explicit table clustering for related tables to be stored in the same physical data blocks.
 SQL Server focuses on clustered indexes, which determine the physical order of rows in a single
table. It does not support multi-table clustering in the same way as Oracle.

Project Assignments:
In Chapter 4, you created the relational schema for the MVCH database. Next, you will develop the
specification for database implementation. Specifically, you need to identify and document choices
regarding the properties of each data element in the database, using the information provided in the
case segments and options available in SQL Server (or other DBMS you may be using for this
assignment).
P1. Review the information provided in the case segments and identify the data type for each field in
the database. • Do you see any opportunities for user-defined data types? Which fields? Why? • Are
any fields candidates for coding?
If so, what coding scheme would you use for each of these fields?
• Which fields may take on a null value? Why?
• Which fields should be indexed? What type of index?
Answer: Data Types
 PHYSICIAN
o PhysicianID: INT (Primary Key)

o Name: NVARCHAR(100)

o Specialty: NVARCHAR(50)

o Phone: NVARCHAR(15)

 ORDER
o OrderID: INT (Primary Key)

o PhysicianID: INT (Foreign Key referencing PHYSICIAN)

o PatientID: INT (Foreign Key referencing PATIENT)

o OrderDate: DATETIME

 ORDER DETAIL
o OrderDetailID: INT (Primary Key)
 o OrderID: INT (Foreign Key referencing ORDER)

o TreatmentID: INT (Foreign Key referencing TREATMENT)

o Quantity: INT

 TREATMENT
o TreatmentID: INT (Primary Key)

o Description: NVARCHAR(100)

o ICD9Code: CHAR(10)

 PATIENT
o PatientID: INT (Primary Key)

o Name: NVARCHAR(100)

o DateOfBirth: DATE

o Gender: CHAR(1) (M/F)

o Address: NVARCHAR(200)

User-Defined Data Types

 Phone numbers: VARCHAR(15) for a consistent format.
 ICD9Code: Use a user-defined type like CHAR(10) for consistency in medical codes.
Fields for Coding
 IDs (PhysicianID, PatientID, OrderID, etc.): Numeric or alphanumeric coding, e.g., PHY001,
PAT001.
 ICD9Code: Use the ICD-9 coding structure for treatment categories.
Nullable Fields
 TREATMENT.Description: May allow nulls if description is optional.
 PATIENT.Address: May allow nulls for patients without permanent addresses.
Indexing
 Primary Keys: Automatically clustered indexes in SQL Server.
 Foreign Keys: Use non-clustered indexes for better join performance.
 Frequently Queried Fields:
o PHYSICIAN.Name: Non-clustered index.

o PATIENT.Name: Non-clustered index.

o ORDER.OrderDate: Non-clustered index.

P2. Create a data dictionary similar to the metadata table shown in Table 1-1 in Chapter 1 to
document your choices. For each table in the relational schema you developed earlier, provide the
following information for each field/data element: field name, definition/description, data type,
format, allowable values, whether the field is required or optional, whether the field is indexed and the
type of index, whether the field is a primary key, whether the field is a foreign key, and the table that
is referenced by the foreign key field.
Answer:

Primary Foreign
Field Name Description Data Type Format Required Indexed References
Key Key

Unique
PhysicianID identifier for INT - Yes Yes Yes No -
physicians

Physician
Name NVARCHAR(100) - Yes Yes No No -
name

Medical
Specialty NVARCHAR(50) - Yes No No No -
specialty

Unique
PatientID identifier for INT - Yes Yes Yes No -
patients

Patient’s
Address NVARCHAR(200) - No No No No -
address

P3. Using Microsoft Visio (or similar tool designated by your instructor), create the physical data
model for the MVCH relational schema you developed in Chapter 4, clearly indicating data types,
primary keys, and foreign keys.
Answer:

P4. Identify five reports to be generated by the database and create a composite usage map for each.
Answer:
1. Report 1: Orders by Physician (PhysicianID, Name, Specialty, OrderID, OrderDate).
2. Report 2: Patient History (PatientID, Name, Gender, Address, OrderID, OrderDate, TreatmentID,
Description).
3. Report 3: Treatment Summary (TreatmentID, Description, ICD9Code, Number of Orders).
4. Report 4: Monthly Order Summary (OrderID, OrderDate, PhysicianID, PatientID, TreatmentID).
5. Report 5: Patient Demographics (Gender, Age Distribution, Address).
 Chapter 6
Case Questions:
1. What version of SQL and what RDBMS will you use to do the case exercises?
The version of SQL and RDBMS depends on the tools available. Based on the book's recommendation:

 Use SQL Server Management Studio (SSMS) for practicing SQL queries.
 This environment allows you to use T-SQL (Transact-SQL) commands for interacting with the
database.

2. Which CASE tools are available for completing the case exercises? Can the CASE tool you are
using generate the database schema from the physical data model(s) you created?

 CASE tools like Oracle SQL Developer Data Modeler, ER/Studio, or Microsoft Visio are
commonly used for designing physical data models.
 These tools can generate database schemas directly from physical data models by exporting the
design as SQL scripts, which you can run to create your tables and constraints.
3. Can you suggest an easy way to populate your tables if you want to create a large set of test data?

 Use SQL scripts to insert data in bulk:

o Write SQL INSERT INTO statements for each record.
o Example:

sql
Copy code
INSERT INTO Patients (PatientID, Name, Age, Address, Phone)
VALUES (8766, 'John Doe', 45, '123 Main St', '555-1234');

 Alternatively, use tools like:

o Mockaroo or Faker.js to generate realistic data.
o Import data into SQL from a CSV file using commands like:

sql
Copy code
BULK INSERT Patients
FROM 'C:\data\patients.csv'
WITH (FIELDTERMINATOR = ',', ROWTERMINATOR = '\n');

4. How do the actual values you are using help you to test the functionality of your database?

 The values allow you to test:

o Data retrieval and insertion queries.
o Constraints like primary keys, foreign keys, and validations.
o The accuracy of aggregate functions like SUM(), AVG(), etc.
o The performance of queries involving joins, groupings, and filtering.

Case Exercise:
1. . In Case Exercise 1 in Chapter 5, you created the physical data model for Dr. Z’s database that
keeps track of patients checking in. You may recall that Dr. Z decided to use SQL Server. Instructions
for installing SQL Server and SQL Server Management Studio Express are available in the Pine
Valley sample database area of this book’s Web site.
a. Create the database and tables using SQL. Be sure to create the proper assertions necessary to
ensure referential integrity and other constraints.
Based on Chapter 5, you need tables like Patients, Appointments, Doctors, and SocialWorkers. Below is an
example:
SQL

CREATE DATABASE MountainViewDB;

USE MountainViewDB;

-- Create Patients Table

CREATE TABLE Patients (
PatientID INT PRIMARY KEY,
Name NVARCHAR(50),
 Age INT,
Address NVARCHAR(100),
Phone NVARCHAR(15)
);

-- Create Social Workers Table

CREATE TABLE SocialWorkers (
WorkerID INT PRIMARY KEY,
Name NVARCHAR(50),
Department NVARCHAR(50)
);

-- Create Appointments Table

CREATE TABLE Appointments (
AppointmentID INT PRIMARY KEY,
PatientID INT,
WorkerID INT,
AppointmentDate DATE,
Notes NVARCHAR(255),
FOREIGN KEY (PatientID) REFERENCES Patients(PatientID),
FOREIGN KEY (WorkerID) REFERENCES SocialWorkers(WorkerID)
);

b. Populate the database with sample data.

You can populate your tables using INSERT statements. Here are examples:
SQL

-- Insert Sample Data into Patients

INSERT INTO Patients (PatientID, Name, Age, Address, Phone)
VALUES
(8766, 'John Doe', 45, '123 Main St', '555-1234'),
(8767, 'Jane Smith', 34, '456 Elm St', '555-5678');

-- Insert Sample Data into Social Workers

INSERT INTO SocialWorkers (WorkerID, Name, Department)
VALUES
(101, 'Alice Green', 'Psychology'),
(102, 'Bob Brown', 'Rehabilitation');

-- Insert Sample Data into Appointments

INSERT INTO Appointments (AppointmentID, PatientID, WorkerID, AppointmentDate, Notes)
VALUES
(1, 8766, 101, '2025-01-10', 'Follow-up for counseling'),
(2, 8767, 102, '2025-01-12', 'Physical therapy session');

c. Write and test queries

i. Select information from only one of the tables

 Alphabetical listing of all patients:

SQL
SELECT * FROM Patients
 ORDER BY Name;

 Alphabetical listing of patients assigned to a social worker:

SQL
SELECT P.Name AS PatientName, SW.Name AS SocialWorkerName
FROM Patients P
JOIN Appointments A ON P.PatientID = A.PatientID
JOIN SocialWorkers SW ON A.WorkerID = SW.WorkerID
WHERE SW.Name = 'Alice Green'
ORDER BY P.Name;
ii. Aggregate information from one attribute in a table

 How often has patient 8766 visited the MS Center in a given month?

SQL
SELECT COUNT(AppointmentID) AS VisitCount
FROM Appointments
WHERE PatientID = 8766 AND MONTH(AppointmentDate) = 1;

 How many patients are assigned to each social worker.

SQL
SELECT SW.Name AS SocialWorkerName, COUNT(DISTINCT A.PatientID) AS PatientCount
FROM SocialWorkers SW
JOIN Appointments A ON SW.WorkerID = A.WorkerID
GROUP BY SW.Name;
iii. Try out various functions (MIN, MAX, AVG)

 What is the average level of pain reported by Dr. Z’s patients?

SQL
SELECT AVG(PainLevel) AS AveragePainLevel
FROM PainLevels;

 What is the worst level of pain his patients have experienced?

SQL
SELECT MAX(PainLevel) AS WorstPainLevel
FROM PainLevels;

2. Write and test queries:

Here are some SQL queries to test the database:

1. Select information from only one of the tables:

SQL
SELECT * FROM Patients;

2. Aggregate information from one attribute in a table:

o Example: Find the average age of patients:

SQL
 SELECT AVG(Age) AS AverageAge FROM Patients;

3. Try out various functions like MIN, MAX, and AVG:

o Find the earliest and latest appointment dates:

SQL

SELECT MIN(AppointmentDate) AS EarliestAppointment,

MAX(AppointmentDate) AS LatestAppointment
FROM Appointments;

o Find the number of appointments for each social worker:

SQL

SELECT WorkerID, COUNT(AppointmentID) AS TotalAppointments

FROM Appointments
GROUP BY WorkerID;

4. Qualify results by category:

o List patients assigned to each social worker:

SQL

SELECT SW.Name AS SocialWorkerName, P.Name AS PatientName

FROM SocialWorkers SW
JOIN Appointments A ON SW.WorkerID = A.WorkerID
JOIN Patients P ON A.PatientID = P.PatientID
ORDER BY SW.Name;

Project Assignments:
P1: Create the MVCH Database and Tables
a. SQL Statements for Creating Tables
Below is an example of creating tables for an MVCH database based on typical hospital requirements (e.g.,
Patients, Appointments, SocialWorkers, etc.).
SQL
-- Create the Database
CREATE DATABASE MVCH_DB;

-- Use the Database

USE MVCH_DB;

-- Create Patients Table

CREATE TABLE Patients (
PatientID INT PRIMARY KEY,
Name NVARCHAR(50) NOT NULL,
Age INT,
Address NVARCHAR(100),
Phone NVARCHAR(15),
 Insurance NVARCHAR(100)
);

-- Create Social Workers Table

CREATE TABLE SocialWorkers (
WorkerID INT PRIMARY KEY,
Name NVARCHAR(50) NOT NULL,
Department NVARCHAR(50)
);

-- Create Appointments Table

CREATE TABLE Appointments (
AppointmentID INT PRIMARY KEY,
PatientID INT NOT NULL,
WorkerID INT NOT NULL,
AppointmentDate DATE NOT NULL,
Notes NVARCHAR(255),
FOREIGN KEY (PatientID) REFERENCES Patients(PatientID),
FOREIGN KEY (WorkerID) REFERENCES SocialWorkers(WorkerID)
);

-- Create Pain Levels Table

CREATE TABLE PainLevels (
PainLevelID INT PRIMARY KEY,
PatientID INT NOT NULL,
PainLevel INT CHECK (PainLevel BETWEEN 1 AND 10),
ReportDate DATE NOT NULL,
FOREIGN KEY (PatientID) REFERENCES Patients(PatientID)
);

b. SQL Statements for Creating Indexes

Indexes improve query performance and ensure faster data retrieval. Below are some examples:

 Index for Searching Patients by Name:

SQL
CREATE INDEX IDX_PatientName
ON Patients (Name);

 Index for Appointment Dates:

SQL
CREATE INDEX IDX_AppointmentDate
ON Appointments (AppointmentDate);

 Unique Index on Social Worker Name:

SQL
CREATE UNIQUE INDEX IDX_SocialWorkerName
ON SocialWorkers (Name);

P2: Populate the Database with Sample Data

Below are SQL INSERT statements to add test data:
SQL
-- Insert Sample Data into Patients
INSERT INTO Patients (PatientID, Name, Age, Address, Phone, Insurance)
VALUES
(1, 'John Doe', 45, '123 Main St', '555-1234', 'Health Plan A'),
(2, 'Jane Smith', 34, '456 Elm St', '555-5678', 'Health Plan B'),
(3, 'Michael Brown', 60, '789 Oak St', '555-9876', 'Health Plan C');

-- Insert Sample Data into Social Workers

INSERT INTO SocialWorkers (WorkerID, Name, Department)
VALUES
(101, 'Alice Green', 'Psychology'),
(102, 'Bob Brown', 'Rehabilitation');

-- Insert Sample Data into Appointments

INSERT INTO Appointments (AppointmentID, PatientID, WorkerID, AppointmentDate, Notes)
VALUES
(1, 1, 101, '2025-01-01', 'Initial consultation'),
(2, 2, 102, '2025-01-15', 'Physical therapy'),
(3, 3, 101, '2025-01-20', 'Follow-up session');

-- Insert Sample Data into PainLevels

INSERT INTO PainLevels (PainLevelID, PatientID, PainLevel, ReportDate)
VALUES
(1, 1, 8, '2025-01-01'),
(2, 2, 3, '2025-01-15'),
(3, 3, 5, '2025-01-20');

P3: Write and Execute Queries to Test the Database

1. Query: List All Patients
SQL
SELECT * FROM Patients;
2. Query: List All Appointments for a Specific Social Worker
SQL
SELECT A.AppointmentID, P.Name AS PatientName, A.AppointmentDate, A.Notes
FROM Appointments A
JOIN Patients P ON A.PatientID = P.PatientID
WHERE A.WorkerID = 101;
3. Query: Count Patients Assigned to Each Social Worker
SQL
SELECT SW.Name AS SocialWorkerName, COUNT(A.PatientID) AS TotalPatients
FROM SocialWorkers SW
JOIN Appointments A ON SW.WorkerID = A.WorkerID
GROUP BY SW.Name;
4. Query: Patients Who Have Reported Pain Above 5
SQL
SELECT P.Name AS PatientName, PL.PainLevel
FROM PainLevels PL
JOIN Patients P ON PL.PatientID = P.PatientID
WHERE PL.PainLevel > 5;
5. Query: Average Pain Level Reported
SQL
SELECT AVG(PainLevel) AS AveragePain
FROM PainLevels;

Defend the Test Data

1. Realistic Representation:
o The data reflects real-life scenarios at a hospital, such as patient appointments and pain level
tracking.
2. Covers Multiple Use Cases:
o The sample data supports testing for different queries (e.g., joins, aggregations, filtering).
3. Comprehensive Testing:
o Ensures the functionality of primary keys, foreign keys, and constraints (e.g., PainLevel
between 1 and 10).

Chapter 7

Case Questions:
1. Does your SQL-based DBMS support dynamic SQL, functions, triggers, stored procedures, and
UDTs?

 Most SQL-based DBMS platforms, like SQL Server, Oracle, or MySQL, support these features:
o Dynamic SQL: Allows you to build and execute SQL statements dynamically at runtime.
o Functions: Reusable code blocks that return a value, such as GETDATE() or custom scalar
functions.
o Triggers: Automatically executed SQL code in response to certain events (e.g., AFTER
INSERT, BEFORE UPDATE).
o Stored Procedures: Precompiled collections of SQL statements and logic stored in the
database.
o UDTs (User-Defined Types): Custom data types defined by users.

2. How can DDL triggers be used in support of HIPAA audit controls?

 DDL triggers (Data Definition Language triggers) can enforce audit controls by tracking schema
changes, which is crucial for HIPAA compliance. For example:
o Monitoring creation, modification, or deletion of database objects (tables, columns,
constraints).
o Recording these events in an audit log table, including details like the user who made the
change and the timestamp.

Example DDL Trigger:

SQL
CREATE TRIGGER AuditSchemaChanges
ON DATABASE
FOR CREATE_TABLE, ALTER_TABLE, DROP_TABLE
AS
BEGIN
INSERT INTO AuditLog (Event, ObjectName, UserName, EventTime)
VALUES (EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'NVARCHAR(100)'),
 EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(100)'),
EVENTDATA().value('(/EVENT_INSTANCE/LoginName)[1]', 'NVARCHAR(100)'),
GETDATE());
END;

Case Exercises:

1. Queries Illustrating Complex SQL

a. Select information from two or more tables

Example: Retrieve all details of visits for a specific patient:

SQL

SELECT P.Name AS PatientName, A.AppointmentDate, A.Notes, SW.Name AS SocialWorkerName

FROM Patients P
JOIN Appointments A ON P.PatientID = A.PatientID
JOIN SocialWorkers SW ON A.WorkerID = SW.WorkerID
WHERE P.PatientID = 8766;

b. Use subquery syntax

Example: List patients who reported pain exceeding the average pain for all visits:

SQL
SELECT P.Name AS PatientName, PL.PainLevel
FROM Patients P
JOIN PainLevels PL ON P.PatientID = PL.PatientID
WHERE PL.PainLevel > (SELECT AVG(PainLevel) FROM PainLevels);

c. Return a result table for a report

Example: List of patient visits assigned to a specific social worker, sorted by patient name:

SQL
SELECT P.Name AS PatientName, A.AppointmentDate, A.Notes
FROM Patients P
JOIN Appointments A ON P.PatientID = A.PatientID
WHERE A.WorkerID = 101
ORDER BY P.Name;

2. Additional Queries

a. For a given physician, which treatments have they performed on each patient?

SQL
SELECT PhysicianID, PatientID, TreatmentName
FROM Treatments
WHERE PhysicianID = 123; -- Replace 123 with the specific physician's ID
b. Include physicians who have not referred patients

Use an OUTER JOIN to include all physicians:

SQL
SELECT PH.PhysicianID, PH.Name, T.TreatmentName
FROM Physicians PH
LEFT JOIN Treatments T ON PH.PhysicianID = T.PhysicianID;

c. For each patient, average number of treatments by physician

SQL
SELECT P.PatientID, PH.PhysicianID, AVG(TreatmentCount) AS AvgTreatments
FROM (SELECT PatientID, PhysicianID, COUNT(*) AS TreatmentCount
FROM Treatments
GROUP BY PatientID, PhysicianID) T
GROUP BY P.PatientID, PH.PhysicianID;

d. List all patients who received no treatments

SQL
SELECT P.PatientID, P.Name
FROM Patients P
LEFT JOIN Treatments T ON P.PatientID = T.PatientID
WHERE T.TreatmentID IS NULL;

e. Total hours worked by employees under a nurse in charge

SQL
SELECT NC.NurseID, SUM(E.WorkHours) AS TotalHours
FROM Employees E
JOIN NurseInCharge NC ON E.CareCenterID = NC.CareCenterID
GROUP BY NC.NurseID;

f. Technicians with more than one skill or no skills

 More than one skill:

SQL
SELECT TechnicianID
FROM TechnicianSkills
GROUP BY TechnicianID
HAVING COUNT(SkillID) > 1;

 No skills:
 SQL
SELECT T.TechnicianID
FROM Technicians T
LEFT JOIN TechnicianSkills TS ON T.TechnicianID = TS.TechnicianID
WHERE TS.SkillID IS NULL;

g. Outpatients accidentally assigned to resident beds

SQL
SELECT P.PatientID, P.Name, B.BedNumber
FROM Patients P
JOIN Beds B ON P.PatientID = B.PatientID
WHERE P.PatientType = 'Outpatient';

h. Determine which item is consumed most

SQL
SELECT ItemID, SUM(Quantity) AS TotalQuantity
FROM Consumption
GROUP BY ItemID
ORDER BY TotalQuantity DESC
LIMIT 1;

i. Physicians prescribing the most expensive item

SQL
SELECT PhysicianID, ItemID, MAX(UnitCost * Quantity) AS MaxCost
FROM Prescriptions
GROUP BY PhysicianID, ItemID
ORDER BY MaxCost DESC
LIMIT 1;

j. Hospital report: Nursing staff per care center

SQL
SELECT CC.CareCenterName, E.Name AS NurseName
FROM CareCenters CC
JOIN Employees E ON CC.CareCenterID = E.CareCenterID
WHERE E.Role = 'Nurse';

k. UNION: Combined care center and laboratory locations

SQL
SELECT CareCenterName AS Name, Location
FROM CareCenters
UNION
SELECT LabName AS Name, Location
FROM Laboratories
ORDER BY Location;
Project Questions:
P1. Write and Execute Queries for Five Reports
The reports can be based on the tables and data created in earlier exercises. Here are five possible report
queries:
1. Report: List of Patients with Their Appointments
SQL
SELECT P.PatientID, P.Name, A.AppointmentDate, A.Notes
FROM Patients P
JOIN Appointments A ON P.PatientID = A.PatientID
ORDER BY A.AppointmentDate;

2. Report: Number of Patients Assigned to Each Social Worker

SQL
SELECT SW.Name AS SocialWorkerName, COUNT(A.PatientID) AS TotalPatients
FROM SocialWorkers SW
JOIN Appointments A ON SW.WorkerID = A.WorkerID
GROUP BY SW.Name;

3. Report: Patients Who Have Visited More Than Once

SQL
SELECT P.PatientID, P.Name, COUNT(A.AppointmentID) AS VisitCount
FROM Patients P
JOIN Appointments A ON P.PatientID = A.PatientID
GROUP BY P.PatientID, P.Name
HAVING COUNT(A.AppointmentID) > 1;

4. Report: Average Pain Level Reported by Patients

If you have a PainLevels table:
SQL
SELECT AVG(PainLevel) AS AveragePain, MAX(PainLevel) AS MaxPain, MIN(PainLevel) AS MinPain
FROM PainLevels;

5. Report: Social Worker Assigned to the Most Appointments

SQL
SELECT SW.Name AS SocialWorkerName, COUNT(A.AppointmentID) AS AppointmentCount
FROM SocialWorkers SW
JOIN Appointments A ON SW.WorkerID = A.WorkerID
GROUP BY SW.Name
ORDER BY AppointmentCount DESC
LIMIT 1;

P2. Create Opportunities for Triggers

Example Trigger Opportunity: Health Insurance Updates

 Use Case: A claims manager needs to be notified when a patient’s health insurance is updated.
 Trigger Purpose: Log the update in an audit table and notify the claims manager.
Step 1: Create an Audit Table
SQL
CREATE TABLE InsuranceAudit (
AuditID INT PRIMARY KEY IDENTITY(1,1),
PatientID INT,
OldInsurance NVARCHAR(100),
NewInsurance NVARCHAR(100),
UpdateDate DATETIME,
UpdatedBy NVARCHAR(50)
);

Step 2: Create a DDL Trigger

SQL
CREATE TRIGGER InsuranceUpdateTrigger
ON Patients
AFTER UPDATE
AS
BEGIN
IF UPDATE(Insurance)
BEGIN
INSERT INTO InsuranceAudit (PatientID, OldInsurance, NewInsurance, UpdateDate, UpdatedBy)
SELECT
i.PatientID,
d.Insurance AS OldInsurance,
i.Insurance AS NewInsurance,
GETDATE() AS UpdateDate,
SYSTEM_USER AS UpdatedBy
FROM Inserted i
JOIN Deleted d ON i.PatientID = d.PatientID;
END
END;

Step 3: Test the Trigger

Update a patient’s insurance and verify the audit log:
SQL
UPDATE Patients
SET Insurance = 'New Health Plan'
WHERE PatientID = 8766;

SELECT * FROM InsuranceAudit;

 Chapter 8
Case Questions:
1. Should MVCH IT staff under Mr. Heller undertake the project of moving MVCH toward an
integrated environment? Should MVCH outsource such a project? Why or why not?

 MVCH IT staff should undertake the project if they have the required expertise, understanding of
existing systems, and sufficient resources. They already know the hospital's infrastructure, internal
workflows, and integration challenges, which may make the project smoother.
 However, outsourcing may be necessary if:
o The IT staff lacks experience with Web services or integration projects.
o The hospital needs the project completed within a short timeframe (e.g., 3–6 months, as
mentioned).
o External vendors could provide specialized tools or solutions not available internally.

Recommendation: A hybrid approach could be used where MVCH IT staff collaborate with an external
service provider for technical expertise. This approach ensures knowledge transfer, cost management, and a
tailored solution for MVCH.

2. Can you think of any other approaches to integration besides the Web-based approach?
Yes, alternatives to a Web-based approach include:

1. Enterprise Service Bus (ESB):

o An ESB can act as a middleware platform to integrate multiple applications and systems.
o It supports real-time data exchange, event-driven communication, and message
transformation, which are crucial for health-care systems.
2. Health Information Exchange (HIE):
o HIE systems allow standardized sharing of health-care information across organizations.
o Using HIE standards such as HL7 (Health Level Seven) and FHIR (Fast Healthcare
Interoperability Resources), MVCH could integrate clinical and administrative systems.
3. Cloud-Based Solutions:
o Cloud platforms like Microsoft Azure or AWS HealthLake can provide centralized data
storage and integration services.
o Cloud-based APIs can simplify data sharing between existing systems and new services.
4. Point-to-Point Integration:
o For smaller-scale integration, a point-to-point system could connect specific clinical and
financial applications.
o While not scalable, this approach can address immediate integration needs.

3. Discuss the extent and nature of security and privacy issues when evaluating decisions to provide
critical patient information over the Web. Why would systems integration address HIPAA’s privacy
and security concerns?

 Security and Privacy Issues:

o Confidentiality: Patient health information must be protected from unauthorized access.
Web-based systems need robust encryption (e.g., HTTPS, SSL/TLS).
o Authentication and Access Control: Implement strong authentication mechanisms (e.g.,
two-factor authentication) to restrict access to sensitive data.
o Data Integrity: Ensure that patient data is not altered during transmission or storage.
 o Audit Logs: Maintain detailed audit logs for all data access and modifications to meet
HIPAA requirements.
o Network Security: Protect against potential breaches by implementing firewalls, intrusion
detection systems, and secure APIs.
 Why Integration Helps Address HIPAA Concerns:
o Centralized Data Management: Integration reduces the chances of data inconsistencies and
unprotected manual transfers.
o Real-Time Monitoring: Unified systems allow administrators to monitor access and activity
in real time, detecting any unauthorized actions quickly.
o Audit and Reporting: An integrated system simplifies compliance reporting and tracking of
who accessed or modified patient information.

4. Why has the health-care industry been slower to adopt Web services compared to other industries?
What are the critical success factors for making Web services successful at MVCH?

 Reasons for Slow Adoption:

o Regulatory Concerns: The health-care industry faces strict privacy and security regulations
(e.g., HIPAA) that slow down technology adoption.
o Legacy Systems: Hospitals often rely on legacy systems that are not easily compatible with
Web services.
o Cost Constraints: Health-care organizations may have limited budgets for IT upgrades.
o User Resistance: Clinicians and staff may resist new workflows or technologies that increase
workload.
 Critical Success Factors for Web Services at MVCH:

1. Stakeholder Engagement: Involve physicians, nurses, administrators, and IT staff in the

planning and implementation process.
2. Robust Security Measures: Ensure compliance with HIPAA and implement advanced
security protocols.
3. Interoperability Standards: Use health-care standards like HL7 and FHIR for seamless
communication between systems.
4. Scalability and Reliability: Design systems that handle high user loads and provide near-
zero downtime.
5. Training and Support: Offer comprehensive training for all users to ensure smooth
adoption.
6. Cost-Benefit Analysis: Demonstrate the financial and operational benefits of Web services to
secure buy-in from decision-makers.

5. Should MVCH treat the potential implementation of Web-based solutions and Web services as a
technology issue or a strategy issue? Please explain.

 It should be treated as a strategic issue.

o The implementation of Web services at MVCH aligns with the hospital’s long-term goals of
improving patient care, operational efficiency, and stakeholder satisfaction.
o Technology is merely a tool to achieve these strategic objectives. The focus should be on how
the Web services solution integrates with the hospital’s vision, mission, and future growth.
 Why a Strategic Approach?

1. Alignment with Goals: A strategic approach ensures that IT solutions support broader
objectives like cost reduction, improved patient outcomes, and enhanced user satisfaction.
 2. Resource Allocation: Strategy-driven decisions help prioritize resources and funding for the
most impactful projects.
3. Change Management: A strategic approach anticipates and addresses organizational
changes, such as workflow adjustments and training needs.

Case Exercises:
1. Advantages and Risks/Disadvantages of a Three-Tier Architecture in a Web-Based Environment
Advantages:

1. Scalability: The three-tier architecture separates the presentation, application logic, and data layers,
making it easier to scale any layer independently.
2. Improved Security: By isolating the database and application server, it reduces the chances of direct
database exposure to external threats.
3. Flexibility: Multiple front-end clients (e.g., web browsers, mobile apps) can access the same back-
end services.
4. Efficient Maintenance: Changes in one layer (e.g., presentation UI) don’t require changes to the
other layers, simplifying updates.
5. Fault Tolerance: Failure in one layer (e.g., the front-end) doesn’t necessarily impact the other layers.

Disadvantages/Risks:

1. Complexity: The architecture introduces additional components and complexity in development,

deployment, and maintenance.
2. Performance Issues: The separation of layers may introduce latency, particularly if the network
communication between layers is slow.
3. Costs: Higher infrastructure and development costs, as each layer requires specific tools and
technologies.
4. Integration Challenges: Interfacing legacy systems with the three-tier model can be complicated.

Significant Challenges:

1. Ensuring seamless integration with MVCH’s existing heterogeneous platforms.

2. Addressing real-time performance requirements for clinical data.
3. Ensuring data consistency and interoperability with legacy systems.

Recommended Technologies:

1. Front-End (Presentation Layer): Use modern frameworks like React.js, Angular, or Vue.js.
2. Application Server (Logic Layer): Implement using Node.js, Java Spring Boot, or .NET Core.
3. Database (Data Layer): Use MySQL, SQL Server, or PostgreSQL, depending on MVCH’s
existing database setup.
4. Security Tools: Employ OAuth 2.0, JWT tokens, and SSL/TLS encryption for secure
communication.

2. Advantages and Challenges of a Fully Integrated Health Information/ERP System

Advantages:

1. Unified System: A single integrated system avoids data silos, ensuring all departments work with
consistent, real-time information.
2. Streamlined Processes: Improves efficiency by automating and standardizing workflows across the
hospital.
 3. Compliance: Easier to ensure regulatory compliance, such as HIPAA, when all data resides in one
system.
4. Improved Decision-Making: Provides a centralized data source for better analytics and reporting.

Challenges:

1. High Initial Costs: Purchasing and implementing an ERP system is expensive.

2. Implementation Time: Full integration may take years, disrupting hospital operations.
3. Resistance to Change: Staff may resist adapting to new workflows and systems.
4. Customization: Off-the-shelf ERP systems may not fit all hospital-specific needs, requiring
significant customization.
5. Vendor Lock-In: Relying on a single vendor can limit future flexibility and innovation.

3. Has MVCH Arrived at the Right Decision?

MVCH’s decision to explore Web-based integration using a three-tier architecture is a reasonable first step.
This approach offers the flexibility to integrate systems incrementally and address immediate operational
challenges. However, transitioning to a fully integrated ERP system may offer long-term benefits, including
seamless data flow and regulatory compliance.
Additional Information Needed:

1. Cost-benefit analysis of both approaches.

2. Feasibility of integrating existing systems with Web-based services.
3. Estimated downtime and impact on hospital operations.
4. Training requirements and associated costs for staff.

4. Benefits of Thin Clients in a Hospital Setting

Benefits:

1. Centralized Management: Thin clients are easier to maintain since all applications and data are
stored on a central server.
2. Cost-Effectiveness: Thin clients are less expensive than full-featured desktops and consume less
power.
3. Improved Security: Centralized data reduces the risk of data breaches due to lost or stolen devices.
4. Easier HIPAA Compliance: Since data isn’t stored locally, it’s easier to ensure data confidentiality
and security.

Recommended Thin Client Devices:

 Tablets for nurses and physicians for portability and quick access.
 Desktop Thin Clients in administrative areas for stationary workstations.

Recommendation: MVCH should pursue a thin client strategy for better security, cost savings, and ease of
maintenance.
5. Prioritizing Web-Based Business Functions
Recommendation: Implement patient portals for online appointment scheduling and clinical information
access first. This offers immediate benefits to both patients and physicians.
Evaluation of the Options:

Se
Function Data Entry Requirements Benefits & Costs
curity Concerns
1. Submitting Insurance Medium: Limited Billing staff handles data Reduces
 administrative
Claims Online access needed. entry.
burden.
High: Patients
2. Providing Clinical Physicians and nurses Improves patient
require secure
Information update records. satisfaction.
access.
3. Supply Chain Management Medium: Internal Inventory staff updates Increases efficiency;
Online access only. data. reduces waste.
Improves inter-
High: Requires
4. Medical Records Sharing Limited to medical staff. hospital
encrypted transfer.
communication.
5. Online Medical Knowledge Low: Public Admins or IT staff upload Enhances decision-
Base information. data. making.

Project Questions:
P1. MVCH Hospital Database Available to Several Desktop Client Applications
a. What client and connectivity components are needed to access the database?

1. Client Components:
o Database Driver: A driver is needed to allow client applications to communicate with the
database (e.g., ODBC, JDBC, or ADO.NET drivers).
o Middleware: Software that connects the application to the database using the driver.
o Network Configuration: The client must have access to the database server via a configured
network.
2. Connectivity Components:
o Connection String: Specifies the server name, database name, user credentials, and driver.
o Database Protocols: Such as TCP/IP for network communication.

b. What types of client applications can access the database, and how do they connect?

1. Types of Client Applications:

o Desktop Applications: Built with tools like .NET Framework (C#), Java, or Python.
o Web Applications: Access the database using server-side code (e.g., PHP, Node.js, or
ASP.NET).
o Mobile Applications: Use APIs (RESTful or GraphQL) to interact with the database
indirectly.
2. Connection Methods:
o ODBC (Open Database Connectivity): For Windows-based client apps.
o JDBC (Java Database Connectivity): For Java-based applications.
o ADO.NET: For .NET applications.
o Direct SQL Queries: Used when the client application has direct access to the database via
drivers.

c. Which APIs are supported for building Web-based applications?

Common APIs for Web-based database applications include:

1. ADO.NET (for .NET Framework)

2. JDBC (for Java-based Web applications)
3. Python Libraries:
o PyODBC: For connecting Python apps to SQL Server.
o SQLAlchemy: For database interactions in Python.
 4. Node.js Modules:
o mssql: For connecting Node.js apps to SQL Server.
5. PHP PDO (PHP Data Objects): A common API for PHP-based applications.

d. What client tools are available, and what are their functions?

1. SQL Server Management Studio (SSMS):

o A graphical interface for managing, querying, and analyzing the database.
o Used by developers and database administrators for designing and maintaining databases.
2. Microsoft Access:
o Can connect to SQL Server and provide user-friendly forms and reports.
3. Data Visualization Tools:
o Power BI: For creating dashboards and reports.
o Tableau: For advanced data analytics.
4. Command-Line Tools:
o sqlcmd: For executing queries and managing the database from the command line.

e. Would you use more than one database server? For what purposes? How would you add another
server?

1. When to Use More Than One Server:

o Load Balancing: Distribute workload across multiple servers for better performance.
o High Availability: Maintain availability with replication or failover servers.
o Data Segmentation: Separate clinical, financial, and administrative data for security and
efficiency.
2. How to Add Another Server:
o Replication: Set up database replication between the primary server and secondary server.
o Database Clustering: Use clustering techniques to ensure high availability.
o Connection Configuration: Update client connection strings to support multiple servers.

P2. Linking Dr. Z’s MS Management System Database

a. How could you establish a link to that database?

1. Database Link:
o In SQL Server, create a Linked Server to connect to Dr. Z's MS database.

SQL

EXEC sp_addlinkedserver

@server = 'DrZ_DB_Server',
@srvproduct = '',
@provider = 'SQLNCLI',
@datasrc = 'DrZDatabaseServer';

2. Authentication:
o Configure login credentials to connect to the linked server:

SQL

EXEC sp_addlinkedsrvlogin
@rmtsrvname = 'DrZ_DB_Server',
 @useself = 'false',
@rmtuser = 'username',
@rmtpassword = 'password';

3. Querying the Linked Server:

o Use the OPENQUERY function to query the remote database:

SQL

SELECT *
FROM OPENQUERY(DrZ_DB_Server, 'SELECT * FROM Appointments');

b. How would you move Dr. Z’s database to the same server?

1. Backup and Restore:

o Backup the database from the existing server:

SQL

BACKUP DATABASE DrZ_DB TO DISK = 'C:\Backup\DrZ_DB.bak';

o Restore it to the MVCH database server:

SQL

RESTORE DATABASE DrZ_DB FROM DISK = 'C:\Backup\DrZ_DB.bak';

2. Update Connection Strings:

o Modify the connection strings of client applications to point to the new server.

P3. Web-Enabling the MVCH Database

a. Online Patient Registration

1. Functionality:
o Allow patients to register online by filling out a form with their details.
o Example registration data:
 Name
 Address
 Phone
 Appointment Date
o Data is stored in the Patients and Appointments tables.
2. Technologies Used:
o Frontend: HTML, CSS, JavaScript (e.g., React.js or Angular).
o Backend: Node.js or PHP to handle form submissions.
o Database: SQL Server for storing patient data.
3. SQL Query for Registration:

sql
Copy code
INSERT INTO Patients (Name, Age, Address, Phone)
VALUES ('John Doe', 45, '123 Main St', '555-1234');
b. Online Volunteer Application

1. Functionality:
o Create an online form for volunteers to sign up with fields like:
 Name
 Availability
 Skills
o Data is stored in a new Volunteers table.
2. Table Design:

SQL
CREATE TABLE Volunteers (
VolunteerID INT PRIMARY KEY IDENTITY(1,1),
Name NVARCHAR(50),
Availability NVARCHAR(100),
Skills NVARCHAR(100)
);

3. Insert Query:

SQL
INSERT INTO Volunteers (Name, Availability, Skills)
VALUES ('Jane Smith', 'Weekends', 'First Aid');

c. Employee/Physician Login

1. Functionality:
o Provide a secure login system for employees or physicians using usernames and passwords.
2. Table for Users:

SQL
CREATE TABLE Users (
UserID INT PRIMARY KEY IDENTITY(1,1),
Username NVARCHAR(50),
PasswordHash NVARCHAR(256),
Role NVARCHAR(50) -- e.g., Admin, Physician, Nurse
);

3. Secure Authentication:
o Use password hashing (e.g., bcrypt) to store passwords securely.
o Example login query:

SQL

SELECT *
FROM Users
WHERE Username = 'admin' AND PasswordHash = HASHBYTES('SHA2_256',
'password123');