|
| From: | James Busser |
| Subject: | Re: [Gnumed-devel] Re: Cannot change the dates of the encounters |
| Date: | Sun, 19 Oct 2008 16:52:32 -0700 |
On 14-Oct-08, at 7:39 AM, Karsten Hilbert wrote:
On Sat, Sep 06, 2008 at 03:51:59PM -0700, Jim Busser wrote:What exactly should we regard as the "literally" chronological journal? Literally as in time-of-insertion or time-of-clinical-occurrence ?Time-of-insertion, *and* the time-of-clinical-occurrence are important. Since the journal is the record, I was thinking in this context "literal"would refer to the insertion.
A view that sorts on insertion-time would be useful to understand and look back over any changes to the medical record. Eventually, this view would be able to be developed into an audit. A proper audit for any one patient would need to combine (inter-digitate), into one view, the patient-related rows which live in the "active" tables along with the patient-related rows which had been deprecated into the audit tables. After this was possible (implemented), the tab could be called "Audit trail". Until that time, deprecated versions would not be included, until which time the view could maybe be called the "Insertion tree" or "Insertions" or "Trail". More below.
Time-of-clinical-occurrence is already the basis of the EMR tree, so I was thinking we could / should use the EMR journal to display along timeof insertion.I have written up the current understanding of times as used in the GNUmed project here: http://wiki.gnumed.de/bin/view/Gnumed/GnumedTimeConcept Thus, a third time becomes relevant to the question above: The time-of-care-process. We need to decide among those three by which to order the Journal. It seems there is equally good arguments for each ?If you look at the Journal the way that it works presently, GNUmed would not (?) present to you that this was part of the discussion of the lastvisit, coming about as a result of the praxis receiving a copy of the report ordered 5 months ago by a walk-in clinic doctor elsewhere.Assignment of a clinical_when of 5 months ago would move the informationpotentially several screens up in the Journal.That is why the Journal should be ordered by time-of-care-process rather than either of the other two. Time-of-insertion could move the information further down to when the receptionist transcribed a voice-recorded note while time-of-clinical-occurrence might move it up to, say, 5 months ago as you correctly note.Or maybe part of the last visit would concern the discussion, but it would not show the (late)entry of the radiology report, since that had been given a clin_when of 5months ago and legitimate because after 5 months the condition of the spine could have changed.Correct. The clin_when of the xr report *content* would legitimately be -5/12 while the modified_when of the entry would be last night at 23:15 by the transcriptionist. But the really relevant time would be the encounter start/end during which the existance and content of the report was relayed to us. I do think the time of technical insertion may make sense to be displayed in parenthesis, though, as it may help to explain a difference in knowledge between the memory of the doctor who received the report first-hand in the encounter and the follow-up doctor who looked after the patient, say, 21:00 later that night while the earlier note was only committed at 23:00 by the secretary ... Do we agree here ?
I agree. I am trying to clarify what more is needed to support time- of-process when it may be different from clin_when.
We are potentially looking at:- clin_when as denoting the year / date / time of a patient- experienced symptom onset / illness onset (or a procedure) - care_when as denoting the year / date / time when care was initiated, or was given (this would include when a procedure was done) - mod_when as denoting datetime of record alteration/insertions of the *documentation*
We know patients often come for care days, or weeks, or months after the onset of a symptom. It can be important to backdate the sequential onsets of symptom 1 and condition 2 and possibly an activity or other exposure (like the first use of a medication) so that we do not confuse dates of *occurrence* (onset) with dates of *care* or dates of *documentation* which would cloud the clinical understanding of what is going on.
Past history items and health issues will want a value for clin_when ... this raises a number of issues: 1) the table health_issue presently holds only the field age_noted which is of type interval... I assume this is to permit its value to be an operator in a calculation that would include a patient's date of birth? 2) does anything prevent this value being raised into the Edit details widget, when one desires to edit some piece of this health_issue? If nothing prevents it, can the widget seed values into both fields "when noted" and "or year" and test whether the user altered either value, and if only one of these was changed, update the value according to this change, but if both values were changed, then complain to the user? 3) can the field store a precise date, when it may be known (for example) that a motor vehicle accident, or a stroke, or a myocardial infarction, or "status post <procedure>" occurred on a specific date? 4) revising what may have been a previous suggestion, when the user inputs into "when noted" only an age (e.g. 39), should the logic calculate and store the value equal to the {year _of_birth + years, month of birth, date of birth} and how do we then later recognize whether the value stored was approximate (if we recognize it seems to be on their birth anniversary) or exact (since it could have fallen on the person;s anniversary of birth)? 5) the field and the widget labels say age_noted and "When noted" however is this meant to store the age or date on which the illness began (or the event happened), or is it meant to store the date when medical care was first obtained? IOW is this supposed to correspond to clin_when or care_when which may be different?
At creation of past history and health issue items, we store a backend comment (in clin_narr) linked via a pseudo-episode "inception notes".
- episodes, however, carry only modified_when- the encounter attached to this episode contains "started" however this does not help to manage the various dimensions of the 5-month old x-ray report, whose content describes the patient's findings as they existed 5 months ago (clin_when) but which we only knew about yesterday. When this report is imported into our document archive (into blobs.doc_med) it could have a content "date" of 5 months ago, corresponding to the dimension clin_when but there is no way to keep the document related to a care_when date and time because the table in which the document is stored is itself linked only to encounters and episodes.
I agree that the really relevant time would be the encounter start time, however when this encounter contains many rows, and when these rows can get touched in various orders which can confuse their original context (if later sorted on modified_when) do we need to preserve record creation datetimes? What more (or otherwise) is needed to implement or support time-of-care-process?
PS as a ToDo should blobs.doc_med field "date" be renamed to "clin_when" ??
| [Prev in Thread] | Current Thread | [Next in Thread] |