Adopt Gender Harmony Name to Use (NtU)

[dt-r]

Proposal

1. AU Core R1 to adopt Gender Harmony (GH) Name to Use (NtU) as a Must Support in
   1. AU Core Patient
   2. AU Core RelatedPerson (noting if this AU Core RelatedPerson is not in scope of R1 then add to backlog)
2. AU Core to implement support for Name to Use by:​
   1. Make name.use a Must Support element (inside HumanName data type). No change to name.use cardinality (remain 0..1).
   2. Add a subsection on the profile page (see AU Core Patient and AU Core RelatedPerson) labelled Gender Identity and related concepts and add the following statement

Name to Use (NtU)​ By making name.use a Must Support data element, this profile explicitly supports representation and exchange of the Name to Use (NtU) data element (as defined in the Gender Harmony - Sex and Gender Representation, Edition 1 Implementation Guide from HL7 International). It should be noted that, name.period is not a Must Support data element in this version of the profile.

Background​

[!NOTE] See related page Sex and gender concepts proposal for AU Base & AU Core R1. This issue is part of the set that will supersede https://github.com/hl7au/au-fhir-core/issues/66.

Gender Harmony Project: https://hl7.me/GHP ​ Gender Harmony Implementation Guide, Edition https://t.ly/Ukq9C​ GH Name to Use (NtU) logical data element: https://t.ly/IEXD3 ​ Exchanging NtU in HL7 FHIR: https://t.ly/eFRMW ​ FHIR R4 HumanName data type: https://t.ly/4r9zY

Name to Use (NtU) (excerpted from Gender Harmony IG) The Name to Use enables care providers to use the name that is chosen by the person. This element may match but is distinct from a person’s legal name and is the appropriate name to be used in person-centered healthcare conversations. Some cultures have very long names, and expect that for all but mandatory legal situations, the person will use a more manageable name. Jurisdictions have different rules and processes for name changes, so there is often a mismatch that can be prolonged in difficult situations.

Definition: Text attribute that provides the name that should be used when addressing or referencing the patient.

Usage Note: This information is usually provided by the patient. Depending on the standard applicable to an implementation, this might be encoded within a Person/Patient Name field with an appropriate name type qualifier but is independent of any other name type or name component. This may be a nickname or formal name. Multiple cardinalities are required to support changes in desired name over time, such as when a patient desires a change in name to align with expressed gender identity. This means a validity period and a comment attribute to allow text that can be used to capture context for use of the name. ​

[dt-r]

This proposal is scheduled for AU Core TDG call 11 JAN 12PM: Consensus Meeting: AUCDI and R1 Scope + Gender & Sex | zoom: https://hl7-au.zoom.us/j/89487846749

Feedback should be raised as comments in this issue. Questions can be raised here or in chat.fhir.org: https://chat.fhir.org/#narrow/stream/179173-australia.

[jaydedalus]

Would it be possible to use the term "Preferred Name" instead of "Name to Use" as that is a more commonly use description of this type of data that is already in use today.

[reubendaniels]

Would it be possible to use the term "Preferred Name" instead of "Name to Use" as that is a more commonly use description of this type of data that is already in use today.

We can certainly note that Name to Use is synonymous with Preferred Name in the proposed subsection (see 2(ii) above). However, it would be best to retain the term Name to Use to make it clear that we adopting the data element defined in the HL7 Gender Harmony Implementation Guide.

That said, the data in FHIR resource instances ("on the wire") will use neither term as the data element is realised in FHIR using the subelements of the HumanName FHIR data type.

[dt-r]

My response to the proposal below (this issue was raised on behalf of Reuben):

I think this proposal makes sense to be considered for inclusion in AU Core.

In AU Core If we are going to clarify that one part of the name element is supported, i.e. put MustSupport on name.use, then we need to go further and clarify the other parts. I'm strongly in support of being clear on which parts of name are required to be support for Patient, Practitioner, and RelatedPerson.

Current state in AU Core is that the Must Support is on the element; without clarifying which parts of the HumanName are to be supported that means that ALL parts are to be supported.

[grahamegrieve]

It doesn’t mean all parts. Some parts must be supported, somehow

Grahame

http://www.healthintersections.com.au / @.*** / +61 411 867 065 Benson & Grieve: Principles of Health Interoperability (Health Information Technology Standards), 4th ed - http://www.springer.com/978-3-030-56882-5

On 10 Jan 2024 at 3:58:43 pm, Danielle Tavares-Rixon < @.***> wrote:

My response to the proposal below (this issue was raised on behalf of Reuben):

I think this proposal makes sense to be considered for inclusion in AU Core.

In AU Core If we are going to clarify that one part of the name element is supported, i.e. put MustSupport on name.use, then we need to go further and clarify the other parts. I'm strongly in support of being clear on which parts of name are required to be support for Patient, Practitioner, and RelatedPerson.

Current state in AU Core is that the Must Support is on the element; without clarifying which parts of the HumanName are to be supported that means that ALL parts are to be supported.

— Reply to this email directly, view it on GitHub https://github.com/hl7au/au-fhir-core/issues/86#issuecomment-1884192477, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMWKFKOLTOEP3466YYV3TDYNYNYHAVCNFSM6AAAAABBKUQ5JCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBUGE4TENBXG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[dt-r]

I think we need clarify AU Core so that it means 'some parts'. I've been rereading the Must Support section in AU Core and I can't find the part of the IG that I thought said that around how to interpret application of must support at the element level.

I can see that clarity for where there are choices of data types or references but not for a complex data type.

Updated comment

Found it. AU Core currently states:

Updated response: In AU Core If we are going to clarify that one part of the name element is supported, i.e. put MustSupport on name.use, then we need to go further and clarify the other parts. I'm strongly in support of being clear on which parts of name are required to be support for Patient, Practitioner, and RelatedPerson.

Current state in AU Core is that the Must Support is on the element; without clarifying which parts of the HumanName are to be supported that means that some parts are to be supported (expectation to support 'valid' whatever that means for your data, and missing and supressed data).

[r-newell]

I agree that Name to Use is an important concept to include in AU Core, My view is date of commencement is probably all that is needed as when Name to Use changes the date of commencement for the change would then be the end date for the previous Name to Use. My question is regarding software implementation of this concept, Should the commencement date be a user modifiable field so that it can be backdated to the time the patient advises (default value being the date it was recorded) or should it be system generated to simplify user experience so logged in the background as the date name to use is recorded in software.

[dt-r]

This change proposal was discussed in 2024-01-11 AU Core TDG Agenda/Minutes and is under electronic vote eVote - Adopt Gender Harmony Name to Use (NtU) in AU Core.

Related to this proposal, clarification on the parts of HumanName to be supported will be worked on. To assist clarifying the parts of HumanName that should be supported and the ongoing efforts to refine AU Core Patient, AU Core RelatedPerson, and AU Core Practitioner/PractitionerRole we would like to understand current element usage across our various systems. To achieve this, we are asking for members to review and update the tables provided on the following pages: • HumanName Vendor Support • AU Core Patient Vendor Support • AU Core PractitionerRole & Practitioner Vendor Support • AU Core RelatedPerson Vendor Support

[dbojicic]

HL7 Jira is now used for specification feedback. This issue has been moved to HL7 Jira issue #/FHIR-43833.

[heatherleslie]

Would it be possible to use the term "Preferred Name" instead of "Name to Use" as that is a more commonly use description of this type of data that is already in use today.

We can certainly note that Name to Use is synonymous with Preferred Name in the proposed subsection (see 2(ii) above). However, it would be best to retain the term Name to Use to make it clear that we adopting the data element defined in the HL7 Gender Harmony Implementation Guide.

@reubendaniels I'm curious if the Gender Harmony authors provided a rationale why they chose this term, which now creates a conflict with ISO 22220 re 'Preferred name'. I can't find any reference to it.

[dbojicic]

Would it be possible to use the term "Preferred Name" instead of "Name to Use" as that is a more commonly use description of this type of data that is already in use today.

We can certainly note that Name to Use is synonymous with Preferred Name in the proposed subsection (see 2(ii) above). However, it would be best to retain the term Name to Use to make it clear that we adopting the data element defined in the HL7 Gender Harmony Implementation Guide.

@reubendaniels I'm curious if the Gender Harmony authors provided a rationale why they chose this term, which now creates a conflict with ISO 22220 re 'Preferred name'. I can't find any reference to it.

Moved this comment to HL7 Jira #FHIR-43833.

[dt-r]

Comments should be raised: on HL7 Jira issue #/FHIR-43833