Leveraging Terminology Services for Extract-Transform-Load Processes: A User-Centered Approach

Abstract

Terminology services serve an important role supporting clinical and research applications, and underpin a diverse set of processes and use cases. Through standardization efforts, terminology service-to-system interactions can leverage well-defined interfaces and predictable integration patterns. Often, however, users interact more directly with terminologies, and no such blueprints are available for describing terminology service-to-user interactions. In this work, we explore the main architecture principles necessary to build a user-centered terminology system, using an Extract-Transform-Load process as our primary usage scenario. To analyze our architecture, we present a prototype implementation based on the Common Terminology Services 2 (CTS2) standard using the Patient-Centered Network of Learning Health Systems (LHSNet) project as a concrete use case. We perform a preliminary evaluation of our prototype architecture using three architectural quality attributes: interoperability, adaptability and usability. We find that a design-time focus on user needs, cognitive models, and existing patterns is essential to maximize system utility.

Introduction

Controlled terminologies are an important part of the medical record. The semantics they provide to heath care data is critical not only for interoperability between systems and institutions, but for analytics and secondary use[1]. Demand for these terminology resources at an enterprise level has driven the creation of functional requirements[2], formalizing the role of a terminology service in the enterprise. Because of their broad importance, terminology services are generally thought of as infrastructural components, existing to support other applications[3,4] such as clinical decision support[5] and data processing pipelines[1].

There are, however, many instances where users may interact more directly with terminologies. One such example is the Extract-Transform-Load (ETL) use case. ETL scenarios, usually involved in data warehousing, not only must transform data structure, but data semantics as well[6]. Metadata describing the data semantics is not always readily available[7], which frequently places the responsibility of capturing, managing, and mapping these semantics on the ETL developers. This presents two problems. First, semantic transformation logic may become intermixed with the structural transformation process, and any captured terminology becomes a black box rather than an explicit, shareable knowledge artifact[8]. Second, clinical terminology is complex, and ETL developers often need subject matter experts’ and clinicians’ engagement to properly capture semantics[9].

In this work we present a design approach to the application of terminology services, centered around the ETL use case, that is deliberately focused on the needs and goals of the user, or user-centered[10]. We propose this not because existing terminology services are insufficient, but because domain mastery of terminology modeling and services is not universal, and should not be a prerequisite for utilizing these services - a notion we borrow from a recent study of bioimaging software[11]. Lowering the barrier to entry to these services while keeping users’ processes and cognitive models in mind increases usability[10] and ultimately, utility. Our focus is less around a terminology service in isolation, and more centered on a terminology system - or, the service along with other components in the context of a use case. With this in mind, we present a set of architectural principles necessary to satisfy both our functional and usability goals of a terminology system. Finally, through a concrete case-study, we analyze a prototype system against these principles.

Materials And Methods

Use Case: The Patient-Centered Network of Learning Health Systems

The National Patient-Centered Outcomes Research Institute (PCORI), authorized by Congress in 2010, is an independent nonprofit, nongovernmental organization centered around Clinical Effectiveness Research (CER)[12] with the goal of advancing clinical care by utilizing an evidence-based comparison of methods[13]. The National Patient- Centered Clinical Research Network (PCORnet), a PCORI initiative, focuses on the development of networks to share health care related data[14]. The Patient-Centered Network of Learning Health Systems (LHSNet), a collaboration of ten institutions, is our specific segment of the PCORnet network[15]. The goals of LHSNet build on the objectives of PCORI and PCORnet, and focus on the ability to distribute queries throughout the network. Although the sites are not exchanging patient data - only summary-level query results - a precondition for the network is that each site maintain a common data model-based data mart.

PCORnet Common Data Model. It is necessary for any distributed data set to agree on common data structures and semantics[16]. For PCORI, this agreement is in the form of the PCORnet Common Data Model (CDM)[17]. The PCORnet CDM provides database agnostic information on the data structure (such as data types and referential integrity), as well as data semantics (in terms of allowable values for codified data).

Creating the Data Mart. Construction of a PCORnet CDM compliant data mart introduces our ETL use case. Integrating multiple diverse data sources into a common representation presents significant challenges. First, the data must be structurally aligned at a schema level. Given multiple data sources, this problem compounds[18] - naming of objects and attributes may differ, and differences in granularity will need to be reconciled. Structural differences are only one aspect, however. Semantic alignment needs to be considered as well, and is of particular interest to this study because it often requires a dedicated terminology service[19,20,7]. Semantic alignment, or the reconciliation of analogous codifications, is an important aspect to maximizing data utility, especially across institutions[21].

Related Use Cases. LHSNet draws many similarities to other multi-institutional research network initiatives - mainly, the Informatics for Integrating Biology and the Bedside (i2b2)[22] and Observational Health Data Sciences and Informatics (OHDSI)[23] projects. We explore below in brief the data model and terminology integration of the two.

The i2b2 data model is centered around observations on a patient, or “facts”[24]. Each of these facts is associated with a single concept - either a locally defined term or a concept from an external standard. The concepts themselves are arranged into a collection, or i2b2 ontology, which can then be used to build dynamic queries into the data.

OHDSI uses the Observational Medical Outcomes Partnership (OMOP) Common Data Model as a data specification. WhiteRabbit,¹ an OHDSI developed tool, supports the ETL process by allowing examination of the source and target database structure and content. OMOP provides extensive guidance around both terminology and its structure via the OMOP Common Data Model Standard Vocabulary Specification Version 4.5[25].

Both of these use cases require the use of a defined CDM, and thus, require some sort of ETL process to import data. As with LHSNet, this data import requires the management of the data semantics. Huser and Cimino, while analyzing both OMOP and i2b2, suggest that “[a] terminology driven ETL process” would be a useful, especially when mapping local codes to external standards[20]. This observation aligns with our examination of the LHSNet use case, and suggests some degree of a shared need.

Terminology Models and Services

Value Sets. For our purposes, we define a value set as a set of codes used to define a semantic domain of interest. They must have some notion of a unique identifier and also may carry various metadata, such as names and descriptions. The PCORnet CDM defines 70 value sets to constrain attributes in the data model. These value sets are identified by a unique name and contain concepts specified by a code, name, and optional description. For example, the PCORnet CDM Race value set is shown in Table 1.

Table 1.

PCORnet Common Data Model v3.0 Race value set

Code	Name	Description
01	American Indian or Alaska Native	A person having origins in any of the original peoples of North and South America (including Central America), and who maintains tribal affiliation or community attachment.
02	Asian	A person having origins in any of the original peoples of the Far East, Southeast Asia, or the Indian subcontinent including, for example, Cambodia, China, India, Japan, Korea, Malaysia, Pakistan, the Philippine Islands, Thailand, and Vietnam.
03	Black or African American	A person having origins in any of the black racial groups of Africa.
04	Native Hawaiian or Other Pacific Islander	A person having origins in any of the original peoples of Hawaii, Guam, Samoa, or other Pacific Islands.
05	White	A person having origins in any of the original peoples of Europe, the Middle East, or North Africa.
06	Multiple race
07		Refuse to answer
NI	No information
UN		Unknown
OT	Other

Mappings. Mapping is a process of asserting relationships between concepts from different value sets[26]. These relationships can signify equivalence (or degrees thereof), hierarchical association (such as broader/narrower), or that no match exists for a concept. This is often done for interoperability purposes, where diverse data sets need to be aligned into a common semantic model[27]. It is also prevalent in ETL and data warehousing operations, where the target data model may specify value sets to which the incoming data must conform. To align these semantics, an institution will need to map their internal value sets to the target data sets. This is certainly the situation with our LHSNet use case, as multiple internal value sets need to be aligned to the PCORnet CDM semantics. Table 2 shows a sample view of a mapping of institution-specific codes to the PCORnet Race value set.

Table 2.

A tabular representation of a semantic mapping between an internal Race value set and the PCORnet CDM v3.0 Race value set.

Internal Code	Internal Name	PCORnet Code	PCORnet Name
		NI	No information
A	American Indian/Alaskan Native	01	American Indian or Alaska Native
B	Black or African American	03	Black or African American
BA	African	03	Black or African American
BB	American Born African	03	Black or African American
BC	Caribbean Black	03	Black or African American
BM	African American	03	Black or African American
C	White	05	White
N	Native Hawaiian/Pacific Islander	04	Native Hawaiian or Other Pacific Islander
NG	Guamanian or Chamorro	04	Native Hawaiian or Other Pacific Islander
NH	Native Hawaiian	04	Native Hawaiian or Other Pacific Islander
NO	Other Pacific Islander	04	Native Hawaiian or Other Pacific Islander
NS	Samoan	04	Native Hawaiian or Other Pacific Islander
P	Asian	02	Asian
O	Other	OT	Other

General System Functionality

Our goal is not to enumerate the functional requirements of our specific use case. We aim to reason about a broader architecture - one capable of supporting functionality outside of our current needs. There are, however, some general functional statements we can assume for our system that should broadly apply. Although not exhaustive, the following functional areas of concentration serve to scope our discussion.

Terminology Content and Services. Access to terminology resources depends on two factors: (1) the robustness of the structures used to model them, and (2) the completeness of the services in place to access these structures. At a minimum, the system shall provide a model for value sets and mappings, as well as services providing Create, Read, Update, and Delete operations. Content, both institution-specific and externally defined standardized terminologies, is generally necessary but use case dependent.

Graphical User Interface. User interfaces are often highly contextual, and effective ones focus on the specific concerns of the intended user base[28]. Because of this, we will not attempt to enumerate all user interface requirements here. At a minimum, manipulation of both value sets and mappings should be supported. Also, discussion and collaboration tooling is known to be important to the overall process of terminology refinement and validation[29], and should be supported natively to promote broader user engagement.

Architectural Quality Attributes

Evaluating the quality of a proposed architecture is a non-trivial task[30]. Quality goals often become represented as non-functional requirements, such as the system shall be easy for users to use. This not only presents implementers with a requirement that is untestable[31], it often pushes high-level goals down to individual components or modules, where the overall context can be lost. To avoid this, Architectural Quality Attributes[32] may be used to state system- level goals. They also serve to both influence and measure the system architecture. Below are three important quality attributes for our proposed system. This is by no means an exhaustive list, but was considered the minimal set to meet our stated system characteristics. Implementers are expected to add to this list as appropriate.

Quality Attribute 1: Interoperability. With this quality attribute, we aim to measure how well the components of our system share data with each other and external systems[33]. In previous work, the Strategic Health IT Advanced Research Projects (SHARP) demonstrated the need for standardization of data semantics using terminology services when normalizing Electronic Health Record (EHR) data[1]. While clinical data interoperability is the overarching goal, interoperability of the terminology services themselves can be a catalyst to achieving this. The standardization of terminology services can not only provide predictable integration patterns - and thus, greater uptake - but also promote sharing of terminology resources across the enterprise and beyond.

Quality Attribute 2: Adaptability. The use cases for terminology systems are continually changing and evolving. Meaningful Use, a large incentive program for leveraging value from the EHR, phases in new functionality over several years[34]. The standards landscape is also changing. Specifically, the increasing use of Fast Healthcare Interoperability Resources (FHIR)[35] will place new demands on terminology systems. Responding to stakeholder needs is critical, and we expect these needs to evolve over time[36]. We use this quality attribute to examine how easily and quickly the system may be changed to meet these evolving needs[32].

Quality Attribute 3: Usability. This quality attribute measures the “quality of a user’s experience”[32], with a particular focus on user goals, motivations, and background. Software tooling for terminologies cannot be usable by terminologists alone - it takes a varied mix of subject matter experts to extract the maximum knowledge from the data[37]. Our target user base is highly skilled and often specialized, so impeding these users with usability issues is an expensive proposition. Historically, however, many health care systems are difficult for the intended users to use because they lacked a user-centered design[38]. This leads to poor adoption and can have a direct impact on system success[39]. As usability is of particular interest to our system, we utilize the TURF Framework as a design-time guide - or as the framework states, guidelines for “built-in usability”[40]. This framework, originally designed for analyzing EHR usability, focuses analysis into four components: Task, User, Representation, and Function. Respectively, these components examine the steps or tasks that the user must complete, who uses the system, how the tasks are represented to the user, and the basic function the system is to perform. Using this framework will scope our current qualitative design-time discussion and provide a platform for future quantitative usability tests.

Implementation

With a concrete use case providing functional requirements and enumerated quality attributes, we now have a mechanism for analyzing an implemented system. Our prototype system implementation is based on three main pillars: (1) a Common Terminology Services 2 (CTS2)[41] compliant network of terminology services, (2) a user-centered graphical user interface to expose functionality to end users, and (3) a loosely-coupled, componentized architectural style. These three implementation focuses are described further in the sections below.

Terminology Service: CTS2

