evintimilla-sweng587.. - Eric

bossprettyingData Management

Nov 28, 2012 (4 years and 10 months ago)

265 views

SWENG 587

April 20, 2009

Chemotherapy Drug Ordering System


ABSTRACT



This paper will examine the software architecture of a chemotherapy drug ordering system.
This application will have to do more than just order drugs. It will have to retrieve patient

data,
perform calculations based on patients, allow users to create drug regimens, and send PDF order forms
to the Pharmacy to fill the drug orders. It will also have to have the capacity to interface with other
hospital systems (such as the main patient

repository). Data integrity, system reliability, and
application security are of utmost importance, and these factors will play an important role in the
overall architecture.


PROBLEM



The hospital handles a large amount of patients who come in for chem
otherapy treatments.
They typically have multiple appointments per week for a few weeks and then take a month or two off.
How often a patient has to return is dependent on the drugs they are being given. These drugs are
grouped into strictly measured re
gimens. Doctors prescribe these regimens at the beginning of each
round of chemotherapy treatments. Usually, the drugs are pre
-
ordered the day before the patient is
scheduled to start treatment. This 24
-
hour notice is required by pharmacists, who have t
o put together
the various regimens and even order them if they are missing any of the drugs. The doctors and
pharmacists are in two separate buildings. Furthermore, the pharmacists require detailed patient
information, since the regimens are diagnosed a
ccording to variables such as patient weight, gender,
and age. Therefore, the system has to maintain data integrity and security. It also has to be available at
all times, since doctors tend to work long hours.


BUSINESS GOALS AND QUALITY ATTRIBUTES



Th
e main business goals of this organization (the cancer center at a large hospital) are to allow
doctors and pharmacists to quickly and easily order necessary chemotherapy drugs for patients and
share treatment information. They also want to ensure that th
is data is accurate and secure, since errors
in these areas could lead to deaths or leakage of patient information to unauthorized personnel.
Furthermore, the cancer center wants to be able to support staff, needs, and applications that are
constantly gro
wing or changing, since the application will be used for quite some time.


To attain these business goals, their corresponding quality attributes must be identified. In order
to give doctors and pharmacists the capacity to share information and order drug

treatments for
patients, the system must be able to communicate with other, disparate applications. It also will have to
be highly available, since doctors and pharmacists will be using it throughout the day and occasionally
at night. To protect and ens
ure data integrity, the system will have to be secure and have safeguards to
prevent data corruption. Also, since the workforce and needs of the cancer center are c
onstantly
changing, the system’
s architecture will have to be very modifiable. It will als
o have to be easy for
physicians and pharmacists to perform their tasks, since they tend to be busy with patients, and new
users should be able to learn how to accomplish their goals quickly.

To allow doctors and pharmacists to quickly and easily order nec
essary chemotherapy drugs for
patients and share treatment information, the system must be able to communicate with other, disparate
applications. This quality is concerned with converting incoming data to a format that the system can
use, as well as conv
erting outgoing data to XML so other applications can utilize the information.


Quality Attribute:

The system must be able to communicate with other, disparate applications.


Source:


Internal to the system





External to the system


Stim
ulus:


The format the data is in when it arrives at the system.




The format the data must be in when it leaves the system.


Artifact:


The incoming or outgoing data.


Environment:


At runtime.


Response:


System will convert outgoing data to XML
or incoming XML to plain text.


Response Measure:

Task time, user satisfaction.


To protect and ensure data integrity, the system will have to be secure and have safeguards to
prevent data corruption. There are two concerns for this quality: allowing/deny
ing access to users and
ensuring data integrity. To accomplish this, the system will have user authentication which is tied into
the organization

s LDAP server. Only users in certain departments will be able to use this application.
Also, the system wil
l use data concurrency and transactions to ensure information integrity.


Quality Attribute:

The system will have to be secure.


Source:


Individual or system that is (correctly or incorrectly) identified,




unauthorized/authorized to use the syste
m, and granted/denied access to




resources.


Stimulus:


User tries to access the system, display data, or make changes to data.


Artifact:


System services and data


Environment:


Online system


Response:


Authenticates user, blocks or allows acces
s to data and services, records all user




activities, monitors failed access attempts and notifies administrators in the




case of repeated tries.


Response Measure:

Time and resources to monitor and prevent security breaks, user access/activity




l
o
gs
.


