> > Most parts of this can be reused in another design - it need > > not be an ugly notebook plugin. > I noticed that! Good.
> > I do realize that this may be backwards in functionality - eg, > > really one would want to be able to *first* enter notes and > > *then* decide on which problem they belong to. > > ie: use the active problem list (as you try) to add an empty SOAP control > which is then saved back as another progress note episode. I assume you are > doing something like that. yes > Why try and define an episode before you allow the user to add a soap note - > we don't do that on the page. Simply label all new notes as udnefined, and > then enforce linkage to either an existing problem list or to the definition > of another problem. We might even be able to add this in before 0.1. Carlos, what's your position on this ? > I also seem to remember as recent statement in a mail saying something akin > to > 'we havn't decided how to edit progress notes yet' correct > - the answer is really > simple you don't - progress notes are just that 'progress notes', OK, thanks ! > they are > added sequentially to a running total. They are not meant to be re-edited in > the SOAP editor in any circumstance other than in the current consultation. We still have a slight conceptual difference as to *when* to commit: Eg we tell the user to not save the progress note until deciding to really be done with it while you allow the intermediate step of "saving to a list that later gets really saved to the EMR. You do it since you have only one progress note editor while we have one per problem. So this may be inconvenient but workable. > Finally as I've posted to Carlos, why don't we start of with a proper > integerated design now, it is no extra effort Because we should focus on getting 0.1 out the door (ask Tim) and not "start over". We are well perfected at starting over, I know. IOW progress note handling is pretty much done except it needs polishing here and there. > - it is just yet another wigit combination, but one that makes more sense. Glad you see it that way. 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
