hl7au / au-fhir-base

AU Base FHIR Implementation Guide Source
35 stars 25 forks source link

Adopt elements from the HL7 Gender Harmony IG and introduce an ABS-aligned Variation of sex characteristics extension #819

Open reubendaniels opened 5 months ago

reubendaniels commented 5 months ago

Background In September 2023, HL7 International published the first release of the Gender Harmony - Sex and Gender Representation, Edition 1 cross paradigm and universal realm implementation guide developed by the HL7 Gender Harmony Project (GHP). This publication provides definitive guidance on how to exchange clinical sex and gender affirming information using HL7 models. Further, it defines the data elements for gender identity, sex parameter for clinical use, recorded sex and gender, pronouns and name to use to support this approach and specifications for how these may be implemented in any of the key HL7 product family standards (i.e. V2, CDA and FHIR).

In January 2021, the Australian Bureau of Statistics (ABS) published their Standard for Sex, Gender, Variations of Sex Characteristics and Sexual Orientation Variables to standardise the collection and dissemination of data relating to sex, gender, variations of sex characteristics and sexual orientation.

Proposal To address the increasing need and legal requirements for Australian health services to deliver equitable and affirming care by through the capture and meaningful use of gender identity (and related information) about healthcare consumers in Australian digital health solutions, it is proposed that AU Base be updated to adopt and localise aspects of the Gender Harmony and ABS Standard.

At a high level, implementation of the proposal includes updating AU Base as follows :

Details of this proposal are under the section Proposal for adoption of HL7 International Gender Harmony concepts and introduction of a variation of sex characteristics extension in AU Base on the Confluence page Sex and gender concepts proposal for AU Base & AU Core R1 in the HL7 Australia FHIR Work Group Confluence space.

Feedback should be raised as comments in this GitHub issue. Questions can also be raised as comments in this GitHub issue or alternatively in the Australia stream on chat.fhir.org.

This proposal is scheduled for discussion in the HL7 Australia FHIR Work Group call on 17 January 2024. The meeting details can be found here: 2024-01-17 FHIRWG Meeting Minutes | zoom: https://hl7-au.zoom.us/j/82597386394

cooperthompson commented 5 months ago

Will you be defining any specific RSG types? Or just adding the generic extension and relying on the downstream IGs built on AU Core /AU Base to run through the methodology defined in the RSG Guidance to determine how to exchange the RSG data? Also, I know this proposal isn't meant to be detailed, but what example content will you be adding for RSG?

reubendaniels commented 5 months ago

Hi Cooper

Happy NY and thanks for the comment.

Will you be defining any specific RSG types?

Yes. Included in the proposal is the creation of an RSG types code system and value set (to be extensibly bound to RSG.type) along with guidance on use of these types in RSG data elements.

Also, I know this proposal isn't meant to be detailed, but what example content will you be adding for RSG?

The details of this have not been completely worked out yet. But I anticipate that a number of example Patient/RelatedPerson/Practitioner resource instances illustrating valid RSG data elements for well-known legal documents (e.g. Australian Passport, and birth certificates from the various jurisdictions) and registration schemes (e.g. our healthcare professionals registration scheme) would be included.

cooperthompson commented 5 months ago

Are end users in contexts that would use AU Base regularly collecting details about which legal documents demographics are collected from? I know we used that as a common example of RSG during gender harmony, but my experience is that while data is transcribed from legal documents, the type of which legal document used isn't typically captured. Sometimes users might scan a drivers license, but that would just be a scan and not a discrete indicator of the legal document type. Are there workflows where end users select which (for example) state birth certificate they are transcribing data from (either existing workflows, or specific business requirements that would drive adding that additional user burden in the future).

I just want to make sure nothing we add here is adding additional end user burden around capturing source document information unless there is a specific business requirement for it. Though I understand AU Base isn't adding requirements.

heathfrankel commented 5 months ago

Would it be viable to comment on the Wiki page (inline or at bottom) rather than attempt to restate and comment here?

brettesler-ext commented 4 months ago

F2F comment - requires discussion for final position