Software Design Description Report 29.12.2013 Leblebi Hüseyin Alper ÇINAR Feyza YILMAZ
Özlem ÇÖKÜK
Hazal MOĞULTAY
Preface
In this document the Software Design Descriptions of Post Marketing Safety Study Tool (PMSST)
Project are explained.
This document is based on IEEE Standards. For this purpose “IEEE Standard for Information
Technology – Systems Design – Software Design Descriptions – IEEE Std 1016™-2009” document was
taken as reference. This software design document involves detailed and complete definitions and
specifications that can guide developers throughout implementation of this software.
In the first chapter of document overview about SDD is provided. In the following chapter definitions
used throughout this document is given. In third chapter conceptual model for software design
descriptions explained. In fourth chapter design descriptions are provided and finally in fifth chapter
all necessary viewpoints that are context, composition, logical, information, patterns use, interface,
interaction, state dynamics and resource viewpoints to develop this project are explained.
Table of contents 1 Overview .......................................................................................................................................... 6
1.1 Scope ....................................................................................................................................... 6
1.2 Purpose .................................................................................................................................... 6
1.3 Intended Audience .................................................................................................................. 6
1.4 References ............................................................................................................................... 6
2 Definitions ....................................................................................................................................... 6
3 Conceptual model for software design descriptions....................................................................... 6
3.1 Software design in context ...................................................................................................... 7
3.2 Software design descriptions within the life cycle .................................................................. 7
3.2.1 Influences on SDD preparation ....................................................................................... 7
3.2.2 Influences on software life cycle products ...................................................................... 7
3.2.3 Design verification and design role in validation ............................................................ 7
4 Design description information content ......................................................................................... 8
4.1 Introduction ............................................................................................................................. 8
4.2 SDD identification .................................................................................................................... 8
4.3 Design stakeholders and their concerns ................................................................................. 8
4.4 Design views ............................................................................................................................ 8
4.5 Design viewpoints ................................................................................................................... 8
4.5.1 Context Viewpoint: .......................................................................................................... 9
4.5.2 Composition Viewpoint ................................................................................................... 9
4.5.3 Logical Viewpoint ............................................................................................................ 9
4.5.4 Information Viewpoint .................................................................................................... 9
4.5.5 Patterns use viewpoint .................................................................................................... 9
4.5.6 Interface Viewpoint ......................................................................................................... 9
4.5.7 Interaction Viewpoint ...................................................................................................... 9
4.5.8 State Dynamics Viewpoint ............................................................................................... 9
4.5.9 Resource Viewpoint ......................................................................................................... 9
4.6 Design elements ...................................................................................................................... 9
4.7 Design overlays ........................................................................................................................ 9
4.8 Design rationale ..................................................................................................................... 10
4.9 Design languages ................................................................................................................... 10
5 Design viewpoints ......................................................................................................................... 10
5.1 Introduction ........................................................................................................................... 10
5.2 Context viewpoint ................................................................................................................. 10
5.2.1 Authentication ............................................................................................................... 11
5.2.2 Eligibility Criteria ............................................................................................................ 13
5.2.3 Data Selection ................................................................................................................ 16
5.3 Composition viewpoint ......................................................................................................... 18
5.3.1 Internals of PMMST ....................................................................................................... 19
5.3.2 Externals o PMSST ......................................................................................................... 19
5.4 Logical Viewpoint .................................................................................................................. 20
5.4.1 Class relations ................................................................................................................ 21
5.4.2 EligibilityCriteria ............................................................................................................ 22
5.4.3 CriteriaGroup ................................................................................................................. 22
5.4.4 GroupItem ..................................................................................................................... 22
5.4.5 Criterion ......................................................................................................................... 22
5.4.6 ClinicalStatement .......................................................................................................... 22
5.4.7 MedicationCriterion ...................................................................................................... 22
5.4.8 MedicationInformationModel ....................................................................................... 23
5.4.9 ConditionCriterion ......................................................................................................... 23
5.4.10 TemporalConstraintModel ............................................................................................ 23
5.4.11 CodeModel .................................................................................................................... 23
5.4.12 IvlTSModel ..................................................................................................................... 23
5.4.13 PQModel ........................................................................................................................ 23
5.4.14 IvlPQModel .................................................................................................................... 24
5.4.15 DataSelection................................................................................................................. 24
5.4.16 DataTree ........................................................................................................................ 24
5.4.17 DataElement .................................................................................................................. 24
5.4.18 Variable .......................................................................................................................... 25
5.4.19 Value .............................................................................................................................. 25
5.4.20 Question ........................................................................................................................ 25
5.4.21 Date Variable ................................................................................................................. 25
5.4.22 Numeric Variable ........................................................................................................... 25
5.4.23 DateValue ...................................................................................................................... 25
5.4.24 NumericValue ................................................................................................................ 25
5.4.25 DateQuestion................................................................................................................. 25
5.4.26 NumericQuestion .......................................................................................................... 25
5.4.27 Result ............................................................................................................................. 26
5.5 Information Viewpoint .......................................................................................................... 26
5.5.1 Authentication ............................................................................................................... 26
5.5.2 Eligibility Criteria ............................................................................................................ 26
5.5.3 Data Selection ................................................................................................................ 27
5.6 Patterns use viewpoint .......................................................................................................... 28
5.6.1 Model View Controller Pattern ..................................................................................... 28
5.6.2 Singleton Pattern ........................................................................................................... 28
5.7 Interface viewpoint ............................................................................................................... 28
5.7.1 Login / Logout Page ....................................................................................................... 29
5.7.2 Eligibility Criteria Page ................................................................................................... 29
5.7.3 Data Selection Page ....................................................................................................... 30
5.7.4 Result Page .................................................................................................................... 30
5.8 Interaction viewpoint ............................................................................................................ 31
5.8.1 Authentication ............................................................................................................... 31
5.8.2 Eligibility Criteria ............................................................................................................ 34
5.8.3 Data Selection ................................................................................................................ 38
5.8.4 Result ............................................................................................................................. 41
5.9 State Dynamics Viewpoint ..................................................................................................... 42
5.10 Resource viewpoint ............................................................................................................... 42
5.10.1 Backbone ....................................................................................................................... 42
5.10.2 Backbone-Relational ...................................................................................................... 43
5.10.3 Backbone Marionette .................................................................................................... 43
5.10.4 jQuery ............................................................................................................................ 43
5.10.5 Bootstrap ....................................................................................................................... 43
5.10.6 Require JS ...................................................................................................................... 43
5.10.7 Underscore .................................................................................................................... 43
1 Overview In this document we describe the design details of Post Marketing Safety Study Tool (PMSST). In
second chapter we gave definitions that we used in this document. Then in next chapter conceptual
model for software design description is provided. In the following chapter design descriptions are
given in details. Lastly in chapter 5 the 9 viewpoints that are associated with our project explained in
details with diagrams.
1.1 Scope The scope of this document is giving detailed design description about the software that will be
developed. Since SDD will be the primary reference for code development, it includes all necessary
information about the project. We explained all development states by dividing them into viewpoints
in order to provide quick reference to related functionality.
1.2 Purpose This document aims to describe the design of the project of the group number 25 named Leblebi
about Post Marketing Safety Study. It describes the design descriptions of required product features,
constraints and modules. It provides a complete reference for development of software.
1.3 Intended Audience This Software Design Description document is intended for:
- Developers can use this document in order to understand the software easily and in this way
they can easily improve the features or add new functionalities to the system.
- Testers can use this document in order to find some bugs for their testing strategy.
Generally, bugs are easy to find by using software requirements document.
1.4 References Project Proposal Document of PMSST, 2013
Software Requirement Specification of PMSST, 2013
IEEE. IEEE Std 1016™-2009. IEEE Standard for Information Technology—Systems Design—
Software Design . Software & Systems Engineering Standards Committee of the IEEE
Computer Society, 2009.
2 Definitions
PMSST Post Marketing Safety Study Tool
ADE Adverse Drug Events
EHR Electronic Health Record
CHF Congestive Heart Failure
User Safety analysts, hospitals, pharmacists etc.
MDR Metadata Repository
SILDS Semantic Interoperability Layer Data Service
3 Conceptual model for software design descriptions This section gives a conceptual model for SDD to give the basic knowledge needed to understand the
software.
3.1 Software design in context As explained in the SRS targets of this project are health professionals. We will try to give the most
accurate result in a most feasible time.
For this purpose we will create this software in an object oriented model and we will use different
libraries to make sure everything is calculated properly and fast. These libraries are explained later.
This software can be extended to solve many different health issues, but at the moment we will
focus on the database operations according to the users choices and the statistical examination of
the results.
3.2 Software design descriptions within the life cycle This software will be created following the IEEE standards. The main milestones of this project are
requirements analysis, design description analysis, implementation and finally verification and
validation.
3.2.1 Influences on SDD preparation
SRS document is the guideline for design process of this software. In this document we considered
every functional and non-functional requirement that were covered in the SRS. Given specifications
and the possible new demands of the user that were not explained in the SRS will specify the design
process of this project.
3.2.2 Influences on software life cycle products
First of all user interfaces should be designed. Before connecting to the databases user interfaces and
statistical calculations should be demonstrated with a sample data taken from the database. With
this approach user can have an idea about the final version of this product.
Moreover, SDD document will lead us all the way through the project. According to this document or
the first phase, some specifications may be added or removed from the software requirements. With
this approach, requirements of the user can be met exactly before starting to the test phase.
3.2.3 Design verification and design role in validation
Verification is the process that we will test the software whether it satisfies all the requirements. In
this process SRS and SDD documents will be our guidelines. We will check whether all the functional
and non-functional properties of the final product, are met in the requirements of these documents.
Moreover, we will check whether the viewpoints that are explained in section 5 are implemented
correctly.
Validation is the stage where the user decides if the product is consistent with the main purpose.
This software is created to be able to help safety analysts to investigate the relation between
illnesses and drugs. This system will be validated in terms of its usage within the area. SDD will rise all
the design issues and will be helpful in the validation process.
4 Design description information content
4.1 Introduction Software Design Description of PMSST identifies how this tool will be designed and implemented.
While the design of PMSST is a modular object-oriented structure and practical, qualified interface
will be designed.
The contents are also going to be explained in this section are as follows:
- Identification of the SDD,
- Identified design stakeholders,
- Identified design concerns,
- Selected design viewpoints, each with type definitions of its allowed design elements and
design languages,
- Design views,
- Design overlays,
- Design rationale
4.2 SDD identification Project authorship, organization of the project team and date of the report are given in cover page of
SDD. In the first section an overview of SDD is given. Scope of the SDD report refers to the section
1.1, Purpose of the SDD report refers to section 1.2 and Intended Audience of this document refers
to section 1.3. For design conceptual model for software design descriptions refer to the section 3.
Lastly, for the design viewpoints including context, composition, logical, information, patterns use,
interface, interaction, state dynamics and resource viewpoints refer to the section 5.
4.3 Design stakeholders and their concerns The design stakeholders of PMSST are safety analysts which we call as the user in document. The
design concerns of the users are using this application in order to investigate the relation between
illnesses and drugs and side effects of drugs on patients.
4.4 Design views One of the design concerns is that the extendibility of the project. All of the classes and relations are
designed to make the system as flexible and extendable as possible.
Another concern is that, secure transactions between the servers. All the connections are
encapsulated so that no other process will interrupt the connections.
The design views are governed by the design viewpoints that are explained in chapter 5.
4.5 Design viewpoints This section will be used to give brief outline on the design viewpoints which are used in section 5.
A design viewpoint addresses a different perspective to be focused on to effectively encompass
requirements that have been previously created and to identify the users as to which these
requirements are relevant. There are eleven design viewpoints which have been used to address the
range of the design concerns.
4.5.1 Context Viewpoint:
The context viewpoint depicts services provided by a design subject with reference to an explicit
context. That context is defined by reference to actors that include users and other stakeholders,
which interact with the design subject in its environment. The Context viewpoint provides a “black
box” perspective on the design subject.
4.5.2 Composition Viewpoint
The Composition viewpoint describes the way the design subject is (recursively) structured into
constituent parts and establishes the roles of those parts.
4.5.3 Logical Viewpoint
The purpose of the Logical viewpoint is to elaborate existing and designed types and their
implementations as classes and interfaces with their structural static relationships. This view point
also uses examples of instances of types in outlining design ideas.
4.5.4 Information Viewpoint
The Information viewpoint is applicable when there is a substantial persistent data content expected
with the design subject.
4.5.5 Patterns use viewpoint
This viewpoint addresses design ideas (emergent concepts) as collaboration patterns involving
abstracted roles and connectors.
4.5.6 Interface Viewpoint
The Interface viewpoint provides information designers, programmers, and testers the means to
know how to correctly use the services provided by a design subject. This description includes the
details of external and internal interfaces not provided in the SRS. This viewpoint consists of a set of
interface specifications for each entity.
4.5.7 Interaction Viewpoint
The Interaction viewpoint defines strategies for interaction among entities, regarding why, where,
how, and at what level actions occur.
4.5.8 State Dynamics Viewpoint
Reactive systems and systems whose internal behavior is of interest use this viewpoint.
4.5.9 Resource Viewpoint
The purpose of the Resource viewpoint is to model the characteristics and utilization of resources in
a design subject.
4.6 Design elements The main design elements are entities, attributes and some other member associated with
communication and relations between modules and user of our project. These main design elements
are defined inside the related viewpoints in detail in chapter 5.
4.7 Design overlays Design Overlays usually used to add information to the existing views. This concept will be explained
clearly when necessary in the design viewpoints section.
4.8 Design rationale We choose Object-Oriented approach while designing our project because by this way we will be
able to separate models, views and other functionalities. Moreover, the object oriented design will
help us encapsulating the server connections.
For database design, we choose to create tables as much similar as the classes we used. Therefore,
the communication between databases and our system will be easier and the synchronization
between UI and database will not require any other efforts.
4.9 Design languages In this document Unified Modeling Language(UML) will be used as the modeling language for the
diagrams. The modeling language is used for emphasizing the static structure and dynamic behavior
of the system.
5 Design viewpoints
5.1 Introduction In this chapter, the viewpoints of the PMSST project are explained in detail. The viewpoints
explained, with order, as follows:
Context viewpoint
Composition viewpoint
Logical viewpoint
Information viewpoint
Patterns use viewpoint
Interface viewpoint
Interaction viewpoint
State dynamics viewpoint
Resource viewpoint
5.2 Context viewpoint Post Marketing Safety Study software context viewpoint shows the functions provided by a design.
There are four major parts which are Login/Logout, Eligibility Criteria, Data Selection and Result View
parts in the system. Each part has sub-parts too. The context is defined by the elements that interact
with the software like users:
5.2.1 Authentication
5.2.1.1 Sign Up
Diagram:
Description Part:
When users open the application, firstly meets the login page. In this part, user can sign up before
the login part of the system.
Normal Flow of Events:
1. User opens the web page.
2. Login page occurs on the screen.
3. User presses the “Sign Up” button.
4. User can fill the required information.
5.2.1.2 Login
Diagram:
Description Part:
Thanks to username and password, user can enter the system by login.
Normal Flow of Events:
1. User opens the web page.
2. Login page occurs on the screen.
3. User enters the name.
4. User enters the password.
5. User presses the “Login” button.
5.2.1.3 Logout
Diagram:
Description Part:
This part provides to quit from the system.
Normal Flow of Events:
1. User opens the web page.
2. Login page occurs on the screen.
3. User login to system.
4. User makes the analyses with filters using application.
5. User presses the “Logout” button.
5.2.1.4 Edit User Settings
Diagram:
Description Part:
In this part, user can change the information like name, surname, password and email after
the login part.
Normal Flow of Events:
1. User opens the web page.
2. Login page occurs on the screen.
3. User logins to system.
4. User presses the “Edit User Settings” button.
5. The information belong to user can be changed here.
5.2.2 Eligibility Criteria
5.2.2.1 Add Criterion
Diagram:
Description Part:
Eligibility Criteria page allows user to populate patient health record such as age, diseases,
diseases time, drugs etc. without gathering any private data like name and country. To determine the
patient type, user can choose different medicals and conditions in this part.
Normal Flow of Events:
1. User logins to system.
2. Eligibility Criteria page occurs on the screen.
3. User determine the conditions that restricted by Search concept.
4. User chooses the condition among determined conditions.
5. User also chooses the medicals that patients use.
5.2.2.2 Edit Criterion
Diagram:
Description Part:
To determine the patient type, user chooses different condition. After that, user can change
the type of the condition in this part. For example; at first, user chooses a patients with disease B and
later, change this with disease A.
Normal Flow of Events:
1. User logins to system.
2. Eligibility Criteria page occurs on the screen.
3. User chooses the condition.
4. User changes condition parameters.
5.2.2.3 Edit Constraints
Diagram:
Description Part:
User can give the patient gender, disease time or drug used by patient to condition in order to
filter specifically in this part.
Normal Flow of Events:
1. User logins to system.
2. Eligibility Criteria page occurs on the screen.
3. User chooses the criterion as condition or medical.
4. User changes condition parameters
5. User edits condition with different selected data type.
5.2.2.4 Setting Relations
Diagram:
Description Part:
In this part, user can combine many selected criteria to create different type filter system.
Therefore, user selects one of the relations like And, Or etc.
Normal Flow of Events:
1. User logins to system.
2. Eligibility Criteria page occurs on the screen.
3. User chooses the conditions
4. User chooses another the conditions
5. User determines the relation for 2 conditions.
5.2.2.5 Setting Temporal Relations
Diagram:
Description Part:
With temporal relations, the relations that are selected in previous part can be restricted by
specific data such as age, time and gender. Therefore, the filter system eliminates many criteria
about patients for user.
Normal Flow of Events:
1. User logins to system.
2. Eligibility Criteria page occurs on the screen.
3. User chooses the conditions
4. User determines the relation with a temporal.
5.2.2.6 Search Concept
Diagram:
Description Part:
While user is writing the condition name into related box, all conditions are automatically
checked for to list all the matching conditions.
Normal Flow of Events:
1. User logins to system.
2. Eligibility Criteria page occurs on the screen.
3. User writes the condition into related box.
4. All matching conditions are listed on the screen.
5.2.3 Data Selection
5.2.3.1 Select Object Class
Diagram:
Description Part:
Data Selection page allows user to populate the patient information according to conditions -
patient type- that are determined in Eligibility criteria part. This information includes patient data like
allergy, disease type and time.
Normal Flow of Events:
1. User logins to system.
2. User determines the type of patients in Eligibility Criteria.
3. Then, Data selection page occurs on the screen.
4. User selects new conditions formed according to data in Eligibility Criteria part.
5.2.3.2 Select Data Element
Diagram:
Description Part:
According to selected condition in add condition part, new sub-conditions occur on the screen.
In this part, user can determine very specific conditions to add the filter system.
Normal Flow of Events:
1. Data selection page occurs on the screen.
2. User selects an object class
3. User chooses data element.
5.2.3.3 Variable Assignment
Diagram:
Description Part:
In this part, user can redefine an object class or data element. User makes this by giving a new
name to selected object class. Actually, user creates a condition object with this definition. The
results are also shown with this variable name. This method is also very helpful when user wants to
compare and combine two nested condition lists. It just gives a simple name.
Normal Flow of Events:
1. Data selection page occurs on the screen.
2. User selects object class
3. User chooses data element and gives it a name.
5.2.3.4 Value Assignment
Diagram:
Description Part:
In this part, user defines the information of patients like age, gender and so on to make explicit
selection.
Normal Flow of Events:
1. Data selection page occurs on the screen.
2. User selects object class
3. User chooses data element and gives it a name.
4. User gives patient information.
5.2.3.5 Query Assignment
Diagram:
Description Part:
According to result of Value assignment part, user can determine what kinds of information
about patient are wanted with this selection.
Normal Flow of Events:
1. Data selection page occurs on the screen.
2. User selects object class
3. User chooses data element and gives it a name.
4. User gives patient information.
5. User selects what kinds of information he/she wants from system to filter.
5.3 Composition viewpoint In this section, the modules of the PMSST and the other systems that the PMSST interacts with are
described.
5.3.1 Internals of PMMST
Internally, PMSST have 4 main packages. These packages are described in the following component
diagram.
5.3.1.1 Database
Database module helps to manage databases. The PMMST keeps the user information and their
selections in EligibilityCriteria and DataSelection modules in databases. All of the database modules
are singletons to keep the database management safe and easy.
5.3.1.2 Core
This package contains core classes of PMSST. All of the models used in PMMST are kept in this
module. Moreover, this package keeps the classes to manage authentication, eligibility criteria and
data selections. Lastly, results are prepared in this module.
5.3.1.3 Web
Web package contains a REST API that interacts with Core package. This package is a bridge between
UI and Core packages.
5.3.1.4 UI
UI package contains all of the views and controllers to define a user interface. The pattern used in
this module is MVC. This package is directly interacted with the user.
5.3.2 Externals o PMSST
PMSST interacts with 3 other servers. These servers are described in the following deployment
diagram.
5.3.2.1 Semantic Metadata Repository (MDR)
Semantic MDR involves the PMSST in two operations. First, the PMSST will take the information of
the data elements which the user may select. The user will be able to select from these data
elements. Also, the PMSST server keeps the information that how a data element can be retrieved
from a patient history. When preparing the results, PMSST will interact with Semantic MDR to get the
extraction specifications of the data elements that the user is selected in data selection page.
5.3.2.2 Terminology Server
This server keeps the coded data for different code systems. It has a rest API that allows searching
across coded values. The PMSST will connect this server whenever a coded value is needed.
5.3.2.3 Semantic Interoperability Layer Data Server (SIL-DS)
This server keeps the patient history. It retrieves the histories from databases of different hospitals.
It has a REST API that accepts an eligibility criteria and returns eligible patients.
5.4 Logical Viewpoint In this section, the classes used in the project and their relations are explained in details. Firstly, a
complete class diagram containing all classes and their relations are given. Then, each of the classes
and their methods and fields are explained in detail.
5.4.1 Class relations
5.4.2 EligibilityCriteria
EligibilityCriteria is used to define the population of the patients that the user wants to work with. In
other words, the user may select the common criteria for the patients.
Method/Field Definition
List<CriteriaGroup>inclusionCriteria The criteria list that the user wants the patients to have.
List<CriteriaGroup>exclusionCriteria The criteria list that the user wants the patients not to have.
void addInclusionCriteria() Adds a new inclusion criteria.
void addExclusionCriteria() Add a new exclusion criteria.
5.4.3 CriteriaGroup
CriteriaGroup represents a set of criteria that related with each other with logical operators.
Method/Field Definition
Boolean negatiationIndicator Indicates whether the criteria group is negated or not.
CodeModel conjunctionCode Logical operator from a code system.
List<GroupItem>groupItems The group items that the current criteria group is consisted of.
void setConjunctionCode(CodeModel code) Set the logical operator.
void addGroupItem(GroupItem groupItem) Add a new group item.
5.4.4 GroupItem
GroupItem represents whether a single criterion or a criteria group.
Method/Field Definition
CriteriaGroup criteriaGroup CriteriaGroup that the criteria group represents
Criterion criterion A single criterion that the criteria group represents
void setCriterion(Criterion criterion) Sets the group item as a single criterion
void setCriteriaGroup(GroupItemgroupItem) Sets the group item as a criteria group
5.4.5 Criterion
Criterion class represents a clinical statement and its temporal constraint. For example, the user may
define a clinical statement that starts 10 days after the other conditions that are logically related are
occurred.
Method/Field Definition
ClinicalStatement clinicalStatement Clinical statement of the criterion
TemporalConstraintModel temporalConstraint Temporal constraint for the criterion
5.4.6 ClinicalStatement
Clinical statement class is the base class for the criteria. MedicationCriterion and ConditionCriterion
classes are derived from this class.
5.4.7 MedicationCriterion
MedicationCriterion class represents a criterion that related with medications.
Method/Field Definition
MedicationInformationModel medicationInformation
Information about the medication
CodeModel productForm The way that the medication is applied. (e.g. oral)
IvlTSModel medicationStartStop The date interval that the medication is applied.
PQModel dose The dose of the medication.
5.4.8 MedicationInformationModel
MedicationInformationModel contains information about a medication.
Method/Field Definition
CodeModel codedActiveIngredient Active ingredient of the medication.
CodeModel codedProductName Name of the medication.
CodeModel codedBrandName The name of the producer of the medication.
5.4.9 ConditionCriterion
ConditionCriterion class represents a criterion that related with conditions. (e.g. illnesses, allergies,
disabilities etc.)
Method/Field Definition
CodeModel problemCode The code of the problem.
CodeModel problemStatus The code of the status of the problem.
CodeModel problemSeverity The code of the severity of the problem.
IvlTSModel problemDate The time interval that the condition exists.
5.4.10 TemporalConstraintModel
TemporalConstraintModel is a class that represents a temporal constraint. (i.e. defining the sentence
"3 years later" in a standardized way)
Method/Field Definition
PQModel pauseQuantity The quantity of the temporal constraint.
CodeModel type The type of the temporal constraint.
5.4.11 CodeModel
CodeModel represents a value with its code and code system.
Method/Field Definition
String code The code of the value.
String codeSystem The code system that the code belongs to.
String displayName The human readable name of the code.
5.4.12 IvlTSModel
IvlTSModel represents a time interval.
Method/Field Definition
DateTime start The beginning of the time interval.
DateTime end The end of the time interval.
5.4.13 PQModel
PQModel represents a value with its unit.
Method/Field Definition
String unit The unit of the value.
Float value The value of the model.
5.4.14 IvlPQModel
IvlPQModel represents a PQModel interval.
Method/Field Definition
PQModel low The low value of the PQModel interval.
PQModel high The high value of the PQModel interval.
5.4.15 DataSelection
Data selection class is used to specify the type of the data that the user wants to examine.
Method/Field Definition
List<DataTree>dataTrees The list of the selected data.
List<Variable> variables The list of the defined variables.
void addDataTree() Add a new selected data.
void deleteDataTree() Deletes a selected data.
5.4.16 DataTree
Data tree is the list of data elements that the user is selected. The selected data elements are kept in
a tree structure to provide reusability and define sequential data elements.
Method/Field Definition
DataElement current The data element that the user selected.
List<DataTree> children The child data elements which are related with the current data element.
void addDataElement() Adds a data element.
void removeDataElement() Removes a data element.
void updateDataElement() Updates a data element.
5.4.17 DataElement
DataElement is used for specifying the data to be selected. This data element can be set as value or
question. Moreover, a data element can be assigned to a variable.
Method/Field Definition
String name The name of the data element.
String dataType The data type of the data element.
String commonDataElementID The ID of the data element kept in MDR.
String definition The definition of the data element.
String codeSystem The code system that the data element is coded.
Variable variable The corresponding variable of the data element.
Value value The given value of the data element.
Question question The asked question for this data element.
void setAsVariable() Sets the data element as variable.
void setAsGiven() Gives the data element a value.
void setAsAsked() Signs the data element as asked.
5.4.18 Variable
Variable class represents a defined variable from a data element. Moreover, a user may define
operations (e.g. addition) on this variable.
Method/Field Definition
String name The name of the variable
String dataElementId The id of the data element that the variable corresponds to
String operator The operator type of the variable
List<Object>args The arguments used for defined operator.
Value val The value given for the operation
5.4.19 Value
Value represents a value with some operations on it.
Method/Field Definition
String val The actual value.
String operator The operator to modify value.
List<Object>args The arguments to modify the value.
5.4.20 Question
Question represents a query with some relations with it.
Method/Field Definition
String type The type of the question.
String operator The operator to add some details a question.
List<Object>args The details of the modification
5.4.21 Date Variable
DateVariable is inherited from Variable class. It is used to assign variables to date values or questions.
5.4.22 Numeric Variable
NumericVariable is inherited from Variable class. It is used to assign variable to numeric values or
questions.
5.4.23 DateValue
DateValue is inherited from Value class. It is used to keep date values.
5.4.24 NumericValue
NumericValue is inherited from Value class. It is used to keep numeric values.
5.4.25 DateQuestion
DateQuestion is inherited from Question class. It is used to query date values.
5.4.26 NumericQuestion
NumericQuestion is inherited from Question class. It is used to query numeric values.
5.4.27 Result
Method/Field Definition
Object getResults() Gets eligible patients, processes user's data selection and returns the results.
Object getResultsHumanReadable() Returns the result in a human readable format.
5.5 Information Viewpoint In this section, relations of the different classes are explained. Main purpose of the following ER
diagrams is to explain class diagrams in a different way. One can understand relationships between
classes without being confused by attributes easily by these diagrams. More detailed information
about the classes can be found in logical viewpoint section.
5.5.1 Authentication
The PMSST keeps all the authentication information and user preferences. The following ER diagram
represents the tables and their relations of the authentication database.
5.5.2 Eligibility Criteria
The eligibility criteria that the user selected will be saved into database to make them reusable. The
following ER diagram represents the tables and their relations to save eligibility criteria to a DB.
5.5.3 Data Selection
The data selections that the user selected will also be saved into database. The following ER diagram
represents the tables and their relations to save data selections to a DB.
5.6 Patterns use viewpoint In order to make some parts of the software reusable, some design patterns are used. In our project
we will use two main patterns which are model view controller and singleton. These patterns are not
only reusable but also applicable to any data. Usage of the patterns is explained below.
5.6.1 Model View Controller Pattern
This pattern enables us to separate basic information about the data and user interface. Model
constitutes the hidden data. View represents the form that the data is presented to the user. Finally
the controller converts input to the compatible type for the model or the view.
5.6.2 Singleton Pattern
This pattern is useful when we need a specific class to be instantiated with only one object. Singleton
Pattern is used when we need an object that is controlling the main flow of the software.
5.7 Interface viewpoint The Interface viewpoint provides information for designers, programmers, testers and users to know
how to correctly use the services provided by the system. For this purpose we will provide a
schematic interface for each use case that was defined in SRS.
5.7.1 Login / Logout Page
Login page provides user different options like login, sign up, edit user settings and logout. At
beginning of the application, these parts are represented by buttons. After selecting a button, the
related subpage occurs on the screen.
1. Login allows user to enter the system.
2. Sign up allows user to record login information.
3. Edit user settings part allows user to change information needed to login part.
4. Logout allows user to quit from the system.
5.7.2 Eligibility Criteria Page
Eligibility Criteria page allows user to populate patient health record such as age, diseases, diseases
time, drugs etc. without gathering any private data like name and country. To determine the patient
type, user can choose different conditions in this part. “Setting relations” button includes different
relations such as And, Or and so on. It is also provided to add a temporal feature like time and age
interval besides relations. This gives user a chance for very detailed filtering. Moreover, while user
writing the condition name into related box, system automatically searches and lists all conditions
matched with letters. This is called “search concept” part and it occurs when user starts to write
condition.
5.7.3 Data Selection Page
Data Selection page includes some data that are determined according to selected conditions in
Eligibility Criteria. These data also include sub-parts. If user selects a data, the related sub-data occur
on the screen. When user choose a data (also called condition), it can be represented with different
name. This new name is used to show the results. Besides, user can combine this new condition with
other conditions in an easy way. These processes are called “choose data” and “data assignment”
parts. New criteria can be added if user wants.
5.7.4 Result Page
Result page is very important for the filtering system. All results are shown as a statistical and
graphical data. User can understand results clearly in this page. By using “Save” and “Download”
buttons, user can store results in the system and get the result into computer. Besides, all
specifications selected in previous test or login time can be recorded automatically in system.
5.8 Interaction viewpoint In this viewpoint we explained the relations of modules and functions to each other and the flow of
events. This viewpoint clarifies the communication and messaging between user and modules. In
order to show the relations and interactions, sequence diagram is used in this viewpoint. The flow of
events is shown sequentially which makes understanding the occasion times of events easy. We
separate this viewpoint according to modules and every module includes sequence diagrams
showing its functions and fields which provide communication between user and other modules.
5.8.1 Authentication
The parts of Authentication module are signup, login and logout. These functionalities are explained
below in details using sequence diagrams to show process step by step.
5.8.1.1 Sign Up
The user has to sign up to system in order use it. The procedure for one user to sign up is shown in
the sequence diagram below.
It can be seen from diagram that user should send signup request in order to sign up to system. Then
Authentication module return sessionID if signing up is successful.
5.8.1.2 Login
User should be logged in to use application. The procedure for logging in for one user is shown in the
sequence diagram below.
In the diagram user sends login request to Authentication module and receives sessionID.
5.8.1.3 Logout
After finishing, user should be log out from system by sending logout request to Authentication
module.
5.8.1.4 Editing User Settings
The user can edit his/her settings after logging in to system. The procedure for editing user settings is
shown in the below diagram step by step.
After login user should send editUserSettings request to Authentication module.
5.8.2 Eligibility Criteria
Eligibility Criteria module provides the user specifying patient population. The functionalities used for
this purpose are adding and editing criterion, searching concept and setting relations. The flows and
relations of these functionalities are explained below with sequence diagrams.
5.8.2.1 Adding and Editing Criterion
The procedure to add and edit criterion is shown in sequence diagram below.
User should be logged in first. After that in order to add criterion addCriterion request should be
send to Eligibility Criteria module. In order to edit criterion user must be defined that criterion first.
Then with editCriterion request to the Eligibility Criteria module user can edit the criterion.
5.8.2.2 Searching Concept
Searching Concept is the functionality that provides finding the code for desired medication or
condition to add criterion list. The flow of events for search concept functionality is shown below.
In order to search concept the criterion must be already added. Then user can send seachConcept
request to the Eligibility Criteria module. This module gets results according to user request from
Terminology Server and returns it to user. Then user can select the result s/he desired between
them.
5.8.2.3 Setting Relations
There are two different relation functionality that can be used namely setRelation and
setTemporalRelation. Set relation functionality is used for defining AND/OR relation and set
Temporal Relation is used for setting time interval between two defined criterions. The steps are
shown in sequence diagram below. The steps to set relations are shown below in sequence diagram.
As in the diagram, user first must be logged in and already added two criterions to set their relations.
Then with setRelation request user can set AND/OR relation between these defined criterions and
with setTemporalRelation request can set time interval between them.
5.8.3 Data Selection
Data Selection module provides user to specify the information s/he needs. For this purpose there
are functionalities such that selecting data element from the list of data elements in object class and
specifying it.
5.8.3.1 Selecting Data Element
Selecting Data Element provides user to choose data element which helps to keep the information
that s/he wants. The steps for selecting data element are shown below.
Again user must be logged in. Later getContextList request sends to Data Selection module when
user opens Data Selection page. Data selection module sends getAllContext request to Metadata
Repository in order to return contexts to user. Then Metadata Repository returns contexts in XML
format. Data Selection module converts its type to json and returns it to user. User selects the
context and Data Selection Module sends getDataElements requests to Metadata Repository, gets
data elements, groups them according to object classes and return the list of object classes related to
context that user chose. Then user specifies the object class that s/he wants from Data Selection
Module and the list of data elements inside that object is return to user. Lastly user can choose the
data element that s/he can keep the related information.
5.8.3.2 Specification of Chosen Data Element
After data element is chosen user must specify its properties such as giving a value, setting as query
and assigning variable. The steps for all specifications are shown below.
There are two options that user can assign to one data element namely giving a value to data
element and setting as query. User can apply only one of them to one data element.
In order to give a value to chosen data element user should send giveValueToDataElement to Data
Selection Module. Then this module sends getValueCode requests to Terminology Server and gets its
code so that the value of current data element set to that code.
In order to set data element as query user should send setAsQuery request to Data Selection
Module. Then the information kept on that data element is set according to given query type, for
example first value, last value or all values of the query that data element is associated.
Lastly the value can be assigned to data element by sending assignVariable request to Data Selection
module. The value that user assigned is saved and then user can reuse it.
5.8.4 Result
This module shows the results based on selections that user made in previous modules. The function
flows in result module is explained in sequence diagram below.
The getResults requests send to result module when user opens result page. Then Result module
sends getEligiblePatients request to Semantic Interoperability Layer (SIL-DS) and gets information of
patient that are eligible the specifications that user made in Eligibility Criteria module. After that for
all patient information returned from SIL-DS, getExractionSpecification request is send to Metadata
Repository. Repository returns extractionSpecification for patient information and then data is
extracted and processed according to specifications that user made in Data Selection Module. Lastly
produced results are returned to user and s/he is able to save or download these results.
5.9 State Dynamics Viewpoint This viewpoint is used to specify what happens when specific events occur. In our system in order to occur one module the other one must be completed. Since there is an order between modules and their methods we used this viewpoint to show that order and state transitions clearly. State Transition diagram is used to display relations and dependencies between modules and user from the beginning to the end of the application.
In our application, first, user should be logged in to system. Then the page to define eligibility criteria
is displayed. User has to define one or more criteria in this page. After defining eligibility criteria, the
user will be able to select the data to be extracted from data selection page. In data selection page
the available information that can be extracted from patient histories will be displayed. Finally, after
selecting data, the user will be able to display results. Moreover the user will be able to download
the results to their personal computers.
5.10 Resource viewpoint In this section some basic information about the used libraries is given. Related references can be
found in the references. Note that we will use the final versions of each of them.
5.10.1 Backbone
When creating a web application, one of the very hard things is to synchronize the data with the
DOM. The compulsive thing is to handle the queries and reflect the needed result to the user
simultaneously.
Backbone provides us models that we can bind to the RestAPI. When a model changes, we will not
need to update the DOM. Backbone will update everything related when this change triggers to.1
1http://backbonejs.org/
5.10.2 Backbone-Relational
Backbone relational provides many types of relations to Backbone. By the help of backbone
relational we can control the serialization of different objects, determine the type of relations which
binds one object to many, and when a change triggered we can make sure that not only one object is
updated, also all other objects that has relations are changed.2
5.10.3 Backbone Marionette
Marionette is an application library for Backbone. It simplifies the construction of large JavaScript
applications.
Marionette is a collection of design patterns that we use when we are building a project with
backbone, also it includes some application, event driven and messaging architectures, 3
5.10.4 jQuery
jQuery is a fast JavaScript library. jQuery will help us to manipulate HTML document and also API is
much simpler and it is usable with every browser. 4
5.10.5 Bootstrap
Bootstrapisafreecollectionoftoolsforcreatingwebsitesandwebapplications. It contains HTML and CSS-
based design templates for typography, forms, buttons, navigation and other interface components,
as well as optional JavaScript extensions.5
5.10.6 Require JS
RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used
in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS
will improve the speed and quality of the code.6
5.10.7 Underscore
Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming
support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in
JavaScript objects. Underscore provides 80-odd functions that support both the usual functional
suspects: map, select, invoke — as well as more specialized helpers: function binding, javascript
templating, deep equality testing, and so on. It delegates to built-in functions, if present, so modern
browsers will use the native implementations of forEach, map, reduce, filter, every, some and
indexOf.7
2http://backbonerelational.org/
3http://marionettejs.com/
4http://jquery.com/
5http://getbootstrap.com/
6http://requirejs.org/
7http://underscorejs.org/
6 Planning
6.1 Team Structure Our team consists of 4 senior year students from Computer Engineering Department. We plan to
divide the workload equally. Our names, student ids and e-mail addresses are listed below.
1 Feyza YILMAZ 1746494 [email protected]
2 Hazal MOĞULTAY 1746262 [email protected]
3 Özlem ÇÖKÜK 1746585 [email protected]
4 Hüseyin Alper ÇINAR 1746577 [email protected]
6.2 Estimation (Basic Schedule)
Time Period Topic Responsible
13th October Project Proposal All End of October SRS All 15th November Technology Research All End of November SDD All 7th December Project Initialization All 15th December Design of the Eligibility Criteria
Page Feyza & Alper
15th December Design of the Data Selection Page
Hazal & Özlem
16th December First Iteration All End of December Report Updates All 7th January Team Presentation and Second
Iteration All
End of January First Prototype of the Eligibility Criteria Page
Feyza & Alper
End of January First Prototype of the Data Selection Page
Hazal & Özlem
15th March SILDS & Terminology Server Integration
Feyza & Alper
15th March Semantic MDR Integration Hazal & Özlem 15th April Algorithm Development for
Result Page All
End of April First Prototype of the Result Page
Feyza & Hazal
End of April Server - side implementations of Result Page
Alper & Özlem
15th May Project Revisions and Tests All End of May Finalization of the Project All