On Tuesday 19 September 2006 21:31, Karsten Hilbert wrote: > On Tue, Sep 19, 2006 at 01:35:44PM +1000, Richard wrote: > > 1) Loaded myself as the patient > > 2) went to docs', imported * 3 letters from my file server > > Judging by 4) you did not *import* those 3 letters. What you > did was *preparing* them for import into the record of the > patient that will be active when you press "save". > > > 3) Went to Inbox, looked at some of KK stuff - double clicked to see > > details - it loaded him as a patient > > 4) Went to Docs (visually my 3*docs still in the window) > > 5) Entered some text in the area underneath and an episode in the > > textboxes.and saved > > 6) The history shows it has now attatched the three letters that I loaded > > for me as a patient into Kirks medical record. > > As explained above this is to be expected. However, I fully > agree this is a usability bug because it is surely not what > one would expect. This already is a TODO, BTW: clean out the > import-docs plugin on patient change. > > The underlying concept is "Any data you see always belongs > to the active patient." - unless explicitely labelled > differently such as in the provider inbox.
Whilst on this note - and remember I've pushed this before - I think it is very very unwise having non patient-specific items apearing in your medical record design. The Inbox is a provider (all patient - all stuff) thing. The best solution for this that I've come up with as seen previously is the listbook style of design, where all your clinical stuff live in one section, and all stuff not explicity related to the patient lives elswhere - otherwise it is just too confusing for the user. > I will increase the priority on this. > > > Interestingly there is no record in the progress notes that the user > > imported any documents for the patient - perhaps by design. > > Good idea. I didn't think of that. Any suggestions for the > wording of the entry ? Any action within the medical record should appear. In my program I used a such simple words as "Three documents where imported into the medical record: name1, name2, name 3 + comment if relevant. > > > Just in case you are interested in what I've been doing for the last few > > months (not programming!!!!), I've been torture testing a number of > > medical record programs in use in Aus/NZ, on behalf of our local Division > > of General Practice, have to present a 2 hr talk to them this friday. > > Can you make this talk available somehow ? Perhaps, in part I could just describe. The brief really is that currently in our City Wide after hours GP Clinics all linked to a central server, we use one particular (reallly stupid) software. Aged care in Newcastle (ie all the nursing homes etc) have been pushing to get secure software, and the quest was to look at the options/usability/security issues etc. The software in use is currently used by 100's of GP's in the clinics, but they use a different one in their offices. As Aged care/philosophy is involved much of it may not be of use to you, and anyway, much of it I will have talked endlessly about before and it has fallen on deaf ears. What is interesting to me that when you compare all the programs there is a certain similarity about them all (they mostly have a heritage of about a decade) and that (having observed some of them for years) usage > feedback > has been leading them down a similar functional design. Some are 'dead-end' designs on the software tree of life, one in particular was picked out by the initial 20 member software evaluation team as the best and I think is still on the main stem of the tree of software evolution. Interestingly I'd never seen it before last November, but the screen designs/conceptual use is uncannily like my office program/my open source designs which you have rejected. Above all, having played with all the data input/progress notes methods, my thinking on these have crystalised somewhat. Some use the SOAP boxes like gnuMed, some more like Ian and I's autoexanding SOAP, many just problem separated plain text entries with the ability to insert templates or images. My current opinion (could change without notice) is that problem segregated plain text field entry with ability to insert images and templates is the most practical way to go. Whether the problems are segregated down the page, or like we have on tabs across probably dosn't matter. Whereas strictly separated and saved SOAP notes may have some value in enforcing a method of imput, they don't allow the user freedom to work how they want, and I think though perhaps should be allowed as an option for insitutions needing that, or doctors wanting that, they should be abandoned as the prime method of data entry. The use of a SOAP template within a free rich text field works just as well for those who need that sort of structure in consultations (could be me!!!), with the ability to tailor the variations in structural input to your own needs. So in summary I'd like an editable html type control (can insert piccies) + templates + ian/my popup's (like you've sort of implemented crudely in your soap). Data once saved is displayed in html in the progress notes. Each note entry should be linked to a problem by the user (not by the system which you use which dosn't work logically). You will remember in my mock-ups I had a home/forward back button. This has been implemented in one of the programs I assessed to a variable degree, but certainly makes navigating around the medical record a heap less painful. Anway, have to go Bye for now. > > Thanks for reporting your experience ! > > Karsten _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
