Health Concern Questions

Back to Health Concern

Question	Answer
1 what kinds of concern relationship are there?	Causes? System? Subordinate/Sequel?
2 must a concern have a focal concern?	Assuming yes. Does it have to be an Assessment, or could it just be a text tag?
3 must a care plan have a focal concern.	Not sure it matters.
4 must a concern current name (focal concern) be an assessment.	Yes for now
5 when a clinician "tracks" a concern, what does he or she do?	Is it just a grouping mechanism to filter long lists of facts, or are there other activities?
6 A concern may include findings and interventions. May it include goals? If so, does it not look a lot like a plan?
7 do we have values in mind for "chronicity" and "prognosis"?	FHIM suggests "chronic, acute, congenital, subacute" after IMHC researched value set
8 Do we need to keep track of patient and family awareness of criticality and prognosis here?
9 Does Intervention need Device?	working assumption: no
10 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?
11 These may already be in the scenarios, but I want to make sure we have them: a. need examples of concerns that are conditions (strep throat, chronic obstructive pulmonary disorder, diabetes) b. need examples of concerns that are risks (BRCA-1-identified risk of cancer; functional deficit risk of fall?) c. need examples of concerns that are issues (?) d. need examples of concerns that are goals (?)
12 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.
13 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.
14 Mind map: Goals seem to be part of Plan as well.
15 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)
16 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.
17 Sciatica illustration: Is the initially created concern "sciatica"?
18 Sciatica illustration: What is Mx?
19 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.)
20 Sciatica illustration: Is the concern renamed "Herniated IVD," or is that simply recorded as a cause of the concern of "sciatica"?
21 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)
22 Can we change "observation" to "finding," since it's not just observations?	Working assumption: yes
23 "Clarification": This should be called something like "Focal scenario" or "baseline use case"
24 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?
25 Analogy: I’m not sure this helps. It others are, it may simple belong in the introductory text.
26 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.
27 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.
28 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.
29 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?)
30 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.
31 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?
32 Scenario 2 - adverse drug event: Figure 8 is two views of an unspecified Gantt chart. It could mean literally anything.
33 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.
34 Scenario 3 - cancer concern: The Venn is clearer here, but still very difficult to pull of neatly.
35 Scenario 4 - multiple concerns: I recommend using HL7 names where possible. These shade off into the patronizing.
36 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.
37 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?
38 It's not clear what scenarios 7 & 8 are intended to contribute
39 Scenario 9 - no Concern required: ok, but perhaps a nod to scenario 5 -- there may be concerns to manage anyway
40 It's not clear what scenarios 10 & 11 are intended to contribute
41 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.
42 Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship?
43 Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship?
44 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.
45 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, 23
46 I think the scenarios should all follow a common format, so readers don’t have to work too hard to compare them.
47 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.
48 Draft class diagram: Why do we need both a Concern class and a concern flag? They seem to do the same thing.