About the HIEBus Model
These tables reflect the comprehensive data model used by the HIEBus™ data platform to store transactional health data. These tables are organized in a highly normalized and highly expressive structure that captures an enormous portfolio of health data concepts and relationships. As a result, many common queries will require multiple unions and joins. Most analytics use cases will rely on the tables of enriched concepts represented in the simplified models described below. The HIEBus model is provided to ensure that all data concepts that have been integrated into HIEBus can be made accessible via the Bulk Data API.
Core Concepts
The patients Table and Patient Data
The HIEBus patients table manages one row per unique individual within the context of a data source. The patients table contains a demographic_id column that can be joined to demographic tables such as demographics, demographicnames, and demographicaddresses to obtain all demographic information that was provided by a data source to describe a patient.
All clinical and administrative data that is stored in HIEBus is related to a patient. Tables that manage these data (such as encounters, claims, problems, and procedures, etc.) will include a patient_id column that can be joined to patients.id.
The personrecord View
The personrecord view provides a catalog of all unique human individuals (also referred to as persons or HIEBus recordgroups) and has a row for every patient_id that should be used to assemble a comprehensive view of data for a person. A unique human individual may be described by many rows in the patients table if the person has data from multiple source systems. HIEBus provides a person_id to represent a unique person. The personrecord view relates the person_id to the many patient_id values that can be used to obtain all the clinical and administrative data related to the person.
Coded Values, the terms Table, and the termmap View
All coded values that describe the properties of clinical and administrative data that is stored in HIEBus are represented by terms. Terms encapsulate the code, name and code system related to the coded value. Data tables (such as encounters, claims, problems, and procedures, etc.) will have many columns that end in term_id- these columns refer to a term that is used to represent the coded value for that column.
The HIEBus terms table includes both source terms and reference terms. Source terms are coded values that are received from data sources. For source terms, the terms table stores the code and name provided by the source system. Reference terms are coded values that are obtained from code system authorities (such as ICD-10 or HCPCS).
HIEBus maps source terms to reference terms. Join any column ending in term_id to the termmap view using termmap.term_id to obtain the code, name, and code system of the source term provided by the data source as well as the code, name, and code system of all reference terms to which the source term is mapped.
Archive Tables
Most data tables will have an adjacent table with the suffix _archive and an identical column structure. For example, the HIEBus model has an encounters table for all encounters managed by HIEBus and a encounters_archive table that manage historical data for rows that have been fully deleted from the encounters table.
If you are querying the HIEBus model for current data you should ignore all _archive tables. The _archive tables are only useful if you are using a downstream ETL process to extract data from the HIEBus model. In this ETL case, the _archive tables can be useful to identify data that you may have previously extracted from the HIEBus model that should be deleted.
