rmerk ↗ analysis ↗ GitHub rmerk/mike
A Minnesota medical-malpractice records workspace built to turn complex clinical documents into usable case chronologies.
rmerk is steering Mike toward a focused medical-malpractice workflow for Minnesota cases: set up the matter, work through the records, and arrive at a cited chronology.
The fork adds practical views for medication administration and vital signs alongside a sortable timeline, while treating peer-review material as a compliance gate rather than something to process casually. It also broadens the available AI setup, with NVIDIA-hosted Kimi K2.6 positioned as the default for new installations.
It is a purposeful specialist build, not a cosmetic rebrand. Curious legal teams should click through to GitHub for the implementation detail.
What's in it
- Medical-malpractice case workflow A five-phase direction for moving from case setup through medical-record review to a usable chronology.
- Citation-linked chronology A sortable timeline presents extracted events in chronological order and links them back to their source material.
- Medication and vitals views Dedicated lenses make medication administration records and vital-sign histories easier to inspect within the larger record.
- Peer-review compliance gate Scanned pages are checked for peer-review markers before record events are created, helping keep protected material out of the workflow.
- Expanded AI provider options NVIDIA-hosted Kimi K2.6 is available as the default extraction model for fresh installations.
Direction
workflowcomplianceinfrastructure
Activity
rmerk ↗ analysis ↗ GitHub rmerk ↗ analysis ↗ GitHub rmerk ↗ analysis ↗ GitHub Threads of work (detailed view)
rmerk is turning Mike into a Minnesota med-mal machine
A five-phase buildout that scaffolds a malpractice case, mines the medical records, and hands you a chronology - every piece wired to specific Minnesota statutes and case law.
Minnesota med-mal records platform: five phases from research validation to chronology view
rmerk/mike spent a single day on May 11, 2026 shipping a vertical slice that turns Mike into a Minnesota-jurisdiction-aware med-mal records pipeline. The work spans research validation, project templates, a ~6,900-LOC extraction pipeline, and a citation-anchored chronology view - all grounded in specific MN statutes and Supreme Court authority.
rmerk bolts NVIDIA onto Mike and quietly changes the default brain
A fourth AI provider lands, and fresh installs now think with NVIDIA-hosted models instead of Google's Gemini.
Fourth LLM provider: NVIDIA API Catalog with Kimi K2.6 as new default
rmerk adds `backend/src/lib/llm/nvidia.ts` as a fourth provider alongside Claude, Gemini, and OpenAI, targeting NVIDIA's OpenAI-compatible endpoint at `integrate.api.nvidia.com/v1`. Kimi K2.6 becomes the new default model for chat, titles, and tabular review - replacing the prior Gemini default across the board.
Phase 3 chronology view: Timeline renders event log with bbox sync, no backend changes
rmerk's Phase 3 adds a Timeline view at `/projects/[id]/timeline/[docId]` that renders the Phase 2 event log as a sortable, citation-linked chronology. The roadmap set a hard gate - under two seconds, no LLM call - and this satisfies it by reading an existing endpoint with no new backend code or migrations.
Phase 2 extraction pipeline: §145.64 vision prescan closes compliance gap on scanned pages
rmerk's Phase 2 med-mal extraction adds a peer-review compliance gate that the earlier text-only prescan left open. On scanned pages where peer-review marker phrases appear only in the raster - not the text layer - the original check would have passed them through to event extraction. The new path rasterizes those pages, asks Claude whether markers are visible, and halts before any event row is written.
Phase 3.5a: MAR and Vitals timeline lenses, Kimi K2.6 as extraction default, DocView memory-leak fix
rmerk's Phase 3.5a PR adds MAR and Vitals views over the existing `document_events` log, switches the extraction model to NVIDIA Catalog's Kimi K2.6 (vision), and addresses a memory leak in the extraction page that caused RSS to grow without bound on large Epic PDFs.
Pull requests (detailed view)
🟢 Open (1)
rmerk · opened 6mo ago ✅ Merged (3)
rmerk · opened 6mo ago · merged 6mo ago by rmerk rmerk · opened 6mo ago · merged 6mo ago by rmerk rmerk · opened 6mo ago · merged 6mo ago by rmerk ⛔ Closed without merge (1)
rmerk · opened 6mo ago · closed 6mo ago