A postoperative chart lists 'postoperative acute kidney injury,' but admission labs and the history show the renal injury was already present before surgery. What is the coder's correct approach for PSI-related classification?
Select an answer to reveal the explanation.
Short Explanation
If the kidneys were already in trouble before the knife, do not let a loose postoperative label turn it into a surgical PSI. Follow the timeline and POA—and query when the story fights itself. Words on a template are not destiny.
Full Explanation
When postoperative wording says postoperative acute kidney injury but admission labs and history at a civic hospital show the renal injury was already present, the coder must use chronology and POA to avoid classifying a present-on-admission condition as a true postoperative PSI event, querying if conflict remains. Public quality rates should reflect real postoperative harm, not sloppy labels. Always coding postoperative wording at face value even when chronology proves POA Y manufactures false PSI signals. Deleting the kidney injury code whenever PSI risk exists hides clinically valid disease to manage scores. Changing procedure codes so PSI software cannot read the case falsifies the operative record and is unethical manipulation. Exam caveat: narrative adjectives like postoperative yield to documented onset timing and POA rules. Operational check: compare pre-op labs and H&P to postoperative notes, assign POA from true onset, query the provider when labels conflict with chronology, and partner with quality on PSI exclusions without deleting supported diagnoses. Sustain civic accountability by pairing correct code assignment with transparent denial, quality, and privacy escalation paths so public reporting and payment integrity move together.