**[Note] content is pulled from HL7 Tinkar Ballot**

Summary

Information systems that are used across the healthcare enterprise record and manage clinical data using clinical statements and clinical terminologies in non-standardized ways. Interoperability specifications aim to require terminology bindings to concepts, code systems, and reusable value sets. Currently, there is variation in clinical data exchange across the enterprise, as current payloads and clinical statements use inconsistent and highly variable enterprise terminologies. The management of the concepts, code systems, and value sets is non-trivial because developers, implementers, and end users are forced to manage “unnecessary complexity.” For example:

• Representation of medications: RxNorm codes overlap with CVX codes. Investigational vaccines from the FDA are not represented in either RxNorm or CVX or SNOMED CT .

• Representation of COVID-19 result codes are inconsistent and are not equivalent (e.g., detected, undetected, positive, negative, etc.).

As a result of these complexities, there are many ways to say the same thing using standard terminologies and standard formats. The Institute of Medicine report, Health IT and Patient Safety: Building Safer Systems for Better Care, highlighted the unintended consequences of health IT-induced harm that can result in serious injury and death due to dosing errors, failing to detect serious illnesses, and delaying treatment due to poor human-computer interactions, confusing clinical terminology, or unreliable data quality [3]. Despite the widespread understanding of the importance of the quality of clinical data, there is currently a lack of integration and management of clinical terminologies across the healthcare enterprise.

Tinkar intends to support integration of clinical terminology and local concepts to support increased data quality for interoperable clinical information. Quality clinical data enables healthcare systems across the enterprise to conduct robust and meaningful data analysis and increase overall interoperability, which ultimately enhances quality of care across all medical facilities.

The Problem Tinkar Addresses

The following four high level potential deficiencies related to poorly integrated terminology and inefficient change management describe preventable harm that Tinkar addresses:

Inability to recognize equivalence

Difficulty with determining that codes/terms using standard terminologies from disparate health IT systems represent a common clinical idea/concept (e.g., “Feels Feverish” in the Temperature Symptoms SNOMED CT hierarchy versus "Feels Hot/Feverish" in the Observation and Sensation SNOMED CT hierarchy).

Inability to represent a pertinent phenomenon

A new set of local terminology may be managed with value sets and concept gaps addressed in quick iterations (e.g., "COVID-19 negative test result" was needed in practical use before official SDO releases, or gaps like "mild anemia" which was proposed but not accepted by both the international and U.S. SNOMED CT release).

Flawed information

Incorrect usage or representation of clinical ideas/concepts from standard terminologies due to a lack of harmonization and multiple representations that currently exist (e.g., LOINC , and SNOMED CT have overlapping concepts).

Inability to reliably and safely evolve over time

There is a lack of clear, detailed descriptions of changes to terminologies over time so that changes can be understood by implementers. Terminologies often change in ways that are convenient for the creators, but complex for the users (e.g., redundancy, major name changes, code reuse, and changed codes).

Example Implementations Gone Wrong

• Computer error may have led to incorrect prescribing of statins to thousands of patients.

  • Thousands of patients in England may have been incorrectly prescribed or taken off statins because of a major IT glitch.

  • Underlying cause: (1) code mapping errors, (2) brittle means for determining equivalence.

• Alert for monitoring thyroid function when taking Amiodarone stopped working.

  • Amiodarone is associated with several side effects, including thyroid dysfunction, which is due to amiodarone's high iodine content and its direct toxic effect on the thyroid.

  • Underlying cause: (1) the identifier for the drug amiodarone was changed in another system, (2) uncoordinated means for determining equivalence.

• 62 percent of clinical decision support (CDS) malfunctions were attributable to changes in underlying codes or data fields.

  • Change is a constant feature of providing healthcare.

  • Underlying cause: (1) poorly managed change.

Impact on Strategies

Tinkar is self-describing and completely machine processed. A self-describing architecture is defined in a report from Queensland University of Technology as follow: "[t]he idea is that self-descriptions of data and other techniques would allow context-understanding programs to selectively find what users want, or for programs to work on behalf of humans and organizations to make them more scalable, efficient and productive." [9] Key advantages of a self- describing architecture (or metadata driven architecture) [10] include the following details:

Changes can be reviewed immediately – Every action or change by end users can be immediately previewed or tested, without needing any compilation or deployment process. The review can also be done before saving or publishing the changes, which makes it an interactive development environment for designers to create functionality in an iterative manner.

Version Control with easy rollback - Every time any changes are made to published terminology artifacts, the historic versions of the metadata files are maintained. This enables easy version control and rollback when necessary. Every time a change is made to any artifact, the prior version that existed is archived. When a developer needs to roll back to the prior version, it can be achieved easily.

Any data source can be added – A self-describing architecture facilitates the ability for multiple types of terminology data sources to be connected to the system.

Define granular coordinates and configuration management – The functionality for defining granular user defined settings and controls for granular elements of clinical terminology management is supported. This includes create, read, and append settings, as well as management of individual elements, like fields or other controls.

Faster extensions – A benefit of a self-describing architecture is that it can abstract a lot of the deep internal complexities that makes development of standard terminologies complicated. This approach can improve processes around extensions to terminology.