The tasks of MD:
1—document: create a clinical record of an episode or encounter
2—review: interpret the clinical history and setting
3—interpret: evaluate clinical studies and reports
4—compare: place the individual in epidemiological context
5—order: trigger clinical interventions
6—Rx: prescribe medications
7—message: communicate with other staff and patients
8—annotate: associate interpretation with study
9—research: search the literature
10—consult: communicate questions on behalf of the patient
11-code: classify diagnoses and procedures for tracking, billing and QA
12—search: ferret out information from all of the systems above

Some rules for handheld application parameters:
The nine ‘C’s:
clicks—one-click navigation, no scroll
color—readable, coded to ripeness of data
canvas—data density = only what the field can yield
contrast—smooth visual transitions
cueing—prompt for user actions, hilite new content
context—search, back, forward, up, detail views
confirmation—acknowledge changes and action
consistency—visual nomenclature the same from page to page
content—relevant and salient

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.

More on microcontexts.
One of the key advantages of creating an electronic medical record is the opportunity to provide intelligent decision support at the time of the decision rather than retrospectively. This is especially true in emergency medicine. High-stakes, time-sensitive decisions are made on a daily basis, and now we can use evidence-based medicine to bring practice guidelines and other job aids to the bedside. One example of this kind is an interactive chart tool that has built in logic for various clinical scenarios. This sort of tool contains reminders to ask certain key risk-associated questions while composing the chart note. It's crucial to have synchronicity in order for these tools to work. These job aids are usually very simple algorithms that could easily be coded for a small form factor device, with the output being a text snippet to be added to the full encounter note.