Gbotem 3chap

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 26

CHAPTER THREE

METHODOLOGY

In the realm of this system, access control stands as the foremost guardian of data

integrity and privacy. Access control mechanisms are intricately woven into the fabric of

user interactions, ensuring that sensitive information remains safeguarded and accessible

only to those with explicit authorization. Whether it be patients managing their medical

records or physicians seeking access to pertinent information, the system employs robust

access control protocols. Through meticulous user registration procedures, encryption

technologies, and patient-physician agreements, the system establishes a secure

environment where information is shared conscientiously, and user roles dictate the

extent of data accessibility.

3.1 Physician’s requirements

For the doctors, they would like a system that allows them to access the records from

other hospitals‟ information systems when they were authorized by their patients. So they

don’t have to view a handwritten record. That can significantly reduce the medical

accident caused by misunderstanding. Doctors hope they can not only read the patient’s

medical record, but also can create new medical records and change the old medical

records.

3.2 Administrator’s requirements

The administration of the system requires oversight from an administrator. Within this

role, the administrator maintains a list of hospitals authorized for information sharing.

Hospitals included in this list have the privilege of sharing information with other

member hospitals. The administrator holds the authority to modify, add, or remove

19
hospitals from this list. Any hospital seeking to join the system must submit an

application to the administrator, who subsequently evaluates and approves the request.

Furthermore, all user accounts within the system fall under the management purview of

the administrator. When doctors necessitate modifications to a patient's medical records,

they are required to submit applications to the administrator requesting for a particular

patient medical record. The administrator holds the decision-making power to approve or

reject the Physician's request based on the nature of the modification and adherence to

established protocols. This centralized administrative control ensures a secure and

regulated environment within the system.

3.3 Security requirements

To prevent abusive registration, individuals are restricted to creating only one account per

person within this system, although they can have multiple records. Registration requires

the use of their unique ID number, and during this process, users can establish a

password. The password serves as a secure credential, ensuring that only those with

knowledge of the password can access the account. Additionally, the transmission of both

medical records and personal information is encrypted, providing an added layer of

security. In the event of interception, unauthorized individuals cannot decipher the

information without the corresponding encryption key, enhancing overall data protection.

3.4 Selection of Solutions

As mentioned before, lots of standard and access control models are used and developed.

The EHR system implement in this study is based on the study of current standards and

access control models.

20
Access Control

In previous studies, several access control models are mentioned. These models

essentially cover a wide range of access control methods. Among those models, UCON is

the most flexible model. It includes two layers: a lower level for general authorization,

and a higher level for individual authorization. But individual authorization is not very

necessary in hospital information system. If a doctor needs a specific patient‟s record,

it‟s not necessary for him to send application of individual authorization. He can just ask

his patient to allow him to access the record. So compare with those models, we decide to

use RBAC model. RBAC is very suitable for hospital information systems. Access

control classification in RBAC is enough for hospital information system. In the hospital,

doctors and patients are the main users. In RBAC model, doctors and patients can be

divided into two roles. When the user registers, roles have to be selected (doctors or

patients). Their authority will be allocated based on their role selected in the registration.

From the programming, the RBAC model is relatively easy to design. This distribution of

authority is an appropriate way for people to understand.

3.5 System Design

This system is designed based on the previously selected software architecture and access

control model. First of all, it begins with the system architecture design. The two main

functions information sharing and user access control will be realized based on this

architecture. The system architecture is designed into two main parts called foreground

and background. The foreground is for patients and doctors from hospitals. The

foreground is a user interface and users can manage their information. The background is

operated by the system administrator.

21
3.5.1 Foreground

In this part of the system, patients can search, update and delete their personal

information and medical record. But they can not change the medical records. The

doctors from hospitals can search, add patients‟ medical record if the patients authorize

to them, but they can not change or delete patients‟ medical record. If they want to, they

must ask Hygiene Department (administrator). If administrator gives the authority to

them, they can change or delete the residents‟ medical record. In this system, each user

has their loginID and password. User‟s loginID is fixed once they register in the system.

But they can change the password by themselves. (Administrator registers all users)The

foreground structure of this system is showed as Figure 2 below. Figure 2 shows the

structure of the system foreground.

Fig: 3.1 Foreground Structure

22
3.5.2 Background

In the background part, the administrator can increase or decrease the number of the

users. It can also authorize to the hospitals so they can update the patients‟ medical

records. Then it can create or delete patients‟ files also, it can mange the content of all

files.

Fig. 3.2: Background Structure

3.5.3 Interoperability

There are three databases. The first one is for patients include patients‟ personal

information, ex: name, age, address and so on. The other two databases simulate two

