Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dehall opened this issue May 2, 2024 · 4 comments

Comments

@dehall
Copy link

dehall commented May 2, 2024

(Originally reported on the Inferno test kit at inferno-framework/uds-plus-test-kit#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"
    }]
  }
}

image

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

Anthony

Any preference on the options provided above ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants