Most clinical applications that we use are clooges that patch a bunch of functional requirements together into an ill-fitting suit, and then expect doctors of all sizes to wear it. (This they do, but it's not pretty.) The results tend to be fat-client monstrosities with fastidious platform requirements (plug-ins, controls, applets) and inordinate bandwidth needs.
What useful attributes do these applications have in common? They convey clinical and demographic information to the physician, sometimes provide a little decision support, and then allow the user to act on these data in various ways. Web technology is pretty good at the first two purposes, but has lagged behind desktop applications with regard to enabling the the MD's tasks, depending as it does on sluggish server-client interactions and rudimentary form elements. Much of the real processing has to be forwarded to the server and then sent to and reloaded on the client. System slowdowns and outright failures are common, to the point where new accounts may be suspended to 'reduce load on the application.' Meanwhile, on the other hand, the power, speed and memory capacity of desktop and pervasive devices has grown dramatically. This means that we can safely transfer many processing duties back to the client to reduce both bandwidth and server processing cycles.
The new AJAX powered web sites (Google Earth, Google Suggest, Backbase and others) hint at what could be possible for medical software. Here we have the opportunity to let the user manipulate the data on the page without reloading it, using icons and avatars instead of text boxes to create notes, write prescriptions and code procedures. Combined with RSS's 'push' technology, the user can subscribe to whatever data streams he deems pertinent; e.g., to track the progress of patients without having to poll separate resources one at a time. The data can be then manipulated to support decisions and to create the documentation of those decisions, without leaving the page. By minifying the icons and using semaphoric behaviors for page elements, complex functions can be represented -- and triggered -- easily on smaller devices. The goal is not necessarily to eliminate the need for a keyboard, but to reduce the total number of key or thumb strokes to get a particular task done.
Drag, drop, undo, commit, recent tasks, recent encounters.
We're always going to need some fat clients to render DICOM images, for example, but the point of this post is to suggest that we could distill the user-client interactions much more than we currently do in order to support mobile devices.