Overall, it would be a lot simpler and cheaper for the old payer to simply expose a RESTful API of mature FHIR resources, rather than creating this new document containing these resources. - PCDE #103

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive
    • Priority: Medium
    • US Da Vinci PCDE (FHIR)
    • STU3
    • Financial Mgmt
    • (profiles) [deprecated]
    • Hide

      Payers will not allow ad-hoc querying of their data by another payer. The use-case here is to ask the other payer to prepare a specific set of relevant information that they feel is safe and appropriate to expose to a 'new' payer in a situation of transition of care. This will generally be a human-mediated operation where a human will examine the existing data and determine what should be shared, potentially pruning resources and also generating narrative explanatory text.

      A good comparison would be asserting that a discharge summary isn't necessary - just expose a FHIR interface and let other hospitals query your data. Plus there's the added complexity that some of the relevant data contains proprietary information (fees, payment amounts, etc.) that can't be shared. The reality is that the selection of data for inclusion in a discharge summary together with the organization of that data and the narrative around it is important to its use. As well, it's something that gets created at a particular point in the workflow and represents information that's been deemed appropriate for sharing

      Show
      Payers will not allow ad-hoc querying of their data by another payer. The use-case here is to ask the other payer to prepare a specific set of relevant information that they feel is safe and appropriate to expose to a 'new' payer in a situation of transition of care. This will generally be a human-mediated operation where a human will examine the existing data and determine what should be shared, potentially pruning resources and also generating narrative explanatory text. A good comparison would be asserting that a discharge summary isn't necessary - just expose a FHIR interface and let other hospitals query your data. Plus there's the added complexity that some of the relevant data contains proprietary information (fees, payment amounts, etc.) that can't be shared. The reality is that the selection of data for inclusion in a discharge summary together with the organization of that data and the narrative around it is important to its use. As well, it's something that gets created at a particular point in the workflow and represents information that's been deemed appropriate for sharing
    • Kathleen Connor / Rachael Foerster: 20-0-1
    • Correction

      Comment:

      Overall, it would be a lot simpler and cheaper for the old payer to simply expose a RESTful API of mature FHIR resources, rather than creating this new document containing these resources.

      Summary:

      Overall, it would be a lot simpler and cheaper for the old payer to simply expose a RESTful API of mature FHIR resources, rather than creating this new document containing these resources.

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

              Created:
              Updated:
              Resolved: