Every chart has to answer a question it rarely answers cleanly: what conditions does this patient carry, and which are still active? You know it visit to visit, but the record around you usually does not. The diagnoses are written into whatever note mentioned them, phrased a little differently each time, and almost never coded the same way twice.
So the problem list, the one thing you would want the software to hand you on demand, is something you reconstruct by reading. A diagnosis made two years ago, a condition that resolved last spring, a rule-out you never closed out. The information is in the chart. It just is not in a shape the chart can total up for you.
When the problem list lives in prose
This is most expensive exactly where it matters most. Behavioral health carrying several overlapping diagnoses, primary care managing conditions across years, any practice where the same problem list has to be right at the top of every note. When those diagnoses are free text, three things slip.
You lose the code, so nothing maps to billing or to a registry. You lose the status, so an active condition and one that resolved a year ago read the same on the page. And you lose the carry-forward, because there is no single list to bring into the next visit, only the last note that happened to mention each problem. Every visit you retype, and every visit the list and its history drift a little further apart.
Why is a patient's problem list hard to keep current in most EHRs?
In many EHRs, diagnoses are typed as free text inside individual notes rather than stored as coded, structured entries. There is no single problem list to carry forward, so each visit means retyping it, and an active condition reads the same as one that resolved long ago. Because the work is manual and uncoded, the list, its statuses, and its history slowly fall out of sync.
What the Diagnosis block captures
The Diagnosis block lives inside a progress note. You do not leave the chart or open a separate problem-list module. Type /diagnosis and pick Diagnosis from the Common group.
Each Diagnosis block holds one diagnosis, captured as a coded snapshot rather than a paragraph. To record several conditions you add several blocks, and in practice you rarely add them by hand, because the carry-forward and AI charting below build the set for you.
The heart of the block is the diagnosis itself. Search the ICD-10-CM catalog and pick a coded concept, and the block stores the code, its display name, and the code system version together (for example F33.0, Major depressive disorder, recurrent, mild). When you want to note a condition without coding it yet, type it in as free text and the block records it as Uncoded. A fresh block starts in that uncoded, unfilled state until you fill it.
Under the diagnosis sit the Coding Details. Status is a pick-list of four values: Active, Inactive, Resolved, and Rule-Out. Severity is Mild, Moderate, or Severe. Onset Date and Resolved Date are date pickers, and neither accepts a future date. The block also carries its own date and time stamp, so the entry is pinned to the moment you documented it.
Status is the field you can mostly leave alone. A diagnosis reads Active when its status is set to Active or left blank, and it drops off the active list once you mark it Inactive, Resolved, or Rule-Out, or set a Resolved date on or before today. You record onset and resolution as dates, and Active or not follows from them.
Does Oli Health code diagnoses to ICD-10-CM?
Yes. The Diagnosis block searches the ICD-10-CM catalog, and selecting a concept stores its code, display name, and code system version together, so the diagnosis is coded rather than free text. When you would rather not code a condition yet, you can enter it as an uncoded free-text diagnosis and code it later. Each block holds a single coded or uncoded diagnosis with its own status, severity, and onset.
Coding the diagnosis is also what makes it useful downstream. Billing is the obvious example, because a claim or a superbill needs exactly the structured ICD-10-CM code the block already holds. We are building that hand-off now: a coded diagnosis will flow automatically into the patient's insurance billing and superbill, the code already attached, so you are not retyping it into a separate billing screen. That work is in progress. Today the block captures and codes the diagnosis; the automatic billing pull is on the way.
Building the problem list without retyping
Most of the list arrives before you type anything. Open a new Diagnosis block in a note where there are no other diagnosis blocks, and Oli loads the patient's currently active diagnoses from earlier notes, one block per condition, with duplicates removed by ICD-10-CM code (or by name for uncoded entries) so the most recent version of each wins. A short confirmation tells you how many loaded. From there you reconcile: confirm what is unchanged, mark what resolved, add what is new. You are editing a problem list, not rebuilding it from memory.
Recording the visit removes most of what remains. When the Diagnosis block is part of your note template and you record the encounter, Oli's AI charting reads the transcript and fills the block in as it drafts the rest of the note. A diagnosis discussed during the visit lands in the right fields, code, status, severity, and onset, instead of a sentence you have to unpack afterward. You open a draft that is already filled in, read it against what you remember, fix anything the model misheard, and sign off. Nothing enters the chart without that review.
Closing out a condition is just its status and dates. Mark it Resolved or set a resolved date, and next time it drops out of the active list that carries into the following visit. The reconciliation you do today becomes the starting point for the reconciliation you do next month.
Can AI charting add a diagnosis from a visit recording?
Yes. If the Diagnosis block is part of your note template and you record the encounter, Oli's AI charting reads the visit transcript and fills the block as it drafts the note, placing the condition, its ICD-10-CM coding, status, severity, and onset in the right fields. The clinician reviews the draft, corrects anything inaccurate, and signs off, so no diagnosis reaches the chart without a human check.
Seeing the whole history with Lens
Capturing a clean, coded diagnosis each visit is half of it. The other half is reading those entries as one picture, and that is what Lens does. Lens reads the structured blocks across every note a patient has and rolls them up on the patient dashboard.
The Diagnosis card shows the active and recently documented diagnoses, each with its code, severity, onset, status badge, and the date of the note it came from. It answers the everyday question, what is this patient carrying right now, without opening a single note, and the active ones sort to the top.
The More button is where tracking lives. The number on it, More (6) for this patient, is the total count of diagnosis entries on file across every visit. Open it and the Diagnosis Full History view appears.
It is one table with seven columns: Date, Diagnosis, Code, Status, Severity, Onset, and Resolved, sorted newest first, loading twenty-five rows at a time with a Load More for longer histories. Every diagnosis you have documented for this patient stacks in date order. A condition that was active at one visit and resolved by the next, a rule-out you opened and later closed, something coded this spring, all of it reads as a sequence instead of a memory you assemble from old notes.
The reason this works is the structure underneath it. Because every diagnosis is the same kind of coded object with the same fields, the change from one visit to the next is something Lens can line up and show you, rather than something you piece together by rereading.
How do you see a patient's full diagnosis history over time?
Open the Diagnosis card on the patient dashboard and select More. Every diagnosis from every documented note appears in one table with Date, Diagnosis, Code, Status, Severity, Onset, and Resolved columns, sorted newest first and loaded in pages of twenty-five. New diagnoses, status changes, and resolutions read as a sequence across visits rather than scattered across separate notes.
The patient can report conditions at intake
The Diagnosis block is not limited to progress notes. Add it to an intake form template, and the patient can report a condition from the client portal before the visit, while they have the time you rarely get in a packed appointment.
What comes back is marked as patient reported, and it does not merge itself into the chart. The submission waits for you to review and accept it, the same confirmation step that governs the carry-forward and the AI draft. Accept it and the diagnosis becomes part of the structured record and shows up in the Lens card and Full History with its source noted, so you can tell an entry came from a form rather than from a visit. Decline it and nothing is written. That accept-before-it-counts step is the same idea behind patient intake reshaping the whole chart, not just the form, narrowed to a single block.
Can patients report their existing conditions before an appointment?
Yes. A clinician can add the Diagnosis block to an intake form template, and the patient reports a condition from the client portal before the visit. The entry arrives marked as patient reported and waits for the clinician to review and accept it. Once accepted, the diagnosis becomes part of the chart and appears in the Lens card and Full History with its intake source noted. If the clinician declines it, nothing is written.
Where the diagnosis block earns its place
Anywhere the problem list has to be right and has to carry. Behavioral health practices tracking several active diagnoses with their severities and onset dates. Primary care managing chronic conditions across years of visits. Naturopathic and functional clinicians who want a coded problem list sitting alongside the rest of a structured chart. The block pairs with the others: the same structured-capture idea behind capturing a patient's medications and carrying the active list forward and behind pulling lab values into fields and trending them over time is what lets a diagnosis, the drug treating it, and the number it should move sit on one timeline.
None of this decides anything. The block is a record you reconcile each visit, the active status follows the dates you set, and anything added waits for your review before it counts, whether the carry-forward brought it from the last note, AI charting drafted it from a recording, or a patient reported it at intake. Oli keeps the problem list current, coded, and comparable. The clinical calls stay yours.
Try it on one patient's chart
The fastest way to understand it is to code a couple of diagnoses on one patient, then open a new note next week and watch the active problem list come back already filled in. Reconcile it, resolve one, add one, and open the Full History to see the change laid out by date.
You can do that on Oli Health for free. Practitioners who create an account before August 31, 2026 get the full platform free for the life of the account, with the clinical blocks and Lens included rather than locked behind a tier.
Create your free-forever account and try it on a real patient, or book a live demo and we'll walk you through it.
