IP Review

Unattributed Code Systems

http://unstats.un.org/unsd/methods/m49/m49.htm

Copyright Fragment

This fragment is available on en/technical_artifacts.html

No use of external IP

Copyright and Registered Trademark Uses

IG © 2023+ HL7 International / Biomedical Research and Regulation. Package hl7.fhir.uv.omop#1.0.0 based on FHIR 5.0.0. Generated 2026-04-27 Links: Table of Contents | QA Report | Version History | CC0 | Propose a change ( src )
hl7.fhir.us.hai: Healthcare Associated Infection Implementation Guide ®© HL7 | CC0 ( src )
FHIR to OMOP FHIR IG, published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-omop-ig/ and changes regularly. See the Directory of published versions ( src )

External References

Type Reference Content

web github.com FHIR to OMOP FHIR IG, published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-omop-ig/ and changes regularly. See the Directory of published versions

Type	Reference	Content
web	github.com	FHIR to OMOP FHIR IG, published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-omop-ig/ and changes regularly. See the Directory of published versions
web	ohdsi.github.io	OHDSI OMOP CDM Documentation
web	ohdsi.github.io	The OMOP CDM treats race and ethnicity as single-valued demographic attributes on the `PERSON` table, populated from a controlled set of Standard concepts in the OHDSI Standardized Vocabularies. When a FHIR source carries a single race value and a single ethnicity value per person, transformation is a direct lookup into the OHDSI Standardized Vocabularies. When a FHIR source carries more than one race value per person, the CDM's single-slot structure is preserved by populating `PERSON.race_concept_id` with a designated "more than one race" concept and by capturing each individual race value as a record in the `OBSERVATION` table using the Value-as-Concept Pattern . When a FHIR source carries more than one ethnicity value per person, a structurally parallel pattern applies. Both patterns follow the ratified OHDSI Themis convention for handling multiple races or ethnicities per person and preserve full downstream analytic access to the individual values while keeping `PERSON` compliant with CDM structural rules.
web	athena.ohdsi.org	The authoritative, balloted binding for this IG is the OHDSI Race and Ethnicity Value Set described in the next section; the table above identifies the most commonly populated Standard concepts within that value set but is not a substitute for the value set itself. A complete, current listing of Standard race and ethnicity concepts is available through Athena by filtering on `domain_id = 'Race'` or `domain_id = 'Ethnicity'` with `standard_concept = 'S'` .
web	github.com	Open a submission with the OHDSI Themis project at https://github.com/OHDSI/Themis/issues describing the unmapped source value, so that the mapping gap can be resolved at the vocabulary level rather than worked around in local ETL. This parallels the vocabulary-anomaly reporting pathway described in Reporting Vocabulary Anomalies to the OHDSI Vocabulary Working Group .
web	athena.ohdsi.org	A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists. For example, if the EPISODE_CONCEPT_ID is treatment regimen then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like Afatinib monotherapy .
web	athena.ohdsi.org	A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists. For example, if the EPISODE_CONCEPT_ID is treatment regimen then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like Afatinib monotherapy .
web	athena.ohdsi.org	The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).
web	athena.ohdsi.org	The Concept Id representing the country. Values should conform to the Geography domain.
web	athena.ohdsi.org	The meaning of Concept 4172703 for '=' is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =.
web	ucum.org	FHIR Observation units are embedded within the Quantity type structure, typically utilizing standardized systems such as UCUM (Unified Code for Units of Measure) . The mapping process must preserve unit information through OMOP's `unit_concept_id` field in the Measurement table.
web	www.researchallofus.org	All collected data are maintained and curated by the All of Us Data and Research Center (DRC) and are accessible to researchers through the All of Us Researcher Workbench . The primary data standard and clinical data model utilized by the All of Us Research Program is OMOP.
web	doi.org	Renedo, D., Acosta, J. N., Sujijantarat, N., Antonios, J. P., et al. (2022) . Carotid Artery Disease Among Broadly Defined Underrepresented Groups: The All of Us Research Program. Stroke, 53. https://doi.org/10.1161/STROKEAHA.121.037554 Data Supplement
web	www.ahajournals.org	Data Supplement
web	doi.org	Khan, M. S., Carroll, R. J. (2022) . Inference-based correction of multi-site height and weight measurement data in the All of Us Research Program. Journal of the American Medical Informatics Association, 29(4), 626–630. https://doi.org/10.1093/jamia/ocab251 Data Supplement (additional OMOP concept IDs included in article text)
web	academic.oup.com	Data Supplement (additional OMOP concept IDs included in article text)
web	doi.org	Berman, L., Ostchega, Y., Giannini, J., Anandan, L. P., et al. (2024) . Application of a Data Quality Framework to Ductal Carcinoma In Situ Using Electronic Health Record Data From the All of Us Research Program. JCO Clinical Cancer Informatics. https://doi.org/10.1200/CCI.24.00052 Data Supplement
web	ascopubs.org	Data Supplement
web	forums.ohdsi.org	Report the gap to the OHDSI vocabulary team via the OHDSI Forums or the Vocabulary-v5.0 issue tracker so that the mapping can be added in a future vocabulary release.
web	github.com	Report the gap to the OHDSI vocabulary team via the OHDSI Forums or the Vocabulary-v5.0 issue tracker so that the mapping can be added in a future vocabulary release.
web	ohdsi.github.io	The OMOP CDM is designed for large‑scale aggregation, whether in centralized repositories or distributed research networks. Its domain structure and Standardized Vocabularies allow data from heterogeneous sources—each with distinct schemas and code systems—to be normalized into a single analytic framework. Every concept is assigned a status of Standard , Non‑Standard , or Classification ; only one Standard concept exists for each clinical idea within a domain, eliminating ambiguity and enabling cross‑site comparability. (See: OMOP Vocabulary Concept Structure for additional details)
web	ohdsi.github.io	Because a single FHIR resource may contains multiple clinical ideas, each coded element must be evaluated independently. A FHIR Observation may yield Measurement, Condition Occurrence, or Procedure Occurrence records in OMOP, depending on the specific codes it carries. Terminologies commonly used in FHIR—such as LOINC, SNOMED CT, and RxNorm—frequently align with OMOP Standard concepts. In cases where no Standard mapping exists, particularly in cases such as HL7‑maintained value sets, or local codes, a extension concepts may be added to the OMOP concept table with `concept_id` values of 2,000,000,000 (2 billion) or higher may be created. These “2-billionaires” IDs preserve information without loss and can be retired once the community adopts an official Standard concept. Regular vocabulary updates are therefore essential, both for pipelines ingesting new data and for legacy OMOP datastores. (See: OMOP CDM: Custom Concepts for more information)
web	athena.ohdsi.org	The OHDSI Athena website provides both access to request OHDSI Vocabulary downloads and a comprehensive searchable database that serves dual purposes for mapping activities. Implementers can use this resource to manually browse available vocabularies and identify codes that appropriately match source concepts to Standard OMOP concepts and also receive vocabulary updates when new versions of the OHDSI Stabdardized Vocabularies are published. Utilization of the OHDSI Standardized Vocabularies is essential for validating mappings and resolving complex terminology translation challenges that arise during FHIR to OMOP transformation.
web	github.com	Translate source code to concept ID: Utilise the ConceptMap/$translate FHIR terminology server operation.
web	github.com	Lookup concept properties: Utilise the CodeSystem/$lookup FHIR terminology server operation.
web	github.com	Submissions are made through GitHub issues in the OHDSI/Vocabulary-v5.0 repository , using the templates referenced from the Community Contribution wiki page . Each submission includes a populated template, submission metadata, and a contributor-completed quality checklist. Contributions approved at least two months before a target release are incorporated into that release, which allows ETL pipelines and legacy OMOP datastores to pick up the corrections as part of their routine vocabulary refresh cycle.
web	github.com	Submissions are made through GitHub issues in the OHDSI/Vocabulary-v5.0 repository , using the templates referenced from the Community Contribution wiki page . Each submission includes a populated template, submission metadata, and a contributor-completed quality checklist. Contributions approved at least two months before a target release are incorporated into that release, which allows ETL pipelines and legacy OMOP datastores to pick up the corrections as part of their routine vocabulary refresh cycle.
web	athena.ohdsi.org	Note the table below is only a partial list. A complete listing of type concepts can be found in the OHDSI Standardized Vocabularies and a detailed explanation is available on the OHDSI Vocabulary wiki .
web	github.com	Note the table below is only a partial list. A complete listing of type concepts can be found in the OHDSI Standardized Vocabularies and a detailed explanation is available on the OHDSI Vocabulary wiki .
web	ohdsi.github.io	Drug Exposure
web	ohdsi.github.io	Condition Occurrence
web	ohdsi.github.io	Procedure Occurrence
web	ohdsi.github.io	Visit Occurrence
web	ohdsi.github.io	Measurement
web	ohdsi.github.io	Observation
web	www.hl7vulcan.org	This Implementation Guide was developed under the auspices of the Vulcan FHIR to OMOP work group in collaboration with the OHDSI OMOP + FHIR working group .
web	teams.microsoft.com	This Implementation Guide was developed under the auspices of the Vulcan FHIR to OMOP work group in collaboration with the OHDSI OMOP + FHIR working group .
web	colab.research.google.com	Created to support the Vulcan July 2025 Connectathon, this Jupyter notebook provides basic syntax and specification validation of FHIR JSON and OMOP CSV data for the Vulcan FHIR->OMOP Connectathon. The notebook can be run as-is from within Google Colab (with a Google account) or downloaded and run locally. Upload your FHIR JSON or OMOP CSVs into the colab temporary directory and update the paths accordingly.