different hospitals. One is for hospital A. It includes some patients‟ medical treatment

and their own information. The other one is similar, but it simulates another hospital

called hospital B. This is a sample system, so just two hospitals are simulated in this

system. If more hospitals passion to use this system, they can just easily add their

databases into this system.

Information sharing is realized in this way. Different hospitals have their own database.

For example, a patient has a surgery in hospital. His medical record is stored in A

hospital's database. When he goes to hospital B, the doctor from hospital B need to check

the record created in hospital A. The doctor can ask the patient to change the access

23
authority. If the patient agrees, he can login his account and authorize the doctor from B

hospital to use the record from hospital A.

3.5.4 Access Control

i. Patients: In registration, if the user is a patient, will be assigned to the patient role.

In a patient role users can only access their own medical records and can not access

to other patients‟ medical records. Patients will never be authorized to access other

patients‟ records. Patients can not add, delete their medical records, because the

medical records should given by the doctors, not the patients themselves. And also

can not modify their records. The patient can authorized the doctor to access their

medical records, a patient can authorized more than one doctor to access his records

at the same time.

ii. Physician: Physicians are required to register in the system, choosing the Physicians

role during registration to obtain the necessary authority. A physician has the

capability to access multiple patient records concurrently. However, prior

agreements between Physicians and patients are essential. Upon patients providing

informed consent, the corresponding authority to access their records is established

by the patients. Physicians are restricted from accessing records without

authorization. While physicians can add new records for patients, similar to patients,

they are not permitted to modify the contents of existing medical records.

iii. Administrator: The administrator manages the background of the system.

Administrator does not visit any users‟ personal information and medical records.

Administrator can add or delete hospitals that participate in this information sharing

system in a list. If a new hospital wants to join this system, then only the

24
administrator can make the decision. Only when the hospitals had already been

added into the system by the administrator, can achieve the information sharing with

other hospital within this system. The administrator can also authorize the hospital to

update the patients‟ record. Such authorization requires the patients and doctors to

reach an agreement. Administrator exists as a confidential third part outside of the

patient and doctor. If medical records need to be modified, an agreement between

patient and doctor should be reached first. And then apply to the administrator. The

corresponding operations are done by the administrator.

3.6 Selection of Tools and Models

In this section, the tools we chose to implement the EHR system are introduced. It

includes the system architecture, RBAC model, database, programming language,

compile software and database connection tool. All the tools and models were chosen to

realize functions of an EHR system.

3.6.1 B/S Architecture

B/S: Browser/Server architecture, or WEB application. It‟s 3-tier architecture, different

from C/S (Client/Server 2-tier). In this architecture, user interface is realized by the

WWW browser and few works done by Browser. The main part of work is done by

Server. With this feature, users can visit texts, images and videos information through

WWW browser. That information is generated by kinds of Web servers. Web servers are

connected to the database servers. It send request to database servers to get the

information stored in different databases. The databases are created in the database

servers, so actually the information is stored in database servers. Compared with C/S, B/S

architecture WWW browsers take the part of various Client applications using in C/S.

25
Users just need a WWW browser generally they don‟t need other user applications. Users

can download applications from Web servers to local computers. Applications can be

used to operate databases stored in database servers. The advantages of B/S:

i. Distribution characteristics, query, browse and other services can be done anytime

and anywhere.

ii. Easy to expand server functions by adding web pages.

iii. Easy to maintain. Users‟ updates can be done by changing web pages.

iv. Easy to develop.

v. Easy to share.

Fig. 3.3 B/S Architecture

3.6.2 RBAC

RBAC, Role-Based Access Control. As introduced in the literature review part, it‟s the

authority distribution based on the roles. RBAC was chosen to realize the access control

solution in this system.

26
3.6.3 SQL

SQL is short for Structured Query Language. The main function of SQL is to create

connections to different databases. SQL was defined as a standard language for relational

database management systems by ANSI (American National Standards Institute). SQL

sentences can be used to search, update and manage data from databases. Most of the

popular relational database management systems use SQL language.

3.6.4 SQL server 2005

SQL server 2005 is a relational database management system, developed by Microsoft.

SQL server 2005 follows the SQL language standard defined by ANSI. SQL server 2005

database engine provides full XML support. Its application design model is combined

with Windows DNA architecture. It can be used to develop Web applications. SQL

server 2005 support English Query and Microsoft searching service. User friendly search

and powerful search functions are included in its Web applications. Microsoft‟s SQL

server is developed for Windows NT. It focuses on Web application. A same database

engine can be used in different platforms, from personal computers to large-scale servers.

3.7 System Functions

