Consent Directive Use Cases

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 grant, withdraw, or withhold 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 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.

In addition to providing limited control, the regulation specifies a default privacy policy. An individual (or their SDM) may customize their privacy preferences through Consent Directives, however the jursiction may also identify certain purposes of use, classifications of IIHI (e.g. positive communicable disease test results), etc., which cannot be controlled by the individual(consenter).

Post-Condition

• The IIHI of every individual(consenter) 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 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 Consent Directives

The Consenter, an individual or Substitute Decision Maker (SDM) uses an eConsent management system (also referred to as a 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 consent options that are appropriate for that jurisdiction, either directly or via a "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 consent directive options must be comprehensible by the Consenter (i.e. consent must be knowledgeable and informed).
• The 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 Consent Directives Management System via a publicly-accessible Web Portal.
• The Consenter is allowed to add, modify, or revoke consent directive regarding the disclosure of the IIHI contained within 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 Registrar
• Consent Directives Management Service (CDMS)

Request eConsent for a Consumer

Permission to collect, access, use, or disclose 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.

As written, this use case may violate recognized fair information practices and may be illegal in certain jurisdictions. Ppyette

[Suggested change]A healthcare provider requests access to the patient's medical history, medication list, problems, allergy, etc. stored in the patient's personal health records. Prior to disclosing the requested IIHI, the 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 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.

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).

Masking is a term used to describe the process of restricting an access to or transfer of PHI. Typically, masking is applied at the data source and may be overridden, as permitted by law, by the accessing custodian (e.g. in emergency health situations). -- Canada Health Infoway EHR Privacy & Security Conceptual Architecture, 2005

Given the definition above, does the last sentence of the use case involve a different action or behavior as a result of applying the mask than the rest of the use case would imply?

Pre-conditions

• 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

Comments

• How does this use case differ from the Provider Requests Personal Health Records ?

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.

This use case does not appear to introduce any new specific or significant 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 consent preferences allow the provider to use information contained in the PHR that is clinically relevant.

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 personal 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

Actors

See also: Actor definitions

Patient provides verbal consent at point of service

This use case involves a provider who is the subject of a 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 consent directives.

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

Assumptions

• Records that are masked as a result of the evaluation of a Consent Directive will remain masked for other requests throughout the period the user is given access to the records.
• Override with 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 consent is obtained without coercion or misrepresentation.

Pre-condition

• An individual has active 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 consent for disclosure of IIHI.

Basic Scenario

• The Provider requests access to a clinical profile of any PHI sent to the EHRi 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 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 consent to override the 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 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 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 are temporarily unmasked.
• Once the access duration expires, the mask is reapplied for further access requests.

Actors

See also: Actor definitions

Extra-jurisdictional request for IIHI

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.

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 EHRi. 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, Consent Directive, and Keyword exists for the patient in the Saskatchewan EHRi
• An Ontario 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 EHRi
• The system forwards the request to the Ontario EHR.
• The Ontario EHR evaluates the consent status for this patient and determines that no extra-jurisdictional 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 consent and places a call to the patient’s family practitioner or other Ontario Consent Registrar and asks that a Consent Directive be created on the patient’s behalf to allow the disclosure of her PHI outside of Ontario.
• The 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 EHRi
• The system forwards the request to the Ontario EHR.
• The Ontario EHR evaluates the 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 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.

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 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 Consent Directive (see Break Glass).

Actors

Consenter Referring Provider Radiologist See also: Actor definitions

Provider overrides 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 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 EHRi.
• 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.

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 EHRi and is currently logged on.
• The provider has been granted the authority by the jurisdiction to override a Patient’s Consent Directives without their 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 EHRi 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 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