Discussion on Condition Tracking
Contents
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)
--DanR 15:26, 25 Jun 2006 (CDT)
As a preface to discussion on next PC call, I've added a page with some requirements :
Requirement to message Problem Structures as found in UK clinical systems - Rik 15:13, 26 Jun 2006 (BST)
PCTC met on June 28 and progressed through the second phase of revoting. The status after stage two of voting follows:
Consolidated Condition Tracking Structure Proposal (Revised):
Note: This updated document reflects PCTC voting on changes to the May, 2006 Condition Tracking Structure that has occurred up until 6-28-06:
Format: 1) Condition Tracking Structure Change Log 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) Change Log and Open Issues:
a) Changed the current “=COND” to “<=OBS” in all the Care Provision DMIM’s and RMIM’s including the Condition Tracking Structure.
b) Will recommend deprecating CNOD and COND to M&M.
c) Create a new RIM class called “Concern” (CONC) that clarifies the definition by beginning with “Being Concerned or worried about states and processes that have the potential to require management and ...” “The definition needs to be changed to clear English, and explanation of modeling relationships needs to be included.”
In the meantime, until M&M tooling is updated, R-MIM’s will be changed to ACT with a note in the RMIM’s and ballot documents that describes the intention to change to CONC.
d) Change the CNOD class in the current Condition Tracking Structure to ACT with the associated note on changing ACT to CONC when passed by harmonization
e) Change the entry point to the Condition Tracking Structure from the old COND class to the new CONC (ACT) class
f) Add attributes effectiveTime, statusCode, confidentialityCode to the new CONC class
g) Change the the current NAME ActRelationship to SUBJ ActRelationship with a multiplicity of 1…*
h) Add the attribute priorityNumber to the SUBJ ActRelationship
f) Loosen the current clone NamingObservation from Observation to a Care Statement Choice Box which has been constrained to remove Act, Supply, and Encounter classes
2) Proposed XML Instance in EVN Mood (expanded from Lloyd’s XML proposal):
<concern classCode="CONC" typeCode="EVN">
<id root='6a2fa88d-4174-4909-aece-db44b60a3aba'/>
<effectiveTime>
<low value="date started tracking"/>
</effectiveTime>
<statusCode code="active"/>
<confidentialityCode code="N"/>
<subjectOfConcern typeCode="SUBJ">
<subjectClass classCode="OBS" moodCode="EVN">
<!—All the normal attributes and associations of an observation, procedure, or substance administration in care statement -->
<id root="6a2fa88d-4174-4909-aece-db44b60a3abb"/>
<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>
</subjectClass>
</subjectOfConcern>
<hasSupportingInfo typeCode="SPRT">
<!-- Put your clinical statements here -->
</hasSupportingInfo>
<replaces typeCode="RPLC">
<concern classCode="CONC" moodCode="EVN">
<id root='6a2fa88d-4174-4909-aece-db44b60a3abc'/>
<!—obsoleted previous version goes here -->
</concern>
</replaces>
<links typeCode="ELNK">
<concern classCode="CONC" moodCode="EVN">
<id root='6a2fa88d-4174-4909-aece-db44b60a3abd'/>
<!—NON-obsoleted previous version goes here -->
</concern>
</links>
<subjectOf typeCode="SUBJ">
<controlAct typeCode="CACT" moodCode="EVN">
<id root='6a2fa88d-4174-4909-aece-db44b60a3abe'/>
<code code="trigger event"/>
<effectiveTime value="when it changed"/>
<reasonCode code="reason for change"/>
</controlAct>
</subjectOf>
</concern>
3) Formal Walk-throughs:
| Attribute | Constraint | Constrained Attribute Description |
|---|---|---|
| classCode | Immutable: Yes
Optionality: B* (1…1) Datatype: CS Vocabulary Domain: CNE =CONC |
A mandatory attribute constrained to Concern (CONC), which is a subclass of Act. The definition of this class describes the “Being concerned or worried about a ….” (remaining definition to be crafted). |
| moodCode | Immutable: Yes
Optionality: B* (1…1) Datatype: CS Vocabulary Domain: CNE =ActMood |
A mandatory attribute which is constrained to the values in the ActMood vocabulary domain. Normally, this will be constrained to EVN in many derived RMIM’s, HMD’s, and implementation guides. |
| id | Immutable: No
Optionality: (0…1) Datatype: SET<ii> Vocabulary Domain: Not Applicable |
An optional attribute; multiple id’s may be present. Updates may add id’s to the set, but may not change an id. This attribute should be constrained to be present in most implementation guides. |
| statusCode | Immutable: No
Optionality: *(1…1) Datatype: CS Vocabulary Domain: CNE <= ActStatusCode |
A required attribute that shall be present and shall be valued with a NullFlavor or with members of a value set bound to the Vocabulary Domain “ActStatusCode.” This attribute is used to define whether the concern of a performer is:
• new - draft version • 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 Updates in the value of the attribute are allowed. |
| effectiveTime | Immutable: No
Optionality: *(0…1) Datatype: IVL<GTS> Vocabulary Domain: Not Applicable |
A required attribute constrained to the time range the concern of the author/performer was active or suspended is or was present. If still present at time of update, only the low value in the time range is expressed. |
| confidentialityCode | Immutable: No
Optionality: (0…1) Datatype: CV Vocabulary Domain: CNE <= Confidentiality |
An optional attribute that, if present, shall be valued with NullFlavor or members of a value set bound to the Vocabulary Domain “Confidentiality.” Updates in the value of the attribute are allowed. |
| Attribute | Constraint | Constrained Attribute Description |
|---|---|---|
| typeCode | Immutable: Yes
Optionality: B* (1…1) Datatype: CS Vocabulary Domain: CNE = SUBJ |
A mandatory attribute constrained to SUBJ, which is a type of ActRelationship. This ActRelationship is used to identify the subjects of the Concern. Since a Concern may have many equally valid subjects, this relationship may be repeated as needed unless the multiplicity is constrained in an implementation guide. |
| contextControlCode | Immutable: No
Optionality: * (1…1) Datatype: CS Vocabulary Domain: CNE <= AN |
A required attribute that shall be present and shall be valued with NullFlavor or AN. This attribute determines how the context, e.g. author; subject, can be propogated to the target Act from the source Act. Updates in the value of the attribute are allowed. |
| contextConductionInd | Immutable: No
Optionality: B*(1…1) Datatype: BL Vocabulary Domain: Not Applicable |
A mandatory attribute that shall be valued with a Boolean. This attribute indicates whether context, e.g. author; subject, is propogated from the source Act “Concern” to the target Act “SubjectClass” in this model. |
| priorityNumber | Immutable: No
Optionality:(0…1) Datatype: INT Vocabulary Domain: Not Applicable |
An optional attribute that shall be valued with an integer. The attribute is only present in implementation guides that allow more than one SubjectClass. The attribute is to be interpreted to represent the order of display to the human viewer of the target SubjectClass when more than one SubjectClass is associated with the Concern Class. |
| Attribute | Constraint | Constrained Attribute Description |
|---|---|---|
| ALL | NA | The SubjectClass is a Care Statement Choice Box constrained to NOT include Supply, Act, or Encounter classes. |
No time left for reformatting these tables on the wiki. See the document version from the list server for further formal walk-through.
--DanR 20:28, 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.
| 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
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.
--DanR 12:56, 26 May 2006 (CDT)
| Current | Gunther | Lloyd | Rik | |
|---|---|---|---|---|
| Definition./Require. | An instance of Observation of a Condition at a point in time that includes any Observations or Procedures associated with that Condition as well as links to previous instances of Condition Node for the same Condition | an Act which is the Act of bothering or worrying or of being concerned about something | An Observation with code "Problem" that persists over time and can be updated as needed | An abstract placeholder observation/grouper, having the effectiveTime (and so status) of the problem as whole. It represents the "problem list" entry, off which hang links to the problem's associate statements, one of which is a link to the name. |
| classCode | <=CNOD | "Condition-Management or Being-Concerned Act" | =OBS | =OBS |
Modeling Challenge Questions:
Given that there is an Act with six attributes, "classCode," "moodCode," "code," "statusCode," "effectiveTime," and "activityTime," is there:
1) Any argument for using another existing classCode besides ACT, e.g. OBS(Observation); MPROT(Monitoring Program); ect?
2) Any argument for creating another Act and/or Act definition, e.g. Concern Act or CNOD definition?
--DanR 12:56, 26 May 2006 (CDT)
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.
--DanR 20:28, 26 May 2006 (CDT)
| Current | Gunther | Lloyd | Rik | |
|---|---|---|---|---|
| Discussions | statusCode 0…1 <=ActStatus (completed or nullified) | statusCode - with normal meaning of HL7 ActStatus codes: new - draft (not messaged, we use these internally tho); actively - 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. | statusCode--"active" was illustrated. However, "clinical status" of "resolved" was specifically recorded as a separate observation...clinical status and effectiveTime are tightly tied. When
effectiveTime.high is specified, the clinical status should be "complete/resolved". However, sometimes I know that the status is"complete/resolved", but don't necessarily know the date when that happened. |
It would be nice to use act.statusCode of the abstract problem act to say if it's an active or inactive problem (still with no indication of whether the underlying condition, if any, is active). That isn't what act.statusCode for an OBS is for however, so we use effectiveTime for this....- a Problem can be active or inactive...- Being on the Problem list doesn't necessarily imply that management or active monitoring is needed, although it often will. - The status of the Problem doesn't necessarily imply that the underlying condition, if any, has the same status, although it would normally reflect that |
Modeling Challenge Questions:
Given that there is an Act with six attributes, "classCode," "moodCode," "code," "statusCode," "effectiveTime," and "activityTime," is there:
1) Any argument for constraining statusCode to fewer values than are present in the state transition diagram for ACT?
--DanR 20:28, 26 May 2006 (CDT)
Lloyd: According to MnM, "Condition/Observation/whatever".statusCode refers to the status of the observation/monitoring/being concerned. It does not refer to the actual status of the condition. For example, the clinical status of a pregnancy might be "resolved", but that pregnancy condition may still be something worth monitoring/being concerned about from a post-partum care perspective. Also, the effectiveTime of the pregnancy could be quite different from the activity time of the monitoring/being concerned. We will need a new place to capture the underlying clinical status of the actual condition, independent from the status of the "monitoring" of that condition.
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,r 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.
--DanR 20:28, 26 May 2006 (CDT)
| Current | Gunther | Lloyd | Rik | |
|---|---|---|---|---|
| Discussions | ELNK (doesn't obsolete target) | RPLC (obsoletes target) or SEQL (doesn't obsolete target) | RPLC (obsoletes target) | RPLC (obsoletes target). |
<Rik> (It's a bit confusing whether the above relates to linking or updating, I assume the latter. Maybe these should be separate headings, or the linking section (SPRT/COMP) moved above the updating bit (ELNK/RPLC)) </Rik>
<Rik> I've said RPLC above, but this raises a bigger issue for me. A mechanism is needed to allow partial restatement of the updated problem list, for use when a shared problem list is being contributed to.
I don't want to have to send the whole problem list each time I change an attribute in the problem Act. Many of the statements in the problem list will not have been authored by me originally, so I don't wish to restate them. If I replace (RPLC) the Condition/Concern Act with another (maybe to change the effectiveDate), that replacement act must also be linked to all the old supporting acts, otherwise they will appear to have been sliced off. So the entire condition chain must be restated. If want to add a new statement in SPRT of the main Concern is there a way to do this without restating the whole set of acts ?
If I have Concern Con1 connected to Obs1 and Obs2 and I wish to assert Obs3 is also connected, do I need to send Con1 connected to Obs1, Obs2 and Obs3 ? If I just send Con1 and Obs3 it will appear that Obs1 and Obs2 aren't there any more.
A possible way around this is to allow SPRT relationships to be connected as ActRefs to the Concern. eg I just send Obs3-actRef->Con1.id
The actRef would have a typeCode the same as the equivalent actRelationship it stands in for (eg SPRT), and would be "inverted" so that the relationship worked the right way.
</Rik>
Modeling Challenge Questions:
Given that there is an Act with six attributes, "classCode," "moodCode," "code," "statusCode," "effectiveTime," and "activityTime," is there:
1) Any argument for using any ActRelationships except for APND (when not obsoleting target) and RPLC (when obsoleting target)?
--DanR 20:28, 26 May 2006 (CDT)
Lloyd: Yes. I don't want to use "APND" when I'm creating a new version but not obsoleting the condition. We added a new code in harmonization to deal with this. I just don't remember what it was called off the top of my head.
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).
--DanR 21:16, 27 May 2006 (CDT)
| Current | Gunther | Lloyd | Rik | |
|---|---|---|---|---|
| Discussions | SPRT | COMP | SPRT | The link is represented as an OBS act in its own right, having a representative act.code eg "has problem member", or "has problem name". This "Statement Relationship" observation has two act references attached, one pointing to the problem, one to the member. |
Modeling Challenge Questions:
Given that there is an Act with six attributes, "classCode," "moodCode," "code," "statusCode," "effectiveTime," and "activityTime," is there:
1) Any argument for using COMP over SPRT for the general association of clinical statement acts to the "Worry or BeingConcerned" Act?
Lloyd: I don't like "COMP" as a general thing, though it could be appropriate in limited circumstances. Component says "This act occurred as part of this bigger act", and in the case of an adverse reaction observation that eventually leads to a concern representing an allergy, that's not the case. The concern representing the allergy did not exist at the time the adverse reaction was observered. The reaction observation however may support the assertion and understanding of the allergy however.
2) Any argument for using more than one ActRelationship for this general association?
--DanR 21:16, 27 May 2006 (CDT)
- 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.
--DanR 21:16, 27 May 2006 (CDT)
| Current | Gunther | Lloyd | Rik | |
|---|---|---|---|---|
| Discussions | hasReason ActRelationships in DMIM and RMIMs point to OBS instead of CNOD | a treatment (source) has reason which is a ConditionManagement (or BeingConcerned) (target) | not discussed | not discussed |
Modeling Challenge Questions:
Given that there is an Act with six attributes, "classCode," "moodCode," "code," "statusCode," "effectiveTime," and "activityTime," is there:
1) Any argument for pointing the hasReason ActRelationship from a Clinical Statement Act to other ACTS besides the BeingConcerned Act?
Lloyd: Definitely. You don't have to capture something as a "condition" for it to be a reason for an action. I can have reasons such as surgery preparation, prophylaxis, etc. and not have an associated condition (and it makes no sense to capture one because it's not something I'm wanting to track.)
--DanR 21:16, 27 May 2006 (CDT)
--DanR 21:16, 27 May 2006 (CDT)
| Current | Gunther | Lloyd | Rik | |
|---|---|---|---|---|
| Discussions | NAME | SUBJ - A Problem might have more than one name, e.g. patient's name; clinician's name; billing name. 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 | NAME | A Problem has a single name which can change over time. Problems have members, which are linked to and are part of the overall problem. Names and other members are clinical statements in their own right |
Modeling Challenge Questions:
Given that there is an Act with six attributes, "classCode," "moodCode," "code," "statusCode," "effectiveTime," and "activityTime," is there:
1) Any argument for using SUBJ over NAME for the ActRelationship that identifies the label the BeingConcerned Act is known by?
Lloyd: The subject of the condition/concern/monitoring is the patient. A diagnosis observation cannot be the subject of monitoring because a single diagnosis never changes. I think name remains appropriate if we insist on having the "what condition is this" separated from the "Act of being concerned about" the condition.
I'm concerned about the assertion that when the name changes, the old record must be obsoleted. I want to have a single "condition/concern/whatever" record for an allergy which retains the same id and remains active even if it shifts from "moderate intolerance" to "severe allergy".
2) Any argument for using both SUBJ and NAME as unique ActRelationships with different meanings?
3) Any restrictions on the types of Clinical Statements that might be the target of either SUBJ or NAME ActRelationships?
--DanR 21:16, 27 May 2006 (CDT)
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)
--DanR 21:53, 27 May 2006 (CDT) Modeling Challenge Questions:
Given that it seems possible to want to use DEF, INT(in Care Plans), RQO or other moods in the Business Cycle of BeingConcerned Acts, is there:
1) Any argument for constraining moodCode to EVN at the RMIM level (above the level of the HMD or implementation guide) for a specific message type?
2) Any argument for constraining moodCode from any mood in the moodCode value set?
--DanR 21:53, 27 May 2006 (CDT)
- 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.
--DanR 21:53, 27 May 2006 (CDT) Modeling Challenge Questions:
Given that effectiveTime usually refers to the "biologic time" in the subject, and therefore, this use of effectiveTime might be confusing (even though theoretically correct), is there:
1) Any argument for using effectiveTime rather than activityTime for the BeingConcerned Act?
2) Any argument for using both effectiveTime and activityTime?
Lloyd: What I need is the time the condition was effective. I.e. the patient became pregnant on date Jan. 1 and delivered their child on Sept. 7. This is completely separate from when the provider is "concerned" about the pregnancy, which may begin when the patient comes to see them on Feb 12th and the diagnose pregnancy and may not end until March of the following year after the patient's last pregnancy follow-up visit.
If we wish, we could say that the former is "EffectiveTime" and the latter is "ActivityTime". If we do something else, then we're going to need to find a way to handle the concepts above.
--DanR 21:53, 27 May 2006 (CDT) <Rik>The pregnancy and the concern about it are separate acts, linked in a condition tracking structure. The pregnancy (OBS) has an effective time of 9 months (Jan 1 to Sep 7). The Concern (COND) has a different effectiveTime Feb 12 til March next year. No need for activityTime.</Rik>
- text - for free text describing the concern as a whole.
--DanR 21:53, 27 May 2006 (CDT) Modeling Challenge Questions:
Given that currently, separate annotation acts are used to write comments, is there:
1) Any argument for NOT using the text attribute along with control acts to hold these comments?
Lloyd: Annotations are not ControlActs. Text is a description of the condition overall. Annotations are comments made by various providers over the lifetime of a record
2) Any argument for having both the text attribute and the separate annotation acts?
Lloyd: Canada definitely needs annotations. We will likely constrain out the text attribute if it is introduced at the international level. --DanR 21:53, 27 May 2006 (CDT)
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"?)
<Rik>Why not ELNK ?</Rik>
- 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.
<Rik> The above is a list of solutions to problems discussed higher up the page.
Thinking of the requirements, we may need :
1) a link from Concern to observation (or other act) (possibly SPRT or COMP, possibly (also) via an ActRef)
2) a link from Concern to the observation (generally) that is the main act of concern ie. the name (possibly NAME or SUBJ)
3) a way to supersede one Concern act with another (possibly RPLC)
4) a way to link Concern acts to each other without obsoleting the old one(possibly ELNK)
5) a way to nest Concern acts (possibly COMP, or just use 1 as above) </Rik>
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)
<Rik>What's the difference in Performer and Author above ? I wouldn't expect to see a Concern act performed, since its not a "service event".</Rik>