Quality Attribute:

The system will have to avoid data corruption.


Source:


Incoming and outgoing system data


Stimulus:


An error occurs, packets are lost, incoming/outgoing data cannot be formatted




P
roperly
.


Artifact:


System data


Env
ironment:


At runtime


Response:


Corrupted data and event are logged. The entire transaction is rolled back.


Response Measure:

Percentage of corrupted data to uncorrupted data. Number of corruptions per




source.


Since the workforce and needs of th
e cancer center are constantly changing, the system will
have to be modifiable, and it will have to be easy for physicians and pharmacists to learn and use. To
increase usability, user activities will be logged. This will help developers make future impr
ovements
based on their preferences. The system will also have to be highly modularized, so new functionality
can be added. In order to make this easier for developers, modules will be generalized as much as
possible. Also, information will be hidden, a
nd interfaces will be kept to a minimum, which will
restrict communication paths. Furthermore, the users will need this application to be running all hours
of the day, so availability is important. To ensure a high percentage of system uptime, it will be

built to
detect and recover from faults. This information will be logged an analyzed to prevent future faults
from occurring. Also, the system should be built to perform well, with very little lag between user
input, data processing, and information ret
rieval.


Quality Attribute:

The system should be modifiable.


Source:


Developer, system administrator


Stimulus:


Wishes to add/delete/modify/vary functionality,.


Artifact:


System user interface, data, functionality


Environment:


At runtime,

compile time, build time, design time


Response:


Locates places in architecture to be modified





Makes modification without affecting other functionality





Tests modification





Deploys modification



Response Measure:

Hours spent on development




Hours saved in new functionality


Quality Attribute:

New users should be able to learn how to accomplish their goals quickly.


Source:


End user


Stimulus:


Wants to learn system features, use system efficiently


Artifact:


System


Environment:



At runtime


Response:


System provides step
-
by
-
step support and instructions.




System keeps track of most
-
used regimens and adds them to a user's start page




for easy access.


Response Measure:

Number of errors, user satisfaction, time to train ne
w users


Quality Attribute:

The system must be highly available.


Source:


Internal to the system




External to the system


Stimulus:


Faults, errors, and crashes


Artifact:


System processes and data


Environment:


Normal operation


Response:


System will detect a fault, record it, and notify the administrator. The transaction




that was being processed during the fault will be rolled back.


Response Measure:

Availability time




Repair time


Quality Attribute:

The system shoul
d perform well.


Source:


Internal to the system




User input




Data retrieval


Stimulus:


Periodic events to the system


Artifact:


System


Environment:


Normal operation


Response:


Processes stimuli


Response Measure:

Throughput and late
ncy




Although these requirements all have some importance to the overall architecture, some are
more crucial than others. In order from highest priority to lowest priority, they are:

1.

The system will have to be secure.

2.

The system will have to avoid data
corruption.

3.

The system must be able to communicate with other, disparate applications.

4.

The system must be highly available.

5.

New users should be able to learn how to accomplish their goals quickly.

6.

The system should be modifiable.

7.

The system should perform
well.


Moreover, the system has certain design constraints that must be met. For example, it must employ
a web service that allows external applications to send data to it and receive information from it.
Furthermore, the system will have to be able to g
enerate PDF documents and send emails to users.
Also, the user interface has to be customizable, allowing users to add, remove, or reposition different
modules on their start page. Furthermore, users wish to be able to save frequently used drug regimens.

The system will also require access to a location where it can safely store all generated documents.


SYSTEM DRIVERS AND LAYOUT



Now that the system’
s quality attributes and design constraints have been discerned, its
architectural drivers can be examin
ed. The main attribute that will drive the design of this system is
security. This application must ensure that patient data is only accessible to a small group of people.
Maintaining data integrity is very important as well, since an error in data can
result in the death of a
patient. Another driver is interoperability with other systems. This application must be able to read
data streams from outside sources and also send data back to these sources. Moreover, the architecture
should allow for fault
detection, handling, and prevention. This is necessary for making sure that the
application has a high amount of availability. The final two architectural drivers are usability and
modifiability related. The system should be designed to efficiently m
eet

users’

needs. Thus,
communications will have to be kept to a minimum in order to ensure that data is processed quickly.
Furthermore, the user interface will have to be designed to allow users to change the layout of their
home screen and add and remove

frequently used drug regimens. The final driver is the modifiability
of the system. Since this application will be used for quite some time, the architecture will have to
allow developers to easily add, remove, or update system functionality without aff
ecting other modules.


The system as a whole will follow a layered pattern. Certain parts will be able to communicate
with other areas, but all data must flow through connecting layers (and never around them). This will
help to ensure that some of the de
sign constraints are met. In a generalized overview of the
architecture, the User Interface and Web API are the highest layers. These are the only two access
points to and from the system, which will help to ensure data privacy and security. The Web API

will
communicate with the Data Conversion Layer, which contains all the necessary functions for
converting and/or encrypting incoming and outgoing messages to and from external applications. The
User Interface and Data Conversion Layer will be directly l
inked to the Security Layer, which checks
for user authentication and privileges for all data that enters the system and again for all information
that leaves the system. This layer will communicate with the Concurrency layer and the Fault Handler
layer.

The Concurrency layer temporarily holds on to unmodified information in case of some kind of
fault or error. In other words, a copy of raw data is stored here. If an error occurs, the data can be
logged (and examined later for causes). This layer will
also communicate with the Business Logic
layer and redirect data flow as necessary to make another attempt at processing information. This
portion also communicates directly with the Fault Handler layer. The Fault Handler layer
communicates with the Data

Processing / Business Logic layer and the Concurrency layer. If a fault is
detected, it will log the error and pull the information out of the Concurrency layer in order to attempt
to manipulate the data again. The Data Processing / Business Logic layer

is where all data
manipulation occurs. It is directly connected to the Data Layer, which is a PostgreSQL database server
that is used to store all application information, such as patient, drug, doctor, and regimen information.
Also, in order to check s
ystem performance, a service will be added that pings the system in order to
test latency and throughput. The Performance Checker will only communicate directly with the
Business Logic layer.


User Interface
Web API
Security Layer
Data Conversion Layer
Fault Handler Layer
Concurrency Layer
Data Processing (Business Logic) Layer
Data Layer
Performance Checker


ATTRIBUTE DRIVEN DESIGN


Element: System

Candidate Archite
ctural Drivers and Design Concerns:

1.

The system will have to be secure.

a.

How will security be handled? When will it be handled?

2.

The system will have to avoid data corruption.

a.

Will the system use concurrency, different data routes, or both?

3.

The system must

be able to communicate with other, disparate applications.

a.

What method will be used to translate data? How will system interface with other
applications?

4.

The system must be highly available.

a.

What is an acceptable amount of down time?

5.

New users should be
able to learn how to accomplish their goals quickly.

a.

Should the user interface be a simplistic design? Should it be customizable? Should it
learn from common user activities?

6.

The system should be modifiable.

a.

What parts will be modifiable? How will a cas
cade effect be avoided?

7.

The system should perform well.

a.

Should tasks be timed and stopped if they take too long? What will happen to the data?

Design Concepts to Meet Concerns:

1.

Layered

a.

Pros:

i.

Decouples various modules.

ii.

Improves security by only allowing ce
rtain interfaces to actual system data.

iii.

Improves cohesion.

iv.

Increases modifiability without affecting other layers.

v.

Decreases number of lines of communication.

b.

Cons:

i.

Modifiability may affect other parts of a layer, or other layers on the same
“level”.

ii.

Syste
m performance may be affected by traversing too many layers.

2.

Data Flow

a.

Pros:

i.

Clearly delineates between elements that perform transformations and elements
that carry streams of data.

ii.

Shows how data carriers and data transformers are connected to each other
.

iii.

Increases modifiability by allowing developers to create new or edit existing
elements.

b.

Cons:

i.

Errors in logic in a data transformer will propagate throughout the system.

3.

Model
-
View
-
Controller

a.

Pros:

i.

The user interface, input handler, and core functionalit
y have very low coupling.

ii.

Will allow easy user interface changes/additions.

b.

Cons:

i.

The model will not be very cohesive.

ii.

Changes in the model may multiple modules.


Child Elements:

Sub Element: Security Module

Responsibilities:

1.

The system will have to be sec
ure.

a.

Handle user access/authentication.

The Security Module will only be instantiated once. It will sit between all external applications
and all internal processes. Thus, it will intercept messages to and from the user interface as well as the
Web API.

This will address the quality attribute of security by preventing unauthorized users from
send data to or receiving information from the system. It also communicates with the Fault Handler
and the Concurrency Module.


