Patient Resource Considerations

Mapping Sex and Gender

FHIR to OMOP gender mapping requires attention to both technical precision and the evolving OHDSI conventions around gender and sex data representation. The key to successful implementation lies in establishing clear protocols that respect the OHDSI community's ratified conventions, maintaining comprehensive validation across both Person and Observation domain tables, and preparing for future standard evolution while ensuring current system reliability and accuracy.

NOTE: The OMOP concept identifiers shown in the examples on this page reflect the OHDSI Standardized Vocabularies as they stood when this guide was written. Concept mappings, Standard concept designations, domain assignments, and display names can change between vocabulary releases. Implementers ought to verify these values against the vocabulary version their transformation is bound to rather than copying them forward.

Understanding Both Standards

FHIR Gender Implementation

FHIR implements gender as a CodeableConcept within the Patient resource, providing flexibility in representation while maintaining standardization. The gender field accepts four primary values:

• male: Represents male gender identity
• female: Represents female gender identity
• other: Encompasses non-binary, third gender, or other gender identities
• unknown: Indicates gender information is unavailable or undetermined

The CodeableConcept structure allows implementers to include additional context through display text and system URIs, enabling reference to established terminologies such as SNOMED CT or HL7 value sets.

OMOP Gender Structure

OMOP takes a more rigid approach through the gender_concept_id field in the person table. This field requires a mandatory reference to standardized vocabulary concepts:

• Male: Concept ID 8507 (MALE, Gender vocabulary)
• Female: Concept ID 8532 (FEMALE, Gender vocabulary)
• Unknown: Concept ID 8551 (UNKNOWN, Gender vocabulary)
• Other: Concept ID 44814653 (Unknown, PCORNet vocabulary)

When Two Concepts Carry the Same Display

The last two entries deserve attention, because they show a condition that recurs throughout vocabulary work and is easily mistaken for an error in the guide. Concepts 8551 and 44814653 both carry the display name Unknown. To a transformation engine matching on display text, they are indistinguishable, and a pipeline that resolves concepts by name rather than by identifier will choose between them arbitrarily.

They are not the same concept. 8551 belongs to the Gender vocabulary and sits in the Gender domain. 44814653 belongs to the PCORNet vocabulary and sits in the Observation domain. Neither is a Standard concept. The FHIR other value is being served here by a concept drawn from a different vocabulary and a different domain than the one serving unknown, which is why two rows that look alike carry different meaning.

What separates them is provenance, not display. The vocabulary_id, the domain_id, and the source system that supplied the value are what allow a human reviewer to tell one from the other, and they are what an ETL specification has to record. An implementation that documents only the display name has discarded the information that makes its own assignment reconstructable. This is the practical reason the source value preservation guidance in this guide asks for the original code and system to be retained alongside the resolved concept: a resolved identifier does not always disambiguate itself.

Implementers mapping the FHIR other value ought to record the selection explicitly in their ETL documentation, naming the concept chosen and the basis for choosing it, so that a later reader can distinguish a deliberate assignment from a display-name collision.

The mandatory nature of this field ensures every person record contains gender information, requiring careful handling of missing or null values during transformation.

Important OHDSI Convention Update: The OHDSI community has recognized that the term "gender_concept_id" is outdated and ought to more accurately be "sex_concept_id" to reflect biological sex rather than gender identity. However, due to the significant development effort required to change this field name across all OMOP implementations and package dependencies, this update will be implemented in the next major release of the OMOP Common Data Model.

OHDSI Gender Identity Convention

The OHDSI community has established important conventions regarding gender-related data storage in the OMOP Common Data Model that directly impact FHIR to OMOP mapping strategies. The current gender_concept_id field in the OMOP person table represents a legacy naming convention that causes conceptual confusion. The OHDSI community acknowledges that this field more accurately represents biological sex rather than gender identity. The preferred term ought to be sex_concept_id to reflect this distinction properly.

Implementation Timeline: Due to the substantial development effort required to rename this field across all OMOP implementations, packages, and dependent systems, this change will be implemented in the next major release of the OMOP Common Data Model. Until then, implementers ought to understand that gender_concept_id conceptually represents biological sex.

Ratified Convention for Gender Identity Storage

Scope: This convention applies to any database that captures gender identity information, regardless of data provenance or source system. Core Principle: Any gender-related information that can change over time, particularly gender identity, ought to be stored in the OBSERVATION table rather than the person table. Rationale: The person table is designed for relatively static demographic information, while the OBSERVATION table accommodates time-varying clinical and social observations, making it the appropriate location for gender identity data that might evolve over time.

The key distinctions implementers must understand are:

1. Current State: The gender_concept_id field in the person table ought to be treated as biological sex information
2. Gender Identity: Use the observation table for any gender-related information that can change over time
3. Future Planning: Prepare for the transition to sex_concept_id in the next major OMOP release

By following these implementation guidelines and adhering to OHDSI conventions, healthcare organizations can achieve reliable, compliant, and inclusive gender data transformation that supports both clinical care and research objectives while properly distinguishing between biological sex and gender identity.

Implementation Approach for Gender Identity

When mapping FHIR resources that contain gender identity information (as distinguished from biological sex), implementers should:

1. Person Table: Use gender_concept_id for biological sex information only
2. Observation Table: Store gender identity data using appropriate observation concepts
3. Temporal Handling: Leverage the observation table's date/time capabilities to track changes in gender identity over time

Revised Mapping Approach

Given the OHDSI conventions, the mapping strategy must differentiate between biological sex and gender identity:

For Biological Sex (Person Table):

• Map FHIR sex-related information to gender_concept_id using the established concept IDs
• Treat this as relatively static demographic information
• Use standard validation and transformation rules

For Gender Identity (Observation Table):

• Create observation records for gender identity information
• Use appropriate observation concepts from the OMOP vocabulary
• Include observation dates to track temporal changes
• Link to the person record through person_id

Direct Value Mapping

The core mapping process follows these direct transformations:

Handling Null and Missing Values

The most complex aspect of FHIR to OMOP gender mapping involves managing absent gender information. Since OMOP requires a gender_concept_id for every person record, implementers must establish clear protocols for null value handling.

Recommended Approach: When gender information is completely absent from the FHIR resource, assign OMOP concept ID 0, indicating no appropriate concept could be determined. This approach maintains data integrity while acknowledging information gaps.

Alternative Consideration: Some implementations might prefer mapping null values to concept ID 8551 (Unknown), treating missing information as equivalent to unknown gender. Organizations ought to establish consistent policies based on their specific requirements and regulatory environment.

Advanced Considerations

HL7 Gender Harmony Project Integration

The HL7 Gender Harmony Project produced a FHIR implementation Guide that introduces sophisticated gender and sex categorization that extends beyond traditional binary representations. Implementation teams ought to prepare for enhanced gender concepts including:

• Recorded Sex or Gender (RSG): The sex or gender recorded in official documents
• Sex for Clinical Use (SFCU): Clinically relevant sex information for treatment decisions
• Gender Identity: Personal gender identification separate from biological sex

These concepts will require OMOP vocabulary extensions and updated mapping protocols as standards evolve.

Jurisdictional Compliance

Different healthcare jurisdictions might have specific requirements for gender data representation. Implementation teams must consider:

• Regional terminology preferences and legal requirements
• Cultural sensitivity in gender categorization
• Privacy and security regulations governing gender information
• Coordination between pre-existing local standards and international specifications

Future Considerations

Preparing for OMOP CDM Updates

As the OMOP Common Data Model evolves, implementation teams should:

• Field Renaming: Prepare for the transition from gender_concept_id to sex_concept_id in the next major OMOP release
• Migration Planning: Develop strategies for updating existing implementations when the field name changes
• Documentation Updates: Ensure all internal documentation reflects the conceptual distinction between biological sex and gender identity
• Training Programs: Educate development teams on the proper use of person table vs. observation table for different types of gender-related information

Gender Harmony Project Integration

Monitor Gender Harmony Project developments for vocabulary updates, particularly:

• Enhanced observation concepts for gender identity
• Standardized approaches to temporal gender identity tracking
• Integration with FHIR R5 and future versions

Standards Evolution

• Monitor FHIR and OMOP standard revisions for gender and sex representation
• Maintain flexibility in mapping logic to accommodate new concepts
• Engage with OHDSI community discussions on gender identity best practices
• Prepare for potential additional gender identity observation concepts

Mapping

/// url = 'http://hl7.org/fhir/uv/omop/StructureMap/PersonMap'
/// name = 'PersonMap'
/// title = 'Mapping Patient resource to Person OMOP Domain'
/// status = 'active'
/// description = 'This mapping maps FHIR Patient instances to OMOP Person Table objects.'

uses "http://hl7.org/fhir/StructureDefinition/Patient" alias Patient as source
uses "http://hl7.org/fhir/uv/omop/StructureDefinition/Person" alias PersonTable as target

group Person(source src : Patient, target tgt : PersonTable) {
  // OMOP person ID would be a map from FHIR ID to an external key
  src as s -> tgt then {
    s.id as id ->  tgt.person_source_value,  tgt.person_id = cast(id, 'integer');
  } "personID";
  src.gender as gender ->  tgt.gender_concept_id = translate(gender, 'http://hl7.org/fhir/uv/omop/ConceptMap/GenderClass', 'code'),  tgt.gender_source_value = gender;
  src where (src.gender.empty()) ->  tgt.gender_concept_id = 0,  tgt.gender_source_value = 'unknown' "nogender";
  src.birthDate as bdSrc ->  tgt.birth_datetime = cast(bdSrc, 'dateTime'),  tgt.year_of_birth = (src.birthDate.toString().substring(0, 4)),  tgt.month_of_birth = (src.birthDate.toString().substring(5, 2)),  tgt.day_of_birth = (src.birthDate.toString().substring(8, 2));
}