gnumed-doc 1.1.7-1 / usr / share / doc / gnumed / user-manual / GmManualBasicProgressNotes.html

<h1><a name="Working_with_Progress_Notes"></a>  Working with Progress Notes </h1>
<p />
Progress notes follow the general concept of SOAP notes as first proposed by L.L. Weed back in the 1970s.
<p />
<div class="twikiToc"> <ul>
<li> <a href="#Reviewing_Progress_Notes"> Reviewing Progress Notes</a> <ul>
<li> <a href="#The_EMR_Journal"> The EMR Journal</a>
</li> <li> <a href="#The_EMR_tree_browser"> The EMR tree browser</a>
</li></ul> 
</li> <li> <a href="#Entering_a_Progress_Note"> Entering a Progress Note</a>
</li> <li> <a href="#Inputting_the_Reason_for_and_Ass"> Inputting the Reason for and Assessment of Encounter (RFE, AOE)</a>
</li> <li> <a href="#Saving_or_pausing_a_Progress_Not"> Saving (or pausing) a Progress Note</a>
</li> <li> <a href="#Multiple_notes_per_enclosing_Enc"> Multiple notes per enclosing Encounter</a>
</li> <li> <a href="#Signing"> Signing</a>
</li> <li> <a href="#Editing_and_the_Auditing_of_edit"> Editing, and the Auditing of edits</a>
</li> <li> <a href="#Examples"> Examples</a>
</li></ul> 
</div>
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Reviewing_Progress_Notes"></a> Reviewing Progress Notes </span></h2>
<p />
Different objectives require a different mindset in looking at a situation. The GNUmed progress notes viewers support just that. Currently, there are two of them:
<p />
<h3><a name="The_EMR_Journal"></a> The EMR Journal </h3>
<p />
German EMR users (and others, we are sure) will recognize this way of looking at patient data. It chronologically lists clinical data based on when it happened (in nearly all cases this will be when it was entered into GNUmed). Within one date, the data is ordered by its SOAP category. Here are some things users need to be aware of:
<p /> <ul>
<li> structural elements (encounters, health issues, episodes) are displayed, but are not taken into account for display-ordering
</li> <li> some clinical data (such as lab data) is stored in the backend in a structured form, instead of as plain text <ul>
<li> this means it is not shown in its "full glory" in the Journal
</li> <li> rather, the relevant data (say, test name, result value and normal range) is extracted from the database
</li> <li> nevertheless, the full detail will remain available for display via another viewer (TBA)
</li></ul> 
</li></ul> 
<p />
This EMR Journal viewer is "read-only".
<p />
<h3><a name="The_EMR_tree_browser"></a> The EMR tree browser </h3>
<p />
This viewer displays clinical data in a tree-like view. The EMR structure forms the trunk and branches while the actual progress notes form the leaves. The left hand side displays the tree structure:
<p />
EMR of patient ... <ul>
<li> health issue 1 <ul>
<li> episode 1 <ul>
<li> encounter 1
</li> <li> encounter 2
</li></ul> 
</li> <li> episode 2 <ul>
<li> encounter 1
</li> <li> ...
</li> <li> encounter n
</li></ul> 
</li> <li> ...
</li> <li> episode n
</li></ul> 
</li> <li> health issue 2
</li> <li> ....
</li> <li> health issue n
</li></ul> 
<p />
Single left clicking a tree item causes display of details associated with that item on the right hand pane. Selecting an encounter item will display the progress notes associated with it on the right hand side. They will be selective to the episode the encounter is listed under. Note that one and the same encounter can be listed under several episodes -- namely when the patient attended the clinic with several problems at once.
<p />
All Past History Items will appear as first level items in the EMR tree with or without child indicator. Active issues are bold. Sorting is alphabetical, on issue label.
<p />
A special "placeholder" health issue,  <em>Unattributed</em>, serves by default to group together any and all episodes that had never been, or are presently not, attached to any existing health issue. The sorting algorithm programmatically sorts this <em>Unattributed</em> item at the top, and otherwise sorts issues by name, within which episodes sort by their earliest access time, and encounters by their start time.
<p />
Right-clicking on a tree item pops up a context menu, permitting editing of the item's filing data (not the raw data) so as to be able to relocate it under some other tree item or episode.
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Entering_a_Progress_Note"></a> Entering a Progress Note </span></h2>
<p />
To enter a note you have to follow these steps:
<p /> <ul>
<li> activate a patient with the <a href="GmManualBasicPatientHandling.html" class="twikiLink">patient search box</a> in the top panel
</li> <li> raise the <em>Notes</em> tab
</li> <li> type your note &#8211; see screenshot
</li> <li> save it into the EMR
</li> <li> somewhere along the way, you'll have to decide which episode the note belongs to
</li></ul> 
<p />
Progress note items would be displayed as belonging either to an episode which itself belongs to a health issue, or to a freestanding (<em>Unattributed</em>) episode. For reference, refer to a screenshot generated from <a href="http://screenshots.debian.net/screenshots/g/gnumed-client/2117_large.png" rel="nofollow" target="_top">gnumed-client 0.4.6-1</a>.
<p />
If, within the Active Problems list, you are confident to select an issue or episode with which to associate a new progress note (or progress note portion), double-click that item from the list. You will then be provided a pre-associated progress note editor into which to make your entry. Entries that had been made under health issues will, at the point of saving, prompt you to select (or add) an episode for that issue.
<p />
If you do not yet know the associated episode - which often happens with new patients, or new problems in old patients - you can use the pre-opened unassociated progress note editor or open yourself a new one with the appropriate button. Once you realize a good name for the new episode you can type it into the first line of the editor which will suggest episode descriptions from the existing ones or allow you to start a new one. If you haven't typed a name for the new episode but have pressed <em>[save]</em> you will be asked to provide an episode name.
<p />
Pressing <em>[save]</em> will save the progress note into the EMR of the currently active patient and close the related progress note editor. 
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Inputting_the_Reason_for_and_Ass"></a> Inputting the Reason for and Assessment of Encounter (RFE, AOE) </span></h2>
<p />
#fixme - anyone please add from <a href="http://lists.gnu.org/archive/html/gnumed-devel/2010-01/msg00321.html" rel="nofollow" target="_top">this thread</a> on the devel archive.
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Saving_or_pausing_a_Progress_Not"></a> Saving (or pausing) a Progress Note </span></h2>
<p />
In a paper paradigm, it is possible to partially write a note, and to "pause" an encounter until missing information is obtained (or a quickly-available test performed). During this time, other patients may need to be seen. By holding onto the charts of all involved patients, the doctor has total control over documentation, at the cost of making the charts inaccessible to others. A signature, which can identify the writer, gets added, however the entry may be recognized to have errors, or to be incomplete. Space may or may not permit edits, such as the repair of misspelt words, or the marking of a line through an incorrect word or phrase, or the insertion of additional words but these may be unable to be done clearly, cleanly indicating when these had been done and, in some jurisdictions, are wholly prohibited. Yet corrections which can only live in downstream entries are of dubious adequacy to protect the patient.
<p />
In an EMR, progress notes are entered into computer memory, and must at some stage be written and recorded ("committed") into the patient record ("database"). Until the doctor is ready to let the information be saved, the only option for maintaining an uncommitted note is to keep it in memory.
<p />
In GNUmed, this means not pressing the progress note "Save" button, and not bringing up a different patient, until you are ready to "Save". The "Saving" of a progress note is prompted by any action, within the running GNUmed session, to activate a different patient, or to exit the session.
<p />
GNUmed permits the currently-running session ("instance") to be set aside &#8212; "minimized" by your computer system &#8212; while you open any number of additional session windows, in which you can manage additional patients concurrently (this is done by just "starting" a second instance of GNUmed, or a third, etc...). 
<p />
Pausing an entry in this way will work provided the timeout setting of the system is not exceeded. When a consultation with a patient (or chart) needs to be interrupted, for example to send a patient for a test after which the consultation is intended to continue, the provider can choose whether to keep the current progress note paused, or whether to formalize the note (Saving it), and simply make another note after the return of the patient. This scenario enjoyed some email exploration, archived <a href="http://lists.gnu.org/archive/html/gnumed-devel/2008-08/msg00257.html" rel="nofollow" target="_top">here</a>.
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Multiple_notes_per_enclosing_Enc"></a> Multiple notes per enclosing Encounter </span></h2>
<p />
It is possible to record two or more progress notes (or notelets) as relating to the same, single encounter. This can be achieved from within a single session at the computer, or from two different sessions. In order to avoid making the user decide every time, GNUmed has put in place configurable encounter interval "thresholds": below the lower one, an encounter is always continued; above the upper one, a new encounter is automatically created; and between the two, GNUmed will ask whether to continue the old one.
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Signing"></a> Signing </span></h2>
<p />
The GNUmed architecture does not presently provide for unsigned vs signed "state" for progress notes. Progress notes are <em>de facto</em> witnessed by their creators. As such, progress notes are a somewhat different entity from incoming results. For test results and for archived documents, signing <em>is</em> already supported.
<p />
A later stage of GNUmed may implement the signing of progress notes. Some of the implications if notes were required to be signed, and if all changes (including trivial) are forced to be brought to everyone's attention, are archived here (<a href="http://lists.gnu.org/archive/html/gnumed-devel/2008-08/msg00256.html" rel="nofollow" target="_top">1</a>, <a href="http://lists.gnu.org/archive/html/gnumed-devel/2008-08/msg00258.html" rel="nofollow" target="_top">2</a>, <a href="http://lists.gnu.org/archive/html/gnumed-devel/2008-08/msg00261.html" rel="nofollow" target="_top">3</a> ).
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Editing_and_the_Auditing_of_edit"></a> Editing, and the Auditing of edits </span></h2>
<p />
What if a "Saved" note was incomplete, or contained an error? Clearly, it is always an option to add a new note, to serve as an addendum or supplement. However, in those cases where a prior note should not be left in its existing form, GNUmed will make notes editable. As a result of any editing, a new <em>version</em> of a note will sit on top of all prior versions going back to the original, with all prior versions relocated to the associated "audited" table. <em>Making evident any alteration(s) to a progress note is the project to do list, as is already enabled (in client v 0.3x) for revised test results, as demonstrated at the bottom of <a href="http://lists.gnu.org/archive/html/gnumed-devel/2008-08/pngh60ULQwkpx.png" rel="nofollow" target="_top">this exposed tooltip</a> with associated handling description archived here . In the meantime, any disputes over record version(s) would be able to be resolved using external tools such as <a href="http://www.pgadmin.org/" rel="nofollow" target="_top">pgadminIII</a>.</em>
<p />
<h2 class="twikinetRoundedAttachments"><span class="twikinetHeader"><a name="Examples"></a> Examples </span></h2>
<p />
One or more will be built up over time... see <a href="ProgressNoteExamples.html" class="twikiLink">ProgressNoteExamples</a>
<p />
<em>Next:</em>  <strong><a href="GmManualBasicEmrStructuring.html" class="twikiLink">Structuring the EMR</a></strong>
<p />
<hr />
<p />
<hr />