Clinicians & Students: Problem Oriented Medical Record With MedScrub

A problem-oriented medical record (POMR) organizes every note, order, and result around a discrete list of patient problems rather than around the source of the information. Lawrence Weed built the model in the 1960s on four components: a database, a problem list, an initial plan for each problem, and progress notes in SOAP format. The payoff is straightforward: anyone reading the chart can see exactly what’s wrong, what’s being done about it, and why.

TL;DR:

• The problem list should reflect active, high-certainty diagnoses or symptoms, prioritized by clinical relevance and updated regularly to prevent rot.
• Progress notes in SOAP format must be concise, targeting each problem with clear subjective, objective, assessment, and plan sections that directly inform management.
• Effective EHR implementation of POMR requires simple layouts, context-sensitive data displays, automation, and comprehensive training to ensure high adoption and satisfaction.
• POMR enhances team communication, clinical reasoning, and billing linkage but can fragment care in cases of multimorbidity if not layered with goal-oriented strategies.
• Tools like MedScrub automate problem-based summaries and flag care gaps, but clinicians must review drafts to maintain control and accuracy in problem-oriented documentation.

Table of Contents

• What Is a Problem-Oriented Medical Record’s Origin Story?
• The Four Core Components Of Problem-Oriented Charting
• How Do You Write A POMR Note Step By Step?
• What Does EHR Implementation Of Problem-Oriented Charting Look Like?
• Advantages And Limitations Compared To Other Record Formats
• Templates And Worked Examples You Can Reuse
• A Clinician-Teacher’s Take On Problem Lists
• Using MedScrub To Support Problem-Oriented Documentation
• Sources
• FAQ

What Is a Problem-Oriented Medical Record’s Origin Story?

Lawrence Weed introduced the POMR in the 1960s because he was frustrated by charts that read like diaries: a jumble of nurse notes, lab slips, and physician impressions filed by date and source rather than by clinical logic. A reader had to reconstruct the case from scattered fragments. Weed’s fix was to force every entry to answer one question: which problem does this address? The foundational review of problem-oriented charting traces this shift and describes the four components that still define the model today: a database, a master problem list, an initial plan tied to each problem, and SOAP progress notes.

The problem list functions as the chart’s table of contents. Every diagnosis, symptom, or risk factor that needs tracking gets a number and a name, and every subsequent note references that number. This is what creates what clinicians sometimes call the SOAP cycle: you gather subjective and objective data, form an assessment, write a plan, then return days or weeks later and repeat the loop against the same numbered problem. Nothing drifts unaccounted for, because the list itself is the audit trail. Early computerized systems like PROMIS attempted to formalize this cycle for bedside retrieval decades before EHRs existed, an effort documented in later analysis of how POMR could move forward in digital systems.

Weed’s real insight wasn’t structural. It was cognitive. A record organized by problem forces the clinician to commit to an assessment rather than hiding behind a wall of raw data. That discipline is why medical schools still teach POMR as the default charting model, even though most students will encounter dozens of EHR interfaces that implement it imperfectly.

POMR fits some clinical situations better than others:

• Chronic disease management benefits enormously, since diabetes, hypertension, and heart failure each need their own thread of assessments and plans that persist across visits.
• Multi-specialty inpatient care benefits because consultants can jump straight to the problem they were asked to address instead of parsing an entire unstructured note.
• Single-encounter acute care, like a walk-in laceration repair, gains less from strict problem numbering since there’s often only one issue and no long-term tracking need.
• Undifferentiated complaints, where the diagnosis isn’t yet clear, sometimes fit better under a goal-oriented or symptom-oriented framework until a working diagnosis solidifies.

That last point matters for multimorbid patients, where a rigid problem list can fragment care instead of clarifying it. More on that trade-off later, but it’s worth flagging early: POMR is a tool, not a religion.

The Four Core Components Of Problem-Oriented Charting

Every POMR rests on four building blocks, and getting sloppy with any one of them undermines the whole record. The original review of the model lays these out as the database, the problem list, the initial plan, and progress notes, and each has its own internal rules that students rarely get taught explicitly.

The database is the foundation: history, physical exam, and baseline labs collected at intake. The mistake most trainees make is treating the database as a dumping ground for every data point available. It shouldn’t be. The database needs the essential elements, chief complaint, past medical and surgical history, medications, allergies, family and social history, review of systems, physical exam findings, and baseline labs or imaging, indexed so a reader can locate any piece in seconds. Optional extras (detailed social determinants, extended family pedigree, prior records from outside systems) belong in the database too, but they should be flagged as supplementary rather than mixed in with the core dataset.

The problem list is where most of the teaching value lives. Each entry should be classified as active or inactive, and phrased at the highest level of diagnostic certainty the clinician can defend. That distinction, diagnosis versus symptom, is where students stumble most often. If the cause is confirmed, name it: “Type 2 diabetes mellitus,” not “elevated blood glucose.” If it isn’t confirmed yet, list the symptom itself: “chest pain, etiology undetermined,” rather than guessing at a diagnosis you can’t support. Prioritize the list by acuity and relevance, not by the order problems were discovered.

The initial plan attaches three elements to every new problem: a diagnostic component (what tests or consults will clarify the picture), a therapeutic component (what treatment starts now), and a patient education component (what the patient needs to understand and do). Skipping the education piece is the most common shortcut, and it’s the one that most often shows up later as a missed follow-up or a non-adherent patient who was never actually told what to expect.

Progress notes follow the SOAP structure, and each section has a specific job:

1. Subjective captures what the patient reports: symptoms, changes since the last note, concerns. No lab values here, no vital signs.
2. Objective holds only measurable data: vitals, exam findings, new labs, imaging results.
3. Assessment states your clinical interpretation of that data for this specific problem, including whether it’s improving, worsening, or unchanged.
4. Plan lists the next concrete steps, tied explicitly back to the assessment.

Every SOAP note should map to one numbered problem. A note that tries to cover three problems in one undifferentiated paragraph defeats the entire purpose of the list.

Pro Tip: When you’re unsure whether a finding belongs in the problem list or the database, ask whether it changes management. If it does, it’s a problem. If it’s just background information, it stays in the database.

How Do You Write A POMR Note Step By Step?

Writing a clean SOAP entry during a live encounter is a discipline, not a talent. Most clinicians who write fast, legible notes have internalized a fixed sequence rather than improvising each time.

Start with a mental (or literal) checklist before you type a word:

• Confirm which numbered problem this note addresses. If it touches two problems, write two notes.
• Pull subjective data directly from what the patient said, not your interpretation of it.
• Record objective findings exactly as measured, no rounding or paraphrasing of numbers.
• State your assessment as a judgment, not a restatement of the objective section.
• End the plan with specific, dated next steps, not vague intentions like “continue to monitor.”

Efficiency matters as much as structure, especially in high-volume clinics. Smart use of macros and refreshable smartlinks, templated text blocks that auto-pull current vitals or med lists into a note, cuts documentation time without sacrificing accuracy, since the clinician still has to review and edit before signing. One efficiency habit worth adopting: don’t repeat an unchanged assessment and plan verbatim across multiple visits. If nothing changed since last time, say so directly (“stable, no change to plan”) and reference the prior note rather than retyping three paragraphs that say the same thing.

Knowing when to write a new note for a problem, and when to defer, also saves time. A problem that hasn’t been addressed this visit doesn’t need a fresh SOAP entry; it can sit untouched on the list until it becomes relevant again. Charting a full SOAP note on every listed problem at every visit, regardless of whether anything changed, is one of the fastest ways to bloat a chart into something nobody wants to read.

Here’s a compact way to see how the pieces fit together for a single visit:

A short anonymized example, drawn from a routine outpatient follow-up for hypertension, shows how tight this can be:

Problem 3: Hypertension, active. S: Patient reports no headaches, chest pain, or dizziness. Taking lisinopril daily, no missed doses. O: BP 138/86, HR 72. No peripheral edema. Basic metabolic panel from last week within normal limits. A: Blood pressure improved but not yet at goal on current dose. P: Increase lisinopril to 20 mg daily. Recheck BP in 4 weeks. Reinforce low-sodium diet counseling given at last visit.

Four lines per section, no filler, every sentence earning its place. That’s the target length for the majority of stable, ongoing problems.

What Does EHR Implementation Of Problem-Oriented Charting Look Like?

Digitizing a POMR sounds simple until you try it. Most EHR interfaces default to chronological, source-based views (all notes, all labs, all orders in separate tabs) because that’s easier to build than a true problem-linked interface. Making problem orientation actually usable inside an EHR takes deliberate design work.

The clearest published account of what works comes from a documentation toolkit built for a commercial EHR, described in research on a problem-oriented toolkit’s design and adoption. The design lessons translate well beyond that specific system:

• Keep the visual layout simple. A cluttered problem view with too many competing data elements gets ignored, no matter how complete it is.
• Surface context-sensitive data. Show the labs, meds, and notes relevant to this problem, not every data point in the chart.
• Make the interface predictable. Clinicians build muscle memory fast when a tool behaves the same way every time; inconsistent layouts kill adoption.
• Automate note generation where possible, pulling structured data into a draft note the clinician edits rather than starting from a blank page.

The results speak to how much design discipline matters. That toolkit went from several thousand visits in its first nine months to a vastly larger number of ambulatory visits per month by April 2022, spread across many departments, a scale of voluntary adoption that’s rare for any new documentation feature. On the inpatient side, a Stanford ICU study on problem-based charting found that implementing problem-based charting increased the mean number of new problems documented per encounter and improved clinician recall of conditions like sepsis and acute renal failure compared to the prior charting model.

Toolkit adoption jumped from roughly 8,385 visits in the first nine months to over 92,000 ambulatory visits monthly less than two years later, evidence that problem-oriented tools spread fast once the interface friction is solved.

The obstacles that block adoption are consistent across implementations: clinicians resist anything that adds clicks, training gets skipped when rollout is rushed, and legacy habits (dumping everything into one long note) die hard. Mitigating that takes a real training campaign, not just a system update announcement, one that repeatedly frames the problem list as the chart’s table of contents rather than one more field to fill in.

Measuring whether an implementation is working comes down to three signals: usage rate (are clinicians opening the problem-oriented view voluntarily, or avoiding it?), problem recall (do clinicians reference the correct problem numbers in later notes?), and clinician satisfaction (do surveys show the tool saves time or adds burden?). A tool that scores well on adoption numbers but poorly on satisfaction usually means the interface is fast but the notes it produces are shallow.

Advantages And Limitations Compared To Other Record Formats

POMR earns its reputation for a few concrete reasons. It improves communication across a care team because anyone opening the chart can find the relevant thread without reading the whole history. It’s a stronger teaching tool, since trainees learn to reason problem by problem rather than data-dump. And it links orders directly to the problem that justifies them, which supports both clinical reasoning and billing defensibility, a connection reinforced by findings on toolkit-driven order linkage.

The limitations are just as real, and clinicians complain about them constantly:

• Maintaining an accurate problem list takes ongoing effort; lists rot fast when nobody prunes resolved or duplicate entries.
• Strict problem orientation can fragment care for patients with many interacting conditions, where the “problems” aren’t really separate at all.
• Writing a fully structured SOAP note for every problem at every visit takes real time, and rushed clinicians often shortcut the assessment section into a copy-paste of yesterday’s plan.
• Source-oriented records (chronological, department-based filing) still work fine for simple, short-term episodes where problem tracking adds no real value.

For patients with multimorbidity, a pure problem-by-problem approach sometimes obscures the bigger picture: a frail 84-year-old with five chronic conditions may be better served by a plan organized around functional goals (staying independent, avoiding hospitalization) than around five separately tracked diagnoses. A review on advancing the problem-oriented model argues exactly this: combining problem-oriented and goal-oriented elements preserves the clarity of POMR while adding the coordination that complex, multimorbid patients need.

The rule of thumb worth carrying into practice: use strict problem orientation for discrete, trackable conditions, and layer in goal-oriented framing whenever the patient’s real priority is a functional outcome that cuts across multiple diagnoses at once.

Templates And Worked Examples You Can Reuse

Problem list entries work best as short, declarative phrases with an explicit status marker. A few templates worth adapting:

1. 1. Type 2 diabetes mellitus, active, diagnosed [year] — diagnosis-level entry with clear status.
2. 2. Hypertension, active, on lisinopril — includes current management context in the label itself.
3. 3. Appendectomy, inactive, [year] — historical surgical problem kept for reference, not active management.
4. 4. Chest pain, etiology undetermined, active — symptom-level entry used when a diagnosis isn’t yet confirmed.
5. 5. Tobacco use disorder, active, counseled on cessation [date] — behavioral problem with a documented intervention.

Order the list by clinical priority, not discovery order: the condition most likely to cause harm or drive today’s visit goes first, chronic stable conditions follow, and resolved or historical items move to an inactive section at the bottom.

A short inpatient admission SOAP note, fully anonymized, might read like this for a new problem:

Problem 1: Community-acquired pneumonia, active, new. S: Patient reports three days of productive cough, fever, and shortness of breath on exertion. Chest X-ray shows right lower lobe infiltrate. WBC 14.2. A: Findings consistent with community-acquired pneumonia, moderate severity. P: Start ceftriaxone and erythromycin per hospital protocol. Repeat chest X-ray in 48 hours if no clinical improvement.

An outpatient follow-up note for a resolving problem looks noticeably shorter, since nothing new is happening:

Problem 2: Seasonal allergic rhinitis, active, stable. S: Symptoms well controlled on daily antihistamine, no breakthrough congestion. O: Nasal mucosa normal on exam. A: Stable, adequately managed on current regimen. P: Continue current antihistamine. Follow up as needed.

Pro Tip: Build your own template library from anonymized examples like these, stripped of any identifying detail, and turn the strongest ones into EHR macros. A well-built macro for a common problem (stable hypertension, routine diabetes follow-up) can cut documentation time for that visit type by more than half.

For teaching purposes, converting real (de-identified) cases into templates is more useful than inventing hypothetical ones, since it exposes trainees to the actual phrasing patterns and level of detail that hold up under chart review.

A Clinician-Teacher’s Take On Problem Lists

The hardest part of teaching POMR isn’t the format. It’s convincing trainees that a five-minute problem list is worth the time it costs during a twelve-patient morning. The clinicians who do this well treat the list as a living document they revisit at every visit, not a one-time admission task they never touch again.

When I mentor someone on this, the advice that sticks is simple: never let a trainee close a chart with an assessment that just restates the objective data. Push them to commit to a judgment, even a tentative one, because that’s the entire point of the model. And make clear, early and often, that whoever last touched the problem list owns its accuracy until the next person updates it. Ambiguity about ownership is how problem lists rot.

— Clint

Using MedScrub To Support Problem-Oriented Documentation

If you already run a POMR-style workflow, the friction usually isn’t the format, it’s the time it takes to keep every problem list current across a full patient panel. MedScrub connects directly to major EMR systems, including Epic and Oracle Health, and turns scattered chart data into problem-based summaries, lab trend overviews, and draft SOAP notes clinicians edit rather than write from scratch.

A few specific ways it maps onto the workflows covered here:

• Automated problem-based summaries that pull relevant labs, meds, and prior notes into one view before you ever open the chart.
• PHI anonymization that keeps patient data on the user’s machine for AI processing.
• Care gap and follow-up tracking that flags problems on the list going unaddressed across visits.

One clinic’s experience with this kind of nightly chart preparation and open-plan tracking is detailed in the Monarch Health case study. MedScrub assists documentation; it doesn’t replace clinical judgment, and every draft it produces still needs a clinician’s review before it becomes part of the record. Clinicians can compare the Solo, Practice, and Enterprise plans and start a trial to see how it fits an existing problem-oriented workflow.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

FAQ

What is the difference between a source-oriented and a problem-oriented medical record?

A source-oriented record files information by where it came from, nursing notes, lab reports, physician notes, each in a separate section organized chronologically. A problem-oriented medical record instead organizes everything around a numbered list of the patient’s active and inactive problems, so every note and order ties back to a specific issue rather than a department.

What are the four components of a POMR?

The four components are the database, the problem list, the initial plan for each problem, and progress notes written in SOAP format. This structure comes directly from Lawrence Weed’s original model and remains the standard taught in medical education today.

What are the three types of medical records?

Medical records are generally classified as source-oriented, problem-oriented, and integrated (or hybrid) records that combine elements of both. Some frameworks also describe goal-oriented records as a fourth category, particularly useful for patients with multiple chronic conditions where combining problem and goal orientation works better than either alone.

What are the four components of the problem-oriented record?

The database, problem list, initial plan, and SOAP progress notes make up the core structure, each serving a distinct function from data collection through ongoing follow-up. A tool like MedScrub can help clinicians keep problem-based summaries and progress notes current across a full patient panel without retyping unchanged data at every visit.

Does MedScrub replace the need to write SOAP notes manually?

No. MedScrub drafts problem-based summaries and note content from existing chart data, but a clinician still reviews and finalizes every entry before it becomes part of the record. Pricing details for the Solo and Practice plans are listed on MedScrub’s site for clinicians evaluating a trial.

Recommended

• For Clinicians
• Monarch Health Case Study
• eSpiral Case Study