Clinical Decision Support for Immunizations (CDSi): A Comprehensive, Collaborative Strategy.

This article focuses on the requirements and current developments in clinical decision support technologies for immunizations (CDSi) in both the public health and clinical communities, with an emphasis on shareable solutions. The requirements of the Electronic Health Record Incentive Programs have raised some unique challenges for the clinical community, including vocabulary mapping, update of changing guidelines, single immunization schedule, and scalability. This article discusses new, collaborative approaches whose long-term goal is to make CDSi more sustainable for both the public and private sectors.

Introduction

A key element of preventive care is the provision of immunizations for vaccine-preventable diseases. Over time, however, the immunization schedulea that clinicians consult has become more complex, and routine immunizations have become more numerous across a patient’s life span. This has made it more challenging to monitor and adhere properly and consistently to the guidelines. While computer-based clinical decision support (CDS) can be an effective strategy for improving the quality of care, many clinical information systems either lack CDS or are slow to keep their CDS in line with the changing guidelines.b,2–4 These changes may include new vaccine series, addition or elimination of specific vaccines by specific manufacturers, or changes to clinical recommendations with respect to specific vaccines, dose series, accelerated/catch-up schedules, or age groups.5

This article focuses on the requirements and current developments in clinical decision support technologies for immunizations (CDSi) in both the public health and clinical communities. Because of the large investment needed to develop and maintain a clinically compliant, high-quality electronic immunization schedule, as well as competing priorities for system feature development and enhancement both in the public and private sectors, a more shared approach to deploying CDSi solutions may be inevitable.6,7 As more and more clinical and public health processes and workflows come to rely on immunization evaluation and forecast, inconsistent evaluations and forecasts from different products will only serve to confuse clinicians as well as patients. Ultimately, the author believes that an open-source approach to CDSi development and support will best serve the clinical and public health communities.

Overview of Clinical Decision Support for Immunizations

As we observed in 2013, “Routine vaccination is an integral component of preventive care in the United States and has led to a dramatic reduction in the incidence, morbidity, and mortality of a number of diseases.”c For example, according to Centers for Disease Control and Prevention (CDC), “In the years following licensure of vaccine in 1963, the incidence of measles decreased by more than 95%, and 2–3-year epidemic cycles no longer occurred”d and

As the field of medicine advanced over the last century, the number of vaccine-preventable conditions grew dramatically, as did the number of routinely recommended immunizations. In the 1980s, a 5-year-old child would be up to date (UTD) with 10 doses of 3 vaccines (DTP, polio, and MMR), protecting against 7 diseases. In 2013, a 5-year-old healthy, fully immunized child would need 9 different vaccines, not counting the annual influenza dose. Those 9 routinely recommended vaccines protect against 13 diseases, and need to be administered in 28 different doses, making tracking a very challenging task.e

Information systems that include CDSi capabilities evaluate recommended Advisory Committee on Immunization Practices (ACIP) changes and update their rules and algorithms as they deem necessary. Just as CDSi capabilities differ between systems, the speed and nature of response to changing ACIP recommendations also differ based on local interpretations of the changes, impact of the changes on the particular jurisdiction (eg, some jurisdictions do not use certain vaccines), and staff availability.

The ACIP defines and publishes a recommended immunization schedule that constitutes the best practices for immunization, and it updates and refines several times per year.f The routine childhood schedule for 0-to 18-year olds has 13 separate footnotes, with as many as 13 subbullets for some footnotes. The end result is that it is difficult for providers to monitor and consistently adhere to the ACIP guidelines that are lengthy, complicated, and growing.g The process of updating a CDSi algorithm to changing guidelines involves the full system development life cycle of activities: analysis to determine what the new guidelines mean and how applicable they are, modification of the software code that guides the algorithm, and extensive testing of the new algorithm to make sure that the changes have been applied correctly and that existing rules have not been adversely affected or broken in the process.

Role of Immunization Information Systems

Immunization Information Systems (IIS), or Immunization Registries, are designed to help providers increase immunization coverage rates and were among the first to provide CDSi, which includes immunization history evaluation and immunization forecasting. Figure 1 shows the percentage of children younger than six years participating in an IIS in the United States, five major cities, and Washington, DC, in 2013.h Since it is hard to know exactly which providers perform immunizations, and in many jurisdictions reporting of immunization events to public health is not required by law or regulation, it is difficult to know exactly what proportion of providers currently interact with an IIS. However, in 2013, 39% physicians with computerized capabilities met the Stage 2 Meaningful Use objective for reporting to an IIS under the Centers for Medicare and Medicaid Services (CMS) Electronic Health Record (EHR) Incentive Programs.i

Figure 1

Percentage of children aged <6 years participating in an immunization information system – United States, five cities§, and D.C., 2013.ii

Note: Awardees in Figure 1 are state/local jurisdictional recipients of CDC 371 Program funds.ii

One of the 2013–2017 CDC IIS Functional Standards specifies that,

the IIS has an automated function that determines vaccines due, past due, or coming due (“vaccine forecast”) in a manner consistent with current ACIP recommendations. Any deficiency is visible to the clinical user each time an individual’s record is viewed.j

CDC defines CDSi as “an automated process that determines the recommended immunizations needed for a patient and delivers these recommendations to the healthcare provider.” Many IIS already meet this standard. Most CDSi software products that are deployed within IIS provide clinically accurate CDSi in accordance with the ACIP guidelines for vaccines that are routinely administered to children, adolescents, and adults. These calculations are performed for individual patient records as well as populations of patients; they include both an evaluation of the validity of each immunization in a patient’s history as well as a recommendation that indicates the date on which the next dose is due, whether the series is completed, etc.

Impact of Changes in Immunization Recommendations

Though the underlying rules instantiate the ACIP recommendations and have been recently documented through a collaborative, CDC-led national effort, the devil is still in the details, and individual providers, IIS, and even state departments of education still define rules that vary for different purposes even within a jurisdiction let alone between them. Wright et al.9 described a wide variety of activities that need to be performed to deploy CDS successfully for clinical use. ACIP recommendation changes need to be not only monitored but also evaluated and assessed since the recommendations themselves may be clinically clear but not stated in a way that is easily transformed into computer-based rules. In addition, even the clinical recommendations may not be uniformly interpreted in a consistent way requiring a medical panel of experts within each organization to review and affirm their interpretation of ACIP pronouncements.

In an effort to harmonize the outcomes of existing CDS tools used by IIS and other systems, CDC funded the CDSi project to develop new clinical decision aids for each vaccine on the children’s immunization schedule to:

Make it easier to develop and maintain immunization evaluation and forecasting products;

Ensure a patient’s immunization status is current, accurate, consistent, and readily available;

Increase the accuracy and consistency of immunization evaluation and forecasting;

Improve the timeliness of accommodating new and changed ACIP recommendations.

An expert panel was convened in 2011 to develop recommendations in three areas, including unambiguous logic specifications for the ACIP rules themselves, strategies and examples for testing algorithm behavior, and sustainability, communication, and training around the material developed by the panel. The panel initially produced consensus-driven descriptions of the rules for childhood vaccines and reconvened in 2014 to work on adult vaccine definitions.k

CDSi has both a direct clinical impact on the treatment of an individual patient and a population-level impact on a practice, a neighborhood, or an entire jurisdiction. Even though CDSi algorithms developed primarily within the public health establishment, they were created with both the clinician and epidemiologist in mind. IIS were originally developed as online, interactive applications whose primary user base was the clinician at the point of care; only more recently, the IIS have shifted to become more of a provider of data than an online application with the increase in EHR use financially incentivized by CMS. Whether deployed directly in EHR-S, accessed through public health systems like IIS, or provided by a third-party service, it is the quality and ease of use of the CDSi service that is most important.

In the remainder of the document, the work that has been done to date on CDSi implementations is reviewed. First, we will discuss the impact and scale of CDSi needs, followed by a discussion of the architecture necessary to support robust, scalable, standards-based solutions. Next the issue of CDSi knowledge engineering will be addressed. We will then discuss how EHR-S, in addition to IIS, can leverage CDSi within their systems and briefly discuss how the current marketplace for shared solutions has developed.

Population-Level Impact

As CDSi becomes more and more effective for individual patients, it will become more useful in examining populations of patients. Over time, interactive use of CDSi tools within systems will be supplemented by batch use of CDS, taking a set of person-specific data for a cohort, cluster, or geographic region and applying CDSi rules to determine if certain characteristics are present in the group. IIS provide summary statistics and assessments of UTD status primarily for pediatric and adolescent patient populations, though some focused adult surveillance is also conducted (eg, seasonal flu). These measures are used by public health agencies as part of its Assessment, Feedback, Incentives eXchange (AFIX) quality improvement program and by insurance companies as part of their Healthcare Effectiveness Data and Information Setl quality metrics. The EHR Incentive Programs have added requirements to report clinical quality measures to CMS, including childhood immunization status.m

Coverage assessments have a strong dependence on CDSi services to be done accurately. As IIS CDSi services improve, their ability to support coverage assessment improves. But it takes more than just a good CDSi to do coverage assessments well – specialized skills are needed to ensure that data are extracted properly, processed properly, and presented properly. AFIX is more than a data activity: public health staff members typically visit provider sites in person to review their immunization coverage data and office practice/workflow, and this has a strong impact on providers. IIS will likely continue to invest in and improve their CDSi and coverage assessment capabilities beyond those of typical Electronic Health Record Systems (EHR-S), given other priorities of EHR-S vendors.

CDSi Scale of Operations

CDSi has a unique clinical characteristic in that the forecast for a patient can change simply with the passage of time – no other change in the patient’s medical history is necessary (though other factors may also change, such as disease occurrence resulting in an immunity). For this reason, some systems (especially when they contain a small-to-moderate number of records) may evaluate all patients every day to ensure that records are automatically UTD in their forecast, or store a freshness date after which the most recent evaluation is considered to be expired. In other systems, other events may trigger the evaluation of the patient’s record. Most commonly, simply accessing a record triggers an evaluation. This type of on-demand evaluation obviates the need to process the entire database each day (usually overnight), but may introduce some latency as the record is called for display. In addition, some system queries might also be delayed as they would potentially trigger evaluation of a larger proportion of the database (depending on the query). As CDSi solutions become faster and more efficient, their ability to process records more quickly reduces the likelihood that processing delays access to data.

To illustrate frequency of CDSi use, the following data are presented for a large, municipal IIS. In April 2014, there were more than 5.25 million patients and 70.6 million immunizations stored in the system (an average of just over 13 immunizations per patient, though the distribution varies widely). This system is large enough that CDSi evaluation can only be done on demand by the several applications that access data for individual patient display, practice-level assessment, and aggregate reporting. During April 2014, there were nearly 125,000 patients evaluated each day, with the daily totals as low as 23,000 evaluations and as high as nearly 565,000 evaluations (Fig. 2). The data for the height of the immunization reporting season – August 2013 just before school begins – saw much higher numbers: an average of more than 250,000 evaluations each day with the daily totals as low as 43,000 evaluations and as high as nearly 870,000 evaluations.n These data include all patient evaluations, both those performed routinely by providers when viewing individual patient records and those performed by IIS staff in the course of performing surveillance activities and generating reports (this aggregate reporting probably accounts for the large peaks when they occur).

Figure 2

CDSi – distribution of CDSi patient evaluations, April 2014.

Goldberg et al.10 described nine design goals for an enterprise clinical rules service :establish a single logical service to provide CDS;

Standardize the input and output requirements for CDS;

Facilitate interoperability with external consumers through the use of healthcare standards;

Support multiple rule execution patterns;

Maintain separation between data inputs and underlying inference models;

Leave the presentation of recommendations to client systems;

Support highly scalable deployments;

Emphasize the creation and maintenance of decision support content by knowledge engineers, thus minimizing the need for software engineers;

leverage off-the-shelf rules management systems.

A More Robust CDSi Architecture

These goals are laudable and seem appropriate for an enterprise-wide service as well as a more broadly accessed inter-enterprise service. A well-designed and broadly adopted CDSi service could improve the consistency of vaccine forecasts across the IIS community. Such a well-designed and shared CDSi would allow for the separation of the core software from the underlying rules that will only minimally compromise the shared nature of the approach and embrace many of the nine design features identified above. Building upon Goldberg et al, the design goals of such an initiative might include:

The ability to support multiple immunization schedules;

The ability to simultaneously process multiple requests for CDSi;

The implementation of a fully automated testing process;

The creation of graphical user interface (GUI) tools that empower clinically oriented subject matter experts (SMEs) to update and maintain the immunization schedule without any involvement from programmers and that supports the automated testing;

That it be a self-contained module that could be deployed in diverse technical environments and accessed by other systems through a standards-based Web service interface.

The functionality of a standards-based CDSi service is displayed in Figure 3. In this example, EHR-S and other systems initiate a query to the IIS via standard Health Level Seven International (HL7) v2 messages to inquire about the immunization history and forecast for a particular patient. The IIS in turn invokes the CDSi service through a standards-based service call by passing a message structured as a Virtual Medical Record (vMR) to its standard CDSi Web service.o vMR is a concise, XML-based format for modeling and expressing clinical elements that has been optimized for CDS engines to use. It is a balloted HL7 standard. The Web service utilizes its immunization rules and the data in the vMR, including the patient’s date of birth, gender, immunization history (date and vaccine administered, or CVX, code for each vaccination administered to date to the patient), and disease indicators (for example, indication that the patient had chicken pox), to evaluate and return the validity of each immunization in the patient’s history along with one or more reasons an immunization is invalid, if it is. It also returns a recommendation for each vaccine group (eg, the date on which the next dose is due, the earliest date a dose could be given, series completed, etc.). The Web service architecture should scale to support simultaneous real-time processing of many patients submitted by one or more systems.8 It should also scale to service requests for multiple immunization schedules (eg, schedules for different jurisdictions, or different uses within a jurisdiction like clinical use and school admission use). A web-based tool with a GUI should sit alongside the CDSi Web service and enable SMEs to configure and manage the service without the intervention of software developers. Through this tool, SMEs may manage the concepts, series, and rules that are utilized by the service, as well as manage and run automated tests of the service.

Figure 3

CDSi architecture diagram (EHR-S or other systems access the CDSi Web service through an IIS).

An alternate scenario, depicted in Figure 4, allows EHR-S and other systems to invoke the CDSi service directly without the IIS intermediating in this transaction. In this case, the functioning of the CDSi service is the same as in the primary scenario as the service does not care how many systems submit service calls so long as they are authorized to do so. From the CDSi Web service point of view, there is no difference between the architectures described in Figures 3 and 4. The difference is only from the point of view of other systems receiving the evaluation and forecast: in truth, Figure 3 represents the normative scenario under Stage 3 of the CMS EHR Incentive Programs that require a certified EHR to be able to query an IIS and receive and display both an immunization history and forecast for a patient. While this is compliant with the requirements of the Incentive Program, Figure 4 represents more direct access to the CDSi service by the EHR that may be a preferable solution since the EHR could make use of features of the Web service that the IIS might not make available through the “indirect” query displayed in Figure 3. See more detailed discussion below this section (CDSi and EHR Systems).

Figure 4

Alternate CDSi architecture diagram (all systems directly access the CDSi Web service).

CDSi Knowledge Engineering

As we observed in 2013,

Development and maintenance of CDSi requires a multidisciplinary team with fairly sophisticated background and training: medical/nursing staff to understand and interpret the clinical guidelines; analytical staff to translate the medical rules into computer-accessible instructions; programming staff to code the rules and related interfaces in a programming language; testers to develop test cases and test the algorithm as it is developed; and project managers to make sure all the participants work productively together on schedule and within budget.8

For instance, development of the Immunization Calculation Engine (ICE)p open-source services involved the New York City Department of Health and Mental Hygiene, the University of Utah, the Alabama Department of Public Health, and HLN Consulting, LLC.

It is critical to understand that the knowledge underlying CDSi – the rules themselves – are distinct from any system or software that uses them to provide CDS services. The rules are the data of the system, not the system itself – what Greenes refers to as the knowledge base.11 For many in the immunization community, the CDC CDSi Logic Specification operates a gold standard for CDSi knowledge.q However, a consensus-driven specification may not satisfy all users as it is by definition a compromise for some. Even with the ongoing maintenance of the Logic Specification by CDC, there is still the need for user review and for administrative tools to be able to adjust consensus rules to accommodate local requirements. The CDC CDSi Logic Specification has two components: a document describes the approach, issues, and techniques for developing CDSi software and a set of data files for each vaccine antigen (available in both XML and Microsoft Excel) provide the data for the rules themselves. But it still requires a fair amount of effort to get from these two sets of artifacts to a working CDSi system. And some users might want additional functionality not currently included in the CDC CDSi Logic Specification.

As Goldberg et al noted, it is critically important for CDS knowledge to be developed and maintained as much as possible by SMEs and not by computer programmers. It is also important that the logic is accessible and available for alteration and improvement without programmer intervention. As an example, the open-source ICE does just that: an administrative utility provides a rich set of rule authoring and testing capabilities, but the logic itself is represented in Drools rules (what Greenes refers to as the inferencing method) that are processed by a Web service built on top of OpenCDS.r The data used by the rules is drawn from the vMR-based patient data sent to the service as an input and some externally stored, table-driven parameters related to each vaccine series evaluated (what Greenes refers to as the information model) and the resulting evaluation and forecast are also returned to the user in vMR (what Greenes refers to as the result specification). But note that the table-driven parameters are not enough: some CDSi rules and exceptions are sophisticated enough that they require more precise logic to be written in Drools. SMEs can use the administrative interface to maintain and test the rules.s

Drools rules are portable. While ICE uses them with OpenCDS, they could be used with another CDS engine or product that is capable of reading and interpreting them. Similarly, while ICE currently uses vMR as the structure for incoming patient data, it could be migrated to HL7’s Fast Healthcare Interoperability Resources or some other standard.t But there is still an issue with traceability. While ICE’s online documentation describes in verbose language meant for easy understanding each of the rules for each of the series supported by the Web service, there is no systemic connection between this textual description of the rules and their implementation.u This connection is enforced only through careful inspection and testing. Meanwhile, the CDC CDSi Logic Specification data do provide traceability through direct import of that data by antigen (not by series as ICE does) into a Web service that might be created using the Logic Specification document, but the rules themselves as detailed in the data lack any verbose explanation and are very difficult for a clinician to understand and validate. This represents a trade-off between these two approaches, though there are certainly techniques and products that could be used to enforce the traceability and connection between verbose rules and computer-accessible code.v

Greenes described three intersecting life cycles for CDS. There have been several projects that have tackled “knowledge generation, refinement, and update” for CDSi, including the CDC CDSi Project and the ICE Project described above. Several other projects have accomplished “clinical decision support method development, implementation, and refinement” including the projects listed in Table 1. The third life cycle, “knowledge content management and dissemination”, applies across a broader set of clinical activities in an organization and is largely outside of the scope of CDSi to consider.1 There is near-uniform consensus among clinicians and public health officials that there is a strong desire for CDSi that is ACIP compliant. The challenge has always been in reaching agreement on what ACIP compliance means and entails. Within the IIS community, there is increasing pressure from CDC to adopt the rules articulated in the CDC CDSi Logic Specification’s interpretation of ACIP compliance as a way to bring more uniformity to IIS CDSi nationally. In reality, individual jurisdictions often stand by their local interpretations and requirements. Within the EHR/Personal Health Record (PHR) market, it is less clear whether more uniformity is desired or will be accepted.

Table 1

Selection of CDSi Products by Category.

CATEGORY	DESCRIPTION	EXAMPLE(S)
Proprietary	Existing IIS vendors and developers have already begun de-coupling their algorithms from the rest of the system as a way to improve performance and maintainability, and/or to begin to position the algorithm potentially as a stand-alone product. These components may or may not use a standards-based way of receiving and responding to service calls.	Software Partners’ MatchMerge Decision Support Scientific Technologies Corporation’s (STC) ImmuCast™jj
Public health developed	Software developed by public health agencies is generally available to other public health agencies by interagency agreement or based on the product’s source of funding. There has been some sharing of CDSi software between agencies. These components may or may not use a standards-based way of receiving and responding to service calls.	Web Immunization Service Evaluation and Recommendation (WISER), originally developed as part of California Automated Immunization Registry (CAIR) but provided to RI KIDSNET for use as an SOA component there.
Open Source—limited licensekk	Some products – particularly commercially-developed products – are migrating to the Open Source community, but with restrictions as to how they can be used or who can use them. These components may or may not use a standards-based way of receiving and responding to service calls.	STC’s Open ImmuCast™ which is only available to public health entities or programs.
Open Source – unlimited license (see Note m)	Some products are being developed and managed in the Open Source community with unrestricted licenses for use and modification. These products may or may not come with support from a vendor or organization.	HLN Consulting, LLC’s (HLN) Immunization Calculation Engine (ICE), which is built on OpenCDS and uses Health eDecisions (HeD) standards (no commercial software dependencies). Texas Children’s Hospital’s Open Immunization Software which is supported by Dandelion Software and Research.

Notes:

Note that this product has both a proprietary and open-source version available.

Note that some open-source products may have commercial product dependencies for them to run properly.

CDSi Architecture Leverage in the Public Sector

A combination of market, financial, and technology forces are driving the IIS community toward increased development and use of shared services and the necessary standards, oversight, and best practices. CDSi has broad applicability for both public health and clinical systems, making it a good candidate for shared development and/or operations.

A CDSi service offered on a shared platform can function in a number of capacities, and even support multiple capacities simultaneously:

As a shared service: A CDSi service can be operated on a common platform and made available to multiple sets of users. If designed properly, the service can support multiple schedules for the multiple communities using the service, who will have no knowledge that other communities are sharing the service. Even management of the configuration of the service can be distributed among individuals from the communities who use it. Because invoking such a service happens irregularly during the course of the day by different systems in different time zones, sharing a platform would allow for more efficient use of aggregate services (though peak load times may be more severe). Centralized administration of at least some aspects of the service would also provide more efficiency in staffing and require fewer individuals with deep knowledge of the services.

As shared data: The maintenance of CDSi rules is a somewhat detailed and often onerous activity. The data of a CDSi service are not the patient data (which does not persist beyond a particular transaction) but the rules and terminology. A set of communities could agree to share a common set of rules in order to reduce the support burden on them and to increase the conformity to a particular interpretation of the ACIP rules. Historical versions of rules should be retained for research/analytical purposes including retrospective evaluations of immunization histories at moments in the past. A good CDSi service could be configured to support a mixed model where some communities share the rules and some define their own. Collaborative testing would ensure that all users at least had an opportunity to assess the validity of the service and suggest changes in rules if necessary.

Shared application: Some communities may choose to operate and run a CDSi service on their own infrastructure for various reasons, including performance or policy requirements. Even in this case, the use of a CDSi product that is in use elsewhere in the country, though in this case deployed locally by a project, represents good leverage of joint development and support activities. A good CDSi product allows for the rules and configuration to be exported and shared, independent of the software to accommodate local implementations. A shared capability would be useful in facilitating the distribution and support (within intellectual property constraints) of software products in the public health (and even potentially the larger) community.

An optimal CDSi offering from a shared facility may require various services beyond hosting the run-time service, shared data, and/or a shared application, including:

Provides web conference/telephone/email support to an organization’s information technology (IT) staff;

Works with an organization’s IT staff to integrate the services with their healthcare systems;

Enhances or customizes the software features to meet the custom needs or workflow of an organization.

Provides web conference/telephone/email support to local managers of the service’s schedule, rules, and tests;

Trains SMEs to create and manage the concepts, series, and rules that are utilized by the service.

Customize and/or maintain an immunization schedule on behalf of organizations.

Configuration services

The need for these types of services comes from various potential user organizations as listed in Table 2. For each of the potential user organization types (rows in the table), a business case can be identified to support at least one of the deployment types (columns in the table).

Table 2

User Organizations and Support Options.

	SELF-SUPPORTED	ASSISTED	HOSTED
IISImmunization evaluation and forecast is a CDC Core Functional Standard.	Most IIS have the expertise and interest in at least defining their own rules if not managing them.	This might involve an IIS deploying its own Web Service but relying on an external shared entity to configure it and manage the rules, or offer other ad hoc assistance.	Some IIS are looking for a turnkey solution that involves little effort or expertise on their part.
Other public health agencyPHAs might want to use CDSi for data analytics including up-to-date calculations for individual patients and whole populations.	Local/state PHA with strong informatics capability may want to manage a software service and its rules on its own.	This might involve a PHA deploying its own Web Service but relying on an external shared entity to configure it and manage the rules, or offer other ad hoc assistance.	Most local PHAs likely want a turnkey solution as they do not have the informatics expertise to deploy or maintain a web service.
EHR-S vendorCDS is a major area of functionality and most general-purpose EHR-S do not do this well, especially when it comes to pediatric functions (see below).	Most EHR-S vendors would likely want to run and maintain their own Web Service.	Some EHR-S vendors may want some level of assistance if they are less confident especially of their medical expertise in this area.	An external, shared entity could offer a fully-hosted service for an EHR-S vendor, but would need to make sure it has the support and technical capacity to maintain it.
Academic medical centerMany have developed and deployed home-grown EHR-S.	Those with strong informatics programs may just want to do it themselves. They also tend to be familiar with the open source model.	Those with less capable informatics programs may want some level of assistance all the way up to a turnkey service.
Accountable Care Organizations (ACO)/Patient Centered Medical home (PCMH)ACOs have high expectations placed on them especially for analytics and often little infrastructure to produce results quickly.	Uncertain of how sophisticated any ACOs might be.	ACOs are more likely to need more services rather than fewer.

CDSi and EHR Systems

Significant work has been done by public health agencies to develop CDSi capabilities, including services that can be accessed by various systems including IIS, EHR systems (EHR-S), and even PHR systems. Strong CDSi systems are driven by powerful, increasingly complex algorithms that support a number of functions including evaluation of immunization history for validity and forecasting of due, overdue, or future doses. The CMS EHR Incentive Programs (“Meaningful Use”) are focusing more attention on CDS generally, including immunizations. One of the core set of measures in both Stage 1 and Stage 2 Meaningful Use involves implementation of CDS to support clinical quality, and CDSi continues to be a legitimate selection for this objective in Stage 3.w

EHR-S do not generally support CDSi well, largely because it has not been a high priority for EHR vendors given the many other requirements of Meaningful Use.x While an EHR system is potentially able to generate its own CDSi evaluation and forecast as well as receive evaluation and forecast information from one or more IIS, each evaluation and forecast is only as good as the immunization (and patient) history upon which it is based, and the rules/algorithms that are contained within it. Though the CDC CDSi Project has helped develop some consensus around immunization evaluation and forecast logic and rules, its artifacts are not consistently mandated and there continue to be many algorithm variations in use today.

EHR-S could access CDSi capabilities in a number of ways:

Natively within the EHR-S

Vendorsy could certainly provide CDSi capabilities completely within the EHR-S product (Fig. 5). This would require the EHR-S vendor to maintain the logic/rules and software for this functionality within their products. Users would seamlessly have access to the CDSi features through the natural course of using the EHR-S product. The vendor could develop this functionality in-house or acquire it from another vendor or source. While this option leaves the vendor fully in control of the CDSi functionality, it also leaves the vendor (at least partially) responsible for maintaining the logic and ensuring the features work effectively with the rest of the product. The vendor also needs to decide strategically if only one set of logic will be maintained for users in all jurisdictions (certainly a simpler choice), or if a different logic will be developed and maintained for users in different jurisdictions (more difficult, but perhaps functionally more desirable by users). Given the many requirements on EHR-S vendors to develop and maintain ONC Certified Software (CEHRT) functionality, this may be a huge investment relative to competing priorities.

Figure 5

CDSi native in EHR.

Natively within the EHR-S via a Web service accessed by each EHR-S installation

Rather than embedding CDSi within the EHR-S product, the vendor solution could access the CDSi rules as a Web service that the vendor provides to its clients directly on the Internet (Fig. 6). This would allow the development and maintenance of the CDSi logic to be done independent of the installation of the EHR-S itself but still fully controlled by the EHR-S vendor.z This modularization also allows the vendor to more easily “swap” CDSi modules to get a better one, so long as the interface specifications from the core EHR-S product to the CDSi service remain the same.aa It also may provide the EHR-S vendor with an independent source of expertise for maintaining and supporting the CDSi logic itself if acquired from an external source. In addition, this inclusion of the CDSi functionality in the base product may allow the EHR-S to support certain contraindications to immunization (such as an allergy or vaccine-to-drug interaction) without necessarily including them in the CDSi algorithm itself. This more loosely coupled approach allows more flexibility for the EHR-S vendor and potentially provides an opportunity for IIS to support this option (see below).

Figure 6

CDSi via Web service.

Via HL7 query/response with an IIS

Standards-based query/response via HL7 v2 messaging is a common feature supported by IIS and an increasingly common feature supported by EHR-S (Fig. 7).ab It is also now required for CEHRT for Stage 3 Meaningful Use support. Many IIS return an evaluation and forecast as part of the response to a query. Assuming that the immunization history in the EHR-S matched the immunization history in the IIS, the evaluation and forecast from the IIS would be quite useable by the EHR-S which would need to format and present the information within the user interface of the product.ac There are several advantages to this approach, including:

Figure 7

CDSi via IIS query/response.

The EHR-S vendor can rely on the IIS to develop and maintain the complex rules and algorithms of the CDSi.

HL7-based query/response is included in Stage 3 Meaningful Use, so this does not represent functionality beyond that which all ONC certified products will need to provide within the coming years.

The EHR-S vendor will be able to provide CDSi that may be customized to individual jurisdictions rather than uniform for all jurisdictions based on queries to individual, different IIS.

This strategy encourages clinicians to ensure that the immunization history known to the IIS is consistent with the history reflected in their local EHR-S database.

But there are also some distinct limitations, including:

Some IIS may not yet be capable of providing CDSi within their response to a query, requiring EHR-S vendors to adopt more than one strategy nationally.

IIS do not respond uniformly to HL7 queries, requiring the EHR-S vendor to be able to interpret and process HL7 messages differently in different jurisdictions.

CDSi rules are out of the vendor’s control, which can be a curse or a blessing, depending on the expectations of the product’s users.

The multiplicity of potentially conflicting information received from different IIS may only serve to confuse the clinician and may result in multiple, duplicative investments across the healthcare ecosystem. This challenge is both technical and policy based, and needs to be addressed as this solution develops.

As a Web service provided by the IIS

An alternative to accessing the CDSi features through HL7 query/response with an IIS is access to the IIS’ CDSI logic through a Web service maintained by the IIS itself (Fig. 8). This is different than access via HL7 because in this case the EHR-S is not relying on the immunization history from the IIS, but it is sending its own locally stored immunization history to the IIS’ CDSi service for evaluation. The EHR-S gains an evaluation and forecast consistent with the IIS without being dependent on IIS data. The EHR-S vendor does not have to reproduce the logic nor retain the expertise to manage it. While not all IIS will likely host such a service, potentially requiring the EHR-S vendor to develop multiple CDSi strategies, it is likely that one or more IIS services will be “good enough” for use even nationally. But the EHR-S vendor also gives up a certain amount of control, not only over the logic but over the production Web service as well. You get what you pay for: assuming no payment to the IIS is required for this service, the service level provided by the IIS likely also comes with “no strings attached.”

Figure 8

CDSi via IIS Web service.

As a Web service provided by an independent organization, public or private

Another variation of the external Web service is provided not by the IIS but by an independent organization (Fig. 4). This could range from a no-fee public service to a for-fee service provided by a vendor, organization, or association. By being independent from the IIS, this service can grow or change in response to market demands. By charging a fee, it has the potential to support itself financially and ensure a level of service that may be more appealing to EHR-S vendors. With that independence, however, comes a need to prove that its CDSi logic is solid, tested, and appropriate. Such a service may or may not offer logic specifications customized to specific jurisdictions and should be as consistent as possible with documented CDC CDSi logic (or at least document where it is not). Like some other options above, it does relieve the EHR-S vendor of the burden of developing and maintaining complex logic while allowing organizations or companies that specialize in this capability to continue to develop, refine, and improve their offerings.

One of the key considerations for an EHR-S vendor is the degree to which the selected strategy provides a solution for all their users regardless of location/jurisdiction, or whether multiple strategies might be necessary, which adds cost and complexity to their solution. Note also that to be effective, the EHR-S would have to have a complete immunization history to send to the independent CDSi service. This might require a query to the IIS first before invoking the CDSi service itself.

And Stage 3 Meaningful Use has confused this landscape. The Public Health objective as it related to immunization now requires CEHRT to not only be able to submit data to an IIS but also to display a forecast received from an IIS. While this functionality supports the option to receive CDSi via HL7 query/response with an IIS as described above, it is not consistent with any of the other options. Though the language is somewhat unclear, it seems to allow an EHR to ignore a forecast from an IIS if it feels it has more complete information or a better method of producing the forecast.ad

Market Outlook

IIS and other clinical systems have at their disposal both commercial and open-source CDSi alternatives, which could be made available to healthcare organizations of all sizes, assuming their EHR-S is configured to interact with CDSi services. Most IIS in production today have CDSi algorithms and capabilities deployed within their products. The IIS product market has consolidated somewhat over the past 15 years with three dominant products remaining and a variety of single-vendor/public health developed products. Initially, CDSi components were tightly integrated into the products that used them, especially within older products. Software development techniques tended to be less sophisticated in the past, and most CDSi implementations were (and are) difficult to understand, modify, and support. While a good algorithm contains some table-driven configuration elements, the rules for some vaccines are complex and their configuration parameters cannot easily be captured in a table. For example, a childhood series for DTP is usually a five-dose series. If, however, a patient is aged seven years or older or will be aged seven years or older as of the next due date, and the patient received the first dose of DTP at 12 months of age or later and received at least one dose at four years of age or later, then the series is considered to have been completed with three doses.ae And this is just one exception of several for the DTP series. Regardless, most IIS do have successful algorithm implementations though as time goes on, budget constraints and staff turnover increasingly put the long-term viability of some of the algorithms at risk.

More recently, IIS have turned to CDSi components that are more loosely coupled to the rest of the IIS software. Service-oriented architecture (SOA) is a building-block approach to system construction, which allows complex systems to be broken down into reusable components that can be arranged, rearranged, and invoked through standard programming interfaces (Fig. 9). While originally conceived of as a way to support applications within an organization, SOA has become an architecture upon which system interoperability between organizations can be supported.12,13 The strong resemblance of this diagram to the CDSi Shared Services diagrams is shown in Figures 3 and 4.

Figure 9

Service-oriented architecture.

A CDSi service as described in this use case is making use of SOA strategies. There are several commercial and open-source products available that already provide this capability. They fall into several categories:

CDSi shared services could be offered by nearly any category of software listed in Table 2. However, with continuing constraints on funding and the availability of open-source solutions, it may become harder for both public health agencies and commercial EHR and PHR vendors from justifying investments in proprietary solutions. While proprietary software seems to offer the comfort of a vendor standing behind a product, that comfort is only as good as the stability and responsiveness of the vendor. Open-source initiatives with vendor supporters standing behind them offer the best of both worlds: access to vendor-provided software without lock-in, more transparency in the governance and decision-making over product enhancements, and a greater ability to pool ones resources with like-minded organizations (public or private sector) to enable a good product to develop and survive.

Conclusion: Looking Ahead

Collaborative development across organizations requires trust and cooperation to be successful. But when done right, everyone wins. For CDSi, there is a strong business case for all stakeholders to collaborate and share solutions. Though not all organizational requirements are identical, there are products on the market that allow granular configuration of CDS rules so that acceptable deviation or interpretation of clinical guidelines can be supported. CDSi provides a unique opportunity for the public and private sectors to work together to support solutions that can be shared for more consistent operations, patient follow-up and communication, and data analysis. An SOA supports the industry movement to more loosely coupled interoperating systems and focus on shared, standard application programming interfaces. Investments in shared solutions and their proper governance introduce more efficiency into the development of computer-assisted tools.