Atch 1_RFI_BATDOK FoS.docx

CUI [Remove if N/A]

Program Acquisition Executive, Medical Digital Solutions (PAE MDS) Joint Operational Medicine Information Systems (JOMIS) Program Management Office Battlefield Assisted Trauma Distributed Observation Kit (BATDOK) Family of Systems (FoS) Operations and Sustainment (O&S) Request for Information (RFI)

RFI Number: BATDOK001 Response Due: 19 November 2026 Date: 5 November 2026

A. Notice to Respondents This is a Request for Information (RFI) issued solely for information and planning purposes in accordance with Federal Acquisition Regulation (FAR) 15.201(e). It is not a Request for Proposal (RFP), Request for Quotation (RFQ), or Commercial Solutions Opening, and it is not a commitment by the Government to issue a solicitation or award a contract. The Government will not pay for information submitted or for any cost incurred in responding. Responses will not be returned, and the Government will not provide feedback or evaluations to individual respondents. Not responding to this RFI does not preclude participation in any future solicitation.

Respondents are responsible for appropriately marking proprietary information. The Government will protect properly marked information from disclosure and may share responses with Government support contractors bound by non-disclosure agreements. Do not submit classified information.

B. Purpose The Defense Health Agency (DHA), Program Acquisition Executive, Medical Digital Solutions (PAE MDS), Joint Operational Medicine Information Systems (JOMIS) Program Management Office (PMO), is issuing this RFI to conduct market research for the operations and sustainment (O&S) of the Battlefield Assisted Trauma Distributed Observation Kit (BATDOK) family of systems (FoS). The anticipated period of performance begins 1 October 2027 (Fiscal Year 2028).

The BATDOK FoS is comprised of BATDOK-J, an Android and iOS mobile application for point-of-injury (PoI) casualty documentation; BATDOK Link, a Windows operating system application plug-in that allows for the transfer of data from BATDOK-J into MHS GENESIS Theater (MHSG-T) or Operational Medicine Data Service (OMDS) via QR code; and BAT-TAK, a plug-in for the Android Team Awareness Kit (ATAK). The FoS is a mature capability, fielded and in operational use across the Military Services.

The purpose of this RFI is to:

· Identify potential sources, including small businesses, with demonstrated DoW experience developing, sustaining, and integrating tactical mobile applications on the Android and iOS operating systems, together with associated ATAK and Windows plug-ins;

· Obtain industry input on technical approaches, best practices, and innovations for achieving the outcomes described in the Draft Performance Work Statement (PWS) in Part II; and

· Inform the Government’s acquisition strategy, including contract vehicle, contract type, small business set-aside determination, and refinement of the requirement and its performance measures.

The Government seeks three outcomes: (1) a seamless transition of the fielded BATDOK FoS to the Contractor without disruption to users; (2) sustainment and enhancement of the FoS, including code maintenance, new integrations with DoW tactical applications, tactical radios, medical sensors, and electronic health record (EHR) systems, and operational resilience in disconnected, intermittent, and limited (DIL) environments in support of Large-Scale Combat Operations (LSCO); and (3) a consistent iOS and Android user experience that reduces training demand. The Draft PWS is performance-based: it states required outcomes and does not prescribe staffing, labor categories, or methods. Respondents are requested to describe the approach they would take to achieve those outcomes.

B.1 Capabilities of Interest The Government is particularly interested in respondents with demonstrated recent experience in the following areas. DoW mobile application experience is considered essential.

· DoW mobile application development and sustainment: Android and iOS applications fielded to DoW users on Government-managed or tactical end-user devices.

· ATAK plug-in development: development and sustainment of ATAK plug-ins and integration within the Team Awareness Kit (TAK) ecosystem, including compatibility across ATAK releases.

· Windows plug-in development: Windows-based applications or plug-ins that exchange data with mobile applications.

· Integration with other DoW applications: data exchange with DoW tactical, command and control, and medical applications.

· EHR interoperability: health data exchange using HL7 Version 2 messaging and HL7 Fast Healthcare Interoperability Resources (FHIR).

· Tactical radio integration: data transport over tactical radio and mesh networks in bandwidth-constrained and DIL environments.

· Medical sensor and device integration: wireless integration of vital-sign monitors and other medical sensors (e.g., Bluetooth and Bluetooth Low Energy).

· Development and test hardware: ability to procure, configure to DoW security baselines, maintain, account for, and refresh representative mobile devices (Samsung Galaxy Tab and Galaxy smartphones, iPhone, and iPad), Windows systems, and medical sensors.

· Tactical radio and operational network testing: demonstrated ability to test mobile applications over DoW tactical radios and operational networks, including access to radio equipment, test facilities, exercises, or network emulation.

· Mobile cybersecurity: support obtaining and maintaining DoW Authority to Operate (ATO) for mobile applications under the Risk Management Framework (RMF).

C. Information Requested Please organize your response to match the numbered items below. Where an item requests an approach, the Government values specific, evidence-based answers (relevant past performance, results achieved, and how that experience applies here) over general capability statements.

C.1 Company Information Please submit C.1 information using the included Excel Spreadsheet. Responses that do not provide information in the requested format may be left out of market research results.

· Company name, address, Unique Entity ID (UEI), CAGE code, and a primary point of contact (name, email, and phone).

· Business size and socioeconomic status under the anticipated North American Industry Classification System (NAICS) code 541511, Custom Computer Programming Services. If you believe a different NAICS code is more appropriate, explain why.

· Existing contract vehicles your company holds that could be used for this requirement (e.g., GSA Multiple Award Schedule, Government-wide Acquisition Contracts, DHA or other DoW IDIQs), with contract numbers.

· Facility clearance level, if any, and any anticipated teaming partners or subcontractors and their roles.

C.2 Relevant Experience Describe up to three efforts performed within the last five years that are most relevant to this requirement. For each, provide the customer, contract number, period of performance, approximate annual value, your role (prime or subcontractor), and the measurable results you delivered. For each Capability of Interest in Section B.1, state whether your company has performed that work as a prime contractor, as a subcontractor, or not at all, and identify which effort demonstrates it. Also describe any experience assuming responsibility for an existing Government-owned code base from another developer without disrupting fielded users.

C.3 Proposed Approach to the Desired Outcomes For each Desired Outcome in Part II, Section 3, describe how you would achieve it, the risks you anticipate, and how you would demonstrate to the Government that it is being achieved. At a minimum, address the following:

· Seamless transition of a fielded product (Outcome 3.1). How would you assume responsibility for the BATDOK FoS while fielded users continue to rely on it? What would you require from the Government and the current development team, how long would transition take, and what would you accomplish in the first 90 days?

· Development and test hardware (Outcome 3.1). Contractor currently provides all development and test hardware, and the Government does not own an inventory. How would you establish, by the end of transition, the devices and sensors needed for development and test (including Samsung Galaxy Tab and Galaxy smartphones, iPhone, iPad, Windows systems, and supported medical sensors)? Address sourcing and lead times, DoW security configuration, quantities, accountability, refresh as device models and operating systems change, and whether the hardware should be Contractor-owned or Government-owned.

· Tactical radio and operational network testing (Outcome 3.2). JOMIS does not have the capability to test with tactical radios or other DoW operational networks, and this is a known gap. Explain how you would test the BATDOK FoS over these radios and networks: which radios and networks you can test with today; whether you would use Contractor-owned equipment, Service or Government test facilities and exercises, industry partners, or network emulation; how you would obtain access to and approval for that equipment and those facilities; how you would reproduce degraded and contested conditions; and how you would make results repeatable from release to release. Identify any Government support you would need.

· Sustainment and enhancement (Outcome 3.2). How do you keep mobile applications and plug-ins current with Android, iOS, Windows, and ATAK releases while delivering new capability, and how do you prioritize maintenance against enhancements? How would you provide Tier 3 support, coordinate with the Service Tier 1 and JOMIS Tier 2 support teams, and keep the Software Installation Guide (SIG), System Administration Manual (SAM), and Software User Manual (SUM) current for a separate third-party training and delivery vendor? Describe your approach to offline first and DIL operation; data transport over tactical radios and device-to-device and zero-network methods; new integrations with ATAK and other DoW applications; medical sensor integration; and HL7 and FHIR interfaces to JOMIS and EHR systems. How would you participate in multi-vendor Contractor Integration Testing (CIT), maintain the ATO for mobile applications, and reduce the cost and cycle time of a release over the period of performance? JOMIS delivers in Program Increments of three 4-week sprints rolled up into capability blocks of approximately 28 weeks; describe how you would deliver within that cadence and provide real-time status through Government-provided tools.

· Consistent iOS and Android user experience (Outcome 3.3). How would you achieve and sustain functional and User Interface (UI) parity between the iOS and Android versions of BATDOK-J, and extend common design conventions to BATDOK Link and BAT-TAK? How would you use end-user feedback obtained and provided by the Government to validate designs, and how would you measure and reduce training time for users who rotate approximately every 90 days?

C.4 Measuring Success Propose three to five outcome-based performance measures, with acceptable quality levels, that best indicate whether the BATDOK FoS is being sustained and improved effectively (see the draft Performance Requirements Summary in Technical Exhibit 1). Explain how each would be measured, preferably from data already captured in delivery tools rather than through separate reports.

C.5 Staffing and Organization Describe the team you would field to achieve these outcomes: roles and skill mix, approximate size by contract year, work location (remote, on site, or hybrid), positions requiring security clearances, and how you would scale effort as priorities change. Identify the positions, if any, you recommend the Government designate as key personnel.

C.6 Business and Contracting Considerations

· Recommended contract type (e.g., firm-fixed-price per Program Increment or capability block, time-and-materials, or a hybrid) and the rationale for it.

· Recommended approach to acquiring and pricing development and test hardware (e.g., separate line item, other direct costs, or included in labor pricing), and the implications for ownership and property accountability.

· Feedback on the anticipated period of performance: a 12-month base period and four 12-month option periods.

· Data rights and licensing. The Government intends to own and receive all source code, build scripts, and documentation with unlimited rights. Identify any proprietary, commercial, or open-source components you would propose to use and their license terms.

· An optional, non-binding rough order of magnitude (ROM) cost by contract year, with key assumptions and cost drivers.

C.7 Feedback on the Draft PWS Identify any requirements in the Draft PWS that are unclear, that would limit competition, or that would add cost without adding value, and recommend alternatives. Identify any information the Government should provide in a future solicitation so that offerors can plan and price with confidence.

D. Response Instructions

· Format:

· C.1: Please utilize the format of the included Excel spreadsheet.

· C.2 - C.7:

· Microsoft Word or searchable PDF; 8.5 x 11-inch pages; 12-point font (10-point permitted in tables and figures); 1-inch margins.

· No more than 15 pages, excluding a cover page and a one-page executive summary. Marketing brochures are discouraged and do not substitute for a substantive response.

· Submission: By email to the Contracting Officer, Elizabeth Ruckwardt, elizabeth.m.ruckwardt.civ@health.mil, and the Contract Specialist, Rachael Bealer, rachael.n.bealer.civ@health.mil, no later than 1200 Eastern Time on 19 November 2026. Use the subject line “BATDOK FoS O&S RFI Response – [Company Name].”

· Questions: Submit questions by email to the contacts above by 12:00 Eastern Time on 12 November 2026. The Government may publish answers without identifying the source.

· Industry engagement: After reviewing responses, the Government may invite selected respondents to one-on-one virtual sessions to discuss their approach. Participation is voluntary and is not part of any source selection.

PART II - PERFORMANCE WORK STATEMENT

This Draft PWS excerpt is provided to inform responses to this RFI. It is provided solely for market research purposes. It is not a solicitation, does not constitute a commitment by the Government, and does not oblige the Government to issue a solicitation or award a contract. The Government may revise, remove, or add requirements.

Background Organization The Program Acquisition Executive, Medical Digital Solutions (PAE MDS), within the Defense Health Agency (DHA), delivers health information technology for the Department of War (DoW). Its portfolio includes the federal electronic health record (EHR), MHS GENESIS, shared with the Department of Veterans Affairs (VA) and the United States Coast Guard (USCG), and the operational medicine (OpMed) systems used by deployed and deployable forces.

Within PAE MDS, the JOMIS PMO delivers the software that supports care across the continuum of operational medicine: from the point-of-injury (PoI), through enroute care (ERC) and theater hospitalization, to the EHR. The JOMIS ecosystem includes the BATDOK FoS at the PoI; OpMed Care Delivery Platform (CDP) Role 1, Role 2, Role 3 and ERC; Theater Blood-Mobile (TBLD-M) blood management; Medical Information Exchange (MedIX) data layer and MedHub visualization tools on NIPR and SIPR. Additionally, TRANSCOM Regulating and Command & Control Evacuation System (TRAC2ES) provides patient movement and Joint Medical Planning Tool (JMPT)/Medical Planner’s Toolkit (MPTk) is our joint medical planning toolset under modernization. These products are designed to work together so that a casualty’s record follows the casualty.

Current State BATDOK originated as an Air Force Research Laboratory (AFRL) effort to provide medics a digital alternative to paper casualty documentation. It has since matured into a joint family of systems managed by the JOMIS PMO and fielded across the Military Services. The BATDOK FoS consists of:

· BATDOK-J: an Android and iOS mobile application for POI documentation. BATDOK-J replaces paper Tactical Combat Casualty Care (TCCC) cards with electronic documentation, enabling medics to electronically document injuries and treatments, wirelessly monitor vital signs from supported medical sensors across multiple patients, and transfer care electronically to the next echelon.

· BATDOK Link: a Windows operating system application plug-in that extends BATDOK capability to Windows-based systems (MHS GENESIS Theater, OMDS).

· BAT-TAK: an Android Team Awareness Kit (ATAK) plug-in that integrates BATDOK capability with the TAK used by tactical forces.

· Records created in the BATDOK FoS flow to MedIX, MedHub and MHS GENESIS so that PoI care becomes part of the patient’s longitudinal health record.

The program delivers on a disciplined agile cadence. Work is planned in Program Increments (PIs) of three 4-week sprints, released in ecosystem-wide capability blocks of approximately 28 weeks, and verified through multi-vendor CIT in the PEO METIC test lab and interoperability testing with the Joint Interoperability Test Command (JITC).

Each Service fields the BATDOK FoS on its own end-user devices using its own deployment and device-management methods. The PMO does not push software to those devices or connect to them remotely; Tier 1 support is provided by the Military Services, Tier 2 support is provided by a separate JOMIS support vendor team, and end-user training and software delivery is provided by a separate third-party vendor. Accurate, current documentation and responsive Tier 3 engineering support from the development contractor are essential to successful fielding.

Today, AFRL provides all development and test hardware for the BATDOK FoS, including mobile devices and medical sensors. The Government does not currently own a development and test hardware inventory; the incoming contractor must therefore establish one so that development and testing continue without interruption. Similarly, JOMIS does not have the means to test the BATDOK FoS with tactical radios or other DoW operational networks. This is a recognized gap that the Government wants the Contractor to address possible solutions for.

The BATDOK FoS is a mature, fielded capability that is valued by its users. This requirement is intended to sustain that performance and build upon it.

Future State The operating environment the BATDOK FoS must support is ever-changing. LSCO planning assumes contested and degraded communications, emissions control, high casualty volumes, and extended evacuation timelines that require more prolonged care at the PoI. Under these conditions, medics cannot rely on network connectivity, and data that is lost or delayed affects care downstream. The Government’s objectives for the period of performance are:

· DIL-ready by design. The BATDOK FoS operates fully without a network, exchanges data device-to-device, over tactical radio networks, and through zero-network methods such as high-density QR codes and synchronizes with the ecosystem without data loss when connectivity returns.

· Integrated at the tactical edge. The BATDOK FoS operates with ATAK and other DoW tactical applications, transports data over tactical radios, and integrates with the medical sensors used at the PoI.

· Seamless across the health record. A casualty’s data moves from the PoI to the next echelon of care (OpMed CDP, MHSG-T, MedIX/MedHub and MHS GENESIS) through standards-based HL7 and FHIR interfaces, without re-entry and with a consistent user experience across JOMIS products.

· Lower cost to sustain. Modern software engineering, automation, and continuous ATO practices reduce the cost and cycle time of every release and the Government retains full ownership of the code, build tooling, and documentation.

· Continuous improvement. Changes are driven by end-user feedback gathered by the Government and by operational data, validated in Government-led evaluations in realistic settings, and delivered predictably on the ecosystem capability block cadence.

Purpose & Scope This is a non-personal services requirement for the operation and sustainment of the BATDOK FoS .

The purpose of this acquisition is to provide operations and sustainment of the BATDOK FoS, including continued enhancement, so that it remains reliable, secure, interoperable, and ready for operations in DIL environments, at a reduced total cost of ownership.

The scope includes BATDOK-J (Android and iOS), BATDOK Link (Windows plug-in), and BAT-TAK (ATAK plug-in), and everything needed to build, test, secure, and deliver them: source code and libraries; build and release tooling; interfaces to DoW tactical applications, tactical radios, medical sensors and devices, JOMIS systems, and EHR systems; test artifacts; cybersecurity and ATO documentation; Tier 3 technical support; and the SIG, SAM, and SUM for each component.

The scope also includes establishing, maintaining, and refreshing the development and test hardware needed to perform the work, including Samsung Galaxy Tab tablets and Samsung Galaxy smartphones, Apple iPhone and iPad devices, Windows Operating System hardware, and the medical sensors and devices supported by the BATDOK FoS. The Government does not currently own this hardware.

The scope also includes establishing the means to test the BATDOK FoS over tactical radios and other DoW operational networks, which JOMIS does not have today.

The following are outside the scope of this requirement: procurement of hardware for fielding to end users; development of ATAK core software or radio firmware; Tier 1 support, which is provided by the Military Services; Tier 2 support, which is provided by a separate JOMIS support vendor team, such as the DHA Global Service Center (GSC) model; end-user training and software delivery and installation on Service end-user devices, which are performed by a separate third-party vendor; and development of other JOMIS products, except for the BATDOK FoS side of shared interfaces and joint integration testing.

All end-user engagement, including requirements gathering, feedback, and usability evaluation, is conducted or facilitated by the Government.

Desired Outcomes The outcomes below describe the results the Government requires. Consistent with a performance-based approach, the Contractor will determine how best to achieve them, including staffing, tools, and methods, subject to Government standards and approval where noted. RFI respondents are asked to propose their approach to each outcome (Part I, Section C.3).

Seamless Transition of a Fielded Product Outcome: Responsibility for the fielded BATDOK FoS transfers to the Contractor with no degradation in service to the medics and units that rely on it.

The Contractor shall execute the Government-approved transition-in plan; establish a complete inventory of BATDOK FoS source code, dependencies, build environments, code-signing and distribution arrangements, test assets, and documentation; demonstrate that it can reproduce, build, test, and release the current baseline of BATDOK-J, BATDOK Link, and BAT-TAK from Government repositories; and assume responsibility for defect resolution, security remediation, and Tier 3 support of the fielded baseline by the end of the transition-in period.

Development and test hardware. Because AFRL currently provides all development and test hardware and the Government does not hold an inventory, the Contractor shall establish, by the end of the transition-in period, a development and test hardware inventory representative of the fielded configuration, including Samsung Galaxy Tab tablets and Samsung Galaxy smartphones, Apple iPhone and iPad devices, Windows systems, and the medical sensors and devices supported by the BATDOK FoS, configured to applicable DoW security baselines. The Contractor shall maintain, account for, and refresh this inventory throughout the period of performance as operating systems, device models, and supported sensors change, and shall provide the Government a current inventory. The Contractor shall coordinate transition activities with the Government, the current development team, and Service fielding organizations so that releases in progress, open defects, and planned integration testing continue without interruption. The Contractor will not interact directly with end users; transition coordination with Services and users is conducted through the Government.

Sustainment and Enhancement: Code Maintenance, Tier 3 Support, New Integrations, and Sensors Outcome: The BATDOK FoS remains stable, secure, and current in the field while gaining new capability, integrations, and sensor support on a predictable cadence, at a decreasing cost per release.

Code maintenance. The Contractor shall provide support to sustain BATDOK-J on the Android and iOS operating systems, BATDOK Link on the Windows operating system, and BAT-TAK within ATAK. This includes correcting faults; improving performance and reliability; adapting each component to new operating system, ATAK, and device versions and third-party libraries; and remediating security vulnerabilities within the timelines required by DoW (Department of Defense) policy and the conditions of the ATO. The Contractor should propose how to manage the velocity of sprints to allocate resources to deliver not just software maintenance, but continuous improvements based on end user feedback and technology changes that would improve documentation at PoI.

Tier 3 support and documentation. The Contractor shall provide Tier 3 technical support for all BATDOK FoS components: engineering-level analysis and resolution of issues escalated through the Government’s tiered support model, in which Tier 1 support is provided by the Military Services and Tier 2 support by a separate JOMIS support vendor team such as the DHA GSC model), including root-cause analysis, workarounds, and corrective releases. The Contractor shall develop and maintain, and deliver updated with each release, the SIG, SAM, and SUM for each component, written to support the Government’s third-party training and delivery vendor.

Enhancements. The Contractor shall deliver Government-prioritized enhancements within the performance envelope defined by the Government, including capabilities for operations in disconnected, intermittent, and limited (DIL) environments: offline-first operation; device-to-device data exchange, data transport over Government-designated tactical radio and mesh networks, and zero-network methods such as high-density QR codes; reliable queuing, synchronization, and reconciliation of data when connectivity is restored; and multi-patient and mass-casualty workflows on battery- and bandwidth-constrained devices. The Contractor shall demonstrate these capabilities under operationally realistic conditions defined by the Government, including degraded-network and emissions control scenarios.

New integrations and sensors. The Contractor shall maintain existing integrations and develop new ones with: ATAK and other DoW tactical and command and control applications identified by the Government; tactical radios and networks; medical sensors and devices, including wireless vital-sign monitors (e.g., Bluetooth and Bluetooth Low Energy); JOMIS systems, including OpMed CDP, TBLD-M, and MEDIX; and EHR systems, including MHS GENESIS. Additionally, Service interfaces such as the TAK network, MEDIBRIDGE and other C2 systems, such as NGC2. Interfaces shall conform to Government Interface Control Documents (ICDs) and recognized standards, including HL7 Version 2 and HL7 FHIR, and records created in the BATDOK FoS shall reach MEDIX and MHS GENESIS without loss. Messaging between devices should be small and lightweight to ensure high reliability on DIL networks utilize MOSA such as JSON, XML, COT, etc.

Testing. The Contractor shall conduct Software Code Quality Checks (SCQC) and automated unit, integration, regression, and on-device testing as part of continuous integration and delivery. The Contractor shall participate in Contractor Integration Testing (CIT) at the end of each Sprint and Program Increment (PI), or as otherwise directed, in a Government-provided integration environment and on site at the Government test lab as required. The Contractor shall develop a Software Test Plan; maintain a Requirements Traceability Verification Matrix (RTVM) for the approved design; document CIT results in a Software Test Report or on the Gov’t provided ALM tool, such as Zephyr Scale and Jira; and support Government Test Readiness Reviews (TRR), developmental and operational testing, and Joint Interoperability Test Command (JITC) interoperability testing.

Tactical radio and operational network testing. JOMIS does not currently have a capability to test the BATDOK FoS with tactical radios or other DoW operational networks. The Contractor shall establish and maintain a Government-approved approach to test BATDOK FoS data exchange over the tactical radios and operational networks designated by the Government, including degraded, intermittent, and contested conditions. The approach may combine Contractor-owned equipment, access to Service, Government, or industry test facilities and exercises, and network emulation, and shall produce repeatable results that are documented in the Software Test Report.

Cybersecurity and efficient delivery. The Contractor shall build and release each component through automated build and release tooling in Government-provided or Government-approved environments, with all source code, configuration, and artifacts in Government-owned repositories; perform static and dynamic code analysis, mobile application security testing, and dependency scanning; generate a software bill of materials (SBOM) for each release; and maintain the RMF body of evidence needed to sustain the ATO and support continuous ATO. The Contractor shall track delivery metrics (e.g., lead time for changes, deployment frequency, change failure rate, and time to restore service) and implement improvements that reduce the cost and cycle time of each release.

Delivery cadence and transparency. The Contractor shall plan and deliver work on the Government’s Program Increment (PI) and capability block cadence; support all Government agile ceremonies in accordance with the Government Technical Execution Plan; and maintain its backlog, plans, progress, traceability, risks, and dependencies in Government-provided application lifecycle management (ALM) tools (e.g., Jira and Confluence) so that status is visible to the Government in real time. The Contractor shall manage the technical, schedule, and cost performance of the effort and track Contract Data Requirements List (CDRL) satisfaction. Each release shall be delivered with an updated Software Version Description (SVD) and release notes.

Consistent iOS and Android User Experience to Reduce Training Demand Outcome: A medic trained on BATDOK-J on one platform can use it on the other without additional training, and new users become proficient quickly.

The Contractor shall maintain functional and user-interface parity between the iOS and Android versions of BATDOK-J, so that workflows, terminology, screen layouts, and data entry behave consistently on both platforms, and new features are delivered on both platforms in the same release unless the Government approves otherwise. Interfaces in BATDOK Link and BAT-TAK shall follow the same design conventions where practicable, and all components shall align with JOMIS ecosystem design standards for a consistent look and feel.

The Contractor shall conduct iterative UI and user experience (UX) design, including wireframing and Government design adjudication before implementation, and shall validate designs using end-user feedback obtained through Government-led or Government-facilitated sessions, recognizing that many users rotate on short deployments and have limited time for training. Designs shall meet Section 508 accessibility requirements where applicable.

The Contractor shall support Government-led usability evaluations and demonstrations in operationally realistic settings and shall use the results to reduce the time users need to become proficient. End-user training is performed by a separate third-party vendor; the Contractor shall provide technical information and knowledge transfer to that vendor, through the Government, as needed for the vendor to keep training current with each release.

CUI [Remove if N/A] image1.png