| Potential Challenge | Examples | Potential Solution |
|---|---|---|
| Increased effort required to develop and support knowledge resources for use in multiple contexts | A given knowledge resource may be used for very different types of applications A given knowledge resource may be used in settings using different terminologies |
Balance generalizability with resource realities Spread knowledge development cost over multiple deployment settings to support increased effort requirement |
| Need for service interface to be standardized | A CDS system designed to use one commercial medication knowledge service cannot be easily adapted to use a different knowledge service A CDS system designed to use SEBASTIAN cannot be easily adapted to use a different CDS service with a non-compatible service interface |
Facilitate widespread use of HL7 and OMG Decision Support Service standards [19,20] |
| Service output may need to be customized to meet the needs of clients | Clients may differ in the preferred screening frequency for primary cancer prevention Different health care organizations may wish to provide care guidance according to different clinical practice guidelines |
Incorporate customization parameters (e.g., preferred screening frequency for mammograms) as service inputs |
| CDS service fulfills only one of the several tasks required for delivering CDS | A population health management system using a system-agnostic CDS service still needs to determine who should be evaluated, how patients should be triaged, and how identified care needs should be addressed A point-of-care CDS system using a system-agnostic CDS service still needs to determine when it should be invoked, how data are retrieved, and how care recommendations are communicated |
Develop other system components in a modular, scalable, standards-based, and service-oriented manner |
| “Black-box” nature of service may be unacceptable | A client may wish to know exactly how a clinical decision was reached for cancer chemotherapy A client may require that underlying clinical logic be formally reviewed prior to operational use |
Provide detailed meta-data on underlying clinical algorithms Make underlying service implementation open-source |
| Clients may insist on having local service instance | A client may be uncomfortable relying on a CDS service hosted externally A client may wish to avoid transmitting patient data to a third party A client may wish to minimize the time required for transmitting data to and from the CDS service |
Service instances may be deployed to clients and synchronized |
| Need to account for different data availability and data models | Some clients may have access to only claims data, while others may have access to claims and laboratory data, and still other may have access to various types of electronic health record data Different clients may use different information models and different terminologies |
Standardize expected data availability for CDS, along with associated information models and terminologies Create different sets of knowledge resources for different data availability contexts Structure knowledge resources to accommodate different data availability |
| Limited content availability | Outside of basic medication knowledge resources, only limited clinical content is available through system-agnostic CDS services Fundamental CDS capabilities (e.g., for calculating pediatric vital sign percentiles) are not generally available through CDS services |
Create an interoperable, standards-based market for such knowledge Provide federal funding for the development of clinical content for system-agnostic CDS services |