Gender Harmony Project PSS

1a. Project Name Gender Harmony Project 1b. Project ID 1533 1c. Is Your Project an Investigative Project (aka PSS-Lite)? No 1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU? No 1e. Today's Date 1f. Name of standard being reaffirmed 1g. Project Artifact Information 1h. ISO/IEC Standard to Adopt 1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption? 1j. Unit of Measure 2a. Primary/Sponsor WG Structured Documents 2b. Co-Sponsor WG Patient Care 2c. Co-Sponsor Level of Involvement Request formal content review prior to ballot 2b. Co-Sponsor WG 2 Payer/Provider Information Exchange 2c. Co-Sponsor Level of Involvement Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.) 2c. Co-Sponsor 2 Update Periods at WGMs 2b. Co-Sponsor WG 3 Patient Administration 2c. Co-Sponsor Level of Involvement Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.) 2c. Co-Sponsor 3 Update Periods at WGMs 2b. Co-Sponsor WG 4 Financial Management 2c. Co-Sponsor Level of Involvement Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.) 2d. Project Facilitator Rob McClure 2e. Other Interested Parties (and roles) HL7 Netherland (@Alexander Henket), HL7 Germany (@Kai U. Heitmann), HL7 Canada (@Andrea MacLean), HL7 Australia (@Reuben Daniels) And see https://confluence.hl7.org/display/VOC/Project+participants 2f. Modeling Facilitator 2g. Publishing Facilitator 2h. Vocabulary Facilitator @rob 2i. Domain Expert Representative 2j. Business Requirements Analyst 2k. Conformance Facilitator 2l. Other Facilitators 2m. Implementers n/a 3a. Project Scope 1. identify the primary types of sex/gender classifications/uses that are currently needed for health data documentation and exchange The intent is to primarily represent actual user needs that relects end user community needs including the international community. ⁃ Name and define these types. This class of things will, for now, be referred to as Sex-GenderTypes ⁃ include descriptions of the context of use for each Sex-GenderType. ⁃ If no real context of use can be identified then place the type on a to-do list and move on. Where agreement exists, link the context of use to existing clinical models/systems. ⁃ It is fine to identify existing model/systems that based on definition or existing allowed values, are linked to multiple sexy types. ⁃ Clarify the general context of use (write a definition) for the word “Sex” and the word “gender” ⁃ Pay particular attention to situations where a change in context of use may result in different sex or gender identity may change for the same person (IE: looks like a male but has female sex organs.) 2. Identify code/description/definition (ie, concepts, but not necessarily from an existing code system) to be used for each Sex-GenderType ⁃ While we may draw from a code system, this is not intended to restrict the process to use existing concepts. We’ll match things up later ⁃ Work to align with existing use and existing concepts, but not be hog-tied to them 3. Based on the context of use determined for the Sex-GenderTypes. Decide if the value set associated with the SexyType is “closed” or “open.” ⁃ CLOSED - no further concepts are to be used. This means any situation that doesn’t quite seem to fit one of the defined values would have to compromise and pick an existing value. ⁃ This means if we need to support Other or Unknown, we say that. (A so called null type) ⁃ OPEN - the defined set of concepts can be extended if the meaning that needs be sent is not in the provided value set. This is exactly equivalent to the FHIR Extensible binding strength. The expectation is that a concept from a different code system would be sent, and if that is not supported, then a text string. ⁃ If two Sex-GenderTypes are the same but one context needs to have a null, or needs to not be closed, that is a different context, so it’s a different Sex-GenderType. Out of Scope but mentioned in the informative document: ⁃ Additions or modifications to any base (balloted) standards (eg. FHIR, v2, CDA, etc) ⁃ The use of pronouns as a way of describing or addressing a person's sex or gender identity ⁃ Any potential changes to external code systems (LOINC for observations, SNOMED CT - new sex/gender types) but we will keep these authorities aware of any potential changes to consider. Attachments 3b. Project Need This is project born of the ongoing frustration the ideas encompassed by "sex" and "gender" have never been easy to capture consistently within health models. In particular it has become common for there to exist a single "sex" or "gender" field in a data collection model when in fact it seems that individuals can be represented by multiple types of sex identity (biologic sex) and a gender identity *at the same time* and those identities can properly be represented with "opposite" codes (M for one meaning and F for another) resulting in end-use confusion, increased costs, and negative clinical and social impact. This project intends to provide a framework to disambiguate these issues. 3c. Security Risk No 3d. External Drivers 3e. Objectives/Deliverables and Target Dates A white paper that provides an overview of the general issues involved and provides a set of defined "sex-gendertypes" which are named descriptions for sex and gender value sets with explicitly defined member content. In addition we will identify, in part, existing sex or gender model elements that appear to use these types, and where possible, identify apparent use case situations that could be improved by implementing these more specifically defined sex-gendertypes This will include identifying use cases and specifications that could be updated to reference the output of this project through some other project activity. e.g. The FHIR Patient resource Gender section could refer back to this output document. We also plan to specify FHIR value sets for all of the sex-gender types. We currently intend to submit for ballot no later than May 2020 but will attempt to met January 2020 ballot deadlines if possible. 3f. Common Names / Keywords / Aliases: 3g. Lineage 3h. Project Dependencies 3i. HL7-Managed Project Document Repository URL: https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project 3j. Backwards Compatibility No 3k. Additional Backwards Compatibility Information (if applicable) 3l. Using Current V3 Data Types? No 3l. Reason for not using current V3 data types? 3m. External Vocabularies Yes 3n. List of Vocabularies SNOMED CT, LOINC, HL7 3o. Earliest prior release and/or version to which the compatibility applies 4a. Products White Paper 4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to? 4c. FHIR Profiles Version 4d. Please define your New Product Definition 4d. Please define your New Product Family 5a. Project Intent White Paper 5a. White Paper Type Balloted Informative 5a. Is the project adopting/endorsing an externally developed IG? 5a. Externally developed IG is to be (select one) 5a. Specify external organization 5a. Revising Current Standard Info 5b. Project Ballot Type Informative 5c. Additional Ballot Info 5d. Joint Copyright No 5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval. no 6a. External Project Collaboration 6b. Content Already Developed 6c. Content externally developed? 6d. List Developers of Externally Developed Content 6e. Is this a hosted (externally funded) project? 6f. Stakeholders Quality Reporting Agencies, Regulatory Agency, Standards Development Organizations (SDOs), Payors 6f. Other Stakeholders 6g. Vendors EHR, PHR, Clinical Decision Support Systems, Lab 6g. Other Vendors 6h. Providers Clinical and Public Health Laboratories, Healthcare Institutions (hospitals, long term care, home care, mental health) 6h. Other Providers 6i. Realm Universal 7d. US Realm Approval Date 7a. Management Group(s) to Review PSS CDA, FHIR, V2 7b. Sponsoring WG Approval Date May 09, 2019 7c. Co-Sponsor Approval Date 7c. Co-Sponsor 2 Approval Date 7c. Co-Sponsor 3 Approval Date May 22, 2019 7c. Co-Sponsor 4 Approval Date May 21, 2019 7c. Co-Sponsor 5 Approval Date 7c. Co-Sponsor 6 Approval Date 7c. Co-Sponsor 7 Approval Date 7c. Co-Sponsor 8 Approval Date 7c. Co-Sponsor 9 Approval Date 7c. Co-Sponsor 10 Approval Date 7e. CDA MG Approval Date 7f. FMG Approval Date May 29, 2019 7g. V2 MG Approval Date 7h. Architecture Review Board Approval Date 7i. Steering Division Approval Date Jul 01, 2019 7j. TSC Approval Date