Software Architecture Documentation for

MW revision 0

Gunther Schadow – Team Lead
CL FLeck – Developer
Chase Crafton – Developer

Table of Contents

1. Introduction
2. Background
3. Functional Requirements
4. Quality Attributes

4.1 – Usability
4.2 – Availability
4.3 – Performance
4.4 – Modifiability
4.5 – Security
4.6 – Testability

5. Patters and tactics
6.Views

6.1 – Modules
6.2 – Components and Connectors
6.3 – Data

7. Framework
8. Acknowledgments
9. References
10. Appedices

Revision History

1/22/08 Chase Crafton

Introduction

The purpose of the MW Software Architecture document is to capture, in detail, both high and low level requirements and to document the changes in those requirements and design layout as the project progresses. Revisions will be captured to detail who revised the document, when the revision occurred, and what revisions were made. Furthermore, this document will serve as a guide to explain the purpose of the product, explain who it will benefit, and to simplify the concepts behind how the product will function.

Key stakeholders will include the following people/groups:
Regenstrief Institute – Medical research group
Gunther Schadow – Product inventor and suprevisor
CJ Fleck – Developer
Chase Crafton – Developer
Doctors and Patients – Users of the system

Background

Introduction to purpose:

Doctors in general prefer to have quick and easy access to all sorts of patient information in electronic form. Currently and in general, there are not really any listings of business products available to Doctors that manage Patient info such as: Medications and Allergies. MW is designed to breach this gap between Doctors and their records to make patient assessments and the prescribing of medication more efficient and user friendly.

Key stakeholder’s and concerns:
MW is financed by Regenstrief Institute. Gunther Schadow being a key stakeholder is concerned with scalability and efficient code.

Existing systems:

MW will be capable of running on any existing system since it is built on Java. MW will require access to a PostgreSQL database in order for it to allow Doctors to access and manage patient records.

Key points of MW Problem Statement:

MW needs to satisfy all potential stakeholders as adequately as possible. This includes the ensuring that MW can run on any system (Windows, Linux, Mac OS, Solaris). The system must remain reliable and be easy to use. Security for the transfer of patient records must be ensured. Finally, the ability to modify and customize the software is very important.

Functional Requirements

The system will be required to communicate with other systems in order to produce acceptable outputs for all concerned. As a breakdown example, the following use case will be detailed in a high level manner, explaining how the interactions will take place.

A Doctor retrieves a patient’s records:
“During a patient visit a Doctor must locate the patient’s records to make logical assessments.”

• This will require the system to reference the patients stored in the database. If a patient exists the records will be returned to the system. If the patient does not exist the system should begin a new patient entry.

“The doctor finds the correct patient entry.”

• Once a patient is found in the system and selected the system will change view and And display the key pieces of information pertaining to the patient.

Quality Attributes

1. Usability
The application following the HL7 patient data standard should efficiently and in a timely manner load requested data from the database.

Source: User
Stimulus: Wants to access a patients’ records
Artifact: User interface
Environment: Deployment
Response: User is able to complete tasks without negative side effects
Response Measure: User is satisfied with the user interface

2. Availability
The system should have minimal amounts of down time if any. This attribute is dependent on the reliability of the other applications such as, the database, medical network, and the local machine.

Source: External or internal to the system
Stimulus: unresponsive computer, netowrk, or database
Artifact: computer stability, server communication, carrier communication
Environment: Systems not operating to designed specification
Response: notify administrator of failing entity for appropriate action
Response Measure: no downtime

3. Performance
The system must be able to handle all requests for patient data issued by the user.

Source: System
Stimulus: User requests patient data
Artifact: Add item function
Environment: Run Time
Response: The requested data is returned and handled appropriately by the system.
Response Measure: In 1 second

4. Modifiability

4.1 The system view will remain consistent from user to user requiring little customization.
4.2 Our additions and modified source code will follow the same coding style as the remainder of the system.
Source: Developer
Stimulus: Developer wishes to add functionality
Artifact: Code
Environment: design time
Response: New code is added and tested without adverse side effects
Response Measure: 12 hours

5. Security

5.1 Users define username and password when they are added to the system.
5.2 None of our additions or changes shall compromise the security of the system already in place.

Source: System
Stimulus: User must log in order to use any of the services
Artifact: Login function
Environment: Run Time
Response: User brought to the patient search view.
Response Measure: patient search view appears.

6. Testability
The production environment will remain separate from the development environment to allow us to test each increment before it is put into production.

Source: Lead Tester
Stimulus: Performs tests on each feature in the development environment
Artifact: Features of the system
Environment: In development environment at the completion of each feature
Response: Tests are run and end with a result of pass or fail
Response Measure: All of the tests must pass to be released into the production environment

Patterns and Tactics

1. Usability
Because of security required for medical record systems, a very robust and secure design is necessary to create and effective and reliable environment. The HL7 standard will allow the system effectively deliver patient data.

2. Availability
The system will ideally become a widely used tool within medical facilities. Therefore, having a reliable system is a must.

3. Performance
Database queries can become cumbersome and inefficient. The design takes advantage of hibernate and a PostgreSQL database to handle all queries and data transmission.

4. Modifiability
Any program that is widely used will change often to make room for improvements. In order to make this flow more smoothly, redundant code will be limited by using object oriented programming. Hopefully the code will remain the same between all users limiting confusion between clients, but that code can and probably would change over time.

5. Security
When dealing with private patient records, good security measures take a high priority before functionality. If the system cannot guarantee safe transactions, then the system cannot afford to produce the feature. Security will then mainly consist of a level of protection including encryption and HL7.

6. Testability
The process of two environments will lead to accurate testing without compromising the current system. Thus, updates will occur in a very short amount of time to comply with our availability standards. It will likewise make for much shorter test periods when features can be isolated and tested individually.