In-house AI, running on your machines 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, or live.

A real object-detection model — DETR, fine-tuned on the CPPE-5 dataset — finds coveralls, face shields, gloves, goggles, and masks and draws a box around each. Use a photo, or turn on your camera for continuous analysis of a live feed — the same shape of pipeline behind real video-analytics safety monitoring, running periodically rather than a single one-off check.

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 — or a live camera feed, continuously re-identifying and re-checking every couple of seconds — to see them 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 — live.

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

~40 MB first run only.

Recolor hair on a live camera, in real time.

Google's MediaPipe hair-segmentation model finds the hair region on every video frame; a luminance-preserving color blend recolors it while keeping natural highlights and shadows intact — the same core mechanic behind commercial AR beauty SDKs (ModiFace, Banuba, DeepAR), running entirely in your browser. An optional face-mesh overlay (478 points, also MediaPipe) shows the head-tracking layer that a full 3D try-on would anchor styling to.

Worth being direct about scope: this proves the core segmentation → recolor → render pipeline, not a production SDK. It doesn't do strand-level alpha matting, 3D hairstyle overlays, or the native 60fps mobile performance a real product would need — see the case study write-up for that gap. Hair-segmentation model ~1 MB; face-mesh model (loaded only if you enable it) ~4 MB. Both loaded from Google's model CDN, first run only — nothing about your camera feed is ever sent anywhere.