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

Significant functional overlap in card types

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci CRD (FHIR)
    • 1.1.0-ballot [deprecated]
    • Financial Mgmt
    • CRD Card Types Code System [deprecated]
      CRD Card Types Value Set
    • Supported Hooks
    • 4.3.4.2
    • Hide

      We will remove any language that suggests that a system action card could be accompanied with an information card conveying the same information and will add explicit language saying that payers SHOULD NOT send information cards conveying the same information as is present in any system action cards.

      Show
      We will remove any language that suggests that a system action card could be accompanied with an information card conveying the same information and will add explicit language saying that payers SHOULD NOT send information cards conveying the same information as is present in any system action cards.
    • Bob Dieterle / Mark Scrimshire : 4-0-1
    • Correction
    • Non-substantive
    • Yes

    Description

      There is significant potential overlap between the proposed cardType values. Most concerningly, the Instructions card type could duplicate the function of any of the other card types.

      This is especially problematic because CRD clients can specify which card types they're willing/able to receive.

      For example, say the CRD service (payer) wants to indicate that prior auth is required. They can do so in a computationally-understandable way with an Annotate card (combined with a [coverage-information extension|http://hl7.org/fhir/us/davinci-crd/2022May/StructureDefinition-ext-coverage-information.html).] But they can also do so in a purely textual way with an Instructions card.

      Now suppose CRD Client A says they can accept Instructions but not Annotate cards, Client B says the opposite, and finally Client C says they can accept both. The CRD service needs to support outputting the fact that prior auth is required in both card types.

      There should be one definite card type to accomplish each action. In the above example, Annotate should be the way to respond that prior auth is required. Additionally, all cards need computable elements, something the purely textual Instructions care lacks.

      Either the Instructions card definition should be updated to include computable elements, or more likely, removed entirely in favor of other more robust card types.

      Attachments

        Activity

          People

            Unassigned Unassigned
            ramccormick Rachael McCormick (Inactive)
            Rachael McCormick (Inactive)
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: