Consent Directive Use Cases

Back to: CBCC Main Page > CBCC Use Cases

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

---

Privacy Consent Directive Use Cases

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 Records. Sarah Wattenberg, May 15th, 2008

Use Cases

Grant Control of the IIHI to Individuals

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

Basic Scenario

Based on the current regulation, the Jurisdictional Authority assigns the right to grant, withdraw, or withhold Privacy Consent to the collection, access, use, and disclosure of their 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. An individual's control may be 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.

In addition to providing limited control, the regulation specifies a default privacy policy. An individual (or their SDM) may customize their privacy preferences through Privacy Consent Directives, however the jurisdiction may also identify certain purposes of use, classifications of IIHI (e.g. health system planning, positive communicable disease test results), etc., for which Privacy Consent is deemed or not required -- effectively removing control over that IIHI from the individual in those situations.

Sample scenario: "Patient controls disclosure of Substance Abuse records"

Compliance with 43 CFR Part 2 requires the providers may not disclose/re-disclose substance abuse records without the explicit consent of clients/patients if the clients/patient are covered and receive treatment from public programs. Therefore the regulation grants control over the disclosure of substance abuse records to the clients.

Post-Condition

• The IIHI of every client/patient who has or may have IIHI accessed under the Jurisdictional Authority will be collected, accessed, used, and disclosed in accordance with the default privacy policy until an individual specifies their own specific Privacy Consent directives.
• The individual(consenter) may now grant, withdraw, or withhold consent for the collect, access, use, or disclosure of their IIHI, within the limitations established by the jurisdictional consent model.

Actors

See also: Actor definitions

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

Manage Privacy Consent Directives

The Consenter, an individual or Substitute Decision Maker (SDM) uses a Privacy Consent Directive management system (also referred to as a Privacy Consent Directives Management Service or CDMS) to manage the consent rules that are used, in conjunction with Jurisdictional defaults and imperatives, to control what, if any IIHI may be shared with healthcare providers, payers, and others that may have access to that IIHI (via the individual's PHR, an EHR, or any other system containing the individual's IIHI). The CDMS may be embedded in the PHR or in some other healthcare platform.

Pre-conditions

• The Consenter will have an access to a set of enumerated Privacy Consent options that are appropriate for that jurisdiction, either directly or via a "Privacy Consent Registrar" that has the authority to act as a proxy for the Consenter.
• Each option will have a jurisdictional default selection or value associated with it.
  • The above precondition rely on the ability of the web portal to access jurisdictional/organizational policies .
• An authenticated Consenter and Consumer identity have been established.
• The Privacy Consent directive options must be comprehensible by the Consenter (i.e. consent must be knowledgeable and informed).
• The Privacy Consent directive options must allow them to establish, withhold, or withdraw consent to collect, access, use, and disclose their IIHE (contained within the PHR, EHR, or other system) within the limitations established by legislation and/or jurisdictional/organizational policy.
• The individual has a trusted relationship with the organization(s) that is providing the CDMS capability.
• [appropriate only for the scenario below] the individual has established a PHR with a vendor and the Consenter (if different from the individual) has gone through a registration process with the PHR vendor in order to establish their identity and relationship to the individual.

Basic Scenario

• Consenter accesses a Privacy Consent Directives Management System via a publicly-accessible Web Portal.
• The Consenter is allowed to add, modify, or revoke Privacy Consent directive regarding the disclosure of the IIHI contained within his/her Personal Health Records.
• Verify that added or modified Privacy 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 Privacy Consent requester. The user must not be able to disable the directives derived from these default jurisdictional policies.
  • For example, specific client Privacy Consent policies are required for Alcohol and Substance Abuse information, as specified by 42 CFR, Part 2.

Actors

See also: Actor definitions

• Consenter
• Consent Registrar
• Consent Directives Management Service (CDMS)

Provider System requests Privacy Consent Directive for a Client prior to disclosure

Permission to collect, access, use, or disclose IIHI is determined by both a client's Privacy Consent Directive and the policies of the requester's organization and/or governing jurisdiction. Privacy policies may require that a client must authorize the disclosure on their information. Therefore it is often require that before a disclosure is allowed, the provider’s system must verify that the client authorized the disclosure and specified that authorization in a signed Privacy Consent directive. Therefore the existence of a signed Privacy Consent Directive is often a prerequisite to disclosure of certain IIHI– according to privacy regulation and organizational policies.

Pre-Conditions

• An authenticated Consumer identity has been established.
• The Consenter may be SDM acting on behalf of a Consumer.
• Access control must apply to requests for this data.

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 Consent Directive.
• Query the CDMS and retrieve the patient's Privacy Consent Directive.
• Reconcile patient's Privacy Consent Directive with requester's organizational and jurisdictional Privacy Consent rules.
  • If the patient's Privacy Consent Directive contradicts the organizational or jurisdictional policies, then requester must flag conflict and attempt to reconcile the differences.

Alternate Flow

• There are no Privacy 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 Privacy Consent Directive is retrieved, if available
• If the consumer's Privacy Consent Directive 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 IIHI

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

As written, this use case may violate recognized fair information practices and may be illegal in certain  jurisdictions.  At the very least, we must allow that a Client's Privacy Consent Directives may constitute some of the  most sensitive IIHI that they have and should not assume that any Provider would have access to them at  will. Patrick Pyette'

[Suggested change]A healthcare provider requests access to the patient's medical history, medication list, problems, allergy, etc. stored in the patient's IIHI. Prior to disclosing the requested IIHI, the Privacy Consent directives associated with that patient are evaluated, in conjunction with jurisdictional/organizational imperatives and default rules. Based on the evaluation, the entire request may be satisfied, partially satisfied, or completed denied. In cases where the request is partially satisfied or completed denied, an optional notification may be given to the provider to indicate that some or all of the information requested information has been withheld.

Basic Scenario

• Invoke use case: Request Privacy 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: Privacy Consent Directives Filter Health Record Information
  • Use the access control policies derived from the Privacy Consent Directive to filter the patient health 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.

Sample 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 Privacy Consent form as EHR-S of the DMO supports the manage Privacy Consent and authorization functionality as well as patient privacy and confidentiality (DC.1.3.3, IN.1.9). This Privacy 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 Privacy Consent, there may be DMO privacy/security policy that together with the patient specified Privacy 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

Sample 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 Privacy Consent form as the PHR-S supports the manage Privacy Consent and authorization functionality as well as patient privacy and confidentiality (S.1.3.3, IN.3.8). This Privacy 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 personal health records created during the visit and the Individually Identifiable Health Information (IIHI) contained in it according to the patient's Privacy Consent Directive.

Actors

See also: Actor definitions

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

Information System Masks Health Record Information based on Consumer Preferences

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

A provider's (functional) role is based on their relationship to the patient and their (structural) 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 IIHI 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).

Pre-conditions

• A patient through the Privacy Consent directive may be able to exclude or include specific types of users of IIHI 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 be provided in the form of structured or unstructured clinical documents.

Basic Scenario

Depending on whether the information is structured or unstructured, masking IIHI 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

Comments

• How does this use case differ from the Provider Requests IIHI ?

Information System Flags 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 Privacy Consent Directive 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 IIHI.

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 repository will provide the information allowed in the Privacy 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 Privacy Consent approval will expire.

Actors

See also: Actor definitions

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

Provider Amends IIHI based on Consumer's Privacy Consent Directive

If the consumer requested it, the provider will update the IIHI stored at a location specified by the patient at the end of a visit, encounter, procedure, etc. The provider agrees to update the patient's health records before the patient agrees to receive medical services. This use case describes a very specific implementation that assumes patients are taking greater control of their IIHI and may use Personal Health Record Systems (PHRS) to manage and share their information with providers.

This use case does not appear to introduce any new specific or significant Privacy Consent functionality. Ppyette

Pre-condition

• The provider's role and/or other attributes allows them to use (create, read, update, and delete) information in the individual's PHR from an organizational perspective.
• The individual's Privacy Consent preferences allow the provider to use information contained in the PHR that is clinically relevant.

Post-condition

• The provider creates additional IIHI as a result treating the patient.
• The consumer's IIHI store by a PHRS is automatically updated by the provider’s EHR system
• It must be possible to interpret the information added to the PHRS such as a system can correctly differentiate information that may be sensitive under jurisdictional, organizational, or under consumer's own Privacy Consent Directive preferences.

Actors

See also: Actor definitions

• Consenter
• Provider
• PHR Producer

Request Privacy Policies from Organization or Jurisdiction

In order to correctly manage personal health information, various EHRS will need to have access to computable privacy policies. Similarly, CDMSs will require access privacy policies to establish what type of control should be given to the owner of the information.

Pre-condition

• Consumers have trusted digital identities
• Jurisdictional Authorities (national, state, etc.) and other organizations issue privacy policies that apply to IIHI (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
• Privacy policies are available in electronic form and may be used EHRSs and CDMSs to determine how to manage IIHI in accordance to privacy policies and Privacy Consent directive.

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)

Provide electronic Privacy Consent Directive to a specific healthcare provider/service

In many situations it is necessary to provide a set of computable Privacy Consent directive along with IIHI in order to make sure that the receiving system and its user observe the privacy preferences of the client/patient.

Pre-condition

• An authenticated consenter identity has been established
• The consenter can also be a substitute decision maker (SDM)
• The options provided by the Privacy Consent Directive must be understandable to the consenter in such a way that it allows them to take control of their health records.

Basic Scenario

• The IIHI are sent to a provider along with Privacy Consent directive specifying how the patient data is intended to be managed by the receiving system and its users.
• Consenter shall be able to specify, update or revoke his/her Privacy Consent regarding the use and disclose of his IIHI.
• Privacy Consent directives may be translated into machine readable polices so that they can be used to govern access to patient data.

Sample Scenario: Substance Abuse

A patient receives substance abuse treatment at facility A. As the needs of the patient/client evolve, facility A refer the patient to facility B. Facility A request the permission of the patient to forward to facility B the relevant assessments and notes to ensure a smooth transfer of care. The patient signs a Privacy Consent upon which the information is transferred on condition that facility B may not forward this information and use it for predetermined length of time (e.g. 30 days, 60 days) after which the information must removed.

Sample Scenario: Remote Monitoring

Consenter (e.g. patient)registers with an organization e.g. Disease Management Organization (DMO) which uses remote patient monitoring service to collect health information from health measurement devices installed at patient’s home. During the time of registration, patient fills in an Privacy Consent Directive form on the application hosting device (e.g. home PC, mobile phone, or dedicated medical hub) at his home. The Privacy Consent Directive form consists of the options regarding who will be able to access, use, update and disclose different types of vital-signs that are collected by the remote patient monitoring system. The Privacy Consent Directive form is then sent from his/her application hosting device to the DMO service. The Privacy Consent Directive governs access to the patient data at the DMO and if patient data is sent to third parties (given that this is allowed, e.g. patient’s PHR), the Privacy Consent Directive will be included and sent together with the data. This might require reconciliation of different Privacy Consent Directives (which are given to different services).

Post-condition

• An electronic Privacy Consent Directive is available to the provider/service that becomes responsible for treating the patient along with relevant personal records.

Actors

• Consenter (consumer/patient)
• Consent Directive Management Service (CDMS) of a healthcare service (e.g. DMO)

See also: Actor definitions

Patient provides verbal Privacy Consent at point of service

This use case involves a provider who is the subject of a Privacy Consent directive that restricts disclosure of an individual's IIHI. The provider attempts to retrieve the individual's IIHI with the individual present and is denied. The provider receives an indication that there may be more information contained in the clinical repository, but that access to that information has been restricted by the individual's Privacy Consent directives.

The provider explains her reasons for wanting access to the information to the individual and after some discussion; the individual provides verbal Privacy Consent to have the IIHI disclosed to the provider.

Assumptions

• Records that are masked as a result of the evaluation of a Privacy Consent Directive will remain masked for other requests throughout the period the user is given access to the records.
• Override with Privacy Consent allows only the user who initiated the request to access the masked records unless the person consents to allowing others e.g. user delegates, to also view the masked records.
• The duration of permission to view the masked data will be determined by relevant legislated and policy requirements as well as jurisdictionally specified criteria. Within that duration, the same user may re-access the data multiple times.
• The override will not create a “temporary” Disclosure Directive, but will need to accompany each subsequent request for the previously masked information.
• Policies will need to be implemented regarding the copying and sharing of masked data that is disclosed for a limited time to a specific user or users.
• Policies and protocols will need to be developed and implemented identifying the obligations of the provider to ensure that knowledgeable, informed Privacy Consent is obtained without coercion or misrepresentation.

Pre-condition

• An individual has active Privacy Consent directives that prevent disclosure of IIHI to a Provider.
• The provider has unsuccessfully attempted to retrieve the individual's IIHI.
• The Provider has asked for and received the Patient's verbal Privacy Consent for disclosure of IIHI.

Basic Scenario

• The Provider requests access to a clinical profile of any PHI sent to the EHR in the past month for the patient.
• The system retrieves the requested information, but masks some of the information based on the evaluation of the patient’s Privacy Consent Directives. It displays a message indicating that some or all of the information has been masked as a result of the decision of a patient or their substitute decision maker. The system also provides an option for the provider to override the masking decision.
• The Provider asks the Patient if they’d be willing to identify the general nature of the information that has been masked in order to determine if any of it might be relevant to the current encounter.
• The Patient reveals the nature of the information as requested.
• The Provider asks for the Patient’s Privacy Consent to override the Privacy Consent Directive and remove the mask from the information. The Provider explains the potential risks and identifies how he will use the requested information.
• The Patient provides verbal Privacy Consent to the temporary disclosure of all of her personal health information to the Provider.
• The Provider selects the “Override” option.
• The system displays a screen with a selection of override reasons and an input area for ad-hoc text input. One of the override reasons is “Patient has provided express Privacy Consent for the temporary disclosure of personal health information”.
• The Provider selects the option described in the previous step and submits the request.
• The system ascertains that the Patient has previously established a keyword and responds with a message asking the Patient to enter their Keyword.
• The Provider asks the Patient to enter their Keyword into the system.
• The Patient enters the keyword. As she does so the screen displays asterisks for each character entered in order to hide her keyword from display.
• The Provider submits the request, which transmits a query to the EHR, with the override attached. The override indicator and keyword are retained by the EHR Viewer or Point of Service system in order to resend when necessary for the appropriate duration.
• The system responds by

• Notifying the provider of the success/failure of the Override request
• Displaying requested information
• Logging the override request in the Secure Audit Service log.

Post-condition

• The information that had been previously masked for that provider is temporarily unmasked.
• Once the access duration expires, the mask is reapplied for further access requests.

Actors

See also: Actor definitions

Provider Requests IIHI from Another Jurisdiction

This use case involves the transfer of IIHI from one jurisdiction to another, while respecting patient preferences where possible, while complying with privacy legislation and policy established in both jurisdictions.

 Specialization/scenario for #Provider Requests IIHI

Pre-condition

• Any necessary data-sharing agreements have been put into place between jurisdictions involved in the cross-border transfer of personal health information.

Basic Scenario

A patient from Ontario is visiting her aunt in Saskatoon for the first time. She develops throat pain and difficulty swallowing and decides to visit the local walk-in clinic in case she needs an antibiotic. The clinic has no records for the patient. She does not have a Personal Health Number (unique identifier) in Saskatchewan. She has no records in the Saskatchewan EHR. She advises the receptionist that the doctor should be able to “see all of her records in Ontario” using his own computer.

Post-condition

• An EHR record, Privacy Consent Directive, and Keyword exists for the patient in the Saskatchewan EHR
• An Ontario Privacy Consent Directive expressly allowing the transfer of the patient’s personal health information exists and is active until it expires.

Basic Flow

• The receptionist registers the patient and creates their Saskatchewan (SK) EHR
• The receptionist uses an EHR function to resolve the patient’s client IDs between Saskatchewan and Ontario.
• The provider requests access to the person’s records in the Ontario EHR
• The system forwards the request to the Ontario EHR.
• The Ontario EHR evaluates the Privacy Consent status for this patient and determines that no extra-jurisdictional Privacy Consent Directive exists that would expressly allow disclosure of personal health information. The Ontario EHR denies the request.
• The Saskatchewan EHR receives notification that access to the Ontario records is denied and displays that notice to the provider. There is no electronic option for the provider to override that decision.
• The provider gains the patient’s express Privacy Consent and places a call to the patient’s family practitioner or other Ontario Privacy Consent Registrar and asks that a Privacy Consent Directive be created on the patient’s behalf to allow the disclosure of her PHI outside of Ontario.
• The Privacy Consent Registrar verifies the patient and provider identity and the provider’s credentials and executes Manage Consent Directives on behalf of the patient, setting the Consent Directive to expire on the patient’s expected date of return to Ontario. The Consent Registrar confirms the creation of the new Consent Directive with the provider.
• The provider re-issues the request to access the person’s records in the Ontario EHR
• The system forwards the request to the Ontario EHR.
• The Ontario EHR evaluates the Privacy Consent status and determines that the disclosure is allowed. The Ontario EHR discloses the patient’s personal health information to the Saskatchewan EHR and records an audit event of the transaction.
• The Saskatchewan EHR receives the patient’s personal health information and displays it to the provider who treats the patient appropriately.
• The patient is concerned that her personal health information now in the Saskatchewan EHR might be used inappropriately and asks the provider to create a Privacy Consent Directive to mask her entire EHR and establish a Keyword to allow her to control access as required.

Actors

• Consenter
• Provider
• Home Jurisdiction Consent Registrar

See also: Actor definitions

Request for Pre-Fetch of DI Exams

Pre-condition

A regional or jurisdiction DI Repository maintains DI Exam results and reports to enable sharing between a number of healthcare delivery organizations.

 This appears to be a domain-specific scenario for #Flag Masked Health Record Information involving Diagnostic Imaging.

Basic Scenario

A referring physician schedules a DI exam for her patient at a facility associated with a regional DI Repository. The patient has placed a Privacy Consent directive on her IIHI restricting disclosure to only the referring physician. The scheduled exam is sent to the RIS system for filling. The RIS system notifies the PACS system and the DI Repository in order to pre-fetch any relevant prior exams.

Post-condition

The decision to transfer the relevant prior exams to a local DI cache will be based on data sharing agreements between the Repository and the requesting organization and the privacy policies in place at both locations. At least two options exist:

• The relevant prior's are transferred, but marked as masked. When the Radiologist attempts to open them, the PACS viewer interprets the masked attribute and enforces the directive unless the Radiologist determines that it is medically necessary and within his authority to override the patient's restriction (see Break Glass).
• The relevant prior's are not transferred, but a stub record is transferred to the local RIS/PACS system. Should the Radiologist have the authority and legally acceptable rationale to do so, he can override the Privacy Consent Directive (see Break Glass).

Actors

Consenter Referring Provider Radiologist See also: Actor definitions

Provider overrides Privacy Consent Directive (Break Glass)

A patient is brought to the local hospital ER by ambulance in an unconscious state. She appears jaundiced and minimally responsive. Identification found on her person is used to confirm her identity. While the ER physician is dealing with the patient’s immediate life threats, he requests the ER Charge Nurse to access and review the patient’s records in the EHR. The Charge Nurse logs onto the EHR and validates the patient’s identity. She attempts to access the patient’s PHI and receives a message that states “There are masked records that were not returned.”] The ER physician asks the nurse to submit an override request.

Assumptions

• Only authorized users whose assigned role(s) includes override privileges will be permitted to submit an emergency override request.
• Emergency override may be used to override all existing Privacy Consent Directives or only those specific to certain PHI that the user has a need to access e.g. to support clinical decision-making.
• The reason for emergency override will be provided by the authorized user requesting the override and will be logged in the EHR.
• Emergency override may allow only the authorized user who requested the override to view the masked/restricted data or may allow a group of authorized users e.g. in a facility or department to view the data.
• All the patient health data are recorded into the client health record (note that this is not always the case, since Privacy Consent directives can prevent the collection of some data into the client health record).
• The EHR-S knows there are masked records.
• The jurisdiction rules allow masked records to be revealed.

Pre-conditions

• An active Disclosure Directive exists that will restrict disclosure of personal health information to the provider.
• The provider has been authenticated in the EHR and is currently logged on.
• The provider has been granted the authority by the jurisdiction to override a Patient’s Privacy Consent Directives without their Privacy Consent under certain, defined circumstances.

Basic Scenario

• The nurse requests access the Patient’s PHI.
• The system retrieves the requested information, but masks some of the information based on the evaluation of the patient’s Disclosure Directives. It displays a message indicating that some or all of the information has been masked as a result of the decision of a patient or their substitute decision maker. The system also provides an option for the Nurse to override the masking decision.
• The ER nurse selects the Override option.
• The system displays a screen with a selection of override reasons and an input area for ad-hoc text input. One of the override reasons is “To prevent the risk of serious bodily harm” (or similar language provided by the jurisdiction). The screen also displays a message advising that:

• the override event will be logged in the EHR Secure Auditing Services including the reason for override
• a notice will be sent to the Chief Privacy Officer (CPO) of the hospital who will then notify and follow-up with the person whose directives are being overridden.

• The nurse selects the option described above, and enters some text in the text area indicating the patient’s condition and identifies the physician on who’s behalf she is submitting the request. The override request is submitted to the system.
• The system responds by:

• Creating and transmitting a record of the override to the Security Audit Service, which would likely initiate an alert to the appropriate Chief Privacy Officer for follow up.
• Notifying the nurse if the override was successful/unsuccessful
• Displaying with the requested information.

• At the end of the nurse’s session, she logs out. Her access privileges to view the previously unmasked data are terminated either at that point, at a later time as specified by jurisdictional emergency override rules (e.g. for 24 hours post-override).

Post-condition

• Other than the ER Nurse, requests for the patient’s PHI continue to be masked based on her active Privacy Consent Directive(s).
• Once the override period has ended, the ER Nurse’s no longer has the authority to access the patient’s PHI without re-executing the use case.

Actors

See also: Actor definitions

Accounting of Disclosures (adressed PASS Audit)

Referred to PASS Audit based on October 6th, 2009 discussion See minutes.
Specifying the need to account for disclosure is enforced by the Composite Privacy DAM by setting
Obligation.code = "AuditDisclosure".

Presently, informal surveys of AHIMA membership have revealed that in the 6 years that the HIPAA Accounting of Disclosures requirement has been in place only about half of our members have ever been asked to provide an Accounting of Disclosures to a patient. And, of the survey responder population; approximately half have only prepared an Accounting of Disclosures one time. All responders that report having prepared an Accounting of Disclosures concur that the process of preparing the Accounting of Disclosures is very time consuming, labor intensive, and expensive. The same group reports that in the majority of cases the patient is disappointed. Further research is needed to determine exactly why the patients are disappointed. Anecdotal justifications for patient disappointment point out that the patient does not want to know that their nurse or the lab tech has appropriately viewed their records X number of times; they want to catch individuals in the act of breaching their records. So, the current process is expensive and time consuming and the patient is not always happy with the findings. Finding a way to make Accounting of Disclosures compliance easier would be welcomed by all stakeholders.

Each disclosure event would be logged. The log entries would contain the date of the request, the requesting party identification, and the purpose. The log entry would match the information criteria in the consent directive. Meeting the HIPAA content requirements for a Accounting of Disclosures. It would be easier to capture, archive, and report the Accounting of Disclosures if it used the general-purpose audit mechanism but an enhanced audit entry.

Presently the current information that must be provided in an Accounting of Disclosures by HIPAA are:

• Date of disclosure
• Name of the person or organization that received the information
• Recipients address (if known)
• Brief description of the PHI disclosed
• Brief statement explaining the purpose of the disclosure.

Pre-conditions

A healthcare provider discloses information to another provider in accordance to privacy policies and patient Privacy Consent directives. The disclosure event is recorded in a log in a way similar to other types of events.

Basic Scenario

A patient requires an accounting of every disclosure of IIHI. The provider organization automatically generates a report based on the disclosure log entries that have been stored over time.