Diagnosing The Contextual Problem List

As part of my work on the Welsh Information Solution for Diabetes Management (WISDM), we have the requirement to provide functions to support the curation of a problem list. This is not a definitive list of all the patient’s problems (as if one could exist?) but one that presents the key issues that are of concern to the patient and clinicians who support the management of the condition. In order to explore these requirements, I needed to go back to basics. Firstly, there are the definitions i.e. what is a problem?

Foundations

A great resource for this work was the seminal (and mightily entertaining) Grand Rounds Lecture from Dr Larry Weed in 1971. In the video (at 06:08) Dr Weed states;

You can’t look at the management of a single problem without knowing the context. What are all the problems?

Followed with;

You shouldn’t have to spend a second finding what are all the problems.

Dr Weed continues thusly:

The very structure of the data determines the quality of the output.

Boom.

This video is a treasure trove, but it is shocking that these universal truths about medical records from nearly half a century ago still seem to elude us in 2019. This was proved to me when I spent time in a diabetes clinic at the Royal Glamorgan Hospital and observed the Consultant flicking through the notes. It took elbow grease, pattern recognition and time to assess what they needed to do for the patient. And the major constraint that faces the majority of clinical staff in the NHS is lack of time.

This was a powerful message and a trigger for the wider requirement of the patient record composite view that I began to work on (but more on that another time…). The context is everything and for that we need some ground rules on what all these terms mean.

Primary Diagnosis

The primary diagnosed condition for which the patient that is receiving care. While the primary diagnosis may be a variation of range of codes (e.g Type II diabetes mellitus with peripheral angiopathy), the range of codes within any given terminology will be limited. This essentially means that the diagnosis is focused and based on demonstrable clinical facts.

If the Primary Diagnosis changes or replaced, an historical record is available of this change. In addition, this primary diagnosis is subject to the care pathway the patient finds themselves on. For example, a diabetologist would be treating a patient with some form of diabetes. Likewise, a renal physician would be treating a patient with a primary diagnosis of Chronic Kidney Disease.

Co-morbidity

A co-morbidity is a coded diagnosis that does not require management or acknowledgment by clinicians within a specified disease domain but of clinical importance to the ongoing care of the specific disease. Therefore, these record types will be actively managed through alternate care pathways or specialties.

For example, a Type 1 Diabetes patient who is also under the care of Cardiology. From the perspective of the diabetologist, the Cardiology diagnoses are considered co-morbidities. But in order for a record to be categorised as a comorbidity, it has to have been the result of some form of diagnostic pathway i.e. it cannot be a presenting complaint such as chest pain which is considered a finding.

Problems & Complications

This type of record represents a clinical problem that arises from and is a result of a specific condition or is being investigated as a result of the aforementioned problem. Listed complications within the disease specific context require active management by the clinician and can be viewed as the reason why the given clinician is involved with the patient care at this point in time.

Coded entries may reside from clinical findings (e.g. Pedal oedema) or disease related disorders (e.g. diabetic retinopathy). But importantly, coded entries in this category may be findings or diagnoses.

Other Problems & Diagnoses

Records in this category do not support the clinical context. To a certain extent, they could be ignored provided that there is a master problem list available. However, the master problem list is difficult to maintain with the above categories. Whether something is a primary diagnosis depends on the care pathway. Certain diagnoses could be classed a comorbidities which would then leave a buck list of everything else, some of which comprises this fourth category. In order to manage this effectively, we need some form of reconciliation function to ensure that new codes are viewed and sorted by the clinical user. In addition, all records that comprise the ‘Other…’ category need to be easily accessed.

Sticking their fingers out the window

The following use case diagram provides a broad interpretation of the principle requirements. The term “Composite View” relates to a dashboard-esque view of the electronic record. It should also be noted that the word “diagnosis” is used too liberally in this diagram. It refers to any of the coded entries that could be construed as a presenting problem through to a fully diagnosed condition. I will update this in due course!

NOTE: PS05 should state “Record inactive record”.

The use cases are broadly split as follows:

Create Record

This use case facilitates a PCV user to record a new coded entry as part of the patient record. Each problem or diagnosis is a record in its own right, and one or more records comprises the problem list.

Import Records

This use case is used to populate the Master Patient Problem List from other validated sources such as GP records. It allows a user to select diagnoses or problem that have previously been recorded, validate them and tag them as important for specific disease management.

Edit Previously Recorded Problem

This use case facilitates a clinical user to edit a previously recorded problem in the patient record.

Record Inactive Patient Diagnosis

This use case permits a clinician to mark a problem record as inactive or resolved. In this scenario, the diagnosis or finding has previously been recorded and is currently active. The user is able to record reasons for why the diagnosis is not currently active including that the diagnosis has been resolved or that the original diagnosis was incorrect within additional comment fields or notes.

Review Problem List

This use case permits a clinical user to review, add and edit all problems and diagnoses. Importantly and regardless of any changes the clinician may have made, it also records that the problem list has been viewed which adds to the provenance of the list overall.

Display Problems

This use case permits a clinical user to make a coded problem or diagnosis visible within an application. It is an extension of PS01 and PS03 pertaining to the scenario where the record is required to become visible within one context but not displayed in the 'Other Problems' View. In our case, the “Diabetes View”. The inverse of this scenario may also apply. OK. What does that really mean?

Get the database and get it right every time

The previous “Display Problems” use case typifies the major issue with categorising any problem record i.e. “why does this matter and to whom?”

To a diabetologist, the presenting problem of numbness of foot maybe a complication of the primary diagnosis of Type 1 or Type 2 Diabetes. Let’s follow the logic:

1. Numbness of foot... Cause? To be ascertained...
2. The clinician may have a presumed diagnosis such as diabetic neuropathy.
3. Is the diabetes poorly controlled?
4. What is their foot history?
5. What is their established category of risk? Low, medium or high?
6. Do they have any corresponding co-morbidities/risks/complications e.g. nephropathy/CKD, cardiovascular disease, erectile dysfunction etc.
7. We must do tests to diagnose this such as pulse point, monofilament and vibration tests.
8. These test help the clinician to arrive at a diagnosis.

“Numbness of foot” is a finding that is presented to the clinician. This triggers a series of clinical actions to determine the cause of this, which results in a diagnosis of “diabetic nephropathy”. This is in turn considered a complication of the patient’s primary diagnosis of Type 1 Diabetes i.e. it would not have occurred had the patient not had diabetes to start with. Each one of these steps requires the diligent recording of provenance and outcome, some of which may not have actually lead to a confirmed diagnosis.

Don’t Forget

Within Clinical Modelling circles, the concept of the absence statements exists. I wrote about this using the phrase “Positive Negation” so I won’t reiterate that here. But enough to say that each of the above categories can be fitted with a statement to explain why this portion of the list is empty. A patient early on the diagnostic pathway may not have a primary diagnosis.

As we have seen above, the concept of comorbidity may apply, and the clinical user may also wish to record additional problems in future as clarity on the patient’s condition emerges. But in the first instance, a recorded entry that “There are no known problems” is a potentially valuable statement of fact.

And they’ll write it up so you can read it…

So far we have discussed the definition of types of problem record and some constraints as to what record can appear where. If we consider that all codes exist in one data store, we should be able to retrieve, sort and subsequently present them for specific disease management contexts. The renal physician gets their version, the endocrinologist theirs and so on.

Where we can source all of these entries from a common location, we can prevent duplication. That is a bit obvious but important re-use of resource. But in addition, the individual context to which any given code has been used are also accessible to other care pathways. This facilitates a vehicle to "see what the record looks like to a diabetologist" which is a powerful concept.

If all the above, makes sense then great. I think it does. But to be doubly sure I will be having a chat with colleagues over the next few weeks to double check. My first cut is available as an OpenEHR template on the Apperta CKM here and I'll update this in due course.

Update 30/06/2019

Following the clinical modelling Skype held on 28/06/2019, the above post has been updated to reflect the following;

1. The group discussed the terms principle diagnosis and primary diagnosis. Broadly, it was seen that using ‘primary’ is more typical of clinical language and that ‘principle’ seemed to echo its use in terms of billing use cases. There is a further distinction to be drawn from the ability to record more than one primary diagnosis (or diagnoses). Equally this applies using secondary diagnosis versus comorbidity.
2. Addition of the fourth category of all codes problems that do not fit the categories of primary, secondary/comorbidities or complications.
3. The nature of maintaining this as a digital document is difficult. Where the various context lists are being maintained in parallel the pattern makes sense. However, there is a risk with siloed problem lists if there is not effective problem reconciliation processes at the application layer. Some of this is catered for in my wider design work which does not feature above, but it was a good discussion all the same.
4. Which lead to the idea to remodel the template as a Section. This will allow the Problem List to be inserted into templates with a broader clinical use case such as outpatient summaries.