CTS2 is an Object Management Group ® (OMG) terminology services standard, and includes both a structural model and service specification. It is based on Representational State Transfer (REST)[42] principles, and is comprised of a Platform Independent Model (PIM) and two Platform Specific Models (PSM)s.

PIM. CTS2 is specified using Unified Modeling Language® (UML)[43]. Using a platform-independent modeling representation allows for (1) an implementation-independent yet unambiguous specification, and (2) the ability to derive platform-specific models tailored to a specific implementation or computational platform.

PSM. The OMG specification provides two platform-specific models, Hypertext Transfer Protocol (HTTP)[44] REST and Simple Object Access Protocol (SOAP)[45]. For our implementation, we will focus primarily on the REST PSM.

Implementing the Specification. To speed development, the CTS2 Development Framework² was used as a base for implementation. This open-source project is a toolkit for building CTS2 compliant applications, providing compliant HTTP REST bindings, parameter validation, error handling, and a variety of other features. This leaves implementers responsible for more use case specific tasks, such efficient storage and retrieval of terminology data.

To align with the REST architectural style, the CTS2 specification is divided into the structural representation of resource types (Structural Profiles) and a common interface to interact with them (Functional Profiles). As stated above, our system at a minimum must support value set and mapping resources. This requires, at a minimum, a CTS2 service which supports the VALUE_SET_DEFINITION and MAP_VERSION structural profiles. Functionally, to allow full read/write access to these resources, the READ, QUERY, and MAINTENANCE functional profiles should be implemented. See the full OMG specification (http://www.omg.org/spec/CTS2/) for more information on these profiles.

Graphical User Interface: The CTS2 Workbench

User experience is of critical importance to our system, and nothing factors into user experience more than the user interface. It is important, however, that although the system is standards-based, it is user-centered. This means that to maximize usability, user interfaces must be in alignment with the cognitive models of the intended users, not simply expose the standardized functionality. For our prototype system, we propose the CTS2 Workbench, a web-based platform for interacting with terminology resources. Although functionally based on CTS2, the Workbench aims to abstract as much detail as possible away from the end user, favoring user task accomplishment over 100% CTS2 functionality exposure. Selected functional capabilities are further described below.

Value Set Import. In keeping with our user-centered approach, it is important to understand how value sets (or data dictionaries) are currently being managed. Spreadsheets are ubiquitous in the enterprise, readily available to end users, and for better or worse, serving important roles in business function[46]. For our purposes, they are also a simple storage mechanism for tabular data - a schema in which value sets and mappings may be readily fit. Rather than force an alternative workflow onto the user, we prefer to leverage the existing spreadsheets by viewing them as part of the workflow[47]. Figure 1 shows how the CTS2 Workbench, via a graphical value set import wizard, can accept copy/pasted spreadsheet data and consume it as a CTS2 value set. We assume no a priori knowledge of the imported data structure, so the user is required to apply the appropriate metadata to the parsed columns via a drag-and-drop interface.

Figure 1.

Importing a CTS2 value set using data from a spreadsheet with user-applied drag-and-drop metadata.

Mapping Creation. At a high level, terminology mapping is an exercise in linkage. This is important to note, because through past experiences and daily environmental interactions, users may have pre-conceived cognitive models of how linkages are represented. We can capture these notions as image schemas, or representations of these existing models[48]. Constructing a CTS2 MapEntry resource is the functional goal of mapping concepts, but approaching this activity with the linkage image schemas in mind will improve usability. Intuitively, a line connecting two objects is a strong way to convey linkage[49]. Figure 2 contrasts an approach based heavily on the CTS2 structure (Detailed View) with one aligned to a linkage image schema (Simple View). The CTS2 Workbench is implemented to allow both views to be used, giving users the option of either a simplified interface or a more powerful, detailed one. This layered approach to interface complexity is used throughout the CTS2 workbench and can be an effective way of engaging users with different levels of experience or domain knowledge[50].

Figure 2.

Using established cognitive models to abstract CTS2-specific details when creating terminology mappings.

Architectural Style: Microservices

Microservices is an architectural style where targeted, task-specific software modules are implemented, deployed, and maintained independently, while together functioning to fulfill a larger task[51,52]. Using this style can allow for rapid, incremental expansion of the system as needs arise. For example, in our prototype, functionality was added to the system to automatically map two value sets based on lexical similarity. This presented two challenges: (1) it was outside of the scope of the CTS2 specification, and (2) computing lexical similarity is complex task. By deploying this functionality as a microservice, we are able to wrap CTS2 services without modifying the larger CTS2 infrastructure. Also, because this service has a separate development/deployment lifecycle, we are free to redeploy rapidly as our lexical mapping implementation improves.

Discussion

Quality Attributes. Seventy value sets specified by the PCORnet CDM were imported into the system, as well as an increasing number of internal value sets and mappings from various sources. The CTS2 specification demonstrates the ability to model these constructs without degradation of semantics. More importantly, via microservices, our architecture is positioned to respond to evolving user demands. This demonstrates a degree of Adaptability.

Leveraging existing terminology sources reduces the system implementation burden. By utilizing the CTS2 specification, we are able to consume data from the National Cancer Institute (NCI) CTS2 implementation.³ This rich source of data provides numerous standard vocabularies, eliminating the need for us to manage them ourselves. Because the data and service interactions have been standardized, the CTS2 Workbench is able to consume both data points seamlessly. Without the Interoperability enabled by CTS2, system cost would have been much higher.

Centering the design on the user drove much of the implementation. At the beginning of the LHSNet effort, all value sets and mappings were managed on spreadsheets. Rather than disregard this process as inefficient, it was leveraged as insight into the cognitive models of end users. Placing a focus on importing data from spreadsheets also allows us to lower the barrier to entry of the system. Focusing on the user, their existing processes, and their cognitive models allows the system to have high potential Usability.

TURF Framework. The four components of the TURF Framework played a large role in the usability design. First, the User Analysis focused mainly on ETL developers engaged in creating the PCORnet CDM compliant data mart for the LHSNet project. This analysis, conducted using semi-weekly meetings, provided an overview of their experience with terminology services as well as their motivations for applying these services to an ETL process.

Next, LHSNet and two related use cases (i2b2 and OHDSI) were examined for overall functional requirements. This allowed us to derive some generalized functionality statements necessary to support creation of the PCORnet CDM compliant data mart, our primary use case. Aligning the design to concrete use cases was part of the Functional Analysis of the system.

After analyzing functionality, Task Analysis was used to determine the steps currently taken by users to facilitate the ETL process. By examining the users’ current workflow and tools, we were able to align the architecture to incorporate existing spreadsheet-based methods by providing import functionality. Furthermore, through task analysis, we can isolate steps in the user processes that can be streamlined with additional tooling support. Using microservices, we can quickly respond to this need, as demonstrated by the automated mapping example.

Finally, Representation Analysis was used to ensure user interface components expressed these tasks in straightforward ways. Through interviews of LHSNet ETL developers and an analysis of their current tools, alignment of the design to their existing cognitive models could be measured. Through this process, mapping visualization was identified by the users as a deficiency of the spreadsheet-based approach. An image schema was developed for this feature in collaboration with the users and served as the basis for implementation, shown in Figure 2. Iterative development with user feedback was used to validate and refine the implementation.

Summary. We find that these quality attributes along with the TURF Framework are effective architectural tools for designing a user-centered terminology system. Through our prototype implementation, we demonstrate that the design-time emphasis on usability, interoperability, and adaptability can be successfully applied to the development of a terminology system, maximizing system utility.

Limitations and Future Work. For the LHSNet project, semantic concept to concept alignment was not necessarily sufficient. Smoking Status was one such example. As Figure 3 shows, the alignment of semantics sometimes depends on business logic. In this example, we attempt to align the internal semantics of tobacco use with the PCORnet CDM. To be classified as a PCORnet smoker, we must assert that tobacco is currently in use and that the tobacco is being smoked. As shown by the PCORnet CDM value set, further classification of light/heavy/etc., is possible, introducing the need for further business rules. Although the CTS2 specification supports a rule-based mapping, it is unspecified as to how those rules should be encoded or executed. Furthermore, user interaction with business rules (such as authoring and testing) is often difficult for non-technical users[53], and would introduce new usability challenges.

Figure 3.

Intermixing business logic and semantic mapping: A flowchart for aligning Smoking value sets.

Although the TURF Framework served our need as a design-time guide for building-in usability, a quantitative usability study using this framework was beyond the scope of this work. As the prototype implementation matures, the TURF Framework can be used to gather usability metrics (such as task completion time), which in turn can be used to provide evidence-based recommendations for future development iterations.