We shouldn't be echoing back the 'new' Coverage

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive
    • Priority: Medium
    • US Da Vinci HRex (FHIR)
    • current
    • Clinical Interoperability Council
    • HRex Parameters - Member Match Response Profile
    • Hide

      We've discussed this as part of another tracker item.  We definitely don't need to echo back the new coverage because linking of request and response should always be done using the technical mechanisms FHIR provides, not the data shared.  However, because the requirement was set in the version of the IG that went to regulation, we can't remove it.  In the prior disposition we agreed to add guidance that the requesting system should ignore the echoed-back coverage and NOT use it to match request and response.

      Show
      We've discussed this as part of another tracker item.  We definitely don't need to echo back the new coverage because linking of request and response should always be done using the technical mechanisms FHIR provides, not the data shared.  However, because the requirement was set in the version of the IG that went to regulation, we can't remove it.  In the prior disposition we agreed to add guidance that the requesting system should ignore the echoed-back coverage and NOT use it to match request and response.
    • Bob Dieterle / Richard Esmond : 9-0-1

      The request already identifies the new coverage, and the response is always tied to exactly one request - which has exactly one new coverage.  Echoing this back is, at best, redundant and overly complex, and, at worst, a chance for things to get broken (in the event the old payer accidentally echoes back the new coverage incorrectly).  The

            Assignee:
            Unassigned
            Reporter:
            Lloyd McKenzie
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: