Steve LeVine's blog

2005-10-27T11:40:00.000-07:00

After another conversation with Johannes Ernst I am thinking more about how we can make BirdDog more web-twoey. The concept of attention came up, prodded by a forum Jernst participated in earlier this year. He was saying that the bedside experience might be supplemented with emitting devices that could interact with a handheld device, say to deliver vital signs (VSs). I stated no, the big deal is getting information about the patient from systems that are remote (e.g., ECGs, images, clinical profile from the data repository). As I was elaborating in the last entry to this blog, there is value in understanding and declaring explicitly the log of all salient decision points that pertain to a particular encounter. The 'attention' path of the clinician is the basis for clinical decisions, but only a small proportion of the evidence is usually documented. To the extent that this can be automated, the power of the note will be enhanced, making for a more robust document.

The other Web 2.0 concept that we definitely want to exploit is RSS technology. The idea here is entirely compatible with the role of BirdDog as a passive information space. I subscribe to my patients' data feeds -- they render directly on my device without any need for repetitive requests on my part. (Though I might want to set some parameters for efficiency's sake.)

Finally there is the identity management part of the application. Besides achieving SSO, I might want to register various levels of presence to the application, depending on my role, devices and availability. Netmesh is working on this.

2005-10-09T22:13:00.000-07:00

The elements of a good encounter note:
For those who are not in medicine or medico-legal disciplines, let me describe the clinical enocunter note. A patient arrives in the clinic or emergency room, with a complaint or complaints, and the physician asks a more-or-less directed series of questions, perhaps orders some tests, draws some conclusions and scribbles some summary notes. The resultant document is designed to be structured as an argument in support of a set of conclusions, resulting in a plan of action. A good note has the following characteristics: it is complete, coherent, and logically sound. That way, if something unexpected arises in the patient's condition, it is easy to understand why the physician decided on the course of action, and possible to compare what she did with what other similarly trained clinicians might have done with the same information. Of course, acknowledging all of the small elements that support a clinical diagnosis and plan can be time-consuming, so there is usually some truncation in the name of efficiency. But in the era of a fully electronic medical record, the task is infinitely easier, since much of the entire experience of the clnician is traceable as she retrieves the data in support of her conclusion. If she summons an electrocardiogram (ECG) taken on her patient, the reference to that retrieval belongs in the chart, along with comparison ECGs from the same patient. The same is true of other laboratory results, images, and any other digital records that are pertinent. The chart can be a hyper-linked access log with annotations summarizing the decision points along the way. Other decision support tools can be embedded at the same time, including treatment guidelines and reference articles. Much of this can be automated, saving the clinician time while creating a very robust document. The potential drawback of this kind of solution is that the parts of the chart that are left out may be quite important but harder to document; nuances, intuition, and the art of observation are harder to describe verbally, but may be very crucial. I would still argue that this kind of chart would be an improvement.

2005-09-30T23:03:00.000-07:00

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

2005-09-30T22:47:00.000-07:00

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

2005-09-22T16:10:00.000-07:00

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.

2005-09-15T12:24:00.000-07:00

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.

2005-08-16T23:17:00.000-07:00

Lobster:
Imagine a far-sighted, maladroit physician with a portable computer. Can you design an application that he can easily use?

2005-08-16T04:42:00.000-07:00

Met with Janine Buis yesterday of Nokia's Innovent arm. We're going to be sharing the podium at the Medical Record Institute's Mobile Healthcare Conference in San Diego this December. I will talk about BirdDog as a case study of the potential for mobile computing in the healthcare 'space.' The key concepts are 1) that mobile computing is not just running applications on portable devices; it's best thought of from the application layer up; 2) adoption of devices depends on the business value and usability of the tools more than a price point; 3) that application design should anticipate changing platforms and infrastructure support; 4) that devices that are aware of 'microcontexts' may have the best chance of serving the needs of mobile users; 5) that in healthcare specifically we are simultaneously heading toward a more transparent, shared, and distributed medical record at the same time that we are more than ever concerned with the security of protected health information (PHI).
I'd better elaborate on what I mean by 'microcontexts.' In emergency medicine, much work is done outside of a defined exam room, and as the medical record is essentially a datastream from electronic resources, the 'chart' may not be accessible at the bedside in the conventional sense. It may be difficult to have a private conversation, let alone do a decent examination without compromising the patients' privacy. Yet we may need to recruit them in decision making. Some portable devices may make this more possible since the information can be obfuscated in a way that shared workstations or COWs (computers on wheels) can't. A microcontext might also be thought of in terms of the temporal environment that encloses a decision point. E.g., 'should I order this medicine, here and now?' Because there will be new data incoming, this fleeting moment of opportunity may be best taken if there is a proximate device that allows an action. Lowering the threshold of access to information and the ability to act on that information is what mobile healthcare is about.

2005-08-14T17:04:00.000-07:00

Johannes Ernst, encouraged me to start this blog. And it's not a bad idea, since most of my thoughts evaporate or get buried under a pile of other ones before they can germinate themselves or pollinate elsewhere. Johannes and I met last week to discuss BirdDog, the project on which we are collaborating at Kaiser. Adrian Blakey, the development manager in charge of the project, and Johannes are good about cataloguing the progress of our joint venture internally, but when we start thinking beyond the immediate parameters of BirdDog some good thoughts tend to get lost in the shuffle.
The part of that discussion that I want to elaborate has to do with the limitations of small form factor communication devices and computers. My opinion is that too much is expected on the user's part to accommodate to these little machines. Even if an individual gets really good at one of them, he may find that these skills aren't very transferrable to the successor devices. For example, text entry is a big challenge. I spent years getting good at Graffiti for Palm-based systems, but it's not natively supported on the new Treo phones. I'm getting better at thumb-keyboarding, but that skill is inhibiting my facility with touch-typing. (I was never very good at the latter.) This is a problem for clinical applications, since virtually all of them require lots of keying. So in designing new clinical applications, I am exploring the opportunities for very simple graphical interfaces. That led me to look at AJAX-powered web sites. (Thanks to Jory Bell of OQO for first mentioning AJAX a couple of weeks ago...I'm a little late in becoming aware of this next-gen web technology.) The more we can replicate the tasks that are required without having to type accurately, the more usable and efficient the application will likely be. So if you want to ask something of a database, rather than typing in SQL queries, it makes more sense to use a drop-down selection menu. That's old news. But what makes the new AJAX sites so cool is that they are quick, responsive, and seem to anticipate the needs of the user before the requests are invoked.
As I work through my clinical patient task list (inbox, whatever you want to call it) I am constantly toggling back and forth between disparate applications and re-entering credentials and medical record numbers. Even in a unified system, like Epic, there are so many tiles, tabs and buttons that it is still fairly cumbersome to navigate, even on a full screen. On a small display it might be unusable. How can we get the same functionality out of a mobile app? I think that if we start by designing for lobsters instead of touch typists we'll be on our way.