Software Requirements Specification.docx - Modern Software ...

Oregon Institute of Technology

Health Care Protocol TranslatorModern Software Requirements Specification

Version 1.7

[Note: Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]

[To customize automatic fields (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]

[Note: The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system. The Modern SRS is a typical SRS outline for a project using use-case modeling. This artifact consists of a package containing use cases of the use-case model and applicable Supplementary Specifications and other supporting information. For a template of an SRS not using use-case modeling, which captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed), see \program files\Rational\ RequisitePro\Outlines\ rup_srs.dot.]

Many different arrangements of an SRS are possible. Refer to [IEEE93] for further elaboration of these explanations, as well as other options for SRS organization.]

Health Care Protocol Translator Version: 1.6Modern Software Requirements Specification Date: 03/13/2010

Revision HistoryDate Version Description Author

11/18/2009 1.0 Requirements Specifications HIT

11/18/2009 1.1 Business Case HIT

12/06/2009 1.2 User Interface Johnny Su

12/06/2009 1.3 Historical Perspective and Functional Architecture Definitions

Jin Chen

12/06/2009 1.3 Functional Architecture Diagram Dae Young Roh

12/06/2009 1.3 Actor Descriptions Dae Young Roh

02/02/2010 1.4 Requirements and Functional Architecture Johnny Su

02/02/2010 1.4 User Interface Dae Young Roh

02/02/2010 1.4 Physical Architecture Diagram Dae Young Roh

02/02/2010 1.4 Context Diagram Dae Young Roh

02/02/2010 1.4 System Actors Jin Chen

02/16/2010 1.5 Use case model survey Johnny Su

02/28//2010 1.5 Logical and Component models Johnny Su

03/13/2010 1.6 References, Use Case Model Survey, Requirements, Models

Johnny Su

04/25/2010 1.7 User Interface Dae Young Roh

Confidential Oregon Institute of Technology, 09 Page 2


Table of Contents

1. Introduction 3

1.1 Purpose 31.2 Scope 31.3 Definitions, Acronyms and Abbreviations 31.4 References 31.5 Overview 3

2. Overall Description 3

2.1 Business Case 32.2 Assumptions and Dependencies 3

3. Requirements 3

3.1 Functional Requirements 33.1.1 <Functional Requirement One>

3.2 Usability 33.2.1 <Usability Requirement One> 3

3.3 Reliability 33.4 Performance 3

3.4.1 <Performance Requirement One> 33.5 Supportability 3

3.5.1 <Supportability Requirement One> 33.6 Design Constraints 3

3.6.1 <Design Constraint One> 33.7 Online User Documentation and Help System Requirements 33.8 Purchased Components 33.9 Interfaces 3

3.9.1 User Interfaces 33.9.2 Hardware Interfaces 33.9.3 Software Interfaces 33.9.4 Communications Interfaces 3

3.10 Licensing Requirements 33.11 Legal, Copyright and Other Notices 33.12 Applicable Standards 3

4. Use-Case Model Survey 3

4.1.1 Introduction 34.1.2 Survey Description 34.1.3 Use-Case Model Hierarchy 34.1.4 Diagrams of the Use-Case Model 3

4.2 Use-Case Specifications 3

5. System Architecture 3

5.1 Functional Architecture 35.2 Logical Architecture 35.3 Component Architecture 35.4 Physical Architecture 3

Modern Software Requirements Specification



1. IntroductionThis is the introduction of the Health Care Protocol Translator web system. In this section the purpose, scope, definitions, references and overview of the project will be covered.

1.1 Purpose

The purpose of our project is to build a middleware system that will create a bridge between systems of different protocols, such as HL7 and DICOM. The system will be implemented through a web based interface that will allow users to search and synchronize information from an HIS system or PACS system to another HIS system or PACS system. This will simplify the need of the user to manually input patient information from one system to another. The system will also provide the feature of creating profiles that will keep track of user search and synchronization history as well as the source and target systems being used.

1.2 Scope

The system will be used by institutions in need of a system that will allow them to synchronize information from a HIS system or PACS system to another HIS system or PACS system. Our system will be also made available to third world countries that are in need of an affordable system that will allow them to use open source system and exchange information with other open source or commercial systems. Our system will be open source and will be available through the internet and can be access by anyone throughout the world.

1.3 Definitions, Acronyms and Abbreviations

This section defines definitions, acronyms and abbreviations we used throughout our system.

1.3.1 Systems

HCPT (Health Care Protocol Translator) - the system that we’re building.

HIS (Health Information Systems) –“a comprehensive, integrated information system designed to manage the administrative, financial and clinical aspects of a hospital. This encompasses paper-based information processing as well as data processing machines.” (Wikipedia 2009).

PACS (Picture Archiving and Communication Systems) – “computers, commonly servers, dedicated to the storage, retrieval, distribution and presentation of images.”(Wikipedia 2009).

HL7 (Health Level Seven) - “Standards for electronic interchange of clinical, financial, and administrative information among health care oriented computer systems.” (www.hl7.org).

DICOM (Digital Imaging and Communications in Medicine) –“standard for handling, storing, printing, and transmitting information in medical imaging. It includes a file format definition and a network communications protocol.” (Wikipedia 2009).

Middleware – A computer software that connects multiple computer applications.

1.3.2 ToolsOpenMRS – an open source HIS system that uses the HL7 standard.

MyFreePACS – an open source PACS system that uses the DICOM standard.

C#- a object oriented program language.

ASP.NET – a web application framework developed by Microsoft to help programmers build



dynamic web sites, web applications and web services.

Microsoft SQL 2005 Express Edition – “SQL Server 2005 Express Edition is the next version of MSDE and is a free, easy-to-use, lightweight, and embeddable version of SQL Server 2005.” (Microsoft 2009).

MySQL – an open source relational database management system.

Java – a technology developed by Sun Microsystems for java language software.

Apache HTTP Server – “an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT.” (apache.org 2009).

MDCM – “a .Net class library created with the goal of implementing large parts of the DICOM standard.” (code.google.com/p/mdcm/ 2009)

DCMTK–“a collection of libraries and applications implementing large parts the DICOM standard.” (dicom.offis.de 2009)

DICOM Manager –a software that allows you to open and review DICOM files.

1.4 References

MyFreePACShttp://pacssoft.com/index.php?content=myfreepacsOpen MRS http://openmrs.org/wiki/OpenMRSDepartment of Defense’s HIS http://radiographics.rsna.org/content/20/3/883.fullClearCanvas DICOM Library http://www.clearcanvas.ca/dnn/Home/tabid/37/Default.aspx

*Credit to P.I.L.L. (team from last year)dcm4che http://www.dcm4che.org/confluence/display/ee2/HomeDCMTK – DICOM Toolkit http://dicom.offis.de/dcmtk.php.en

1.5 Overview

The following section is a formal description of the HCPT system. System requirements, use cases, system architecture, transition models, actor models, class models and UI prototypes will be discussed in the following sections. By the end of this document one should have a detailed understanding of the system.

2. Overall DescriptionThe purpose of this application is to create a virtual bridge between HL7 and DICOM messaging standards. The application will gather input from the user and query intersected patient information from HL7 and DICOM standard. The system will effectively replicate a DICOM and HL7 system in order to request and query information from HL7 and DICOM standard. The system will be implemented through a web based user interface and will be available to health care professions throughout the world. The web based system will allow users to search and synchronize intersected patient information from HL7 and DICOM standard to another HL7 and/or DICOM standard system. Users will allow registering for an account on the website which will be review by an administrator to check for valid information. The user profile will be store in our database. After the verification, the user may loginto our website and search for patient information. If the information matches any data from the selected protocol, a list of matching patient will be listed. The user may select from the list of patients and synchronize selected patient information to the desired protocol. The website is only for the purpose of search and exchanging of information, changes will not be allowed. The context diagram of the system is shown in Figure 2.1. The diagram shows the various users that will be using our system.


http://dicom.offis.de/dcmtk.php.en

http://www.dcm4che.org/confluence/display/ee2/Home

http://www.clearcanvas.ca/dnn/Home/tabid/37/Default.aspx

http://radiographics.rsna.org/content/20/3/883.full

http://openmrs.org/wiki/OpenMRS

http://pacssoft.com/index.php?content=myfreepacs


2.1 Actors

Actors are the users of the system. Actors who use our system includestudents, administrators, insurance providers, and health care providers.

Health Care Providers–Health care providers are who provides health services to patients, such as doctors, nurses, etc. They would have full permission, which includes many functions in the system such as searching and synchronizing information with full permission. They are the main users of the HCPT System. The purpose of the HCPT System is allow people, mainly health care providers, to exchange information between the HIS and PACs systems. Health care providers will benefit from our system because their jobs require them to use the HIS and PACs systems and exchange information between the systems.

Students– Students use the system for educational purpose in an institution. They are mainly health major students and this system would allow them to exchange information between the HIS and PACs systems as they are learning about HIS and PACs systems. They would have permissions under control of instructors. So, depending on instructor and their permission on the HIS and PACS systems, their permissions would be different.

Administrators–Administrators of the HCPT system has few jobs: assisting other users, confirming user registration, updating the system, managing user profiles, and configuring system settings. They would not have any right to search patients’ information because they do not have permission to access any “real” servers. Administrator’s use of the HCPT system is different from other users. They use the system mainly for testing purposes.

Insurance Providers–Insurance providers are insurance agents who are required to inspect and verify patients’ information. They use the HCPT system to inspect and verify patients’ information. They would have permission to search and observe patients’ information, but they would not have any rights to synchronize data between the systems. The HCPT system allows them to browse for patients’ information in both HIS and PACs systems.



Figure 2.1 – Context DiagramThese are the various users that will be using our system.

2.2 Business Case

HL7 was developed in 1987 for the purpose of creating a standard for hospital information systems (HIS). HL7 standards for Health Level 7 in which it represents the seventh application layer of the ISO OSI Reference model where HL7 focus on. The current standard is the HL7 3.0, developed in 1995 and was aim to support all healthcare overflow. DICOM stands for Digital Imaging and Communications in Medicine is a health standard for handling medical images. DICOM is the third version of the standard developed by American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA) in 1993 and the current version of DICOM is DICOM 3.0. HL7 and DICOM were created as medical standards but they were developed for different purposes. DICOM was developed for the reason to handle medical images while the reason of development for HL7 was exchange and manage clinical and administrative electronic health data. Originally, information was being entered manually from on system to other. Because of human errors and other factors, many problems such as wrong information occurred. One of the solutions to these problems is to create a virtual bridge where information can be exchange automatically. Throughout the years, different commercial programs have offer solution to this.

This system found its idea for the reason to provide an alternative solution to commercial systems that can be very expensive. We want to create an open source system that provides the functionality to exchange information between HL7 and DICOM protocols. The original approach to exchange information was to enter all information manually from one system to another. This approach created many problems in the system, such as: loss of the patient information, different patient information overlapped, and loss of medical images for patients. Our system will eliminate these problems because the exchanging of



information between the two different systems will be in three simple steps: search, translate, and synchronize.

Through our research for similar competing systems, we found that the Department of Defense also developed a system that maps the dissimilar protocols and translates the data from one system to another. The system is currently being use at 20 military facilities throughout the world. The system is like our system that would simplify the need to make manual entry of patient information from one system to the other, which reduce mistakes that could be made by the user.

Also another competing system was found by P.I.L.L. (team from last year), called dcm4che project and is located at dcm4che.org. The project is a collection of open source tools and utilities for HL7 and DICOM systems.

Both competing systems will be a great reference to us as to how we’re building our system. Our system’s greatest improvement from previous systems is that our system is going to be able to be accessed around the world through our HCPT website. The purpose and functionality of our system will still be the same with the other systems.

2.3 Assumptions and Dependencies

[This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this Modern SRS may be based.]

3. RequirementsHere we discuss our system requirements. This includes functional and non-functional requirements.

High – Key ComponentsMedium- Advance System UtilityLow- Extra Features

3.1 Functionality

This section describes the functional requirements for the HCPT system. For a visual representation of the requirements in relation to each other, please refer to Figure 5.1.1.

System Interface

3.1.1 The system shall allow users to create a user account.

This will allow registered users to access the HCPT website resources.

3.1.2 The system shall allow users to log in to the website.

This will allow users to go to the main page of the HCPT website.

3.1.3 The system shall allow users to log out from the website.

This will allow users to disconnect their account from the HCPT website.

3.1.4 The system shall manage user profiles.

This will allow the HCPT website to store information about the user, such as systems used, patients searched, and among others.



Internal System

3.1.5 The system shall authenticate users with source and target systems.

This will allow the HCPT website to access the source and target systems.

3.1.6 Searching information.

The HCPT system will search the target system for matching patients with information provided.

3.1.6.1 The system shall search patient full name.

3.1.6.2 The system shall search patient ID.

3.1.7 HL7 Protocol

The HCPT system will be able to search for matching patients in HL7 protocol systems with information provided from user, then translated to be able to synchronize to another HL7 protocol system or DICOM protocol system.

3.1.7.1 The system shall post to HL7 protocol system.

The HCPT system will be able to send a HTTP post to the HIS system to search for patients.

3.1.7.2 The system shall search OpenMRS database.

The HCPT system will be able to retrieve a HTTP post message.

3.1.7.3 The system shall format message from OpenMRS database.

The HCPT system will be able to format the retrieved HTTP post message to a data structure.

3.1.7.4 The system shall translate patient information from HL7 protocol system to another HL7 protocol system.

The HCPT system will be able translate patient information from queried information from HL7 protocol system and formatted to be able to synchronize to another HL7 protocol system.

3.1.7.5 The system shall translate patient information from HL7 protocol system to DICOM protocol system.

The HCPT system will be able translate patient information from queried information from HL7 protocol system and formatted to be able to synchronize to a DICOM protocol system.

3.1.7.6 The system shall synchronize patient information from HL7 protocol system to another HL7 protocol system.

The HCPT system will be able synchronize patient information from translated information from HL7 protocol system to another HL7 protocol system.

3.1.7.7 The system shall synchronize patient information from HL7 protocol system to DICOM protocol system.

The HCPT system will be able synchronize patient information from translated information from HL7 protocol system to a DICOM protocol system.

3.1.8 DICOM Protocol

The HCPT system will be able to search for matching patients in DICOM protocol systems with information provided from user, then translated to be able to synchronize to another DICOM protocol system or HL7 protocol system.



3.1.8.1 The system shall echo DICOM protocol system.

The HCPT system will be able echo a DICOM protocol system to test for availability.

3.1.8.2 The system shall send request message to DICOM protocol system.

The HCPT system will be able to send a request for patient information.

3.1.8.3 The system shall retrieve message from DICOM protocol system.

The HCPT system will be able to retrieve the request that was sent to the DICOM protocol system.

3.1.8.4 The system shall query patient from DICOM protocol system.

The HCPT system will be able query patient information from DICOM protocol system.

3.1.8.5 The system shall translate patient information from DICOM protocol system to another DICOM protocol system.

The HCPT system will be able translate patient information from queried information from DICOM protocol system and formatted to be able to synchronize to another DICOM protocol system.

3.1.8.6 The system shall translate patient information from DICOM protocol system to HL7 protocol system.

The HCPT system will be able translate patient information from queried information from DICOM protocol system and formatted to be able to synchronize to a HL7 protocol system.

3.1.8.7 The system shall synchronize patient study from DICOM protocol system to another DICOM protocol system.

The HCPT system will be able synchronize patient image from translated image from DICOM protocol system to another DICOM protocol system.

3.1.8.8 The system shall synchronize patient information from DICOM protocol system to HL7 protocol system.

The HCPT system will be able synchronize patient information from translated information from DICOM protocol system to a HL7 protocol system.

3.1.9 The system shall allow user to select patient from a list of patients.

This will allow the user to select a matching patient for synchronization.

3.1.10 The system shall allow the administrator to set and take out roles from users, and to change other users’ profiles.

This will allow the administrator to give and take out roles from users, and change the stored user information if it is necessary.

3.2 Non-Functions

This section describes the non-functional requirements for the HCPT system.

System Interface

3.2.1 The system shall be running in any system platform.

The HCPT system will run on any platforms that support HIS and PACS systems.



3.2.2 The system shall be a web-based system.

This allows the HCPT system to be easily accessed through the internet from anywhere in the world. Also makes our system be able to be used on any system platform.

Internal System

3.2.3 The system shall use Health Level 7 (HL7) protocols.

This allows the HCPT system to query HL7 protocol information.

3.2.4 The system shall use Digital Imaging and Communication in Medicine (DICOM) protocols.

This allows the HCPT system to query DICOM protocol information.

3.3 Usability

[This section should include all of those requirements that affect usability. Examples:

Specify the required training time for a normal users and power users to become productive at particular operations.

Specify measurable task times for typical tasks, or

Base usability requirements of the new system on other systems that the users know and like.

Specify requirements to conform to common usability standards – e.g., IBM’s CUA standards, or the GUI standards published by Microsoft for Windows 95.]

3.4 Reliability

[Requirements for reliability of the system should be specified here. Suggestions:

Availability – specify % of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations etc.

Mean Time Between Failures (MTBF) – this is usually specified in hours, but it could also be specified in terms of days, months, or years.

Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has failed?

Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems output.

Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs per function-point.

Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a “critical” bug (e.g., complete loss of data, complete inability to use certain parts of the functionality of the system).]

3.4.1.1 <Reliability Requirement One>

[The requirement description.]

3.5 Performance

[The performance characteristics of the system should be outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name.

Response time for a transaction (average, maximum)

Throughput (e.g., transactions per second)

Capacity (e.g., the number of customers or transactions the system can accommodate)



Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)

Resource utilization: memory, disk, communications, etc.]

3.5.1 <Performance Requirement One>


3.6 Supportability

[This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, maintenance utilities.]

3.6.1 <Supportability Requirement One>


3.7 Design Constraints

[This section should indicate any design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, etc.]

3.7.1 <Design Constraint One>


3.8 Online User Documentation and Help System Requirements

[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, etc.]

3.9 Purchased Components

[This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.]

3.10 Interfaces

The following sections describe the interfaces that our system supports, include user interface, hardware interface, software interface, and communication interface.

3.10.1 User Interfaces

This describes our website interface that users can access and use.

3.10.1.1 Login

The login interface will allow the user to login with their credential; username and password. After logging on, the user will be directed to the home page where the user can search and synchronize patients from different HIS and PACS systems. The following Figure3.10.1 shows our interface for logging in.



Figure 3.10.1.1 – LoginThe Login page is for user logging in to access our home page

3.10.1.2Create User Account

If the user is new they can create a user account with a username, password, email, institution that they work for and their institution identification. After creating the user account, the user will have to be approved by our administrators to determine the validity of the information before they can use the system resource.The following Figure3.10.1.2 shows our interface for creating an account.



Figure 3.10.1.2 –Create AccountThe Create Account page is for creating user account

3.10.1.3 Not Logged In

If a user try to access the system illegally by entering the address of search page, the system will block the user by directing to the Not Logged On page. In the page, the user will have no choice but to open the Login page. This UI will increase the security system of the program. The following Figure 3.10.1.3 and Figure 3.10.1.4shows one example of illegal access and the Not Logged In page, respectively.



Figure 3.10.1.3 – Example of Illegal AccessUser might try to access the Search page illegally.



Figure 3.10.1.4 – Not Logged InThe Not Logged In page is for blocking illegal access.

3.10.1.4 Home

The home interface is the page where the user will be directed to when they login. On the interface, the user will be able to choose their source system and target system. The source system being the system that they wanted the patient information to be synchronize to and the target system being the system that the user will acquire the patient information from. After selecting the source and target system, the user will have the option of searching for the patient’s name, id, and birth date. After searching for the patient, a list of matching patients will be display to the right. Then the user can select a matching patient, where the patient information will also be reflected over to the text boxes of where the user can search. Then the user can choose to synchronize the selected patient or clear the text boxes to search again. The following Figure 3.10.1.5shows the interface for the system’s home page.



Figure 3.10.1.5 – Home PageThe home page is for user to search and synchronize patient information.

3.10.1.5 Manage ProfileThe Manage Profile interface will allow user to update user information including e-mail, security question, security answer, password, PACS profiles, and HIS profiles. The following Figure3.10.6, Figure 3.10.7, Figure 3.10.8, Figure 3.10.9, and Figure 3.10.10 show our interface for logging in.



Figure 3.10.1.6 – Manage Profile PageThe Manage Profile page is to update user information.



Figure 3.10.1.7 – Manage Profile Page using User Profile panelThe User Profile panel is to update user’s email, security question, and security answer.



Figure 3.10.1.8 – Manage Profile Page using Change Password panelThe User Profile panel is to update user’s password.



Figure 3.10.1.9 – Manage Profile Page using PACS Profile panelThe User Profile panel is to update PACS profiles.



Figure 3.10.1.10 – Manage Profile Page using HIS Profile panelThe User Profile panel is to update HIS profiles.

3.10.1.6Unauthorized

If a user who has no administrator role tries to access the Administration page, the system will block the user from changing other users’ profiles by redirecting to the Unauthorized page. The following Figure 3.10.1.11shows the interface for the system’s home page.



Figure 3.10.1.11 – Unauthorized PageThe Unauthorized page is for blocking a user who does not have administrator role.

3.10.2 Hardware Interfaces

[This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc.]

3.10.3 Software Interfaces

[This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this SRS, but with which this software application must interact.]

3.10.4 Communications Interfaces

[Describe any communications interfaces to other systems or devices such as local area networks, remote serial devices, etc.]



3.11 Licensing Requirements

[Defines any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software.]

3.12 Legal, Copyright and Other Notices

[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice, word mark, trademark, or logo compliance issues for the software.]

3.13 Applicable Standards

[This section describes by reference any applicable standards, (and the specific sections of any such standards that apply to the system being described). For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, etc.]

4. Use-Case Model SurveyThe use case model survey below shows how various users use and affect the system of the HCPT system.

4.1 Introduction

Our system will be used by four different types of Users; Health Care Providers, Insurance Providers, Students, and Administrators. The following sections will introduce their relationship with the system, and is shown in Figure 4.4.1.

4.2 Survey Description

The use cases are separated into three different functional groupings; Authentications, Settings, Functions. Under each functional grouping, dependencies of use cases and relationship with actors will be explained. Each use case is prioritize by color; High – Key Components, Medium- Advance System Utility, Low- Extra Features.

4.3 Use-Case Model Hierarchy

Each of the following functional groups lists the actors, use cases and their dependencies.

4.3.1 Authentications Features

User verification features to insure access to site features.

Actors:Health Care ProvidersInsurance ProvidersStudentsAdministrators

Use Cases:Use Case Specification 1.0 - User Registration

- Allows user to register for an account to access the online system.

Use Case Specification 2.0 - User Login- Allows user to login to HCPT website and access site features.

Use Case Specification 3.0 - User Logout- Allows user to terminate session after logging in.



Dependency:Use Case Specification 2.0 User Login depends on Use Case Specification 1.0 - User Registration.Use Case Specification 3.0 - User Logout depends on Use Case Specification 2.0 - User Login.

4.3.2 User Settings

User configuration settings to user information and PACS and HIS systems.


Use Cases:Use Case Specification 4.0 –Manager Profile

- Allows user to update personal information and store PACS and HIS systems information.

Use Case Specification 5.0 – Administration- Allows administrators to give out roles to other users.

Dependency:Use Case Specification 4.0 -Manager Profile depends on Use Case Specification 2.0 - User Login.Use Case Specification 5.0 –Administration depends on Use Case Specification 2.0 – User Login.

4.3.3 Internal Functions

Functions to search, select, and synchronize patients.


Use Cases:Use Case Specification 6.1 - DICOM Patient Search

- Allows user to search in a PACS system.

Use Case Specification 6.2 - HL7 Patient Search- Allows user to search in a HIS system.

Use Case Specification 7.0 - Select Patient- Allows user to select a patient from a list of returned searched results.

Use Case Specification 8.1 – DICOM to DICOM Patient Synchronization- Allows user to synchronize a patient from a PACS system to another PACS

system.

Use Case Specification 8.2 – DICOM to HL7 Patient Synchronization- Allows user to synchronize a patient from a PACS system to a HIS system.



Use Case Specification 8.3 – HL7 to HL7 Patient Synchronization- Allows user to synchronize a patient from a HIS system to another HIS

system.

Use Case Specification 8.4 – HL7 to DICOM Patient Synchronization- Allows user to synchronize a patient from a HIS system to a PACS system.

Dependency:Use Case Specification 6.1 and 6.2 - Patient Search depends on Use Case Specification 2.0 - User Login.Use Case Specification 7.0 - Select Patient depends on Use Case Specification 6.1 and 6.2 -Patient Search.Use Case Specification 8.1 – 8.4 - Patient Synchronization depends on Use Case Specification 7.0 – Select Patient.

4.4 Diagrams of the Use-Case Model

Figure 4.4.1is our Use-Case Model. It is a combination of our use cases along with the user (actor) who will be using those use cases. We have a few different actors such as health care provider, insurance provider, student, and administrator. All of the actors have the same privileges except for administrators. Administrators are the only that will be involved with the administration use case as it is shown in Figure 4.4.1



pkg Use Case Model

User

(from Actors)

Administrator

(from Actors)Health Care Prov ider

(from Actors)

Student

(from Actors)

Insurance Prov ider

(from Actors)

(from UC Athentications)

User Registration


User Login

(from UC Settings)

Administration

(from UC Settings)

Manage Profile

(from UC Functions)

Select Patient


User Logout

(from UC Functions)

DICOM Search

(from UC Functions)

HL7 Search

(from UC Functions)

DICOM to DICOM Patient

Synchronization

(from UC Functions)

HL7 to HL7 Patient Synchronization

(from UC Functions)

DICOM to HL7 Patient Synchronization

(from UC Functions)

HL7 to DICOM Patient Synchronization

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»



Figure 4.4.1 – User-Case ModelThis model illustrates the actions of the user and the flow of actions by the users.

4.5 Use-Case Specifications

The following use cases are documented externally.

Use Case Specification 1.0 - User Registration Use Case Specification 2.0 - User Login Use Case Specification 3.0 - User Logout Use Case Specification 4.0 –Manager Profile Use Case Specification 5.0 - Administration Use Case Specification 6.1 - Patient Search Use Case Specification 6.2 - Patient Search Use Case Specification 7.0 - Select Patient Use Case Specification 8.1 - DICOM to DICOM Patient Synchronization Use Case Specification 8.2 - DICOM to HL7 Patient Synchronization Use Case Specification 8.3 - HL7 to HL7 Patient Synchronization Use Case Specification 8.4 - HL7 to DICOM Patient Synchronization

5. System Architecture [This section contains description of the system architecture. The system architecture should contain a description of the logical organization along with the reasoning behind the overall organization.]

5.1 Functional Architecture

The functional structure of the system is shown in Figure 5.1.1. Figure 5.1.1 shows all of our use of functional groupings and the relationships between these groupings. The User Control is the front end of our system and allows users to register for account, log in to main system, log out of main system, search for patients, and select patients. The Search is depended on User Control and will search for patients in either DICOM protocol systems or HL7 protocol systems. Translate will be depended on Search for information to translate to both DICOM and HL7 protocol formats. Synchronize then will take the translated information and synchronize to DICOM and HL7 protocol systems.



pkg Requirements Model

Translate

+ 3.1.7.4 Translate HL7 Patient to HL7

+ 3.1.7.5 Translate HL7 Patient to DICOM

+ 3.1.8.6 Translate DICOM Patient to DICOM

+ 3.1.8.7 Translate DICOM Patient to HL7

Synchronize

+ 3.1.7.6 Synchronize HL7 Patient to HL7

+ 3.1.7.7 Synchronize HL7 Patient to DICOM

+ 3.1.8.10 Synchronize DICOM Patient to HL7

+ 3.1.8.9 Synchronize DICOM Patient to DICOM

HL7 Protocol

+ 3.1.7.1 Post

+ 3.1.7.2 Retrieve Message

+ 3.1.7.3 Format Message

User Control

+ 3.1.1 Register

+ 3.1.2 User Login

+ 3.1.3 User Logout

+ 3.1.4 Manage Profile

+ 3.1.9 Select Patient

DICOM Protocol

+ 3.1.8.1 Echo

+ 3.1.8.2 Send Patient Request

+ 3.1.8.3 Retrieve Message

+ 3.1.8.4 Query Information

Search

+ 3.1.6.1 Search Patient Full Name

+ 3.1.6.2 Search Patient Birth Date

+ 3.1.6.3 Search Patient ID

Figure 5.1.1 – Functional Architecture ModelThese are the dependencies between the various functional requirement groups.

5.2 Logical Architecture

The logical architecture is separated into 3-tiers; User Interface (UI), Logical (Business Object Logic (BOL) and Business Object (BO)), and Persistence. The model is shown in Figure 5.2.1. The UI is dependent on BOL to interface with the internal functionality. Then there is the interdependency between BOL and BO because BOL creates the BO and sends the data to the UI. Then the BOL is dependent on Persistence to store the data that is created with the BO. The arrows in Figure 5.2.1 shows each dependency describe above.



pkg Logical Architecture

Persistence

+ PatientList

+ UserList

+ UserRoleList

BOL

+ AbstractSearchMgr

+ AbstractSynchronizeMgr

+ AbstractTranslateMgr

+ DICOMSearchMgr

+ DICOMSynchronizeMgr

+ DICOMTranslateMgr

+ DisplayPatientInfo

+ FindBaseScu

+ HL7MessageParse

+ HL7SearchMgr

+ HL7SynchronizeMgr

+ HL7TranslateMgr

+ Http_Post

+ SearchMgrFactory

+ SearchMgrProxy

+ SynchronizeMgrFactory

+ SynchronizeMgrProxy

+ TranslateMgrFactory

+ TranslateMgrProxy

+ UserRegister

+ UserRegistration

+ UserSecurityFactory

+ IDisplayPatientInfo

+ ISearchMgr

+ ISearchMgrProxy

+ ISynchronizeMgr

+ ISynchronizeMgrProxy

+ ITranslateMgrProxy

+ ITranslateMrg

+ IUserRegistration

+ IUserSecurityFactory

UI

+ LoginUI

+ ManageUI

+ RegisterUI

+ SearchUI

BO

+ Patient

+ User

+ UserRole

«use»

«use»

«use»

«use»

Figure 5.2.1 – Logical Architecture ModelThese are the dependencies between our 3-tier architecture.

5.3 Component Architecture

The component architecture model shown in Figure 5.3.1 shows the system’s exposed interfaces and the functional group that uses them. The only exposed interface in our system is in the Business Object Logic (BOL) group and it’s used by User Interface (UI) group. Each interface is a internal function of the system and can be built into a dll. The interfaces in the dll can then be use replicate a system similar to the HCPT system.



cmp Component Model

BOL

ISearchMgrProxy

ITranslateMgrProxy

ISynchronizeMgrProxyIUserRegistration

IUserSecurityFactory

IDisplayPatientInfo

BO

PERS

ISearchMgrProxy

ITranslateMgrProxy

ISynchronizeMgrProxy

IDisplayPatientInfo


IUserRegistrationUI

ISearchMgrProxy

ITranslateMgrProxy

ISynchronizeMgrProxy

IDisplayPatientInfo


IUserRegistration

«trace»

Figure 5.3.1 – Component Architecture ModelThese are the interfaces of the system and dependencies of the interfaces with the 3-tierarchitecture.

5.4 Physical Architecture

The following physical architecture figure provides system entities at a physical level, including components related to the system. The web-based user interface will be access via the internet to connect to source and target HIS/PACS systems. To make connection with HIS and PACS servers, the system uses both HL7 and PACS protocols. Once the system is connected to both servers, it can then retrieves patient information from the target system and synchronize patient information back to the source system. Figure 5.4.1 shows our system’s physical architecture.



Figure 5.4.1 - Physical ArchitectureThis figure illustrates the flow of information between physical entities that are required for

operation of the system.


Software Requirements Specification.docx - Modern Software ...

Documents

system architecture35

pacs system

scopethe system

middleware system

affordable system

open source system

help system requirements33

system actorsjin chen