Taking the problem oriented medical record forward

Peter Salmon, Ann Rappaport, Mike Bainbridge, Glyn Hayes, John WilliamsPrimary Health Care Specialist Group of the British Computer Society

The problem oriented medical record (POMR) hasproved to be very successful in providing astructure that helps doctors record their notesabout patients, and view those notes subsequentlyin a manner that quickly gives them a goodunderstanding of that patients history'. Thisapproach has been validated by the AmericanInstitute ofMedicine2. With the increased use ofcomputer systems that implement the POMR bydoctors, the limitations of this structure havebecome apparent, and there is clearly scope fordeveloping the model further to improve thequality of the data recorded, and adding meaningto it.

This paper describes some of the limitations of thePOMR, and discusses a number ofareas in whichit may be extended Crucially, this is done in amanner which is both implementable, and usable.The extensions explored include some types ofentity including encounters, episodes andsubproblems; and an alternative view - theTimeline. The terminology used for the extensionsis clarified.

Mechanisms by which these extensions have beenimplemented are described. Ways in which systemscan manage these extensions automatically aresuggested. Such implementations are constrainedby the need not to allow the demands of thecomputer to intrude into the patient encounter.They are also constrained by the requirements forreporting by professional and governmentalinstitutions, and by what is pragmatically feasiblein software and hardware.

INTRODUCTIONThere are many reasons doctors have in choosingto collect the patient medical record (PMR)electronically. One is to reflect it back to themduring the patient encounter in ways which helpthem to quickly assimilate the key aspects neededto properly treat their patients. In this way, at itsbest, the computer directly improves the quality ofpatient care3. A good electronic PMR (EPMR) willprovide different "views" of the data depending onthe context the doctor wishes to see. This is bestdone using a structured medical record.

0195-4210/96/$5.00 0 1996 AMIA, Inc.

The POMR was first described in 1968 by LarryWeed4. In various forms it has had a widespreaduptake by suppliers and users of medical computersystems because it provides a readilyunderstandable structure for recording and viewingthe patient record.

In the systems some of the authors have designedthe patient record is divided into a series ofsections, each one given a heading which broadlymatches what may be perceived as a problem -either by the patient or by the physician. The labelassociated with the heading may change as theunderstanding of the problem develops, though thehistory of the heading should be available. Itemsin the patient record ("entries" - which may be ofvarious types from simple notes to medicationrecords, pathology reports, images etc.) aregrouped under one or more of these problemheadings. As the author of the record adds entriesinto it, the appropriate heading is chosen to put thenew entries under. When the record is viewed onlythat information pertinent to the currently selectedproblem is viewed. In order to view all the entriesfor all problems in the order in which they wereentered, an alternative "journal" view is provided.As a result of the work done on the POMR, the"SOAP" note was developed (Subjective,Objective, Assessment, Plan)5. This extends theproblem oriented model, by introducing somefurther structure. It provides a standard approachto recording information under a problem. Morework has been done in this area, such as the ASOPmethod6.Other work has taken place since the POMR wasfirst described, and in many ways the complexanatomy of the PMR has been carefully dissected.Rector et al' have taken the understanding of thePMR forward. Many of the principles laid down inthis work have become integral parts ofcomputerised systems. In the process they andPurves described their views of the limitations ofthe POMR (prescriptive vs. descriptive medicalrecords8'9). However there is an elegant simplicityabout the POMR which is appreciated by many ofthose who use it, and on which we would like tobuild.

463

Episodes can be represented in a timeline view.Each episode exists as a bar on the line (figure 4).

Identifying episodes within a problemEpisodes could be derived from the patient data butthe results would be prone to error because of thewide range of types of data, and the different wayspeople choose to store it.

A second approach is to explicitly enter episodesinto the patient record. This could be done bycreating entries that themselves represented an

episode, or by attaching a tag to any other sort ofentry, which indicated that this entry identified a

new episode. The tag could be labelled to describewhat sort of episode it was. Once an episode hasbeen explicitly created, other entries can be linkedto it. All entries for one episode can then be viewedtogether, and the episodes of a problem can beextracted and displayed without the detail of theircontents.

Describing the scope of an episodeThe commencement of an episode of a problem isgenerally straight forward to define. In secondarycare the end of an episode will generally be whenthe patient goes home. However, in primary care

the end of an episode is more difficult to establish.Often the patient will not return to report recovery.So how can the end point be established ? Thereare a number of strategies, which may be used incombination.a) The end point could be manually entered if thecircumstances allowed. This then would be thedefinitive end. Usually this will not be possible.b) Consider the episode as the period containingpatient encounters within which the problem wasaddressed before it was identified as inactive.c) Automatically define the duration (and so theend point) of an episode based on the type of

problem. So for upper respiratory tract infectionsan episode would be regarded as lasting 10 days,for a broken arm 8 weeks, and for a gamma-

globulin hepatitis A immunisation - 6 months.

We suggest that an initial episode is implicit in theexistence of a problem heading. Whether it makessense to consider the problem episodically dependson the nature of the problem, and is in theinterpretation of the user. All entries added to theproblem before the creation of any more explicitepisodes are automatically linked to this firstepisode. All other episodes are explicitly created.The user makes a deliberate action which recordsthat a new episode of a named problem hascommenced. Subsequently all entries under thatproblem are linked to this new episode, withoutfurther action on the users part. This may beoverridden to allow restructuring of the record.

SUBPROBLEMS

There are times when the contents of a problembecomes very complex. Some problems have somany components that each part needs to beconsidered independently. Further structuring isdesirable. This is supported by the concept ofsubproblems.

Subproblems are problems contained within a

problem. In all other ways they behave just likeproblems. They provide a grouping mechanism fora list of related entries. They can be episodic.

One example could be the case of a patient withCrohn's disease. To represent all the differentcomponents of this disease (fever and abdominalpain, diarrhoea, perianal fistulae and abscesses,obstruction and malabsorption etc.) under a singleheading is quite inadequate. Each componentcould however be represented as a subproblem.The detail relating to each subproblem is linked tothe subproblem, not the top level problem and isonly displayed by selecting the subproblem.

There may be value in having a "problem-journalview" which displays all entries under a problem,even if they are under a subproblem of theproblem.

IMPLEMENTATION ISSUES.In order to develop a computer system whichincludes the features mentioned above, a numberof issues of implementation have to be addressed.Most of these are the scope of the developmentteam, but we would like to make a few suggestionsfrom our experience. The main objective was to

466

1992 1993 1994 1995 1999

Figure 4. Sample timeline showing episodles

produce as comprehensive, and accurate a recordas possible whilst not interfering with the doctor-patient encounter.

The computer must be able to make intelligentassumpfions about the data entered Theseassumptions must be both visible and easilycorrected. This requires the system to haveknowledge, and this system knowledge can bedeveloped to enable the capture of some of thetypes of information, without burdening the doctor.

EncountersWe can describe a group of consequtive patientencounters, occuring during part of one day as asession. We suggest that new entries in a patientrecord are automatically linked to an encounter,the characteristics of which are persistent betweenpatients within a session, characteristics whichmay be easily changed. The first encounter createdwill take its characteristics from a set of defaultsfor the user. This will be confirmed by the user. Itwill then become the default "Session encounter"for the rest of the session. Subsequent patients willhave an encounter which matches the sessionencounter created automatically by the system,without confirmation, as the first entry in thatpatients record is saved.

EpisodesWe have said that episodes (after the first) shouldbe explicitly created by users. However the systemcould be instructed to look for specific notes withinnamed problems and automatically generate a newepisode when such an entry was created.

Consider the problem of tonsillitis. If the system isinstructed to create new episodes each time thecoded note "Acute tonsillitis" is created, thefollowing may occur:

1991 New patient with sore throat. Diagnosis:Acute tonsillitis. Read code for acute tonsillitisinserted -> event hooked for new episode. Systemresponds by searching for an existing problem of"Acute tonsillitis" - not found so a new problemwith this title is created.1992 Patient returns with sore throat.Diagnosis : new episode of acute tonsillitis. Readcode for acute tonsillitis inserted -> event hookedfor new episode. System responds by searching foran existing problem of "Acute tonsillitis" - and oneis found so a new episode is created under thisproblem heading.

AcknowledgementsThis work is the result of discussions of theClinical computing special interest group of thePrimary Health care specialist group of the BritishComputer Society.

References1 Hayes G. Computers in the Consultation. TheUK Experience. SCAMC 1993:103-106

2 Institute of Medicine. The computer-basedpatient record: An essential technology forhealth care. Washington DC: National AcademyPress, 1991.

3 Purves I. The current state and future needs ofthe electronic medical record for primary healthcare: A pragmatic view for the United Kingdom.PHCSG Annual Conference proceedings 1993:113-122

4 Weed LL, Medical records that guide and teach.New Engl J Med; 278:593-9 and 278:652-7.

5 Weed LL. Medical records, medical educationand Patient care: Press of the Case WesternReserve University, 1969.

6 Gensinger RA, Fowler J. ASOP: A New methodand tools for capturing a clinical encounter.SCAMC 1995;19:142-146

7 Rector AL, Nowlan WA, Kay S, Goble CA,Howkins TJ, A framework for modelling theElectron Medical Record. Methods Inf Med,1993; 32: 109-119

8 Rector AL, Nowlan WA and Kay S. Foundationsfor an Electronic Medical Record. Methods InfMed 1991; 30:179-86

9 Purves I. The current state and future needs ofthe electronic medical record for primary healthcare: A pragmatic view for the United Kingdom.PHCSG Annual Conference proceedings 1993:113-122

lORogers J & Solomon D: Putting the clinical intoClinical Information Systems. PHCSG AnnualConference proceedings 1995: 20-35

1 IWarner H, Mason C, Livingstone J, Bray B.Enroute toward a computer based patient record.The ACIS Project. SCAMC 1995:152-156

12Cousins S, Kahn M. The visual display oftemporal information. AI in Medicine 3 (1991):341-357

467