We will demonstrate Layered Schema Architecture (LSA) as a novel semantic harmonization tool to make health-related records research and AI-ready. LSA is designed to capture data, contextual metadata, and semantics to preserve the correct meaning of data through transformations in an ecosystem where multiple data standards and conventions exist. The specific examples in this demonstration will deal with the harmonization of clinical data and social needs screening survey data collected from disparate systems using multiple data standards and ontologies.
The longitudinal health data from large diverse populations with varying social, economic, geographic, and environmental conditions is a highly valuable resource for medical and public health researchers through the creation of various data commons where disparate data are structured and harmonized to expand research options. Many challenges hinder the complete and eficient capture and exchange of health data, including: 1) a lack of semantic interoperability across systems; 2) the varying adoption of data standards within and between systems; 3) a lack of standardized metadata; and 4) the poor integration of electronic health records (EHR) data with data from other relevant sources such as social services, environmental measurements, patient-entered, and data collected from wearable devices.
A challenge to semantic harmonization is the ingestion of data from increasingly diverse
sources where vendor specific variations and non-standard representations are common. Some
examples include data from wearable devices, diferent social needs screening tools, and public
datasets. Another challenge is the dificulty in interpreting data based on context. Semantic
harmonization has to take into account the context in which data are captured as well as the
context in which data will be used after transformation. A common data model (CDM) such as
Observational Medical Outcomes Partnership (OMOP [
A common approach for the semantic harmonization of such data involves developing extracttransform-load (ETL) scripts for each data source. This approach hardwires source-specific variations in data (such as measurement units, coding systems, organizational conventions or extensions to standards) while losing valuable contextual information (e.g. measurement variations for laboratory results, patient-reported vs. physician-entered data). This approach also lacks a standardized and reproducible way to capture and distribute relevant metadata.
The “Layered Schema Architecture” (LSA) [
A schema is a machine-readable document that describes the structure of data. JSON and XML
schemas are widely used to generate executable code from specifications and to check structural
validity of data. LSA extends schemas (such as FHIR[
A schema variant is represented using a labeled property graph (LPG) that has a node for each data field. An LPG is a directed graph where every node and edge contain a set of labels describing its type or class, and a set of properties that represent named values. An LPG allows assigning tags that represent diferent types of metadata to fields. A field may be a simple value, a structured object (e.g a JSON object, array, polymorphic object), or a reference to another schema.
Diferent schema variants can be used to ingest data that shows variations based on data source. Data variations can be structural (e.g. additional data fields, extensions) or semantic (e.g. measurements in diferent units, diferent ontologies or coding systems), and can be due to diferent vendor implementations, local conventions, or regulations. Ingesting structured data using a schema variant creates an LPG whose nodes combine the annotations from the schema variant and data values from the input.
A high-level overview of the data processing pipeline to ingest FHIR messages and SDoH surveys
is illustrated in Figure 1. FHIR ingestion uses a schema variant that enriches standard FHIR
schemas with tags for terminology database lookups and data privacy information. The first
overlay contains tags that specify lookups in a terminology database. These tags are used by the data
ingestion logic to add OMOP concept ids for codes given in diferent coding systems. The second
overlay assigns data privacy vocabulary [
The survey data used in our example are collected using Protocol for Responding to &
Assessing Patients’ Assets, Risks & Experiences (PRAPARE)[
The second stage converts the ingested data to the database graph model that organizes
conditions, measurements, observations, etc. as clusters of nodes linked to a person object.
This database graph model provides a convenient representation to perform searches, or to
perform further normalizations on data such a de-duplication, or imputations. Conversion of
ingested data to the database graph model is again done using schema variants. The overlays
for the “graph shaping” stage assign graph queries (using openCypher [
The PRAPARE survey data are ingested as Obvervations using an overlay for that assigns OMOP concept ids for questions and answers to the corresponding concept_id and value_as_concept_id fields. The overlay also adds the PRAPARE and Survey tags to the Observation labels. This allows us to diferentiate between observations coming from clinical data and observations coming from surveys. Such metadata is useful in determining the situations under which data is captured, and in assigning “confidence levels” to data elements.
OMOP uses a relational data model, thus it is necessary to translate data stored in the graph database after the research population is identified. Once research population is identified, each Person graph is exported from the database, shaped to fit to OMOP schemas using another “graph shaping” stage, and exported in tabular format. A sample output for OMOP observations table is given in Figure 2.
Our goal is to develop a reusable and scaleable interoperability framework to ingest and semantically harmonize health-related data and metadata from disparate sources in a research data warehouse setting. While our focus is producing OMOP output for researchers, the architecture is flexible enough to accommodate other CDMs. Our eforts so far suggest that incorporating new data sources using LSA is faster compared to ETL scripting, and yields reusable artifacts.
The LSA approach ofers a method for the management of relevant metadata that can be important in building high quality data sets. Such metadata may include information about the context in which data was captured (e.g. whether data was entered by a provider or selfreported), processed (e.g. whether data was imputed, or fuzzed for deidentification purposes), or stored (e.g. the source filename for the data point).
The use of labeled property graphs as the core data model ofers unique opportunities, such as the ability to use multiple ontologies to tag data. Future work in this area will involve the use of graph properties for data imputations, evaluating the efects of diferent graph models for building study populations, and the incorporation of natural language processing tools to tag textual data.
LSA is an open-source project [
DARTNet Institute is the primary grantee of this project, and provided the sample datasets and original ETL scripts. We thank DARTNet Institute for their partnership and their valuable insight.
This project is supported by the Ofice of the National Coordinator for Health Information Technology (ONC) of the U.S. Department of Health and Human Services (HHS) under grant number 90AX0034, Semantic Interoperability for Electronic Health Data Using the Layered Schemas Architecture, total award $999,990 with 100% financed with federal dollars and 0% ifnanced with non-governmental sources. This information or content and conclusions are those of the author and should not be construed as the oficial position or policy of, nor should any endorsements be inferred by ONC, HHS, of the U.S. Government.