Implementations of the HL7 Context-Aware Knowledge Retrieval (“Infobutton”) Standard: Challenges, Strengths, Limitations, and Uptake

Abstract

To support clinical decision-making,computerized information retrieval tools known as “infobuttons” deliver contextually-relevant knowledge resources intoclinical information systems.The Health Level Seven International(HL7)Context-Aware Knowledge Retrieval (Infobutton) Standard specifies a standard mechanism to enable infobuttons on a large scale.

Objective

To examine the experience of organizations in the course of implementing the HL7 Infobutton Standard.

Method

Cross-sectionalonline survey and in-depth phone interviews.

Results

A total of 17 organizations participated in the study.Analysis of the in-depth interviews revealed 20 recurrent themes.Implementers underscored the benefits, simplicity, and flexibility of the HL7 Infobutton Standard. Yet, participants voiced the need for easier access to standard specifications and improved guidance to beginners. Implementers predicted that the Infobutton Standard will be widely or at least fairly well adopted in the next five years, but uptake will dependlargely on adoption among electronic health record (EHR) vendors. To accelerate EHR adoption of the Infobutton Standard,implementers recommended HL7-compliant infobutton capabilities to be included in the United States Meaningful Use Certification Criteria EHR systems.

Limitations

Opinions and predictions should be interpreted with caution, since all the participant organizations have successfully implemented the Standard and overhalf of the organizations were actively engaged in the development of the Standard.

Conclusion

Overall, implementers reported a very positive experience with the HL7 Infobutton Standard.Despite indications of increasing uptake, measures should be taken to stimulate adoption of the Infobutton Standard among EHR vendors. Widespread adoption of the Infobutton standard has the potential to bring contextually relevant clinical decision support content into the healthcare provider workflow.

1 INTRODUCTION

Health providers frequently have information needs in the course of patient care, a large percentage of which are left unanswered[1-5]. Unaddressed knowledge gaps are among the main causes of errors in the health care system [6-8]. Computerized information retrieval tools known as “infobuttons” provide seamless access to contextually-relevant knowledge resources within clinical information systems [9],[10]. Infobuttons are a promising approach to support clinical decision-making by assisting provider and patients to effectivelyand efficiently meet their information needs [11],[12].

Infobuttons use the context of the interaction between a user and a clinical information systemto predict the information needs that are most likely to occur and to retrieve content from online knowledge resources that may address these needs. Context can be represented in terms of a set of attributes that describe 1) the patient (e.g., gender, age); 2) the clinical information system user (e.g., discipline, specialty, preferred language); 3) the task being carried out in the clinical information system (e.g., order entry, problem list review, laboratory test result review); 4) the care setting (e.g., outpatient, inpatient, intensive care); and 5) the clinical concept of interest (e.g., a medication order, a laboratory test result, a problem).

To facilitate the integration between clinical information systems and online health knowledge resources, the Health Level Seven International (HL7) Clinical Decision Support Work Group has developed the Context-Aware Knowledge Retrieval Standard, more commonly knownas the Infobutton Standard[13]. One year after its publication, the Infobutton Standard is being increasingly adopted by various organizations.

The overall goal of this study was to examine the experience of organizations that implemented the HL7 Infobutton Standard, including health care organizations, health information technology (IT) developers, and knowledge publishers. More specifically, we assessed the following topics: 1) The challenges that organizations faced in the course of implementing the standard; 2) the perceived benefits from adopting the standard; 3) strengths, limitations, and future enhancements; 4) perceived likelihood of widespread adoption; and 5) measures to accelerate adoption.

2 BACKGROUND

2.1 Infobutton managers

Infobutton managers are decision support brokers that facilitate the integration between clinical information systems and knowledge resources [14],[15]. Based on a set of context attributes captured by a clinical information system, infobutton managers anticipate the information needs that a health care provider or patient may have in a particular context and then retrieve content from a subset of relevant resources that are configured in the infobutton manager knowledge base. In addition, infobutton managers maintain mappings from their internal models to non-standard knowledge resource application program interfaces (API).

2.2 Impact of infobuttons on clinician decision-making

A few studies have assessed the impact of infobuttons on clinicians’ information needs and clinical decision-making[11],[12],[16].Results of these studies indicated that 1) when clinicians use infobuttons, they find answers to most of their medication-related questions [11],[12]; 2) infobutton-mediatedinformation-seeking sessions are on average 35 seconds long [12]; 3) clinicians reported decision enhancement or learning in more than half of the infobutton sessions[12]; and 4) clinicians reported a high level of satisfaction with infobuttons [16].Though the results of these studies suggest that infobuttons should be a broadly available clinical decision support (CDS) capability in clinical information systems, the lack of a standard to facilitate the implementation of infobuttons has limited the adoption of this capability on a large scale.

2.3 Why did we need a standard?

Without a standard the scalability and effectiveness of infobuttons are significantly limited. First, in the absence of a standard, clinical information systems and infobutton managers need custom integration with each distinct knowledge resource. In a standards-based environment, the need for custom development is significantly reduced and integration can be achieved on a large scale even in the absence of an infobutton manager.

Second, a standard enables clinical information system developers to offer their customers the option to integrate with one or more external infobutton managers through the same standard mechanism. This approach could enablea “best of breed” selection of clinical information system components and a centralized mechanism for managingknowledge resources that are integrated through infobuttons. This is particularly important in heterogeneous environments that encompass a myriad of clinical information systems, for which it is desiredto provide common and consistent infobutton capabilities across information systems and care settings.

Third, and perhaps most importantly, the lack of a common context information model limits the expressiveness of context in infobutton interactions to the few attributes that happen to be shared between the involved components and typically with no support for standard terminologies. On the other hand, a shared context information model establishes a lingua franca that guides implementers towards a common set of standard context attributes and values.

2.4 The HL7 Infobutton Standard

The HL7 Infobutton Standard consists of three specifications.The first of these specifications, entitled Context-Aware Knowledge Retrieval (Infobutton), Knowledge Request Standard, was published in May 2010 as a normative ANSI/ISO HL7 International standard[17]. This specification provides a context information model based on the HL7 Version 3 Reference Information Model (RIM) [18]. This information model serves as a reference for different implementation formats, such as URL (Uniform Resource Locator) and XML (Extensible Markup Language).

The second specification, also published in 2010, is an implementation guide called URL-Based Implementations of the Context-Aware Information Retrieval [19].Thisimplementation guide describes knowledge request implementations over the Hypertext Transfer Protocol (HTTP). More specifically, it specifies the URL parameter names and values (Table 1) that clinical information systemsare expected send to knowledge resources directly or through an infobutton manager (Figure 1). The URL parameter names and values are directly obtained from the normative context information model. While the URL-based implementation guide specifies a standard knowledge request, it does not specify a standard knowledge response mechanism for knowledge resources and infobutton managers. Most URL-based implementations respond to knowledge requests with a Web page in HTML format.

Table 1.

URL context parameters, along with a description and recommended code systems.

URL parameter namea	Description	Code systems
task context	The action the user is performing in a clinical information system when aknowledgerequest is triggered (e.g., order entry, laboratory results review, problem list review)	HL7 ActCode
main search criteria	The main clinical concept of interest in aknowledgerequest (e.g., a medication, a laboratory test result, a problem)	Medications: RxNorm, NDC; problems: ICD, SNOMED-CT; laboratory test results: LOINC; procedures: CPT, SNOMED-CT
severity observation	Interpretation of a laboratory test result (e.g., high, low, abnormal, normal)	HL7 severity observation codes
Subtopic	A subdomain of interest related to the main search criteria (e.g., dose, contraindications, etiology, differential diagnosis)	A set of MeSH and SNOMED-CT codes
gender	The patient’s gender	HL7 administrative gender
age	The patient’s age as a value and a unit	N/A
age group	The patient’s age in terms of a coded age group	MeSH age groups
performer	Indicates whether the infobutton user is a provider or a patient	PROV = provider; PAT = patient
performer discipline	The provider’s discipline (e.g., nurse, physician, care manager)	NUCC (National Uniform Claim Committee) Health Care Provider Taxonomy
performer language	The user’s preferred language	Tags for the Identification of Languages - IETF (Internet Engineering Task Force) 3066
information recipient	Indicates whether the information consumer is a provider or a patient	PROV = provider; PAT = patient
information recipient language	The information consumer’s preferred language	Tags for the Identification of Languages - IETF 3066
encounter	The type of care setting where care is being provided (e.g., inpatient, outpatient, emergency room)	HL7 Act Code
service delivery location	Physical location where care is being provided	N/A

^aThe list is not exhaustive and parameter names were simplified to improve readability. An official list of parameter names is available in the URL-Based Implementations of the Context-Aware Information Retrieval Implementation Guide.

Figure 1.

URL-based infobutton implementation architecture. The solid lines (steps 1 and 2) represent standard knowledge requests according to the URL-based implementation guide. Dashed lines (step 3) represent non-standard knowledge responses, typically HTML. Knowledge requests can be mediated by an infobutton manager, which may communicate with several knowledge resources (steps 1 and 2); or be submitted directly to a knowledge resource (step 1). The callout provides a simplified sample knowledge request in which a physician, reviews a male, 77 year-oldpatient’s problem listwith bacterial pneumoniaand the patient has been admitted to aninpatient setting. The physician requests specific knowledge content related to therapy.

In January 2011, a third specification called Context-Aware Knowledge Retrieval, Service-Oriented Architecture (SOA) ImplementationGuide was released as a draft standard for trial use [20].This specificationsupplements the URL-based implementation guide by specifying a standard knowledge response format for knowledge resources and infobutton managers based on the IETF Atom Syndication Format[23]. In addition, this document specifies SOA-based context-aware knowledge retrieval implementations over the SOAP (Simple Object Access Protocol) protocol[21] and the RESTful (Representational State Transfer) software architecture style [22].Implementers of the URL-based specification can transition to a SOA-based implementation without major disruption and the two implementations can coexist in the same product.

3 METHODS

To answer the study questions, we conducted a cross-sectional study that included an online survey followed by in-depth phone interviews with members of healthcare organizations, health ITdevelopers, and online knowledge publishers.

3.1 Eligibility criteria and recruitment method

Eligible organizations were those that have implemented, or are in the process of implementing, the HL7 Infobutton Standard. A purposive sample of healthcare organizations, health IT vendors, and knowledge publishers was recruited through the following methods:

1) Two e-mails submitted to the HL7 Clinical Decision Support Working Group(CDS WG) official discussion list. All activities related to the development of the Infobutton Standard are routinely posted to this list, including conference call announcements, meeting minutes, questions, and draft specifications. The list is open to the public and currently has 726 members from a variety of organizations and countries. Organizations that are involved in the development or implementation of CDS standards usually have representatives that subscribe to the discussion list.

2) Oral announcement made during one of the CDS WGwork sessions at the May 2011 HL7 Working Group Meeting (WGM). HL7 WGMs are attended by a broad representation of national and international healthcare and health IT organizations. Issues related to the Infobutton Standard are routinely discussed during the CDS WG sessions.

3) Direct e-mails to members of organizations that did not respond to the first two recruitment strategies, but were known by the co-authors to have implemented the Infobutton Standard.

4) During in-depth interviews, study subjects were asked if they knew any other organization that could be interested in participating. Members of these candidate organizations were invited to participate by e-mail.

Individuals who replied to one of these recruitment strategies were later sent an automated e-mail invitation with a description of the study and a link to complete the online survey. Participants who completed the online survey were then contacted by e-mail to schedule a one-hour in-depth phone interview.

3.2 Online survey and in-depth interview script

First drafts of the survey and in-depth interview script were developed by one of us (HS) and then iteratively refined by a subset of the co-authors (GDF, JJC, CC, SMM) through e-mails and conference calls. Both instruments were piloted by three co-authors (JJC, CC, SMM) who were also subjects in the study. Minor changes were made after the pilot to obtain the final version.

The survey contained questions about organization demographics, implementation status and timeline, implementation approach, and infobutton parameters supported. In addition, slightly different questions were presented depending on the kind of implementation. For example, electronic health record (EHR) system developers were asked to identify the EHR modules in which infobuttons have been placed, while knowledge resource publishers were asked about their strategy regarding the use of coded data for content retrieval. The survey was implemented by one of us (GDF) using REDCap electronic data capture tools hosted at the University of Utah[24]. A copy of the survey is available in the Appendix.

The in-depth interviews explored the following topics: 1) overall experience with the standard implementation process; 2) sources of information used to understand and implement the standard; 3) challenges faced in the course of implementing the standard; 4) benefits realized by enabling infobutton functionality; 5) benefits realized by adopting the standard; 6) lessons learned from implementing the standard; 7) main strengths and limitations of the standard; 8) perceived level of standard adoption in the next five years; and 9) measures that could be taken to promote adoption. Interviewees were also encouraged to raise any additional topics that they wished to discuss.

All phone interviews were conducted by GDF, except that HS interviewed GDF. Interviews started with a brief description of the topics to be addressed, followed by a quick review of the responses to the online survey and the interview script itself. Phone interviews were recorded with a digital voice recorder. In addition, detailed notes were taken during and after the interviews. Whenever applicable, follow-up questions were posed by e-mail.

3.3 Data analysis

Descriptive statistics were generated from the survey data. From the in-depth interviews, we reviewed the recordings and notes to identify common themes that participants raised in the interviews. Themes were iteratively created and refined according to the following steps:

1) Individual comments were transcribed into a spreadsheet and organized by comment category (e.g., challenges, strengths, limitations) and by the kind of implementation with which they were associated (i.e., infobutton manager, EHR system, knowledge resource).

2) The comments within each category were sorted into clusters that appeared to convey similar high-level concepts.

3) Two independent and blinded reviewers (GDF & VH) analyzed each comment sequentially, attempting to identify common themes that were present in multiple comments. As the comments were reviewed, themes were created and iteratively refined as needed.

4) The two reviewers compared their themes and attempted to reach consensus on a consolidated set of themes.

5) The two reviewers independently assigned the consolidated themes to the comments. The process repeated iteratively until the themes were stable and no more refinement was needed.

6) Finally, the comments were reviewed and the associated themes were further refined by all co-authors via e-mail and conference calls.

4 RESULTS

4.1 Participant Demographics

A total of 17 organizations agreed to participate in the study: 6 healthcare organizations, 3 health IT vendors, and 8 knowledge publishers (Table 2). All organizations that expressed interest in participating completed the online survey and the in-depth interview. Three EHR system vendors that were known to have implemented the standard were sent a direct e-mail invitation,but declined to participate.

Table 2.

List of participant organizations.

Organization	Organization type	Implementation typea
Epic Systems	Health IT vendor	EHR
GE Healthcare	Health IT vendor	EHR
Pen Computer Systems & Hewlett Packard	Health IT vendor	EHR
Columbia University	Healthcare organization	IM
Intermountain Healthcare	Healthcare organization	IM
Marshfield Clinic	Healthcare organization	IM
Partners HealthCare	Healthcare organization	IM
University of Utah	Healthcare organization	IM
Veterans Health Administration (VHA)	Healthcare organization	EHR
American College of Physicians (ACP)	Knowledge publisher	KR
EBSCO Publishing	Knowledge publisher	KR
Elsevier	Knowledge publisher	KR
Healthwise	Knowledge publisher	KR
Logical Images	Knowledge publisher	KR
Merck	Knowledge publisher	KR
National Library of Medicine (NLM)	Knowledge publisher	KR
Wolters Kluwer Health	Knowledge publisher	KR

^aEHR=electronic health record; IM=infobutton manager; KR=knowledge resource.

4.2 Online survey

Results of the online survey are summarized in Table 3. Thirteen out of the seventeen study participants are HL7 members; over half of the participants engaged in the Infobutton Standard development process; and five of the participants are also study co-authors. Organizations released infobuttons as early as 1994. A total of 6 out of the 17 participants released their first pilot HL7-compliant implementation in 2007 for a live demonstration at the American Medical Informatics Association (AMIA) Annual Fall Symposium[25]. The other 11 participants released HL7-compliant infobuttons after 2010, when the URL-based Implementation Guide became an official HL7 International standard.

Table 3.

Answers to the online survey.

	Overall	IM	EHR	KR
	N=17	n=5	n=4	n=8
Are you or your organization a member of HL7?	13 (76%)	4 (80%)	4 (100%)	5 (63%)
Ever voted on any of the HL7 Infobutton standard specifications?	12 (71%)	4 (80%)	3 (75%)	5 (63%)
How often participates in HL7 Infobutton conference calls?
frequently	6 (35%)	2 (40%)	1 (25%)	3 (38%)
sometimes	4 (24%)	2 (40%)	2 (50%)	-
occasionally	4 (24%)	1 (20%)	-	3 (38%)
never	3 (18%)	-	1 (25%)	2 (25%)
When did you first release your HL7-compliant implementation?
Before 2010	6 (35%)	3 (60%)	-	3 (38%)
What type(s) of implementations have you done?
HTTP GET	17 (100%)	5 (100%)	4 (100%)	8 (100%)
HTTP POST	10 (59%)	2 (40%)	3 (75%)	5 (63%)
RESTful	5 (29%)	2 (40%)	-	3 (38%)
SOAP	3 (18%)	1 (20%)	-	2 (25%)
Any plans to implement any of the following specifications?
HTTP POST	1 (6%)	1 (20%)	-	-
RESTful	5 (29%)	1 (20%)	2 (50%)	2 (25%)
SOAP	1 (6%)	1 (20%)	-	-
What knowledge request attributes do you support?
patient gender	12 (71%)	4 (80%)	4 (100%)	4 (50%)
patient age	12 (71%)	4 (80%)	4 (100%)	4 (50%)
patient age group	5 (29%)	1 (20%)	1 (25%)	3 (38%)
task context	11 (65%)	5 (100%)	3 (75%)	3 (38%)
subtopic	6 (35%)	2 (40%)	1 (25%)	3 (38%)
main search criteria	17 (100%)	5 (100%)	4 (100%)	8 (100%)
severity observation	2 (12%)	1 (20%)	-	1 (13%)
Information recipient	9 (53%)	4 (80%)	2 (50%)	3 (38%)
performer	6 (35%)	3 (60%)	2 (50%)	1 (13%)
performer discipline	6 (35%)	3 (60%)	1 (25%)	2 (25%)
information recipient discipline	1 (6%)	1 (20%)	-	-
performer language	2 (12%)	1 (20%)	-	1 (13%)
information recipient language	4 (24%)	2 (40%)	-	2 (25%)
care setting	8 (47%)	3 (60%)	4 (100%)	1 (13%)
service delivery location	3 (18%)	2 (40%)	1 (25%)	-

HTTP GET (URL-based) was the most common implementation approach, which was adopted by all study participants. Five organizations (two infobutton managers; 3 knowledge resources) implemented the RESTful specification, which was recently released as a draft standard in January 2011. Another set of five organizations (one infobutton manager; two EHR developers; two knowledge resources) are planning to implement the RESTful specification in the future.

The most commonly supported infobutton parameters were mainSearchCriteria(17; 100%), patientgender (12; 71%), patient age (12; 71%), task context (11; 65%), and information recipient (9; 53%). EHR developers implemented infobuttons in several EHRs modules, such as problem list (3 out of 4), medication list (2 out of 4), order entry (2 out of 4), chief complaint (1 out of four), and alerts and reminders (one out of four). All infobutton managers, and six out of eight (75%) knowledge publishers, are able to process standard coded valuesfrom the mainSearchCriteriaparameter.

4.3 In-depth interview

A total of 20 themes were identified in the theme analysis (Table 4). The following sections describe these themes according to each of the interview topics. When opinions were consistent among the different types of participants (i.e., EHR, knowledge publisher, and infobutton manager), we use the terms “participants” or “implementers.”Dissimilaropinions among different kinds of participants are highlighted whenever applicable.Similar break down is presented regarding participants who were actively engaged in the Infobutton Standard development process vs. those who were not.

Table 4.

Themes identified from the in-depth interviews grouped by interview topic.

Information sources

Theme 1: Use of standard specifications.

Theme 2: Reliance on experts.

Challenges

Theme 3: Specification access and learning curve.

Theme 4: Underlying infrastructure and standard terminologies.

Theme 5: Competing priorities and EHR adoption.

Benefits realized by enabling infobutton functionality

Theme 6: Information delivery supports decision-making.

Theme 7: Infobutton functionality adds business value.

Benefits realized by adopting the Infobutton Standard

Theme 8: Interoperability and lower cost.

Theme 9: Infobutton Standard adds business value.

Theme 10: Improved knowledge resource quality.

Strengths

Theme 11: Simplicity.

Theme 12: Coverage, transition, and evolution.

Limitations

Theme 13: Documentation clarity and ambiguity.

Theme 14: Gaps and needed enhancements.

Future enhancements

Theme 15: Documentation and guidance.

Theme 16: Improved context representation.

Perceived adoption in five years

Theme 17: Fairly wide adoption within five years.

Measures to promote adoption

Theme 18: Infobutton Standard included in Meaningful Use.

Theme 19: Educate stakeholders.

Theme 20: Enable freely available tools and knowledge content.

Implementers, especially knowledge publishers, cited growing EHR adoption and customer request as the main drivers for adopting the Infobutton Standard. In addition, compatibility of the standard with implementers’ underlying infrastructure was commonly suggested as an enabler of adoption. The effort required to implement the standard was typically small, especially among EHR and infobutton manager developers. Overall, the typical development team consisted of two to three people working part time on the infobutton project for one to three months, including requirements gathering, programming, and testing. On the other hand, large knowledge publishers that provide a suite of knowledge resource products engaged representatives from each of these resources. The programming effort for EHR and infobutton manager developers was minimal and typically completed within one week. For knowledge resource publishers, the programming effort was slightly more intense (in the order of months), especially when content indexing had to be revisited to support standard terminologies.

4.3.1 Information sources

Theme 1: Use of standard specifications

To implement the standard, implementers used the standard specifications and/or specification derivatives developed by implementers.Overall, participants cited the URL-based implementation guide as the most useful and usable specification. In addition, implementers, especially knowledge publishers, created derivatives of the official specifications that were more targeted to their own specific implementations. This kind of documentation was created not only to guide internal development, but also to share with their consumers.

Theme 2: Reliance on experts

In general,implementers relied on Infobutton Standard experts who had been actively engaged in the standard development process.. In some cases, these experts were infobutton champions within their own organizations. In the absence of internal expertise, organizations reached out to external experts for informal or formal consultation.

4.3.2 Challenges

Theme 3: Specification access and learning curve

The InfobuttonStandard specifications are not easily accessible and the initial learning steps for beginners are difficult to overcome. One of the most important and frequent challenges faced by implementers, including those who were actively engaged in the Infobutton standard development effort, was that the Infobutton Standard and related specifications were very difficult to find. Participants used search engines to find relevant documentation, but their search would commonly return only an older draft of the specification. Participants who interacted with the HL7 ballot site, where HL7 specifications are published, found the site very difficult to navigate, especially when looking for relevant terminology assets, such as code systems, value sets, and concept codes. Implementers also found the standard documentation to be too fragmented, with several dependencies on other documents.

Participants who were engaged in the Infobutton Standard development typically found the specification easy to understand and simple to implement. On the other hand, novices mentioned several challenges, such as not knowing the initial steps and the type and depth of HL7 foundational knowledgethat was needed to implement the Infobutton Standard. Nevertheless, newcomers mentioned that once knowledge of a few basic HL7 version 3 concepts was absorbed, such as coded data types, understanding and implementing the Infobutton Standard itself was quite straightforward and required very little knowledge of HL7 Version 3.

To overcome access and comprehension challenges, several implementers, including the Infobutton Standard authors, created derivative documents that digested the official specifications and included all information needed in a single document. These derivative documents were typically shared with other parties to facilitate integration with a specific infobutton product.

Theme 4: Underlying infrastructure and standard terminologies

These challenges were more prominent among knowledge resources and infobutton managers than EHR developers. Knowledge resources had to adapt their previous content indexing and structure to support multiple standard terminologies and to respond effectively to knowledge requests. To overcome this challenge, knowledge publishers developed various strategies, such as translating incoming codes into effective search terms, indexing the entire content with standard terminologies, or both. Most knowledge resources adopted a two-phase transition approach: In the first phase, a simple translation layer was developed over an existing API. In the second phase, improvements were made to the underlying infrastructure to respond to knowledge requests more effectively. Examples of such improvements include content indexing following best terminology practices, fine tuning of search engines, intelligent processing of multiple knowledge request attributes, and developing a specialized user interface that accounts for needs of clinicians at the point of decision-making.

Terminology-related challenges were also experienced by infobutton managers, especially to enable translations from EHR codes into adequate search terms or codes supported by target knowledge resources. To overcome this challenge, infobutton managers relied on external terminology servers and services. Another challenge for infobutton managers that were developed prior to the Infobutton Standard was the need to change infobutton links within EHR clients into HL7-compliant URLs. Although HL7-compliant, these infobutton managers also needed to maintain a backwards compatible and non-compliant API, used by pre-standard EHR clients.

EHR developers reported fewer challenges with their underlying infrastructure than knowledge resources and infobutton managers. According to EHR developers, knowledge request attributes are commonly available in memory and can be easily captured by the EHR client to populate knowledge requests. The main issues were related to the pre-Web nature of most EHR systems, which imposed user interface limitations, such as custom Web browsers embedded in the client application and problems placing hyperlinked infobutton icons in the user interface.

Theme 5: Competing priorities and EHR adoption

Knowledge publishers uniformly raised slow adoption among EHR systems as a significant limitation to overall adoption. Conversely, EHR developers mentioned competing priorities, such as the need to meet the United States Department of Health and Human Services (HHS)EHR Meaningful Use Certification Criteria[26], and lack of user awareness of infobuttons as the main barriers to their adoption. On the other hand, organizations that received contracts specifically to develop infobutton capabilities or received pressure from a large customer were more easily able to raise the internal priority to enable HL7-compliant infobuttons.

4.3.3 Benefits realized by enabling infobutton functionality

Theme 6: Information delivery supports decision-making

Overall, participants believe that Infobuttons facilitate information delivery to the point of decision-making, helping clinicians and patients meet their information needs.Healthcare organizations reported increased infobutton usage over time, especially for medication-related and diagnostic test-related questions. In addition, according to study participants, studies conducted at these organizations showed that infobuttons helped clinicians meet their information needs and enhance their patient care decisions. One health care organization named infobuttons a major selling point for their new medication administration record system and observed a ten-fold increase in infobutton usage after this system went live.

Theme 7: Infobutton functionality adds business value

According to knowledge publishers, infobuttons enhance the usability and usefulness of their content in the health care workflow, which ultimately drives higher use of their products. In addition, EHR integration was consistently named as a strategic goal, aligned with knowledge publishers’ missions and values. For example, one knowledge publisher’s vision is to have their content easily available wherever clinicians make decisions. Another publisher’s mission is to support point of care decision-making and improvement of quality measures. Health care organizations indicated that infobuttons add value to knowledge resource licenses for which these organizations are already paying.

4.3.4 Benefits realized by adopting the Infobutton Standard

Theme 8: Interoperability and lower cost

Several participants indicated that the Infobutton Standard eliminates the need for developing custom APIs, significantly reducing integration costs. This was particularly important for small-size knowledge publishers, who are not able to afford building custom interfaces. For example, a smaller knowledge publisher indicated that the standard allowed them to offer an infobutton-enabled API and become a market player in this area, which would have been unfeasible in the absence a standards-based mechanism.

Theme 9: Infobutton Standard adds business value

Being able to offer infobutton functionality through a standards-based approach was generally seen as a competitive advantage among EHR vendors and knowledge publishers. For example, two EHR developers indicated that they will work only with HL7-compliant knowledge resources. EHR vendors and knowledge resources uniformly indicated that claiming compliance to an international standard adds credibility to their products and can be used as a marketing message.

Theme 10: Improved knowledge resource quality

To support clinical decision-making more effectively, most knowledge publishers had to fine tune their products. This included improving content indexing and tagging to match the standard context information model; improving the user interface with the view that the content would be used to support patient care decision-making; fine tuning search engines to offer more precise and clinically relevant results; and providing a stable API that prevents links from breaking. Knowledge publishers indicated that the Infobutton Standard provided a clear path on how to improve their underlying architecture and that the standard “raised the bar” in terms of the functionality resources are expected to provide. In general, infobutton manager developers perceived that the quality of knowledge resources did improve once these resources became HL7 compliant.

4.3.5 Strengths

Theme 11: Simplicity

Implementers particularly liked the simplicity of the URL-based implementation;it is well-received by vendors and it is easy to understand by those who are familiar with the HTTP protocol. According to a knowledge publisher, “unlike other HL7 standards, the Infobutton Standard was approachable and groundbreaking in the sense that it was implementable without the need for enormous amount of training and development.” According to an EHR developer, the Infobutton Standard is “a really good entry point for people who are new in these kinds of standard.”Participants also appreciated the fact that the Infobutton Standard is compatible with common software infrastructure and is built over a stack of understandable and widely adopted standards (e.g., HTTP, Web services, Atom), hence almost nothing needs to be developed from scratch.

Theme 12: Coverage, transition, and evolution

Implementers find that the standard provides a good balance between being overly prescriptive and too flexible. Its underlying context information model includes most of the clinically relevant attributes and covers most of the information needs. In addition, participants think the standard enables a graceful evolution to more sophisticated functionality that may go beyond the traditional infobutton concept. For example, by evolving from simple URLs to the Web services specification, knowledge resources enable client infobutton managers or EHR systems to aggregate, filter, and render knowledge responsesfrom multiple resources.

4.3.6 Lessons learned

Implementers reported various lessons learned in the course of implementing the Infobutton Standard. However, no recurrent theme was identified among the participants. Examples include lessons regarding the approach to learning the standard; the need to focus on better user experience and workflow integration; the optimal use of standard terminologies; and a different implementation approach.

4.3.7 Limitations

Theme 13: Documentation clarity and ambiguity

Most of the limitations raised by the participants were challenges associated with the standard specifications. According to implementers, these limitations contribute to slowing down the standard adoption and lead to inconsistencies across implementations. For example, while the standard specifies most knowledge request parameters as optional, some implementations process optional attributes as required ones. To address these issues, one participant suggested the development of tighter conformance criteria, perhaps in the form of IHE(Integrating the Healthcare Enterprise) profiles.¹

Theme 14: Gaps and needed enhancements

Participants had divergent opinions regarding some of the future enhancements for the Standard. A few participants requested a more expressive patient context model to improve the specificity of the knowledge retrieved, such as including pregnancy status and renal function. On the other hand, other participants counter argued that most knowledge resources would not be able to handle a more complex context information model and that such an enhancement should be deferred until more experience is gained from current implementations.A few participants would also like to see some guidance regarding security and authentication, ideally leveraging the HTTP protocol.

4.3.8 Future enhancements

Theme 15: Documentation and guidance

Overall, participants raised the need to improve documentation and provide better implementation guidance.Enhancements proposed by participants were primarily related to addressing documentation challenges as well as the gaps and enhancements described above. To improve documentation, participants suggested beginner-level introductory guidance to assist novice implementers and ease their learning curve. In addition, participants proposed the development of a quick reference guide that lists the value sets and code systems recommended by the standard.

Theme 16: Improved context representation

In order to enable more advanced functionality, a few implementers requested two main additions to the infobutton specifications: 1) Design a richer context information model, perhaps by including a snapshot of a patient’s medical record according to the HL7 Continuity of Care Document (CCD) Standard [27]; and 2) add support for JSON² (JavaScript Object Notation) as an alternate lightweight data exchange format for infobutton messages.

4.3.9 Perceived adoption in five years

Theme 17: Fairly wide adoption within five years

Overall, participantsexpressed a positive attitude regarding the future adoptionof the Standard. Participants perceived that adoption has been increasing and that there are driving forces that should accelerate adoption. .However, a common concern among knowledge publishers was the strong dependency on a larger EHR adoption of the Infobutton Standard. Nevertheless, most participants believe that the standard will be widely or fairly well adopted in the next five years. For example, a knowledge publisher indicated that all EHR developers that they are dialoguing with either have or are currently working on HL7 compliant infobutton capabilities. Participants also mentioned emerging driving forces that should help accelerate adoption, including: 1) Broader EHR adoption driven by Meaningful Use certification and competition, especially now that a few large EHR vendors have released HL7-compliant infobutton capabilities; 2) increased awareness of the Infobutton Standard and its strengths; and 3) requirements imposed by HL7-compliant EHR vendors on knowledge resources to adopt the standard. For example, two EHR developers indicated that they will prioritize, or even limit their options, to HL7-compliant knowledge resources.

4.3.10 Measures to promote adoption

Theme 18: Infobutton Standard included in Meaningful Use

Implementers consistently believe that the most important factor towards accelerated adoption is to include HL7-compliant infobuttons in the EHRMeaningful Use certification criteria[26].In addition, implementers suggested clarifying the definition of CDS in the Meaningful Use criteria to explicitly include infobuttons as one type of CDS for both patients and health care providers.

Theme 19: Educate stakeholders

Implementers believe that despite improvement in the last couple of years, the awareness of infobuttons and the Infobutton Standard among stakeholders is still not high enough to accelerate adoption. Participants suggested several education and promotion measures to raise awareness, such as demonstration projects, EHR user base training, success stories, presentations at large conferences, and a quick start guide.

Theme 20: Enable freely available tools and knowledge content

All types of participants suggested the need for freely available HL7-compliant tools, such as infobutton managers and knowledge resources, to facilitate implementation of infobuttons and the Infobutton Standard. For example, participants indicated that infobutton managers may help with integrating highly specialized resources so that such resources are not offered to users when their content is not relevant to the user’s specific context.

5 DISCUSSION

Interviewees represent a broad sample of industry stakeholders, including health care organizations, health IT developers, and knowledge publishers as well as for profit, non for profit, and governmental entities. Overall, the attitude of participants towards the HL7 Infobutton Standard and its future adoption was quite positive. Participants especially appreciated the simplicity of the standard and the ability to transition into a standard-compliant product by leveraging preexisting software infrastructure and tools. As a result, most implementations were done by a fairly small team with minimal software development effort. In addition, participants named several benefits realized by enabling HL7-compliant infobutton capabilities in their products. These findings suggest that the cost-benefit of infobuttons may justify a higher prioritization in the stakeholders’ roadmap as “low hanging fruit.”

The perceived simplicity of the Infobutton Standard seems to derive primarily from strategic principles that guided the development of the two Infobutton Standard Implementation Guides: 1) employ implementation technologies that are compatible with implementers’ underlying software infrastructure; 2) leverage ubiquitous Web-based standards with which most software developers are familiar and for which extensive support is available in the form of tools and infrastructure; and 3) specify an approachable and developer-friendly layer over the highly abstract HL7 RIM. As a result, software developers do not need to become HL7 RIM experts to implement the Infobutton Standard Implementation Guides. A similar approach within the HL7 community that has been gaining increasing popularity is the “greenCDA” (green Clinical Document Architecture) methodology, which allows highly complex HL7 RIM-derived XML schemas to be automatically mapped into simpler models with clinically meaningful elements and attributes names [28].

Despite the perceived simplicity, study participants still named access to documentation and the initial familiarization with the Infobutton Standard among the main implementation challenges. HL7 standard specifications are not open to the general public and to Web search engines, which makes access to these specifications particularly challenging. To overcome these challenges, implementers created their own derivative documentation for internal or customer use, but these documents are not always openly accessible and are specific to a particular organization’s implementation. Participants suggested that easily accessible, novice-friendly guidance should be made available to accelerate the adoption of the HL7 Infobutton Standard. This auxiliary documentation would not necessarily be balloted components of the standard and should be made easily accessible through a collaborative repository, such as the HL7 Wiki³. A similar, systematic approach could be taken to facilitate the adoption of other HL7 version 3 standards.

Another important challenge faced especially by knowledge publishers was related to adopting standard terminologies. Although knowledge resources can become HL7 Infobutton compliant with minimal changes to their underlying infrastructure, effective infobutton APIs rely on the use of standard terminologies that are implemented through a carefully considered set of best practices.Despite the challenge, knowledge publishers seem to appreciate the value of standard terminologies, since six out of eight knowledge publishersreported support for standard terminologies in their products.

Until recently, adoption of the HL7 Infobutton Standard has been primarily driven by academic organizations with home-grown EHR systems and by major knowledge publishers. Knowledge publishers and infobutton manager developers have mentioned slow adoption among EHR vendors as one of the primary obstacles to an overall wider adoption. Factors that may have slowed EHR adoption are competing priorities for limited development resources and a strategic decision to wait for an official and more stable version of the Infobutton Standard. Nevertheless, this study revealed signs of recent uptake among EHR vendors. First, the EHR vendors that participated in the study have expressed enthusiasm towards infobuttons and the Infobutton Standard. Second, knowledge publishers cited other EHR vendors that have implemented or are implementing HL7 compliant infobutton capabilities. Third, a recent survey among EHR vendors has also shown wide support for infobutton functionality, although the survey did not specify whether these implementations are HL7-compliantor not [29]. EHR adoption itself may also stimulate knowledge resource adoption. In our study, two EHR developers are prioritizing or limiting their integration options to HL7-compliant resources.

While pure competition among EHR vendors may be sufficient to expedite adoption of the HL7 Infobutton Standard, study participants consistently recommended HL7-compliant infobutton functionality to be explicitlyincluded in the EHR Meaningful Use criteria. Factors that support this recommendation are: 1) fairly broad adoption among knowledge publishers; 2) reliance on a fairly large and mature knowledge publishing industry, which handles most of the knowledge integration complexity; 3) recent uptake among EHR vendors; 4) scientific evidence that demonstrates the effectiveness and efficiency of infobuttons at supporting and enhancing clinicians’ patient care decision-making [11],[12],[16]; and 5) the overall perception among study participants that the implementation of HL7-compliant infobuttons is simple and cost-effective, unlike some other modalities of CDS. Study participants suggested revising the definition of CDS in the Meaningful Use certification criteria to explicitly include HL7-compliant infobuttons as one of the CDS capabilities that EHR products should support. Besides strongly accelerating adoption of the Infobutton Standard, such a revision could lead to interesting examples of large scale CDS that would serve as models for the large scale dissemination of more complex and sophisticated CDS capabilities.

To facilitate adoption and to support enhanced infobutton functionality, participants also raised the need for freely available HL7-compliant tools and knowledge resources. Examples of such tools and resources are OpenInfobutton,⁴the Librarian Infobutton Tailoring Environment (LITE)[30], and MedlinePlus Connect.⁵OpenInfobutton is an infobutton manager that was funded by the VHA Greenfield Incubation Initiative. OpenInfobutton is currently being integrated with EHR systems at the VHA and at the University of Utah andthe VHA plans to release the OpenInfobutton source code to the open source community. LITE is a user-friendly infobutton manager configuration tool that was developed initially at Columbia University and then at the National Institutes of Health Clinical Center. LITE enables users with no technical background to configure HL7-compliant infobutton managers to integrate with multiple knowledge resources. MedlinePlus Connect is an HL7-compliant API that provides access to MedlinePlus, a large collection of consumer health information developed by the National Library of Medicine (NLM). MedlinePlus Connect offers an API compliant with the HL7 Infobutton URL-based implementation guide and a Web service compliant with the SOA-based implementation guide.

These tools may help foster adoption by providing reference implementations of the Infobutton Standard as well as free content that can be integrated through HL7-compliant APIs. In particular, the recent release of MedlinePlus Connect has drawn significant attention to infobuttons and the Infobutton Standard through anHHS press release⁶ and the HHSinnovates award.⁷Since its release in November 2010 through November 2011, MedlinePlus Connect has received over approximately 1.3 million requests for targeted patient health information to its HL7-compliant API (personal communication). A list of healthcare organizations and EHR vendors that are known to be using MedlinePlus Connect is available online.⁸This is list is maintained based on information volunteered by the organizations themselves, and hence it is not complete.

Among the future enhancements proposed by participants, a recurrent topic was the desire to represent richer patient context, perhaps derived from HL7 CCDs, to support more sophisticated functionality and handle more complex information needs. Patient record summaries are becoming increasingly available and exchanged as HL7 CCDs to comply with the Meaningful Use criteria. This creates a unique opportunity for pairing these patient summaries with contextually relevant knowledge summaries that could be supported in future versions of the Infobutton Standard.

5.1 Limitations

Our study had several limitations. First, the study methods were primarily qualitative and based on a purposive sampling strategy aimed at recruiting representatives from different types of organizations, at different levels of adoption, and that could provide interesting insights to this study. Hence, it is not possible to estimate a quantitative measurement of Infobutton Standard adoption based on the results of our study. Second, the results of our study are based solely on the answers and opinions of study participants. Therefore, no conclusions can be made regarding the compliance of the participants’ products. Third, some of the study subjects are co-authors of the Infobutton Standard and co-authors of this research. Therefore, these subjects may have more optimisticopinions of the Standard than other subjects. However, the interviews did not reveal any prominent difference between the opinions of authors and non-authors.Last, and perhaps most important, we could not identify and interview any organization that attempted to implement the Infobutton Standard and failed or organizations that have decided not to implement it at all. Therefore, the study results may reflect the opinions of subjects and organizations that are naturally optimistic about infobutton capabilities and the Infobutton Standard, including overly optimistic predictions regarding the future adoption of the Standard. Yet, given the simplicity of the Infobutton Standard, it is unlikely that an organization would fail to implement it due to technical reasons. Instead, the main failure factor is likely to be failing to prioritize the Infobutton Standard in a product’s development roadmap.

5.2 Conclusion

Through an online survey and in-depth interviews with organizations that implemented the HL7 Context-Aware Knowledge Retrieval (Infobutton) Standard, we investigated the experience of these organizations in the course of implementing the Infobutton Standard.We found that implementers valued the simplicity and flexibility of the Infobutton Standard as well asthe ease of implementing it. Nevertheless, implementers had challenges accessing the Infobutton Standard specifications and takingthe initial learning steps. Implementers predicted that the Infobutton Standard will be widely or at least fairly well adopted in the next five years, but uptake will depend largely on EHR adoption.These predictions should be interpreted with some caution, since the generally positive attitude expressed by the study subjects may have been biased by a sample of organizations that successfully implemented the Infobutton Standard.Implementers also recommended that HL7-compliant infobutton capabilities be included in the Meaningful Use certification criteria to accelerate adoption of the Infobutton Standard among EHR systems. Widespread adoption of the Infobutton standard has the potential to bring contextually relevant clinical decision support content into the healthcare provider workflow.