FHIR Chat · FHIR race codings · implementers

Stream: implementers

Topic: FHIR race codings


view this post on Zulip Hannah Riggs (May 04 2020 at 15:32):

Hi FHIR chat -

What is the preferred way to represent race for a resource (ex: Patient or RelatedPerson) if the coding does not fit into OMB Race Categories or Detailed Race, and thus, cannot be stored in the USCore race structure definition (https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-race.html)?

Some options are:

  1. Store the data in a custom extension on the USCore race extension.
  2. Store the data in a custom extension separate to the USCore race extension.
  3. Store the data in the extension:detailed Extension and ignore the binding (is this valid?).

I have the same question for ethnicity and the USCore ethnicity extension (https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-ethnicity.html).

Thanks!

view this post on Zulip Lloyd McKenzie (May 04 2020 at 15:55):

What is your intention with capturing the custom value? Are you based in the U.S. or elsewhere? Can you give an example of a value you'd want to capture that doesn't fit?

view this post on Zulip Hannah Riggs (May 04 2020 at 16:17):

Thank you for the follow-up!

  1. The intention is that there is another value set that the application is using.
  2. Based in the U.S.
  3. An example would be wanting to use the code "HAI" for "HAITIAN" in ethnicity, but the USCore ethnicity value sets do not have this code as an option.

view this post on Zulip Lloyd McKenzie (May 04 2020 at 16:27):

@Brett Marquard @Eric Haas Thoughts?

view this post on Zulip Brett Marquard (May 04 2020 at 16:35):

Hmm, the US regulations requires race/ethnicity using the specified value sets -- https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf

view this post on Zulip Brett Marquard (May 04 2020 at 16:36):

I don't think an extension is appropriate.

view this post on Zulip Lloyd McKenzie (May 04 2020 at 16:37):

An extension would be appropriate to convey additional information

view this post on Zulip Brett Marquard (May 04 2020 at 16:44):

Haitian is available in the race value set. If you believe this should be an ethnicity it would be wise to talk with CDC before using an extension

view this post on Zulip Hannah Riggs (May 04 2020 at 17:32):

Thank you for information.

To clarify: the extension would be to convey additional information and the appropriate value sets would be used in the USCore structure definitions.

Would it be preferable to have the extension with the additional information on the USCore structure definition or have it completely separate to the USCore extensions?

view this post on Zulip Eric Haas (May 04 2020 at 19:02):

@Hannah Riggs what Brett said is this is not a FHIR issue Haitian is defined as a race by the US federal government rather than creating your own extension follow the code system definitions of race and put Haitian in the race extension.

view this post on Zulip Charles Frankston (May 04 2020 at 19:30):

So Hannah didn't mention a critical component of the use case here. We are mapping what we can into the official USCore race and ethnicity value sets -- as best as we can. The problem is that we have a requirement to round-trip the race and ethnicity values back to the institution's (non-FHIR) based system. Since there's no one-to-one mapping of race and ethnicity between the institution's value set and the USCore value set, we've decided we'll need to store both. Hannah is simply asking for advice on the best way to store the source system's race and ethnicity values. We've already determined this will have to be in some sort of extension -- to convey this additional information (as Lloyd Mckenzie put it), but we could use some extensions about where to put the extension and guidlines on how to name it.

view this post on Zulip Eric Haas (May 04 2020 at 19:36):

I would create an extension on Patient not on the extension.

view this post on Zulip Robert McClure (May 06 2020 at 17:20):

Just arriving at this thread and I'm worried there are some misalignments happening. As Brett noted, in the US, Haitian is considered a Race and not an ethnicity. @Hannah Riggs and @Charles Frankston Are you saying your implementation needs to represent Haitian as an ethnicity?

view this post on Zulip Charles Frankston (May 06 2020 at 19:31):

Are you saying your implementation needs to represent Haitian as an ethnicity?

More or less, yes. The institution is sending us both race and ethnicity. And they're sending us Haitian as an ethnicity (Haitian is just one example). So, we're doing the best we can to map to the US Core valuesets, but also preserving the original value and label (as an ethnicity). I don't think we're at the point where we want to take something that we got labelled as an ethnicity and change it to race (for USCore purposes), but that could be something worth considering. However, we'd still preserve the original coding using an extension, as it was originally marked (as an ethnicity), so we could round-trip it back to the legacy system.

view this post on Zulip Lloyd McKenzie (May 06 2020 at 21:20):

Round-tripping would require an extension, but you'll still have to map to the standard value sets in order to comply with U.S. Core. (You 'have' race and ethnicity so you need to map it somehow to be compliant.)


Last updated: Apr 12 2022 at 19:14 UTC