Enter the CCG on writing for a readership

As one of my (rather numerous) subsidiary occupations, I teach medical journalism to clinical medical students. It’s great fun, and hopefully provides them with the tools to communicate more incisively.

One of my first teaching points is to get the student routinely to ask: “Who is the intended audience?”

How would they explain hypothyroidism to a lay readership? What would they change if their article were to be aimed at university dons – but in arts subjects; or professors of medicine?

Quite clearly, although the core facts remain the same, each piece would need to be substantially different in scope, style and terminology.

I call this approach “seeing through the eyes of the reader”, and it’s vital in all types of communication.

Quite simply, you have to understand where your readers are coming from: get this wrong, and what you say will just be ignored — or even worse, misunderstood.

The appliance of science

“Seeing through the eyes of the reader” has some particular application when it comes to conveying information about medical IT.

Although healthcare workers aren’t stupid, most aren’t IT experts, either. Their focus is the healthcare, not the computer. The IT is not an end in itself, it’s just a tool.

Unfortunately, those who write the ‘help’ files for medical applications are often IT specialists, who may well not fully understand what you, as a healthcare worker, are trying to find out.

As proof of this, look at the help files in any medical program. Typically they describe how to operate a specific screen once you’ve reached it.

The instructions will explain what each icon, button, or tab does – often in exhaustive detail – but this isn’t necessarily all you need to know.

What you really want to know is how to get the computer to do a specific task. You might want to create a call and recall system for everyone with thyrotoxicosis, for example.

Or you might want to get a list of everyone who received a tetanus booster in casualty over the previous twelve months. Or you want the computer to help identify all those patients whose chronic disease is starting to go out of control.

Task-based needs

There is therefore a gap between the current, detailed help file approach and a user’s overall needs.

But note; there’s nothing intrinsically wrong with either of these approaches: they are complementary.

Most people need help file guidance at some stage; but crucially, healthcare users also require answers to task-based queries.

Unfortunately, companies and individuals who create help files don’t always realise this. Or, to use the concepts of the journalism course, they don’t always look through the eyes of the clinical user and then address their real needs, comprehensively.

The cure is obvious: all medical IT help files need to have two completely separate sections. As now, they should contain a detailed, technical guide.

But in parallel they also need a task-based section describing how to use the application to address their practical, clinically-based needs.

Getting the balance

Almost by definition, detailed, two-pronged guides like this can’t be written solely by a coder or a systems analyst.

They need further input — from clinicians, healthcare administrators, or both — depending upon what the program is intended to do and who is meant to be doing it.

Indeed, whenever I’m asked to promote the use of a particular application, my first action is to see if the existing help file contains a section of clinically-orientated, task-based advice — and if it doesn’t, to sit down and write it.

I often call such a document ‘A Short Friendly Guide to…’  It does what it says on the tin: it’s short (and therefore not overwhelming); it’s friendly (no specialised words, no assumed IT knowledge); and it’s a guide (quickly showing the user how to use the application to carry out the day job more effectively).

My intention is that, within half an hour, any healthcare user should be able with confidence to use the application to perform new, clinically-based tasks, albeit in a rudimentary way.

Seeing through each others’ eyes

The same principle applies to the design and creation of the programs themselves. Clearly it’s best if the system analysts and the users can both learn to see through each others’ eyes, because this will create the best opportunities for truly user-friendly and technically slick programming.

However, in specialised areas this synthesis may be difficult to achieve. Ideally, system analysts need to understand with some subtlety how the clinical users think and work — but this may be difficult without ten years’ training in the relevant medical specialty!

Similarly, the advising clinicians may need to look through the eyes of the system designers — not easy in a complex and fast-moving area such as IT.

One solution is to schedule frequent, detailed meetings between users and designers, extending throughout the entire development process — from the first tentative design steps to the very last stages of detailed placing, labelling and colouring features on individual screens.

Providing detailed clinical input to system design is much more than just a nice, theoretical idea. Indeed, many of the best primary care applications started life being written by practising clinicians.

They knew instinctively what existing information to show on-screen and what to omit; how and when to record new findings, and in what order; and how to provide output in a form which alleviates the burden on healthcare staff.

Detailed planning like this can be subtle, but makes a wealth of difference to the usability, user-friendliness and sheer helpfulness of the IT — which, after all, is what it’s actually there for.

Dr John Lockley

Dr John Lockley is clinical lead for informatics at Bedfordshire Clinical Commissioning Group and a part-time GP.