Current State Analysis.pdf

Enterprise Software Services (ESS) Current State Analysis Dated: April 2026

The purpose of this whitepaper is to detail the existing PEO DHMS operational landscape to assist offerors in understanding the baseline size and scope of current services. This document provides a factual snapshot of the current environment and is provided for information purposes only. It is not intended to be prescriptive or restrictive.

In January and February 2026, a study was conducted to understand the services and capabilities of the ESS environment. To complete the analysis, the Defense Healthcare Management Systems (DHMS) engineering leaders visited the testing site to understand the physical layout and how the testers use the devices and equipment, reviewed technical diagrams, studied test use cases, and gathered inventories of the equipment used across the ESS environment.

Based on the above research, the services and capabilities have been divided into six sections:

• Section 1: The physical environment itself, the Medical Enterprise Test Innovation Center (METIC)1 is the physical testing location designed for employees and vendors (either virtually or in person) to manage and run tests to support DHMS health care technology. The scope of this includes the physical location, furnishings, electricity, heating and cooling, management of physical equipment, and physical testing layout.

• Section 2: The computer infrastructure includes network connectivity and configuration, compute resources, storage, specific medical devices used for testing, laptops, mobile devices and security services.

• Section 3: Testing has three sections. The first describes the Developmental Test and Evaluation (DT&E) services in scope. The second provides illustrations of use cases that describe how the testing is completed using the resources provided by ESS. The third gives more details on test execution.

• Section 4: Enterprise Tools covers SDLCNext and the additional managed software and platforms operated by ESS for the supported programs.

1The METIC is located at 14432 Albemarle Point Pl, Suite 205, Chantilly, VA 20151

• Section 5: Application Support Scope describes the broader application portfolio that ESS supports operationally, including enterprise collaboration tools and program-owned clinical applications.

• Section 6: In-flight Initiatives describes the active modernization and transition initiatives affecting the supported infrastructure, applications, and tooling during and beyond the recompete window.

1. Physical Environments ESS is comprised of two physical environments. One is an industrial office space configured and built specifically to support high scale testing (referred to as the METIC in this document). The second is a hosted environment in the DHMS Data Center (DDC) where ESS leases space to host computing equipment and provide security services.

Hardware in use in ESS is owned by DHMS. Additional hardware documentation provided in response to the Request for Information (RFI) requests is available with this package and includes:

• ESS Hardware Inventory (Excel) file

• Three diagrams: DDC Rack Layout.mil; DDC Rack Layout for .and .COM and METIC

LAN Room with Server names

1.1 METIC Office Space

The METIC, located at 14432 Albemarle Point Pl, Suite 205, Chantilly, VA 20151, contains 16,361 square feet. Approximately 48% is configurable lab space. The lab space is configured to accommodate testing events and is equipped with the appropriate heating, cooling, and electrical wiring to properly support the equipment. The remaining 52% accommodates nine offices, a kitchen, two conference rooms (20 person and 8 person) and touchdown workspaces for up to 30 support personnel. The large conference room includes audio-visual capability and videoconferencing for meetings and whiteboards used for technical discussions. A small percentage of the space hosts a reception area with a badge-only door behind it that is used to access the facility.

The average number of people using the facility for testing is 30 per day, while at peak test events, the number can increase to 75 testers per day onsite. In total, there are 184 active users of the TI.com environment and 308 active users of the TI.mil environment (includes development vendors) who can participate on site or through remote connections.

Figure 1 shows the METIC facility floor plan as described above.

Figure 1. METIC Floorplan

Figure 2 shows the METIC configuration for Joint Operational Medicine Information Systems (JOMIS) testing (see Testing section below for more information on JOMIS use cases).

Figure 2. JOMIS Lab Configuration

Note: OMGAL refers to the test operational set up maintained for JOMIS testing as shown in Figure 2.

Figure 3 below shows the physical layout and inventory for MHS GENESIS2 testing (see Testing section below for more information on DoD Healthcare Management Systems Modernization (DHMSM) use cases).

2 MHS Genesis is the Electronic Health Record software configured for use in Department of Defense medical facilities. DHMSM is the program within DHMS that manages MHS Genesis.

Figure 3. DHMSM Lab Configuration and Device Inventory Note: FMGAL refers to the test operational set up maintained by DHMSM as shown in Figure 3.

Operating the METIC facility presently involves a range of supporting services, including custodial and cleaning, physical security and reception, badging and access control, mail and shipping/receiving for equipment, HVAC maintenance, utilities, telecommunications and network circuits, audio-visual and conference room support, and routine maintenance and consumables for government-furnished equipment within the facility.

1.2 DHMS Data Center (DDC)

The DDC is located in a third-party hosting facility, the Equinix facility at 21721 Filigree Ct, Ashburn, VA 20147. Inside the DDC are storage, compute, networking and security devices that provide secure storage and processing capabilities to support the ESS goals.

The DDC infrastructure includes a virtual machine environment, test automation tools, and a management layer integrated with cyber tools. DHMS owns the hardware hosted in the environment and provides the software solutions. ESS manages and maintains the hardware and software required for hosting the ESS testing infrastructure, including providing the virtual machines and resource pools the test teams use for installing software they are testing.

1.3 Government Furnished Equipment (GFE)

Government-Furnished Equipment (GFE) at METIC encompasses all movable property within the facility (i.e., property not affixed to or part of the facility structure). GFE includes furniture (desks, chairs, tables, shelving), appliances (refrigerators, coffee machines, and similar), raised floor tiles, audio-visual equipment, lab equipment, IT hardware (enumerated in the Hardware Inventory attachment), network cabling, storage cabinets, whiteboards, and similar fit-out items.

1.4 Accreditation Status

The METIC and DDC facilities currently hold separate physical security accreditations specific to their present locations. Physical security accreditation is distinct from the ATO process; ATOs covering the IT systems and platforms operated within ESS are described in Section 2.5. Network accreditations for the TI.com, TI.mil, and DHA boundary networks are not facility-specific. No facility-level IL5 or FedRAMP designations apply to either site.

2. Computer Infrastructure The ESS Architecture Diagram, Figure 4 below, shows the hosting services provided by ESS and illustrates how the computing services provide infrastructure, security, applications, and virtual machines that enable the Program teams3 to install their specific software and complete their test cases.

A resource pool is a centralized, shared collection of computing resources -- such as Central Processing Units (CPU), Random Access Memory (RAM), storage, or network capacity -- that is dynamically allocated to various virtual machines, applications, or projects on demand. Resource pools are the mechanism for booking and delivering CPU, RAM and storage packages to the test teams.

3 Program teams refers to DHMSM, JOMIS and EIDS, the organizations responsible for delivering the customer solutions.

Figure 4. ESS Architecture Diagram

2.1 Compute and Storage Resources

The testing infrastructure is supported through a resource pool model that provides network, compute, and storage capabilities to Program teams. These resource pools (see definition in footnote 2) are accessed through Virtual Machines (VMs) that ESS services configures to meet specific program testing needs. At present there are 20 resource pools in use in the .com environment and 14 in use in the .mil environment. The average TI.com compute utilization is 15.3% (total compute available is ~2,600,000 MHz) and the average TI.mil compute utilization is 12.4% (total compute available is ~1,250,000 MHz). TI.com average storage utilization is 38.2% (total storage available is ~470 TiB) and TI.mil average storage utilization is 18.7% (total storage available is ~425 TiB).

The equipment used to provision resource pools (i.e., servers and networking and storage devices) is owned by DHMS. A complete hardware inventory for both the METIC and the DDC is provided as an attachment, enumerating manufacturer, asset description, sub-type, quantity, and location for each item. Lifecycle posture is described in Section 2.9.

The ESS environment supports approximately 2,400 virtual machines across two virtualization environments, designated TI.com and TI.mil. The TI.com environment hosts approximately 70 percent of the total VM count; TI.mil hosts the remainder. A third VDI-specific vCenter exists but is currently offline.

The two environments share a converged physical infrastructure rather than running on physically separated host pools. Individual hypervisor hosts within the TI.com environment routinely serve workloads from both the TI.com and TI.mil VM populations, and shared networks carry traffic from both. Workload separation between the two environments is logical rather than physical.

Recent utilization metrics indicate that approximately one-third of the total VM inventory is powered off but retained. Of the active, powered-on VMs, a portion operate at near-zero CPU utilization, resulting in approximately half of the aggregate VM inventory showing minimal active operational use. Additionally, current utilization data indicates that some active VMs are configured with capacity exceeding their actual workload requirements, while storage capacity is occupied by long-retained snapshots and thin-provisioning overhead.

The current VM inventory spans two governance layers. Core ESS infrastructure VMs are managed under the ESS infrastructure project's authority. Program-supported VMs, including but not limited to those associated with DHMSM, JOMIS, EIDS, and FEHRM-managed workloads, are managed under their respective program's authority and require program engagement for any disposition.

A current full enumeration of VM inventory by environment, power state, host assignment, network domain, and supported program will be made available to the awarded partner during contract transition.

Testing is conducted with on-prem resources within the ESS boundary and interfaces with test environments hosted by the individual programs. The on-premises percentages reflect resources within the ESS boundary. The cloud percentages reflect test environments hosted by the individual programs and their vendors; ESS does not operate cloud environments used by the programs. Below are the testing location percentages by program:

• DHMSM: 84% cloud and 16% on prem

• JOMIS: 85% cloud and 15% on prem

• EIDS: 100% cloud

Note that the above percentages reflect resource usage within the ESS boundary and do not include information for test environments hosted by the individual programs or prime mission vendors.

2.2 End User Computing Devices

DHMSM and JOMIS are responsible for providing and maintaining end-user devices specific for their test case execution needs. Laptops and other end-user devices required for testing are stored on site. Shipping and receiving are also available to assist the Program teams with sending and receiving equipment needed to support testing.

