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

Health Concern DAM Questions

From HL7Wiki
Revision as of 18:02, 10 July 2014 by Jlyle (talk | contribs)
Jump to navigation Jump to search

Back to Health Concern

Health Concern DAM Questions


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