Title: Privacy Preferences for Electronic Medical Records Application

Introduction

In healthcare sector there is a continued adoption of EMR to improve on the storage,

retrieval and display of patient information. However, with the digitization of such
records, such patient’s records are at risk of exposure as it becomes challenging to
protect patient data where there is confidential information. Privacy is a vast concern
in the field of healthcare and; GDPR and HIPAA offer clear rules on data protection
and consent from the patient. However, there is a need to allow patients to have more
input so that they can regulate who gets to have access to the data and when.

To this end, the Privacy Preferences for Electronic Medical Records application was
created to help patients regain control of their Electronic Medical Record data.
Through the interface of setting the privacy level, consent, and audit, the application
introduces responsibility and openness into working with EMRs. This report outlines
the specific application, developed as an agile system, and will focus on the fields of
applicability, architecture, and assessment.

The reason behind choosing agile development as the methodology for this project is
due to the fact that, as much as privacy regulations and users’ preferences and
requirements are complex and dynamic in the health care sector, the development
process too should be. The agile devel-opment approaches facilitate direct
communication between developers and patients, health care providers, and
regulatory agencies to ensure that the system delivers functional and nonfunctional
requirements. Thus, during several development iterations, the response of users was
taken into account in order to make the application more convenient and less
susceptible to interference.

This report contains a brief of the functional and non-functional requirements that are
functional and non-functional; an account of the user stories as well as the elaboration
of the use case diagrams; the wireframes; and the data model. An effective test plan is
also presented to include the approaches used in testing to ensure that the system is
correct. Lastly, the report presents the assessment of the particular application,
author’s self-consideration of the experience, as well as the analysis of the
professional, ethical, and legal concerns faced throughout the project. The creation
and utilization of this application show how privacy control is a factor in healthcare,
as well as how utilizing agile methodologies are necessary due to consistently
changing requirements.

1. Requirements Specification

1.1 Functional Requirements

Functional requirements are the specific action that must get delivered by the system
in order to satisfy the users need. In the case of the Privacy Preferences for Electronic
Medical Records (EMR) application, these requirements play a huge role in the
management and controlling of medical data.

Some of the key functional requirements include:

User Registration and Authentication: It would be important to allow only the right
persons to accesses the application, and this can be done by implementing a strong
multi factor authentication. This brings a little extra security measure to it to ensure
that only allowed people will be allowed to see or tamper with patients’ information.

Patient Privacy Control: From the functional perspective, the main role of the
application is to allow patients to manage access rights on their records. People whose
care has been solicited should be able to choose the amount of openness different
kinds of medical information, including diagnoses, prescriptions, treatment plans, etc.

Consent Management: It has been observed that consent management is a

significant component of the application. Transfers. Patients would need to be able to
answer consent questions to do with access of their data as well as sharing of the data,
thus they are able to determine who accesses specific medical data. It should be
possible to set consent levels that are as detailed as with time-limited access to data.
Audit Logging: High levels of visibility are particularly important for patients who
want to gain access to their information in a transparent manner and with the consent
of their doctors. The system should log every access to medical records so that when
the data of a given patient is accessed the patient is informed.

Emergency Access Override: There are always concerns, where, in life-threatening

situations, information stakeholders may require the patient’s data without his/her
permission. It important to have an emergency access that will allow access to the
system while at the same time creating an audit trail.

1.2 Non-Functional Requirements

Service requirements are a subset of external requirements that describe process

characteristics of a system and its capacity, as well as legal requirements and
constraints. These requirements make the system to be stable, secure and efficient.
Some of the non-functional requirements include:

Scalability: In the last, The system should be able to accept additional loads
corresponding with the number of users without compromising its performance. The
architecture has to be horizontally scalable to fit an increasing number of patients and
other healthcare providers.

Security and Data Encryption: In the healthcare solution applications, security is

among the most crucial concerns. Patient generated data and privacy choices have to
be protected by end-to-end encryption so that individuals may not gain access to or
alter any information.
Compliance with Regulations: The app related rules like GDPR or HIPAA must be
followed here in order to manage the patient data legally and ethically.

Usability: It should be able to open different types of files that it can process, and the
interface should be user friendly especially for lay user. It is also important that
patients are able to select their privacy preferences with little difficulty and that the
consequences of both low and high privacy settings are explanatory.
Reliability and Availability: The application is to be always On because of the need
of healthcare providers such as doctors, nurses and patients at odd hours. Servicing
can also pose a problem when patients require doctor attention hence the need for
reliability.

2. User Stories

Notably, user stories are one of the most important components of the agile method
that describes the requirement on an application from the user’s standpoint. The
following user stories were developed to guide the implementation of the Privacy
Preferences for EMR application:

 For the user as a patient, she needs to be able secure the login for her account in
the system to manage privacy settings for the medical records.
 I have the right to seek permission to access my loved one’s private medical
record for medical necessity where necessary as a healthcare provider.

Patient: The information I provide to the healthcare organisation has to be protected

from access by unauthorized staff and where my records are accessed I have to
receive a notification.

Process 4 : All round responsibilities as an administrator to confirm that the system

adheres to the applicable laws in regard to data privacy such as HIPAA and GDPR so
that the healthcare institution will not face legal consequences.

The following user stories formed the development process so that it would meet the
needs of the users while considering legalities.

3. Use Case Diagram

The diagram below shows the use case interactions between patients, EMR heath care
givers and administrators with the Privacy Preferences for EMR system.
4. Data Model

An improved data model will ensure that many data are stored and retrieved easily
within the given system. The key entities in the data model are as follows:

 Patient Table: Manages personalized information of the patient including their

data, contact data and preferences for privacy.
 Healthcare Provider Table: It holds data related to the identity of the disparate
practitioners and their permissions.
 Consent Table: Documents patients’ consent to their records to include certain
details about who can access certain information.
 Audit Log Table: Registers every interaction with the patient data, specifically
the time, user involved and data viewing by the user.
5. Wireframes

Scaffolding is used when the layout and the navigation of the application needs to be
planned before its creation. The following wireframes depict key interfaces:

 Patient Dashboard: They enable users to monitor and also manage their privacy
options of the accounts.
 Healthcare Provider Request Screen: Where providers if they wish can request
access to specific patients’ records.

6. Screenshots

Below are screenshots of the developed application interfaces, showcasing various

functionalities:
 Login Screen
 Patient Privacy Settings
 Access Request Confirmation
7. Test Plan

Based on the outcomes of the research, a detailed test plan was created to facilitate
validation of the application when various procedures are applied. The following test
cases were defined and executed:

Test Case Description Expected Outcome

Test user registration

User Registration Successful registration
process
Login Verify the multi-factor
Successful login
Authentication authentication process
Privacy Check if patients can
Preference update their privacy Preferences updated successfully
Update settings
Ensure that consent
Consent
management is Consent recorded and processed
Management
functioning correctly
Confirm that audit logs
Audit Logging are generated for all Accurate audit logs generated
access events

It was possible to achieve the above results due to the fact that the above test cases
incorporated the most important functionalities on the side of the system in addition to
meeting functional and non-functional requirements.

8. Evaluation of the Application

8.1 Application Evaluation

Hence, based on functional and non-functional requirements the Privacy Preferences

for EMR application is implemented successfully. Here it was possible to apply the
agile approach based on successive development and constant feedback from users to
create a useful application that would also be safe. Security measures as well as the
user authentication feature and auditing log that defines the extent of conformity to
the data protection laws which include GDRP and HIPAA.

8.2 Personal Reflection

The implementation of this application has taught about project management using
the agile methodology and the problems of designing a privacy-oriented app in the
healthcare context. Because of the day to day changes in regulation and users’
requirements it was possible to focus on improving based on feedback on sprints
which are in fact short bursts of work.

8.3 Professional, Ethical & Legal Issues

There are legal and ethical issues that must in health care data security as health
information is sensitive. The application is GDPR and HIPAA compliant, which
means patient’s information is collected, processed, and shared with care and consent.
The use of audit log make sure that who accessed what is well recorded and recorded
while the use of an override means that the privacy aspect of the client is assured but
at the same time in cases where the patient needs urgent medical attention then their
details can be accessed.

8.4 Difference between Agile Development and Application

This suggests that the use of the agile programme of development is flexible as
compared to the traditional programme of development because the development
team worked closely with the stake-holders. Thus, this iterative working allowed the
team to develop the application further according to the received feedback in order to
deliver the needed service to patients and healthcare workers.

Conclusion

The Privacy Preferences for Electronic Medical Records application addresses a

critical need in the healthcare sector: the principles dealing with patient’s control over
the disclosure of their personal medical information. By allowing patient to self
operating their privacy settings, consent management and audit logs, the system
encourages patient understanding.

References

1. Beck, K., Beedle, M., Van Bennekum, A., et al. (2001). Agile Manifesto for
Agile Software Development.
2. Sommerville, I. (2011). Software Engineering (9th ed.). Addison-Wesley.
3. European Union (2016). General Data Protection Regulation (GDPR).
Official Journal of the European Union.
4. U.S. Department of Health and Human Services. (1996). Health Insurance
Portability and Accountability Act (HIPAA).
5. Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach (8th
ed.). McGraw-Hill Education.