This wiki has undergone a migration to Confluence found Here
Health Concern DAM Questions
Back to Health Concern
Health Concern DAM Questions
Settled
- Is the indication of a Care Plan a Health Concern or a Condition?
- 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)
- When specifying a concern, are we simply classifying a condition, or are we creating a new object?
- 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)
- Are diagnosing as a condition, classifying as a concern, and assigning a (initially empty) plan each distinct actions to be taken by the caregiver?
- 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.
- Assume that observations are associated with encounters; associations with concerns, conditions, or plans are secondary
- 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.
- 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.
--KevinCoonanMD (talk) 21:18, 10 July 2014 (UTC)
- Does "intervention" belong in the Health Concern domain?
- 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.
- 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.
--KevinCoonanMD (talk) 21:18, 10 July 2014 (UTC)
Not Settled
- What is the cardinality of the association between Condition and HealthConcern?
- A condition may serve as the focus of a concern, or it may not. 0:1 on this end.
- A concern could lead to multiple conditions. For example Obesity could lead to Diabetes, Bad Eysight, hypertension etc.
- 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.
- A concern should have a single focal concern, but it may have other related concerns. How do we define the relationship--as cause?
- What are the relationships allowed between related HealthConcerns?
- Cause? Sequel? Complication? Risk?
- A concern could well be the cause of another concern. (cause)
- A concern could also evolve into another concern ( sequel)
- I don't think
- Yes. Also "Manifestation". These are easy. The hard ones are where you cannot figure out which Condition some signs/symptom/diagnosis/problem belongs to.
- Do HealthConcern properties differ from their "CurrentName" condition properties (start date, end date, prognosis, chronicity, status)?
- must a concern have a focal concern?
- Assuming yes. Does it have to be an Assessment, or could it just be a text tag?
- must a care plan have a focal concern.
- Not sure it matters.
- must a concern current name (focal concern) be an assessment.
- Yes for now
- 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?
- A concern may include findings and interventions. May it include goals? If so, does it not look a lot like a plan
- do we have values in mind for "chronicity" and "prognosis"
- FHIM suggests "chronic, acute, congenital, subacute" after IMHC researched value set
- Do we need to keep track of patient and family awareness of criticality and prognosis here
- Does Intervention need Device
- working assumption: no
- 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
- These may already be in the scenarios, but I want to make sure we have them:
- 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
- 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
- Mind map: Goals seem to be part of Plan as well
- 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
- 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
- Sciatica illustration: Is the initially created concern "sciatica"
- Sciatica illustration: What is Mx
- 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.
- Sciatica illustration: Is the concern renamed "Herniated IVD," or is that simply recorded as a cause of the concern of "sciatica"
- 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
- Can we change "observation" to "finding," since it's not just observations
- Working assumption: yes
- "Clarification": This should be called something like "Focal scenario" or "baseline use case
- 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
- Analogy: I’m not sure this helps. It others are, it may simple belong in the introductory text
- 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
- 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
- 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
- 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?
- 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
- 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
- Scenario 2 - adverse drug event: Figure 8 is two views of an unspecified Gantt chart. It could mean literally anything
- 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
- Scenario 3 - cancer concern: The Venn is clearer here, but still very difficult to pull of neatly
- Scenario 4 - multiple concerns: I recommend using HL7 names where possible. These shade off into the patronizing
- 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
- 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
- It's not clear what scenarios 7 & 8 are intended to contribut
- Scenario 9 - no Concern required: ok, but perhaps a nod to scenario 5 -- there may be concerns to manage anywa
- It's not clear what scenarios 10 & 11 are intended to contribut
- 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
- Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship
- Scenario 12 - avoidable stay: What does it mean to "link" the fracture concern to the osteoporosis concern? Is it causal relationship
- 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
- 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
- I think the scenarios should all follow a common format, so readers don’t have to work too hard to compare them
- 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
- Draft class diagram: Why do we need both a Concern class and a concern flag? They seem to do the same thing