Health Concern DAM Questions

Back to Health Concern

Health Concern DAM Questions

Settled

1. Is the indication of a Care Plan a Health Concern or a Condition?
   1. Concern. If a condition is of sufficient concern to merit a plan, it's a concern.

• The question is which. It is binary, either the Concern or the Condition is the indication.
• We will encounter issues either way, esp. if it is the Concern. We assume that a Concern is dynamic (not everyone agrees with this, BTW, and think that when there is a change in the Condition, you update the Concern with a new one), so this implies the underlying diagnosis could be changed.
• If we manage context conduction in detail in the logical (static) model, we can address this, but we need to be very careful.

--KevinCoonanMD (talk) 21:10, 10 July 2014 (UTC)

1. When specifying a concern, are we simply classifying a condition, or are we creating a new object?
   1. We are specifying a new object. Especially because the relationship could be 1:n between concerns and conditions.

• To be more specific: we create a new Health Concern instance, and we assign the identified Condition to it.
• We do not have a consensus on the cardinality between Concerns and Conditions.
  • The case for [1..n] is that you may have different people calling the same thing by different names, and we want to be able to aggregate like things.
  • The case for [1..1] is that you have clear semantics, and you avoid having one person call it CHF and another COPD when they cannot tell which is causing the dyspnea on exertion.
  • We still need further semantics and analysis to address this specific issue--i.e. how to link seemingly (at least from the EHR perspective) different signs, symptoms, and diagnosis to each other.
    • We will need semantics for the association, i.e. cause, result, synergy, etc.

--KevinCoonanMD (talk) 21:10, 10 July 2014 (UTC)

1. Are diagnosing as a condition, classifying as a concern, and assigning a (initially empty) plan each distinct actions to be taken by the caregiver?
   1. Yes. It could even be different roles and responsibilities, especially if there are multidisciplinary teams involved. In my example of Obesity the pain in the knee could diagnosed by the physiotherapist , but the overall Care plan is coordinated by a general practitioner.

1. Assume that observations are associated with encounters; associations with concerns, conditions, or plans are secondary
   1. Yes

• • NO! Encounters are associated with our (somewhat nebulous at this time) Care Provision Event. The Encounter is part of the Clinical Context for the Observations entered into the care record as Care Record Entry. The same is true with Concern, Conditions and Care Plans. They all need to be associated with Encounters, and they all end up in the EHRS via Care Record Entries.
    • The big distinction is that we are now specifying the logical associations which exist beyond the linear/document centric view of the Care Record.

--KevinCoonanMD (talk) 21:18, 10 July 2014 (UTC)

1. Does "intervention" belong in the Health Concern domain?
   1. Yes. There is a consideration of overlap with Care Plan, but [not sure I followed the rationale for this].

• • Intervention is part of a Care Plan. Every Health Concern requires at least one Care Plan which describes what is being done to monitor the Care Plan.
    • See above comment--does this attach to the Health Concern or the Condition???
    • Along a similar line, it is the Condition which "owns" the Goal. Care Plans will reference and use it, but it really belongs (at least in the RIM!) to the Health Concern, as it is a statement of how life should be if the Condition could be resolved.
    • The Care Plan will have Objectives which work like goals, but are specific criterion.

--KevinCoonanMD (talk) 21:18, 10 July 2014 (UTC)

Not Settled

1. What is the cardinality of the association between Condition and HealthConcern?
   1. A condition may serve as the focus of a concern, or it may not. 0:1 on this end.
   2. A concern could lead to multiple conditions. For example Obesity could lead to Diabetes, Bad Eysight, hypertension etc.
   3. But, can a Condition be part of >1 Concern? If we allow for >1 Condition to name as Concern, we likely need to do this.
      1. A concern is basically a tag. So I think it has to be *:* -JL
   4. A concern should have a single focal concern, but it may have other related concerns. How do we define the relationship--as cause?
      1. See enumeration of relationship kinds. Needs attention. -JL
2. What are the relationships allowed between related HealthConcerns?
   1. Cause? Sequel? Complication? Risk?
      1. A concern could well be the cause of another concern. (cause)
      2. A concern could also evolve into another concern ( sequel)
      3. I don't think risk belongs in this list.
         1. Yes. Also "Manifestation". These are easy. The hard ones are where you cannot figure out which Condition some signs/symptom/diagnosis/problem belongs to.
3. Do HealthConcern properties differ from their "CurrentName" condition properties (start date, end date, prognosis, chronicity, status)?
   1. assuming no. -JL
4. must a concern have a focal concern?
   1. Assuming yes. Does it have to be an Assessment, or could it just be a text tag?
   2. We have not used the word focal concern before. Rather we have the definitions health concerns versus problem concerns.
      1. I mean the condition that names the concern. And I don't understand the distinction between health concerns and problem concerns--or, I kind of do, but if so I think it's irrelevant.
5. must a care plan have a focal concern.
   1. Not sure it matters.
6. must a concern current name (focal concern) be an assessment.
   1. No. could be a complaint, observation, or assessment (condition or risk).
7. when a clinician "tracks" a concern, what does he or she do?
   1. Is it just a grouping mechanism to filter long lists of facts, or are there other activities?
8. A concern may include findings and interventions. May it include goals? If so, does it not look a lot like a plan
   1. And should it even contain interventions? What happens to those interventions when the concern is incorporated into a plan?
9. do we have values in mind for "chronicity" and "prognosis"
   1. FHIM suggests "chronic, acute, congenital, subacute" after IMHC researched value set
10. Do we need to keep track of patient and family awareness of criticality and prognosis here
11. Does Intervention need Device
    1. working assumption: no
12. Intervention works to capture time and place information for procedures and observations, but the name doesn't really fit for assessments. Is there a more general term we could use? Or do we need to split assessments (& complaints) out
13. These may already be in the scenarios, but I want to make sure we have them:
14. Mind map: Confirm: I think we determined that the "Health Concern Thread" groups many "Health Concern Events." This means a) that the two bubbles at the top are actually one bubble, and b) that the relationships radiating out from the "Health Concern Event" are actually "is-a" relationships, not "has-a" relationships
15. Mind map: "Monitoring Plan" seems to be part of Care Plan, not Concern. We may need to show it in a picture in order to clarify that it is out of scope and suggest the relationship
16. Mind map: Goals seem to be part of Plan as well
17. Mind map: Monitor Risk: the verb "monitor" raises the question of whether the Concern is simply a grouping of information related to a concern or it has some kind of functional profile as well. What actions take place when something is monitored? Are there scheduled events or reminders? Are other parts of the health record automatically scanned for relevant information? I have the same question for the verb "track": what does it look like? (See #5
18. The distinction between the "clinical perspective" and the "information engineering perspective" is not clear: the text for each seems to be talking about the same thing. To the extent that the terms imply a difference, the "information engineering perspective" is out of scope for a Domain Analysis Model
19. Sciatica illustration: Is the initially created concern "sciatica"
20. Sciatica illustration: What is Mx
21. Sciatica illustration: Isn't "reassess 6 months" a Plan item rather than a concern item? (We can still represent it, as something needed from the Plan domain.
22. Sciatica illustration: Is the concern renamed "Herniated IVD," or is that simply recorded as a cause of the concern of "sciatica"
23. Sciatica illustration: What does "monitor" mean? Check on this whenever the patient shows up for an encounter? Check on this after N days? Continually assess the record for any potentially relevant entries? (See #5, 15
24. Can we change "observation" to "finding," since it's not just observations
    1. Working assumption: yes
25. "Clarification": This should be called something like "Focal scenario" or "baseline use case
26. Focal scenario, back to PCP. This reads like reconciliation. A key requirement here is to merge things that are the same. We do have a "replace" use case in the model: is this enough? Is there provenance data we need to have to make sure this can be done accurately
27. Analogy: I’m not sure this helps. It others are, it may simple belong in the introductory text
28. C-CDA: this should be an appendix. I like that tabular format: it prevents us from wandering too far off topic. The words here are a necessary analytical step to get to the table, but they don't need to be in the final product
29. Scenario 1 - abdominal pain: If the graphics reflect a requirement that's not in our model, we should put it in the model. Does that flavor of root-cause analysis have a name or a standard? Do our SOAP classes cover what we need? If not, I find the graphics distracting and confusing. If the point is that Concern management is iterative, I think that comes through without the pictures
    1. the graphics are to reflect the SOAP flow of the patient at the various institutions. The patient undergoes this flow several times, because each care provider repeats the acts of hypothesis, analysis and so on. The care provider could relate to an observations from a previous care provider.
30. Scenario 1 - abdominal pain: The Venn diagram classifies items by source rather than concern, which is a bit confusing but I think is meant to suggest that some concern items are shared and others are not. But it doesn’t show any overlaps. It's difficult to show individuals in a Venn anyway; perhaps a cross-table might do this more clearly
    1. It happens to be by source, but actually it is grouped by the diagnosis by each separate institutions/care provider. Each physician comes up with a different conclusion. These problem concerns are grouped by the larger cloud of the health concern, which is the abdominal pain. It overlaps where the referral information is shared by the institutions.
31. Scenario 1 - abdominal pain: The Venn diagram also asserts a distinction between a Health Concern and a Problem Concern that we have not made. Should we?  What's the requirement for doing so, and the criterion to define it? (Jumping ahead to the mastectomy example, I think that career interruption is definitely something that is a concern to the patient that should be noted in the record, but I don't think it should be possible to make that a focal concern--it's relevant to the management of a medical concern. Is that our distinction?
    1. The distinction between problem concerns and health concerns has been taken over from the CCDA-input. There they defined the health concern as the major concern, while problem concerns could be a manifestation of a smaller part of the problem. It is obviously related, but in the discussion it was clear that we could not draw the lines in the boundaries where health concerns cease to exist and where problem concerns start.
32. Scenario 2 - adverse drug event: This is a use case for Drug Interaction Check, an important case, but it's not clear what Concern has to do with it. You could manage this by asserting that clinicians remember to create Concerns for every allergy (or prescription), but that seems both unnecessary and inelegant. If we use this case, I'd recommend using it to stipulate that this is out of scope
33. Scenario 2 - adverse drug event: The concern list and Venn don't quite match up, but they do suggest that a concern may be a part of another concern--i.e., not only can we attach the assessment of low blood pressure to the concern of Cardiovascular disease, but that low blood pressure could itself be a concern. We need to clarify that possibility. It seems that the point of the concern construct is to filter out irrelevant information: is it then possible to consider low blood pressure outside the context of the system of cardiovascular functions and disorders that have been observed? If we allow this sort of thing, can we articulate some criteria for when it's appropriate and when it's not? Is the Concern grouper just a tag, or does it imply a kind of EHR ontology that could relate any fact to any other
34. Scenario 2 - adverse drug event: Figure 8 is two views of an unspecified Gantt chart. It could mean literally anything
35. Scenario 3 - cancer concern: The point of this seems to be how to use a concern in a plan--most of the narrative seems to involve planning and executing to plan. It's important, but I think it's also important to keep that scoping fact in clear view of the reader
    1. The issue here in the concern for cancer is how to relate to an observation of another patient. In this Angelina's mother who also had breast cancer.
36. Scenario 3 - cancer concern: The Venn is clearer here, but still very difficult to pull of neatly
37. Scenario 4 - multiple concerns: I recommend using HL7 names where possible. These shade off into the patronizing
    1. This story has been removed.
38. Scenario 5 - advance planning: See question 31 & 32. These are advance directives, and there is already a function envisioned, designed, and implemented to take care of it. It may not always be done well, but designing another way to do it won't help
39. Scenario 6 - conflicting interventions: Is the point that the "Concern" information architecture would make it easier for the cardiologist (currenty digging through labs and meds on different screens) to notice the patient's preference
40. It's not clear what scenarios 7 & 8 are intended to contribut
41. Scenario 9 - no Concern required: ok, but perhaps a nod to scenario 5 -- there may be concerns to manage anywa
42. It's not clear what scenarios 10 & 11 are intended to contribut
43. Scenario 12 - avoidable stay: I'm not sure what the purpose of this one is, either. However, I do notice that the general concern might be something like functional deficit, resulting in risk of falls. This raises the question of whether we can state rules or guidelines for when a concern should be recognized
    1. this story has been removed
44. Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship
    1. this story has been removed
45. Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship
    1. this story has been removed.
46. Scenario 13/14 - structured approach: The fact that the gastritis might be linked but is instead a new concern suggests that those cases (making it a concern or making it part of another concern) are exclusive, contrary to observation in question 22 above
    1. It may well be under debate whether it is exclusive, but that is the way it works now.
47. Scenario 13/14 - structured approach: Attention flag is the first concrete example I've seen of what has been called "tracking." Is this it? See question # 15, 21, 2
    1. No. The attention flag is an artificial way of the GP's to make a concern, which has been completed, a permanent warning flag. For example: the patient might have had a cancer treatment and it may be called cured, but even then you want to be reminded later on that the patient has had this cancer treatment 2 years ago.
48. I think the scenarios should all follow a common format, so readers don’t have to work too hard to compare them
49. How do we address the fact that you can implement this at different levels of granularity or functionality? E.g., whether observations get automatically suggested for inclusion, or how much reconciliation can be proposed automatically; or how much ontological thought a given concern grouping implies
50. Draft class diagram: Why do we need both a Concern class and a concern flag? They seem to do the same thing