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

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Highest
    • US Da Vinci CDex (FHIR)
    • current
    • Patient Care
    • Specification [deprecated]
    • Hide

      PAS Claim  constrained to the preauthorization use case and cannot be used for other use cases such as claims attachments or audits and the the commenter suggests.  Will reference the FHIR base claim resource as it is defined in HRex. 

      re: Formalizing the described scenarios into specific use-cases: 

      Document in the IG:

      The intent of the rewritten IG was not to enumerate specific use-cases and provides examples. For this IG we focus the existing examples on simple scenarios  to illustrate the different approached for exchanging Clinical data.  Instead we plan to create "Clinical Data Exchange- Supplemental Guide(s)"  which will consist of use case examples.

      And reference where they will resolve.

       

       

      Show
      PAS Claim  constrained to the preauthorization use case and cannot be used for other use cases such as claims attachments or audits and the t he commenter suggests.  Will reference the FHIR base claim resource as it is defined in HRex.   re:  Formalizing the described scenarios into specific use-cases:   Document in the IG: The intent of the rewritten IG was not to enumerate specific use-cases and provides examples. For this IG we focus the existing examples on simple scenarios  to illustrate the different approached for exchanging Clinical data.  Instead we plan to create "Clinical Data Exchange- Supplemental Guide(s)"  which will consist of use case examples. And reference where they will resolve.    
    • Enhancement

      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.

      (Comment 21 - imported by: Jean Duteau)

            Assignee:
            Unassigned
            Reporter:
            Isaac Vetter
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: