Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-11025

Need to explicitly assert presence vs. absence of a risk - 2016-09 core #44

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • DSTU2
    • Patient Care
    • AllergyIntolerance
    • 9.1.3 allergy
    • Hide

      The negated subset of codes within the AllergyIntolerance.code value set are all fully defined http://browser.ihtsdotools.org/?perspective=full&conceptId1=716186003

      The AllergyIntolerance.code, when precoordinated, is declaring the meaning and doesn't modify the AllergyIntolerance. The tooling does not allow us to specify that the substanceExposureRisk.exposureRisk modifies the substance. That could be a tooling request.

      Add a usage note for the substanceExposureRisk extension's exposureRisk is a modifier of the substance element.

      Show
      The negated subset of codes within the AllergyIntolerance.code value set are all fully defined http://browser.ihtsdotools.org/?perspective=full&conceptId1=716186003 The AllergyIntolerance.code, when precoordinated, is declaring the meaning and doesn't modify the AllergyIntolerance. The tooling does not allow us to specify that the substanceExposureRisk.exposureRisk modifies the substance. That could be a tooling request. Add a usage note for the substanceExposureRisk extension's exposureRisk is a modifier of the substance element.
    • Rob/Stephen: 8-0-1
    • Enhancement
    • Non-substantive
    • DSTU2

    Description

      Comment:

      A resource asserting the existence of a risk and a resource asserting the absence of a risk should be clearly and easily differentiable. Ideally, this would mean an explicit assertion of presence or absence (e.g., as demonstrated in the substanceExposureRisk extension, though specified values would be useful). Wrapping negation inside of the code seems to violate a rule proposed for "modifier extensions" about modifiers inside date types. However, if there were a way to clearly and consistently distinguish these values (e.g., a requirement that such codes be fully defined, so that negation could be computably identified) and clear guidance on how to do this, that would be a positive move.

      Summary:

      Need to explicitly assert presence vs. absence of a risk

      Attachments

        Activity

          People

            Unassigned Unassigned
            jlyle Jay Lyle
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: