On Tue, Sep 13, 2005 at 10:39:27AM -0700, Jim Busser wrote: > If the EMR tree by default opens with all subitem triangles "closed" > it will be an extra step for the user to have to open the triangles > to identify whether there exists an open episode. I agree.
> Options would include > - pre-opening the triangles for issues that have open episodes. todo > - appending to the issue line some indication (symbol or episode > name) the fact of an open episode todo > I guess closure of the > episode would be dated the current date/time because that is when the > judgement was made to close the episode. I agree. This is currently assured at the database level by the auditing trigger (it updates modified_when to now()). > It should still be possible > to identify the date of the last encounter within the episode. It is :-) clin_encounter.modified_when or .last_affirmed In fact, each and every clin_root_item has it's modified_when time associated with it. > I do have a question about the decision to close an open episode from > the tree. What if an open episode contains a plan that is incomplete? We are not into tracking medical decision/ outcomes/ completeness yet. IOW, we currently have no way to detect an "incomplete" plan. So, whatever the user decides is to happen will happen. > How would one know, except by inspecting the content of the > encounters? One would not. > So if the episode perhaps *should* stay open, maybe its > better for the user (who declines to append) to have to make an > *informed* decision to close the episode, and maybe that can only > reasonably be done by viewing it. Depends if we have any agreement on > what it means to 'close" an episode. To me it means the doctors decided (by means beyond my *control*) that this episode is to go dormant. > I think it should carry some > meaning such as "symptoms expected to resolve" (although you would > not know until later) or "care completed". A patient may have failed > to return within 90 days on account of personal problems and I am not > sure what is to be gained by having automatically "closed" the > episode, is there some inherent (or EMR performance-based) advantage > to closing it arbitrarily? It is not closed arbitrarily. It is only closed when new data is to be appended to the episode. Which mostly happens when the patient re-presents. If the patient never comes back and I don't manually go close his episodes on purpose they stay open until the worlds tumble. > Or to split some out e.g. > - diabetes mellitus (control) > - diabetes mellitus (foot care) If I am a diabetic care center this may actually make sense. In other settings it may not. Note that I could still tag individual progress note lines with arbitrary markers (eg foot care, eye care, glucose control) if I feel the need. > While I do little primary care, I imagine that between followup > visits, phone management, patient-initiated visits, and dealing with > contacts from the diabetes centre and nurses plus lab results, there > might easily be a couple of entries per month just for diabetes so > over the course of --- say --- 10 years there could be 2-3/mo x > 12mo/yr x 10 yrs = 240-360 entries. That is a lot. Well, if that patient is under such regular care there will be, say, 3 episodes per year, only one of them active. The EMR tree (not the problem list) will then show 30 episodes over the course of ten years - IF we choose to view that level of detail. There may well be use for a view that ignores episodes and only chronologically displays progress notes for health issues. People are free to do so if it makes sense. As Horst says: Allow structure but allow to use it in a simplified (appropriate ?) form. > So would there be a view that (for example) when dealing with this > patient's feet, looking back over their foot care (& ulcer) history > to review its course, the specialists involved, when were the most > recent contacts, there would be fewer visits to need to browse if > they were split out under > - diabetes mellitus (foot care) Well, the visits are most likely going to be aggregated in some sort of, say, HTML under the episodes - or even the issue itself. As needed. > Would this also simplify the export (once we are able to do so) of a > *subset* of EMR information, say on one health issue, upon referral > to a specialist? Yes. Improved data quality improves selectability. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
