See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/320110839

Software Requirements Specification of E-Health Architecture for Nepal

Research Proposal · September 2017

DOI: 10.13140/RG.2.2.17207.57764

CITATIONS READS
0 1,160

2 authors:

Sanjog Sigdel Ravi Kiran Yadav

Kathmandu University Tribhuvan University
5 PUBLICATIONS   0 CITATIONS    1 PUBLICATION   0 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Twitter Keywords Mining for Implicit Analysis View project

eHealth: More than just an electronic record View project

All content following this page was uploaded by Sanjog Sigdel on 29 September 2017.

The user has requested enhancement of the downloaded file.

 Software​ ​Requirements
Specification
E-Health​ ​Architecture​ ​for​ ​Nepal
Sanjog​ ​Sigdel
sigdelsanjog@gmail.com
Computer​ ​Science,
Department​ ​of​ ​Computer
Science​ ​and​ ​Engineering,
Kathmandu​ ​University,
Dhulikhel,​ ​Nepal
Ravi​ ​Kiran​ ​Yadav
​7thnovravi@gmail.com
Computer​ ​Engineering,
Department​ ​of​ ​Computer
Science​ ​and​ ​Engineering,
Kathmandu​ ​University,
Dhulikhel,​ ​Nepal
1
Table​ ​of​ ​Contents
1.​ ​Introduction
1.1​ ​Purpose
1.2​ ​Scope
1.3​ ​Definitions​ ​&​ ​Acronyms
1.4​ ​References

2​ ​Description​ ​of​ ​Project

2.1​ ​Overall​ ​Description
2.2​ ​Product​ ​functions
2.3​ ​Product​ ​perspective
2.4​ ​User​ ​characteristics
2.5​ ​Constraints
2.6​ ​Assumptions​ ​and​ ​dependencies

3​ ​Specific​ ​Requirements
3.1​ ​External​ ​Interface​ ​Requirements
3.4​ ​Design​ ​Constraints
3.5​ ​Software​ ​system​ ​attributes
3.6​ ​Functional​ ​Requirements
3.7​ ​Non-Functional​ ​Requirements:

4​ ​System​ ​Evolution

APPENDIX​ ​1:​ ​CONFORMITY​ ​ASSESSMENT​ ​ACTIVITIES​ ​AND​ ​STAKEHOLDERS​ ​(CAAS)

APPENDIX​ ​2​ ​:​ ​RELEASE​ ​PLAN

2
1.​ ​Introduction
This section gives a scope description and overview of everything included in this SRS
document. Also, the purpose for this document is described and a list of abbreviations and
definitions​ ​is​ ​provided.

1.1​ ​Purpose
The purpose of this document is to give a detailed description of the requirements for proposing
an efficient “E-Health Architecture for Nepal”. It will illustrate the purpose and complete
declaration for the development of system. This document is primarily intended for a customer’s
approval​ ​ ​and​ ​as​ ​a​ ​reference​ ​for​ ​developing​ ​the​ ​demo​ ​version.

1.2​ ​Scope
The title “E-Health Architecture for Nepal” itself describes its objective. E-Health Architecture
is a hardware and software-based integrated web architecture which aims to provide online
health facilities for Nepal. This architecture will help an organization launch any web-based
health​ ​program​ ​over​ ​the​ ​country.

1.3​ ​Definitions​ ​&​ ​Acronyms

This section consists of terms, their definitions and acronyms which will be used throughout the
document.

Dashboard: ​A ​dashboard ​is the panel for any system which contains tools as softwares to
monitor​ ​and​ ​deploy​ ​services.

Dedicated Server: ​A ​dedicated server is a single computer in a network reserved for serving
the​ ​needs​ ​of​ ​the​ ​network

Health Facilities: Health facilities are places that provide health care. They include hospitals,
clinics, outpatient care centers, and specialized care centers, such as birthing centers and
psychiatric​ ​care​ ​centers.

CAAS:​ ​Conformity​ ​Assessment​ ​Activities​ ​and​ ​Stakeholders

GUI:​​ ​Graphical​ ​User​ ​Interface
ISP:​ ​Internet​ ​Service​ ​Provider
MoHP:​Ministry​ ​of​ ​Health​ ​and​ ​Population
RAID:​ ​Redundant​ ​Array​ ​of​ ​Independent​ ​Disks
DESC:​​ ​Description
3
RAT:​​ ​Rational
DEP:​​ ​Dependency

1.4​ ​References
[1] Software Requirements Specification, Computer Information Systems Program, Janusz
Zalewski,​ ​Ph.D.​ ​College​ ​of​ ​Business,Florida​ ​Gulf​ ​Coast​ ​University
[2]​​ ​Software​ ​Engineering:​ ​A​ ​Practitioner’s​ ​Approach,​ ​Seventh​ ​Edition,​ ​2010
[3]​​ ​Software​ ​Engineering,​ ​Ninth​ ​Edition,​ ​Ian​ ​Sommerville,​ ​2011
[4]​​ ​Web​ ​Based​ ​Project​ ​Management​ ​System,​ ​Anne-Mai​ ​Adamson,​ ​2010
[6]​​ ​Software​ ​project​ ​management​ ​/​ ​Bob​ ​Hughes​ ​and​ ​Mike​ ​Cotterell,​ ​London
[7] ​eHealth Interoperability Framework, Version 1.1, National E-Health Transition Authority
Ltd,​ ​NEHTA​ ​managed​ ​specification,​ ​April​ ​2012,

1.5​ ​Overview​ ​of​ ​Document

This​ ​section​ ​describes​ ​the​ ​overview​ ​of​ ​the​ ​entire​ ​document.​ ​ ​brief​ ​introduction​ ​is
provided​ ​here.
​ ​Section​ ​1:​​ ​This​ ​section​ ​describes​ ​the​ ​purpose​ ​and​ ​scope​ ​of​ ​the​ ​project.
​ ​Section​ ​2:​ ​ ​This​ ​section​ ​describes​ ​the​ ​functions,product​ ​perspective,​ ​various​ ​user
characteristics,​ ​constraints,​ ​limitations,​ ​assumptions​ ​and​ ​dependencies.
Section​ ​3:​ ​This​ ​section​ ​describes​ ​the​ ​requirements​ ​of​ ​the​ ​entire​ ​system.​ ​This
includes​ ​hardware​ ​requirements,​ ​user​ ​interfaces,​ ​use​ ​case​ ​diagram,​ ​design
constraints,​ ​functional​ ​and​ ​non-functional​ ​requirements.
Section​ ​4:​ ​This​ ​section​ ​describes​ ​ ​about​ ​the​ ​system​ ​evolution

4
2​ ​Description​ ​of​ ​Project

2.1​ ​Overall​ ​Description

This section will give an overview of the whole system showing its interaction with other
interrelated systems. The basic functionality of the system will also be explained. This section
will explain the types of stakeholders who will use the system and their respective available
functionality.​ ​The​ ​constraints​ ​and​ ​assumptions​ ​used​ ​for​ ​the​ ​system​ ​is​ ​also​ ​explained​ ​at​ ​the​ ​end.

2.2​ ​Product​ ​functions

With the server-side web portal or dashboard, system administrator will be able to deploy the
health applications, so that clients (all health facilities) will be able to use them. Whereas in
client side, the technical officer will use the web application online and will also be able to view
the available applications online. Data input by every health facilities from all over the countries
will concurrently be stored in the server through the E-Health Architecture. This data will
further be classified, analysed and visualized by a data engineer using some E-Health data
visualization softwares. Then the report generated will be again distributed to specific targeted
authorities​ ​through​ ​dashboard.

2.3​ ​Product​ ​perspective

The system will consists of two parts: one Hardware configuration part and one Web Portal.
Hardware configuration
will be used to establish a
physical connection of all
the Health Facilities of
Nepal while web portal
will be used to load web
based applications in the
areas connected by the
architectures.

Hardware configuration
part simply enables
establishment of an
integrated server-client
architecture. This includes
establishment of a high
5
performance dedicated server in central unit of Ministry of Health and Population MoHP. Each
hardware components of health facilities all over country ranging from lower level health
facilities to the MoHP will be connected online which will be web hosted by some relevant
Internet Service Provider(ISP). A web portal also known as dashboard will be installed in the
central server. Any web based health applications can be launched from the server and all its
clients throughout the nation will easily be able to use it. Client side dashboard will only be able
to​ ​view​ ​the​ ​permitted​ ​applications​ ​and​ ​use​ ​them.

2.4​ ​User​ ​characteristics

There are four types of users who interact with the system: client side users i.e. employees or
lower​ ​level​ ​health​ ​facility​ ​users,​ ​data​ ​engineers,​ ​system​ ​administrator,​ ​high​ ​level​ ​officers.

Lower level health facilities users are only concerned with limited objectives like data input to
the server. They will input all medical or patient related data to the server. To input data users
must​ ​be​ ​able​ ​to​ ​search​ ​and​ ​view​ ​their​ ​required​ ​application​ ​online​ ​in​ ​the​ ​repository.

Data engineers ​are only concerned with data and data operations. Data engineers will be
filtering the raw data. They will classify it from data sets. From the generated datasets; data will
be analysed using applications provided by the architecture. Then furthermore report generation
according​ ​to​ ​the​ ​necessity​ ​of​ ​high​ ​level​ ​managers​ ​is​ ​also​ ​done​ ​by​ ​the​ ​data​ ​engineers.

High Level Officers ​are only concerned with the use of the dashboard. High level officers are
also client-side users. They use the architecture to use certain components like report generating,
viewing​ ​and​ ​exporting​ ​tools.

System Administrator ​A system administrator is solely responsible for smooth operation of

E-Health Architecture. It is system administrator who monitors, maintains and authorises the
hardware components as well as software resources to the end users. System administrator is
responsible​ ​for​ ​security​ ​of​ ​the​ ​ ​whole​ ​architecture.

Besides these four user characteristics, for the development of softwares and its stability:
Software Developers and Support Communities are also essential. They are responsible for
assessment activities and communicating with various stakeholders of the system. Details about
these​ ​users​ ​are​ ​described​ ​in​ ​APPENDIX​ ​1

6
2.5​ ​Constraints
The architecture is targeted to run all over the country. So being a huge system it needs to face
several constraints and limitations which may lag the performance of architecture. As Nepal has
a unique geography of hills and terrains, deployment of architecture will be a constraint. As the
architecture will be set up with government support, after the system is set up, skilled manpower
will also play key role in delivering the quality service to the users. As E-Health architecture is
about providing services online, we should make sure the power supply, internet, internet
bandwidth and communication with central server is always up and functioning. The architecture
will receive huge no. of data so the classification of applications, targeted user groups and
classification of data are some essential constraints to be considered throughout the development
and​ ​use​ ​of​ ​system.

2.6​ ​Assumptions​ ​and​ ​dependencies

The architecture will be focusing on providing E-Health facilities online. So our ​assumption is
that the internet facility, power supply, backup power, internet bandwidth is always up and
functioning. Another assumption also a ​dependency for the architecture is hardware
configuration of the central server. We assume that the hardware will be above specification, so
that​ ​it​ ​will​ ​not​ ​need​ ​to​ ​face​ ​any​ ​problem​ ​in​ ​future.

7
3​ ​Specific​ ​Requirements
This section contains all of the functional and quality of the system. It gives a detailed
description​ ​of​ ​the​ ​system​ ​and​ ​all​ ​its​ ​features.

3.1​ ​External​ ​Interface​ ​Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also
gives a description of the hardware and software interfaces and provides basic prototypes of the
user​ ​interface.

3.1.1​ ​User​ ​Interfaces

The​ ​major​ ​interfaces​ ​of​ ​the​ ​system​ ​are:
Dashboard()
The dashboard will be accessible with all user types. Here they will perform respective tasks
according​ ​to​ ​their​ ​permission​ ​level.

8
The figure shown above is the interface of a dashboard. Almost all the interfaces like
UploadSoftware(), ViewSoftware(), GenerateReport(), DataExport(), SysAdmin() will be
accessed from the dashboard. It it the system administrator who assigns the access to each type
of users. From the dashboard all types of users will access the softwares. System Administrator
will upload a project, data engineers will export the data and prepare report and the high level
officials​ ​will​ ​view​ ​them.​ ​And​ ​all​ ​activities​ ​will​ ​be​ ​done​ ​through​ ​the​ ​Dashboard​ ​shown​ ​above.

UploadSofware()
This interface is accessible to system administrator who will upload E-Health Projects to the
architecture.

ViewSoftware()
Here all the software uploaded by system administrator is collected. Users will view application
only​ ​assigned​ ​to​ ​them.

GenerateReport()
This interface will be used mainly by Data Engineer to analyze data and produce report. Also
high​ ​level​ ​managers​ ​will​ ​see​ ​this​ ​interface.

Figure:​ ​Login​ ​/​ ​Signup​ ​Interface

9
Use​ ​Case​ ​Diagram:​ ​A​ ​use​ ​case​ ​diagram​ ​is​ ​shown​ ​below​ ​:

Figure:​​ ​Use​ ​Case​ ​Diagram​ ​displaying​ ​user​ ​interactions

In above use case diagram, four level of users system administrator, lower level users, data
engineers and decision makers are displayed. With all users the way they access their own
customized​ ​dashboard​ ​is​ ​displayed.

3.1.2​ ​Hardware​ ​Interfaces

Even though this architecture is hardware-software integrated web architecture, we will not be
designing any specific hardware interface to run the system. Our system is a web based system,
so​ ​we​ ​will​ ​be​ ​launching​ ​it​ ​in​ ​several​ ​computers​ ​online.

10
3.4​ ​Design​ ​Constraints
This​ ​section​ ​includes​ ​the​ ​design​ ​constraints​ ​on​ ​the​ ​architecture​ ​caused​ ​by​ ​the​ ​hardware.

3.5​ ​Software​ ​system​ ​attributes

The requirements in this section specify the required reliability, availability, security &
maintainability​ ​of​ ​the​ ​software​ ​system.

3.6​ ​Functional​ ​Requirements

ID​ ​:​ ​FR1
TITLE​ ​:​ ​Access​ ​the​ ​web​ ​portal
DESC: A user should be able to access the wep portal. The access should not be
restricted to registered users. Someone who is not registered should also be able to read
the​ ​relevant​ ​eHealth​ ​information​ ​provided​ ​by​ ​the​ ​web​ ​portal.
RAT​:​ ​To​ ​access​ ​health​ ​related​ ​information
DEP​:​ ​None

ID​ ​:​ ​FR2

TITLE:​ ​Constantly​ ​update​ ​and​ ​notify​ ​government’s​ ​Health/eHealth​ ​policy.
DESC : The web portal should always be up-to-date in regard to the government’s
policy.It should should notify the users about the new policy and rules made by the
authority.
RAT:​ ​to​ ​give​ ​user​ ​an​ ​up-to-date​ ​information
DEP:​ ​None

ID​ ​:​ ​FR3

TITLE​ ​:​ ​User​ ​registration
DESC​: A user, as specified in earlier section must be able to register their credentials.
They should provide their basic information about themselves for eg. name, address,
email, phone number. They should also identify themselves the kind of users (mentioned
under​ ​user​ ​characteristics)​ ​they​ ​are.
RAT​:​ ​In​ ​order​ ​to​ ​be​ ​a​ ​contributing​ ​factor​ ​in​ ​the​ ​eHealth​ ​Architecture
DEP​:​ ​FR1

11
ID​ ​:​ ​FR4
TITLE​ ​:​ ​User​ ​Verification:
DESC ​: User should be able to verify them through their email. A link in the email
should​ ​be​ ​provided​ ​for​ ​the​ ​user​ ​to​ ​follow​ ​if​ ​he/she​ ​is​ ​logging​ ​for​ ​the​ ​very​ ​first​ ​time.
RAT​ ​:​ ​In​ ​order​ ​for​ ​a​ ​real​ ​user​ ​to​ ​register
DEP​ ​:​ ​FR1,​ ​FR3

