Incompatibility between UDS+ Observation profiles and core Observation vital signs profiles

[dehall]

(Originally reported on the Inferno test kit at https://github.com/inferno-framework/uds-plus-test-kit/issues/24 )

There is an apparent incompatibility between the UDS+ Observation-based profiles (eg https://fhir.org/guides/hrsa/uds-plus/StructureDefinition-uds-plus-lab-observation.html ) and the base FHIR vital signs profiles: http://hl7.org/fhir/R4/observation-vitalsigns.html

There is a requirement in base FHIR that if an Observation references a certain concept then it SHALL use the appropriate core profile:

The following core profiles for the Observation resource have been defined as well. If implementations use this Resource when expressing the profile-specific concepts as structured data, they SHALL conform to the following profiles:

(from http://hl7.org/fhir/R4/observation.html#core )

This requirement is checked in the FHIR validator by keying off certain codes. For instance an observation with a code representing BMI will automatically be checked against the BMI profile:

{
  "resourceType": "Observation",
  "code": {
    "coding": [{
      "code": "59574-4",
      "system": "http://loinc.org"
    }]
  }
}

https://validator.fhir.org/

The incompatibility between these is on the effective[x] field. The core vital signs profile has a constraint "if Observation.effective[x] is dateTime and has a value then that value shall be precise to the day" (vs.1) The UDS+ profiles have a conflicting requirement "The Data Submitter has to truncate the following dates to only have a precision of year: effective[x]"

[cooperthompson]

FYI, I have run into issues with this profile before, and brought this issue up on this chat.fhir.org topic. I also submitted Jira FHIR-46061 against the core spec, though that will only get addressed (at best) in R6, so it won't do us much good for this R4 spec.

[nbashyam]

Two options: Create UDS+ specific profiles to address the issue Ignore the error from the validation of the specific constraint (work around).

Any thoughts ?

[anthonygalba]

I'd also like to point out effective date is not the only issue here. CMS-155 is specifically looking for BMI Percentile using LOINC codes 59574-4, 59575-1, 59576-9. The FHIR vitals requirements call for LOINC 39156-5, which is BMI Ratio.

Now, if BMI is documented in Epic, it's easy enough for us to send both percent and ratio. However, if the value comes from an outside source, such as an imported QRDA I document, we may only get the BMI percentile (as that's what the eCQM uses).

My plan is to always send percent, as that's what is actually required to calculate the eCQM and send the ratio when we have it. So there will be situations where we are technically non-compliant with FHIR, but we are sending all of the correct data needed to calculate the eCQM outcome.

[nbashyam]

Anthony

Any preference on the options provided above ?