Written and maintained by CASRAI Editorial Board
Last updated
The Present on Admission (POA) indicator is a claims-level coding field, not a clinical diagnosis. For every ICD-10-CM diagnosis code on an inpatient hospital claim, a Health Information Management (HIM) coder assigns one of four reportable values — Y, N, U, or W — recording whether that specific condition was already present when the patient arrived, or developed afterward. It sounds like a back-office coding detail, but it is the single field that determines whether a hospital-acquired complication costs the hospital money under the CMS HAC payment provision, and whether it counts against the hospital in the AHRQ Patient Safety Indicator (PSI) screens used for public reporting and the HAC Reduction Program. For infection preventionists, patient-safety officers, quality directors, and risk managers, POA is worth understanding directly — not delegating entirely to HIM — because the accuracy of this field depends on documentation your clinical teams control, and the consequences of getting it wrong land on your quality dashboards and your hospital’s reimbursement.
What the POA Indicator Actually Records
POA is reported on the UB-04 institutional claim, one indicator per diagnosis code, for inpatient prospective payment system (IPPS) hospitals. It answers a narrow, specific question for each diagnosis: was this condition present at the time the order for inpatient admission occurred — not at the time of surgery, not at the time a symptom was first charted, but at the moment of inpatient admission. A condition that develops in the emergency department before the inpatient admission order is written is still considered present on admission under CMS guidance; a condition that first appears after that order is not.
Coders assign POA from what is documented, not from clinical inference. If a physician doesn’t document a conclusion about onset timing one way or the other, a coder cannot fill that gap with judgment — which is exactly where the four-value structure below, and the query process discussed further down, becomes operationally important.
The Four Reportable POA Values — Y, N, U, W
- Y — Yes. The condition was documented as present at the time of inpatient admission.
- N — No. The condition was documented as not present at the time of inpatient admission; it developed during the encounter.
- U — Unknown. Documentation is insufficient to determine whether the condition was present at admission. This is a documentation-gap code, not a clinical judgment — it means the record doesn’t say, not that the provider actively couldn’t tell.
- W — Clinically undetermined. The provider has documented that they are unable to clinically determine whether the condition was present at admission or not. This is different from U: it reflects a genuine clinical limit (for example, a condition identified early in the stay where onset genuinely cannot be pinned to before or after arrival), documented as such, rather than a gap in the paperwork.
A fifth marker, “1” (or a blank field, depending on the claim format), means the diagnosis code is exempt from POA reporting entirely. CMS maintains a POA Exempt list of ICD-10-CM codes for which the present-on-admission concept doesn’t meaningfully apply — codes that by definition always represent a pre-existing state (a personal history code, for instance) or that are exempt for other CMS-defined reasons. Exempt codes are not scored under the POA-based payment and PSI-exclusion logic described below at all.
Why U and W Are Not Treated the Same for Payment
The distinction between U and W matters well beyond documentation neatness, because CMS does not treat them symmetrically for payment purposes. Under CMS’s POA reporting guidelines, W is treated the same as Y — a clinically undetermined condition gets the benefit of the doubt as present on admission, because the provider affirmatively documented that it could not be determined. U is treated the same as N — an undocumented, unresolved case is treated as though the condition were not present on admission for payment purposes, because CMS will not assume onset-before-admission in the absence of documentation.
That asymmetry is the direct financial argument for closing documentation gaps rather than leaving them as U by default: a condition that was, in fact, present on admission but never clearly documented as such doesn’t get the Y/W benefit of the doubt — it defaults toward N/U treatment, which is the less favorable outcome for the hospital under the HAC payment provision described next. This is why POA accuracy is a clinical-documentation problem before it is a coding problem, and why patient-safety and quality teams — who already own event review, root-cause analysis, and clinician documentation habits — have a direct stake in it.
How POA Feeds the CMS HAC Payment Provision
Section 5001(c) of the Deficit Reduction Act of 2005 directed CMS to identify selected hospital-acquired conditions and stop paying hospitals the higher DRG rate that would otherwise apply when one of those conditions is coded as a complication or comorbidity (CC/MCC). The mechanism runs directly through POA: if a diagnosis on CMS’s designated HAC list is coded N or U (not present on admission, or the U/N-equivalent unknown), it is excluded from raising the case to a higher-paying DRG, even if it would otherwise qualify as a CC/MCC. If the same diagnosis is coded Y or W, it is treated as present on admission and the DRG assignment proceeds normally.
CMS’s HAC list is set and updated by annual IPPS rulemaking, so treat any specific list as time-bound and confirm the current version before relying on it for a specific claim — but the list has included, in some form, conditions such as retained foreign objects after surgery, air embolism, certain fall- and trauma-related injuries, catheter-associated urinary tract infection, vascular catheter-associated infection, and stage III/IV (or unstageable) pressure injuries. This payment provision is distinct from — but related to — the separate CMS Hospital-Acquired Condition Reduction Program, which uses a composite of PSI and NHSN healthcare-associated infection measures to apply a total-payment reduction to the worst-performing quartile of hospitals each year; that program’s own scoring mechanics are outside the coding-and-reporting scope of this guide.
How POA Drives PSI Exclusion Logic
The Agency for Healthcare Research and Quality’s Patient Safety Indicators (PSIs) are administrative-data screens built from claims, and POA is one of their core inclusion/exclusion mechanisms. In general, a diagnosis coded Y or W for POA is excluded from a PSI’s numerator — the logic being that a condition already present at admission cannot be counted as a safety event that occurred during this hospitalization. Diagnoses coded N or U are the ones that flow into PSI numerator logic and can trigger a flagged case.
The practical consequence for a patient-safety program: a POA value that’s wrong in either direction distorts more than one claim. A truly present-on-admission condition miscoded as N or U can inflate a hospital’s apparent PSI rate for something that wasn’t a care failure at all; a truly hospital-acquired condition miscoded as Y or W can mask a real safety event from the same screen meant to catch it. Either error degrades the reliability of a measure that feeds public reporting and, through the HAC Reduction Program, hospital payment — which is a strong reason for patient-safety teams to treat POA accuracy as part of their own data-integrity work, not a coding-department concern they can ignore.
Where Clinical Documentation Makes or Breaks Correct Assignment
Coders can only report what clinicians actually document. A few documentation habits determine whether POA gets assigned correctly:
- Explicit onset-timing language. Admission history and physical notes that state plainly whether a condition (an infection, a pressure injury, a fall-related injury) was present at the time of admission give coders a Y or N to work with directly.
- Explicit “cannot determine” documentation, when that’s genuinely true. If a clinician truly cannot establish onset timing, documenting that explicitly supports a W assignment — which, as covered above, is materially better for the hospital than letting the chart go silent and defaulting toward U.
- A working concurrent query process. Queries raised while the patient is still admitted, when the treating clinician can still speak precisely to onset timing, produce more reliable POA data than queries raised retrospectively after discharge, when the answer is reconstructed from memory or inference.
- No default assumption that silence means N. A condition not explicitly addressed one way or the other should be coded U, not assumed to be N, per CMS reporting guidelines — a frequent source of error is coders or reviewers treating an undocumented onset as equivalent to a documented “not present,” which they are not.
A Data-Integrity Point Worth Flagging: POA Is Not the Same Pipeline as NHSN Surveillance
It’s worth being explicit about a distinction that’s easy to blur: the POA indicator on a claim and an NHSN healthcare-associated infection surveillance classification (see CASRAI’s guides on CLABSI and CAUTI) are built from two separate rule sets, run by two different teams, and they can disagree for the same patient. NHSN surveillance definitions are built from device-day denominators, laboratory-confirmed criteria, and a specified surveillance window — not from the POA indicator. A hospital’s IP team can correctly determine a case doesn’t meet NHSN CLABSI criteria at all, independent of whatever POA value ends up on the corresponding claim, and vice versa. If a patient-safety dashboard shows a surveillance-defined HAI count and a claims-based PSI/HAC count moving in different directions, that divergence is not automatically an error in either system — it’s a reason to check which pipeline produced which number before drawing a conclusion.
A Documentation and Coding Checklist for Patient-Safety Teams
- Partner with HIM/Clinical Documentation Improvement (CDI) to build a POA-specific concurrent query trigger list for high-stakes diagnoses (device-associated infections, pressure injuries, fall-related trauma) rather than leaving query timing to chance.
- Build explicit onset-timing prompts into admission H&P and nursing assessment templates for the condition categories most likely to appear on the HAC list or trigger a PSI.
- Periodically sample HAC-flagged or PSI-flagged discharges specifically for POA accuracy against the source documentation — a clinical-validity review and a POA-accuracy review are not the same audit, and a program that only does the former misses this failure mode entirely.
- Keep NHSN surveillance review and claims/POA review as clearly labeled, separately tracked data streams on your quality dashboard, per the distinction above, so a discrepancy prompts investigation instead of being averaged away.
Frequently Asked Questions
Who actually assigns the POA indicator?
HIM coders assign it, based on what clinicians have documented in the record — not automatically, and not directly by clinicians themselves. Coders cannot infer an onset timing that isn’t documented; that’s the reason clinical documentation habits, not coding software, are the real lever for accuracy.
Is “not present on admission” the same thing as “hospital-acquired”?
Not precisely. An N or U code means the claims record doesn’t show the condition as present at admission, which is a reasonable proxy for hospital-acquired in most cases — but it’s a coded proxy built from documentation, not an independent clinical determination of causation the way a root-cause analysis or an NHSN surveillance review would be.
What does a POA value of “1” or a blank field mean?
Exempt. The diagnosis code is on CMS’s POA Exempt list, meaning the present-on-admission concept doesn’t apply to it, and it is not scored under the HAC payment provision or PSI POA-exclusion logic described above.
Does every diagnosis on a claim get a POA value?
Every diagnosis except those on the CMS-maintained exempt list, yes — POA reporting is required for all other diagnoses on IPPS inpatient claims.
If documentation is ambiguous, should a coder default to N?
No. Ambiguous or absent documentation about onset timing should be coded U (unknown), not N. Defaulting to N without supporting documentation is a documented source of POA-assignment error, and — per the payment logic above — N and U are treated the same way for HAC payment purposes regardless, so there’s no accuracy reason to guess N over U.
Related CASRAI Resources
For the surveillance side of hospital-acquired infection reporting, see CASRAI’s guides on CLABSI, CAUTI, and hemovigilance reporting. For the broader quality-measurement and reimbursement context this indicator feeds into, see the Hospital Readmissions Reduction Program and Hospital VBP’s Total Performance Score. For the documentation-accuracy discipline this guide leans on, see MEAT criteria and HCC documentation. For event-review and reporting-privilege context, see Sentinel Event: What It Means, and What Happens Next and Patient Safety Organization Reporting and the Work Product Privilege. For the wider patient-safety and infection-prevention cluster, visit the Patient Safety & Infection Prevention pillar.
