Summary

Solor Knowledge Architecture was created to integrate disparate knowledge sources and preserve the meaning of information for the interoperability of electronic health record data (i.e., semantic interoperability) critical to delivering safe Veteran care and leveraging standards-based clinical decision support. Solor is an open-source project of capabilities and services that overcomes interoperability complexities by assimilating disparate health knowledge sources into a consistent representation based on best practices of computer science.

Solor’s Knowledge Architecture employs the design principle called separation of concerns, whereby a system is divided into distinct sections, such that each section can address separate concerns. In this case, each architectural layer may build upon artifacts from lower layers, as described below:

• Foundational Architecture of the Knowledge Architecture provides the common elements of interoperability, such as object identity, versioning, modularity, and knowledge representation. It includes a) the foundation and building blocks of the common model; (b) how the repeatable
  transformation process of disparate standards into the common model promotes interoperability with other environments; and (c) how the modules of the architecture are tightly version controlled over time.

• Terminology Knowledge layer is responsible for structured sets of medical terms and codes that define concepts of interest, including descriptions, dialects, language, and semantic hierarchy. SNOMED CT, LOINC, and RxNorm are part of this layer. It defines what valid codes or expressions may be used by higher level layers.

• Statement Model layer is responsible for defining how data elements are combined to create a statement. This layer reuses the artifacts defined in the Terminology Knowledge layer.

• Assertional Knowledge layer uses the Terminology Knowledge layer concepts to specify non-defining facts that may be used by procedural knowledge algorithms. An example of such a fact might be that "thiazide diuretics treat hypertension." Assertional Knowledge may indicate what symptoms may be associated with a disorder.

• Procedural Knowledge layer is responsible for information about standard ways to carry out specific procedures and other procedural guidelines, e.g., treatment protocols for diseases and order sets focused on certain patient situations. Procedural knowledge, together with assertional knowledge, enables clinical decision support, quality measurement, and supports patient safety. This layer relies on the architectural foundation and terminology layers, incorporates the statement model for information retrieval, and uses the assertional knowledge. Procedural knowledge artifacts may include clinical alert rules, reminders, etc. that trigger actions or recommend interventions.

Impact on Strategies

Increased reliance on computerized health records, including Electronic Health Records Systems, requires standardized medical terminology to encode health information consistently across systems and enterprises. Clinicians require not only objective quantitative measurements (e.g. 90 beats per minute for a patient's pulse) but also contextual or procedural context (e.g. pulse oximetry, manual) about past observations or requests for future interventions. While two quantitative measurements may be the same, the procedural information could indicate meaningful semantic differences and lead to different clinical interpretation and treatment. As information is exchanged across systems, the solution requires a common understanding of data and a method to support knowledge-representation and clinical decision rules based on common terminology and statements. Each component must address an aspect and, together they need to address the requirements of clinicians. Current HL7 standard implementations rely on profiles and templates to disambiguate statement and terminology, and provide sufficient precision for transactions, documents, and standards-based APIs. Therefore the architectural approach described here would be applicable to standards organizations developing interoperability-enterprise, and project-specific implementations in equal measure.

Functional decomposition—often referred to as a Separation of Concerns (SoC)—across components or sections with a specific purpose is a foundational design principle for complex system architecture. Enabling a SoC allows a complete system to be subdivided into distinct sections or components with well-defined functionality and dependencies. If successful, this approach allows individual sections to be able to be reused, as well as designed, implemented, and updated independently to address emerging requirements. This is especially useful and important in a medical context given how many different health information and clinical terminology projects are ongoing at any given time. Efforts are often uncoordinated and led by disparate and unrelated standards development organizations. In these cases, SoC allows teams to work independently, in coordination with each other, and reuse the resulting artifacts.

References

1. Veterans Affairs (VA) Terminology Strategy of the Health Informatics Business Line, VA/DoD Health Executive Committee. White Paper. 2021-03-12.  200728 -JCISI FINAL-v2 CDO comments 210312.1

Figure 1.3. Separation of Concerns: Knowledge Architecture
Foundational Architecture – The Foundational Architecture of the Knowledge Architecture provides the
common elements of interoperability such as object identity, versioning, modularity, and knowledge rep-
resentation. It includes a) the foundation and building blocks of the common model; (b) how the repeatable
transformation process of disparate standards into the common model promotes interoperability with other
environments; and (c) how the modules of the architecture are tightly version controlled over time.
Terminology Knowledge – The Terminology Knowledge layer is responsible for structured sets of medical
terms and codes that define concepts of interest, including descriptions, dialects, language, and semantic
hierarchy. SNOMED CT, LOINC, and RxNorm are part of this layer. It defines what valid codes or expres-
sions may be used by higher level layers.
Statement Model – The Statement Model layer is responsible for defining how data elements are combined
to create a statement. ANF Reference Model belongs in this layer. Other standards-based clinical statements
are discussed later in this chapter. This layer reuses the artifacts defined in the Terminology Knowledge
layer.
Assertional Knowledge – The Assertional Knowledge layer makes use of the Terminology Knowledge
layer concepts to specify non-defining facts that may be used by procedural knowledge algorithms. An
example of such a fact might be that "thiazide diuretics treat hypertension." Assertional Knowledge may
indicate what symptoms may be associated with a disorder.
Procedural Knowledge – Procedural knowledge, also known as imperative knowledge, is the knowledge
exercised in the performance of some task, such as determining a hypertension treatment plan by analyzing
a combination of a patient's ANF statements, and the available assertional knowledge. The procedural
knowledge is responsible for information about standard ways to carry out specific procedures as well as
other procedural guidelines, e.g. treatment protocols for diseases and order sets focused on particular patient
situations. Procedural knowledge, together with assertional knowledge, enables clinical decision support,
quality measurement, and supports patient safety. This layer relies on the architectural foundation and
terminology layers, incorporates the statement model for information retrieval, and uses the assertional
knowledge. Procedural knowledge artifacts may include clinical alert rules, reminders, etc. that trigger
actions or recommend interventions.
Examining a clinical procedure for controlling hypertension illustrates each of the layers of the informatics
architectural separation of concerns.
HL7_CIMI_LM_ANF_R1_I1_2019SEP
Page 8
© 2019 Health Level Seven International. All rights reserved.
Why Analysis Normal Form? A Normal Form for Clinical Statements• At the Terminology Knowledge layer, there may be various codes and terms from disparate source ter-
minologies to define a concept (e.g. hypertension). Ideally, these overlapping codes and terms would
be oriented to the same parent concept during the transformation and integration process at the Founda-
tional Architecture layer (e.g., Solor).

• The Statement Model layer enables representation of blood pressure measurement values (e.g., systolic

BP = 140 mmHg) or the categorical data (e.g., pregnancy induced hypertension vs. renal hypertension)
within a standard data structure to facilitate information exchange or retrieval, such as within a standards-
based clinical statement (i.e. CIMI, CDA, FHIR, ANF, etc.).

• The Assertional Knowledge layer represents non-procedural statements, or facts, such as "Stage 2 high

blood pressure is over 140 systolic or 90 diastolic," or that beta-blockers and ACE inhibitors may be
used to treat hypertension, or that beta-blockers are contraindicated in patients with a diagnosis of reactive
airway disease.

• Finally, the Procedural Knowledge layer provides algorithms to analyze ANF statements about a patient,

in combination with the Assertional Knowledge, to recommend a treatment protocol for different kinds
of hypertension, including the considerations of, e.g. patient age, comorbidities etc., which can be gen-
erated by an electronic clinical decision support system (Statement + Assertional layers). This layer
adds support for workflow and conditional logic (i.e. if-then-else).
A clear separation of concerns enables the isosemantic transformation of standards-based clinical statements
to normal form in the Statement Model layer by decoupling structure from semantics and workflow.
HL7 relies on implementation guides (for V2, CDA, and FHIR) to add sufficient terminology knowledge
to standards-based clinical statements. Vocabulary constraints documented as profiles or templates are the
mechanism to create interoperable implementation guides from health IT standards. Only after the Termin-
ology Knowledge is fully defined, the standards-based statements can be used to support business and
workflow decision points consistent with the Assertional and Procedural layers described above.