This may sound like a rhetorical question, but I have worked with many people in the pharmaceutical industry for whom readability is not high on the list of priorities. For documents to be submitted to regulatory agencies, the accuracy of data and compliance with regulations are certainly the most critical concern. After this, however, importance can vary widely among members of a drug development team on specific issues, ranging from strict adherence to in-house templates and styles to how many tables should be replaced by figures. More often than not, team members just want each document to look exactly like every other document of the same kind written within the company for the last 10 years. Those got the drugs approved, didn't they? If the process isn't broken, why fix it? 

It is understandable that readability is not a major concern. Regulatory writing is generally considered the most rigid and standardized genre of medical writing. The industry around the world follows ICH guidelines and templates for study reports, protocols, and summaries, which can breed a sense of complacency. Regulatory agencies employ experts in the review of applications, who surely do not mind highly complex data presentation, dense text, and lots of jargon. In addition, standardization and uniformity are indeed important in technical writing (that's another subject onto itself), although they are often confused with a lack of flexibility. Most important, submissions are often put together under very tight deadlines, and there is simply no time to bother with such "luxury" as document readability. 

So why does readability matter? The answer is simple. On the other side of each submission, a real person will read these documents, and it is to your advantage to get on their good side. 

When I worked as an FDA labeling reviewer, I read many briefing packages and new drug applications and, in some cases, felt the frustration of wading through poorly written and illogically organized text. I heard medical reviewers sigh with resignation. One person said she wished that poor writing were grounds enough for refusal to file. Poorly written documents take longer to read and absorb, are less persuasive, and reduce the effectiveness of the message. 

Think about the workload of the medical reviewers who will look at your submission, and imagine how much a crystal clear, easy-to-read, logically organized application would lighten their mental load. Everyone has experienced the sensation of smooth sailing when reading a well written article with no "bump" of confusion or disconnected reasoning. The mood of the reviewer depends on the readability of your documents, which in turn may leave a general impression in your favor. Even if your data are overwhelmingly and indisputably positive, readability can substantially reduce the review duration and get your product on the market a few days before the mandatory review deadline. This can mean thousands or millions of dollars in extra revenue or an edge over your competitors. 

Nathaniel Hawthorne wrote, "Easy reading is damn hard writing." That truth applies even more to technical writing than to fiction, where data are abundant and complex.  

When I was first given the timeline some months ago, my first thought was "It cannot be done." The company was planning to file an NDA. Two phase 3 studies were to reach database lock in June. I, the lead medical writer on one of the clinical study reports, was requested to complete the first draft of the results (Sections 10 through 13) in 4 working days and the entire document, from TFLs to sign-off, in 3 weeks. I am a fast writer. I have written several first-draft CSRs in three whole days. However, those CSRs were small --- phase 1 or phase 2, involving no more than 50 subjects. The endpoints were generally pharmacokinetics and safety, and the text portion (Sections 5 through 13) was usually 40 to 60 pages.

This time, the phase 3 study was a pivotal trial of approximately 350 patients with analyses on half a dozen efficacy endpoints and a dozen safety endpoints. The report contained 50 in-text tables, 10 figures, and over 100 post-text tables and figures (Section 14).

In the end the impossible was done: The first draft was written in 4 working days and the final version was ready for sign-off in 3 weeks, including editing and QC. (Another writer wrote the text Section 12 Safety, which shaved a day off. Without the assistance I would need 5 working days for the entire draft.) Besides the large-scale coordination and collaboration among all the departments involved, I learned a few lessons specific to writing:

1. Preparation. Do as much as possible before the clock starts ticking. Finalize the "shell" by working with the team. Work with biostatisticians and data programmers to review and understand all the tables and figures. Get the appendices lined up. Establish an internal style guide.

2. Immersion. The fastest way of writing a study report is to hold in your brain as much information about the study as possible before and during the writing. If you don't need to look up the definition and assessment method of every endpoint, you can carry on describing the data accurately and correctly without a pause and achieve the "flow" that makes the work enjoyable. 

3. Brevity. To write concisely is generally desirable but especially critical in a shortened timeline. Do not repeat every data point in the in-text tables. The text is used to draw attention to key efficacy and safety results. Focus on the data that support the endpoints.

4. Communication. If you need help, ask. Do not wait. The medical monitor and statistician are your most valuable resources to help you make sense of the data. They can help you resolve data anomalies and clarify ambiguity. Report your progress often, so that the team is aware of any risk to the deadline and can lend you a hand if necessary.