EHIgnite Challenge — Data Brief & Strategic Overview

What This Is: HHS launched the EHIgnite Challenge in February 2026 — a $490,000 competition to build tools that make single-patient EHI exports actually useful. This brief explains the underlying data format, the regulatory context, what "single-patient" means vs. bulk, and the opportunity space for an AI-powered solution.

1. Background — What Is EHI and Why Does It Matter Now?

EHI (Electronic Health Information) is the formal term for all electronic protected health information (ePHI) contained in a patient's Designated Record Set (DRS) — essentially everything an EHR system holds about that person. This includes clinical data, administrative records, billing history, insurance information, and anything else that would be included under the HIPAA DRS definition.

The critical regulatory moment: under the 21st Century Cures Act Final Rule (ONC §170.315(b)(10)), all certified EHR developers have been required since December 31, 2023 to provide EHI export capabilities. This is now a non-optional compliance requirement for Epic, Cerner, Oracle Health, Meditech, athenahealth, and every other certified EHR vendor.

"Since December 2023, health IT developers have been required to export EHI, but 'computable' doesn't always mean 'usable.' Raw exports are often overwhelming and difficult to integrate." — HHS/ASTP, EHIgnite Challenge site

The mandate created a paradox: patients and clinicians now have a legal right to this data, and EHRs are legally required to provide it — but the exports are technically compliant while being practically unusable. That gap is what this competition targets.

2. The Data Format — What a Single-Patient EHI Export Actually Looks Like

Primary Format: FHIR R4 NDJSON

The dominant format for EHI exports is HL7 FHIR R4 (Fast Healthcare Interoperability Resources, version 4), delivered as NDJSON (Newline-Delimited JSON) files inside a ZIP archive. Each line in an NDJSON file is one complete, self-contained FHIR resource JSON object.

{"resourceType":"Patient","id":"abc123","name":[{"family":"Smith","given":["Jane"]}],"birthDate":"1985-03-14","gender":"female","address":[{"line":["123 Main St"],"city":"Los Angeles","state":"CA","postalCode":"90024"}]}
{"resourceType":"Condition","id":"def456","subject":{"reference":"Patient/abc123"},"code":{"coding":[{"system":"http://snomed.info/sct","code":"44054006","display":"Type 2 diabetes mellitus"}]},"onsetDateTime":"2019-07-12","clinicalStatus":{"coding":[{"code":"active"}]}}
{"resourceType":"MedicationRequest","id":"ghi789","subject":{"reference":"Patient/abc123"},"medicationCodeableConcept":{"coding":[{"system":"http://www.nlm.nih.gov/research/umls/rxnorm","code":"860975","display":"metformin 500 MG Oral Tablet"}]},"status":"active","intent":"order"}

A typical patient ZIP export contains multiple NDJSON files, one per resource type:

File	FHIR Resource Type	What It Contains
Patient.ndjson	Patient	Demographics, contact info, identifiers
Condition.ndjson	Condition	Diagnoses, problem list (coded via SNOMED/ICD-10)
MedicationRequest.ndjson	MedicationRequest	Prescriptions, ordered medications (coded via RxNorm)
Observation.ndjson	Observation	Labs, vitals, social history, smoking status (coded via LOINC)
Encounter.ndjson	Encounter	All visits — inpatient, outpatient, ED, telehealth
Procedure.ndjson	Procedure	Surgeries, interventions (coded via CPT/SNOMED)
AllergyIntolerance.ndjson	AllergyIntolerance	Drug, food, environmental allergies
Immunization.ndjson	Immunization	Vaccine history (coded via CVX)
DiagnosticReport.ndjson	DiagnosticReport	Pathology, radiology, and other reports
DocumentReference.ndjson	DocumentReference	Clinical notes (often base64-encoded C-CDA XML inside FHIR)
CarePlan.ndjson	CarePlan	Goals, care activities, planned interventions
Coverage.ndjson	Coverage	Insurance coverage, payer info, member IDs
Device.ndjson	Device	Implantable devices, medical equipment

Important: The format is vendor-flexible. ONC requires EHRs to document their export format, but does not mandate a specific structure. Epic exports look different from Cerner exports. Some vendors mix FHIR NDJSON with C-CDA XML, proprietary CSV files, or PDF attachments in the same ZIP. This inconsistency is a core problem the EHIgnite Challenge is trying to solve.

Alternative / Supplemental Formats

C-CDA (Consolidated Clinical Document Architecture): Older XML-based format still used by many vendors for clinical summaries (especially for notes)
CSV: Some vendors export structured data as flat CSV files alongside FHIR
PDF / Binary attachments: Scanned documents, radiology images, pathology reports often come as binary blobs inside DocumentReference resources
HL7 v2: Legacy format still present in older EHR environments

3. Single-Patient vs. Bulk (Population) Export — A Critical Distinction

The ONC certification requirement (§170.315(b)(10)) has two distinct sub-requirements, and the EHIgnite Challenge focuses specifically on the first:

