Thanks for writing this up, @veronica. A few things have moved since the screenshots, so I want to get the thread onto the current thinking.
The PR already pre-selects the first diagnosis as Primary when the distro requires one, and anything added after that is secondary until you tick it. That’s how the O2 diagnosis widget behaved, and it’s probably better to keep it as our baseline than to make people tick Primary on every single-diagnosis note.
On certainty, after @burke’s feedback and a chat with @ibacher, we’re leaning towards flipping the default: assume a diagnosis is confirmed and make provisional the thing you have to tick. Most diagnoses recorded at the point of care are the clinician’s working conclusion. The ones waiting on a lab result are the exception, so that’s where the click should go. Worth noting that everything recorded before this lands is stored as provisional because the old form hardcoded it, so older visits will look less certain than new ones.
For display, certainty on the pill itself is too much noise. We’d rather keep the pill as just the name and put certainty in a tooltip that also opens on tap, so it works on tablets and is there for anyone who needs it. That replaces the “?” marker in the post above.
Related but separate: can we stop using red for primary diagnoses? Red should mean something needs attention. Blue for primary and gray for secondary reads better.
Two things we’d like opinions on:
Should there only ever be one primary diagnosis, so ticking Primary on a second row clears the first? The backend stores this as a free rank integer and allows any number, so we’d need to enforce it there too. It’s also common in outpatient settings to record several problems for one visit, which argues for leaving it alone.
Certainty changes during a visit. A malaria rapid diagnostic test comes back an hour later and the only way to record that today is to edit the note, which deletes and recreates every diagnosis. That’s really a question about diagnoses being visit-level facts while notes are per-provider. Probably its own thread, but flagging it.
One more for @akanter: “Malaria, confirmed” and “Primary respiratory tuberculosis, confirmed” exist as Diagnosis-class concepts, which is going to collide with a certainty field. Are those in the right class?
I’m going to leave most of the feedback to actual clinical users, but I can provide a little reflection on diagnosis documentation from my perspective.
First, as I have mentioned before, there is a distinction between a patient’s problem list or condition list, and the diagnoses as recorded in a particular visit. These visit diagnoses also have administrative value as they may have to be recorded with a reference code for billing or reporting. Designation as primary or secondary is often an administrative need for a particular visit, but may have no value for clinical review or longer term management. Designating a diagnosis as “Primary” by default makes sense by the order of entry, but how this persists to a patient’s problem/condition list should probably be discussed.
Designating a diagnosis as provisional or confirmed was probably an artifact of the few cases were reported required confirmation as part of the coding. This is why there are malaria and TB diagnoses which already include whether it was confirmed (or in the case of TB, how it was confirmed). For almost all other situations this is not required and a diagnosis is considered confirmed when the clinician enters it.
For example, if a patient comes in with a cough which later turns out to be a pneumonia… on the initial visit they have a COUGH (confirmed) not Pneumonia (provisional). In the next visit after the x-ray comes back showing a pneumonia, the COUGH is retired and Pneumonia (confirmed) is added. I think it is rare that people should be documenting provisional diagnoses as assessments or visit diagnoses.
There is a workflow which would allow clinicians to document their differential diagnosis (what they think a patient might have) as a way of recording their decision-making, so the next time someone sees the patient, they can narrow down the actual diagnosis using that list, or perhaps change the list. So for the cough example, COUGH is added as the visit diagnosis. BRONCHITIS and PNEUMONIA could be captured as differential diagnoses. These latter two would not be considered visit diagnoses, would not be counted in administative reporting using ICD codes, etc.
The existing concepts which have confirmed already in them are the ones which should be used for documentating confirmed diagnoses for Malaria or TB. Using a regular malaria code and flagging it as “confirmed” will not produce the correct ICD code for reporting.
Thanks @veronica for the writeup just one question or two
Will the added diagnosis add up as a stack as in the latest added as the first to avoid scrolling to locate the newly added incase of many?
In the sense of the added diagnosis as of a view they seem not much of focus to the user ( Basically what am implying is could it be better that section we put it under background not white ) like given the example of the section in the date like that background?
Is there any metadata we could leverage to make this distinction? Much of Burke’s feedback has been that confirmed diagnoses don’t really make sense except in a few limited cases and I’d rather we drive the UI to not bother the user about a diagnosis being “confirmed” or “provisional” without a real clinical use-case for it.
In this case, what should we do with both 116128 and 160148 being included in the RefApp metadata?
This isn’t a bad suggestion, but it makes the “first diagnosis is primary” thing… weird. I kind of like the table-ish view. Do you think that compressed version will help?
I do leave it up to actual clinical users in the field to make this decision, but I would not bother them about whether something is confirmed or not. Malaria as a diagnosis is what most people would use. If there is a use case for distinguising the confirmed malaria, or TB confirmed by culture, etc. then the users should be trained and they select those diagnoses. We could also have a form specifically for WHO Malaria reporting if we wanted to which would have two choices: Malaria or Malaria, confirmed. This would help distinguish between all those “malaria” cases that are presumptive like we saw in MVP. One RDTs were implemented, the diagnoses went down since they could rule out the malaria before the patient left.
Yes @ibacher maybe we can prioritise the rank basis here to say Pin Primary rows to the top and keep the rest in entry order. However to add on paper this seems practical but am skeptical on how the real use may look like
Any reservations about dropping red for primary, switching to blue primary/gray secondary?
How about green for primary and blue for secondary? Since gray is mostly used to annotate deleted/retired objects and green is mostly used for confirmations/success?
Warning that at least one primary diagnosis is required shows whenever nothing is selected as primary. Mark any diagnosis as primary and it disappears; uncheck the last primary diagnosis and it reappears. Form cannot be submitted without at least one primary diagnosis selected.
All diagnoses are confirmed by default.
Only actual diagnoses – i.e., concept class == Diagnosis – can be marked preliminary, which is done through an action (ellipsis) button. Initially, the only option might be “Mark as preliminary” or “Mark as confirmed”, but future options might include things like “Add to condition list”, “Add to past medical history”, “Mark resolved”. If we add actions in the future that apply to symptoms & findings, they can get action buttons too.
Concepts with class Findings or Symptom (like “cough” or “Loss of sense of smell”) cannot be marked as preliminary, so the option isn’t provided.
Preliminary diagnoses would show as preliminary. I would favor a leading or trailing question mark or a prefix of “Rule out”.
I don’t know why we need lozenges for diagnoses, much less colors. I would think a list of diagnoses with primary diagnoses listed first would suffice. If we need to use lozenges, then let them be white or grey. Colors should be used judiciously, IMHO.
@burke thanks for the feedback. I have incorporated the changes.
UI changes incorporated → Warning when no primary is ticked; turns red if you try to save anyway, and the note cannot be saved without at least one primary diagnosis.
Every diagnosis is recorded as confirmed unless you choose “Mark as provisional” from the row’s menu.
Apparently, the visit note search already applies a filter for concept class == Diagnosis, so everything you can add is markable — and yes, CIEL classes Cough and Loss of sense of smell asDiagnosis, which is why they can be marked as preliminary.
“?” marks a preliminary diagnosis, both in the form and in the visits table.
Not surprisingly, this looks like a big improvement to me!
I would expect cough to be a Symptom/Finding (patient or provider observation) and Loss of sense of smell to be a Symptom (only observable by patient), so if they have been classified as Diagnosis, I would consider them as misclassified concepts.
One suggestion would be to give the columns fixed widths rather than letting them be fluid, especially the Diagnosis column, so the content has more room and stays readable.
