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.
2. Assume that observations are associated with encounters; associations with concerns, conditions, or plans are secondary
   1. Yes
3. 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].

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 should have a single focal concern, but it may have other related concerns. How do we define the relationship--as cause?
2. What are the relationships allowed between related HealthConcerns?
   1. Cause? Sequel? Complication? Risk?
3. Do HealthConcern properties differ from their "CurrentName" condition properties (start date, end date, prognosis, chronicity, status)?
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?
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. Yes for now
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
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
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
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?
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
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
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
44. Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship
45. Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship
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
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
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