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.

Please follow the format provided here to enter your requirements as use cases.

Authenticate users and systems

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

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

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

Enforce authenticity of legal healthcare documents

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

Enforce secure exchange of personal health records

This use cases 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."

Enable patient access to personal health records

A patient is intended to have access to their personal health records

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.

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.