Talk:Discussion on Condition Tracking
Gunther, regarding your proposal:
Are you locked to the wording of "BeingConcerned" vs the noun form "Concern". "BeingConcerned" seems very awkward and is unidirectional (providers are beingConcerned about problems, but problems aren't BeingConcerned about providers). This wording to me is similar making an "Observation" act into a "BeingObserved" act.
[Gunther's response:] NO, I LIKE "CONCERN" BETTER TOO. I JUST TRIED AN ACT FORM TO AVOID THE SPANKING FROM BERRY SMITH AND CO. :)
I'm confused about how you see the difference between your "BeingConcerned" act and a CNOD or Condition? My (perhaps weak) understanding of CNOD suggests to me that these seem the same. They both seem to act as the reason for my other actions such as placing an order. They are the persistant place where I link the related time point observations (including coding/labelling). Concerns may split/merge over time. Eg, first I'm worried (my concern) about "Chest Pain" as a new thing, but after I have ruled out the heart attack I write it off as part of (merge with) the patients existing "anxiety" (which is likely another ongoing concern).
GS: THE CONCERN AND CNOD SHOULD BE THE SAME.
Are you just proposing that the name "Condition" or "CNOD" be replaced with "Concern"? If so, which one and why is this so important? If not, how are is a "BeingConcerned" (as in what attributes/relations) act different.
CONDITION "OR" CNOD IS A PROBLEM, THERE IS ONE TOO MANY HERE. WE SHOULD KEEP CNOD AND YOU HAVE ALREADY DITCHED "CONDITION" FOR A GENERIC OBSERVATION ANYWAY. THAT'S WHAT I THINK WE SHOULD DO.
All:
I'm a relative newby, and this may have been hashed out priviously, but for reference, it still isn't clear to me, and it may be the root of many peoples confusion also. Who's list are we talking about?
I think that most people (certainly many EMR systems) tend to view the the problem list as a single list for a given patient. In the real world, however, that isn't really the case. There usually are many problem lists for a given patient -- each provider has one. There also tends to be a thinking that with a computer these can be somehow merged into a single (_THE_) problem list which is the union of all of those lists with all of the redundancy and irrelevant old problems filtered out. In other words _THE_ problem list for the patient is just the all of the active problems in there most recently known state. This is what rules/triggers/ordersets/careplans would look at to see if they match for that patient. There is confusion over if this is the list of all of the tails of the CNOD's or if it is something else.
If a Condition (or CNOD or Concern) is an observation, then who is the observer responsible for maintaining it? Is it an individual user or a group? The condition_list and conditionEvents have a custodian/author with is a responsible party (either person or group). Reading the RMIM, I'm still not sure who maintains the CNOD in either the original, modified, or on Gunthers model. But assuming a CNOD does have an author/custodian is the easy answer and not really what I'm getting at. I'm asking is it an _Individual_ or a _Group_. This is important because problems/diagnoses/conditions are assertions of beliefs, they are not facts, and I believe the whole idea of tracked conditions seems to break down if the maintainer is a group. If it is maintained by the group, then is it really an observation at all? Perhaps it is a very specialized form of an observation in that it may be shared between providers (ie it has some kind of meta-observer). Or is it the case that only individuals have problem lists that cannot be shared?
An example may make this more clear.
Every provider wants to track his problems his/her own way. There is a common assumption that the care providers would be inputing and maintianing the (condition/CNOD/concern) data, but every provider has their own need and interest so at the very least _THE_ problem list needs to be filtered to "just my problems" that the individual provider can maintain.
So, lets say each provider may have their own problem list, and others can view those problems and use them as the rational for some other purpose such as justifying an order or billing or suggesting a rule. This viewing alone doesn't seem to be a problem, and is an easy thing to do.
Now say there are 2 providers. Provider A updates the status of a (Problem|Condition|CNOD| Concern) on provider B's problem list. Provider B may get quite upset because that problem is meant to be provider B's belief, not provider A's. To solve this, we should suggest that Provider A must first _copy_ the (problem|condition|CNOD|concern) to his list first (ie he also asserts the observation as a separate event) and then he may edit the (P|C|C|C) to his hearts delight. Again, the world seems happy.
But then, provider C comes along and wants to view _THE_ combined problem list. Provider A and B have been sharing a lot and so Provider C sees all sorts of duplicates all with subtle differences. Imagine a real patient with and Internist keeping his 15 problems, the cardiologist adding his 5, pulmonologist 5, the nurse with 10, all of the problems added for billing purposes, a smattering of ER problems, historical problems,etc. Many (P|C|C|C)'s overlap, some don't. Even before extending this to a lifetime EMR or the like, Provider C sees a mess, and says, "Hey, can't you IT guys just filter out all of the duplicates and irrelevant stuff?"
Somehow, the system must keep references when problems are copied and manage the merge to filter duplicates. But, subtle things creep in it so that it wont be so easy to do this. For example, in the most simple case, after a copy happens let say Provider A changes the NAME for his (P|C|C|C) but Provider B does not. Who's NAME gets used for the list going to Provider C? Some smarty-pants may say "well just code everything and only show 2 problems if the codes are different (therefore the 'concepts' are different). Make/let Provider C pick his own NAME based on his vocab server". Dispite the practical UI issues (who does this coding and when, which coding system are we talking about, how do you manage differences in the opinion of what granularity, etc), suppose the the codes do match, but provider B records that the clinical status is "resolved" but provider A wants to keep the problem around and thinks it's still active. Provider C want's to know if the problem is resolved or not? Uh, now it depends on who you talk too. In fact, _any_ attribute associated with the (P|C|C|C) will have this issue.
Maybe we can just copy what everyone agrees to? No, because there is if this is the model, then if just one person involved in the care doesn't agree then it wouldn't be available for copy and _THE_ problem list becomes empty. You could try to split the middle by using some algorithm such as if "most" (ie >50% of providers) agree then copy. But, then the problem turns into a probability model and there will be all sorts of disagreement over what "most" means. I'm not sure how these probability based specs would be written.
OK, lets say we go back to purist view of modeling and decide that CNOD's/Concerns are strictly a single persons belief. So no automatic merging -- thats out of scope. Provider C is left out and must manually pick from the subtle differences and choose for him/herself what they believe to be true.
I believe the crux of the original issue (which has now expanded to touch on many other points too) is that in some cases would be very nice/important to have a single point of truth.
For example, suppose that Provider C is now an arden syntax rule or an orderset trigger. People really want a way to just say "If this patient has the condition of 'acute MI', then suggest a beta-blocker" Right or wrong, they want a single condition list to check and they don't see this a CNOD because they don't care about thread history like an individual does and they want it shared to be broader than an individual providers viewpoint -- the CNOD thread makes it difficult to share. They maybe right in the fact that, if a CNOD is just somebodies opinion and 2 people can disagree so there are differing lists, making a (rule|orderset|careplan) trigger will be ugly gymnastics. You could be oversensitive and always suggest if _anyone_ asserted that the patient had a MI. But then, how do you keep from firing duplicate or inappropriate rules/ordersets when all sorts of people are recording this information and just one of them doesn't mark things as resolved? They may be wrong in the fact that its entirely unclear how problems get onto or are maintained on a single list. We don't have that individual identified. A PCP may be close, but I don't think a PCP wants to remove the duplicates for nursing problems, or manage the problem granularity issues needed for an oncology patient.
So, I think there are 2 or perhaps 3 camps. There are those that view the (P|C|C|C) from the perspective of the clinician (as an individual belief thing) trying to follow conditions over time. Then there are those that view the condition from the perspective of the hospital (as a relatively static last state, group shared thing) as some kind of data that they can leverage to do billing, do data analysis and trigger off of. And then there the camp that are just flat confused. Count me the last camp. If your in one of the first 2, convince me of your point.
Larry (Larry McKnight, MD, Siemens)
Contents
All
I agree with Dr. McKnight. The problem list is mostly a management tool and will vary from clinician to clinician. The status of a problem will vary depending on who is managing the problem. For instance as a rehab doctor, I may want to call someone's cardiac problem as inactive, because it is well managed and won't interfere with their therapy. For the cardiologist the cardiac problem may need to be classified as active, as he/she would be adjusting many medications. For the cardiologist, their back pain is an inactive problem as it is being managed by me and doesn't really impact their visits.
It appears that the two biggest needs for problem lists are for direct patient management and tracking of what needs to be managed and concerned about and as a place to hold medical reasoning. A problem list in its best form would help show the reasoning that we think something is a problem. For me an ideal problem list would include a top level view of the problem, with a drill down view of all the component parts that helped make this a problem. As a scenario, I would like to have an L5 radiculopathy with my own way of stating this is active/inactive. I would also like to attach to the problem my reasoning, which would include MRI results, elements of my clinical exam (including straight leg raising and crossed straight leg raising) and the pain diagram that the patient drew when I first saw him. I would also like to attach to this whether they received benefit from oral steroids, physical therapy and where they had their physical therapy, or an epidural steroid injection. I also need to establish a start date (that may be fuzzy-about January 2006) and an end date if I think the problem is resolved, not just when I first observed the problem(I only started seeing the patient in May of 2006)
Now this is a lot of detail, and most of it may only be of interest to me. Many other clinicians would not be interested in my detailed problem list. However, most other clinicians would be interested in the level of diagnosis and the fact that this person has a radiculopathy. Perhaps that is the main distinction that we need to draw. Problems that are elevated (or shifted sideways) to diagnoses are the conditions that need to be shared in global lists about the patient. So we need to view the (P|C|C|C) from both camps for it to be useful, but I think the group view is mostly diagnoses, not everything that I would call a problem. I may always put "lack of exercise" in my problem list, but it may not need to go on a diagnosis list.
Douglas R. Johnson, MD
Gunther sez
Yes, a problem list belongs to a provider. Both the list and the problem (Concern, CNOD) is owned by the author. And my system allows multiple problem lists for the same patients for different providers. That's been part of the design forever.
Some additional thoughts on condition tracking
Greetings,
I don't agree that we need a condition management act. All we need to do is put a condition on a problem list. Once it's there, we can reference its object identifier, with a pretty rich set of relationship types.
I also don't see any fundamental problem with saying that some of the things on a problem list have statusCode="active" if they are continuing to be observed.
Structured Documents and Patient Care are working on a shared clinical scenario to help make this topic more concrete. A patient sees a primary care provider for a rash. An encounter note is created. A problem list entry is made. The patient then sees a specialist, who references the problem list entry, and further clarifies the diagnosis.
A couple other comments I had about the representation of conditions include:
o There seems to be a slippery slope between replace and revise. The notion that one can change the Observation.code of something on a problem list is something I've never seen in any application.
o I feel like there's still a big need to reach some resolution about the code/value split, and how one should be valuing observation.code for a problem, diagnosis, etc.
o Where does the ActRelationship "UPDT" (updates (condition)) fit in to all of this?
Thanks, Bob
Gunther = Camp A
Gunther,
For the sake of clarity, I think that puts you squarely in my "Camp A" -- all problems and lists are a belief of the author only -- no merging. I agree that CNOD does that much. But, then how do you manage Provider C's problem of trying to capture _THE_ list?
Another example. If a condition is just someones belief and not shared, but an allergy is a just a condition, how would you fire an alert to say -- "don't prescibe the PCN, the patients allergic to that"? Would every provider have to explicitly copy the allergy and assert that as true?
Although it isn't stated as such (I would favor that it is) to me this is the essence of the difference between the CNOD and a Condition and why a separate layer might be of value. CNOD is the personal belief, and is linked to a Condition which is the more generic shared/accepted fact in the last known state.
Larry.
Canadian requirements
We're interested in conditions for two purposes:
- Allergy tracking
- Medical condition tracking
In both cases, our desire is for a single record of any given allergy or medical condition across the country. Those records may evolve over time. E.g. An allergies severity may change, or be updated to be a non-allergy intolerance. A diabetes condition may change in severity. A pregnancy may end.
Basically we want the following attributes for the "condition":
- Condition kind (e.g. Allergy to sulphonomides, hypertension, etc.)
- Severity (mild, moderate severe)
- Status (e.g. active, remission, resolved, refuted. This reflects the presence of the condition in the patient, not whether or not it is considered an active concern by a particular provider.)
- Id (unique identifier which remains consistent across changes)
- Effective time (indicates when the condition began and when it ended)
- Previous version (points to a previous version of the condion. Chaining through versions allows you to see how the condition record has evolved over time. Links to ControlActs shows who was responsible for each version, when it was created, why, etc.)
- various other standard stuff (confidentiality, author, author time, supervisor, etc.)
- links to 'supporting' information.
- For allergies, this would be previous adverse reactions, previous exposures that did not result in reactions, allergen tests
- For a health condition such as hypertension, this would be previous diagnosis, blood pressure observations, medications, etc.
From a problem list perspective, different applications may choose to locally "track" any subset of these nationally stored "conditions/problems/concerns/whatever". At some point we might allow these subset problem lists to be shared, though this is not part of near-term plans. I.e. The assertion of something as being a condition/problem/concern/whatever and choosing to track it in a problem list are distinct things.
In terms of whether a condition/problem/concern/whatever is an observation or not, general preference is to say "yes" because it makes sense to use the Observation.code and Observation.value attributes when expressing a condition in exactly the same way we do for a diagnosis.
A key thing for us is that the concept of "management" of an allergy or other condition be considered a distinct concept from the existence of the condition itself. We may choose to capture and track numerous conditions with no intention of ever managing them.
At present there are no plans to implement national standards for the more sophisticated behavior of using condition node-like behavior where different collections of supporting items associated with a condition are attached to the condition at different times.
From a perspective of reviewing the proposal, I'm having trouble understanding whether it meets the above requirements or not. If it does, then I'm happy to endorse it :)
Lloyd
