Inconsistent use of MS flag on required elements

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • US Minimal Common Oncology Data Elements (mCODE) (FHIR)
    • STU3
    • Clinical Interoperability Council
    • Profiles
    • Hide

      The issue is discussed in some detail here: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Supported.20Vs.201.2E.2E1.20Cardinality

      The outcome of that discussion is that a required element has to be present for the resource to be valid, but does not have to be meaningfully supported in some applications. If mustSupport is false on a required element, that means that the profile doesn't particularly care about that element, though they still aren't allowed to drop it.

      Based on that discussion, it should not be automatic to assign a must support to a required element. Only elements important to mCODE should be designated as MustSupport.

      At the same time, FHIR considers MustSupport to be inheritable. If mCODE requires all implementers in the US to be US Core compliant, then all MustSupport elements (as well as extensions, bindings, etc.) must be included in the mCODE profiles. That's a separate issue, taken up in GF#24015.

      The proposed resolution is to make sure the MustSupport flags reflect only what is important in mCODE (not blindly adding MS flags to every required element). Depending on the resolution of GF#24015, we may also remove some of the MS flags inherited from US Core, on elements not important to mCODE.

      Proposed resolution: Persuasive with mod

      Show
      The issue is discussed in some detail here: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Supported.20Vs.201.2E.2E1.20Cardinality The outcome of that discussion is that a required element has to be present for the resource to be valid, but does not have to be meaningfully supported in some applications. If mustSupport is false on a required element, that means that the profile doesn't particularly care about that element, though they still aren't allowed to drop it. Based on that discussion, it should not be automatic to assign a must support to a required element. Only elements important to mCODE should be designated as MustSupport. At the same time, FHIR considers MustSupport to be inheritable. If mCODE requires all implementers in the US to be US Core compliant, then all MustSupport elements (as well as extensions, bindings, etc.) must be included in the mCODE profiles. That's a separate issue, taken up in GF#24015. The proposed resolution is to make sure the MustSupport flags reflect only what is important in mCODE (not blindly adding MS flags to every required element). Depending on the resolution of GF#24015, we may also remove some of the MS flags inherited from US Core, on elements not important to mCODE. Proposed resolution: Persuasive with mod
    • May Terry/Richard Esmond: 11-0-0
    • Enhancement
    • Compatible, substantive

      Should the MS flag be dropped if the element is required? Sometimes required elements are labeled MS, and sometimes not. Should the reader infer these elements are somehow different? Example: In the `ComorbidCondition` profile, this is inherited from US Core. However, we explicitly mark `Condition.clinicalStatus` as `MS` even though it is a required element. The `MS` flag is inherited from US Core, and since `subject` is a required element, the MS flag is a moot point. (Or is it?) mCODE should consider a consistent application of the `MS flag`, potentially, adopting the US Core practice.

      REF: MCODE-77

            Assignee:
            Mark Kramer
            Reporter:
            Mark Kramer
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: