The VA EHRM Opportunity Map.
Companion to “The Interoperability Problem VA Already Solved.” The public issue drew the line between interoperability and migration. This is the operator’s companion: where the money is, what to propose, and the risk basis that justifies it. The federation-versus-consolidation distinction becomes an opportunity map, the standards become the language a response has to speak, and the inspector general’s findings become a failure-to-remedy bridge you can build a technical volume on.
★ Premium Capture Corner
The full operator’s companion: the opportunity sized from the public record, the three lanes that do not compete for the same dollar, the exact standards baseline a response has to speak, the reference architecture VA already validates, and every documented OIG failure mapped to the proven remedy it justifies. Free members see the framing; premium gets the full board.
See premium plansCapture Corner is the premium BD intelligence companion to Mission Meets Tech. Public-record sourced. Independent analysis. Not a recommendation, not vendor advocacy, not capture material. Built for federal health BD, capture, and proposal leaders who need analytical depth, not headlines.
This issue is the operator's companion to the public piece, "The Interoperability Problem VA Already Solved." It turns the federation-versus-consolidation distinction into an opportunity map, the standards into the language a response has to speak, and the inspector general's findings into a failure-to-remedy bridge you can build a technical volume on. Public-record sourced. Not a recommendation, not vendor advocacy.
Timing note. This posts the morning of Monday, June 22. If you have a response due today in VA interoperability or EHR modernization, Sections 3 through 5 are built to be mined now. Section 3 is the standards baseline a responsive submission has to speak. Section 4 is the reference architecture to propose. Section 5 turns the documented failures into the scope justification. The capture-window guidance in Section 7 is for the pursuits behind this one. Everything here is public-record and solicitation-agnostic.
1. The opportunity, sized
The program is funded, large, and still growing. What is public tells a capture lead where the work actually sits.
| Component (public record) | Figure | What it tells you |
|---|---|---|
| EHR contract, Oracle (FY18–Q2 FY25) | $5.85B | The prime's lane. Not yours unless you team Oracle |
| IT infrastructure (same period) | $3.35B | Cloud, hosting, network, integration. Open lane |
| Program management (same period) | $1.48B | PM, IV&V, oversight-responsive work. Open lane |
| Total obligated to date | ~$13.84B | Spent through Q2 FY25 |
| Current estimate to lawmakers (2026) | ~$37B | The forward envelope, still unbaselined |
| Legacy VistA sustainment | ~$900M/yr | Runs until each instance retires, through 2031 |
| Sites: total / live / remaining | 164 / 10 / ~154 | The deployment runway to 2031 |
Sources: [CC1][CC2][CC3][CC4]
Read it this way. The Oracle contract is one line. The infrastructure and program-management lines, roughly $4.8 billion combined through Q2 FY25 and still climbing, plus the $900-million-a-year sustainment tail, are where the broader contractor base works. The headline is the prime's. The runway is everyone else's.
2. Two problems, three lanes
The public issue drew the line: interoperability and migration are different problems, and VA already solved the first through federation. That line sorts the opportunity space into three lanes that do not compete for the same dollar.
| Lane | What it is | Why it persists |
|---|---|---|
| The deployment wave | Data migration, terminology mapping, validation, training, change management at each go-live site | Runs site by site through 2031 |
| The federation layer | Sustainment of VDIF-EP and the Lighthouse FHIR façade, the bridge keeping 130 instances exchanging until full cutover | Runs in parallel until the last site converts |
| The VA-DoD seam | The FEHRM interface work behind a single shared federal record | The interoperability prize the migration actually buys |
Position to the lane. A team pitching "we deliver interoperability" is selling the press release. A team that names its lane and shows validation evidence is selling the work.
Public-record market context, not endorsement: the federation layer runs on InterSystems HealthShare, delivered by a documented team that includes VetsEZ, Ready Computing, and J2 Interactive.[CC5] The federal interface engine named in FEHRM's own reporting is Rhapsody.[CC6] Oracle holds the EHR contract. Know the incumbents before you build a teaming theory.
3. The compliance baseline a response has to speak
A responsive submission in this space has to name the federal standards baseline exactly. Propose to the floor, not above it. Naming the wrong version tells the evaluator you do not know the rule.
| Standard | Status | What to propose |
|---|---|---|
| FHIR R4 (v4.0.1) | Federal certification baseline (ONC Cures Rule) | Propose R4. R5 is trial-use, not the floor |
| US Core STU7 (v7.0.0) | USCDI v4-aligned, current published release | The US-realm profile every certified system implements |
| USCDI v3 | ONC certification baseline since Jan 1, 2026 (HTI-1) | The data-element floor |
| SMART App Launch 2.2.0 | Required under ONC §170.315(g)(10) | OAuth 2.0 + PKCE app authorization |
| FHIR Bulk Data v2.0.0 | $export operation |
The EHR-to-EHR population migration mechanism |
| HL7 v2-to-FHIR IG | Maturity Level 1 (trial-use) | Pin to a published release; budget local Z-segment work |
| Conformance | Inferno + NIST tooling | The gate every claim has to pass |
Sources: [CC7][CC8]
The single most common tell in a weak technical volume here is proposing R5 because it is newer. R4 plus US Core plus USCDI v3 is the certification floor. Build to it.
4. The reference architecture to propose
A credible technical approach is not a product. It is a layered architecture VA's own builds already validate.
The stack, four layers:
- API gateway: OAuth and SMART enforcement, rate-limiting, observability, for FHIR traffic
- Integration engine: HL7 v2 normalization for the legacy estate
- Event-streaming backbone (Kafka): high-throughput real-time feeds
- FHIR server / clinical data repository: the canonical store
Pick the façade pattern to the situation:
- Broker: federate queries across multiple VistA instances
- Façade: front a VistA instance that cannot be modified
- Repository: native FHIR persistence after migration
For 130 instances mid-migration, broker plus façade is the transitional answer, and VA already runs it. The Lighthouse FHIR API is a FHIR R4 and US Core façade over VistA on a Google Apigee gateway, the model in use during the migration window.[CC9]
The migration method is strangler-fig with Kafka. Each VistA instance's outbound v2 interfaces become producers. As a site goes live, consumers switch from legacy v2 feeds to FHIR topics. The legacy interface runs until cutover, then retires. The decisive capability is replay: run 30, 60, or 90 days of real events through the new mappings, diff old output against new, and catch the mismatch in a test environment before a clinician meets it.[CC10]
If a technical approach cannot name the façade pattern, the conformance gate, and the replay-validation step, it is a brochure, not an architecture.
5. The risk basis that justifies the scope
The strongest scope justification in this program is the public record. Every documented failure is a fundable remedy, and a credible response ties the two together. This is the requirement-to-past-performance bridge, built from the inspector general's own findings.
| Documented VA failure (public record) | The remedy you propose | Maturity |
|---|---|---|
| Unknown queue: 11,000+ orders undelivered, no clinician alert | Integration-engine ACK/NAK and dead-letter queues; replay diff to detect non-delivery | Production-proven |
| Pharmacy data corruption: ~120,000 patients affected | Terminology normalization at the canonical layer; migration-validation diff | Normative / Production |
| 826 incidents, 1,909 hours downtime; ~77% from configuration management and monitoring | CI/CD conformance dashboard (Inferno + NIST); change-control gates | Production |
| ~30% productivity loss for 18 months post-go-live (DoD benchmark) | Workflow design, role-based training, change management, hypercare | Established |
| Big-bang cutover risk; legacy data not consistently migrated | Strangler-fig phased parallel-run; Bulk $export |
Production-proven |
Sources: [CC11][CC12][CC13][CC14][CC10]
Used right, this table is the spine of a technical volume. It says you understand the problem from the government's own oversight record, and you propose the proven remedy, not a promise. The 77-percent configuration-management figure alone justifies a standing investment in monitoring, change control, and observability, recurring work across every one of the 154 sites still to convert.
6. The diligence questions
Whether you are bidding the work, teaming into it, or assessing a partner's readiness, these five separate a real validation program from a go-live date.
- Terminology mapping coverage. How much of the site's local vocabulary is mapped to LOINC, SNOMED, and RxNorm, and how is "done" measured? A percentage with a test behind it is an answer. A date is not.
- Validation method. Is there a parallel run, a replay of real traffic, and an output diff before cutover? That is what catches the unknown-queue class of failure.
- Conformance. Which suite, Inferno or the NIST tooling, gates the build, and against which US Core and USCDI version?
- The human gate. Who signs the safety-critical mappings, and what halts a cutover? If the answer is no one, the validation is theater.
- Rollback. What is the contingency when a go-live degrades, and how fast can a site fall back?
Bring these to a teaming call and you learn in ten minutes whether a partner has a validation program or a calendar.
7. Capture windows and what to do this week
The June wave is effectively closed for positioning. Chillicothe goes live June 6, with the Cincinnati, Cincinnati-Fort Thomas, and Dayton cluster following in June. The open windows are August, three Indiana centers including Roudebush in Indianapolis, and October, Alaska and Ohio.[CC15][CC16] Behind them runs the long tail: 164 sites, 10 live, roughly 154 to convert by 2031, on a market-based selection model with a standardized national baseline.[CC1] That national baseline is the signal that this becomes repeatable, productized delivery, not 154 bespoke projects.
What to do this week:
- Mine Sections 3 through 5 into your live response today. The standards baseline, the reference architecture, and the failure-to-remedy bridge are submission-ready.
- Map your pipeline to the three lanes. Drop the pursuits that are really "interoperability" with no lane behind them.
- Position August and October now. The June window has closed. The readiness cycle opens months ahead of each go-live.
- Run the five diligence questions on any teaming partner before you commit a slot.
- Track GAO, not just VA. The open-recommendations and missing-cost-estimate findings are the leading indicator of where oversight-driven IV&V and program-management work gets funded.
Editorial discipline note
Capture Corner is built to be useful, not provocative. It is solicitation-agnostic and does not respond to, reference, or tailor to any specific open procurement. It does not name a preferred vendor or recommend a build-or-buy or teaming choice for your firm. It does not characterize any contractor's performance beyond what public records and the parties' own published claims support. It does not reveal nonpublic information. Every figure, incumbent, schedule item, standard, and oversight finding here is drawn from public VA, GAO, FEHRM, OIG, ONC, and HL7 records and reporting. What it does is turn the public issue's argument into the opportunity map and response-ready intelligence a federal health capture lead actually has to assemble. Use it accordingly.
Mary
Mission Meets Tech Premium
The views expressed in this newsletter are my own and do not represent the official position of any organization. This content is for informational purposes only.
Sources
[CC1] VA EHR Deployment Schedule and VA News press room, 2026. 164 medical centers targeted; 10 currently live; four Michigan sites live Apr 11, 2026; 13 sites in 2026; full deployment as early as 2031; market-based site selection and a standardized national baseline. https://digital.va.gov/ehr-modernization/ehr-deployment-schedule/ ; https://news.va.gov/press-room/va-health-record-system-back-on-track-with-michigan-deployments/
[CC2] Nextgov/FCW, Apr 2026. Total cost estimate to lawmakers ~$37B; full deployment targeted as early as 2031. https://www.nextgov.com/modernization/2026/04/va-resumes-ehr-rollouts-four-michigan-medical-sites/412807/
[CC3] GAO-26-108812, Statement of Carol C. Harris, Dec 15, 2025. ~$13.84B obligated FY18–Q2 FY25 (EHR contract $5.85B; IT infrastructure $3.35B; program management $1.48B); 16 of 18 recommendations not fully implemented; no current cost estimate or detailed schedule. https://docs.house.gov/meetings/VR/VR11/20251215/118749/HHRG-119-VR11-Wstate-HarrisC-20251215.pdf
[CC4] Military Times, Mar 2023, citing House VA hearing testimony. VistA sustainment ~$900M (FY2022). https://www.militarytimes.com/veterans/2023/03/07/vet-agency-asks-why-fix-outdated-but-outgoing-record-system/
[CC5] VA VDIF-EP FY2025 Privacy Impact Assessment (InterSystems HealthShare COTS suite); Ready Computing VA VDIF case study (delivery-team context: VetsEZ, Ready Computing, J2 Interactive). https://department.va.gov/privacy/wp-content/uploads/sites/5/2024/11/FY25VeteransDataIntegrationandFederationEnterprisePlatformPIA.pdf ; https://readycomputing.com/wp-content/uploads/2026/02/VA_CaseStudy_NoDate.pdf
[CC6] FEHRM Interoperability Progress Quarterly Report, Q4 FY2022. Rhapsody named as the interface engine for the federal "one interface team." https://www.fehrm.gov/images/q4-fy2022-fehrm-interoperability-progress-report_508.pdf
[CC7] ONC HTI-1 Final Rule; §170.315(g)(10) standardized API criteria; USCDI v3 certification baseline effective Jan 1, 2026. https://healthit.gov/regulations/hti-rules/hti-1-final-rule/ ; https://www.healthit.gov/test-method/standardized-api-patient-and-population-services
[CC8] HL7 standards: US Core IG v7.0.0 (STU7); FHIR R4 v4.0.1 (federal baseline via ONC Cures Rule); SMART App Launch 2.2.0; FHIR Bulk Data Access v2.0.0; HL7 v2-to-FHIR Implementation Guide. https://hl7.org/fhir/us/core/ ; https://hl7.org/fhir/smart-app-launch/ ; https://hl7.org/fhir/uv/bulkdata/
[CC9] VA Lighthouse FHIR API PIA FY2025. FHIR R4 / US Core façade over VistA on a Google Apigee gateway; the model in use during the migration window. https://department.va.gov/privacy/wp-content/uploads/sites/5/2025/02/FY25LighthouseFastHealthcareInteroperabilityResourcesAPIPIA.pdf
[CC10] Kafka strangler-fig migration with replay-based validation (engineering reference); FHIR Bulk Data $export for EHR-to-EHR transfer. https://www.kai-waehner.de/blog/2025/03/27/replacing-legacy-systems-one-step-at-a-time-with-data-streaming-the-strangler-fig-approach/ ; https://hl7.org/fhir/uv/bulkdata/
[CC11] VA OIG Report No. 22-01137-204, Jul 14, 2022. Unknown queue: more than 11,000 orders undelivered with no clinician alert. https://www.vaoig.gov/sites/default/files/reports/2022-07/VAOIG-22-01137-204.pdf
[CC12] VA OIG Report No. 23-01450-114, Mar 21, 2024. Pharmacy-related data issues affecting ~120,000 patients. https://www.vaoig.gov/sites/default/files/reports/2024-03/vaoig-23-01450-114.pdf
[CC13] VA OIG Report No. 22-03591-231, Sep 23, 2024. 826 major incidents; 1,909 hours of downtime (Oct 2020–Mar 2024); ~77% of downtime hours from configuration management and monitoring. https://www.vaoig.gov/sites/default/files/reports/2024-09/vaoig-22-03591-231.pdf
[CC14] VA OIG Statement, Deputy IG David Case, Jul 21, 2021. DoD benchmark: ~30% productivity decrease for 18 months after go-live. https://www.vaoig.gov/sites/default/files/document/2023-08/VAOIG-statement-20210721-Case.pdf
[CC15] Healthcare Dive, Apr 2026. 2026 wave schedule: Chillicothe, Cincinnati, Cincinnati-Fort Thomas, and Dayton in June; three Indiana sites in August; Alaska and Ohio in October. https://www.healthcaredive.com/news/veterans-affairs-va-medical-centers-michigan-oracle-ehr/817470/
[CC16] VA Chillicothe Health Care, EHR Modernization. Chillicothe Federal EHR go-live June 6, 2026. https://www.va.gov/chillicothe-health-care/programs/electronic-health-record-modernization/
Want a custom deep-dive on any line in this brief?
This Capture Corner sizes the opportunity, names the three lanes, sets the standards baseline, and maps the OIG failures to proven remedies. Where it stops short — scoring your technical approach against the reference architecture, profiling the incumbent team on the federation layer, building the failure-to-remedy bridge for one specific OIG finding, or reading a likely August or October site against your validation method — the next layer of intelligence is custom by request.
I will pull the additional public-record sources, read the visible signal, and write a 4–6 page custom intelligence memo on the area you select. You name the question; I do the BD-grade analysis.
Buy a Custom Deep Dive — $50 →
Examples: "VA EHRM Deep Dive — score [my technical approach] against the four-layer reference architecture" · "Deep Dive — the incumbent team and teaming map on the federation layer" · "Deep Dive — build the failure-to-remedy bridge for the 77% configuration-management finding" · "Deep Dive — a likely August Indiana site read against my replay-validation method"