On Wed, Sep 14, 2005 at 12:04:15AM -0700, Jim Busser wrote: > >My "compromise" is a single text box for entering unstructured text but > >with the provision for tagging text in order to provide some sort of > >structure > >and searchability > >... > >By default I will always have the previous progress note in view for > >reference, but a single click (sort by problem) will default to the last > >progress note tagged with the current problem (if current problem already > >set) > > It is hard *not* to like what Horst has shown in terms of usability. Almost the same effect (UI-wise) can be achieved by taking the exact same design Horst shows here but replacing the single free-text progress note input field with the notebooked progress note input field we currently have in GNUmed 0.1. One would then open new tabs when double-clicking a problem. The drawback would be that one would need to switch (inner) tabs when wanting to enter notes for different episodes.
IOW the structure can be implanted into that design. > Issue 1: > ------ > Whether to support a separately & purely defined problem list (as > Horst seems to do) Actually, this is quite possible with the current backend, too. Just forget about health issues for the moment. Think of episodes as problems - they are really pretty much the same thing. You can define any number of them and have open any number of them. You can name them any way you wish. You can or cannot attach codes to the narrative if you so wish. Such "problems" == episodes need to be clinically distinct at all - nothing of that sort is enforced by the backend. The health issues just provide a means to clinically aggregate problems into larger groups. > Horst's approach could permit the problem (no matter what language > was used to name it, free-text) to be attached to one (or even more) > diagnostic codes. Same in GNUmed. > And by extension when one or more problems are used > to tag a visit, the progress notes become retrievable by diagnostic > code. No different here. > This should not preclude attaching additional codes to a progress > note entry, e.g. to capture treatments administered. It does not in GNUmed. > Issue 2: > ------ > The pros and cons of *partitioning* the data contained within any one > visit (encounter) into parts each attached to the "owning" issue. > There may be a *design tension* here between what's advocated by > technically correct designers, who strive to maximize the exactness > or precision of a data relationship versus what is "good enough" and > much more satisfactory to get the "work" done. I am not at all opposed to let people write a "dumbed down" (or "different" if you prefer) interface for the backend if they so wish. I could not care less. However, I am strongly opposed to dumbing down the *backend* thereby precluding ourselves of being able to take advantage of more structured data should we chose to employ it. The one point I do not have an answer for yet given the current backend is that, indeed, GP medicine seems to warrant linking some progress note snippets to more than one "problem" (= episode name). I am thinking hard currently how to best accommodate this. I think Richard, Horst, you et al do have a point there. I do, of course, recall times when it felt natural to think of some piece of narrative to belong to several problems at once in my very practicing medicine. > So if at a visit a patient was initiated on an angiotensin converting > enzyme inhibitor at a visit where diabetes, hypertension and heart > failure were pertinent, does it matter which one (or more) problems > were the "indication". Even if we care (because we might) is there > some way to capture this other than by partitioning the contents of > the note into separate problems? After all, maybe the drug is > selected to treat all three (supposing they have proteinuria [setting > aside if that should be separate]) but we certainly don't want to > have to repeat the drug three times, once in each partition. Now, you always find the perfect use case for shaking our foundations :-) This case lends itself quite well to the current approach: - have a table clin_aux_narr2epi which allows for additional episodes/problems to be linked to this clin_root_item (eg clin_medication) - make the prescription widget allow to select further episodes/problems to be attached - set clin_root_item.fk_episode to whatever episode/problem the prescription happened to be triggered under - the actual medication row would thus be linked to several episodes/problems, however, the prescription widget could automatically place identical cues into the progress notes for each of the episodes/problems Other cases could be handled similarly. Progress note widgets could have a field "Also link to". > Anyhow I could be open to a backend that supports those who want to > do the extra work of splitting *but* can this also accommodate the > single-SOAP per visit design? I am wondering whether single-SOAP is > the way to start It could be - GUI wise. It should not be backend-wise because that is not necessary anymore. 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
