Case Study 2 — Four Lines of a Nursing Record: A Composite

Constructed. The infusion center and the figures are not real. The mechanism — infusion claims collapsing to their simplest code because start and stop times were not charted — is ordinary, and it is the clearest example in this book of a clinical documentation practice determining a billing outcome that nobody in either department could see.

Background

Section 19.9 ended with a sentence and then a chart excerpt:

The medication administration record is the source document for this entire subsection.

Then the 📋 Read the Chart showed what four charted times make possible, and closed with an instruction: delete the times, and see what is left.

This is a place that deleted them.

The composite

Constructed.

A hospital outpatient infusion center. Busy, well-staffed, clinically excellent.

Its electronic medication administration record had been configured, years earlier, so that documenting an infusion required only a start time and a completion checkbox. A stop time field existed. It was not required.

Nurses, being busy and being asked for a great many required fields, filled in the required ones.

For a large share of infusions, no stop time was charted.

What that did to the claims

Everything in §19.9 depends on duration.

   WITH start and stop times

     initial infusion, first hour
     + each additional hour (add-on units)
     + sequential administrations
     + concurrent administrations

   WITHOUT a stop time

     duration unknown
        → cannot support "infusion" over "push"
        → cannot support any add-on units
        → the hierarchy still applies, but there is
          nothing to build on top of it

     what remains: ONE administration code

A three-hour chemotherapy infusion with two sequential drugs, charted without stop times, is reportable as a single administration.

And the claim is correct. That is the part that makes this hard. The coder did not make an error. Faced with documentation that establishes that something was given and does not establish for how long, reporting the code the documentation supports is exactly right. Reporting more would be reporting a duration nobody recorded.

Why nobody found it

The coders knew. Individually, in the moment, every one of them knew that the claim they were building was smaller than the service that had been provided. They coded it correctly anyway, which is what they should have done.

But nobody aggregated it. Each instance was a single claim, coded correctly, on a busy day. There was no mechanism by which "I had to downcode this one again" became a number.

The nurses did not know there was a problem, because there wasn't one clinically. A stop time is useful clinically and not essential in the way a start time is; the patient's care was never affected. Nobody had ever told them the field had a downstream consumer.

And the two departments had no forum. The infusion center reported to nursing leadership. The coders reported to revenue cycle. The field connecting them was in a system owned by informatics.

Three departments, one field, and no conversation.

How it surfaced

A coder said something.

Not in a report, not through a control. In a meeting about something else, a coder mentioned — as an aside, slightly apologetically — that she wished the infusion notes had stop times, because she was "probably underbilling those."

Someone in the room asked how often.

She did not know. Nobody knew. It took two weeks to find out, because answering it required joining claims data to documentation fields, which nobody had ever had a reason to do.

(Constructed.) The answer was: often enough that it was among the largest single revenue findings the department had produced that year, and all of it recoverable going forward at the cost of making one field required.

What it cost to fix

One configuration change: make the stop time a required field.

(Constructed.) Two weeks, including a change-control process, testing, and — the part that actually mattered — telling the nurses why.

That last piece is worth dwelling on. The change was not "you are now required to do more documentation." It was: "this field, which you have been treating as optional because it was optional, is what allows the department to be paid for the three hours you spent with the patient."

Compliance with the new requirement was immediate and did not decay, which is unusual for a documentation mandate, and the reason is that the people being asked understood what it was for.

What it shows

First, a clinical documentation practice determined a billing outcome, and neither department could see it. Nursing could not see the claims. Coding could not see the aggregate. The information required to notice existed in three systems and one person's private frustration.

Second, the coders were right the whole time. They coded what the documentation supported, every time, which is what a coder is supposed to do. This is not a story about coders being too conservative. Coding beyond the documentation would have been the actual error.

Third — and this is the useful part — "I had to downcode this again" is data, and nobody collects it. Every billing office in the country has coders who routinely encounter documentation that supports less than what was done. In almost none of them is that observation captured anywhere. It is the single most valuable unrecorded signal in a revenue cycle, and capturing it requires a field, a habit, and someone who reads it.

Fourth, the finding came from an aside in a meeting. This is the fourth finding in this book that came from a person rather than a control — after Chapter 14's new biller, Chapter 15's productivity report, and Chapter 18's contract report. Chapter 18's Case Study 2 asked whether "hire curious people and give them time" is a control. This one adds the corollary: it is not a control, but the absence of a place to say something is a control failure. The coder had known for months. There was nowhere to put it.

And fifth, the fix worked because someone explained why. A documentation requirement imposed without a reason decays. A documentation requirement whose purpose the documenter understands does not. Chapter 33 is about this and this is its cleanest example.

The lesson

The billing consequences of clinical documentation are invisible to the people creating it, and the clinical realities are invisible to the people billing it. Somebody has to carry information across, and in most organizations nobody's job description says so.

Three carry-forwards:

Capture "the documentation supported less than what was done." A checkbox, a reason code, anything. Then read it monthly. It is the highest-value unrecorded signal in a billing office and it costs one field.

Go look at the source documents. Not the claim — the medication administration record, the anesthesia record, the therapy log. Chapter 18 §18.11 said the anesthesia record is the source document for an entire billing specialty; §19.9 said the same about the medication administration record. Most people in a billing office have never seen either.

And when you ask clinicians for a field, tell them what it does. Not "compliance requires it." What it does. The infusion nurses in this composite were not resisting documentation; they were prioritizing correctly on incomplete information, which is what everyone does.

Discussion questions

1. The coders were right every time and the organization lost money anyway. Is there any version of "code what is documented" that would have avoided this? Should there be?

2. Design the capture mechanism for "the documentation supported less than what was done." What is the field, who fills it in, what stops it from becoming noise, and who reads the output?

3. The coder had known for months and there was nowhere to put it. Whose failure is that? Be specific about the role.

4. The fix required nursing, coding, and informatics. In your own organization, who convenes that meeting? If the answer is "nobody," what is the actual consequence?

5. Compare this with Chapter 15's Case Study 2, where a prefilled time default caused an overpayment. Both are stories about time fields. Why did one organization document too much and the other too little, and what does the difference suggest about how fields should be designed?