2.3 Network Architecture

Three networks are used to complete testing in the METIC - TI.com, TI.mil and Defense Health Agency (DHA). The DDC hosts the backend infrastructure for all three networks, and ESS Services enable wireless network support within the METIC for connectivity to all three networks.

• TI.com is a development network designed with a low barrier to entry, allowing development teams without DoD ID cards (CACs) to access and work within the environment.

• TI.mil is a production-equivalent test environment that mirrors operational conditions to validate systems before deployment.

• The DHA network provides the boundary solutions to secure, protect, and provide the virtual desktop infrastructure for remotely accessing the test infrastructure.

The Physical Network Diagram, Figure 5 below, illustrates the network connections and facilities in use for ESS.

Figure 5. Network Connections and Facilities

The networks above are supported by the following external connectivity:

• A dedicated fiber connection between the METIC and the DDC, currently provisioned at approximately 10 Gbps.

• Medical Community of Interest (MedCOI) connectivity terminates at the DDC and is handed off to the ESS environment from that point. MedCOI connectivity is maintained in coordination with the DHA accreditation.

• Internet circuits at both the METIC and the DDC. These circuits are part of the established service baseline.

• No wide-area peering arrangements or VPN tunnels with prime mission vendors are in place.

• The ESS environment consumes DHA enterprise services accessed through the MedCOI connection. The specific set of services and their operational integrations reflect the current state.

The network environment is predominantly virtual. Approximately 95 percent of network work involves virtual network infrastructure, including software-defined networking, virtual switches and VLANs, virtual firewalls, load balancers, DNS, DHCP, and IP address management. Approximately 0.3 percent of network work involves physical cable infrastructure such as cable drops, patch panels, and physical port assignments.

Network administration within DCOPS-managed DHA cloud environments, including for SDLCNext, is outside ESS scope.

Physical network equipment including datacenter switching, load balancers, and perimeter security devices forms part of the hardware lifecycle posture described in Section 2.9.

Network operational tasks including DNS, DHCP, and IP allocation are partially automated through internally developed tooling.

A current full enumeration of network architecture, addressing structures, routing configurations, network device inventories, and active network changes will be made available to the awarded partner during contract transition.

2.4 Operational Support Service Volumes

The operational support workload for the ESS environment is captured through an IT service management queue covering the testing infrastructure, including infrastructure support for SDLCNext. A separate JIRA project used for development and project work tracking does not function as an incident queue and is not reflected in these metrics.

The table below summarizes monthly volumes across three views: the 36-month historical baseline prior to SDLCNext entering production operations, the current 12-month ESS standard workload (excluding SDLCNext), and the current 12-month SDLCNext infrastructure support load. The Current Total column is the sum of the two current-period workloads.

Volume Category

Historical Baseline (Apr 2022 - Mar 2025)

Current ESS Standard (May 2025 - Apr 2026)

Current SDLCNext (May 2025 - Apr 2026)

Current Total

Service Requests

Avg ~277/month Range 198-448

Avg 219/month Range 170-306

Avg 52/month Range 37-72

Avg ~270/month

Changes Avg ~8/month Range 3-20

Avg 12/month Range 4-18

-- Avg 12/month Range 4-18

Incidents Avg ~8/month Range 1-17

Avg 2/month Range 0-6

Avg 2/month Range 0-5

Avg 4/month Range 0-6

SDLCNext infrastructure support is additive to the ESS standard operational workload; it does not replace or substitute existing ESS support services. Changes are not routed through the SDLCNext request portal during this period.

Incident priority assignments over the available record set (n=398) distribute as: highest priority (analogous to Sev 1), 11 percent; high priority (analogous to Sev 2), 35 percent;

medium and low priority (analogous to Sev 3 and 4), 53 percent. Time-to-resolution data is not currently maintained in a form that supports reliable cross-period reporting.

Work composition across the portfolio reflects the operational character of the environment: approximately 50 percent routine operations (recurring maintenance, scheduled work, predictable service requests); approximately 14 percent access and permissions management; approximately 15 percent software and application support;

approximately 11 percent testing and quality assurance support; with the remainder distributed across infrastructure management, documentation, planning, training, security and compliance, and specialty work.

Within the ESS infrastructure project specifically, work composition skews toward mandated security compliance work including continuous vulnerability remediation (ACAS-driven), STIG compliance, and POA&M tracking. These compliance categories represent a substantial share of ESS work.

In aggregate across the portfolio, approximately 90 percent of tickets carry priority equivalent to Sev 3 or Sev 4; the remaining 10 percent carry Sev 1 or Sev 2. Work characteristics vary by program cycle; periods of intensive testing for supported programs may produce sustained increased tempo.

A current full enumeration of tempo data, including category-level volumes, work-pattern classification, ESS-specific composition, and historical trends, will be made available to the awarded partner during contract transition.

