19 05 request for proposal for services (rfp-s)-updated...
TRANSCRIPT
REQUEST FOR PROPOSALS (PROCUREMENT OF SERVICES)
SERVICES FOR
Developing IT System for Inbound Health Assessment Project (IHAP)
Prepared by
IOM Sri Lanka, No.62, Ananda Coomaraswamy Mawatha, Colombo 03.
15.10.2018
GPSU.SF-19.5
2
REQUEST FOR PROPOSALS
RFP No.: RFP LK18-007
Mission: Sri Lanka
Project Name: Developing Information System for Inbound Health Assessment Project
(IHAP)
WBS: MH.0034.LK10.30.14.016
Title of Services: Developing Information System for Inbound Health Assessment and Health
Security Coverage
3
Request for Proposals The International Organization for Migration (hereinafter called IOM) intends to hire Service
Provider for the Developing IT System for Inbound Health Assessment Project (IHAP) for
which this Request for Proposals (RFP) is issued.
IOM now invites Service Providers/ Consulting Firms to provide Technical and Financial
Proposal for the following Services: Developing Information System for Inbound Health
Assessment and Health Security Coverage More details on the services are provided in the
attached System Requirement Specifications (SRS).
The Service Provider /Consulting Firm will be selected under a Quality –Cost Based Selection
procedures described in this RFP.
The RFP includes the following documents:
Section I. Instructions to Service Providers/ Consulting Firms
Section II. Technical Proposal – Standard Forms
Section III. Financial Proposal – Standard Forms
Section IV. System Requirement Specification
Section V. Standard Form of Contract
The Proposals must be delivered by hand or through mail to IOM with office address at
International Organization for Migration, No. 62, Ananda Coomaraswamy Mawatha,
Colombo-03 on or before 3.00 p.m. on 05th November 2018. No late proposal shall be
accepted.
IOM reserves the right to accept or reject any proposal and to annul the selection process and
reject all Proposals at any time prior to contract award, without thereby incurring any liability
to affected Service Providers/ Consulting Firms
Chairperson.
Bid Evaluation and Awarding Committee (BEAC).
International Organization for Migration
No. 62, Ananda Cooomaraswamy Mawatha,
Colombo-3
IOM is encouraging companies to use recycled materials or materials coming from
sustainable resources or produced using a technology that has lower ecological footprints.
4
Table of Contents
Section I - Instructions to Service Providers/ Consulting Firms ......................................... 5
Section II – Technical Proposal Standard Forms ................... Error! Bookmark not defined.
Section III. Financial Proposal - Standard Forms ............................................................. 24
Section IV. System Requirement Specification .................................................................. 30
Section V – Pro-forma Contract ........................................................................................... 31
5
Section I - Instructions to Service Providers/ Consulting Firms
1. Introduction
1.1 Only eligible Service Providers/ Consulting Firms may submit a Technical Proposal
and Financial Proposal for the services required. The proposal shall be the basis for
contract negotiations and ultimately for a signed contract with the selected
Consultant Firm.
1.2 Service Providers/ Consulting Firms should familiarize themselves with local
conditions and take them into account in preparing the proposal. Service Providers/
Consulting Firms are encouraged to visit IOM before submitting a proposal and to
attend a pre-proposal conference if is specified in Item 2.3. of this Instruction.
1.3 The Service Providers/ Consulting Firms costs of preparing the proposal and of
negotiating the contract, including visit/s to the IOM, are not reimbursable as a
direct cost of the assignment.
1.4 Service Providers/ Consulting Firms shall not be hired for any assignment that would
be in conflict with their prior or current obligations to other procuring entities, or
that may place them in a position of not being able to carry out the assignment in the
best interest of the IOM.
1.5 IOM is not bound to accept any proposal and reserves the right to annul the
selection process at any time prior to contract award, without thereby incurring any
liability to the Service Providers/ Consulting Firms.
IOM shall provide at no cost to the Service Provider/ Consulting Firm the necessary inputs
and facilities, and assist the Firm in obtaining licenses and permits needed to carry out the
services and make available relevant project data and report (see Section V. System
Requirement Specification).
2. Corrupt, Fraudulent, and Coercive Practices
2.1 IOM Policy requires that all IOM Staff, bidders, manufacturers, suppliers or
distributors, observe the highest standard of ethics during the procurement and
execution of all contracts. IOM shall reject any proposal put forward by bidders, or
where applicable, terminate their contract, if it is determined that they have engaged in
corrupt, fraudulent, collusive or coercive practices. In pursuance of this policy, IOM
defines for purposes of this paragraph the terms set forth below as follows:
Corrupt practice means the offering, giving, receiving or soliciting, directly or
indirectly, of any thing of value to influence the action of the
Procuring/Contracting Entity in the procurement process or in contract
execution;
Fraudulent practice is any act or omission, including a misrepresentation, that
knowingly or recklessly misleads, or attempts to mislead, the
Procuring/Contracting Entity in the procurement process or the execution of a
6
contract, to obtain a financial gain or other benefit to avoid an obligation;
Collusive practice is an undisclosed arrangement between two or more bidders
designed to artificially alter the results of the tender procedure to obtain a
financial gain or other benefit;
Coercive practice is impairing or harming, or threatening to impair or harm,
directly or indirectly, any participant in the tender process to influence
improperly its activities in a procurement process, or affect the execution of a
contract
3. Conflict of Interest
3.1 All bidders found to have conflicting interests shall be disqualified to participate in the
procurement at hand. A bidder may be considered to have conflicting interest under
any of the circumstances set forth below:
A Bidder has controlling shareholders in common with another Bidder;
A Bidder receives or has received any direct or indirect subsidy from another
Bidder;
A Bidder has the same representative as that of another Bidder for purposes of this
bid;
A Bidder has a relationship, directly or through third parties, that puts them in a
position to have access to information about or influence on the Bid of another or
influence the decisions of the Mission/procuring Entity regarding this bidding
process;
A Bidder submits more than one bid in this bidding process;
A Bidder who participated as a consultant in the preparation of the design or
technical specifications of the Goods and related services that are subject of the
bid.
4. Clarifications and Amendments to RFP Documents
4.1 At any time before the submission of the proposals, IOM may, for any reason,
whether at its own initiative or in response to a clarification amend the RFP. Any
amendment made will be made available to all short-listed Service Providers/
Consulting Firms who have acknowledged the Letter of Invitation.
4.2. Service Providers/ Consulting Firms may request for clarification(s) on any part of
the RFP. The request must be sent in writing or by standard electronic means and
submitted to IOM at the address indicated in the invitation at least seven (7)
calendar days before the set deadline for the submission and receipt of Proposals .
IOM will respond in writing or by standard electronic means to the said request and
this will be made available to all those who acknowledged the Letter of Invitation
without identifying the source of the inquiry.
7
4.3 For this purpose, a pre-proposal conference will be held at International
Organization for Migration, No. 62, Ananda Coomaraswamy Mawatha, Colombo-
03 at 10.00 a.m. on 19th October 2018. Attendance to the conference is optional.
5. Preparation of the Proposal
5.1 A Service Provider/ Consulting Firm Proposal shall have two (2) components:
a) the Technical Proposal, and
b) the Financial Proposal.
5.2 The Proposal, and all related correspondence exchanged by the Service Providers/
Consulting Firms and IOM, shall be in English. All reports prepared by the
contracted Service Provider/ Consulting Firm shall be in English.
5.3 The Service Providers/ Consulting Firms are expected to examine in detail the
documents constituting this Request for Proposal (RFP). Material deficiencies in
providing the information requested may result in rejection of a proposal.
6. Technical Proposal
6.1 When preparing the Technical Proposal, Service Providers/ Consulting Firms must
give particular attention to the following:
a) If a Service Provider/ Consulting Firm deems that it does not have all the
expertise for the assignment, it may obtain a full range of expertise by
associating with individual consultant(s) and/or other consultants or entities in a
joint venture or sub-consultancy, as appropriate. Service Providers/ Consulting
Firms may associate with the other consultants invited for this assignment or to
enter into a joint venture with consultants not invited, only with the approval of
IOM. In case of a joint venture, all partners shall be jointly and severally liable
and shall indicate who will act as the leader of the joint venture.1
b) For assignment of the staff, the proposal shall be based on the number of
professional staff-months estimated by the firm, no alternative professional staff
shall be proposed.
c) It is desirable that the majority of the key professional staff proposed is
permanent employees of the firm or have an extended and stable working
relationship with it.
d) Proposed professional staff must, at a minimum, have the experience of at least
three years, preferably working under conditions similar to those prevailing in
the country of the assignment.
6.2 The Technical Proposal shall provide the following information using the attached
Technical Proposal Standard Forms TPF 1 to TPF 6 (Section III).
1 This clause shall be included/revised as deemed necessary
8
a) A brief description of the Service Providers/ Consulting Firms organization and
an outline of recent experience on assignments of a similar nature (TPF-2), if it
is a joint venture, for each partner. For each assignment, the outline should
indicate the profiles of the staff proposed, duration of the assignment, contract
amount, and firm’s involvement.
b) A description of the approach, methodology and work plan for performing the
assignment (TPF-3). This should normally consist of maximum of ten (10)
pages including charts, diagrams, and comments and suggestions, if any, on
Terms of Reference and counterpart staff and facilities. The work plan should be
consistent with the work schedule (TPF-7)
c) The list of proposed Professional Staff team by area of expertise, the position
and tasks that would be assigned to each staff team members (TPF-4).
d) Latest CVs signed by the proposed professional staff and the authorized
representative submitting the proposal (TPF-5) Key information should include
number of years working for the firm and degree of responsibility held in
various assignments during the last three years.
e) A time schedule estimates of the total staff input (Professional and Support
Staff, staff time needed to carry out the assignment, supported by a bar chart
diagram showing the time proposed for each Professional and Staff team
members (TPF–6). The schedule shall also indicate when experts are working in
the project office and when they are working at locations away from the project
office.
f) A time schedule (bar chart) showing the time proposed to undertake that the
activities indicated in the work plan (TPF-7).
g) A detailed description of the proposed methodology and staffing for training if
the RFP specifies training as specific component of the assignment.
6.3 The technical proposal shall not include any financial information.
7. Financial Proposal
7.1 In preparing the Financial Proposal, consultants are expected to take into
account the requirements and conditions outlined in the RFP. The Financial
Proposal shall follow the Financial Proposal Standard Forms FPF 1 to FPF 4
(Section IV).
7.2 The Financial proposal shall include all costs associated with the assignment,
including (i) remuneration for staff (FPF–4) (ii) other expenses, if any (FPF-5). All
items and activities described in the Technical proposal must be priced separately.
Any activities and items mentioned in the Technical Proposal but not priced, shall
be assumed to be included in the prices of other activities or items.
7.3 The Service Provider/ Consulting Firm may be subject to local taxes on
9
amounts payable under the Contract. IOM is a privileged organization in Sri Lanka
and exempted from taxes, hence it is not liable to pay taxes such as VAT and NBT.
IOM shall provide tax exemption documents, issued by Inland Revenue department if
required. Taxes shall not be included in the sum provided in the Financial Proposal as
this will not be evaluated, but they will be discussed at contract negotiations.
7.4. Service Providers/ Consulting Firms shall express the price of their services in Sri
Lankan rupees (LKR)
7.5 The Financial Proposal shall be valid for 60 calendar days. During this period, the
Service Provider/ Consulting Firm is expected to keep available the professional
staff for the assignment2. IOM will make its best effort to complete negotiations
and determine the award within the validity period. If IOM wishes to extend the
validity period of the proposals, the Service Provider/ Consulting Firm has the right
not to extend the validity of the proposals.
8. Submission, Receipt, and Opening of Proposals
8.1 Service Providers/ Consulting Firms may only submit one proposal. If a Service
Provider/ Consulting Firm submits or participates in more than one proposal such
proposal shall be disqualified.
8.2 The original Proposal (both Technical and Financial Proposals) shall be prepared in
indelible ink. It shall contain no overwriting, except as necessary to correct errors
made by the Service Providers/ Consulting Firms themselves. Any such corrections
or overwriting must be initialed by the person(s) who signed the Proposal.
8.3 The Service Providers/ Consulting Firms shall submit one original and one copy of
the Proposal. Each Technical Proposal and Financial Proposal shall be marked
“Original” or “Copy” as appropriate. If there are any discrepancies between the
original and the copies of the Proposal, the original governs.
8.4 The original and all copies of the Technical Proposal shall be placed in a sealed
envelope clearly marked “TECHNICAL PROPOSAL.” Similarly, the original
Financial Proposal shall be placed in a sealed envelope clearly marked
“FINANCIAL PROPOSAL” and with a warning “DO NOT OPEN WITH THE
TECHNICAL PROPOSAL.” Both envelopes shall be placed into an outer envelope
and sealed. The outer envelope shall be labeled with the submission address,
reference number and title of the project and the name of the Service Provider/
Consulting Firm.
8.5 Proposals must be received by IOM at the place, date and time indicated in the
invitation to submit proposal or any new place and date established by the IOM.
Any Proposal submitted by the Service Provider/ Consulting Firm after the deadline
for receipt of Proposals prescribed by IOM shall be declared “Late,” and shall not
be accepted by the IOM and returned to the consultant unopened.
2 For this purpose, the Mission may have the option to require short-listed Consultants a bid security.
10
8.6 After the deadline for the submission of Proposals, all the Technical Proposal
shall be opened first by the BEAC. The Financial Proposal shall remain sealed until
all submitted Technical Proposals are opened and evaluated. The BEAC has the
option to open the proposals publicly or not.
9. Evaluation of Proposals
9.1 After the Proposals have been submitted to the BEAC and during the evaluation
period, Service Providers/ Consulting Firms that have submitted their Proposals are
prohibited from making any kind of communication with any BEAC member, as
well as its Secretariat regarding matters connected to their Proposals. Any effort by
the Service Providers/ Consulting Firms to influence IOM in the examination,
evaluation, ranking of Proposal, and recommendation for the award of contract may
result in the rejection of the Service Providers/ Consulting Firms Proposal.
10. Technical Evaluation
10.1 The entire evaluation process, including the submission of the results and
approval by the approving authority, shall be completed in not more than fourteen
(14) calendar day] after the deadline for receipt of proposals.
10.2 The BEAC shall evaluate the Proposals on the basis of their responsiveness to the
Terms of Reference, compliance to the requirements of the RFP and by applying
an evaluation criteria, sub criteria and point system3. Each responsive proposal
shall be given a technical score (St). The proposal with the highest score or rank
shall be identified as the Highest Rated/Ranked Proposal.
10.3 A proposal shall be rejected at this stage if it does not respond to important
aspects of the TOR or if it fails to achieve the minimum technical qualifying score
which is. 70%.
10.4 The technical proposals of Service Providers/ Consulting Firms shall be evaluated
based on the following criteria and sub-criteria:
Points
(i) Specific experience of the Service Providers/ Consulting Firms relevant to
the assignment: [10]
(ii) Adequacy of the proposed methodology and work plan in response to the
Terms of Reference: a) Technical (overall) approach and methodology including modularity
[15]
b) Work plan [10]
c) Organization and staffing [05]
c) Approach for integration with existing systems (DIE and health
programmes) [10]
3 The criteria, sub criteria and point system may vary depending on the requirement of the Mission
11
[10]
Total points for criterion (ii): [40]
(iii) Key professional staff qualifications and competence for the assignment: a) Team Leader [15]
b) Senior Software Engineer/Software Engineer [15]
c) Quality Assurance Lead [10]
d) Software Engineer [10]
Total points for criterion (iii): [50]
The number of points to be assigned to each of the above positions or
disciplines shall be determined considering the following three sub-criteria
and relevant percentage weights:
1) General qualifications [30%]
2) Adequacy for the assignment [50%]
3) Experience in domain, region and language [20%]
Total weight: 100%
The minimum technical score St required to pass is: 70 Points
10.5 Technical Proposal shall not be considered for evaluation in any of the following
cases:
a) late submission, i.e., after the deadline set
b) failure to submit any of the technical requirements and provisions provided
under the Instruction to Service Provider/ Consulting Firm (ITC) and Terms of
Reference (TOR);
11. Financial Evaluation
11.1 After completion of the Technical Proposal evaluation, IOM shall notify those
Service Providers/ Consulting Firms whose proposal did not meet the minimum
qualifying score or were considered non responsive based on the requirements in
the RFP, indicating that their Financial Proposals shall be returned unopened after
the completion of the selection process.
11.2 IOM shall simultaneously notify the Service Providers/ Consulting Firms that have
passed the minimum qualifying score indicating the date and opening of the
Financial Proposal. The BEAC has the option to open the Financial proposals
publicly or not.
11.3 The BEAC shall determine the completeness of the Financial Proposal whether
all the Forms are present and the required to be priced are so priced.
11.4 The BEAC will correct any computational errors. In case of a discrepancy
between a partial amount and the total amount, or between words and figures, the
former will prevail. In addition, activities and items described in the Technical
proposal but not priced, shall be assumed to be included in the prices of other
12
activities or items.
11.5 The Financial Proposal of Service Providers/ Consulting Firms who passed the
qualifying score shall be opened, the lowest Financial Proposal (F1) shall be given
a financial score (Sf) of 100 points. The financial scores (Sf) of the other
Financial Proposals shall be computed based on the formula :
Sf = 100 x Fl / F
Where:
Sf - is the financial score of the Financial Proposal under consideration,
Fl - is the price of the lowest Financial Proposal, and
F - is the price of the Financial Proposal under consideration.
The proposals shall then be ranked according to their combined (Sc) technical (St)
and financial (Sf) scores using the weights4 (T = the weight given to the Technical
Proposal = 0.80; F = the weight given to the Financial Proposal = 0.20; T + F = 1)
Sc = St x T% + Sf x F%
The firm achieving the highest combined technical and financial score will be
invited for negotiations.
12. Negotiations
12.1 The aim of the negotiation is to reach agreement on all points and sign a contract.
The expected date and address for contract negotiation is 21st November 2018.
12.2 Negotiation will include: a) discussion and clarification of the Terms of Reference
(TOR) and Scope of Services; b) Discussion and finalization of the methodology
and work program proposed by the Service Provider/ Consulting Firm; c)
Consideration of appropriateness of qualifications and pertinent compensation,
number of man-months and the personnel to be assigned to the job, and schedule
of activities (manning schedule); d) Discussion on the services, facilities and data,
if any, to be provided by IOM; e) Discussion on the financial proposal submitted
by the Service Provider/ Consulting Firm; and f) Provisions of the contract. IOM
shall prepare minutes of negotiation which will be signed both by IOM and the
Service Providers/ Consulting Firms.
12.3 The financial negotiations will include clarification on the tax liability and the
manner in which it will be reflected in the contract and will reflect the agreed
technical modifications (if any) in the cost of the services. Unless there are
exceptional reasons, the financial negotiations will involve neither the
remuneration rates for staff nor other proposed unit rates.
4 May vary depending on the requirement of the Mission; normally, weight assigned to Technical is .80 and .20
for the Financial.
13
12.4 Having selected the Service Provider/ Consulting Firm on the basis of, among
other things, an evaluation of proposed key professional staff, IOM expects to
negotiate a contract on the basis of the experts named in the proposal. Before
contract negotiations, IOM shall require assurances that the experts shall be
actually available. IOM will not consider substitutions during contract negotiation
unless both parties agree that the undue delay in the selection process makes such
substitution unavoidable or for reasons such as death or medical incapacity. If this
is not the case and if it is established that staff were referred in their proposal
without confirming their availability the Service Provider/ Consulting Firm may be
disqualified. Any proposed substitution shall have equivalent or better
qualifications and experience than the original candidate.
12.5 All agreement in the negotiation will then be incorporated in the description of
services and form part of the Contract.
12.6 The negotiations shall conclude with a review of the draft form of the Contract
which forms part of this RFP (Section VI). To complete negotiations, IOM and
the Service Providers/ Consulting Firms shall initial the agreed Contract. If
negotiations fail, IOM shall invite the second ranked Service Provider/ Consulting
Firm to negotiate a contract. If negotiations still fail, the IOM shall repeat the
process for the next-in-rank Service Providers/ Consulting Firms until the
negotiation is successfully completed.
13. Award of Contract
13.1 The contract shall be awarded, through a notice of award, following negotiations
and subsequent post-qualification to the Service Provider/ Consulting Firm with
the Highest Rated Responsive Proposal. Thereafter, the IOM shall promptly
notify other Service Providers/ Consulting Firms on the shortlist that they were
unsuccessful and shall return their unopened Financial Proposals. Notification will
also be sent to those Service Providers/ Consulting Firms who did not pass the
technical evaluation.
13.2 The Service Provider/ Consulting Firm is expected to commence the assignment
on 26th November 2018 .
14. Confidentiality
14.1.1 Information relating to the evaluation of proposals and recommendations
concerning awards shall not be disclosed to the Service Provider/ Consulting Firm
who submitted Proposals or to other persons not officially concerned with the
process. The undue use by any Service Provider/ Consulting Firm of confidential
information related to the process may result in the rejection of its Proposal and
may be subject to the provisions of IOM’s anti-fraud and corruption policy.
14
Section II. Technical Proposal Standard Forms
15
TPF-1: Technical Proposal Submission Form
[Location, Date]
To: Bid Evaluation and Awarding Committee (BEAC).
International Organization for Migration
Ladies/Gentlemen:
We, the undersigned, offer to provide the Services for Developing Information System for
Inbound Health Assessment and Health Security Coverage in accordance with your Request
for Proposal (RFP) dated 15th October 2018 and our Proposal. We are hereby submitting our
Proposal, which includes this Technical Proposal, and a Financial Proposal sealed under a
separate envelope.
If negotiations are held after the period of validity of the Proposal, we undertake to negotiate
on the basis of the proposed staff. Our Proposal is binding upon us and subject to the
modifications resulting from Contract negotiations.
We acknowledge and accept IOM’s right to inspect and audit all records relating to our
Proposal irrespective of whether we enter into a contract with IOM as a result of this proposal
or not.
We understand you are not bound to accept any Proposal you receive.
We remain,
Yours sincerely,
Authorized Signature:
Name and Title of Signatory:
Name of Firm:
Address:
16
TPF – 2A: Service Providers/ Consulting Firms Organization
1. Provide here brief: A two pages description of the background and organization of
your firm/entity and each associate for the assignment.
TABLE 1 – GENERAL INFORMATION
Name of the Company
Address
Phone Number
Fax Number
Email Address
Address of Other Offices, if any
Name and Designation of the Contact Person
Legal Status (Provide certified copies of Registration)
Registration number
Place of Registration
Principal place of business
VAT Registration number
2. Provide certified copies
TABLE 2 – COMPANY EXPERIENCE IN LAST THREE YEARS
Starting Month/ Year
Ending Month / Year
Client
Description of services
Contract Amount
Remarks ( Provide documentary evidence)
TABLE 3 – ONGOING COTRACTS
Client
Description of Contracts
Location
Amount
% of Completion (Provide documentary evidence)
TABLE 4 - ADEQUACY OF WORKING CAPITAL
Source of credit line
Amount
Remarks (Provide documentary evidence)
Please provide proof of financial competency and audited financial statements
for the last three financial years.
17
TABLE 5 – LIST OF PERMANENTLY EMPLOYED STAFF
Name
Designation Qualification
No. of Years of Experience
Provide an organizational chart and detailed CVs for key management and
technical personnel in the Organization
TABLE 6 – LIST OF PLANT AND EQUIPMENT (OWNED AND HIRED) – If
applicable
Description whether Owned or Leased
Year of Manufacture
TABLE 7 – ANY OTHER INFORMATION
In addition to the required information, Companies may provide brochures and
other related documents
I, the undersigned, warrant that the information provided in this form is correct and, in
the event of changes, details will be provided as soon as possible:
______________________ __________________ ____________
Name/ Signature/ Date
18
TPF-2B - Service Provider/ Consulting Firm’s Experience
Relevant Services Carried Out in the Last Five Years
That Best Illustrate Qualifications
Using the format below, provide information on each assignment for which your firm/entity,
either individually as a corporate entity or as one of the major companies within an
association, was legally contracted.
Assignment Name:
Country:
Location within Country:
Professional Staff Provided by
Your Firm/Entity(profiles):
Name of Client:
No of Staff:
Address:
No of Staff-Months; Duration of
Assignment:
Start Date (Month/Year):
Completion Date
(Month/Year):
Approx. Value of Services (in
Current US$):
Name of Associated Service Providers/ Consulting Firms
, If Any:
No of Months of Professional
Staff Provided by Associated
Service Providers/ Consulting
Firms :
Name of Senior Staff (Project Director/Coordinator, Team Leader) Involved and Functions
Performed:
Narrative Description of Project:
Description of Actual Services Provided by Your Staff:
Firm’s Name:
19
TPF – 3: Description of the Approach, Methodology and Work Plan for Performing the
Assignment
[Technical approach, methodology and work plan are key components of the Technical
proposal. The Consultant is suggested to present the Technical Proposal using the following:
a) Technical Approach and methodology
b) Work Plan and
c) Organization and Staffing
a) Technical Approach and Methodology. In this section the Service Provider/ Consulting
Firm should explain their understanding of the objectives of the assignment, approach to
the services, methodology for carrying out the activities and obtaining the expected
output, and the degree of details of such output. The Consultant should highlight the
problems being addressed and their importance, and explain the technical approach that
would be adopted to address them. The Consultant should also explain the methodologies
being proposed to adopt and highlight the compatibility of those methodologies with the
proposed approach.
b) Work Plan. In this section the Service Provider/ Consulting Firm should propose the main
activities of the assignment, their content and duration, phasing and interrelations,
milestones (including interim approvals by the IOM, and delivery dates of the reports.
The proposed work plan should be consistent with the technical approach and
methodology, showing understanding of the TOR and ability to translate them into a
feasible working plan. A list of the final documents, including reports, drawings, and
tables to be delivered as final output, should be included here. The Work Plan should be
consistent with the Work Schedule (TPF-8).
c) Organization and Staffing. In this section the Service Provider/ Consulting Firm should
propose the structure and composition of the team. Main disciplines of the assignment
should be listed, the key expert responsible, and the proposed technical and support staff.
20
TPF – 4: Team Composition and Task Assignments
1. Technical/Managerial Staff
Name Position Task
2. Support Staff
Name Position Task
21
TPF – 5: Format of Curriculum Vitae (CV) for Proposed Professional Staff
Proposed Position:
Name of Firm:
Name of Staff:
Profession:
Date of Birth:
Years with Firm/Entity: Nationality:
Membership in Professional Societies:
Detailed Tasks Assigned:
Key Qualifications:
[Give an outline of staff member’s experience and training most pertinent to tasks on
assignment. Describe degree of responsibility held by staff member on relevant previous
assignments and give dates and locations. Use about half a page.]
Education:
[Summarize college/university and other specialized education of staff member, giving names
of schools, dates attended, and degrees obtained. Use about one quarter of a page.]
Employment Record:
[Starting with present position, list in reverse order every employment held. List all positions
held by staff member since graduation, giving dates, names of employing organizations, titles
of positions held, and locations of assignments. For experience in last ten years, also give
types of activities performed and client references, where appropriate. Use about two
pages.]
Languages:
[For each language indicate proficiency: excellent, good, fair, or poor in speaking, reading,
and writing.]
Certification:
I, the undersigned, certify that to the best of my knowledge and belief, these data correctly
describe me, my qualifications, and my experience. I understand that any willful
misstatement described herein may lead to my disqualification or dismissal, if engaged.
Date:
[Signature of staff member and authorized representative of the firm] Day/Month/Year
Full name of staff member:______________________________________
Full name of authorized representative: __________________________
22
TPF-6: Time Schedule for Professional Personnel
Months (in the Form of a Bar Chart)
Name Position Reports
Due/Activities
1 2 3 4 5 6 7 8 9 10 11 12 Number of Months
Subtotal (1)
________________
Subtotal (2)
________________
Subtotal (3)
________________
Subtotal (4)
________________
Full-time: Part-time:
Reports Due:
Activities Duration:
Location
Signature of Authorized Representative:
______________________
Full Name:_____________________________
Title : ________________________________
23
TPF-7: Activity (Work) Schedule
A. Activity breakdown schedule
No.
Activity/Wor
k Description
Duration
1st 2nd 3rd 4th 5th 6th 7th 8th 9th 10t
h
11t
h
12t
h
1
2
3
4
5
B. Completion and Submission of Reports
Reports Date
1. Inception Report:
2. Detail System Design Report
3. Interim Progress Report
(a) First Status Report
(b) UAT Report for the first stage
(c) Final report for the first stage
4. Interim Progress Report for second stage
(a) Second Status Report
(b) UAT Report for the second stage
(c) Final report for the second stage
5. Completion Report
24
Section III. Financial Proposal - Standard Forms
25
FPF-1: Financial Proposal Submission Form
[Location, Date]
To: Bid Evaluation and Awarding Committee (BEAC).
International Organization for Migration
Ladies/Gentlemen:
We, the undersigned, offer to provide the consulting services for Developing Information
System for Inbound Health Assessment and Health Security Coverage in accordance with your
Request for Proposal (RFP) dated 15th October 2018 and our Proposal (Technical and
Financial Proposals). Our attached Financial Proposal is for the sum of [Amount in words
and figures]. This amount is exclusive of the local taxes, which we have estimated at
[Amount(s) in words and figures].
Our Financial Proposal shall be binding upon us subject to the modifications resulting from
Contract negotiations, up to expiration of the validity period of [insert validity period] of the
Proposal.
We acknowledge and accept the IOM right to inspect and audit all records relating to our
Proposal irrespective of whether we enter into a contract with the IOM as a result of this
Proposal or not.
We confirm that we have read, understood and accept the contents of the Instructions to
Service Providers/ Consulting Firms (ITC), Terms of Reference (TOR), the Draft Contract,
the provisions relating to the eligibility of Service Providers/ Consulting Firms, any and all
bulletins issued and other attachments and inclusions included in the RFP sent to us.
We understand you are not bound to accept any Proposal you receive.
We remain,
Yours sincerely,
Authorized Signature:
Name and Title of Signatory:
Name of Firm:
Address:
26
FPF– 2: Summary of Costs
Costs Currency Amount(s)
I – Remuneration Cost (see FPF- 3 for breakdown)
II - Other Cost ( see FPF – 4 for breakdown)
Total Amount of Financial Proposal 1
1 Indicate total costs, net of local taxes, to be paid by IOM in each currency. Such total costs must coincide with the sum of the relevant
subtotal indicated in all Forms FPF-3 provided with the Proposal.
Authorized Signature:
Name and Title of Signatory:
27
FPF-3: Breakdown of Costs by Activity
Group of Activities (Phase):2
_____________________________________
_____________________________________
Description: 3
_____________________________________________________________
_____________________________________________________________
Cost Component Costs
Currency Amount
Remuneration 4
Other Expenses 4
Subtotals
1 Form FPF3 shall be filed at least for the whole assignment. In case some of the activities require different modes of billing and payment
(e.g. the assignment is phased, and each phase has a different payment schedule), the Service Provider/ Consulting Firm shall fill a
separate Form FPF-3 for each Group of activities. 2 Names of activities (phase) should be same as, or corresponds to the ones indicated in Form TPF-7. 3 Short description of the activities whose cost breakdown is provided in this Form. 4 For each currency, Remuneration and Other Expenses must coincide with relevant Total Costs indicated in FPF-4 and FPF-5.
Authorized Signature:
Name and Title of Signatory:
28
FPF-4: Breakdown of Remuneration per Activity
[Information provided in this Form should only be used to establish payments to the Service
Provider/ Consulting Firm for possible additional services requested by Client/IOM]
Name of Staff Position Staff-month Rate
Professional Staff
1.
2.
3.
4.
5.
Support Staff
1.
2.
3.
4.
5.
1 Names of activities (phase) should be same as, or corresponds to the ones indicated in
Form TPF-8. 2 Short description of the activities whose cost breakdown is provided in this Form.
Authorized Signature:
Name and Title of Signatory:
29
FPF-5: Breakdown of Other Expenses
[Information provided in this Form should only be used to establish payments to the Service
Provider/ Consulting Firm for possible additional services requested by Client/IOM]
Description Unit No of Unit Unit Cost Total
1 Delete items that are not applicable or add other items according to Paragraph 7.2 of Section
II-Instruction to Service Providers/ Consulting Firms 2 Indicate unit cost and currency.
Authorized Signature:
Name and Title of Signatory:
30
Section IV. System Requirement Specification
Please refer the attached
31
Section V – Pro-forma Contract
GPSU.SF.19.20
IOM office-specific Ref.
No.:
IOM Project Code:
LEG Approval Code /
Checklist Code
SERVICE AGREEMENT
Between
the International Organization for Migration
And
[Name of the Service Provider]
On
[Type of Services]
This Service Agreement is entered into by the International Organization for Migration,
Mission in [XXX], [Address of the Mission], represented by [Name, Title of Chief of Mission
etc.], hereinafter referred to as “IOM,” and [Name of the Service Provider], [Address],
represented by [Name, Title of the representative of the Service Provider], hereinafter
referred to as the “Service Provider.” IOM and the Service Provider are also referred to
individually as a “Party” and collectively as the “Parties.”
1. Introduction and Integral Documents
The Service Provider agrees to provide IOM with [insert brief description of
services] in accordance with the terms and conditions of this Agreement and its
Annexes, if any.
The following documents form an integral part of this Agreement: [add or delete as
required]
(a) Annex A - Bid/Quotation Form
(b) Annex B - Price Schedule
(c) Annex C - Delivery Schedule and Terms of Reference
(d) Annex D - Accepted Notice of Award (NOA)
2. Services Supplied
2.1 The Service Provider agrees to provide to the IOM the following services (the
“Services”):
32
[Outline services to be provided. Where relevant, include location and how
frequently etc. services are to be provided. List all the deliverables and their date of
submission, if applicable. Description needs to be as detailed as possible to provide
for a reliable yardstick to measure compliance. It may be necessary to attach a
description of the Services as an Annex.]
2.2 The Service Provider shall commence the provision of Services from [date] and
fully and satisfactorily complete them by [date].
2.3 The Service Provider agrees to provide the Services required under this Agreement
in strict accordance with the specifications of this Article and any attached Annexes.
3. Charges and Payments
3.1 The all-inclusive Service fee for the Services under this Agreement shall be
[currency code] [amount in numbers] ([amount in words]), which is the total
charge to IOM.
3.2 The Service Provider shall invoice IOM upon completion of all the Services. The
invoice shall include: [services provided, hourly rate, number of hours billed, any
travel and out of pocket expenses, (add/delete as necessary)]
3.3 Payments shall become due [insert number of days in numbers] ([write figure in
words]) days after IOM’s receipt and approval of the invoice. Payment shall be
made in [Currency code] by [bank transfer] to the following bank account: [insert
the Service Provider’s bank account details].
3.4 The Service Provider shall be responsible for the payment of all taxes, duties, levies
and charges assessed on the Service Provider in connection with this Agreement.
3.5 IOM shall be entitled, without derogating from any other right it may have, to defer
payment of part or all of the Service fee until the Service Provider has completed to
the satisfaction of IOM the services to which those payments relate.
33
4. Warranties
4.1 The Service Provider warrants that:
(a) It is a company financially sound and duly licensed, with adequate human
resources, equipment, competence, expertise and skills necessary to provide
fully and satisfactorily, within the stipulated completion period, all the Services
in accordance with this Agreement;
(b) It shall comply with all applicable laws, ordinances, rules and regulations when
performing its obligations under this Agreement;
(c) In all circumstances it shall act in the best interests of IOM;
(d) No official of IOM or any third party has received from, will be offered by, or
will receive from the Service Provider any direct or indirect benefit arising from
the Agreement or award thereof;
(e) It has not misrepresented or concealed any material facts in the procurement of
this Agreement;
(f) The Service Provider, its staff or shareholders have not previously been declared
by IOM ineligible to be awarded agreements by IOM;
(g) It has or shall take out relevant insurance coverage for the period the Services
are provided under this Agreement;
(h) It shall abide by the highest ethical standards in the performance of this
Agreement, which includes not engaging in any discriminatory or exploitative
practice or practice inconsistent with the rights set forth in the Convention on
the Rights of the Child;
(i) The Price specified in Article 3.1 of this Agreement shall constitute the sole
remuneration in connection with this Agreement. The Service Provider shall not
accept for its own benefit any trade commission, discount or similar payment in
connection with activities pursuant to this Agreement or the discharge of its
obligations thereunder. The Service Provider shall ensure that any
subcontractors, as well as the personnel and agents of either of them, similarly,
shall not receive any such additional remuneration.
4.2 The Service Provider further warrants that it shall:
a) Take all appropriate measures to prohibit and prevent actual, attempted and
threatened sexual exploitation and abuse (SEA) by its employees or any other
persons engaged and controlled by it to perform activities under this Agreement (
“other personnel”). For the purpose of this Agreement, SEA shall include:
1. Exchanging any money, goods, services, preferential treatment, job
opportunities or other advantages for sexual favours or activities, including
humiliating or degrading treatment of a sexual nature; abusing a position
of vulnerability, differential power or trust for sexual purposes, and
physical intrusion of a sexual nature whether by force or under unequal or
coercive conditions.
2. Engaging in sexual activity with a person under the age of 18 (“child”),
except if the child is legally married to the concerned employee or other
34
personnel and is over the age of majority or consent both in the child’s
country of citizenship and in the country of citizenship of the concerned
employee or other personnel.
b) Strongly discourage its employees or other personnel having sexual relationships
with IOM beneficiaries.
c) Report timely to IOM any allegations or suspicions of SEA, and investigate and
take appropriate corrective measures, including imposing disciplinary measures
on the person who has committed SEA.
d) Ensure that the SEA provisions are included in all subcontracts.
e) Adhere to above commitments at all times. Failure to comply with (a)-(d) shall
constitute grounds for immediate termination of this Agreement.
4.3 The above warranties shall survive the expiration or termination of this Agreement.
5. Assignment and Subcontracting
5.1 The Service Provider shall not assign or subcontract the activities under this
Agreement in part or all, unless agreed upon in writing in advance by IOM. Any
subcontract entered into by the Service Provider without approval in writing by
IOM may be cause for termination of the Agreement.
5.2 In certain exceptional circumstances by prior written approval of IOM, specific jobs
and portions of the Services may be assigned to a subcontractor. Notwithstanding
the said written approval, the Service Provider shall not be relieved of any liability
or obligation under this Agreement nor shall it create any contractual relation
between the subcontractor and IOM. The Service Provider remains bound and liable
thereunder and it shall be directly responsible to IOM for any faulty performance
under the subcontract. The subcontractor shall have no cause of action against IOM
for any breach of the subcontract.
6. Delays/Non-Performance
6.1 If, for any reason, the Service Provider does not carry out or is not able to carry out
its obligations under this Agreement and/or according to the project document, it
must give notice and full particulars in writing to IOM as soon as possible. In the
case of delay or non-performance, IOM reserves the right to take such action as in
its sole discretion is considered to be appropriate or necessary in the circumstances,
including imposing penalties for delay or terminating this Agreement.
6.2 Neither Party will be liable for any delay in performing or failure to perform any of
its obligations under this Agreement if such delay or failure is caused by force
majeure, such as civil disorder, military action, natural disaster and other
circumstances which are beyond the control of the Party in question. In such event,
35
the Party will give immediate notice in writing to the other Party of the existence of
such cause or event and of the likelihood of delay.
7. Independent Contractor
The Service Provider shall perform all Services under this Agreement as an independent
contractor and not as an employee, partner, or agent of IOM.
8. Audit
The Service Provider agrees to maintain financial records, supporting documents,
statistical records and all other records relevant to the Services in accordance with
generally accepted accounting principles to sufficiently substantiate all direct and indirect
costs of whatever nature involving transactions related to the provision of Services under
this Agreement. The Service Provider shall make all such records available to IOM or
IOM's designated representative at all reasonable times until the expiration of 7 (seven)
years from the date of final payment, for inspection, audit, or reproduction. On request,
employees of the Service Provider shall be available for interview.
9. Confidentiality
All information which comes into the Service Provider’s possession or knowledge in
connection with this Agreement is to be treated as strictly confidential. The Service
Provider shall not communicate such information to any third party without the prior
written approval of IOM. The Service Provider shall comply with IOM Data Protection
Principles in the event that it collects, receives, uses, transfers or stores any personal data
in the performance of this Agreement. These obligations shall survive the expiration or
termination of this Agreement.
10. Intellectual Property
All intellectual property and other proprietary rights including, but not limited to, patents,
copyrights, trademarks, and ownership of data resulting from the performance of the
Services shall be vested in IOM, including, without any limitation, the rights to use,
reproduce, adapt, publish and distribute any item or part thereof.
11. Notices
Any notice given pursuant to this Agreement will be sufficiently given if it is in writing
and received by the other Party at the following address:
36
International Organization for Migration (IOM)
Attn: [Name of IOM contact person]
[IOM’s address]
Email: [IOM’s email address]
[Full name of the Service Provider]
Attn: [Name of the Service Provider‘s contact person]
[Service Provider‘s address]
Email: [Service Provider‘s email address]
12. Dispute resolution
12.1. Any dispute, controversy or claim arising out of or in relation to this
Agreement, or the breach, termination or invalidity thereof, shall be settled
amicably by negotiation between the Parties.
12.2. In the event that the dispute, controversy or claim has not been resolved by
negotiation within 3 (three) months of receipt of the notice from one party of the
existence of such dispute, controversy or claim, either Party may request that the
dispute, controversy or claim is resolved by conciliation by one conciliator in
accordance with the UNCITRAL Conciliation Rules of 1980. Article 16 of the
UNCITRAL Conciliation Rules does not apply.
12.3. In the event that such conciliation is unsuccessful, either Party may submit the
dispute, controversy or claim to arbitration no later than 3 (three) months following
the date of termination of conciliation proceedings as per Article 15 of the
UNCITRAL Conciliation Rules. The arbitration will be carried out in accordance
with the 2010 UNCITRAL arbitration rules as adopted in 2013. The number of
arbitrators shall be one and the language of arbitral proceedings shall be English,
unless otherwise agreed by the Parties in writing. The arbitral tribunal shall have no
authority to award punitive damages. The arbitral award will be final and binding.
12.4. The present Agreement as well as the arbitration agreement above shall be governed
by internationally accepted general principles of law and by the terms of the present
Agreement, to the exclusion of any single national system of law that would defer
the Agreement to the laws of any given jurisdiction. Internationally accepted
general principles of law shall be deemed to include the UNIDROIT Principles of
International Commercial Contracts. Dispute resolution shall be pursued
confidentially by both Parties. This Article survives the expiration or termination of
the present Agreement.
13. Use of IOM Name
37
The official logo and name of IOM may only be used by the Service Provider in
connection with the Services and with the prior written approval of IOM.
14. Status of IOM
Nothing in this Agreement affects the privileges and immunities enjoyed by IOM as an
intergovernmental organization.
15. Guarantee and Indemnities
15.1 The Service Provider shall guarantee any work performed under this Agreement for
a period of 12 (twelve) months after final payment by IOM under this Agreement.
15.2 The Service Provider shall at all times defend, indemnify, and hold harmless IOM,
its officers, employees, and agents from and against all losses, costs, damages and
expenses (including legal fees and costs), claims, suits, proceedings, demands and
liabilities of any kind or nature to the extent arising out of or resulting from acts or
omissions of the Service Provider or its employees, officers, agents or
subcontractors, in the performance of this Agreement. IOM shall promptly notify
the Service Provider of any written claim, loss, or demand for which the Service
Provider is responsible under this clause. This indemnity shall survive the expiration
or termination of this Agreement.
16. Waiver
Failure by either Party to insist in any one or more instances on a strict performance of
any of the provisions of this Agreement shall not constitute a waiver or relinquishment of
the right to enforce the provisions of this Agreement in future instances, but this right
shall continue and remain in full force and effect.
17. Termination
17.1 IOM may terminate this Agreement at any time, in whole or in part.
17.2 In the event of termination of this Agreement, IOM will only pay for the Services
completed in accordance with this Agreement unless otherwise agreed. Other
amounts paid in advance will be returned to IOM within 7 (seven) days from the
date of termination.
38
17.3 Upon any such termination, the Service Provider shall waive any claims for
damages including loss of anticipated profits on account thereof.
18. Severability
If any part of this Agreement is found to be invalid or unenforceable, that part will be
severed from this Agreement and the remainder of the Agreement shall remain in full
force.
19. Entirety
This Agreement embodies the entire agreement between the Parties and supersedes all
prior agreements and understandings, if any, relating to the subject matter of this
Agreement.
20. Special Provisions (Optional)
Due to the requirements of the Donor financing the Project, the Implementing Partner
shall agree and accept the following provisions:
[Insert all donor requirements which must be flown down to IOM’s implementing
partners and subcontractors. In case of any doubt, please contact
21. Final clauses
21.1 This Agreement will enter into force upon signature by both Parties. It will remain
in force until completion of all obligations of the Parties under this Agreement
unless terminated earlier in accordance with Article 17.
21.2 Amendments may be made by mutual agreement in writing between the Parties.
39
Signed in duplicate in English, on the dates and at the places indicated below.
For and on behalf of
The International Organization
for Migration
For and on behalf of
[Full name of the Service Provider]
Signature
Signature
_________________________
Name
Position
Date
Place
____________________________
Name
Position
Date
Place
1
Inbound Health Assessment Programme
System Requirement Specification for
Inbound Health Assessment and Health Security Coverage
at
Inbound Health Assessment Unit
Ministry of Health, Nutrition and Indigenous medicine
Prepared by
Dr. Roshan Hewapathirana
Project Implemented by
International Organization for Migration
2
Contents
1 Overall requirements of the Bid related to functional, non-functional, process, operational and management of the proposed IHA and HSC systems ............................................................ 1
Scope of the Bid ........................................................................................................ 1 Current business requirement and workload ........................................................... 2 Overall system objectives ......................................................................................... 3
2 Inbound Health Assessment System ...................................................................................... 3 Overview of the IHA Process..................................................................................... 3 Workflow and the Business process (BP) of the IHA ................................................ 5
Overview of the integrated IHAS .............................................................................. 21 Process, and technical features of IHAS ................................................................... 22
3 Health Security Coverage System .......................................................................................... 23 Overview of the HSC Process .................................................................................... 23 Business process of the HSC ..................................................................................... 23
4 Overall system specifications ................................................................................................. 25 System design fundamentals .................................................................................... 25
System administration operations and management .............................................. 27
Records management ............................................................................................... 29
Reports ...................................................................................................................... 32
5 System implementation requirements .................................................................................. 33
3
Implementation and Project Management .............................................................. 34
Project Staffing .......................................................................................................... 37
System Design ........................................................................................................... 39
System Installation .................................................................................................... 40
Privacy protection ..................................................................................................... 41 System Test and Acceptance .................................................................................... 41 Documentation and source code .............................................................................. 42
6 System maintenance and enhancement ............................................................................... 43 Scope of Maintenance and Support ......................................................................... 43 System Warranty ...................................................................................................... 43 System Maintenance ................................................................................................ 44
Technical Support for On-going Operations and System Enhancement/Expansion 47
7 General requirements on System Testing, Deployment and Training................................... 48 System testing ........................................................................................................... 48
8 General requirements on training ......................................................................................... 52 Scope ......................................................................................................................... 52 Training Strategy ....................................................................................................... 53 Training Plan ............................................................................................................. 54 Training Delivery ....................................................................................................... 55 Training Management............................................................................................... 55
9 Detailed Technical Requirements .......................................................................................... 56
Appendices .......................................................................................................................................... 69
I. Investigations ................................................................................................................................... 69 Chest X Ray (CXR) ................................................................................................................... 69 Sputum Culture and AFB ........................................................................................................ 69
4
II Domain Analysis ............................................................................................................................... 71 High-level activity diagram .................................................................................................... 71 Selected processes in detail ................................................................................................... 72
5
Definitions, acronyms, and abbreviations Term Definition
AFC AIDS AMC CXR DHIS2 HIV DIE IHU IHA IOM IVR MLT MO MOH NPTCCD NSACP TB WHO
Anti-Filariasis Campaign Acquired Immunodeficiency Syndrome Anti-Malaria Campaign Chest X Ray District Health Information System Human Immunodeficiency Virus Department of Immigration and Emigration Immigration Health Unit Inbound Health Assessment International Organization for Migration Interactive Voice Response Medical Laboratory Technician Medical Officer Ministry of Health National Programme for TB Control and Chest Diseases National STD and AIDS Control Programme Tuberculosis World Health Organization
1
System Requirement Specification (SRS)
For
Inbound Health Assessment (IHA) Health Security Coverage (HSC) System
for
Inbound Health Assessment Unit (IHAU)
Ministry of Health, Nutrition and Indigenous Medicine
Project implemented by
International Organization for Migration (IOM)
1 Overall requirements of the Bid related to functional, non-functional, process, operational and management of the proposed IHA and HSC systems
Scope of the Bid More than 60,000 foreigners apply for long term residence visa every year and around 60% of them arrive from countries with higher disease burden than Sri Lanka. Aligned with the World Health Organization (WHO) resolution on Health of Migrants 2008, Sri Lanka National Migration Health Policy (2013) and the recommendations of the Global Consultation on Migration Health 2017, the Ministry of Health, Nutrition and Indigenous Medicine with the technical support of the International Organization for Migration (IOM) is now in the process of establishing a post-arrival health assessment for resident visa applicants.
Sri Lanka enjoys comparatively higher health standards and has set targets to maintain the Malaria and Filariasis free status, to end HIV epidemic by 2015 and to reduce TB incidence by 90% by 2025. In this context, TB, HIV, Malaria and Filariasis are identified as the health conditions to be assessed through a post arrival health assessment of long term residence visa applicants. The proposed inbound health assessment (IHA) process will be linked to Sri Lanka’s public health system for treatment and follow up of the migrant. Further, it is proposed to introduce a health insurance scheme for migrants to provide access to the emergency and primary health services.
To ensure the international standards and to adopt best practices for fraud prevention, it was decided to strengthen the Inbound Health Assessment with a comprehensive purpose-built information system. This system is expected to securely link the key stakeholders of the IHA process, the
2
International Organization for Migrants (IOM), Immigration Health Unit (IHAU) of the Ministry of Health and the Department of Immigration and Emigration (DIE). In addition, the system will link the National Programme for TB Control and Chest Diseases (NPTCCD), National STD and AIDS Control Programme (NSACP), Anti Malaria Campaign (AMC) and Anti Filariasis Campaign (AFC) to support further follow up of the applicants of the Residents Visa.
Hence, the key components and functionalities to be implemented by this Bid will include the following.
Inbound Health Assessment System (IHAS):
Call centre with Interactive Voice Response (IVR) and appointment scheduling system Internet Payment Gateway (IPG) and on-site payment integration with IHA Inbound Health Assessment System (IHAS) with radiology (RIS), laboratory information (LIS)
and referral components for IHAU Health Assessment Process (HAP) summary for IHAU and DIE Confirmatory tests and follow-up of the applicant among IHAU with NSACP, NPTCCD, AMC
and AFC. Under this, the IHAS shall be integrated with the existing information systems in NTPCCD, AMC, NSACP and a basic eRegistry has to be developed for the use of AFC.
Health Security Coverage System (HSCS): Residents Visa applicants’ Health Security Coverage portal, Health Security Card and IPG
integration
For the clarity of the stakeholders and the Bidders, IHAS and HSCS are discussed separately in chapter 2 and 3 respectively.
Current business requirement and workload More than 20,000 foreigners apply for long term Residence Visa every year and around 60%
of them arrive from countries with higher disease burden than Sri Lanka. Aligned with the World Health Organization (WHO) resolution on Health of Migrants 2008, Sri
Lanka National Migration Health Policy (2013) and the recommendations of the Global Consultation on Migration Health 2017, the Ministry of Health with the technical support of United Nations Agency for Migration (IOM) is now in the process of establishing a post-arrival health assessment for resident visa applicants.
Sri Lanka enjoys some of the best health standards in the region and has set targets to maintain the Malaria and Filariasis free status, to end HIV epidemic by 2015 and to reduce TB incidence by 90% by 2025.
In this context, considering the public health importance for Sri Lanka and the epidemiological profile of the countries of origin, TB, HIV, Malaria and Filariasis are identified as the health conditions to be assessed through a post arrival health assessment of long term Residence Visa applicants.
Hall mark of this proposed health assessment is its inclusionary, non-discriminatory public health approach based on active surveillance principles. Those Residence Visa applicants who are found to be positive for any of the disease conditions screened through the inbound health assessment will be linked to Sri Lanka s public health system for treatment and follow up.
The working hours of the IHA centre shall be from Monday to Friday, 8.00 am till 4.00 pm.
3
• This projected workload should be considered by the Bidder for projection of the system requirements.
Overall system objectives The objective of this information system is to support the operations of the proposed Inbound Health Assessment Unit, which will be positioned under the Immigrant Health Unit of the Ministry of health, Sri Lanka. This system is expected to securely link the designated panel physician employed by the IOM, the Ministry of Health and the Department of Immigration (DIE) and National Programme for Tuberculosis Control and Chest Diseases (NPTCCD), National STD and HIV Control Programme (NSACP), Anti-Malaria Campaign (AMC) and Anti-Filariasis Campaign (AFC) for the Ministry of Health while ensuring secure and efficient data management, maintain the confidentiality of applicants’ data and to minimize possible introduction of fraud.
This objective is to be achieved by:
• Secure and robust active surveillance process which is integrated with the passport and biometric data verification
• Streamlining the first line investigations with the routine management of HIV, TB, Malaria and Filaria cases
• Periodic follow-up of the applicant by integrating business processes of DIE, IHA unit, IHAU and four vertical health programmes of the Ministry of Health, namely NSACP, NPTCCD, AMC and AFC.
• Improving the IHA process with the use of modern ICT capabilities • Offering an applicant focus service encouraging early completion of the IHA and proper
follow-up throughout the stay in Sri Lanka • The Health Security Coverage, which could be offered as a general health insurance scheme
for migrants and tourists. It should be noted that the ICT component of the migrant health insurance scheme, HSCS, shall be able to implement independent of the IHAS and shall function independent of the IHA process.
2 Inbound Health Assessment System
Overview of the IHA Process To support active surveillance of the migrants, the IHAS is expected to incorporate following key operational, administrative and process objectives in to its design and implementation.
Inbound Health Assessment System (IHAS) with radiology (RIS), laboratory information (LIS) and referral components
Health Assessment Process (HAP) summary for IHAU and DIE Confirmatory tests and follow-up of the applicant for HU with NSACP, NPTCCD, AMC and AFC
Following are key activities in the IHA process:
Tracking the applicant - To initiate the active surveillance of the prospective applicant, the DIE shall share the relevant information (biographic and biometric) of the migrants who has applied for Entry Permits and Landing Endorsements.
4
Call centre and IVR – IOM shall maintain a call centre providing necessary information to the applicants. The IVR will have pre-recorded messages in the languages of the most frequent applicants.
Appointment scheduling and payment – IOM shall accept payments on-line and on-site and confirm appointments for the applicants who have already applied for Residents Visa. For this purpose, a roster for designated panel physicians (DPP) shall be maintained and the daily consultation slots should be made available to the applicants to book appointments. Also, an internet payment gateway (IPG) shall be integrated with the IHAS.
Inbound Health Assessment (IHA) – The key objective of the proposed system is to link IOM, IHAU and DIE to facilitate the inbound health assessment process. At the IOM, the biographic and biometrics of the applicants will be recorded and verified against the passport biographics (and biometrics) of the applicants. There after a DPP shall update applicants health profile and the applicant shall be directed to the phlebotomy and radiology after getting the informed written consent (for pre-HIV test). The radiology component will consist of a comprehensive PACS and radiology reporting features, whereas the lab information component will support rapid test results for HIV, Malaria and Filariasis. The system will facilitate Early Morning Sputum Test for suspected TB cases.
Summarizing the IHA and referring the applicant for confirmatory tests/follow-up- IOM shall share the results of the IHA with IHAU and refer the applicant to NSACP, NPTCCD, AMC and AFC in case of a positive finding. The thick and thin films for Malaria and Sputum Samples shall be dispatched respectively to the AMC and National Reference Laboratory for Tuberculosis, Welisara. The IHAU shall be able to categorise the results of each applicant and share the same with the DIE. The category A is medically cleared applicant, who can be granted residents visa. The category B is the applicants who are under medical treatment for HIV, Malaria, TB of Filariasis or needs the follow-up at the respective health campaigns. The category C shall include the treatment defaulters of the applicant those who not complete the HAP. Based on the recommendations from IHAU, the DIE will decide the eligible visa category for each applicant. The applicants who were granted Interim Visa (Category B under HAP) will be referred to relevant programmes for further management. The results of the confirmatory tests and the follow-up will be able to share with IOM and IHAU by the planned integration of the IHA system with the information systems and registries already implemented in respective health programmes. The category C or defaulted category B will be traced and investigate by the DIE and the applicant shall be deported after a case-by-case consideration of the situation. The applicants referred for further follow-up shall be managed by the respective health programme (NSACP, NPTCCD, AMC or AFC). The results of the confirmatory tests and follow-up progress shall be shared with the IHAU.
System maintenance – The system administrator at IOM shall manage IHAS user, back-up and restore the system and access system logs.
Analytics – IHAS shall provide options to analyse IHA process and outcome. The data shall be visible to the relevant user roles and data shall be able to export for the further analysis.
5
Workflow and the Business process (BP) of the IHA An overview of the work flow under the proposed IHA system can be outlined as follows:
Overview of Business Process Call centre and Interactive Voice Response (IVR) Online booking of an appointment (the applicants has already applied for Residents Visa) and
proceeding to the payment Applicant registration with integrated biographic and biometric verification Inbound Health Assessment (IHA) process PACS and RIS integration and radiology reporting Laboratory information management system (LIMS) integration – phlebotomy, sputum Referral management and confirmatory tests by health programmes Summarizing/reviewing the IHA by IHAU and recommendation for Residents Visa to DIE Follow-up of the applicants by health programmes and IHAU to observe the follow-up of the
applicant
Business process and activities The selected work flow has been described as several business processes (BP) below.
BP1: Call centre and Interactive Voice Response (IVR)
Process Activity
IVR
Applicants will dial a given phone number and access the IVR.
6
The IVR will play pre-recorded messages in the selected language on information pertaining to the IHA process, scheduling an appointment, investigation procedure, fee and estimated duration of IHA.
IVR should run in 9 pre-selected languages
Call Centre for information
Applicant shall dial the call centre number should they require further clarifications. The call centre shall function in English language.
Call centre operatives shall not have access to the IHAS (the applicant’s health assessment is not visible to call centre operatives).
Booking an appointment through the Call Centre
Should the applicant need the assistance to book an appointment, call centre operative shall place an appointment on behalf of an applicant. However, in this case payment options shall not be available to call centre operative. The applicant shall inform the passport number to the Call Centre operator and if the same passport number has already been informed to the appointment system by DIE as an eligible candidate for IHA, the call centre operative shall be allowed to proceed with placing the appointment.
Appointment system shall generate a unique Appointment ID (need to discuss the format with IOM, preferably longer), which Call Centre operative shall inform the applicant over the phone, SMS and email. Applicant shall use this Appointment ID to trace the appointment and complete the payment (BP2).
Call centre operatives shall see how many appointments have already been placed for a day and the daily limit for the appointments as per the availability of DPPs for the specific day.
Call centre shall trace an appointment to verify and/or change the date and time of an appointment by tracking it through the Appointment ID (see BP2 also for Appointment ID). However, the call centre operative shall not see the IHA details of the applicant who has booked an appointment.
Call centre operatives shall see total number of appointments placed per day. However, the call centre operative shall not see the details of the applicant who has booked an appointment unless applicant provided an Appointment ID to inquire/update an appointment.
Call Centre operative shall update an appointment date to a date where more appointments can be accommodated (due to cancellation of appointments etc). This is entertained only up to one (01) week prior to the appointment date (this is applicable to BP2 as well). Appointment update request should be submitted by the applicant with a valid Appointment ID. Without a valid Appointment ID, the system shall not make Update Appointment available to the Call Centre operative.
Priority Appointments
Need to discuss with IOM on how to handle (if any) priority appointments
Information Website
Applicant shall access the web-site and select the preferred language.
7
The information pertaining to the IHA process, scheduling an appointment, investigation procedure, fee and estimated duration of IHA shall be displayed in selected languages in Unicode fonts.
IOM shall provide the languages for localization.
SMS/email reminders
Automated SMS shall be sent to the applicant and/or sponsor in following frequency to encourage scheduling an appointment as early as possible.
Reminders shall be sent after entry to Sri Lanka. With this, the applicant is marked as ‘IHA Defaulted’ and DIE shall be notified.
SMS/email will be generated to inform the successful attempt of booking an appointment (Appointment ID).
Tracking prospective applicants
Applicant/sponsor details will be sent by DIE upon them applying for Residents Visa.
Call centre operative shall contact applicants/sponsors to encourage them to register for IHA. Date and time of the call and the respondent’s details shall be logged by the call centre operative.
Defaulters shall be informed to the DIE.
BP2: Scheduling an appointment online after applying for Residents Visa and proceeding to the payment
[scheduling an appointment through the Call Centre was covered in BP1]
Process Activity
Applicant accessing the appointment scheduling portal
When accessing the portal without submitting a valid Appointment ID, total number of booked appointment for each date shall be shown to the applicants. The dates those can accommodate more appointments and dates which cannot accommodate further appointments shall be displayed in different and contrasting colours in a calendar. The calendar shall display month, weeks and days formats.
If an Appointment ID is provided by the applicant, the portal shall highlight the date applicant has scheduled the appointment with a 3rd colour in addition to the above-mentioned colours.
Boking an appointment
By clicking on a preferred date where new appointments are allowed, the applicant shall initiate scheduling a new appointment. The applicant shall provide the passport number, so that IHAS verifies the applicant’s eligibility to schedule an appointment. When the applicant schedule and appointment with a DPP, IHAS shall generate a unique Appointment ID, which is displayed (and SMSed and emailed) to the applicant. If the applicant wants to proceed to the payment via the IPG, the applicant shall proceed to the payment option.
8
Else, te Appointment ID can be used to pay for the services later either online or on-site when applicant visit IOM.
Payment Online payment: The applicant shall proceed to the payment option directly from the scheduling screen or selecting Payment option on the appointment and scheduling system. In either case, the applicant will be directed to the integrated IPG and a credit/debit card of the type Visa/Master shall be used to complete the payment.
On-site payment: If the applicant opt-in for on-site payment, the Appointment ID should be produced to the payment counter (or digital payment booth – need IOM feedback) to proceed with the payment.
The applicants should have the access to a Desktop computer with the internet connection at the waiting area should they require to do an online (credit/debit card) payment for IHA before the registration process, or to purchase the Immigrants’ Insurance.
Updating an appointment
An applicant shall update an appointment date to a date where more appointments can be accommodated (due to cancellation of appointments etc). This is entertained only up to one (01) week prior to the appointment date (this is applicable to BP1 as well). Appointment update request should be submitted by the applicant with a valid Appointment ID. Without a valid Appointment ID, the system shall not make Update Appointment available to the applicant.
BP3: Applicant registration with integrated biographic and biometric verification [Sputum Collection shall be initiated by BP5 and, is discussed in the BP12]
Process Activity
Accepting the applicant
When Floor Manager logs in to the system, IHAS shall display ‘Next Applicant’ option. Upon selecting this option IHAS shall fetch the next customer by the pool of Appointment IDs.
The passport number of the applicant shall be loaded to the screen with the option ‘Start Registration’ option.
In case of an applicant who failed to report to the appointment, ‘No-show applicant’ (check with IOM) shall be available to the Floor manager.
9
Registration and verification of biographics
When the payment was completed, a consultation session with a DPP shall be reserved and applicant’s Registration Number (need to discuss the format with IOM, preferably short 3-5 digits) shall be displayed on the queue management screen (see BP11 as well).
When the applicant’s Registration number appeared on the display on screen on registration area, the applicant shall be received by the floor manager. The ideal waiting time from the Registration number appearing on the screen and the applicant is contacted should be …. Minutes. This station (how many registration stations – IOM) is equipped with a Desktop computer and a fingerprint scanner integrated.
The floor manager (or nurse/receptionist – IOM feedback) shall check the applicants name, age, address in Sri Lanka, sponsor details and the passport numbers (forwarded from the scheduling system after verifying with the passport biographics provided by the DIE).
Data elements to be verified/captured are,
Applicant:
Name
Passport number
Nationality
DoB
Address in Sri Lanka
Sponsor:
Name
Passport number
Nationality
Address in Sri Lanka
Recording biometrics (and verification)
When the biographics were captured, the floor manager initiates the recording of the biometric.
The applicant shall record both thumb (10 finger – IOM?) using the Biometric Fingerprint Scanner. IHAS shall verify the thumb prints against the same provided by the DIE (if available).
If thumb print captured and provided by the DIE match each other, IHAS shall prompt floor manager to save the biometric. If there are no thumbprint available in DIE database, IHAS shall note that along with the thumbprint upon saving the biometric.
Biometric Specifications: Shall be conforming to the ISO/IEC 19794.
Exception: If the applicant’s fingerprints are not available, then a special approval shall be noted from the chief of the DPPs to continue the registration without the fingerprints.
Fingerprint data shall be encrypted before storing in the database using a 64 bit encryption algorithm.
10
Photography booth
When the biometrics are captured, the applicant shall be directed to the Photography Booth. This station is equipped with a Desktop Computer and a integrated DSLR camera.
The interface should provide functionalities to align (rotate), crop and scale down the image to 300 dpi. The specifications for the photograph:
Format – Colour
Resolution – 300 dpi
Size – 300px X 300px
Background – white
Minimum space from Left or Right margin to the face - nnnn cm
Space between crown and the upper margin – nnnn cm
No spectacles shall be worn by the applicant during the photography. Hats or head covering that obscures the hair or hairline, unless worn daily for a religious purpose, shall not be allowed. Full face shall be visible, and the head covering must not cast any shadows on the face. If the applicant normally wear a hearing device, they may be worn in the photo.
Composition template:
IHAS shall store the digital image in the Portable Network Graphics (PNG) format. Each photo shall be encrypted using a 64 bit encryption algorithm if the photo is stored in a database or as a digital file (PNG).
Registration is only completed once photograph was saved.
After the photograph was saved, ‘Next Applicant’ option shall be available to the floor manager.
Exceptions Can Floor Manager reschedule an appointment for which the payment is completed.
Counselling – group counselling
Group counselling – mechanism TBD
11
Individual counselling
Medium of delivery – English. However, significant applicants may not understand English. Hence, group counselling should be reconsidered (perhaps a leaflet in multiple languages).
Counselling – individual
When biographic and biometrics are captured, the applicant shall be directed to the Pre-test Counselling.
When Counselling Nurse logs in to the system, IHAS shall display ‘Next Applicant’ option. Upon selecting this option IHAS shall fetch the next customer by the pool of Registration Numbers.
The passport number of the applicant shall be loaded to the screen with the option ‘Start Counselling’ option.
In case of an applicant who failed to report to the appointment, ‘No-show applicant’ (check with IOM) shall be available to the Nurse.
Prior to the counselling commences, the Counselling Nurse (confirm the name with IOM) shall confirm the identity of the applicant with biographic (Name, Passport number), applicants photograph and fingerprints.
The counselling station shall have a Desktop computer integrated with a fingerprint scanner.
The counselling nurse shall perform the counselling session which include HIV pre-test counselling.
Counselling section of the IHAS shall have the counselling procedure (checklist), instructions to the counsellor and the counselling script displayed in English languages as a guide to the counsellor.
The IHAS shall have the option to playback the pre-recorded counselling message in several (about 9).
IHAS shall provide an option to note the completion of the counselling with any remarks. The ‘Counselling Completed’ option shall be active (voice file length + adequate time for any clarifications/Q&A – check with IOM) minutes after playback of the pre-recorded counselling message.
‘Next Applicant’ option shall be available to the counselling nurse upon clicking ‘Counselling Completed’.
Check with IOM - Needs options to record voice of the applicant confirming the counselling.
HIV pre-test counselling
TBD
Prioritizing the consultative session with
Floor manager shall, case-by-case, decide whether an applicant should be prioritized to a consultation session with a DPP.
12
the DPP (if required)
Needs to discuss with IOM – This prioritization could happen after the Counselling Session (Counselling Nurse does the prioritization).
BP4: Consultation session by DPP
Process Activity
Accepting applicants for consultation
When DPP logs in to the system, IHAS shall display ‘Next Applicant’ option. Upon selecting this option IHAS shall fetch the next customer by the pool of Appointment IDs.
The passport number of the applicant shall be loaded to the screen with the option ‘Start Consultation’ option.
In case of an applicant who failed to report to the appointment, ‘No-show applicant’ (check with IOM) shall be available to the DPP.
Consultation Prior to the consultation commences, the DPP shall confirm the identity of the applicant with biographic (Name, Passport number), applicants photograph and fingerprints.
The DPP station shall have a Desktop computer integrated with a fingerprint scanner.
DPP shall inquire the past medical history of the applicant and measure blood pressure.
In case of a female applicant, rule out pregnancy before directing the applicant to the radiology section.
IHAS shall list all children (fetching from data made available through DIE database) within the range of minor age category (under 12) and provide option to cater them during mother’s consultation session.
Data elements to be captured may include;
• Fit for phlebotomy and BP • Fit for Radiography and for female applicant – record LRMP
Suggestive history for TB – rule out cough more than 2 weeks, weight loss, haemoptysis and any contacts with TB
Exceptions What shall be done for pregnant applicants – CXR
Not fit for phlebotomy (e.g. acutely febrile, week general health, aggressive behaviour)
Can DPP reschedule the appointment?
Completing the consultation session
When the examination and consultation is completed, the DPP shall select, ‘Complete Consultation’. After this, ‘Next Applicant’ option shall be made available.
IHAS shall record and log the time taken to each consultation by counting the time duration from
13
BP5: PACS and RIS integration and radiology reporting
Process Activity
Chest X Ray (CXR)
All applicants (exclude pregnancies with LRMP) > 11 years of age shall be subjected to CXR
When the applicant presents to the radiology section, the biographic, photograph and the biometrics are verified by the radiographer.
The CXR is performed.
IHAS shall fetch the digital CXR and link it with the applicant’s biographic. Once this was done, the CXR is available for the Consultant Radiographer for the reporting.
Reporting CXRs shall be queued for reporting and shall be divided among the consultant radiologist.
The consultant radiologist shall mark self as ‘Not accepting CXR reporting’ temporarily and during this, IHAS shall not allocate CXRs for the said consultant radiologist.
The IHAS shall provide standard PACS/RIS options (--LIST) to consultant radiologists.
Consultant radiologists shall report the radiological findings of the CXR. The text descriptions as well as graphical representation of any lesion shall be supported by IHAS.
(need IOM input about the report – data fields)
Both TB suggestive lesions as well as non-TB lesions shall be reported.
When the reporting is completed, the next CXR shall be opened. However, the CXR load shall be divided among available Consultant Radiologists equally (not by the reporting rate).
CXR access to DPP
When the CXR was reported by the consultant radiologist, both the report and the CXR shall be made available to the DPP consulting the particular applicant.
DPP shall note the observations, including any suspicions on TB. If there is a suspicion of TB had been raised either by the consultant radiologist or DPP, the sputum sample shall be ordered.
The CXR shall be available to DPP during the post-IHA consultation and counselling (BP13).
14
BP6: Laboratory information management system (LIMS) integration for phlebotomy
Process Activity
Phlebotomy
HIV ELISA – all applicants >15 years of age; infants where mother is ELISA +ve
Malaria – all applicants
Filaria – only applicants from endemic countries
When the applicant presents to the laboratory, the biographics, photograph and the biometrics are verified by the MLT.
At this point, IHAS shall generate three (03 – confirm the number) barcoded stickers and a unique phlebotomy ID. Hence, the laboratory shall be given Desktop computers integrated with barcode (or QR code) readers.
Barcoded sticker shall be used to rapid test kits where as unique laboratory ID shall be used to mark Malaria thin and thick films (where sticker is ineffective).
Results from internal laboratory
When results for rapid test are available, those can be entered to the IHAS against barcodes. The IHAS shall link the record with the biographics of the relevant applicant for DPP to review the results.
Dispatching Malaria thin and thick slides
Malaria thin and thick films shall be marked with the laboratory code using lead pencils. (discuss QR/bar code on slides if possible).
Malaria slides shall be dispatched to the AMC.
Results from external sources
The results of confirmatory tests and the sputum test shall be decoded and a copy of the result shall be stored in the LIMS component of the IHAS. This is to avoid loss/unavailability of information in case of a system/connectivity failure at NPTCCD, NSACP, AMC and AFC level.
BP7: Confirmatory tests by health programmes
Process Activity
Sputum sample – National TB reference
Encoded sputum sample shall be dispatched to National TB reference laboratory from IOM (following BP12).
National TB reference laboratory shall create a record for the applicant when the encoded samples were received. The applicant is identified by the code at the National TB reference laboratory.
15
laboratory, Welisara
As National TB reference laboratory performs GeneXpert, AFB and Culture tests, the relevant record shall be updated.
For this purpose, a barcode reader and a Desktop computer shall be provided to the National TB reference laboratory.
Upon receiving the encoded results, IHAS shall link the sputum test results with the boigraphics of the corresponding applicant. Thereafter, this results shall be visible only to DPPs at IOM and authorised personnel at IHAU.
Malaria thin and thick films – AMC
Blood samples from all applicants
Thin and Thick films for Malaria are dispatched to AMC. The blood films are marked with a unique Laboratory ID.
Needs to support batch processing.
When to refer the applicant – positive rapid test or wait till microscopy.
When IOM decides to send the blood films for malaria, the record for each client shall be created and made available to AMC with the unique laboratory code generated by the IHAS. The applicant is identified by the laboratory code generated by the IOM at the AMC. The results shall be entered against the laboratory code by the AMC staff.
Hence, barcode reader may not be required by the AMC. (need to discuss a possibility of a QR code for this with IOM. Will glass slides hold the sticker in place after processing. If so, MLT can use a book with the unique lab code and the slide will be dispatched with the QR code, which is smaller compared to a barcode. Can supply QR code reader instead).
Upon receiving the encoded results, IHAS shall link the Malaria microscopy results with the boigraphics of the corresponding applicant. Thereafter, this results shall be visible only to DPPs at IOM and authorised personnel at IHAU.
Filaria – positive rapid test
Only for samples +ve for rapid test
IHAS shall provide option to refer the applicant to AFC (see, BP13). The referred applicant shall be received by AFC and update the IHAS accordingly following the confirmatory tests (repeat rapid test and night blood film).
In order to do this, AFC shall have the access to IHAS. This interface shall accommodate the results of the repeat rapid test and night blood film.
When the result is available, it can be visible to DPP at IOM and the relevant authority at IHAU against the applicants biographics.
HIV ELISA positive
IHAS shall provide option to refer the applicant to NSACP (see, BP13). The referred applicant shall be received by NSACP.
If the applicant didn’t show up for the follow-up, NSACP shall update IHAU. IHAU shall inform DIE as the applicant is defaulted.
NSACP shall periodically inform the status of HIV/AIDS follow-up to HIU.
16
In turn, IHAU shall mark the applicant as ‘Defaulted’ if the applicant is lot to follow-up. DIE shall not extend the Residents Visa for such applicants.
BP8: Summarizing/reviewing the IHA by IHAU and recommendation for Residents Visa to DIE
Process Activity
Available results
Following results shall be available to IHAU immediately after the post-IHA consultation and counselling (BP13);
• HIV Elisa • Malaria rapid test • Filaria rapid test • CXR
Estimated duration for sputum Sample results
• GeneXpert: 24 hours • AFB – within 24 hours • Drug sensitivity – 6 weeks • Culture – 8 weeks
Hence, Tb shall be ruled out ONLY after culture, which takes approximately 8 weeks. To avoid the delay in Residents Visa application, IHAU shall proceed the case as Category B, recommending the applicant for a Interim Visa in case of pending sputum test result.
Recommendations Following is the summery of the IHA results for each IHA decision.
Decision IHA results Category A Medically cleared (all 4
screening tests) Category B Under medical treatment
and follow-up if at least one test is positive (or Sputum – pending result)
Category C Treatment defaulters (or non-complete HAP)
IHAU shall inform IHA decision categories to DIE.
Visa decision at DIE
Following is the recommended visa category for each IHA decision.
IHA decision Recommended Visa Category
Medically cleared (all 4 screening tests)
Resident Visa
17
Under medical treatment and follow-up
Interim Visa (and under follow-up)
Treatment defaulters (or non-complete HAP)
Terminate (case by case)
DIE shall take the appropriate action.
BP9: Surveillance of the applicants by health programmes and IHAU to observe the compliance to follow-up
Process Activity
Need to discuss with 4 programmes and IHAU
BP11: Queue Management
Process Activity
Queue Management
The IHAS shall facilitate queue management. This include;
• Adding DPPs to the queue management component • Selecting number of DPPs stations functioning each day • Updating working days/hours and holidays • Updating daily/hourly changes to available DPPs • Change the time for an appointment (in minutes) at Registration,
Nurse’s Counselling, DPP consultation, Radiography, Phlebotomy and Sputum Sampling. This will be used to prepare the queues for each station.
• Displaying an appointment time at Registration, Nurse’s Counselling, DPP consultation, Radiography, Phlebotomy and Sputum Sampling
• Option to select ‘On Hold’ (equivalent to temporarily not accepting applicants) and ‘Next Applicant’ on the relevant screens of IHAS linked with the appointment system. This option is available for all stations at Registration, Nurse’s Counselling, DPP consultation, Radiography, Phlebotomy and Sputum Sampling.
• When a station selects ‘Next Applicant’, • Shall be able to pause appointment rotation
At Biometrics By Appointment ID (issued in BP1 and BP2)
18
Display shall show 10 Appointment IDs to be catered next.
At Counselling By Registration Number (issued in BP3)
Display shall show five (05) Registration numbers to be catered next.
At DPP consultation
By Registration Number (issued in BP3)
Display shall show the five (05) Registration numbers with the DPP station number, to be catered next.
At Radiography
By Registration Number (issued in BP3)
Display shall show five (05) Registration numbers to be catered next.
At Phlebotomy
By Registration Number (issued in BP3)
Display shall show five (05) Registration numbers to be catered next.
At end of IHA counselling
By Registration Number (issued in BP3)
Display shall show five (05) Registration numbers to be catered next.
At Sputum Collection
By Sputum Sampling Number (issued in BP12)
Display shall show five (05) Registration numbers to be catered next.
Sputum Sampling Number shall be displayed in a separate Display.
Need to discuss with IOM – separate waiting area for Sputum Sampling
BP12: Sputum Collection
Process Activity
Registration Sputum Collection Area shall have a Desktop computer, finger print scanner and a barcode printer.
The applicant will be present with a Sputum Sampling Appointment Number.
In case of not having the Sputum Sampling Appointment Number, the MLT (need to confirm the role with IOM) at the sputum collection area shall trace the appointment with Passport number.
Upon retrieving the appointment, the biographics and biometrics shall be confirmed.
At this point the MLT shall print barcode stickers for the Sputum containers.
Thereafter, the applicant shall be explained on how to produce the sputum sample and shall be stressed that the applicant should report to Sputum Collection in next 2 days as well.
19
If the client failed to report for any of the sputum collection session, the applicant shall be noted as ‘Defaulted’ and the case shall be brought to the notice of the chief DPP.
Sample collection
When the applicant produced the sputum sample, the MLT shall observe the sample. The sample collection process shall be taken place under the supervision of the MLT.
If the sample is satisfactory, the sticker shall be pasted on the container and prepare the sample to be sent to the National TB reference laboratory, Welisara.
IHAS shall be updated as ‘Sputum Sample Collected’ with the date. With this IHAS shall create appointments for next 2 consecutive days as well and shall be ready to accommodate the status of next 2 samples.
If not, sampling process shall be repeated.
Dispatch The encoded sample shall be dispatched to the National TB reference laboratory by IOM staff within 12 hours.
Log IHAS shall log the time taken to complete the sputum collection
BP13: Post-IHA consultancy and counselling session by DPP
Process Activity
When post-HAP consultancy and counselling starts
Needs IOM advice – Morning HAP and evening post-HAP ?
Whether queue management shall cater for post-HAP as well ?
Exception All applicants underwent IHA shall be listed for post-IHA during the same day.
If an applicant didn’t show up for post-IHA consultancy and counselling, IHAS shall bring that to the notice of chief DPP before the end of the day. The applicant shall be contacted through the call centre. The applicant shall be flagged as ‘Defaulted’
Review HAP session
Biographics, past history (if pregnant pregnancy details, otherwise LRMP; if a mother, details and HAP results for children), CXR and results of HIV, Malaria and Filaria rapid test shall be available to DPP.
When this session is completed IHAS shall prompt DPP to confirm sharing the test results with the IHAU.
20
Schedule a Sputum Sampling
If TB changes in CXR is confirmed by the Consultant Radiologist
OR
If any suggestive history or doubts about CXR (without definitive TB changes in CXR)
DPP shall schedule a Sputum Sampling for the applicant
Refer to NSACP
? IOM advice
Suggestive history?
What shall be done for kids if mother is having a risky social history or positive Elisa?
If ELISA test is positive, DPP shall refer the applicant to the NSACP. IHAS shall offer the option for ‘Refer applicant to NSACP’. In this case, applicant’s biographics and the results of HIV ELISA, CXR and sputum test shall be made available to NSACP.
Refer to NPTCCD
Positive CXR
Suggestive History
How to track Sputum Test results – takes longer duration as discussed
An applicant having a CXR with TB changes, suspected TB case where sputum sample has been sent to National TB reference laboratory shall be referred to NPTCCD.
In such a situation, the applicant’s biographics, CXR, results of Sputum sample (when available), the results of HIV ELISA shall be made available to NTPCCD.
Refer to AMC If rapid test is +ve
Refer to AFC If rapid test is +ve
Other referrals
If CXR indicates any other abnormalities (such as scoliosis or COPD), that shall be noted in under the post-HIA consultation. The applicant shall be referred to a suitable medical practitioner and the detail of this referral shall be noted under the ‘Other referrals’ section.
BP14: IHAS analytics
Process Activity
By IOM
To be discussed
21
By IHAU To be discussed
By DIE ? needs
By NSACP ? needs
By NPTCCD ? needs
By AMC ? needs
By AFC ? needs
BP15: IHAS administration
Process Activity
Access Logs To IOM system admin. Need to discuss with IOM.
Backup To IOM System Admin. Need to discuss with IOM.
User creation To IOM System Admin. Need to discuss with IOM.
Roster Management
To chef DPP (MO-IC)
Password reset
By IOM System Admin upon request by user. Temporary password valid for 24 hours shall be issued (email/SMS).
Self, upon request by IHAS, periodically.
Overview of the integrated IHAS The diagram below illustrates the target integrated system after the introduction of the IHAS to the existing business processes at DIE, NSACP, NTPCCD, AMC and AFC.
22
Process, and technical features of IHAS
Key component IHAS and functions IHAS shall be considered to be consist of five main components. Apart from the central IHAS, the passport and biographic database of DIE, case-based health information systems (electronic registries) of NSACP, NTPCCD, AMC and AFC are integral parts of IHAS design and architecture. While NTPCCD and NSACP are having custom build information systems, AMC is using a customized instance of the open source public health information system, DHIS2 for its case-based operations.
Following are the key sub-systems of the IHAS:
• Appointment scheduling and service station management component • Registration and biographic/biometric capturing component • Counselling, consultation, referral and follow-up component • RIS • LIMS
The Bidders may consider and design Migrant Health Insurance component as a independent component (system) on its own. - - Need to discuss with MOH etc, the possibility of a health card (if so, independent Point of Issue ID perhaps?
Main system functions: IHAS The key objective of IHAS is to facilitate the active surveillance and following-up the applicants. In order to attain the above objectives, the IHAS shall perform the following broad functions:
• Verification of applicants (biographic/biometric) • Appointment scheduling • Registration to IHA and payment • Counselling, consultation, referral and follow-up • Radiographic imaging, storage and retrieval, radiology reporting (PACS compatible RIS) • Phlebotomy, rapid diagnostic tests for HIV, Malaria and Filariasis, Malaria thin and thick films
and sputum sampling, dispatch and results management (LIMS) • Confirmatory tests and follow-up of the applicants • IHA decisions and recommendation for Residents Visa • Messaging and alerts • Public Health analytics • System administration and back-up functionalities. These shall include, but not limited to
system analysis, security and access audits, system diagnostics, system back-up and restoration.
23
3 Health Security Coverage System
Overview of the HSC Process Currently, the non-citizens (excluding right categories, expats etc) of Sri Lanka are eligible only for the free accidents and emergency care from the state sector institutions. The objective of the health security card is to cover the expenses incurred during the routine care of the Residents Visa holder at state sector curative and preventive institutions. With the rising number of the resident visa holders, the government will have to bear a significant cost to provide routine and ambulatory care to non-citizens in the future. In-order to achieve this preferable pre-arrival health insurance scheme will be introduced to the Residents Visa applicants. A Health Security Card will be issued for each applicant, which should be produced at all state sector health institutions upon seeking the medical cate. Upon producing, the HSC shall provide priority care for the Residents Visa holder at the state sector institutions. HSC card is not valid for the private sector institutions or general practice settings.
Business process of the HSC An overview of the business process under the proposed HSC can be outlined as follows:
Overview of the business process The proposed system shall support migrants purchasing a health insurance offered by the MOH.
Verifying the visa status with DIE to decide the eligibility for the HSC Applying for the Migrant Health Insurance Accepting the payment for the health insurance premium. The premium shall be paid online
or on-site. To facilitate the online payments, the Residents Visa applicants’ Health Security Coverage
portal, HSCS, shall be integrated with the IPG of the IOM. Upon successful completion of the transaction, the biographic of the applicant together
with the picture taken at the IHAU shall be sent to print the Health Security Card. After verifying the card shall be posted to the resident visa applicants. Lost card: replaced with a fee
Business process and the activities
BP10: Applying for the Migrant Health Insurance and payment of premium
Process Activity
Verifying the eligibility
Need to discuss with IOM – eligible to apply and pay before initiating IHA?
24
The applicant’s eligibility to obtain the health insurance shall be considered case-by-case. In order to do this, the applicant’s Visa category and status need to be retrieved from the passport biographic database.
Registering for the HSC
The applicant’s verified biographics, biometrics and the photograph taken at the IHAU shall be used to register the applicant to the HSC process.
Exported biographics, biometrics and the digital photograph shall remain in HSC database until the applicant subscribe to the HSC scheme. Upon joining the HSC, the client’s profile is being created and the HSCS shall wait to accept the payment.
The default duration of the HSC is a one-year period from the date of registration.
The payment shall be done either online (through the IPG) or offline, by visiting the IHAU.
Printing the card
The IOM staff assigned for this purpose shall see the list of applicants who paid the HSC fee.
The staff member verifies the identity and the details provided by the IHAS.
The HSCS shall allow the user to print the card by placing a blank plastic card in the specific printer assigned for this task.
- Need to discuss with IOM the type of the card
Card (specifications)
Information on the card Type of the card: Magnetic and bar/QR coded OR Chip?
Information on the card
Picture
Name in applicant’s native language, English, Sinhala and Tamil
Passport number
PHN
Country
Address in Sri Lanka
Expiry/renewal date
Blood group (not recorded anywhere during the IHA process)
Inform lost card and replacement
- TBD
25
Main system functions: HSCS - TBD
• Verification of applicants • Selection of Insurance Type/Category • Review the policy/agreement • Payment • Issue Insurance card and dispatch/collect the Insurance card • Renewal of the insurance policy and the card • Lost cards
4 Overall system specifications Unless specified under the Technical Requirements the proposed system is expected to meet the following general system and design specifications.
System design fundamentals The major tasks are:
• Design, develop and implementation of the Inbound Health Assessment System (IHAS). • Integrating the IHAS with the passport data from the DIE • Integrating existing/proposed databased of NSACP, NTPCCD, AMC and AFC for further follow-
up of migrants. This shall include developing a basic eRegistry for AFC. • Design and develop the HSCS to issue Health Security Card
Design principles The proposed system must cover the following principles:
• The design should be efficient and effective. During design and development, is shall be noted that the clinical systems shall have the flexibility to handle unexpected situations. The system design should be simple yet comprehensive while exceptional cases should be handled outside of the normal queue (usually by the chief of DPP) and in a cautious way. In this way, attending the typical applicants will not be unduly prolonged while the security of the process will not be compromised. The chief of DPP hall have the authority to override the IHA process case-by-case.
• The design of the IHAS and HSCS should strike a balance between efficiency and accuracy. IHAS performance should be monitored and reviewed regularly for adjustment/modifications to suit operational need in a progressive manner.
• The design of the IHAS shall be discussed among the users and the system developer in light of the unique features of the integrated solution and the nature of the medical domain’s needs such as privacy and confidentiality of the individually identifiable health data.
• The IHA Unit and its operations are proposed based on current health assessment process in mind. Hence, the IHAS should be designed with the required level of simplicity of learning
26
capability (learnability). It should be noted the complexity of the IHA process and the system design shall not impose an additional burden or overly complexity to the routine tasks performed by DPPs or Nursing Officers (NO).
• It may take sometimes to understand the behaviour and the nature/profile of the Residents Visa applicants. Hence the Bidder shall peep provisions to this potentially broadening understanding of the applicant during the design and implementation process (e.g. language, cultural practices of the applicants).
Operational procedures to tie in with the integrated IHAS
The active participation of IOM, Ministry of Health and DIE representative is mandatory for the design and implementation of overall solution. Below are some examples where the input or views of the user are required:
• Detailed user requirements and hence system design of the IHAS and HSCS • Residents Visa categories and IHA decisions • Different categories of doubtful cases to be identified by the stakeholders • Detailed procedures for consultation, examination, investigation and decision making by the
IOM (whereby DPPs) and IHAU • Input of the DIE staff to design and integrate passport and biographic/biometric databases at
DIE • Agreement of various decisions pertaining to the operation of IHA and handling exceptions
and difficult applicants (e.g. diplomats, language issues, pregnancy, non-consent, defaulters etc)
• Detailed procedures and security arrangement of the sampling and sample dispatch to prevent frauds
• Role of IOM when the IHAU was handed over to the Ministry of Health (to be mindful whether the roles and operations might change in the future)
• Access authorities for various functions by different level of staff within the stakeholder organizations.
• Principles and procedures for release of biometric information by DIE to an outside entity • Health Information System roadmaps for NSACP, NTPCCD, AMC and AFC • Principles and procedures for release of patient details information by for NSACP, NTPCCD,
AMC and AFC • Formats for the following form templates: Applicant registration form, consent form,
consultation (history and examination) form, lab result sheets for each investigation, CXR reporting form, IHA conclusion and referrals (specimens and applicants), confirmatory test results from TB reference laboratory, confirmatory result forms
• Guidelines or standard operational procedures (SOP)s for following, but not limited to: applicant registration, counselling, consultation, radiography, phlebotomy, reviewing results, referral of applicant and specimens
• Technical agreement for health data sharing -whether to use a Master Patient Index (MPI) approach (with messaging) or simple database level integration (with or without APIs).
27
• Whether IHAU shall issue Public Health Identification (PHN) numbers for the applicants and IHAU shall obtain a Provider/Point of Issue ID to generate PHN numbers.
• Eligibility of the applicant for HSC and process of issuing the HSC card and renewal of it. Further to this, the type of card (magnetic/chip/barcoded) and information to be displayed on the card.
In coordination with IOM Project team, the Bidder must work closely with the designated staff of the IOM, IHAU, DIE and other health programmes of the Ministry of Health in determining the system functions and operating rules with respect to these process integration activities.
System administration operations and management
In order to properly manage the IHAS project, it is recommended that a System Administrator position shall be established at IHA Unit upon the implementation of the project to undertake the important role of system administration. These roles are explained in this paragraph.
System Operations
• The system shall provide the capability for IHA operations, including system re/srart and shutdown, component reconfiguration, and operational control and monitoring to be performed from a system dashboard accessed online.
• Dedicated system dashboard shall be provided, and configured with appropriate system settings, access control and database administration capabilities for the central control and administration of all IHAS configurations, databases, operational processes, system administration functions, maintenance, and reporting.
• The system dashboard on-line access to all operations and maintenance documentation for the central system.
• The system shall only need one operator knowledgeable in computer systems to perform all system operations and this operator shall be placed in the IHAU
System Configuration Management • A comprehensive capability shall be provided for the management of the system configuration
and system users. • The system design shall incorporate user-maintainable data structures (e.g., code tables for
visa categories, diagnosis and medical nomenclatures etc, user permissions) which define and control all standards, values, configurations and system security. These system features shall be supported by a comprehensive documentation and user training.
• At a minimum, the tables for the authorized users, user permissions, user access controls, medical coding, fee structures and API/integration settings shall be user-maintainable.
• The system shall be able to be maintained by a trained system administrator and shall not require reprogramming or manufacturer intervention to maintain system tables and basic configurations.
28
• The system shall provide capabilities that enable an authorized system administrator to easily edit, add, or delete individual entries in any table or update/replace a complete table.
• The system shall provide capabilities that enable an authorized system administrator to: o Update the system/s o Automatically log the updates for administrative reporting; and o Automatically report any update errors to the system administrator.
• Software version updates (if required, specially the APIs and middleware to integrate IHAS with passport database and the eRegistries of NTCCD, NSACP, AMC and AFC) and corresponding updates for user documentation shall be provided under the system warranty and any subsequent maintenance agreement.
• All software updates and software or hardware upgrades shall be subjected to formal change control review and approval before being applied.
• An administrative capability to track and report change history shall be provided with the system.
• The system shall include a capability to test changes in an operational system environment prior to introduction of the changes into the production configuration. If the changes are undesirable or needs further improvements, the system shall include a capability to roll back itself to the immediately previous configuration/system status.
System Status Monitoring and Diagnostics
The system shall provide system monitoring and alerting capabilities including:
• To automatically monitor the components, processes and infrastructure of the IHAS, and to provide real-time detection of the occurrence of system problems including hardware component failures (such as biometric scanners and barcode/QR code scanner), software problems and service interruptions.
• To automatically generate and send email messages for notification of the system administrator and/or the responsible maintenance entity regarding the detection of a system problem.
• System administrator dashboard display of system status and problems, access logs and error logs etc. However, the system shall not indicate any medically sensitive information including applicant identifiable information to the system administrators.
The system shall maintain system monitoring logs, which are defined as the date/time stamped record of system or component starts and restarts, system or component shutdowns and off-line conditions, hardware errors reported, software errors reported by the application servers and infrastructure electrical service and network communications interruptions.
The system shall provide on-line retention of daily system monitoring logs for at least 90 days, followed by permanent archival storage. The system shall be capable of providing error logs, access logs and logs of altering/deleting medical data and system status information in response to system user requests. This information shall provide intelligible assistance in the diagnosis of problems/issues.
29
The system shall enable authorized system administration and system support personnel to access the system monitoring log, and to selectively print reports for a specific error or incident or for a specified time period, from any stakeholder organization (e.g. API/integration failures, IPG failures). Reports shall be in an easy-to-read format that clearly states the nature and extent of the problem.
The system shall provide built-in system diagnostics and error correction capabilities, including:
• Interactive diagnostic tools with comprehensive capabilities for status checking and problem isolation for every component of the central IHAS configuration.
• Comprehensive on-line system administration documentation, including descriptions of system error messages and their interpretation, system diagnostic capabilities and operational procedures, and response requirements for specific problems.
Records management
All records captured in IHAS and HSCS, shall be maintained properly in the database permanently with all necessary maintenance and security protection.
Data Storage
• The IHAS and HSCS architecture shall include a high-reliability on-line data storage subsystem to provide storage for the on-line biographics and biometrics databases, medical records, administrative databases, system logs, etc.
• The database management system shall provide for full real-time synchronization of the mirrored on-line identification / verification databases and transaction logs.
• The on-line storage solution shall support the required long-term storage capacity requirements, and shall be expandable as needed over the life of the system to support the actual growth of the system. This shall be especially applicable to PACS/RIS components which has higher storage requirements.
Database and Archive Operations
4.3.2.1 Record Access, Query and Retrieval The IHAS design shall provide direct user access to the PACS enabled radiological images (RIS component) in the HIAS databases.
IHAS shall duplicate and store relevant data from the integrated systems (other stakeholder organizations) to ensure uninterrupted service during system failures beyond the control of IHAU. These include, the results of confirmatory tests, and follow-up status from NSACP, NPTCCD, AMC and AFC; and biographics of the passports of applicants and sponsors from DIE.
4.3.2.2 Database Content Analysis and Reporting • The system shall enable an authorized administrator to query and analyse any IHAS database
and log file, and to develop reports and statistical analyses of database contents, as required.
30
• The system shall permit access to database records and records-in-queue for review and analyses, such as database integrity checks.
• The system shall provide operating system utilities for individual and batch file manipulation, including copy, delete, dumping and merging.
Database Backup and Restoration The design of the database management system shall ensure that database transaction data is secured such that a temporary loss of communications or processing capability will not result in the loss of any data. This shall be combined with the browser-based (e.g. caching) approach to avoid data loss in a short-term network failure at the user end.
• All transactions received by the database management system shall be logged in a database transaction journal in real-time.
• The system shall automatically back up transaction journals at least daily as an element of database backup procedures.
• The system shall enable an authorized system administrator to access the database transaction journals and determine the status of the journaling process.
• The system shall provide the capability to restore transactions and restart operations under control of an authorized system administrator.
4.3.3.1 Database Backup • The system shall provide an automated database backup capability. • The backup shall not affect the on-line production operations. • Bidder shall identify any system downtime requirements associated with the regular or on-
demand full or partial backups of the IHAS and HSCS databases. • The system shall enable an authorized system administrator to interactively initiate a full and
partial backup of any system database, transaction log, or the system applications software. • The system shall provide backup logging and reporting that enables a system administrator to
monitor backup status and identify and report successful, partially successful and unsuccessful automated backups.
4.3.3.2 Database Restoration • The system shall provide interactive restoration/recovery capabilities, including the capability
to restore individual records, a database tables, or a complete IHAS database. • The system shall have a process to recover the databases from mirrored on-line backup and
transaction journals.
System security and access control The system security and access control shall satisfy the audits performed by Sri Lanka Computer Emergency Readiness Team (SL Cert).
31
4.3.4.1 System Security The bidder shall provide a detailed description of the security administration the bidder is proposing including authentication capabilities and how these capabilities will satisfy the security policies and eHealth Guidelines and Standards of the Ministry of Health, Nutrition and Indigenous Medicine.
The security management component in general must provide the following functions and capabilities:
• Automatically log-off of the current user with a given period of inactivity (shall be able to configure) and session-based user authentication, to ensure that there shall not be any erroneous entries in the usage log.
• An automatic log-off capability that will disable the access to on-line systems after a pre-determined time interval during which the workstation is inactive. The system shall include provisions to ensure that no in-process (e.g. during a counselling/consultative/phlebotomy session) or work is lost if a browser is automatically logged-off.
• All workstations shall have a standard password-protected screensaver at the completion of the implementation process.
o Workstation screensavers shall be configured to activate when the keyboard or mouse is not used for a (shall be configurable) period of time (initial default setting shall be 15 minutes – needs to discuss wot IOM).
o Re-entry of the login information (user ID + password) shall be required to regain access to the workstation.
o Users shall not install other screensavers or wallpapers; any data sharing applications (e.g. Drop Box) and access Social Media sites from workstations.
• Standard “remember your password” functions shall be disabled on all workstations/browsers.
• The system shall provide scheduled and on-demand administrative reporting including but not limited to:
o Periodic summaries of authorized users, including individual permissions, user status (active or suspended) and date of last log-in.
o Periodic password policy compliance audits. o Periodic security assessment audits, including unsuccessful log-in analysis.
Access control provisions • The system shall provide comprehensive tools and capabilities for administration of user
authorizations and system security. • The system shall enable an authorized system administrator to add and remove users, to
assign, modify and suspend access privileges for any user or group of users, and to reset passwords.
• All system workstations shall restrict each user’s access to the application, maintenance and operating system functions of the workstation and the system applications, according to each user’s specific access authorizations.
o The system shall support the assignment of specific access privileges for each user and shall enable the limitation of access to only those functions required by the user to perform his/her assigned tasks.
32
o Access to system functions shall be controlled by individual operator log-on identification. Login access shall be controlled with a unique user login name plus password. In production operations, generic user IDs and/or passwords for any component shall not be permitted.
• The system shall support strong password authentication and enforce associated password policies including periodic password changes for all users and prohibiting re-use of passwords for specified cycles.
• The system shall log all successful logons/logoffs and all unsuccessful logon attempts. • The system shall enforce a maximum number unsuccessful logon attempts, such that when
this limit is reached, the logon ID shall be automatically disabled and require intervention of the system administrator and chef of DPP to re-enable the user’s access rights. The system shall enable the system administrator to establish and update the “maximum unsuccessful logon attempts” parameter.
Virus and Malware Protection • Anti-virus software clients shall be installed, configured and maintained on all Desktop
workstations. o The anti-virus implementation on each workstation shall enable current virus
signatures to be maintained and automatically updated on all workstations.
Reports
Management Reporting • The IHAS and HSCS shall provide the capability to generate statistical analysis and system
activity reports, including standard pre-defined management reports and special reports. • The initial delivery of the system shall include a comprehensive set of standard management
reports that will be produced by the system on a regular recurring basis. Full reporting capabilities shall be provided with the initial operational capability delivery of the system. The selected Bidder shall work closely with IOM and IHAU to define all details of the standard management reports (report types, content, frequency etc.) to be implemented in and delivered with the initial system configuration.
• A capability shall be provided that enables a system administrator to establish regular reporting schedules for each type of report, and that produces the reports according to the pre-defined schedules.
• It is desirable is the system can enable the administrator to selectively generate any standard report on-demand.
Database Statistics Reports • The system shall provide standard pre-defined reports for reporting IHAS and HSCS database
content statistics, including: o Record counts by record type, originator, record date, etc. o Record counts and statistics for complete and incomplete records. o Record information for selected records.
33
• The system shall provide standard pre-defined reports for reporting database activity for a user selected time period, including:
o Record adds, changes and purges for a selected record type, originating agency, or a selected record.
o Record sealing activity. o Database audits and integrity checks. o Backup activity, status, and media usage for a selected date or time period.
System Transaction Activity Reports The system shall provide the capability to access transaction logs (specially, detailed logs of altering medical records and biographic/biometric data) and to develop standard pre-defined reports for reporting:
• System transaction activity during a specified time period, including: o Transaction counts by transaction type, user, time-of-day and day-of-week, etc. o Processing statistics for automated and manual processing and rejected transactions,
by transaction type, originator, etc. o System operations, including downtime and error incident counts and statistics. o Transaction, logon and security audits.
• System response time statistics during a specified time period, • Operations statistics during a specified time period.
5 System implementation requirements 4.1 System implementation requirements
The goal of this project is to complete the design, implementation, installation and integration of the IHAS and HSCS and achieve full production operations within the specified duration in the contract (-- check with IOM, by December 2018). However, the Bidder shall note the ongoing eRegistries and clinical information systems implementations by several stakeholders are beyond the control of IHAU and may affect the implementation trajectory of IHAS. The Bidder shall consider these when Master Implementation Schedules are prepared.
4.2 Contractor Responsibility
The selected Bidder shall be responsible for all aspects of system implementation, as required under relevant agreement, to accomplish the successful delivery of the required system and associated implementation services in accordance with the specified system requirements and established delivery timeline objectives. Contractor responsibilities shall include:
• Project planning and management;
34
• Refining the System Requirements Analysis and System Design provided by the IOM; • Network and infrastructure requirements specification; • System configuration and integration; • Installation planning and preparation; • System delivery and installation; • User training; • Project documentation; • System testing (include addressing the security recommendations by SL CERT) and transition
to production identification operations. • Supporting the system (preventive maintenance) for a three (03) year period (-- Duration
needs to be clarified with IOM)
The selected Bidder shall maintain effective communications with IOM Project Manager or any other party appointed by IOM, throughout the duration of the development and implementation process to ensure the effective exchange of information, responsiveness to customer inquiries and directives, and timely identification and resolution of questions and problems.
Implementation and Project Management It is necessary that a single contractor is required to take up the overall project implementation management (that is, IHAS together with IVR and HSCS development and integration with the DIE databases; and IHAS integration with the existing systems in IHAU, NSACP, NTPCCD, AMC and AFC, development and implementation of HSCS and the eRegistry for AFC) to ensure that there shall not be any omissions.
The IOM is responsible for overall project coordination and delivery of the hardware components. The selected CONTRACTOR in coordination and consultation with IOM project manager shall be responsible for all relevant aspects of project management as specified in respective agreement, including planning, staffing, performance monitoring and oversight, subcontractor management, project coordination, quality assurance and reporting. At minimum, following specific Implementation Project Management activities shall be performed.
Project Plan The selected Bidder in coordination with IOM Project Manager (clarify the post with IOM) must develop and maintain throughout the project a comprehensive Project Plan for the IHAS and HSCS implementation project, and shall maintain the project plan through the active implementation phases of the project. The Project Plan at minimum shall include the following:
• Project Implementation including planning Considerations (Quality, Dependencies, Planning Assumptions and Constraints imposed by internal and external factors and stakeholders)
• Products including product Breakdown Structure, Product Flow Diagram • Resources • Project Controls including Management Structure, Quality Management, Change
Management and Risk Management • Document Administration
35
• Project Staffing Chart – An organization chart and contact list for all individuals in the Bidder’s organization and any subcontractors who are assigned to the project or have a management or support role for any aspect of the project.
o Master Implementation Schedule – A detailed Gantt chart, showing the schedule for accomplishing all design, development, integration, delivery and testing activities, with milestone schedules for accomplishing the primary project milestones.
o Deliverable Schedule – A detailed Gantt chart showing the delivery, review and approval schedules for all deliverable reviews and documentation prepared in line with IOM overall delivery schedule. This shall include the system components as well as training and preventive maintenance during the project period (3 years, since AMC, NPTCCD etc doesn’t have a case-based information systems yet)
The Master Implementation Schedule shall include guaranteed dates for the key implementation and delivery milestones listed below.
• System Requirements Review for IHAS and HSCS • User Acceptance • System Installation Completion for IHAS and HSCS • IVR integration • IPG integration • System handover for security testing (by SL CERT) • User Training Completion and Acceptance • System Acceptance Test • Integration with DIE database • Development and implementation of the eRegistry for AFC • Integration with existing case-based registries in NSACP, NPTCCD*, AMC* and AFC* • Functional Capability Test Segment Completion • Performance Benchmark Test Segment Completion • Operational Availability Test Segment Completion • System Acceptance and Final Sign-off
* Shall not affect the Final Sign-off, since these stakeholders doesn’t have case-based information systems as of today)
The Deliverable Schedule shall include a detailed description and delivery schedule for reports, plans and technical documentation items that will be prepared and delivered in association with system implementation. At a minimum, the following Deliverable Data Items shall be prepared and provided in association with the IHAS and HSCS implementation.
o Project Plan (final) o Monthly Project progress Status Reports o Recommendation for hardware and service procurements (E.g. biometric devices,
IPG, SMS gateways and IVR services) o Site Preparation and Installation Plan o Roll Out Plan o System documentation for security testing o System Acceptance Test Plan and Procedures
36
o Transition Plan o Assets Registry o Training Curricula, Training Materials and Training Delivery Plan o System Maintenance Plan
The Deliverable Schedule shall reflect the understanding that all deliverables are subject to customer review and approval, and shall allow for rework to correct deficiencies (specially, security recommendations) prior to final review and approval. Bidder must submit a preliminary Project Plan as part of their response. The preliminary project plan shall provide at minimum specific details as described in 4.3.1 above including of the proposed Master implementation Milestone and deliverable schedules. The list of Deliverables in the Deliverable Schedule shall specifically identify user guide for each user category and system manual and documentation that will be provided with the system.
Project Management The project plan and Master Implementation Schedule shall be updated as necessary throughout the implementation cycle to reflect changes in scheduled activities. The baseline schedule shall be separately maintained to enable assessment of progress against the original schedule. The monthly project schedule update shall be delivered not less than three full working days prior to the monthly project status review meeting.
Project Status and Progress Reporting
Informal weekly reviews and formal monthly reviews of project status, progress and current issues shall be provided to the IOM project manager throughout the duration of the project.
• The selected Bidder shall prepare for and participate in informal weekly project status meetings with IOM and its stakeholders to discuss project status and to resolve issues. Directives, resolutions and action assignments shall be documented in writing by the Bidder’s Project Manager and the document shall be delivered to the IOM Project Manager no later than 4.00 p.m. of the next business day after the meeting.
• The selected Bidder shall prepare for and participate in formal monthly project review meetings with the IOM and its stakeholders. At the formal monthly project review, the Bidder shall present the status of all project tasks, identify problems and potential risk areas, coordinate the development of action plans to resolve issues, and discuss the detailed activities planned for the next reporting period. Each review shall include a detailed discussion of the project schedule and any actual or projected variances between the baseline schedule and the current activities. Directives, resolutions and action assignments shall be documented in writing by the Bidder’s Project Manager and the document shall be delivered to the Project Team no later than 4:00 p.m. of the next business day after the meeting.
37
Project Staffing
• Bidder shall be responsible for providing adequate qualified staffing for the project to accomplish the system implementation and provide the associated services in accordance with the contractually-established schedule.
• The project staffing plan shall include the identity and qualifications of key staff that will be assigned to the project, including key individuals for the following positions. Bidder must provide a staffing plan in their proposal response that identifies all key personnel, describes their roles and responsibilities, provides an experience summary for each key person that supports his/her project role (highlight any projects delivered for the State health sector of Sri Lanka), and defines the reporting structure of the project within the tenderer’s organization.
• The Bidder who had the prior experience in working with biographic/biometric databases, IPG and IVR integration, case-based medical record systems (specially at NSACP, NPTCCD, AMC and AFC settings) and the District Health Information System1 (DHIS2) which is the framework for Quarantine Health Information System at IHAU and aggregate public health information systems at NPTCCD and AMC, shall be prioritized during the selection process.
• Similarly, the past experience in implementing PACS and Master Patient Index (MPI) would be an advantage during shortlisting the prospective CONTRACTOR.
Key Personnel
5.4.1.1 Project Manager
The Bidder shall provide a dedicated Project Manager whose project management responsibilities shall include:
• Planning and monitoring project activities. • Working with the IOM Project Manager and other key stakeholders to ensure timely and
effective response to information requirements and to resolve actual and/or potential problems.
• Reporting on project status. • Providing analytical and technical expertise as required by the project. • Obtaining and scheduling the use of required Bidder’s resources. • Management and quality assurance of all required implementation and support services. • Quality assurance of all documentation deliverables
5.4.1.2 Other supporting professionals
The Bidder shall provide a list of other supporting professionals to ensure the smooth and successful implementation of the system. These professionals should include but not limited to, system
1 https://www.dhis2.org
38
engineers, QA engineers, health/health IT professionals, information security experts etc. Their tasks shall include:
• Oversight and coordination of the detailed system design and implementation activities, with ongoing monitoring to ensure conformance with all specified System Requirements.
• Primary technical liaison with the IOM with responsibility for defining and obtaining concurrence for implementation and operational details including workflows, component configurations, default settings, etc.
• Oversight and coordination of system integration and testing activities to ensure conformance of the system with system requirements and implementation agreements.
• Direct involvement in the preparation of formal test plans for pre-delivery, installation, and formal acceptance testing, and leadership of all formal testing activities.
• Quality assurance of system deliverables and associated technical documentation. • Training of staff in particular the system end user at the Ministry of Health. • Oversight and direction of the operations and maintenance support activities during the initial
warranty period and throughout the full production period.
Personnel Assignments and Access
• Bidder, subcontractor, and other personnel assigned by the CONTRACTOR to this project shall be apprised of and shall acknowledge their responsibilities with respect to the confidentiality of the operations and especially the personally identifiable health information. Hence, all staff the CONTRACTOR assign to the project must sign a Non-Disclosure Agreement (NDA) with the IOM with regards to the sensitive biographics and medical data which may be entrusted to them for the system testing purposes during the project period.
• IOM reserves the right to approve all personnel assigned to the project, including all proposed staffing changes, and to explicitly authorize participation and facilities access for each assigned individual. IOM and Ministry of Health reserves the right to unilaterally request the replacement of any individual assigned to the project, and the Bidder shall accomplish the replacement with a person of appropriate qualifications for the assigned position in a timely manner.
• All personnel who perform services at any DIE facility, or have access to data (with regards to the passport biographics and biometrics), shall be required to pass a background check, including a fingerprint-based criminal history check. Individuals who do not pass a background check will not be allowed to access facilities or data.
39
System Design High level system overview and a design shall be provided by the IOM. However, a detailed system analysis and design shall be produced by the Bidder and shall be discussed with IOM in order to prevent ambiguities and gaps of understanding among the various parties involved in the project.
Design documentation • The Bidder shall design the IHAS and HSCS providing comprehensive capabilities as defined in
respective Requirements Specification, and shall apply internal quality control processes to verify that the system design is in conformance with each and every detailed functional and performance requirement of the system.
• In support of development of the system design, the selected Bidder for review and approval in accordance with the deliverable schedule established in the Implementation Project Plan. The System Design Documentation shall include:
o A requirements traceability matrix, providing a reference index to the system/subsystem element and/or workflow that satisfies each technical requirement in the IHAS and HSCS Requirements Specification.
o A data model for each of the system databases. o A comprehensive set of system workflows for accomplishing all required elements of
transaction processing. o A system configuration specification, including Interface Control Document (ICD)
sections describing the physical and logical configurations of each internal and external interface of the proposed system. These shall include the interface for IPG, IVR, passport biographic/biometric databases of DIE and case-based medical record systems at NSACP, NPTCCD, AMC and AFC.
Change Management Mechanism
• Once the detailed design is agreed between the IOM (and other stakeholders) and the CONTRACTOR, any subsequent request for change of the design by either party shall be subject to a change mechanism agreed by both parties in advance and normally upon project initiation or during the design of the system. The process normally comprises the following steps:
o Raise a change request form as agreed beforehand with details of the proposed change and an initial assessment of the impact for consideration by all parties.
o Request will be evaluated by appointed representatives of both parties with particular attention to the project schedule, resources requirements, etc. and each party will indicate their decision.
o Change will be made if the request is endorsed. Otherwise the issue will be negotiated among parties for a final decision.
• However, the IHAS integration with case-based medical record systems at NPTCCD, AMC and AFC shall be negotiated case-by-case basis. (-- Need to discuss these with 3 programmes and IOm)
40
System Installation
Installation Planning and Management • The Bidder shall be responsible for planning and accomplishing installation of following;
a. Central server with IHAS and IHIS b. Operating Systems (provided by IOM), Drivers and antivirus software (provided
by IOM) for all Workstations c. Installation of digital camera finger print and barcode scanners; and laser and
barcode printers and integrate them with the relevant Workstations d. IPG and IVR integration e. Installation of middleware for X Ray machines and PACS integration f. (? Any lab equipment integration – IOM) g. Installation and configuration of the Local Area Network (LAN) in IHA Unit h. Integration with existing databases at IHAU, NSACP, NPTCCD, AMC and AFC
• Similarly, the Bidder shall coordinate the installations to ensure minimal impacts to operations
at each installation site. • The central IHAS and IHIS shall be installed in the data centre facility provided by IOM. This
will be physically located in Sri Lanka. • The Bidder shall work cooperatively with IOM and the other stakeholders to identify the
specific installation location(s) for each deliverable component and to coordinate the system installation and testing, including workstations and peripheral components.
• Bidder shall coordinate with, if necessary consult and support the SUPPLIER who would be responsible for the installation of the LAN in the proposed IHA Unit. (-- check with IOM)
Site Surveys
• The Bidder shall conduct site surveys of IHA Unit, IHAU, DIE, National TB Reference Laboratory – Welisara, NSACP, NPTCCD, AMC and AFC to identify specific installation requirements to support preparation of a detailed installation plan. This shall include, but not limited to;
o A detailed equipment integration plan and suggests arrangement for installation site o Adequacy of power supplies o Required network connectivity at each installation area and site-specific requirements
for LAN outlets. (--- with IOM: assumed that network will be done by a different supplier)
System Delivery and Installation
• Bidder shall be responsible for coordination and accomplishing the delivery and installation of IHAS and IHIS; and integrating the same with the other components listed in 4.6.1.
• This shall include, o Loading software and databases as necessary and configuring all components to
operate in the desired manner.
41
o Connecting the installed components to the communications networks at each installation location and verifying interfaces with external systems, including the passport biographic/biometric system at DIE and case-based medical record systems at NSACP, NPTCCD, AMC and AFC.
• The Bidder shall Inspect and test all installed components to verify complete functionality of the system and the operability of all system interfaces.
• At the completion of system installation and successful accomplishment of the installation test, Bidder shall certify the availability of the full operational capabilities of the installed system and obtain IOM and its partners approval to proceed with formal acceptance testing.
Privacy protection Since the project involves highly sensitive medical information and personal information such as biographics and biometrics. Hence it is utmost important for all parties pay particular attention to the privacy and confidentiality of the information entrusted to them and stored in the databases.
• The Bidder shall ensure the privacy and confidentiality of the data stored in the system, and safeguards the personally identifiable and medically sensitive data with suitable measures in the system design.
• The Bidder shall consult each stakeholder (specially health sector) to identify the specific privacy/confidentiality practices and to device appropriate security measures in delivering the system.
• System design shall include 64-bit encryption of mandatory data elements, such as biometrics, biographic and test results such as HIV ELISA.
• Further, it is necessary to limit the access to medically sensitive data with a proper access control policy tied up with the user roles.
System Test and Acceptance The System Design Diagrammes (SDD) shall be accepted and signed off both by the Bidder and IOM. These shall serve as the framework for test and acceptance by both parties. The final User Acceptance Test (UAT) shall be subject to confirmation by the other stakeholders also, as specified in the project plan.
• The objective of system test is to ensure that all required functionalities of the system fully meet the expectation of the user as stipulated in the SDD. Following test shall be performed prior to the User Acceptance Test (UAT)
a. Component Testing: Internal test of the newly developed product by the contractor- These normally include internal system test and quality assurance by the contractor, including programme validation, unit test, and module test.
b. Integration Testing: This follows the component testing. Pre-agreed test cases shall be used to test the integrated system. All system interfaces (hardware and software) shall be tested during the integration test.
• Security Testing: Since the security and the privacy is a key concern in IHAS, IOM shall handover the integrated system to SL Cert for a through security audit.
• User Acceptance Test (UAT): The developed system shall be delivered to the user for thorough test and trial prior to the formal roll out of the system. The UAT involves the testing of all
42
required logics, design, functions, loading, performance, and resilience of the system. A detailed UAT plan should be worked out by the user in consultation with the CONTRACTOR. For this purpose, UAT data should be prepared well before the actual conduct of the test. UAT test data should cover all parameters, including normal and abnormal cases and outliers and exceptions to identify the inadequacies or bugs of the system.
a. Biometrics and barcodes shall be specially focused during user acceptance test. The sensitivity of the scanners shall be tested with adequate number of samples.
b. PACS integration shall be tested with real PACS enabled digital CXRs • After passing the initial UAT, it is also necessary to conduct trial run of the integrated system
in the simulated production environment to test the integrated system. The system roll out shall be authorised only after the reviewing the trial run by all the stakeholders.
• Load and stress testing shall be performed using a simulation tool. • Testing IVR and instructions to the applicants: The voice and text messages have to be
validated with native speakers of the respective languages. • IPG integration: The IPG shall be tested first, IPG in sand-box mode with test credit card
numbers provided by the bank and then with the IPG in full operational mode with real credit cards (with and without 2 factor authentication and 3DS failures).
• After the roll out of the system, the Bidder shall constantly attend to the software bugs, inadequacies and problems of the newly developed system in the live production environment. The problems shall be addressed and remedied immediately. The bidder shall assist users to overcome the operating problems and this should be noted and addressed during the training. Two (02) month of nursing period shall be recommended prior to the formal acceptance of the IHAS by the users.
Documentation and source code All documents relating to the project should be available for reference by the IOM before the roll out. These documentations shall include, but not limited to, the following:
• System operation manual, including system and hardware configurations • System documentation including system design and architecture, system specifications and
component integration instructions, database design etc • User manuals for each organizational user categories • Training guide: These shall include the training guides for end user categories, system
administrator and maintenance staff. • Source Code: The bidder shall use a consistent coding practice in all components of the IHAS
and IHIS. Similarly, appropriate comments shall be included in all places of the software source code.
43
6 System maintenance and enhancement
Scope of Maintenance and Support A comprehensive programme of technical support, operations support and preventive and remedial maintenance support for IHAS and IHIS system, including the equipment and software, shall be provided throughout the life of the system. The required elements of this support are:
• IHAS and HSCS product and application support, including system configuration, system operations, database administration, reporting, system performance monitoring and enhancement (e.g. threshold setting etc.), backup and archival operations, and system recovery operations.
• Technical coordination with and support of IOM as necessary for security configuration and interoperability.
• Regular preventive maintenance of the system. • On-site remedial response to hardware or software problems. • Repair or replacement of defective components and components that can no longer maintain
required levels of performance. • Software version management (if applicable), with regular updates to apply approved patches
and updates, maintain current versions of all software components and to achieve or maintain compliance with new and evolving Sri Lanka Government standards.
• Technical support for system expansion and extension of standard services to new users. • System configuration management. • System backups and restores. • Periodic reporting of routine activities and problem detection and resolution status.
All service and support of the system processing components, software, and workstations, if any, shall be provided under a comprehensive System Maintenance Agreement for the system. The System Maintenance Agreement shall provide for all of the maintenance support elements defined above, and the selected Bidder shall be solely responsible for delivery of maintenance services under the Agreement.
System Warranty • The system shall be covered by a comprehensive three-year (-- need to agree the period with
IOM) warranty, under which all elements of system maintenance and support as specified in the contract are provided at no additional cost for the two-year period beginning upon successful completion of the Operational Acceptance Test and final acceptance of the system.
• The following extended warranty and support options shall be provided: o Annual renewable maintenance: (year-to-year system maintenance beginning after
the base 3-year system warranty period). o 5-year Extended Warranty support option: base 3-year system warranty plus 2
additional years of warranty support)
44
System Maintenance • The Bidder shall provide first-line operations support, preventive maintenance, warranty
maintenance and on-call remedial maintenance of the system in accordance with the following detailed requirements.
• System maintenance shall be provided throughout the life of the system, so long as contractual maintenance coverage is maintained by IOM (--- or Ministry of Health? When is the HANDOVER planned?). System maintenance coverage shall not be terminated or discontinued by the Bidder during the operational life of the system. The Bidder shall not refuse to renew the maintenance contract or unilaterally modify the terms of the maintenance contract.
Local Technical support • The selected Bidder shall provide sufficient number of technicians in IHA Unit to provide all
on-site maintenance services and coordinate remedial maintenance as required. If the need arises, the technicians shall visit other places as directed by IOM. These shall include, DIE, NSACP, IHAU, NPTCCD, AMC, AFC and National TB Reference Laboratory, Welisara.
• The Bidder’s local technician shall be able to respond and be on-site within two hours of a call for service.
• The technician shall be fully trained and qualified to provide all aspects of operations support, preventive maintenance, first-tier remedial maintenance, management of the spares inventory, performance of system backups and regular status reporting regarding routine operations and problem detection and resolution.
• The assigned technician shall successfully pass a DIE background check if they attend any service at the DIE.
• At their sole discretion, the IOM may request, and the contractor shall comply with the request to replace the assigned technician.
• Bidder shall provide a help desk capability that answers calls for service for incidents, problems and questions during the operational hours of the system, and that coordinates problem resolution.
• The help desk shall be staffed with technical system specialists, providing expertise in systems operations.
• The help desk shall have remote diagnostic capabilities for remotely diagnosing problems and for either correcting problems remotely or providing detailed problem information to the local area technician.
• The help desk shall maintain a detailed date/time-based log of all calls for service with updates documenting the response to the call and the resolution of the service issue. Bidder shall provide a monthly report of calls for service.
Software Maintenance • Bidder shall provide software maintenance support to keep the software system up to date
and free from bugs; and shall rapidly respond to and correct problems with system functional capabilities and databases.
45
• Bidder shall provide software updates (especially, if security vulnerability was revealed) modifications/patches and associated documentation updates to maintain optimum operational capabilities of the integrated system.
o The local technician shall assist IOM or Ministry of Health personnel in determining the necessity of applying critical and routine software updates.
o A formal change management process shall be implemented and used to provide scheduling and obtain approval for all software modifications.
• Preventive maintenance of the system and related system components shall be scheduled and performed on a regular basis. The regular schedule for each facility shall be coordinated with facility or component managers to be at times selected to minimize impacts to operations.
• Bidder shall correct all system problems, whether caused by hardware or software or both in combination, when the problem reduces the functional or performance capabilities of the system or otherwise impacts operations. Remedial maintenance coverage shall be provided during the operation of the system.
o The local area technician shall acknowledge a call for service within 10 minutes of the call and inform the call originator of the plan of action.
o If applicable, remote diagnostics and remediation shall be initiated within 1 hour of the call for service to investigate or resolve the problem, and the call originator or a unit supervisor shall be notified when remote access to the workstation or component is to be initiated.
o If an on-site response is required, an estimated time of arrival shall be provided. For central IHAS and HSCS problems, the Bidder shall try to attend the issue remotely and immediately. For the on-site response regarding the central server, the response time shall be not more than 90 minutes.
• Throughout the resolution process, the call originator shall be kept informed of the progress of the resolution effort and shall be notified when the problem is resolved.
• Complete restoration of system capabilities shall be expedited to maintain the required level of system availability established in this specification.
Maintenance Scheduling, Problem Tracking and Reporting • Comprehensive management of the maintenance program shall be provided during the life of
the contract, including: o Maintenance scheduling and management reporting. o Problem tracking using a formal problem tracking, resolution and sign-off
methodology. o Standard problem escalation procedures for handling all types and levels of problem
situations. o Regular reporting of the status of all routine operations support, preventive
maintenance, and problem response and resolution. • A problem log and service record shall be maintained for each system hardware (e.g.
Biometric scanners) and software component. IOM system administrators shall have interactive capabilities to access the log and obtain information to aid assessment of system availability and effectiveness.
46
• An incident report shall be prepared and provided upon completion of each remedial maintenance call. The report shall include at least the following information:
o Institution/location (Central Server, IHA Unit, IHAU, IHAU, National TB Reference Laboratory – Welisara, NSACP, NPTCCD, AMC or AFC)
o Type of incident o Date and time notified o Date and time of arrival/attending the issue (in case of central server related problem) o Time spent for repair o Time repair completed o Service provided o Description of malfunction o List of items replaced o Action taken to prevent recurrence o Whether requires a software/database upgrade (e.g. a software bug, omission,
restructuring for a database table) o Signature of site representative
System Maintenance Plan • A comprehensive System Maintenance Plan shall be developed and maintained describing the
plan and procedures for managing and providing system maintenance and operations support. The System Maintenance Plan shall include the following:
o Maintenance Responsibility: Need to discuss with IOM/Ministry of Health; which stakeholder is responsible for which (up to which level) kind of maintenance, what are the maintenance operations assigned to the CONTRACTOR. CONTRACTOR and other stakeholders shall list the qualifications of their maintenance staff. The Bidder shall be responsible for the training of the maintenance staff.
o Warranty Period and Warranty Maintenance: Need to discuss with IOM o Operations Support: A detailed discussion of operations support, including a
description of procedures for backup operations and backup QA, procedures for maintaining system virus protections, procedures for software update assessments, and other operations support activities that will be provided under the Maintenance Agreement. The section shall describe the planned frequency of each of the operations support activities, a description of how the services will be scheduled and coordinated, and proposed Service Level Agreement (SLA) performance levels.
o Preventive Maintenance: A detailed discussion of preventive maintenance, including a description of periodic service requirements (database backup, calibration of biometric scanners, etc.), the time required for each type of service, the planned frequency with which preventive maintenance services will be provided, a description of how the services will be scheduled and coordinated, and proposed Service Level Agreement (SLA) performance levels.
o Remedial Maintenance: A detailed discussion of remedial maintenance procedures, including the problem response approach and sequence of activities, the methods used to ensure that response times are met and system availability requirements are maintained, a description of repair/replacement procedures and timeframes, a
47
description of procedures for problem tracking, escalation and reporting, , and proposed Service Level Agreement (SLA) performance levels.
Technical Support for On-going Operations and System Enhancement/Expansion
• The selected Bidder must (-- need to discuss with IOM, MUST or EXPECTED TO, but optional) provide technical support throughout the life of the system, at the request of the IOM/Ministry of Health. This support shall include, but not be limited to, configuration management, periodic testing and training, and system expansion planning and implementation.
• The Bidder must coordinate a meeting between Bidder’s Account Manager and IOM system managers regularly, not less than semi-annually, or on ad hoc basis, to review the status of the system and discuss operational issues, review the maintenance history and discuss any chronic problems, coordinate upcoming major activities, and discuss new reliability improvements and enhancements. – Needs to check with IOM. • -- needs to check with IOM, preferable to have an Escrow Agreement and keep the source
code with a 3rd party in case CONTRACTOR refuse to continue the tech support for expansions
Test and Training Support Bidder shall provide technical support for annual system testing and training exercises, as follows:
• Annual performance benchmark test: Bidder shall configure and operate the system to repeat the Accuracy Performance Benchmark Test originally developed and performed as part of final system acceptance testing.
• Annual Disaster Recovery / Business Continuity Training Exercise: CONTRACTOR shall support the planning, preparation and conduct of an annual training exercise to ensure familiarity of all personnel with Disaster Recovery and Business Continuity procedures.
System Expansion • Bidder must (--again can’t expect this to be a MUST. So, need to discuss with IOM about an
ESCROW) provide technical support for planning, implementing and testing customer-directed expansions and extensions of the IHAS and HSCS, including but not limited to:
o IHAS expansion to provide additional functionalities (or remove existing practices, such as outdated laboratory tests).
o Extension of IHAS/HSCS services to other health sector programmes in the Ministry of Health, Sri Lanka, as authorized by the IOM/Ministry of Health.
o Future integrations of IHAS with any other State health sector systems due to organizational policy issues (e.g. introduction of a sector-wide MPI)
o Network expansion planning, specification support, reconfiguration and testing as necessary to maintain performance as system workloads increase, and to maintain compliance with Sri Lanka and DIE Security policies.
48
7 General requirements on System Testing, Deployment and Training
System testing The Bidder shall comply with the test plans in order to ensure that all required functionalities of the system fully meet the expectation of the user as stipulated in the SDD. The Bidder shall, at minimum, follow these steps in system testing:
• Component Testing: Internal test of the newly developed product by the contractor- These normally include internal system test and quality assurance by the contractor, including programme validation, unit test, and module test.
• Integration Testing: This follows the component testing. Pre-agreed test cases shall be used to test the integrated system. All system interfaces (hardware and software) shall be tested during the integration test.
• Load and stress testing shall be performed using a simulation tool. • Security Testing: IOM shall outsource the security audit to SL Cert. However, the Bidder shall
support SL Cert to carry out the security audit and address the security concerns revealed prior to the UAT.
• User Acceptance Test (UAT): The developed system shall be delivered to the user for thorough test and trial prior to the formal roll out of the system. The UAT involves the testing of all required logics, design, functions, loading, performance, and resilience of the system. A detailed UAT plan should be worked out by the user in consultation with the CONTRACTOR. For this purpose, UAT data should be prepared well before the actual conduct of the test. UAT test data should cover all parameters, including normal and abnormal cases and outliers and exceptions to identify the inadequacies or bugs of the system.
a. Biometrics and barcodes shall be specially focused during user acceptance test. The sensitivity of the scanners shall be tested with adequate number of samples.
b. PACS integration shall be tested with real PACS enabled digital CXRs • After passing the initial UAT, it is also necessary to conduct trial run of the integrated system
in the simulated production environment to test the integrated system. The system roll out shall be authorised only after the reviewing the trial run by all the stakeholders.
• Testing IVR and instructions to the applicants: The voice and text messages have to be validated with native speakers of the respective languages.
• IPG integration: The IPG shall be tested first, IPG in sand-box mode with test credit card numbers provided by the bank and then with the IPG in full operational mode with real credit cards (with and without 2 factor authentication and 3DS failures).
• After the roll out of the system, the Bidder shall constantly attend to the software bugs, inadequacies and problems of the newly developed system in the live production environment. The problems shall be addressed and remedied immediately. The bidder shall assist users to overcome the operating problems and this should be noted and addressed during the training. Two (02) month of nursing period shall be recommended prior to the formal acceptance of the IHAS by the users.
49
Test Plan The Bidder at minimum, shall carry out the following functional and non-functional tests:
• Recommended functional testing types include; a. Unit testing b. Integration testing: The objective of the System Integration Test is to verify
whether the system performs properly with its various components and with the external systems with which it interfaces
c. System testing, including problem diagnosis d. Interface testing e. Regression testing (if a major bug discovered after system roll-out) f. Acceptance testing (please see 6.1.2 below)
• Recommended non-functional test types include; a. Performance Testing b. Load, Stress and Resilience testing: The Bidder shall coordinate and perform
comprehensive Load/Stress/Resilience Test after the successful completion of the System Integration Test by preparing Load/Stress/Resilience Test plan, and providing the required resources including, but not limited to, Load Test applications equipped with business scenarios creation, execution and performance monitoring, thereby simulating the realistic heavy workloads of selected user locations, and carrying out the Load/Stress/Resilience Test. The Bidder shall provide Load/Stress/Resilience Test tools to simulate various functions/scenarios in the response time requirements and to verify that the System meets the performance requirements. The Load Test tools shall be able to capture detailed performance statistics by each type of transaction, application, system process and system resource, and identify any performance bottleneck.
c. Volume testing: Testing the system for high volume of data, such as PACS compatible imaging between RIS component and X Ray machine.
d. Security testing (The bidder may perform own security tests even if the security audit shall be outsourced by IOM)
e. Compatibility testing: This shall be performed to ensure browser compatibility, compatibility of the radiological monitors to PACS standards, hardware compatibility, such as digital camera, fingerprint scanners, barcode readers, X Ray machines with the respective middleware and invoked software methods. Further, this shall ensure the functions and facilities of the hardware and the software the system intended to rely upon are compatible to each other. It should be performed by the Bidder after proper installation of the system and to submit to the IOM certifying that all the hardware and software and every part thereof are operating in full and proper working order.
f. Recovery testing g. Reliability testing: The Bidder shall provide means for measuring system
performance and reliability of the System.
50
h. Usability testing: User-friendliness, application flow, predictability and learnability of the system shall be checked.
i. Compliance testing: Whether software system complies with standards and guidelines prescribed by the NeHSG, PACS and biometric standards etc.
j. Localization testing: Unicode support and IVR integration
• Depending on the nature of any failure in the test or any failure in specified component of the system, the Bidder, shall provide such replacement programmes to rectify the failure. In the event that such replacement software programmes fail to enable the system or unit such the system pass the said test, the IOM is entitled to reject such replacement. In such occasion, it will be considered that the said replacement fails to conform with the agreement, and hence, IOM shall refuse to accept such replacement of the system subject to with or without an abatement of the price of the supplied system, in an amount which, taking into account of the circumstance.
• As the final step of the testing process, a Trial Run shall be initiated. The stakeholders recommended to conduct the trial run for two (02) months period to understand the impact of the system in the domain practice prior to full scale roll out.
System Acceptance Testing The system shall be subjected to a sequence of formal tests associated with major implementation milestones, and each formal test shall be performed and successfully completed before the Bidder will be authorized to proceed to the next implementation stage. The following formal and informal acceptance tests will be performed at the designated implementation stages:
Test Implementation Pre-requisite
Result of Successful Completion
Site Installation Verification and Operational Readiness Test
Completion of system development, database loading, site installations, network connectivity, and final configurations.
Approval to commence final Formal Acceptance Test
Unit Acceptance Test (informal and not mandatory)
Completion of development of independent modules or units of the target system without major impact on other units so to speed up the testing process
Proceed to Formal System Acceptance Test
System Acceptance Test (SAT) Completion of system delivery, user training, and establishment of the support infrastructure.
Completion and sign-off of formal acceptance testing.
Operational Acceptance Test (OAT)
Completion of Formal System Acceptance
System acceptance and authorization of final payment.
51
Testing and certification of tentative acceptance of the system.
• The Site Installation Verification and Operational Readiness Test shall include: o Inspection of all equipment installations, including digital and radiology imaging
equipment, biometric and barcode scanners and Workstations etc ; o Inspection and acceptance of database loading; o Operability verification of all component-level functional capabilities; o Operability verification of system interfaces and system workflows. o Inspection of system administration documentation and user guides.
• The System Acceptance Test (SAT) shall include: o A comprehensive functional test demonstration of all system capabilities in an
integrated mode; o A throughput and accuracy performance benchmark test; o Verification of completion and certification of all user training. o A final verification of complete requirements satisfaction using a comprehensive
requirements matrix. • The Operational Acceptance Test (OAT) shall include:
o Successful completion of at least two (02) months of full production operations. o Analysis of production data and activity reports, and confirmation of required
operational availability and performance levels. o Resolution of all outstanding deficiencies and retesting as necessary. o Final acceptance certification.
• Bidder shall prepare and deliver a formal System Acceptance Testing Plan and Procedures (SAT Plan/Procedures) document, which shall be used to coordinate each stage of system acceptance testing. The SAT Plan/Procedures shall include a detailed definition of all tests, including:
o Operational, functional and performance test scenarios and procedures. o Makeup and content of test data sets. o Operational and technical oversight and support during testing, and the roles of
participants. o Development, management and reporting of resolution plans for correcting any
system deficiencies and discrepancies that are found during acceptance testing. • A detailed requirements traceability matrix shall be included in the SAT Plan/Procedures
which shall facilitate the assessment of the test plan, test results and compliance of the system with all requirements.
• The SAT Plan/Procedures shall be prepared and delivered not less than four (4) weeks prior to commencement of the final SAT. Bidder shall include the proposed testing and delivery schedules in their proposed Master Implementation Schedule, and shall include the initial delivery and each test-specific update of the Acceptance Test Plan and Procedures as deliverable milestones in their Implementation Schedule.
52
• The Bidder shall provide assistance to users in the preparation and conduct of the user acceptance test. The Contractor shall be responsible for, without limitation, the following:
o Preparing test plan with detailed schedule and high-level test cases for each function to assist users in preparing detailed test cases
o Arranging walk through the test plan and high-level test cases with users to explain the purposes, the expected number of detailed test cases for different combination of data and the expected results for each test case
o Providing utility programs to generate data for test cases with given criteria o Providing on-site support and assist users in data setup. For example, import data
prepared in spreadsheet into the System o Providing all necessary support to facilitate users in conducting the test o Assisting users in analyse the test results o Arranging back up of the test data in each step with proper labelling o Formulating documents for auditing purposes
Trial Run After completion of the System Acceptance Test, a Trial Run shall be recommended before committing for a roll out of the system. As suggested by the stakeholders, for the IHAS, the Trial Run for two (02) months duration would suffice. The whole system, including software and hardware as well as the staff shall be tried out in real environment during this phase. The objective of the trial run is to enable the staff to experience the integrated system as a rehearsal and to be familiarises with the new system and procedures. The Bidder shall assist IOM to trial run IHAS followed by the Acceptance Testing.
8 General requirements on training It is essential for all the users of the proposed system are thoroughly trained preparing them for the system roll out. It is essential that staff will be given integrated view during the training in particular, those who are functioning as front-end operating staff. It shall be noted that most of the staff personals may be subjected to annual transfer orders in the State health sector. Hence, the training programme shall be comprehensive, yet easily administered and highly learnable.
Scope • The selected Bidder shall provide comprehensive training in the operations and management
of the IHAS and HSCS; including handling biometric and barcode scanners and workstations as applicable to system users, supervisors (e.g. chief DPP), system managers and operations support personnel.
• The system shall be capable of supporting training of users without impacting the operations or the integrity of databases (e.g. purging training/test data without affecting the data captured at the live run).
• The following types of operations and administration training shall be developed and provided for DIE management, administrators, and operations staff:
53
o System Users: Detailed training for designated users of relevant system workstation or equipment. The training shall include an overview of the system and a discussion of general operational concepts and support procedures, along with detailed classroom and hands-on training in the operation of all functions of the specific workstation. Individual training courses shall be designed for each operational unit (e.g., Floor Manager, Nurse Counselling, DPP stations, Radiographer and MLT, etc.).
o Call Centre Operations: o Biometric capturing: A 1-2 hour hands on training shall be provided on capturing
biometrics and applicant verification. o System Administrators: Detailed system and application-specific training for the
assigned system administrators in the use of the System including procedures for IHAS and HSCS, system administration, database administration, user administration, security administration, and system monitoring and reporting.
• Technical orientation and maintenance training shall be provided for the designated staff who are responsible for system maintenance at IOM, IHAU, DIE, National TB Reference Laboratory – Welisara, NSACP, NPTCCD, AMC and AFC. It should be noted that most of the staff who were assigned for the system maintenance in health sector are not formally trained ICT personnel (e.g. Attendants or Labourers). Hence, the training programme shall be able to cover the basics the relevant ICT concepts and gradually focus the system maintenance.
• The system administer training for IHAU, DIE, National TB Reference Laboratory – Welisara, NSACP, NPTCCD, AMC and AFC, shall include technical descriptions and operating procedure discussions covering of IHAS architecture and operations, network operations, organizational level security management and business continuity operations. In addition to this, system administrator assigned for the IOM shall be trained on managing the call centre software and IVR, IPG management, biometric scanners and imaging device manipulation, database administration, HSCS administration, system monitoring, overall security management, backup and archival operations and system recovery.
• Master trainers and trainer training programme – discuss with IOM. May not be effective for health sector staff due to their turnover.
Training Strategy
To ensure that training objectives are achieved, IOM shall work closely with Bidder to prepare materials for a comprehensive class room and hands on training for the relevant staff categories in stakeholder organizations. Therefore, the following schedule of training is recommended as the minimum standard:
Type of training duration Target participants
54
Biometric system management: Overview of the biometric capturing and identity verification. Both, ICT and procedural aspects shall be trained.
1 - 2 hour Floor Managers, Nurses, DPPs, Radiographers
System administration:
2 to 3 days Designated system administrator - IOM
System operation: Detailed operation of the IHAS with sufficient hands on training
It is highly recommended that the staff responsible for different tasks will be trained in the same group to provide a better understanding of the integrated operational procedure.
1 day All Users
Supervisory training:
A comprehensive overview of the IHAS, activity analysis, security management, report generation, spot checking, discretion and decision making, etc.
2 days Systems Administrator – IOM, Chief of DPP, representative each from DIE and IHAU.
Training Plan
• The selected Bidder shall develop a detailed training plan identifying the task and milestone schedule for coordinating training requirements coordination, training courseware development, and training delivery.
• The Bidder shall coordinate with IOM to identify the training requirements for each group of target users, supervisors and managers, including:
o Number of users, supervisors and administrators/managers requiring training, and the maximum number that can be trained in each training class;
o Specific training to be provided in each of the general types of training classes and the estimated duration of each class.
o Training location(s) for each type of training for each operations unit and training facilities that can be provided.
55
o Any per-diem for the trainees (shall be provided by IOM)
Training Delivery
• System administrative and operations management must be carried for a selected group of personnel using hands-on training sessions.
• All manuals and training materials must be made available for the trainees at least a week before the commencement of the training session
• Training must not be carries on the production system. A separate test/training instance of the system must be created and made available for this purpose
• The training must cover all aspects of systems management and operations • For end-user training the training must be carried out as hands-on training sessions. • Adequate copies of all training material must be made available for the trainees at least 2
weeks before the commencement of the training sessions (shall be provided by IOM) • All training activities must be completed at least 2 week prior to the live run of the system • Trainers must collect a trainee feedback at the end of each training session. A summary of
the feedback must be made available to the IOM at least 1 week prior to the live run of the system.
Training Management
• The selected Bidder shall be responsible for all aspects of preparing and delivering system aspect training for users, supervisors and administrators at all of the equipment installation sites.
• A Training Manager shall be assigned to lead the planning, preparation, coordination, and delivery of training for the system and its distributed workstation and application components.
• The Training Manager shall work closely with IOM to ensure the policies and procedures of the Ministry of Health and DIE are correctly represented in each training session.
• During the planning, preparation for, and delivery of training, the Training Manager shall participate in weekly and monthly program reviews, shall report status, and coordinate the resolution of problems and issues.
Training Material
• Comprehensive training courseware and associated training materials relating to the system shall be developed and submitted for review and approval. Any required modification or updates shall be incorporated, and final courseware and materials shall be delivered two (02) weeks prior to commencement of training.
• All lesson plans, courseware and training materials shall be delivered in an electronic form (MS Word and PDF formats) that can be reproduced and used by IOM in on-going training and shall become the property of the IOM. This material shall be appropriate for use in future classroom-based training for new employees.
56
• Under the system maintenance agreement, the selected Bidder shall provide updates and modifications to the courseware and training materials as required to keep the training materials up to date as system upgrades and changes are implemented throughout the life of the system.
Scheduling and Conducting Training
• On-site training shall be provided for the operations of the IHA Unit to be established by IOM. • The selected Bidder shall develop a training delivery schedule in close coordination with IOM.
Each type of training shall be scheduled in coordination with IOM, and the final coordinated schedule shall be incorporated in the final Training Plan.
• The IOM or designate shall participate as a co-trainer in all training classes conducted to the representatives of the stakeholder organizations on IHAS operations.
9 Detailed Technical Requirements
TR.1 General and non-functional requirements
TR.1.1 Software Licenses: All software components should be loyalty free and licensed to the IOM, and thereafter to the Ministry of Health on a perpetual basis and should be valid for use in all implementation sites. All custom build and standard software license should not be restricted on a user or workstation basis. Following shall be specially considered:
• Database engines – Open source database engines shall be recommended. There shall not be any annual licence fee to the IOM, and thereafter to the Ministry of Health, on acquiring/maintaining database licenses.
• Software Libraries – Preferably custom developed or open source. There should not be annual licence fee to the IOM, and thereafter to the Ministry of Health, on acquiring database licenses
• Use of Open Source – Use of Open Source frameworks, libraries etc shall be explicitly mentioned and the Open Source license shall be Permissive.
TR.1.2 Intellectual policy rights, warranty and maintenance: The Following policy for Intellectual Property Rights ownership would determine Purchaser’s and Supplier’s rights and obligations (i.e. except standard software).
The IOM shall have the sole Intellectual Property Rights ownership to the custom software or elements thereof, including customizations specific to the IOM. The Supplier shall, not later than expiry of the Warranty Period, deliver to the IOM an inventory of the said custom software together with all related documentation,
57
including but not limited to source code, data dictionaries, all relevant diagrams (i.e. ER diagram, class diagram, sequence diagram deployment diagram etc), with all the rights to use the source code by the IOM at the end of the warranty, maintenance period.
During the warranty period, both the Supplier and IOM may agree to maintain a copy of the source code under the custody of a third party under an Escrow Agreement. (-- discuss with IOM)
The IOM, shall have the right to replicate the Custom Software in all sites required during the contract period and thereafter. IOM shall also have rights to further develop this category of software, at the end of warranty, maintenance period.
The Supplier shall provide new versions and new releases of the custom software or elements thereof at the IOM discretion, free of charge, during the warranty period. In the event the IOM exercises the option to obtain the said new versions or new releases, the Supplier’s obligation in respect of the Warranty for the said versions or releases shall be limited to the remaining period of the warranty applicable to custom software.
TR.1.3 Complete set of documents describing all interfaces to external systems must be provided to the IOM prior to the User Acceptance Testing. Any updates, modifications that affects such interfaces must also be provided prior to the deployment on such update / modifications.
TR.1.4 Confidentially of Information: Supplier is required enter into a separate Non-disclosure Agreement regarding the use and disclose of information which the Supplier may gather during the performance of this contract.
TR.1.5 Technical management and troubleshooting: The solution must include appropriate tools for administering, monitoring and troubleshooting various software, hardware and communication systems provided by the bidder. A complete description of such tools and utilities must be included in the bidding document.
TR.1.6 User Training: Bidder must provide User Training for the users of IOM, Ministry of Health and DIE on following areas at a minimum, before the commencement of operations. Bidder may propose any other User Training modules in addition to what is stated below.
• Application specific training • System operation training • User administration and management training • System maintenance training
Technical Training: Bidder MUST provide Technical Training for the IT staff of IOM and IHAU on following areas at a minimum, before the commencement of operations.
58
Bidder may propose any other Technical Training modules in addition to what is stated below.
• Operating System Administration • IHAS and HSCS database administration and housekeeping • Application Administration • Backup and Restore Administration • Call centre management
Bidder must provide a comprehensive Training Plan in the bidding document which identifies, at a minimum, the following. Bidder may include any other areas in addition to what is stated below:
• Training Methodology • Training concepts such as ‘train the trainer’ • How the Bidder intends to evaluate the success of the training
TR.1.7 Maintenance and Support Services:
The Bidder must sign a service level agreement with the IOM related to the provision of warranty and maintenance service. A draft of Bidders proposal for such an agreement must be included in the bidding document, based on a draft agreement template proposed by the purchaser.
Bidders shall prepare detailed proposals on System Maintenance and Support Services. These proposals should reflect best industry practice. During the first three years starting from the date of acceptance of the System, Supplier must provide System Maintenance and Support Services without any cost to the Purchaser.
Maintenance and Support Services Proposal: The Bidder must submit a detailed proposal on System Maintenance and Support Services as an integral part of the Bidding Document, adhering to the best industry practices as an integral part of the Bid.
Maintenance and Support Services Period: The Bidder must provide for System Maintenance and Support Services for a period of three years starting from the date of acceptance of the System as an integral part of the Bid.
TR.1.8 End User documents: Complete and up to date End- User documents must be provided in following formats / mediums:
• Ten printed and bounded copies (-- IOM: to each programme and 3 to IOM) • One (1) copy in ‘.pdf’ format on CD / DVD • One (1) copy as an editable document (in ‘.DOCX’) on CD / DVD
End User documents must be in English. The documents must be concise, unambiguous, clear, explicit, and use simple, yet professional language.
End User documents must adequately describe all the functionalities operations of the application and illustrate those through pictorial, graphical, screenshots presentation where required.
59
End User documents must have comprehensive indexes to facilitate quick reference.
Final versions of the End User documents must be available to the users two (02) weeks prior to the commencement of User training of the system.
Any subsequent changes in the system must be reflected in the End User documents. End User documents must be delivered as new version releases when incorporating subsequent system changes to the documents. Bidder must provide new version releases as an editable document on CD / DVD.
TR.1.9 Technical Documents: Complete and up to date technical documents must be provided in following formats / mediums:
• Three (02) printed and bound copies • One (1) copy in ‘.pdf’ format on cd / dvd • One (1) copy as an editable document (in ‘.DOCX’ format) on CD/ DVD
Technical documents must be in English. The documents must be concise, unambiguous, clear, explicit, and use simple yet professional language.
Technical documents must adequately describe relevant details through pictorial, graphical, screenshots presentation where applicable.
Technical documents must have comprehensive indexes to facilitate quick reference.
Final versions of the technical documents must be available to the users prior to the commencement of technical training of the system.
Any subsequent technical changes in the system must be reflected in the technical documents. Technical documents must be delivered as new version releases when incorporating subsequent system changes to the documents.
TR.1.10 Training Documents: Complete and up to date training documents must be provided in following formats / mediums:
• One copy per each trainee paper-based copies (number of trainees TBD) • One (1) copy in ‘PDF’ format on CD / DVD • One (1) copy as an editable document (in ‘.DOCX’ format) on CD / DVD
Training documents must be in English. The documents must be concise, unambiguous, clear, explicit, and use simple yet professional language.
Training documents must adequately describe relevant details through pictorial, graphical, screenshots presentation where applicable.
Training documents must have comprehensive indexes to facilitate quick reference.
Final versions of the training documents must be available to the users one (01) week prior to the commencement of general training of the users.
Any subsequent significant changes in the system must be reflected in the training documents. Training documents must be delivered as new version releases when incorporating such system changes to the documents.
60
TR.1.11 System Design Documentation (Technical documents): The Technical Specification of the Bid must include Entity Relationship Diagram, Class Diagrams, Data Base Structures, Sequence Diagrams (where necessary) and Activity Diagrams, Logical Specifications at a minimum of any customized or tailor-made Software. Technical Specification must maintain correct versioning mechanism for the original document and subsequent changes the System including the following.
• System Interface details • System Administration details • Network details, detailed diagrams, configuration and management details • System configuration details • Backup, recovery and system contingency plan details • Comprehensive Disaster Recovery Plan (DRP) details which must include
personnel, assigned tasks, procedures, recovery, and management thereof • Business continuity plan • User testing and acceptance plan • Detailed ICT asset register • Interfaces to external systems
TR.1.12 General warranty requirements: Unless stated specifically in this document, different type of components in the system must be covered with a comprehensive warranty against design, manufacture, workmanship or material defects per periods as specified below.
• All standard software components: at least 1 year or as per the End User License Agreements of the respective software vendor (which ever longer)
• Custom built software components: at least 3 years
All warranties shall start from the date of signing user acceptance by the purchaser on respective components.
TR.2 Overall System Architecture and Design
TR.2.1 Architectural Principles: The proposed system must comply with the following architectural principles
a. Conceptual integrity • System should have a clear & concise vision • Architecture should maintain enterprise consistency
b. Componentization (component division) • Roles and responsibilities of each component should be clear • Components should map onto discrete business or technical functions of the
application c. Use of standard technology or middleware components d. Platform agnostic architectural design
Architecture should not depend on specific alternatives or options presented by the underlying operating platform
e. Architecture Representation For the architecture to be effective, it should be effectively communicated to different stakeholders. In addition to discussing the architectural styles and
61
patterns within the proposed system, the architecture representation should ideally present several views such as, the 4+1 view model (logical view, process view, development view, physical view and scenarios) or Applied architecture viewpoints (conceptual view, module view, execution view and code view)
TR.2.2 Architectural Qualities: The proposed system must be built based on and demonstrate the following architectural qualities
a. Flexibility / Extensibility • System should have the flexibility to respond and adapt to unanticipated
requirements • System should fit new requirements into the architecture easily • System should not have many dependencies between system modules (a
change in one module should not require major changes in other modules) • Bidder should state how changes in message formats are handled • System should not have any design compromises to enhance performance. • Software should use meta-data to configure itself (using declarations rather
than coding)
b. Ability to integrate System should have the ability to integrate with other systems. System should be designed using open integration standards and the APIs should be designed in such a way that other systems can use the component services.
This shall be paid attention special integrating the IHAS with the existing (or proposed) case-based medical record systems in NSACP, NPTCCD, AMC and AFC. The Bidder shall take the necessary steps to use web services or API if the said systems provided system integration strategies. If not, a configurable integration design shall be discussed with the stakeholders and approved by IOM case-by-case basis.
c. Testability • Bidder should define a sufficiently comprehensive Quality Assurance plan
(including test cases for important components) • Bidder should state any tools, processes and techniques formulated to test
language classes, components and services • Bidder should state whether any automated testing tools can be used to test
the system • Bidder should state whether system or critical components of the system can
run in a debugger • Bidder should state whether there are hooks in the framework to perform
unit tests
d. Availability / Reliability • Bidder should state how hardware and software failures are identified • Bidder should state the backup procedures, how long it takes to back up the
system and how long it takes to restore the system from a backup • Bidder should state whether the integrity of the data can be compromised in
a failure scenario TR.2.3 n-tiered architecture: Application should be based on a loosely coupled n-tiered
62
architecture (n>=3) that separate the front-end, business logic, communication and database aspects in to different coupled layers.
TR.2.4 Standard web-based architecture: All clients interfaces should be web-based and compatible with industry standard web browsers. However, the Bidder shall try to maintain the browser independent design as much as possible.
TR.2.5 Redundancy and fault tolerance: All centralized applications should be fully redundant and fault tolerant with automatic fail-over. There should not be any single point of failure in the entire application architecture. The system must support 99.9% availability on all critical components.
TR.2.6 Performance: Unless otherwise mentioned specifically, following minimum performance standards should be maintained with respect to general workflow functions, user interface functions of the system.
(Note: The bidder must provide quantitative scenarios for the following, based on the proposed solutions. The performance level below excludes any latency in wide area network connections)
TR.2.7 Use of open standards: All information technologies used in the application (except for standard software such as operating systems, database systems etc.) should be based on ‘Open Standards’ that are supported by more than a single vendor.
• For X Ray related communications PACS standard should be used • For all integrations with medical record systems, HL7 is the recommended
messaging/XML standard
TR.2.8 Compliance with National eHealth Standards and Guidelines: Overall system architecture must be compatible with the National eHealth Standards and Guidelines (http://www.health.gov.lk/enWeb/publication/NeGS_v_1.pdf)
TR.3 Project planning and execution
TR.3.1 Preliminary Project Plan: The Bidder must prepare a Preliminary Project Plan describing, among other things, the methods and human and material resources that the Bidder proposes to employ in the design, management, coordination, and execution of all its responsibilities, if awarded the Contract, as well as the estimated duration and completion date for each major activity. The Preliminary Project Plan should also state the Bidder’s assessment of the major responsibilities of the Purchaser and any other involved third parties in System supply and installation, as well as the Bidder’s proposed means for coordinating activities by each of the involved parties to avoid delays or interference.
TR.3.2 Organization and Staffing
Bidder must state the structure of the bidder’s project team that is proposed for the project.
Bidder must provide the qualifications and experience of the key personal proposed for the project team to demonstrate the competence of the bidder’s project team to undertake this project. Bidder should highlight any specific experience of these
63
personnel in the health domain, especially with regards to the stakeholder organizations, system integration and ICT training delivered to the employees of the State health sector.
Bidder must provide details of exact involvement of the key personnel proposed in the project team with details of the duration and the stages in which these personnel will be involved in the project.
Bidder must obtain prior written approval from the purchaser if bidder replaces the proposed key personnel with new personnel during the life cycle of the project. New personnel must have same or more qualifications and experience as those who were being replaced.
TR.3.3 Pre-commissioning Tests: In addition to the Supplier’s standard check-out and set-up tests, the Bidder (with the assistance of the IOM) must perform the following on the System and its Subsystems before Installation.
Prior to commencement of Pre-commissioning Tests, bidder must provide a comprehensive Test Plan addressing, at a minimum, the following areas. Bidder may include any other areas in addition to what is stated below.
• Composition of the testing team • Scope of testing • Schedule • Test Deliverables • Release criteria • Risks and Contingencies
Pre-commissioning Tests MUST ensure the correctness, completeness, security and the quality of the solution provided by the Bidder. Pre-commissioning tests, at a minimum, must include the following test levels and such testing MUST be conducted on the System and all its Subsystems.
• Unit testing • Integration testing • Interface testing • Volume testing • Stress/Load testing • Performance testing • DR site failover testing
Bidder must provide the IOM the Test Cases used for above testing and have them approved by the Purchaser prior to conducting the above mentioned tests.
TR.3.4 Operational Acceptance Tests: The IOM (with the assistance of the Bidder) will perform the following tests on the System and its Subsystems following Installation to determine whether the System and the Subsystems meet all the requirements mandated for Operational Acceptance.
64
a. Functional testing: Validate those mandatory functional requirements and the given desired functional requirements of the System supplied, work properly. It is necessary to certify that the System supplied conforms to the specification.
b. Integration testing: Validate that combined parts or modules of the System are working properly.
c. Performance testing: Validate that the System is in compliance with the functional and performance requirements
d. Disaster failover testing: Validate and verify that a smooth transition, without any disruption to service or loss of information occur during the failure of the main site/servers.
TR.4 System, Information Security and audits
TR.4.1 Information System Security: The proposed system should be protected from unauthorized access, use, disclose, destruction, modification or disruption. The proposed Information Security Model could be integrated with the work flow model of the Proposed System where it will work as an intelligent security management system.
The proposed solution must include the following features:
• Automatically log-off a current operator when a new operator logs on, to ensure that only a single operator can be the operator of a record at any given time.
• An automatic log-off capability that will prevent accessing the central system after a pre-determined time interval during which the browser/workstation is inactive. The system shall include provisions to ensure that no in-process data or work is lost if a a user is automatically logged-off.
• Re-entry of the login information (user ID + password) shall be required to regain access to the workstation
• The system must provide following system security reports:
o Periodic summaries of authorized users, including individual permissions, user status (active or suspended) and date of last log-in.
o Periodic password policy compliance audits.
o Periodic security assessment audits, including unsuccessful log-in analysis
TR.4.2 The system must maintain appropriate logs and audit trails for each and every transaction carried at different levels. Appropriate tools must be provided to manage examine and manage such audit trails by authorized users. The system must contain at least one level of audit trails that cannot be deleted or edit by a user, including those having administrative access to the system.
o Log of all activities those involved deletion and modification of medical data and biometrics shall be highlighted by the system automatically and brought to the notice of Chief of DPP in addition to the System Administrator.
TR.4.3 The system shall provide comprehensive tools and capabilities for administration of user authorizations and system security.
65
TR.4.4 The system shall enable an authorized system administrator to add and remove users, to assign, modify and suspend access privileges for any user or group of users (e.g., latent examiners), and to reset passwords.
TR.4.5 The system must implement a role-based access control policy and a mechanism. All system workstations shall restrict each user’s access. The central IHAS shall use role-based authentication to limit the access to medical data and biographics.
Access to each principal IHAS function and capability to perform database inquiries and updates shall be limited to authorized users and system administrators.
The system shall support the assignment of specific access privileges for each user and shall enable the limitation of access to only those functions required by the user to perform his/her assigned tasks.
Access to system functions shall be controlled by individual operator log-on identification. Login access shall be controlled with a unique user login name and password. In production operations, generic user IDs and/or passwords for any component shall not be permitted.
TR.4.6 The system shall support strong password authentication and enforce associated password policies:
The system shall enforce the password policy stipulated in National eHealth Guidelines and Standards.
The system shall enforce periodic password changes for all users and prohibiting re-use of passwords for 10 cycles
TR.4.7 All external system interconnections and service transactions must be carried through a secure and authenticated service interface APIs. The system must maintain audit trails and access / transaction logs with respect to all transactions carried through such interfaces. Appropriate tools must be provided for auditing, monitoring such transactions and the management of such credentials.
TR.4.7 The system shall enforce a maximum number unsuccessful logon attempts, such that when this limit is reached, the logon ID shall be automatically disabled and require intervention of an authorized supervisor or administrator to re-enable the user’s access rights. The system shall enable an authorized system administrator to establish and update the “maximum unsuccessful logon attempts” parameter.
TR.5 Compliance with national and international standards
TR.5.1
Hardware Standards
Storage and transmission of PACS
Biometrics
Images
TR.5.2 Language Support: IVR, HSCS and information portal shall displayed in multiple languages.
66
TR.5.3 DATES: All information technologies MUST properly display, calculate, and transmit date data, including, but not restricted to 21st-Century date data. System MUST be compliant with ISO 8601 Standard with regards to date / time.
TR.6 Management Information Reports
TR.6.1 The proposed system shall provide the capability to generate statistical analysis and system activity reports, including standard pre-defined management reports and special reports based on user-defined ad-hoc queries.
TR.6.2 The initial delivery of the system shall include a comprehensive set of standard cataloged management reports (up to 50 reports) that will be produced by the system on a regular recurring basis. Full reporting capabilities shall be provided with the initial operational capability delivery of the system. The selected Bidder shall work closely with the purchaser to define all details of the standard management reports (report types, content, frequency, routing, etc.) to be implemented in and delivered with the initial system configuration.
TR.6.3 All standard reports shall be template based and the user should be capable of changing/ editing the respective templates. Necessary tools and training must be provided to the end-users for such editing of report templates.
TR.6.4 A capability shall be provided that enables a system administrator to establish regular reporting schedules for each type of report, and that produces the reports according to the pre-defined schedules
TR.6.5 The system shall enable an administrator to selectively generate any standard report on-demand under operator control and this shall not affect the established automatic production schedule for the report
TR.6.6 The system must provide the capability to access transaction logs and to develop standard pre-defined reports for reporting:
a) System transaction activity during a specified time period, including:
1) Transaction counts by transaction type, originator, time-of-day and day-of-week, rejected transactions, etc.
2) System operations, including downtime and error incident counts and statistics.
3) Transaction, logon and security audits. TR.7 General Technical Requirements for the proposed software system
TR.7.1 The proposed system capabilities, and all associated system software, applications software, database management software, operating system software, and special-purpose middleware components shall have capacity and performance specifications equivalent to or greater than those included in this Requirement.
67
All the components supply under this project must comply with the following requirements.
• No discontinued or obsolete products (e.g. software frameworks or deprecated methods/libraries) shall be utilized in the proposed system
• The proposed software configuration shall be updated at no additional cost at the time of system delivery to replace any discontinued or superseded component(s) listed in the proposal with equivalent or better current-production model(s) and Bidder-qualified software.
• The system to be implemented shall be compliant with security requirements stipulated by SL CERT and policy recommendations stipulated by the Ministry of Health and DIE.
TR.7.2 The system must be provided with a web-based dashboard interface that would allow real-time monitoring of all system statistics, system health, performance indicators and time-aging statistic
TR.7.3 The systems must provide continuous operation during the regular operating hours of the Ministry of Health. Any planned maintenance must be carried outside these operating hours
TR.7.4 System availability on all components measured on a monthly basis shall be equal to or greater than 99.9%
TR.7.5 Scheduled downtime for any component or primary/mirror segment of the system, including preventive maintenance and system backups shall not exceed five (5) hours per calendar month. Such scheduled maintenance must be arranged giving not less than 7 days of notice to the IOM and Ministry of Health.
TR.7.6 The system design shall minimize the extent and scope of primary/mirror segment downtime for system software updates, and configuration modifications to add system components. Bidder must describe the specific configuration control provisions and procedures for installation, testing, and acceptance of system software updates and configuration modifications prior to their incorporation into the production system, and for rollback of unsuccessful updates.
TR.7.7 The system shall permit complete shutdown of the central software system and restart to full functionality within a 60 minute period of time
TR.7.8 Shut-down and restart of components or of the entire system shall be able to be accomplished without loss of data or the requirement to re-create any transaction. Also, The system shall provide the capability to maintain seamless continuity of operations in the event of a scheduled outage, component failure or disruption of infrastructure services.
TR.7.9 The continuity of service capability shall provide real-time monitoring of the core system segments, with the capability for automated detection of a loss of service condition (e.g. failure of IVR or IPG).
68
TR.7.10 The proposed system should enable the system administrator to interactively initiate a switchover to periodic testing and training while maintaining continuity of services during service hours of the system.
TR.8 Overall Bidding requirements
TR.8.1 The Bidder must comply with overall requirements of the Bid related to functional, non-functional, process, operational and management of the proposed system specified in this document
TR.8.2 Bidder in his bid must specify detailed description of how the technical requirements and general overall requirements are met in his proposed solution
TR.8.3 The Bidder must provide a detailed Bill of Material in the bidding document corresponding to his solution proposed
TR.8.4 The Bidder must use all existing resources and infrastructure facilities available at present in the DIE for his solution. A clear justification must be given on all instances where the use of such facilities are not possible.
Name of Bidder : ______________________
Signature: ____________________________
Date:_________
69
Appendices I. Investigations Chest X Ray (CXR) A posterior-anterior (PA) chest X-ray is the standard view used. In active Tb, abnormalities on chest radiographs may be suggestive of, but are never diagnostic of, TB. However, chest radiographs may be used to rule out the possibility of pulmonary TB in a person who has a positive reaction to the tuberculin skin test and no symptoms of disease.
The results if CXR is available immediately to DPPs and the consultant radiologists.
Sputum Culture and AFB If the CXR is suggestive, the applicant is advised to come to IHAU (preferably) next day if he/she present during Monday and Tuesday. If the applicant faced HAP during Wednesday to Friday, three consecutive day EM sputum sampling should start on Monday to Wednesday. The Early Morning Sputum sampling, has to be done within seven (07) days of the CXR. Thee Early Morning Sputum samples shall be produced for three (03) consecutive days. Figure nnn indicates the latest days for the consecutive sputum sampling () according the date of CXR performed () in the HAP.
This week Next week
Mo Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri
Table: Latest date for the sputum test based on the applicant’s presentation
70
Even if the CXR is negative, if the history is suggestive of Tb (cough more than 2 weeks, weight loss, haemoptysis) sputum will be sent for Culture and AFB (Acid Fast Bacillus). To rule out Tb, results of following test shall be required.
GenEx (immediate)
Within 3 hours
AFB
within 24 hours
Culture for Drug Sensitivity
6 weeks
Culture -
8 weeks
-ve -ve +ve
-ve -ve -ve +ve
The Tb reference laboratory, Welisara needs 10 weeks (2 days refrigerate before sending for batch processing) for Culture and AFB. So, to possibility of 10 weeks waiting time to confirm ‘free of Tb’). If Tb, system should follow up (or trace the case) for 10 weeks. We can’t confirm cat A till 10 weeks (until 8-week culture results come).
71
II Domain Analysis Overall HAP process is shown by the figure below. This summarizes the process initiated by the self-referral of the applicant, the HAP screening by the IOM, the role of IHU and resident visa decision at the DIE.
High-level activity diagram
Figure : High level relationship of the key stakeholders involved in the HAP
72
Selected processes in detail The Figure below will summarize the steps in which applicant is seeking information and scheduling an appointment with IOM. During this process the HAP is explained by the Call Centre operative. If the applicant requests for an appointment, the Call Centre operative will check the available dates and schedule an appointment. Upon booking, the date and time will be confirmed to the applicant.
Figure 2: Current process of scheduling an appointment
The applicant needs to report to the IOM between 8am to 1.30pm to register for the HAP with a prior appointment. Upon arrival, the appointment is checked, and identity of the applicant is verified with the passport. After identity of the applicant was verified, instructions will be given to proceed with the payments. Under the current process, IOM has an on-site banking facility to deposit the fee specified for the health screening. Bank will issue a receipt upon depositing the fee for HAP.
When payment is completed, the Receptionist/Floor Manager will guide the applicant to registration. Registration desk Is open from 8am to 2pm. Prior to the registration, Floor Manager can prioritize the applicants for the registration.
Registration is managed by the call centre where applicants social-demographics are entered to the system after verifying the identity. Followed by capturing of the biometrics and a digital photograph of the applicant will take place. This process will take approximately 15 minutes and summarized in the figure. Upon successfully completing the registration, applicant is ready to initiate the health screening.
73
Figure: Registration process
When the registration is completed, the applicant is offered a counselling session by a nursing officer to prepare the applicant for the screening process. This includes a HIV pre-test counselling
74
IOM verifies applicant’s identify against the Passport produced and directs the applicant to the waiting area for the payments (on-site) unless payment hasn’t been done already. Upon payment of the service fee, the appointment is confirmed and proceed to the rest of the HAP. During the registration, a bar code is created for the future reference during the process. Prior to the examination and investigations begin, the applicant is offered a briefing and a HIV pre-test counselling by an IOM nurse. Followed by, the applicant will be examined by the medical officer (MO) and directed to the sample collection process.
Figure: Counselling and examination
The briefing will take place between 8.30 am to 10.30 am. There is a batch briefing for a group of 10 – 15 applicants on general matters relating to HAP. The nursing officers will be allocated in rotation to conduct the counselling, floor management and chaperoning. The individual briefing and HIV pre-test counselling, followed by signing the consent form.
When the written consent is obtained, the applicant is referred to the Medical Officer. The medical officers will obtain the history of the applicant and perform the medical examination. When the applicant’s medical record was updated, the he/she will be directed to the radiology and blood investigations. If required, the medical officer will conduct another counselling session with the applicant.
Followed by the examination and counselling session by the medical officer, the applicant is directed to the phlebotomy and radiology waiting section. At this point, the applicant may first take either radiology or phlebotomy. Figure 5 shows a case of the applicant first opting in for blood tests.
75
Figure 5: Phlebotomy process
The blood samples are collected by a Medical Laboratory Technician (MLT) after verifying the applicant’s identity. Upon collection, the blood samples will be sent to IOM laboratory (on-site) for recording and investigating. The samples for Malaria, HIV and Filariasis will be investigated in the IOM laboratory using rapid test kits.
If Malaria rapid diagnostic test was positive, the smear will be sent to Anti Malaria Campaign (AMC) for further investigation and confirmation. In case of a positive rapid test for Malaria and Filariasis, the applicant will be referred to AMC or AFC respectively. If HIV ELISA test is positive, the applicant will be referred to the National STD and AIDS Control Programme (NSACP) for further management.
During the phlebotomy process, MLT issues an encoded sticker after verifying the identity of the applicant. This sticker is used in all sample identification and reading the rapid test results
76
and entering the same to the system.
The blood drawn used for HIV ELISA, and Malaria and Filariasis rapid tests.
If the Malaria rapid test is positive, thick and thin slides are also created. Malaria slides will be transferred daily to the AMC.
Applicants with positive screening test for HIV, Malaria and filariasis will be referred to the national programmes (respectively, NSACP, AMC, AFC).
When the phlebotomy is completed, the applicant can proceed to the radiology section (figure nnnn). The CXR will be taken by the radiographer and uploaded to the RIS. The PACS images will be examined by the radiologist for any lesions suggestive of Tb. The images of a particular applicant is available for the MOs to view alongside of the applicants medical record.
Applicant will be directed to the internal radiology section for the chest X ray. Applicant’s identity is verified by the radiographer. The Chest X Ray is digitally stored in the internal Picture Archive and Communication System (PACS)/Radiology Imaging System (RIS). The image is referred to the Consultant Radiologist for reporting. In case of a Tb suggestive change in CXR or suspicion (raised either by the medical officer or consultant radiologist, or by both), it will be noted, and applicant will be directed for the Early Morning Sputum investigation. A sputum investigation can be ordered merely by the suspicion of TB (e.g. symptoms such as cough more than 2 weeks, weight loss, haemoptysis, etc).
In the CXR Waiting area the applicants will be waiting until the CXR is read and reported by the radiologist. In case of an ambiguity or confirmed Tb suggestive lesions (noted either by the Radiologist or an MO) the applicant is asked to come for an Early Morning Sputum Test by giving an appointment.
77
Figure: Radiological investigation
If the history is suggestive of TB or CXR indicates TB changes, applicant is asked to report for an Early Morning Sputum test. The applicant should report to IOM by 7.30am on three (03) consecutive days starting from the date given by the IOM. The recommendation is to report to the EM sputum test immediately next working day. Sputum sample is collected under the supervision of a MLT of the IOM at the designated Sputum Collection Area. The sample collection is verified for the identity of the applicant and the accuracy of the sample (whether the sample is produced by the registered applicant and quality of the sample). The Tb specimen is sent to National Tuberculosis Reference Laboratory, Welisara in a secure and confidential manner. The specimen is dispatched by a IOM staff under sealed container with encoded label. Acid Fast Bacilli (AFB) and culture will be done at the National Tuberculosis Reference Laboratory, and the results will be confidentially communicated to the IOM (sealed envelope, once a day, encoded identification). When the result reaches the IOM, the
78
applicant’s medical record will be updated. The applicant is referred to the NPTCCD for further management.
If any other abnormality of the CXR noted (e.g. Malignant change in the lung, Scoliosis) the applicant shall be referred to a suitable medical practitioner (e.g. Chest Physician). System needs to record these decisions.