Dr Martyn Read outlines his proposals for a minimum data set that could be used as the starting point for a computerised database of clinical guidelines

If there is one thing that characterises the organisation of medical practice by British consultants in the late 1990s, it is an obsession with guidelines and protocols. In England the Clinical Negligence Scheme for Trusts (CNST), and in Wales the Welsh Risk Pool (WRP), are demanding these in great quantity.

While lip service has been paid to the importance of supplying clinicians with information technology, most NHS IT investment has been devoted to the development and maintenance of the managed competitive health market. As a result, most front-line doctors now have a dearth of hardware and only rudimentary IT skills.

I have a picture in my mind of clinicians the length and breadth of the UK beavering at word processors on PCs to produce inconsistently structured guidelines, and then printing dozens of them, dozens of times, in order to give newly appointed trainees several kilos of pages each, which for reasons of complexity and bulk will neither be read nor carried around for reference.

Despite the drawbacks in the current system, a literature search or a search on the internet, will reveal a huge number of people around the world involved in recommending certain structures for guidelines, or developing formal evaluation tools for them.

These processes are commendable, but without an increase in the sophistication of the IT supporting them, they threaten to turn kilos of print into tonnes of it.

If we consider the evolution of information storage, then the starting point is the hand-written page. In computing terms this equates with a bit-map – you can cut-and-paste (literally) but such things as spelling checks, changes in font, easy correction of mistakes etc. are impossible.

Now consider a word processing document. Here the writer has much more control over the final printed page, but that is the limit of IT's contribution to this effort.

Much more than this can be made available to us with a minimum of extra work. Intranet technology is mature, useful and inexpensive. Every time a doctor refers to a protocol he/she needs to be confident that it is the latest version.

The practical way to do this is to publish it as a web page on the NHS intranet (the local one here in Wales is known as NHS Cymruweb). Aficionados of the hypertext programming language will tell you that converting a word processing document to a hypertext mark-up language (HTML) document is only the beginning of what you can do in terms of allowing the reader to move from topic to topic at will ('surfing').

Thus, in progressing to hypertext on an intranet, we have overcome so-called concurrency problems, and increased the user-friendliness of our information.

When clinical workstations become commonplace, portability problems will also no longer be an issue: every doctor will have access to all the local guidelines on the nearest workstation, and still have room in his white coat pocket for such essentials as a pin, a stethoscope, and a sandwich.

The next step is to facilitate collation of the documents. Questions that a researcher, an interested trainee, or a medical director might ask include:

Have local guidelines been published on topic X?
Are they any good?
Is there duplication?
Is there contradiction?

How old is our oldest guideline?

Free text (even dressed up as hypertext) cannot begin to answer these questions.

Here in Wales, the WRP requires us to keep a record of all local guidelines, which in its crudest sense could be a paper-based card-and-file system, but modern IT can make this much more powerful and easier to achieve.

I propose that the modern clinical guideline has evolved to the status of an entry into a networked computerised database. Anything less is 'an opportunity for improvement', as our managerial colleagues might put it.

The medical profession should now define a minimum data set, so that software engineers (or interested amateurs; the professionals have their minds on other things) can write database systems that will provide answers to the above questions and, furthermore, allow nationwide collation of guidelines. Future presidents of the Royal Colleges, and future health secretaries, would then be able to address questions similar to those above, but on a national scale.

By the same token, a doctor charged with drawing up a local guideline would be able to pick one 'off the shelf' which would merge seamlessly with other guidelines stored at the local institution.

In order to provide a starting point for software writers, I present my suggested minimum data set for a computerised database of clinical guidelines.

Fields can be (N)umerical, (C)haracter, (L)ogical, (D)ate, or (M)emo. Field width (and number of decimal places for numeric fields) is defined, except for memo fields, which conventionally are of unlimited length. Field names have been limited to 8 alphanumeric characters, contain no spaces, and none begins with a number. To maximise flexibility, only a small number of fields are mandatory. A text description of each field is included. I intend that all character fields of width 2 alphanumerics should be Kenu-driven, and include examples in the text descriptions of these fields.

If that last paragraph didn't read like ancient Sanskrit to you, you might be considering writing a simple program, in one of the main database programming languages, which could be used to collate all the local guidelines. In the absence of any other published suggestions, I commend this minimum data set to you (Table 1).

Table 1: Clinical guidelines minimum data set
Field Name Field Type width dec Text Description of Field
guid_loc C 6   Local unique identifier of guideline*
guid_nat C 14   National unique identifier of guideline
author_l C 20   Main author's last name*
author_i C 6   Main author's initials*
author_p C 10   Main author's profession
author_t C 10   Main author's title or rank
au_dept C 10   Main author's department*
au_inst C 20   Main author's institution*
au_other C 30   Other authors list
sponsor C 20   Sponsor of guideline or of author(s)
date_fr D     Date guideline current from*
rev_freq N 5 0 Planned review frequency in months*
date_til D     Review date for guideline*
readl_pm C 2   Primary intended readership (AL)1, (DO)ctor, (NU)rse, (PH), (OT), (ST), (RA), (DI), (SW)*
read1_pt C 20   Text description of primary intended readership
read2_pm C 2   Secondary intended readership (AL)1, (DO)ctor, (NU)rse, (PH), (OT), (ST), (RA), (DI ), (SW)
read2_pt C 20   Text description of secondary intended readership
diag1 C 20   Patients addressed by guideline: primary diagnosis: text
diag1icd C 8   Patients addressed by guideline: primary diagnosis: icd-10 synonym for diag1§
diag1rea C 8   Patients addressed by guideline: primary diagnosis: Read code synonym for diag1§
diag2 C 20   Patients addressed by guideline: secondary diagnosis: text
diag2icd C 8   Patients addressed by guideline: secondary diagnosis: icd-10 synonym for diag2
diag2rea C 8   Patients addressed by guideline: secondary diagnosis: Read code synonym for diag2
pathphys C 20   Patients addressed by guideline: pathophysiology: text
path_icd C 8   Patients addressed by guideline: pathophysiology: icd-10 code
pathread C 8   Patients addressed by guideline: pathophysiology: Read code
age_low N 6 2 Patients addressed by guideline: age range lower limit*
age_high N 6 2 Patients addressed by guideline: age range upper limit: if empty, assume infinity
males L     Guideline applies to males T/F*
females L     Guideline applies to females T/F*
race C 8   Patients addressed by guideline: race: if empty, assume all
pt_other C 20   Patients addressed by guideline: other
exc_pats C 20   Exception to use of guideline: patients
exc_sits C 20   Exception to use of guideline: situations
exc_locs C 20   Exception to use of guideline: locations
interven C 2   (CO)mplex, (DR)ug, (MO)nitoring, (OP)erative, (PH)ysical*
int_text C 60   Text description of intervention proposed by guideline
opcs C 6   OPCS code of any operation involved
bloodix C 8   Telepath code or equivalent for lab investigation that guideline concentrates on
imageix C 8   Radis code or equivalent for imaging that guideline concentrates on
drug_rx C 20   Generic name for drug that guideline concentrates on
harm C 20   Potential harm to patients processed according to guideline
costtext C 30   Text description of cost components of guideline
costdept N     Cost to department of intervention per patient (Pounds sterling)
sec_pref C 60   Text description of second-preferred option
cost_net N     Cost to department of intervention minus cost of second-preferred option (Pounds sterling)
cost_nhs N     Cost to NHS of intervention per patient (Pounds sterling)
nhs_net N     Cost to NHS of intervention minus cost of second-preferred
out_surv L     Outcome measure of guideline should be survival
out_qual L     Outcome measure of guideline should be QALYs
out_othe C 20   Outcome measure other than survival or QALYs
title C 60   Title of guideline*
guidintro M     Introductory paragraph
guidquic M     Main text of quick reference version of guideline (less than 12 pages)
guid_rec M     Recommendations/summary paragraph of guideline
guid_text M     Full text of guideline or reference to where it is to be found
guid_ref M     References cited in guideline
appr_no N 2 0 Number of systematic appraisals available*
guid_app M     References to systematic appraisals available
app_summ M     Conclusions/summary paragraph of most recent/detailed/
validity C 2   Validated well, moderately well or poorly (V1), (V2), (V3),
reliabil C 2   Good, moderate or poor reliability, (R1), (R2), (R3)
reproduc C 2   Good, moderate or poor reproducibility, (R1), (R2), (R3)
* Mandatory field; § Mandatory to fill in at least one of these two fields


Guidelines in Practice, November 1999, Volume 2
© 1999 MGP Ltd
further information | subscribe