Automated clinical decision support (CDS), in the form of EHR systems that issue patient-specific alerts and reminders, has been with us for forty years.[14
] While these systems have been shown repeatedly to improve the quality of patient care, increase patient safety and decrease cost, they also have well-documented challenges. Despite the incorporation of rule engines in commercial EHR systems, the creation, testing and maintenance of the rules themselves remains a resource-intensive process. Even when rules are perfectly implemented, their messages are often ignored due to “alert fatigue” and other cognitive factors.
Infobuttons are a relatively newer technology, only recently included in some commercial systems. Unlike rule-based systems, the knowledge used by Infobuttons is created and maintained by outside entities, such as publishers and knowledge base vendors. They also have the advantage that they are a “pull” technology, as opposed to the “push” approach of traditional CDS, so that the user, not the computer, decides when the access to knowledge is appropriate and useful.
Infobutton managers, on the other hand, have been largely restricted to institutions that have strong informatics research and development programs, such as Vanderbilt, Harvard, Utah and Columbia Universities. The recent proposal by ONC to include infobuttons in their criteria for meaningful use of EHRs poses a potential obstacle to institutions without the resources to develop their own solutions. The creation of OpenInfobutton now provides them with an engine to meet this requirement in a way that goes beyond a simple, hard-wired EHR-resource link. LITE provides the knowledge engineering piece of the puzzle. Unlike the knowledge required to create decision support rules, the knowledge collected by LITE, and used by OpenInfobutton, is much simpler and less volatile: what information need is likely to arise in a given circumstance and what is the right knowledge resource to address that need. Once the EHR-OpenInfobutton link is established, the maintenance becomes a simple matter of answering questions in LITE wizards, with no programming involved. Furthermore, as the number of LITE users increases, we expect a user community to develop provide that will not only share resource descriptions but will provide advice about when include particular resources and even perhaps “crowd-source” the improvement of the LITE user interface.
There are still some challenges to the full implementation of OpenInfobutton and LITE. While the functions in LITE are operational, we are wary of the complexity of the task and are unsure as to whether the user interface we have established will be comprehensible to the typical LITE user. We have therefore limited the tasks in LITE to those related to establishing institution groups and defining contexts for a predefined set of resources. As we gain experience with the use of this limited functionality, we expect to learn better ways for LITE to ask questions and present information. We will then modify and release additional functions in an incremental manner.
Another challenge that remains for our architecture, and infobuttons in general, is the issue of controlled terminology. In particular, the mainSearchCriteria parameters can include codes from controlled code sets. While EHRs are increasing their use of controlled terminologies, the information resources may not be able to recognize the codes or preferred names from these terminologies. Overcoming this challenge may require adding significant terminology services to OpenInfobutton so that it can create URL links that will be understandable by the resources to which they link.
Despite the challenges, the infobutton solution described in this paper exists today and is capable of providing context-specific information to EHRs users, including clinicians and patients. Several institutions are already using OpenInfobutton in their EHRs and are poised to begin using LITE to customize OpenInfobutton.