Annexure-A Preliminary Requirements Document FOR Electronic Patient Information System ... · 2020. 8. 7. · P a g e 3 | 101 ©Thimphu TechPark Limited, Post Box 633, Babesa, Thimphu,

_____________________________________________________________________________________________________

Annexure-A

Preliminary Requirements Document

FOR

Electronic Patient Information System (ePIS) Project

August 2020

_____________________________________________________________________________________________________

Table of Contents

1 . E x e c u t i v e S u m m a r y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 . I n t r o d u c t i o n a n d C o n t e x t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1. Project Overview .................................................................................................................... 5

2.2. Key Focus areas of the Project .............................................................................................. 5

2.3. Business Strategy and Business Architecture of the Project............................................... 6

2.4. Business Capabilities .............................................................................................................. 8

2.5. Business Functions ................................................................................................................. 9

3 . P r o p o s e d e P I S S o l u t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1

3.1. ePIS Application Overview ................................................................................................... 11

3.1.1. ePIS Core Application ................................................................................................... 12

3.1.1.1. Modules / Processes ................................................................................................. 13

3.1.2. ePIS Solution Features ................................................................................................. 18

3.1.2.1. ePIS lighter version .................................................................................................. 18

3.1.2.2. ePIS Web Portal and Mobile App ............................................................................ 19

3.1.2.3. Tele / Video-Consultation ......................................................................................... 20

3.1.3. Additional Functionalities and Features ..................................................................... 22

3.1.4. Recommended Technologies ...................................................................................... 25

3.2. Technology – Solution Architecture ................................................................................... 26

3.2.1. Technology Solution .................................................................................................... 26

3.2.1.1. Architecture Vision and Principles .......................................................................... 27

3.2.1.2. Design Considerations & Approach ........................................................................ 30

3.2.1.3. Technical Architecture Components ...................................................................... 35

3.2.1.4. DevOps Architecture ............................................................................................... 63

3.2.1.5. Non-Functional Requirements ................................................................................ 65

3.2.2. Proposed Technology Stack ........................................................................................ 67

4 . D a t a m i g r a t i o n / I n t e g r a t i o n a n d M a n a g e m e n t S t r a t e g y . . . . . . . . . . . . . . . . . . 7 1

4.1. Data Digitization of Physical Records .................................................................................. 71

4.2. Objectives of Data Migration .............................................................................................. 72

4.3. Steps in Data Migration ....................................................................................................... 72

4.4. List of Applications for integration ..................................................................................... 73

_____________________________________________________________________________________________________

5 . e P I S D e p l o y m e n t A r c h i t e c t u r e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1

6 . S o l u t i o n D e v e l o p m e n t A p p r o a c h & I m p l e m e n t a t i o n M e t h o d o l o g y . . 8 2

6.1. Hybrid Model - Procurement and Adoption of an Open Source Solution ........................ 82

6.2. Proposed Solution Implementation Strategy .................................................................... 82

6.3. Implementation Plan ........................................................................................................... 83

6 . 4 . Solution Development and Implementation Methodology .............................................. 85

7 . e P I S T e s t i n g a n d A c c e p t a n c e C r i t e r i a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1

7.1. ePIS Testing Strategy ............................................................................................................ 91

7.2. ePIS Testing Methodology ................................................................................................... 91

7.3. ePIS Testing Process ............................................................................................................ 92

7.4. User Acceptance Testing (UAT) .......................................................................................... 93

7.4.1. Acceptance Test Design and Execution ...................................................................... 93

7.4.2. Fault Correction............................................................................................................ 94

7.5. ePIS Acceptance Criteria ..................................................................................................... 94

8 . C a p a c i t y B u i l d i n g a n d C h a n g e M a n a g e m e n t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6

8.1. TTPL technical capacity building ......................................................................................... 96

8.2. End user training .................................................................................................................. 97

9 . P r o p o s e d G o v e r n a n c e F r a m e w o r k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8

9.1. Responsibilities of TTPL team and System Integrator/partner: ...................................... 100

1 0 . C o n c l u s i o n a n d W a y F o r w a r d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 0

_____________________________________________________________________________________________________

List of Figures

Figure 1 Key Focus Areas ....................................................................................................................................... 6 Figure 2 Vision, Mission, Goals and Objectives ...................................................................................................... 6 Figure 3- Business Capabilities .............................................................................................................................. 8 Figure 4- Overview of Patient Information System ............................................................................................. 9 Figure 5- ePIS Solution Framework ..................................................................................................................... 12 Figure 6- Design consideration ........................................................................................................................... 30 Figure 7- Technical Architecture Components ................................................................................................... 35 Figure 8- Legends ................................................................................................................................................ 35 Figure 9- Containerization ................................................................................................................................... 40 Figure 10- Authentication .................................................................................................................................... 43 Figure 11 Authorization and Accessing APIs ....................................................................................................... 44 Figure 12 Configuration Management ................................................................................................................ 45 Figure 13 Schedulers ............................................................................................................................................ 47 Figure 14 Service Discovery ................................................................................................................................. 48 Figure 15 ePIS System Schematic Diagram ......................................................................................................... 48 Figure 16 Kafka Components .............................................................................................................................. 49 Figure 17 Workflow Management....................................................................................................................... 51 Figure 18 Rule Management ............................................................................................................................... 52 Figure 19 Rule Management ............................................................................................................................... 53 Figure 20 System Monitoring .............................................................................................................................. 55 Figure 21 Cache Sequence Diagram .................................................................................................................... 58 Figure 22 Replication and Clustering .................................................................................................................. 59 Figure 23 Alfresco Solution ................................................................................................................................. 60 Figure 24- Mobile Application ............................................................................................................................. 61 Figure 25 Enterprise Portal Framework .............................................................................................................. 64 Figure 26 Logical Deployment Architecture ....................................................................................................... 81 Figure 27 Testing Strategy ................................................................................................................................... 91 Figure 28 Testing Models .................................................................................................................................... 92 Figure 29 Proposed Standards ............................................................................................................................ 95 Figure 30 Governance Structure ......................................................................................................................... 98

List of Tables

Table 1- List of processes for Medical Care Services .......................................................................................... 15 Table 2- List of processes for Medical Support Services.................................................................................... 16 Table 3- List of processes for Business Services................................................................................................. 17 Table 4- List of processes for Operational Services ........................................................................................... 18 Table 5- Proposed Technology Stack .................................................................................................................. 70 Table 6 Integration of Application ...................................................................................................................... 80 Table 7 Implementation Plan .............................................................................................................................. 84 Table 8 Testing Processes ................................................................................................................................... 93

P a g e 1 | 101 ©Thimphu TechPark Limited, Post Box 633, Babesa, Thimphu, Bhutan

Tel: +975-2-350052 [email protected] | www.thimphutechpark.bt

Acronyms and Glossary of Terms

S. No. Acronyms/ Abbreviations Description

1 ACWT Average After-Call Work Time

2 AHT Average Handle Time

3 API Application Programming Interface

4 APM Application Process Management

5 ASA Average Speed of Answer

6 BOM Bill of Material

7 BPM Business Process Management

8 CBN Common Bonding Network

9 CCN Change Control Notice

10 CDSS Clinical Decision Support System

11 CMS Content Management System

12 COTS Commercially Off The Shelf

13 COW Computer on Wheels

14 CR Change Request

15 DC/ DR Data Center/ Disaster Recovery'

16 DICOM Digital Imagine and Communication

17 DLP Data Loss Protection

18 DMS Document Management System

19 DSS Decision Support System

20 EHR Electronic Health Record

21 EMS Enterprise Management System

22 ePIS Electronic Patient Information System

23 EUM Elastic Real User Monitoring

24 FIFO/ LIFO First In First Out/ Last In First Out

25 GDC Government Data Center

26 GIS Geographic Information System

27 HIE Health Information Exchange

28 IMTRAT Indian Military Training Team

29 IPD In-Patient Department

30 ISMS Information Security Management System

31 JDWNRH Jigme Dorji Wangchuk National Referral Hospital

32 LAN/ WAN Local Area Network, Wide Area Network

33 LDQ Longest Delay in Queue

34 LMS Learning Management System

35 MoF Ministry of Finance, Bhutan

36 MoH Ministry of Health, Bhutan

37 MoM Minutes of Meetings

38 NGFW Next Generation Firewalls

39 NOC Network Operations Center

mailto:[email protected]

https://thimphutechpark.bt/

_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 2 | 101

©Thimphu TechPark Limited, Post Box 633, Babesa, Thimphu, Bhutan


S. No. Acronyms/ Abbreviations Description

40 OPD Out-Patient Department

41 PACS Picture Archiving and Communication System

42 PMU Project Management Unit

43 RAD Rapid Application Development

44 RBAC Role-based Access Control

45 RFID Radio-Frequency Identification

46 RPO Recovery Point Objective

47 RTO Recovery Time Objective

48 RUM Real User Monitoring

49 SAN Storage Area Network

50 SDD System Design Document

51 SDG Sustainable Development Goals

52 SDLC Software Development Life Cycle

53 SDT System Development Team

54 SIEM Security Information and Event Management

55 SLA Service Level Agreements

56 SoW Scope of Work

57 SRS System Requirement Specifications

58 STLC Software Testing Life Cycle

59 SWOT Strength, Weakness, Opportunity, Threat

60 TLS Transform Layer Security

61 TM Traditional Medicine

62 TNA Training Needs Assessment

63 TTPL Thimphu Tech Park Ltd.

64 UAT User Acceptance Testing

65 VHW Village Health Workers

66 WAF Web Application Firewall

67 WHO World Health Organization

68 ICD International Classification of Diseases

69 CORS Cross-Origin Resource Sharing

70 ZESt Zhiyog Electronic System



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 3 | 101



1. Executive Summary

Bhutan’s healthcare system plans to harness the potential of information and communication

technologies in completely transforming healthcare delivery through healthcare facilities across

the country. Bhutan is among those countries that have pledged to improve health sector services

through the attainment of goals and objectives defined under the National Health Policy in

accordance with SDGs. While the individual healthcare institutions in Bhutan at all levels are

addressing the issues of providing efficient health services to their citizens, by implementing

various programs and ICT initiatives, Electronic Patient Information System (ePIS) is one of the

initiatives by MoH, Royal Government of Bhutan, that aims at increasing the availability and

accessibility of healthcare services for the citizens as well as usage and sharing of timely and

accurate health information at all levels across the country. It aims to enable the Ministry and

facility level administrators for quick decision making and optimal utilization of resources. ePIS is

envisaged to be a central initiative guiding and integrating all other programs and schemes

towards the achievement of envisaged targets and objectives of improving health care services

and its administration in Bhutan.

Project Objective

The objective of this initiative is to implement a state-of-the-art ICT enabled Electronic Patient

Information System (ePIS) in order to improve productivity of the health institutions at all levels,

thereby improving public health services and bringing administrative efficiency in the entire

healthcare ecosystem.

Project Coverage

The ePIS will be implemented at the health facilities1 covering three referral hospitals, 46 hospitals,

186 Primary Health Centres (formerly BHU-IIs), 53 sub-posts, 542 Outreach Clinics, 3 Thromde

Health Center, 6 Health Information Services Center and one Traditional Medicine hospital with 70

indigenous unit.

ePIS Solution Overview

The ePIS for Bhutan is envisaged to be a comprehensive, integrated, fully automated ICT based

platform to help transform the entire healthcare service delivery system through all the health

facilities run by the Government. This will manage overall functioning of a government healthcare

facilities including patient care, hospital administration and all the other corresponding services

and processes. All the services and processes which are applicable in all the healthcare facilities

across Bhutan have been considered for automation as part of ePIS project.

The Solution Architecture for ePIS is designed based on principles of Modularity, Scalability, High

Availability, Security, Privacy, Reliability, Flexibility, Manageability, Reusability, Interoperability,

1 The two military hospitals and other health facilities outside the purview of MoH are out of scope of this project.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 4 | 101



Resiliency and Performance. This provides a robust design to cater to the needs of strengthening

capabilities of the healthcare facilities to enhance the experience during entire patient lifecycle,

with an aim to achieve the envisioned goals & objectives of MOH, RGOB.

Core Design principles of a micro service-oriented platform with an ‘N’-tier implementation form

the architectural base of the solution. The ePIS solution is proposed to be primarily based on the

open source technologies. The solution will provide Open “Application Programming Interface”

(APIs) to all its ecosystem partners in order to allow other external applications, both existing and

future, to integrate seamlessly with ePIS as and when required. Unlike closed proprietary systems,

these Open APIs are RESTful APIs that can be used to further develop mobile applications, web

applications and help integrate with other government systems. This will allow government the

ability to replace existing systems, as required and further integrate or develop as part of ePIS.

ePIS Development Approach

A Hybrid development approach is envisaged for developing all the core capabilities and features

of comprehensive solution. An open source / stack solution package will be selected through a

tendering process. Once the solution is selected, the concerned vendor would provide complete

training and handholding support to the TTPL delivery and development team on the solution

package. The required customization, configuration and additional Be-spoke development as well

as implementation would be done by the TTPL delivery and development team with the support

from the selected vendor.

The customization and development of ePIS will be done adopting Agile and Rapid application

development (RAD) software development methodology, which heavily emphasizes rapid

prototyping and iterative testing and delivery to fast track the implementation.

ePIS Implementation Approach

Considering the requirements and expectations of MoH, hybrid wise implementation approach

(facility and module approach) has been proposed for ePIS. Within the facility, some modules may

be released on priority depending on the preference of MoH and feasibility of such releases.

Once the solution package is adopted and the TTPL team is trained by the concerned vendor, TTPL

team would commence the design, development, customization, configuration of core ePIS

application as per requirements of MoH. This will enable the standardisation of almost all

processes and modules covered under the scope of ePIS along with solution features. Further, one

Regional Referral Hospital would be taken up for rollout, where a brief study would be done to

consolidate any specific requirements of these hospitals and accordingly ePIS would be

implemented with required customizations. Next a set of 8 health facilities will be taken up and

same process would be followed for ePIS implementation.

The entire implementation of ePIS in above mentioned Hospitals will be part of Phase 1 where

learnings from all these implementations, including stabilization period would help make the ePIS



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 5 | 101



more robust and user friendly and play a crucial role in widespread adoption of the new automated

ICT platform.

Implementation Timeline

It is estimated that with the above Hybrid approach for ePIS design, development and

implementation, the total implementation period would be around 3 years for country wide roll

out, including the stabilization period, with all defined functionalities and features. The detailed

implementation plan has been provided as part of this proposal.

2. Introduction and Context

2.1. Project Overview

Bhutan is currently undergoing rapid health and social transitions, as it is happening across the

world, due to rapid changes occurring in terms of new health technologies, the ever-improving

capability of medical personnel and, in turn, the demand for newer and better health technologies.

Bhutan’s healthcare system has recently realized the potential of ICT in completely transforming

healthcare delivery through healthcare facilities across the country. While the individual healthcare

institutions in Bhutan at all levels are addressing the issues of providing efficient health services to

their citizens, by implementing various programs and ICT initiatives, Electronic Patient Information

System (ePIS) is one of the initiatives by MoH, RGOB, that aims at increasing the availability and

accessibility of healthcare services for the citizens as well as usage and sharing of timely and

accurate health information at all levels across the country. It aims to enable the Ministry and

facility level administrators for quick decision making and optimal utilization of resources. ePIS is

envisaged to be a central initiative guiding and integrating all other programs and schemes

towards the achievement of envisaged targets and objectives of improving health care services

and its administration in the Bhutan.

ePIS initiative is envisaged to provide a comprehensive, integrated and automated platform which

can efficiently drive the inputs and processes leading to desired outputs and outcomes. It will

eventually help MoH assess the impact based on public health-related goals.

The purpose of this initiative is to implement a state-of-the-art ICT enabled Electronic Patient

Information System (ePIS) in order to improve productivity of the health institutions at all levels,

thereby improving public health services and bring administrative efficiency in the entire

healthcare ecosystem.

2.2. Key Focus areas of the Project

In view of the issues and challenges faced by various stakeholders, the proposed ePIS initiative

aims to provide a comprehensive IT enabled solution framework to help bring efficiencies in

functioning of healthcare facilities and delivery of healthcare services.

The below diagram represents the ‘key focus’ areas of the intended ePIS initiative by MoH, RGOB:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 6 | 101



Figure 1 Key Focus Areas

2.3. Business Strategy and Business Architecture of the Project

Strategy helps to establish the vision, mission & goals of Ministry of Health, Bhutan which is broadly

represented as below:

Core values aligning with the goals & objectives

Healthy Living

Technology

based

Person Based Care

Decisions driven by

data

Quality Healthcare

Disease Eradication

Better Health in

Communities

ICT enabled Healthier Bhutan

A nation with Best Health

Vision

Goals & Objectives

Improving performance

Compassion Equity Quality Economy & Out of pocket

Expenditure

Integrity Professional healthcare

Mission

Figure 2 Vision, Mission, Goals and Objectives



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 7 | 101



1. Vision: The Royal Government of Bhutan is mandated to provide free public health care

services to its citizen. The digital transformation of healthcare services with the

implementation of Electronic Patient Information System will enhance the efficiency of the

citizen-centric service delivery mechanism and ensure optimum utilization of the health

care resources thereby adding impetus in achieving the sacred mandate. MoH, Bhutan

envisages ICT enabled health system for making Bhutan ‘a Nation with the Best Health’

thereby ensuring access, equity and quality healthcare.

2. Mission: Ministry of Health aims at the following:

a. Imparting quality healthcare services in terms of modern medicine as well the

traditional medicines.

b. Support the provision of better health in communities along with promotion of

healthy living.

c. Ensuring sustainable, responsive, equitable, accessible, reliable and affordable

healthcare services for its citizens thereby providing better person-based care to

individuals.

d. Prevention, Control & Eradication of disease through efficient healthcare

ecosystem.

e. Empowering healthcare providers with use of technology & fostering technology

in patient care to bring positive change in the Healthcare services.

f. Enable the exchange of individual and aggregate data to help policymakers take

better informed decisions.

g. To make healthy & easy choices for all Bhutanese citizens and those residing in

Bhutan.

h. To support and empower various sectors in the government, private, civil society

Organizations, communities and individuals to engage in actions that promotes

their health.

3. Goals & Objectives: Ministry of Health aims to establish the core values of competence,

compassion, equity, integrity and quality while envisioning its goals & objectives as

explained below.

a. Improve physical, social, spiritual, mental and emotional wellbeing with a particular

emphasis on infants and children, pregnant women, youth in schools and religious

institutes and the elderly through efficient delivery of healthcare services.

b. Reduce the risk of major non-communicable diseases and promote prevention of

communicable diseases.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 8 | 101



c. Promote optimal nutrition to ensure the progression of the all Bhutanese from

healthy childhood to productive adulthood, and further on into healthy old age

thereby maintaining a healthy lifecycle.

d. Promote supportive environments that would improve health and happiness of all

segments of the populations living, working, studying and playing in urban and

rural settings by building a robust health ecosystem.

e. Reduce inequalities in health by provisioning equitable healthcare care services for

all.

f. Increase contributions of all sectors in promoting health and wellbeing, including

financial contributions.

2.4. Business Capabilities

A business capability, a key component of business architecture, is an expression of what the

Organizations (referred in here as hospitals) does and can do to achieve the envisioned goals &

objectives. Defining capabilities aim to devise an overarching plan of services to be offered by the

hospitals during the entire patient life cycle which is broadly represented below:

Figure 3- Business Capabilities



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 9 | 101



A typical service offering is comprised of several medical and non-medical services, each service is

enabled by a set of workflows involving a number of stakeholders and activities to provide the

service and each workflow is supported by a number of processes that facilitate the completion of

its activities. In the context of current operating model of the hospitals as indicated above, the

following four capabilities have been defined to encapsulate all the service offerings during the

patient lifecycle:

1. Medical Care Services relates to direct provision of care and treatment of patients

presenting with illness. They cover the workflow of patients through the respective out-

patient departments & in-patient departments. Medical care is aptly supported by the

other three capabilities which together form the pillars of imparting quality healthcare

services to the citizens arriving at the hospital.

2. Medical Support Services pertains to provisioning of medical care, diagnosis and manage

information gathered throughout the treatment. The services aim to manage the required

medical information throughout the patient encounter cycle of Register, Admit, Diagnose,

Treat and Discharge.

3. Business Services cover the services to relevant stakeholders thereby facilitating effective

delivery medical services. They cover the critical domains of Research, Business

Management, Financial Management & Human Capital Management.

4. Operational Services provide the required backend support for effective and efficient

functioning of the hospital. They cover the critical components of patient administration,

supply chain management & facilities management.

An overview of capabilities offered by Patient Information System is represented below:

Figure 4- Overview of Patient Information System

2.5. Business Functions

A business functions is a summarization of core functions required to support the identified

capabilities. It also helps to identify the functional owners accountable for delivering capabilities.

Business functions describes the roles that individuals and units within the business play in regard

Medical Care Services

Medical Support Services

Business Services

Operational Services



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 10 | 101



to meeting business objectives. Business functions provide an outlay of various services/modules

required to support identified capabilities. Business functions help to classify various services

associated with each capability like Medical treatment services, Surgical specialties services,

Medical treatment Support Services, Diagnostic Support Services, Medical Information

Management Services, Research & Education services, Business Management Services, Finance

Management Services, Human Resource Services, Information Technology services, Patient

Administration services, Facilities Management Services & Supply Chain Services. The different

business functions pertaining to each above-mentioned capability have been defined as below:

1. Medical Care Services is supported by the following two business functions.

a. Medical Treatment covers treatment to patients with illness pertaining to internal

medicines, medical specialties & traditional medicines. The approach in the

treatment of illness of patient is purely medical in nature.

b. Surgical Treatment pertains to operative treatment of diseases. The approach in

the treatment of the patient is purely surgical in nature.

2. Medical Support Services is supported by the following three business functions.

a. Medical Treatment Support helps in facilitating support for provision of care e.g.

provision blood & blood components, pharmacy, Dialysis etc.

b. Diagnostic Support relates to laboratory techniques, imaging, or physiological

testing for diagnosis and management of patients to operative treatment of

diseases.

c. Medical Information Management relates to the acquisition, storage, retrieval,

usage, and analysis of medical and diagnostic information of patients.

3. Business Services is supported by the following four business functions.

a. Research & Education refers to provision of healthcare research and education

thereby covering the knowledge management which aims to improve the learning

and innovation.

b. Business Management relates to the corporate level management of the business

capability. It covers the guiding principles along with compliance of the

Organization.

c. Finance Management pertains to ensuring the financial health of the Organization

covering essential processes of asset management, bank management & credit

management.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 11 | 101



d. Human Capital Management is related to the administration, performance

management, and resource planning of Organization personnel. It also covers the

critical aspects of talent management.

4. Operational Services is supported by the following four business functions.

a. Technology refers to the technology driven initiatives deployed in the Organization

that support an institution’s requirements. The processes associated with this

function covers the entire aspects of the PACS, Tele-medicine, asynchronous (store

and forward) and synchronous-real-time (video conferencing) communication

features for consultation (e.g., dermatological, mental patients, ortho, etc.)

between the users and specialists.

b. Patient Administration relates to the functions covering processing of patients in

OPD & IPD along with providing non-medical services during treatment from

entering to leaving the healthcare Organization.

c. Facilities Management pertains to back end operational facilities related to patient

care that enable Organizations to provide medical services. This functions also

covers the critical aspect of Equipment Management including preventive &

corrective maintenance.

d. Supply Chain Management is related to the provision of drugs, reagents & surgical

items that enable Organizations to provide medical services. It includes all aspects

of procurement, inventory management, Logistics, Warehouse Management &

Quality control.

The details of all the processes and modules under above categories are listed in Section 2.1 of this

document.

3. Proposed ePIS Solution

3.1. ePIS Application Overview

The ePIS solution framework is shown below:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 12 | 101



Figure 5- ePIS Solution Framework

The details of solution components are explained in below sections.

3.1.1. ePIS Core Application

The core ePIS application is envisaged to be a comprehensive, integrated, fully automated ICT

based platform to help transform the entire healthcare service delivery system through all the

health institutions run by MoH, RGOB. This will manage overall functioning of a government

healthcare institution including patient care, hospital administration and all the other

corresponding services and processes.

ePIS is proposed to be one core, automated, scalable and integrated software application suite,

deployed centrally at GDC, having a web portal interface accessible through internet and lighter/

offline version accessible to all hospital staff through Internet Broadband / LAN/ WAN / Wi-Fi as

available. Each of the hospital/ healthcare facility across the country will be connected to the core

central application hosted at GDC.

The application suite will be customized, configured and enabled for various requirements of

individual healthcare facilities according to the type of facility and individual facility requirements.

But the application will work on a common architecture, configuration and functional modules.

The application would be further designed to cater to offline functioning for various key users

through their end-point devices.

The core modular, fully integrated and automated software application suite for the ePIS will have

interface for various types of users and applications. The application and its functionalities will be

granular and modular enough for the administrators to enable or disable any particular



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 13 | 101



functionality or feature of ePIS at any healthcare facility in Bhutan at any given time as per their

requirement without the need for a developer/ code level change/ custom UI change.

3.1.1.1. Modules / Processes

The following four capabilities have been defined to encapsulate all the processes / service

offerings during the patient lifecycle:

5. Medical Care Services relates to direct provision of care and treatment of patients

presenting with illness. They cover the workflow of patients through the respective out-

patient departments & in-patient departments. Medical care is aptly supported by the

other three capabilities which together form the pillars of imparting quality healthcare

services to the citizens arriving at the hospital.

Medical Care Services is supported by the following two business functions.

a. Medical Treatment covers treatment to patients with illness pertaining to internal

medicines, medical specialties & traditional medicines. The approach in the

treatment of illness of patient is purely medical in nature.

b. Surgical Treatment pertains to operative treatment of diseases. The approach in

the treatment of the patient is purely surgical in nature.

The detailed list of Processes under each category are defined below:

Internal Medicine

Cardiology Endocrinology Gastroenterology

Geriatrics Traumatology Hepatology

Infectious Diseases Nephrology Oncology, Proctology,

Pulmonology

Rheumatology

Medical Specialties

Anesthesiology Dentistry Dermatology &

Venerology

Ear, Nose, Throat (ENT) Emergency Medicine General Medicine

Intensive Care Neurology Ophthalmology

Otolaryngology Pediatrics Psychiatry



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 14 | 101



Physiotherapy & Rehabilitation Infection Prevention and

Control

Obstetrics and

Gynecology

Audiology Speech Therapy

Community Health

Reception Antenatal Care Unit Ultrasonogram Unit

CHD Laboratory Pharmacy Consultation

Maternal Exercise Unit Adolescent friendly Health

Services EPI Unit

Post Natal Unit Family Planning Unit Newborn Examination

Unit

Lactation Management Unit Pap Smear Unit Colposcopy Unit

VCT Unit Oral Health Clinic Outreach Clinics

Service Coordination Unit

Traditional Medicines

Jamtse (Mild Enema) Shel (Purgation) Najong (Nasal Cleansing)

Kamkhab (Acupuncture)

Chulum/Langlum/Langduug

(Herbal Bath/Steam

bath/localized Steam)

Application

Chingduug (Herbal

Compression)

Ser Khab (Gold Needle Therapy)/

Ngul khab (Silver Needle

Therapy)

Numtshuk (Hot Oil

Compression) Tarr (Blood Letting)

Meybum 'Kam Bum' (Dry

Cupping)

Meybum 'Loen Bum' (Wet

Cupping)

Meytsa (Direct

Moxibustion)

Tshug Rig (Other Compression) Tradhen Serkhab (Gold Needle

Moxibustion) Rajib (Horn Suction)

Jukpa (Massage) Zhiney/ Meditation (Physical

exercises) & Semkham Labtoen

Chuyi Thruelkhore

(Affusion)

Chingdhug (Herbal Pack

Compression)

Duetap Lamlug (Appointment

System)

Drungtsho (Physician

Chamber)



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 15 | 101



Chubta/ Unitta (Urine Analysis) Niruha (Strong Enema) Laynga

Ngulkham Kham Jamchoead Chuuk (Emesis)

Surgical Specialties

Cardiothoracic Surgery Colon and Rectal Surgery General Surgery

Gynecology and Obstetrics Gynecologic Oncology Neurological Surgery

Ophthalmic Surgery Oral and Maxillofacial Surgery Orthopaedic Surgery

Otorhinolaryngology Pediatric Surgery Plastic and Maxillofacial

Surgery

Urology Vascular Surgery

Table 1- List of processes for Medical Care Services

6. Medical Support Services pertains to provisioning of medical care, diagnosis and manage

information gathered throughout the treatment. The services aim to manage the required

medical information throughout the patient encounter cycle of Register, Admit, Diagnose,

Treat and Discharge.

Medical Support Services is supported by the following three business functions.

a. Medical Treatment Support helps in facilitating support for provision of care e.g.

provision blood & blood components, pharmacy, Dialysis etc.

b. Diagnostic Support relates to laboratory techniques, imaging, or physiological

testing for diagnosis and management of patients to operative treatment of

diseases.

c. Medical Information Management relates to the acquisition, storage, retrieval,

usage, and analysis of medical and diagnostic information of patients.


Medical Treatment Support

Food and Nutrition / Dietary Blood Bank Dialysis

Pharmacy Medical Administration Nursing Administration

Forensics Emergency

Diagnostic Support



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 16 | 101



Clinical Laboratory/Pathology Clinical Neurophysiology Radiology

Endoscopy, Colonoscopy, ERCP

Medical Information Management

Health Record Management Laboratory Data Management Radiology Data

Management

Table 2- List of processes for Medical Support Services

7. Business Services cover the services to relevant stakeholders thereby facilitating effective

delivery medical services. They cover the critical domains of Research, Business

Management, Financial Management & Human Capital Management.

Business Services is supported by the following four business functions.

a. Research & Education refers to provision of healthcare research and education

thereby covering the knowledge management which aims to improve the learning

and innovation.

b. Business Management relates to the corporate level management of the business

capability. It covers the guiding principles along with compliance of the

Organization.

c. Finance Management pertains to ensuring the financial health of the Organization

covering essential processes of asset management, bank management & credit

management.

d. Human Capital Management is related to the administration, performance

management, and resource planning of Organization personnel.


Research & Education

Research Clinical Trials Knowledge Management

Business Management

Executive Administration Communications Legal/Regulatory

Management

Quality Management Risk Management

Finance Management

Budgeting and Planning Revenue and Expenditure Payments



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 17 | 101



Asset Management

Machinery Equipment Physical Assets

Healthcare Specific Assets Biomedical Equipment

Management

Table 3- List of processes for Business Services

8. Operational Services provide the required backend support for effective and efficient

functioning of the hospital. They cover the critical components of patient administration,

supply chain management & facilities management.

Operational Services is supported by the following four business functions.

a. Technology refers to the technology driven initiatives deployed in the Organization

that support an institution’s requirements. The processes associated with this

function covers the entire aspects of the PACS, Tele-medicine, asynchronous (store

and forward) and synchronous-real-time (video conferencing) communication

features for consultation (e.g., dermatological, mental patients, ortho, etc.)

between the users and specialists.

b. Patient Administration relates to the functions covering processing of patients in

OPD & IPD along with providing non-medical services during treatment from

entering to leaving the healthcare Organization.

c. Facilities Management pertains to back end operational facilities related to patient

care that enable Organizations to provide medical services. This functions also

covers the critical aspect of Equipment Management including preventive &

corrective maintenance.

d. Supply Chain Management is related to the provision of drugs, reagents &

surgical items that enable Organizations to provide medical services. It

includes all aspects of procurement, inventory management, Logistics,

Warehouse Management & Quality control.


Technology

Picture archiving and

communication system (PACS) Telehealth Alert management

Patient Administration

Patient Registration Out-Patient Department In-Patient Department



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 18 | 101



Patient Enquiry Appointments and Scheduling Bed Management

Bay and Queue Management Referral Management Operation Theater

Management

Grievance Management

Facilities Management

Parking & Protection General Store Central Sterile Services

Supply Chain Management

Inventory Management Warehouse Management Quality Management

Indent Requisition Supplier Management

Table 4- List of processes for Operational Services

3.1.2. ePIS Solution Features

3.1.2.1. ePIS lighter version

To support the functioning of the ePIS, when there is limited or no connectivity option, an “Lighter

Application” or “ePIS Lite” will be developed. A part of the core system functionality will be

provided as a lighter application hosted at the local server within hospital premises. The application

will have its own local database to store the transactional data and masters required for the local

application. This application will be built in a manner to support synchronization with central

database to avoid any duplicate data entry requirements and provide consistent information.

ePIS Lite is intended to be a lighter version of the main application which can process multiple

functionalities and records related to all key healthcare processes to enable the health facilities to

function independently if required. It will have the feature of getting synchronized with ePIS core

application on demand or on triggered event to synchronize data with ePIS application when

connected to the network.

In order to avoid the delay in switch over between the centralized core application and ePIS Lite in

the event of connectivity breakdown, it is required that the ePIS Lite is deployed in-line with the

centralized core application. In other words, the core transactions within the hospitals would flow

through the ePIS Lite first and then to the centralized Core Application, but for none critical

functions, the lighter version would need to sync with the main application. In the event of normal

connectivity, the system would automatically bypass ePIS Lite and directly access the central core

application for non-critical services only, while the critical services continue to function through

the lighter version of the application. In case of connectivity breakdown, the ePIS Lite would keep

processing the transactions without causing any delay at the front end. As and when the



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 19 | 101



connectivity is restored, the system would automatically connect to the central core application to

provide non critical function as well. The data from ePIS Lite would sync with the central core

application as soon as the connectivity is restored.

Local application will have the following features to operate independently without any

dependence on the network connectivity for all mission critical processes:

1. Master data management with persistent queue mechanism for local and central data

synchronization. Master data management will maintain ePIS core application and support

services which will eliminate the data inconsistency, data duplicity and facilities in

identification and merging of records

2. Hospitals will have the same version of localized and centralized application. Any version

upgrades will be uniformly deployed to all hospitals and the central application

3. Local application will have:

a. Master index

b. Terminologies

c. User access control and authentication details of that particular hospital/ facility

d. Master data of users

e. All core modules and processes applicable to the healthcare facility

Currently, only 3 Hospitals i.e. National Referral hospital and two Regional Referral Hospitals are

planned to have the lighter version of the ePIS deployed in respective Mini DCs. However, it is

suggested that all the other key healthcare facilities, especially the hospitals providing multiple

services, should also have the same deployed to enable their independent functioning without

relying on network connectivity all the time.

The application in smaller facilities can be installed on the entry level server, which will be

configured to function in offline mode as well, as per the services provided by respective HFs. The

hardware configuration of these devices has been shared separately.

Refer Section 5 of the report for more details on the Deployment Architecture.

3.1.2.2. ePIS Web Portal and Mobile App

The ePIS is planned to be accessed through Web Portal and mobile App. ePIS will be accessible

through a web browser via Internet and Intranet from within the healthcare facilities. The ePIS

web portal will have both static and dynamic content. The kind of information to be displayed on

the web portal will be managed and controlled through the ‘Application Admin’ and ‘Content

Management’ developed as part of the ePIS Solution framework, with an intention of making most

of the information available for public consumption through the web portal as possible.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 20 | 101



Apart from the core application suite and Web Portal, ePIS Mobile App will also be developed and

implemented, compatible with both Android and iOS. The overall functionality and features, as

mandated through RBAC, would be available over mobile app as well, with user friendly

navigational features and UI.

The mobile app for ePIS is planned to be generic mobile app for all users, providing standard

features, functionality and information about the healthcare services in Bhutan. The mobile app

may be downloaded by any user from the Android or Apple play store as applicable.

The developed mobile app will further provide the functionalities for HPs (Doctors, Managers,

Health Workers, Programs and other service providers) with which they can access and provide

service while outside the HF premises. These functionalities will be available to such users once the

user is authenticated through his / her login credentials. The mobile app will allow HPs to initiate

Tele / Video Consultation facility, with intended Patients, once the appointments are booked

through the App, and the solution will allow chatting, video consultations and Point to Point (P2P)

conference amongst HPs. However, the HPs would need to record the observations / diagnosis

made during such interactions using the e-Prescription / Clinical Decision Support system of ePIS,

for further record and reference about Patients health. Currently the recording of the video

consultation is not planned as part of ePIS project.

In order to engage patients, the mobile app will allow the access to hospital information,

healthcare advocacies and notifications, facility to make appointments, get appointment alerts,

notifications and raise complaints / grievances.

The Mobile app will be integrated with the core application and database for seamless exchange

and update of data / information.

3.1.2.3. Tele / Video-Consultation

As part of the ePIS, the Telemedicine / Teleconsultation / Video Consultation facility through the

automated set up is envisaged to be implemented in Bhutan. The guidelines stated by Government

regarding Teleconsultation, Video consultation and Telemedicine will be adhered to. With the

current setup, the Teleconsultation / Video consultation facility would be implemented and made

available.

Tele / Video Consultation will enable the use of telecommunication and Information Technology to

provide clinical healthcare from distance. It will help eliminate distance barriers and improves

access to medical services to needy an inaccessible population by connecting to patients using

telephone or video calling facility. It will improve the accessibility of patients and clinicians to

higher referral centers which may also serve as knowledge centers.

Advantages:

1. Eliminate distance barriers and improve access to quality healthcare services



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 21 | 101



2. Access to specialty consultation services in emergency and critical care situations where

moving a patient may be undesirable and / or not feasible

3. Reduce unnecessary travel of Patients and Healthcare professionals, thereby reducing

cost, time and effort for all

As part of the ePIS, the Teleconsultation / Video Consultation facility through the automated set

up is envisaged to be implemented in Bhutan. The guidelines stated by Government regarding

Teleconsultation / Video consultation will be adhered to. With the current setup of Devices,

Network and Application, the Teleconsultation / Video consultation facility would be implemented

and made available. The Tele / Video Consultation platform will be integrated with the other

modules of ePIS, doctor’s registry and with patient’s electronic health record.

The video consultation may be categorized in following two ways:

1. Real time i.e. Synchronous or Online, where the e-prescription / digital copy of the

prescription based on entries made by the doctor in real time, may be shared with the

patient through the system with information being shared over email and / or SMS with

downloadable link as soon as the consultation is over

2. Store and Forward i.e. Asynchronous or Offline, where the digital copy of the prescription

is generated separately based on observations of the doctor in a prescribed format (either

the physical prescription can be scanned and tagged, OR data entry of the notes made by

doctor may be entered in prescribed format which is further verified and authenticated by

the doctor), and then shared with the patient through the system or over email as

attachment. The information about the same may be shared through SMS as well with

instructions to access the prescription.

In either of the two methods above, the actual consultation, examinations and diagnosis i.e.

patient’s condition, symptoms and other critical observations related to investigations and

treatment etc. will be conducted using the device camera (laptop / Desktop Webcam) over the

available network. The observations will be recorded in ePIS using the Doctor’s console and e-

prescription facility.

There are two mechanism to initiate the tele / video consultations, once the appointment the

concerned doctor is booked through ePIS:

1. Use of external apps installed on Mobile Devices/ Desktops – Initiate consultations using

the pre-installed external apps like Google Hangouts, Whatspp, Facetime etc. while the

observations are recorded in ePIS

2. Inbuilt system plugin – Initiate consultation directly through ePIS using the video

consultation platform already integrated as plug-in while the observations are recorded in

ePIS

Many of the commercially available software applications provide either of the above facilities

which may be further explored and selected during the procurement of standard solution for ePIS



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 22 | 101



project. Further storage of video consultations will require additional support of IT infrastructure

and security provisions, both during storage and over the network, which is generally not the

standard practice hence not recommended.

Only e-prescriptions generated through ePIS will be used for any further references and record

patient’s health.

3.1.3. Additional Functionalities and Features

In addition to the above, following functionalities and features are proposed to be implemented

as part of ePIS:

1. Supply Chain – The centralized supply chain would also be automated and integrated with

ePIS. There is an existing system already operational i.e. E-BMSIS (ELECTRONIC BHUTAN

MEDICAL SUPPLIES INVENTORY SYSTEM), and ePIS would be integrated with the same for

seamless information and data exchange for maintaining uninterrupted supply of

medicines, equipment’s, supplies and consumables.

2. Repositories – Various repositories like Drug, Drug reaction, Investigative references,

Trauma, Blood Donors, etc. would be implemented

3. User Authentication – Authentication is the process of uniquely identifying an individual,

usually based on a username and password or Biometric / Facial recognition, as a valid

application User. A valid User for this application is one who has been set-up in this

application such that he/she can access the application as per rights / privileges assigned

to him / her. When ePIS is implemented and made live, the directory of all authorized Users,

hierarchy and level, role & purpose, access rights, privileges, etc., all would be configured

and tested thoroughly. Also, the roles and responsibilities of each User, based on user type,

level in hierarchy, designation etc. would be defined and mapped with each User created

in the system.

4. Content Management – A “Content Management System” (CMS) within the ePIS is an

important component, which will allow the designated administrators to dynamically

update elements / sections / contents / forms / formats / notices / figures etc. that change

regularly, without the constant need of a web developer or backend coding job. The CMS

would offer easy administration of the overall ePIS Application, simply requiring nominated

and authorized nodal members to log-on to a secure area of the Application and complete

simple web forms and upload to the centrally controlled database, so that the changes are

reflected throughout the Application pages / sections, as applicable. The formats for

various reports / notices and other communications like promotional messages would also

be designed through this module and uploaded on to the ePIS application.

5. Application Admin - As part of ePIS, it is required that there would be an UI Interface

provided for the Admin User, for User Management, Rights Management, and Master’s

Management for controlling list / field values, etc. The UI for Admin needs to be configured



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 23 | 101



as per the ‘ACCESS CONTROL’ requirement provided by health facilities / MoH and

configured at the time of acceptance of the ePIS application suite. And for every change

carried out during the Change Request (CR), the impact analysis with reference to the

Admin controls would be analyzed, discussed, approved by MoH and then implemented.

6. Document Management System – The proposed solution would support storing of various

documents/ reports in any type of electronic format including word processing,

spreadsheet, image, PDF, etc. A Document management system would provide storage,

versioning, metadata, security, archival as well as indexing and retrieval capabilities. The

proposed solution would support archival of digital documents in any format (like PDF,

PDFA, Word, Excel, Image, etc.), support roles and rights-based security where there can

be multiple levels of access right to the content like read, create, modify, delete, etc. The

proposed solution would support inbuilt “Document Image Viewer” for displaying image

document without native viewer. The proposed solution would support the search

functionality within the content. It would support search criteria like search by metadata

fields, content objects, document content, pages, etc. It would support full text search on

image and electronic documents.

7. GIS – It is important to map the location of all the healthcare facilities within Bhutan, for

ready reference of patients / citizen. This is expected to boost the real time decision making

and disease surveillance by storing, visualizing, analyzing, and interpreting geographic

data, mapping of Healthcare facilities across Bhutan along with types, services offered and

geographic distances, mapping of geographical groupings of patients across Bhutan, to

facilitate disease surveillance and epidemic / pandemic management, mapping of hot spots

for various communicable and non-communicable diseases, etc. for reference to potential

disease source and impact of environmental factors on the population

8. Biometric Authentication – The proposed ePIS to have facility to integrate with biometric

devices for biometric authentication of not only Users but also Patients. The biometric

authentication capability is envisaged to fast track the unique identification of an individual

and facilitate the working through ePIS.

9. Barcodes – Barcode solutions will help streamline the patient admittance process, track

medication and care admission, and identify patients throughout their entire stay. Barcode

wristbands are typically created at the point of admission, and specific patient information

is continually updated based on the patients’ needs. Medical records, medications and

specimen samples are tagged with a barcode label for doctors and nurses to easily scan in

order to trace critical patient information. The barcode technology makes sure the correct

treatment is administered to the right patient, ultimately reducing errors and ensuring

patient safety. Barcodes are also used in the registration slips provided to the patient at

the time of registration which will be further used to keep track of and record every activity

of any patient. Barcode solutions are also critical for workflow changes in hospitals and

healthcare practices.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 24 | 101



10. Audit Trail – Audit trail will be a detailed record showing who has accessed the system and

what transactions / operations have been performed by the concerned user during a given

period of time.

11. Enterprise Search – The integrated ePIS and database structure would ensure a one-point

stop search / enterprise search available to all the users.

12. API and Gateway Integrations – The API / middleware-based integration framework would

be implemented, to enable seamless integration and data exchange between various

systems / applications as required. The integration with external system is planned

through the Government Data Hub.

13. Community Health- The services provided by the Community Health Department

encompass cross-cutting areas of health promotion and disease prevention delivered

through fixed facilities and outreach services. Most of these services are an integral part

of primary health care rendered at the district health level. Reporting is done using Dhis2

and MCH tracking. It is suggested that the processes in the Community Health Department

which are not automated yet would be automated and then integrated with ePIS.

14. Alerts & Notification – The system will have the functionality to raise alerts and send

notifications to intended Users (Healthcare staff, Administrators, government Officials and

Patients) through E-Mail, SMS and Mobile App over the ePIS Portal. The ePIS is planned to

be integrated with SMS and E-Mail gateway to facilitate such alerts and notifications which

would be triggered (through automatic and manual triggers) based on specific events or

inputs from specific Users. E.g. Patients can get alerts about follow up, or collection of

investigation reports as soon as they are generated, or to HPs when a patient is registered

under their consultation or if the results show that the patients diagnosis is critical and

requires emergency services, or to Administrators if any event is escalated for their

attention and decision, etc. All such triggers will be configured as part of the workflow and

mapped through the Admin module as per defined Role Based Access.

15. HR Module: The ePIS shall also have HR module with which it can consolidate all HR activities

as per the standard mandated. The module shall get the user for the system (ePIS) from

CSIS/ZESt of RCSC but there should be provision for the hospital to register other staff not

available in the CSIS/ZESt such as the para regular, ESP, GSP etc. The module should also

be able to monitor job assigned, attendance, leave and other HR aspects required within

MoH, DHO and Hospital management. In the central repository, MoH managers and HRD

should be able to use this for annual transfer or HR need projection and publishing other

necessary reports on click of a button. The module should also capture short term training

and tours. It should have minimum requirements of Leave and Attendance System of MoIC

which is currently used in MoH and have lots of shortcomings and issues. The attendance

should be possible from either app, biometric, RF or certain device so that employees could

be managed efficiently. It should include a database of all HPs and MoH employees. Any

hardware requirement should be procured by MoH.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 25 | 101



3.1.4. Recommended Technologies

While the following technologies are not part of the ePIS project requirements, TTPL would like to

recommend these technologies for additional enhancement at later phases.

1. Health Information Exchange – It is proposed to set up the policies, guidelines, rules and

regulations for ‘Health Information Exchange’ (HIE) as part of Bhutan ePIS project.

In addition, the Consent Management Framework would be implemented as part of ePIS,

to facilitate exchange of digital healthcare information within the healthcare ecosystem,

which is crucial in the process of complete automation. Following are the broad

considerations for HIE:

a. Enable access to & retrieval of health data between stakeholders

b. Provide safer, more timely, efficient, effective and equitable patient care

c. Adds value through standardization of data

d. HIE needs to operate with a patient’s consent

2. Templatized e-Prescription & Clinical Decision Support System

e-Prescriptions and Clinical Decision Support System (CDSS) are some of the very

important feature and functionalities envisaged for ePIS to facilitate the working of

doctors / specialists at any level and at any healthcare facility. A CDSS supported by e-

prescription, as a health information technology system, is required to be designed and

implemented, as part of ePIS, to provide doctors / surgeons / physicians / specialists and

other health professionals with a tool, to assist with clinical decision-making tasks

E-prescribing allows a physician, nurse practitioner, or physician assistant to electronically

transmit a new prescription or renewal authorization to a community or mail-order

pharmacy. It outlines the ability to send error-free, accurate, and understandable

prescriptions electronically from the healthcare provider to the pharmacy. E-prescribing is

meant to reduce the risks associated with traditional prescription script writing. It is also

one of the major reasons for the push for electronic medical records.

3. Computer on Wheels (COW) – Computers on Wheels are PCs or laptops that are mounted

on a mobile cart. It is proposed that COWs are used in hospitals by medical staff to track

patient admissions and records, administer medicine and much more. Most COWs are

equipped with EMR at bedside and have access to DSS systems which means the nurses

can create and edit quickly and in real-time. COWs can connect to diagnostic equipment,

wirelessly connect to hospital network to retrieve patient info, show lab results and can be

used to store medicine etc. The importance of COWs in medical setting is critical to the

success of its medical staff. The ability to move the cart gives caregivers more opportunity



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 26 | 101



to engage with patients and worry less about technology. The required hardware and

software need to be purchased separately by MoH if it is decided to be implemented.

4. Digital Pads, Pens and Voice Over Text – This technology is proposed to be utilized be any

healthcare staff – Doctors, Nurses, staff, etc. and can be used across different

functionalities like Dial-In-Pharmacy, Electronic Prescriptions, Prescription Label Reading,

Appointment reminders and Health Monitors for patients. In critical moments, medical

devices can benefit greatly from having voice capabilities. From issuing step-by-step audio

instructions on how to use a life-saving AED machine to be instructing medical personnel

on how to assemble complicated surgical devices to enabling hospital patients to call for a

nurse, text-to-speech embedded devices combine intelligent design with methods that

enhance efficiency. The required hardware and software need to be purchased separately

by MoH if it is decided to be implemented.

5. Self Help Kiosks & Digital Display Boards – The self-help Kiosks and Digital display boards

are included as part of ePIS and would be integrated with the proposed solution, with

centralized “Content Management” console. The new technologies adopted in

manufacturing of self-help Kiosks, specially demonstrating the touch-less capability as

much as possible, would be preferred for implementation in Bhutan. The required

hardware and software need to be purchased separately by MoH if it is decided to be

implemented.

6. Digital tagging of samples for medical research – It is proposed to have feature in ePIS to

allow digital tagging of relevant samples and images for future medical research and

education and keep a log / repository of all such samples. The required hardware and

software need to be purchased separately by MoH if it is decided to be implemented.

3.2. Technology – Solution Architecture

3.2.1. Technology Solution

The proposed solution described herein will detail the design approach, components and technical

architecture to implement the ePIS Enterprise Portal Framework. The solution proposed is

articulated keeping the following design considerations in mind.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 27 | 101



3.2.1.1. Architecture Vision and Principles

1. Scalability: The System is designed to scale both horizontally and vertically by adoption of

a loosely coupled architectural paradigm. A Micro service-based approach with clear

separation of Data Access, Business Processing and Data Presentation concerns via

creation of Composite services using Granular Services (Stateless REST APIs) is central to

the proposed system. This provides ability to scale up infrastructure (containers) for

individual components or modules of the system on demand, as opposed to an overall

system upgrade with higher costs. Asynchronous processing of long running processes

and 3rd Party integrations will augment system capability, scalability and reduce response

time. This approach will allow for component level tuning, analysis, refactoring and

upgrade. The Data architecture implements robust Data indexing and archival processes

to support consistent performance with increasing data volume. Elastic Search and

Caching augmentation will ensure faster retrieval and reduce complexity and business

logic coupling at application layers.

2. High Availability: The solution components will be deployed to multiple nodes in a cluster

environment, which will provide high fault tolerance and availability. Also, a DR setup is

proposed to be set up for business continuity. A subset of critical functionalities/processes

will be deployed at the local centers (hospitals and medical centers) to overcome the

scenario of total central infrastructure failure.

3. Security and Privacy: The system deals with sensitive data from multiple units in house and

3rd party stakeholders like hospitals, medical centers and patients. There could be serious

Principles

Auto Scaling

Open API

Performance

Integration Friendly

Reusable Compone

nts

Highly Available

Resilient

Secure by Design



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 28 | 101



security threats to the EPIS in general from external and internal sources. The system

design provision for Robust Security as a core feature for Data at Rest and Data in Motion.

Configurable Authentication and authorization with internal and 3rd Party systems will be

integrated. The System implements a Governance model for Data access to revoke and

provide grants to partial contents of a system record. Strong end to end encryption of data

(Data at Rest and Data in motion) will be implemented using applicable measures of strong

benchmarked cryptography, audit trail, monitoring, throttling and robust compliance

processes. System restoration, Impact isolation and recertification of data in eventuality of

a Data breach or Security incident is also an inherent feature of the system.

The Application Programming Interfaces (API’s) exposed by the system will be through the

API gateway (Edge Service) for the common concerns which are inherent for every micro

service like CORS, authentication, and security so all common aspects will be applied on

each request, and if any changes occur in the future, we just have to update the business

logic of this Edge Service with no changes in individual micro services.

The data in motion is secured using secure TLS layer and Data in Rest is secured by using

strong server-side encryption algorithms.

4. Reliability: Given the dynamic, sensitive, legal and financial nature of the ePIS system, the

sanctity of System Records and Data accessed through the system is of paramount

importance. Responsibility of Data validation and Data integrity will be restricted to

defined Core System components. All System of Records will have clear Audit trail and

anomaly routines will be set up for early detection and warnings. System will look to

achieve a desired RPO (Recovery Point Objective), RTO (Recovery Time Objective) and

concurrent transactions while maintaining transactional integrity with appropriate

queuing, messaging, retries and event implementations.

5. Flexibility and Extensibility: The system is designed as an extensible platform over which

multiple applications can be integrated and composed. The Core platform layer exposes

Data access, Workflow and Rule engine features as REST APIs (Open Standard). This allows

a diverse set of independent applications to be built using these APIs. These federated

applications thrive in an ecosystem where each of them can be extended, enhanced and

integrated independently thereby allowing for rapid turnaround in inducting the dynamic

requirements both in terms of scale and functionality.

The Core platform will ensure interoperability of functionality with 3rd party systems. This

is achieved through provision of a Datahub/Enterprise Service Bus (ESB) in the

architecture.

6. Maintainability: Each of the components can be monitored in a non-intrusive manner and

metrics obtained such that real time analytical views can be pulled. This is done via usage

of monitoring tools, log analysis both at Network and Application Module level. The

System enables Module level issue debugging in a switchable and secured manner with

proper access controls.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 29 | 101



Interfacing Operation Support applications will be deployed to enable deployments, log

analysis and metric visualizations. Automated system metric reports will be published with

respect to Performance, Resource Utilization along with configurable alerting thresholds.

The proposed Architecture enables a layered approach to test the system components

where eco system components can be stubbed, allowing for more agility, reduced inter

team/application dependence, faster issue detection, analysis and mitigation.

7. Reusability: The DRY (Don’t Repeat Yourself) principle of architecture design is being

employed and reusability is factored in the solution design. The currently running bespoke

developed modules which can be customized to cater to the requirements of ePIS

Enterprise Portal Framework. This will ensure a faster time to market for the system.

8. Interoperability: The entire system/subsystem would be interoperable, in order to support

information flow and integration. Operating systems, database and storage technologies

from several vendors must interact well with each other. These systems would support the

open architecture solutions such as XML, LDAP, SOAP, etc. where information/ data can be

ported to any system, whenever desired.

9. Resiliency: Circuit Breaking Mechanisms will be used for making the architecture resilient

to failures. These components provide fault tolerance, seamless failover and graceful

handling for non-responsive or error throwing services, thereby ensuring common

contracts in the micro services ecosystem. This will also ensure that there is no single point

of failure in the system. This component monitors underlying services health, redirects

subsequent requests to erring services to a fall back implementation. It monitors the

defective service and restores calls once the fault is corrected.

10. Performance: Infrastructure and networks would be designed to support performance as

per the agreed Service Levels. The application would be tested to identify and mitigate

performance issues. The system infrastructure would be architected considering failover

requirements and ensure a single server or network link failure does not bring down the

entire system. The platform would support effective disaster recovery.

Leading technologies has been proposed for solution to ensure high performance. Design

would ensure that performance of various modules (especially in case of disaster) are

independent of each other to enhance the overall performance. The solution design would

cater to the following:

a. Modular design to distribute appropriate system functions on web and app server

b. Increase In-memory operations

c. Reduce number of I/O operations and N/w calls using selective caching

d. Micro-services-based architecture and container-based deployment along with

container orchestration for auto scaling using Docker containers and Kubernetes.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 30 | 101



3.2.1.2. Design Considerations & Approach

To cater to Functional and Non-Functional Requirements, following design considerations will be

employed as part of solution:

Figure 6- Design consideration

1. Scalability

The Architecture platform is designed to scale horizontally using elastic extensible

capabilities of Container Orchestration. So, the Applications platforms can be scaled in

many instances during peak hours, while brings the instance numbers down when the

loads are not expected to be high. The solution is designed on open source platform to

ensure no lock in with proprietary technology to further facilitate scaling. The scale up

methodology will follow the rules as below:

a. During the design and implementation of services, the following guidelines will be

followed

i. Utilization of hardware resources

ii. We plan to have a loosely coupled layer architecture

iii. The Application would be microservice enabled

iv. The Application is capable of exposing services through lightweight

Restful APIs.

v. The system supports horizontal scaling



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 31 | 101



vi. Data access and storage in an efficient manner

vii. The system sits on top of an Elastic infrastructure which can grow and

shrink on demand basis. This helps to optimize the use of resources.

viii. Use of distributed caching helps to reduce the database communication

and provide a quicker response time

ix. Use of rule based and workflow-based development which provide

configurability to the system.

x. Optimization of Performance

xi. Application can be hosted on cloud that leverages the greater efficiency

with less cost. This will help to optimize the resources and also can be

scaled to many instances on higher loads

xii. Designed API and horizontal scaling will help to quickly scale up during

unexpected, large web traffic

xiii. Reduce write requests by using messaging queue to process

asynchronous requests

2. Unbundled

Define unbundling or the loose coupling of services across the entire system in different

areas.

a. Platform Services

i. Telemetry (Audit Journal)

ii. Event

iii. Content

iv. Search

v. Caching

vi. Communication (Mail, SMS communications)

vii. Notifications

viii. Identity & Access Management

b. Atomic Services

i. Deliver one and only one purpose



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 32 | 101



ii. Be removable and replaceable independent of other elements

iii. Be reusable across applications/solutions, contexts, domains and even

platforms

c. Composite Services

i. Delivers a cohesive set of purposes

ii. Using an assembly of services & service components deployed together

in a single service

iii. Access through API's

iv. Be removable and replaceable independent of other elements

3. Layered Approach

The solution will follow the layered architecture and adhere to the following guidelines

a. All the modules in the Portal layer will interact with Service layer through API's.

b. All the process modelling, orchestration and routing will be done in the Service

layer. The Portal layer could directly talk to Service layer where direct service calls

are required

c. Atomic and composition services will be implemented in Services layer and will

expose standard REST API's using the Open API 3.0 standard.

d. The Content Management layer is used to store and manage content for the portal.

e. The BPM layer is responsible for modelling business processes and storing rules.

f. The Persistence layer will be storing all the data related to Content Management,

Microservices, Documents.

4. Openness: Openness in the platform is critical to ensure

a. Reuse of existing open source software or elements

b. Enabling others to reuse, extend, and create solutions

Following guidelines will be followed in the platform design and implementation

a. Use open source software's and wherever we have developed a good service that

could be open sourced for wider industry benefit, make the source code available

to public via repositories like GitHub



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 33 | 101



b. Use Open APIs to enable our platform and features team to build additional

services and extensions faster, leading to faster contextualization and solution

delivery

c. Use open standards and frameworks to ensure the design is vendor neutral. This

allows the software and hardware of the platform to evolve as the standards

themselves evolve.

d. Open up the data on the platform with applicable constraints of ownership,

consent and privacy, to allow faster decision making and necessary corrective

actions.

5. Configurability

a. Configurability makes the platform highly reusable, improves usability and

enforces a substantially lower total cost of ownership as a result of its simplicity,

flexibility, and adherence to standards

b. Configurability is required across the layers and provided below are few

configurations to be considered

i. Presentation: Info displays, Navigation, Interaction and Permissions

ii. Service: Process flow, orchestration, routing, rules, lookups, parameters

iii. DevOps: DevOps pipeline, Deployment templates

6. Event Driven

a. Events are both a fact and a trigger. Something that has happened, expressed as a

notification

b. Event types: Business, Operational, Technical

c. Event Service API will be provided to publish and subscribe to an event (uses Kafka

as underlying implementation)

7. Approach towards Peak load handling

We understand high volume of user request will hit the system on peak hours and the

system success depends upon its successful load management. To achieve this technically

we plan to perform the following activities

a. Distribution of Load through load balancer

b. Availability of DC – DR on HA mode



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 34 | 101



c. Use of light weight REST API based data exchange which uses less network traffic

d. Proper use of session management

e. Use of distributed caching with Redis

f. Use of In-memory processing

g. Use of Node JS based light weight front ending which load 5 times quicker than

conventional pages

h. Reduce memory leakage through proper event management and exception

handling

i. Use of distributed messaging like Kakfa to increase persistence and reduce data

loss.

j. Efficient use of web session management

8. Approach towards Rapid Development

We understand all the modules of the application needs to be developed within limited

time. To increase the productivity, we plan to use the following approach

a. Use of reusable digital framework like Authentication framework, rule engine,

document management framework

b. Dynamic Form builder

c. Dynamic workflow generator

d. Dynamic reporting template designer

e. Automat the development process through the use of DevOps

9. Multi-Tenant

a. Multiple applications running on a single platform and scaled in and out in a

seamless fashion there by achieving scalability on demand.

b. Strategy on the application scaling to be designed based on system peaks on

critical dates and time periods.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 35 | 101



3.2.1.3. Technical Architecture Components

Figure 7- Technical Architecture Components

Angular JS

Zuul

ReactJS/ Native

Spring Boot

Legends

Node JS Key Cloak

J BOSS Fuse

PostGreSQL

Alfresco

Redis Cache

PentahoMongo DB

Figure 8- Legends



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 36 | 101



The architectural considerations described above have been considered in the proposed solution.

Core Design principles of a micro service-oriented platform with an ‘N’-tier implementation forms

the architectural base of the solution. The solution will provide Open APIs (Application

Programming Interface) to all its ecosystem partners in order to allow other 3rd parties to develop

applications and hence be able to add to the existing capabilities. These Open APIs are RESTful

APIs that can be used to further develop mobile applications, web applications and help integrate

with other systems. Other agencies will be able to query and integrate with the ePIS system

Detailed description of the layers is provided below:

1. Presentation Layer

A custom React JS, and HTML5 based installation will host a suite of Web facing application

sites which will use the application micro services for authentication, authorization and

core business logic execution.

These microservices will be built using NodeJS and Spring Boot as the framework. This will

ensure abstraction and encapsulation of security processing and core business processing

from end user device applications. The web applications will provide the User Interfacing

features only and orchestrate the execution of Application Service components.

The Enterprise Portal Framework will present following functionalities at a high level.

a. Reports and Dashboards

The portal layer will host the Analytical reports, predictive analysis reports, Drill

down dashboards generated through Analytics layer based on the user

requirements. The reports generated can be downloadable in different formats

like PDF, CSV and HTML. And the system will have an extensible API for developing

custom reports.

The system will also be able to import data from external databases or any other

file format based on the user requirements, as well as the user can upload data in

the system based on user requirements.

b. Enterprise Search

Enterprise search component will used to search in many orders of magnitude of

unstructured/structured documents along with their metadata, content and

information which resides in the system.

The Search process primarily has three steps involved in building a unified index of

heterogeneous enterprise data namely: -

i. Gathering



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 37 | 101



ii. Extracting and

iii. Indexing

Gathering of information will be done from the plethora of enterprise software

applications which may be deployed at an Organization, through the use of

appropriate APIs or adapter services. So-called “enterprise software applications”

include portal and other periphery systems integrated with the EPIS Enterprise

Portal Framework.

Extracting (or filtering) will encompass retrieving text and metadata from binary

documents such as PDFs and office documents, other information sources and

send the same to the indexing utility so that appropriate meaning full indexes can

be created.

The purpose of indexing is to optimize speed and performance in finding relevant

documents for a search query. Without an index, the search engine

would scan every document in the corpus, which would require considerable time

and computing power.

Elastic Search will be used to enable enterprise search.

c. Transactional Interfaces for Cross Cutting Modules, Vertical Modules and

Traditional Medicine Modules

These are the screens/interfaces which are required for the stakeholders to

perform BAU tasks. The presentation layer will fetch/update the transactional data

by the virtue of calling relevant APIs from the API Gateway layer. Field level

validations will be part of these interfaces.

d. Governance Interfaces

These interfaces of portal will provide the authorities, admins to configure and

monitor the system. These will have periodic alerts displayed to give the admins an

indication of the systems performance. These interfaces will interact with the APM

tools to seek the information. All Master data updates are also performed through

these interfaces.

e. Web Session Management

The portal layer will also be responsible for managing the session information for

the users accessing the ePIS Portal.

User session will be managed in Distributed cache. After user is successfully

authenticated an entry will be made in Distributed cache with key as username and

module combination and value as frequently accessed user information like session



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 38 | 101



id, name, role, list of entity id and mapping values to which user has access to, etc.

Time to live or session expiry will be set to a session time out period - 15 minutes

(configurable) and after this time the token will expire. Session data will be purged

on auto expiry of session or if user selects to logout in the portal.

For authorization of web request, portal will first check if the session id for the user

name is valid and then use the role to check access to user action and URL user is

attempting to access, and then check if user has access to the entity for which user

is requesting action, before providing access to the restricted feature. Timer based

client-side JavaScript will check if user is idle for 10 minutes (configurable) and

prompt user that session might expire. If user chooses to extend session, session

will be extended further by session time out period. If user does not respond in 3

minutes of launching of the alert, the script will post request to server to expire

session. Post successful authentication if application finds existing user session the

old user session will be expired, and new user session will be created.

i. Before login

▪ Check if no. of user logged in is > allowed count, do not allow to

login

ii. User login

▪ Check username present, if not present, create auth token; create

username; increment user counter

▪ If present, find auth token, delete this auth token, create new auth

token, update auth token to username

iii. User session expires

▪ Auth Token gets removed

iv. User logout

▪ Delete auth token, decrement counter

2. Services Layer

Each of the core modules in the system is designed to expose data via REST web services

using which functionality for application level modules can be extended.

a. The Core Data Access Services will be hosted here. Access to Persistent Storage

layer (Data Store) is restricted to this cluster. Data access is restricted to the core

API layer and this will ensure data integrity, security and performance as the

concern is delegated to defined modules rather than directly coupled with



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 39 | 101



application logic as in a monolithic architecture. Non-functional Performance

tuning and improvements can be promoted without impacting the entire system.

b. The Application Business Services will also be hosted in this Cluster of machines.

Data aggregation responsibilities and business implementation are delegated to

these services which can then implement the ever-changing requirements with

greater control and agility, while also enabling reuse.

c. To make the micro services fault tolerant the circuit breaker design pattern will be

used. The Circuit breaker pattern helps to prevent such a catastrophic cascading

failure across multiple systems. We will wrap a protected function call in a circuit

breaker object, which monitors for failures. Once the failures reach a certain

threshold, the circuit breaker trips, and all further calls to the circuit breaker return

with an error or with some alternative service or default message, without the

protected call being made at all. This will make sure system is responsive and

threads are not waiting for an unresponsive call.

d. A Discovery Service running on the cluster will service as directory lookup for

service availability and instance health. Application instances on deployment and

spawn will register with the Discovery service before being able to service

requests. The Application and Core Platform Services can be scaled logically and

physically with multiple instances of each service being deployed and even hosted

in physically separate machines. Every Micro service will register into

the discovery server and discovery server knows all the client applications running

on each port and IP address.

e. Containerization

Docker Containers would be used to package and deploy the micro services.

Docker images are built for a micro service which encapsulates the entire

environment definition and dependencies required to seamlessly install and deploy

the micro services irrespective of the underlying operating environment specifics.

This ensures a consistent environment from development to production.

Environment specific nuances/issues are brought to light very earlier in the

development process thereby mitigating a practical risk and dependency in the

typical SDLC.

We propose to implement a “Dockerized” environment for deployment of the

micro services. A Kubernetes topology will be implemented to group relevant

Services in a manner such that adequate instance redundancy is provided for every

service. Docker Nodes allow for bifurcated allocation of available infrastructure

resources to a group of application services for execution, automated spawning,

balancing and monitoring.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 40 | 101



Figure 9- Containerization

Docker implementation overview diagram

For managing and deploying micro services, Docker is an excellent tool. With the

help of Docker, a microservice can be broken down into processes running in

separate Docker containers, also it can be specified with Docker files and Docker

Compose configuration files. Along with Docker, Kubernetes will be deployed and

collaborated. With the help of Docker, we can take things a step further and run

multiple software stacks side by side avoiding the mix-up of dependency versions.

Docker capabilities which can be utilized for the ePIS solution is provided below:

i. Configuration Management: As using the mechanism of Docker files and

Docker-compose files, the configuration of environments can be

managed as code. So, with the help of Docker, configuration

management can be handled through existing version control tools

already used by development teams.

ii. Docker Files and Version Control: The files that Docker uses to build,

ship, and run containers are text-based definition files and can be stored

in version control. There are different text-based files related to Docker

depending on what they are used for in the development pipeline, which

are provided below:

▪ Files for creating images: Docker files, docker-compose.yml,

entrypoint.sh, and configuration files

▪ Files for deploying containers or services: docker-compose.yml,

configuration files, and run scripts



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 41 | 101



iii. Resource Efficiency: With the help of Docker, Process level isolation can

be achieved, and usage of the container host’s kernel is more efficient

when compared to virtualizing an entire hardware server.

iv. Portability: With the help of Docker all the dependencies for an

application are bundled in the container. This means they can be easily

moved between development, test, and production environments.

v. Continuous Deployment and Testing: Docker has the ability to have

consistent environments and flexibility with patching, this feature make

Docker a great choice for teams that want to move from waterfall to the

modern DevOps approach to software delivery.

vi. Continued Development Methodology: Containerizing an application

that has ongoing development

The developed Microservices will be deployed on the Container technology

platform. Kubernetes will be used for container cluster management as which

container to run on which node (scheduling), how to increase/decrease the

number of running containers according to the loads of services. During peak

loads, more pods will be instantiated and once the peak is over, they will be scaled

down.

Kubernetes Orchestration will enable following Features:

i. Micro services by breaking an application into smaller, manageable,

scalable components that could be used by groups with different

requirements

ii. Horizontal scaling in which additional or fewer replicas of the pod could

be run using auto scaling

iii. Higher resource utilization and efficiency

iv. Fault tolerant cluster in which if single pod fails another is started and

replaced automatically

f. API Gateway

The APIs exposed by the micro service cluster can be accessed by the client

application layer via the API Gateway. The API Gateway would be responsible for

looking up the Service Catalogue from the Discovery Service and load balancing

the Application Services. The API Gateway abstracts the internal communication

and messaging protocols in the Application service and Core Platform Service

implementations from the Application Aggregation services. This provides a

Unified interface and Protocol to the Composite Service Layer/ Consumer



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 42 | 101



applications. Internal workings and compositions of the Application services are

completely abstracted from the Consumer applications.

It provides service authentication, client authorization (whitelisting), client rate

limiting (throttling), monitoring, response caching. Zuul API Gateway service will

be leveraged for the same.

i. API Gateway includes policies which defines API (request, response,

error), API Keys, API Security Policies, audit etc.

ii. Integrates with Access Management solution to provide API

Authentication and Authorization. Protected APIs end points will be

authenticated by generated token

iii. Policies are stored in In-built database.

iv. Once request is authorized API gateway will route response to Core API

Engine cluster and return the response back to client application

v. API Gateway stores system logs, application logs, audit logs in local

storage and have provision to push to Centralized log server

g. Process flow API scenarios:

i. Authentication

We propose using Token based approach inside the API Gateway to

perform authentication for each API call. Mainly, whenever Consumer

sends a request with the credentials combination of CLIENT_ID and

CLIENT_SECRET for authenticating their identity, the API Gateway will

validate these credentials; If the user is authenticated, then request will

be forwarded to the Downstream micro service. Micro service will

validate the username, password against LDAP user store for Token

generation. Generated Token will be stored in in-memory database Redis

cache, along with its expiry time.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 43 | 101



Figure 10- Authentication

ii. Authorization and Accessing APIs

Once Token is generated using Authentication call – Consumers are ready

to invoke APIs. As part of the all requests that are coming to Gateway will

have CLIENT_ID and CLIENT_SECRET headers and values for

authenticating their identity; in addition, Token generated using

Authentication will be sent in every request by Consumer. API Gateway

will validate CLIENT_ID and CLIENT_SECRET and forwards the request

with the Token to Micro services. AuthFwk module will validate the

Token and also checks whether the Consumer is allowed to access the

API. If Authorized, API will be invoked, otherwise Unauthorized error

message will be thrown.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 44 | 101



Figure 11 Authorization and Accessing APIs

In highly secured transactions with the banks, instead of Token based, consumers

to send the username and password in addition to the CLIENT_ID and

CLIENT_SECRET

h. API Monitoring

Centralized logging and audit trail for every API call is implemented via usage of

Spring Cloud Sleuth. This will ensure creation of common distributed data models

also performance monitoring and rapid issue resolution and debugging. This also

common traceability across applications and services which are truly independent

but communicate with each other via HTTP.

i. Configuration Management

This component allows separation of configuration dependencies from the core

source code, allowing for robust and secure control and versioning on

configuration metadata e.g. ports on which each of the micro services will run,

properties configuration, service registry configuration etc. This ensure a seamless

promotion of code and configurations between dev, test and production

environments.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 45 | 101



All the properties that will be needed by the integrated EPIS System will need to

be hosted and provided from a single service. These configuration properties will

be maintained in the database. The credentials and other secure property values

will be symmetrically encrypted and stored

The config reader Service/application will get the config database properties from

a properties file and then decrypt config property values and is returned to the

calling microservices.

Figure 12 Configuration Management

j. Schedulers

Scheduled processes deployed in the system also perform business logic and the

logic would be performed using the APIs as is used by the online consumer

applications. This ensures Data integrity and consistency of records through

multiple channels of access. The Scheduled processes will also help in performance

and availability of the system when the API calls are too heavy to fetch the real time

data. For example, for complex Reports and Dashboards, for the reporting

application available in near real-time fashion, the schedulers will be employed to

store the data in Reporting Storage /Data Warehouse.

We propose to use Spring Batch framework, an open source framework for batch

processing – for executing a series of complex jobs requires high processing in

Asynchronous mode. Spring Batch provides classes and APIs to read/write

resources, transaction management, job restart and partitioning techniques to



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 46 | 101



process high-volume of data. A batch process will be able to handle bulk data and

runs for a long time. Batch framework will be used in the

i. Time-based events such as periodic calculations.

ii. Periodic applications that are processed repetitively over large datasets.

iii. Applications that deals with processing and validation of the data

available in a transactional manner.

Following are the notable features of Spring Batch:

i. Flexibility: Spring Batch applications are flexible. You simply need to

change an XML file to alter the order of processing in an application.

ii. Maintainability: Spring Batch applications are easy to maintain. A Spring

Batch job includes steps and each step can be decoupled, tested, and

updated, without effecting the other steps.

iii. Scalability: Using the portioning techniques, you can scale the Spring

Batch applications. These techniques allow you to

▪ Execute the steps of a job in parallel.

▪ Execute a single thread in parallel.

iv. Reliability- In case of any failure, you can restart the job from exactly

where it was stopped, by decoupling the steps.

In addition to these, Spring Batch applications support

i. Automatic retry after failure.

ii. Tracking status and statistics during the batch execution and after

completing the batch processing.

iii. To run concurrent jobs.

Following figure shows a high-level solution for the same:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 47 | 101



Figure 13 Schedulers

Scheduler Architecture

In ePIS all Batch job instances will be invoked using the Quartz scheduler, and

Scheduler jobs configuration is available in PostgreSQL DB. Quartz is a job

scheduling library that can be integrated within any Java application. Quartz can be

used to create simple or complex schedules for executing multiple jobs; jobs whose

tasks are defined as standard Java components that may execute virtually anything

you may program them to do, in our case Quartz Scheduler invokes the Spring

Batch Job instance. Spring-Batch job will have Reader, Processor and Writer

configurations to perform the specific job needed.

i. Service Discovery

A Netflix Eureka Discovery Service running on the cluster will serve as

directory lookup for micro service API availability and instance health.

Application instances on deployment and spawn will register with the

Discovery service before being able to service requests. The Application

and Core Platform Services can be scaled logically and physically with

multiple instances of each service being deployed and even hosted in

physically separate machines.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 48 | 101



Figure 14 Service Discovery

Service Discovery overview diagram

ii. Event Based Messaging (Kafka Queue)

There are multiple microservices in the EPIS system which while

processing the information will generate various events, which are

applicable to other services in the landscape.

A schematic diagram is shown below:

Figure 15 ePIS System Schematic Diagram



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 49 | 101



Communicating microservices in ePIS will persist the data in the data

store and send a message on Apache Kafka with control information to

trigger other microservices Processing.

Various consumer groups are implemented as microservices using Java

Platform which can be scaled according to the processing load. The

microservices will pick the messages for processing from the respective

queues.

Apache Kafka which is a distributed messaging platform is being used in

the EPIS Solution for asynchronous messaging to achieve massive

scalability.

A Kafka cluster consists of multiple servers where each server is called a

broker. Each broker in the cluster is uniquely identified by a broker_id and

has an associated port and log directory. Messages in Kafka are

categorized into topics. The closest analogies for a topic are a database

table or a folder in a file system. Topics are additionally broken down into

a number of partitions.

Figure 16 Kafka Components

3. Database Layer

These Persistent Storage components are deployed in an Active – Active Cluster with

asynchronous streaming to ensure desired RPO of and RTO. PostgreSQL Database



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 50 | 101



instances will be used as Persistent Storage for Master Data and transactional data. Clear

separation of transactional and reporting data, automatic scheduled movement from OLTP

to OLAP database will be implemented through the use of web services.

PostgreSQL is a relational database service that combines the speed and availability of

high-end commercial databases with the simplicity and cost-effectiveness of open source

databases.

4. Workflow Management (BPM Layer)

It facilitates modelling, automation, and continuous improvement of business processes,

routing information of any type according to user–defined business rules. It is the

sequence of departmental, administrative, or other processes through which a piece of

work passes from initiation to completion.

Workflow could be categorized into 2 different ways:

a. System centric workflow: automated workflow, where no human interaction is

required

b. Human centric workflow: where human interaction is required

The workflow framework would be designed to facilitate effective user interactions and

task tracking. It will also facilitate easy configuration of the workflow metadata through

user friendly interfaces.

This proposed framework will support both static and dynamic workflows as detailed

below:

a. Static Workflow: where all the workflow steps would be predefined. These

workflows would be configured as part of System development.

b. Dynamic Workflow: where the workflow steps or numbers of different human

tasks are not defined and that is configurable.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 51 | 101



EPIS Unified Portal

Workflow Management

Workflow Manager

Listener

Trigg

ers

Wor

kflo

w

Figure 17 Workflow Management

Workflow Management

The workflow rule engine consists of different components, each of which is used to

perform some defined tasks. Some of the features of the proposed workflow is described

below:

a. For any application, whenever any user initiates a workflow for an approval, a

process initiation request is generated.

b. This in turn generates a Human Task that would be assigned to a designated user /

user group. The Task would be shown in user’s task list and the same is notified

accordingly.

c. A user can view the Task list from his/her dashboard and claim a task. Once a task

is claimed by a user, it won’t be available in the pending task list anymore.

d. The user (with whom the document is pending at that point of time) takes an

action like forward, approve, reject, assign, release by initiating user action

request.

e. According to the workflow meta-data, if the number of recipients for the next step

is multiple and more than one user is resolved as the recipient for the document,

then a pop-up, with the list of resolved users would be shown to the current task

owner. Then the current task owner has to select the owner of the next task.

At any given step apart from the first step, users can either send the process back for

modification/correction to the owner of a previous task or complete their assigned activity

which will either complete the process or send the process to the next available task.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 52 | 101



5. Rule Management

Business Rule Management provides flexibility in administration and maintenance and real-

time responsiveness to changes in business requirements.

The following figure depicts a typical workflow on ingesting of new rules which arises from

any Govt orders and direction. These rules are related to hospital guidelines, patient

Guidelines, treatment guidelines etc.

Figure 18 Rule Management

The next figure describes about how the rules are placed in rules repository and what are

the various components of a Rule Engine.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 53 | 101



Business Rule Management

Rule Builder

Rules Repository

Repository APIs

Rule #1 Rule #2 Rule #3 Rule #n

Action #1

Action

#2

Action

#3

Action

#n

Action

#1

Action

#2

Action

#3

Action

#n

Action

#1

Action

#2

Action

#3

Action

#n

Action

#1

Action

#2

Action

#3

Action

#n

Admin User

Create/Update Business Rules

Business Services

Figure 19 Rule Management

a. The above picture depicts how we envisage the Business Rule Management to

work for the proposed ePIS solution. For any business logic triggered from the

System, if it involves decision making, the decision will come from business rule.

For example, for a functionality in a use case, whether any user will have access to

it will be defined in the Rule Engine. In that way, access can be granted/revoked

from the System in a configurable manner without making any changes in the

System.

b. As part of the proposed ePIS solution, there will be a metadata driven rule engine

capability for calculation and decision-making purposes. This engine will expose

the business rules as services, which accepts an input in XML format, processes the

predefined business logic of the rule and returns the result in another XML. It will

facilitate easy configuration of the rules as and when required.

c. The advantage of the architecture lies in the consideration that it provides the

necessary isolation between the main application and the business rule and

therefore, makes it easier to effect changes or additions to the rules without

impacting the main application.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 54 | 101



6. System Monitoring

For this project, we propose to use Elastic APM.

Elastic APM is an application performance monitoring system built on the Elastic Stack. It

allows the monitoring of software services and applications in real time by collecting

detailed performance information on response time for incoming requests, database

queries, calls to caches, external HTTP requests, etc. This makes it easier to pinpoint and

fix performance problems quickly.

Elastic APM also automatically collects unhandled errors and exceptions. Errors are

primarily grouped on stack trace, due to which new errors can be identified as they appear

and is easier to track, how many times specific errors happen.

a. Components of Elastic APM

Elastic APM consists of four components:

i. APM agents are open source libraries written in the same language as

your service. They instrument the code and collect performance data and

errors at runtime. This data is buffered for a short period and later sent

to APM Server.

ii. APM Server is an open source application written in ‘Go’, which typically

runs on dedicated servers. It receives data from agents through a JSON

HTTP API. It then creates documents from that data and stores them in

Elasticsearch.

iii. Elasticsearch is a highly scalable open-source full-text search and

analytics engine. It allows to store, search, and analyze big volumes of

data quickly and in near real-time. Elasticsearch is used to store APM

performance metrics and make use of its aggregations.

iv. Kibana is an open source analytics and visualization platform designed to

work with Elasticsearch. Kibana is used to search, view, and interact with

data stored in Elasticsearch. It can be used to visualize APM data by

utilizing the dedicated APM UI bundled in Basic license, or the pre-built,

open source Kibana dashboards that can be loaded directly via the APM

Kibana UI.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 55 | 101



Figure 20 System Monitoring

Components of Elastic APM

b. Activities

i. Component Communication

The APM Server helps keep the agents light, prevents certain security

risks, and improves compatibility across the Elastic and APM Stack.

APM agents make use of the Intake APIs to talk to the APM Server. After

the APM Server has validated and processed events from the APM

agents (via the intake API), the server transforms the data into

Elasticsearch documents and stores them in corresponding Elasticsearch

indices. In a matter of seconds, user can start viewing the application

performance data in Kibana.

ii. Real User Monitoring (RUM)

Real User Monitoring captures user interaction with clients such as web

browsers. The JavaScript Agent is Elastic’s RUM Agent. In order to use it,

you need to enable RUM support in the APM Server.

RUM JavaScript agent monitors the real user experience and interaction

within client-side application. The RUM JavaScript agent is also

framework-agnostic, which means it can be used with any frontend

JavaScript application.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 56 | 101



User will be able to measure metrics such as "Time to First Byte",

domInteractive, and domComplete which helps you discover

performance issues within your client-side application as well as issues

that relate to the latency of your server-side application.

iii. Distributed Tracing

Together, transactions and spans form a Trace. Distributed tracing

enables user to analyze performance throughout the micro services

architecture, all in one view.

iv. Search and fixes

Elastic offer dedicated UI to identify bottlenecks and zero in on

problematic changes at the code level. As a result, user can get better,

more efficient code that leads to a speedier develop-test-deploy loop,

faster applications, and better user experience.

v. Dashboard feature

Elastic APM instruments the applications to ship performance metrics to

Elasticsearch for visualization in Kibana with pre-configured dashboards.

7. Caching

Cache is an in-memory, NoSQL data structures store, frequently used as a database, cache,

and message broker. Unlike other in-memory stores, it can persist the data to disk, and is

remarkably versatile due to a wide variety of data structures (Sets, Sorted Sets, Hashes,

Lists, Strings, Bit Arrays, HyperLog Logs, Geospatial Indexes). Highly performant

operations on these structures with very little complexity can be performed on the cache.

In other words, Cache is purpose-built for performance and simplicity.

Throughput of the cache far exceeds that of the NoSQL databases. Cache in general

support more than a million operation/second, sub-millisecond latencies with minimal

hardware size, when compared to NoSQL or RDBMS.

Caching is a common technique used to enable high performance systems to scale. All the

frequently accessed data will be stored in Cache rather than in RDBMS. This will ensure the

response time requirements are well taken care.

A caching layer is a distributed system design pattern that offers many advantages.

Distributed cache will be separated from the application and decoupled cache can be used

by more than one application thus enable sharing the data among applications easier.

Popular Uses of Cache include:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 57 | 101



a. User Session Data Management

b. Message queues for workflow

c. Caching both static and interactive data

d. Cache also used for high speed transactions

e. Caching User Session information, as previously mentioned, for virtually every type

of app, SOA and micro services framework

f. Caching the results of database queries

ePIS system will include following type of data which will be repeatedly accessed from

various modules and stakeholders:

a. Static master data or reference data: These are data which never changes or

changes least frequently (once a month, quarter or year).

b. Transactional master data: These are master data which changes less frequently

post certain system events. E.g. Patient details etc.

c. Session data: These are data linked with web user session so that user profile and

personalized data are readily available to the EPIS systems when user is in session.

These data need to available for access for very limited time period (linked to

session timeout) E.g. username, email address of user in session.

d. Processing data: These are large transactional data which changes frequently due

to various user events. These needs to be accessed for limited period for

processing – searching and sorting without interfacing with backend data store.

e. Web static data: Web application transmits html, scripts and styles which changes

very less frequently.

Repetitious acquisition, initialization, and release of the same resource causes unnecessary

performance overhead. In situations when the same component or multiple components

of a system access the same resource, repetitious acquisition and initialization incurs cost

in terms of CPU cycles system performance. Memory must be constantly allocated and

later released to accommodate these resources. The cost of acquisition, access, and

release of frequently used resources would be reduced to improve performance.

For the efficacy of the system there are various levels of cache which will be there:

a. HTTP server cache: This cache will hold the static content being served at the

presentation layer like the images, static html markups etc.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 58 | 101



b. In Memory Object cache: This cache will be used by service layer and portlets when

in memory objects are to be stored. The object which has high creational times will

be stored in the cache. This cache will also store user specific encrypted

information which will help in efficient retrieval of the session. Elastic Cache as an

in-memory data structure store will be used to implement this cache. It supports

data structures such as strings, hashes, lists, sets, sorted sets with range queries,

bitmaps, hyperlog logs, geospatial indexes with radius queries and streams.

c. Distributed Cache: specific transaction data will be loaded in a distributed cache

that will be accessible to all applications across the system.

For all the caches intelligent eviction parameters will be decided and configured to have a

desirable freshness in the cached information.

The following figure shows how the client application acquires data from the secondary

data store. After acquiring the data is put into a cache instead of releasing it. When the

client application needs to access the same data again, it uses the Cache to retrieve it. This

behavior is depicted in the following sequence diagram.

Figure 21 Cache Sequence Diagram

Redis Cache Solution

A node is a physical or virtual machine on which the Redis is installed and configured order

to make the machine part of the cluster. Each node is a container for running multiple Redis

instances, referred to as shards.

In a Clustered & highly available Redis database – Each master shard in the clustered

database has a slave shard, enabling failover if the master shard fails.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 59 | 101



Cache replication is a technique involving many nodes to enable fault-tolerance and data

accessibility. In a replication environment many nodes share the same data with each other

so that even if few nodes go down, all the data will be available. Master and slaves are redis

servers, and the slaves contain exactly same data as master. There can be as many as slaves

per master server. When a new slave is inserted to the environment, the master

automatically syncs all data to the slave. All the queries are redirected to master server;

master server then executes the operations. When a write operation occurs, master

replicates the newly written data to all slaves. When a large number sort or read operation

are made, master distributes them to the slaves so that a large number of read and sort

operations can be executed at a time. If a slave fails, then also the environment continues

working. When the slave again starts working, the master sends updated data to the slave.

Clustering is a technique by which data can be shared (divided or distributed) into many

nodes. The main advantage is that more data can be stored in a cluster because it's a

combination of nodes.

In ePIS replication and clustering will be done to ensure high availability and better read-

write performance. So, if any node (master) fails, the cluster will start using the slave to

keep the cluster operating.

Figure 22 Replication and Clustering

8. Identity and Access Management

Identity and Access Management solution will be used for storing all the user related

information and maintain the user repository in a directory structure. This layer will take

care of Authentication, Authorization and required token management.

For the Authentication and Authorization functionalities inside the system components, it

has been proposed to use KeyCloak as an Identity and Access Management Solution.

9. Document and Content Management:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 60 | 101



Alfresco Document Management System will be leveraged to manage the document and

content lifecycle. Alfresco’s inbuilt workflow engine will be used to facilitate this lifecycle.

After a document or a content is uploaded in the system, a workflow will be automatically

initiated to push the workflow to the next approver.

The following figure shows high level block architecture for Alfresco solution:

Figure 23 Alfresco Solution

10. Mobile Application

Application services will be available through mobile Application. The Web applications and

Mobile App will share common data repository. If needed, Patient and medical services can

also be available through mobile applications going forward. The basic benefits of the

mobile apps are

a. To provider fast and smooth user experience introduced caching methodology

b. API based integration to increase flexibility

c. Unified data and document repository for seamless transaction

d. All services in place

e. OTP based authentication

The data access methodology through mobile applications have been described in the

below diagram:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 61 | 101



UI Components

Event Listners

UI Process Components

Business Validations

CMSBusiness Services

DMS

Integration Layer

Service Provider Layer

Data

Portal Database

SMS Gateway

SMTP

Data

External Applications

Ca

ch

ing

Co

nfi

gu

ra

tio

n

Co

mm

un

ica

tio

n/C

on

ne

cti

vit

y

Ex

ce

pti

on

Ha

nd

lin

g

User

Payment Gateway

Figure 24- Mobile Application



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 62 | 101



Following security aspects are covered while architecting the mobile application:

a. App is self-protected. Obfuscating techniques will be adopted so that the source

files are not accessible.

b. To secure the communications with the backend server, a certificate check will be

created on the client side. The SSL certificate would be with the application.

c. Alerts users if the app detects an invalid/expired certificate.

d. App does not send sensitive data over alternate channels (e.g., SMS, MMS, or

notifications).

e. When an app is quit or user logs off, all cache files created by the app would be

cleared from phone memory.

f. The app debug mode would be set to off during product release.

g. Application session timeout will be implemented.

h. Copy and Paste will not be allowed for certain critical fields such as Password,

Account number, OTP in the app.

i. Sensitive information such as Password, mPIN, OTP will not be stored in the app.

The following practices will be applied to ensure mobile applications works in low band

width scenario:

a. Minify Payloads: Each header, payloads, params are inspected to minify the request

payload.

b. Compress the payload: The payload which is part of request/response will be

compressed.

c. Optimize Images: Image optimization tools will be used to compress images.

Adaptive.

d. Resolution pattern will be used to fetch rightly sized images based on device

resolution.

e. Pre-fetch high priority/context sensitive information first: Take the most important

network calls as early as possible so that high priority data is made available.

f. Make just enough network calls: Make sure that app will not make redundant

network calls

g. Cache the app UI-related data (not sensitive) on a good network.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 63 | 101



11. SLA management

We plan to use the Elastic APM solution to manage the SLA of The Application. Elastic real

user monitoring (EUM) captures user interactions with the web browser and provides a

detailed view of the “real user experience” of your web applications from a performance

perspective. Elastic’s RUM Agent is a JavaScript Agent, which means it supports any

JavaScript-based application. RUM can provide valuable insight into your applications.

Some of the common benefits of RUM include:

a. RUM performance data can help you identify bottlenecks and discover how site

performance issues affect your visitors’ experience.

b. User agent information captured by RUM enables you to identify the browsers,

devices, and platforms most used by your customers so that you can make

informed optimizations to your application.

c. Together with location information, individual user performance data from RUM

helps you understand regional performance of your website worldwide.

d. RUM provides insight and measurement for your application’s service level

agreements (SLA).

12. Interfacing with External Devices/Equipment

An adaptor layer has to be written, which will provide transformation capabilities and

interfacing capabilities with the Equipment’s. The Integration interfaces for the

equipment’s have to analyzed and for different patterns of interfacing requirements

different adaptors have to be introduced in the system. These adaptors will facilitate

fetching information, images and other artifacts in real-time or batch mode depending on

the requirements.

13. Document Management System

Alfresco DMS will be leveraged to store the documents and document related workflows

in the system defined format. After a document is uploaded in the system, a workflow will

be automatically initiated to push the workflow to the next approver.

3.2.1.4. DevOps Architecture

DevOps is combination of process and philosophies which contains four basic component culture,

collaboration, tools, and practices. In return, this gives a good automated system and

infrastructure which helps an Organization to deliver a quality and reliable build. The beauty of this

culture is it enables a quality for Organizations to better serve their customers and compete more

effectively in the market and also add some promised benefits which include confidence and trust,

faster software releases, ability to solve critical issues quickly, and better manage unplanned work.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 64 | 101



Following diagram represents indicative deployment architecture based on CI/CD capability of

DevOps for ePIS Enterprise Portal Framework.

Figure 25 Enterprise Portal Framework

Here is a brief information about the Continuous DevOps lifecycle:

1. Development

In this DevOps stage the development of software takes place constantly. In this phase,

the entire development process is separated into small development cycles. This benefits

DevOps team to speed up software development and delivery process.

2. Testing

QA team use tools like Selenium to identify and fix bugs in the new piece of code.

3. Integration

In this stage, new functionality is integrated with the prevailing code, and testing takes

place. Continuous development is only possible due to continuous integration and testing.

4. Deployment

In this phase, the deployment process takes place continuously. It is performed in such a

manner that any changes made any time in the code, would not affect the functioning of

high traffic application.

5. Monitoring

Build artifacts(.jar)Static Code Analysis

Branching & merging strategyJira software

Sprint Planning E2E Traceability

SCM Restructuring

Project Management

Code Commit

Jenkins

Auto trigger once new code checked in

Artifact versioning

Continuous Build

Continuous Deployment

Deploy jar in Target Env

Web Tier

App Tier

Automated Build script

Maven Build Job

DB Tier

Nexusupload

Git

Deployment Script

Sonar Qube

Build



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 65 | 101



In this phase, operation team will take care of the inappropriate system behavior or bugs

which are found in production.

Below, are some principles which we will employ for effective DevOps adoption:

a. Customer-Centric Action: DevOps practice helps to take customer-centric action at

the early stages since the deliverables are getting deployed on regular basis for

continuous feedback.

b. End-To-End Responsibility: The DevOps team provide support until the end of life

cycle/engagement of the application. This enhances the level of responsibility and

the quality of the products engineered.

c. Continuous Improvement: DevOps culture to focus on continuous improvement to

minimize waste. It continuously speeds up the improvement of product or services

offered.

d. Automate everything: Automation is a vital principle of DevOps process. There

would be an endeavor to automate the Jenkins pipeline for build and deployment.

This process will also help building dockerized versions of proposed modules.

e. Work as one team: In the DevOps culture, the designer, developer, and tester will

be identified at the commence of the project so that they work as one team with

complete collaboration. For the same the Sprint teams will comprise of the various

skilled team members so that each team can work independently while

collaborating.

f. Monitor and test everything: It is very important for DevOps team to have a robust

monitoring and testing procedures. Automated testing procedures for unit testing

using JUnits, System Integration Testing using Selenium and performance testing

using tools like JMeter will be employed.

g. Acceptance tests for each deployment: As part of the testing process we would

define the acceptance tests that will be a part of each deployment, including levels

of acceptance for the applications, data, and even the test suite that we use for

testing suite that we use for testing.

3.2.1.5. Non-Functional Requirements

1. The system will be able to interface with latest versions of web browsers.

2. The system will make use of API based interaction to provide high reusability.

3. Web applications will be developed to adhere to HyperText Markup Language (HTML5)

guidelines and standards.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 66 | 101



4. All developers on the project will have identical development environment configurations,

and all testers will have identical quality assurance environment configurations.

5. Software testing will require the use of a test database with data extracted from the

production database to insure high verifiability. This test database will be deleted after

successful implementation of the software system.

6. The system would be highly scalable module wise.

7. The system would provide high availability.

8. The access to the system, applications would be highly secured.

9. The system would implement robust password policies.

10. The access permissions for system data may only be changed by the system’s data

administrator.

11. Passwords will never be viewable at the point of entry or at any other time.

12. Each unsuccessful attempt by a user to access an item of data will be recorded on an audit

trail.

13. No piece of text that might be displayed to a user will reside in source code. That is, every

piece of text that a user might see must be modifiable without changing source code. This

will provide high level of configurability.

14. Method calls will not be nested more than two levels deep to ensure high modifiability and

readability.

15. The system would have configurable logging levels and powerful exception handling

mechanism.

16. The system would have intuitive and user-friendly interface.

17. The system would operate on high throughput and low response times.

18. The system would enable that interchange of information across the modules is secured.

19. The system would enable that modules are extensible independently to provide high

flexibility.

20. Make available manuals for overall system operations.

21. Provide training, documentation and handover to ePIS teams.

22. Provide support and suggestions for system improvement after requirement analysis.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 67 | 101



23. Proactively identify gaps in requirements and obtain clarification and sign off on change

requirements.

24. Ensure Code quality and maintainability of delivered artefacts.

25. Ensure proper versioning of delivered artefacts, enabling rollback of deployed artefacts.

26. Provide standard mechanisms for logging and tracking newly developed application issues

to closure within agreed SLA.

3.2.2. Proposed Technology Stack

Following is the proposed technology stack for Bhutan ePIS:

Proposed Technology Stack

Layer Technology

Open

Source

Product

Required

Configur

ation

Required

Enterprise

Support

Required

(Proposed)

Comment & Explanation

Operating

System

RedHat

Linux/Centos Yes No No

Lightweight Linux OS

such as Alpine for

container-based nodes

Web Server Apache HTTP

Server/Nginx Yes Yes No

Apache HTTP

Server/Nginx

Web Portal HTML5, ReactJS No No No

HTML 5 and ReactJs are

development

frameworks. No product

required

Application

Server Jboss Wildify Yes Yes No

Database PostgreSQL Yes Yes Yes

PostgreSQL for

transactional data and

MongoDB for reports



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 68 | 101




Layer Technology

Open

Source

Product

Required

Configur

ation

Required

Enterprise

Support

Required

(Proposed)


Data Base

Abstraction

(ORM)

Spring Data JPA No No No

Spring JPA is a module of

Spring to be used. No

product Required

Data

Integration

Framework

Spring Cloud

Data Flow, REST No No No

Spring Cloud is a module

in spring framework

Server-Side

Scripting

Language

Java No No No Java- programming

language

Micro Service

Layer

Spring Boot

Framework,

Node JS

No No No

Spring boot and Node JS

are microservices

development

frameworks

Integration

Platform

WSO2 powered

Health Data

Hub /JBoss Fuse

ESB

Yes Yes No

API Layer Zuul Yes Yes No

Batch

Processing Spring Batch No No No

Spring Batch is a module

in spring framework

API

Monitoring

Spring Cloud

Sleuth No No No

Spring Cloud is a module

in spring framework



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 69 | 101




Layer Technology

Open

Source

Product

Required

Configur

ation

Required

Enterprise

Support

Required

(Proposed)


Business

Process

Management

jBPM Yes Yes No

Rule Engine Drools Yes Yes No

Identity and

Access

Management

KeyCloak Yes Yes No

User

Management Open LDAP Yes Yes No

Caching Redis Yes Yes No

BI Tool

Microsoft

Power BI/

Pentaho

No Yes Yes Power BI is a COTS

product.

Reporting

Framework

Apache POI,

Spring Batch,

Jasper Reports

No No Frameworks from

Apache. Not a product.

System

Monitoring

Elastic-

Logstash-

Kibana(ELK)

Yes Yes No

DevOps Tools

Jenkins,

Ansible, Maven,

Junit, Sonar

Qube,

Selenium,

Yes Yes No



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 70 | 101




Layer Technology

Open

Source

Product

Required

Configur

ation

Required

Enterprise

Support

Required

(Proposed)


Jmeter,Nexus

and Git.

Development

Platform

Visual Studio

Code/ Eclipse

IDE/ IntelliJ Idea

Yes No No

Unit Testing JUnit, Jasmine No No No Testing frameworks not a

product.

Build Tools Maven, NPM No No No Application building

framework

Mobile

Development

Platform

React Native No No No Mobile app development

language

Document

and Content

Management

Alfresco Yes Yes Yes

Containerizati

on Docker No No No

Containerization

platform.

Container

Orchestration Kubernetes Yes Yes No Orchestration platform

Data

Warehouse Pentaho Yes Yes No

Table 5- Proposed Technology Stack



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 71 | 101



4. Data migration / Integration and Management

Strategy

Data Migration is the process of moving data from the existing location and form to another

standard format for the new system. This process will lead to enhanced collaboration and flexible

scalability in TTPL for the ease of use ePIS.

The next section defines the general concepts of Data digitization and data migration.

4.1. Data Digitization of Physical Records

The data digitization approach based, on the data type, volume and source would be as follows:

1. Migration of digitized data from legacy systems – as per the list provided in Table 7 below,

the available data from the legacy systems which are planned to be replaced by ePIS, will

be migrated through deployment of migration scripts. The cleansed data in standard

format compatible with the data schema of ePIS would then be merged with the data

already residing on the main database, with unique identifier to trace the migrated data

whenever required.

2. Scanning and uploading of scanned documents with metadata tagging – there are possible

scenarios where physical record may need to be scanned and uploaded in Document

Management System (DMS) proposed as part of ePIS. There are two mechanisms which

would be adopted as required for digitization of such records:

a. Simple scanning and metadata tagging of the physical records – in this

scenario the physical records would be scanned through standard DMS

solution and device and tagged for ease of searching the scanned document.

The Users would be able to search whole of the scanned records through the

key words which are tagged to that particular scanned record. However, it

may be noted that in this case the actual contents of the scanned document

will not be searchable, and only the whole document may be retrieved for

reference purposes.

b. Optical Character Recognition (OCR) – in this scenario the scanned image

would be converted by the software tool into digital content and tagged

through key words automatically while uploading and storing the same in

ePIS DMS. This would require a full enterprise licensed version of the DMS

tool to achieve this functionality. Once the scanned document is stored in the

DMS it would be easily retrievable through enterprise search, not only the

document but also the contents within. One important aspect to note here

that even with the OCR based digitization of physcial records, the



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 72 | 101



handwritten notes and prescriptions of the doctors may not be able to be

automatically digitized. It may require manual translation and data entry to

achieve this.

The application architecture proposed for ePIS supports the data digitization of physical

records and storing the same in ePIS DMS. However, the ability of the DMS, depending upon

whether a standard community version is being deployed or full enterprise licensed version,

will determine the output and flexibility in terms of digitization of physical record.

Further it should be noted that as part of ePIS project, only the software capability for

digitization of physical records would be provided, however the actual digitization of the

physical records would be done by the Healthcare facility or concerned Users as the case may

be.

4.2. Objectives of Data Migration

The main objective of the data migration activity is to migrate the required legacy data to support the operation of relevant business processes of ePIS. The data migration activity has the following additional objectives:

1. Data Cleansing: Data to be migrated to attain agreed measures of cleanliness.

2. Data Mapping: All required data and data relationships from the legacy systems to be

accurately represented in the relevant target systems.

3. Data Migration: The data set to be defined and migrated.

4. Data Migration Timelines: Activities to be undertaken within agreed timelines.

5. Risk Mitigation: Appropriate contingency plans to be defined and implemented.

6. Data Reconciliation: Audit and reconciliation activity will be performed during data

migration to ensure data consistency and data quality is maintained, and to verify that the

data extracted from the source systems is consistent with that loaded into the target

systems.

4.3. Steps in Data Migration

The following are the detailed steps that need to be undertaken for data migration:

1. Identifying and assessing the Source Data: It is essential to understand the format,

location and type of source data being migrated, this is essential for identifying potential

risks and taking appropriate security measures. There may be data with lots of fields, some

of which won’t need to be mapped to the target system. There may also be missing data

fields within a source that will need to pull from another location to fill a gap. The current

analyzed and a plan on type of data to be migrated should be created. The requirements



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 73 | 101



for data fields to be transferred, run an audit on the actual data contained within. Poorly

populated fields, incomplete data pieces, inaccuracies, or other problems, should be

identified before the migration process.

2. Define and Design the Migration: The scope of data migration plan in the design phase in

which the type of data migration should be finalized which involves drawing out the

technical architecture of the solution and detailing the migration processes. After

consideration of design, the data to be pulled over and the target system, the timeline

would be defined. It is also important to consider security plans for the data and necessary

steps should be taken to protect the data from any security threat. Conduct an advanced

analysis of both the source and target system, write out a flexible timeline for the project

and consider whether the data migration will interfere with normal business operations,

or contribute to downtime.

3. Building migration solution: The migration solution would involve breaking down the data

into subsets and building one category at a time followed by a test since the dataset is large

build and test should be done parallelly, this would allow successful data migrating to the

target, from source system. It should be ensured that data is cleaned to protect target

system, transformed into the proper format and the loaded date is cleaned and

deduplicated into target system as per the data migration rules and map already laid out

4. Conducting live test: After building the migration solution it is important to test the data

migration design with real data to ensure accuracy of the implementation and completion

of the application.

5. Audit: After the implementation, the data shall be audited in order to check the accuracy

of the migration and identify the anomalies in the migrated data.

4.4. List of Applications for integration

On the basis of urgency of integration requirement with ePIS, the applications have been assigned the following priority level:

1. N.A: Theses applications are not required to be integrated with ePIS

2. Low/Mid: These applications may be required to be integrated with ePIS in the future on

discretion of TTPL

3. High: These applications are to be integrated with ePIS on top-priority.

Below is the list of applications that needs to be integrated with ePIS:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 74 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

01 RCDC,

MoH NEWARSIS

Public

Health Event

& National

Notifiable

Diseases

Reporting

system

HA, DHO,

ACO, Lab

Technologis

t and

Technicians

, Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Pull Data /

Integrate High No

02 JDWNRH PACs

PACs

connects all

the imaging

modalities.

The images

are accessed

through a

web porta

l(OsiriX)

Radiologist

and Radio

Technicians

