0% found this document useful (0 votes)
2 views5 pages

Database Management Systems

The MEDI-CINE medical center in Melbourne is implementing a digital transformation to manage patient and administrative data through a conceptual data model using the Entity-Relationship (ER) model. Key entities include Doctor, Patient, Consultation, Prescription, Referral, and Payment, with defined relationships and cardinalities, such as optional one-to-many relationships between doctors and consultations. The model has limitations, including the inability to enforce procedural logic or validate patient eligibility for Medicare, which must be addressed in the application layer.

Uploaded by

Brian Kuhutha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views5 pages

Database Management Systems

The MEDI-CINE medical center in Melbourne is implementing a digital transformation to manage patient and administrative data through a conceptual data model using the Entity-Relationship (ER) model. Key entities include Doctor, Patient, Consultation, Prescription, Referral, and Payment, with defined relationships and cardinalities, such as optional one-to-many relationships between doctors and consultations. The model has limitations, including the inability to enforce procedural logic or validate patient eligibility for Medicare, which must be addressed in the application layer.

Uploaded by

Brian Kuhutha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Database Management Systems & Design

Student Name:

Student Number:

Course Code: MMIS103

Course Name: Database Management Systems & Design

Professor:

Date:
Part A

Introduction

The MEDI-CINE medical center in Melbourne aims to perform digital transformation of

its business operations including storing patient and administrative data. As part of this initiative,

a conceptual data model has been designed to represent the center’s key operations using the

Entity-Relationship (ER) model. The ER diagram generated and shown below is specifically

aimed at digitizing and saving essential operations and data of the medical center, including

doctor and patient details, consultations, prescriptions, referrals, and different types of payments.

To ensure diversity in billing methods, the Payment entity has a generalization hierarchy which

splits the entity into two specific subtypes: BulkBilling and FullUpfront. This generalization is

disjoint, meaning that a payment instance must be either a bulk-billing or a full-upfront payment.
Entities and Attributes.

The core entities in the system include Doctor, Patient, Consultation, Prescription,

Referral, and Payment. Each entity is defined with distinguishable attributes and primary keys, as

follows:

Entity Primary Key Attributes

Doctor RegistrationNumber Name, Date of Birth, Gender,

Qualifications(multi-valued),

Specializations (multi-valued)

Patient SerialNumber Name, Address (composite),

DateOfBirth, Gender,

TelephoneNumbers (multi-

valued), MedicareNumber,

PrivateHealthCoverNumber,

PrivateHealthCoverCompany

Consultation ConsultationNumber Name, Address (composite),

DateOfBirth, Gender,

TelephoneNumbers (multi-

valued), MedicareNumber,

PrivateHealthCoverNumber,

PrivateHealthCoverCompany

Prescription (ConsultationNumber, Dosage, NumberOfRepeats,

MedicineName) SpecialInstructions

Referral (ConsultationNumber, ShortDescription,


ProcedureName) ReferredPractitioner,

EssentialOrOptional

Payment PaymentNumber Timestamp, Amount

BulkBilling None MedicareReferenceNumber

(subtype of Payment)

FullUpFront None PaymentMethod (subtype of

Payment)

Relationships and Cardinalities

The model defines several key relationships:

1. The doctor to consultations relationship is an optional one-to-many (1:N). A doctor can

have zero or many consultations while each consultation is conducted by one doctor.

2. The patient to consultations relationship is also an optional one-to-many (1:N). A patient

can have multiple consultations but each consultation is linked to exactly one patient.

3. The consultations has a one-to-many relationship with prescriptions. Each Consultation

contains multiple prescriptions and may also include several referrals.

4. Consultations have one or more associated payments. This relationship accommodates

mixed payment methods including bulk billing and full upfront payments.
Assumptions

Several assumptions were made in the development of this model:

 A Consultation can only be associated with a Doctor and a Patient.

 A Prescription or Referral cannot work in isolation to a consultation.

 Mixed payments are stored as two distinct Payment records rather than a new, separate

entity.

Model Limitations

The use of the mentioned ER model seems helpful in depicting the structural and the

relational scenario of MEDI-CINE’s business processes However, it poses certain restrictions.

Notably, it does not support procedural logic or rule enforcement. For example, the model cannot

validate whether a patient is eligible for Medicare or determine the exact conditions that trigger a

mixed payment. Such logic would need to be implemented in the application or business logic

layer, or through advanced constraints in the relational schema.

You might also like