Design, Develop, Test, Implement and Maintenance of Common Registries for the Ministry of Health and Mass Media, Sri Lanka

New amendment added #3: Amendment 03:The RFP shall be amended to reflect the following:Upload Addendum to RFP_Section_II_Schedule of Requirements RFP_2026_60951 and Evaluation Criteria & Scoring Document RFP_2026_60951_R2Extend the Deadline for bid submissionRevision of the date of the Deadline for bid submission as follows:Deadline for bid submission under General section:2026-03-18, 11.30 UTC (5:00 PM Sri Lanka time)

New clarification added: Clarification 14:We kindly request clarification regarding Clause 1.3 of the Evaluation Criteria, which states:"Should be legally registered and operate in Sri Lanka or authorized to operate within its jurisdiction for software development related activities. Proof of registration is required."Specifically, we would appreciate further clarification on the phrase “authorized to operate within its jurisdiction.”Could you please confirm whether this refers to:1. Companies that are legally registered in another country but are authorized to conduct software development related activities within their own country, or2. Companies that are registered outside Sri Lanka but have obtained authorization or registration to operate in Sri Lanka, or3. Any other form of legal authorization recognized by UNOPS for participation in this tender.Response: Any bidder who participate in this tender as the lead party should have the authorization authorized to operate within Sri Lanka for software development related activities.Additionally, with regard to the statement “Proof of registration is required,” could you kindly clarify what specific documents would be acceptable as proof of registration (for example, Certificate of Incorporation, Business Registration Certificate, or any other relevant legal documentation)?Response: Certificate of Incorporation, Business Registration Certificate, or any other relevant legal documentation to prove the registration is acceptable.Furthermore, we would appreciate clarification regarding the evaluation aspects related to "4 . Type of activities undertaken overall experience, 5. demonstrae general organizational capability.” Response: Offeror's are expected to provide details of their past experiences, types of activities the organization has undertaken that is relevent to this scope of work, management structure, financial stability and project financing capacity, project management controls, extent to which any work would be subcontracted (if so)

New clarification added: Clarification 13:Q 01:We have already submitted a bid for the tender RFP/2025/60611 – Provision of Specialised Support Services for the Ministry of Health, Sri Lanka for the implementation of the “Thin-slice” of the National Digital Health Blueprint.” As the evaluation process for that tender is still ongoing and the award decision has not yet been communicated, we would like to know whether we are eligible to submit a bid for this tender as well.Kindly note that, if permitted, we will allocate a different team of personnel for this project.Response: As the evaluation of the Specialised Support Services tender is still ongoing, we highly encourage you to to submit a proposal for this tender.Q 02:We would also like to inquire whether it would be possible to grant an extension to the submission deadline for this tender.Response: We will not be able to provide an extension to bid submission deadline at this stage.

New clarification added: Clarification 12:Could you please clarify that is it required to provide experience only in region/country and region/country means Sri Lanka?Response: We have asked for experience in two stages. Under the qualification criteria, you need to meet the minimum requirement.Under the technical criteria, experience in Sri Lanka and the region will be scored.

New clarification added: Clarification 11:We kindly request clarification regarding the following clauses mentioned in the tender document, which are indicated as “Combine [Full JV]”.1.4 – Offeror accepts Bid validity of 120 days from the tender closing date.1.2 – Completeness of the Proposal: All required Questionnaires (if any), and Returnable Bidding Forms and other documentation requested under the Document Checklist section have been provided and are complete.As the submission is intended to be made under a Full Joint Venture (JV) arrangement, we would appreciate your clarification on whether these requirements should be fulfilled and declared jointly by the full JV, or if they should be submitted individually by each JV partner.Response:Yes, these two criteria need to be fullfilled by all the partners jointly as the full JV.

New clarification added: Clarification 10: We request for your kind clarification regarding the following Questions:1. We have some documents to show our technical specifications, project management approach, infrastructure, etc. which we believe are crucial to demonstrate our ability to meet the tender requirements, where do we upload these documents? We checked the vendor submission form but couldn't find relavent place to upload.Response: You may upload under Document checklist. For further details refer https://esourcing.unops.org/#/Help/Guides  2. As for questions in returnable form D (Technical proposal form), can we answer the questions in a separate document that we attach to provide a more comprehensive and organized response? Where can we add the attachment? Response: Yes, you may. But you must fill Form D and provide clear reference to where to refer for each question3. In the event of a consortium, do all members sign the returnable forms or only the leading tenderer? Response: For Joint Venture, consortium, or association, the bid submission documents must be submitted in the name of the leading partner. If the forms are signed by a non-lead partner the proposal should accompany a Power of Attorney (POA) authoring the non lead partner to sign the submission document on lead partner's behalf.For Joint Venture, consortium, or association, at least the leading entity must be registered in UNGM, and preferably all members. The submission must be made by the leading partner through their UNGM account. 4. Regarding returnable form D, 1.3, is the answer only provided by leading tenderer or can a member of the consortium add their experience in their region?Response: This criteria can me met by all members together

