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.

start --DanR 21:38, 30 May 2006 (CDT)

Gunther...I could be happy keeping the CNOD class code if we changed the definition, the name, and the location in the observation hierarchy. However, if we're going to change all these things, why don't we just avoid the confusion by defining a new class code and deprecating CNOD?

Are there any other RIM classes we could use that would meet our need without having to make a new RIM proposal?

end --DanR 21:38, 30 May 2006 (CDT)

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)

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.

Gunther Replies:

Larry, why are you saying "no merging"? Of course I can merge, but of course my merging is my opinion, not yours. I simply merge by creating another "Concern" act that REVIses two such prior nodes at once.

Also, note that problem "LIST" isn't even discussed here. Problem LIST is simply a LIST act with components , one per item on the problem list. Each component would usually be a Concern, but, who says it has to. One might as well allow you to put any other act on the list...

But Condition as "more generic shared/accepted" how do you operationalize the difference? What is the technical difference? Condition is reflected by Observation. It's nature as to chronic or acute, trivial or grave, is in the medical knowledge connoted with the diagnosis code (Observation.value code.) This doesn't warrant a special class. Only our choice to consider it a main Concern to deal with is needed in addition.

LARRY REPLIES: I was referring to merging the LIST not the concern -- my bad for poor choice of wording. The issue here is that it will be very difficult if not impossible to identify the significant overlap in multiple overlapping but subtly different problem representations. This problem is exacerbated by attaching all of the baggage of a CNOD tree. Operationally, I was viewing the difference as a lightweight Condition definition that could be thought of as the shared perspective and one that individual providers could assert links from their personal lists. However, after some thought, I'm not convinced that this is the answer either. So for now, you can ignore.

Canadian requirements

We're interested in conditions for two purposes:

1. Allergy tracking
2. 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

Gunther's response

Lloyd, so why are you having trouble interpreting the proposal? You make it sound like it's impenetrable, to you???

What you say againt "Management" is an issue of words not technical function.

The argument against using Observation only for this is an issue of technical function, because the semantics of the status code are confused.

So, if we call that act, which used to be ConditionNode the "Concern" act, and keep the allergy diagnosis in a simple Observation, removing any class code and special class for "Condition", we have all that you need.

• Condition kind (e.g. Allergy to sulphonomides, hypertension, etc.)

This is a diagnosis code: "sulphonamide allergy", "pollen allergy", "G6PDH deficiency", etc. Goes in Observation.value.

• Severity (mild, moderate severe)

Is a secondary observation qualifier like any other severity. If you can do it for pain you can do it for allergy and you should not do it any different.

• 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.)

Why does the difference which you make matter to you? By saying it is no longer a concern you have said all you should need. So Concern act does this just fine. I doubt you can use remission vs. resolved operationally: what do you do upon each? What is the difference for an allergy anyway?

• Id (unique identifier which remains consistent across changes)

That is not a requirement the way you like to construct it. All that matters is that I can send an id to you and if you have heard something about this, you can find the id of this act and any other act which has meanwile superceded the act which you reference.

• Effective time (indicates when the condition began and when it ended)

Concern.effectiveTime does that just fine, Observation.effectiveTime also does that, except that you can't really tell whether the reaction last year was due to that penicillin allergy which you now observe through objective testing. So, you'd be cautious to state an effectiveTime in the Observation which exceeds what you can actually tell objectively. You can still say that you identify the two as the same concern. So, Concern.effectiveTime does that fine.

• 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.)

RPLC links do that for every act in HL7.

• links to 'supporting' information.

Those are links from the Diagnosis-Observation to the supporting Observations (e.g., from the allergy-diagtnosis to the the skin test panel.)

• • For allergies, this would be previous adverse reactions, previous exposures that did not result in reactions, allergen tests

Yes, all of those would be links from the main allergy diagnosis Observation to the prior reactions which you have on history as you make your diagnosis.

However, if you follow the case prospectively, and you come back with repeated reactions, you will record these reactions and link them to the known Observation or Concern to say that they are now re-manifestations of that same underlying concern.

• • For a health condition such as hypertension, this would be previous diagnosis, blood pressure observations, medications, etc.

Yes, but be careful: why "medications"? How does a medication support the diagnosis?

So, I say the Concern proposal (which is the original CNOD design) works for all these.

Peter MacIsaac comment:

Had a look at the discussion. Having joined this midway I am a bit lost with the context. What are we trying to achieve?

Clearly the issue of problems or conditions and how they are described over time is critical to any clinician or medical record application.

I was amazed to find that a rehab specialists would regard cardiac failure as inactive as it is being managed well and was of no immediate concern. It is being treated and the management consists of being aware of it and continuing the medications, might also involve weighting the patient regularly to watch for occult decompensation, might need to check electrolytes at least once etc.

[dan]
This comment relates to several places on the wiki:
Definition and Name of the "Act." "Monitoring program" is one potential name of the Act. Note that Act.code will give more  specifics to the Act such as "Problem" (encoded in SNOMED)." 



SPRT vs COMP Acts: the acts you describe such as weighing, checking electrolytes, etc.


Note that the models proposed don't say how the rehab specialist has to regard cardiac failure. The models just have to capture the rehab specialists opinions and other actions.


Hope that helps. Looking forward to seeing your comments on the wiki!
[/dan]

start --DanR 13:47, 4 Jun 2006 (CDT)

This is a proposal that attempts to consolidate all the discussion. Note that this is an extract of the material sent out on the list. A voting date is a TBD. The tables of the formal walkthrough are not included on the wiki version:

Consolidated Condition Tracking Structure Proposal:

Format:

1. Quick Summary
2. Proposed XML instance in EVN Mood
3. Formal Walkthrough of Model Classes and Attributes
4. Voting Flowchart
5. Visio Model (if possible—not yet done)

1) Quick Summary:
First, as agreed to in San Antonio, this proposed model applies the change recommendation to change the current '=COND' to '<=OBS' in all the Care Provision DMIM’s and RMIM’s.

Second, this model takes the recommendation from Gunther to deprecate one of the class codes (COND or CNODE) and deprecates CNOD. The reason for deprecating CNOD that it was simpler to propose simple changes to the RIM description of COND in order to make it fit the model:

1. change to definition of COND that adds '(Being)Concern(ed) or worry(ied) about' to the beginning of definition of COND; much easier than crafting a new definition for CNOD.
2. change name of 'Condition Class' to '(Being)Concern(ed) Class'

This proposal then changes the CNOD class in the current Condition Tracking Structure to COND

Third, this model changes the entry point to the Condition Tracking Structure from the old COND class to the new class (as recommended by Lloyd), i.e. to COND

Fourth, as discussed extensively in M&M and on the list, this model adds attributes to the new COND class to support time ranges and status codes. The attribute activityTime was chosen instead of effectiveTime to emphasize that the time range applies to the Activity of Being Concerned rather than some hard to define feature of the patient or the performer.

The 'negationIndicator' attribute in this new COND supports the concept that 'there is no concern.' SNOMED users may decide to place negation in Act.code as a modifier and constrain out negationIndicator.

The 'Code' attribute in this new COND supports the ability to subtype the kinds of 'concern,' e.g. concern about problems; concern about risks, concern about intolerances, etc.

The main alternative proposal to be considered is to use MPROT (monitoring program) instead of COND for those who don’t want to use an observation for this monitoring class. Main advantage is that the semantics are very clear. Main disadvantage of this approach is that it is so clear that there is no wiggle room and people may not agree. In addition, there is the need to use '<=Act' for the target of the Reason ActRelationship (or use a choice box to include both OBS and MPROT as the target for the Reason ActRelationship).

2) Proposed XML Instance in EVN Mood (expanded from Lloyd’s XML proposal):

<concern classCode='COND' typeCode='EVN'> <code code='181301000000103' displayName='abstract problem node' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED-CT'/> <activityTime> <low value='date started tracking'/> </activityTime> <statusCode code='active'/> <negationIndicator> whether concerned or not </negationIndicator> <hasName typeCode='NAME'> <namingObservation classCode='OBS' moodCode='EVN'> <code code='DX' printName='Diagnosis'/> <!—- Any valid TermInfo Options; Code value may get squished for SNOMED --> <value code='123' displayName='Lung Cancer'/> <effectiveTime nullFlavor='UNK'/> <subjectOf typeCode='SUBJ'> <!-- This could be squished into the observation for SNOMED --> <severityObservation classCode='OBS' moodCode='EVN'> <code code='SEV' displayName='Severity'/> <value code='S' displayName='Severe'/> </severityObservation> </subjectOf> <subjectOf typeCode='SUBJ'> <!-- This could be squished into the observation for SNOMED --> <clinicalStatusObservation classCode='OBS' moodCode='EVN'> <code code='STAT' displayName='Clinical Status'/> <value code='IR' displayName='In Remission'/> </clinicalStatusObservation> </subjectOf> </namingObservation> </hasName> <hasSupportingInfo typeCode='SPRT'> <!-- Put your clinical statements here --> </hasSupportingInfo> <replaces typeCode='RPLC'> <concern classCode='COND' moodCode='EVN'> <!—- obsoleted previous version goes here --> </concern> </replaces> <links typeCode='ELNK'> <concern classCode='COND' moodCode='EVN'> <!—- NON-obsoleted previous version goes here --> </concern> </links> <subjectOf typeCode='SUBJ'> <controlAct typeCode='CACT' moodCode='EVN'> <code code='trigger event'/> <effectiveTime value='when it changed'/> <reasonCode code='reason for change'/> </controlAct> </subjectOf> </concern>

Voting Process:

1. Motion: Propose to M&M Harmonization that CNOD Class be deprecated.
2. Motion: Propose to M&M Harmoniztion that: a) Definition of COND that be changed to begin with: “(Being)Concern(ed) or worry(ied) about” b) change name of “Condition Class” to “(Being)Concern(ed) Class” Discussion: Fine tune the word-smithing of the RIM changes
3. Motion: Change the CNOD class in the current Condition Tracking Structure to “COND.” Discussion: Entertain motions to change the CNOD class in the current Condition Tracking Structure to “MPROT” instead of “COND.”
4. Motion: Change the Entry Point of the Condition Tracking Structure to the new class.
5. Motion: Add “code” to the new class (see Formal Walkthrough above)
6. Motion: Add statusCode to the new class (see Formal Walkthrough above)
7. Motion: Add activityTime to the new class (see Formal Walkthrough above)
8. Motion: Add confidentialityCode to the new class (see Formal Walkthrough above)
9. Motion: Add negationIndicator to the new class (see Formal Walkthrough above)
10. Motion: Complete model per Formal Walkthrough above with vocabulary domain detail and associations to Severity, ClinicalStatus, and Annotation clones.

end --DanR 13:47, 4 Jun 2006 (CDT)

Hi Dan,

This strikes me as a large radical proposal. (So, you have my vote there :-)

But seriously, I think it's premature to be talking about voting on anything. Someone needs to take everything that's been discussed and put out a synthesis, and see just how much controversy remains. Just based on what you mention below, I get some anxiety, which will only be relieved by seeing all the changes very well documented.

For instance, changing "condition" class to "(being) concern(ed)" to me is a pretty major (too major) change. This just misses the notion that items on a problem list are put there in part because the clinician wants to track them. There is a ton of stuff I'm concerned about that isn't a condition.

What I also really struggle to understand is - why is this so easy in real life, and yet so complicated here. Put something on a problem list. From there, it can be referenced and/or the problem list can be updated. Let's make sure we know which ActRelationship typeCode values to use for referencing. Let's just take a look at existing applications, because they all allow for problem list entries to be updated. (Oh, and let's clarify where UPDT fits in).

I strongly disagree with the need to add any new classCode here such as MPROT. Let's be absolutely sure to include something in the shared clinical scenario that justifies all the complexity if in fact MPROT is needed.

What are some of the bumps people are running into when representing conditions in V3, and how are they resolved by this proposal?

• Must the classCode of an item on a problem list always be "COND"? what about a family history or past surgical history item?
• How to value Observation.code for a condition or disease?
• What classCode to use for an encounter diagnosis on a progress note?

I also have significant concerns about the XML example below, including:

• the nested <namingObservation> contains a status and a severity, whereas really what we want to be doing is updating the status and/or severity of the problem list item.
• Do we really care about messaging the fact that someone is concerned about something, or do we want to message someone's problem list? If the latter, we already have LIST.
• I've never seen an application that lets you change the Act.code of a problem list item.
• It doesn't use the shared clinical scenario. One of the primary intents of that scenario is to cover what's being addressed here.

Anyhow Dan, I know you've thought long and hard about this, and so I have no doubt that I'll be learning a lot from you as we go through the voting, but for now, this entire proposal for me represents, well, a "condition".

Take care,
Bob

Summarization/Suggestions for resolution

Hi All,

I had a little more education from Dan on the RIM modeling and HL7 nuances and we had some additional discussion about the issues, including a review of the RMIM.

After mulling over this for several days, I consistently find myself coming back to the statement “There are multiple ways to skin this cat.”

Here is what I understand of the Issue list:
a) What is the appropriate ClassCode for Condition/ConditionNodeEvent b) How is “clinical Status” represented c) How should the times of Conditions/ConditionNodes be recorded d) How should Condition Observations be linked/revised. e) How should Condition coding be represented

My suggestions: (reference off the ballot RMIM REPC_RM_000300)

1) Consider changing Condition ClassCode=Act.CCRN

My understanding was that M&M took issue with COND as ambiguous by confusing the name ‘Condition’ being perhaps something broader (ie the concept independent of the patient like "Diabetes is a abnormality in Blood Sugar"), or perhaps something more narrow(an observation/judgment of a clinician that a patient has that condition ("Mr. Jones has Diabetes"), and by Gunthers observation something in the middle (a concern the provider has about the patient, which relates observations but is very subject to change "Mr. Jones has a high blood sugar -- I think it's Diabetes out of control"). If we take the Condition object (eg the tracking structure defined in the RMIM) to mean a ‘Concern’ as Gunther suggests (and I agree with) then I think the semantics become more clear. I propose we add Concern (CCRN) with Gunther providing an appropriate definition. I also favor adding it as an Act rather than as an Observation strictly since it hurts my brain to think of a concern/condition as an observation (The observer is the provider and the concern is the providers, so the provider is observing his/her own thoughts??). However, I do understand Lloyds problem of needing to put the code in value and need to make it an observation to get that attribute, which would require a RIM subclass.

Technically, I do wonder if this is truly doing that much, particularly if it remains an observation. If the concern that would prompt renaming Condition is that there is potential for misunderstanding what Condition really means, then I think we are adding fuel to the fire by just making yet another classCode with a very similar meaning to COND/CNOD, particularly if they have the same attributes. The existing model works (or could be massaged to work) even if the names are sub optimal.

While we're making thing more clear, I also like using the classCode to constrain the object better than leaving it as a general OBS and using a SNOMED code=”problem.” to constrain meaning (I believe this suggested this as a possible solution). I think classCode better reflects the subgroup of things that have the defined relations. I thought the name “Condition” as chosen over "problem" because “conditions” is a more general term (eg some concerns/conditions are not “problems” with the negative connotation). I think this would imply that the code be one of a set of valid values such as “problem|allergy|health maintenance|etc”. This would have to be specified upfront in order to have some clarity that we’re talking about condition tracking (as opposed to generic observation tracking). I would prefer not spend more time debating the granularity of this valueset right now.

2) Add hasName->NamingObservation

I agree with Lloyd’s use of “namingObservation” as an important distinction of a condition. In fact, I think that’s pretty close to what is currently the ConditionNodeEvent/Condition relationship is trying to do in the existing ballot, except that ConditionNodeEvent doesn’t have the attributes of name (so it acts more like the "concern") but is defined as a point in time (so it acts more like the namingObservation), where Condition has capability to define Name/Codes (so it acts like naming) but can occur over a period of time (so it acts like the concern). Ergo the confusion. Something needs to be fixed here. I favor using the existing Condition object for the "concern" part because I think is an easier change to the RMIM. The entrance point is currently to the Condition Object, to me most of the attributes/relations seem to fit better with the "concern" part (although that may be up for further debate).

Another advantage of keeping the naming separate from the Condition also has a very pragmatic use case. In the US at least, Billing codes (the namingObservation of a Concern at a point in time) must be assigned to visits (at a point in time=Admit/Discharge) where the from a clinical perspective the condition/concern persists on a problem list. It also solves the code/value problem because now this can be a pure observation, just like diagnosis.

3) Drop the class ConditionNodeEvent and just put the recursive ELNK on the Condition class itself by allowing the replace to be <=RPLC rather than =. Move the support->CareStatement to Condition directly.

Fixing/Clarifying points 1&2 above fixes the problem of the relationship of the concern and naming relationships and makes CNOD obsolete (fixing the time period problem of a CNOD).

Note for those that don’t like this, CNOD is still defined in Care Statement, so it’s just a step away (might want to address this as a separate topic).

My only concern with this is clarity about what instance identifiers should do. I think this is problem no matter what, but it should be specified for clarity.

For example, is this would this be expected? A simple evolving condition:

[Condition: “Hx of MI “, id=1
  [replaces [Condition: namingObservation=“Acute MI”, id=1,
    [replaces [Condition: namingObservation=“R/O MI”, id=1,
      [replaces [Condition: namingObservation=“Chest Pain”, id=1 ]]]]]]]]

A split makes new instance identifiers

[Condition: “Pneumonia”, id=3
  [replaces [{id=1}]]
[Condition: “CHF”, id=2
  [replaces [{id=1}]]
[Condition: Dyspnea, id=1]

A merge ?? keeps the older id??:

[Condition: {id=1} replaces {id=2}]
[Condition: “chest paint”, id=2]
[Condition: “anxiety, id=1]

4) Add ActivityTime to the (either COND/CCRN ) object.

Where ActivityTime low would be the time the observation/concern began. ActivityTime high would be the time the concern ended. Presently, there is no way to indicate that the Condition observation is ongoing, but also what time it begins/ends (independent of when the patient problem begins/ends which is effectiveTime).

5) Allow statusCode of the Condition mean clinical status.

Now that there is clarity about Conditions meaning the Concern portion and activityTime meaning when it the statusCode changes state. If M&M still takes issue with this, add a statement in the ballot indicating the recommended way to represent clinical status as a care statement.

Larry.

<Lloyd>

I don't think MnM had an issue with the existence of the class, merely with the use of status. There were also concerns about what exactly was being represented - was it the observation of the condition or the condition itself.

</Lloyd>

<Lloyd>

I would not recommend adding a new classCode unless we have a really good use-case for the existing ones. If we need to, we can change the print names and definitions of the existing classCodes to clarify their use. The only issue would be if those are already used in normative materials.

</Lloyd>

re: "I would prefer not spend more time debating the granularity of this valueset right now"

<Lloyd>

Agree. Some get most upset when you call "pregnancy" a problem :>

</Lloyd>

re: Add hasName->NamingObservation

<Lloyd>

Right, so this would mean that we would have a non-observation class called "Condition" or "Condition Node" which would not have a value. It would have a "has name" relationship to an observation event which would be a diagnosis or similar finding, which would be modeled as diagnosis always is. My only question then is "what goes in Condition.code". It should *not* be something relating to management. The semantics are effectively "what kind of concern is being had" (as opposed to what the concern is labeled as). Any thoughts?

</Lloyd>

<Lloyd>

I'm comfortable with dropping the distinction between COND and CNOD. I'm not so happy about using <=, though I could live with it. Note that ELNK is not a specialization of RPLC. The advantage to having them distinct is we can clearly document their intended uses.

</Lloyd>

<Lloyd>

We added a new typeCode in March to allow distinguishing "updates" (where the id stays the same) and replacements (where the id changes). We should adopt these codes and make the distinction clear.

</Lloyd>

re: statusCode as Clinical Status

<Lloyd>

MnM will definitely take issue with this. The concern was not "you can't use statusCode for clinical status because you need it for something else", it was "you can never use statusCode to represent the clinical status of an act, only to represent the status of an action". The only way we could get MnM to agree with using Act.statusCode would be if we defined Condition.code as the "Act of being affected by a condition".

</Lloyd>

Larry replys: 6/7 7:30p

Thanks for the clarifications, Lloyd.

One reason for proposing the new classCode was that I understood/misunderstood that it was a major thing to change the meaning/names of these definitions. I would be OK by clarifying meanings:

Condition(classCode:COND) An object that groups namingObservations together as a thread of the clinicians concern for a process occurring in a patient. It persists over time and changes names frequently. This is the item that sits on problem lists. Examples include a physician recording a problem of "breast Mass" then updating it to "probable Cancer" then to "Breast Cancer" then to "Breast Cancer s/p Lumpectomy/Chemo" then to "History of Breast Cancer" These named Observations eg "Breast Cancer" are linked via a Condition which is the ongoing concern that the clinician is tracking.

An alternate would be to use CNOD for this, but change the definition to persist over time, and in the RMIM change entrance point to in ConditionTracking to CNOD, rename the condition object to NamingObservation and move appropriate relationships)

namingObservation(classCode:OBS) is a timePoint observation that assigns a name to something such as a clinical condition. Examples include assigning a diagnosis code or label to a Condition

Once we decide which approach we will use (CNOD or COND), we should define these more formally. Gunther???

Re: "you can never use statusCode to represent the clinical status of an act, only to represent the status of an action" "... if we defined Condition.code as the "Act of being affected by a Condition"

I think that's what I'm saying/proposing, except maybe that it's not Condition.code that's constraining its classCode=COND. The action here is "being Concerned". I think the status of that "being Concerned" IS the clinical status. If not, what is the definition of clinical status?

re: "My only question then is "what goes in Condition.code". It should _not_ be something relating to management. The semantics are effectively "what kind of concern is being had" (as opposed to what the concern is labeled as). Any thoughts?"

Is it constrained to be required (maybe a stupid question, I'm still learning)? Conceptually, I think it just further constrains what type of concern it is (eg Allergy|Health Maintenance|...). My preference would be to leave it for customers as an organizational label (eg use if your interested, but not required). I don't know if that's possible, but the use case here is a layer of abstraction higher than a diagnosis, but lower than Concern. Examples might include things distinguishing like "Nursing Problem" from "Physician Problem" (a really common issue) or perhaps even "Pulmonary Concern" from "Oncology Concern" from "PulmonaryOncology Concern". (A messy area just like Diagnosis codes)

Larry.

From Gunther

I have looked to see whether a synthesis has emerged in my prolonged absence. But I don't see one. I would therefore strongly agree with Bob above that it is too early to vote on anything on today's call. We need to have a specification that works and is clear, whether that's mine to which this discussion is attached or something significantly morphed from there. How do we get there?

Some scribbles I took from today's call

These scribbles make no sense but contain some keywords and argumentations which I heard.

hasName -> subject

hasSupportingInfo -> should not be done

replaces -> previous need not be obsolete

--DanR 17:15, 25 Jun 2006 (CDT) Not true...check out the definition in the RIM --DanR 17:15, 25 Jun 2006 (CDT)

Other relationships

• PROBLEM MEMBER ???

- - what is that? - - U.K. has only that "member", besides perhaps a name, but

   no specific semantics attached.

- - how would they convert to HL7?

• REASON FOR CONCERN as opposed to SUBJECT OF CONCERN ???

Example:

Blood test shows Liver-problem + med that can cause liver problems + prior history of alcoholism

• Link to "name" Observation or Concern??

- - off of name observation not of the concern

• Chest X-Ray related to Pneumonia and CHF

- - REASON from Chest X-Ray to both of Pneumonia and CHF - - REASON can go directly to the Observations of Pneumonia and CHF whether or not they are CONCERN

Do something because of chest pain then chest pain resolves / turns into GERD now the reason changes? This means reason relationships from treatments to "conditions" should go to the observations which are the "names" (subjects) of Concerns rather than to the concerns.

[But those people who like to talk about "versioning" will say that this can be tracked by the version of the Concern... and they are right. So, reasons could probably link to naked observations as well as Concerns.]

• SUPPORTING evidence goes of "named" Observation

What the heck is SUPPORT about? I hear only vague things.

Shortness of breath -> Pneumonia and CHF

Allergy to X Supporting diagnosis? Had a Reaction Lab test shows are not allergic Con

Adverse reaction Supports diagnosis of allergy

Concern -subj-> Allergy -supported-by-> Adverse Reaction

 ^
 |
replace
 |

Concern -subj-> Allergy -supported-by-> Adverse Reaction

Abstract-Membership?

Problem List

|

Concerns

|

Members???

Concern -> Members???

--DanR 17:15, 25 Jun 2006 (CDT)

Motions for Wednesday, June 28 PCTC Call:

I haven't seen any motions come through on the list or the wiki. So I'll make a few.

1. Motion: In addition to the NAME ActRelationship from Concern, add a (0...*) SUBJ ActRelationship (for "Subject of Concern") from Concern Class to Care Statement Choice Box.

2. Motion: Correct the NAME definition in the RIM to take away the mention of CNOD and COND.

3. Motion: change the current SPRT ActRelationship from Concern to Care Statement Choice Box to the vocabulary domain "ActRelationshipType."

--DanR 17:15, 25 Jun 2006 (CDT)

--DanR 21:46, 29 Jun 2006 (CDT)

---

Preparation for July 12 Call:

The next big discussion on July 12 will attempt to resolve issue number three above--what ActRelationshipTypes do we allow from Concern (source) to Care Statement Choice Box (target)?

Summarizing the use cases (please correct if I mispeak here):

1) UK wishes to create a new ActRelationship of type "member" to allow the problem to include both 'subject" and "member ActRelationships from Concern to Clinical Statement Choice Box.

2) Netherlands primary care associates each clinical statement with an un-named ActRelationship to both encounter and named problem.

3) Netherlands inpatient problem list project does not collect similar information

3) Canada wishes to have a persistant Act to incrementally collect details about a concern over a time range rather than only being able to use Acts which represent points in time for this purpose.

4) Gunther's problem list project does not collect similar information from the Concern (only associations to the "subjectClasses" are allowed, which always have status of "completed" and may be replaced.)

5) US has ASTM CCR, for which the HL7 Board has committed to a joint mapping project with ASTM. CCR allows non-specific references from the "problem," which has a coded description, to other EHR objects.

Overall, this collection of use cases points to the need for the ActRelationship from Concern to Care Statement Choice Box. However, local implementation guides will either use different ActRelationships or will constrain out the use of this ActRelationship entirely until more experience is gained during the DSTU phase.

Therefore, the first motion for July 12 will be the same as tabled from the June 28 call:

Motion: change the current SPRT ActRelationship from Concern to Care Statement Choice Box to the vocabulary domain "ActRelationshipType."

Discussion: The creation of a vocabulary domain will allow a realm to meet its local needs by identifying a realm-specific vocabulary domain value set in its implementation guides for use during the DSTU period.

--DanR 21:46, 29 Jun 2006 (CDT)

Addressing these use cases

1) UK wishes to create a new ActRelationship of type "member" to allow the problem to include both 'subject" and "member ActRelationships from Concern to Clinical Statement Choice Box.

The issues isn't what the relationship type would be, as long as it connects to the concern directly but not to the "name".

Would use PERT for sending, and could receive any special relationship type.

a) all of the things you'd like to see reported to you as "members" should be connected directly Concern and not through some other nodes, specificly not.

b) for sending they need one default relationship which they can always use PERT is good.

2a) Netherlands primary care associates each clinical statement with an un-named ActRelationship to both encounter and named problem.

Every statement has a relationship to an Encounter and one of the Problems on the problem list.

2b) Netherlands inpatient problem list project does not collect similar information

3) Canada wishes to have a persistant Act to incrementally collect details about a concern over a time range rather than only being able to use Acts which represent points in time for this purpose. f

Canada wants to associate two things with the Concern:

- Reactions - Lab Tests

so that they can change their minds whether to call it an Allergy or Intolerance and still use the same Concern with these relationships to Reactions and Lab Test.

Seems similar to U.K. in that it's just related information without there being a special need for a relationship type. The Concern is then like a folder where you can throw information in. You don't want to force them to say why they put it into this folder.

It's like "free association".

Component relationship would not be appropriate.

Pertinent might work. Reference could work, as it only establishes a directed relationship.

4) Gunther's problem list project does not collect similar information from the Concern (only associations to the "subjectClasses" are allowed, which always have status of "completed" and may be replaced.)

5) US has ASTM CCR, for which the HL7 Board has committed to a joint mapping project with ASTM. CCR allows non-specific references from the "problem," which has a coded description, to other EHR objects.

Reference seems to work.

--Gschadow 16:25, 12 Jul 2006 (CDT)

Wiki Skills

FYI, For all those (like me) who couldn't figure out why the formatting is getting all messed up, here are some cheet sheets on wikitext formatting.

Quick Complete

Larry.