Integrate High No

03 MoHCA

Civil

Registratio

n System

Civil Service,

government

employee

data

Governmen

t & Citizen

App: Java,

Db:

MySQL

Integrate

High Yes

04 RCSC CSIS/ZESt

Civil Service,

government

employee

data

HR Officials

Applicatio

n: ASP,

Database:

MSSQL

Server: IIS

Pull Data/

Integrate High Yes

05 DITT Gov Data

Hub Systems WSO2 Integrate High Yes



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 75 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

06 HMIS,

MoH DHIS2

Collects

Aggregated

Level Data

by monthly

Morbidity,

Activity,

Household,

C4CD,

Mortality,

VCT

HA, DHO,

MRT, PO,

Data

Assistant

Applicatio

n: Java

and

Database:

PostgreS

QL,

Server:

Tomcat

Server

Integrate/

Pull Data/

Push Data

Mid No

07 BSP,

MoH BTS

Tracks and

Keeps

record for

blood donor

including the

records of

blood safety

collected

rationally

with Mobile

Apps for

donor

Blood Bank

Staff

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Integrate/

Migrate Mid Yes

08 DoMSHI,

MoH eBMSIS

Web-based

Bhutan

Medical

Supplies

Inventory

System.

Preparation

of Annual

Indentation,

Stock

Record

Keeping and

Procureme

nt

Officer,

Program

Officer,

Medical

Store

Incharges

Applicatio

n: Java;

Database:

PostgreS

QL

Integrate Mid Yes



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 76 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

Mobilization

of all medical

items

09

PSGRD,

Cabinet

Secretari

at

Payment

Aggregato

r

Systems Java Integrate Mid Yes

10 DRC,

MoF RAMIS/GST

Revenue

Personal Integrate Mid Yes

11 RCDC,

MoH WQMIS

Drinking

Water

Quality

Monitoring

& Reporting

HA, DHO,

ACO, Lab

Technologis

t and

Technicians

, Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Integrate Low

Not

Requir

ed

12 RCDC,

MoH MRSIS

Measles &

Rubella

Surveillance,

Case

Investigatio

n

HA, DHO,

ACO, Lab

Technologis

t and

Technicians

, Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Integrate Low

Not

Requir

ed

13 RCDC,

MoH SIMS

Salt Iodine

Quality

Monitoring

HA, DHO,

ACO, Lab

Technologis

t and

Technicians

Applicatio

n: PHP

Database:

MySQL

Integrate Low

Not

Requir

ed



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 77 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

, Program

Officer

Server:

Apache

HTTP

14 RCDC,

MoH

ILI & SARI

System

Influenza

Like Illness &

Severe

Acute

Respiratory

Infection

Surveillance

system for

Selected

Sites

HA, DHO,

ACO, Nurse,

Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Integrate Low

Not

Requir

ed

15 RCDC,

MoH FooDSIMS

Foodborne

Disease

Surveillance

Information

Managemen

t System for

Selected

sites

(Diarrheal

Surveillance

system)

HA, DHO,

ACO, Lab

Technologis

t and

Technicians

, BAFRA,

Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Integrate Low

Not

Requir

ed

16 RCDC,

MoH CIHEWS

Climate

Based

Disease

Surveillance

System for

Selected

Sites. Under

Environment

al Health

Program,

HA, DHO,

ACO,

NCHM,

Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

Integrate Low

Not

Requir

ed



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 78 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

Hosted &

Maintained

at RCDC

17 RCDC,

MoH BFMIS

System

Owned by

VDCP.

System

redeveloped

as module in

DHIS2.

Legacy data

(data of old

System) is

stored in

server

hosted at

RCDC which

need to be

migrated to

the new

system

(DHIS2)

HA, DHO,

ACO,

Malaria

Technician,

Program

Officer

Applicatio

n: C#.Net,

PHP

Database:

MSSQL,

Integrate Low Yes

18 MoF ePEMS

Public

Expenditure

Managemen

t System of

Ministry of

Finance

Finance &

Revenue

Officer

Pull Data/

Integrate Low Yes

19 BHMC

Medical

and Health

Profession

Records

BHMC

Officials &

Medical

Professiona

l

Applicatio

n: PHP,

Database:

MySql

Pull Data/

Integrate Mid No



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 79 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

Server:

Apache

HTTP

20 DRA Approved

Drug List

DRA

Officials,

gov. &

private

pharmacy

Pull Data/

Integrate Mid No

21 PMO PMs eDesk

PMO &

Governmen

t Executives

App: Java,

Db:

MySQL

Push Data/

Integrate Low Yes

22

HHC,

DMS,

MoH

HERCS Emergency HHC

Personal Integrate Low Yes

23

HHC,

DMS,

MoH

K-Tracker

Ambulance

Dispatch

System

HHC

Personal Integrate Low Yes

24 MoE EMIS Student

Record Teachers

Pull Data/

Integrate Low Yes

25 JDWNRH LIS

Polytech

Laboratory

Information

System (LIS)

Biochemistr

y,

Hematology,

Histopathol

ogy,

Cytology,

Lab

Technologi

es and

Technicians

Phlebotomi

st

Standalon

e on

windows,

Peer-to-

Peer,

Database:

Pervasive

ePIS

Module/

Migrate

N.A

Not

Requir

ed



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 80 | 101



Sl.

No Owners

Sys

tem

s/

So

ftw

are

Bri

ef

De

scri

pti

on

s

Typ

e o

f E

nd

Use

rs

Pla

tfo

rm

Inte

gra

tio

n

Sta

tus

Pri

ori

ty

Ava

ilab

ility

of

AP

I

Microbiolog

y

26 JDWNRH IPD

Records

patient data

and print

discharge

and

admission

summary

Record

section

Standalon

e MS

Access.

ePIS

Module /

Migrate

N.A

Not

Requir

ed

27 RCDC,

MoH TBISS

TB

Information

Surveillance

System

HA, DHO,

ACO, Lab

Technologis

t and

Technicians

, Program

Officer

Applicatio

n: PHP

Database:

MySQL

Server:

Apache

HTTP

ePIS

Module N.A

Not

Requir

ed

28 JDWNRH

Doc

Appointme

nt App

Off Hour

service app

with

backend

Hospital

Manageme

nt & Public

Java &

MySQL

ePIS

Module N.A

Not

Requir

ed

Table 6 Integration of Application



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 81 | 101



5. ePIS Deployment Architecture

The proposed comprehensive ePIS application will be deployed on Hybrid model with a mix of in-

house Mini data centers and central Government Data Center (GDC). The overall ePIS solution will

be hosted centrally on Government Data Center. The Disaster Recovery will also be set up

separately, at a different location from GDC, and ePIS will be implemented in Government Data

Center for backup and Business Continuity.

The possibility of having a private cloud within Government Data Center to optimize the IT

infrastructure requirements will be explored. Currently virtualization of the IT infrastructure within

the GDC is planned. Further in-house Mini data centers in 3 hospitals, as decided by MoH, will be

implemented, as well as in those healthcare facilities which are situated in very remote locations

of Bhutan but the decision on the same will be taken later.

The logical deployment architecture is represented below:

Figure 26 Logical Deployment Architecture

The Government DC will act as a single source of data and information for all health-related

functions, processes and services within the Healthcare ecosystem, envisioned under this project.

The Government DC would also be used to provide host of collaborative services (email, voice and

video communications etc.), backup and related services, Helpdesk and support services and

management services (Asset, network and application).

In-house Mini data centers in 3 hospitals (JDWNRH, MRRH and CRRH) and servers in other

hospitals, would host ePIS Lite version which would also be able to function in offline mode in case



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 82 | 101



there is a network outage or intermittent connection between these healthcare facilities and the

Government DC. In any scenario, all the mission critical processes / services would always run

through the local instance within these hospitals, while other processes / services may run directly

from Government DC. During network outage or intermittent connection, local instances would

process transactions and store data at individual healthcare facility premises. Once the network

connection is up, the local data would automatically sync with the central Government DC. For all

other healthcare facilities, all processes / services will run through the Government DC only through

the mobile/web app. As long as adequate hardware and network devices are provided, MoH is free

to decide the facilities where local instances should be made available.

The above logical architecture is high level depiction of the proposed deployment model, and the

IT Infrastructure section represents individual physical components like servers, storage network

equipment etc. in line with proposed deployment model.

6. Solution Development Approach & Implementation

Methodology

6.1. Hybrid Model - Procurement and Adoption of an Open

Source Solution

A Hybrid development approach is envisaged for developing all the core capabilities and features

of comprehensive solution. A technology stack based on open source solution package will be

selected through a tendering process. Once the solution is selected, the concerned vendor would

provide complete training and handholding support to the TTPL delivery and development team

on the solution package. The required customization, configuration and additional Be-spoke

development as well as implementation would done by the TTPL delivery and development team

with the support from the selected vendor.

The customization and development of ePIS will be done adopting Agile and Rapid application

development (RAD) software development methodology, which heavily emphasizes rapid

prototyping and iterative testing and delivery to fast track the implementation.

6.2. Proposed Solution Implementation Strategy

Considering the requirements and expectations of MoH, hybrid wise implementation approach

(facility and module approach) has been proposed for ePIS.

Once the solution package is adopted and the TTPL team is trained by the concerned solution

provider, TTPL team would commence the design, development, customization, configuration of

the core ePIS application as per requirements of MoH. This will enable the standardisation of

almost all processes and modules covered under the scope of ePIS along with envisaged solution



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 83 | 101



features. Further, the Regional Referral Hospitals would be taken up for rollout, where a brief

study would be done to consolidate any specific requirements of these hospitals and accordingly

ePIS would be implemented with required customizations. Next a set of 8 Hospitals will be taken

up and same process would be followed for ePIS implementation.

The entire implementation of ePIS in above mentioned hospitals will be part of pilot phase or phase

1 where learnings from all these implementations, including stabilization period would help make

the ePIS more robust and User friendly and play a crucial role in widespread adoption of the new

automated ICT platform.

Further in Phase 2, rest of the hospitals would be covered and later in Phase 3, rest of the

healthcare facilities would be covered for nation-wide roll out of ePIS.

6.3. Implementation Plan

It is estimated that with the above Hybrid approach for ePIS design, development and

implementation, the total implementation period would be around 3 years for country wide roll

out, including the stabilization period, with all defined functionalities and features.

The detailed implementation plan has been provided below.

1. Phase 1: Phase 1 will include implementation of ePIS in 10 healthcare facilities selected for

initial rollout, starting with National Referral Hospital and then one facility at a time.

The implementation is planned to be completed in a 18-23 months’ period including

stabilization period of 1-2 months as required.

2. Phase 2: Phase 2 will include implementation of ePIS in one Regional Hospital, 44 Hospitals

and three Primary Health Centers. The implementation is planned to be completed in

approximately 6-8 months’ period after Phase 1 is completed.

3. Phase 3: Phase 3 will include implementation of ePIS in rest of the 181 Primary Health

Centers, 53 Sub-Posts, 5 Health Information Service Centers and 1 Thromde Health Center.

The implementation in these health facilities is planned to be completed in approximately

6-8 months’ period, after Phase 2 is completed. TTPL may employ third party local partners

for rollout at smaller facilities.

The detailed list of these facilities is mentioned below:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 84 | 101



Serial

No Phase No of Facilities Details of Facilities

1. Phase One 10

1 National Referral Hospital

1 Regional Hospital

2 Hospitals

1 Traditional Medicine

1 Thromde Health Center

1 Health Information Service Center

1 Sub-post

2 Primary Health Center

2. Phase Two 45 1 Regional Hospital

44 Hospitals

3. Phase

Three Rest of HFs

181 Primary Health Centers,

53 Sub-Posts,

5 Health Information Service Centers,

2 Thromde Health Centers

Table 7 Implementation Plan

Go Live of the system

1. Go Live would mean the date on which the proposed ePIS application is successfully

implemented, and all the acceptance test and certifications are successfully concluded to

the satisfaction of the Ministry of Health Bhutan.

2. Go live is also subject to successful completion of UAT. Only after the successful

completion of UAT, the deployed system would be used by the rest of the health facilities

for performing their related activities. For the purpose of Go-Live, the system development

team would demonstrate successful execution of all modules requested by the Ministry of

Health, Bhutan.

A brief snapshot of the entire implementation plan as described above is provided below for reference:



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 85 | 101



It is envisaged that after the Phase 1, the system would be mature and adopted enough for roll out to rest of the healthcare facilities, and beyond the 10 Healthcare facilities in Phase 1, the rest two phases of ePIS rollout would concentrate mainly on replication of ePIs in all different categories of facilities, and further concentrate efforts on training and capacity building of the Users.

6.4. Solution Development and Implementation Methodology

Implementation of the envisioned ePIS will be done in a modular approach (piece-meal

basis) through Agile and RAD methodology which is proposed to have the following stages

below:

1. Project Initiation and Planning: It would involve on-boarding of the entire team of TTPL

and creating a detailed and time bound plan for implementation of the project. It is one of

the very critical stages to ensure the project is delivered as per requirements and

expectation of MoH.

2. Requirement Gathering and Analysis: It would involve in collecting the detailed

requirement from the end users and stakeholders regarding various modules of the

envisioned ePIS and analyzing the same to formulate the System Requirement

Specifications (SRS) and System Design Document (SDD). This facilitates to translate the

user requirements into system design by creating design documents i.e. High-Level Design

(HLD) and Low-Level Design (LLD). A meticulous approach to requirement collection is

essential for capturing the expectation of the stockholders in detail.

3. System Design and Development: It would involve designing various processes, modules,

solution functionalities and features of the envisioned ePIS and developing the same as per

the requirements gathered and designed. Adequate attention to proper design facilitates

development of a convenient and user-friendly system.

4. Testing: It would involve detection of bugs/errors in the developed modules/system and

facilitates its resolution with track changes and version control. A rigorous multi layered

testing approach should be followed through Unit testing, System testing, Integration

testing and User Acceptance Testing to identify most of the bugs/errors for their resolution

which in turn maximizes the system acceptability by the end users. The testing should also

involve the Application and Security audit of system.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 86 | 101



5. Capacity Building & Change Management: It would involve providing training to the end

users on operating computers and application software modules being developed. This

stage also deals with minimizing the resistance through appropriate change management.

A robust and user-oriented Capacity Building & Change Management approach creates

better awareness and ensures adequate knowledge for the end users which results in

higher system utilization and sustainability of the system.

6. Deployment & Go-Live: It would involve hosting and configuring the tested, security

audited and accepted modules of the ePIS in the production environment and making it

fully operational for all stockholders. Adequate configurations of the Production

Environment need to be ensured to have seamless access and operations through ePIS.

7. Operation & Maintenance: It would involve post implementation support to the end users

and maintenance of the implemented system for its smooth functioning. It is very much

required to ensure sustainability of the system in long run.

Agile methodology will help build on the iterative and incremental model, where user

requirements are built as user stories which evolve through cross collaboration between functional

teams. Small requirements (which can be demonstrated within two-four weeks) called Sprints are

designed and the solution is built over a period of time.

Each of the aforementioned stages contain multiple key activities. The overview of inputs, activity

details and outputs for each key activity under all the above-mentioned stages are described in the

below table for ready reference:

Sl.

No. Phase Input Outcome

1.

Preparation of

Project

Charter.

a. TTPL will mobilize its System Development Team (SDT)

as per the signed agreement/Proposal.

b. The team of SDT will interact with Project

Management Team (PMT) and the key officials of MoH

to prepare a detailed Project Charter containing a

detailed project plan.

c. The project charter will be presented to MoH along

with PMT for discussion, feedbacks and finalization.

d. SDT will also prepare and submit a Meeting Schedule

for discussion with various officials of MoH to gather

requirements for development of the envisioned ePIS.

• Team

mobilizatio

n

• Project

Charter

• Meeting

Schedule



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 87 | 101



Sl.


2. Requirement

Gathering

a. The SDT will initiate discussions with the officials of

MoH to gather requirements as per the Meeting

Schedule and with reference to the Project Charter.

b. SDT team will submit the requirement gathered to

MoH and PMT on a daily basis in the form of Minutes

of Meeting (MoM).

• MoM on

requiremen

ts gathered

3. Requirement

Analysis

a. SDT team will analyze the requirements gathered and

submit the Software Requirement Specification

documents (SRS) as per the defined timeline in project

charter.

b. The inputs/feedbacks received on the requirement

specification documents will be discussed and

incorporated in the concerned document by SDT for

finalization.

• Requireme

nt

Specificatio

n

documents

(SRS)

4. System

Design

a. Basing on the requirement specification the SDT team

will design a Prototype of the envisioned ePIS having

core modules and processes as defined under

implementation strategy.

b. The prototype will be presented by SDT to MoH and

PMT for receiving inputs/feedbacks.

c. The inputs/feedbacks will be incorporated in the

prototype till its finalization.

d. SDT will submit a revised requirement specification

documents as per the finalized prototype to MoH and

PMT for review and finalization.

e. SDT will also submit the High-Level Design (HLD)

documents and Low-Level Design (LLD) documents to

MoH and PMT for the modules of the envisioned ePIS

being developed for review, finalization and approval.

• Finalized

Prototype

• Finalized

Requireme

nt

Specificatio

n

documents

• HLD

• LLD



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 88 | 101



Sl.


5. System

Development

a. SDT team will develop the modules of the envisioned

ePIS as per the finalized prototype, requirement

specification documents, HLD and LLD with reference

to the timeline mentioned in the Project Charter.

b. SDT will follow the coding standard and any other

technical parameters.

c. SDT will get the developed module security certified.

d. SDT team will report the system development status

on a regular basis (weekly and monthly) to MoH and

PMT.

Developed

Modules of the

ePIS

6.

Testing of the

developed

modules of

the IT System.

a. SDT will develop the Test Cases for Unit Testing,

System Testing and Integration Testing as per the

requirement specifications and design documents and

submit the same to MoH and PMT for review.

b. Any inputs/feedbacks received on the test cases will be

discussed and incorporated in the same by SDT.

c. SDT will conduct testing of the developed modules as

per the Project Charter.

d. SDT will submit the test result for all type of testing to

MoH and PMT for checking and approval.

• Test Cases

• Test Result

7.

Planning User

Acceptance

Test.

a. Upon successful testing of the modules, SDT in

coordination with PMT and key officials of MoH, will

identify and form the user groups for conducting the

User Acceptance Test (UAT).

b. SDT will prepare a schedule for UAT training and UAT

along with UAT cases as per signed agreement/RFP

with reference to project charter and submit to

Registration department and PMU for review.

• UAT Groups

• UAT

Training

Schedule

• UAT

Schedule

• UAT Cases



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 89 | 101



Sl.


c. SDT will setup the UAT environment in coordination

with key officials of MoH and PMT and host the

modules in the same for conducting UAT.

d. SDT will submit the UAT cases for review, finalization

and approval to MoH and PMT.

• UAT

environmen

t

8.

Conducting

User

Acceptance

Test.

a. SDT will provide UAT training as per the schedule to

the UAT group.

b. SDT will circulate the UAT cases among the UAT groups

and ensure UAT is conducted as per the schedule.

c. SDT will collect the user feedback post testing of the

modules.

d. SDT will submit the UAT result to MoH and PMT and

also discuss the feedbacks received during UAT with

the key officials of MoH in coordination with PMT.

e. SDT will resolve any bugs/errors identified during UAT

of the modules.

• UAT report

• UAT result

• User

Feedback

9.

Planning for

Capacity

Building &

Change

Management.

a. SDT will prepare the schedule for various types of

capacity building trainings (Basic Computer

Awareness, Application Specific Training, etc.) &

change management sessions as per the project

charter and submit the same to MoH and PMT for

review.

b. SDT will also prepare the Training Materials, User

Manuals and training evaluation mechanism and

submit the same to MoH and PMT for review.

c. Inputs/Feedbacks received on training schedule,

training materials, user manuals and training

evaluation mechanism will be incorporated by SDT.

d. SDT in coordination with MoH and PMT will setup the

training environment as per the project charter.

• Capacity

Building &

Change

Manageme

nt

schedules.

• Training

Materials

• User

Manuals

• Training

Groups



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 90 | 101



Sl.


10.

Conducting

Capacity

Building &

Change

Management

Sessions

a. SDT will conduct Capacity Building sessions and

Change Management Sessions as per the schedule and

distribute the training materials and user manuals to

the trainees. SI will also collect user feedback on the

training sessions.

b. SDT will evaluate the training effectiveness and submit

the training evaluation reports along with user

feedback to MoH and PMT.

c. Basing on the training evaluation report, SDT in

coordination with PMT will discuss with the key

officials of MoH for re-training. Based on the

recommendation of MoH and PMT, retraining sessions

may be organized by SDT if required.

• Trained

Resources.

• User

Feedback

on training

• Training

Evaluation

Report.

11.

System

Implementati

on

a. SDT will setup the production environment as per the

project charter

b. SDT will host the modules of the envisioned ePIS in the

Production Environment along with the necessary

configuration

c. SDT will ensure adequate hosting environment at the

user end of MoH.

d. The Security audit of the system needs to be carried at

the end of the testing and before hosting. SDT needs

to get Safe for Hosting certificate as a process of

completion of Security audit.

• Go-Live of

the

modules of

the

envisioned

IT System.

12.

Operation &

Maintenance

Support

a. SDT will provide the O&M support and adhere to the

SLA clauses.

b. SDT will submit periodic reports on System Utilization

and O&M support to MoH and PMT.

• O&M

Support

• System

Utilization

Report

• O&M

Report



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 91 | 101



7. ePIS Testing and Acceptance Criteria

7.1. ePIS Testing Strategy

The overall Testing of the ePIS is segregated into two parts.

1. The functional verification and validation against the Requirement Specification and

2. Performance evaluation against the indicated requirements.

The diagram below describes the overall testing strategy and various types of testing that would

be conducted by the development team.

Figure 27 Testing Strategy

The test documentation will include test procedures, test data and test results and would be

properly documented. Errors detected during testing would be logged, classified, reviewed, and

resolved prior to release of the software. Software error data that is collected and analyzed during

a development/customization life cycle may be used to determine the suitability of the software

product for release and installation. Test logs and reports would comply with the requirements of

the corresponding test plans.

7.2. ePIS Testing Methodology

Several types of testing will be conducted on the new build/package before releasing it for

deployment on the production environment according to standard Software Testing Life Cycle

(STLC).

System Architecture

Requirements

Design

Code

Integration Testing

Functional Testing

System Testing

Unit Testing



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 92 | 101



Following testing model is proposed as given below.

Figure 28 Testing Models

7.3. ePIS Testing Process

The overall summary of testing process is depicted below for reference:

Task Input Tools and Techniques Output

Test Strategy -Business Requirement

- Application details

- Overall solution

Architecture

- Testing Knowledge

-Testing

Methodology

- Test Strategy

-Individual

Applications

Test Strategy

- Test Management -Test Plan



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 93 | 101



Task Input Tools and Techniques Output

Test Planning

-Test Strategy

documents

-Application

Information

- Project Plan

Tool

- Testing Knowledge

- Test Methodology

- Templates

- Automated Tools

Knowledge.

- Support details

Test Case Design

- Test Plan

- Solution Mapping

- Business Scenarios

- Detailed Design doc

- Testing Knowledge

- Templates

- Test Cases/Scripts

Test Execution

- Test Plans

- Test Cases/Scripts

- Testing Skills

- Test Tools

- Performance Graphs

- Test Results

- Defect Reports

- Summary Reports

Table 8 Testing Processes

7.4. User Acceptance Testing (UAT)

It is proposed that MoH forms different user groups which will be headed by a competent official

appointed by MoH for the purpose of UAT. These user groups would test the application for the

functionality, reliability and all other related tests. Once the users are completely satisfied with the

application a formal sign off from the competent officer appointed by MoH for acceptance of each

module.

7.4.1. Acceptance Test Design and Execution

All the acceptance test criteria will be specified and finalized under the technical guidance of

Project Management Unit and the user representative authorized by MoH. The test criteria would

be comprehensive to address all aspects of testing the new systems. Extensive testing would be



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 94 | 101



carried out by the User Representatives with technical support from Project Management Unit

(PMU).

7.4.2. Fault Correction

The responsibility for correcting all faults found during the acceptance process will be taken up by

the development team. The Governance Framework established for the project will ascertain what

all measured risks that needs to be accepted and responsibility at each such occurrence/incident

be taken up for correction, prevention and remediation throughout the project tenure.

It is advised to undertake an exercise of application security audit of the ePIS through MoH, on

completion of system implementation.

7.5. ePIS Acceptance Criteria

The ePIS solution will be designed to meet all functional, non-functional and management

requirements as mentioned in this document. Some of the key acceptance criteria proposed for

ePIS are defined below:

1. Performance – The system would provide fast and steady response times (Quality of

Service). The maximum user response time would be less than 5 seconds, for the next

screen to appear or the existing screen to refresh for submission of data. The speed and

efficiency of the system would not be affected with growing volumes, especially during

search operations, reporting, online processes and batch processes etc.

2. Availability – All the components of ePIS must provide adequate redundancy to ensure

high availability. The systems will be designed for 24x7 operations and meet all SLA

requirements. All the components of the solution would support Simple Network

Management Protocol (SNMP) for the effective monitoring and management. An

enterprise management system (EMS) would be provisioned to monitor all the server and

network performance and automatic SLA monitoring based on predefined configurations.

3. Security – The implementation of all solution components for each of the project locations

would comply with the standard guidelines of Information Security Management System

(ISMS) and application solution protocols. ISO 27001 would be implemented for the project

and standard security policy and procedures applicable to be formulated for each of the

solution components separately.

4. Scalability – All components of the solution would support both horizontal and vertical

scalability to provide continuous growth to meet the requirements and demand of ePIS

healthcare facilities. Proposed Solution would support vertical scalability (the growth

within one operating environment) and horizontal scalability (leveraging multiple systems

to work together in parallel) by the use of load balancers and High available servers as

defined in It Infrastructure section.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 95 | 101



5. Manageability – The proposed System would have versioning features to track, document

and process the solution revisions made. A tool would be used for version control. The

admin control of the tool would always remain with designated admin from MoH.

6. Inter-operability – The entire system with all subsystems and components would be

interoperable and would seamlessly integrate with other legacy applications and the

applications being developed / already developed by Government of Bhutan as well as MoH

for similar purposes.

A solution design which is modular, decoupled, service oriented, container based with user

friendly remote orchestration features is planned to be implemented.

7. Standards and protocols – The proposed solution would comply with all necessary health

and IT standards. Following are the minimum standards that are proposed to be followed

for ePIS project:

Figure 29 Proposed Standards

8. Additional Acceptance Criteria – The system would be at minimum web 3.0 compliant to

ensure the ePIS works on various platforms, browsers and resolution. and flexible enough

to transition\upgrade into web 4.0 and web 5.0 (intelligent web) standard as and when

these standards along with the technologies become widely available for use by the

industry.

a. Access and User Interface – The system would be user-friendly, intuitive and

equipped with all required User help / support features and functionalities.

b. Mostly Server Based Computing – The computing architecture would be mostly

Server based. The solution will reside on the servers and will be accessed by the

users through various end points such as laptops, desktops, mobile app, kiosk, etc.

The end points would run the application both in online and offline mode. There



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 96 | 101



will be mechanism to store data in local cache securely whenever there is a network

outage. Once the connection is up, data stored in local cache would seamlessly get

synced with the server hosted in Mini DC if applicable, and then on the Government

DC.

c. Client-Side Scripting – In case of specific requirements (Static/ dynamic content in

ePIS / Web portal etc.) where client-side scripting is required, the latest standard

for HTML, DHTML, CSS, Java Script, JQuery, AJAX etc. would be used for best user

experience.

d. Application Client – The proposed solution would be accessed through web

browser from multiple different end points including Desktops, Laptops, Handheld

Mobile devices, Smart Phones and Kiosks etc. as required. The solution would be

supported by the latest browsers.

A responsive web design would be adopted that can be adjusted with each user’s

resolution and will be suitable for "CSS3 Media Queries" in the case of use

iOS/Android. Also, all interactive content from the ePIS web portal would run

seamlessly in all mentioned web browsers with the support of appropriate plug-ins

(Adobe Flash Player, Adobe Reader etc.) and proper setting of JavaScript in case

certain contents in the portal use Java Script.

A modern security protocol such as TLS (Transport Layer Security) 1.3 would be

considered in client and server-side data exchange and bulk encryption

(symmetric/session) algorithm and a hashing algorithm would be used to ensure

proper encryption.

8. Capacity Bui lding and Change Management

In order to ensure adequate capacity building of the TTPL technical team for solution development, implementation and support and client end users to operate ePIS successfully, it is essential to have comprehensive knowledge transfer (KT) strategy with detailed plan. Further, the strategy shall cover detailed change management plan at various stages of project for key stakeholders to embrace the changes with minimum resistances.

8.1. TTPL technical capacity building

For successful development, implementation and support of the ePIS project, vendor is required

to assess technical training needs and come up with a comprehensive training plan for which key

topics have been highlighted as below, but not limited to:

Training type Coverage Participants



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 97 | 101



Developer training

-Selected design/development architecture (Microservices)

-Agile and RAD concept and utilization

-Project phases, activities and deliverables based on selected methodology.

-Solution (application) architecture.

-Detailed training on solution design, configurations, development, standards, quality assurance, documentations, testing, deployment and post go live enhancements and support.

-Specific training in Database, Data warehouse, business intelligence, analytics, DMS, BPMS, DevOps, and any other pertinent training.

Development team (TTPL)

Project Management

Based on detailed project charter conduct project management and implementation workshop.

Project Manager & coordinators

Technical training

IT infrastructure, networking, hardware, security etc. required for ePIS solution.

Technical team (Client & TTPL)

8.2. End user training

In order to ensure adequate capacity building of the healthcare staff to operate ePIS, it is very

essential to assess the existing knowledge of the healthcare staff to operate in computers and

form a robust training curriculum to reduce the gap in bringing the competency of healthcare staff

to desired state. To gain user confidence and satisfaction effective training would be imparted

during the implementation phase and continuing to support users once the system is operational.

While the suggested solution officially replaces the existing manual system, the Ministry of Health

Bhutan in coordination with system development team would conduct the first user seminar for

local staff at the health facilities. The objectives of this seminar will be to introduce the system and

to dispel, at an early stage, any resistance to or fear of change. Once the system is in place, master

trainers will assist the staff on-site. Follow-up sessions will be organized to help the staff deal with

difficult scenarios. The training program will aim to achieve the following:

1. Implement capacity building of data capture and management (technology and human

resource) from the Ministry of Health Bhutan to all the health facilities.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 98 | 101



2. Develop constant training workshops for the skilled healthcare staff and provide the

capacity for training other staff members

3. Develop audio-visual training material to be disseminated among health facilities in

formats of e-learning tools.

9. Proposed Governance Framework

The proposed Governance Structure is shown below for reference:

Figure 30 Governance Structure

A brief description of the composition and key roles & responsibilities of the above is provided

below for reference:

1. High Level Committee / Steering Committee: A high-powered committee preferably

headed by Minister of Health, Government of Bhutan, along with and senior officials of the

Ministry of Health, Bhutan would constitute this committee. This would provide a required

level of advocacy for the ePIS project and also set directions which are acceptable to all

stakeholders. The key role of this steering committee would be to provide strategic

direction to the project.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 99 | 101



2. Project Management and Operation Team: A group of resources specializing in different

domain like project management, finance, database administration, application design and

development, as well networking and hardware would form a team having the overall

responsibility of ePIS project. It would be the nerve center of the proposed institutional

framework and will also be responsible for coordinating efforts of various agencies /

organizations, involved in ePIS implementation. This including representatives from

system development team and Advisors / Consultants as the case may be, would be

responsible for overall monitoring, risk management, issue resolution, coordination, etc. It

may include private and industry participation as well, based on requirement. This team

will be responsible for the overall implementation (including day-to-day monitoring) of the

project and will report to the Operations Committee and Steering Committee. This would

further aid in providing required level of advocacy for the implementation of ePIS and also

set directions on day to day activities of ePIS project, which are acceptable to all

stakeholders.

3. Healthcare Facilities: There are proposed to be the actual owner of the processes and

functions covered under ePIS and will be responsible for constituting the project teams

headed by the senior Healthcare staff, designated as Project Management office (PMO).

The PMO of the concerned healthcare institution will be the final deciding authority and

own of the processes / functions under the scope of this project.

4. Also, there will be ePIS Project Implementation teams which will be the single point

responsibility center to implement the project in line with the strategic directions and

approvals from Project Management Unit / Team. This will be headed by the team leader

(SPOC) for all conceptualization, design and implementation purposes within their Hospital

premises. This is proposed for all individual Hospitals / Health institutions during pilot phase

as well as during the nation-wide rollout.

5. TTPL Project Manager: Preferably from system development team, they will serve as a

single-point contact within the institutional framework for the purpose of project

monitoring / reporting purposes. They will be responsible for all the activities within the

project and will report to Project Management Unit / Team in coordination with the team

from Health institutions. They will be directly responsible for providing periodic project

statuses, tasks schedule and Action Taken Reports (ATRs).

6. Delivery Team: They will be delivery team / Agencies which will provide assistance in select

areas of the ePIS implementation phase and may also constitute of various other teams

within Hospitals or outside.

7. It is also proposed that Quality Assessment / Audit will be conducted by any nominated

agency by MoH Bhutan and will be responsible for providing feedback to the PMU at a

predefined frequency.



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 100 | 101



9.1. Responsibilities of TTPL team and System

Integrator/partner:

The TPPL and SI teams shall be managed by respective project team leads. Teams and members composition with key responsibilities are as below, but limited to:

TTPL team – Team headed by Project Manager shall be fully responsible for gathering

requirements, acquiring required technical knowledge from System Integrator (SI), working as

counterparts to respective SI team members, testing and acceptance, implementation and

coordination in their respective fields of responsibilities. They are also responsible for post go live

support, maintenance and future rollouts. The following are indicative, which vendor need to

assess and propose adequately during tendering stage:

• Project Manager - 1

• Business Analyst - 1

• Application system developers - 5

• Data warehouse and Business intelligence - 1

• DB administrator – 2 (TTPL-1, MoH-1)

• IT infrastructure and system administrator – 2 (TTPL-1, MoH-1)

System Integrator (SI) Team – SI team supported by TTPL counterparts shall technically lead the

implementation of ePIS project. As required adequate knowledge has to be imparted as agreed.

A minimum of following key resources are proposed. However, SI is required to propose their team

composition with adequate justification during tendering stage.

• Project Manager-1

• Business Analyst - 1

• Application system developers - 5

• Data warehouse and Business intelligence - 1

• DB consultant – 1

• Technical consultant for IT infrastructure and system – 1

10. Conclusion and Way Forward

On the basis of the project design and implementation strategy, as described in the above sections

of this proposal, TTPL will take up following activities as way forward to implement ePIS as soon

as possible and bring the effort to its logical conclusion:

1. Set up the core development and management team, and establish Project Governance

Structure with specific role and responsibilities



_____________________________________________________________________________________________________

_____________________________________________________________________________________________________ P a g e 101 | 101



2. Selection of a solution package and components

3. Commence SDLC process for ePIS customization, configuration and additional Be-Spoke

Development

4. Work out the commercial proposal and submit for approval from MoH.

5. Implementation and Roll out of ePIS in all healthcare facilities

6. Operations and Maintenance of ePIS

It is proposed to establish a dedicated PMU team with required experts and resources to provide

necessary guidance, support and technical advice during the entire implementation phase of ePIS.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Disclaimer

This publication (and any extract from it) may not be copied, paraphrased, reproduced, or distributed in any manner or form, whether by photocopying, electronically, by internet, within another document or otherwise, without the prior written permission of TTPL. Further, any quotation, citation, or attribution of this publication, or any extract from it, is strictly prohibited without prior written permission from TTPL.

© 2020 Thimphu TechPark Ltd. All rights reserved. In this document, TTPL refers to Thimphu TechPark Ltd.