New clarification added: Clarification 9 [cont.]:5. Stakeholder Landscape and GovernanceTo better understand the operational ecosystem for the registries, could the client clarify:The key government entities and departments that will act as stakeholders in the project (e.g., Ministry divisions responsible for health information systems, digital health programs, etc.).Whether professional councils or licensing bodies will act as data authorities for the Provider Registry.Whether regional or provincial health authorities will have administrative roles within the system.Whether there are additional external stakeholders expected to integrate with the platform, such as:National laboratoriesHealth insurance programsNational identity or civil registration systems.Response: The three registries will have different stakeholders, while the Health Information Unit will remain the focal point.Where relevant necessary Health stakeholders, Non-Health stakeholder in the government sector, Regulatory authorities and private sector should be consulted.Example: for client registry, other than the Ministry of Health we expect the following to be stakeholders;1.        Registrar General Department2.        Department of Registration of Persons 3.        Ministry of Digital Economy and GovTech4.        Department of Immigration and Emigration5.        Private Sector Regulatory Council6. Integration and Pilot TestingWe would also appreciate clarification regarding the scope of pilot integrations:The expected number of systems to be integrated during pilot phases.Whether a national interoperability platform (e.g., health data exchange) is already operational and available for integration testing.Whether the project includes participation in a formal interoperability testing event (e.g., Connectathon) with defined test scenariosResponse: The Integration and Pilot Testing will be a collaborative activity between the different suppliers of the procurements.The relent entity should organize connectathons for the integration of components they build and develop early sandboxing environments to facilitate.As the priority use case Exchange of a) demographic datab) OPD/Clinic Summariesandc) e-referrals data is required

New clarification added: Clarification 09:1. Adopters / Participating InstitutionsCould the procuring entity please clarify the anticipated scope of initial adopters for the platform?Specifically:The approximate number of health facilities expected to be onboarded during Phase 1 of implementation.The types of facilities included in the initial rollout (e.g., national hospitals, provincial hospitals, primary care facilities, laboratories, etc.).Whether integration will occur directly at facility-level systems (e.g., HIS/EMR/LIS) or primarily through a national interoperability platform or health information exchange.Whether the bidder is expected to support onboarding of pilot facilities only, or if broader nationwide onboarding support is required during the project duration.Response: All registries must be scoped to handle the full national requirement. Thus, national scalability projections must be done and proven with test data submissions.During the grant period for practical reasons, only the existing HIS/EMR systems in the state health sector (~130 HHIMS, ~12 HIMS, ~32 OpenMRS and CloudHIMS) and the ~14 new HIS/EMR to be established under the grant is to be connected.The hospitals would cover primary, secondary and tertiary care levels. (this will cover National, Specialized, Teaching, Provincial General, District General, Base, Divisional and PMCIs)  All exchanges are expected to be primarily through the National Health Data Exchange (NHDX)Hospital level HIS/EMR improvements and integrations are expected to be procured through a different procurement bundle (already published).2. Expected System Load and Transaction VolumesTo appropriately size infrastructure and ensure adequate system performance, we would appreciate clarification on the following:Estimated daily number of patient identity transactions expected at the Client Registry (MPI), including:Patient search queriesNew patient registrationsUpdates to demographic informationEstimated annual and daily volume of healthcare encounters expected to interact with the registries.Approximate peak concurrent request levels expected during busy operational hours.Whether laboratory systems are expected to generate additional identity validation or transaction loads.This information will assist in determining appropriate levels of horizontal scalability, caching, and messaging infrastructure.Response:The hosting infrastructure would be a Huawei DCS virtualized high availability environment co-located in a tier-III data center that will be provided by the Ministry of Health. To ensure efficient use of limited computing resources the applications are expected to be architected and optimized in resource utilization.While we don’t have exact transaction estimates. The state health sector is expected to cater to nearly ~25 millions OPD visits & clinic visit and ~5.5million Inward episodes. Each of these interactions are expected to have multiple interactions with the registries for read, write, update of information and verification of audit data, etc.There is also a general pattern of peek usage between the morning and afternoon of the day.3. Estimated Record VolumesTo design data storage and indexing strategies effectively, could the client provide approximate estimates for:Total number of patient records expected in the national registry at maturity.Approximate number of provider records (healthcare professionals).Approximate number of facility records (health institutions and organizational units).Expected daily growth rate of records, particularly for patient registrations.Response:All 22 million citizens are expected to have client registry records. As the current methodology allows for duplication of records (not promoted), the number of records is likely to exceed the population.There 1600 state healthcare facilities and many more private healthcare facilities. Also, some health care organizations are expected to have multiple service delivery locations providing multiple healthcare service.There are over 150,000 health staff in the state health sector4. User Training ScopeWe kindly request clarification on the expected training scope under this project:Approximate number of users to be trained across the system (administrators, data stewards, technical staff, etc.).Types of users expected to participate in training, such as:System administratorsRegistry data stewardsIntegration engineersMinistry-level operational staffWhether training is expected to be conducted:Centrally (e.g., Ministry-level training sessions), orDistributed across multiple facilities or regions.Whether the bidder is expected to provide training materials and train-the-trainer sessions only, or direct training for all end users.Response:Training is initially expected to be limited to the Ministry focal points and 30 hospitals covered under the grant. These users are expected to be given direct training.But the training methodology should be rapidly scalable with Training of Trainer, and Online prioritized with extensive documentation, and e-learning content.It can be expected the training to hosted in Colombo with online participation by the regional staff.

