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

Should Condition date of diagnosis be an invariant instead of special MS meaning?

    XMLWordPrintableJSON

Details

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

      Background:

      Because EHR vendors could not reach a consensus on a single profile structure to meet a USCDI ( and CCDS before that) requirement, we have defined instances in this Guide where there is a choice of supporting one or another profile element.  This pattern began in Argonaut DSTU2 with the representation of medication and continues through the current ballot.  In Version 4.0.0 we introduced a Conformance page to document the expectations for mandatory and must support elements in the US Core Profiles and defined this "Choice of Profile Elements" pattern  ( see: http://build.fhir.org/ig/HL7/US-Core/conformance-expectations.html#must-support---choice-of-profile-elements).

      As Described in FHIR-34553, 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.

      Because there is no consensus among EHR vendors on how to represent Condition Date of Diagnosis to meet the USCDI V2 requirement, and there no way to express a conditionally must support via an invariant, the Choice of Profile Elements" pattern is used here to represent it as follows (note there is separate tracker to clarify this text):

      • There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate ExtensionCondition.onsetDate, or Condition.recordedDate.
        • Although all three are marked as must support, the server is not required to support all [three].
        • A server SHALL support Condition.recordedDate.
        • A server SHALL support at least one of assertedDate Extension and Condition.onsetDate. A server may support both, which means they support all 3 [elements].
        • The client application SHALL support all three elements.

      Reasoning:

      Based on the background given above, we disagree with the commenter's assertions that an invariant would satisfy the requirements and that the existing pattern is unusual or novel for US Core. 

      Proposed Changes:

      There is no action needed by US Core on this issue.

      Show
      Background: Because EHR vendors could not reach a consensus on a single profile structure to meet a USCDI ( and CCDS before that) requirement, we have defined instances in this Guide where there is a choice of supporting one or another profile element.  This pattern began in Argonaut DSTU2 with the representation of medication and continues through the current ballot.  In Version 4.0.0 we introduced a Conformance page to document the expectations for mandatory and must support elements in the US Core Profiles and defined this "Choice of Profile Elements" pattern  ( see: http://build.fhir.org/ig/HL7/US-Core/conformance-expectations.html#must-support---choice-of-profile-elements). As Described in FHIR-34553 , 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. Because there is no consensus among EHR vendors on how to represent  Condition Date of Diagnosis  to meet the USCDI V2 requirement, and there no way to express a conditionally must support via an invariant, the Choice of Profile Elements" pattern is used here to represent it as follows (note there is separate tracker to clarify this text): There is no single element in Condition that represents the date of diagnosis. It may be the  assertedDate Extension ,  Condition.onsetDate , or  Condition.recordedDate . Although all three are marked as must support, the server is not required to support all [three] . A server  SHALL  support  Condition.recordedDate . A server  SHALL  support at least one of  assertedDate Extension  and  Condition.onsetDate . A server may support both, which means they support all 3 [elements] . The client application  SHALL  support all three elements. Reasoning: Based on the background given above, we disagree with the commenter's assertions that an invariant would satisfy the requirements and that the existing pattern is unusual or novel for US Core.  Proposed Changes: There is no action needed by US Core on this issue.
    • Brett Marquard/Eric Haas: 15-0-0

    Description

      For Condition date of diagnosis, we are bending the definition of must-support, since we have Condition-specific language saying that servers only have to support one of two MS elements.

       

      Should this just be an invariant instead of a weird flavor of MS?

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: