HL7 Cross Paradigm Implementation Guide: Gender Harmony - Sex and Gender Representation, Edition 1, published by HL7 Terminology Infrastruture Work Group. This is not an authorized publication; it is the continuous build for version 1.0.0. This version is based on the current content of https://github.com/HL7/fhir-gender-harmony/ and changes regularly. See the Directory of published versions

FHIR Design Background

Background and Rationale for FHIR design approach

There were several options considered when representing these sex and gender concepts in FHIR:

• Add new properties in the relevant resources
• Create extensions in the relevant resources
• Create a profile on Observation

Option	Advantages	Disadvantages
Property on resources	1. Easily discoverable in the specification 2. Establishes the properties as first-class data elements.	1. Requires an alternative approach for pre-adoption in prior versions of FHIR. 2. For the Patient resource, which is Normative, a change such as this requires additional implementer and standards community acceptance/review processes.
Extension on resources	1. The extension may be directly pre-adopted in prior versions of FHIR. 2. The extension can be defined in one location and applied to many resources, rather than having to copy and maintain an identical structure on many related resources. 3. We may consider changing the extension to a property in future versions of FHIR. 4. Avoids problems with changing normative content.	1. Extensions are somewhat hidden, so are moderately difficult for implementers to discover.
Profile of Observation	1. Enables collecting a broad set of metadata about the property. However, it is not expected that the metadata Observation enables is necessary or useful for most use cases. 2. Aligns with sexual orientation profile. 3. Avoids problems with changing normative content.	1. Observation profiles are somewhat hidden, so are moderately difficult for implementers to discover. 2. Clients would require additional authorization scopes to access demographic data. For servers that provide only resource-level scopes, patients may not wish to share an Observation just to grant access to Gender Identity, when it would also grant access to labs, vitals, etc. Note: it may not always be viewed as a disadvantage for systems to require additional authorization. Rather, it may be desired in some scenarios

When creating the FHIR extensions, there were several proposed changes to the logical model that were identified. We chose to apply those changes to FHIR structures so that we can solicit feedback via the ballot. As a result of the FHIR R5 and this Gender Harmony Cross Paradigm IG ballot, any resulting required changes to the logical model have been made.

Explicit Decisions:

Gender Identity: extension

Context: This extension is available on all “person” type resources, which includes Patient, RelatedPerson, Person, and Practitioner. It is not included on PractitionerRole, as PractitionerRole refers to Practitioner for demographics.

Sex Parameter for Clinical Use: extension

Note: The Sex Parameter for Clinical Use (SPCU) concept was formerly known as Sex for Clinical Use (SFCU).

Context: The Sex Parameter for Clinical Use extension is available on all FHIR resource types; however, it is intended for use on clinical resource types (e.g., DiagnosticReport, Observation), and enclosing contextual resources (e.g., Encounter, EpisodeOfCare, Patient). We considered limiting the extension only to the resources we expect it to be used on, however there will likely be resources we incorrectly excluded, and new resources created to which it could apply, so we opted to allow it to all resources, understanding that it would not be applicable for many resource types.

Structure: We considered two structural options for this extension:

1) An extension applied to a contextual resource with the Sex for Clinical Use value in-line. 2) An extension applied to a contextual resource with a reference to an Observation documenting the Sex Parameter for Clinical Use value.

We opted to include the Sex Parameter for Clinical Use value in-line rather than as a reference to Observation after discussion on tradeoffs between two options. We felt that the in-line option was simpler while being sufficiently expressive. An extension with a reference to Observation allows for the expression of complex metadata associated with the value, however we expect the need for that complex metadata would be sufficiently rare to not outweigh the benefits of the simpler in-line extension option. Note that the patient-sexParameterForClinicalUse extension does include a supportingInfo property which may reference supporting clinical observations.

Recorded Sex and Gender: extension

The Patient Gender and Sex section describes considerations for exchanging Recorded Sex and Gender concepts. The Recorded Sex and Gender extension is provided as option only when a use-case specific property or extension is not practical.

Context: This extension is available on all “person” type resources, which includes Patient, RelatedPerson, Person, and Practitioner. It is not included on PractitionerRole, as PractitionerRole refers to Practitioner for demographics.

Pronouns: extension

Context: This extension is available on all “person” type resources, which includes Patient, RelatedPerson, Person, and Practitioner. It is not included on PractitionerRole, as PractitionerRole refers to Practitioner for demographics.

Name to Use: Guidance on HumanName datatype

The Gender Harmony project has agreed that to represent the Name To Use when addressing an individual, the datatype HumanName.use = “usual” should be used.

Backwards Compatibility for FHIR versions:

One of the benefits to using extensions in FHIR R5 is that they can be easily backported to prior versions. Implementers may use any of the new standard extensions in R5 in prior versions of FHIR. This is further discussed in the Version Management Policy of the R5 documentation.

However, the patient-sexParameterForClinicalUse, and the individual-recordedSexOrGender extensions make use of the CodeableReference datatype, which was added in R5. Further analysis of the implications for backporting this datatype resulted in improvements to the FHIR publisher and validator so extensions such as these that contain new data types may be pre-adopted in versions of FHIR prior to R5.