The functions of the system are divided into two parts, namely patients and doctors. In

this section, most of the system functions are introduced. Patients and doctors functions

have similar part. The similar part is to browse personal information and records. The

main difference for patients and doctors can be simply explained to one-to-many and

many-to-one. For patients, more than one doctor can diagnose the same patient. For

doctors, a doctor can deal with multiple patients‟ records.

27
3.7.1 Patient’s functions

When a patient logs into their account, they encounter two entrances: PersonInfo and

Hospital. In the PersonInfo section, the patient can review personal information or access

their medical records. Within the 'Personal information show' page, options include

updating the account's password and personal information. The search function is

available for finding specific records, crucial for comprehensive healthcare.

Medical records are continually generated during hospital visits due to varying diagnoses,

treatments, diseases, doctors, and hospitals. Despite their diversity, these records serve as

a fundamental diagnostic foundation. Historical medical records play a vital role in future

disease treatment and healthcare. As a result, patients' past medical records remain

accessible throughout their lifetime.

Given the accumulation of numerous records over time, an effective search function is

essential. This system employs two search methods. The first method allows patients to

search based on the medical record number, employing a fuzzy search function for partial

input. The second method involves searching based on the creation date of the medical

record. Patients can specify a start and end time to retrieve records within a particular

period.

In the 'Hospital' page, patients have the ability to set authorization for doctor access to

their medical records. To grant a doctor access, patients operate within their 'Hospital'

page, selecting the doctor's name and adding them to the authorized visitors' list."

28
Fig. 3.4: Patient’s Block Diagrams

3.7.2 Physician’s Functions

Within the doctor's account, there are two distinct options available. The first allows

doctors to access their personal information, akin to the patient's functionalities. Here,

doctors can choose to update their account password and view records of their patients.

Given the abundance of patient medical records, doctors often require the search

function. Similar to patients, doctors can employ two search methods. However, a notable

distinction exists – the doctor's search function incorporates an 'add new records' feature.

This additional function serves two purposes. Firstly, it is utilized when dealing with a

new patient without any existing medical records. In such cases, doctors need to create a

new medical record for the patient. Secondly, the 'add new records' function comes into

play when patients transfer from one hospital to another. While the patient may have

29
records in the former hospital, the doctor, in the new hospital, relies on both the previous

records and their own diagnosis. This dual reliance on information makes it conceivable

to create a new medical record when necessary.

Fig. 3.5: Physician’s Block Diagram

30
CHAPTER FOUR

RESULTS AND DISCUSSION

4.0 Implementation

There are many features on this system but I will focus more on the main and the

objective of this work which are the access control.

4.1 Login Page

Before accessing the system, users are required to undergo a login process. This involves

entering a traditional username and password on the login page. Following successful

authentication, a drop-down menu prompts users to specify their role—either

administrator, physician, or patient. A feature allowing the saving of usernames and

passwords is available on the login page, contingent upon the user's browser settings.

Users have the option to enable this function, and upon subsequent logins, the system

remembers their credentials, eliminating the need for repeated manual input. The process

concludes with a "login" button, and upon correct username and password entry, users

gain access to their respective user pages.

Fig. 4.1 Login Page

31
4.2 Physicians Part

When physician login this system, he can click the “update Password” to change the

password. physician’s password update function is the same as patients. Entering the

update password page, the users need to enter the old password first, then enter the new

password, and finally enter again. The new password is confirmed. In order to

successfully update the password, the users must enter the same password twice. At last,

click “submit” to confirm that change.

Physicians can search the patients depends on the file number. The file number is unique

and fixed when the user registered. One patient has only one file number, but he can have

many medical records.

Physicians are granted the ability to view specific medical records listed within the

system. Notably, not all patient medical records are displayed; inclusion in the list is

limited to two scenarios. First, records created by the physician are automatically

included. Second, records are featured if the physician has received prior authorization

from the respective patient.

To access a specific medical record, physicians can click on the blue underlined record

number. This action allows them to enter and review the pertinent medical information.

Physician’s medical records search interface. After entering the medical record number,

doctor can see the corresponding medical records. Medical records include the patient’s

basic information, and the most important thing, the content of the records. The record

primarily aims at doctors for patient’s diagnosis, treatment and the use of medication.

32
4.2.1 Access Requesting

Fig 4.2 Access Request

In critical moments of urgency, physicians have the option to submit specialized requests

for immediate access to a patient's record, providing compelling reasons for the expedited

review. Notably, this process is subject to the exclusive approval of administrative

personnel, underscoring the significance of a meticulously controlled approach.

This stringent yet judicious control mechanism has been purposefully integrated to not