2.5 Authorizations to Operate (ATO) Package Context

The ESS environment's IT systems hold or are pursuing ATO packages at varying lifecycle stages. Physical security accreditations for the METIC and DDC facilities (described in Section 1.4) are separate from the ATO process and are not included in this summary.

The following ATO packages apply to the ESS environment:

• ESS testing infrastructure IT system (TI overall): currently authorized; in an active accreditation maintenance cycle at the time of this analysis.

• SDLCNext platform: currently authorized under an ATO with Conditions (ATO-C);

remediation activity for documented conditions is in progress at the time of this analysis.

• JIRA instance hosted on the TI.mil network: currently operates under a provisional ATO; the net-new first authorization is in progress and may or may not be complete at contract transition.

• CAMEO (systems engineering modeling tool, being deployed to the DHA AWS environment at end state): separate authorization activity in progress; the resulting ATO package may or may not be complete at contract transition.

ATOs that are authorized remain in force across contract transitions, and a successor contractor assumes management of each package in the state it is in at transition.

2.8 Asset Lifecycle Management Operations

All hardware, software, AWS cloud hosting, and software licenses supporting the ESS environment are acquired through DHA Asset Lifecycle Management. Procurement is coordinated by the PEO DHMS Asset Lifecycle Management team, with the partner providing operational support throughout the lifecycle from requirement identification through procurement and disposition. PEO DHMS provides funding to DHA for procurement execution.

The operational workflow proceeds as follows: the partner identifies a need (typically driven by approaching end-of-life of an asset, license renewal date, or capacity demand);

the partner and the PEO ALM team conduct back-and-forth validation to confirm need, right-sizing, and technical specifications; the PEO ALM team submits the validated procurement action to DHA; and DHA executes the procurement with PEO DHMS funding.

Coordination between the partner and the PEO ALM lead occurs through recurring meetings held one to two times per month, supplemented by ad-hoc coordination on specific procurement actions as they arise. Procurement cadence is not driven by fixed refresh cycles but by end-of-life and renewal triggers identified through the partner's lifecycle tracking.

The partner maintains inventory and lifecycle records for all government-procured assets supporting ESS. Inventory records include procurement dates, asset age, configuration, support status, third-party support availability, and lifecycle status. The volume baseline of tracked assets is reflected in the inventory attachments.

The PEO DHMS Asset Lifecycle Management Standard Operating Procedure is provided as an attachment. The partner is expected to support the same procurement workflow described above using its own tracking methodology and tooling. On-demand information delivery to the Government is the operational expectation; the partner is required to provide inventory and lifecycle information when requested without extended preparation delays.

2.9 Hardware Lifecycle Posture

The ESS environment is supported by a physical infrastructure baseline that has not undergone a major hardware refresh cycle for several years. As of recent inventory analysis, a substantial majority of primary infrastructure hardware is past vendor End of Software Support or End of Life. The lifecycle gap spans the principal categories of compute, storage, datacenter switching, load balancing, and perimeter security infrastructure. The earliest End of Software Support dates affecting active production equipment are more than three years past as of the recompete; the latest dates affecting active production equipment have either recently passed or fall within the recompete window. Equipment in some inventory categories carries End of Life dates more than a decade past.

The current physical inventory is owned by DHMS. The primary lab facility (METIC) hosts approximately 1,600 assets, of which approximately one-third are categorized as spares. A separate hosting footprint at the DDC, located at Equinix Ashburn, supports approximately 200 assets, comprising the principal core servers, storage systems, and supporting network infrastructure.

An active storage migration is in progress, moving production workloads from the past-EOS storage platform to a vSAN-based storage platform running on the compute fleet. The migration is ongoing as of the recompete; until completion, it imposes operational constraints on infrastructure rationalization and host-removal activities.

A full hardware inventory enumerating platforms, models, lifecycle dates, and locations is provided as an attachment. The following additional information will be made available to the awarded contractor during contract transition: current vendor support and maintenance contracts and warranty status, configuration baselines, rack elevations, and license and entitlement details.

3. Testing Testing contains four sections. The first describes the Developmental Test and Evaluation (DT&E) services in scope. The second provides sample use cases representing each of the Program team's test activity. The use cases illustrate the types of testing environments, platform services, and operational support provided by ESS. The third section gives more details on test execution. The fourth describes the test methodology, measurement, and tools used across the ESS environment.

3.1 Developmental Test and Evaluation (DT&E) Services

The full scope of Developmental Test and Evaluation (DT&E) services for PEO DHMS products is currently delivered under the Workforce 3 contract. DT&E activities include test planning, test case development, and test automation development; execution of functional, integration, smoke, regression, and system integration testing; defect identification and management; Independent Verification and Validation (IV&V) of artifacts produced by prime mission vendors; and test reporting and data analysis derived from multiple data sources including system and tool logs. DT&E services currently support the JOMIS, DHMSM, and EIDS programs at the volumes and cadence reflected in Section 3.3 Test Execution. Defect counts and prime mission vendor escape rates over the most recent reporting period are provided in a separate attachment.

