In-browser AI, running on your machine — not ours.

Line-level claims. One claim-level answer.

A claim can arrive with several lines, and a field like admission type is sometimes coded inconsistently across them. This "votes" across a claim's lines — the most-frequent value wins — to pick one claim-level answer, then classifies each line-level field into valid / invalid / null, exactly the three-bucket split a real data-quality pipeline uses.

The voting logic, the valid/invalid/null classification, and the UB-04 admission type codes below are copied from an actual open-source healthcare-data dbt project's normalization and data-quality models — including a real quirk: its paid-amount check only has valid/null buckets, so a negative amount still counts as "valid" there. The NPI/ICD-10 reference lists here are a small illustrative sample, not the full real terminology tables. Runs entirely in JavaScript — no model download.

Column headers just need to resemble the sample below (e.g. "ClaimID" or "Claim Number" both work) — exact wording isn't required.

Probabilistic record linkage, the Fellegi-Sunter way.

A pair of records only gets compared if they share a blocking key (exact match on name+DOB, or on SSN alone). Each shared field then contributes a Bayes factor — how much more likely a true match is to agree this way than two random people are — multiplied against a prior to get a match probability. Pairs scoring ≥ 0.70 auto-link, 0.50–0.70 go to a review queue, below that they're dismissed.

Uses the real blocking rules and trained comparison weights (m/u probabilities) from an actual open-source Splink-based record-linkage model, not invented weights — including its real limitation: first/last name similarity is plain string similarity, with no nickname dictionary. Runs entirely in JavaScript — no model download.

Real classification logic. Your own coefficients.

CMS-HCC risk adjustment sorts each patient into a demographic segment (community non-dual aged, institutional, new enrollee, etc. — CMS's actual category codes), then sums a demographic factor with disease-category factors. A condition's more-severe HCC excludes its milder version via an explicit exclusion list — not "pick the bigger number" — so it isn't double-counted.

The demographic-segment logic and the exclusion-list hierarchy mechanism below are copied from an actual open-source healthcare-data dbt project's CMS-HCC model. Its own coefficient seed tables ship empty in that project too — CMS's official rate-table numbers aren't redistributable — so the numbers below are clearly-marked placeholders for you to replace with official CMS Rate Announcement values, exactly as that project requires. Runs entirely in JavaScript — no model download.

Headers just need to resemble the sample below — exact wording isn't required.

Two claims, two sources, one visit.

A single ED visit often produces two separate claims — an institutional (facility) claim and a professional (physician) claim — and today those might arrive as a claims flat file from one system and a FHIR feed from another. This runs claims from both source shapes through the same chaining rules for deciding which claims belong to one emergency-department encounter: an exact same-day/same-facility match, a next-day transfer, a general date overlap at the same facility, or — since professional claims don't carry facility or discharge fields — a looser overlap-or-adjacent-day rule when either claim is professional.

The four chaining rules are copied from an actual open-source healthcare-data dbt project's real emergency-department encounter-grouping model, applied here with a union-find over the same pairwise conditions instead of that model's original row-closure SQL — same rules, same resulting groups. The FHIR shape uses the standard public FHIR Encounter resource fields, not that project's own FHIR-ingestion connector code (which lives in separate repositories this build didn't have access to). Worth flagging directly: that project's real connectors cover claims flat files, FHIR feeds, EHR database extracts, and ADT feeds — no CCDA support was found anywhere in its actual code, so it's left out here rather than invented. Runs entirely in JavaScript — no model download.

Find missing protective equipment in a photo.

A real object-detection model — DETR, fine-tuned on the CPPE-5 dataset — finds coveralls, face shields, gloves, goggles, and masks in an image and draws a box around each. PPE detection is one of the most widely deployed computer-vision use cases in industrial and clinical safety today; this is the same underlying pattern.

Fine-tuned checkpoint and dataset are both openly published (see /models/README.md). ~43 MB first run only, self-hosted from this site — no third-party model host is queried.

Not just "someone" — flag exactly who.

A YOLOv8 model trained specifically for hard-hat compliance runs alongside a face-recognition model, so a violation isn't just a red box on a screen — it's tied to a specific person. Enroll a worker below with a photo and a name, then check a second photo to see them identified and matched against their PPE status.

Enrollment and matching both run entirely on-device — nothing about the photo, the name, or the computed face signature is ever sent anywhere. Use your own photo rather than a stranger's: this step only makes sense with a face whose use you actually control. ~12 MB hard-hat model self-hosted here, plus ~14 MB of face-recognition weights loaded from their publisher's CDN, first run only.

Draw a zone. Flag who steps into it.

Draw a rectangle over any hazardous area — a loading dock, a forklift lane, equipment with a live exclusion radius — and a general-purpose object detector flags every person whose position overlaps it. This is the same underlying pattern (person detection plus a geofenced rule) behind proximity and restricted-access alerts on a real production floor, in any industry.

~40 MB first run only.