Moderate evidence
Published recordHealthProblem Space
More
Completeness, Safety, and Readability of Large Language Model-Generated Informed Consent Materials for Orthognathic and Craniofacial Surgery: A Procedure-Specific Content Analysis
- Truvace record
- TRV-2026-2471raw data (JSON)
- Version
- v1Published
- First published
- Evidence type
- Benchmark or lab evaluation
- Sources
- 1 sourcePeer-reviewed
- sha256
- a1763120a43b…check it
Background: Procedure-specific completeness of large language model (LLM)-generated orthognathic and craniofacial consent materials remains uncertain. Methods: A fixed corpus of 132 outputs from four default/free consumer interfaces (ChatGPT, Gemini, DeepSeek and Grok; 11 procedures; three new-chat repetitions) underwent revision-stage independent scoring by three oral and maxillofacial surgeons using a locked checklist. Final outcomes used item-level two-of-three majorities. Coverage comparisons used 11 paired…
The problem
In a study of 132 chatbot outputs, 15 of 33 ChatGPT and 17 of 33 Gemini consent documents for jaw and facial surgery missed at least one critical item.
What this doesn’t fix
Patient comprehension, clinical utility and the effectiveness of checklist-assisted verification were not tested, and aggregate coverage did not establish completeness or clinical safety.
Sources
1 on file- Journal of Stomatology Oral and Maxillofacial Surgerydoi:10.1016/j.jormas.2026.103077
Cite this record
v1Truvace Impact Record TRV-2026-2471, v1: “Completeness, Safety, and Readability of Large Language Model-Generated Informed Consent Materials for Orthognathic and Craniofacial Surgery: A Procedure-Specific Content Analysis.” Truvace, 2026-11-11. /record/TRV-2026-2471 (accessed on the day you copy it). sha256 a1763120a43b30b7…
Change history
1 versionEvery change made to this record since it was first published, and why. Nothing has changed since it went up.
Certified into the record
Check this record hasn’t been altered
How to check it yourself, without trusting this page
Download any version from /api/record/TRV-2026-2471 and hash its canonical field yourself, for example with shasum -a 256. You should get its content_hash. Each version’s text also ends with prev:and the hash of the version before it (version 1 points to 64 zeros). If anyone had changed a single character of any version after it was saved, those hashes wouldn’t line up.
ace