only regulate but also enhance the security surrounding access to patient medical reports

during emergency situations. By infusing a touch of procedural sophistication, this

ensures that the handling of critical health information remains not only swift but also

structured, reinforcing the system's commitment to maintaining the utmost standards of

privacy and security.

4.2.2 Physician Live Chat

33
Fig 4.3 Administrative Live Chat Screen

Once a patient has chosen the specific physician with whom they wish to engage in a live

conversation, the selected physician can then log in to their dedicated portal. Within this

portal, the physician can promptly check their messages and respond with expedience,

ensuring timely communication and effective interaction with the patient.

4.3 Patient Portal

This page provides a centralized location for patients to access and manage their personal

information, medical records, and various features related to their healthcare interactions.

It includes elements such as basic patient information, buttons for updating passwords

and personal details, and a section displaying the patient's medical history. Moreso a

navigation bar for quick access to different features and tabs, making it a comprehensive

and user-friendly platform for patients to engage with their healthcare information and

communicate with healthcare providers.

34
Fig 4.4 Patient Sign in Portal

On the "Person-Info" page within the patient's account, showcased in Figure 4.2, a user-

friendly interface unfolds. Positioned at the top right of the page, a navigation bar

provides swift access to key features such as My Profile, My Messages, My Dashboard,

My Signature, My Appointments, Change Credentials, and Logout. The "Report" section

extends further functionality with options like View CCD, Download CCD, Report

Content, and Download Charted Documents. Additionally, there is an "Accountings" tab

featuring the Ledger, and a dedicated "Chat" tab.

The intuitively placed buttons in the navigation bar empower patients to effortlessly

navigate to specific pages, enabling them to modify passwords, update personal

information, and access various features promptly.

35
Beneath the patient's information, a comprehensive medical history unfolds seamlessly.

Each medical file is thoughtfully designed with five crucial data points, providing

immediate visibility without the need for additional clicks. This user-centric design

streamlines the browsing experience, displaying essential information such as the medical

number, hospital name, patient's name, responsible doctor's name, and the creation date

of the record.

4.3.1 Appointment Booking

Fig. 4.5 Patient Appointment Booking

In the diagram provided above, one approach to access control implementation involves enabling

a patient to choose a doctor from a list and schedule an appointment. The patient has the option to

select the specific doctor they wish to consult with. This personalized approach extends to the

seamless booking of appointments, as patients can confidently choose the specific doctor

with whom they aspire to engage in medical consultations. This intricate yet user-friendly

feature enhances the patient experience by placing control directly in the hands of

individuals seeking healthcare services within the OpenEHR system.

4.3.2 Full Security Sign in

36
Fig, 4.6 Patient Dashboard

Upon successful login, an additional layer of access control is implemented, requiring the

patient to affix their signature on the screen. This security measure is enacted to mitigate

the risks associated with potential hijacking or hacking attempts. Once the patient has

appended their signature, full access to their personalized dashboard is granted. Within

this secure environment, patients can seamlessly engage in various healthcare activities,

including scheduling appointments, downloading medical reports, initiating online chats

with their designated doctor, and managing other aspects pertinent to their medical

records and well-being. This multi-faceted approach not only safeguards the integrity of

the patient's information but also ensures a robust and secure interaction within the digital

healthcare ecosystem.

37
4.3.3 Secure Live Chat

Fig. 4.7 Patient Live Chat

In tandem with these security measures, an innovative feature known as Telemedicine

has been integrated. This facet empowers patients to communicate with their healthcare

providers through messaging, offering a convenient avenue for both emergencies and

scheduled interactions at a time and place of the patient's choosing.

Furthermore, a specialized access control mechanism has been introduced within the Live

Chat functionality. This enables patients to not only engage in real-time conversations

38
with their chosen healthcare professional but also to selectively designate a specific

doctor for the live chat session. By doing so, the patient ensures that their medical records

are accurately updated and maintained in conjunction with the insights and guidance

received during these live interactions. This thoughtful approach not only enhances the

accessibility of healthcare services but also fortifies the privacy and continuity of the

patient's medical information throughout telemedical engagements.

4.4 Administrative Portal

The Administrative Portal serves as a central hub for a multitude of functions,

encompassing a range of access control features. It plays a pivotal role in managing

accessibility, granting and revoking access permissions, and assigning duties to various

users within the system. Through the Administrative Portal, administrators have the

authority to regulate and oversee the intricate web of user roles, ensuring a structured and

secure environment. This includes tasks such as assigning specific responsibilities to

different personnel, controlling who has access to patient records, and managing the

overall access control framework to safeguard sensitive healthcare information. The

portal serves as a powerful tool for administrators to maintain order, security, and

efficiency within the healthcare system.

Before gaining full access to the system, the administrator is also required to undergo a

login process. This involves entering a conventional username and password on the login

page. Following successful authentication, the administrator is then granted full access to

the system, allowing them to carry out various administrative functions and oversee the

access control mechanisms within the healthcare system.

39
Various sections each represented by a navbar item. Additionally, each navbar item

appears to have a dropdown list, likely containing specific subcategories or options

related to that particular section. The Administrator Portal encompasses a variety of

features, including Calendar for scheduling, Finder for information retrieval, Messages

for communication, Recalls for appointment management, Patient for overseeing patient

information, Fees for financial tracking, Modules for component functionalities,

Inventory for resource management, Procedures for medical procedure tools, Admin for

overseeing settings and controls, Reports for generating system reports, Miscellaneous

for additional features, and Popups for handling notifications and alerts. Each of these

sections likely serves a specific purpose in managing and overseeing various aspects of

the healthcare system.

4.4.1 Access Control

Fig. 4.8 Access Control

The comprehensive access control system is centralized within the Administrative Portal,

where individual workers, such as accountants, clinicians, physicians, and others, possess

autonomy over their designated offices. Each worker has specialized control within their

40
respective domains. The administrative authority extends to the ability to dynamically

assign additional tasks based on time and situational requirements.

This strategic implementation serves the dual purpose of enhancing access control and

facilitating efficient task distribution. It allows the administrator to judiciously manage

who has access to specific aspects of patient records, thereby ensuring a secure and

tailored approach to information accessibility within the healthcare system. The system's

flexibility accommodates real-time adjustments, aligning roles and responsibilities with

the evolving demands of the healthcare environment.

4.4.2 Access Granting

Fig. 4.9 Access Granting

In the Figure Above, the default setting restricts physicians to solely adding patient

reports while maintaining empty Access Control Lists (ACLs) on the left-hand side,

41
denoted as "Active." On the right-hand side, responsibilities are distributed among other

roles.

In situations requiring urgent attention, the administrator possesses the capability to

intervene. In the event of an emergency, the administrator can select any duty from the

list on the right, subsequently assigning it to the physician by clicking the respective duty

and utilizing the forwarding arrow to transfer it to the left. This dynamic allocation

mechanism facilitates swift and targeted adjustments in responsibilities, ensuring that the

physician is equipped to address emergent scenarios effectively.

4.5 System Interoperability and Access Control

In this system, information sharing is seamlessly integrated with access control functions.

Patients employ the RBAC model to grant physician authorization to access their medical

records. Unauthorized doctors are restricted from viewing records from other hospitals.

The patient's "hospital" page facilitates physician authorization through a list, enabling

patients to add or remove doctors, thereby controlling access to their medical

information.

Moreover, physicians have the capability to request access to a specific patient's record,

but only the administrator can grant access. This access request is typically reserved for

emergency situations. In urgent cases, the administrator can dynamically assign duties to

physicians, ensuring swift adjustments in responsibilities to effectively address emergent

scenarios. This dual-layered access control system ensures controlled and authorized

information sharing while allowing for responsive interventions in critical situations.

42
CHAPTER FIVE
CONCLUSION AND RECOMMENDATION

5.1 Conclusion

This study delves into the challenges of information sharing and access control in EHR

systems. A review of international and domestic literature, EHR system standards, and

access control models led to the identification of issues in current EHR systems,

prompting the design and implementation of a simplified EHR system.

The system ensures uniformity in patient information and medical records through a

standardized format. Utilizing a header file during transmission enhances interpretability.

Semantic tools enable communication between heterogeneous systems, acting as

translators to ensure compatibility.

Implemented as a B/S architecture, the system prioritizes patient-centric access and

information sharing. By leveraging network and browser advantages, it streamlines

access to medical records and empowers patients to authorize doctors. The system's

simplicity, cost-effectiveness, and scalability make it a viable template for future designs,

promising reduced workload for medical staff and broader information sharing

capabilities.

5.2 Recommendation

Future studies could explore the fusion of B/S and C/S systems for enhanced

functionality, combining the ease of use and sharing capabilities of B/S with the

complexity and rapid response of C/S. Additionally, incorporating a comprehensive

record system is recommended. This would track changes to patient records, recording

modifications and the responsible doctor's details, serving as evidence in case of medical

malpractices.

43
Expanding the scope beyond patients and hospitals, a complete EHR system should

include various government medical departments. This holistic approach ensures a

comprehensive and interconnected healthcare information ecosystem.

44

You might also like