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

“hooking” on a mere patient view seems premature

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci CRD (FHIR)
    • Financial Mgmt
    • Supported Hooks
    • Hide

      CRD doesn't require support (or anticipate support) for triggering off the Patient hook.  However, it wouldn't be wrong to do so.  Payers may have relevant clinical information.  For example, a payer may have awareness (based on what was paid for when) that a patient is due for a particular type of screening and may wish to highlight that and even simplify the process of ordering the relevant test. CRD isn't only about payment or prior authorization.

      However, based on further discussion, we will add the following language to the specification:

      Implementations SHALL have the ability to flag particular orders, appointments, encounters and other records as 'payer-sensitive' and ensure that such sensitive information is not queryable by payers and that such information does not trigger payer hooks or get included as part of payer hook invocation.  The process to flag information as payer-sensitive should fit within standard workflow and minimize provider effort.  The determination of the flag SHOULD be set as early in the process as possible in the workflow to ensure that decision support can be provided as early as possible.

       

      Show
      CRD doesn't require support (or anticipate support) for triggering off the Patient hook.  However, it wouldn't be wrong to do so.  Payers may have relevant clinical information.  For example, a payer may have awareness (based on what was paid for when) that a patient is due for a particular type of screening and may wish to highlight that and even simplify the process of ordering the relevant test. CRD isn't only about payment or prior authorization. However, based on further discussion, we will add the following language to the specification: Implementations SHALL have the ability to flag particular orders, appointments, encounters and other records as 'payer-sensitive' and ensure that such sensitive information is not queryable by payers and that such information does not trigger payer hooks or get included as part of payer hook invocation.  The process to flag information as payer-sensitive should fit within standard workflow and minimize provider effort.  The determination of the flag SHOULD be set as early in the process as possible in the workflow to ensure that decision support can be provided as early as possible.  
    • Bob Dieterle / Celine Lefebvre: 19-0-3
    • Enhancement
    • Compatible, substantive
    • Yes

    Description

      “hooking” on a mere patient view seems premature – especially if information is being sent to the payer, as no service has been ordered yet. There is no “payment/operation” use for the information if no service is in the process of being ordered.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: