Healtheon/WebMD - RACER
Healtheon was founded in 1996 to bring Internet efficiency to healthcare and insurance administration, an archaic, paper-based system representing 20% of a $2T industry…a $200B overhead. The company went public in 1999.
The role of RACER (Referrals, Authorizations, Claims, and Eligibility Reporting) in this grand vision was to reduce or eliminate administrative paperwork between providers and payers.
We arranged visits to several providers of varying sizes to observe typical day-to-day operations, interview office staff, and retained some domain experts on a consulting basis. We made similar visits to the offices of a local managed-care organization.
There were 3 main types of user for RACER:
Provider (front office): These are the folks at the counter who set up appointments, get your insurance info, etc.
Provider (back office): These are the folks who handle claims and billing.
Payer: These are the folks at the insurance company who review authorizations and claims for approval or adjustment.
These activities raised concerns about what was possible with browser-based applications at the time:
What if the user is offline?
Always-on Internet connections were not as common in 1997, but the application still needed to work.
What about keyboard UI?
Users were familiar with terminal apps with sophisticated keyboard interaction.
What about performance?
Performance is an important aspect of user experience, and users were very sensitive to any productivity impact (payers especially so, because their own performance was judged by the number of authorizations or claims they processed).
These concerns seem quaint now, but they were real concerns in 1997. We didn’t have Ajax or local storage. Not to mention it was the height of the browser wars.
As the primary interaction designer, I developed a prototype in Visual Basic to explore design concepts and facilitate user research, which also embedded IE4. That elimated the worry about browswer inconsistencies, and opened the doors to stuff like Ajax, DOM manipulation (“Dynamic HTML”), and offline functionality. But it required an installed app, which was very controversial. We did pursue this approach though.
Despite the different types of user, the overall workflow is mostly the same — viewing and handling different types of documents, just from different perspectives:
TODO: System workflow chart
Main application screens include an inbox, various lists of documents, and a patient search screen.
Asynchronous searches: Searches for patient records (and certain other codes and records) were asynchronous. This helped to improve perceived performance, by freeing the user to focus on their task.
Building a patient list: A daily front office task was to prepare a list of patients for the next day. On paper, this is just the day's appointments. In RACER, the Patient Lookup screen allowed the user to quickly enter one name after another, without waiting for searches to happen. When online, the application would run searches in the background. Once all the names are entered, as the search results come back, the user could resolve name collisions, deal with insurance issues, and add them to the Patient List.
The Patient List, in turn drove various “quick-pick” lists in the UI, avoiding further searches, and allowing more offline functionality.
Documents were at the heart of RACER. There were three main design goals for documents:
- Paper-like look and feel
- Consistent appearance at all stages of workflow
- Integrated audit trail
The document appearance changes as it moves from stage to stage in the workflow, but preserves the sense that it is still the same document.
Audit trail: Document History provides a cumulative audit trail of the document’s path through workflow. Payer users route the document through workflow using toolbar command buttons, rather than explicitly entering a new status value, as was done in the previous system. The possible actions were:
The first 3 actions would prompt for a message, and send the document back to the provider’s RACER inbox. Forward is essentially escalating the document to a higher-level reviewer.
Simplification: The client’s existing system was complex, having more than 15 types of record, each comprising 3 screens, and which had no “document-feel”. Pushing this out to providers required simplification, without reducing any provider-side functionality or reporting.
An analysis of which fields appeared on which forms, and which fields were actually used by the client allowed a reduction of data fields and a consolidation from 16 forms down to 6, with each having a consistent appearance and behavior.
When filling out a document, users need to identify patients and physicians, and provide various codes for billing and claim purposes. In many cases, these things could be entered simply by typing a few characters or a name, but various “Find” dialogs were also provided:
Each dialog had a tab for the search form, and a tab for a customizable “preferred” list, which appeared in forms as dropdown combo boxes. (For patients, this is the Patient List; for codes, it would be a list of the typical codes used by that provider). These dialogs were also available from the menu, so they could be used at any time.
Various entities in the system (patients, physicians, hospitals, labs, etc.) were represented by records with their
contact information, ID numbers, and so on. Accessing these records was as simple as clicking on a hyperlink wherever
the entity was referenced. A sample patient record:
The patient record had 3 tabs:
- A summary of the patient’s contact and insurance information,
- Details of the selected benefits plan coverage, and
- RACER documents for this patient (active documents would automatically be listed, but the user could search for
archived documents as well).
The long-range idea was to grow this into a full-blown electronic medical
record by adding additional tabs for clinical information, medications, allergies, and so on. But users were
thrilled just to have the ability to search the benefits summary and scroll up and down (the existing
system didn’t allow for either capability)!
Oldie, but Goodie
This project is quite old now, but I select it partly because of its depth of function and process, but also for these personal reasons:
Mentor: I got into UI design based on a book by Bruce “Tog” Tognazzini. That was around 1992 in Minnesota. At Healtheon, I actually got to work with the man who had a profound impact on my career.
Team: This was my first (and so far only) opportunity to work with a fairly large UX team. I kinda miss that.
Domain: I found this field very interesting, and learned a lot about the inner workings of the business-side of healthcare.