The patient medical record as a database
B. E. Jones and M. A. Ould
King's College Hospital Computer Centre, 97 Denmark Hill, London SE59RS
The patient medical record, viewed as a life-time's accumulation of health care information,
presents interesting problems in database design. The requirement may be a database where
structure is partially controlled by users at terminals.
(Received March 1974)
Introduction
An early real-time filing system for medical records at King's
College Hospital soon demonstrated a need for planning
patient-based information on a grand scale. The filing system
was adequate for the early real-time applications but soon all
kinds of patient-based batch systems began to appear, and even
real-time applications acquired their own archive files. This
fragmentation of related data sets suggests a database solution.
Computerised patient records may be a 'natural' for database
technology since there is so much replication of data across the
information systems in the health care services. The content of
a referral letter, say, from General Practitioner to Clinic, or
vice versa, should largely be recorded somewhere already.
There are numerous examples of this kind both within the units
of health care—hospitals, health centres, etc.—and across them.
Primary objectives
The database approach is so fundamental that the starting
point of design must be 'better patient care'. Perhaps the prim-
ary purpose of acquiring a computer-based medical record is
that one may thereby achieve acceptable measures of aspects of
patient care—even if the underlying concept remains elusive.
If such measurements prove possible, then the potential for
improving these aspects is not in doubt.
A step towards such an information system was embodied in
the aims of the King's College Hospital Medical Computing
project. The chief characteristics defined for this system were to
be:
1. The storage of medical records containing information of
both disciplined and unrestricted nature.
2. The handling of data flow around the hospital.
3. The gathering of statistics for a management information
service.
To provide a generalised solution to these objectives we
recently sought to establish a database which would provide:
1. A day-to-day, patient-based medical information system
gradually to replace much of the paper-based medical
records, and to speed theflowof information throughout the
health care services.
2. A longer-term information storage system supporting the
patient medical record for life and interfacing with all forms
of medical care.
3. An information base suitable for various types of clinical and
administrative analysis.
Additionally, the database design must take seriously the
matters of privacy and legality, which are associated somewhat
informally with the paper-based medical record. Inattention to
these aspects at this stage, in the face of public sensitivity to
database technology, could be disastrous.
There is, perhaps, one further major objective which is much
less tangible. Users of the information system, particularly
Volume 17 Number 4
doctors and nurses, must have a clear idea of what is in the data-
base, how it is organised, and how to use it—just as they have
with respect to the elements of the paper record system. The
Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020
database may prove to be very complicated in fact, but as far
as possible, this should not cloud the users' conception of it.
The day-to-day information system
This is by far the most important area of design because it is
where the bulk of the database is gathered and distributed.
Here the quality of the database is established and so is its value.
The day-to-day information system is already well understood
in the sense that computers have already made some impact,
particularly in hospital laboratories. Here we are concerned
with a larger pattern and less with the detailed systems in wards,
clinics, surgeries, etc.
The long-term information system
The intention is to build up a computer-based medical record-
for-life for each patient. Superficially this is an obvious strategy
which becomes more feasible with the advent of computers.
It should be possible to derive valuable supplements to the
traditional patient history, saving doctors' time or improving
patient care or both. The long term record should also add
another dimension to the possibilities of clinical analysis of the
database. In practice, there are various problems and the kind
of benefits expected must take many years to be realised.
Our objective in this area must be to develop an additional
patient data structure, within the database, called the front
end, which is to provide the essential data required of each
life-long medical record but not the detail. Of course, we have
yet to establish more than a vague notion of what the essential
data is but we do expect to generate some of it via the day-to-
day information system. Thus, for the time being, the structure
and content of the long-term information base will be mainly
derived from the day-to-day system—although the latter is
logically a subset of the former.
Preservation of data for long periods—perhaps 70 years—
introduces two further problems of maintaining relevance and
compatibility, which are beyond the scope of this paper.
The statistical information system
The challenge of clinical and administrative analysis requires
careful consideration. The problem is that an information
system that supports rather than dictates to the medical record
cannot ever be either wholly accurate or complete. Computer
techniques may compare favourably with paper systems in this
respect, but that is not saying much.
If the day-to-day information system integrates well with
users, there will be two-way information flow between the data-
base and users and it is reasonable to suppose that the quality
of information recorded will improve dramatically. If the
computer system collects data with no real feed-back to users,
then the database cannot be regarded as good for analysis.
295
Whatever the quality of data the statistical techniques used on
the database should be more akin to census studies than
direct counts of admissions, etc. Then, up to a point, the sheer
volume of the database can be expected to eliminate problems
of data quality.
Analysis of the database does raise specific problems of the
compatibility of data and whether data should be coded as is
sometimes argued, but we ignore these issues here.
Privacy
The Younger Committee in England and the Department of
Health, Education and Welfare in the United States have both
recently reported the findings of their respective investigations
into the subject of database privacy and the citizen.
It is a telling comment on the ambiguity of the subject that the
Younger Committee feels there is no need for urgency in respect
of detailed controls and have presented an advisory document
full of 'shoulds' whilst the Americans come to the opposite
conclusion and arm their proposals with imperatives. In the
final analysis, data will only be as private as its users are
prepared to make it.
Many of the Younger Committee principles are matters for
the Medical Profession with respect to patient records, rather
than requirements for database design. In particular, database
content, how it is used, how long it is kept, etc. are not easily
defined as Younger would recommend. On the other hand, the
database design can ensure, at some cost, proper access controls
and other mechanisms in support of Younger.
Legal requirements
This area is not well defined, either. For example, hospital
inpatient and outpatient information must be held for six years
after the last attendance at the hospital by the patient. A medical
record-for-life appears to meet this kind of requirement almost
by definition.
However, the legal problem is essentially one of providing
evidence in cases of litigation. Then the database must provide
information with the legal status of 'notes taken at the time'.
This implies the reconstruction of a patient's record to the state
it was in at a particular moment, and identification of the source
of all the content.
In practical terms, then, the database must record who makes
additions and changes to the patient data and when. Changes,
comments, etc. must be effected without loss of the amended
data so that the earlier state can be reconstructed.
Resilience
It is logically 'impossible' for a patient to be re-admitted to
hospital unless he has been already discharged in some sense.
The designer of a computer-based admission system might
therefore wish to force users to record a discharge before per-
mitting the re-admission procedure. While this may be accept-
able to the user, it is a matter for detailed systems study for the
particular application and not an area where the database
should dictate the possibilities (as it might well do otherwise).
This should demonstrate some of the dangers in database
design. It is essential to relate the database to medical recording
and other hospital practices, but, in so doing, one must not
build in too many constraints on individual applications. An
elusive balance is required to achieve a level of what might be
called resilience without 'going overboard' for endless flexi-
bility.
Another consideration, which is also a matter of resilience,
is manual correction of the database. So far we have been
concerned with the ability of the system to sort itself out
despite minor 'abuses' or disruptions to the normal information
flow. The database may nonetheless accept some significantly
erroneous data. For example, two separate records may develop
296
for the same patient. If such trouble can be detected by the
system, this is all to the good, but even if a user discovers the
flaw (or causes it) it is essential that it be possible to put things
straight. The natural solution is to provide simple batch facili-
ties for adjusting or editing the database under strict supervision.
Structure as seen by the user
General
Users, in this context, could be any medical or paramedical
persons, inside or outside a hospital, with a valid interest in the
patient medical record. It is convenient though, to consider the
hospital patient medical record as representing most of the
problems for this section. For users the hospital medical
record folder is an accepted fact of hospital life. It may be
disorganised, incomplete, illegible or unobtainable but its
shortcomings, and the reasons for them, are largely accepted.
Moreover, what structure is intended is simple and users know
how to handle it; they know what to expect and how to find
what they want.
Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020
When we introduce a computer-based medical record, we are
suppressing the familiar in favour of the unknown. If users have
little or no concept of what the new system is about, we can
confidently expect trouble in various forms. In particular, it is
possible that the early medical recording experiments at King's
College Hospital became largely a 'data collection system'
because the doctors had a poor conception of the structure of
the record they were creating and how it could be accessed.
This is clearly not just a problem for the database; it affects all
systems more or less. But with the database we introduce, of
necessity, more structure to the medical record than ever before.
There is a strong requirement, then, that the database should
be portrayed to users in a form they can understand and which
can reflect their thought processes.
The discussion of structure is therefore divided into two
parts—that presented to the user, and the internal software
structure which will represent the medical record for the user.
What and where is the total patient record?
At the simplest and highest level, there should be a simple
division of patient data between, on the one hand, the database,
and, on the other, the continuing but diminished data storage
systems currently used such as the patient folder, headboards
and the Kardex system in the hospital environment. This
division will, of course, change as the database becomes more
comprehensive and is really controlled by applications
development, but the patient database will exclude, as policy
if not necessity, certain types of information (e.g. graphic,
photographic, etc.).
Within the database, there are some more difficult conceptual
problems. There seem to be three distinct areas:
1. The front end and patient medical record-for-life concept.
2. Summary creation to provide communication between
parallel episodes of treatment.
3. Structure of data within individual episodes of treatment.
At this point we begin to wonder whether the database should
concern itself with such a detailed level of user requirement,
especially bearing in mind the requirements for resilience. Our
answer is that the medical record must embody structure to
permit practical methods of access. It is possible for the same
technical structure to support distinct views of the database
structure.
Without valid structure, the database will be disastrous—like
a library with books distributed randomly on the shelves.
In the ensuing discussions, it should be apparent that any
structure will impinge on current medical practice. By attempt-
ing to minimise this effect we may destroy the potential of the
database, whereas the more radical approaches, for example,
The Computer Journal
that of Weed's problem-oriented record (Weed, 1971), could be
symbiotic with the database technique.
Summaries and the front end
There is a presumption here that users, particularly doctors,
require resumes of the current episode, of other current treat-
ment and of past episodes. The GP and hospital summaries are
steps in this direction, although a computer system can, hope-
fully, go much further.
In simple terms, the hospital summary provides a resume of a
hospital episode and similar levels of summary are conceivable
for other episodes (e.g. outpatients, health centres, etc.). We
can then extrapolate this principle to provide the front end as
a summary of such summaries. This is a tidy concept, provided
that there are workable ways of maintaining each level of
summary, because the user gets a simple picture of the past
from the front end and otherwise has only the detail of the
current episode to deal with.
Unfortunately such a simple view collapses once one attempts
to cope with two or more parallel episodes (e.g. attendance at
distinct outpatient clinics). The paper record may not be
effective in this situation either; but then users are not expecting
resumes. The essence of the problem is to find a balance
between keeping information entirely separate and combining
it for the distinct but parallel episodes. This appears to require
the propagation of all salient points of each episode among all
those episode records running in parallel. Now we have a
situation where salient information must be recognised when it
is generated, so that it can be propagated for other users.
In this more complex database structure, the user 'sees' a
front end summary, plus the statements that make up the
episode with which he is associated, plus the salient statements
from other episodes which may be current for the same patient.
It should be possible to integrate the key information from
other episodes into the topical episode. This is not denying the
doctor, for example, access to the entire medical record for life;
it is promoting a simple way of accessing a large and complex
information structure.
If in practice it were not possible to establish the salient
information in such a way that it can be 'propagated' across
parallel episodes then the database medical record structure
would revert to one of two degenerate forms:
1. Information from a number of parallel episodes must be
maintained as one whole, so that users concerned with
distinct episodes 'see' all of each other's information.
This makes it more difficult to create summaries and thence
the front end.
2. Users concerned with distinct episodes 'see' only their own
information for their particular episodes. The system cannot
help them to be aware of other courses of investigation and
treatment, so users must themselves explore the possibility
of relevant data outside their 'own' episodes. Of course, this
latter situation is inevitable to some extent until most aspects
of medical care are recorded in the database.
Discussion of episode structure
The record of a particular episode of medical care is made up of
a number of what may be termed statements of various types.
In this context, virtually every type of entry in the patient
medical record is implied, including orders, reports, comment,
etc.
There are broad categories of statements such as history,
physical examination, diagnoses, etc. but the distinctions tend
to be arbitrary although probably not contentious. This view
of the episode we call segmented and the individual categories
are referred to as segments. In practical terms, the history
and physical examination segments represent the state of the
patient at the start of the episode. Subsequently the manage-
Volume 17 Number 4
ment of the patient can be recorded in terms of other segments
of the record (e.g. investigations, diagnosis, therapy, clinical
comment, etc.). These management segments may not provide,
of themselves, adequate structure.
Earlier medical recording experiments at King's have shown
that there is considerable useful structure in the history and
physical examination segments. In other words, there can be a
visible pattern in these segments and not just a series of state-
ments. This was not the case for management statements and
there seems to be a need to bring out the medical logic in the
management segments. Two possible approaches have been
considered.
If one retains the primary segmentation of the statements
relating to one episode, it could be made possible for users
explicitly to cross-link statements in the management segments
and possibly those in the history and physical examination. In
simple terms, when a user ordered an investigation, for example,
he could link it to some other statement in the record. The
resulting sequences of statements then should reflect some
Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020
'line' of clinical thought. Unfortunately it is not only difficult
to provide an adequate pattern of links technically but we find
it difficult to comprehend the real advantage to the users of
thinking in these terms. We feel that this kind of additional
structure is conceptually difficult for users to grasp.
An alternative may be some derivative of the problem oriented
record (Weed, 1971) for the management segments. After
recording conventional history and physical examination
segments, management data is recorded by 'problems' (i.e.
signs, symptoms, diagnoses. . .) which the doctor has elected to
manage. So, apart from history and physical examination
segments, users see a problem list for each patient. Within each
problem are recorded comment, investigations, treatment,
management plans, etc. Since Weed undoubtedly designed this
kind of structure bearing in mind a computer-based information
system, it is not surprising that the whole approach seems more
viable in computing terms than the kind of linking structure
suggested above. In particular, it is easier to see how to combine
parallel episodes through a common problem list, and how to
manage summaries and the front end by problem lists.
Whatever view of an episode is presented to a user, the data-
base can only support a few options unless it becomes exces-
sively complex.
A reasonable compromise seems to be to limit the user's view
of the database to segmentation with either simple statement
linking or a problem oriented management structure super-
imposed. In either case, the exposition of structure at this level
becomes a matter for medical expertise.
Structure within the database
Here we take the structure seen by the user and discuss it in
general terms, leaving a formal definition to the Appendix.
The four structural concepts with which the user must become
familiar are:
1. the episode and the episode group
2. segmentation of episodes
3. summaries
4. the front end.
We consider these in turn, and then discuss other aspects.
The episode and episode group
An episode may be defined in different ways. Possibly the most
natural definition is that which treats
a stay in hospital
a sequence of clinic visits
a sequence of outpatient visits
and a set of health survey results
as separate episodes.
297
 However, it seems reasonable to assume that the following
two statements hold for any definition of an episode:
(a) an episode is an interaction between the patient and the
NHS, possibly for a considerable period and possibly for a
number of reasons, and
(Jb) there is a definite possibility that several episodes may be
concurrent.
Statement (b) leads us on to define an episode group (EG) as a
set of episodes during the total time span of which there is
always at least one current (active) episode. (This definition is
introduced because, in practical situations, it is desirable that
workers in different but possibly concurrent episodes have
available vital data from each other's episode—this is pursued
later.)
Furthermore, as we are obliged by expense of on-line backing
store to remove some of the database to less easily accessible
devices (tapes and so on), we introduce a split in the database
between current (on-line) data and archived (off-line) data.
To make this a clean division we adopt the convention that
neither the front end nor any EG can straddle it, so that any
EG is either wholly current—a CEG—or archived—an AEG.
Clearly there can be at most one CEG but any number of
AEG's, and since the latter are effectively read-only we can
consider them to be eternally in our archives, even though we
may want to get a copy of one on-line for perusal. (Fig. 1)
Each episode is further divided into segments.
Segmentation of episodes
The statements in a given episode may be divided into broad
categories:
History
Physical examination
Diagnoses
Investigations
Patient education, and so on.
These categories are called segments, and the breakdown of an
episode into the divisions suggested clearly says something
about the definition of 'episode' being used.
The way that the system handles segments in the structure of
the patient record must ensure that access is fast to all data
within a segment (of a given episode) as soon as we have
'fixed' on that segment.
Any further subclassification of data within a given segment
is achieved by the use of simple data types—each data item has
such a data type. They would:
(a) be defined by applications software
(b) be local to a given segment as regards meaning
(c) be stored by database software with each data item
(d) permit a finer selection mechanism for application software
when extracting data from records.
As an illustration, within the segment 'Investigations' we might
define the data types 61, 62 and 63 for Chemical Pathology,
Haematology and Radiology results, respectively.
Summaries
A summary within an episode is a selection of data statements.
For instance, the Hospital Summary aims to give a precis of a
patient's stay in hospital and contains only those facts which
are considered significant and useful should the patient re-
appear in the hospital. The GP Summary orientates the data
more towards what the patient's GP will want to know to help
him in the management of the patient after discharge from
hospital.
The hospital summary has an important place in the user's
view of the patient, giving a concise description of an episode
in terms of 'significant findings'. We clearly have a data dis-
semination problem when we have concurrent episodes. To
298
solve it, the database summary mechanism must allow workers
in concurrent episodes within an episode group to 'pass around'
significant findings, without lumbering each other with all
statements from each episode. 'Starring' data in your episode
with reference to the hospital summary category has the special
property that that data is starred relative not only to your
episode (in which it is generated) but also to all other current
episodes—automatically.
Hence any user working within episode A and requesting all
significant data about the patient sees not only what has been
starred in that episode but also any other data in episodes B, C,
etc. which has been starred there. The system must also provide
him with a mechanism for editing the starrings, i.e. for remov-
ing the star from any data he sees as starred (be it from his
episode or another). This latter action will have no effect on the
starrings seen from other episodes.
Now these two summaries are standard, but we also want to
offer users the ability to create such summary categories as
would be useful to them. These summaries would probably be
Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020
confined to one episode within a group, and the categorisation
of data involved would have no effect on other episodes.
A doctor will want to be able to mark certain data as signi-
ficant with respect to a given summary category—either at
input or retrospectively. He may also wish to remove the
summary marks from data. This marking and unmarking of
data must be recorded by the system and machinery is required
for abstractions and presentation of data in any summary
category; in fact, this may well be the most used form of
interrogation.
There are two important features then of summaries. Firstly
the division of data in the patient record according to episode
of origin or segment within episode must not hamper the
important database function of summarisation—a process that
cuts across episodes and segments. Secondly, since summaries
are one of the main access routes to patient data the
'threading' of summarised data must not only be flexible
but also fast to access.
The front end
This is a group of statements containing, inter alia,
(a) a highly condensed summary of past episode groups plus
vital data from them about operations, confirmed diagnoses
and treatment (where this might affect later episodes).
(b) personal medical data of general importance such as blood
group, tissue type, abnormal reactions to drugs, etc.
(c) ongoing therapy (where this may affect later episodes).
It is maintained quite separately from all episodes and could
well consist of a simply structured collection of statements,
grouped under such headings as were described earlier. The
ARCHIVES CURRENT
(a). In this case the pat ent has no interaction with the
hospital/Health Serv ce currently.
| AEG's 1 Front End
(b). Here the patient is j n contact with the hospital , and
not for the first tilae»
| AEG's CEG Front End
(c). This patient is in ec ntact with the hospital for the
first time.
| CEG | Front End
Fig. 1 The different possible states of a patient record
The Computer Journal
 split into the various data areas. (This shows only one problem
PATIENT
structure although there may be more than one.)
This introduces a division between two different types of
segment:
History
Physical Examination Data = Initial Data Baso * (a) Initial Patient Data (IPD) segments, consisting of history,
Admission Laboratory Results physical examination and such like,
(b) Management Data (MD) segments, consisting of diagnoses,
PROBLEM LIST treatment, investigations, etc.
Problem 1 (P ) • • Management Data for P^ Using this division we can envisage a structure where the
Problem 2 (Pg) • • Management Data for P2 problem list is a further level of division between episode and
segment, so that an episode looks like Fig. 3.
Such a system has the disadvantage that frequently certain
Problem n (P )
n
Management Data for P data in an MDS is relevant to more than one problem and we
would become involved in some sort of crosslinking or dupli-
Initial action plans cation of records to reflect the sharing of data between prob-
Progress notes lems.
Subjective Data The situation is made simpler if we refer to the structure of
Objective Data * Fig. 4 and regard a problem as a selection of data from the MD

Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020

Interpretation segments—in other words, as a special sort of summary of
Treatment and Therapy
Immediate plans the episode. Several points follow immediately:
etc. 1. The name of the summary corresponding to a problem is the
Note: terms marked with an asterisk are defined in Weed (1971).
statement of the problem itself,
Fig. 2 A representation of the problem-oriented record
2. Problems can now overlap quite happily,
3. Problems do not require special mechanisms within the
I SOD database to deal with them as they use the same machinery
I as other summaries. Creation, merging and suppression
IPD Segments Problem List come under functions that we have already decided to adopt,
4. The user is not obliged to make any use of problems,
I 1 I
Problem 1 Problem 2 Problem 3 .. 5. The concept of a problem, which may fall into disuse at any
time, is embedded purely in application software and its use
MDS for P, MDS for P, MDS for P, ..
or non-use in no way affects database structure.

H i II! Ill
Fig. 3 An unsatisfactory structure for an episode
exact content and structure is very much a medical matter,
but we can see certain data types being automatically copied, on
generation, from the originating episode into the front end—
admission and discharge data, operations performed, confirmed
diagnoses and so on.
We should also mention here two other appendages to the
patient record—patient details and patient diary—which have
a structural status similar to that of the front end. Patient
details consists of a collection of statements, possibly coded for
privacy in some way or separate from the main file and indices,
giving the standard personal data for the patient.
The patient diary is, generally speaking, a simple time-
sequential collection of statements describing the time, date
and location of the patient's appointments at clinics, say, or
any other events known to be happening at a prescribed time.
It is relevant only to the CEG but cuts across all CEs and is
used by them all.
Handling the problem-oriented record (POR)
We now consider how the concepts of the 'problem' and
'problem management' fit into our structure. We presuppose:
(a) that the individual problem is episode-specific,
(b) that a doctor may choose to use or not to use the problem-
oriented technique. So facilities must be available for the
doctor to work in 'problem-context',
(c) that the problem structure may be reviewed and re-
assembled repeatedly.
We might summarise Weed's description of the POR (Weed,
1971) with Fig. 2, in which, as an example, problem Pn has been
Classes and groups
We now return to the subject of summaries and, in retrospect,
consider the two different types of summary which are sup-
ported by the database:
(a) system-defined summaries, hereafter to be called 'classes'
(hospital summary, GP summary),
(b) user-defined summaries, hereafter to be called 'groups
(private summary categories, problems, etc.).
(It is perhaps worth noting in passing that there is a third type
of summary which does not concern the database, namely that
which is formed from statements selected at the time of output
of the summary and which does not involve any explicit
marking, in the database, of the statements involved. An
'episode summary' consisting, say, of the current active problem
list plus related ongoing treatment and investigation plans
might be an example—the relevant data statements are selected
from the patient record not on the basis of any explicit episode
summary marker but because those statements are known to
represent ongoing material.)
Generally speaking, every episode for every patient will have
all classes automatically set up, whereas groups are defined
locally within a given patient episode and vary from episode to
episode. In consequence, classes do not vary in number (except
EPISODE
IPD Segments MD Segments
Fig. 4 Weed-based segmentation of an episode

Volume 17 Number 4 299

perhaps once in several years) and every patient episode has
that number of classes; on the other hand the number of
groups denned within any given patient episode may vary from
day to day.
At this point we face a logical conflict with the propagation
property of the hospital summary. If a data item, X say, is
starred in episode A, we are forced by technical considerations
(and by the problem of complete reconstruction of a patient
record on any given date) to copy Zinto all concurrent episodes,
say B and C. But suppose episode B is being handled in a
problem oriented way. Then if X is not 'put under' some prob-
lem within B, workers in that episode will not be aware of it
except by interrogating the entire record. Here the database
must rely on applications software to provide a group status for
X perhaps by instruction from users.
Implementation
Introduction
Earlier sections describe the database largely in medical terms
and the resulting structure is expressed formally in the Appen-
dix. Technical judgments are implicit in this design, being
mainly concerned with achieving the maximum capability for
an acceptable level of complexity. An over ambitious design
could become a Pandora's Box of technical trouble and so there
must be a comfortable credibility for what is proposed.
Having achieved a desired structure with the minimum of
technical constraint, there are some further important technical
considerations to be fitted into the picture.
Technical objectives
One of the obvious benefits of database design, as opposed to
evolution of a series of adhoc file structures, is the opportunity
to provide features which might be clumsy or even prohibitively
costly if developed for isolated applications.
1. Security
A general strategy must be adopted such that data does not
get lost as a result of peripheral failure or breakdown of the
processor for example. Recovery must be total and accurate
within reasonable limits. We adopt the objective that data in
the database should have at least two levels of backup. That is,
if a version of the database fails at any stage in its daily usage
then there should always be sufficient backup information to
rebuild the database completely. If this backup information
should itself fail at any stage of database recovery there should
be recourse to a second level of backup information. Only if
this second level fails should data loss be a possibility.
Since the database is common to all applications, errors in it
caused by technical shortcomings can have widespread effects
but the centralisation has the advantage that the database can
be validated as a whole and utilities can be justified for this
purpose.
2. Transparency
The system will be able to store many distinct types of data
for many kinds of patient and this data may have its own
inter-relationships and structure which the database will
maintain. However any structure imposed on data by the
system—in pursuit of access speed, storage economy (in time
and space) as well as the mechanisms of the basic structure—
must not be apparent to applications accessing the database.
Equally the database structure must be independent of the
content to the extent that the structure of the database can be
altered with minimum upheaval to the applications which
access it.
In practical terms this means that applications should have
easy access to the data content of statements within the rigid
framework of segments, summaries, episodes and patients.
300
3. Long-term compatibility
Techniques and standards used will promote long term com-
patibility with future information standards. As far as possible,
records should still be valuable after, say, 50 years.
4. Contemporaneity
The database should be as up-to-date as possible. This implies
that any working subsets of the database have to be correlated
with the main database regularly so that all the data is self-
consistent at midnight every day, for example.
5. Manipulation
A manipulative capability is required for re-organising the
database at various levels. It could happen, for instance, that
the same patient might have records stored by accident under
two different unit numbers; the database software will be able
to merge the two sets of records. It should also be possible with
suitable controls to correct errors in the individual statements
of the database where normal access to the database cannot
Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020
achieve the desired result.
6. Monitoring
The database is a general purpose structure rather than a
mechanism for storing a predictable quantity of data in a
particular fashion. It is therefore desirable to provide for some
analysis of how the database is used as a guide to enhancement
and also a cross check on other analyses of system usage. The
main requirements are for a breakdown of the database into its
constituent parts and for a study of how the database access
machinery is used by on-line users.
Technical constraints
In practice, we must plan for a real information system on a
simple configuration using current technology.
1. Archives
It is not possible at present to hold all the data in on-line direct
accessfilesfor reasons of bulk, expense, etc. Although direct
access storage will undoubtedly become cheaper and more
compact in future it is almost certainly true that a considerable
price differential will still exist between such techniques and
mass serial storage such as magnetic tape. In view of this, the
archival of low activity patient records is and will remain a
more economical approach to storage than attempting to hold
all data on-line.
The database software must therefore include facilities for
moving patient medical records from the current database to
the archive database and vice versa as required.
2. Accessibility
Access to the database takes finite time and resources, and this
must be compatible with the needs of the applications. On-line
users of the database are the main problem since they compete
for the resources. A particular access to the database must take
place quickly enough to satisfy the on-line user who instigated
it; it must also not tie up too much of the computer resources
else it will interfere with other users of the computer. Of course,
the more common the type of access the more critical each of
these factors becomes.
This will affect the structure of the on-line database. Common
modes of on-line access to the database must operate efficiently
and the structure can make all the difference. Only in an
idealised hardware situation is this just a mapping problem.
3. Recovery of the on-line database
Security of the archive database can be provided by grandfather-
father-son techniques but the back-up strategy for the on-line
database is inextricably related to other design considerations.
The Computer Journal
 According to the requirements of security, at least two copies