New clarification added: Clarification 08:Extension Request: UNOPS RFP 2026/60951We are currently in the process of preparing our proposal for the above-mentioned tender. We have a keen interest in participating and wish to provide a comprehensive and high-quality submission that fully addresses UNOPS' requirements.However, due to the complexity of the technical specifications requiring additional coordination with sub-consultants. Recent clarifications provided on the portal that require us to adjust our technical approach & the need for further internal due diligence to ensure a competitive and cost-effective financial proposal.We kindly request a bid closing deadline extension of 14 working days.  We believe this extension will allow for a more robust competition and ensure that our final proposal offers the best possible value to the project.Thank you for your consideration of this request. We look forward to your favorable response.Response: We will not be able to provide an extension to proposal submission deadline at this stage.

New clarification added: Clarification 07:As per the 'RFP-Section_II - Schedule of Requirements' document, you have specified that 'The proposed team shall be deployed in Sri Lanka'. Could you please clarify whether this means that the entire team has to be physically present during the project period in Sri Lanka?Response: Yes, The key personnel required in the RFP-Section_II - Schedule of Requirements should be deployed in Sri Lanka

New clarification added: Clarification 06:Q1: Regarding the eligibility criteria, specifically the requirement: "Should have a minimum 10 years of experience in software development/customisation prior to proposal submission deadline," please clarify whether this 10-year experience must be held by a single company, calculated from its business registration date, or if it pertains to the cumulative experience of the proposing team.Response: The offorer (the firm) should have a minimum of 10 years of cumulative experience in software development / software customisation prior to proposal submission deadline. Overlapping or concurrent project periods will not be double-counted. Q2: Regarding the requirement for "Financial capability: Offeror should have annual sales turnover of minimum USD 750,000 in each of the last 2 years," is it acceptable for a Joint Venture (JV) to meet this criterion based on the combined turnover of its constituent vendors?Response: Yes, In the event of a JV, this criteria can be met combinly by all the partners.Q3: What virtualisation platform is deployed at the MoH Tier III data centre? (VMware, OpenStack, Proxmox, Hyper-V, bare metal?) Response: The MoH Data Centre uses Huawei DCS virtualization platform for hosting. Q4: The ToR requires "management APIs for user creation, updates, and deactivation" (Section 5). Does this refer to managing registry data records (patients/providers/facilities) or managing user accounts that access the registries?Response: The primary goal of the registries is to enable FHIR API based interoperability for data records (patients/providers/facilities). The Management APIs are to facilitate the automation of on-boarding and management of institutional users to the DHP services.Q5: Since the Identity Provider (Keycloak) is under Bundle #2, should the registries implement OAuth2/OIDC token validation assuming the central IdP will be available during our integration testing phase? If the IdP is not yet deployed, what interim authentication mechanism should the registries use during development and Connectathon?Response: It would be prudent to setup interim authentication mechanism to support authentication requirements. But, all efforts will be taken to provide at least a sandboxing environment for OAuth2/OIDC token validation early. Q6: For the RBAC requirements (CR.FN.15, PR.FN.11, PR.FN.16-17), should the registries manage their own role definitions and user-role assignments locally, or will role assignments be managed centrally in Keycloak and passed to the registries via OAuth2 token claims/scopes?Response: Registries manage their own role definitions and user-role assignments locally. API based access is primarily meant to support authentication of different connected systems and not users. Q7: PR.FN.17 specifies that a Nursing Council user should not update Medical Council records. Is this ownership-based access model defined in a DHP-wide governance policy, or should the service provider propose the access control model during inception?Response: After studying the context the the service provider propose may suggest an access control model acceptable to the Ministry of Health during inception.Q8: The 99.999% availability requirement — does this apply from day one of production go-live, or is there a ramp-up/stabilisation period?Response: From the go-liveQ9: For the 99.999% availability, are planned maintenance windows excluded?Response: reasonable and pre-approved planned maintenance windows can be excluded​​Q10: What are the expected peak concurrent user loads?Response: Peak loads are expected to be different for different registries. Each citizen in the country (22 million) on average make 2.5 times health visits per year and each of the would require client registry interactions one or multiple times to query. update and deactivate records. It is expected to have peak hours around 8 and 2pm on working days. Q11. The specified Common Registries potentially contain Personally Identifiable Information (PII); therefore, these registries must comply with the PDPA Act. Is there a requirement for these registries to be deployed with an inbuilt consent-based personal data management mechanism, or will consent management be handled externally to the registries?Response: Consent management is to be expected to be implemented in the National Health Data Exchange levelQ12. Deduplication is specified as a requirement in the RFP.   (a) Should duplicate records be detected prior to data being recorded, or after recording (i.e., deferred detection)?   (b) Upon discovery of a duplicate record, how should the registry respond? (For example: Place the record into a duplication-handling workflow within the registry, Notify the originating system to correct and resubmit the data, or Automatically deduplicate the record without notifying the originating system)Response: (a) Deterministic matching based on multiple identifiers in real time. Probabilistic matching can be done after recording. (b) automated deduplication is not expected.Q13. What level of alignment is expected from the proposed offering in relation to the SLUDI foundational ID? e.g: Should SLUDI be considered the foundational UID for 3 registries and related systems ? Response: SLUDI and/or health domain specific derived ID from the SLUDI is identified as another business identifier. Should be stored, searched and updated,,, etc.

New clarification added: Clarification 05:We would like to formally request an extension of the submission deadline.Response:Deadline for bid submission, Deadline for submission of Clarifications and Expected Contract Start date are revised as follows: Deadline for bid submission under General section:2026-03-16, 11.30 UTC (5:00 PM Sri Lanka time) Deadline for submission of clarifications under General section:2026-03-09, 11.30 UTC (5:00 PM Sri Lanka time)Expected Contract Start date2026-04-07

New amendment added #2: Amendment 02:Revision of the date of the Deadline for bid submission, Deadline for submission of Clarifications and Expected Contract Start date as follows: Deadline for bid submission under General section:2026-03-16, 11.30 UTC (5:00 PM Sri Lanka time) Deadline for submission of clarifications under General section:2026-03-09, 11.30 UTC (5:00 PM Sri Lanka time)Expected Contract Start date2026-04-07

New clarification added: 19.) Question 1: Maintenance Costs & Duration Reference: Section 7 (Post-Implementation Warranty), Page 10 & Form C (Financial Proposal), Page 1 Question: Section 7 requires a comprehensive support and maintenance program for 12 months after Go-Live. Should the cost for this 12-month maintenance period be included in our Total Financial Proposal (Form C), or will it be a separate contract? Are we required to quote for maintenance beyond the first 12 months? Response: The 12-month post-implementation warranty and maintenance is part of this contract and must be included in the total financial proposal. Bidders are not required to quote for maintenance beyond the initial 12-month warranty period.20.) Question 2: Hosting Charges Reference: Section 6 (Inputs from MOH), Page 13 & Section 11, Page 25 Question: The RFP states that the Ministry of Health (MoH) will provide the Data Centre infrastructure. If we use the MoH infrastructure, confirm that we do not need to include any hosting or hardware costs in our financial proposal. If we propose a Cloud Hosting solution (as per our technical proposal), should we include the hosting subscription charges in our financial proposal, and if so, for how many years (e.g., 1 year or 3 years)? Question 3: User Counts & Load Response: The MoH will provide the Data Centre hosting infrastructure as stated in Section 6 of the ToR. Bidders should not include hosting or hardware costs in their financial proposals. Cloud hosting alternatives are not envisaged under this procurement.21.) Reference: Section 1 (Background), Page 5 Question: To ensure the system is designed for the correct capacity, please provide the estimated counts for: Total Users: How many total System Users (Doctors/Nurses/Staff) will utilize the system? Concurrent Users: What is the expected number of users logged in and active at the same time (Peak Load)? Database Size: What is the expected number of records for the Provider Registry (Total Health Workers) and Facility Registry (Total Hospitals/Clinics)? Response: Detailed capacity planning figures will be refined during the Inception phase. However, for proposal sizing purposes, bidders may use the following indicative parameters:MoH sees the primary registries and back send services that are accessed through the Hospital HIS/EMR systems. Thus, most interactions would be API calls.Capacity Building is expected to be limited for the following instances.1) Health Information Unit for all the 3 registries as the focal point.2) The planning division and the provincial/regional health directorates for health facility data3) Relevant regulatory councils, and hospital HR staff for provider informationComprehensive documentation (manuals, guides, etc.) should be provided along with the training for the Ministry of Health to replicate such training sessions with the expansion of the services to a wider digital health ecosystem.Record numbers;Client registry: > 22 millionFacility Registry: >1600 health organizationsProvider Registry: >150,000 health staffOn average each Sri Lankans seek health care 2.5 times per year.For each such interaction the registries would be queried multiple times. The health services delivery would also have peek hours around 8am and 2pm Sri Lanka Time.

New clarification added: Category 4: Support & Warranty (Crucial for Costing) 10. "Included Enhancement Capacity" (Section 7, Page 10) Context: "Twenty (20) person-days per quarter shall be allocated at no additional cost." (Total 80 days/year). Question: a) If the MoH does not utilize these 20 days in a specific quarter, do they expire, or do they roll over to the next quarter? b) Does "Person-day" refer to a specific profile (e.g., Senior Developer vs. Junior Tester), or can it be an average blended rate? Response:10a.) The 20 person-days per quarter allocation does not roll over. Unused days in a given quarter expire at the end of that quarter.10b.) A “person-day” refers to a standard working day of effort and is not tied to a specific staff profile. 11. Tier-3 Support Definition (Section 7, Page 10) Context: "Tier-3 expert help desk support... during Sri Lanka business hours." Question: Does this require a dedicated support engineer sitting at the MoH/Helpdesk physically, or is "On-Call" remote support acceptable as long as SLAs are met? Response:Tier-3 support does not require a dedicated on-site engineer. Remote on-call support is acceptable provided the bidder meets the SLA response and resolution times specified in the ToR. The support team must be based in Sri Lanka as stated in Section 7 (Post-Implementation Warranty).12. Warranty vs. Maintenance Period (Section 7, Page 10) Context: "Support and maintenance program for a period of twelve (12) months following Go-Live." Question: Please confirm that the 12-month period begins after the final sign-off of the "Final Report & Closeout" (Deliverable 8). Response:Confirmed. The 12-month post-implementation warranty period commences upon formal Go-Live and Acceptance of the solution by the Ministry of Health, as stated in Section 7 of the ToR.Category 5: Staffing & Eligibility 13. Project Experience Overlap (Section 7, Item 4, Page 14) Context: "Overlapping or concurrent project periods will not be double-counted." Question: If a firm has run two distinct, high-value projects for two different clients simultaneously (e.g., Client A: Jan-Dec 2024, Client B: Jan-Dec 2024), does this count as 1 year of experience or 2 years of cumulative project experience? (The current wording implies 1 year, which penalizes large firms handling parallel projects). Response: As stated in the ToR, overlapping or concurrent project periods will not be double-counted. If two projects ran concurrently during Jan–Dec 2024, this counts as one (1) year of experience. This approach measures the firm’s duration of active engagement, not the aggregate volume of projects.In the event of a JV, this criteria can be met combinly by all the partners (firms).14. Key Personnel Exclusivity (Section 8, Page 22 & Section 14, Page 26) Context: "No overlap of full-time key personnel across the awards." Question: a) If we bid for both Bundle 1 and Bundle 2, must we propose two completely distinct sets of 8 people (16 people total)? b) Can non-key staff (e.g., UI Designers, Junior Testers) be shared across bundles?  Response:14a.) The ToR requires that key personnel designated for "full-time" roles must be unique to each DHP component/bundle. The Key Personnel table explicitly tags which positions are full-time: Project Manager/Team Lead, Software Engineers, Business Analyst, and Quality Assurance Engineer. If bidding for both Bundle 1 and Bundle 2, the bidder must propose completely distinct individuals for these full-time positions in each bundle.14b.) The non-overlap requirement applies specifically to key personnel designated as full-time in the Key Personnel table. Positions not tagged as full-time (e.g., Software Architect, DevOps Engineer) and non-key staff (e.g., UI designers, junior testers) may be shared across bundles, provided this does not affect the bidder’s ability to deliver on both contracts concurrently.15. Definition of "Large-Scale" (Section 7, Item 5, Page 14) Context: "National or multi-national software implementations." Question: Would a large-scale private sector implementation (e.g., a major Telco or Banking core system) be accepted as "Large-Scale" experience, or is it strictly limited to Government/National scale projects? Response: The ToR defines “large-scale” as “national or multi-national software implementations and enterprise-level data management.” This is not limited to government projects. Enterprise-level implementations in the private sector (e.g., telecommunications, banking core systems) would qualify.Category 6: Financial & Legal 16. Intellectual Property & Reselling (Section 5, Page 11 & 12) Context: "The contractor shall not commercialise... any solution... developed under this contract." Question: If the bidder proposes a solution based on their own pre-existing Intellectual Property (an accelerator or framework) configured for MoH, does the MoH claim ownership of the underlying pre-existing IP, or only the customizations built specifically for MoH? Response:The IP provisions in the ToR (Section 5) apply to all artefacts “developed or produced under this contract.” Pre-existing intellectual property owned by the bidder prior to contract signature remains the bidder’s property. However, all customisations, configurations, and derivative works built for MoH under this contract become MoH property. The bidder must ensure that the use of any pre-existing IP does not create vendor lock-in or restrict the Ministry’s ability to operate, modify, or extend the solution independently.17. Payment Schedule (Section 13, Page 26) Context: 5% payment for Inception Report. Question: Given the high mobilization costs (staffing, hardware setup), would UNOPS consider increasing the Inception Report payment tranche to 10% or 15% to better support cash flow for local vendors? Response: The payment schedule is as published in the ToR. The Inception Report payment is fixed. Bidders should plan their cash flow accordingly.18. Exchange Rate Fluctuations (General Financial) Context: The bid is in LKR. Question: Given the project duration and potential economic volatility, is there any provision for price adjustment due to significant inflation or exchange rate fluctuation during the 30-week delivery or the 12-month maintenance period? Response: The contract is a fixed-price, deliverable-based agreement in LKR. There are no provisions for price adjustment due to inflation or exchange rate fluctuations. Bidders should factor any foreseeable economic risks into their financial proposals.

New clarification added: Category 2: Data & Migration 6. Data Cleansing Responsibility (Section 5, Page 9) Context: "Execute initial data loads and pre-populate required datasets." Question: What is the estimated volume of records for the initial load (e.g., 20 million citizens, 50k providers)? Furthermore, is the Data Cleansing (deduplication, fixing spelling errors in legacy data) the responsibility of the Bidder, or will the MoH provide "clean" CSV/JSON files ready for import? Response:Estimated volumes: Client Registry — approximately 22 million records based on population coverage targets; Pro-population of this client data is not expected. Provider Registry — approximately 150,000 records based on registered health professionals;  (in the initial stage)Facility Registry — approximately 1600 facilities based on the national health facility inventory. (in the initial stage)The bidder is expected to execute initial data loads and pre-populate required datasets (Section 5). Data validation and cleansing routines are part of the Operational Readiness deliverable. The MoH will provide available source datasets; the bidder should budget for data cleansing and transformation activities.7. Provider Registry Data Sources (Annex 3, Page 38) Context: Integration with Medical Councils, Nursing Councils, etc. Question: Do the various councils (SLMC, SLNC, etc.) currently have digital databases with API access? If not, will the initial population be manual data entry or CSV uploads? If manual entry is required, is the bidder responsible for the data entry labor? Response:The professional councils maintain their own member databases at varying levels of digitisation. API-based access is not currently standard across all councils. The bidder is expected to develop adapters for data exchange where digital interfaces exist and to support bulk import (CSV/file-based) where they do not. Manual data entry labour is not in scope for the bidder.Category 3: Integration & Dependencies 8. Dependency on Bundle #3 (Identity Provider/Keycloak) (Page 4, Table) Context: Bundle #1 (this tender) requires an Identity Provider (IdP) integration, but "Identity Provider" is listed under Bundle #2 components in the table on Page 4 (Item 4), and Certificate Services are under Bundle #3. Question: Please clarify if the successful bidder for Bundle #1 is responsible for setting up the Identity Provider (Keycloak/IAM) and Certificate Authority, or if we are merely required to integrate with an IdP set up by the Bundle #2/#3 vendors? If we are dependent on other vendors, what is the protocol if their delivery is delayed? Response: The Identity Provider is a Bundle #2 component, and Certificate Services fall under Bundle #3. The Bundle #1 bidder is required to integrate with these services, not to implement them. The bidder should design for standard protocols (OAuth2/OpenID Connect, TLS 1.2+) as specified in the technical specifications.Regarding inter-bundle dependencies: the project will be coordinated through the DHP Programme Management structure. Sandbox/stub environments may be provided to enable parallel development where dependent bundle services are not yet available. Bidders should account for integration risks in their risk register and mitigation framework (Deliverable 1).9. SMS Gateway and Email Services (Page 3, Diagram) Context: Diagram shows "SMS Gateways" and "E-Mail Services." Question: Will the MoH provide the SMS Gateway API credentials and cover the cost of SMS transmission, or should the bidder include SMS costs in the financial proposal? Response: SMS gateway and email services will be provided by the MoH. Currently and Zimba email server is managed by the MoH along with SMS gateway accounts from Sri Lankan telecom operators.The bidder should design for integration with an SMS gateway API but should not include SMS transmission costs in their financial proposal."

New clarification added: Clarification 04Category 1: Scope of Work & Technical Solution 1. Preference for Specific Open Source Products (Section 4, Item 2, Page 8) Context: The RFP prioritizes "Open-source with configuration" over "Bespoke development." The Global Digital Health community (OpenHIE) often uses specific tools (e.g., OpenEMPI for Client Registry, iHRIS for Provider, GOFR for Facility). Question: Does the Ministry of Health (MoH) or the International Technical Assistance (ITA) team have a preferred set of pre-selected Open Source products (e.g., HAPI FHIR, OpenEMPI, Keycloak), or is the bidder entirely free to propose any stack provided it meets the FullSTAC/FHIR requirements? Response: The ToR does not prescribe specific open-source products. Bidders are free to propose any solution stack that meets the fullSTAC/FHIR requirements, provided the evaluation criteria in Section 4 (Technical Assessment and Solution Options) are satisfied. The prioritisation order is: (1) open-source with configuration, (2) open-source with customisation, (3) bespoke development.2. Scope of "Adapters" for Existing Systems (Section 4, Item 3, Page 9) Context: The RFP states: "Identify and develop adapters or libraries (Java and PHP) enabling integration with existing Hospital Information Systems." Question: Can the MoH provide a definitive list of the specific Hospital Information Systems (HIS) versions and their current underlying technology (DB/Language) that require adapters? Is the scope limited to providing a generic SDK/Library for these vendors, or is the successful bidder responsible for the actual implementation code within the 3rd party HIS? Response: The scope requires the bidder to identify and develop adapters or libraries (Java and PHP) enabling integration with existing Hospital Information Systems. The bidder is responsible for providing the adapter/library layer; implementation within third-party HIS source code is not in scope. Current HIS/EMR implemented in Sri Lankan state health sector is primarily based on Java and PHP (latest versions)(solutions are OpenMRS, Hospital Health Information Management System, Hospital Information Management System, CloudHIMS). The adopters need not be solution specific. The integration of the adapters would be the responsibility of the HIS/EMR solution provider.3. Integration with National Digital Identity (Section 2, Page 4 & 6) Context: Mentions integration with SLUID (Sri Lanka Unique Digital ID) and NDPI. Question: Is the SLUID system currently live and are its APIs available for integration during the 30-week project timeline? If SLUID is delayed, what is the interim "Source of Truth" for authentication that the bidder should plan for? Response: The SLUID infrastructure is being developed under the Ministry of Digital Economy. Integration readiness during the contract period will depend on SLUID’s deployment timeline. Bidders should design for SLUID integration but also accommodate an interim authentication mechanism (e.g., NIC-based identification) pending SLUID availability. A sandboxing enviornment is expected to be in place before the full SLUID deployment and Ministry of Health will facilitate access to such when available through Ministry of Digital Economy.4. Tier-3 Data Centre Infrastructure (Section 6, Item I, Page 13) Context: MoH provides the hosting environment (Tier III).Question: a) What specific virtualization platform is used (VMware, Hyper-V, KVM)? b) Will the MoH provide the necessary operating system and database licenses (e.g., RHEL, Oracle), or must the bidder budget for OS/DB licenses? c) Is there an existing Kubernetes/Container orchestration layer available, or must the bidder build the container environment from bare metal/VMs? Question 1: Hosting Option Reference: Section 6, Page 13 (Inputs from MOH) & Section 5, Page 9 Question: The tender states that the Ministry of Health will provide the Data Centre. are we allowed to propose a Commercial Cloud Hosting Provider (such as AWS, Azure, or a Local Cloud) instead of using the Ministry's infrastructure, if it offers better performance? Question 2: Direct Payment for Hosting Reference: Section 11, Page 25 (Financial Proposal) Question: If we propose a Commercial Cloud solution, can the monthly hosting costs be billed directly to UNOPS or the Ministry of Health based on actual usage? (We would be responsible for the configuration and management, but the client pays the hosting provider directly). Question 3: Data Location (Data Sovereignty) Reference: Annex 2, Item CR.NFN.7, Page 37 Question: The document states data must reside "within the Sri Lanka data center." If we propose a Cloud solution, does the server physically have to be located inside Sri Lanka, or can we use a secure global cloud region (like Singapore or Mumbai)? Response:4a.) The MoH Data Centre uses Huawei DCS virtualization platform for hosting. 4b) Bidders are expected to use open-source databases (PostgreSQL, MongoDB, MySQL) and open-source operating systems as per the fullSTAC approach. The MoH will provide virtualization infrastructure; bidders should include any additional software requirements in their proposal (should be included and costed as part of the proposal). 4c) Huawei DCS supports containerization. Any additional requirements over the Huawei DCS must be proposed (in line with FullSTAC approach)and costed by the vendor.The ToR specifies deployment in the “Ministry of Health Provided Data Centre Infrastructure” (Section 5 and Section 6). This is the required deployment target. Cloud hosting alternatives are NOT envisaged under this procurement.All data must reside within Sri Lanka in compliance with applicable data sovereignty requirements. 5. SLCERT Penetration Testing Costs (Section 4, Item 4, Page 9) Context: "Conduct security testing, including penetration (PEN) testing through the Sri Lanka CERT." Question: Are the fees charged by Sri Lanka CERT for the penetration testing and subsequent re-testing to be borne by the Bidder (included in the financial proposal) or will they be paid directly by the MoH? Response: The ToR requires the bidder to “Conduct security testing, including penetration (PEN) testing through the Sri Lanka CERT” (Section 4). As the financial proposal is all-inclusive, SLCERT testing fees should be included in the bidder’s financial proposal.

New clarification added: Clarification 03 Please clarify the following, a.) What is the level of maturity of existing Provider and Facility registry? Response: The existing Provider and Facility data are currently maintained through manuel/semi-digital processes managed by relevant units. There is no operational digital registry with API-based access at present. The successful bidder will be expected to design and develop these registries as greenfield implementations, informed by existing datasets.b.) Who collects and persists the information of each registries?Response: Client data is captured at the point of care across hospitals, MOH offices, and public health programmes. Provider data is maintained by the respective professional councils (SLMC, SLNC, etc.) and the Ministry’s Establishment Division. Facility data is maintained by the Health Information Unit and relevant line directorates.c.) What type of access integrations existing registries support, if any?Response: There are currently no standardised API-based integrations for registry data. Data exchange is largely file-based (CSV/Excel). The DHP registries to be developed under this assignment are expected to provide HL7 FHIR R4 compliant APIs as specified in the ToR and the published FHIR Implementation Guides.

New clarification added: Clarification 02Regarding the Qualification Criteria (Form F), which requests a minimum of 10 years of experience in software development/customization:Our firm has 8 years of experience, during which we have successfully delivered large-scale digital projects similar in complexity to the HiQi ProjectCould you please clarify if a bidder meeting all other criteria and demonstrating significant technical competence in the health sector will be considered, or if the 10-year requirement is a mandatory 'Pass/Fail' threshold that would lead to immediate rejection?Response: All criteria mentioned under 'Section 7.I: Qualifications of the firm' are mandatory (Pass/Fail) criteriaIf an offeror does not have all the expertise required for the provision of the Services described in the RFP, the offeror may submit a proposal in association with other entities, particularly with an entity in the country where the Services are to be provided. In the case of a Joint Venture, consortium or association:(i) All parties of such Joint Venture, consortium or association shall be jointly and severally liable to UNOPS for any obligations arising from their proposal and the Contract that may be awarded to them as a result of this RFP;(ii) The proposal shall clearly identify the designated entity designated to act as the contact point to deal with UNOPS. The duly filled Form A: Joint Venture Partner Information Form must be included with the proposal. Such entity shall have the authority to make decisions binding upon the Joint Venture, consortium or association during the proposal process and, in the event that a Contract is awarded, during the duration of the Contract;(iii) The composition or the constitution of the Joint Venture, consortium or association shall not be altered without the prior consent of UNOPS; and(iv) Each Joint Venture, consortium, or association member shall meet the offeror eligibility conditions, as defined in the document Section I: Instructions to Offerors, Article 4.For Joint Venture, consortium, or association, the bid submission documents must be submitted in the name of the leading partner. If the forms are signed by a non-lead partner the proposal should accompany a Power of Attorney (POA) authoring the non lead partner to sign the submission document on lead partner's behalf.For Joint Venture, consortium, or association, at least the leading entity must be registered in UNGM, and preferably all members. The submission must be made by the leading partner through their UNGM account.

New amendment added #1: Amendment 01:The ITB shall be amended to reflect the following:Upload of Pre-Bid Meeting Minutes,To amend the document Section II Schedule of Requirements, Section 7: Expertise Of The Firm & Project Staffing, 'Sub Section I: Qualifications of the firm' and 'Sub Section II: Required qualifications and experience of the proposed team' andTo amend the documents 'Form E: Format for Resume of Proposed Key Personnel', 'Form F: Performance Statement Form' and 'Evaluation Criteria & Scoring Document' to reflect the changes made in the document 'Section II Schedule of Requirements'Replaced 04 documents under Documents section:Replace the file "RFP_Section_II_Schedule of Requirements RFP_2026_60951" with "RFP_Section_II_Schedule of Requirements RFP_2026_60951_R1" under documents.Replace the file "Form E_ Format for Resume of Proposed Key Personnel" with "Form E: Format for Resume of Proposed Key Personnel_RFP_2026_60951_R1" under documents.Replace the file "Form F_ Performance Statement Form" with "Form F: Performance Statement Form RFP_2026_60951_R1" under documents.Replace the file "Evaluation Criteria & Scoring Document" with "Evaluation Criteria & Scoring Document RFP_2026_60951_R1" under documents.

New clarification added: Clarification 01Greetings!! We would like to participate for the RFP and we would like to request the clarifications on below questions:Q1. Over the past decade, we have successfully implemented and maintained large-scale common registry platforms for multiple governments and Ministries of Health. These platforms are mission-critical systems designed for high availability, interoperability, data integrity, and long-term sustainability.Our current framework already addresses more than two-thirds of your stated requirements out of the box. The remaining components can be rapidly configured and tailored to meet your specific operational, regulatory, and contextual needs. This approach significantly reduces implementation risk, compresses timelines, and optimizes total cost of ownership — while still delivering a solution that feels purpose-built for your environment. May we understand whether you are open to a configurable, proven platform approach such as this, or whether you are specifically seeking fully bespoke development from the ground up?Q2. Are you planning a formal demonstration or presentation phase?  We would be delighted to showcase the platform in action.Response:Please refer detials provided under Section II: Schedule of Requirements, 2. PURPOSE OF THE ASSIGNMENT,  2. Technical Assessment and Solution OptionsEvaluate potential open-source solutions, prioritised as:Open-source with configurationOpen-source with customisationBespoke software developmentand 5. INTELLECTUAL PROPERTY 

New clarification added: Pre-proposal clarification meeting:A pre-proposal meeting will be conducted virtually as set out below: Date: Friday, 20 February 2026Time: 10:00 – 11:00am [Sri Lanka Time]Link: https://meet.google.com/zrz-thha-xvsAttendance of the pre-proposal clarification meeting is NOT mandatory, but strongly encouraged to avoid the risk of non-compliant proposals. Failure to attend the non-mandatory virtual pre-proposal clarification meeting shall not render your proposal invalid.