You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Situation
FHIR Version 4 is the version of FHIR that is compatible with the App. When it comes to the raceCode element, the app looks for the omb-race-category url extension and pulls the associated race code into the eICR. In both eICR 1.1 and 3.1, there are five allowed values that do not include 2131-1 (other race). This aligns with the omb-race-category value set in FHIR version 4, so everything works great.
In FHIR STU5 and up, the 2131-1 code is included as a valid value in the valueSet:
For any vendors who have advanced their FHIR server to this version, a situation is now possible where their server can emit a valid value per the FHIR Spec, but result in an invalid value being included in the eICR.
This will cause Schematron errors in the DQ Monitoring Report that is used for data quality validation by the onboarding team and PHAs.
Approach
One solution, of course, is for the FHIR Server to revert back to the version 4 valueSet and not allow 2131-1. This does however feel like potentially a step in the wrong direction. FHIR R6 will eventually be required and this would have to be switched back.
Another solution is to handle this in the app code - the app could, for instance, add a check in CdaHeaderGenerator.java such as:
if (race != null && race.hasCode()) {
if (race.getCode().equals(OTHER_RACE_code)) {
patientDetails.append(
CdaGeneratorUtils.getXmlForNullCD(
CdaGeneratorConstants.RACE_CODE_EL_NAME, race.getCode()));
else if (!isCodingNullFlavor(race)) {
patientDetails.append(
CdaGeneratorUtils.getXmlForCD(
CdaGeneratorConstants.RACE_CODE_EL_NAME,
race.getCode(),
CdaGeneratorConstants.RACE_CODE_SYSTEM,
CdaGeneratorConstants.RACE_CODE_SYSTEM_NAME,
race.getDisplay()));
Submitting this request for eCR Now Team's input and review on behalf of McKesson Ontada
The text was updated successfully, but these errors were encountered:
@nbashyam as per Sarah, as per Chuck- they do sometimes get that code (2131-1 Other Race), so I think that the code change that you suggested would be fine.
Situation
FHIR Version 4 is the version of FHIR that is compatible with the App. When it comes to the raceCode element, the app looks for the omb-race-category url extension and pulls the associated race code into the eICR. In both eICR 1.1 and 3.1, there are five allowed values that do not include 2131-1 (other race). This aligns with the omb-race-category value set in FHIR version 4, so everything works great.
In FHIR STU5 and up, the 2131-1 code is included as a valid value in the valueSet:
For any vendors who have advanced their FHIR server to this version, a situation is now possible where their server can emit a valid value per the FHIR Spec, but result in an invalid value being included in the eICR.
This will cause Schematron errors in the DQ Monitoring Report that is used for data quality validation by the onboarding team and PHAs.
Approach
One solution, of course, is for the FHIR Server to revert back to the version 4 valueSet and not allow 2131-1. This does however feel like potentially a step in the wrong direction. FHIR R6 will eventually be required and this would have to be switched back.
Another solution is to handle this in the app code - the app could, for instance, add a check in CdaHeaderGenerator.java such as:
Submitting this request for eCR Now Team's input and review on behalf of McKesson Ontada
The text was updated successfully, but these errors were encountered: