Melinda – A custom search engine that provides access to locally-developed content using the HL7 Infobutton standard

Abstract

Healthcare organizations use care pathways to standardize care, but once developed, adoption rates often remain low. One challenge for usage concerns clinicians’ difficulty in accessing guidance when it is most needed. Although the HL7 ‘Infobutton Standard’ allows clinicians easier access to external references, access to locally-developed resources often requires clinicians to deviate from their normal electronic health record (EHR) workflow to use another application. To address this gap between internal and external resources, we reviewed the literature and existing practices at the University of Utah Health Care. We identify the requirements to meet the needs of a healthcare enterprise and clinicians, describe the design and development of a prototype to aggregate both internal and external resources from within or outside the EHR, and evaluated strengths and limitations of the prototype. The system is functional but not implemented in a live EHR environment. We suggest next steps and enhancements.

Background and Significance

Among industrial nations, the US ranks highest in health care costs and last in quality, efficiency and patient outcomes.¹ In a recent White House report, the US President attributed these inefficiencies to the lack of coordination of care, over-treatment, and the failure to adhere to best practices.² For example, one study shows that 53% of patients who have undergone cataract surgery still received unnecessary preoperative testing even though guidelines recommending against such testing were published 20 years ago.³ To address these problems, healthcare organizations began developing care pathways to standardize best practices.⁴ However, difficulties with accessing these care pathways at the point of care impede adoption.⁵ Therefore, organizations use a variety of knowledge management solutions for delivering resources and guidelines, ranging from storing static documents in a shared network location,⁴ customizing off-the-shelf products (such as Microsoft SharePoint),^6,7 configuring internal wiki pages,⁸ and developing custom mobile applications.⁹ While these approaches are better than the archaic paper-in-binder approach, none allow users to access documents from within electronic medical records where care pathways and support for clinical decision-making are needed most.¹⁰

The difficulty of retrieving relevant clinical guidance at the point of care is a well-documented problem.¹¹ To address this problem, the HL7 Context-Aware Information Retrieval (e.g., Infobutton) Standard was adopted as a Meaningful Use Requirement.¹³ The standard specifies the usage of controlled terminologies, and query and reply formats. Using a service-oriented architecture, the basic workflow is as follows: 1) a standardized query is submitted as a knowledge request to the Infobutton Manager; 2) the Infobutton Manager interprets the clinical context within the request and matches against available resource profiles; 3) once matched, the Infobutton Manager replies with the Uniform Resource Locator (URL) to any matched resources (see top section of Figure 1).¹⁴ Depending on the receiving application, the user may be presented with the resources’ URL or the content fully rendered. Although Infobutton is designed to be flexible for local adoption, most accessible resources are developed externally and published by third-party content providers.¹⁴ Local content is not accessible through Infobutton until a resource context profile is defined by indexing with standard terminology.^15,16 OpenInfobutton, an open-sourced implementation of the Infobutton standard, includes a Librarian Infobutton Tailoring Environment (LITE) to ease the creation of context profiles.¹⁴

Figure 1.

Current UUHC Information access paths for internal and external resources

Information retrieval problem at UUHC

University of Utah Health Care (UUHC) is an academic, regional healthcare system. UUHC consists of both inpatient hospitals and outpatient clinics serving patients in Utah and surrounding areas. Since 2014, Epic has been the electronic health record (EHR) in the inpatient and outpatient settings. The Epic system includes an Infobutton solution called ClincKB. OpenInfobutton serves as the Infobutton Manager for Epic’s Infobutton requests. Users can initiate an Infobutton query by clicking an icon next to a discrete patient data field such as a diagnosis, lab result, or medication. The query is then submitted to the OpenInfobutton. OpenInfobutton then aggregates and returns resources from third-party content providers such as UpToDate, Micromedex and Karma. Like most Infobutton implementations, accessing an Infobutton requires that a provider first to be signed into Epic, search for a patient’s record, find the relevant discrete data with an Infobutton icon, and then click on the icon to query for the references. To date, content developed locally is not part of the result set. For locally developed content, UUHC uses Microsoft’s SharePoint, which also serves as a collaboration space for all workforce teams (see Figure 1). Naturally, searches in SharePoint only return locally developed content.

Many approaches have been tried to meet the information needs at the point of care. Early on, static documents were compiled into physical binders and distributed to each nursing unit within the medical facilities. Access and updates proved to be cumbersome. A less physically-bound approach was implemented by adding static links to the EMR’s toolbar menu. However, the number of searchable links became unmanageable as the number of documents grew, and the linked guidance became outdated. Another approach used links within Epic to redirect users to SharePoint. While this method did allow providers to search for local content, the search results often included clinically less relevant documents. Another approach was adding resource links to Best Practice Alerts (BPA) within Epic. This approach meant resources were only accessible after providers have performed specific steps that triggered the BPA. Often decisions were already made and alerts were ignored.

Using Infobutton to access care pathways poses another challenge. Since Infobutton is designed to serve relevant resources within clinical contexts,¹¹ many resources are only available after the provider has established a clinical context by making some clinical decisions. Conversely, care pathway documents often are needed before decisions are made. One organization added a search box to their Infobutton result page for their providers to find resources beyond the scope of the established context. They have found that providers used this search box more than half the time.¹⁷ Their finding demonstrated that the need for a more flexible search was greater than expected. Similarly, at UUHC, even with the availability of Infobutton and SharePoint, providers still have difficulty accessing institutional guidelines and content. A new approach is needed to leverage the relevance of Infobutton search results while providing the flexibility of free searches for both internal and external content.

Objective

Our long-term goal is to utilize the Infobutton standard and provide users access to both local and external content at the point of care even before the establishment of a patient’s context. Our specific objectives for the work described in this paper were to a) define major requirements to provide users more flexible access, b) design and develop a prototype solution, and c) evaluate strengths and limitations of the prototype and propose next steps for evaluation and development.

Define major requirements

During 2015, a team of informatics graduate students collaborated with a multidisciplinary team of clinicians and IT hospital operations staff responsible for the EHR and enterprise-wide document control. The team focused on the challenge of implementing care pathways and communicating recommended guidance. After performing user testing of clinical alerts associated with the care pathway guidance,¹² the team reviewed the literature and started to document requirements particularly focused on making information available at the point of care. The team reviewed the current knowledge workflow within the organization and determined that a custom solution may meet that need. After several meetings with stakeholders responsible for document control, quality control, and clinical care, the following major requirements were identified:

Functional requirements

• Providers should be able to access care pathways within EHR: Since providers began using Infobutton to access references, the solution should allow providers access to locally-developed care pathway documents using Infobutton. Infobutton access makes it easier for providers to search for these documents.

• Providers should be able to generate custom Infobutton queries at the point of care: The effectiveness of Infobutton depends on the precision of the resource context profiles. However, because the context is defined with high specificity, the reference often can only be accessed after a matching context is established. Of course, generalizing the context profile would return more results, but it would also decrease precision.¹⁵ Instead of generalizing the context profiles, the solution should enable the user to customize the query.

• Providers should be able to search resources by free-text: One of the difficulties in formulating Infobutton queries is using relevant controlled terminologies. Free-text search shifts the burden of term selection from the user to the system.¹⁷ The solution should allow providers to perform free-text searches.

• Providers should be able to access both internal and external resources from a single tool: Outside of Infobutton, UUHC providers use SharePoint to search for internal documents. For external references, providers must remember the appropriate content provider’s website. Since this multi-portal approach has been a hurdle in care pathway implementation,⁶ the solution should search and aggregate both internal and external content, forming a single point of access.

• Providers should be able to access the tool from anywhere: Allowing access to reference materials independent of an EHR is important. In fact, most medical reference content brokers include searches on their websites or mobile applications. Conversely, searching for resources indexed within Infobutton requires multiple logins to access the organization’s EHR through a secure network. Separating protected health information from openly available references allows searches from any Internet-enabled device and may lead to wider dissemination of best practices.¹⁸ Therefore, the solution should be accessible from inside and outside of the EHR.

User Interface design requirements

An effective search engine should be simple to use, provide useful feedback and display accurate results with meaningful metadata to help users select the most relevant results.¹⁹ With these goals in mind, we identified the following user interface (UI) related requirements:

• The UI should be fast, simple and easy to use: Ideally, users should be able to use it without explicit instruction. The layout of the website should direct users to the entry point of the workflow. The user interface should be responsive, intuitive and fast in returning results.

• The solution should provide meaningful feedback: The current appearance of the Infobutton icon does not indicate if a locally developed resource exists. Anecdotally, some users hesitate to use Infobutton because it may detract from their workflow without gaining any useful information. An effective search engine should provide feedback even before the query is issued.¹⁹ Since providers and the institution may consider internal content to be more relevant, the solution should give an indication if the query will return any local content.²⁰

• The system should provide customizable autocomplete ranking for more relevant results: Autocomplete had been the most used Google Search feature. The selection of the search term that affects the accuracy of search results is heavily influenced by the entry’s ranking.²¹ With the promotion of a certain autocomplete suggestion, UUHC would be able to deliver relevant resources more accurately.

Prototype development

To build within the Infobutton ecosystem, two parallel efforts were required: 1) identify resources requested by clinicians in a primary care setting that are stored in a location accessible by URL, and then index the resources’ URLs using LITE and creating their resource profiles; and 2) develop a custom search engine to initiate an Infobutton knowledge request and present the resulting URLs of the resources.

Identify and index resources using Librarian Infobutton Tailoring Environment (LITE)

Resources were selected two ways. We included four care pathway diagrams recently developed by UUHC clinicians for knee pain, concussion, and seizures. We also included 14 resources selected by a lead pharmacist and a nurse manager in a UUHC community clinic. These resources were accessible by URL and included because they were either frequently used or desired to be accessible. Most of the sample resources identified (n=16) currently reside in UUHC’s internal SharePoint server. Two are external resources (Table 1).

Table 1.

Description of resources curated and indexed using the UUHC Infobutton LITE application

Title of Resource	Resource Type	Resource Format	Internal or External
Acute Knee Pain Pathway - traumatic	Care Pathway	PDF	Internal
Acute Knee Pain Pathway - non traumatic	Care Pathway	PDF	Internal
Concussion Pathway Diagram	Care Pathway	PDF	Internal
Seizure Care Pathway Algorithms	Care Pathway	PDF	Internal
Chest Pain Workflow - Community Clinic	Care Pathway	DOC	Internal
Guideline: Kidney Transplant Inpatient Management	Care Pathway	HTML	Internal
Headaches in Pregnancy	Care Pathway	HTML	Internal
Guideline: Pulmonary Embolism Care Pathway Algorithms	Care Pathway	HTML	Internal
Guideline: Inpatient Thrombosis Service Pharmacist Anticoagulation Management Protocol	Care Pathway	HTML	Internal
Hypertension: Clinician Guideline Summary	Care Pathway	HTML	External
Adult Blood Pressure Measurement	Clinical Task	HTML	Internal
Intravenous (IV) Medication Policy and List	Clinical Task	HTML	Internal
Warfarin Dosing	Medication	HTML	External
Alternatives to nadolol	Medication	HTML	Internal
CDC Hand Hygiene Patient Brochure	Pt Education	PDF	Internal
MyChart FAQ	Pt Education	DOC	Internal
Medication Refill	Pt Education	HTML	Internal
Patient Complaint Process	Pt Education	PDF	Internal

The resources represented an array of references requested by clinicians working in outpatient primary care settings. Ten of the resources were care pathways and clinical guidelines that could be used to guide clinicians in treatment planning. Four resources were patient education materials that could be used in various contexts. Two documents addressed specific clinical tasks (i.e., blood pressure measurement and IV line care) that may be useful as a reference for interns and students outside of a single patient’s context. Two additional documents related to medication administration and guidance that may be useful before a physician places an order. Currently, the 16 resources that reside in SharePoint can only be accessed by URLs after user authentication has been established, and after searching the site for the resource.

Independently, two informatics graduate students assigned standardized codes that should be used to index the resources in LITE according to the HL7 specification, including for example SNOMED CT codes for the main search criteria and other code systems for the performer, encounter, and task context properties. The students had access to the specification and experience with clinical-related controlled terminologies through their informatics course work. The codes were then reviewed by an informatics research faculty member (author CS) with extensive experience in controlled terminologies, followed by discussions with the two students to reconcile differences. After the list of codes was finalized, the two students created context profiles for each resource using LITE. Note that LITE has functionality that allows the user to select the major concept heading for the “MainSearchCriteria” element, and will then populate additional MainSearchCriteria with the children of the major concept heading based on hierarchies in SNOMED CT. For those resources that were not related to a particular disease process (such as the Patient Complaint Process Form), the “MainSearchCriteria” element was left unpopulated.

Design and Develop the Prototype

The design of the custom search engine was based upon service oriented architecture and consisted of three parts:

1. A front end application allowed for user input and submitted the input to the server for suggestions.

2. A backend server received user input, queried the database, and replied with appropriate suggestions.

3. A custom database contained all the available resource titles and controlled terminologies for suggestions.

The prototype was named Melinda. Its focus was to help a user easily formulate an Infobutton request using an autocomplete function and submit the request to the Infobutton Manager. Figure 2 illustrates the system’s components and their interactions with the Infobutton Manager. The front-end user interface was developed using Angular. Django was chosen as a web framework for the backend server because of its ease of in prototyping. A SQLite database contained the resource titles and the set of standardized terms and associated codes used for matching by Melinda. Melinda is hosted by Heroku as www.Melinda.tech

Figure 2.

Proposed Design of Infobutton Search Engine Information Process

The terms used for user-input matching came from two sources. First, we downloaded the “CORE Problem List Subset of SNOMED CT” from the National Library of Medicine UMLS Terminology Services²² and loaded the 6,166 concepts into the matching table. We selected this source because the complete list of terms in SNOMED CT is too large and many terms would not be relevant. This subset of most used terms to represent clinical problems seemed sufficient to seed the system for the prototype. Second, we used a new service recently-developed for our use in the OpenInfobutton Manager that allowed Melinda to directly access and download the standard codes assigned for the MainSearchCriteria in the resource profiles. We loaded these codes into the matching table as well. Therefore, each row in the matching table contained the term, the code, and the Object Identifier (OID) for the corresponding code system.

The matching process has three major steps. Step 1: As a user starts typing in the text box, the front-end application takes the user’s input and submits the input for matching. Step 2: The server matches the input against the terms in the matching table as well as the titles of the indexed resources. The matching is done by tokenizing the user’s input into list of words and matching them with the terms in the matching table. Step 3: The server replies with suggestions consisting of terms and/or resource titles. The replies with terms include the code and code system required for an Infobutton request. The replies with resource titles include the resource URLs for direct Ajax calls. The suggestion ranking is customizable in Melinda’s database, allowing an enterprise to prioritize internal versus external resources. Any entry that is associated with locally-developed content is displayed with an icon as shown in Figure 3.

Figure 3.

Melinda’s user interface as user first types in the text box

The response process has several steps depending on the user’s selection. If the user selects a term from a standard terminology, Melinda will build an Infobutton request with the associated code and submit the request to the Infobutton Manager. Then, Melinda parses the resulting JSON object from the reply, sorts the URLs by the source of the content, and displays the results. In contrast, if the user selects a resource title, Melinda extracts the URL and displays the link directly to the user, bypassing the Infobutton request-reply workflow altogether. The results are displayed to the user organized by the source of the resource. The order of the sources in the display is a customizable feature. For each result entry, the title, URL and last update date are displayed as shown in Figure 4.

Figure 4.

Melinda’s display of results, showing the metadata including title, URL, and last update date

Strengths and Limitations of the current prototype

Strengths

• Users have a single point of access for both internal and external content: Once internal content was indexed within the Infobutton Manager, relevant (i.e., matching) internal resources were included in the Infobutton reply along with relevant external resources in a single page. Users were able to access both internal and external resources from a single application.

• Users can perform search outside the current patient context: With Melinda, clinicians now can perform any searches without the need to first establishing a patient context.

• Users can perform custom searches at the point of care: Melinda’s autocomplete suggestions allows providers the flexibility to search any resource, even those that were without MainSearchCriteria populated in their profiles. This added flexibility allows content authors to define the resource profiles as precisely (or as generally) as needed without hindering access to a resource.

• Users can access Melinda anywhere: Since Infobutton context profiles were accessible publicly, and Melinda was hosted on a public domain, the query result was accessible to anyone without the burden of logins. Moreover, Melinda can detect device display size and provide navigation layout appropriate for small mobile devices, tablets, or full desktop display. Screenshots of the interface rendered on a mobile device are shown in Figure 5.

• Finer control of information distribution for the organization: Melinda’s autocomplete suggestion and result rankings are both customizable. The sorting order allows UUHC to sort most relevant and targeted information to the top, thus allowing providers easier access to common organization-specific resources. Furthermore, many accreditation programs, such as ISO9001,²³ require healthcare organizations to establish a policy update and access procedures. This approach may be part of such an established system.

• Better user experience: The three principles of effective search engine design guided Melinda’s UI development.¹⁹ For simplicity, the single search box design was chosen to minimize confusion and distraction. Second, since locally-developed guidelines were more likely to be considered than external resources,²⁴ the suggestion list’s special icon allows users to see which searches would return locally- developed content before the search was performed. Finally, the title, URL and updated date and time associated with the resources help the user determine the relevancy of the result.

Figure 5.

Melinda added as a shortcut on an iPhone, with a screenshot of the user interface for both user input and search results

Limitations

• Possible user confusion if similar terms from different coding system return different resources: To ensure adequate matches, system administrators may include terminologies with overlapping domains of clinical content. As a consequence, users may be presented with a set of similar terms that return different resources when used in a query. For example, if terms from SNOMED CT and ICD-10 were loaded into the matching table and a user inputs “knee pain”, both “Knee Pain (findings)” from SNOMED CT and “Pain in unspecified knee” from ICD10 would be presented. Depending upon the MainSearchCriteria indexed in the resource profiles, each term may return different results.

• Lack of full integration into EHR: Currently, the prototype was only a proof of concept. While it was functional, the lack of full integration with Epic means access to the tool remains isolated from Epic. Within Epic, access to care pathways continues to be Infobutton icons or the dedicated link to SharePoint. The theorized benefits of custom search by Melinda within the EHR can only be realized after UUHC Epic’s ClincKB environment is configured to direct requests to Melinda.

• Limited context tailoring: Separating the Infobutton queries from protected health information introduced one major drawback: the user now must re-establish the context manually for Infobutton. When forming the request, even though Melinda could search by the most used Infobutton resources criteria (i.e. mainSearchCritera¹¹), the absence of other contextual information may diminish the relevance of the search results¹⁵. Soliciting for these additional parameters would require additional user input which the current simple UI design does not yet accommodate.

• Lack of free-text search: The quality of Infobutton queries rests on the use of standard terminologies, particularly a standard codes’ Universally Unique Identifiers (UUIDs). To this end, Melinda supplied standard terms (with associated codes) for the user to select. In turn, Melinda converted the term to its corresponding UUID to make a request. In essence, the search box is not a true free-text search box but an expanded picklist. This approach limits the flexibility of free text searches, a feature commonly used by other external content providers. Future enhancements could address this need.

Even with these limitations, adding Melinda to the Infobutton framework may expand the power of Infobutton to other clinical decision support solutions. Melinda met many of the initially-identified requirements (Table 2).

Table 2.

Requirements of the Infobutton search engine and their fulfillment status by the prototype.

Requirements:	Requirement Source: (Literature, UUHC problem analysis or Both)	Is the requirement met in the current prototype?
Functional requirements- The User should be able to:
…access care pathways within EHR	UUHC Analysis	Not yet implemented in production Infobutton manager
…generate custom Infobutton queries at the point of care	Both	Partial - only MainSearchCriteria is used
…search resources by free-text	Both	Not Met
…access both internal and external resources from a single tool	UUHC Analysis	Met
…access the search tool from anywhere	Both	Partial - accessible outside of EMR only.
User Interface requirements - The system should:
…be fast, simple and easy to use	Both	Not yet evaluated
…provide meaningful feedback	Literature	Met
…provide customizable autocomplete ranking	Literature	Met

Future work

Evaluation

The usability and functionality of Melinda needs to be evaluated more formally. First, Neilson’ usability heuristic criteria should be applied to evaluate Melinda’s usability before provider end user feedback.²⁵ After most of the usability defects and issues are addressed, we should then perform user studies with five to 10 providers who represent the target audience for this application.²⁶ For example, the user study should include physicians, pharmacists, and nurses in the outpatient primary care setting during the first phase of testing. These evaluations will provide input for enhancements and guide further evaluation plans before Melinda can be implemented in a production setting. Once Melinda can be implemented in a production environment, on-going monitoring should be carried out to assess usage, satisfaction, system response times, and the relevance (i.e., predictive value positive) of terms presented to the user based on selections made by the user. Ongoing feedback may be solicited with the use of a simple feedback button.

Enhancements

The following future enhancements can be built upon the current framework:

• More context awareness: The Infobutton Standard allows for use of other context information that Melinda is currently not gathering. With additional context information, the system may be able to learn to map frequent user input to the appropriate standard terminology (e.g., ‘K’ for Potassium level). Of course, such features will require a machine learning middleware and an efficient user interface with a feedback loop.

• Encapsulate Melinda into a web service: Minor customization of Melinda could convert the web page to a web service that passes Infobutton requests along to Infobutton Manager. As a web service, Melinda could also replace the current Infobutton responder page and unify the interface between Infobutton icon access and search page access. As a web service, Melinda could integrate more fully and easily with an EHR.

• Security: While the resources at UUHC were protected behind SharePoint’s user authentication, the indexes and metadata could be accessible without user authentication, allowing open access to Melinda. If security were needed, single sign-on technology, such as LDAP or OAuth might be beneficial to free the user from having to remember yet another secure identity.

• Individual accounts: The framework design could also be leveraged as a mobile app. If user accounts were implemented, a mobile app might be built to include advanced features such as push notification and user feedback. Melinda could query a provider’s schedule and calendar to present needed resources as a custom reading list based on chief complaints of patients upcoming in their clinic. User’s interaction tracking for dynamic page ranking may be added as a well.

Conclusion

We identified key requirements for a system to support the clinician’s needs to access clinical guidelines that were developed internally and externally both from within and outside an individual patient’s clinical record (i.e., both with and with clinical context). A prototype was developed to demonstrate the feasibility and to study further the system and user requirements for full implementation. While the benefits may seem promising, the limitations we uncovered would need to be addressed in future development. This research addresses a major gap in the current strategy for accessing relevant and updated information important for clinical care.