Lakewright solutions / brief

Load X12 837 claims into Apache Iceberg and query them from Snowflake

You can turn raw X12 837 EDI claim files into governed Apache Iceberg tables that Snowflake queries directly — without a claims clearinghouse, custom parsers, or your PHI leaving your environment.

What is an X12 837 file?

The HIPAA-mandated EDI format for healthcare claims (837P professional, 837I institutional, 837D dental). Wire format: ISA/GS envelopes, segment-delimited records, no column headers — unreadable to standard ETL tools expecting CSV or JSON.

How does detection work?

By evidence, not file extensions: the ISA fixed-width envelope, the GS functional group, and the ST transaction-set code (837) identify the file; the implementation guide version rides in the envelope. Claim loops become rows; service lines flatten with their parent claim keys.

What about PHI?

Patient identifiers are flagged at scan time and the proposed plan defaults them to masked or keyed-hash columns. The transformation happens at load, in your VPC — the raw values never land in the warehouse, and no third-party processor touches the file (no BAA required for the pipeline itself).

The steps

lakewright scan  s3://claims-drop          # inventory + PHI report
lakewright plan  s3://claims-drop --out plans
lakewright approve plans/claims_837.plan.yaml   # human gate
lakewright load  plans/claims_837.plan.yaml --rest $ICEBERG_CATALOG

Snowflake then reads the table via an Iceberg external volume + catalog integration — no copy, no ingestion job on the Snowflake side.

FAQ

Does this replace a clearinghouse?No — it lands the analytical copy. Adjudication stays where it is; analytics stops waiting on it.
835 remittances too?Yes — same pipeline, and claim/remit tables share key columns for denial-rate joins.
Do I need X12 dictionaries/licenses?No. Detection and extraction derive from the public envelope/segment structure.

The question that matters

"Which payers' denial rate rose after the July fee schedule change, and what is driving it?"

Two payers moved materially, and for different reasons.

The larger of the two rose 3.1 points, concentrated almost entirely in CARC-97 — the benefit already being included in another service's payment — which points at bundling logic changing rather than at anything the practice did differently. The second rose 1.4 points spread across several reason codes, with no single driver, which is the signature of a submission-quality drift rather than a policy change.

Because denial rate is defined once in the semantic view, revenue cycle and finance are reading the same number rather than two versions of it. The assistant joined the 837 claims to the 835 remittances on claim identifier — the join that usually lives in someone's saved query — and returned the ranked answer with reason codes attached. Every figure traces back to a specific EDI file and its digest, so the first question in the payer call ("where are you getting that?") has an answer.

Want this run against your data?

We start with a read-only scan and an inventory report — no installation on your systems, nothing leaves your environment. Most engagements produce findings the team didn't know about in the first afternoon.

Start a conversation