Closed dt-r closed 9 months ago
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.
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.
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.
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.
It doesn’t mean all parts. Some parts must be supported, somehow
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: @.***>
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).
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.
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
HL7 Jira is now used for specification feedback. This issue has been moved to HL7 Jira issue #/FHIR-43833.
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 withPreferred Name
in the proposed subsection (see 2(ii) above). However, it would be best to retain the termName 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.
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 withPreferred Name
in the proposed subsection (see 2(ii) above). However, it would be best to retain the termName 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.
Comments should be raised: on HL7 Jira issue #/FHIR-43833
Proposal
name.use
a Must Support element (inside HumanName data type). No change to name.use cardinality (remain 0..1).Background
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.