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

revise sentence in Architectural Approach on CDS Hooks

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci CRD (FHIR)
    • 1.1.0-ballot [deprecated]
    • Financial Mgmt
    • STU
    • Technical Background
    • 3.5
    • Hide

      This section is documenting our path through the decision tree.  We have landed on and chosen CDS Hooks as the solution, so removing the line that says we've chosen CDS Hooks and why would make no sense.

      The need for security provisions is not a criteria around the selection/non-selection of CDS Hooks.  EHRs are free to impose 'appropriate' constraints on data access to CDS services.  The security considerations wouldn't have been any different if we'd used operations or messages - they simply wouldn't have been as elegant.

      The questions raised by implementers about the viability of CDS Hooks have been focused on preserving the status quo, where there is no decision support given to providers and all prior authorization considerations are handled in the back office.  That would be completely contrary to the objectives of this implementation guide.

       
      However, to acknowledge the concern, we will add a new paragraph under the list of bullets describing our walk through the decision tree that says:
      "Because of the sensitivity around disclosure of clinical information to payer-controlled systems during the clinical workflow process, this IG imposes a number of safeguards around the use of the selected CDS Hooks technology to help ensure that providers and their systems have an appropriate degree of control over disclosure and that information can't be used in inappropriate ways."

      Show
      This section is documenting our path through the decision tree.  We have landed on and chosen CDS Hooks as the solution, so removing the line that says we've chosen CDS Hooks and why would make no sense. The need for security provisions is not a criteria around the selection/non-selection of CDS Hooks.  EHRs are free to impose 'appropriate' constraints on data access to CDS services.  The security considerations wouldn't have been any different if we'd used operations or messages - they simply wouldn't have been as elegant. The questions raised by implementers about the viability of CDS Hooks have been focused on preserving the status quo, where there is no decision support given to providers and all prior authorization considerations are handled in the back office.  That would be completely contrary to the objectives of this implementation guide.   However, to acknowledge the concern, we will add a new paragraph under the list of bullets describing our walk through the decision tree that says: "Because of the sensitivity around disclosure of clinical information to payer-controlled systems during the clinical workflow process, this IG imposes a number of safeguards around the use of the selected CDS Hooks technology to help ensure that providers and their systems have an appropriate degree of control over disclosure and that information can't be used in inappropriate ways."
    • Bob Dieterle / Chris Cioffi : 12-0-0
    • Clarification
    • Non-substantive

    Description

      This is not accurate – CRD involves sharing PHI with patient, privacy/security protections are needed (which is different than a CDS that is just providing clinical guidelines etc to a physician). For example, protections are needed to not trigger CRD for insured patient who wishes to self pay for a particular service. Further, there have been question raised by vendors about the value and ability of CDS Hooks. Suggest revising this statement " CDS-hooks? - Yes - CDS hooks was a good fit for the workflow we needed. There was no need to define custom operations or messages to meet our use-cases."

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: