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

Condition.encounter should be an invariant instead of MS

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Medium
    • Resolution: Persuasive with Modification
    • US Core (FHIR)
    • current
    • Cross-Group Projects
    • STU
    • US Core Condition Profile
    • Hide

      There is a USCDI V2 requirement to support Encounter Diagnosis which is met by the Condition Profile and specifically the Condition.encounter element. Based on vendor input, this implementation guidance is informative but not prescriptive:

      • When Condition.category is “encounter-diagnosis” the encounter, SHOULD be referenced in Condition.encounter.

      Currently an invariant can require an element to be present (conditionally mandatory) but an invariant can not require an element to be must support (conditionally must support).  There are no examples of this in US Core or any other IGs based upon our review.  Therefore this would be a novel  ( and complex ) conformance structure.

      Reasoning:

      Because the Condition.encounter element is needed to meet the USCDI V2 requirement, and there is no way to express a conditionally must support via an invariant, creating nearly identical Condition profiles for each category similar to Observations, may be a solution.   However it may lead to a bloated ig with redundant content and some may find this less clear ... discuss.

       

      Proposed Changes:

      create two Condition Profile:

      see attached mockup of proposal

      Show
      There is a USCDI V2 requirement to support Encounter Diagnosis which is met by the  Condition Profile  and specifically the  Condition.encounter  element. Based on vendor input, this implementation guidance is informative but not prescriptive: When  Condition.category  is “encounter-diagnosis” the encounter,  SHOULD  be referenced in  Condition.encounter . Currently an invariant can require an element to be present (conditionally mandatory) but an invariant can not require an element to be must support (conditionally must support).  There are no examples of this in US Core or any other IGs based upon our review.  Therefore this would be a novel  ( and complex ) conformance structure. Reasoning: Because the  Condition.encounter  element is needed to meet the USCDI V2 requirement, and there is no way to express a conditionally must support via an invariant, creating nearly identical Condition profiles for each category similar to Observations, may be a solution.   However it may lead to a bloated ig with redundant content and some may find this less clear ... discuss.   Proposed Changes: create two Condition Profile: see attached mockup of proposal
    • Brett Marquard/Eric Haas: 13-0-0
    • Enhancement
    • Compatible, substantive

    Description

      I think Condition.encounter should be required via an invariant instead of a MS tag.  That way if a system were only supporting problem lists and not encounter diagnoses, they could use US Core.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              cooper.thompson Cooper Thompson
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: