Drug-induced liver injury is a hard call, and the difficulty is rarely about spotting a signal. A clinician looking at a rising ALT already knows something is happening. The hard part is the reasoning that has to follow: which of the patient's medications is a plausible cause, how the injury pattern reads on the lab values and the timeline, whether a competing explanation fits better, and whether the label of "causality" is defensible enough to act on.
That reasoning is structured. Causality assessment frameworks such as RUCAM and the DILIN expert-consensus categories, the Hy's Law thresholds, and the LiverTox monographs all exist precisely because the argument has to be laid out in a consistent, inspectable way. A lot of the work of a DILI review is therefore assembly and consistency rather than insight: collecting the right inputs, resolving the liver chemistry pattern, checking the same boxes every time, and keeping the evidence visible next to whatever conclusion gets written.
DILIGENT is an application for that part of the job. It is a local, single-user decision-support tool for structured DILI review: it collects the case, runs a deterministic pipeline over it, assembles an evidence bundle, and produces a reviewable draft assessment that a clinician can edit, approve, or reject. The draft is not an answer. It is the assembled case, written down in a form that can be checked.
What a review looks like
The workflow is one screen at a time, and each step has a defined output.
Configure. The application needs several models, and it treats them as roles rather than as a single chatbot: a clinical model for the consultation step, a text extraction model for structured extraction, a revision model for editing passes, and a timeline model for chronological reconstruction. Each role can point at a local Ollama model or at a cloud provider, and the access key is added and explicitly activated before it is used.
Enter the case. The DILI Agent form asks for the things the frameworks need: patient and case identifiers, demographics, the suspected drug with dose and timing, symptom onset and history, laboratory values with units and reference limits, concomitant medications, competing causes, dechallenge and rechallenge status, and the clinical question being asked. Where the deployment enables it, files can be attached.
Pre-flight checks. Before any model is called, rule-based checks run over the input. Blocking issues have to be fixed. Warnings can be acknowledged and carried forward. Section extraction confidence is enforced here too: an aggregate below 0.65 blocks the run, and between 0.65 and 0.85 the operator has to acknowledge the weakness. This is the first place where the design chooses to stop rather than guess.
The pipeline. The assessment runs as a background job, so a long consultation does not hold the browser. The stages are concrete: normalization, deterministic section extraction, structured LLM extraction of drugs, diseases and labs with bounded retries and a deterministic fallback, hepatic pattern resolution through the R ratio using the LiverTox boundaries (R above 5 is hepatocellular, below 2 is cholestatic, between 2 and 5 is mixed), candidate selection, per-drug RUCAM scoring, DILIN-like causality categories, Hy's Law status, severity, a mandatory competing-cause checklist, optional retrieval, a bounded clinical consultation, and finally the evidence bundle and the report with a faithfulness audit.
Review. The result lands in Clinical Sessions as two things side by side: the narrative report and the structured dossier behind it, including twelve acceptance questions answered with quotes and a fourteen-section dossier in the shape clinicians already expect from an FDA-style review. Drug matching is exposed rather than hidden, with per-drug flags distinguishing accepted matches from ambiguous ones that need a human decision and from missing ones. From there the report can be edited by hand, put through an LLM revision that becomes a new official version, compared against the previous version, saved, copied, or exported. A separate tab reconstructs the patient timeline, and Data Inspection shows the local catalogs the matching ran against.
The report is built from the evidence, not from the model
The design decision that shapes everything else is the order of operations. The final report is generated from a persisted evidence bundle that exists before any LLM summary is written. The narrative is then checked against that bundle by a faithfulness audit, and blocking faithfulness issues are finalization blockers: a session with an unresolved one is forced into "requires human review" and can never be marked successful.
The same instinct shows up in the extraction layer. When a model-based extraction fails, the pipeline falls back to deterministic rule-based parsers and records a fallback warning instead of failing the run or inventing content. Degradation is visible in the session rather than silent.
Causality stays conservative
Scoring a drug as a cause is where clinical software is most likely to overreach, so the causal semantics here are deliberately narrow. RUCAM output is treated as supportive rather than dispositive. A rechallenge is never recommended. A missing follow-up laboratory value is recorded as missing, not as negative. Competing causes are checked against a mandatory list rather than left to the model's enthusiasm.
None of this makes the tool cautious in a vague way. It makes each statement in the report traceable to either a computed value or an explicit absence, which is what an audit of the case would need.
Retrieval that runs on the machine
The RAG layer is optional per assessment, and its embedding stack is local by construction: the pinned IBM Granite multilingual embedding model, 384 dimensions, run through ONNX Runtime on CPU with a quantized artifact and a SHA-256 verified download. Retrieval itself is hybrid over LanceDB, combining vector similarity with text search, weighted so that vector evidence dominates while exact terms still matter.
The corpora come from updaters built into the application: LiverTox monographs pulled from the NCBI FTP server, the RxNorm and RxNav drug catalog, and a user-supplied documents folder that the desktop build can select through a native folder picker. A retrieval run does not need a cloud embedding service, and it does not need to send the case anywhere to find the relevant monograph.
Models are a configuration choice
The four roles can run entirely on Ollama, drawing from a local catalog that includes general and medical models, or they can point at cloud providers. Switching is configuration rather than architecture. That matters for two audiences at once: a hospital-adjacent user who needs the case to stay on the workstation, and a researcher who wants to compare how different models handle the structured extraction and consultation steps over the same evidence bundle.
Running it, and where the data lives
On Windows the application ships as a packaged desktop build: a portable executable and an MSI installer, with a WebView2-based shell and the backend bundled as its own binary. Release artifacts carry SHA-256 manifests, and application data lives under the user's local application data directory. A source mode is also available for anyone who would rather build from the tree; it pins the exact Python, Node, uv and Rust versions it expects.
macOS and Linux are supported in source mode only, with no one-step launcher, and containers are explicitly not supported. Storage is a relational database, either embedded SQLite or an external PostgreSQL instance, and the API surface is described by a checked-in OpenAPI document so the client and backend cannot drift apart silently.
One caveat belongs in the first paragraph of any deployment discussion rather than the last: if the model roles are pointed at a cloud provider, the clinical text of the case leaves the machine. The local configuration exists, and the choice is the user's.
What it deliberately is not
DILIGENT is not a diagnostic device and does not replace clinical judgment. Every input, generated statement, conclusion and piece of exported text is the responsibility of the qualified clinician using it. It is a single-user tool: there is no multi-user deployment, no authentication layer, no mobile client, and no hosted service. It does not train or fine-tune models, and it does not publish accuracy numbers, because none have been measured. The repository ships user documentation, architecture documentation and runtime documentation instead, which is the honest artifact for software at this stage.
The licence is the GNU General Public License, version 3 or any later version, so it is free software in the full sense: inspectable, modifiable, and redistributable under the same terms.
Who this is for
If you work with drug-induced liver injury and you have ever wanted the case assembled the way the frameworks actually specify it, with the scoring visible and the report traceable line by line to the evidence behind it, this is worth an afternoon. It runs on a workstation, it takes a fictional case in minutes, and it will show you exactly how it reached whatever it says.
The repository, documentation and packaged Windows builds are at github.com/CTCycle/DILIGENT-Clinical-Copilot.
Draft notes (not for publication)
- Tags: healthcare, ai, opensource, python (Dev.to). Medium: same topic set.
- Description / subtitle: "A local, single-user decision-support application for structured Drug-Injured Liver review" is wrong; use: "An open-source application that assembles a Drug-Induced Liver Injury case the way the causality frameworks specify it, on your own machine."
- Images: five screenshots, all from the repository's own validation set for the current release, all containing only synthetic or public data. Upload to the platform's CDN at publish time (Dev.to uploader first, then the Medium paste route), never hotlink the repository.
- Version references: deliberately absent. The draft names no release tag and no version number anywhere, per the current promotion rule. The evidence was read at the repository state pinned in the pack.
- Claims deliberately left out: accuracy or benchmark numbers (none exist), any statement implying diagnosis, any suggestion of multi-user or hosted operation, any Docker or mobile support.
- Tone check: plain sentences, no em dashes, no hype vocabulary, no rhetorical triplets.
Top comments (0)