This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Consent Directive Implementation Guide

From HL7Wiki
Jump to navigation Jump to search

Back to CBCC Wiki: Meetings

Back to HL7 FHIR Consent Directive Project

You can get to current Privacy Consent Directive IG in the continuous build directly: http://hl7-fhir.github.io/pcd/pcd.html

This page is used to develop new content before committing it to the Current build.

  • Do NOT write more than is necessary for our reader to understand how to use
    • Rely on prior works to explain basics
    • Less is More

Draft Privacy Consent Directive IG

Introduction (Glen)

  • Note we have an introduction to the PCD http://hl7-fhir.github.io/pcd/pcd.html
  • Need to have consent be informed consent
  • Relationship with Contract - why is a consent a contract? (Kathleen)
  • Relationship with the resources it uses - Patient, Document, AuditEvent, Provenance
  • Relationship with Resources it controls -
  • Use of Questionnaire for UX with patient

Need to have consent be informed consent

Obtaining informed consent from patients is a central ethical requirement of health care treatment. In the context of clinical research or other areas outside of the essential processes of treatment, obtaining informed consent from the subjects of data is often also a regulatory mandate.

Informed consent for data use consists of this information, in a form that is clearly understandable to a layperson patient:

  • Purpose of data use
  • Benefits to the patient of data use
  • Voluntary participation, including the ability to opt-out
  • Degree of confidentiality the patient can expect
  • Risks of data misuse and measures taken to prevent it
  • Liabilities to the patient that the data-collector has for data misuse
  • Contacts that the patient has before, during, and data collection.

The consent must be acknowledged by the patient, or an authorized proxy, plus a representative of the data collecting organization. Acknowledgement may be a signature on a paper document, or an electronic signature with equivalent authenticity. The FHIR consent for data disclosure reflects these elements in a persistent unalterable manner.

Relationship with the resources it uses

Patient The FHIR consent for data disclosure is a resource that is electronically signed by the patient, or proxy, and an authorized representative of the data collection agency.

Document The form of consent is a paper or electronic document authored by an institutional review board (IRB). The form and content may be regulated by laws, government regulations, or institutional policies – often all three – within jurisdictional boundaries. The FHIR consent for data disclosure contains an unalterable dated copy of the original consent document.

AuditEvent Creation of a FHIR consent for data disclosure results in a FHIR audit event, especially noting the participating parties to the consent document. Reading a FHIR consent for data disclosure results in a FHIR audit event, especially noting the party who read it. An attempt to alter to delete a FHIR consent for data disclosure, which should fail, results in a FHIR audit event, especially noting the party the attempted the act. Creation of data copies authorized by a FHIR consent for data disclosure results in a FHIR audit event, especially noting the participating parties. Reading, exporting, updating, or deleting data copies authorized by a FHIR consent for data disclosure results in a FHIR audit event, especially noting the participating parties.

Provenance Creation of a FHIR consent for data disclosure results in a FHIR provenance record, especially noting the data disclosure purpose (e.g., a clinical study identification), the IRB authorship, and the signing parties to the consent document. Creation, update, and deletion of data copies authorized by a FHIR consent for data disclosure results in a FHIR provenance record, especially noting the participating parties.

other A FHIR consent for data disclosure may additionally be related to FHIR resources that:

  • Identify and authorize the IRB and other parties who may create a FHIR data disclosure consent form
  • Identify and authorize the IRB and other parties who may create an instance of a signed FHIR data disclosure form
  • Identify and authorize those who may collect and consume the data, e.g., SMART on FHIR OAuth scopes.

Relationship with Resources it controls

The FHIR consent for data disclosure may result in the creation of patient-specific authorization scopes, should such resources be defined as part of FHIR.  

Use of Questionnaire for UX with patient

Although it is possible that the form of consent document is electronic, it is current practice to obtain consent via a paper-based document. The form of consent is determined by an institutional review board (IRB). The form and content may be regulated by laws, government regulations, or institutional policies – often all three – within jurisdictional boundaries.

The UX for an electronic consent document should contain all of the elements of the paper-based equivalent.

Exceptional Cases

Authorization granted by exceptional means

  • Court order to access outside of normal use
  • Action of auditor
  • Foster Care?
  • Legal hold

Abstract Data Model (Kathleen)

  • What needs to be recorded
  • Types of Consent
    • Basic - TPO
    • Exception vs Inclusion
    • Research (Beth)
    • Patient Centric
  • Jurisdiction Models (David) -- look to Goldstein paper

The selection of consent options and the implementation of the consent directive can be influenced by jurisdictional constraints. Frequently, the national jurisdiction provide a framework that expresses the balance between privacy protection of the individual and the benefit of the public to personal health information. Regulations may increase access to personal health information for the identification and treatment of health emergencies, e.g. syndromic data. Alternatively, governments may reduce access to personal health information in order to encourage treatment of diseases that may bear a stigma, e.g., substance abuse. These decisions may directly affect the range of choices available to the consenter. Additional national involvement, e.g., existence of a national identifier or investment in a national health infrastructure, may impact the implementation of consent directives.

Regional laws or court decisions, e.g., in provinces, states, cantons, and/or municipalities, add an additional layer that may complicate the implementation and interoperable exchange of consent directives. Receipt of health benefits may impact the scope of consent directives for certain groups, e.g., foster children. The impact of the combined legal framework varies depending on the enforcement and penalty mechanisms involved. The exchange of information across jurisdictional boundaries may impact the choice and wording of the consent directive. Jurisdictions may directly affect the choice and scope of consent through the creation of government or quasi-government health information exchanges (HIE) or health information repositories, e.g., immunization registries. Governments may also have indirect influence, e.g., creation of committees that publish guidelines or issue statements on best practices.

Legal frameworks have addressed the use, exchange, and breach of patient information within the traditional health care system. Emerging products and services are now interacting directly with the consumer. Consumer may download medical records, e.g., into personal health record (PHR) applications or health record banks, or generate health-related information using personal monitors. Regulation defining the requirement and documentation of consent in these instances may be regulated under consumer, tort, or common law.

    • Implied
    • Explicit
    • Chinese?
  • Cross-Organization vs Within-an-Organization

Types of Consent

Research (Beth)

An informed consent form for research must provide a potential research subject information about the research study/clinical that will allow the individual to decide whether or not to participate. This information includes a summary of the research study/clinical trial (including its purpose, the treatment procedures and schedule, potential risks and benefits, alternatives to participation, etc.) as well as the rights and responsibilities of all parties involved in the research study/clinical trial. By signing the document, the individual voluntarily consents to participate. Informed consent information is most often presented in the form of a written document, but may also be offered verbally by a member of the study team or in some other format (e.g., online) to the potential subject. Requirements related to the elements, language and format of informed consent can be found in federal regulations 45 CFR 46, Part 46.116.

Abstract Interaction Model (John)

  • Actors -- Not clear which of these need to be formally recognized.
    • Involved in capturing consent
      • Registry of template consents available to be used
      • UX with Legal to update template consents
      • UX with Patient to select, and customize captured consent
      • Registry of Consent instances
    • Involved in enforcing consent
      • Registry of Consent instances
      • Protected Resource Service
      • Access Control Decision Engine
        • Uses Registry of Consents as PIP (May be batch, pre-fetch, real-time)
        • Uses Registry of Identities, Patients, Locations, Organizations, etc
        • Uses RBAC for gross protection of various Resource types (FHIR Resource)
        • Uses resulting data metadata to further refine returned results
      • Enforcement - enforces Decisions
    • Affected transparently
      • Repository of data
      • Requesting party
  • Transactions
    • Template discovery
    • Create, Read, Update, Delete -- Replace
    • Request access decision
    • Communicate data with Consent attached
      • see CP 6865 asking for guidance on how to add a Consent to an otherwise communication pattern Bundle.
      • For example, pushing some data from one place to another, and needing to communicate the Consent
      • For example, asking for data with attached consent giving authorization for the question.

Related Work (John, Kathleen)

  • Consent Receipt
    • Use of AuditEvent - disclosure
  • Relationship to OAuth scopes
  • Relationship to UMA -- HEART
  • IHE BPPC and APPC
  • HL7 CDA Privacy Consent Directive IG
  • HL7 Patient Frendly Consent
  • HL7 HCS
  • ONC Patient Choice (David)

Examples

  • USA Realm examples (Kathleen)
  • Canada Examples (Pat, Ken)
  • European Examples (Alex, Tarik)
  • Research Examples (Rob, Kathleen)

European Examples

Consent for an episode of care

Pre-Conditions:

This use case takes place in an opt-in environment, where all patient data is organized as episodes of care. The episode of care is summarized by a diagnostic code and always has an (expected) end date. The patient is identified using a common patient ID. The participating providers and organizations are listed in a shared healthcare provider directory.

Main Flow:

A patient has completed an inpatient treatment at a mental health treatment center for depression. A staff member of the center recommends a care team consisting of a psychiatrist, the patient’s primary care physician and a occupational therapist. The staff member initiates a new episode of care in her information system to allow the participants to exchange all relevant medical data (i.e. including documents regarding the inpatient treatment, psychiatric evaluations, occupational therapy progress notes, intervention plans, medications and problem lists). The staff member first selects the patient. She then selects the diagnostic code that best summarizes the episode of care and enters the expected duration of the episode. She searches in a provider directory to find the care team members and adds them in her information system to the episode of care. The system prints out a consent form containing this data. The patient signs it and the nurse confirms the signature in her system. The center’s system creates a Consent Resource and posts it to the central, shared FHIR server. The FHIR server's security system uses the information in the Consent Resource to set the access rights for the care team members accordingly.

Post-Condition:

The FHIR server has stored the Consent Resource. The participants can upload and access medical data on the FHIR server if the data is linked to the episode of care. Other healthcare providers do not have access to the medical data on the FHIR server, which is linked to the episode of care.

Example

<Contract xmlns="http://hl7.org/fhir">
 TODO: How can we link to the existing examples pages?

Other Draft Materials

Bernd Blobel Contract Diagram.png

FHIR Consent Directive in Trust Framework

Discussed in Mike Davis' FHIR Contract Design Considerations

FHIR Consent Directive in Trust Framework.png

HL7 FHIR Consent Directive Implementation Guide "Comic Book"

FHIR Consent Directive IG Components.png