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

Remove Consent.except.purpose - 2016-09 core #74

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • DSTU2
    • Community-Based Care and Privacy
    • Consent
    • 6.4.4
    • Hide

      Add to pupose and security label a comment stating:

      "When the purpose of use tag is on the data, access request purpose of use shall not conflict"

      Show
      Add to pupose and security label a comment stating: "When the purpose of use tag is on the data, access request purpose of use shall not conflict"
    • Kathleen Connor/John Moehrke: 9-0-2
    • Correction
    • Non-substantive
    • DSTU2

    Description

      Existing Wording: Consent.except.purpose Definition: The context of the activities a user is taking - why the user is accessing the data - that are controlled by this exception.

      Proposed Wording: Remove Consent.except.purpose.

      Comment:

      The HL7 definition for this set of ActReason codes is equivalent while more complete than the FHIR Consent definition. It serves exactly the same function, and will result in possibly conflicting purposes of use.

      C:ActReason:PurposeOfUse:23408 Definition: Reason for performing one or more operations on information, which may be permitted by source systems security policy in accordance with one or more privacy policies and consent directives. Description: The rationale or purpose for an act relating to the management of personal health information, such as collecting personal health information for research or public health purposes.

      The only reason to have a purpose of use in a Consent Directive is to computably represent the purpose(s) of use specified in it so that recipients and downstream users know the permissible reasons for and workflows in which they may perform permitted privacy actions. The authors provided no evidence that Consent Directives are indexed or searched for by purpose of use. They seem to conflate the type of Consent Directive with a purpose of use. E.g., a researcher may search for HIPAA Authorizations to ROI for Research, but not a research POU. They might filter on types of Research POU once they have assembled a set of Research Consent Directives that fall under a particular Consent Directive Policy, but searching on research POU first would be far less efficient. In any case, the POU will be in the securityLabel, and that will be authoritative representation of Consent Directive policy, not the one that ends up in a Consent.purpose field with no criteria about its valuing, because POU loses meaning outside of a security label context.

      The Consent.except.purpose is not conformant with the HL7 Healthcare Privacy and Classification System, which is the normative standard specifying how privacy tags are to be used in a security label structure, will lead to conflicting or duplicative use of this privacy tag, and lead to confusion or put all end users at increased risk of breach.

      The authors of this model have not provided any rationale for having a Consent.except.purpose rather than a Consent.securityLabel. Only rationale provided, which is spurious, is that it could be used for indexing of searching for Consent Directives with a specific exception level purpose of use. Indexing and search could be done on a Consent.except.securityLabel purpose of use tag just as well.

      Summary:

      Remove Consent.except.purpose

      Attachments

        Activity

          People

            Unassigned Unassigned
            k.connor Kathleen Connor
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: