One of the interesting sessions at the recent American Medical Informatics Association meetings was about "infobuttons". This seems like a functionality that would have general value for the OpenACS toolkit. (I have a vague recollection that there may have been discussion about something similar to this in the past, but I can't find it now.)
Here's the basic idea: attached to various items in a page of information are small buttons (consisting graphically of an image like this). When clicked, these buttons bring up a window with context-appropriate information. For instance, in a patient record containing a serum potassium level, an infobutton by the level might bring up a page of links -- to a discussion of causes of high and low potassium levels from an external online reference, a Medline search of medical literature, a list of relevant medications from pharmacy records, etc etc.
The resources which an infobutton links to an information item in a page thus include (among probably other things):
- links to internal pages/images/etc in the site
- links to external site pages/images/etc
- search queries within the site
- search queries to external sites
- calculations
- agents
The challenge obviously is maintaining these mappings between informational "about items" and the various resources. Currently this is a labor-intensive process. For example, when an EpicCare medical record links to Micromedex reference data, the search params are arbitrarily constructed per Micromedex's apis and can't be easily reused for a different reference vendor. HL7 standards for messaging will help regularize the syntax of such calls, but the management of the links themselves remains complex.
I think the broad strokes of a solution would include the following:
- An "infobutton-aware" package would specify which of its object types it wants to provide infobuttons, include the buttons with each "about_item" of these object types, and register these object types with the infobutton package.
- The "infobutton package" would supply an abstraction for all resources it can map to client "about_items" plus an "infobutton manager" that would handle configuration tasks (registering new resources, handling popup window size/location preferences, etc) and realtime use tasks (taking the object_id of the "about_item" plus any other "context" ie key-value pairs sent with it, if any, to generate the links and display them in the popup window; tracking infobutton use -- ie which one was clicked, when, and by whom; etc).
- Beyond these basic functions, the infobutton package could append a more general Google search to the links provided so that users who aren't satisfied with the provided information can hunt on their own. The package could store a record of infobutton use -- simply for admin users to review, or for a "receipt" for users -- such that they could get education credits for using the infobutton, or even cash payments. This could be coupled to a short quiz, even, at the end of the infobutton page.
At this point, I haven't thought through any implementation details, but the new callback system seems ideal for this application. And the basic functionality seems like it would be useful generically, much as is categorization, with which this has a number of semantic similarities. Does this sound like something worth adding to the toolkit?
