Current State ESS Analysis.pdf

Enterprise Software Services (ESS) Current State Analysis

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 four areas:

1. The physical environment itself, the Medical Enterprise Test Innovation Center (METIC) 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 area includes the physical location, furnishings, electricity, heating and cooling, management of physical equipment, and physical testing layout.

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

3. Testing provides illustrations of use cases that describe how the testing is completed using the resources provided by ESS.

4. Software Development Lifecycle Tool Hosting explains the software development tool support provided to DHMS through ESS.

The purpose of this whitepaper is to describe the current state of each of the above.

Physical Environments ESS is comprised of two physical environments. One is a leased 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.

METIC Office Space The METIC 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 and Device Inventory

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 GENESIS1 testing (see Testing section below for more information on DoD Healthcare Management Systems Modernization (DHMSM) use cases).

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.

DHMS Data Center (DDC) The DDC is located in a third-party hosting facility. Inside the DDC are storage, compute, networking and security devices that provide secure storage and processing capabilities to support the ESS goals.

1 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.

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 pools2 the test teams use for installing software they are testing.

Government Furnished Equipment (GFE) GFE includes desks, chairs, tables, audio-visual equipment, kitchen furnishings (i.e., coffee machine), etc. These furnishings are owned and provided by DHMS who makes them available to support the METIC operations.

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 teams to install their specific software and complete their test cases.

2 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.

Figure 4. ESS Architecture Diagram

Compute and Storage Resources

The testing infrastructure is supported through a resource pool model that provides network, compute, and storage capabilities to program offices. 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 equipment used to provision resource pools (i.e., servers and networking and storage devices) is owned by DHMS, however, it is noted that many are aging toward end of life.

End User Computing Devices The program teams, DHMSM and JOMIS (referred to as the Program teams in this document) 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.

Physical Network 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

Testing Sample use cases representing each of the Program teams are illustrated below. The use cases illustrate the types of testing environments, platform services, and operational support provided by ESS.

JOMIS Use Cases JOMIS applications provide technology to support operational medicine services for our fighting force. 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.

JOMIS Modern Application Testing JOMIS’ modern client applications are hosted on both physical devices located at the METIC and in an Amazon Web Services (AWS) cloud environment.

The ESS environment supports the integration and deployment of product deliveries from JOMIS’ prime mission vendors across both the .com and .mil networks. The JOMIS Modern Product Pipeline (JMPP) ensures the efficient validation, configuration, and distribution of JOMIS’ modern products.

Software for JOMIS product testing is loaded into a GITHUB environment by the various program vendors who develop and configure the software. The Program test teams provision their testing software from the GITHUB instance. A project is underway to deprecate the ESS instance of GITHUB and move the services to the DHA instance.

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.

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

Developmental Test and Evaluation (DT&E) Team

• JIRA

• Zephyr

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

CCB • SDLCNext

5 Package and deliver the new build by inserting it into the Nexus tool, which sends it to JMPP

BATDOK-J Vendor

• Nexus, JMPP

6 Pull build from JMPP and install on an endpoint where DT&E can install the build.

JOMIS Platform Services Lead

DT&E System Administrator Team

• JMPP

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

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.

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

Table 2. JOMIS Legacy Testing Use Case Example

Step Activity Who Does It Tools Used

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

DHMSM Use Cases

The scope of DHMSM testing includes validating patches, software updates and product improvements for MHS GENESIS prior to updating the technology deployed throughout the miliary 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, various staging environments for testing, 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 MSH GENESIS testing use case.

Table 3. Sample DHMSM Test Use Case Using FFGAL

Step Activity Who Does It Tools Used

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 a

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

Software Development Lifecycle (SDLC) Tool Hosting SDLCNext is an enterprise tool that consists of a Jira instance and several integrated plug-ins. It is hosted in DHA’s Amazon Web Services (AWS) environment using the Datacenter version of Jira. While DHA provides the hosting services for SDLCNext, ESS supports the production application instance for DHMS by performing regular patching and updates to ensure its security, stability, and performance.

In addition to the above, ESS services support a second Jira instance that is hosted in the TI.mil network. There is a desire to merge the two JIRA instances to streamline test data reporting.

Software Development Lifecycle (SDLC) Tool Hosting