The Problem Oriented Medical Record just a little more structure to help the
world go round?
Mike Bainbridge, Peter Salmon, Ann Rappaport, Glyn Hayes, John
Williams, Sheila Teasdale
Clinical Computing Special Interest Group (CLICSIG) of the PHCSG
Introduction
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.
The 'Current' POMR
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
1
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
1. Quick to pick up but can be complex to maintain.
2. Not all headings are 'problems' in the strict sense of the word. For example, the
3.
4.
5.
6.
7.
8.
heading of 'Vaccinations' is used commonly to denote where all the entries related to
a vaccination history may be found.
A 'single problem consultation' is rare. Many different issues may be discussed within
a single consultation (feeling short of breath after argument with spouse, for
example).
Information may legitimately belong under more than one problem heading. A blood
pressure reading could appear under both 'Adult screening ' and 'Essential
Hypertension' or even 'Anxiety State'. In each of the above examples, a marginally
raised blood pressure would have a markedly different meaning.
Problems are often linked in a causal way (pneumonia following a fall causing
fractured neck of femur). There is no easy way to express this in a POMR.
The POMR only gives a crude measure of the state of a problem. The problem is
either 'Current', 'Dormant' or 'Resolved' (the best examples are Surgical - for
example, Appendicitis, where the boundaries are generally obvious). In the real
world, however, problems tend to go in cycles. Things get better and then get worse
(for example, Asthma) over a long period.
Different clinicians, and indeed anyone with the right to view the clinical record, need
different amounts of information from the record as well as different views. A
Consultant Anaesthetist looking at a record in Intensive Care would need to see all
127 blood gases done since admission. A GP would probably be happy with the
information: 'Acute Myocardial Infarction, in ITU for 3 weeks'.
Some problems are complex and hence difficult to read. Those with few entries are
conversely easy to read. Hence the problem of 'drowning in data' that the POMR is
meant to avoid comes to the fore again.
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
2
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.
The Timeline
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.
Encounters
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
3
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
Episodes
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.
Episodes within problems
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).
4
Figure 3: A timeline showing episodes
The scope of an episode
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.
1. Manual entry where circumstances allow.
2. Consider the episode as the period containing patient encounters within which the
3.
4.
problem was touched upon. (This could be regarded as both note entry as well as
medication entry and reauthorisation and also even prescription printing.) The
episode would close when the last encounter was recorded.
Define the duration of an encounter for a particular problem and hence the end point.
Hence an URTI might last 10 days, an uncomplicated fractured femur might last 8
weeks.
The initial episode is implicit in the creation of the problem heading (this, of course,
may change over time). All entries added to the problem before the explicit creation of
a further episode are linked to the first one. Thus the user must make a deliberate
action to record a new episode.
Sub-problems
5
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.
Attribution of a note
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
Conclusions
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
6
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.
Acknowledgment
This paper is derived from discussions with and meetings of the Clinical Computing Special
Interest Group of the PHCSG.
References
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
7