Security Use Cases

Back to Main Security WG >> Requirements Analysis

Security Use Cases

Introduction

• The following page is intended to allow all Security WG stakeholders to record their security use cases.
• Contributors are encouraged to follow the format provided here to enter additional requirements as use cases.
• The use cases listed here were used along with other standard reference to draft an overall information model:

Security Analysis Information Model (Draft for review)

The details of this model are available at on the Security WG SVN.

The terminology required to support the coded attributes in this model were similarly analyzed and described here:

Authenticate users and systems (out of scope)

This use case does not require healthcare-specific information. This use case does not apply to IIHI access. 
Decision approved during the October 27th 2009 Security Conference Call.

This use case is based on the IN.1.1 Entity Authentication function in EHR Functional Model - Infrastructure.

"Both users and applications are subject to authentication. The EHR-S must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include:

• username/ password
• digital certificate
• secure token
• biometrics."

Information

The following information specifies the classes required to support authentication.

Authorize users and systems

This use cases is based on "IN1.3 Authorize users and systems" function in EHR Functional Model - Infrastructure.

"Manage the sets of access control permissions granted to entities that use an EHR-S (EHR-S Users). Enable EHR-S security administrators to grant authorizations to users, for roles, and within contexts. A combination of these authorization categories may be applied to control access to EHR-S functions or data within an EHR-S, including at the application or the operating system level.

EHR-S Users are authorized to use the components of an EHR-S according to their identity, role, work-assignment, location and/or the patient’s present condition and the EHR-S User’s scope of practice within a legal jurisdiction.

• User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is a patient defined denial of access to all or part of a record to a particular party for privacy related reasons. Another user based authorization is for a tele-monitor device or robotic access to an EHR-S for prescribed directions and other input.
• Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device (tele-monitor or robotic); or a nurse, dietician, administrator, legal guardian, and auditor.
• Context-based Authorization is defined by ISO 10181-3 Technical Framework for Access Control Standard as security relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For example, an EHR-S might only allow supervising providers’ context authorization to attest to entries proposed by residents under their supervision. In addition to the ISO standard, context authorization for an EHR-S is extended to satisfy special circumstances such as, work assignment, patient consents and authorizations, or other healthcare-related factors. A context-based example is a patient-granted authorization to a specific third party for a limited period to view specific EHR records. Another example is a right granted for a limited period to view those, and only those, EHR records connected to a specific topic of investigation."

Pre-conditions

• Authenticate users and systems in Domains A and B.
• Both organizations (Domain A and B) have agreed on the functional roles that may be exchanged and the meaning of the permissions carried by the functional roles.

Basic Scenarios

1. RBAC Authorization Use Cases

Actors

• Domain A Information Requester - Radiologist, Nurse, Physician, Pharmacist, etc.
• Domain B Policy Enforcement Point (Verifier PEP)
• Domain B Policy Information Point (Verifier PIP)
• Domain B Policy Decision Point (Verifier PDP)
• Domain B Policy Administration Point (Verifier AP)
• Domain B Service Provider

Information

The following diagram shows the classes required to support RBAC:

Enforce privacy policy and consent directives using access control

This use cases is based on IN.1.3 "Entity Access Control" function in EHR Functional Model - Infrastructure.

"Verify and enforce access control to all EHR-S components, EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource.

Description: Entity Access Control is a fundamental function of an EHR-S. To ensure that access is controlled, an EHRS must perform authentication and authorization of users or applications for any operation that requires it and enforce the system and information access rules that have been defined."

Pre-conditions

• Organizational and Jurisdictional Privacy Policies provide specific rules regarding the use, disclosure, or update of Individually Identifiable Health Information (IIHI)
• Patients have the option to authorize the disclosure of their information (e.g. IIHI) that meets specific criteria.
• Two Domains exist [Domain A (Security Domain A) and Domain B (Security Domain B)] as separate entities each with a set of subjects, their information objects, and a common security policy (NIST Special Publication 800-33).
• A trust relationship exists between Domain A (Security Domain A) and Domain B (Security Domain B).
• Both organizations have agreed to use the Cross Enterprise Security and Privacy Authorization (XSPA) Security Assertion Markup Language (SAML) Profile.
• Both organizations have agreed on the functional roles that may be exchanged and the meaning of the permissions carried by the functional roles
• The patient has created a patient consent directive in Domain B to deny access to their medical record to all radiologists under normal treatment circumstances. The patient’s consent directive allows access to their medical record to radiologists under emergency treatment circumstances.

Basic Scenarios

Purpose of Use: Permit Patient Consent

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Radiologist
  • Functional Role: None
  • Obligations: None
  • Domain A Policy: Radiologist may make external requests for patient information at Domain B.
  • Domain B Policy: Grant radiologist access for treatment.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to deny access for radiologists for all purpose of use other than emergency access.
• Scenario:The radiologist in Domain A asserts the purpose of use as Emergency Treatment and then requests the patient’s medical record in Domain B.
• Result: The radiologist’s access to the patient’s medical record is granted by asserting the purpose of use as emergency treatmen

Purpose of Use: Deny Local Policy

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Physician
  • Functional Role: None
  • Obligations: None
  • Domain A Policy: Physicians may make external requests for patient information at Domain B.
  • Domain B Policy: Grant Physician access for treatment.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to grant access for purpose of use of emergency access. Requests made under all other purposes of use are denied.
• Scenario:While on an out-of-town business trip, the patient develops a slight fever and cough and determines they may have an infection and goes to the local urgent care center in Domain A. A healthcare provider sees the patient. During the discussion the patient states that they recently had a physical and that some blood work was done at Domain B. The provider believes these results might contain information valuable to this encounter. Since there is an existing trust relationship between Domain A and Domain B, the Domain A provider is able to assert the role of physician. The Domain B policy permits access to physicians for treatment purposes however the patient has generated a consent directive at Domain B that states that Domain A clinicians may access their information only in the event of an emergency. The provider will attempt to access the patient’s medical record at Domain B by performing a cross-enterprise lookup of the patient’s medical record.
• Result: The provider is denied access and cannot view the patient’s medical record based on patient consent directive stating that Domain A clinicians may access their information only in the event of an emergency

Purpose of Use: Deny Patient Consent Directive

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Radiologist
  • Functional Role: None
  • Obligations: None
  • Domain A Policy: Radiologist may make external requests for patient information at Domain B.
  • Domain B Policy: Grant Radiologist access for treatment.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to deny access for radiologists for all purpose of use.

• Scenario:During the patient’s visit at the urgent care center in Domain A, the patient mentions to the provider that the patient’s knee has been sore and swollen. The provider writes a radiology order for a standard series on the patient’s knee. The radiologist performs the procedure and prepares his findings. The radiologist is concerned over some abnormal findings and feels it necessary to review the patient’s clinical history. The radiologist attempts to access the patient’s medical record at Domain B.
• Result: The Radiologist is denied access to patient’s medical record per the patient consent directive to deny access for radiologists for all purpose of use.

Information Masking Scenario 1 - Patient Consent Directive Denies

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Physician
  • Functional Role: None
  • Obligations: Mask Medication Information
  • Domain A Policy: Physicians may make external requests for patient information at Domain B.
  • Domain B Policy: Grant Physician access for treatment.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to grant general access to patient’s medical records but, deny access to patient’s medication history to all but pharmacists.

• Scenario: While on an out-of-town business trip the patient experiences pain in their knee, from a pre-existing condition. The patient goes to the local urgent care center in Domain A. A healthcare provider sees the patient. During the patient’s visit at the urgent care center, the patient indicates to the provider that they have received treatment for the pain in their knee at Domain B. The provider attempts to view the patient’s medical record at Domain B to review the treatment given and determine what medications the patient has been given.
• Result: The physician is able to see the patient’s medical record at Domain B but is denied access to the patient’s medication history as a result of the patient consent directive at Domain B to deny access to the patient’s medication history to all but pharmacists.

Information Masking Scenario 2 - Patient Consent Directive Permits

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Pharmacist
  • Functional Role: None
  • Obligations: Mask Medication Information
  • Domain A Policy: Pharmacists may make external requests for patient information at Domain B.
  • Domain B Policy: Grant Pharmacists access for treatment.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to grant general access to patient’s medical records but, deny access to patient’s **medication history to all but pharmacists.
• Scenario: While on an out-of-town business trip the patient experiences pain in their knee, from a pre-existing condition. The patient goes to the local urgent care center in Domain A. A healthcare provider sees the patient. During the patient’s visit at the urgent care center, the provider prescribes pain medication for the patient’s sore knee, and sends the patient to local pharmacy to pick it up. The pharmacist attempts to check for drug-to-drug interactions by accessing the patient’s medication record at Domain B.
• Result: The pharmacist is able to see the patient’s medical record complete with the patient’s medication history as a result of the patient consent directive at Domain B to deny access to the patient’s medication history to all but pharmacists.

Functional Role Access Control: Permit

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Nurse
  • Functional Role: Nurse
  • Obligations: None
  • Domain A Policy: Nurse may make external requests for patient information at Domain B.
  • Domain B Policy: Grant Nurse access to patient record for treatment as per functional role and required permissions.

• Scenario: The patient, while on an out-of-town business trip, develops a slight fever and cough. The patient determines they may have an infection and goes to the local urgent care center. The Provider sees the patient. During the discussion the patient informs the provider of a recent physical and that some blood work was done at Domain B. The provider believes these results might contain information valuable to this encounter and asks the nurse to document the results of the blood work from Domain B. Since an existing trust relationship exists between Domain A and Domain B, the nurse will attempt to access the patient’s medical record at Domain B by performing a cross-enterprise lookup of the patient’s medical record.
• Result: The nurse has the required functional role and is granted access to view the patient’s medical record.

Functional Role Access Control: Deny

• Policy Environment
  • Model: Extranet
  • Purpose of Use: Treatment
  • Structural Role: Nurse
  • Functional Role: None
  • Obligations: None
  • Domain A Policy: Nurse may make external requests for patient information at Domain B.
  • Domain B Policy: Grant Nurse access to patient record for treatment as per functional role.

• Scenario: The patient, while on an out-of-town business trip, develops a slight fever and cough. The patient determines they may have an infection and goes to the local urgent care center. The Provider sees the patient. During the discussion the patient informs the provider of a recent physical and that some blood work was done at Domain B. The provider believes these results might contain information valuable to this encounter and asks the nurse to document the results of the blood work from Domain B. Since an existing trust relationship exists between Domain A and Domain B, the nurse will attempt to access the patient’s medical record at Domain B by performing a cross-enterprise lookup of the patient’s medical record.
• Result: The nurse does have the required functional role and is denied access to view the patient’s medical record.

Structured Role Access Control - Permit

Structural roles provide authorizations on objects at a global level without regard to internal details (ASTM E2595). Examples include authorization to participate in a session, connect authorization to a database, authorization to participate in an order workflow, or connection to a protected uniform resource locator (URL). A structural role applies to the business process task as a group. The use cases below will use structural role access permissions to health information based on ASTM E1986 as part of the authorization process.

• Policy Environment
  • Purpose of Use: Treatment
  • Domain A Policy: Licensed clinicians may make requests for patient information including information located at Domain B.
  • Domain B Policy: The structural role of “Physician” is required for cross-domain access to Domain B EHR data objects under the purpose of use of “Treatment”.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to grant unrestricted access to all health information to properly authorized clinicians for the purposes of use of “Treatment” (opt-in w/o restriction).
• Scenario: The patient, while on an out-of-town business trip, develops a slight fever and cough. The patient determines they may have an infection and goes to the local urgent care center. The Provider sees the patient. During the discussion the patient informs the provider of a recent physical and blood work done at Domain B. The provider believes these results might contain information valuable to this encounter. The provider, in the role of physician, performs a cross-enterprise lookup of the patient’s medical record, finds the patient, and then makes a request for the physical and blood work. Since the policy for these objects requires structural role of physician, the request is allowed and the Domain B Service Provider provides information in its response.
• Result: The provider is able to access and view the patient’s medical record.

Structured Role Access Control - Deny

• Policy Environment
  • Purpose of Use: Treatment
  • Domain A Policy: Physicians may make external requests for patient information including information located at Domain B.
  • Domain B Policy: The Physician role is allowed to make requests under the purpose of use of “Treatment” at Domain B for specific EHR data objects.
  • Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to grant unrestricted access to all health information to properly authorized clinicians for the purposes of use of “Treatment” (opt-in w/o restriction).

• Scenario: The patient, while on an out-of-town business trip, develops a slight fever and cough. The patient determines they may have an infection and goes to the local urgent care center. The Provider sees the patient. During the discussion the patient informs the provider of a recent physical and that some blood work was done at Domain B. The provider believes these results might contain information valuable to this encounter. The provider does not have access to a computer. The provider asks the nurse, to login to system and perform a cross-enterprise look up of the patient’s medical record.
• Result: The nurse is denied access to patient’s medical record at Domain B based on the policy at Domain B to grant access to physicians and to deny access to all others.

Structural Role Access Control – Patient Denies

• Policy Environment

Purpose of Use: Treatment Domain A Policy: Pharmacists may make external requests for patient information at Domain B. Domain B Policy: The structural role of licensed clinician is required to make requests under the purpose of use of “Treatment” at Domain B for specific EHR data objects. Domain B Privacy Policy: The Domain B privacy policy (per the patient consent directive) is to grant access to all structural roles except pharmacists for the purposes of use of “Treatment”.

• Scenario: The patient, while on an out-of-town business trip, develops a slight fever and cough. The patient determines they may have an infection and goes to the local urgent care center. The Provider sees the patient. During the discussion the patient informs the provider of a recent physical and that some blood work was done at Domain B. The provider believes these results might contain information valuable to this encounter. The provider attempts to access the patient’s medical record at Domain B by performing a cross-enterprise lookup of patient’s medical record. The provider notes a change needs to be made on one of the patient’s prescriptions, notifies the onsite pharmacy of the change, and sends the patient to pick it up. The Pharmacists attempts to check for drug-to-drug interactions by accessing the patient’s record at Domain B.
• Result: The pharmacist’s access to the patient’s medical record is denied based on a patient consent directive denying access to Domain B information by Domain A pharmacists under purpose of use of Treatment.

Note: Even though the patient has given consent for the pharmacist at Domain A to make the request, the pre-established Domain B policy dominates under the principal that each domain is responsible for enforcing it’s own policies. In this case, the patient will need to modify the Domain B consent directive. Note: The result does not preclude Domain A from issuing the prescription; it is only that the drug interaction check will not be possible. Note: The physician can still access the patient’s Domain B medications. Assuming the patient allows, the Domain B pharmacist can then access the medications from the Domain B repository.

Actors

• Domain A Information Requester - Radiologist, Nurse, Physician, Pharmacist, etc.
• Domain B Policy Enforcement Point (Verifier PEP)
• Domain B Policy Information Point (Verifier PIP)
• Domain B Policy Decision Point (Verifier PDP)
• Domain B Policy Administration Point (Verifier AP)
• Domain B Service Provider

Information

The following diagrams summarizes the classes required to support this use case:

Enforce authenticity of legal healthcare documents (out of scope for Security DAM 1.0)

This use case was deemed out of scope based on Oct. 20th discussion - See minutes.  

This use cases is based on IN.1.5 "Non-Repudiation" function in EHR Functional Model - Infrastructure.

"Limit an EHR-S user’s ability to deny (repudiate) the origination, receipt, or authorization of a data exchange by that user.

Description: An EHR-S allows data entry and data access to a patient's electronic health record and it can be a sender or receiver of healthcare information. Non repudiation guarantees that the source of the data record can not later deny that it is the source; that the sender or receiver of a message cannot later deny having sent or received the message. For example, non-repudiation may be achieved through the use of a: - Digital signature, which serves as a unique identifier for an individual (much like a written signature on a paper document). - Confirmation service, which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent and/or received) and - Timestamp, which proves that a document existed at a certain date and time. Date and Time stamping implies the ability to indicate the time zone where it was recorded (time zones are described in ISO 8601 Standard Time Reference). "

Information

This use case does not require any domain specific information.

Enforce secure exchange of health records - Extended (out of scope)

The basic secure exchange use case relies on generic security solutions.

This use case is based on IN.1.6 "Secure Data Exchange" function in EHR Functional Model - Infrastructure.

"Secure all modes of EHR data exchange.

Description: Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation as well as both destination and source authentication when necessary. For example, it may be necessary to encrypt data sent to remote or external destinations. A secure data exchange requires that there is an overall coordination regarding the information that is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within an EHR-S or external to an EHR-S."

Additional: Consent Directives may be exchanged along with the information. For example if information is exchanged as a result of a transfer of care or a request from an agency to a healthcare provider. --

This is already covered in Composite Privacy DAM using query and notification for consent directives. 
The decision to exclude this use case was approved during the October 27th 2009 Security Conference Call.

Information

This use case does not require any domain specific information.

Automated Policy Resolution

This use case illustrates an example of how an automated system would use structured negotiation for resolving and enforcing privacy policies and rules under normal treatment conditions. An important facet of this use case is the system’s ability to change a user’s access privileges automatically based on a series of pre-set conditions.

Pre-conditions

Jurisdictional and organizational authority has developed privacy policies that cover patient information at Sunnybrook Hospital. These policies comply with all applicable laws and mandates of the hospital and also allow patients to register their privacy preferences through consent directives. Patient preferences fit within the guidelines provided by the hospital policies so as not to conflict with these policies.

Hospital policy allows patients to indicate which individuals, who may normally have access to their records, they wish to block from accessing their medical records.

• Hospital authorities have implemented privacy policies that comply with jurisdictional and organizational mandates for patient privacy.
• Hospital authorities have provided the means for patients to register their own personal preferences for privacy.

Basic Scenario

Sam Jones has been provided with a form to register his privacy preferences. He indicates that he does not want Dr. Bob to access his records. Sunnybrook Hospital has a rule that provides access to all patient records to treating physicians. Mr. Jones is alerted to this rule when he enters his preferences and agrees to it. Dr. Bob is not Mr. Jones’ primary physician and so is not granted access to Mr. Jones’ record on a regular basis.

During the course of normal treatment it is necessary for Dr. Bob to access Mr. Jones’ medical record. Dr. Bob indicates to the system that he is in the role of Mr. Jones’ treating physician. The system grants Dr. Bob access to Mr. Jones’ medical record automatically without requiring an override condition.

Post-Conditions

All jurisdictional and organizational policies are complied with and no consent directive has been changed without the stakeholders’ previous consent. At such a time as Dr. Bob is no longer Mr. Jones’ treating physician, he will no longer have access to Mr. Jones’ medical record.

Information

The following diagrams summarizes the classes required to support this use case:

Negotiate Privacy Policy

This use case describes a how a manual process, unstructured negotiation, can be used to resolve conflicts between jurisdictional and organizational privacy policies and the patient’s preferences under normal treatment conditions. This use case covers the consent to access information and not necessarily the consent for treatment.

The unstructured negotiation process is used at decision points in the system where decision options are either not known or require further elaboration before the decision can be made.

Pre-conditions

Jurisdictional and organizational authority has developed privacy policies that cover patient information at Sunnybrook Hospital. These policies comply with all applicable laws and mandates of the hospital and also allow patients to register their privacy preferences through consent directives. Not all patient preferences fit within the guidelines provided by the hospital policies creating conflict with these policies. These situations will require unstructured negotiation in order to resolve the conflict.

Hospital policy allows patients to indicate which individuals, who may normally have access to their records, that they wish to block from accessing their medical records.

• Hospital authorities have implemented privacy policies that comply with jurisdictional and organizational mandates for patient privacy.
• Hospital authorities have provided the means for patients to register their own personal preferences for privacy.

Basic Scenario

Sam Jones has been provided with a form to register his privacy preferences. He indicates that he does not want Dr. Bob to access his records. Sunnybrook Hospital has a rule that provides access to all patient records to treating physicians. Mr. Jones is alerted to this rule when he enters his preferences. Although Dr. Bob is not Mr. Jones’ primary physician, there may be occasions when Dr. Bob would be granted access to Mr. Jones’ medical record.

Mr. Jones does not agree to the policy and does not sign the consent form. Because the hospital cannot provide service to Mr. Jones without a signed consent form, a privacy officer at the hospital is alerted to this and contacts Mr. Jones.

The privacy officer explains the situation to Mr. Jones and explains the different options that are available and their consequences. Mr. Jones either selects an option that he is comfortable with or suggests an alternative option. The privacy officer then complies with Mr. Jones’ decision or evaluates the alternative option. This process continues until a mutually satisfactory option is reached.

Post-Conditions

All jurisdictional policies are complied with and neither organizational policy nor consent directive has been changed without the stakeholders’ knowledge. One possible resolution to the conflict could be that the hospital and patient have not come to an agreement and the patient has decided to seek healthcare services at another hospital.

Information

The following diagrams summarizes the classes required to support this use case: