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

Consent Directive Use Cases

From HL7Wiki
Jump to navigation Jump to search

Back to: CBCC Main Page > CBCC Use Cases

See also: Glossary of Consent Terms for definition of acronyms and terms.


Introduction

The following use cases describe requirements for the creation and use of privacy consent directives to express consumer preference in regards personal health record and personally/individually identifiable information. These use cases are based on the recommendation issued by [www.samhsa.gov/ SAMHSA] in May 2008 to the American Health Information Community (AHIC) Consumer Empowerment Workgroup:

Recommendation 1:

Personal Health Records should possess the functional and technical capability to enable healthcare consumer control of the collection, access, use, and disclosure of their individually identifiable health information (IIHI) according to the type of information, type of provider, and purposes/circumstance of the collection, access, use, or disclosure. The consumer control capability must remain associated with the IIHI as it travels through the electronic health information exchange such that consumer control is supported when IIHI is further disclosed. Thus, the consumer control of IIHI capability must span Electronic Health Records and Personal Health Recrods.

Sarah Wattenberg, May 15th, 2008

Use Cases

Grant Control of the Personal Health Records to Individuals

This use cases is the basis of the entire Consent Directive specification. If the consumers do not own/control their IIHI, then they cannot specify consent directives or privacy preferences.

Basic Scenario

Based on the current regulation, the Jurisdictional Authority assigns the right to control personal health information to the individual who is its subject or to their designated Substitute Decision Maker (SDM) that acts on behalf of that individual. In addition to providing control, the regulation specifies a set of default privacy policy. An individual (or their SDM) may customize their privacy preferences through Consent Directives.

Control is limited to one or more specified purposes of use as well as a finite range of granularity options based on the consent model adopted by the jurisdiction.

Post-Condition

Based on the default privacy policy, a individual(consenter) may assign control to parts of the personal health records to specific providers for treatment or other organization for research, etc.

Actors

See also: Actor definitions

  • Jurisdictional Authority
  • Consenter
  • Substitute Decision Maker (SDM)

Consenter Manages Consent Directives

The Consenter, a consumer or substitute decision maker uses an eConsent management system (CDMS) via Web portal to manage the eConsent rules that are shared with healthcare providers, payers, and others that may access the consumer's personal health records. The CDMS may embedded in a PHR System or some other publicly accessible healthcare platform.

Pre-condition

  • The Consenter will have an access to a set of default enumerated eConsent options that are appropriate for that jurisdiction.
    • This precondition relies on the ability of the web portal to access jurisdictional/organizational policies
  • An authenticated Consenter and Consumer identity have been established.
  • The Consenter may be SDM acting on behalf of a Consumer.
  • The consent directive options must be comprehensible by consumers and must allow them to take control of their personal health records
  • The consumer has a trusted relationship with the organization(s) that is providing the CDMS capability and Web Portal associated with it.

Basic Scenario

  • Consenter may add, modify, or revoke consent directive regarding the disclosure of his/her Personal Health Records.
  • Verify that added or modified consent directive rules do not conflict with existing federal or local rules.
  • The CDMS will include default jurisdictional policy rules that are applicable across all requesting organizations. Other organizational or local jurisdiction policies must be applied by each consent requester. The user must not be able to disable the directives derived from these default jurisdictional policies.
    • For example, specific client consent policies are required for Alcohol and Substance Abuse information, as specified by 42 CFR, Part 2.

Actors

See also: Actor definitions

  • Consenter
  • Consent Directives Management Service (CDMS)

Request eConsent for a Consumer

Permission to access, use, update personal health records is determined by both a consumer's eConsent and the policies of the requester's organization and/or governing jurisdiction. The request for a patient's eConsent must discover and reconcile all relevant policies.

Pre-Conditions

  • An authenticated Consumer identity has been established.
  • The Consenter may be SDM acting on behalf of a Consumer.

Basic Scenario

  • The Consent Requester uses the consumer's identity to query the CDMS Registry (if available) and discover location of the specific CDMS that stores the consumer's eConsent.
  • Query the CDMS and retrieve the patient's eConsent.
  • Reconcile patient's eConsent with requester's organizational and jurisdictional consent rules.
    • If the patient's eConsent contradicts the organizational or jurisdictional policies, then requester must flag conflict and attempt to reconcile the differences.

Alternate Flow

  • There are no consent directives for the consumer, or no registered CDMS.
  • Apply only the organizational and jurisdictional rules applicable in the requester's jurisdiction.

Post-condition

  • The consumer's eConsent is retrieved, if available
  • If the consumer's eConsent and the organizational directives cannot be reconciled, the consumer may sign a waiver or refuse medical services.

Actors

See also: Actor definitions

  • Consent Requester
  • Consent Directives Management Service (CDMS)
  • CDMS Registry
  • Consumer

Provider Requests Personal Health Records

When a healthcare provider requires access to the patient's medical history, medication list, problems, allergy, etc. stored in the patient's personal health records, the provider must first retrieve any existing eConsent for that patient. Before the personal health records may be viewed, used, and updated by a provider, that patient's eConsent must be retrieved and used to determine the consumer's consents, dissents, or directives regarding their information.

Basic Scenario

  • Invoke use case: Request Consent Directives for a Patient.
  • Query the repository (or repositories) to retrieve patient's health records including Individually Identifiable Health Information (IIHI)
  • Invoke use case: Consent Directives Filter Health Record Information
    • Use the consent directive rules to filter the patient healht records allowing only content appropriate for the various type of professionals involved in direct care (e.g. nurses, physicians), supporting care (e.g medical technicians, dietitians, etc), administration, and payment.
  • Scenario "Third Party Opinion"

Mary is registered with a disease management organization (DMO). Her DMO offers an advance remote patient monitoring service that collects health information from a couple of health measurement devices installed at patient’s home. At the time of registration with DMO, Mary fills in a consent form as EHR-S of the DMO supports the manage consent and authorization functionality as well as patient privacy and confidentiality (DC.1.3.3, IN.1.9). This consent form (privacy policy) will govern the access and usage to Mary’s personal health data in the future. Mary specifies in her privacy policy that her data can be used for legitimate healthcare purposes by nurses at the DMO and that they could share it with her GP. In addition to the patient’s consent, there may be DMO privacy/security policy that together with the patient specified consent may govern disclosure and usage of the patient’s health data to third parties. Mary doesn’t do well in the program and develops a specific condition. Therefore, a nurse from the DMO wants to consult Mary’s GP. The nurse can share the health data collected by Mary in a secure way with Mary’s GP as she is allowed to do so according to the Mary’s privacy policy. Since EHR-S of the DMO has the functionality to support referrals (DC.2.4.2), the nurse prepares her referral report which may include Mary’s demographics and vital signs measurements. The nurse forwards her referral report in protected manner (e.g. encrypting it) together with the patient’s privacy policy and/or DMO privacy/security policy. These policies will govern the access and usage to her referral report. After successful authentication to his EHR-S system, the GP (or the specialist) notices a new message from the nurse, which contains Mary’s referral report. The GP clicks on the report and gives his opinion on Mary’s status. The application of the GP only allows him to view the report and not to forward it (as he is not allowed to do so according to Mary’s privacy policy). Note that if the nurse from the DMO sends the report by mistake to another care provider and not to Mary’s GP, that care provider will not be able to access the data as it is cryptographically protected

  • Scenario "Sharing Data with Fitness Coach"

Mary is concerned with her blood pressure and wants to more actively manage her health (PH.3); hence she registers with a PHR service (e.g. WebMD, Microsoft Health Vault etc.) where she can upload her blood pressure, activity and other measurements data related to her health. At the time of registration with PHR-S, she fills in a consent form as the PHR-S supports the manage consent and authorization functionality as well as patient privacy and confidentiality (S.1.3.3, IN.3.8). This consent form will govern the access and usage to Mary’s personal health data in the future. After collecting her blood pressure (BP) for a month and confirming her fears Mary registers with a disease management organization (DMO) to get help in managing her hypertension. Mary updates her privacy policy allowing that her data can be used for legitimate healthcare purposes by a nurse at the DMO. Mary takes her BP by herself and uploads it in combination with other measurements data such as her weight to the PHR-S. The nurse at the DMO logs in and authenticates successfully to the PHR-S system. The nurse can view Mary’s self reported data according to her privacy policy. The nurse examines Mary’s self reported data and at one point suggests her to register with a health and wellness centre to decrease her blood pressure. Mary registers with a fitness service. In addition, Mary modifies her privacy policy in order to allow a fitness coach to view parts of her personal health data. Since PHR-S has the functionality for support for referrals (PH.6.6), the nurse prepares her report which may include vital signs and other demographic data. The nurse forwards her referral report in protected manner (e.g. encrypting it) together with the patient’s privacy policy that governs the access and usage to her referral report. After successful authentication to his fitness application, the fitness coach notices the reception of a new message from the nurse at DMO, which is the referral report for Mary. The fitness coach prepares a personalized program for Mary. The fitness coach application only allows the fitness coach to view Mary’s report and selected data from her PHR service. However his application does not allow him to view the other data at her PHR and to further disclose (e.g. forward) the referral and the selected data as specified in Mary’s privacy policy.

Post-condition

  • The Provider's EHRS stores a copy of the patient's health record that was created in by that provider. This information must be retained for legal reasons.
  • The Provider's EHRS must update the patient's health record in the appropriate repository with the new data that was created by the provider. The Provider must flag the perosonla health records created during the visit and the Individually Identifiable Health Information (IIHI) contained in it according to the patient's eConsent.

Actors

See also: Actor definitions

  • Provider's EHR System (EHRS)
  • PHR Repository

Mask Health Record Information based on Consumer Preferences

Filtering mechanisms and algorithms are required that apply eConsent rules describing the consumer's preferences to that individual's personal health records. Consent directives may include restricted access filters that are applied to a category of health information (e.g., all HIV related information). A consent directive may also require that personally identified health information is "masked" to protect the patient's sensitive information.

Pre-conditions

  • A provider's role is based on their relationship to the patient and their role within the organization. For example, a member of the immediate care team may be a physician, nurse practitioner, etc.. These users may be allowed to see and update the personal health records while other clinicians (e.g. laboratory medical technicians, consulting physicians, etc.) will be allowed access only to the information intended for their use (e.g. laboratory order or consult request).
  • A patient through the consent directive may be be able to exclude or include specific types of users of personal health records based on various criteria (e.g. exclude a physician who happens to have a personal relationship a certain role within the provider organization).
  • A provider requests a patient's health record in order to provide care to the patient. The information may provided in the form of structured or unstructured clinical documents.

Basic Scenario

Depending on whether the information is structured or unstructured, masking personal health records may be applied at document level, or on document sections. Structured information and coded information may be masked or filtered at the data element level. Unstructured information can only be filtered or masked at the document or document section level.

Actors

See also: Actor definitions

  • Consent Directives Management Service (CDMS)
  • Consent Requester

Flag Masked Health Record Information

Local policies may allow an authorized provider to know that restricted information is available in the personal health record even though it was masked based on the Consenter's eConsent or local privacy policies. Upon Consenter's approval or by "breaking the glass" in an emergency the provider may access the information that was masked. "Breaking the glass" occurs when a provider who is authorized by organizational policy or jurisdictional law overrides the consumer's dissent.

Pre-condition

Based on local policy rules, provider may or may not know that a set of personal health information was masked as a result of a consumer's preferences. Some jurisdictions may eliminate the option of breaking the glass by not allowing providers to know that they cannot access is otherwise included in the consumer's personal health records.

Basic Scenario

If the consenter authorized a specified type of provider (e.g. one involved in supporting care services) to access specific parts of the personal health record but not other parts, the PHR respository will provide the information allowed in the consent and provide flags indicating that other types of IIHI was excluded (e.g. flag that substance-abuse-related information exists). In case of an emergency or based on consenter's approval, the provider may retrieve the masked information, thus "breaking the glass".

  • A provider's use of restricted information upon may be limited to read-only for a specified time period, after which the consent approval will expire.

Actors

See also: Actor definitions

  • Healthcare Provider
  • Consent Directives Management Service (CDMS)
  • PHR Repository

Provider Amends Personal Health Records based on Consumer's eConsent

If the consumer requested it, the provider will update the personal health records stored at a location specified by the patient at the end of a visit, encounter, procedure, etc.

Pre-condition

The provider is given access to an individual's personal health records (including IIHI) and the consent directive,

Post-condition

  • The provider produce additional information as a result treating the patient.
  • The consumer's personal health records are updated in the Repository.
  • It must be possible to interpret the information added to the perosonal health records such as a system can correctly differentiate information that my be sensitive under jurisdictional, organizational, or under consumer's own eConsent preferences.

Actors

See also: Actor definitions

  • Consenter
  • Provider
  • PHR Producer

Request Privacy Policies from Organization or Jurisdiction

Pre-condition

  • Consumers have trusted digital identities
  • Jurisdictional Authorities (national, state, etc.) and other organizations issue privacy policies that apply to personal health records (including IIHI).
  • These polices may vary from national to state/province to local/organization. They may also vary across organizations or states/provinces.
  • A system is required to evaluate/access the policies that apply in a jurisdiction or organization

Basic Scenario

  • Based on a user request, a system sends a query for current privacy policy rules that apply in a jurisdiction or organization.

Post-condition

  • The requesting system has copy of the policy rules for the designated organization or jurisdiction

Actors

  • Policy Directory or a Policy Management Service
  • Requesting system (e.g. CDMS)

Share Privacy policies between jurisdictions

Pre-condition

Basic Scenario

Post-condition

Actors

See also: Actor definitions