Mode	ONC Provision	Who Triggers It	Use Case	Challenge Relevance
Single-Patient Export	§170.315(b)(10)(i)	Patient request, care team request for one patient	Patient obtains their records; second opinion; care transitions; insurance claims	PRIMARY TARGET
Patient Population Export	§170.315(b)(10)(ii)	Health system admin or IT team	EHR migration, data warehousing, population health analytics, research	OUT OF SCOPE for this challenge

What Makes Them Different in Practice

Single-Patient Export: The Patient-Centric View

Triggered per-patient, typically on demand (patient portal request, provider request)
Contains ALL EHI for that individual — not just the USCDI subset
Delivered as a ZIP download — patients get a file, not an API stream
Designed for human consumption and care coordination, not analytics
Volume: a complex patient may have 10,000+ FHIR resources spanning 10+ years
HIPAA requires response within 30 days; many portals deliver in minutes

Patient Population (Bulk) Export: The Operational View

Triggered by the health system, not the patient — for operational/administrative needs
Covers all patients in a practice or system simultaneously
Delivered via FHIR Bulk Data Access API (asynchronous, server-to-server)
Used for: EHR migrations, analytics platforms, research datasets, population health
Not generally available to patients — this is an IT/admin function
Same FHIR R4 NDJSON format, but at massive scale (millions of resources per export)