of each update to the database must be filed, in addition to the
update itself. This provides the two levels of back-up but
places an additional burden on the time and resources involved
in database access. This influences considerations of internal
structure.
From another point of view, the speed of the recovery process
must be taken into account. Thus if the database is maintained
entirely in duplicate, the operation of first level back-up is
trivial but the duplication itself may tie up excessive resources
for normal access.
4. Control of access to on-line data
A system of access management is required to avoid certain
types of overlapped access to the database by independent
users. The 'lockout' system adopted is also related to both
access and recovery considerations. Ideally the database
structure should avoid logical dependencies across the actual
data statements, although this is quite impossible to achieve in
practice. However, the less the logical relationships stretch
across the database the better. In the worst extreme, the entire expressions.
database has to be 'locked' out from other users while each on-
line access is performed. This would presumably have a serious
effect on a highly conversational system. Lock-outs at patient
level might also be impracticable on such a system. Ideally, we
would like to work as low as segment level.
Software
The database discussed requires a great deal of software to
support it in the following areas:
(a) housekeeping (archive interfacing, file reorganisation, etc.) <initial-data-segments> = (segment, : / e Iid)
(Jb) archive maintenance (current database interfacing, <management-data-segments> = (segment;: ielmd)
statistical analysis)
(c) batch access (input and output)
(d) on-line database recovery
(e) data manipulation.
Further discussion of these is outside the scope of this paper.
Conclusion
Very little has been said about implementation. A phased
approach was essential because of the scale of the project.
The detailed design of the first phase, including bridging
existing systems, had been established before the medical
recording project was closed down.
There was no question of using manufacturers' software in
the circumstances of the project. It is interesting to note, how- Also, Iid and Imd are index sets, their union being the set /.
Reference
WEED, L. L. (1971). Medical records, Medical education, and patient care: the problem-oriented record as a basic tool, Cleveland, Ohio:
Case Western Reserve University Press.
Volume 17 Number 4
ever, what challenges a standard database management package
would face. The real-time element presents the usual problems
of recovery systems, access management and performance.
Possibly the 'audit trail' requirements of updating and the
open size of the structures could present difficulties. The cre-
ation and manipulation of problem structures in real time may
be related to creating and manipulating files under a multi-
access operating system.
Acknowledgements
We would like to thank Professor John Anderson, Department
of Medicine, King's College Hospital Medical School as our
mentor in the medical aspects of this paper and also our
colleagues at King's College Hospital Computer Centre who
have contributed to the problems and solutions discussed.
Appendix—Formal structure
The following is a formal definition of the structure of the
proposed database.
Note that round brackets have their usual set-theoretic
Downloaded from https://academic.oup.com/comjnl/article/17/4/295/443627 by guest on 13 October 2020
meaning, and that square brackets are used to enclose 'optional'
<database> = «patient-record»
(patient-record) = <patient-identity>[<front-end>[<pra>,
<prc>]]
<pra> = «archived-episode-group»
(prc) = <patient-diary>[<current-episode-group>]
(current-episode-group), (archived-episode-group) =
«episode»
<episode> = (initial-data-segments)(management-data-
segments)
(segment-set) = (segment,-: iel)
<patient-identity> = ((statement))
<patient-diary> = ((statement))
(statement) = type, datatype,, origin date data . . .
. . . ([classification,.] : c) ([grouping^] : g)
where the statement is in segment; of episode^.
<front-end> = ((statement)) possibly segmented,
class,. = ((statement: classification,., type; e statement) : i e /)
group ti , = ((statement : grouping^, type, e statement) : i e I)
—a subset therefore of episode*,
segment^ = (statement : typet e statement)
Note that the definitions of 'group' and 'class' imply that they
are both segmented structures.
301