Design, Development, Testing, Implementation, and Maintenance of the Document and Imaging Repository of the Digital Health Platform

New clarification added: Clarification No: 07Question:1. The RFP defines identity federation (OAuth2/OpenID), certificate-based trust, and API-based integrations across distributed DHP components. However, it does not explicitly define an overarching security architecture model such as Zero Trust.We kindly requests below clarifications on this.Q1.1  Clarify whether a Zero Trust Architecture (ZTA) or equivalent security model is intended for the Digital Health Platform, particularly governinginter-service communication (east-west traffic),user-to-service access,and cross-institution data exchange.Q1.2  Provide the expected architectural principles and controls (for example, continuous authentication, policy enforcement points, mutual TLS, device/context-aware access).If such a model is not yet defined, confirm whether:Q1.3  bidders are expected to propose and implement a Zero Trust-aligned architecture, andQ1.4  such design will be evaluated as part of the technical solution.This clarification is critical to ensure consistent security design across all DHP components and avoid fragmented or inconsistent implementations across vendors. 2.     The RFP describes a federated architecture with multiple interconnected DHP components exchanging sensitive health data, but does not define network segmentation or internal trust boundaries.We kindly requests below clarifications on this.Q 2.1  Clarify the expected network security architecture, including segmentation of:·       external access zones,·       application/service layers,·       and data/storage layers. Q2.2  Specify whether microsegmentation or zero-trust network controls (for example, service-to-service isolation, east-west traffic control) are required.Q2.3  Confirm whether encryption and authentication of all internal service-to-service communication (for example, mutual TLS) is mandatory.Q2.4  If not defined, confirm whether bidders are expected to propose a segmentation and internal security architecture aligned with best practices.This clarification is important for us to provide and ensure protection against lateral movement and consistent security posture across distributed DHP components. 3.     The RFP requires regular backups and high availability, in page 11 and 35 of section 2, but does not define a comprehensive disaster recovery or ransomware resilience strategy.We kindly requests below clarifications on this.Q3.1  Provide detailed requirements for backup architecture, including:·       backup frequency,·       retention policies,·       and storage isolation. Q3.2  Clarify whether immutable backups (ransomware-protected) are available for critical national health data, or whether it is provided to the bidder during implementation. Q3.3  Define the expected RPO (Recovery Point Objective) and RTO (Recovery Time Objective) for the Document and Imaging Repository.Q3.4 Confirm whether geo-redundant disaster recovery (multi-site failover) is available.   Q3.5  If these are not defined, confirm whether bidders are expected to design and propose a complete DR and cyber-resilience strategy. If it is needed, how will it be evaluated in the tender process ? 4.     The RFP describe a SIEM and audit repository components but does not define the operational cybersecurity model for monitoring and incident response.We kindly requests below clarifications on this.Q4.1  Clarify whether a centralized Security Operations Centre (SOC) will be established at national level ? Q4.2  Kindly Define responsibilities between:·       platform providers,·       component vendors,·       and national cybersecurity bodies (for example, Sri Lanka CERT). Q4.3  Kindly Provide requirements for:·       incident detection,·       response timelines,·       escalation procedures,·       and reporting obligations. Q4.4  Confirm whether vendors are expected to:·       integrate with an existing SOC, or·       provide partial SOC/SOAR capabilities within their solution.This is necessary to ensure clear accountability and effective response to cybersecurity incidents across the DHP ecosystem. Response:Response to Q 1.1: YesResponse to Q 1.2: The model is most likely to be mutual TLS, and is part of the platform support services bundleResponse to Q 1.3: The bidders are expected to conform to the implemented security architecture of the DHPResponse to Q 1.4:  As the security architecture is defined by a separate procurement bundle, we are mainly evaluating the architecture proposed for the actual document and imaging repository in this proposal.Response to Q 2.1: As the project comprises of many interconnected components by multiple vendors such information is not available at present. However, the proposed product should support defining these details at the implementation stage.Response to Q 2.2: YesResponse to Q 2.3: Please assume as mandatory at this stageResponse to Q 2.4: The bidders are expected to conform to the implemented security architecture of the DHP as defined in the platform support services bundle.Response to Q 3.1: The DHP Infrastructure provides regular DR side VM backupsResponse to Q 3.2: No such infrastructure available at presentResponse to Q 3.3:  4 hrs for RPO and 8hrs for RTOResponse to Q 3.4: Offsite DR backup availableResponse to Q 3.5: Proposals should be aligned with the available infrastructure, other DHP components in consultation with UNOPS and Ministry of HealthResponse to Q 4.1: YesResponse to Q 4.2: Platform provider: provide the SIEM and audit repository platformComponent vendor: Integrate with the the provided SIEM and audit repositorySLCERT: No direct responsibility other than evaluating and certifying  the component proposed by the vendorResponse to Q 4.3: Will be defined by the platform support services bundleResponse to Q 4.4: integrate with the existing SOC    

New clarification added: Clarification No: 06Question:The RFP specifies role-based access control (RBAC), identity federation, and consent management across multiple distributed DHP components (e.g., Document Repository, NEHR, NHDX, HHIMS integrations). However, the architecture for access control enforcement and policy management is not clearly defined.We kindly requests below clarifications on this.Q1:  Please clarify where access control decisions are expected to be enforced, specifically:·       centrally (for example,  via Identity Provider / API Gateway / NHDX),·       within each individual DHP component (e.g., Document Repository), or·       through a hybrid/distributed model. Q2  Kindly define whether a centralized authorization service or policy engine (e.g., for RBAC/ABAC policies) will be provided as part of the platform, or whether each vendor is expected to implement and manage access control independently. Q3  Please clarify whether attribute-based or policy-based access control (ABAC/PBAC) is required in addition to RBAC, particularly for:·       patient consent enforcement,·       purpose-of-use restrictions,·       and cross-institution data sharing. Q4 Kindly define expectations for fine-grained authorization, including:·       API-level access control,·       document/image-level permissions,·       and field-level or metadata-level restrictions. Q5 Please confirm whether context-aware access controls (e.g., user role, location, device, emergency override scenarios) must be enforced, and where such context evaluation should occur. Q6 If the above is not centrally defined, confirm whether bidders are expected to:·       propose a complete access control architecture, including policy definition, enforcement points, and integration with consent management, and·       ensure interoperability and consistency with other DHP components.This clarification is critical to avoid inconsistent authorization implementations across vendors and to ensure secure, compliant, and auditable access to sensitive health data across the national platform.Response:The vendor is expected to collaboratively agree on certain technical desicions with the Ministry of Health, UNOPS and the Specialist Support Services provider.Response to Q1: Centrally via identity providerResponse to Q2: RBAC policies is expected to be provided as part of the platformResponse to Q3: The Document and Imaging Repository is expected to enforce consent and purpose-of-use at the document/image level based on attributes passed from the central Identity Provider.Response to Q4:  API-level access control is mandatory; document/image-level permissions should be supported, but field-level restrictions are not required at this stage.Response to Q5: Context-aware access controls should be supported, with specifics to be defined collaboratively during implementation.Response to Q6: Bidders must demonstrate how the solution will integrate with the centrally defined access control framework under the Platform Support Services bundle.

New clarification added: Clarification No: 05Question:In reference to the subject Request for Proposal (RFP) regarding the Digital Health Platform (DHP) components, we are seeking technical clarification regarding the geographical and institutional scope of the initial implementation.The "Schedule of Requirements" specifies that the solution must be capable of national-level scaling, supporting petabyte-scale storage and the records of every citizen. However, we understand that the Ministry of Health has currently finalized a hardware procurement cluster designated for 30 specific hospital sites.We would appreciate clarification on the following points:Q1.    Implementation Scope: Is the "Implementation" and "Deployment" phase (Milestones 4 and 5) of this 30-week contract limited to the 30-hospital cluster for which hardware has been purchased? Or is the service provider expected to facilitate a wider nationwide rollout within this specific contract duration?Q2.    Edge Node Alignment: Does the "Edge Node Support" (FR5) requirement specifically target the 30 hospitals in this initial cluster as the primary peripheral storage nodes?Q3.    Architecture vs. Deployment: Does the "national-level implementation" requirement refer primarily to the Software Architectural Pattern (ensuring the design is future-proof for all citizens) while the physical Operational Readiness (Milestone 5) is restricted to the current 30-site hardware footprint?Clarification on these points will allow us to more accurately propose a solution that aligns with the Ministry's current infrastructure roadmap and the "fullSTAC" principles outlined in the RFP.Response:Response to Q1:The solution should be scalable to the National level. But, will be expected to be implemented in 30 hospitals. All implemention related documentation and trainng should be provided to the designated Ministry of Health staff for implemention in other institutions.Response to Q2: Edge node support should be first depolyed in the 30 hospitals by the vendor and Ministry will support the implemention in other institutions.Response to Q3:Yes. National scalability with 30 hospital deplyment under the project.

New amendment added #1: Amendment 01The RFP shall be amended to reflect the following:Upload Pre-Proposal Meeting Minutes RFP/2026/61830Revision of the Deadline for submission of Clarifications to 2026-03-30, 11.30 UTC (5:00 PM Sri Lanka time)Revision of the Deadline for submission to 2026-04-02, 11.30 UTC (5:00 PM Sri Lanka time)Upload Amendment to RFP_Section_II_Schedule of Requirements RFP/2026/61830,Replace Evaluation Criteria & Scoring Document_RFP/2026/61830 with Evaluation Criteria & Scoring Document_RFP/2026/61830_R1 to include following;The following evaluation criteria has been included as a qualification criteria in to this RFP;Offerors submitting proposals for multiple RFPs for DHP components/bundles (including this solicitation and any other solicitations for DHP components/bundles referenced in this TOR) must ensure that the key personnel designated for “full-time” roles are unique to each DHP component/bundle. This requirement is intended to ensure no overlap of full-time key personnel across the awards as set out in Amendment to RFP_Section_II_Schedule of Requirements RFP/2026/61830 

New clarification added: Clarification No: 04Question 11.1. We kindly request a one month extension for this project. Your consideration in this regard is highly appreciated1.2. Kindly give an Extension for this Tender, due to complexity of the Project.Question 2As we are positioning a developed product, we will not be in a position to handover the source code to the client, instead will it be acceptable for UNPOS to deposit the source code to the client using the ESCROW mechanism? Response: 1) As this is a donor-funded project supported by a grant that expires in 2026, we regret to inform you that an extension to the bid submission deadline cannot be accommodated at this stage. Extending the submission period would ultimately impact the overall implementation timeline, which must remain aligned with the grant’s validity.2) This request does not comply with requirements set out in the schedule of requirements.The product should be either open-source configurable, open-source customizable (permissible to anyone) or bespoke (full IP rights to the Ministry of Health). Software needs to be hosted in the MoH source-code repository and deployed through CI/CD pipelines

New clarification added: Clarification 03:Regarding RFP/2026/61830, we have a query concerning the proposal of Key Personnel. We are currently participating in other open UNOPS tenders. Could you please clarify if it is permissible to propose the same individual (e.g., the Project Manager) for this tender as well as for other ongoing tenders? If the offeror is successful in multiple tenders, what is UNOPS's policy regarding the substitution of personnel or the requirement for exclusivity at the time of contract award?" Response: Offerors submitting proposals for multiple RFPs for DHP components/bundles (including this solicitation and any other solicitations for DHP components/bundles referenced in this TOR) must ensure that the key personnel designated for “full-time” roles are unique to each DHP component/bundle. This requirement is intended to ensure no overlap of full-time key personnel across the awards.Please refer: Amendment to RFP_Section_II_Schedule of Requirements RFP/2026/61830 for more details

New clarification added: Clarification 02:We would like to respectfully draw your attention to the fact that the three referenced RFPs collectively constitute Sri Lanka's integrated Digital Health Platform (DHP) and are not standalone procurements. RFP/2026/61796 (Platform Support Services) delivers the foundational FOSS infrastructure — Identity Provider, Certificate Services, ETL, APM and Audit Repository — upon which both other components critically depend. RFP/2026/61570 (NEHR & National Health Data Exchange) sits at the core clinical data layer and relies on the platform services of 61796 for authentication, security, and data exchange. RFP/2026/61830 (Document & Imaging Repository) feeds directly into the NEHR and must align with both the data exchange standards and the shared platform infrastructure defined across the other two tenders. Given this deep interdependency, preparing technically consistent and financially coherent proposals across all three simultaneously requires considerable care and coordination.We would therefore kindly request your consideration of a 2-week extension to the submission deadlines for all three RFPs, and we remain grateful for your understanding.Response:We will not be able to provide an extension to bid submission deadline at this stage.

New clarification added: Clarification No: 01Subject: Payment Currency Clarification – RFP/2026/61796, 61830 & 61570We would like to respectfully seek clarification on whether contract payments under the above RFPs can be remitted in USD, either to a USD-denominated account held within Sri Lanka or to an account held abroad, given the current economic situation. We would be grateful for your guidance on this matter.Response:Please refer instruction to offerors clause 17: PROPOSAL CURRENCY(IES)Prices in the Proposal shall be quoted in the currency(ies) stated in the Tender Particulars section. If applicable, for comparison and evaluation purposes, UNOPS will convert the Proposal prices into USD at the official United Nations rate of exchange in force at the time of the Deadline for Proposal Submission.  UNOPS reserves the right not to reject any Proposals submitted in a currency other than the mandatory Proposal currency(ies). UNOPS may accept Proposals submitted in another currency than stated above if the Offeror confirms during clarification of Proposals in writing that it will accept a contract issued in themandatory Proposal currency and that for conversion the official United Nations operational rate of exchange of the day of RFP deadline as stated in the Tender Particulars section shall apply. Regardless of the currency of Proposals received, the contract will always be issued and subsequent payments will be made in the mandatory Proposal currency above.