Military Health System and the Layered Compliance Stack: HIPAA, MARS-E, and AI

Military Health System and the Layered Compliance Stack: HIPAA, MARS-E, and AI

If you are a contractor working with the Defense Health Agency, you already know the compliance environment is dense. But the specific way HIPAA, MARS-E, and federal security baselines interact in this space creates a layered stack that most commercial compliance frameworks were never designed to handle. Add AI tooling into the mix and things get genuinely complicated, fast.

Let me walk through where the layers sit, where they conflict, and where AI tools can actually help versus where they will get you into trouble.

The DHA Compliance Landscape: Two Frameworks, One Mission

The Defense Health Agency oversees healthcare for approximately 9.6 million beneficiaries through TRICARE. Contractors supporting DHA operations, whether building eligibility systems, managing claims processing, or developing patient-facing applications, sit at the intersection of two major compliance regimes.

First, HIPAA. The Privacy Rule (45 CFR Parts 160 and 164) and the Security Rule apply because you are handling protected health information. Business Associate Agreements are mandatory. Breach notification timelines under the HITECH Act (60 days to HHS, with state-level requirements layered on top) are non-negotiable. The Office for Civil Rights has collected over $142 million in HIPAA enforcement actions since 2003, and penalties under the revised penalty tiers (set by the HITECH Act and adjusted by the 2019 Notification of Enforcement Discretion) can reach $2,067,813 per violation category per year.

Second, MARS-E. The Minimum Acceptable Risk Standards for Exchanges, published by CMS, were originally developed for Affordable Care Act health insurance exchanges. Version 2.2, released in 2021, maps controls to NIST SP 800-53 Rev. 4 (with organizations increasingly aligning to Rev. 5). DHA adopted MARS-E requirements for TRICARE-related systems that handle eligibility and enrollment data. This means contractors building or operating systems that touch Federal health exchange-adjacent functions need to implement a control set that goes well beyond what HIPAA's Security Rule demands on its own.

The practical result: you are implementing HIPAA's administrative, physical, and technical safeguards and a NIST 800-53 derived control baseline simultaneously. These are not identical. HIPAA's Security Rule is deliberately flexible ("addressable" vs. "required" implementation specifications). MARS-E is prescriptive. When both apply, the more stringent requirement wins.

Where the Frameworks Overlap and Where They Diverge

Access controls are a good example of convergence. HIPAA requires them (45 CFR 164.312(a)(1)). MARS-E, through its mapping to NIST AC-family controls, specifies how they must be implemented, including things like session lock (AC-11), separation of duties (AC-5), and least privilege (AC-6). If you are only thinking about HIPAA, you might implement role-based access and call it done. Under MARS-E, you need documented enforcement of least privilege with periodic access reviews.

Audit logging is another area. HIPAA requires audit controls (45 CFR 164.312(b)). MARS-E requires specific audit events to be captured, retained for defined periods, and protected against tampering, per the AU-family controls. The gap between "we log stuff" and "we capture AU-2 defined events, review them per AU-6, and protect them per AU-9" is significant in practice.

Incident response diverges more sharply. HIPAA breach notification has its 60-day clock. But DHA contracts often incorporate DFARS 252.204-7012, which imposes a 72-hour reporting requirement to the DoD Cyber Crime Center for cyber incidents involving covered defense information. If your system processes both PHI and CDI (which is common in military health contexts), you are managing two incident response timelines with different reporting chains.

Where AI Tools Fit

There are legitimate, high-value applications for AI in this environment. Anomaly detection in audit logs is one. When you are generating the volume of audit data that MARS-E AU-family controls require, human review alone is insufficient. Machine learning models trained on baseline system behavior can flag deviations that warrant investigation under AU-6. This is well-trodden ground, and the compliance case for it is straightforward.

Clinical decision support is another area where AI is already deployed in MHS contexts. The DHA has invested in predictive analytics for readmission risk and population health management. These tools, when properly validated and when their outputs are treated as advisory rather than deterministic, fit within existing regulatory frameworks.

Natural language processing for claims adjudication and eligibility determination is increasingly common. When these systems operate on structured data within controlled environments, they can improve accuracy and throughput without creating novel compliance risks.

Where AI Tools Do Not Fit (Yet)

Generative AI is where things get difficult. Large language models that process PHI create data residency and minimization problems that are hard to reconcile with both HIPAA and MARS-E. Under MARS-E's SC-family controls (system and communications protection), data must be encrypted in transit and at rest, and system boundaries must be clearly defined. When a query containing PHI is sent to a cloud-hosted LLM, you need to answer hard questions about where that data is processed, whether it persists in model memory or training pipelines, and whether the API provider qualifies as a Business Associate.

OpenAI's enterprise terms, for example, state that they do not use API inputs for training as of March 2023. But "not used for training" and "compliant with MARS-E data handling requirements" are different assertions. You still need to address SC-28 (protection of information at rest), SC-8 (transmission confidentiality), and MP-6 (media sanitization) for any system component that touches PHI.

Automated decision-making in eligibility determinations is another boundary. CMS has been cautious about algorithmic decision-making in exchange contexts, and DHA follows suit. If an AI system is making or materially influencing eligibility decisions for TRICARE beneficiaries, you are potentially running into due process concerns under the Fifth Amendment (since DHA is a federal entity) and the APA's requirements for reasoned decision-making. The VA's experience with algorithmic tools in benefits adjudication, which has drawn Congressional scrutiny, is instructive here.

Risk scoring models that influence clinical resource allocation also warrant caution. The well-documented racial bias issues in Optum's commercial health risk algorithm, which UnitedHealth Group used and which a 2019 Science paper by Obermeyer et al. demonstrated systematically underestimated the health needs of Black patients, should be a standing reminder. In a military health context serving a diverse beneficiary population, deploying unvalidated risk models creates both compliance and mission risk.

Practical Guidance for DHA Contractors

• Map your controls to both frameworks explicitly. Maintain a crosswalk between HIPAA Security Rule requirements, MARS-E controls, and any DFARS/CMMC obligations. Do not assume satisfying one satisfies the other.
• Treat AI components as separate system boundaries. Under MARS-E, each system boundary requires its own security assessment. If you are integrating an AI tool, it likely constitutes a new or modified boundary that needs its own Authority to Operate consideration.
• Document AI tool data flows exhaustively. For any AI component that touches PHI or CDI, you need data flow diagrams that account for every processing node, every API call, and every persistence layer. This is not optional under MARS-E's CA-family (security assessment and authorization) controls.
• Validate before deploying. Bias testing, accuracy benchmarking, and adversarial testing for AI tools should be completed and documented before production deployment. Post-deployment monitoring should be continuous and tied to your AU-6 review processes.

How FirmAdapt Addresses This Problem

FirmAdapt's architecture was built for exactly this kind of layered compliance environment. The platform maintains control mappings across HIPAA, MARS-E, NIST 800-53, and DFARS/CMMC simultaneously, so contractors can assess a single AI tool or system component against all applicable frameworks without maintaining separate compliance workflows. Data processing stays within defined system boundaries, and the platform enforces data minimization and access controls that satisfy the more stringent MARS-E requirements by default.

For DHA contractors evaluating AI integration, FirmAdapt provides a structured assessment workflow that documents data flows, maps them to applicable controls, and identifies gaps before deployment. The platform treats AI components as discrete system elements requiring independent authorization documentation, which aligns with how DHA and CMS expect these systems to be assessed. If you are navigating this stack, it is worth looking at how a compliance-first approach to AI can reduce the friction between innovation and regulatory obligation.