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

Consider renaming parameters

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Resolved - change required (View Workflow)
    • Priority: Medium
    • Resolution: Persuasive with Modification
    • Specification:
      US Da Vinci HRex (FHIR)
    • Raised in Version:
      0.1
    • Work Group:
      Clinical Interoperability Council
    • Related Page(s):
      Profile overview
    • Grouping:
    • Resolution Description:
      Hide

      Based on the expansion of the use-case to include provider-initiated member match, rather than just payer member match, the 'new Coverage' will have to be optional.  In addition, we will do the following:

      1. We will add a usage note explaining that the term "oldCoverage" actually refers to the "coverageToMatch" and the "newCoverage" actually refers to the "coverageToLink" and that we're retaining the original names to avoid issues for systems bound by regulation, but that the names might change in a future release.
      2. We will add a business rule that says "for now", that if a member match comes in with a "newCoverage", it SHALL be echoed back by the server.  However, will add a note that this requirement is likely to be removed in future versions
      3. We will add an implementation note indicating that payers SHOULD NOT depend on the presence of newCoverage in the operation response to tie request and response instances together in their system, but should instead use standard FHIR mechanisms (and include an explanation of how to do that for both synchronous and asynchronous systems)
      4. Will add a note that when invoking the operation, newCoverage is "mustSupport" and SHALL be sent by payers to allow the original payer to establish a linking in their system between old and new member and leverage this linkage information when determining authorization to share information in subsequent queries or other operations.

      Will also add an example for provider-to-payer member match.

      Show
      Based on the expansion of the use-case to include provider-initiated member match, rather than just payer member match, the 'new Coverage' will have to be optional.  In addition, we will do the following: We will add a usage note explaining that the term "oldCoverage" actually refers to the "coverageToMatch" and the "newCoverage" actually refers to the "coverageToLink" and that we're retaining the original names to avoid issues for systems bound by regulation, but that the names might change in a future release. We will add a business rule that says "for now", that if a member match comes in with a "newCoverage", it SHALL be echoed back by the server.  However, will add a note that this requirement is likely to be removed in future versions We will add an implementation note indicating that payers SHOULD NOT depend on the presence of newCoverage in the operation response to tie request and response instances together in their system, but should instead use standard FHIR mechanisms (and include an explanation of how to do that for both synchronous and asynchronous systems) Will add a note that when invoking the operation, newCoverage is "mustSupport" and SHALL be sent by payers to allow the original payer to establish a linking in their system between old and new member and leverage this linkage information when determining authorization to share information in subsequent queries or other operations. Will also add an example for provider-to-payer member match.
    • Resolution Vote:
      Bob Dieterle / Richard Esmond : 9-0-1
    • Change Category:
      Enhancement
    • Change Impact:
      Non-compatible

      Description

      It's not clear that "new" and "old" will be relevant to all uses of this operation.  So perhaps 'requester' and 'source'?

      Also, not clear why 'new' Coverage gets shared.  And should consider whether resource id should come back as part of new Coverage.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: