Perhaps the most familiar example of an enumerated scheme - in a non-medical field - is the traditional taxonomic classification of the animal kingdom, which you can browse online here or here.
Most of the existing medical terminologies actually in use today are also enumerative. Instead of listing the names of animals, medical schemes list (for example) names of diseases or of surgical operations.
The idea behind an enumerative coding scheme is to list, within the scheme, all the phrases you might ever want to use and then give each phrase its own code for handy-dandy reference. The phrases chosen can be very long and detailed - for example:
ICD-9-CM code '49.31' 'Endoscopic excision or destruction of lesion or tissue of anus'
ICD-10-AM code 'X24.24' 'Contact with centipedes and venomous millipedes (tropical), school, other institution and public administrative area, while resting, sleeping, eating or engaging in other vital activities'
ICD-10-AM code 'V32.22' Occupant of three-wheeled motor vehicle injured in collision with two- or three-wheeled motor vehicle, person on outside of vehicle, nontraffic accident, while working for income
ICD-10-AM code 'W65.00' Drowning and submersion while in bath-tub, home, while engaged in sports activity
..or they may be quite short and vague:
READ 3.1 code '0Z...A' 'Other occupations'
The two most important properties of an enumerated scheme are that the list of phrases provided is finite, and it is fixed. It is possible that the user might want to say something that isn't already in the list provided: the list is finite, not infinite. And if the user really has to say something that is not already in the list provided, then they can do nothing. The list is fixed, and users usually are not allowed to add to them whenever they feel like it.
Another problem occurs if what a user wants to say is in the list, but they can't find it.
Attempting to enumerate in advance all useful phrases inevitably encounters two serious problems: scale and organisation. In addition, most existing enumerative schemes have extra problems caused (usually) by particular technical choices that might have made sense at the beginning but which later contribute to the scaling problems.
These three issues are looked at in more detail below.
The following task uses medical examples, but it is not necessary to know anything about medicine to complete it. You should search through the coding list fragment provided using simple string searching techniques in your WWW browser (usually on the Edit menu, under Edit..Find Next). In fact, even if you do know medicine, you'll probably find this is the quickest way to find what you need.
Part One: Using the fragment of ICD-9-CM shown here, find and record in your portfolio the 'exact match' codes for:
Part Two: Some medical diseases of the thyroid gland do not have an exact ICD-9-CM term that matches. Using the fragment of ICD-9-CM given here, find and record a code that is the 'best fit' for the following terms:
Part Three: Explain where you would expect to find the code in ICD-9-CM for 'cancer of the thyroid gland'.
Learning Goal: Understand why enumerative terminologies become too big to maintain
For obvious reasons, enumerative schemes that aim to encompass the whole of medicine tend to become very large - the list of all phrases anybody, anywhere might ever want to record is unimaginably vast. Examples of enumerative schemes currently published typically run to 150,000 to 250,000 discrete phrases - usually called 'rubrics' - but their users often complain that the particular phrase they actually want still isn't present. Or, if it is, that they can't find it.
An additional problem, when a scheme grows to this sort of size, is that even the people writing it can no longer remember what is in it. This is especially the case if the authorship of the scheme is actually performed by a changing cast of thousands. The result is that authors put new codes in because they failed to find the one that was already there.
Having grown to such a size, these schemes must therefore address two important problems: they must provide a means whereby users and authors can reproducibly find their way to the right code (to avoid interrater variability and accidental redundancy), and they must provide a mechanism to allow useful analysis of data after it has been recorded.
Why ?
Because if a scheme is so complex that different people use the same codes to mean completely different things, or different codes to mean the same thing, then any analysis of the final joint recording result is likely to be invalid. This invalidity may not matter for statistical analysis; as long as the data is equally invalid over time, trends can still be reliably spotted. Such terminology users who are mainly interested in statistical trends are often the fiercest opponents of attempts to improve data coding quality for this reason.
Data that is invalid, however, is a big problem if you intend to use it for reliable machine decision support. If the input data doesn't mean what it appears to say, then it can be no surprise when the algorithm makes the wrong recommendation.
Equally, even if the users do actually use the codes to mean the same things, there is no point recording anything at all unless the end result can be analysed in a useful way. The extreme version of this would be a coding scheme that was made up of exactly one code:
0001 'Thing'
In such a coding scheme it is certain that all the users would code everything the same way (because there was no choice) but what would be the point ? The data would be useless.
So, whilst some enumerative schemes (e.g. OXMIS) exist only as unordered, flat lists of phrases, in most cases the phrases are additionally presented in some form of structure. This structure is usually intended to simultaneously support both user navigation to the right code and also later analysis of recorded data. Traditionally, and in the absence of any realistic technical alternative, this 'navalytical' structure has been created entirely manually by the original developers of the scheme, usually by cutting and pasting the terms around within a large wordprocessing document until a navalytical structure that 'looks right' is arrived at.
Typically the navalytical structure is a hierarchy, where each layer of the tree as you descend it is in some way more specific than the last. For example:
Anatomy
-Cardiovascular Anatomy
--Heart
--Blood Vessel
---Artery
---Vein
In this example, as you go down the tree, all elements of any one layer of the tree are 'a kind of' their common parent.
Alternatively, you might also see:
Anatomy
-Cardiovascular Anatomy
--Blood Vessel
--Heart
---Heart Valve
----Pulmonary Valve
----Aortic Valve
-----Cusp of Aortic Valve
....where, as you go down the tree, the relationship between successive layers changes. Sometimes it is 'is-kind-of' but sometimes it is 'is-part-of'. Heart valves are part of the heart, but the pulmonary valve is a kind of heart valve.
With such structures, a user looking to record a term can navigate down the tree - beginning, for example, with 'Anatomy' and then zeroing in on the particular piece of anatomy they require. Similarly, somebody wanting to analyse the data can look at sets of recorded data - for example a set including the terms 'Aortic valve' and 'Cusp of Aortic Valve' - and look up the tree. So, they might only retrieve records that talk about terms that are more specific forms of 'Cardiovascular Anatomy'.
The main problem with such navalytical structures is that the thing they are trying to organise is still very large and very complicated. Moreover, the rules by which the navalytical organisation is imposed are often variable across the whole structure and usually not written down anywhere. It should be no surprise to know that, because they are put together manually by people, they are prone to mistakes. This raises a question mark over their safety and utility in the context of any machine analysis, such as decision support.
Summary: large enumerative schemes need structuring so that different users will record things consistently, and also the result of their efforts can be analysed. As the scheme grows, the manual and ad hoc rules for structuring become too complicated for any human to follow reliably. The result is usually something which looks sort of OK but which fails in the field because users find it confusing. Further, the recorded data is too inconsistent or can not be analysed in all the ways that it needs to be.
Learning Goal: Understand the problems involved in organising a big term list
In most existing medical schemes the navalytical hierarchy chosen is 'uniaxial', meaning that any specific code is restricted to having one and only one parent code even though it might also reasonably be considered to be a 'kind of' one or more other codes elsewhere in the scheme. So, for example, in ICD10, the code:
A15.2 Tuberculosis of lung, confirmed histologically
..is classified only below
Chapter I Certain infectious and parasitic diseases
and is not also classified below
Chapter X Diseases of the respiratory system
.. even though tuberculosis of the lung is clearly a kind of both.
The decision to make a scheme uniaxial is usually justified as a necessary compromise between the needs of the users - where uniaxiality in this real ICD example introduces the risk of users wandering around under respiratory diseases looking unsuccessfully for pulmonary tuberculosis - and the overriding requirement for the scheme as a whole to serve as a statistical tool. Without the 'single parent' rule, any statistical analysis of data could end up counting individual patients several times. If you're trying to pigeon hole patients for the purposes of statistical aggregation, you have to be sure that each patient ends up in only one pigeon hole - and you may need complex rules for deciding which pigeon hole a patient ultimately goes into if there is more than one reasonable choice.
Despite having been designed and optimised specifically for statistical purposes and not at all for either data entry or for non-statistical analysis, current clinical computing systems generally offer such statistically oriented, enumerative schemes as the only means - other than free text - by which a clinician is invited to enter a clinical record. To describe a patient, the clinician either types a lot of free text (speilling mistooks and all), or selects one or more of the available phrases from the enumerated list.
In the absence of more appropriately designed - not primarily statistical - terminologies this state of affairs is understandable. However, the fact remains that enumerative classifications of any kind do not really lend themselves very well to the task of talking about an individual patient, and statistically oriented schemes are worst of all. In the same way that you would not try to write a novel using a phrasebook, it is generally difficult to write a detailed description of a specific patient episode or disease using one or even several of such pre-ordained rubrics.
Statistical enumerative schemes - like ICD - are particularly bad for medical record data recording because their very function is, right from the very start, to encourage coders to group patients by concentrating on what features the patients have in common. In doing this, they deliberately aim to throw away the details which make every individual patient - and their treatment - unique. This means that even the initial data capture using ICD is beginning the process of a statistical aggregation. For certain applications you might reasonaly use ICD to mark-up the content of the medical record, but it really isn't suited to actually being the record.
Additionally, and most importantly, the uniaxial statistical orientation of these schemes means that many of the interesting clinical analyses of patient records that you would like to perform are very hard to execute. For example, to retrieve all patients with respiratory disease you have to go hunting around the whole of ICD10 to ensure that you have all the valid categories, since that particular aggregation category isn't actually present. ICD-10 Chapter X Diseases of the respiratory system doesn't mean what it says. There are respiratory diseases - beginning with Pulmonary Tuberculosis - which are not in that chapter.
The root problem is the tension between the needs of statistical aggregation - each patient in one pigeon hole only - and clinical abstraction. Clinical abstraction might look superficially similar to statistical aggregation but - crucially - for clinical abstraction the last thing you want is for the patient to be categorised into only one, rigid pigeon hole, possibly by arbitrary rules. Instead you want the patient to be simultaneously placed under all the different categories that are valid, otherwise you don't get the right answer. And the number of different clinical abstract categories that you might need for useful clinical applications turns out to be very large and not predictable in advance.
Learning Goal: Understand how bad technical choices can making the scaling and organisational problems even more difficult
(Kluge=not very elegant solution to a technical problem)
One technical kluge commonly used in established enumerative coding schemes (e.g. ICD, READ) is to make the code itself also serve two purposes. In so far as a code is basically an abstract identifier for a particular rubric, it would be possible to imagine an enumerative coding scheme where the codes were assigned randomly. This is not, however, usually what you see. Instead, the codes themselves serve not only as the unique identifiers of concepts, but they also are the means of representing the relative organisation of the concepts; the codes are the means by which the navalytical hierarchy of the underlying concepts is stored. So, for example, the code X000 could be the code for the concept which is the direct parent of both X100 and X200, and also the more distant ancestor of any code like X23f or X43a:
X000
..X100
..X200
....X210
....X220
....X230
......X23b
......X23f
....X240
..X300
..X400
....X410
....X420
....X430
......X43a
Another kluge in the codes is the common practice of restricting their physical length. Historically this has been attributed to the need to be compatible with fixed length database fields. So, for example, in READ 2 all codes are exactly five characters in length.
However, the practice of restricting the length of the code itself places a restriction on the maximum size and depth of the hierarchy that can be represented, if that hierarchy is also represented in the code. In very complex parts of medicine the fact that READ 2 can only store 5 levels of hierarchy detail was a major problem: If the authors discovered disease-Y that was a-kind-of another disease-X already in the scheme, but where disease-X was already at the bottom (fifth) level of the navalytical hierarchy, for example with the code X2535, then unfortunately the new disease-Y could not be placed underneath that legitimate parent disease-X. There was no room in the coding structure. You can not have a READ 2 code that has six characters in it.
Equally, if you came up with a disease that had more than 62 children then you also had a problem: to represent each of the children, using the READ2 coding scheme, you would take the code of the parent disease and make a new code for each child by adding one of the roman numerals 0-9 or an uppercase or lowercase letter A-Z and a-z. Once you have 62 children there are no more characters available for the 63rd.
ICD codes have very similar problems, only worse. For example, ICD codes are generally made up from numbers only, so any single ICD code can have a maximum of 10 children (each enumerated using one of the roman numerals 0,1,2,3,4,5,6,7,8,9 after the original parent code stub), even when in fact there are 11 or more terms that you would like to be able to put underneath it in the navalytical hierarchy. ICD in its 10th version has still chosen not to do anything about this problem.
These technical barriers were one of the reasons why in READ version 3 , GALEN and in SNOMED CT, the shape of the respective hierarchies (which in all three schemes are also multiaxial) is no longer represented in the codes themselves.
There are other curiosities and kluges found in many of today's enumerative schemes - such as 'not otherwise specified', 'not elsewhere classified' and 'other' rubrics. I'm not going to discuss them here. Suffice it to say that enumerative schemes are reasonably well suited to what they were designed for - statistical data analysis - but very badly suited to computer data entry of narrative clinical records about individual patients, and even less well suited to true clinical abstraction.
Statistical schemes will continue to be a necessary target to which captured information must be transformed (because we will always need statistical analysis) but trying to capture the information ready-coded doesn't really work.
Examples of enumerative schemes include:
International Classification of Diseases (ICD) now in version 10. Primarily employed as the global standard for statistical analysis of population morbidity (our illnesses) and mortality (reasons why we die), rather than clinical reporting on individuals. In many countries it is a central government requirement that information about disease incidence, and some information about clinical activity, is returned to the centre already coded using ICD. It is therefore a requirement of most clinical information systems that, regardless of how the detail of an individual's record was originally captured and represented in a particular site, it must also be possible to manually or (preferably) automatically abstract that detail into an ICD code in order to provide central government with ICD coded population data as abstractions from collections of individual patient records.
OPCS-4 The UK standard for classifying all operations and surgical procedures that may be carried out on a patient during an episode of health care. Increasingly outdated and lacking any terms to adequately code many modern surgical procedures, particularly minimally invasive and endoscopic surgery and plastic surgery. Planning for a replacement is currently under consideration (2004).
Read Codes (4 and 5 byte versions)Very few UK doctors perform coding themselves. If they do, the chances are that they will be a primary care physician (hospital doctors very rarely get involved) and it is almost certain that the coding scheme being used will be 5-Byte Read, still the prevailing scheme in use in Primary Care Systems in the UK even in 2004. Because of the need to cross-map to earlier version of ICD (to version 9, in fact), READ is structurally very similar and essentially contains ICD9 as a subset of itself. In addition to the core ICD9 diseases content, READ provides numerous codes for e.g. symptoms and procedures, as well as health administration terms such as 'Sick note given'.