Question:
1. A requirement is for the solution to "Support File, Object and Block."

(a) Of the 2PB per site, what is the estimated capacity breakdown for each data type? (eg: 1PB File, 500TB Object, 500TB Block?)

(b) What applications are using File, Object or Block protocols?

(c) What VNA is being used (Application/Vendor) and what protocols does it support?

(d) What is the expected capacity growth over next 3-5 years?

(e) Does the 2PB incorporate Backup data?

- If Yes, what volume is required for Backup data, and what type of storage is this (File, Block, Object)?

- If Yes, does this data need to reside on a separate physical hardware stack to primary VNA, File and Object data?

- If Yes, is your backup application configured to encrypt data in flight?

2. Section 1.6 – “Ensure seamless integration with existing IT infrastructure” – can you expand on what the existing “infrastructure" is?



3. There are also documented requirements relating to Backup (Section 4.2)

- Is a backup ISV proposal in-scope for this?

- If No, can you provide details of the Backup ISV in use, to enable us to appropriately assess backup ISV integration capability.

Answered on 25/Aug/2025 05:06 PM:


1. The replacement solution must provide multi-protocol support to cover all clinical and enterprise workloads, including File (SMB/NFS), Object (S3-compatible), and Block (iSCSI/FC).

(a) File (SMB/NFS): ~40% (primarily PACS image data, department shares, research data). Object (S3-compatible): ~30% (cloud integration, application/backup archiving, analytics pipelines). Block (iSCSI/VM datastores): ~30% (VMware datastores, application databases, and clinical workloads requiring low latency).

(b) File (NFS/SMB): PACS storage, modality storage, departmental file shares, EMR attachments, research datasets. Object: Backup/Archival tiers, analytics workloads, integration with cloud services (Azure/AWS S3). Block: VMware/Hyper-V datastores, clinical databases (SQL/Oracle), some VNA/PACS storage backends.

(c) Protocols supported: NFS, SMB, and iSCSI (block) – with some vendor roadmaps enabling S3/Object for cloud/hybrid tiering.

(d) Projection is inclusive of capacity growth

(e) Yes - 2PB does incorporate Backup data

- Volume - Object ~30% (cloud integration, application/backup archiving, analytics pipelines).

- Data does not need to reside on a separate physical hardware stack to primary VNA, File and Object data, provided there are cross-site data replication/snapshots that are sufficient.

- Yes - Backup software supports TLS encryption in flight, and data-at-rest encryption is a requirement for any replacement storage platform.

2. Existing IT infrastructure is:

- Compute/Virtualisation: VMware vSphere & Physical Servers

- VNA, PACS, EMR, and departmental systems. Backup Applications

- Networking: 10/25/100 GbE for NFS/SMB/Object, 16/32Gb FC/iSCSI for block

- Cloud: Hybrid integration with Azure and AWS

- Security/Compliance: Data encryption, HIPAA-equivalent/IS18 Maturity level 3, audit logging, immutability

3. Backup ISV selection is out of scope. The tender is focused on storage replacement only. Back up ISV in use is Rubrik.

Question:
Hi Team,

Can you please clarify the following?

1. Is a Capex, Opex or Consumption preferred?

2. Is the fabric for connectivity to hosts and applications in consideration for this bid or is it assumed that there is sufficient capacity for the storage infrastructure

3. Is the Core IP network for connectivity to filers and object stores in consideration for this bid, or is it assumed that the IP network has capacity for the storage infrastructure

4. Is there a requirement or appetite for multiple tiers of performance from the storage infrastructure, or is a general “all flash is good enough” approach, where higher capacity and lower performance flash profiles, like QLC flash, will still be appropriate for all workloads

5. Do you have specific documented objectives around availability and resiliency for data availability and recoverability within a cyber event

6. Is there a requirement or appetite for multiple tiers of availability/resiliency from the storage infrastructure (such as active-active across site, active-active within site, single active with snapshot or clone capabilities)

7. With reference to “Ensure seamless integration with existing IT infrastructure and support for hybrid environments to streamline management and automation”, what is the existing infrastructure and can you define “hybrid environments” in this context

8. VNAs, NAS and Backup workloads can have varied requirements around performance, protocols and use cases. Would GCHHS be able to share information such as:

a. Capacity requirements for each workload

b. Application/protocols for each workload (CIFS, NFS, S3, FC, NVMe-oF)

c. Performance requirements for each workload

d. Cyber Resiliency Objectives for each workload

Thank you!

Answered on 25/Aug/2025 05:25 PM:


1. CAPEX or staggered payment over 5 years with ownership retained, all costs inclusive.

2. The fabric is out of scope for this bid. It is assumed that the existing host connectivity (FC/iSCSI/Ethernet) has sufficient capacity to support the proposed storage infrastructure. However, vendors should specify any minimum connectivity requirements (bandwidth, latency, port density) for compatibility.

3. The core IP network is not in scope for this tender. It is assumed that sufficient IP network capacity (10/25/100 GbE) is available for SMB/NFS/Object connectivity.

Vendors should recommend network design best practices (e.g., jumbo frames, multipathing, segregation for storage traffic).

4. Current stance: All-flash is sufficient for all workloads, with QLC-based high-capacity flash acceptable for archive/backup targets. No immediate requirement for distinct performance tiers, but solutions that allow seamless tiering within the platform (e.g., mixed SSD classes, auto-tiering, or cloud tiering) will be viewed positively for future-proofing.

5. Specific documented objectives around availability and resiliency for data availability and recoverability within a cyber event include:

• 99.999%+ availability for clinical workloads.

• Immutability and WORM capability for backup/object targets.

• Rapid recovery (minutes to hours, not days) for VNA/PACS and EMR workloads.

• Integration with existing cyber recovery strategies (air-gapped backup, ransomware detection, MFA for management).

• Compliance with health sector data security obligations

6. Preferred model for multiple tiers of availability/resiliency from the storage infrastructure is:

• Active-active cross site for high availability with inclusions for Upper Coomer future state (Triplication).

• Synchronous/asynchronous replication between sites for business continuity.

• Snapshot/clone capabilities for operational recovery and test/dev workloads.

7. Existing IT infrastructure / hybrid environments:

• Compute/Virtualisation: VMware vSphere & Physical Servers

• VNA, PACS, EMR, and departmental systems. Backup Applications

• Networking: 10/25/100 GbE for NFS/SMB/Object, 16/32Gb FC/iSCSI for block

• Cloud: Hybrid integration with Azure and AWS

• Security/Compliance: Data encryption, HIPAA-equivalent/IS18 Maturity level 3, audit logging, immutability

8. Various requirements around performance, protocols and use cases:

• File (SMB/NFS): ~40% (primarily PACS image data, department shares, research data).

• Object (S3-compatible): ~30% (cloud integration, application/backup archiving, analytics pipelines).

• Block (iSCSI/VM datastores): ~30% (VMware datastores, application databases, and clinical workloads requiring low latency).

• VNA/PACS: Must deliver equal or better performance than the current Dell EMC Isilon H400 platform, with low latency and high IOPS suitable for clinical image retrieval, database workloads, and modality integrations.

• NAS/File: Must deliver performance equal to or greater than the Dell EMC Isilon H400 platform, supporting mixed enterprise workloads (department shares, research data) with consistent throughput and responsiveness.

• Backup: Must provide throughput and ingest performance at or above the Dell EMC Isilon A200 platform, optimised for sequential writes and large-scale backup/recovery operations.

Question:
• Does GCHHS have a preference for a CAPEX, lease or as-a-service consumption model?

• If the solution design does not include storing departmental data outside the departmental network, does MR08 and Response Schedule 13 need to be completed?

Answered on 27/Aug/2025 01:09 PM:


- CAPEX or staggered payment over 5 years with ownership retained, all costs inclusive will be considered.

- MR08 and Response Schedule 13 will need to be completed for all solution designs. Both the IS18 Scorecard and the Third-Party Cloud Security Questionnaire are used to evaluate and whilst they mix cloud and non-cloud items, together they evidence overall security posture and maturity. Include concise answers, cite supporting artefacts, and note any exceptions or compensating controls.

Question:
Can you confirm if the intent is to deploy a single converged Block and File array supporting all file protocols (SMB,NFS,S3) and Block (iSCSI\FC) or can respondents provide Block capacity separate to File capacity to ensure unstructured data growth isn’t limited

Answered on 27/Aug/2025 01:11 PM:


A converged platform that delivers all protocols within a single array will be considered, provided it can scale to performance and capacity growth (particularly unstructured file/object).

Alternatively, vendors may propose separate Block and File/Object platforms where this provides a more optimal outcome in terms of scalability, performance, cost, or operational simplicity.

Example Use Case – PACS Storage

PACS requires access to large local volumes for image caching. NFS exports are generally not recommended for this workload. Instead, a local disk on the virtual server is preferred. In situations where local vSAN capacity is insufficient, the requirement would be met through an iSCSI or FC datastores.

An NFS datastore could be considered; however, IOPS and latency may be a concern, and this approach may not deliver consistent performance for PACS image retrieval.

Question:
Good morning. Please find below questions for consideration.

1 What applications are writing to the NAS?

2 Are there any bandwidth requirements for VNA, NAS or Backup Archive data?

3 Section 1.7 of “SECTION A – GENERAL INFORMATION AND PARTICULARS” states that 2 petabyte usable storage is required containing VNA, NAS, and Backup Archive. The following questions are related to ensuring that effective storage is sized appropriately for this requirement: -

4 Could an approximate percentage split be provided for each type of workload (VNA, NAS, and Backup Archive)?

5 Could an estimate of uncompressible data stored on NAS be provided e.g. images, encrypted data, compressed data?

6 Does the VNA store DICOM images using the DICOM Encapsulated Format or does it provide further lossless compression?

7 What front end connectivity is required to connect to the GCH networks in each location e.g. 100Gb/40Gb Ethernet or 25Gb/10Gb Ethernet for NAS, 100Gb/40Gb Ethernet or 25Gb/10Gb Ethernet for iSCSI, 16Gb/32Gb/64Gb FC for FCP?

8 What network bandwidth is available for replication between sites e.g. GCUH and ROBH, GCUH and Internet, ROBH and Internet?



9 What is the network round trip time (RTT) between GCUH and ROBH? This will impact the proposed method of replication.

Answered on 01/Sep/2025 12:32 PM:


1. Various medical imaging systems, research systems, department shares, backups, cross-site replication etc.

2. VNA/PACS: Must deliver equal or better performance than the current Dell Isilon H400 platform, with low latency and high IOPS suitable for clinical image retrieval, database workloads, and modality integrations. NAS/File: Must deliver performance equal to or greater than the Dell Isilon H400 platform, supporting mixed enterprise workloads (department shares, research data) with consistent throughput and responsiveness. Backup: Must provide throughput and ingest performance at or above the Dell Isilon A200 platform, optimised for sequential writes and large-scale backup/recovery operations.

3. The following responses are provided:-

4. File (SMB/NFS): ~40% (primarily PACS image data, department shares, research data). Object (S3-compatible): ~30% (cloud integration, application/backup archiving, analytics pipelines). Block (iSCSI/VM datastores): ~30% (VMware datastores, application databases, and clinical workloads requiring low latency).

5. Our current/future growth should be taken into consideration via end state sizing of 2 petabyte including anticipated storage replication from Coomera Hospital with a 5-year baseline and +2-year additional growth headroom. We currently run de-duplication on VNA/NAS shares. Backup shares are encrypted and not de-duplicated.

6. DICOM Encapsulated Format

7. Current networking allows for 25/10 but future network growth capability is favoured. Switches may be required for FC/iSCSI if additional bandwidth is required.

Note: FC/iSCSI is currently not in use as we use a separate HCI for compute with storage built in. The reason its included is as per the below use case.

Example Use Case – PACS Storage Physical to Virtual. PACS requires access to large local volumes for image caching. NFS exports are generally not recommended for this workload. Instead, a local disk on the virtual server is preferred. In situations where local vSAN capacity is insufficient, the requirement would be met through an iSCSI or FC datastores.

As another option, an NFS datastore could be considered; however, IOPS and latency may be a concern, and this approach may not deliver consistent performance for PACS image retrieval.

8. 10G for replication between sites and anticipated 10G for Coomera.

9. Direct fibre between sites ~1-2ms

Question:
1. Please provide current performance metrics—such as IOPS and throughput—for the following:

a) File storage: Primary PACS image data, departmental shares, and research data

b) S3 storage: Analytics pipelines

c) Block storage: VMware environments, application databases (e.g., SQL, Oracle), and clinical workloads

2. Please elaborate on how S3 integration with cloud services is being used.

Answered on 03/Sep/2025 09:53 AM:


1. Performance metric responses:

a) Must deliver equal or better performance than the current Dell Isilon H400 platform, with low latency and high IOPS suitable for clinical image retrieval, database workloads, and modality integrations.

b) We currently have very limited pipelines so that information is not available. Any information from vendors on if/how they provide the service is acceptable.

c) Currently not using block storage for Vmware or Databases.

Example Use Case – PACS Storage Physical to Virtual.

PACS requires access to large local volumes for image caching. NFS exports are generally not recommended for this workload. Instead, a local disk on the virtual server is preferred. In situations where local vSAN capacity is insufficient, the requirement would be met through an iSCSI or FC datastores.

As another option, an NFS datastore could be considered; however, IOPS and latency may be a concern, and this approach may not deliver consistent performance for PACS image retrieval.

2. Data replication and cloud-based backups. We currently do this on a very limited scale but may change in the future.