HCD Q-As 8 Aug25_v2.pdf

Question Answer

1 Ideally, does JOMIS envision this solution working with your upcoming OpMed suite of applications?

JOMIS seeks solutions that are interoperable and can contribute to the broader OpMed ecosystem. The specific nature of that interaction will depend on the capabilities of the proposed solution and alignment with the overall OpMed strategic vision.

2 Does the Government desire prototyping to be completed by September 30th, 2025? The goal is full functionality within FY25. The duration of the prototype project will depend on the solution's complexity.

The CSO references a prototype in the Background section however the very last paragraph of page one states the Government desires to have full functionality in FY25. Assuming FY25 is correct since this is time sensitive, will the government please provide greater detail on what it means by full functionality? "Full functionality" signifies a working model demonstrating the core capabilities and potential success of the solution.

The CSO infers JOMIS is looking for a COTS product depending on the definition of full functionality. Is JOMIS looking to purchase a COTS product or has market research done to suggest that COTS products exist to meet the CSO requirements?

The concepts of COTS and market research are tied to traditional FAR-based procurement contracts. JOMIS has chosen to pursue an other transaction award pursuant to 10 U.S.C.

4022. JOMIS is open to any approach that addresses the problem statement and satisfies the definition of a prototype project.

Does the government expect the solution to have an ATO in FY25 and integrated with the military services deployment platforms? If not, does the government have a required timeline for these milestones?

While there is no requirement that the solution obtain an ATO in FY25, in order to show the potential for success the solution should have an approach that will address cybersecurity. Integration with deployment platforms is a long-term goal and the timeline will depend on the proposed solution.

6 What is the next step in the procurement process after the 10-page submission? Will an immediate award be made or does the government intend a follow-on procurement action(s)?

The Government anticipates inviting companies whose project proposals are determined to have merit to a question and answer session as a next step in the process. The prototype other transaction authority (10 U.S.C. 4022(f)) authorizes the Government to make follow-on production contracts or transactions under certain circumstances.

The description of AOI #2, Healthcare Delivery Documentation for Deployed Personnel, describes an expected solution that closely mirrors the current work being performed by Peraton & T6 Health Systems. Is the government intention to expand on the integration work being performed by Peraton? The Government's intent is to award a prototype other transaction agreement for a prototype project to address the problem described in AOI #2.

The expected solution objectives read like JOMIS is looking for fully integrated care delivery platform to document medical encounters in the theater. Can the Government clarify if the objective of this CSO AOI is to identify an alternate solution to the JOMIS modernized products (i.e. OPMED CDP, MHS GENESIS-T, OMDS, and TBL-D) or is the Government looking for a vendor to act as an integrator for the modernized products? JOMIS is not seeking an alternative solution to the OpMed ecosystems (See #1) or for a vendor to act as an integrator.

9 Are there any specific health standards that the government is looking to deploy? Solutions should adhere to relevant health standards to ensure interoperability. Specific standards should be identified in the submission.

Given that the “Government desires to have full functionality in FY25,” can you please provide more information concerning the government’s timeline / evaluation process?

The Government anticipates inviting companies whose project proposals are determined to have merit to a question and answer session as a next step. The subsequent review process will depend on the number and quality of submissions as well as the results of the question and answer session.

By way of explanation, the Department of Defense (DoD) Other Transactions (OT) Guide (2023) describes the goal of this process: "As a general matter, the Government’s evaluation process should enable the Government team to review submissions effectively and efficiently. The Government team may, for example, employ an interactive process where it issues follow-up questions in writing or as part of a virtual session. A common practice is for the Government team to initially request white papers of a relatively short length. In order to clarify any important information, the Government may ask follow-on questions. For those white papers the Government wishes to review in more detail, the Government may request a full technical proposal. This saves the Government, as well as industry, time, and resources. This also allows the Government to focus on the best proposed approaches."

Will the Government clarify the anticipated award date and period of performance for AOI #2? The AOI states that, "This is a time-sensitive effort and the Government desires to have full functionality in FY25."

The Government plans to make prototype OT award(s) in FY25. The period of performance will depend on a number of factors, including the selected solution and implementation plan.

Will the Government detail what key performance indicators (KPIs) or metrics it will use to measure the 'potential impact' of a submission? Can the Government provide examples of what it consider a high-impact outcome?

The ultimate goal is to improve healthcare outcomes for deployed personnel while reducing administrative burdens on providers and ensuring the security and integrity of healthcare data. The words “high impact” are not used in the AOI.

13 Will the Government clarify what specific evidence (e.g., project timeline with milestones, risk mitigation plan, etc.) is required to demonstrate feasibility? The word “feasibility” is not part of AOI #2. Note that the questions and answers for the draft CSO related to AOI 1a and 1b are not applicable to AOI #2.

Will the Government elaborate on the level of detail that is required in the submission to demonstrate scalability, interoperability, and cybersecurity measures, especially concerning integration with existing systems like MHS GENESIS?

AOI #2 requests an approximately 10-page project proposal that addresses the approach. The level of integration with existing systems will depend on the approach.

Will the Government elaborate on required connections when discussing "seamless access" in regards to MHS Genesis or MHS Genesis-T? Are APIs to be developed by the awardee or will the MHS Genesis teams be required to interface with the solution? i.e. Which office is responsible for developing the interoperability layers?

"Seamless access" means efficient data exchange. Responsibility for interoperability layers will depend on the proposed solution. .

16 Can the Government elaborate on the expected or estimated number of concurrent users for the solution? The expected number of concurrent users will vary depending on, among other things, the location and role, as well as the proposed solution.

17 What funding level is available for this effort?

The Government has FY25 and FY26 funding available; however, the amount for individual prototype project other transaction award(s) will depend on the solution.

What level of "real time documentation" is required? Notes/Injuries/Treatments/Vitals, etc. or are further documentation modalities like radiographic imaging required in the prototype? "Real-time documentation" means capturing critical patient information quickly. The required data elements depend on the clinical scenario.

19 Will the Government provide a list of required systems of record which will be required to interface with the solution? Companiess should identify the systems of record their solution needs to interface with and describe the integration approach.

At what level does JOMIS expect/prefer this system to communicate? (i.e. Integrated Tactical Network, hand-held radio communications, satellite communications, Brigade Level, Battalion Level, etc.) The communication level depends on the deployment environment.

21 Are you looking to replace existing systems such as MHS Genesis Theater? Or your current EMR? While the Government is not looking to replace MHS Genesis Theater, the Government may consider replacing other legacy systems.

Regarding AOI #2 – HCD JOMIS-PMO, is PEO DHMS asking for a completely new Electronic Health Record (HER) solution from Point of Injury to Role 3 and subsequent handoff to tertiary care? If not, then is PEO DHMS asking for a solution to wrap into a holistic, current solution for JOMIS, in other words from POI to Role 1, then T6 to Role 2 + and with Cerner millennium at Role 3.

No, the Government is not looking for a completely new EHR solution from Point of Injury to Role 3 and subsequent handoff to tertiary care. The Government is asking for solutions to solve the challenges described in AOI #2, which may include a variety of approaches.

Will AOI 2 include an example use case, similar to AOIs 1a and 1b? If not, is there a recommended operational context (e.g., pharmacy, clinical decision support, or force readiness) for framing our proposed capability?

AOIs 1a and 1b are for a separate program office with a different review process. While AOI #2 is based on the same CSO, the effort is for JOMIS, and the review process is distinct.

24 To what extent should AOI 2 submissions be aligned with the existing MHS Information Platform (MIP)?

Ultimately, the Government's goal is to have the prototype align with the MIP. While the Government does not want to exclude companies who may not already be familiar with the MIP and who have viable solutions, given the compressed time frame for the full functionality goal companies who possess that understanding are encouraged to demonstrate an understanding of and integration with the MIP and JOMIS ecosystem in the project proposal.

25 Are there specific architectural patterns, APIs, or interoperability standards that AOI 2 solutions should comply with to ensure compatibility with DHA systems? Solutions should comply with widely accepted architectural patterns, APIs, and interoperability standards.

Beyond HIPAA and FedRAMP, are there additional compliance frameworks or data protection constraints that AOI 2 solutions must address, particularly for cross-domain analytics or patient-level data?

The answer to the question depends, in part, upon the proposed solution. Companies are encouraged to address relevant compliance frameworks and data protection constraints as part of their submission.

Could the Government please clarify whether this CSO AOI is intended to support innovation that builds upon, or integrates with, work currently being performed (or recently performed) under existing contracts? If yes, would the Government be willing to identify any predecessor or related contract numbers that inform or align with this CSO AOI? This context would be helpful in aligning proposed capabilities with existing programmatic objectives and infrastructure.

AOI #2 does not exclude work that has been done, or that integrates with work done, on work performed under current or prior contracts.

The DoD OT Guide (2023) states that the purpose of OTs, in part, is to foster new relationships and practices involving traditional and nontraditional defense contractors, especially those that may not be interested in entering into Federal Acquisition Regulation (FAR)-based contracts with the Government, to broaden the industrial base available to the Government, and to encourage flexible, quicker and cheaper project design and execution, among other things. Given this purpose, the Government will not review prior contracts to determine which inform or align the problem statement or provide predecessor or related contract numbers.

28 Understanding that the desired end state is a protype, will the government please define what full functionality means in the context of this requirement. See #2.

29 Does JOMIS require that the prototype is available for functional evaluation by September 30, 2025, or is the expectation that the evaluation will have been completed by this date? The Government’s goal is that the prototype be available for functional testing by September 30, 2025.

30 Will the government please clarify where this will fit in the MHS GENIs the government looking to replace GENESIS Theater? See #21 31 Does the government intend for this protype and subsequent system to integrate with BATDOK? Yes.

32 Will the government please clarify what Healthcare documentation is? Healthcare documentation includes all records related to a patient's medical history, diagnosis, treatment, and care.

Can the government clarify if they are looking to procure another set of services or software capability for healthcare documentation alongside the existing healthcare delivery and documentation projects, such as CDP, BATDOK, T-Blood, etc.? The Government is not seeking to duplicate existing capabilities. See #1, 31.

HT003825900xx, AOI #2 HCD Q&As

34 Can the government clarify what kinds of “resource-constrained settings” the solution should account for? "Resource-constrained settings" have limited bandwidth, power, and/or access to specialized medical personnel.

Having full functionality in Government FY25, effectively by September 30, 2025, is a very aggressive schedule, especially with DoD’s unique healthcare and cybersecurity polices, integration efforts, and coordination. Can the government clarify how they define full functionality? See #3

Can the government clarify on what a “project submission” is? What components need to be included in the 10-page project submission? For example, is the government looking for an Integrated Master schedule that is fully loaded? A project plan on the different phases of work to be completed?

The Government did not request an Integrated Master schedule or project plan. Please see the Project Proposal Submission and Review Process section of the AOI for a description of the submission. Although no specific request has been made for a plan on different phases of work to be completed, the Government notes that it intends to award in FY25 with the goal of a fully functional prototype in a short time period and appreciates submissions that address an approach to successfully meet those goals.

37 Is the Government requesting estimated pricing? The Government is not requesting estimated pricing at the time of the project proposal submission.

38 What legacy systems beyond MHS GENESIS (e.g., TMIP-J, AHLTA-T, MC4) must be integrated with during prototyping?

Which legacy systems must be integrated during prototyping may depend on the proposed solution. As a result, the Government does not have a list of systems that are minimum requirements. However, given the importance of the FY25 prototype award and fully functional goal for the prototype, companies are encouraged to describe their approach to or experience with integrating their solution into the OpMed environment.

39 Will the Government provide APIs or interface specifications for required systems? The Government will address access to APIs and interface specifications on a case-by-case basis depending on the solution.

40 How should the solution support data exchange across coalition partner platforms or NATO STANAGs? While this may become a long-term goal for the solution, the fully function status for prototyping in FY25 does not include the NATO partner platforms.

41 Will the solution need to operate within existing IL5/IL6 classified environments, and will a FedRAMP or DoD RMF ATO be required during the prototype phase?

The Government anticipates that the solution will need to operate in an IL5 environment, but not necessarily within an IL6/classified environment. The Government does not anticipate requiring FedRAMP during the prototyping phase. The Government does anticipate that the solution will require an ATO during the prototyping phase and companies are encouraged to explain their path to obtaining an ATO in their project proposal.

42 What cybersecurity standards beyond HIPAA (e.g., NIST 800-53, Zero Trust) must be demonstrated?

The cybersecurity standards will depend, in part, on the proposed solution. The Government intends to engage with industry to understand the risks of the proposed solution and to address any specific compliance risks leading up to and during the prototyping process. Because the solution is integrally related to health care, the Government cannot envision a solution that is not compliant with HIPAA.

43 Can the solution leverage Commercial Solutions for Classified (CSfC) architecture for secure documentation? Yes, the Government will consider a solution using CSfC architecture as a potential consideration.

44 What is the target user base (approximate number of concurrent providers) during the prototype and at full scale? See #16.

45 Should the solution be modular based on clinical system components to support phased implementation? A modular design is generally desirable for phased implementation and scalability.

46 What user roles/personas be accommodated in the interface and documentation workflows? The solution should accommodate various user roles (medics, nurses, physicians, etc.).

47 Who will validate workflows for clinical completeness? Qualified healthcare professionals will validate clinical workflows.

48 What clinical data standards must be adhered to (e.g., FHIR, C-CDA, SNOMED, LOINC, ICD-10)? Solutions should adhere to relevant clinical data standards.

49 Are there specific templates (e.g., SOAP notes, trauma registries) that must be incorporated into the prototype?

The Government does not have specific templates, but there are workflows that are planned to ultimately need to be incorporated into a successful prototype (a phase beyond the full functionality goal in FY25). The Government does not intend to use that level of detail to discriminate among potential solutions for the initial prototype project awards.

50 What training modalities are acceptable or expected (e.g., SCORM packages, embedded walkthroughs, role-based help)?

The Government requested embedded training as part the project proposal submission. This question on training modalities appears to address training more as a separate service and appears to be outside of the focus of the problem statement.

51 Should the solution support remote support models such as virtual help desk or in-theater field support kits?

The problem statement focuses on the software solution. The Government does not anticipate including a remote support model or virtual help desk as part of its prototype project award, in part because given the operational constraints only local support is available in most cases. That said, the Government may consider these services as ancillary to the software solution.

52 How will success be measured during the prototype phase (e.g., time to documentation, user adoption, system uptime)?

Per the DoD OT Guide (2023): “As a general matter, success means that the performer (1) met the key technical goals of a project; (2) satisfied success metrics incorporated into the Prototype OT; or (3) accomplished a particularly favorable or unexpected result that justifies the transition to production. This definition is addressed in the policy memo title “Definitions and Requirements for Other Transactions Under Title 10, United States Code, Section 2371b”. The Government will identify the specific success metrics as part of the prototyping process as they are somewhat dependent upon the proposed solution.

53 Will user feedback sessions be part of the evaluation, and will industry have access to field users for refinement?

The Government does not anticipate including field/end users as part of the initial review of the proposal project submissions. For prototyping phases, the Government does intend to include field/end users. Industry access to those results may be negotiated as part of the prototype project award.

54 What is the planned acquisition timeline post-prototype? The post-prototype acquisition timeline depends on the project's success and funding availability.

55 Will successful prototypes be transitioned to a production contract under the same CSO or via a new solicitation? It is premature for the Government to identify the specifics with respect to a possible follow-on production contract or transaction.

"To ensure our proposed solution aligns with all relevant regulatory requirements, could you please provide a comprehensive list of the *specific* healthcare regulations (e.g., HIPAA, HITECH, 42 CFR Part 2, state-specific regulations regarding data privacy) and cybersecurity regulations (e.g., NIST Cybersecurity Framework, FedRAMP requirements at a specific impact level, DoD Instruction 8500.01, DFARS clauses pertaining to cybersecurity) that the solution *must* comply with? Please include any relevant compliance standards or certification requirements."

Companies are responsible for complying with all laws applicable to their proposed solutions, which may include healthcare and cybersecurity regulations.

"Beyond MHS GENESIS, what specific healthcare systems (including legacy systems, operational data stores, and reporting systems) and databases will the proposed solution need to interoperate with? For each system, please provide details on: The specific data elements that need to be exchanged; The data exchange frequency (e.g., real-time, near real-time, batch); The APIs or integration protocols supported (e.g., FHIR, HL7 v2/v3, REST, SOAP)

This information is more detailed than the Government expects as part of the initial project proposal submission and likely depends in part on the proposed solution. The Government anticipates engaging with prototype project awardees to resolve these details as part of the award.

58 Any data transformation requirements: Real-Time Definition (Quantifiable Performance Metrics) While the Government defined this as a goal of the solution, the Government does not have a defined metric for “real time” at this time.

"To clarify the requirement for "real-time" documentation, please provide quantifiable performance metrics for data capture, processing, and retrieval. Specifically, what is the maximum acceptable latency for: Data entry by the user (e.g., form submission); Data processing and validation; Data retrieval for display to the user; Data synchronization with other systems

See #59. “”

60 Please specify the acceptable delay in seconds or milliseconds for each of these operations, and the required availability (e.g., 99.999% uptime) See #59.

"To help ensure the proposed solution provides an "intuitive design and functionality" for healthcare providers in deployed environments, could you please provide: Detailed user personas representing the different types of healthcare providers who will be using the system (e.g., medics, nurses, physicians); Specific use cases illustrating how the system will be used in different operational scenarios; Examples of existing systems (even if not in the healthcare domain) that you consider having excellent usability; Key usability requirements related to factors such as screen size, input methods (e.g., touch, keyboard, voice), and offline access."

See Joint Publication 4-02 Joint Health Services, available online at https://cdmrp.health.mil/pubs/pdf/Joint%20Health%20Services%20Publication%20JP%204- 02.pdf

"To ensure the new system integrates seamlessly with the existing IT infrastructure, could you provide a comprehensive list of systems and databases that this new system will need to integrate with? For each system, please include the following details: System name and version; Purpose of the system; Type of database used (e.g., SQL, NoSQL, specific vendor and version); Data format and exchange protocols supported; Available APIs or integration endpoints; Authentication and authorization mechanisms"

This information is more detailed than the Government expects as part of the initial project proposal submission and likely depends in part on the proposed solution. The Government anticipates engaging with prototype project awardees to resolve these details as part of the award.

63 Beyond general cybersecurity regulations, are there specific data encryption requirements (e.g., at rest, in transit)? What are the requirements for access control and audit logging?

This information is more detailed than the Government expects as part of the initial project proposal submission and likely depends in part on the proposed solution. The Government anticipates engaging with prototype project awardees to resolve these details as part of the award. Companies should anticipate complying with all applicable laws and regulations.

64 What are the expected scalability metrics (e.g., number of users, transaction volume, data storage requirements) for the proposed solution, both initially and in the future? The Government anticipates developing the scalability metrics as part of the prototyping process.

65 What types of authoritative medical references are envisioned for embedding within the system? (e.g. Drug formularies, clinical guidelines, diagnostic tools)

The Government does incorporate the JTS Clinical Guidelines, available online at https://jts.health.mil/index.cfm/PI_CPGs/cpgs. The Government does not have a comprehensive list of medical references to include at this time, but companies are encouraged to describe the medical references that are embedded as this may be of benefit to the Government in determining prototype awards.

66 Will any GFE/GFI be provided to the selected vendor? If so, what and when? The Government will determine the availability of GFE/GFI on a case-by-case basis based on the solution after prototype award.

67 Will the JOMIS Program Office sponsor CAC’s for both system and physical access for testing and integration sites? The Government will sponsor CACs where needed for performance. The number and type of CAC sponsorship will be determined on a case-by-case basis.

68 Will the Government consider sponsorship of security clearances for access to testing sites and events?

While security clearances are not anticipated to be a requirement, the Government will consider sponsoring companies for clearance where needed for performance. Security clearance sponsorship will be determined on a case-by-case basis.

69 Are there any data sovereignty or residency requirements that the solution must adhere to? The Government is not aware of any data sovereignty or residency requirements for this solution.

70 Are there any requirements or preferences regarding the use of open-source software or technologies? The Government is open to considering solutions that utilize open-source software or technologies.

“Deployed personnel in austere environments” – Can we assume this CSO is focused on point of injury / Role 1 -> transport -> Role 2. Would Role 3 also use this documentation capability? The primary focus is on Point of Injury / Role 1 -> transport -> Role 2. The potential use of the documentation capability at Role 3 is a consideration.

Is the solution expected to provide interfaces / documentation tools specific to Roles of Care (Documentation solution for Role 1 should align to TCCC; Role 2 application aligns to broader scope of practice, etc.) The Government expects that solutions will provide interfaces and documentation tools specific to different Roles of Care.

73 Store and Forward – What is the expected frequency and granularity of data synchronization (real-time, batch, event-driven, etc.)? The expected frequency and granularity of data synchronization will depend on the specific use case and operational requirements.

74 Does government have a list of data elements in scope for austere deployed documentation?

This information is more detailed than the Government expects as part of the initial project proposal submission and likely depends in part on the proposed solution. The Government anticipates engaging with prototype project awardees to resolve these details as part of the award.

75 Does the solution require integration with telemetry / patient monitoring / wearables? Does the government intend that this solution capture and/or process of video, audio, photo?

The Government is interested in solutions that include integration with telemetry/patient monitoring/wearables and those that have the ability to capture and process audio, video and photos. However, these are not requirements.

76 Scope of interoperability – What specific DOD information systems must the tool must directly interface with? What data formats/ standards are required?

This information is more detailed than the Government expects as part of the initial project proposal submission and likely depends in part on the proposed solution. The Government anticipates engaging with prototype project awardees to resolve these details as part of the award. See #1 and #38.

77 Can government identify preferred or required protocols for synchronization processes? The Government does not have preferred or required protocols for the synchronization processes at this time.

78 What authentication mechanisms does the tool need to support for interoperability with other systems?

The Government expects that the solution will be CAC-enabled/authenticated, PKI, and with applicable DOD cybersecurity requirements. The Government anticipates address authentication prior to determination of a successful prototype (a later phase than that of full functionality) such that this can be addressed during the prototyping process.

79 Can the government provide specific cybersecurity / accreditation requirements for the prototype project? The cybersecurity/accreditation requirements depend on the proposed solution.

80 For the prototype project, which, if any, government-provided identity management solutions or platforms must the tool integrate?

This information is more detailed than the Government expects as part of the initial project proposal submission and likely depends in part on the proposed solution. The Government anticipates engaging with prototype project awardees to resolve these details as part of the award.