Stream: implementers
Topic: missing data values
Gaius Gracchus (Jan 15 2021 at 18:40):
Since we cannot remove the gender element from our JSON
output, and sometimes we have no value from the genderidentity list, can we just use an empty string for the missing gender value?
ryan moehrke (Jan 15 2021 at 19:00):
is there a reason why not to use the 'unknown' code?
also what IG are you trying to adhere to, US Core? because FHIR without any other IG requirements does not require patient gender
Lloyd McKenzie (Jan 15 2021 at 19:17):
Empty strings are never allowed in FHIR.
Gaius Gracchus (Jan 15 2021 at 20:32):
Hi Ryan,
Thanks for the suggestion. We considered 'unknown' but it is not one of the GenderIdentity values.
Yunwei Wang (Jan 15 2021 at 21:46):
@Gaius Gracchus What do you mean "Since we cannot remove the gender element from our JSON output"? In base FHIR profile, Patient.gender is [0..1] so you don't have to include it.
Gaius Gracchus (Jan 16 2021 at 00:08):
Thanks, Yunwei, for the reply. We originally had a hardcoded profile and had to include it, as I mentioned above. However, we are working on a more dynamic profile that will allow us to exclude it now. Thanks!
Warren Lin (Feb 05 2021 at 16:16):
gender identity is CodeableConcept. I think it should follow Missing Data handling, http://hl7.org/fhir/us/core/general-guidance.html#missing-data.
Cooper Thompson (Feb 05 2021 at 16:24):
Are we talking about genderIdentity (i.e. this extension), Patient.gender (which is admin gender, not gender identity), or birth sex (which is the USCDI data element)?
- For Patient.gender, unless you are using an IG that requires it, just don't send it, though it would be preferred to end unknown if you don't have it. Interestingly, US Core does require it...
- For genderIdentity, if you don't have it, just don't include the extension. Also, the genderIdentiy value set is just an example binding, so if you feel like you need to send unknown, rather than just not sending it, you can use your own code.
- For birth-sex, again, if you don't have it, just don't include the extension.
@Eric Haas - do you know why US Core has Patient.gender as 1..1? I know that we can DAR it, but since birth sex is the USCDI data element, I would have thought that would have had the more strict cardinality, rather than Patient.gender.
Warren Lin (Feb 05 2021 at 16:28):
If the gender field is not required, you don't need to send it. But if it is required, Data-Absent can be sent.
Lloyd McKenzie (Feb 05 2021 at 16:42):
Strongly disagree with not sending Patient.gender. It's a core element. You should always populate core elements if you have something useful to send, because that gives you the most common degree of interoperability. Lots of systems won't recognize extensions, but everyone should recognize Patient.gender. It may not convey all of the nuances desired, but it's far better than nothing.. Also, in US-core, gender is mustSupport and 1..1, so you MUST populate it if you can possibly map your data to one of its values.
Lloyd McKenzie (Feb 05 2021 at 16:42):
Sending DAR is not ok if you can reasonably perform a mapping.
Cooper Thompson (Feb 05 2021 at 16:48):
I agree with Lloyd that you should send the administrative gender if you have it. And I expect almost everyone will. I was just saying if for some reason you don't have it (maybe unconscious ED patients), then you can just not send it. I did update my post to suggest sending unknown as the administrative gender if you don't know. However the initial post seemed to be about gender identity. Or was there just some confusion between gender and gender identity?
Cooper Thompson (Feb 05 2021 at 16:49):
I am still curious why US Core locked down gender - perhaps that was something we did for non-USCDI reasons?
Cooper Thompson (Feb 05 2021 at 16:57):
Long term I do want to push back against the idea that administrative gender is a core element. I agree that it is core today, but it doesn't really have a definition, and gets misused in all sorts of ways, so I would like to see the more defined sex and gender properties become core elements, while the admin gender concept disappears. I get that this is probably an optimistic and very long term goal though.
Lloyd McKenzie (Feb 05 2021 at 17:07):
It's core because most systems in the world are capable of capturing a single, ill-defined and sometimes confusing broad categorization of gender. And having that is much more useful than having nothing. Very few systems across the world can consistently capture and share anything else. Even if the US manages to drive better consistency on concepts such as birth gender and gender identity, interoperability with the rest of the world is still going to matter.
Last updated: Apr 12 2022 at 19:14 UTC
