u/jb89b

nope!!

But who makes sure they back their numbers up? Hit me up

So my father-in-law is bounded and end up needing an ostomy and it's for a bowel perforation/ cyst that got infected when they did a colon screening and perforated his colon now to me if you have a perforation that won't go away and it just keeps getting infected from your vehicle matter getting into it couldn't he go on tpn and drive that up and maybe it would heal itself maybe if they just clip it and not need an ostomy

Let's say that 15 years ago I left the service couple months after that filed for a few things one of them being a foot issue they immediately did surgery for a condition that wasn't the one that I had and after that I started getting medical files that were under a different name in the body on my DBQ and my name in the header and then at a later DBQ they tried rating me for that condition of which I had never been diagnosed with treated for or had. It was during a massive Community Care Scandal when I had the surgery and of course the VA and the Private Practice lost all records so up until recently they denied that it even happened but now that they have admitted that happened I'm filing for a cue to go back 15 years what's my chance

Background: emergency c-section after an induction, requested the full electronic record afterward. Below is just the stuff that's missing or incomplete in what we got back — not the events themselves, just the gaps. Curious if anyone's dealt with this before or knows what's normal vs. not.

#	What's missing	Why it matters
1	Consent form / e-signature tables came back completely empty in the structured data export	The narrative notes reference consent being handled, but the actual signed-document tables have zero records
2	Witness-signature tables for consent, also empty	Same issue — no backing data for who witnessed what
3	Medication infusion audit trail (pump/device-level log) — empty	Would show rate changes, start/stop times, and who made them, second by second
4	Medication "pause log" — empty	Would show any holds/pauses on an active drip and why
5	An entire category of tables related to "prior version" history for notes and flowsheets — not present in the export at all	This is the mechanism that would show if a note or a chart value was edited after the fact (old value vs. new value, who changed it, when)
6	Native fetal monitor tracing / strip data — not included, only summary flowsheet numbers	The raw strip is the actual waveform; what we got is just periodic manual entries pulled from it
7	Native OR/anesthesia module records — not included, only summary logs	Would show the full moment-by-moment OR timeline instead of just headline timestamps
8	Staff badge/location records — not included	Would independently confirm who was physically present and when
9	Internal messaging system — message bodies, read status, and deletion history not included, only stripped headers	Care team may have messaged about the case; we only have that messages existed, not what they said
10	One system table showed 30 exact duplicate rows in the admission/discharge/transfer log	Not proof of anything by itself, but nobody's explained why
11	No export manifest, data dictionary, or schema version provided alongside the data	Without this, there's no way to confirm whether the empty tables above mean "nothing happened" or "wasn't exported"

Questions for the sub:

• Is it normal for a records request to come back with structured data this incomplete, or is this a sign we need to push harder / request differently?
• Anyone gone through a formal HIPAA right-of-access complaint for something like this — worth it?
• Anything on this list I should specifically be asking for by name that I'm not?

Appreciate any input, this has been a lot to sort through on our own.

I’m reviewing a patient requested Epic EHI export and trying to distinguish normal format separation from an incomplete export. NOTE\\\_ENC\\\_INFO contains valid metadata for rich text notes, including author, timestamps, status, and encounter linkage, but some corresponding note bodies are not present in the machine readable delivery.

In a normally complete Epic EHI export, would those bodies usually appear in another table, separate non-computable files, or an export manifest? Also, what fields or logs best distinguish an expected rich text separation from an actual export failure?

I’m not seeking proprietary information or sharing patient identifiers, just general architecture guidance.

I’m reviewing a patient requested Epic EHI export and trying to distinguish normal format separation from an incomplete export. NOTE\_ENC\_INFO contains valid metadata for rich text notes, including author, timestamps, status, and encounter linkage, but some corresponding note bodies are not present in the machine readable delivery.

In a normally complete Epic EHI export, would those bodies usually appear in another table, separate non-computable files, or an export manifest? Also, what fields or logs best distinguish an expected rich text separation from an actual export failure?

I’m not seeking proprietary information or sharing patient identifiers, just general architecture guidance.

I’m reviewing a patient requested Epic EHI export and trying to distinguish normal format separation from an incomplete export. NOTE\_ENC\_INFO contains valid metadata for rich text notes, including author, timestamps, status, and encounter linkage, but some corresponding note bodies are not present in the machine readable delivery.

In a normally complete Epic EHI export, would those bodies usually appear in another table, separate non-computable files, or an export manifest? Also, what fields or logs best distinguish an expected rich text separation from an actual export failure?

I’m not seeking proprietary information or sharing patient identifiers, just general architecture guidance.