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

Better standardize Task.reasonReference by formalizing (but not limiting) the current scenarios

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci CDex (FHIR)
    • current
    • Patient Care
    • (many)
    • Hide

      Background

      Task.reasonReference and Task.reasonCode are 0…1 MS

      Changes

      1. make Task.reasonReference.identifer 0…1 MS

      Add a comment to the element:

      Most payer systems will not expose their claim and prior authorization records as a FHIR resource. They will provide a unique business identifier for the claim or prior authorization using Task.reasonReference.identifier.  This could be a payer-assigned or provider-assigned identifier which SHOULD be communicated inTask.reasonReference.identifier.type using the FILL for the payer and PLAC for the provider.

      2. update examples to use claim identifiers (and other business identifiers as well) to reflect the more likely usage.

      3. The intent of this IG to provide a general approach illustrating the different approaches with a simple scenarios and representative examples. We will be adding the Attachments Use Case as a specific use case. But we plan to create “Clinical Data Exchange- Supplemental Guide(s)” which will consist of the other use case examples.

      4.  In the general case the CDex Task Data Request Profile will not reference a specific Claim or Coverage profile.  For a specific use case, however the reasonreference may indeed reference a profile.

      Show
      Background Task.reasonReference and Task.reasonCode are 0…1 MS Changes 1. make Task.reasonReference.identifer 0…1 MS Add a comment to the element: Most payer systems will not expose their claim and prior authorization records as a FHIR resource. They will provide a unique business identifier for the claim or prior authorization using  Task.reasonReference.identifier .  This could be a payer-assigned or provider-assigned identifier which  SHOULD  be communicated in Task.reasonReference.identifier.type  using the FILL for the payer and PLAC for the provider. 2. update examples to use claim identifiers (and other business identifiers as well) to reflect the more likely usage. 3. The intent of this IG to provide a general approach illustrating the different approaches with a simple scenarios and representative examples. We will be adding the Attachments Use Case  as a specific use case. But we plan to create “Clinical Data Exchange- Supplemental Guide(s)” which will consist of the other use case examples. 4.  In the general case the  CDex Task Data Request Profile will not reference a specific Claim or Coverage profile.  For a specific use case, however the reasonreference may indeed reference a profile.
    • Eric Haas/Bob Dieterle: 8-0-3
    • Correction
    • Non-compatible

      Many of the excellent examples contain a Task.reason* of supporting prior auth and the url to a Claim on the payer's FHIR server. Is the intent that this Claim resource adheres to the PAS Claim profile? If so, you should make this a SHALL by formalizing the described scenarios into specific use-cases and standardizing the Task.reasonReferences. Generally, the more machine understandable the reasonReference is, the more automatable this will be.

       

            Unassigned Unassigned
            Isaac.Vetter Isaac Vetter
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: