Clinical knowledge entails information about relations of particular signs and symptoms with specific diseases. It consists of interpretive action and interaction-factors that involve communication, opinions, and experiences. The computability of clinical knowledge will provide leverage and support for existing informatics and clinical decision support infrastructure.

Establishing a basis for computable clinical knowledge will help support the Quality Improvement Ecosystem through the ease of use for shared logic in regards to HIV Screening.

Figure 1 The Quality Improvement Ecosystem.

Clinical Quality Language (CQL)

Clinical Quality Language (CQL) is a high-level, domain-specific language focused on clinical quality and targeted at measure and decision support artifact authors. CQL has matured into a capable and flexible specification for representing clinically-focused logic, and is being used in a broad variety of applications from cohort definition and quality measurement, to clinical decision and cognitive support, computable guidelines, and public health reporting.

The usage of CQL enables the automated point-to-point sharing of executable clinical knowledge along with providing a clinically focused, author-friendly, and human-readable language that can be used in conjunction with Fast Healthcare Interoperability Resources (FHIR) and CDS-Hooks.

Figure 2 The logical structure and architecture for CQL.

Integration and delivery for HIV Screening involves the usage of reasoning as a service (or on-demand data ingestion) to deliver computational expressions for a clinical practice guideline. This mechanism of integration is utilized for the HIV Screening guidelines through the usage of CDS-Hooks to provide clinical decision support for a clinician's workflow.

Reasoning-as-a-Service (on-demand data ingest and insight/inference delivery)

Integration of inferences or insights as a Service is similarly discussed in the related Methods of Implementation. In this pattern, there is some trigger (e.g. user interface event) in the clinical information system (or application of use) that prompts the system to call a Clinical Reasoning Service that provides the execution capability for the computable representations of the clinical practice guideline. The application of record/use may require multiple “round trips” to get the clinical reasoning service the data required to make appropriate inferences and then to receive those inferences. The service may directly provide inferences as data elements, may return a presentation layer (e.g., html), may return a link (href) to launch an external application (e.g. SMART-on-FHIR), or some combination of all three. Of note, this pattern of integration is typically implemented as on-demand or just-in-time service calls, clinical reasoning, and inference/insight delivery. CDSHooks is a principle example of this pattern.

Figure 3 An example and pattern of Clinical Reasoning-as-a-Service using CDS Hooks eventing, 'pre-fetch' of patient data, and response.