XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci CDex (FHIR)
    • 1.0.0
    • Patient Care
    • STU
    • Exchanging Clinical Data [deprecated]
    • Hide

      The referenced section 

      Exchanging Clinical Data

      The Specification pages provides specific guidance on exchanging clinical data between Payers and Providers. For general Background on FHIRConformance Expectations, refer to the corresponding sections in the Da Vinci Health Record Exchange (HRex) Implementation Guide. For Security and Privacy considerations refer to the Security and Privacy page.

      When we say “Payer” in these pages, we don’t mean to limit ourselves to only Payers. The same technology can be used for other data consumers like Providers. Consider “Payer” here as a short-hand notation for “data consumer”

      FHIR offers numerous architectural approaches for sharing data between systems. Each approach has pros and cons. The most appropriate approach depends on the circumstances under which data is exchanged. (Review the Approaches to Exchanging FHIR Data in the Da Vinci HRex Implementation Guide for more guidance and background.) This guide focuses on three FHIR transaction approaches for requesting information:

      1. Direct Query: Payer directly queries EHR for specific data using the standard FHIR RESTful search.
      2. Task Based Approach: Payer requests the information desired using the FHIR Task resource and the EHR supplies the data possibly with human involvement to find/aggregate/filter/approve it.
      3. *Attachments*This content is DRAFT and is open for ballot. Based on pre-defined payor rules or business needs the EHR sends supporting information for claims or prior authorization directly to Payer using a “push” based FHIR operation.

      See the Background page for an overview.

      Payers may request data for many patients/members or anticipate large payloads from the Provider. For example, requesting a detailed set clinical information related to their members. For these requests, the Bulk Data Access IG and the FHIR Asynchronous Request Patterns specifications may be considered. However, there has not been enough implementation experience with this use case to provide specific guidance in this guide.

       

      This page provides  a brief high level introduction to the 3 types of exchanges to tie the pages together under the Specification menu item.  "how CDex helps exchange clinical data" and  example use cases  are  covered in the Introduction to guide and in the Background Section.  There is no need to repeat it here.

      In. FHIR-37166  We  have agreed that "preferred" should be removed.

      Show
      The referenced section  Exchanging Clinical Data The Specification pages provides specific guidance on exchanging clinical data between Payers and Providers. For general  Background on FHIR ,  Conformance Expectations , refer to the corresponding sections in the  Da Vinci Health Record Exchange (HRex)  Implementation Guide. For Security and Privacy considerations refer to the Security and Privacy page. When we say “Payer” in these pages, we don’t mean to limit ourselves to only Payers. The same technology can be used for other data consumers like Providers. Consider “Payer” here as a short-hand notation for “data consumer” FHIR offers numerous architectural approaches for sharing data between systems. Each approach has pros and cons. The most appropriate approach depends on the circumstances under which data is exchanged. (Review the  Approaches to Exchanging FHIR Data  in the Da Vinci HRex Implementation Guide for more guidance and background.) This guide focuses on  three  FHIR transaction approaches for requesting information: Direct Query:  Payer directly queries EHR for specific data using the standard FHIR RESTful search. Task Based Approach:  Payer requests the information desired using the FHIR  Task  resource and the EHR supplies the data possibly with human involvement to find/aggregate/filter/approve it. *Attachments*This content is DRAFT and is open for ballot. Based on pre-defined payor rules or business needs the EHR sends supporting information for claims or prior authorization directly to Payer using a “push” based FHIR operation. See the Background page for an overview. Payers may request data for many patients/members or anticipate large payloads from the Provider. For example, requesting a detailed set clinical information related to their members. For these requests, the  Bulk Data Access IG  and the  FHIR Asynchronous Request Patterns  specifications may be considered. However, there has not been enough implementation experience with this use case to provide specific guidance in this guide.   This page provides  a brief high level introduction to the 3 types of exchanges to tie the pages together under the Specification menu item.  "how CDex helps exchange clinical data" and  example use cases  are  covered in the Introduction to guide and in the Background Section.  There is no need to repeat it here. In. FHIR-37166   We  have agreed that "preferred" should be removed.
    • Eric Haas/Jay Lyle:9-0-1
    • Clarification
    • Non-substantive

    Description

      We are having trouble understanding how CDex helps exchange clinical data. The guide is relatively vague. It would be helpful to provide more in the narrative and give more examples. Futhermore, it is unclear why Data Query is the preferred method? As far as we can tell, a task based approach would be preferable from a patient privacy and security standpoint as it is more in line with the concept of Purpose of Use. Suggest deleting the term preferred, or better explaining the pros and cons of each approach, and to/for who data query would be the preference, if at all.

      Attachments

        Activity

          People

            Unassigned Unassigned
            celine_lefebvre Celine Lefebvre
            Celine Lefebvre
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: