search

AuDigitalHealth / ci-fhir-r4

Working drafts of HL7™ FHIR® Release 4 (R4) artefacts authored and maintained by the Informatics Architecture team at the Australian Digital Health Agency.
Other
14 stars 3 forks source link

Support exchange of patient gender identity #151

Open dtr-agency opened 1 year ago

dtr-agency commented 1 year ago

Prerequisites

The issue / feature

Establish capability to exchange patient gender identity in Agency FHIR and CDA specifications - no prior art in an Agency specification.

This work progresses Agency capability implementing the Australian Government Guidelines on the Recognition of Sex and Gender in digital health exchanges.

The guidelines apply to all Australian Government departments and agencies that maintain personal records (including employee records), and/or collect sex and/or gender information.

The guidelines help people who are transgender, intersex and gender-diverse to ensure their Australian Government records accurately reflect their sex and/or gender.

Individuals may identify and be recognised within the community as a gender other than the sex they were assigned at birth or during infancy, or as a gender which is not exclusively male or female. This should be recognised and reflected in their personal records held by Australian Government departments and agencies. In the guidelines these terms are defined as follow:

The preferred Australian Government approach is to collect and use gender information. Information regarding sex would ordinarily not be required and should only be collected where there is a legitimate need for that information and it is consistent with Australian Privacy Principles. In a healthcare setting it is important to collect and use sex and gender information as distinct concepts and using the correct terminology.

This work needs to support patient gender identity in accordance with the ABS Standard for Sex, Gender, Variations of Sex Characteristics and Sexual Orientation Variables.

This work will preferably be defined via national standards, e.g. HL7 AU standard and SNOMED CT-AU.

How awesome would it be?

Very.

Workarounds

None.

Additional context

The FHIR Core Gender Identity extension is a starting point but needs maturation within an Australian context in its conceptual definition, physical definition, terminology, scope of use, boundaries, guidance.

US Core Gender Identity Extension defined to support US content - for design reference but not for direct use in an AU context.

The Primary Care Data Quality Foundations Clinical Content Working Group identified gender identity as being of value with preliminary content.

Gender identity as a data element in an exchange is not to be conflated with administrative gender, or with other gender elements such as 'recorded gender' - these are not the same concepts.

dtr-agency commented 1 year ago

In accordance with FHIR as primary, and FHIR-driven CDA, design approach. Patient gender identity work will be driven by work with HL7 AU Patient Administration working group via Patient needs more work to use Core's Gender Identity extension #599.

CDA support to derive from FHIR approach

dtr-agency commented 1 year ago

FHIR support As agreed via https://confluence.hl7australia.com/pages/viewpage.action?pageId=116461176 a patient's gender identity is to be supported by the inclusion of the core extension in AU Base Patient as a codeable concept. The terminology implementing the ABS set, developed by Agency terminology using SNOMED CT and published in the National Clinical Terminology Service.

The next version of the HL7 Australian Base Implementation Guide will include this extension with ballot forecast for later this year.

dtr-agency commented 1 year ago

FHIR support Gender identity will not be automatically included in ADHA Core Patient. Inclusion via the application of MS in one or more profiles of Patient is to be agreed to support a particular release as needed.

This core extension however should be treated as a known extension.

dbojicic-agency commented 1 year ago

CDA support Map core extension as an administrative observation using a LOINC code to type the observation to a gender identity observation. Mapping would be something like:

entry[gender_identity]/observation/code/@code="76691-5"

Example 1: Non-binary gender, represented by sending the SNOMED CT code 33791000087105|Identifies as nonbinary gender| 

<observation classCode="OBS" moodCode="EVN">
     <code code="76691-5" codeSystem="2.16.840.1.113883.6.1" 
                 displayName="Gender identity" codeSystemName="LOINC"/>
     <statusCode code="completed"/>
     <value xsi:type="CD" code="33791000087105" codeSystem="2.16.840.1.113883.6.96" 
                  codeSystemName="SNOMED CT" displayName="Identifies as nonbinary gender"/>
</observation

Example 2: [I/They] use a different term (please specify) - represented by sending text only and no code

<observation classCode="OBS" moodCode="EVN">
     <code code="76691-5" codeSystem="2.16.840.1.113883.6.1"
                 displayName="Gender identity" codeSystemName="LOINC"/>
     <statusCode code="completed"/>
      <value xsi:type="CD">
           <originalText>Questioning</originalText>
     </value>
</observation>

Example 3: Prefer not to answer may be represented by sending the code “asked-declined”

<observation classCode="OBS" moodCode="EVN">
     <code code="76691-5" codeSystem="2.16.840.1.113883.6.1"
                 displayName="Gender identity" codeSystemName="LOINC"/>
     <statusCode code="completed"/>
     <value xsi:type="CD" code="asked-declined" codeSystem="2.16.840.1.113883.4.642.1.1048" 
                  displayName="Asked But Declined">
            <originalText>Prefer not to answer</originalText>
     </value>
</observation>