'What the Heck is This?' Written Documentation Queries: A Clinician's Perspective

What do we want?

Clinicians who document efficiently and thoroughly, specifying diagnoses, linking them to interventions, and including pertinent and relevant clinical information!

When do we want it?

Now!

In any clinical documentation program, it seems that our primary goal is to put clinical documentation specialists out of a job. We want clinicians that document effectively the first time and have no need for documentation queries or education.

Luckily for clinical documentation specialists (who presumably need to eat) that’s unlikely to happen any time soon.

Clinical documentation improvement has been around in the USA for around two decades and hasn’t yet made itself redundant.

As such, we will often need to attempt to correct documentation deficiencies after the clinician has completed their note.

Enter documentation queries, stage right.

In concurrent CDI, the majority of these can be verbal, to combine education and relationship-building with the query itself. However, there are many circumstances in which written queries are appropriate, and indeed unavoidable.

When a patient is discharged, only written queries can be sent. This might occur for patients who have been discharged over the weekend or unexpectedly. Some clinicians might request that their queries are written, and clinical coders can only complete retrospective written queries.

However, clinical documentation specialists and clinical coders can invest significant time, energy, and focus into writing documentation queries, only for them to be returned incomplete or rejected entirely.

Why is this?

Well, it’s usually not because clinicians are lazy, malicious, or careless. They’re usually just not entirely sure what’s going on or what we want from them.

My Experience

When I was first presented with a clinical coding query, I was utterly bemused.

I was on general surgery, and a friendly, quietly spoken man approached me, asking if I was the intern of the team in question.

This was in the days of paper records, and he handed me a weighty tome, with what looked like an MCQ exam stapled to the front. Surely I didn’t need to do an exam?!

I was given a brief explanation of what was happening which, if I’m completely honest, I can’t actually remember. What I do recall is a vague sense that this wasn’t important, wasn’t for patients, and was primarily for funding.

As a junior doctor I was completing 10-week rotations, so I hadn’t been on the team when the patient had been an inpatient. I was told that this was okay, and I could still complete the documentation query.

The query was for an antibiotic resistance and again, all I remember is a faint sense of exasperation that things “needed to be documented in a particular way”.

My other encounter with clinical coding, which I have mentioned before, was in a short session during orientation week. The presenter was giving an example of specificity and told us we needed to make clear whether sepsis was “localised” or “generalised”.

As an intern my first reaction was panic. “What’s localised sepsis? Why don’t I know about this? Oh my goodness, I must have been the worst medical student ever!”

After talking to my fellow interns, I quickly realised that I wasn’t ignorant, just unconfident. Localised sepsis, as we said, “isn’t a thing”. As much as it loathes me to admit it, especially now I understand the amazing work that health information managers and clinical coders do for the hospital, that one mistake made us all dismiss the very notion of documenting well for the clinical coders.

What to Do?

So, when clinicians have poor understanding at best, and outright frustration about coding at worst, how can you ensure your clinical documentation queries will be well received and understood by doctors?

Well, the most important thing is having a well-rounded CDI program with concurrent CDI, clinician education, data analysis, and executive support.

That’s all very well, but what if you’re a clinical coder working in a hospital without a CDI program? Or a CDS in a program that’s in its infancy?  

There are some things you can do to help clinicians understand and respond to your query.

If it’s possible for you to come to the ward, like the nice clinical coder at my hospital, this is always a great option. However, despite the coder explaining the query to be in person, I still didn’t quite get where he was coming from. I ended up thinking it was “all about the money”.

So it’s important that you emphasise that an important aspect of coding queries is to facilitate the capture of accurate data. Let them know that this allows hospitals to plan and predict effectively, and also explains long length of stays or high resource use. Emphasise that the goal for funding is to be reimbursed for work the hospital has already done, not trying to get more than the hospital is entitled to.

For your piece de resistance, explain that appropriate funding and accurate data are essential for patient safety. A hospital that doesn’t know the needs of its population and is under-resourced cannot provide safe and quality care.

Many clinical coders will not have the opportunity to deliver their queries in person. If this is the case, include the above information in a letter or introductory paragraph. See if you can make it relevant and catchy for the clinician, perhaps by referencing the hospital in which you both work. Build some camaraderie!

Ideally, a query should go the person who wrote the documentation in question. However, doctors move around, so it’s not always possible if the clinician has moved to a different hospital or area. This is especially the case for coding backlogs, when the coding might take place many weeks after the documentation has occurred.

If you can’t find the clinician who documented, direct it to a senior member of the clinical team the patient is under. Ideally, this should be the consultant. See if you can liaise with departments to develop some standardisation for sending queries. For example, it could go to a senior registrar who can answer those they feel comfortable with and send more complex cases to the consultant.

While we all know to directly reference the documentation that has prompted the query, making it easy for the clinician to find that documentation can increase the chances you’ll get a response. In paper records, a sticky note on the page is helpful. In electronic medical records, make sure to reference the documentation exactly.

I was once conducting an audit on clinical documentation, and saw that a query had already been sent to the clinical team. The query referenced a blood transfusion given in theatre and was asking for the indication. I looked at the response from the clinician and it happened to be someone I had gone to school with! This doctor had responded to the query by writing “no evidence blood transfusion given”. I looked more closely. The clinical coder has stated that the blood was given in theatre, and, in the anaesthetic chart, I could see that packed cells had indeed been administered. The anaesthetic chart was in an electronic medical record, and quite difficult to navigate. I am sure that my fellow clinician had navigated to the anaesthetic chart, looked at the front page, and not seen the administration of blood.

So I rewrote the query to say “as seen on the anaesthetic chart, a bag of packed red cells was commenced at 1315 and continued until 1620.” This meant that in order to dispute the claim that packed red cells were given, the clinician would have to find 1315 in the anaesthetic chart. Of course, when they found that, they would see that the blood had, in fact, been given.

Using page numbers, times, dates, and the names of forms will ensure the clinician can find the information being referenced.

For queries to be ethical, they need to be non-leading. We shouldn’t be communicating to the clinician which option we want them to pick. For many of us, this is accomplished using a multiple-choice format.

However, sometimes we might be stumped about what options to give.

While we don’t want to be leading, we do want to provide options that are relevant. Going rogue and giving an option from a completely different body system or pathology might put the clinician offside. They’ll think “whoever is sending me this odd letter hasn’t the foggiest idea of what they’re talking about!”

However, if you give relevant alternate diagnoses, the clinician will relax. For example, a. Bacterial pneumonia, b. Viral pneumonia, c. Unable to be determined, d. Other: please specify. Or a. Acute blood loss anaemia due to surgery, b. Acute blood loss anaemia of another cause (please specify) c. Another anaemia (please specify) d. Unable to be determined, e. Other (please specify).

If you’re completely unsure, it’s appropriate to use an open-ended question. But be warned, asking for the indication for a blood transfusion might get you a dreaded “Low Hb”.

Some of the terms that are used in coding are so commonplace to clinical coders and CDSs, we might forget that they can sound inflammatory to those not in the know.

For example, there are plenty of codes with “complications of surgery”, but a surgeon might see the term “complication” and think it infers some wrongdoing or surgical error.

Where possible, avoid this kind of terminology and stay neutral.

However, sometimes, in order to capture the correct code, you might need to use a particular term. In these instances, it can be good to preface this with a discussion and education about the fact that “complication” just refers to a causal link between a procedure and an outcome.

Another example of using neutral language to your advantage is the term “difficult airway” instead of “difficult intubation”.

Difficult “intubation” implies some problem with the technique, and therefore the clinician. Many anaesthetists will respond with “but I didn’t find it difficult!”.

Using the term difficult “airway”, however, makes it clear that this is a patient factor, not a clinician factor.

Sometimes queries can be returned with “unable to be determined” selected, which can leave the sender scratching their head. All the information in the record pointed to this diagnosis!

However, some clinicians can interpret the question differently, and select “unable to be determined” when it is not 100% proven.

Often, in medicine, we treat based on clinical suspicion, or probability, so if you’re only writing diagnoses when they’re “certain”, you’re probably not writing many diagnoses!

Education can help with this, by emphasising that if a condition is treated, and still suspected on discharge, it can be coded.

Using terms of uncertainty in the query, however, can also be appropriate. For example “Was the pneumonia suspected to be a. Viral, b. Bacterial, c. Fungal, d. Unable to be determined, e. Other: please specify”.

Without a sputum sample, in this example, we will almost always be treating based on clinical suspicion, so it’s fitting to reflect that in the query.

The Take Home

Documentation queries take a lot of effort and time on the part of CDSs and clinical coders. It can be disheartening to see them returned without a diagnosis. However, following the tips above will increase the chances that the query works for both the sender and the clinician!

Of course, the most important intervention to make sure that queries are understood is thorough clinician education, with ongoing reinforcement.

This might reduce the number of clinicians who respond with “What the heck is this!?” when presented with a clinical documentation query.

We can only hope.

We invite you to share your ideas, experiences, and achievements in CDI by submitting content to the CDIA Community!  Contact community@cdia.com.au to learn more.