web

ohdsi.github.io

OHDSI OMOP CDM Documentation

web ohdsi.github.io The OMOP CDM treats race and ethnicity as single-valued demographic attributes on the PERSON table, populated from a controlled set of Standard concepts in the OHDSI Standardized Vocabularies. When a FHIR source carries a single race value and a single ethnicity value per person, transformation is a direct lookup into the OHDSI Standardized Vocabularies. When a FHIR source carries more than one race value per person, the CDM's single-slot structure is preserved by populating PERSON.race_concept_id with a designated "more than one race" concept and by capturing each individual race value as a record in the OBSERVATION table using the Value-as-Concept Pattern . When a FHIR source carries more than one ethnicity value per person, a structurally parallel pattern applies. Both patterns follow the ratified OHDSI Themis convention for handling multiple races or ethnicities per person and preserve full downstream analytic access to the individual values while keeping PERSON compliant with CDM structural rules.

web athena.ohdsi.org The authoritative, balloted binding for this IG is the OHDSI Race and Ethnicity Value Set described in the next section; the table above identifies the most commonly populated Standard concepts within that value set but is not a substitute for the value set itself. A complete, current listing of Standard race and ethnicity concepts is available through Athena by filtering on domain_id = 'Race' or domain_id = 'Ethnicity' with standard_concept = 'S' .

web github.com Open a submission with the OHDSI Themis project at https://github.com/OHDSI/Themis/issues describing the unmapped source value, so that the mapping gap can be resolved at the vocabulary level rather than worked around in local ETL. This parallels the vocabulary-anomaly reporting pathway described in Reporting Vocabulary Anomalies to the OHDSI Vocabulary Working Group .

web athena.ohdsi.org A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists. For example, if the EPISODE_CONCEPT_ID is treatment regimen then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like Afatinib monotherapy .

web athena.ohdsi.org The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).

web athena.ohdsi.org The Concept Id representing the country. Values should conform to the Geography domain.

web athena.ohdsi.org The meaning of Concept 4172703 for '=' is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =.

web ucum.org FHIR Observation units are embedded within the Quantity type structure, typically utilizing standardized systems such as UCUM (Unified Code for Units of Measure) . The mapping process must preserve unit information through OMOP's unit_concept_id field in the Measurement table.

web www.researchallofus.org All collected data are maintained and curated by the All of Us Data and Research Center (DRC) and are accessible to researchers through the All of Us Researcher Workbench . The primary data standard and clinical data model utilized by the All of Us Research Program is OMOP.

web

doi.org

Renedo, D., Acosta, J. N., Sujijantarat, N., Antonios, J. P., et al. (2022) . Carotid Artery Disease Among Broadly Defined Underrepresented Groups: The All of Us Research Program. Stroke, 53. https://doi.org/10.1161/STROKEAHA.121.037554

Data Supplement

web

www.ahajournals.org

Data Supplement

web

doi.org

Khan, M. S., Carroll, R. J. (2022) . Inference-based correction of multi-site height and weight measurement data in the All of Us Research Program. Journal of the American Medical Informatics Association, 29(4), 626–630. https://doi.org/10.1093/jamia/ocab251

Data Supplement (additional OMOP concept IDs included in article text)

web academic.oup.com Data Supplement (additional OMOP concept IDs included in article text)

web

doi.org

Berman, L., Ostchega, Y., Giannini, J., Anandan, L. P., et al. (2024) . Application of a Data Quality Framework to Ductal Carcinoma In Situ Using Electronic Health Record Data From the All of Us Research Program. JCO Clinical Cancer Informatics. https://doi.org/10.1200/CCI.24.00052

Data Supplement

web

ascopubs.org

Data Supplement

web forums.ohdsi.org Report the gap to the OHDSI vocabulary team via the OHDSI Forums or the Vocabulary-v5.0 issue tracker so that the mapping can be added in a future vocabulary release.

web github.com Report the gap to the OHDSI vocabulary team via the OHDSI Forums or the Vocabulary-v5.0 issue tracker so that the mapping can be added in a future vocabulary release.

web ohdsi.github.io The OMOP CDM is designed for large‑scale aggregation, whether in centralized repositories or distributed research networks. Its domain structure and Standardized Vocabularies allow data from heterogeneous sources—each with distinct schemas and code systems—to be normalized into a single analytic framework. Every concept is assigned a status of Standard , Non‑Standard , or Classification ; only one Standard concept exists for each clinical idea within a domain, eliminating ambiguity and enabling cross‑site comparability. (See: OMOP Vocabulary Concept Structure for additional details)

web ohdsi.github.io Because a single FHIR resource may contains multiple clinical ideas, each coded element must be evaluated independently. A FHIR Observation may yield Measurement, Condition Occurrence, or Procedure Occurrence records in OMOP, depending on the specific codes it carries. Terminologies commonly used in FHIR—such as LOINC, SNOMED CT, and RxNorm—frequently align with OMOP Standard concepts. In cases where no Standard mapping exists, particularly in cases such as HL7‑maintained value sets, or local codes, a extension concepts may be added to the OMOP concept table with concept_id values of 2,000,000,000 (2 billion) or higher may be created. These “2-billionaires” IDs preserve information without loss and can be retired once the community adopts an official Standard concept. Regular vocabulary updates are therefore essential, both for pipelines ingesting new data and for legacy OMOP datastores. (See: OMOP CDM: Custom Concepts for more information)

web athena.ohdsi.org The OHDSI Athena website provides both access to request OHDSI Vocabulary downloads and a comprehensive searchable database that serves dual purposes for mapping activities. Implementers can use this resource to manually browse available vocabularies and identify codes that appropriately match source concepts to Standard OMOP concepts and also receive vocabulary updates when new versions of the OHDSI Stabdardized Vocabularies are published. Utilization of the OHDSI Standardized Vocabularies is essential for validating mappings and resolving complex terminology translation challenges that arise during FHIR to OMOP transformation.

web github.com Translate source code to concept ID: Utilise the ConceptMap/$translate FHIR terminology server operation.

web github.com Lookup concept properties: Utilise the CodeSystem/$lookup FHIR terminology server operation.

web github.com Submissions are made through GitHub issues in the OHDSI/Vocabulary-v5.0 repository , using the templates referenced from the Community Contribution wiki page . Each submission includes a populated template, submission metadata, and a contributor-completed quality checklist. Contributions approved at least two months before a target release are incorporated into that release, which allows ETL pipelines and legacy OMOP datastores to pick up the corrections as part of their routine vocabulary refresh cycle.

web athena.ohdsi.org Note the table below is only a partial list. A complete listing of type concepts can be found in the OHDSI Standardized Vocabularies and a detailed explanation is available on the OHDSI Vocabulary wiki .

web github.com Note the table below is only a partial list. A complete listing of type concepts can be found in the OHDSI Standardized Vocabularies and a detailed explanation is available on the OHDSI Vocabulary wiki .

web

ohdsi.github.io

Drug Exposure

web

ohdsi.github.io

Condition Occurrence

web

ohdsi.github.io

Procedure Occurrence

web

ohdsi.github.io

Visit Occurrence

web

ohdsi.github.io

Measurement

web

ohdsi.github.io

Observation

web www.hl7vulcan.org This Implementation Guide was developed under the auspices of the Vulcan FHIR to OMOP work group in collaboration with the OHDSI OMOP + FHIR working group .

web teams.microsoft.com This Implementation Guide was developed under the auspices of the Vulcan FHIR to OMOP work group in collaboration with the OHDSI OMOP + FHIR working group .

web colab.research.google.com Created to support the Vulcan July 2025 Connectathon, this Jupyter notebook provides basic syntax and specification validation of FHIR JSON and OMOP CSV data for the Vulcan FHIR->OMOP Connectathon. The notebook can be run as-is from within Google Colab (with a Google account) or downloaded and run locally. Upload your FHIR JSON or OMOP CSVs into the colab temporary directory and update the paths accordingly.