@darius I suggest we keep audit trail for everything and keep the logic simple.
An audit trail also comes handy in certain circumstances like medico-legal cases, erroneous diagnosis and (potentially) settling false insurance claims.
I was referring to EncounterDiagnosis, which could have a foreign key to the condition list entry when the relationship was explicit. The reason being that someone could single click add a condition from the condition list and we’d explicitly capture the relationship rather than infer it. When someone manually added an encounter diagnosis that matches an active condition list entry, we could ask them if this is the same condition or not and make the explicit link if they say yes. This would allow for encounter diagnoses for repeated or concurrent occurrences to be recorded and not be implicitly linked as referring to the same thing. If we are going to enforce that active conditions in the condition list and conditions in encounter diagnoses cannot contain duplicates, then we can survive without an explicit link… but make implicit links may still come back and bite us for episodic non-related conditions (tb, pregnancy, etc.)
There is a ticket for this in openmrs-core, but it hasn’t been done yet (it’s not even ready-for-dev), and it’s not in our current workplan.
I think we’ll go ahead an implement this feature in the simpler way, knowing that it’s less than ideal. As long as there aren’t two active conditions with the same concept at the same time, then there’s no data loss. (And we may have to deal with a data migration task when condition and encounter_diagnosis actually make it into openmrs-core.)
(@akhilmalhotra let’s make sure to include in the story that we shouldn’t allow you to add another active condition with the same concept or non-coded-text as an existing one.)
Do Inactive, and History Of for in clinical status align to FHIR’s values of remission and resolved, respectively?
I’m still trying to understand how clinically irrelevant conditions will be hidden or removed from the list, Are we planning on introducing Past Medical History (PMH) separately in the future? That would allow non-clinically relevant conditions to be moved off the condition list without being lost. The main point I’m trying to get across is whether or not a condition is clinically relevant (should be shown in the condition list) is not always determined by whether the condition is active, inactive, or historic. I just want to make sure we aren’t assuming that a clinical status field can single-handedly reflect “truth” of the condition’s state and determine whether or not an entry shows by default in the condition list.
I’m hoping that @jteich can also weigh in on the topic…
The model we plan to follow (I think largely advised by Jonathan) is that we’ll have “current conditions” as well as a historical view. Conditions with status of ACTIVE or HISTORY_OF are displayed in the “current conditions” view, and INACTIVE are only displayed in the history view and you have to do one more click to see them.
@burke I think you’re suggesting that we should have an additional boolean status field to indicate whether or not the entry is shown in the condition list (a.k.a. “is clinically relevant”). I don’t see this in FHIR. (Unless you think it maps to clinicalStatus?
I was actually suggesting we use clinicalStatus to indicate clinical relevance rather than assuming it will somehow always reflect physiological truth. We’re far more likely to have reliable clinical relevance, because users will want to control what is on their list. The idea that someone will be dutifully recording when a stroke becomes a history of stroke (physiologically) is unrealistic.
If we conflate clinical relevance (do I want to see it in the main list) with physiological status (is this condition actually active or not in the patient’s body), they will be at odds at times. Example: I want History Of Stroke and Heroes in Remission on the condition list, but I want the patient’s ongoing Halitosis (bad breath), which is physiologically “active” in their medical history but not cluttering up my condition list (because it isn’t clinically relevant right now).
While, we could make a separate flag for clincallyRelevantStatus, that suggests that someone will be maintaining clinicalStatus, which I think is unlikely. People will just toggle off clinicallyRelevantStatus and leave clinicalStatus untouched (forcing the API to guess if the condition just went from active to inactive or active to history of).
One of the benefits of using clinicalStatus for active & inactive/resolved to manage what should or should not be shown by default is it saves you from having to worry about this problem. It’s perfectly acceptable for a doctor to have a “History of stroke” as an active item on the list and, when the patient presents with a new stroke, add a new “Stroke” concept to the condition list as active. When the acute stroke has been treated, the doctor clicks an “X” to remove it from the list and we market as inactive/resolved. “History of Stroke” remains active on the list.
The system doesn’t have to know or track the relationship between “History of stroke” and “stroke” to support this.
I don’t understand how the halitosis example is relevant, because FHIR’s clinicalStatus does not have a solution for it either. The clinicalStatus options are active | relapse | remission | resolved. Which one of these indicates “active Halitosis that is not clinically relevant”?
One key point: the client specifically requested the ability to mark a condition as historical. So we need to support this.
Our solution is to have two different buttons on the condition list, one for “make this historical” and the other for “remove this from the list”. One will set the status to HISTORY_OF, and the other will set the status to INACTIVE.
I’m not sure I understand how you’re
I understand/infer that your proposal is:
(1) rename Condition.status column to Condition.clinicalStatus, for alignment with FHIR
(2) rename the INACTIVE enum value to instead be RESOLVED, for alignment with FHIR
and then either:
(3a) redo the concept dictionary for this implementation to have separate concepts for “stroke” and “history of stroke”
(3b) rename the HISTORY_OF enum value to instead be REMISSION, for alignment with FHIR (but we can choose to display this in the UI as “History Of”)
You agree that there’s only one status/clinicalStatus column, so I assume you agree it’s appropriate to display by default all conditions whose status is ACTIVE or HISTORY_OF, but not INACTIVE (aka whose clinicalStatus is ACTIVE or REMISSION, but not RESOLVED).
Is that right, or are you proposing something different?
Option 3a is absolutely impossible in this case. Existing implementations that want this feature cannot redo their whole concept dictionaries.
I think that “remission” is going to be confusing for people who will be generating reports from looking at the database. Maybe the right solution is that the API should support the statuses:
ACTIVE
RELAPSE (won’t be used in the Bahmni UI for now)
REMISSION (won’t be used in the Bahmni UI for now)
RESOLVED (instead of INACTIVE)
HISTORY_OF (plus document that it’s recommended to not use this but instead have precoordinated concepts)
Halitosis would be marked as resolved/inactive, reflecting it is not clinically relevant. The system would not be able to distinguish between Halitosis that was resolved vs Halitosis that remains physiologically active but is no longer clinically relevant, but nobody is going to be collecting or maintaining that granularity of data even if we supported it.
Those sites using CIEL likely already have these concepts. If not, there’s no requirement to have them. Setting clinicalStatus for “Stroke” to remission/history would be effectively the same as having “History of stroke” marked as active or remission/history of. For those concepts without a “History of x” concept, you just would have the option of having both “Stroke” (i.e., acute stroke) and “History of stroke” in the condition list simultaneously when a patient comes in with their third stroke. But using “History of x” concepts or not is left to an implementation decision (similar to choosing the name to use in the UI for remission/history of or resolved/inactive).
Yes. That’s right. The key point is that clinicalStatus is being used to record clinical relevance, not physiological truth. In other words, the semantics of marking something active, remission/history of, or resolved/inactive reflects the state of the condition’s clinical relevance. Most of the time, this will align with physiology – i.e., when the Pneumonia is resolved, it’s actually resolved. But when clinical relevance and physiological state of a condition do not align, clinical relevance wins – e.g., if the patient still has constipation, but it has been clinically stable for 10 years and the provider wants it off her list, its clinicalStatus becomes resolved/inactive even if the patient is still taking the stool softener he’s taken for the past 10 years for his constipation. If we leave this ambiguous and half the people using the API are using clinicalStatus to have manageable condition lists and the other half are assuming that clinicalStatus must reflect “truth” (physiology), the two will eventually hit an impass like two Zax.
A couple of points to get out of the way, mostly agreeing with the above threads, before getting to the big topic about active/inactive and major/minor, which will be the next reply:
The main purpose of a condition list (as opposed to an encounter diagnosis) is primarily to provide a summary overview of the patient, and secondarily to possibly enforce consistency over several encounters for the same thing. With that in mind:
Remission – unfortunate choice on FHIR’s part. Mainly only applies to cancer and even where you can kind of use it for other conditions (like asthma), most people will not understand it or properly use it anyway because that word isn’t used much except for cancer. I agree that we should avoid surfacing it in the UI; if I had my druthers, I wouldn’t use it as a status at all.
Relapse – slightly more understandable, but not necessary for condition list. If a patient has had acute HIV, then it got better for awhile, then it got worse, what I want to see on the condition list summary is just “HIV”. I can follow the improvements and worsenings by looking at the history. So, I also wouldn’t bring this up to the UI.
Pre-coordinated conditions and duplicate conditions – while I suppose this may be up to a specific site, I’d hope we can do everything possible to avoid precoordinated conditions that duplicate another condition. It isn’t clinically useful for the list to have both “stroke” and “history of stroke” on the list for the same patient – that’s all one grouping of history and data. When I look at the list, I just want to see if there was a stroke or not in the past. If we ever do tie visits or data to conditions, I don’t want to have some of the relevant stroke data (like a carotid study, or thrombolysis treatment) associated only with one of these and hidden from someone reviewing the other.
a. Note that a stroke, like an MI and other things, is really an instantaneous event anyway; it’s history the moment after it occurs. If I have a stroke in October and another one in January, then a few weeks later my condition list should just say “history of stroke” (or simply just “stroke”)
Audit log entry vs delete/add new – in past work we audit-trailed every time any field changed. That may or may not be OpenMRS standard operation. But in any event, the only time I would inactivate one problem and start up a new one is when the main concept [name] changed.
So, everyone seems to agree that we need to distinguish current/past conditions and major/minor conditions. However we set it up, I maintain that those are two independent fields.
A. Here are some use cases:
Active (Current):
condition is getting current attention over the last few encounters
Inactive but important enough to show in the major-conditions list
acute condition is over but worth knowing for general care [broken hip, stroke], or
chronic condition has not been a problem for some time but worth knowing for general care [COPD, childhood asthma]
includes conditions in the distant past [congenital heart defect that had surgery]
Inactive and not important enough to show in the major-problems list
Stable minor chronic condition [halitosis]
Resolved minor acute condition [broken arm, strep throat]
B. What I think the user wants:
From a user perspective, the user would first see all the major problems, with a column showing whether they are currently active or inactive/past (includes “resolved” and “remission”). A button at the top of the table would include minor problems in the displayed list. This is the same UI we use for active meds vs. all meds.
C .A proposal for handling the transitions – trying to keep clicks to one, or nearly so:
When a problem is first entered, it is active and a major problem, i.e., it shows up on the first-seen list.
When the problem isn’t active anymore and the user wishes to keep it important, the user changes its status from active to inactive (or “current” to “past”, and you’re welcome to put “history”, “resolved” or anything else you like here) but otherwise keeps it at the same importance level. I suppose this same option could let the user delete it altogether, merge it into another condition, mark it as an error or whatever.
When the user wants to render the condition minor – i.e., take it off the first-shown list, a button lets the user make it a minor condition. (When viewing the full list, there can be a Major/Minor column which can be toggled.)
Hopefully this helps address both issues of active-ness and importance, and provides a default (problems are major and active/current when first entered, and if you don’t change anything they just stay that way)
I agree that the main criteria users will want to see and control is major/minor (aka primary/secondary or active/hidden). In addition, optionally, the user can set a clinical status on the condition.
@akhilmalhotra, I would recommend that we approach things as Jonathan suggested (with a required relevance=major/minor field, and an optional clinicalStatus=active/relapse/remission/resolved/history).
@burke, you’re saying we should have a single status field matching FHIR’s clinical status, but use it to capture “clinical relevance”. However the FHIR clinicalStatus values (active/relapse/remission/resolved) clearly do not align with relevant/irrelevant, and it’s a mismatch to say active=relevant and resolved=irrelevant. We’re better off introducing a separate field to indicate clinical relevance, with values matching the actual meaning, and letting clinicalStatus represent the actual status (even if it’s not consistently filled – we can default it to Active on export).
listStatus (active, inactive)? We won’t be able to communicate it to other systems nor receive it.
On export, we could influence an empty clinicalStatus based on the listStatus
Presumably, we would default listStatus of active? Or inactive? We will have to be careful about how/where conditions are imported or added, because filling condition lists with irrelevant entries is easy to do if you are not careful and can very quickly find workarounds to avoid using the condition list.
Primary diagnosis is something that makes the patient visit the doctor.
Secondary diagnosis is something that is diagnosed but was not the one that brought the patient to the clinic.
Major/minor could be used for any diagnosis (primary or secondary).
Introducing major/minor (importance of a diagnosis) as an option, will introduce another level of complexity for the users. Also, importance is subjective. Dental abscess is a major diagnosis for a dentist but a gastroenterologist might say that this is irrelevant to me and put it as a minor diagnosis. I would suggest against putting this additional field on the UI.
However, I can put this in the product backlog and if someone feels this is important in their version of conditions list, they can introduce it as and when required.
As of now we don’t have this requirement from the client we are building conditions list for.
We are talking about condition list. This is a list of conditions the patient has across (independent of) encounters. When a user looks at the condition list (whether or not in the context of an encounter), they would see active (i.e., listStatus = active) entries and would have to toggle a “Show inactive conditions” option to see less relevant ones.
Primary vs secondary is a property of EncounterDiagnosis and applies to a condition only in the context of that encounter.
If a user wants a new encounter diagnosis to be added to the patient’s condition list, the application would assume it’s an active condition (listActive = true). So, users would not be making the primary/secondary vs active/inactive at the same time. Any encounter diagnoses can be inferred to be active if they are added to the condition list and, while managing items on the condition list (e.g. removing old entries which would alter listStatus) might technically be available to users when looking at the condition list in the context of an encounter, would not be part of selecting encounter diagnoses or deciding their ordinarily.
As Burke says, this shouldn’t add to the work of doing an encounter diagnosis, and major/minor doesn’t apply to diagnoses (just as primary/secondary doesn’t apply to the condition list).
New conditions will be active and major by default, so if a user never wants to deal with any of the options, they don’t ever have to do so.
I’m fine with adding a listStatus property for conditions on the condition list to indicate whether or not they are included on the list of “active” conditions. In my mind, listActive=true is an item on the problem list and listActive=false is an item on the past medical history list that isn’t on the problem list.
If we are going to add some measure of priority, I would favor supporting more than two (e.g., high, medium, low) and making it user-patient specific, since it’s a subjective measure and we shouldn’t expect users to agree on a single shared value.
If major/minor is an attempt to measure severity, I’d favor adding severity to align with FHIR.
If major/minor was just an alternate name for active/inactive, then I’d favor the latter for the reasons I mentioned above.
Definitely don’t want to add even more categories and more branch points – and we have seen from past experience that having different views of the condition list (CL) by different providers is a safety hazard as well as an opportunity for miscommunication.
Darius, Akhil and I happened to be in the same forum today. From that discussion:
the overpopulation of the CL is less likely than in other exemplars (because diagnoses are not automatically sent there), so there is less need to filter the CL based on perceived priority. We doubt that the CL will get so large that a too-long CL will be a larger problem than a partially-hidden CL.
Clinically, if someone felt it was important to take the time to place halitosis on the CL, then it should be on the CL; that provider intends for themselves or others to note it when they glance at the patient’s chart for an overview.
So: we now advocate
not filtering the CL by priority, but rather letting everyone see the complete list.
keeping a field for clinical (not physiological) status, i.e., this problem is worth considering as you look at this patient today (Active) vs. this problem isn’t really something you should be thinking about anymore (Inactive – which could possibly be mapped to FHIR Resolved, although that continues to not quite be the right term)
we went back and forth about this, but currently feel that having a listStatus field, even hidden from the initial UI, could cause more problems (tempting people to add importance filtering which we now feel doesn’t make sense) than it solves