Encounter diagnoses may reference a condition, but not always. In FHIR, the Encounter.diagnosis.condition is actually a CodeableReference type, which can be a concept or a reference to a Condition.
What I’m proposing is for OpenMRS Condition be used to store a list of longitudinally clinical significant conditions – i.e., conditions that are either chronic/lifelong or are clinically important historically. In simple clinical terms, this means the all conditions that would be in the “Problem List” (in recent years renamed the “Condition List”) and the “Past Medical History.” If someone is seen for an acute illness (e.g., a laceration or an acute viral illness), these could be noted on the encounter (as an encounter diagnosis), but would not be added to the condition list.
A simple example:
Peter has high blood pressure and no other chronic medical issues. He had tuberculosis 10 years ago, but was successfully treated. When his doctor opens his medical record, she would see something like this:
| Conditions |
Past Medical History |
| High blood pressure |
Tuberculosis |
|
High blood pressure |
When Bob comes in to be seen today for a routine follow up of his high blood pressure, he complains of a headache for the past few days and, on a screening test, is newly diagnosed with HIV. After an exam, Bob’s doctor tells him the headache is likely due to dehydration, should resolve if he drinks more water, and to let her know if it’s not better soon.
In the EMR during today’s encounter, the doctor:
- Copies high blood pressure from Bob’s condition list to the encounter as an encounter diagnosis
- Adds headache as an encounter diagnosis
- Adds HIV as an encounter diagnosis and copies it to Bob’s condition list, since this will now be an ongoing condition to track & treat
So, we end up with these three lists:
| Encounter diagnoses |
Conditions |
Past Medical History |
| High blood pressure |
High blood pressure |
Tuberculosis |
| Headache |
HIV |
High blood pressure |
| HIV |
|
|
- The high blood pressure encounter diagnosis references the existing Condition
- The headache diagnosis is stored as a Concept, since it is only relevant to today’s encounter
- The HIV encounter diagnosis might be a Concept when it is first added as a new diagnosis by the provider, but when she clicks on something to “Add this to the patient’s Condition List”, we would probably add HIV as a new Condition for Bob and then convert the encounter diagnosis to a reference to it (so the outcome would be the same if she first added HIV to the Condition list and then copied it to today’s encounter)
A client calling the API should be able to make requests like:
GET /Conditions?category=problem-list-item to get High blood pressure & HIVGET /Conditions to get High blood pressure, HIV, and Tuberculosis (all conditions in Condition List or PMH)GET /Encounters/:uuid and something like GET /Encounters?diagnosis=CIEL:139084 to find encounter diagnoses for a specific encounter or search encounter for a specific diagnosis
This example shows that not all encounter diagnoses are conditions. It also points out why Condition.category = problem-list-item would help us control what is in the “Problem list” (aka “Condition list”), but it also highlights one issue we’ve overlooked: there are cases where providers might expect a condition to be on both the Condition list and the Past Medical History.
This last point suggests that, while we could use category to label items on the condition list, we can’t assume (as I was earlier) that items are mutually exclusive across Condition List PMH – i.e., we can’t assume items are in the PMH if they aren’t categorized as a problem list item. If we adopt FHIR’s many-to-one categorization, then we could define the Condition List as only those conditions categorized as problem-list-item and the Past Medical History as any items without a category or categorized as past-medical-history-item (where, in the example, High blood pressure would have both categories).
It’s not fully clear to me where FHIR is expecting past medical history items to be stored, but it seems like Conditions would be the most logical place from my perspective/experience.
In any case, if we head this direction, then controlling which items appear in the Condition List (or Past Medical History) would be explicitly & independently controlled, allowing Clinical Status to be managed independently without conflicting with what is or isn’t on the patient’s Condition List.
