This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Security Use Cases

From HL7Wiki
Jump to navigation Jump to search

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:

SecurityDAM.PNG

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:

TerminologyAnalysis.PNG

RoleandInformationConcepts.PNG

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

Pre-conditions

Basic Scenario

Actors

Information

The following information specifies the classes required to support authentication.

AutenticateUsers.PNG

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

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.

Actors

  • Domain A Information Requester - Radiologist, Nurse, 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:

AuthorizeUsers.PNG

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.

Actors

  • Domain A Information Requester - Radiologist, Nurse, 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:

EnforcePrivacy.PNG

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

Pre-conditions

Basic Scenario

Actors

Information

This use case does not require any domain specific information.

Enforce secure exchange of health records - Extended (addressed in Composite Privacy)

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.

Pre-conditions

Basic Scenario

Actors

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:

AutomatedPolicyResolution.PNG

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:

NegotiatePolicy.PNG

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.

Actors

Information

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

DisclosureAccounting.PNG