ID​ ​:​ ​FR5

TITLE​ ​:​ ​User​ ​Login
DESC ​: Given that a user is registered, the user should be able to log into the web portal.
The​ ​system​ ​should​ ​keep​ ​and​ ​maintain​ ​the​ ​user​ ​login​ ​information.
RAT​ ​:​ ​In​ ​order​ ​for​ ​the​ ​user​ ​to​ ​log​ ​into​ ​the​ ​system
DEP​ ​:​ ​FR1,​ ​FR3

ID​ ​:​ ​FR6

TITLE​ ​:​ ​Data​ ​Entry
DESC ​: User should be able to fill in the necessary health information. Some of the key
data​ ​that​ ​should​ ​be​ ​entered​ ​by​ ​the​ ​user​ ​themselves​ ​are​ ​as​ ​follows:
----Name​ ​of​ ​the​ ​patient
----Age
----Sex
----Disease​ ​diagnosed
----Address
----Prescription
----Types​ ​of​ ​patients
----Diseases​ ​suffered​ ​(health​ ​history)
RAT​​ ​:​ ​In​ ​order​ ​for​ ​the​ ​user​ ​to​ ​enter​ ​health​ ​issues​ ​into​ ​the​ ​system
DEP​​ ​:​ ​FR1,​ ​FR3,​ ​FR5

ID​​ ​:​ ​FR7

TITLE​ ​:​ ​User​ ​Identification
DESC : The system must be able to identify the type of users who have entered health
information​ ​as​ ​described​ ​in​ ​requirement​ ​no.​ ​5.
RAT​ ​:​ ​In​ ​order​ ​for​ ​the​ ​system​ ​to​ ​identify​ ​the​ ​type​ ​of​ ​user
DEP​ ​:​ ​FR3,​ ​FR4

12
ID​ ​:​ ​FR8
TITLE​ ​:​ ​Acquisition
DESC : The system should be able to discover critical information/knowledge required
by​ ​the​ ​the​ ​government​ ​or​ ​the​ ​health​ ​ministry.
RAT​​ ​:​ ​In​ ​order​ ​for​ ​the​ ​system​ ​to​ ​acquire​ ​the​ ​data​ ​entered​ ​by​ ​the​ ​user
DEP​​ ​:​ ​FR6,​ ​FR7

ID​​ ​:​ ​FR9

TITLE​​ ​:​ ​Filtering
DESC : After collecting information from various sources, there is a need to find out
which information is relevant and which information is irrelevant or duplicated.
Generally, the primary objective of information filtering is to sort through large volumes
of dynamically collected information and present those that are likely to satisfy users'
information​ ​needs.
RAT​​ ​:​ ​In​ ​order​ ​for​ ​the​ ​system​ ​to​ ​filter​ ​in​ ​only​ ​the​ ​relevant​ ​information
DEP​​ ​:​ ​FR8

ID​​ ​:​ ​FR10

TITLE​ ​:​ ​ ​Categorization,​ ​Indexing,​ ​and​ ​Linking
DESC : Indexing, categorization, and linking are performed to organize information.
Indexing is a critical method in achieving fast and accurate searching. It is the problem of
assigning labels to cases or other information to ensure that the right information and
knowledge can be retrieved at appropriate time. All the eHealth related information
should be categorized by some criteria. Linking means to establish connections between
relevant information so that everything related to a specific disease in the system be
located​ ​through​ ​interconnected​ ​links.
RAT​​ ​:​ ​In​ ​order​ ​for​ ​the​ ​system​ ​to​ ​enable​ ​a​ ​fast​ ​and​ ​accurate​ ​search​ ​mechanism
DEP​​ ​:​ ​FR8,​ ​FR9

ID​​ ​:​ ​FR11

TITLE​ ​:​ ​Knowledge​ ​Creation
DESC : New knowledge can be derived through a number of different processes ranging
from data visualization to data mining. The extracted information, such as various
situational features, actions taken, the health institutions involved, success of the resulting
outcomes, and the information source, can be integrated and codified to generate
well-structured disaster cases. Those cases are treated as knowledge for future reuse
through​ ​case-based​ ​reasoning.
RAT​​ ​ ​:​ ​In​ ​order​ ​for​ ​the​ ​system​ ​to​ ​make​ ​meaningful​ ​information​ ​from​ ​the​ ​acquired​ ​data
DEP​​ ​:​ ​FR8,​ ​FR9,​ ​FR10

13
 ID​ ​:​ ​FR12
TITLE​​ ​:​ ​Maintenance
DESC : The system will keep receiving new health information and knowledge, and also
periodically​ ​removes​ ​what​ ​are​ ​replicated​ ​and​ ​outdated.
RAT​ ​:​ ​In​ ​order​ ​for​ ​the​ ​system​ ​to​ ​remove​ ​redundancy
DEP​ ​:​ ​FR8,​ ​FR9,​ ​FR10,​ ​FR11

3.7​ ​Non-Functional​ ​Requirements:

ID​ ​:​ ​NFR1
TITLE​ ​:​ ​Usability
DESC​: The system should be easy to use and learn in every aspects. The new users
should​ ​get​ ​used​ ​to​ ​in​ ​the​ ​system​ ​fast​ ​as​ ​possible.

ID​ ​:​ ​NFR2

TITLE​ ​:​ ​Reliability
DESC ​: The system shall be available for use at 24 hours a day, 7 days a week. The data
storage shall be available for use 24 hours a day, 7 days a week. The system may get
failed​ ​few​ ​times​ ​in​ ​a​ ​year​ ​and​ ​had​ ​a​ ​small​ ​maintenance​ ​time.

ID​ ​:​ ​NFR3

TITLE​ ​:​ ​Hardware
DESC​ ​:
Mobile​ ​Requirements
Nowadays handheld devices are one of the best tool for raw data entry. With the help of
mobile devices patient’s and other related medical data can be entered on the go. The web
portals​ ​can​ ​be​ ​accessed​ ​through​ ​various​ ​smart​ ​phone​ ​platform​ ​like
i)​ ​IOS
ii)​ ​Android
iii)​ ​Blackberry

Server​ ​Requirements
The server hardware specification depends on the amount of data to be processed and the
number of users accessing the server database. The specification of server usually
increases with increase in the number of end users. However, a general estimate for a
5000+​ ​users​ ​sever​ ​is​ ​given​ ​below

14
No.​ ​of​ ​users​ ​:​ ​5000​ ​+
Processor​ ​:​ ​Dual​ ​Hexacore​ ​Xeon​ ​L5640​ ​(​ ​or​ ​better​ ​)
Memory​ ​:​ ​32​ ​GB​ ​+
Hardware​ ​:​ ​15k​ ​SAS2​ ​drives​ ​RAID​ ​10

The above mentioned mobile requirements are not necessary but recommended hardware
requirement​ ​for​ ​the​ ​use​ ​of​ ​ ​webportal.

ID​ ​:​ ​NFR4

TITLE​ ​:​ ​Error​ ​Rate
DESC ​: The system should provide good quality and be error free. The quality is
sufficient if there are few errors per week in first release and few errors per month and so
on.​ ​The​ ​system​ ​should​ ​provide​ ​log​ ​information​ ​about​ ​process​ ​and​ ​errors​ ​to​ ​the​ ​users.

​ ​ID​ ​ ​:​ ​NFR5

TITLE​ ​:​ ​Scalability
DESC​ ​:​ ​System​ ​should​ ​provide​ ​option​ ​to​ ​extend​ ​hardware​ ​and​ ​other​ ​services​ ​in​ ​future.

ID​ ​:​ ​NFR6

TITLE​ ​:​ ​Security
DESC ​: The system shall protect the data and services from unauthorized access. The
system shall also provide authentication and secure transaction. System should provide
highest possible security mechanism in order to protect critical information. System
should run privately over public network (For this Secured tunneling mechanism should
be used). System should restrict all the non-member of the project to get access to the
system. The system shall provide a mechanism of user authentication to unambiguously
identify​ ​a​ ​user.

15
4​ ​System​ ​Evolution

The preliminary stage of E-Health Architecture, gives a high chance to evolve into better system
with many stable features in upcoming future. Gaining its stability, the system targets to
incorporate more hardware and software tools, security and software updates. With the evolution
of the system, it becomes more and more stable and shall become robust E-Health architecture in
Nepal.

Following​ ​are​ ​some​ ​new​ ​features​ ​which​ ​can​ ​be​ ​expanded​ ​in​ ​the​ ​architecture:

1. Present architecture focuses only in available internet facility, but in future the
architecture​ ​can​ ​provide​ ​internet​ ​facility​ ​of​ ​its​ ​own(​ ​Government​ ​as​ ​ISP).

2. Bandwidth allocation and routing feature can be integrated in future, so that data can be
available​ ​everywhere​ ​and​ ​reliable​ ​for​ ​every​ ​targeted​ ​user​ ​groups.

3. The architecture can incorporate documents and tools to teach users about the uses,
objectives​ ​and​ ​ways​ ​of​ ​troubleshooting​ ​them.

4. The system can also incorporate error reporting, error logging features with the help of
GUI.

16
APPENDIX​ ​1:​ ​CONFORMITY​ ​ASSESSMENT​ ​ACTIVITIES​ ​AND
STAKEHOLDERS​ ​(CAAS)1

Conformity Assessment Activities and Stakeholders as shown in above diagram

focuses on stability of a system considering various constraints like: measurements,
product certifications, standards and customer's requirements. CAAS also incorporates
developers, governments, regulators, approver, specifiers, stakeholders and sponsors
to provide an organisational framework in which inter-related artefacts are verified for
consistency,​ ​traceability​ ​and​ ​compatibility​ ​of​ ​the​ ​system.

Figure​ ​2:​ ​Conformity​ ​Assessment​ ​Activities​ ​and​ ​Stakeholder

eHealth​ ​Interoperability​ ​Framework,​ ​Version​ ​1.1,​ ​National​ ​E-Health​ ​Transition​ ​Authority​ ​Ltd,
1

NEHTA​ ​managed​ ​specification,​ ​April​ ​2012,

17
View publication stats

Consistency is a characterisation of the logical coherence of the artefacts that are defined in the
specification​ ​viewpoints.

Traceability defines relationships that link an attribute or other feature of a particular

specification​ ​artefact​ ​with​ ​another​ ​artefact​ ​in​ ​the​ ​other​ ​(or​ ​same)​ ​cell​ ​of​ ​the​ ​specification​ ​matrix.

Compatibility is a relationship between two or more conformance statements involving two or

more specification instances. The relationship identifies whether two or more implementations
claiming​ ​to​ ​be​ ​conformant​ ​to​ ​the​ ​specification​ ​instances​ ​can​ ​achieve​ ​interoperability.

APPENDIX​ ​2​ ​:​ ​RELEASE​ ​PLAN

The architecture will be deployed in two phases. First phase ensures the setup of hardware and
necessary software platform. Second phase will focus on web portal setup. This phase will test
whether every component of the architecture is functioning. Real time testing will be done in
phase​ ​two.

PHASE​ ​1

After the architecture is approved, necessary hardwares as mentioned in section ​3.4 Design
Constraints of this document will be setup. Hardware components like switch, router, LAN
cable, power backup dedicated server will be set up. Each and every components will be tested
and​ ​phase​ ​2​ ​release​ ​will​ ​begin.​ ​PHASE​ ​1​ ​will​ ​take​ ​maximum​ ​one​ ​month.

PHASE​ ​2

In this phase user will fetch live data from the central server. User will test whether the
applications are installed and if they are working properly. At the same time system
administrator will monitor the performance of server. System administrator will add the
necessary applications and tools to be used by users. PHASE 2 will take two months to be
completed. This phase will face many errors and bugs. This phase will take more time if various
users​ ​will​ ​make​ ​errors.

18