Request My Ehi

Request My EHI Export

First-Time Setup

Before using any scripts, install dependencies in the skill's scripts directory:

cd /scripts && bun install

This installs pdf-lib for PDF generation/manipulation. All scripts in this skill use Bun (not Node.js).

Optional: pdftoppm from poppler-utils (apt install poppler-utils) is useful for rendering PDFs to images for visual verification.

Script usage pattern:

bun /scripts/.ts [arguments]

Background: What Is an EHI Export and Why Does It Matter?

Every patient has a right to their complete medical record. In practice, when patients request "their records," they usually get a small, curated summary (a CCDA document or MyChart printout) that omits the vast majority of the data their provider actually stores about them.

The EHI Export is different. It's a certified feature (ONC § 170.315(b)(10)) that all EHR vendors have been required to support since December 31, 2023. It produces a bulk export of all structured data in a patient's record -- the format varies by vendor (TSV files for Epic, CSV/NDJSON/SQL for others) but the result is the same: the closest thing to a complete copy of everything the provider's system knows about the patient.

Most patients don't know this feature exists, and many providers haven't used it before. Your job is to be a knowledgeable, patient, and supportive guide -- helping the patient understand what they're asking for, why they're entitled to it, and how to navigate any friction they encounter.

This skill supports Epic and 70+ other certified EHR vendors. You can identify the vendor from the patient's portal URL or provider name, then generate vendor-specific documentation.

Key concepts to convey to the patient

• EHI Export is NOT the same as a CCDA, patient portal download, or standard records release. Those are summaries. The EHI Export is the full database extract.
• It's their legal right. HIPAA's Right of Access (45 CFR § 164.524) entitles patients to receive their PHI in the electronic form and format they request, if readily producible. Since EHI Export is a built-in certified feature, it is readily producible.
• Refusing is potentially information blocking. Under the 21st Century Cures Act (45 CFR Part 171), declining to use an available, certified export feature when a patient requests it could constitute information blocking.
• The provider must act within 30 days (with one 30-day extension if they notify the patient in writing).
• Patient identifiers should NOT be encrypted in the patient's own copy -- since it's their data, encrypted IDs make it unusable.
• Every certified EHR has this feature. The format varies by vendor -- Epic uses TSV, others use CSV, NDJSON, SQL, etc. -- but the legal requirement is the same across all vendors.

What You're Producing

A ready-to-submit PDF package consisting of:

1. A cover letter (page 1) addressed to the records department -- explains what's being requested and suggests routing
2. An access request form (page 2) filled with the patient's details -- ideally the provider's own ROI form, or our generic HIPAA-compliant access request form if the provider's form isn't available
3. An appendix (page 3) explaining what EHI Export is, legal basis, and how to produce it

Step 1: Identify the Provider

Your first question should be: "What's the name of the doctor or clinic you want to request records from?" A website or patient portal URL is also great if they have one.

Don't ask about EHR systems, vendors, or technical details -- that's your job to figure out, not the patient's. If the patient already told you the provider name (e.g., as an argument when invoking the skill), skip ahead.

Be ready to explain things in plain language if the patient has questions. Many patients are frustrated because they've asked for "all my records" before and received an incomplete summary. Validate that experience and explain how the EHI Export addresses it.

Step 2: Identify the EHR Vendor

Once you know the provider, figure out which EHR system they use. This determines the vendor-specific details in the appendix (export format, documentation URL, entity counts, etc.). This is a web research task -- search for information about the provider online. Don't ask the patient what EHR their doctor uses.

How to identify the vendor

1. Check their patient portal URL (if the patient provided one) -- the domain often reveals the vendor:

• mychart.* or *.epic.com → Epic
• *.athenahealth.com or *.athenanet.athenahealth.com → athenahealth
• *.eclinicalworks.com → eClinicalWorks
• *.nextgen.com → NextGen
• *.allscripts.com or *.veradigm.com → Veradigm/Allscripts
• *.elationhealth.com → Elation Health
• *.drchrono.com → DrChrono
• *.kareo.com → Kareo/Tebra
• *.advancedmd.com → AdvancedMD
• *.modmed.com → Modernizing Medicine

1. Search the web for "[provider name]" EHR or "[provider name]" "electronic health record" or "[provider name]" "patient portal"
2. Check CHPL (ONC Certified Health IT Product List) if needed
3. Ask the patient as a last resort -- they may know (e.g., "we use Epic" or "we use athena")

Look up vendor details

Use the vendor database at https://joshuamandel.com/ehi-export-analysis/data/vendors.json (71 vendors with detailed export information). The lookup script makes this easy:

bun /scripts/lookup-vendor.ts "athena"

This returns the vendor's:

• Product name and developer
• Export formats (CSV, NDJSON, TSV, SQL, etc.)
• EHI documentation URL -- the official vendor page documenting their export
• Entity/field counts -- how many data tables and fields the export includes
• Grade and coverage -- quality assessment of the export
• Analysis report URL -- a detailed markdown report you can fetch for deeper details

If the vendor has an analysis report, fetch it to learn:

• How the export is produced (UI-based? API? bulk?)
• What data categories are included (clinical, billing, scheduling, etc.)
• Any quirks or limitations
• Specific instructions for the provider's IT team

# The analysis report URL follows this pattern:
# https://joshuamandel.com/ehi-export-analysis/data/analyses/{slug}.md

If you can't identify the vendor

If you can't determine the vendor from web searches, ask the patient if they happen to know. If not, default to generic language in the appendix. The legal requirements are the same regardless of vendor -- every certified EHR must support EHI Export.

Step 3: Gather Patient Details

Ask the patient for their information. They can either:

• Upload a file (e.g., a FHIR Patient resource JSON, or any structured file with their details)
• Provide details directly in conversation

You need:

• Full name
• Date of birth
• Street address, city, state, zip
• Phone number
• Email address

If they provide a FHIR Patient resource or similar file, extract all details from it. Confirm the details with the patient before proceeding.

Step 4: Find and Obtain a Request Form

Using the provider's own ROI (Release of Information) form reduces friction -- staff recognize their own paperwork and are more likely to process it without pushback. Always attempt the provider's form first, whether it has fillable fields or not. But it's not required. HIPAA requires that the patient put the request in writing if the covered entity asks (45 CFR § 164.524(b)(1)). If you can't find the provider's form, use our generic access request template instead.

Finding the provider's form

Help the patient get this form through multiple approaches:

1. Ask if they have it already -- they may have downloaded it from their provider's website or picked one up at the office.
2. Search the web with several query variations:

• "[provider name]" "authorization" "release" "protected health information" filetype:pdf
• "[provider name]" "medical records" "release form" filetype:pdf
• "[provider name]" "ROI" OR "release of information" form filetype:pdf
• "[provider name]" "request" "own records" OR "own medical records" filetype:pdf
• "[provider name]" "patient access" "health information" filetype:pdf
• site:[provider-domain] authorization release

1. Navigate the provider's website -- look for sections like:

• "Patients & Visitors" / "Patient Resources" / "Forms"
• "Medical Records" / "Health Information Management (HIM)"
• "Release of Information" / "Request Your Records"

1. Check if the provider is part of a larger health system -- the form may be on the parent system's website rather than the individual clinic's.
2. Look for the provider's patient portal -- some portals have downloadable forms.

Choosing the right form

Providers often have multiple forms for different purposes. When you find more than one, apply these preferences:

1. Prefer patient-access forms over third-party release forms. Some providers have a separate form specifically for patients requesting access to their own records (sometimes called "Patient Access Request," "Request for Own Records," or "Individual Right of Access"). This is distinct from the general ROI form used to release records to a third party (another doctor, insurer, attorney, etc.). The patient-access form is a better fit because we're requesting records for the patient themselves. If no separate patient-access form exists, the general ROI form is fine.
2. Prefer the most recent version. Forms are sometimes revised -- look for dates, version numbers, or "revised" labels on the form itself or in the filename/URL. When multiple versions exist, use the most recent one.
3. Prefer the provider's own form over a generic state or federal form, unless the provider's website explicitly directs patients to use that external form.

Downloading and verifying the form

Once you've identified a candidate form URL, follow these steps in order:

1. Download with a realistic user agent to avoid bot blocking:

``bash curl -sL -o provider_form.pdf \ -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" \ "" `` If the download fails (network error, CAPTCHA, 403), share the link with the patient and ask them to download and share the file back to you: > "I found what looks like your provider's records release form at [URL], but I'm having trouble downloading it directly. Could you click that link, download the PDF, and share it with me? Then I can fill it out for you."

1. Verify this is actually a records release/authorization form. Extract the text and review it:

``bash pdftotext ./provider_form.pdf - | head -80 ` Read the output and confirm this document is a form the patient can use to authorize release of their own health information. If it's something else (privacy notice, patient rights brochure, billing form, general informational document), discard it and continue searching. If pdftotext` returns no text at all, the PDF is likely a scanned image — fall back to the generic form rather than attempting to transcribe from the image. If you've exhausted all search approaches, fall back to the generic form.

1. Check if the form has fillable fields:

``bash bun /scripts/list-form-fields.ts ./provider_form.pdf ``

Decision flow

Found provider's form?
├── Yes, has complete fillable AcroForm fields
│   └── Fill via form field API → flatten → visual check → proceed
├── Yes, but flat/scanned OR incomplete fields (missing signature, date, key sections)
│   ├── pdftotext returns text → Transcribe to markdown with filled values → convert to PDF → visual check → proceed
│   └── pdftotext returns no text (image-only scan) → Use generic form (fillable fields)
└── No form found
    └── Use generic form (fillable fields)

⚠️ CRITICAL: Never invent or fabricate form content. Your transcription must faithfully reproduce the actual text from the downloaded form. If you cannot read or extract the form's content (download failed, file is corrupt, wrong document type), fall back to the generic form at templates/right-of-access-form.pdf. A real generic form is always better than a fabricated provider-specific form.

⚠️ IMPORTANT: When the form lacks fields for required information, do NOT skip straight to the generic form. The provider's own form reduces friction with records staff. Transcribe the flat form to markdown (preserving all sections, text, and structure) and convert to a clean PDF.

Signs a form needs markdown transcription (not just field filling):

• Zero fillable fields (completely flat/scanned)
• Missing fields for key patient info (name, DOB, address)
• Fields exist but are too small or poorly placed
• Mix of fillable and hand-write-only sections

Exception: If signature is the only missing field, fill the other fields via API, then add the signature image by coordinates (signature placement is forgiving - bottom of form near a signature line).

Handling form-specific questions

Provider forms often include questions or fields we didn't ask the patient about upfront:

• Date range for records ("from ___ to ___")
• Specific record types (lab results, imaging, notes, billing, etc.)
• Delivery method preferences (mail, fax, patient portal, pick up)
• Purpose of disclosure
• Whether to include sensitive records (mental health, HIV, substance abuse)

Default to maximal data collection — don't ask the patient about routine choices. Fill in:

• Date range: "All available records" or "From earliest to present"
• Record types: "Complete medical record / EHI Export" (check all boxes or write "all")
• Delivery: Electronic format (USB drive, secure download, CD)
• Purpose: "Personal use" or "At patient's request"
• Sensitive records: Include all

Inform, don't ask: When presenting the filled form for review, briefly note any choices made (e.g., "I selected 'all record types' and 'all dates' — let me know if you'd prefer specific date ranges or categories"). This saves the patient a conversation turn while still giving them the option to adjust.

The generic access request form

If the provider's own form can't be found, use the generic fillable PDF at templates/right-of-access-form.pdf. This is a last resort when no provider form exists. It is a proper interactive PDF form with labeled fields that any user could open and fill in a standard PDF reader. It frames the request as an exercise of the HIPAA Right of Access (45 CFR § 164.524). It includes:

• Description of information to be disclosed
• Who the request is directed to
• Who the records should be delivered to
• Acknowledgment
• Signature and date

To use it programmatically, copy it to ./provider_form.pdf and fill it with pdf-lib's form field API -- the same approach used for provider forms:

const form = doc.getForm();
form.getTextField('patientName').setText(patient.name);
form.getTextField('dob').setText(patient.dob);
form.getCheckBox('ehiExport').check();
// ... etc
form.flatten();

The generic form is clean and professional. Let the patient know you're using a standard access request form and explain that providers must accept any written request for access -- they cannot insist on their own form.

Either way, also suggest the patient:

• Call the provider's medical records department to confirm the best way to submit
• Ask about turnaround time and preferred delivery method (fax, mail, in person, portal)

Step 5: Find the Provider's Fax Number and Address

While searching for the form, also look for the provider's medical records / HIM department fax number and mailing address. The patient will need these to submit the completed request. Search for:

• `"[provider name]" "medical rec

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jmandel
• Source: jmandel/request-my-ehi
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.