Mechanisms of Integration

Mechanisms of integration refers to the computational approaches and how capabilities behave, function, and interact as a system to deliver computational inferences and insights resulting from the faithful execution of the computable expressions of a clinical practice guideline (as expressed in using the knowledge artifacts defined in this implementation guide) against patient-specific data. This includes results and inferences for CPGCaseFeatures, CPGRecommendations/CPGProposals, CPGMetrics, CPGeCaseReports, CPGCasePlanSummaryViews, and the results of other derived artifacts. These inferences include individual resources and, as importantly, the relationships between them.

• Mechanisms of Integration
  • Direct (Ingestion or Translation of Computable Artifacts)
  • Reasoning-as-a-Service (on-demand data ingest and insight/inference delivery)
  • Via Data Enrichment (real-time data ingest and insight/inference delivery)
  • As an Application (data ingest with external reasoning and results presentation)
  • Hybrid (combination of approaches (most likely for CPGs))

Clearly, the mechanisms of integration are highly correlated to the methods of implementing the knowledge of artifacts. For instance, If the knowledge artifacts are directly ingested or imported by the systems of record or use (e.g., EHRs), the mechanisms of integrating the inferences or insights are likewise scoped to the context of the capabilities of these systems. However, if reasoning (execution of knowledge artifacts against patient-specific data) is performed external to these systems of record or use, then there may be several mechanisms by which the resulting inferences or insights may be integrated into these target information systems. These mechanisms may include reasoning-as-a-service (e.g. CDSHooks), Data Enrichment (e.g., FHIR PUT/POST, HL7 v2, or numerous standards-based or custom electronic data interchange approaches), as an embedded or workflow-adjacent app (e.g. SMART-on-FHIR), or a “hybrid” approach using some combination of these patterns.

Of note, a hybrid of external and internal reasoning (methods of integration) as well as multiple mechanisms of integration of inferences or insights from external reasoning capabilities may be and often are combined to address the needs and requirements of the local enterprise clinical application ecosystems.

Direct (Ingestion or Translation of Computable Artifacts)

Direct ingestion or import of the knowledge of artifacts (representations and expressions) is discussed in Methods of Implementation and defers the mechanisms of integrating inferences and insights that result from the execution of these knowledge artifacts to the application within which they are being executed. Reasoning on these knowledge artifacts and the resulting inferences or insights from their execution against patient-specific data are matters left to these application-specific implementations. Ingested content may be directly executed or it may be translated into execution languages native to these applications (e.g., rules engines).

Furthermore, some systems of record/use may not be able to directly ingest and/or computationally translate standards-based content. In these situations, the computable clinical practice guideline representations (artifacts and expressions) together with the knowledge engineering work products used in translation at various levels (packaged and contained in the specific Content-IG ) may serve as an explicit, formal specifications for application analysts and clinical Informaticians to manually translate the guideline into application-native languages and/or build environments (e.g., OrderSet Build tooling). In this case, clinical reasoning still occurs within the native application, however, testing and validation will need to be done to ensure faithful execution aligned to the intent of the clinical practice guideline. The Test Cases packaged with the Content-IG can be of some utility in this case.

Figure 1 Direct ingestion/import of computable clinical practice guideline knowledge representations (artifacts and expressions).

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 2 An example and pattern of Clinical Reasoning-as-a-Service using CDS Hooks eventing, 'pre-fetch' of patient data, and response.

Via Data Enrichment (real-time data ingest and insight/inference delivery)

Another pattern for integration of an external clinical reasoning capability is data enrichment. In this pattern, there is a real-time, bidirectional interaction between the system of record/use (e.g., EHR) in the clinical reasoning capability with continuous delivery of inferences/insights resulting from the execution of the computable clinical practice guideline representations from the clinical reasoning capability to the system of record/use. In this mechanism of integration, the clinical practice guideline inferences are computed as new information on a patient is generated and sent to the clinical reasoning capability and persisted in the system of record/use for presentation and/or use for internal decision support logic. This pattern is a form of “chaining through data” where the guideline-directed inferences are computed when new information is known (or the passage of time as dictated by the guideline specification) and provided to the clinical reasoning capability. The guideline-directed inferences are then sent to and persisted in the system of record/use for use in various native mechanisms within this system.

