Difference between revisions of "Consent Directive Use Cases"
| Line 19: | Line 19: | ||
== Consenter Manages Consent Directives == | == Consenter Manages Consent Directives == | ||
| − | + | A patient or substitute decision maker, the "Consenter", accesses a CDMS through a Web portal and manages consent directive rules that are shared with healthcare providers, payers, and others that may access PHI. | |
===Pre-condition=== | ===Pre-condition=== | ||
===Basic Scenario=== | ===Basic Scenario=== | ||
| − | + | * | |
| + | * By default, the CDMS will include the protection specified by [http://www.access.gpo.gov/nara/cfr/waisidx_02/42cfr2_02.html CFR 42, Part 2]. The user will not be able to disable the directives derived from [http://www.access.gpo.gov/nara/cfr/waisidx_02/42cfr2_02.html CFR 42, Part 2] for Alcohol and Substance Abuse information. | ||
===Actors=== | ===Actors=== | ||
See also: [[CBCC Use Cases#Actors | Actor definitions]] | See also: [[CBCC Use Cases#Actors | Actor definitions]] | ||
| Line 29: | Line 30: | ||
== Request Consent Directives for a Patient == | == Request Consent Directives for a Patient == | ||
| + | Consent for access to PHI is determined by both a patient's consent directives and the policies of the provider's organization and/or governing jurisdiction. The request for a patient's consent must discover and merge all relevant privacy policies. | ||
===Basic Scenario=== | ===Basic Scenario=== | ||
* The Provider's EMRS uses the patient's identity to query the CDMS Registry and discover location of the patient's CDMS. | * The Provider's EMRS uses the patient's identity to query the CDMS Registry and discover location of the patient's CDMS. | ||
* Query the CDMS and retrieve the patient's consent directives. | * Query the CDMS and retrieve the patient's consent directives. | ||
| − | * Merge patient's directives with organizational and jurisdictional consent rules. | + | * Merge patient's directives with organizational and jurisdictional consent policy rules. |
| − | ** If the patient's consent directive rules contradict the organizational or jurisdictional | + | ** If the patient's consent directive rules contradict the organizational or jurisdictional policies, then flag conflict in result set. |
===Alternate Flow=== | ===Alternate Flow=== | ||
* There are no consent directives for the patient, or no registered CDMS. | * There are no consent directives for the patient, or no registered CDMS. | ||
| Line 63: | Line 65: | ||
==Consent Directives Filter Health Record Information== | ==Consent Directives Filter Health Record Information== | ||
Filtering mechanisms and algorithms are required that apply consent directive rules to an individual's health record content. Consent directives may include restricted access filters that are applied to a category of health information (e.g., all HIV related information) or to a particular data element (e.g., filter all instances of a provider's name). A consent directive may also require that personally identified health information is "masked" to hide the patient's identity. | Filtering mechanisms and algorithms are required that apply consent directive rules to an individual's health record content. Consent directives may include restricted access filters that are applied to a category of health information (e.g., all HIV related information) or to a particular data element (e.g., filter all instances of a provider's name). A consent directive may also require that personally identified health information is "masked" to hide the patient's identity. | ||
| − | |||
| − | |||
| − | |||
| − | |||
===Basic Scenario=== | ===Basic Scenario=== | ||
Depending on whether the information is structured or unstructured, filtering may be applied at the record or document level, or on subsections. Structured information, which is encoded data, can be filtered at the data element level. Unstructured information, which is unencoded data that may be transmitted, e.g., as an image or bit map, can only be filtered at the document or document section level. | Depending on whether the information is structured or unstructured, filtering may be applied at the record or document level, or on subsections. Structured information, which is encoded data, can be filtered at the data element level. Unstructured information, which is unencoded data that may be transmitted, e.g., as an image or bit map, can only be filtered at the document or document section level. | ||
| − | |||
===Actors=== | ===Actors=== | ||
See also: [[CBCC Use Cases#Actors | Actor definitions]] | See also: [[CBCC Use Cases#Actors | Actor definitions]] | ||
| Line 77: | Line 74: | ||
==Flag Filtered Health Record Information== | ==Flag Filtered Health Record Information== | ||
If Consenter decides to restrict certain information, he may have the option of deciding whether to permit PHI Repository to send a flag to an authorized party alerting the Consent Requestor that restricted information is available upon Consenter's approval or by "breaking the glass" in an emergency. "Breaking the glass" occurs when a provider who is authorized by organizational policy or jurisdictional law overrides a consent directive. | If Consenter decides to restrict certain information, he may have the option of deciding whether to permit PHI Repository to send a flag to an authorized party alerting the Consent Requestor that restricted information is available upon Consenter's approval or by "breaking the glass" in an emergency. "Breaking the glass" occurs when a provider who is authorized by organizational policy or jurisdictional law overrides a consent directive. | ||
| − | |||
| − | |||
| − | |||
| − | |||
===Basic Scenario=== | ===Basic Scenario=== | ||
Authorize a specified type of provider to access all restricted health information, and to receive a flag that restricted information may be accessed, following Consenter's approval. A provider's use of restricted information is limited to read-only for a specified time period, after which the consent approval will expire. | Authorize a specified type of provider to access all restricted health information, and to receive a flag that restricted information may be accessed, following Consenter's approval. A provider's use of restricted information is limited to read-only for a specified time period, after which the consent approval will expire. | ||
| − | |||
===Actors=== | ===Actors=== | ||
See also: [[CBCC Use Cases#Actors | Actor definitions]] | See also: [[CBCC Use Cases#Actors | Actor definitions]] | ||
Revision as of 14:26, 26 August 2008
Back to: CBCC Main Page > CBCC Use Cases
See also: Glossary of Consent Terms for defintion of acronyms and terms.
Contents
- 1 Introduction
- 2 Use Cases
Introduction
The following use cases describe requirements for the creation and use of consent directives.
Use Cases
Grant Access to Protected Health Information
Pre-condition
The right/license to control one's medical information is assigned by jurisdiction to the Patient.
Basic Scenario
Based on the current regulation, the Jurisdictional Authority assigns the right to control personal health information to the Patient who is its subject or to their designated Substitute Decision Maker (SDM) that acts on behalf of the Patient.
Actors
See also: Actor definitions
- Jurisdictional Authority
- Patient
- Substitute Decision Maker(SDM)
Consenter Manages Consent Directives
A patient or substitute decision maker, the "Consenter", accesses a CDMS through a Web portal and manages consent directive rules that are shared with healthcare providers, payers, and others that may access PHI.
Pre-condition
Basic Scenario
- By default, the CDMS will include the protection specified by CFR 42, Part 2. The user will not be able to disable the directives derived from CFR 42, Part 2 for Alcohol and Substance Abuse information.
Actors
See also: Actor definitions
- Consenter
- Consent Directives Management Service (CDMS)
Request Consent Directives for a Patient
Consent for access to PHI is determined by both a patient's consent directives and the policies of the provider's organization and/or governing jurisdiction. The request for a patient's consent must discover and merge all relevant privacy policies.
Basic Scenario
- The Provider's EMRS uses the patient's identity to query the CDMS Registry and discover location of the patient's CDMS.
- Query the CDMS and retrieve the patient's consent directives.
- Merge patient's directives with organizational and jurisdictional consent policy rules.
- If the patient's consent directive rules contradict the organizational or jurisdictional policies, then flag conflict in result set.
Alternate Flow
- There are no consent directives for the patient, or no registered CDMS.
- Apply only the organizational and jurisdictional consent rules.
Post-condition
- A set of patient's consent directive rules, or empty set if no rules are registered or no CDMS is found.
- Flags for conflicts in merged rules.
Actors
See also: Actor definitions
- Provider's EMR System (EMRS)
- CDMS Registry
- Consent Directives Management Service (CDMS)
Provider Looks up Protected Health Information (PHI)
When a healthcare provider looks up a patient's PHI, that patient's consent directives must be retrieved and used to filter the data before returning or displaying results to the provider.
Basic Scenario
- Invoke use case: Request Consent Directives for a Patient.
- Query the PHI Repository to retreive patient's medical record.
- Invoke use case: Consent Directives Filter Health Record Information
- Use the consent directive rules to filter PHI, allowing only content appropriate for clinician involved in care, administration, and payment.
Post-condition
- The Provider's EMRS stores a copy of the patient's consent directives.
- Question: Is it required that EMRS queries CDMS for current consent rules upon each new clinician session?
Actors
See also: Actor definitions
- Provider's EMR System (EMRS)
- PHI Repository
Consent Directives Filter Health Record Information
Filtering mechanisms and algorithms are required that apply consent directive rules to an individual's health record content. Consent directives may include restricted access filters that are applied to a category of health information (e.g., all HIV related information) or to a particular data element (e.g., filter all instances of a provider's name). A consent directive may also require that personally identified health information is "masked" to hide the patient's identity.
Basic Scenario
Depending on whether the information is structured or unstructured, filtering may be applied at the record or document level, or on subsections. Structured information, which is encoded data, can be filtered at the data element level. Unstructured information, which is unencoded data that may be transmitted, e.g., as an image or bit map, can only be filtered at the document or document section level.
Actors
See also: Actor definitions
- Consent Directives Management Service (CDMS)
- Consent Requestor
Flag Filtered Health Record Information
If Consenter decides to restrict certain information, he may have the option of deciding whether to permit PHI Repository to send a flag to an authorized party alerting the Consent Requestor that restricted information is available upon Consenter's approval or by "breaking the glass" in an emergency. "Breaking the glass" occurs when a provider who is authorized by organizational policy or jurisdictional law overrides a consent directive.
Basic Scenario
Authorize a specified type of provider to access all restricted health information, and to receive a flag that restricted information may be accessed, following Consenter's approval. A provider's use of restricted information is limited to read-only for a specified time period, after which the consent approval will expire.
Actors
See also: Actor definitions
- Consenter
- Consent Requestor
- Consent Directives Management Service (CDMS)
- PHI Repository
