Jan 2015 Ballot Comment #47

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • FHIR Infrastructure
    • Conformance Rules
    • 1.13.3.2, 1.13.8.0.2
    • Hide

      Will not address this in STU 3. Will consider as part of Release 4

      Reopened on May 8, 2017. Motion: Enable committees to flag concepts with isModifier status by adding an appropriate concept propety to the CodeSystem resource.

      Grahame Grieve / Chris Grenz: 5-1-12.

      Show
      Will not address this in STU 3. Will consider as part of Release 4 Reopened on May 8, 2017. Motion: Enable committees to flag concepts with isModifier status by adding an appropriate concept propety to the CodeSystem resource. Grahame Grieve / Chris Grenz: 5-1-12.
    • Grahame Grieve/Eric Haas: 8-0-0
    • Enhancement
    • Compatible, substantive
    • DSTU1 [deprecated]

      Existing Wording
      Is-Modifier is a boolean property that is assigned when an element is defined, either as part of the base resource contents in this specification, or when extensions are defined. An element is labeled "Is-Modifier = true" if the value it contains may change the interpretation of the element that contains it (including if the element is the resource as a whole). Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty". Whether an element is a modifier cannot be changed when element usage is described in a Resource Profile. When an element is labeled as Is-Modifier, the documentation must be clear about why it is a modifier.

      Comments
      Is-Modifier is too coarse-grained to be of much use. Some attribute values change the semantics, and some do not. For example, if the element is "wasCancelled" then true is the modifying value, and false is not modifying. If the element is status, then there might be several status values that are not modifying (e.g. active, completed, in progress) and some that are (e.g. entered in error, cancelled). Instead of labeling the element as a modifier, that modifier label should be applied to values. That way, the receiver can quickly scan a resource and know if the meaning is actually being modified, even if the receiver does not understand the nature of the specific modification. This will result in less data being potentially lost, simply because there is a modifying element. Under the proposed change, the data receiver can process a resource without having prior knowledge of each possible modifier.

      Grahame's Comments
      Well, we could do that; it would be an extra layer of complexity and there are co-occurance cases. It's really just a flag to implementers to be careful and check for values they don't understand in these fields. I think that whitelisting by the implementer is better than bloacklisting by HL7. I suspect committees will agree.

      Disposition
      Not Persuasive

      Disposition Comment
      The purpose of "isModifier" is to indicate that the element cannot be safely ignored. "active" and "cancelled" are both 'modifying' in that a value of 'active' causes elements to be interpreted differently than a value of 'cancelled'. There is no default semantic to the other elements in the resource.

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

              Created:
              Updated:
              Resolved: