Mike Bainbridge, Peter Salmon, Ann Rappaport, Glyn Hayes, John Williams, Sheila Teasdale
Clinical Computing Special Interest Group (CLICSIG) of
the PHCSG
The use of an electronic health record (EHR) is becoming
commonplace in UK General Practice despite continuing uncertainty about its legality and
admissibility,,. Work is currently in progress addressing the concept of
transfer between practices when the patient moves. We have also seen projects which have
sought to deliver standard reporting capabilities from general practice computer systems.
There is a feeling within general practice that electronic
transfer of clinical records should be accomplished with ease and as soon as possible. The
view from the computer suppliers is one of more reticence. The problem is due to the
historical development of clinical record keeping systems. Since the early 1980s,
commercial and non-commercial suppliers have always developed their own proprietary and
often secret structure to their records. These implementations vary from a simple
chronological list of medical concepts in an obsolete coding system to relatively
sophisticated Problem Oriented Medical Records (POMR) (q.v.).
Electronic health records are being used increasingly, and
now the limitations of the current systems are becoming apparent. There is clear scope for
development within the various models to allow better recording and retrieval of
information so that the EHR can play a more active part in better patient care.
This paper describes some of the limitations of the POMR
and discusses a number of areas into which it could be extended. Critical to the future
success of the EHR is the transferability of a clinical record between clinical systems
without compromising the integrity and indeed admissibility of the record in a court of
law. The record transferred must also not compromise the integrity of the existing records
on the accepting system. Hence this paper attempts to define and clarify a set of
structures which could be used in an EHR. One extension will be explored in depth - the
timeline - as an example of how the other structures can be pulled together into a
more clinically useful whole.
The implementations discussed are constrained by what is
pragmatically feasible in today's software and hardware, but it is felt that without using
the structures it will be difficult for the EHR to gain more widespread usage and
certainly it will be much more difficult to transfer records.
There are many reasons which clinicians have for choosing
to record clinical events electronically. It would be nice to think that the main reason
was so that the record was reflected accurately, and so that the patient's 'story' was
more transparent. This, unfortunately, is not apparent in many of the current
implementations of the EHR available in the UK. A good EHR will provide different 'views'
of the data contained in it depending upon the desired context and wishes of the viewing
clinician. The POMR was described by Larry Weed in 1968 and there can be few clinicians
from this time to the early 1980s who have not had at least one attempt at a paper
implementation of the concepts in their own records. There is no doubt that it provides a
readily understandable structure for recording and viewing the patient record. It is,
however, best suited to the electronic environment, due to the work needed to keep a paper
system up to date.
Following this model, the patient record is divided into a
series of sections, each of which is given a heading which broadly can be called a
'problem' either by the patient of the clinician. The label associated with the heading
may change as the problem or the understanding of it develops. Items of data in the
patient record (entries - which may be simple notes, medication records, pathology reports
or even images and drawings) are grouped under one or more of the problem headings. As the
clinical record is used and data is being added, the appropriate heading is chosen and the
new entries are 'put under' this heading. When a problem is viewed, only information
relevant to the currently selected problem is viewed. In order to view all entries for all
problems in the order that they were entered a separate 'Journal' view is needed.
A further development of the basic POMR involves the use of
the 'SOAP' note (Subjective, Objective, Assessment, Plan). It provides a standard approach
to recording information under a problem. Once again, there has been much enthusiasm but
little sustained take-up in paper records of these techniques due to the increased
administration demands. Rector and Purves, have laid down many of the
principles which are now integral to many EHRs as well as many of their limitations. There
is, however, a popularity of the POMR within current practice upon which there is room to
build.
Limitations of the POMR
Thus it can be seen that, although the POMR is a popular
medium for data entry and viewing, there is certainly room for improvement and
development. These developments must be tempered with knowledge of two conflicting
pressures. There is a marked reluctance to reduce the amount of time taken in interaction
with the patient in favour of entering data onto a computer. The new items discussed below
will only be practical if they either require no extra time for data entry or if, by
improving the ability of the clinician to gain a 'story' from the record, they reduce time
spent elsewhere.
As has been defined, a 'problem' consists of a heading and
a list of all entries grouped under this problem. The problem may be filtered according to
status (Current, Dormant or Resolved) and may be sorted into chronological order, either
by date of data entry (Flu 1/8/96) or by the date to which the entry applies (entering a
historical note of 'Syphilis 1927' on the same day as the diagnosis of flu).
Figure 1: A problem timeline
A problem view generally allows one problem to be
considered at a time. To give a better representation of all the problems that the patient
has, a timeline may be created (see Figure 1). Each problem exists as a bar along a time
axis. The left end of the bar is at the time that the problem started (or when the
physician became aware of it). The right end of the bar stops where the condition
resolved.
For the purpose of this paper this concept will be defined
as 'a communication about the patient between two or more individuals, at least one of
whom is a member of the health care team currently involved'. This communication may
be face-to-face but could be a letter, report or even telephone call. An encounter could
be crudely derived by collecting together all entries made within a certain time span (for
example, Monday morning 9.30 a.m. - 12.30 p.m.). However, this approach would not fulfil
many uses. It is more important to include in the recording of an encounter the time, date
and reason for the encounter as well as the site (face-to-face, letter etc.) and persons
involved. Many practices use electronic appointment systems, and these data can usefully
be automatically derived and, of course, analysed. To place the encounter concept into the
concept of the timeline, the diagram in Figure 2 shows the display extended to include a
single encounter on 12th October 1993. This encounter could have dealt with the
problems of shoulder pain and asthma but, in fact only touched upon asthma. It can be seen
that a clinical system must be designed to collect encounters as entities within the EHR.
All note entries may then be 'linked' to these encounters and displayed accordingly.
Figure 2: A timeline showing a single encounter
In real life, many 'problems' are not active all the time
but have a cycle of activity and inactivity. A good example of this is the course of
Asthma, which may vary during the course of a single year (here the allergen is a pollen
which is only present for a few weeks every year) to a period of several months where the
patient has no symptoms reported at all. The periods where the problem is reported to
be active to the health care team may be known as the episode of the problem.
Although an encounter may apply to many problems an episode
may only ever be associated with a single problem. Hence, an asthmatic who gets wheezy
during a cold would have an episode of URTI coincidental with their episode of Asthma
(that is, two separate but clearly related episodes). In the encounter view, they would
appear together.
While it is possible to attempt to derive episodes from the
patient data, the wide range of data collection techniques and types of data would make it
very error-prone. Thus it will be necessary explicitly to enter episodes into the EHR.
This could be done in the same way as encounters where an explicit entity was created.
Alternatively a 'tag' could be attached to another entry to label this entry as the start
of a new episode. The tag could be labelled to describe the type of episode it was. Once
such an entry has been created other entries can then be linked to it. Then all entries
for an episode can then be grouped and viewed together. The episodes of a problem can then
be extracted and displayed in 'cut-down' form (see Figure 3).
Figure 3: A timeline showing episodes
In both primary and secondary care, the commencement of an
episode of care is usually easy to determine. In secondary care, the end of an episode
will often be when the patient goes home from hospital or when they are discharged from
Out-patient follow up. In primary care, however, the end of an episode is more difficult
to establish. In many cases the patient will not return to report the resolution, say, of
a sore throat or even more important conditions.
There are, of course, some problems which are better suited to the episode approach than others. This will depend upon the nature of the problem as well as the interpretation of the user. A number of strategies are possible to determine this end point.
Sub-problems
A POMR which has been in use for some time will often
become complex. Some problems have many components. Ischaemic Heart Disease may have
elements of Angina, Myocardial Infarction and Left Ventricular Failure, all of which need
to be considered separately. Further structuring is desirable. Hence sub-problems are
problems contained within a problem. In other ways they behave just as problems but
provide a grouping mechanism for a list of related entries. They can, of course, be
episodic. In the example of IHD above, entry of all notes and medication under a problem
heading of 'IHD' can be seen to be clearly inadequate. Each component could, however, be
represented as a sub-problem. The detail relating to each sub-problem is linked to this
sub-problem and not to the top level heading and may only be displayed by selecting the
sub-problem.
A final area where timelines may be used is in the display
of information relating to who made the entries and where. We are entering an era where we
are starting to consider the transfer of a patient record between primary care sites when
the patient moves, and sharing information in an appropriate fashion with secondary care.
It will be vital to understand who made an entry as well as where and when. In the same
way that episodes of care can be used in a timeline to be displayed along with the problem
view, it will be necessary to view the source of notes in the same 'cut down' form. This
is demonstrated in Figure 4. It will, of course, be necessary to have available the full
details of the actual person making the entries for more detailed analysis as well as for
medico-legal reasons.
Figure 4: The source of notes superimposed on a timeline
The POMR is a popular means of entering medical data. It
can be found within many electronic models of the health record. Current implementations
need to be enhanced by the use of timelines to make them more transparent to the
increasing number of possible users of the information. There is still no adequate
definition and acceptance of a standard set of terms surrounding the EHR. The above
definitions of Problem, Sub-problem, Encounter and Episode are offered for refinement and
discussion by clinicians, system suppliers and clinical bodies. Care must also be taken in
the attribution of clinical records when they are transferred between sites. Timelines are
one way of making sure that it is easy to view these data.
This paper is derived from discussions with and meetings of
the Clinical Computing Special Interest Group of the PHCSG.
1 Hayes G. Computers in the Consultation. The UK Experience. SCAMC 1993:103-106
2 Markwell D. Computerised records in general practice: Guidelines for Good Practice. NHS-E, March 1995
3 Hayes G. Archiving and deleting patients' electronic medical records. In Teasdale S (ed.). Proceedings of the PHCSG Annual Conference 1996, PHCSG, Worcester, 1996:
4 MIQUEST Project Board. MIQUEST Project report Version 3.3. MIQUEST Project Board, 1994
5 Weed LL. Medical records that guide and teach. New Engl J Med: 1987; 278:593-9 and 278:652-657
6 Weed LL Medical records, medical education and patient care. Press of the Case Western Reserve University, 1969
7 Purves I. The current state and future needs of the electronic medical record for primary health care: a pragmatic view for the United Kingdom. PHCSG Annual Conference proceedings 1993: 113-122
8 Rector AL, Nowlan, WA, Kay S. Foundations for an Electronic Medical Record. Methods Inf. Med 1991; 30:179-86
9 Warner H, Manson C, Livingstone J, Bray B. Enroute toward a computer based patient record. The ACIS Project. SCAMC 1995:152-156
10 Cousins S, Kahn M. The visual display of temporal information. AI in Medicine 3; 1991:341-357