Clin Health Issue

Jim Busser's draft notes (developed in part from thread here with a further update here)

• at the top level of the clinical construct*, we have a clin_health_issue (e.g. diabetes mellitus) although we may not know, or decide, until later that this is the root cause of a complaint or abnormality (e.g. abnormal weight loss) and in the meantime the complaint or abnormailty can just be linked to an episode.
  *As opposed to the top level of the schema, where we have clin_root_item
• clin_health_issues could be named with prepending numbers to permit their presentation (i.e. grouping and sorting) to convey relationships (The schema at present does not manage relationships among issues.)
• in a view, the list of issues could be filtered to remove from view any which did not have a clin_narr row related to a clin_diag row marked is_significant
• an original need for the issue "xxxDEFAULTxxx" has been deprecated
• a health issue need not necessarily have an episode - this allows us to enter "proven" diagnoses from the past history as "problems" or IOW as health issues
• to each clin_health_issue can be attached one or more health episodes
  • an episode only becomes meaningful ("constituted") upon creation / attachment of at least one encounter
    • one encounter may fully define an episode, or there may be more encounters before the episode "closes" (! is_active) - i.e. an episode may span multiple encounters
    • deciding to which episode to assign an encounter may have to be postponed until the relationship becomes clear, which is why encounters can default attachment to a "xxxDEFAULTxxx" episode, within a "xxxDEFAULTxxx" clin_health_issue
    • it has been suggested / proposed that the problem list be drawn from the episode names rather than from the health issue names. The latter would turn up mainly when adding episodes to health issues. Front desk staff would attach encounters to episodes, not health issues.
    • repeat episodes could have their name (description) preserved unchanged, or could evolve to reflect a bit of status information such as DM, diet-ctrld --> DM, on oral Rx --> DM, on insulin
  • an episode must not necessarily be linked to a health issue - when the link is NULL this means it isn't decided yet whether that episode of, say, cough is related to any problem (health issue)
  • When encountering a new problem it should be stored as a new episode - unless immediately recognized as belonging to an existing health issue. Later on, when an episode is recognized to be a problem that will cause several episodes it might get promoted to become a clin_health_issue.
• The "problem list" is a view over issues and episodes selectable by is_active and (via linked clin_diag) clinically_relevant.

An email concerning how postgres inheritance is handled for these tables, and the related class cClinRecord, is archived here

> Various clinical narrative entries will have permitted
> diagnoses to be coded in clin_diag. The sort order of whatever is the
> coding system might go part way toward a sort order that puts
> clinically-related items closer together in a list.

> If the health_issue is kept general (diabetes mellitus), it is still
> possible to accumulate a new coded diagnosis with each SOAP note. Since
> each of these clin_diag records could be related back to that one
> general health_issue it could be tidy to express (nest) the accumulated
> diagnoses underneath the general health issue.
Yes. Or the "episode names" which would be drawn from soAp/AOE/diagnoses.

> This is harder to do if
> the diagnoses are distributed across multiple health issues when each
> just reflects various dimensions of a chronic disease.
That would mean the treating doc hasn't yet realized they are dimensions of a chronic issue due to lack of data, lack of insight - or she has done so on purpose.

-- JamesBusser