Can EHI Be Used as a General Patient Data Exchange Platform? In short — yes, this is exactly what the regulatory framework envisions, but the infrastructure is immature. The SMART Health IT team (MIT/Harvard) has built a reference EHI Export API specification (via HL7's Argonaut Project) that enables apps to programmatically request and receive a patient's EHI export. This would allow patients to authorize an app or clinician to receive their export — essentially a secure, patient-mediated data exchange. The Apple Health app and CommonHealth app already do this for the USCDI subset via SMART on FHIR. Extending this to the full EHI export is the frontier.

4. EHI as an Exchange Platform — The Broader Vision

The regulatory architecture supports three distinct exchange modes, each with different maturity:

Exchange Mode	Mechanism	Current Maturity	Notes
Patient Download	ZIP via patient portal	Live / Required	All certified EHRs must support this now. File-based, not streaming.
App-Mediated API	SMART on FHIR + EHI Export API	Emerging	Draft IG published by Argonaut/HL7. Apple Health uses this for USCDI. Full EHI via API is not yet widespread.
Provider-to-Provider Exchange	Patient-authorized data push	Emerging	Patient can authorize their data to go to a new provider. Technically possible via FHIR APIs; workflow still manual at most health systems.
Payer Workflows	Structured data packaging for insurers	Nascent	Prior auth, appeals, utilization review — huge administrative burden, largely still fax/PDF. One of the EHIgnite use cases.
Research Donation	Patient-consented EHI contribution	Nascent	HL7 Argonaut reference app ("Second Opinion App") demonstrates a patient donating their EHI for research. No production examples at scale.

Key Technical Resources Available

Synthetic Patient Data (Synthea): MIT's Synthea generates realistic FHIR R4 patient records. SMART on FHIR's GitHub hosts pre-generated bulk datasets of 10, 100, and 1,000 patients in NDJSON format — free, open-source, no PHI concerns.
→ github.com/smart-on-fhir/sample-bulk-fhir-datasets
EHI Export API Reference Implementation: SMART Health IT (Boston Children's Hospital/Harvard) built a complete open-source EHI server + patient app using Synthea data. The server handles export requests; the patient app ("Second Opinion App") demonstrates requesting, downloading, and sharing a complete EHI export.
→ github.com/smart-on-fhir/ehi-server | github.com/smart-on-fhir/ehi-app
HL7 Argonaut EHI Export API Draft IG: The standards-track specification for programmatic EHI access.
→ build.fhir.org/ig/argonautproject/ehi-api/ehi-export.html

5. What Tools Can Be Built on Top of EHI Exports

The EHIgnite Challenge specifically calls for tools that convert raw FHIR NDJSON into usable experiences. Here is the landscape of what's technically feasible today:

Tool Type	Input	Output	Technical Approach	AI Role
Patient Q&A	Single-patient FHIR ZIP	Conversational answers in plain language	Parse FHIR → index resources → RAG over LLM	Core
Clinical Summary	Single-patient FHIR ZIP	Structured summary document (problem list, meds, allergies)	FHIR parser → template rendering + LLM synthesis	Core
Domain Filtering	Single-patient FHIR ZIP	Specialty-specific view (e.g., cardiology only)	Resource type filtering + SNOMED/ICD taxonomy mapping	Assistive
Multi-EHR Stitching	Multiple FHIR ZIPs from different health systems	Unified longitudinal record	Entity resolution (patient matching) + deduplication	Core
Payer Package Builder	Single-patient FHIR ZIP	Structured prior auth / appeals package	Rule engine (payer-specific requirements) + FHIR extraction	Assistive
Timeline Visualization	Single-patient FHIR ZIP	Interactive health timeline (web or PDF)	Encounter + Condition + Observation date extraction → UI	Assistive
Medication Reconciliation	Single-patient FHIR ZIP (or multi-source)	Reconciled medication list with interaction flags	MedicationRequest parsing + drug interaction API	Core
Second Opinion Prep	Single-patient FHIR ZIP	Curated brief for specialist review	LLM with specialist context + FHIR resource selection	Core

6. The Core Technical Challenge — Why This Is Hard

Problem 1: Format Inconsistency Across EHRs

Epic's FHIR export ≠ Cerner's export ≠ Meditech's export. Each vendor interprets the standard differently. Custom extensions, proprietary codes, and non-standard resource structures are common. A robust solution must handle this variance gracefully — either by normalizing to a common model or by building vendor-specific adapters.

Problem 2: Scale and Complexity

A patient with 10 years of chronic disease management at a major academic medical center may have 30,000+ FHIR resources in their export. Observations alone (labs, vitals, social history) can run into the thousands. Naive approaches (e.g., dumping everything into an LLM context window) fail immediately. Smart indexing, resource prioritization, and retrieval-augmented generation (RAG) are necessary.

Problem 3: Clinical Coding Literacy

EHI is coded in multiple clinical terminology systems: SNOMED CT (conditions, procedures), LOINC (labs, observations), RxNorm (medications), ICD-10 (diagnoses), CPT (procedures), CVX (vaccines). A useful tool must be able to interpret these codes — either by maintaining code lookups or by leveraging LLMs trained on medical ontologies. "44054006" should be understood as "Type 2 diabetes mellitus."

Problem 4: HIPAA and Privacy by Design

EHI is among the most sensitive personal data that exists. Any tool in this space must demonstrate: data minimization, secure processing (ideally in the patient's own environment or a BAA-covered cloud), no retention without explicit consent, and audit logging. For the competition, proposals will be judged on privacy and security — this is not optional.

7. The EHIgnite Challenge — What They're Asking For

Phase 1 deadline: May 13, 2026 (concept proposal + wireframes)
Up to 9 winners × $10,000 each → invited to Phase 2
Phase 2 prizes: $250K / $100K / $30K + $20K AI Innovation bonus
Registration: ehignitechallenge.org

Phase 1 requires a concept and design addressing summarization plus at least one of:

Interactive patient tools — Patients ask questions about their own data in plain English and receive accurate, understandable responses
Clinical domain filtering — Customized views organized by relevant clinical specialty or workflow need
Multi-setting integration — Stitching together exports from multiple EHRs into a unified longitudinal record
Streamlined payer workflows — Packaging EHI for insurance coverage, prior authorization, or appeals
Participant-defined use case — Open-ended, propose your own

Judging criteria (100-point scale):

Relevance and problem alignment
Potential for scaling
Ease of use
Privacy and security
Use of AI
Bonus: multi-EHR interoperability

8. Strategic Fit & Opportunity Assessment

From a product and technical perspective, the core ask of this challenge is: build an LLM-powered agent that ingests a patient's FHIR R4 export and makes it conversationally accessible.

This is architecturally equivalent to the enterprise AI assistant work already underway — an agent that reads structured domain data, indexes it, and answers natural-language questions. The FHIR domain is arguably more tractable than raw claims data because:

The schema is standardized (FHIR R4 resources are well-documented)
Synthetic data is freely available for development (Synthea)
Clinical coding ontologies (SNOMED, LOINC, RxNorm) are open and machine-readable
The user needs are concrete and validated (patients want to understand their health records)

Key differentiators for a competitive submission:
(1) Deploy inside the patient's or provider's Azure environment — data never leaves their control. This directly addresses the privacy/security judging criterion.
(2) Demonstrate multi-EHR stitching using entity resolution (NPI matching, demographic matching) — directly targets the interoperability bonus.
(3) Build the clinical domain filtering on top of real code ontologies — show that "cardiology filter" means mapping ICD-10 I-codes + CPT cardiac procedures + relevant LOINC labs.
(4) Include a clinician-facing view alongside the patient view — the challenge talks about both audiences.

For a Clinician's Perspective — Questions Worth Exploring

As someone working directly with patients and EHR data, the most valuable input would be:

What information do you actually wish you had faster access to when seeing a patient for the first time?
How often do you get a patient's records from another health system — and how usable are they today?
What would a "second opinion prep" package need to contain to actually be useful?
What's the biggest bottleneck in payer workflows you encounter — prior auth? appeals? something else?
If a patient handed you a 1-page AI-generated summary of their full record, what would need to be on it?

Sources: HHS/ASTP EHIgnite Challenge website (ehignitechallenge.org) · ONC §170.315(b)(10) EHI Export Factsheet · HL7 FHIR R4 Specification · SMART Health IT EHI Export API project (Boston Children's Hospital / Harvard Medical School) · SMART on FHIR sample-bulk-fhir-datasets (GitHub) · TechTarget SearchHealthIT · HCI Innovation Group · Drummond Group ONC Certification · Firely Server FHIR Documentation · eClinicalWorks Interoperability · CharmHealth EHR

Prepared by Chief (OpenClaw) — March 11, 2026