HealthOne Medical

Project

Group #9 (BLOCKCHAIN TECHNOLOGY)

Integrates

Joshua Bonilla
Marvin Guillen
Nicol Zuniga

1
Database Design Oracle
 Project Case:

You are the owner of a small consulting company specialized in developing databases for the medical
sector. You have just been awarded a contract to develop a data model in a database application system for
a medium-sized health insurance company to track medical claims and include patient information,
information from the provider (doctor), information about the consultations in which the patient visits his
or her doctor, as well as the medications prescribed to the patient.

Some information is required, such as the patient's name, address, phone number, email address, etc., as
well as who the primary care doctor for each patient is, insurance ID number, and name. from the insurance
company. Information about each doctor is also required, such as their specialty and the hospitals they are
affiliated with, as well as their phone number, address, etc. Regarding the hospitals themselves, we will
need to know where they are located and contact information

This time it will also be necessary to record in this particular database the medications prescribed to each
patient by a healthcare provider to determine if the claim is admissible, including basic information about
the prescribed medication to ensure that it is not incompatible. with other patient prescriptions. You
should know the name, purpose/use and possible side effects of each medication.

Finally, the database will be used to track trends and for some extrapolative modeling based on
accumulated data. The database will only be available in English initially, although the goal is to make it
available in several languages.

2
Database Design Oracle
Step 1: Determination of Entities, Attributes, UID
(Sections 2 and 3)

Based on the business case described above, you will need to identify your database requirements and then
create a conceptual data model that addresses these needs.

1. Check what type of information a medical database can contain. Read articles and check online to see
what challenges recording this information poses.

2. Gather medical information to better understand the topic. Look for the type of information you will
need to keep track of.

3. Make a list of business needs, rules, and assumptions based on the case, research, and objectives.

4. Make a list of possible entities, including their attributes, attribute options, and a possible UID for each
entity.

5. Create an Entity Relationship Diagram (ERD) that meets these goals and needs. (Note: Create only the
entities. Relationships will be added in step 3)

3
Database Design Oracle
Section #2:

Information and examples of formats were DEVELOPMENT

sought to track the data with which the different insurance companies
work and what type of products they offer, in order to have better guidance when carrying out and identifying
what type of entities, can get to make the database
Sectionhttps://www.ficohsa.com/seguros/productos-y-servicios/seguro-personas/seguro-medico-hospitalario/
#1 Project challenges.
https://segurosatlantida.com/medico-hospitalario/
https://www.palig.com/pan-american-life-seguro-de-salud-honduras-2
https://vasscompany.com/seguros-de-salud-objetivo-1-conocer-al-cliente/
1. The organizational culture of companies facing the possible change of an information system for
https://www.segurossura.com.mx/personas/vida-y-ahorro/objetivo-seguro/
the insurance company.
https://www.ficohsa.com/seguros/formularios/formularios-banco-ficohsa/
2. The content of the processes that each financial institution has for the internal management of
insurance claims is part of its confidential information and cannot be revealed to the general
public.

4
Database Design Oracle
Section #3:

Aim

 Develop a data model in a database application system for a medium-sized health insurance company.

Specific objectives

 Develop an ERD model diagram (Entity Relationship Diagram) for a health insurance company.
 Develop a physical model diagram of the ERD (Entity Relationship Diagram) for a health insurance
company.
 Understand the terminology used by insurance companies to handle your information.

Investigation

 Based on the forms provided by the instructions that are dedicated to these activities of offering insurance
services, we analyze that companies enter patient data and their claims with forms assigned for this
function.
 The information provided for follow-up depends on the type of claim that the person or client makes with
the forms provided by the institution to document an insurance claim.

Business needs

• Insurers must adapt to the unique needs of each client to adapt to the existing insurance market.
• Improve existing products or services and if they do not exist, design and develop this product or service.
• Attract new clients.

Business rules

• Insurance companies cannot assign an insurance policy to a client who does not have a fixed monthly
income.
• Patients will need to have an insurance company before they can create a record.
• Doctors can be providers for the insurance company.
• Doctors can have several specialties studied.
• Doctors can be in several assigned hospitals, there is no exclusivity.
• Hospitals have your location information and contact information.
• Medical claims submitted by patients will be followed up.
• Claims may not have medications assigned, they are optional.
• Claims must be verified to determine if they are admissible to prevent the patient from receiving a
prohibited medication.
• The information entered will be assigned to country in order to define its language.
• Information about patient consultations.

5
Database Design Oracle
Business assumptions
• Expand internationally.
• Provide medical advice to clients.
• Optimize technology channels to customers for better medical care.
• Generation of advertising for insurance companies to attract new clients by offering our services.
Structural Business Rules
• Every doctor must be assigned to a Hospital.
• All medical consultation will be provided by an assigned physician.
• Medical personnel assigned to a consultation must be licensed to practice their profession.
• Medical consultation providers may be suppliers of goods and services to the insurance company.
• Each patient must be attended to through a consultation.
Business Rules by Procedure
• The patient must appear for a consultation, where the assigned doctor will provide a signed prescription in
order to make the claim to the insurance company.
• A patient can be transferred to another doctor, from the primary care doctor to a specialist.
Programmable Business Rules

6
Database Design Oracle
Section #4:

SUPPLIER HOSPITAL DOCTOR

# * supplierid # * idHospital #*
* suppliername * hospitalname PhysicianID
* address * address * doctorname
* phone * e-mail * phone
* e-mail * phone * e-mail
* address
* idSpecialty
* idHospital

PATIENT
# * patientid
* patientname MEDICINE CLAIM
* address # * drugid # * claimid
* phone * drugname * PatientID
* e-mail * functionality * supplierid
* secureid * side effects * MedicalID
* expiration date * queryid
* MedicationID

CONSULTATION
# * queryid
* PatientID
* supplierid
* PhysicianID
or dateQuery
or illness
o Observations

7
Database Design Oracle
 8
Database Design Oracle
Section #5:

Step 2: Supertypes and Subtypes (Section 4, Lesson 1)

As indicated in the case, we must track the visits in which the patient visits his doctor. Some patient visits are related to a new
condition/disease, some are follow-up visits to an existing diagnosis, and others are routine “well patient” visits or checkups. We
would like to be able to keep track of the type of query that is made each time, so that we can save information specific to the
query. For example:
1. For each new consultation for a condition/disease, an initial diagnosis will be stored
2. In follow-up consultations, it is necessary to monitor the patient's condition in relation to the diagnosis
3. In routine checkups, we need to track vital information about the patient, such as current blood pressure, height, and weight.

Modify the ERD using a supertype/subtype structure within the Query entity.

Add Entity Others

9
Database Design Oracle
Step 3: Relationships (Section 5, Lesson 1, 2, 3)

When creating the entities, you must first consider what relationships should be established between them. Create the relationships
between these entities, including the options and cardinality of the relationship.

1. Write the ERD for each of the relationships.

Each Doctor can care for one or more Patients (Transferable)

Each patient must be treated by only one doctor.

Each Doctor can work in several Hospitals (Transferable)

Each Hospital must hire one or more Doctors.

Each Doctor can provide one or more Consultations. (Transferable)

Each Consultation must be provided by a single Doctor.

Each Consultation must belong to a Claim (Non-Transferable)

Each Claim must have an Inquiry

Each Patient can make one or more Claims (Non-Transferable)

Each Claim must be made by one or more Patients

Each Supplier can supply one or more Medications (Transferable)

Each Medication must have at least one supplier

Each Prescription may contain several Medications (Non-Transferable)

Each Medication must be assigned to a Prescription

10
Database Design Oracle
Each patient can have a consultation. (Non-Transferable)
A consultation must be assigned to a patient.

Consultation should a prescription be issued. (Non-Transferable)

Each prescription can be received from one query.

Each doctor can have one or more specialties. (Non-Transferable)

Each specialty must have a doctor.

Each claim may have medications. (Transferable)

Each medication delivered must be assigned to a claim.

2. Some relationships will be transferable and others will be non-transferable (be sure to show this in the ERD). For example,
once a prescription has been written for a patient, it cannot be transferred to another patient.

3. The possible relationship types are: 1 to 1, 1 to many and many to many.

Entities Relationshi Optionality Cardinality

p
Doctor-Hospital Labor Can be M:M
Doctor-Patient Attend Can 1:M
11
Database Design Oracle
 Doctor-Consultation Toast Can 1:M
Consultation-Claim Belong Has to 1:1
Patients-Claim Carry out Can 1:M
Provider-Medicines Supply Can M:M
Prescription-Medication Assigned Can M:M

4. Any many-to-many relationship must be resolved. For example, each doctor can be associated with multiple hospitals, and each
hospital can have multiple associated doctors. We need to make sure that this many-to-many relationship is resolved so that it
allows us to keep track of which doctors are affiliated with which hospitals.

Entities Relationshi Optionality Cardinality

p
Doctor-Hospital Labor Can be M:M
Provider-Medicines Supply Can M:M
Prescription-Medication Assigned Can M:M

12
Database Design Oracle
Add the entities that were not in step 1.4

STANDARDIZATION
Step 4: Normalization (Section 6, Lesson 2, 3, 4)
13
Database Design Oracle
 PRESCRIPTION
#*Prescription_Id
* Prescription_Date
*Dose
*Duration
*Refillable

Relationship

Each PATIENT can be given one or more PRESCRIPTIONS OR PRESCRIPTION.

Each PRESCRIPTION OR PRESCRIPTION must be for only one PATIENT.

Each DOCTOR can prescribe one or more PRESCRIPTION OR PRESCRIPTION.

Each PRESCRIPTION OR PRESCRIPTION must be prescribed by only one DOCTOR.

Recipe

14
Database Design Oracle
 PRESCRIPTION
#*Prescription_Id
* Prescription_Date
*Dose
*Duration
*Refillable

Step 5: Arches (Section 7, Lesson 1)

PRESCRIPTION
#*Prescription_Id
* Prescription_Date
*Dose 15
*Duration
Database Design Oracle
Step 6: Recursive Relationships (Section 7, Lesson 2)
Each Patient can be the owner of one or more insurance policies.
And each insurance must have a patient as its owner.

16
Database Design Oracle
Steps to change Normalization

Creation of Insurance Entity

Remove the country_id from the entities
Modify Prescription entity by Prescription

Change Physician-Specialty relationship

Each doctor can have only one specialty

17
Database Design Oracle
Each specialty can have one more specialties

The prescription-entity intersection changes the recipe name

Step #7 create an Intersection History data entity called (Primary Doctor History)

#*Start date
*Final date
*reason why you live

Add the new entities to step #4

18
Database Design Oracle