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

MustSupport rules are too loose

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Resolved - change required (View Workflow)
    • Priority: Highest
    • Resolution: Persuasive
    • Specification:
      US SDOH Clinical Care (FHIR)
    • Raised in Version:
      0.1.0
    • Work Group:
      Patient Care
    • Related Page(s):
      MustSupport and Missing Data
    • Grouping:
    • Resolution Description:
      Hide

      Current text

      Receiving Systems SHOULD be capable of processing (display, store, etc) the data elements based on the utility of the specific element to the receiver.

      Proposed Text

      Receiving Systems SHALL be capable of processing (display, store, etc.) all required elements (Cardinality 1 or greater) and SHOULD be capable of processing (display, store, etc.) all mustSupport elements. The expectation is that this requirement will be tightened (SHOULD going to SHALL) for at least a subset of the mustSupport elements in future version of the IG

      Show
      Current text Receiving Systems SHOULD be capable of processing (display, store, etc) the data elements based on the utility of the specific element to the receiver. Proposed Text Receiving Systems SHALL be capable of processing (display, store, etc.) all required elements (Cardinality 1 or greater) and SHOULD be capable of processing (display, store, etc.) all mustSupport elements. The expectation is that this requirement will be tightened (SHOULD going to SHALL) for at least a subset of the mustSupport elements in future version of the IG
    • Resolution Vote:
      Bob Dieterle / Jay Lyle : 7-0-3
    • Change Category:
      Correction
    • Change Impact:
      Non-compatible

      Description

      The mustSupport ruels for USCore for receivers are too light here. In the Gravity use-cases, to be conformant, I think systems must understand and support all of the MS elements in the profiles. In the case of US Core, it's supporting an essentially unlimited set of use-cases. In the case of SDOH, it's supporting a single use-case. Saying it's ok to not support arbitrary elements (SHOULD, not SHALL support) is potentially dangerous and not going to achieve interoperability. Similarly, just as Da Vinci places increased restrictions in where/when DAR is allowed, I think the same holds true from Gravity. You don't want any arbitrary mandatory element to be able to be omitted - you need to decide where DAR is ok and where it's not for your specific use-case.

      (Comment 108 - imported by: Robert Dieterle)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              lloyd Lloyd McKenzie
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: