RFP071326KJM Addendum Number 02-Q&A(FINAL).pdf

THE UNIVERSITY OF NORTH CAROLINA AT CHAPEL HILL

REQUEST FOR PROPOSALS (RFP) ADDENDUM

FAILURE TO RETURN THIS ADDENDUM IN ACCORDANCE WITH THE INSTRUCTIONS BELOW MAY

SUBJECT YOUR PROPOSAL TO REJECTION

RFP Number: RFP071326KJM Addendum Number: 02 Addendum Date: August 7, 2026 RFP Opening Date / Time: August 21, 2026, at 12:00 PM Eastern Time (ET)

Instructions: Return one properly executed copy of this addendum prior to the RFP Opening Date / Time specified above. This addendum may be included with your proposal, or it may be emailed separately to Kimberly Middleton at kimberly_middleton@unc.edu.

A. Please see the following University responses to all questions received by the deadline to submit written questions of July 24, 2026, at 12:00 PM ET:

1. Question: Please confirm the approximate number of specimens, freezers/storage units, and distinct laboratories expected to be onboarded in the initial three-year term to help size licensing, hosting, and onboarding services.

Answer: The initial three-year implementation is expected to include approximately 12–15 laboratories.

Estimated storage and sample volumes are as follows: TPF: approximately 6,000 LN2 tanks over three years (based on approximately 2,000 tanks per year; tank sizes vary), with an estimated 500,000– 750,000 samples. If breeding events are included within scope, this would add approximately 15,000 plates over the three-year period. Storage equipment includes approximately 15–80 mechanical freezers, 6 LN2 freezers, 3 refrigerated (4°C) units, and 4 (-20°C) freezers, with laboratories located both within and outside MacNider Hall. BSP: approximately 600,000 samples stored in 20 (-80°C) freezers and 1 LN2 tank (approximately 6,000 samples), plus an additional 30 (-80°C) freezers used for study-specific projects. HTSF: approximately 100,000 samples, including roughly 20,000 stored at -80°C and 80,000 stored at -20°C.

2. Question: Does UNC require out-of-the-box HL7 or FHIR interfaces to a specific EHR/LIS at go-live, or is bidirectional data exchange scoped for a later phase?

Answer: The University anticipates a need for integration with UNC Health's Epic EHR environment.

Where such integrations are within the agreed implementation scope, the solution must support HL7 v2 and FHIR standards. Any FHIR-based integrations must be compatible with Epic's supported integration framework and approved in accordance with Epic's applicable requirements. Where bi-directional data exchange with Epic is included within the agreed implementation scope, such functionality should be available at go-live unless otherwise agreed by the parties in the implementation plan. The solution shall not utilize non-standard integration methods for UNC Health clinical systems unless expressly approved in writing by UNC Health.

3. Question: Will UNC allow a vendor-hosted (SaaS) environment within FedRAMP-Moderate or HITRUST certified infrastructure, or is on-premises deployment mandatory for sensitive specimen data?

Answer: The University will consider vendor-hosted (SaaS), customer-hosted, on-premises, and private cloud deployment models, provided the proposed solution satisfies the University's security, privacy, compliance, data protection, and operational requirements. Offerors should describe their proposed hosting architecture, identify any relevant security certifications or independent assessments (e.g., SOC 2, HITRUST, FedRAMP, as applicable), and explain how customer data ownership, security, availability, backup and recovery, and data portability are maintained throughout the term of the agreement and upon termination or expiration.

mailto:kimberly_middleton@unc.edu

4. Question: For data migration, please identify the current repository or LIMS systems in use and the estimated data volumes/format to be migrated.

Answer: Current data repositories include Microsoft Excel, a homegrown system that is expected to support CSV export (with programmatic extraction options potentially available, subject to vendor capabilities and permissions), and the BSP system, which is similarly expected to support CSV export and contains approximately 22 years of historical sample records. TPF data is not expected to be large in volume but is broad in scope.

5. Question: During the evaluation, what specific workflow scenarios and compliance reports should vendors be prepared to demonstrate live?

Answer: Vendors should be prepared to demonstrate representative end-to-end workflows and reporting capabilities applicable to the University's operations, including: scheduling → intake → processing → storage or immediate distribution; long-term storage → distribution; processed intake → quarantine;

quarantine → storage or destruction; project setup; processing protocol setup; material creation;

processing of multiple vessel and material types (e.g., blood → plasma/buffy coat → DNA/RNA) in tubes, plates, and matrix tubes/racks; EHR data integration; billing configuration and reporting; inventory management, including blinded and unblinded inventory reports, direct client inventory queries, inventory searches, and sample audit trails. Vendors should also demonstrate deviation reporting and compliance reporting, including the ability to report total animal counts by year (or actual counts where tracked), estimates based on tank size where applicable, and the number of animals used in experiments before 8 days post-fertilization (dpf).

6. Question: Would the University consider alternative continuity-of-operations protections in lieu of source code escrow for a commercially available enterprise platform, provided the vendor maintains formal product lifecycle governance, defined software sunset procedures, advance customer notification periods, customer ownership of data, data portability mechanisms, and support for customer-owned extensions through documented APIs? (Reference Attachment B, Section 45 of the RFP)

Answer: The University will consider alternative continuity-of-operations protections in lieu of source code escrow on a case-by-case basis. Any proposed alternative must provide protections that are substantially equivalent to source code escrow and adequately address the University's business continuity, ongoing support, and long-term access requirements. The Vendor should clearly describe the proposed approach, including product lifecycle governance, software sunset procedures, customer notification commitments, customer data ownership and portability, support for customer-owned extensions, and any other measures that ensure continuity of operations in the event the software is discontinued or support is no longer available. Acceptance of any alternative will be at the University's sole discretion.

7. Question: For vendor-hosted deployments utilizing a major cloud provider, what types of security assessments, certifications, attestations, or cloud-provider compliance documentation may be considered acceptable as a "comparable third-party assessment" if a SOC 2 Type II report is not available?

(Reference 4.3.1 of the RFP)

Answer: The University will evaluate comparable third-party assessments on a case-by-case basis for selected awarded vendors. Acceptable evidence may include, but is not limited to, independently audited security certifications, attestations, and control assessments that demonstrate a comparable level of security assurance to SOC 2 Type II. The absence of a SOC 2 Type II report will not automatically result in disqualification; however, awarded vendors will be required to provide sufficient documentation regarding their security controls, hosting environment, and independent assessments as part of the University’s security review and risk assessment process.

8. Question: For customer-hosted deployments, what forms of security assessment or compliance documentation would be considered acceptable?

Answer: For selected awarded vendors with customer-hosted deployments, the University will evaluate applicable security documentation based on the proposed solution, hosting model, and associated risk profile. Vendors may be required to provide relevant security assessments, certifications, attestations, and documentation describing implemented security controls as part of the University's security review and risk assessment process following award.

9. Question: Please describe the intended business use case, anticipated direction of data flow, and whether each integration is required for initial go-live or may be implemented in a subsequent phase for the integrations? (Reference 4.4.2 of the RFP)

Answer: The University anticipates the following integration use cases and data flows: iLab will support billing-related workflows, with data expected to flow from the LIMS to iLab. IRBIS, OnCore, and Veeva will support regulatory-related workflows, with data expected to flow from these systems into the LIMS.

Epic/EHR will support clinical data abstraction and related workflows, with data expected to flow into the LIMS and potential outbound data exchange to another database as needed; bi-directional Epic/EHR integration capabilities should be supported where applicable to the approved implementation scope.

TRACS will support reporting-related data exchange, with data expected to flow into the LIMS. The University will determine whether each integration is required for initial go-live or may be implemented in a subsequent phase based on implementation scope, priorities, and technical readiness.

10. Question: As iLab is identified as the University’s billing and service management platform, please clarify the intended functional boundary between iLab and the proposed solution. Specifically, should investigator request intake, approvals, service ordering, and billing remain within iLab with the proposed solution providing downstream sample and repository management, or is the proposed solution expected to own portions of those workflows? (Reference Section 4.4.2.1.1 of the RFP)

Answer: The University anticipates that iLab will remain the system of record for investigator request intake, service ordering, and billing-related functions. The proposed solution should provide the necessary sample and repository management capabilities and support integration with iLab to enable appropriate data exchange between systems. The University prefers a solution that provides the required connectivity without requiring the purchase of additional modules or functionality beyond the proposed solution, unless otherwise identified as necessary within the vendor's response.

11. Question: The RFP is titled “Institutional Biorepository Management Platform,” while Sections 3.7 and 4.1 describe broader laboratory operations and LIMS capabilities. Please clarify whether the primary objective is an institutional biorepository platform, a broader enterprise LIMS supporting multiple research core operations, or a combination of both. Additionally, please identify the departments, repositories, core facilities, and research programs expected to be included within the initial implementation scope.

(Reference Section 3.7 and 4.1 of the RFP)

Answer: The University’s long-term objective is a combination of institutional biorepository management capabilities and broader LIMS functionality to support multiple research operations over time. The initial implementation phase will focus on establishing the Biorepository LIMS platform and supporting the repositories and workflows included within the initial project scope. Future expansion to additional departments, repositories, core facilities, and research programs may occur in subsequent phases as needs and priorities are identified.

12. Question: Does the University have a preferred deployment model (vendor-hosted SaaS, customer-hosted/on-premises, or private cloud deployment), or will all deployment approaches be considered provided they satisfy the stated security, compliance, and operational requirements?

Answer: The University will consider all deployment approaches, including vendor-hosted SaaS, customer-hosted/on-premises, and private cloud models. Proposed solutions will be evaluated based on their ability to meet the University's security, compliance, data protection, integration, and operational requirements.

13. Question: Please identify the primary stakeholder groups and user communities expected to participate in the evaluation and implementation of the selected solution. Should offerors assume the platform will initially support institutional biorepositories only, or should requirements from additional research cores, shared resource facilities, and associated research programs also be considered within scope?

Answer: The evaluation and implementation will involve stakeholders from The University of North Carolina at Chapel Hill, including institutional biorepositories, research cores, shared resource facilities, and associated research programs. Offerors should consider requirements from all applicable University cores, shared resource facilities, and biorepository operations within the scope of the proposed solution.

The University anticipates that the platform may support broader University research operations beyond the initial biorepository implementation as future needs are identified.

14. Question: For the required sandbox evaluation period, should vendors provide a standard demonstration environment containing representative data, or should the environment be configured using University-specific workflows and use cases? Additionally, please confirm the anticipated number of evaluator accounts required during the sandbox period. (Reference Section 4.5.2 of the RFP)

Answer: The University would prefer a sandbox environment that allows evaluation of both the vendor’s standard functionality and University-specific workflows and use cases. If feasible, vendors should provide an environment or partition that enables evaluators to assess both a representative demonstration environment and workflows configured to reflect University requirements. The anticipated number of evaluator accounts required during the sandbox period is seven (7) users.

15. Question: Please describe the primary systems, databases, spreadsheets, or repository platforms currently used by the repositories and programs expected to participate in this project. Additionally, please indicate whether historical data migration is expected as part of the initial implementation and, if so, the approximate volume of data to be migrated.

Answer: Current data repositories include Microsoft Excel, a homegrown system that is expected to support export to CSV format, and the BSP system. Programmatic extraction options from the homegrown system may be available, subject to vendor capabilities and permissions. TPF data is not expected to be large in volume but is broad in scope. The BSP system contains approximately 22 years of historical sample records. The University’s preference is to migrate applicable historical data into the selected solution as part of the initial implementation, with the final migration scope and approach to be determined during implementation planning.

Execute Addendum:

Vendor Name:

Authorized Signature: Date:

Name and Title:

Email Address:

REQUEST FOR PROPOSALS (RFP) ADDENDUM