What are the known use cases that will use this communication/communicationRequest workflows? - CDex #208

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive with Modification
    • Priority: Medium
    • US Da Vinci CDex (FHIR)
    • STU3
    • Financial Mgmt
    • (many)
    • Hide

      When data is being shared from a provider organization to a payer organization, there's a need to ensure that payers are only asking for (and receiving) information they have a legitimate need to know.  In some cases, that verification/filtering process can be automated and standard query/subscription/etc. mechanisms can be used to support data access.  However, in other cases, the determination cannot be made in an automated way.  In the current world, clinicians and administrative staff handle the determination of relevance in deciding what information to fill into forms or include as attachments for data that is 'pushed' to the payer.  However, as we shift the model to support 'pull', there are still situations where a human needs to be involved.  The CommunicationRequest workflow was intended to support that need.

      We are likely changing from CommuniationRequest to Task for this purpose, but will ensure that the documentation more clearly expresses the circumstances in which this row is necessary - and also note that is in the best interest of provider and payer organizations to come to agreements that maximize the amount of data that can be shared automatically to minimize imposition on provider staff and also to minimize delays to the flow of information.

      Show
      When data is being shared from a provider organization to a payer organization, there's a need to ensure that payers are only asking for (and receiving) information they have a legitimate need to know.  In some cases, that verification/filtering process can be automated and standard query/subscription/etc. mechanisms can be used to support data access.  However, in other cases, the determination cannot be made in an automated way.  In the current world, clinicians and administrative staff handle the determination of relevance in deciding what information to fill into forms or include as attachments for data that is 'pushed' to the payer.  However, as we shift the model to support 'pull', there are still situations where a human needs to be involved.  The CommunicationRequest workflow was intended to support that need. We are likely changing from CommuniationRequest to Task for this purpose, but will ensure that the documentation more clearly expresses the circumstances in which this row is necessary - and also note that is in the best interest of provider and payer organizations to come to agreements that maximize the amount of data that can be shared automatically to minimize imposition on provider staff and also to minimize delays to the flow of information.
    • Bob Dieterle / Laura Herrman : 13-0-2
    • Clarification
    • Non-substantive

      Comment:

      What are the known use cases that will use this communication/communicationRequest workflows? If none are known, can this be removed from the IG as it is not part of the 80% of use cases?

      Summary:

      What are the known use cases that will use this communication/communicationRequest workflows?

            Assignee:
            Unassigned
            Reporter:
            Danielle Friend
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: