On 2011-12-07, at 6:04 PM, Jim Busser wrote:
> Why can't documents be attached to health issues without having to be attached to an episode?
>
> If that cannot be sanely managed
The more I think about it, the more I question why it is *required* to have a constraint in which the episode cannot be null? What *clinical* difference does it make which episode(s) a document has been associated with? When considering the case of a patient
overall,
- the document will already be attached to the record via whatever was the associated encounter
- the document (for example, the consultation) often has clinical relevance and utility beyond the time frame (episode) when it was created
- the document (consultation or discharge summary) can easily be relevant to more than one problem, and therefore more than one problem-episode. What if it is a non-granular lab report which reports on diabetes and renal function and investigations for hypertension?
So when looking over a patient's documents to decide what has relevance, it is really the type of document (discharge summary, operative report, consultation, lab tests) along with its clin_when that determine whether we want to look at it, and/or whether to
include it in what we would communicate outside of the praxis.
Particularly given that a document can have a meaningful and useful relationship to more than one clinical problem even while we can in GNUmed only 'associate' it with a single problem, indirectly, and only via its episode, and by so doing we lack anyway the
means to access it 'via' any other problem (and even if we could I would be driven nuts to be forced to do all that inputting)
AND last but not least, since we have the (unimplemented) possibilities of identifying relevance via
backend blobs.doc_med.clin_when
and
codes
Therefore I *really really* think that while it is well and good to keep episodes *available* to be inputted, I would:
- relax the constraint, make them nullable in
blobs.lnk_doc_med2episode
- rotate them to the bottom of the field list in the screenshot
- split the width that has been provided to 'Date of creation' and in that space provide left and right:
'Date to which it clinically relates' 'Date of creation'
-- Jim