3.2 Sample Use Cases

The sections below provide sample uses cases for both JOMIS and DHMSM.

3.2.1 JOMIS Use Case

JOMIS applications provide technology to support operational medicine services for our warfighters. The products are in the process of being modernized.

The sections below describe use cases pertaining to modern products and legacy products. Legacy products will be deprecated as the new products are deployed.

3.2.1.1 JOMIS Modern Application Testing

JOMIS' modern client applications (BATDOK-J, OpMed CDP, and TBLD-M) are hosted on both physical devices located at the METIC. These applications are hosted on both physical devices and virtual machines. JOMIS MHSG-T support is also provided; several resource pools are allocated to JOMIS MHSG-T environments and consume a significant portion of capacity.

The ESS environment supports the integration and testing of product deliveries from JOMIS' prime mission vendors across both the .com and .mil networks. A custom-developed product delivery pipeline (the JOMIS Modernize Product Pipeline, or JMPP) performs scanning, configuration, and validation of JOMIS' modern client products. The pipeline is implemented in approximately 60,000 lines of Python and is maintained by the current contractor as part of operational scope. Architectural and functional detail beyond the disclosed scale is currently held by that contractor; full pipeline structure, dependencies, and sustainment baseline will be made available to the awarded partner during contract transition. JMPP validates, distributes, and configures applications in TI.com, TI.mil, and Cloud One. Approximately 98 percent of JMPP code is developed and maintained by the JOMIS Platform Services team using the ESS-provided tools.

Software for JOMIS product testing is loaded into a GitHub environment by the various prime mission vendors who develop and integrate the software. The Developmental Test and Evaluation team (DT&E) team provisions their testing software from the GitHub instance. Nexus is used as a repository to hold JOMIS software in both TI.com and TI.mil as part of JMPP. JOMIS elected not to use the DHA GitLab instance for JMPP due to its complexity; the current ESS-provided tools meet the requirement.

Table 1 below describes a sample modern JOMIS use case. The purpose of the table is to demonstrate how the various teams work with and within the ESS infrastructure. Note that the JOMIS team is responsible for installing their specific software and completing the tests. ESS provides the infrastructure and environment. The tables are meant to give examples of some test types supported by the ESS services. The tools listed in Step 2 are specific to the vendor development environment and are used prior to delivery of the product to JMPP. Test Infrastructure (TI) is also used for CM Share, supporting both modernized and legacy release management. Some tools listed in the tables, such as Android Studio and GitLab, are not provided by ESS; they are part of the program or vendor development environment.

Table 1. JOMIS Modernization Testing Use Case Example

Step Activity Who Does It Tools Used

1 Create user stories and acceptance criteria based on features the BATDOK-J vendor developed for the current sprint.

Value Team • JIRA

2 Develop and test the latest sprint capabilities and resolve open defects.

BATDOK-J Vendor

• Android Studio

• Click

• GitLab

• BATDOK

• Google Chat

• Goodlife Router

3 Create test plan and test cases based on user stories, acceptance criteria, and defects coming in for re-test.

DT&E Team

• JIRA

• Zephyr

4 Receive Change Control Board (CCB) Approval to install new build in the environment.

CCB • SDLCNext

Package and deliver the new build by inserting it into the Nexus tool, which sends it to the JOMIS product delivery pipeline.

BATDOK-J Vendor Nexus, JOMIS product delivery pipeline

Pull the build from the JOMIS product delivery pipeline and install on an endpoint where DT&E can install the build.

JOMIS Platform Services Lead

DT&E System Administrator Team

JOMIS product delivery pipeline

7 Install and configure build on Android Devices.

DT&E

• Android Devices

8 Execute Test Cases by staging clinical data in BATDOK-J, using scanner to scan QR code to transfer data to OpMED CDP.

DT&E • JIRA, Zephyr, Android Devices,

• OpMED CDP, Scanner

3.2.1.2 JOMIS Legacy Application Testing

JOMIS Legacy Applications are provisioned and tested in the METIC using the services provided by ESS. The METIC testing facility hosts a computer cabinet with ~ 50 laptops configured with supported operating system versions. This enables development, Quality Assurance (QA) testing, and developmental integration to successfully identify and mitigate defects for currently deployed products. Note that over the next several years, the legacy applications will be phased out. See the hardware inventory references in Section 1 above for more information on the devices used in testing.

Table 2 below illustrates a JOMIS legacy use case testing sequence.

Table 2. JOMIS Legacy Use Case Testing Sequence

1 Change request submitted for builds for legacy JOMIS products. This process follows the project schedule and uses a waterfall project management methodology.

Prime Mission Vendor

• SDLCNext

2 Create user stories for QA and integration testing.

Prime Mission Vendor

• Jira

3 Approve Change Request for the Development Environment.

CCB

• SDLCNext

4 Plan to conduct test: Plan and review content list of changes in the build to develop test plan, develop schedule, verify user stories, review script, review previous test events, and plan regression testing (as applicable).

DT&E

• SDLCNext

• TI JIRA

5 Develop approved build. Prime Mission Vendor

N/A

6 QA testing, Developmental Integration Testing in bespoke environment mimicking a wide variety of operating systems in operational environments.

Prime Mission Vendor

• JIRA

• Vendor environment

• Laptops in laptop cabinet

7 Deliver new build, test results, and technical documentation to JOMIS Configuration Management.

Prime Mission Vendor

• JIRA for test results and cases

• Shared drive accessible to both DT&E team and Integration Team (JOMIS SharePoint) for the build

8 Move build into .com environment (supported by ESS) and complete validation of the delivery package.

DT&E

• Win SCP file transfer

9 Install all applicable baselines and machines.

DT&E • None, manual

10 Smoke test, System Integration Test, draft and submit test report.

DT&E

• SDLCNext

• JIRA (for TMDS only)

• UFT (automation tool)

• Teams / SP

• Email

11 Approve report. Gov Test Lead

• Teams / SharePoint

• Email

• SDLCNext

12 Add test report to the change request. DT&E

• SDLCNext

3.2.2 DHMSM Use Case

The scope of DHMSM testing includes validating patches, software updates and product improvements for MHS GENESIS prior to updating the technology deployed throughout the military health system. MHS GENESIS is configured and managed by prime mission vendors.

The DHMSM Program team executes ongoing changes to software through uploaded patches four to ten times per month. These changes are tested at the METIC. The METIC facility provides the infrastructure to support the cross-team requirements, interdependent tasks between multiple vendors, and the MHS GENESIS requirement to integrate with a wide range of peripheral devices present at various medical treatment facilities. The METIC supports the physical co-location space for ~50 peripherals for medical device testing.

Table 3 below describes a sample MHS GENESIS testing use case.

Table 3. Sample DHMSM Test Use Case Using FFGAL

1 Submit change request to the Vendor Change Control Board (VCCB).

Prime Mission Vendor

SDLCNext

2 Approve or reject change request. VCCB SDLCNext

3 Submit change request to the PMO Federal Change Control Board (FCCB).

Prime Mission Vendor

SDLCNext

4 Approve or reject change request. FCCB SDLCNext

5 Complete change. Prime Mission Vendor

Prime Mission Vendor development environment

6 Load change into the test environment identified in the change request.

Prime Mission Vendor

Prime Mission Vendor test environment

7 Assess the level of effort required to test the change.

DT&E team, as well as, LPDH

N/A

8 Conduct testing on the build. Prime Mission Vendor

• SDLCNext

• Peripheral Devices in the FFGAL

9 Execute test plan and/or conduct IV&V of vendor's test artifacts. If defect found, write defect ticket.

DT&E

• SDLCNext

• Peripheral Devices in the FFGAL

10 Consult Gov test manager with findings and list of concurrence and non-concurrence.

DT&E SDLCNext

11 Request concurrence and non-concurrence in FCCB bi-weekly FCCB meeting until required changes are made and sign-off is approved.

FCCB SDLCNext

12 Deploy to production. Prime Mission Vendors

N/A

3.3 Test Execution

Prime mission vendors perform testing within their own development environments prior to delivery and execute Component Integration Testing (CIT) and System Integration Testing (SIT) within the ESS lab environment. Multiple prime mission vendors may co-locate during CIT and SIT activities when integration scenarios require it. DT&E (as described in Section 3.1) performs independent testing and IV&V of vendor deliveries within the ESS environment. The following bullets describe test cadence and scope for the testing conducted across the ESS environment.

• Currently, JOMIS follows a bi-weekly sprint cadence with approximately 25 sprints per year. Pre-deployment hotfixes in response to issues found during the test cycle are also tested. Historically, there have been approximately 75 test events, with 6 being major test events4 for JOMIS each year. In 2025, 27,231 test use cases were run on JOMIS products.

• Historically, DHMSM has had two major releases, 24 minor releases, and 60 small releases per year translating into 36 major test events. In 2025, 66,608 test use cases were run on DHMSM.

• Historically, EIDS has had approximately 40 releases per year. In 2025, there were 41 major test events for EIDs. In 2025, 33,359 test use cases were run on EIDS products.

In total, there are 23,256 test use cases in the DHMS test library -- 4% of which are currently automated. Historically, test data is refreshed twice per year using de-identified production data supplemented with structured clinical data sets to support test scenarios.

Defect counts and prime mission vendor escape rates by program for the most recent reporting period are provided as a separate attachment.

Test environment provisioning activity within the ESS environment follows a relatively stable pattern. Test environments generally remain provisioned for extended periods rather than being created and decommissioned per specific test events. Test activities across the programs are scheduled in advance, and the current lead time for new environment provisioning is two to four weeks, delivered through collaboration between ESS and the requesting program.

