9 Appendix I: Clinical Data Standards
In this appendix, we describe several data standards that have been developed to support consistent representation, exchange, and analysis of clinical data. These standards can be filtered into two main categories: syntactic and semantic. In literature, syntax refers to the structure of a sentence and the constraints placed upon it by rules of grammar, while semantics refers to the meaning of the words themselves that are used within the sentence. In data modeling, syntactic standards refer to how concepts are organized, while semantic standards define the concepts themselves. Syntactic standards are sometimes referred to as schemas, data models, common data models, and specifications. Semantic standards are typically called terminologies, ontologies, vocabularies, and knowledgebases. While there can certainly be exceptions to this generalization, the distinction of a “standard” as syntactic or semantic can be an important first step for prospective users.
9.1 Syntactic Clinical Data Standards
Data modeling can be undertaken for a variety of purposes, one of the most common is to ensure interoperability between data obtained from different sources. For example, developers of a new clinical trial who want to ensure that data collected across sites can be collated properly create a case report form to “standardize” the various elements collected during the enrollment and treatment of a patient. This case report form can be thought of as a syntactic standard for all participants of the clinical trial. A more familiar example to many is the effort being undertaken by the biomedical informatics community at large to “standardize” the data collected in electronic health records (EHRs) in thousands of hospitals across the world. Facilitated by Health Level Seven (HL7), a professional standards organization, working groups have formed to crowd-source the creation of a syntactic standard known as HL7 FHIR. This standard puts forth a consensus view of what members of the community see as essential elements for various aspects of the clinical domain (e.g., which data fields are necessary to accurately represent a laboratory test, a diagnosis, a specimen, a clinical encounter, etc.). In each of these cases, individuals with subject matter expertise have come together to define which data elements are essential to the use case, and have formalized certain rules about those data elements. Some of the common features of a syntactic data model are shown in Table 1.
| Feature | Description | Example |
|---|---|---|
| Field Name | The name of the component data element. | medication_name |
| Data Type | The form that the data should take when reported by the user. | Code (from a predefined list of values) |
| Cardinality | An indication of whether the value is required for the field, and if so, how many instances. | 0..* (can be left blank, or have one or more values) |
| Terminology Bindings | A reference to a semantic standard of some kind that defines the meaning of the field | RxNorm |
One of the most pervasive issues with any standard, both syntactic and semantic, is ongoing maintenance. Many syntactic standards are fit-for-purpose and represent the consensus of a specific group, at a specific time, who had a specific use case. This issue is mitigated somewhat by professional standards organizations who provide long-term maintenance of the models/schemas/specifications. It is important for users to investigate the source of any syntactic standard being considered and to try to understand what pipeline may exist for requesting help or modifications. A few syntactic standards have been so well-maintained, and have therefore been used in so many different initiatives, that they have been designated as “Common Data Models”. Below is a brief description of some leading common data models.
9.1.1 HL7 FHIR
Fast Healthcare Interoperability Resources (FHIR) is a standard for the exchange of health data. It is described as “Designed to enable the exchange of healthcare-related information. This includes clinical data as well as healthcare-related administrative, public health and research data. It covers both human and veterinary medicine and is intended to be usable world-wide in a wide variety of contexts, including in-patient, ambulatory care, acute care, long-term care, community care, allied health, etc.” (Health Level Seven n.d.). FHIR represents data fields in the context of “resources”, which are discrete building blocks that can be composed to accurately represent clinical scenarios. Each resource represents a particular type of healthcare information, such as a patient, encounter, condition, observation, or medication request. FHIR defines the structure in which healthcare information is represented and exchanged, while semantic terminology systems provide standardized codes that can be used within those resources to identify clinical concepts, diagnoses, medications, and observations. FHIR defines both the structure of these resources and application programming interfaces (APIs) for exchanging them (Health Level Seven n.d.).
In its second decade of development, FHIR has been implemented in EHRs worldwide. As stated previously, it is primarily developed by working groups that consist of a variety of stakeholders (clinicians, data scientists, statisticians, regulatory experts, etc.). Due to the rigorous balloting process developed by HL7, users are protected against compatibility issues and backward compatibility by clear and careful bureaucratic procedures.
9.1.2 OHDSI OMOP
The Observational Health Data Sciences and Informatics (OHDSI) specification for the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is described as “an open community data standard, designed to standardize the structure and content of observational data and to enable efficient analyses that can produce reliable evidence” (Observational Health Data Sciences and Informatics n.d.b). OMOP organizes data fields into tables which can be instantiated in a relational database or other tabular format (such as spreadsheets). Data from source systems can be mapped from their native formats and source codes into the standardized structure and vocabularies of the OMOP CDM (Observational Health Data Sciences and Informatics n.d.a). OMOP’s standardized vocabularies incorporate concepts from many semantic terminology and classification systems, more information about these vocabularies can be found here (Observational Health Data Sciences and Informatics n.d.c).
Officially released in 2009, OMOP has been a mainstay for academic medical centers internationally. Many institutional data warehouses have used OMOP modeling to harmonize their content and enable interoperation with other data sources. It has also been used for other prominent biomedical initiatives such as the All of Us Research Program in the United States (see more information about All of Us in Section 5.4.2). By organizing data from diverse sources into a common structure, OMOP enables researchers to analyze data consistently across institutions and health systems.
9.1.3 CDISC SDTM
The Clinical Data Interchange Standards Consortium (CDISC) specification for the Study Data Tabulation Model (SDTM) is described as “a standard for organizing and formatting data to streamline processes in collection, management, analysis and reporting. Implementing SDTM supports data aggregation and warehousing; fosters mining and reuse; facilitates sharing; helps perform due diligence and other important data review activities; and improves the regulatory review and approval process” (Clinical Data Interchange Standards Consortium n.d.a). Actively developed since 2013, SDTM is one of the required standards for clinical trial data submissions to the U.S. Food and Drug Administration (FDA) and is widely implemented by pharmaceutical companies and other clinical research organizations. SDTM organizes concepts (each with a trademark uppercase name that is concatenated and condensed) into domains and subsequent classes. Users rely on a detailed PDF implementation guide that is published on the CDISC website (Clinical Data Interchange Standards Consortium n.d.b). Though specific to clinical trials, it can be a useful syntactic standard for other clinical data harmonization needs as well.
9.1.4 FDA Sentinel
The FDA Sentinel model is described as “a long-term effort to improve the FDA’s ability to identify and assess medical product safety issues. The Sentinel System is an active surveillance system that uses routine querying tools and pre-existing electronic healthcare data from multiple sources to monitor the safety of regulated medical products” (U.S. Food and Drug Administration n.d.). First released in 2010, it also has deep ties to the FDA and has been implemented by other federal agencies, such as the National Institutes of Health (NIH) Collaboratory Distributed Research Network (DRN). It is available in a publicly accessible markdown format that contains the constraints, cardinality, data types, and other features that are common in a syntactic standard.
9.1.5 PCORnet
Adapted from the FDA Sentinel model, the National Patient-Centered Clinical Research Network (PCORnet) data model is a shared schema that allows data collected at each participating site to interoperate. Developed to represent both observational as well as trials-based research data, it is organized into tables that contain many similar features as the other models described here (The National Patient-Centered Clinical Research Network n.d.). See more information about PCORnet in Section 5.5.1.1.
9.1.6 i2b2
The i2B2 model is among the oldest clinical common data models still in use, having been initially developed in 2004. They describe their approach as “a ‘star schema’. Instead of separate tables for diagnoses, medications, and other data types, all patient observations are stored in a single ‘fact’ table” (Klann n.d.). With concepts organized into tables and fields, it follows the convention that is adhered to by most clinical data modeling efforts. It has been used by an international network of collaborators and has been adapted into several subsequent initiatives, such as the Accrual to Clinical Trials (ACT) project. Interestingly, the documentation for the i2B2 model creates a clear distinction between the syntactic standards set forth and the semantic standards that are bound to (required) for its fields. It says, “A separate ontology describes the different codes that are placed in this fact table. As a result, institutions can use their own local codes, without having to map to common code sets.” The importance of this distinction will be described below in the section on Semantic Clinical Data Standards.
9.1.7 Oncology-Specific Syntactic Standards
In addition to “common” data models, there are a handful of oncology-specific syntactic standards that are worth including in this overview.
9.1.7.1 HL7 FHIR mCODE
The Minimum Common Oncology Data Elements (mCODE) specification is an implementation guide that describes a collection of FHIR profiles (Health Level Seven n.d.). The “base” FHIR standard was always intended to be constrained by profiles to specific use cases. These profiles include increased stringency for cardinality and even some “extensions” or additional fields. The mCODE profiles are intended to be used to represent the main components of clinical oncology and guide the future of EHR oncology modules.
9.1.7.2 OMOP Oncology Extensions
The OMOP model is currently being expanded in response to its ever-present variety of use cases. The Oncology Extensions were undertaken to better accommodate the complex concepts typical to oncology (e.g., cancer staging, tumor classification, chemotherapy regimens, radiation therapy cycles, response assessment, etc.) (Observational Health Data Sciences and Informatics n.d.b).
9.1.7.3 D4CG PCDC
The Pediatric Cancer Data Commons (PCDC), housed at the University of Chicago, is the world’s largest set of harmonized pediatric cancer data. More information about the PCDC can be found in Section 5.3.2.2. The underlying data model represents consensus from a wide variety of clinical stakeholders (pediatric oncologists, radiologists, surgeons, genetic counselors, statisticians, etc.) from institutions spread over 40 countries and currently spanning 16 different cancers (Data for the Common Good n.d.).
9.2 Semantic Clinical Data Standards
Unlike syntactic data standards, which focus on the organization of clinical data concepts, semantic data standards focus on the meaning of clinical data concepts. The goal of semantic interoperability is for meanings of terms and codes to be consistent and sharable across healthcare systems. Terminologies and vocabularies define terms for a specific domain (in this case, clinical care), creating a common language to work with (De Mello et al. 2022). Ontologies are classifications that formally define relationships between concepts (Callahan et al. 2023).
Concepts in data standards can be pre-coordinated or post-coordinated. A pre-coordinated concept is defined before use, such as “severe knee pain”. A post-coordinated concept uses a primary concept to represent the clinical observation, but can be combined with other codes for additional information, such as combining a “knee pain” concept with the modifier “severe”.
9.2.1 Terminologies
9.2.1.1 SNOMED CT
Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) is a clinical terminology that provides consistent representation of clinical concepts. The clinical concepts include clinical findings (such as signs and symptoms), procedures, body structures, and other concepts. SNOMED CT provides a standardized way to represent data captured by clinicians (SNOMED International n.d.). SNOMED promotes consistency in the representation of clinical data across clinicians and institutions and organizes concepts hierarchically.
9.2.1.2 ICD-10-CM
The International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) is a terminology for coding diseases and medical conditions used in the United States. It is built on the ICD-10, the International Classification of Diseases maintained by the World Health Organization (U.S. Centers fo Disease Control and Prevention n.d.). ICD-10-CM codes are often required for diagnosis coding in healthcare billing, and also useful for clinical research.
9.2.1.3 RxNorm
RxNorm provides a terminology for clinical drugs, and links these names to other drug terminologies and pharmacy systems (National Institutes of Health n.d.). Healthcare facilities use different sets of drug names when recording drug information, which causes problems when combining data from multiple facilities. RxNorm translates these different naming systems into a standardized set of drug names, while also representing medication ingredients, strength, and dosage form.
9.2.1.4 LOINC
Logical Observation Identifiers Names and Codes (LOINC) is the international terminology for laboratory tests, measurements, and clinical observations (Regenstrief Institute n.d.). Different healthcare systems have different ways of identifying tests and observations. LOINC provides standardized identifiers for laboratory tests, measurements, and other clinical observations, while the associated result records the value obtained.
9.2.1.5 CPT
The Current Procedural Terminology (CPT) is a terminology for medical services and procedures maintained by the American Medical Association. This terminology provide standardized identifiers to be used by physicians and other health care providers (American Medical Association n.d.).
9.2.1.6 NCIt
The NCI Thesaurus (NCIt) is a cancer-focused terminology for NCI and other systems, including terms for clinical care, research, and administration. It contains codes for biomedical concepts and cross-links between concepts (National Cancer Institute n.d.).
9.3 Applying Data Standards: Computational Phenotypes
Research on secondary clinical data requires identifying patients with the appropriate characteristics. A study of relationships between genetic tests and prescribed medications for women with breast cancer will require precise definitions of the types of cancer diagnoses, medication, and genetic tests of interest. Computational phenotypes (also referred to as computable phenotypes and phenotype algorithms) are structured selection criteria, used to describe phenotypes used in research (Mo et al. 2015). These phenotypes must be carefully and rigorously constructed to support reproducible research.
Development of a computational phenotype often starts with a relatively unstructured and informal description, such as the breast cancer example given above. Each of the components of the original description can then be refined into a more precise definition based on the representations of those concepts in the source data set. For example, the search for “women with breast cancer” might start with an examination of how gender is represented in the source data and the determination of values acceptable for the current study. For example, some systems might use “F” or “M” for female or male, while others might use “Female” and “Male”. The appropriate value(s) would be part of the clinical phenotype, along with any rules describing when patients with another value for gender should (or should not) be included.
A similar definition would be needed for breast cancer. In many EHR datasets, diagnoses are recorded in ICD codes (described above in Section 9.2.1.2). Since the mid-2010s, these will likely be ICD10 codes; earlier data will likely be ICD9. Other datasets may have ICD-O (ICD oncology) codes. Many studies will specify a range of codes in one or more of these schemes. For example, breast cancer might be defined as 174.* in ICD9, C50.* in ICD10, or ICD-O codes C500-C509. ICD9 or 10 codes are likely to be found in EHR notes; ICD-O codes are more likely to be found in cancer registry data. Patients with any of these codes might be potentially considered to be breast-cancer patients.
| Specific Code for Breast Cancer | ICD system | Examples |
|---|---|---|
| 174.* | ICD9 | 174.6: Malignant neoplasm of axillary tail region of female breast |
| C50.* | ICD10 | C50.4: Upper-outer quadrant |
| C500-C509 | AICD-O | C506 Axillary tail of breast |
Similar decisions can be made for other facets of the research question at hand. Comorbidities, medications, patient ages, and other demographic features are all likely represented as structured data and can be either mapped to standard vocabularies (ICD codes for comorbidities; RxNorm codes for medications, etc.) or directly extracted. Projects including details extracted from notes via natural language processing will also need to define the variables extracted and how they are represented. For example, genetic testing details extracted from notes might be mapped to a standardized list of genes.
Additional details available in the text and structured data might be used to determine how patients are selected or analyzed. Diagnoses, medications, and procedures in structured data are often associated with dates or full timestamps. These data can be used to further refine computational phenotypes to include temporal relationships: for example, restricting potential side effects such as nausea to incidents occurring after (as opposed to before) the administration of chemotherapy.
Accurate computational phenotyping may also require consideration of the dynamics of clinical care. In one project involving computational phenotyping with breast cancer, consultations with collaborating oncologists led to the insight that a single ICD code for breast cancer might be associated with an order for a diagnostic test, which might or might not indicate a positive diagnosis. The project team decided to adopt multiple ICD codes for each included patient as a more reliable assurance of a positive diagnosis. Similar issues might arise for medications such as dexamethasone that might be used for cancer treatment in some, but not all, circumstances.
Precise definitions of all of the necessary criteria can be converted into database queries or functional code capable of extracting relevant patients and attributes from EHR platforms or other data stores. Given the challenges associated with creating computational phenotypes, reuse of prior work is preferred whenever possible. Potential starting points for reuse include descriptions in prior work and entries in repositories such as the Phenotype Knowledge Base, which contains complete definitions for previously used phenotype algorithms (such as this example for breast cancer), or or the National Library of Medicine’s Value Set Authority Center, which contains lists of codes associated with diagnoses of interest (such as this example for breast cancer) (PheKB n.d.) (National Library of Medicine n.d.).