David Guest <[EMAIL PROTECTED]> wrote: > > Tim Churches wrote: > > A very good point, which Richard Terry has also made many times as > > well. There is a clear difference between the acceptable level of complexity > > of user interfaces that skilled professionals are expected to use > > every single working day, and a user interfaces that neophyte users can > > assimilate and understand in 30 seconds. Far too many software > > designers implement the latter, because they look nicer in the marketing > > brochures and during 10 minute demos of the software, and don't produce an > > initial shock reaction of "uggh, that's so complex, I'll never understand > > it". > > But utility is more important than aesthetics for something that is > > used every day and which by necessity becomes as familiar in layout as the > > inside of your own mouth. That is not to say that complex and > > information-dense displays can't be made aesthetically pleasing, but > > it does require more thought and creativity on the part of the designer. > > We probably need a myghty solution (http://www.myghty.org/).
Not really, that is just a Web templating system (one of many). What we really need is an iGoogle-style interface. Have a look at http://www.google.com.au/ig and, if you have a Google account, sign in. Each of the panels can be dragged around the screen, hidden etc. If you sign in, it remembers all these customisations and also allows you to choose from hundreds of other panel applets which can be added to your home page - these applets are written to a standard API - some are done by Google but many are done by third parties. So, imagine, instead of the Google search box etc at the top of the page, it displays some basic patient demographics and a patient search/selection mechanism. In the lower part of the page, a configurable array of information panels which collect and display information about that patient, including latest lab results, reminder lists for screenings and immunisations, visualisations of their progress over time (eg BMI, BP or BSL charts etc), decision support panels and so on. There could even be some user-defined rules which allow some panels to be substituted for others depending on the characteristics of each patient. Some of the panels could be editable to allow progress notes, problem lists and meds to be updated. All panels work via AJAX so there is no need to reload the browser page, except perhaps when changing from one patient to another. Keep multiple patients' records open in multiple tabs in your browser. The point is that Google demonstrably has all the technology to do this, and all the post-docs and software engineers it needs to be able to hook it all up to a solid database back-end. It could sell the thing as a hosted service or as a locally installable server as it does with its search engine (see http://www.google.com.au/enterprise/index.html - with Google-hosted automated back-ups of the local server data). You'd have to pay Google to use it but then it wouldn't need to be supported by advertising - and Google's enormous economies of scale mean that it could end up being rather cheap for GPs and still profitable for Google. Other smart organisations could also do it. All that is lacking is will to do it and a few million in funding to get it started. And, as Google so clearly understands, there is ginormous advantage in providing a standard and open API,t thus allowing third parties to create and install plug-ins. That way Jon Patrick's group at Sydney Uni could easil! y develop plug-ins that understand natural language English expressions and convert them into SNOMED CT codes all related to each other via an ontology, and Kuangie could even do a DOCLE plug-in panel, and I could add epidemiological analysis panels. And Pfizer could do a Lipitor panel as well - but you wouldn't be forced to install it. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
