The stated authorization preconditions are insufficient. - HRex #96

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive with Modification
    • Priority: Medium
    • US Da Vinci HRex (FHIR)
    • Financial Mgmt
    • Profile overview [deprecated]
    • Hide

      The process by which data sources (EHRs or Payers) use to track patient consent and data segmentation is not subject to this IG as it is done internally within the application.  We will, in our section on security and privacy, make clear that the data source is responsible for ensuring consent for disclosure exists and appropriately segmenting data to comply with any restrictions on consent.

      The section on Privacy and Security for HRex was reviewed on multiple working calls and the Security WG.  All comments incorporated into the final document.  This is now the Privacy and Security Section for the HRex IG and the basis of the Privacy and Security Section of all Da Vinci IGs (subject to specific use case requirements). 

      However, when it comes to sharing information, at this time, there is no regulatory requirement to convey consent directives or security labeling to allow any patient-directed restrictions on data sharing to be conveyed with downstream information consumers.  As such, it would be premature for this implementation guide to mandate support for such mechanisms.  Nothing within this IG prevents the sharing of consent directives or the use of security labels on data for those systems that choose to do so and which have in place the appropriate legal agreements to ensure the shared constraints are appropriately adhered to.

      Show
      The process by which data sources (EHRs or Payers) use to track patient consent and data segmentation is not subject to this IG as it is done internally within the application.  We will, in our section on security and privacy, make clear that the data source is responsible for ensuring consent for disclosure exists and appropriately segmenting data to comply with any restrictions on consent. The section on Privacy and Security for HRex was reviewed on multiple working calls and the Security WG.  All comments incorporated into the final document.  This is now the Privacy and Security Section for the HRex IG and the basis of the Privacy and Security Section of all Da Vinci IGs (subject to specific use case requirements).  However, when it comes to sharing information, at this time, there is no regulatory requirement to convey consent directives or security labeling to allow any patient-directed restrictions on data sharing to be conveyed with downstream information consumers.  As such, it would be premature for this implementation guide to mandate support for such mechanisms.  Nothing within this IG prevents the sharing of consent directives or the use of security labels on data for those systems that choose to do so and which have in place the appropriate legal agreements to ensure the shared constraints are appropriately adhered to.
    • Bob Dieterle / Russ Leftwich: 8-0-0
    • Correction
    • Non-substantive

      Existing Wording: The HRex profiles documented in this IG will be used to exchange data between providers systems (e.g. EHRs) and other providers, payers, and third-party applications were appropriate.

      Then @ the following links is a precondition: "The Information Server adheres to business rules that govern which patients can be queried by authorized Information Clients, and what information can be returned to Information Clients. The Information Client is authorized to create new or update information onto the Information Server."

      HRexPush (POST and PUT)

      https://build.fhir.org/ig/HL7/davinci-ehrx/Push_(POST_and_PUT).html

      Hrex PUSH

      https://build.fhir.org/ig/HL7/davinci-ehrx/Push_(Unsolicited_Communication).html>

      HRex GET

      https://build.fhir.org/ig/HL7/davinci-ehrx/Pull_(GET).html

      Comment:

      The stated authorization preconditions are insufficient. There need to be specific privacy/security protocols in scope of this IG for all interactions. Why does this IG only specify that Member-authorized sharing of information between Payers, or from a Payer to a Third-Party Application, uses the OAuth2.0 Authorization protocol? What about Provider to Payer information sharing? Why is no authorization protocol specified for Provider to Payer? And even if SMART on FHIR were specified, the presumption that such exchanges are simply permitted under HIPAA Treatment, Payment, and Operations purposes, as stated in PDex, is insufficient. There are a number of privacy policy use cases that SMART on FHIR would not be capable of supporting, and where the Provider's access control system would need to check for consent directives before disclosing. Wrt to SMART on FHIR not supporting security labeling: Providers may share Title 38 Section 7332 information with Payers without an authorization, but still must label the disclosed information as requiring "restricted" confidentiality protections i.e., accessible only by users with a need to know 7332 sensitive information, as well as the privacy tags for the governing law, the sensitivity type, the permissible purposes of use. Wrt to checking consent directives: Providers need to segment any information for which a patient has paid in full out of pocket and directed the Provider not to share with specified Payers. This IG needs to provide additional guidance on how implementers should support the need to check consent directives, segment information based on those directives or other privacy policies, and how to label disclosed information so that the recipient is able to comply with governing policies.

      Summary:

      The stated authorization preconditions are insufficient.

            Assignee:
            Unassigned
            Reporter:
            Kathleen Connor
            Kathleen Connor
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: