Unleash DD214 as the Olive Button

This paper proposes Olive Button, a Blue Button-style FHIR implementation pattern for DD214 service data that helps meet the 30-, 120-, and 180-day mandates of Executive Order 14426 using existing systems and standards. It matters because the order now requires records sharing at separation. The FHIR mapping is an implementation hypothesis, and the order does not mandate FHIR.

Abstract

Olive Button is no longer just a good interoperability idea. Executive Order 14426 now requires immediate records sharing at separation, interoperability requirements in relevant IT contracts, and permanent ongoing DoW/VA sharing on fixed deadlines. Olive Button is a narrow DD214-centered implementation pattern that can help turn those mandates into working software using systems and standards that already exist.

Key points

Question: What is the smallest standards-based implementation that helps meet the 30-, 120-, and 180-day mandates of Executive Order 14426 for DD214 service data, without launching another enterprise modernization program?
Proposal: Olive Button: a compact FHIR profile package that reuses HL7’s Military Service History profiles, fed by a read-only contract on existing systems, released first as a Veteran download and then as a Veteran-authorized API.
Meaning: It gives agencies a concrete, testable interoperability target for the 120-day contract review without replacing source systems. The FHIR mapping is an implementation hypothesis, and the order does not mandate FHIR or the name Olive Button.

Status of this paper

This is a working technical strategy, version 3, as of October 1, 2026. It proposes an implementation pattern. The FHIR mapping in “What Olive Button should mean technically” is an implementation hypothesis: the paper does not claim that every DD214 field already has a published FHIR mapping.

Important

Executive Order 14426 does not mandate FHIR, the name Olive Button, or Veteran-directed download/API access by name. This paper proposes Olive Button as a practical way to implement and extend the interoperability, data-sharing, and digital-service requirements already directed by the White House.

1. The directive is already on the clock

Executive Order 14426, signed September 8, 2026, identifies outdated records management and data systems as a cause of delays in health coverage, benefits, education, job training, and placement. It then establishes three implementation clocks.[1][2] As of October 1, the first deadline is one week away.

Table 1. The three deadlines in Executive Order 14426 and what each means for Olive Button
EO 14426 deadline	Date	What the Order requires	Olive Button implication
30 days	Oct. 8, 2026	All current service member Official Military Personnel Files, health records, and Service Treatment Records must be shared with VA immediately at discharge or release.	Do not invent a new transport platform. Map the DD214/service-data slice of the handoff already being used for compliance and make it machine-readable and testable.
120 days	Jan. 6, 2027	DoW and VA, with HHS/ONC and OMB Federal CIO/OFPP, must review and modify relevant IT contracts for interoperability; future personnel and medical IT contracts must include interoperability.	A stable Olive Button FHIR profile plus conformance tests can become a concrete DD214 interoperability requirement instead of leaving “interoperable” undefined.
180 days	Mar. 7, 2027	DoW and VA must establish updated IT systems, policy guidance, and memoranda for permanent, prospective, ongoing sharing from entry into service through the period of VA benefits, and deploy digital tools for a comprehensive source of benefits access.	Olive Button Phase 1 and Phase 2 provide a small, testable pattern for portable service data and Veteran-authorized access that can plug into the broader permanent-sharing architecture.

The executive question is no longer “Should we modernize DD214 data?” The useful question is “What is the smallest standards-based implementation that helps us meet the 30-, 120-, and 180-day mandates without launching another enterprise modernization program?”

2. Blue Button is the proof; Olive Button is the Armed Services pattern

Blue Button 1.0 demonstrated a deliberately simple move: give an individual a usable copy of data government already holds. Blue Button 2.0 turned that same principle into programmable, beneficiary-authorized access using FHIR APIs and OAuth.[12][13] Olive Button applies the same sequence to military service data, starting with the DD214.

Figure 1. Existing personnel data reaches the Veteran through one FHIR representation

The historical lesson is not that government needs another large integration program. The 2009 Virtual Lifetime Electronic Record vision already promised DoD/VA continuity, yet the 2026 Executive Order still has to put record movement on a deadline.[18] Olive Button therefore favors a narrow, reusable data contract and conformance model over a new enterprise platform.

Weakened if: the HL7 Military Service History profiles cannot carry the DD214 service episodes, discharge data, and provenance in one Bundle, or a Veteran-held DD214 copy proves harder to produce than the Blue Button 1.0 download was.

3. The DD214 data is already electronic

DoD Instruction 1336.01 already requires the uniformed services to electronically transmit DD Form 214/5 Series data to DMDC within one day of certification or separation, requires the electronic data to match the retained image, and requires digital certification and serialization. DMDC is directed to share electronic service and separation data with VA, DOL, and designated State or territorial Veterans agencies.[3]

That changes the technical problem. Olive Button does not need to “digitize the DD214.” It needs to standardize, expose, validate, and authorize data that already exists electronically.

FHIR is also not greenfield. HL7 already publishes a U.S. Military Service History and Status Implementation Guide on FHIR R4, including profiles for US Veteran, Military Service Episode, Deployment History Episode, and Military Occupation.[14][15] The first technical task is therefore mapping and gap analysis, not standards invention.

4. What Olive Button should mean technically

Do not begin by inventing a brand-new core FHIR resource named DD214. Build a compact DD214 Olive Button Implementation Guide/profile package that reuses existing Military Service History profiles, adds only the extensions and terminology that are genuinely missing, and packages the result for both Veteran download and authorized API use.

Table 2. FHIR elements proposed for the DD214 Olive Button package
FHIR element	Role	Likely DD214 content
US Veteran / Patient	Identity	Person identity and Veteran status
Military Service Episode	Period of service	Branch/component, service dates, discharge/separation
Military Occupation	Military specialty	MOS/rating/specialty and duration
Deployment History Episode	Deployment	Completed deployment periods/context
DocumentReference	Source artifact	Authoritative DD214 image/PDF reference
Provenance	Trust	Issuer/source, mapping version, corrections, signature metadata
Bundle / Composition	Portable package	Self-contained Veteran-downloadable service record
Extensions / companion profiles	Residual fields	Rank/pay grade, awards, education, locations, obligations, and genuine gaps

This is an implementation hypothesis, not a claim that every DD214 field already has a published FHIR mapping. The Olive Button technical group must determine the exact resource paths, code systems, value sets, extensions, cardinalities, and provenance rules.

FHIR is the interchange model at the edge. Existing DoD/DoW personnel systems do not have to become FHIR-native.

Weakened if: the field inventory finds that many DD214 fields cannot be expressed by existing Military Service History profiles plus a small set of extensions, so a new core resource or a large new profile family becomes necessary.

5. The policy stack already supports the operating model

Table 3. Authorities that support the operating model
Authority / policy	What it says that matters here	Olive Button consequence
EO 14426 (2026)	Immediate discharge-time sharing, permanent ongoing sharing, interoperable contracts, and new digital tools; OMB and ONC are explicitly in the implementation chain.[1]	Treat Olive Button as an implementation artifact for the executive mandate, not an optional innovation project.
38 U.S.C. §5103A	VA has a statutory duty to make reasonable efforts to obtain relevant service medical and other government-held service records for disability claims.[4]	Faster authoritative service-data availability directly supports an existing VA statutory workflow.
38 U.S.C. §8111	Requires VA and DoD coordination and sharing of health-care resources and joint planning.[5]	The EO builds on an existing statutory history of VA/DoD sharing rather than creating interagency cooperation from scratch.
Privacy Act, 5 U.S.C. §552a	Individuals generally have rights to access records about themselves and obtain copies; disclosure to others is generally governed by consent or statutory exceptions.[6]	Olive Button Phase 1 should emphasize individual access; Phase 2 should use explicit, auditable authorization rather than broad disclosure.
CASES Act + OMB M-21-04	Federal agencies must modernize digital access and consent for disclosure of Privacy Act records using digital identity proofing and authentication.[7]	Veteran-authorized digital consent is not a novel legal concept; OMB already provides an implementation path.
OMB M-26-18, Login.gov	Pushes a universal sign-on, discourages repeated identity proofing, encourages reuse of previously provided data, and directs GSA to assess verifiable digital credentials including veteran status.[8]	Use existing identity infrastructure where appropriate. Do not create a Olive Button identity stack unless required by mission risk.
OMB M-23-22	Directs agencies to keep digital interactions digital end-to-end and expand self-service and unified digital experiences.[9]	A DD214 that is already electronic should not be converted into a human-only paperwork loop before becoming useful again.
OMB M-19-18 + Federal Data Strategy	Treats Federal data as a strategic asset and emphasizes standards, interoperability, sharing, documentation, and reuse.[10]	The FHIR mapping and reusable read-only contracts are aligned with existing government-wide data policy.
OMB Circular A-130	Establishes policy for managing information as a strategic resource, including interoperability, information sharing, privacy, security, records management, and electronic signatures.[11]	Olive Button should be implemented as information-resource management, not as a standalone app procurement.
OMB M-25-21	Directs agencies to remove unnecessary barriers to responsible AI adoption and reuse agency data, models, code, and assessments.[16]	AI can help downstream with benefits/navigation, but the Olive Button service record itself should remain deterministic and provenance-rich.
OMB M-26-12	Reinforces preference for commercial products/services and scrutiny of unnecessary custom development.[17]	After the Olive Button standard is stable, implementation partners can be competed against a clear conformance target instead of defining the target themselves.

EO 14426 also expressly cites 38 U.S.C. §7332(e) and 5 U.S.C. §552a as privacy constraints on the permanent sharing architecture, and cites 10 U.S.C. §§1142-1144 and 38 U.S.C. §4113/§4215 for transition and employment pathways. Olive Button should preserve those legal boundaries rather than trying to collapse personnel, health, and employment data into one unrestricted record.

6. A new supporting directive: America.gov

On September 29, 2026, the White House separately directed creation of America.gov as a unified digital front door. That order calls for common standards of interoperability, data minimization, secure authentication, and auditable authorization while preserving each agency’s custody and control of its records.[19] This is highly consistent with the Olive Button architecture on the VA-facing side.

Important

The America.gov order excludes Department of War services from its definition of covered services. It therefore strengthens the case for common access patterns and the VA consumer experience, but it should not be cited as direct authority requiring DoW to implement Olive Button.

7. Form the technical group before adding implementation vendors

The Olive Button standard should be solidified by authoritative data owners, interoperability experts, and system engineers before implementation vendors are asked to build against it. Vendors should conform to the standard, not accidentally define it.

Table 4. Participants in the technical group
Participants	Purpose
DoD/DoW DD214 policy and data owner	Authoritative field definitions, issuance rules, and ownership
DMDC data architect/owner	Electronic DD214/5 feed, serialization, current downstream sharing
Service personnel-system DB/data engineers	Map Olive Button fields to actual tables, views, exports, and semantics
VA FHIR/API engineer	Existing VA service-history APIs, FHIR practices, and downstream use
HHS/ONC interoperability/FHIR representative	Help align the 120-day interoperability work with health IT and FHIR practice. The Order names ONC in the 120-day review and does not name FHIR
HL7 Military Service IG implementer	Reuse existing profiles and constrain extensions/terminology
GSA/Login.gov identity representative	Align Veteran authentication/authorization with M-26-18 where applicable
OMB Federal CIO / OFPP liaison	Keep the Olive Button conformance target useful for the 120-day contract review, without turning OMB into the technical design owner
Veteran and external application representative	Prove the output can be used outside the source systems

First deliverables

DD214 field inventory with source ownership, sensitivity, optionality, repeatability, and authoritative definitions.
DD214 → FHIR mapping matrix: field, meaning, resource.path, terminology, extension, cardinality, provenance.
FHIR → source-system mapping matrix: authoritative system, table/column/export element, transformation, freshness.
Synthetic example Bundles plus a validator/conformance harness.
A contract-ready interoperability clause or technical attachment that can be used during the EO 14426 120-day review.
Olive Button Phase 1 download specification and Phase 2 OAuth/API specification.

Weakened if: a vendor-built reference implementation conforms to the DD214 mapping matrix and validator as readily as one built after the technical group publishes them, showing the group’s prior work did not reduce divergence.

8. How existing systems can emit Olive Button safely

Figure 2. A canonical system emits Olive Button through a read-only contract

The system owner should not be asked to replace the personnel system, install an AI agent in production, or expose operational tables directly. The request should be smaller: expose authoritative fields through the least risky read-only mechanism the team already knows how to operate.

Table 5. Techniques for emitting Olive Button from an existing system
Technique	System-owner work	FHIR-layer work
Secondary read-only schema	Views over approved fields; no writes	Read stable views and map to FHIR
SELECT-only stored procedures	Publish narrow procedures for service episodes, occupations, deployments, and document metadata	Call procedures and serialize rows into FHIR
Read replica	Expose reporting replica rather than production transaction tables	Run versioned mapping queries
Scheduled export	Emit CSV/JSON/NDJSON	Transform export into FHIR Bundles/repository
Thin internal API	Wrap existing queries in a small endpoint	Translate response into the Olive Button profile
Existing DMDC feed	Reuse serialized DD214/5 data already moving today	Map the same feed into the canonical Olive Button FHIR representation

Safety rules for canonical system owners

No writes from the Olive Button project into the canonical system.
No operational-table schema changes merely to support FHIR.
No direct external application access to source databases.
Prefer secondary schemas, reporting replicas, views, and SELECT-only procedures.
Use query limits, timeouts, logging, service identities, and versioned contracts.
Keep the FHIR mapper outside the source database whenever practical.
Test with synthetic identities and data before production Veteran records.
Require every output to preserve provenance back to the authoritative source and mapping version.

The canonical system owner does not have to build the Veteran application. The owner only has to expose a safe, stable read-only contract. Everything above that boundary can move quickly.

Weakened if: a pilot source owner finds that a read-only view, procedure, replica, or export cannot supply the authoritative fields with acceptable freshness, or that the safety rules force changes to operational tables.

9. Olive Button Phase 1: Veteran download

Begin the way Blue Button 1.0 did: authenticate the Veteran, retrieve authoritative service data, emit the Olive Button FHIR package, and let the Veteran keep it. The first user experience should be intentionally boring: “Download My Military Service Data.”

Figure 3. Phase 1: the Veteran downloads and keeps the service data

Human-readable DD214/service summary.
FHIR JSON Bundle containing structured military-service data.
DocumentReference or equivalent pointer to the authoritative DD214 artifact where permitted.
Provenance identifying source systems, generation time, mapping version, corrections, and signature metadata.

Weakened if: Veterans in a controlled test cannot complete the download unaided, or the Bundle’s service data fails to match the authoritative DD214 on review.

10. Olive Button Phase 2: Veteran-authorized API

After the downloadable representation is stable and useful, expose the same representation through a Veteran-authorized API. This is the Blue Button 2.0 pattern: standardized resources, secure authentication, narrow authorization scopes, revocation, and audit.[12][13]

Figure 4. Phase 2: the Veteran authorizes an app to read the same data

OAuth 2.0 / OpenID Connect authorization controlled by the Veteran.
Narrow scopes such as service episode, occupation, deployment, discharge, or full service record.
Synthetic developer sandbox before production access.
Revocation and audit of third-party access.
One canonical FHIR mapping shared by download and API paths.
Use Login.gov or another approved identity solution according to agency risk and applicability rather than inventing a new Olive Button identity provider.

Weakened if: the sandbox shows that the download representation cannot be served through narrow OAuth scopes with revocation and audit without a separate mapping, or that a third-party app cannot use it without custom source-system work.

11. Implementation plan aligned to the White House clock

Table 6. Implementation plan aligned to the White House clock
Window	Olive Button work	Executive relevance
Now → Oct. 8	Identify the existing discharge-time DD214/OMPF transfer path, source owners, formats, and current exception points. Do not disrupt the path being used to satisfy the 30-day requirement.	Maps Olive Button onto the mandated immediate-sharing flow rather than competing with it.
Oct. 9 → Oct. 31	Form technical group; complete field inventory; map existing HL7 Military Service profiles; produce first synthetic Olive Button Bundles.	Creates the technical definition the agencies need before contract language hardens.
November	Build one read-only source adapter, FHIR mapper, validator, provenance chain, human renderer, and conformance harness.	Proves interoperability without a source-system rewrite.
December	Pilot Veteran download with synthetic or controlled data; draft OAuth scopes and developer sandbox; finalize conformance specification and contract attachment.	Produces a concrete standard before the Jan. 6 contract-review deadline.
By Jan. 6, 2027	Make Olive Button conformance language available for relevant contract modifications and future solicitations.	Directly supports EO 14426 section 2(b).
Jan. 7 → Mar. 7	Pilot Veteran-authorized API access and one downstream consumer while integrating the pattern into permanent sharing architecture.	Supports the 180-day permanent-sharing and digital-tool deadline without pretending Olive Button alone satisfies the entire order.

Weakened if: the November adapter, mapper, validator, and conformance harness are not working against one real source path by the end of December, or the conformance language is not ready by Jan. 6, 2027.

12. What not to do

Do not start by procuring a new enterprise platform.
Do not require every service personnel system to become FHIR-native internally.
Do not invent a new standard where the existing Military Service History profiles are sufficient.
Do not let an implementation vendor define the Olive Button standard before the mapping and conformance package is stable.
Do not wait for a perfect all-services mapping before proving one end-to-end source path.
Do not use AI as the source of truth for an authoritative service record; use AI around deterministic, provenance-rich data.
Do not cite the RealClearDefense article as authority. Cite EO 14426 and the primary policies below.

The sponsor ask: designate the authoritative DD214 data owners and the small cross-agency technical group now. Give them one narrow mission: define the Olive Button FHIR profile, expose one safe read-only source path, prove one Veteran download, and turn the resulting conformance package into a concrete interoperability target before the Jan. 6 contract deadline.

13. Limitations and open questions

This paper proposes an implementation pattern and does not claim more than it shows.

The FHIR mapping is an implementation hypothesis. The paper does not claim that every DD214 field already has a published FHIR mapping. The exact resource paths, code systems, value sets, extensions, cardinalities, and provenance rules are for the Olive Button technical group to determine (“What Olive Button should mean technically”).
Executive Order 14426 does not mandate FHIR, the name Olive Button, or Veteran-directed download or API access by name.
The America.gov order excludes Department of War services from its definition of covered services. It supports common access patterns but is not direct authority for Olive Button in the Department of War (“A new supporting directive: America.gov”).
Olive Button does not by itself satisfy the order’s requirement for permanent, ongoing sharing (“Implementation plan aligned to the White House clock”).
Open question: which DD214 fields have no published mapping, and how many extensions will they need?
Open question: can each source system offer a read-only path, whether a view, a replica, a stored procedure, an export, or the existing feed, without writes or schema changes?

References and authorities

Context note: A September 30, 2026 RealClearDefense article, “The Longest March Is the Paperwork,” usefully summarizes the operational stakes and deadline sequence. It is treated here as narrative context only; the authority in this memo comes from the Executive Order, statutes, DoD instructions, and OMB guidance cited below.^[1]

[1] Executive Order 14426, “Accelerating Access to Veterans’ Benefits and Employment Opportunities,” Sept. 8, 2026. Accessed 2026-10-01. https://www.whitehouse.gov/presidential-actions/2026/09/accelerating-access-to-veterans-benefits-and-employment-opportunities/

[2] White House Fact Sheet, “President Donald J. Trump Accelerates Veterans’ Access to Benefits and Employment Opportunities,” Sept. 8, 2026. Accessed 2026-10-01. https://www.whitehouse.gov/fact-sheets/2026/09/fact-sheet-president-donald-j-trump-accelerates-veterans-access-to-benefits-and-employment-opportunities/

[3] DoD Instruction 1336.01, Certificate of Uniformed Service (DD Form 214/5 Series), Feb. 17, 2022. Could not be checked: the publisher’s page returned "Access Denied" on 2026-10-01. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/133601p.pdf

[4] 38 U.S.C. §5103A, Duty to assist claimants. Accessed 2026-10-01, through law.cornell.edu because uscode.house.gov was under maintenance. https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title38-section5103A

[5] 38 U.S.C. §8111, Sharing of Department of Veterans Affairs and Department of Defense health care resources. Accessed 2026-10-01, through law.cornell.edu because uscode.house.gov was under maintenance. https://uscode.house.gov/view.xhtml?req=(title:38%20section:8111%20edition:prelim)

[6] 5 U.S.C. §552a, Privacy Act records maintained on individuals, including access/copy and disclosure rules. Accessed 2026-10-01, through law.cornell.edu because uscode.house.gov was under maintenance. https://uscode.house.gov/view.xhtml?req=(title:5%20section:552a%20edition:prelim)

[7] OMB M-21-04, Modernizing Access to and Consent for Disclosure of Records Subject to the Privacy Act, implementing the CASES Act. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-04.pdf

[8] OMB M-26-18, Scaling Use of Login.gov to Deliver a Universal Sign-on for Public Services, Aug. 31, 2026. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/2026/08/M-26-18-Scaling-Use-of-Login.gov-to-Deliver-a-Universal-Sign-on-for-Public-Services.pdf

[9] OMB M-23-22, Delivering a Digital-First Public Experience. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/2023/09/M-23-22-Delivering-a-Digital-First-Public-Experience.pdf

[10] OMB M-19-18, Federal Data Strategy - A Framework for Consistency. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/2019/06/M-19-18.pdf

[11] OMB Circular A-130, Managing Information as a Strategic Resource. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf

[12] CMS Blue Button API documentation, FHIR-based beneficiary-authorized access. Accessed 2026-10-01. https://bluebutton.cms.gov/api-documentation/

[13] CMS, Claims Data for PHRs (Blue Button), history of the VA/CMS Blue Button download pattern. Accessed 2026-10-01. https://www.cms.gov/priorities/key-initiatives/e-health/personal-records/claims-data-phrs-blue-button

[14] HL7 FHIR Implementation Guide for Military Service History and Status, Release 1 - US Realm. Accessed 2026-10-01. https://hl7.org/fhir/us/military-service/

[15] HL7 Military Service History and Status profile descriptions. Accessed 2026-10-01. https://hl7.org/fhir/us/military-service/militaryhistory.html

[16] OMB M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf

[17] OMB M-26-12, Increasing the Acquisition of Commercial Products and Services, Apr. 17, 2026. Accessed 2026-10-01. https://www.whitehouse.gov/wp-content/uploads/2026/04/M-26-12-Increasing-the-Acquisition-of-Commercial-Products-and-Services.pdf

[18] U.S. Army, “Obama announces joint virtual lifetime electronic record,” Apr. 9, 2009. Could not be checked: the publisher’s page returned "Access Denied" on 2026-10-01. https://www.army.mil/article/19508/obama_announces_joint_virtual_lifetime_electronic_record

[19] Executive Order, “Streamlining Access to Government Services Through America.gov,” Sept. 29, 2026. Accessed 2026-10-01. https://www.whitehouse.gov/presidential-actions/2026/09/streamlining-access-to-government-services-through-america-gov/

1. Jay Rogers, “The Longest March Is the Paperwork,” RealClearDefense, Sept. 30, 2026. The article synthesizes the operational implications of Executive Order 14426 and links to White House, VA, GAO, BLS, and historical VLER materials. It is used here as narrative context; the authoritative requirements in this strategy are grounded in the primary government sources listed in the references. https://www.realcleardefense.com/articles/2026/09/30/the_longest_march_is_the_paperwork_1208861.html