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.

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 use case

Basic Scenarios

1. RBAC Authorization Use Cases

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.

Basic Scenarios

• Mask information

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 (addressed in Composite Privacy)

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.

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:

Accounting of Disclosures (adressed PASS Audit)

Referred to PASS Audit based on October 6th, 2009 discussion See minutes.  

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

Information

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