In this pattern the execution of the computable guideline representations and integration of the resulting inferences occurs in near real-time. As inferences are knowable (and data provided to the clinical reasoning capability), they are computed and returned to the system of record/use thus maintaining a persistent record the current state of the patient, including current and recommended care plan in these systems. These inferences include at least:

• The inferred CaseFeatures that provide comprehensive, detailed descriptions of the patient with respect to the scope of the computable guideline (e.g., condition, procedure);
• Patient-specific recommendations as CPGProposals (e.g., orders or order surrogates with attributes that indicate it is recommended or proposed); and
• The CPGMetrics that provide assessments of compliance with recommendations, adherence to Strategies or the overall Pathway, and/or the status of the patient with respect to intermediate and ultimate goals

Thus, the system of record/use can maintain detailed information about the current and relevant historical state of the patient with respect to the condition or procedure (as scoped by the by the guideline), the current and proposed state of this specific patient’s Care Plan, as well as the state of the patient and their respective care plan with respect to the clinical best practice as specified in the computable clinical practice guideline representations.in this pattern, note that ”state” with respect to the patient (Case), Care Plan, and assessments thereof are maintained in the system of record/use and may either be used as the source of truth for the external clinical reasoning capability and/or maintained concurrent with a data store local to the clinical reasoning capability.

Figure 3 An example and pattern of data enrichment integration using eventing, messaging, bulk transfer, and request patient/response.

As an Application (data ingest with external reasoning and results presentation)

Another very relevant mechanism of integration for computable clinical practice guidelines is the use of a distinct, fit-for-purpose application (App) that can be manifested adjacent to systems of record/use within clinical workflows (e.g., mobile Apps) or in some cases directly in screens within the system of record/use itself (e.g., in EHR iFrames). SMART-on-FHIR Apps are an prime example of such a mechanism of integration. In this pattern, the required data elements are securely accessed from the system of record/use (e.g., EHR) by an external application, the clinical reasoning on the computable guideline representations (artifacts and expressions) occurs with the App itself and/or the App can call an external clinical reasoning capability via services as described above, and the user interaction occurs within the App. The critical point here is that the system of record/use only provides the required data elements and does not require a means to incorporate the inferences either via services or data enrichment- the inferences about the ”state” of the patient (e.g., inferred CaseFeatures), the state of the patient-specific Care Plan including proposed case (e.g., CPGProposals), and assessments thereof are manifested in the App’s presentation layer (UI).

Figure 4 Integration with systems of record/use via a distinct Application (e.g. SMART-on-FHIR App) where the required data elements are provided by the system of record/use, the user interaction (presentation layer) occurs within the App, and the clinical reasoning that executes the computable clinical practice guideline and provides inferences/insights on the patient and care plan may occur either directly within the app itself or the App may call an external clinical reasoning capability as a service as described above.

Hybrid (combination of approaches (most likely for CPGs))

For many implementations of computable clinical practice guidelines that desire to leverage multiple derivatives and especially if they desire to support a broader clinical quality improvement lifecycle or learning health system, more than a singular mechanism of integration may be required. This becomes an exercise in Solution Architecture where both a sound understanding of the various Methods of Implementation and Mechanisms of Integration are well understood, as well as the implications for the computable guideline knowledge architecture and even specific content are given thoughtful consideration for how such a solution will impact the overall capabilities, performance, and scalability.

Such a “hybrid” pattern certainly requires understanding the respective patterns chosen from above- where computable content execution or clinical reasoning occurs for respective pieces and parts, or aspects of the computable guideline, but also requires planning and consideration for how these various integration patterns interact with one another. This may include identifying the sources of truth for required data elements and or specific inferences/insights (e.g. CaseFeatures, Proposals, Metrics) as well as orchestration if clinical reasoning/ knowledge execution occurs in distributed systems. In many of these cases, one pattern of mechanisms of integration may serve as the principal pattern with others used to supplement and/or build upon. For several reasons, data enrichment often becomes this principal pattern so that that systems of record/use retain a surrogate for the history of computable guideline execution and can serve as the source of truth. Services, Apps, and internal application capabilities can then leverage this ‘holistic’ data collectively. It can further make inclusion of and integration with application-native capabilities such as Order Sets and broader decision-support and knowledge base capabilities (e.g. Drug Knowledge Bases) much more feasible.