The Concepts used in the GNUmed EMR

Help translate this into Deutsch Español Français Polska Português

In brief, the concepts and key references are…

If you know what this is all about, you can stop reading here, and jump to GmManualStartingGnumed.

What they all mean…

The concepts used in the GNUmed EMR align (un?)surprisingly well with those written up by the UK NHS for the CEN/ISO Concepts for Continuity of Care.

The Encounter

In health care, an encounter is commonly understood as a distinct contact of a patient with the health care system. In a GP setting, most encounters start when the patient enters the building and end when the patient leaves the building. Contact with a doctor may or may not have taken place. An encounter need not end on the day it started, e.g. when care is given over midnight the encounter will span a date boundary. Likewise there may well be two or even three encounters in one day (think of patients you have seen in and sent home from the practice in the morning, only to have to admit into hospital later in the day).

Technically, in the GNUmed EMR, an encounter need not always include a patient visit, or even doctor (or other human) interaction. They are a fusion of a conceptual participant <==> health care related interaction and a technical EMR (database) session.

In addition to the usual patient-provider physical visits, then, the following situations are considered encounters, too:

Deutsch
Inanspruchnahme, Arzt-Patienten-Kontakt

Each encounter can span a time interval and thereby conveniently group together (interconnect) multiple pieces in a single patient's record. This does not prevent later reassignment of any of these pieces (which keep their date and time stamps) to a different encounter, where it would make sense to do so.

Reason for Encounter

RFE, Reason for Visit, Reason for Consultation.

This may evolve from the original purpose at the time that the encounter was planned, such as a chief complaint or planned followup, to include additional purposes or tasks that may come up in a visit as needing also to be looked after.

Deutsch
Beratungsursache (nicht -anlaß !)
Beratungsanlaß
"keifende Nachbarin" (Nachbarin: "Du nervst mich mit Deinem ewigen Gejammer über den Rücken ! Geh doch mal zum Doktor !")
Beratungsursache
"Rückenschmerz" (Patient: "Herr Doktor, mir kneift es schon 3 Wochen im Rücken !")

Assessment of Encounter

AOE

This offers the ability to capture a larger insight or formulation for the encounter as a whole and where multiple problems may have been touched upon, for example "Malignancy now explains all' or "General decompensation due to renal failure" or "Increasing frailty, close to failing at home".

Deutsch
Beratungsergebnis

Problem-Oriented Documentation of Care

In a problem-oriented medical record (POMR), all stored clinical data has been associated with an explicitly-stated problem suffered by a patient. Problems need not be diagnoses. They need not be hard scientific facts. They can be syndromes, they can be findings, they can be history items. Over time, they are likely to merge and consolidate into well-founded diagnoses. Or they may not. That is the beauty of GP-level health care.

Note that during one single encounter, several problems with the patient's health can be dealt with.

The SOAP Schema

In 1964 Lawrence L Weed introduced the SOAP structuring of progress notes in medical records. This concept roughly says that all clinical data associated with giving care to a patient is to be grouped into the categories Subjective, Objective, Assessment, and Plan. Various criticisms have been put forth as to where this classification lacks sophistication or falls short of properly capturing clinical information. However, setting aside academically-proper validation and evaluation, most clinical data at the GP level can be grouped into one of:

Subjective
what the patient narrates (Deutsch: Anamnese)

Objective
what findings were elicited at the encounter in question (Deutsch: Befunde)

Assessment
what clinical meaning is given to the Subjective and Objective data, as to causes and consequences for the patient's health (Deutsch: Bewertung)

Plan
what do the patient and clinician intend or agree to do about the patient's health (Deutsch: Procedere)

Each problem will, in GNUmed, have its own, dedicated, SOAP-structured data.

Classification of Diagnostic Certainty

Based upon Subjective and Objective data, a provider will formulate an Assessment of the patient's state of health. This assessment is often captured as a short catchy phrase which, in GP-level care – despite being referred-to as a diagnosis – may start out as a summary of the state of health, and may only reach a professionally-formed, scientifically-founded working diagnosis, and not one that attains a scientific or gold-standard proof. GNUmed has (as of 0.6) a provision for labelling assessments at the level of Episode and Health Issue with a classification of the diagnostic certainty of that assessment. The literature describes four levels of certainty:

A - sign
a single symptom such as back pain, or a single sign such as elevated BP, which implies and may even be denoted "Not Yet Diagnosed" (NYD). (Deutsch: Symptom)
B - cluster of signs
a group of signs often seeming to go together but not yet safely recognizable as a particular disease as to be diagnosable, such as rash and fever and still implying and more often denoted NYD. (Deutsch: Symptomgruppe)
C - syndromic diagnosis
a group of presenting signs and findings are specific enough to allow for a reasonably likely presumptive diagnosis, even without scientific proof, as yet eg. Strep throat in the absence of throat swab results. (Deutsch: Bild der Krankheit)
D - scientific diagnosis
the exact ailment has been adequately scientifically proven by microbiological culture, lab results, autopsy, histology etc. for example Scarlet Fever in ASL +ve Strep throat. (Deutsch: Diagnose)

Such a codification might have value to flag patients who may have symptoms or abnormalities that have recurred or persisted without explanation, but which might (if taken together) point more clearly to a diagnosis.

The Episode of Care

Encounters are often clustered in time. In the course of possibly several encounters, a few health problems will be worked on, incorporated into one (or more) episode(s) of care. It is entirely at the discretion of the clinician how long the episode lasts. Usually an episode will only be assumed to be "case closed" after the patient did not report back for an extended period of time, or when some knowledge of resolution has somehow come to the clinician.

Each episode of care may comprise one or several encounters. While GNUmed does not yet model this graphically, an analogy based on an example at Dipity, may inform. Encounters would distributed from left to right along the patient's time line. Episodes would each form a horizontal stripe, with the various stripes "stacked" vertically, with each episode positioned at an _arbitrary height, with a left edge determined by the episode start date, and a right edge defined by the episode's end date, except if the episode remains open / active.

An episode may be associated with a health issue. Each episode can also be labelled with a diagnostic certainty.

The Health Issue

At times the clinician will recognize a cluster or subset of distinct episodes of care as looking suspiciously related. In such cases it may make sense to group them under one health issue. Thus, health issues may be at the fundamental or foundational level of a patient's health. They may be active or inactive. Post-MI state is likely to be clinically relevant for the rest of the patient's life, despite that it may not be an active problem at a given time. On the other hand, a traumatically amputated finger will always be both clinically relevant and active if it confers continuous disability. Health issues will more often be understood as diagnoses than will "problems" or "episodes". Therefore, health issues can be further associated with a diagnostic certainty. In GNUmed, past medical history items will mostly be stored as health issues.

Setting aside simple "past history" items, each health issue will aggregate one or several episodes of care.

The Problem List

The problem list (the list of active problems) consists of items being worked on, or kept in mind, while trying to improve the health of the patient. This list includes:

Putting Things Together

The structure of a patient's EMR can be seen as a tree:

* each health issue will aggregate, within it, clinically-related episodes of care

* an early diagram of this is hosted at the internet archive, here.

* a further treatment of how this works, but which you may rather skip for the moment, is initiated at EncounterEpisodeIssue

Next: Starting GNUmed

Literature

(sorted by lastnames of authors)