The ultimate goal of this effort is to support the coordination of safe, effective medicine (Requirement 1). This goal requires quality information in the patient record (Requirement 2), wherever it comes from, and the increasingly distributed nature of care that requires commonly understood data standards (Requirement 3) to ensure mutual comprehension across the care team and over time. There are four outlined clinical use cases:

Clinical Use Cases

The key capability for a clinician should be to record and review data quickly and accurately (Requirement 8), taking advantage of up-to-date classifications and decision support rules. This should be accomplished by knowing when a change in the knowledge base might affect a record. The change management capability that supports these operations should be as unobtrusive as possible to patients and care providers, and always readily available.

These operations depend on the availability not only of currently accurate terminology assets, but also assets from prior points in time (Requirement 7). These may include assets as defined or refined by different stakeholders with different sets of assumptions. For instance, whether a disorder meets a criterion defined by a standard terminology, a payor, a professional society, or a locally chartered board of specialists.

To support these needs, the Enterprise Terminology that supports the clinical systems must manage change systematically (Requirement 9), and it must do so for both internally-managed and externally-sourced assets.

Curation of these assets requires detailed change data. The evolution and maturation of knowledge happens at different times and places. Keeping standards and relationships to standards current is a complex undertaking. A health system may subscribe to dozens of standard and commercial terminologies, each of which may publish scheduled updates several times a year, and any of which may push out an emergency update at any time. All these assets have different designs, so ensuring continued cohesion is expensive and time-consuming, and the necessary transformations introduce risk. Systematic management of change requires granular representation of the assets and associated asset changes.

There are best-practice capabilities in knowledge asset maintenance. The following is proposed for clinical data standards:

These core properties support authoring and maintenance operations: at a high level, this means modifying the enterprise terminologies (Requirement 15), importing standard terminologies (Requirement 16), and publishing the enterprise terminologies (Requirement 17) to the client clinical systems. The standard terminology publisher has the same needs around modification and publishing as the enterprise, and some standards import other standards as well (e.g., Medication Reference Terminology [MedRT], which publishes relationships among other standards).

We distinguish between the Enterprise Terminologist and the SDO Terminologist. The Enterprise Terminologist is responsible for ensuring that the terminology resources provided to clinical systems are current and accurate. This involves managing the consumption of external terminologies as well as maintenance of assets defined within the enterprise. The SDO Terminologist is responsible for ensuring that the terminology resources provided to other terminology systems are current and accurate. This may involve managing the consumption of external terminologies as well as maintenance of assets defined within the SDO.

Asset Curation Use Cases

Today, clinical systems consume terminologies, but the interfaces are point-to-point. To assert or assess new information, the tools must already understand all relevant interface models. Since an external organization may modify that model at any time, the ability to consume external assets involves ongoing manual efforts to understand or confirm the model and the design of transformations to support consumption. This is potentially expensive and risky.

We propose a “data-driven” architecture to support self-describing terminology assets. All changes can be programmatically managed with a globally consistent design. Management may involve human review, but it can leverage pattern-based recognition of specific change types for automated handling, leaving a smaller number of cases that require human judgment. This information design will support a common representation of all terminologies. There are two key requirements for this design:

The context information of the first requirement includes the following:

These elements together are referred to by the acronym “STAMP.” Every new assertion, whether a new asset or a change to an existing asset, must have a STAMP to determine when it is to be used. The STAMP properties support the ability to apply terminology assets for specific purposes. For example:

A further requirement is that not only must the architecture support these properties, but that it must require the properties for all assets under curation. Without consistent application of this rule, the foundational capability of detailed version management is more difficult.

Additionally, for an asset to support a record of changes, each asset must itself be identifiable (Requirement 10).

The “single syntax” requirement is harder to satisfy. One approach would be to define a syntax that addresses the data elements of all known terminologies. This would be a heavy specification, that would be difficult to maintain, and could fail to capture new elements as terminologies are added in the future.

The other approach is to use a “self-describing” or “meta-modeling” approach, where the syntax defines not only the content but also what the content means. “Rigid” or “brittle” specifications determine in advance where information belongs: a database may use column names to suggest what belongs in a column, but there is no way to determine whether the name is a good one, or whether an instance value meets the criterion implied by the name. But flexible specifications support data definition. Extensible Markup Language (XML) (a subset of Standard Generalized Markup Language [SGML]) provides a way to specify types of data and structural (not semantic) relationships. Resource Description Framework (RDF) goes one step further by making the relationship between an element and its containing class an explicit part of every triplet. If this relationship is specified in a controlled terminology, then assertions can be tested for validity. For example, if an RDF Schema Specification (RDFS) asserts that the finding site of a lesion must be an anatomical feature, then assertions about actual lesions can be tested for valid finding sites. Furthermore, this logic specifies a “range” in the same syntactic structure as the instance assertion: changes to the knowledge base do not affect the syntactical representation of the knowledge. Systems that adopt this approach will require effort to take advantage of new features of terminologies, without having to rebuild their infrastructure when changes are made.

Having change data in discrete tagged change sets will allow the software to hide most of the complexity of version management from the human managers, allowing them to focus on significant decisions.

A granular self-describing model will support any statement that can be made using concepts in a subject-predicate-object structure, and its compositional aspect permits compound predicates. It is difficult to imagine a proposition that cannot be supported, however, this means that there are multiple ways to support any specific kind of statement that a terminology knowledge base must support. This section addresses best practices for these cases.