This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Discussion on Condition Tracking"

From HL7Wiki
Jump to navigation Jump to search
Line 4: Line 4:
  
 
My negative ballot is on Condition and ConditionNode. I have been involved in the early design of the condition tracking and problem list topic in the RIM (then called USAM) and I have observed (rather passively) how the committee had worked with these things over the years. May 2006 was the first time the material was up for a normative track ballot, and the first time I voted on it.
 
My negative ballot is on Condition and ConditionNode. I have been involved in the early design of the condition tracking and problem list topic in the RIM (then called USAM) and I have observed (rather passively) how the committee had worked with these things over the years. May 2006 was the first time the material was up for a normative track ballot, and the first time I voted on it.
 +
 +
--[[User:DanR|DanR]] 12:29, 26 May 2006 (CDT)
 +
Thank you Gunther for starting this page. Patient Care TC would like to continue the discussion on this page. Since this is the first "wiki experiment" for PCTC, we would also like some summaries of this discussion on the list, but hope to direct discussion to this page.
 +
 +
I was instructed by the committee to move the Excel spreadsheet rows on the various proposals to this wiki and generate discussion questions that will lead to votes on each discussion item in official Patient Care TC conference calls. This will lead to a "focused" re-ballot of this portion of the Care Provision DSTU at a time to be announced by PCTC.
 +
 +
Again, thanks for getting this started!
 +
 +
--[[User:DanR|DanR]] 12:29, 26 May 2006 (CDT)
  
 
= Ballot Comments =
 
= Ballot Comments =

Revision as of 17:29, 26 May 2006

Introduction

I, Gunther Schadow, start this page to have an organized discussion on my ballot comment on condition tracking material in the care provision ballot of the 2006 ballot cycle.

My negative ballot is on Condition and ConditionNode. I have been involved in the early design of the condition tracking and problem list topic in the RIM (then called USAM) and I have observed (rather passively) how the committee had worked with these things over the years. May 2006 was the first time the material was up for a normative track ballot, and the first time I voted on it.

--DanR 12:29, 26 May 2006 (CDT) Thank you Gunther for starting this page. Patient Care TC would like to continue the discussion on this page. Since this is the first "wiki experiment" for PCTC, we would also like some summaries of this discussion on the list, but hope to direct discussion to this page.

I was instructed by the committee to move the Excel spreadsheet rows on the various proposals to this wiki and generate discussion questions that will lead to votes on each discussion item in official Patient Care TC conference calls. This will lead to a "focused" re-ballot of this portion of the Care Provision DSTU at a time to be announced by PCTC.

Again, thanks for getting this started!

--DanR 12:29, 26 May 2006 (CDT)

Ballot Comments

My main issue with the patient care ballot is occams razor rule: don't invent more things than you need; in other words, keep it simple. Plus, the specification needs to be defined enough in order to say how to implement it. And implementing condition tracking functions in a new order entry system is what I am presently doing, so I like to have it settled soon.

I find that things are too complex and that when I speak with members of the committee, I do not hear that people actually have a common technical understanding of what the specification says.

Gunther Schadow's Ballot Comments on Care Provision Ballot May 2006 on REPC_RM000300 Neg-Mj.
Text Comment
There are 2 Acts that seem like a condition, and 3 linkages REPL, SEQL, and ELNK. The difference is quite obscure, and the text seems to be at odds with the diagram. The text says that ELNK is a relationship on Condition but the diagram has it on ConditionNode and the text doesn't speak about ConditionNode.
SEQL, vs. RPLC Note that according to the HL7 terminology, a RPLC link is a SEQL link. So it is not clear what the point is of separating the two relationships. The notes may explain the motivatkion, but the model is ambiguous. You want to make the distinction between the link to a previous state of the condition in the near past and an earlier condition in the far past. To do that you'd need to define a different ActRelationship type, under SEQL, but more specific to SEQL.
In pregnancy, the understanding of the pregnant condition is altered by the fact that the woman had a previous pregnancy. When the care provider wishes to communicate an analogous situation, then the "sequel" act relationship should be used and the previous condition instance should be declared "obsolete" instead of "complete." That would make no sense. The previous condition is in the past and presumably was resolved. Assuming that the status code for a resolved condition would be "complete", then why would you change that status code later on if all you do is refer to it from a distant future condition to say that this reoccurred. That's the main difference between the RPLC link and your new link, that it does not speak about the old condition, only says that the new one is somewhat like the old.
Condition.statusCode I believe you assume that the statusCode of the Condition would be "active" for active problems and "complete" for resolved problems. I don't think that works if you think of a Condition as an Observation. An Observation status is "complete" once you are done making your observation. You found out that the patient has CHF, then that's your observation and it is complete. What you are talking about is the MANAGEMENT of that condition, which is still "active". I think this model is fundamentally broken in this regard. You should have two acts, one general condition management structiure using ConciditionNodes and the other one using normal Observations and even other Acts to say what the management is about. That is best done with a SBJ ActRelationshiop. Then the status of the ConditioNode (or ConditionManagementAct) would be "active" for active management and "complete" for those conditions thought to be resolved. (see diagram pasted here for a simple shematic of how this can work much more clearly and also simpler than what you have here.)
Note: replacementOf usded to link previous versions of the same Condition, i.e. same instance identifier. The instance id of these nodes would certainly be allowed to change. You don't need this version thing that doesn't even exist in HL7 v3 at thius time. All you need is a RPLC link between two acts with two different ids.
ConditionNode I can't find a discussion about how condition and condition node relate, but as I am saying above I think they are mixed together here. The status code should be on the ConditioNode.

I would like to hear from other voters, such as the Canadians and Oracle and other groups who are actually writing software for this on the question of whether the present specification tells what needs to be done to implement it. Because if it doesn't say exactly what to do, it can't work interoperably.

Proposal

Schematics of Condition Management RMIM

Overview

I think we are already moving towards understanding Condition and Observation as one and the same. The long term thing which you need, should be accomplished with an Act which is the Act of bothering or worrying or of being concerned about something, and that is short of calling it "ConditionManagement" act, although, for the so-inclined that would be the right thing to call it.

Such act would have one outgoing relationship of type subject, which is the subject of concern.

Excurse: Similarity to Issue (ALRT) Act

A ConditionManagement (or BeingConcerned) Act of that kind, would further be almost identical in logic with the Issue modeled as an Act, at least in one point of view:

 Issue -[subject]-> stuff to worry about.

And interestingly the Issue act also has a similar confusion around it as has Condition vs. Observation.

Dynamics of Status Code

The statusCode of the ConditionManagement (or BeingConcerned) Act is naturally:

active - for active conditions and completed - for resolved conditions.

This is the response to the MnM meeting which raised the same concern that an Act statusCode of a specialization of Observation was redefined to work differently than the statusCode of the Observation itself.

Observation statusCode means: complete when the observation is complete. However, even though I completed the observation that you have a fever, that doesn't complete your fever nor does it complete my being concerned about and trying to help your fever.

Thus, the "BeingConcerned" act is the right response to the issue raised at MnM.

Mechanics of Linking

I am not proposing anything new, instead I am proposing that we use existing RIM machinery to powerfully and meaningfully manage conditions, which I propose we understand actively as the Act of BeingConcerned. This is important to respond to the issue that we may not actually manage a condition ourselves, but yet we can still track it as a problem which I or my patient is concerned about.

The updating mechanics would work just like for any other Act, i.e., you use replace (RPLC) relationship from new act (source) to old act (target) with the old act becoming obsolete and the new act becoming active to take over the meaning of the old act.

This allows the splits and joins just fine as has often been discussed. And it doesn't invent any feature which don't already exist in our repertoir of well-understood constructs.

If we want to link a treatment action with the ConditionManagement (or BeingConcerned) Act, as Larry Weed says we should, we can think of it in one of two ways:

  • 1st way: a treatment (target) is a component of the ConditionManagement (or BeingConcerned) (source).
  • 2nd way: a treatment (source) has reason which is a ConditionManagement (or BeingConcerned) (target), or, if all we have is an Observation it could also be just the Observation which might also be the the subject of the BeingConcerned act.

The 2nd way is supperior because of our USAM rule of attribution of relationships. The outgoing relationships are attributed to the author of an Act. With Reason, it allows someone else to address your problems with their actions. With component it allows only you to address the problems you manage. You could refer to other acts as fulfilling what you would do, but it would be you who decides whether something addresses the concern that you manage or not.

The latter is the only open end to be worked out. The rest is simple to understand and easy to implement.

Summary of Detail

It then requires only 3 main acts in your model, which I propose you split into two topics:

CareProvision Topic

  • the CareProvision
  • the Observation (which is the reason for care provision)

I am not really worried about that part of the ballot.

Condition Tracking Topic: ConditionManagement or BeingConcerned Act

For a condition tracking topic (would make it a separate topic in the ballot) you would have two acts:

  • ConditionManagement (or BeingConcerned) Act, and
  • WorkingList for the problem list (nothing new or contentious here,
 WorkingList -hasComponent[priorityNumber]-> BeingConcernedAct.

The ConditionManagement or BeingConcerned Act has the following properties from the RIM which we should point out in the ballot:

Attributes

  • moodCode - EVN (fixed)
  • classCode - something darn similar to "issue" but for now can use CNOD (as that already exists) just needs to be revised in its definition.
  • code - start with a domain which only includes the same concept as the class code.
  • statusCode - with normal meaning of HL7 ActStatus codes
    • new - draft (not messaged, we use these internally tho)
    • active - currently being concerned
    • completed - resolved concern
    • aborted - a concern which we decide to drop without resolution
    • suspended - a concern which is active but we are setting it aside
    • nullified - a concern which was created in error
    • obsolete - a concern which has been replaced by another concern
  • effectiveTime - the time at which we are effectively concerned. It is an open ended (left) interval starting with the first moment which this was a concern (even if an earlier concern act covers this time already). It ends when the concern is completed.
  • text - for free text describing the concern as a whole.

ActRelationships:

Outbound Relationships
  • subject (SUBJ) - the ClinicalStatement which is the subject of our concern (usually an observation representing a diagnosis of chief complaint.) A single ConditionManagement (or BeingConcerned) Act has generally one subject of concern. If multiple subjects exist, then this is to indicate that all the subjects together are the subject of concern (but not necessarily each subject alone, notice the similarity for the Issue act in SPL to convey drug-drug-interactions.) The subject of the BeingConcerned act has in the past been called the "name" of the condition. When a new name is associated, a new BeingConcerned act is usually created and linked to the old (obsolete) act using the RPLC relationship.
  • replaces (RPLC) - an earlier version of the ConditionManagement (or BeingConcerned) Act. That previous version is in status obsolete while the new version takes over. This is used particularly when associating a different subject (or "name" of the condition). Notice that one ConditionManagement (or BeingConcerned) Act can replace multiple predecessors, which means that two concerns join into one. On the other hand, one two concerns can have the same precdecessor, which means that what was believed to be one problem is now understood as two (split).
  •  ??? - one relatiohship from the SEQL family but with a meaning different from RPLC would be defined to allow a concern to be linked with a previous similar concern. This would allow to speak of recurrent episodes of condition. (There may already be suitable relationship types defined, such as "previous instance"?)
  • component (COMP) - acts which we do while being concerned or sub-concerns. It would seem possible to divide a concern into sub-concerns. Other health care acts could also be components if we consider them to be done as part of our being concerned with the subject. Outbound relationships are attributed to the author of the source act, which means the COMP relationship is suited to bind acts addressing the concern from the perspective of the author of the concern.

Note: other relationships such as "supported by" are not needed because what is supported are conclusions, diagnoses, which are still Observations. Conditions are Concerns and need no conclusion or justification other than a valid subject.

Inbound Relationships
  • reason (RSON) - acts which are motivated by the concern which someone has. (As a finer point, notice that the rules of attribution allow someone else (e.g., me) to do health care actions addressing your concerns, even though you might not agree that what I am doing is right.)

Participations

These are standard HL7 RIM participations, nothing special:

  • performer - the one who is concerned
  • author - the one who voices the concern (usually == performer)
  • subject - the subject entity of concern (patient)
  • recordTarget - the role in which record we keep the concern (patient)