Element: Data Conversion Module

Resp
onsibilities:

1.

The system must be able to communicate with other, disparate applications.

a.

Convert outgoing data to XML.

b.

Convert incoming XML to system
-
specific format.

c.

Encrypt outgoing data when necessary.

The Data Conversion Module will be instantiated onl
y during times when communication with
the Web API is necessary. It will communicate directly with the Web API and the Security Module,
taking in plain text to convert to XML or XML to convert to plain text. This will allow other
applications to send dat
a to the Web API and read information from the system.


Sub Element: Fault Handler

Responsibilities:

1.

The system must be highly available

and perform well
.

a.

Detect Faults.

b.

Document Faults.

c.

Redirect data flow as needed.

The Fault Handler will be instantiated
once per process (incoming or outgoing data). It
communicates with the Security Module, Concurrency Module, and the Data Processing (Business
Logic) Layer. Its job is to watch over the lifecycle of a specific process, which typically involves an
incoming

or outgoing message. It will take in a message and send it to the Business Logic layer. It
also return messages to the Security Layer. If a fault is detected, the Fault Handler will send
notification to the Business Logic layer to reroute the informati
on. If the data becomes corrupted, it
will contact the Concurrency Module for the preliminary data.


Sub Element: Concurrency Module

Responsibilities:

1.

The system should protect against data corruption.

a.

Maintain unprocessed data.

b.

Disseminate data during a
fault.

The Concurrency Module is instantiated once per incoming or outgoing data stream. It
communicates with the Security Module, Fault Handler, and Business Logic Layer.


Sub Element: User Interface

Responsibilities:

1.

New users should be able to learn h
ow to accomplish their goals quickly.

a.

Save user preferences.

b.

Record common user actions.

c.

Display information according to user preferences.

This object is instantiated once per user session. It communicates directly with the Security
Module.


Sub Element:

Performance Checker

Responsibilities:

1.

Maintain system performance.

a.

Send out a “heartbeat” monitor to check for system slowdown or halting.



The Performance Checker is a service that runs in the background. Its main job is to ping the
Business Layer to c
heck the processing time of various pieces of information. If a process appears to
be slowing down, it will tell the Business Layer to consider it a fault, which will cause the Fault
Checker to handle it. If it repeatedly fails, the failure will be logge
d and the transaction will have to be
started over.


Sub Element: Data Object/Layer

Responsibilities:

1.

Perform all saving and retrieval of data from and to persistent storage.



This element communicates solely with the Business Logic Object/Layer. It is o
nly instantiated
once. It attends to its requirements by setting up a database connection and performing all writing and
reading tasks.


Sub Element: Business Logic Object/Layer

Responsibilities:

1.

The system will have to accurately perform calculations in
order to create documents and
notifications.

2.

Perform processing of data, such as calculations.

3.

Create PDF copies of drug request forms.

4.

Send out email notifications to users.



This element will handle all the processing of information before it is sent to

the database or
after it is read from the database. It is only instantiated once, and it communicates with the Data
Object, Performance Checker, Fault Handler, and the Concurrency Module.


Sub Element (to Business Object): Data Processor

Responsibilities
:

1.

Perform calculations on data, such as regimen cost and frequency of treatments based on patient
weight.


.

This element will do any necessary math or information transformations. It will be instantiated
once per Business Object and communicates with the

Document Generator and Notification Generator.


Sub Element (to Business Object): Document Generator

Responsibilities:

1.

Create PDF copies of drug request forms.



This element creates PDFs of drug requests/order forms. They are stored on the server, as a

backup (and as a paper trail). This object communicates with the Data Processor and Notification
Generator. It is only instantiated when a PDF has to be created.


Sub Element (to Business Object): Notification Generator

Responsibilities:

1.

Send out email
notifications to u
sers.



This element creates email notifications for users and administrators. It communicates with the
Document Generator and the Data Processor. It is only instantiated when a notification is needed.


CONCLUSION



The very act of crea
ting architecture documentation for the chemotherapy drug ordering system
caused the original design ideas to change. Creating this document made requirements on all levels
become more apparent, which made it prioritize and meet these needs. Moreover, it

helped to clearly
define what the major requirements of the system are, and how best to meet them. Thus, this system
will be up to user expectations, while ensuring data integrity, system reliability, and application
security.