FHIR Chat · US Core race/ethnicity - patient declined to specify · implementers

Stream: implementers

Topic: US Core race/ethnicity - patient declined to specify


view this post on Zulip Michael Poremba (Jan 27 2017 at 20:29):

US Meaningful Use documentation around capturing patient race and ethnicity mentions handling responses for "patient declined to specify". This is a valid response for patients to make and to be record by physicians.

However, the US Core extensions for patient race and ethnicity do not include options for "patient declined to specify" nor "practitioner did not ask".

How best to represent these valid responses?

view this post on Zulip Igor Sirkovich (Jan 27 2017 at 21:25):

@Michael Poremba , for any missing data you can use a standard extension http://build.fhir.org/extension-data-absent-reason.html with the codes bound to valueset http://build.fhir.org/valueset-data-absent-reason.html

view this post on Zulip Lloyd McKenzie (Jan 28 2017 at 03:45):

@Michael Poremba Igor is right that that's an option, but the general recommendation in FHIR is that if "unknown" or other similar responses are valid answers for a coded element, those concepts should be part of the value set. I'd recommend submitting a change request to the US Core IG to get those concepts added to the race and ethnicity value sets. It makes things a lot cleaner for everyone.

view this post on Zulip Eric Haas (Jan 28 2017 at 17:12):

This is already documented in IG under Must Support

view this post on Zulip Robert McClure (Jan 28 2017 at 20:08):

The rules around this for US implementations, are a bit odd. In essence only actual race values were allowed as originally specified which of course was unworkabe given the need to document R&E to qualifiy for MU. So for eCQMs and CCDA they allowed the use of NULL codes ASKU for refused to answer and UNK for unknown. I don't know why FHIR had to make it's own set of "data absent" codes that Igor lists - perhaps the word "Null" is so laden with improper use (yep) they abandoned the codes, but they do provide a mapping.

view this post on Zulip Grahame Grieve (Feb 06 2017 at 03:42):

no we use the same codes, we just say that they should be explicit in the value set.

view this post on Zulip Grahame Grieve (Feb 06 2017 at 03:43):

unlike in CDA where the codes are implicitly merged with every value set in an uncontrolled implementer surprise


Last updated: Apr 12 2022 at 19:14 UTC