The test data described above consists of approximately 900 user records based on structured clinical data sets rather than synthetic data. Personally identifiable information and protected health information are anonymized prior to use in the ESS test environment.

4An event that validates the introduction of significant new functionality and features, large-scale changes and/or major enhancements that have a substantial impact to end users (potentially across a number products).

The refresh activity is conducted collaboratively across the program management offices, with DHMSM and JOMIS as the primary participants. PHI handling responsibilities are shared between ESS and the program management offices. The data is stored within the ESS test infrastructure.

3.4 Test Methodology, Measurement, and Tools

This section describes how testing is currently planned, prioritized, measured, and executed across the ESS environment, beyond the quantitative description in Section 3.3.

3.4.1 Risk-Based Test and Evaluation

DT&E activities apply risk-based test prioritization to determine the appropriate test depth and approach for each test event. Test prioritization decisions consider product criticality, change scope, integration impact, and historical defect patterns. The prioritization process selects test scenarios for manual execution with full coverage, scenarios for automated execution, and areas where the DT&E team recommends accepting prime mission vendor test results in lieu of duplicate testing. Risk-based T&E is applied across the test scope and informs test planning, resource allocation, and coverage decisions for each test event.

3.4.2 Performance Testing

Performance testing capability includes both standard performance scenarios and operationally-specific scenarios. Operationally-specific scenarios include low-communication and no-communication (lowcomm/nocomm) test scenarios, which simulate degraded or disconnected network conditions relevant to deployed military medical operations. Performance testing capacity and scenario inventory will be made available to the awarded partner during contract transition.

3.4.3 Current Test Measurements

Test activities are measured through the following indicators: defect detection effectiveness (defects identified during testing prior to release); defect escape rate (defects reaching production environments or operational test that should have been identified during DT&E); test cycle time (elapsed time between test scenario initiation and defect closure or scenario acceptance); Test Plan Depth (coverage and granularity of test scenarios planned per test event); and test coverage (percentage of in-scope requirements and components addressed by executed test scenarios). Current measurement values for the most recent reporting period are provided as a separate attachment. Time-to-resolution data is not currently maintained in a form that supports reliable cross-period reporting.

3.4.4 Test Automation Tools and Investment

The current test automation toolchain includes Unified Functional Testing (UFT), used for DHMSM testing in alignment with the prime mission vendor's testing toolchain, and UI Path, used for test automation across the ESS test scope. The test automation library represents substantial cumulative investment and includes hundreds of automated test cases. The existing automation library includes hundreds of test cases, covering approximately 4 percent of the 23,256-test-case DHMS test library described in Section 3.3 Test Execution.

4. Enterprise Tools The enterprise tools currently in scope for ESS include SDLCNext (described below); a second Jira instance hosted on the TI.mil network; and additional managed software and platforms operated by ESS and hosted across on-premise infrastructure and the DHA AWS environment. The additional managed software spans operating system and database platforms, security and endpoint protection, virtualization, software development and test tooling, systems engineering modeling, monitoring and observability, and backup and data protection. Specific tools, manufacturers, and license details are enumerated in the Software Inventory attachment. The consolidation of the TI.mil Jira instance into SDLCNext is targeted to streamline test data reporting, eliminate redundant tooling, and establish unified enterprise metrics.

SDLCNext is an enterprise platform consisting of an Atlassian Jira instance, an Atlassian Confluence instance, and integrated non-Atlassian plug-ins. The platform is hosted in DHA's Amazon Web Services (AWS) environment using the Datacenter version of Jira. The AWS infrastructure is operated by DHA Data Center Operations (DCOPS), consistent with DHA policy; PEO DHMS does not operate the AWS infrastructure directly. DCOPS provides a hardened operating system baseline. Platform deployment is currently automated through infrastructure-as-code tooling.

The full lifecycle of SDLCNext is currently managed across two contracts: platform-layer engineering and operations under the current ESS contract, and front-end operational management under the Workforce 3 contract. Effective at ESS Next contract start, both scopes are consolidated into ESS as a single accountable scope. ESS serves as the technical interface between PEO DHMS and DCOPS for platform management.

Consolidated SDLCNext scope under ESS Next includes:

• Platform-layer services: deployment, configuration, patching, updates, monitoring, cloud-based optimization for cost and performance, and ongoing operational management of the platform baseline.

• Front-end operational services: user account provisioning, lifecycle management, and tier 2 user support; project setup, workflow configuration, and custom field and screen scheme management; integration management for Jira, Confluence, and non-Atlassian plug-ins; reporting and dashboard configuration;

governance, standards enforcement, and change management for the platform;

release management for the Atlassian platform and integrated components;

license management of the platform baseline; and training, user enablement, and platform documentation.

SDLCNext currently has approximately 980 active users. SDLCNext operational support volumes (approximately 52 service requests per month) are reported in Section 2.4 alongside the broader ESS operational support workload.

The Section 2.4 SDLCNext column (approximately 52 service requests per month for the May 2025 - April 2026 window) reflects the SDLC Service Request issuetype within the ESS Environment ITSM queue, which captures the ESS-side execution of SDLCNext support work -- predominantly production-side account provisioning -- handled by the ESS contractor on behalf of the SDLCNext front-end. The Section 2.4 figure does not include the front-end operational queue (approximately 130 monthly tickets covering account intake, JIRA workflow and field configuration, Tier 1/2 user support, and incident response currently delivered under the Workforce 3 contract), front-end sprint and improvement work (approximately 30 to 40 monthly closures beyond the front-end queue), software license and asset management activity (approximately 14 monthly tickets), or CDRL deliverable production. Platform-layer infrastructure work (deployment, patching, monitoring, AWS administration) is performed through mechanisms not consistently reflected in JIRA ticket counts; the SDLCNext platform architecture and AWS deployment baseline (instance types, storage configuration, database topology) are described in the LCCE Methodology Reference Section 6 and may inform offeror estimation of platform-layer operational scope. At a representative point in time prior to transition, the SDLCNext front-end queue carries approximately 175 to 200 open work items across in-flight stories, test executions, and operational tickets, representing inherited work-in-progress at contract start. Service coverage hours and target service levels for SDLCNext operations are part of the offeror's proposed QASP commitments and evaluated under Section M.

A software inventory (ESS Software Inventory February 2026 - in Excel format) is available as an attachment.

Government Data Integration, Warehousing, and Reporting Capabilities The Government currently delivers data integration, warehousing, and reporting capabilities that support cross-program operational governance, program-office consumption, and the Process and Tools (P&T) front-end functions described elsewhere in this section. The capabilities consume from the SDLCNext production JIRA instance and the JIRA Testing Environment (JTE), warehouse operational data spanning approximately 87 program-aligned projects, and produce downstream reports and dashboards for the PEO DHMS programs (DHMSM, JOMIS, EIDS, and other supported programs).

The capability is implemented as a containerized Python application that consolidates issue, test, and traceability data from the production JIRA instances and the Zephyr test-management repository, through the REST interfaces of the source systems, into a PostgreSQL data warehouse. As of the current reporting period, the warehouse holds approximately 764,700 JIRA issues across 87 projects on two production instances, together with associated comments, change history, work logs, attachments, issue links, and sprint data, and a parallel body of Zephyr test plans, cases, runs, and execution results. The total managed dataset is approximately 5 gigabytes.

Synchronization is automated. Incremental updates run on an approximately ten-minute cadence using cursor-based delta extraction, with full sweeps used for initial population, recovery, and reconciliation. Integrity and reconciliation jobs run on recurring cadences to detect and remediate drift between the warehouse and the source systems, and observability components evaluate alert conditions and render operational dashboards.

Inbound change ingestion is supported through an authenticated webhook receiver. Test-management data from Zephyr is currently synchronized on a manual, full-refresh basis rather than on an automated schedule.

The warehouse currently provides a faithful, continuously synchronized consolidation of source-system data, the bronze layer in a medallion data architecture. Curated, conformed data products (the silver layer) and business-level analytics and reporting products (the gold layer) are planned and in early development. The awarded partner inherits the operational bronze layer together with this planned progression and is expected to continue developing the curated and analytics layers as part of the data integration, warehousing, and reporting scope.

Current-state constraints relevant to forward-looking scoping include a single-host deployment in which compute, scheduling, and the database run on one Linux host;

manual rather than scheduled refresh of the Zephyr test-management data; and a derived-views and analytics layer that is still maturing.

The capability handles data from Military Health System sources, including clinically relevant defect and support records. Source connectivity uses DoD public key infrastructure certificate trust and token-based authentication, with credentials managed outside the codebase. The software is maintained under a software-assurance posture aligned to NIST SP 800-218, including software bill-of-materials generation, software composition analysis, and static analysis.

5. In-flight Initiatives The ESS environment is subject to a number of in-flight modernization and transition initiatives that affect the supported infrastructure, applications, and tooling during and beyond the recompete window. The active storage migration to the vSAN-based platform is described in Section 2.9 (Hardware Lifecycle Posture).

A migration of source code repositories from Subversion to GitLab is active. Container adoption through Docker is expanding in scope and footprint.

The MHS GENESIS clinical system rollout, supporting the modernization of the legacy AHLTA electronic health record, is ongoing across the supported workloads.

Splunk is being expanded as the SIEM and log retention platform, with progressive transition of workloads from the legacy Nagios-based monitoring environment.

Internal automation framework adoption, including expansion of Ansible-based configuration management, is ongoing.

New systems are periodically introduced to the supported environment, including authorization activities through eMASS, integration with shared infrastructure, and operational acceptance. New system onboarding workload varies with program-driven introduction activity.

A current full enumeration of in-flight initiatives, including current status, projected completion timelines, dependencies, and supported program ownership, will be made available to the awarded partner during contract transition.

3.2.2 DHMSM Use Case