Difference between revisions of "Security and Privacy Ontology Use Cases"
(New page: ==Use Case: Access Control Based on Category of Action== This use case illustrates an example of how an EHR system would control access to an object in a medical record based on the type o...) |
m |
||
(13 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | == | + | Back to [[Security and Privacy Ontology]] Main Page |
+ | |||
+ | =='''Access Control Based on Category of Action'''== | ||
This use case illustrates an example of how an EHR system would control access to an object in a medical record based on the type of action to be performed on it. A number of access control actions are attempted on a medical record object for which the system grants or denies access privileges. | This use case illustrates an example of how an EHR system would control access to an object in a medical record based on the type of action to be performed on it. A number of access control actions are attempted on a medical record object for which the system grants or denies access privileges. | ||
===Actors=== | ===Actors=== | ||
Line 6: | Line 8: | ||
<li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
<li>Shady Grove Hospital’s security policy – the policy that determines how objects are accessed in the hospital’s EHR.</li> | <li>Shady Grove Hospital’s security policy – the policy that determines how objects are accessed in the hospital’s EHR.</li> | ||
− | <li>Sam Jones – Patient at Shady Grove Hospital</li> | + | <li>Sam Jones – Patient at Shady Grove Hospital.</li> |
<li>Dr. Bob – Physician at Shady Grove Hospital, primary physician for Sam Jones.</li> | <li>Dr. Bob – Physician at Shady Grove Hospital, primary physician for Sam Jones.</li> | ||
<li>Dr. Dan – Physician at Shady Grove Hospital, who also treats Sam Jones.</li> | <li>Dr. Dan – Physician at Shady Grove Hospital, who also treats Sam Jones.</li> | ||
Line 25: | Line 27: | ||
===Analysis=== | ===Analysis=== | ||
Shady Grove Hospital’s security policy denies a physician the ability to update a progress note if he or she is not the author of that progress note without additional authority. | Shady Grove Hospital’s security policy denies a physician the ability to update a progress note if he or she is not the author of that progress note without additional authority. | ||
+ | |||
+ | |||
+ | =='''Access Control Based on Category of Object'''== | ||
+ | This use case illustrates how an EHR system would control access to an object in a medical record based on the type of object it is. A user attempts to access a number of objects in a medical record for which the system grants or denies access privileges based on the category of object. | ||
+ | ===Actors=== | ||
+ | <ul><li>Shady Grove Hospital – Provider Organization in which the use case takes place.</li> | ||
+ | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
+ | <li>Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.</li> | ||
+ | <li>Sam Jones – Patient at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Bob – Physician at Shady Grove Hospital, primary physician for Sam Jones.</li> | ||
+ | <li>Dr. Dan – Physician at Shady Grove Hospital, who also treats Sam Jones.</li> | ||
+ | </ul> | ||
+ | |||
+ | ===Precondition=== | ||
+ | <p>Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. The objects have been categorized hierarchically so that if a user has been granted access to a category of objects, he or she is granted access to all objects in that category. For example, an initial assessment is categorized as an assessment which in turn is categorized as a clinical report, while payment history is categorized as an administrative report.</p> | ||
+ | <p>The security policy grants the primary physician access to create and read a patient’s assessment. The system does not explicitly grant the primary physician the privilege to access a patient’s initial assessment, however, as initial assessment is categorized as an assessment, access to the initial assessment would be inherited from assessment. Dr. Bob has previously completed assessments of Mr. Jones’ health.</p> | ||
+ | ===Basic Scenario=== | ||
+ | <p>Dr. Bob interviews Mr. Jones upon his admission into the hospital. Dr. Bob creates an initial assessment on Mr. Jones’ health after the interview. </p> | ||
+ | ===Post-Condition=== | ||
+ | An initial assessment on Mr. Jones’ health has been entered into the system. | ||
+ | ===Analysis=== | ||
+ | Shady Grove Hospital’s security policy grants the primary physician access to create a patient’s assessment. The initial assessment is categorized by the system as an assessment thus granting the primary physician the privilege to create an initial assessment on the patient. | ||
+ | ===Alternative Scenario=== | ||
+ | Dr. Bob interviews Mr. Jones upon his admission into the hospital. Dr. Bob reviews Mr. Jones’ medical history for relevant clinical information. Dr. Bob then attempts to access Mr. Jones’ payment history with Shady Grove Hospital and is denied access. | ||
+ | ===Post-Condition=== | ||
+ | Dr. Bob can read Mr. Jones’ medical history but he cannot access Mr. Jones’ payment history. | ||
+ | ===Analysis=== | ||
+ | Shady Grove Hospital’s security policy allows the primary physician the ability to access clinical reports. Medical history is categorized as a clinical report and thus Dr. Bob can access it. The security policy does not allow a primary physician access to administrative reports without additional authorization. Since a payment history is categorized under administrative reports, Dr. Bob is denied access to it. | ||
+ | |||
+ | |||
+ | =='''Access Control Based on Category of Structural Role'''== | ||
+ | This use case illustrates how an EHR system would control access to an object in a medical record based on the structural role assigned to the user requesting access. In this case a structural role reflects a human or organizational category. A user, with an assigned structural role, attempts to access a number of objects in a medical record for which the system grants or denies access privileges based on the category of the user’s structural role. | ||
+ | ===Actors=== | ||
+ | <ul><li>Shady Grove Hospital – Provider Organization in which the use case takes place.</li> | ||
+ | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
+ | <li>Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.</li> | ||
+ | <li>Sam Jones – Subject of care - Patient at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Bob – regulated health professional – general practitioner at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Dan – regulated health professional - dermatologist at Shady Grove Hospital.</li> | ||
+ | <li>Mark Clark – admissions clerk at Shady Grove Hospital.</li> | ||
+ | </ul> | ||
+ | ===Precondition=== | ||
+ | Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. Certain structural roles are assigned permission for certain types of access regardless of which user has been assigned to the structural role. Structural roles have been categorized hierarchically so that sub-roles of a structural role class are granted the same permissions as the parent roles. For example, a dermatologist is categorized as a physician who in turn is categorized as a regulated health professional. | ||
+ | The security policy grants the structural role of physician the ability to read a patient’s progress note. The security policy does not specify the medical specialty of the physician role. | ||
+ | ===Basic Scenario=== | ||
+ | Dr. Bob examines Mr. Jones as part of an episode of care. Dr. Bob opens Mr. Jones’ medical record and reads his medical history. Dr. Bob’s initial assessment leads him to refer Mr. Jones to Dr. Dan. Dr. Dan opens Mr. Jones’ medical record and reads his medical history. | ||
+ | ===Post-Condition=== | ||
+ | Dr. Dan can access Mr. Jones’ medical records and proceeds to treat Mr. Jones for his condition. | ||
+ | ===Analysis=== | ||
+ | Both Dr. Bob and Dr. Dan have been assigned the structural role of physician at Shady Grove Hospital. As such, they have been given permission to read the medical records of all patients in the hospital. This is the default policy which may be constrained if other conditions, such as a patient’s consent directive, are present. Dr. Bob and Dr. Dan have different medical specialties, sub-roles of the physician role. Since the security policy grants the access permission to the structural role of physician, all sub-roles, i.e. medical specialties classified under physician, will receive the same access permissions. | ||
+ | ===Alternative Scenario=== | ||
+ | Dr. Bob examines Mr. Jones as part of an episode of care. Dr. Bob opens Mr. Jones’ medical record and reads his medical history. Mark Clark attempts to open Mr. Jones’ medical record but is denied access. | ||
+ | ===Post-Condition=== | ||
+ | Mr. Jones’ medical record is protected from unauthorized access. | ||
+ | ===Analysis=== | ||
+ | Mark Clark is assigned the structural role of admissions clerk at Shady Grove. Admissions clerk is not categorized as a physician role at Shady Grove and is not granted the same access permissions as physician and the security policy doesn’t explicitly grant these permissions to the admissions clerk role. Therefore, without additional authority, Mark Clark cannot access Mr. Jones’ medical record. | ||
+ | |||
+ | |||
+ | =='''Access Control Based on Category of Functional Role'''== | ||
+ | This use case illustrates how an EHR system would control access to an object in a medical record based on the functional role assigned to the user requesting access. Functional roles are bound to the performance of actions carried out by an entity. A user, with an assigned functional role, attempts to access a number of objects in a medical record for which the system grants or denies access privileges based on the category of user’s functional role. | ||
+ | ===Actors=== | ||
+ | <ul><li>Shady Grove Hospital – Provider Organization in which the use case takes place.</li> | ||
+ | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
+ | <li>Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.</li> | ||
+ | <li>Sam Jones – Subject of care - Patient at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Bob – Privileged healthcare professional - Physician at Shady Grove Hospital, assigned to Sam Jones by Shady Grove to fill this functional role.</li> | ||
+ | <li>Dr. Sue – Healthcare professional - Physician at Shady Grove Hospital, privileged healthcare professional to Sam Jones when Dr. Bob is not available.</li> | ||
+ | <li>Dr. Dan – Health-related professional - Physician at Shady Grove Hospital, indirectly involved with the treatment of Sam Jones.</li></ul> | ||
+ | ===Precondition=== | ||
+ | Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. Certain functional roles are assigned permissions for certain types of access regardless of which user has been assigned to the functional role. Functional roles have been categorized hierarchically so that sub-roles of a functional role are granted the same permissions as the parent roles. For example, an alternate privileged healthcare professional, under certain conditions, is categorized as a privileged healthcare professional who in turn is categorized as a healthcare professional. | ||
+ | The security policy grants the functional role of privileged healthcare professional the ability to access to all of a patient’s medical record, including sensitive medical records, while that healthcare professional is assigned to the patient. The period of the assignment is limited to the privileged access time interval. A sub-role of the privileged healthcare professional is the alternate privileged healthcare professional; a healthcare professional that fills the role of the privileged healthcare professional during periods when the primary is unavailable. | ||
+ | Dr. Bob has taken a week off to go on vacation. | ||
+ | ===Basic Scenario=== | ||
+ | Mr. Jones enters the hospital with a medical complaint. Dr. Sue can access all of Mr. Jones’ medical record, including those which indicate Mr. Jones’ alcohol abuse condition. | ||
+ | ===Post-Condition=== | ||
+ | Dr. Sue has complete access to all of Mr. Jones’ medical record, including sensitive medical information, until Dr. Bob returns from vacation after which she has only limited access to Mr. Jones’ medical record without additional authorization. | ||
+ | ===Analysis=== | ||
+ | The time interval in which Dr. Sue is assigned the functional role of alternate privileged healthcare professional begins when Dr. Bob departs on vacation and ends when Dr. Bob returns. During this time period, Dr. Sue is the alternate privileged healthcare professional, a sub-role of the privileged healthcare professional, and is granted all the access privileges of the privileged healthcare professional. | ||
+ | ===Alternative Scenario=== | ||
+ | Mr. Jones enters the hospital with a medical complaint. Dr. Dan attempts to access Mr. Jones’ medical record but is denied access to objects within Mr. Jones’ record that are considered sensitive. | ||
+ | ===Post-Condition=== | ||
+ | The sensitive information within Mr. Jones’ medical record is kept confidential except to privileged healthcare professionals. | ||
+ | ===Analysis=== | ||
+ | Dr. Dan’s functional role of health-related professional is not a sub-role of privileged healthcare professional and thus he is not granted access to all of Mr. Jones’ medical record without additional authorization. | ||
+ | |||
+ | |||
+ | =='''Access Control Based on Multiple Role Values'''== | ||
+ | This use case illustrates how an EHR system would control access to an object in a medical record based on a user being assigned more than one role attribute value. A user, with one or more assigned roles, attempts to access an object in a medical record for which the system grants or denies access privileges based on the combination of the user’s roles. | ||
+ | ===Actors=== | ||
+ | <ul><li>Shady Grove Hospital – Provider Organization in which the use case takes place.</li> | ||
+ | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
+ | <li>Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.</li> | ||
+ | <li>Sam Jones – Subject of care - Patient at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Bob –Physician on the staff at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Dan – Physician with access privileges at Shady Grove Hospital but not on the staff.</li></ul> | ||
+ | |||
+ | ===Precondition=== | ||
+ | <p>Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. Certain types of access require that a user be assigned to more than one role, i.e. that access is not assigned to a single role but a combination of roles.</p> | ||
+ | <p>The security policy grants the combination role of staff physician the ability to update a patient’s care plan.</p> | ||
+ | ===Basic Scenario=== | ||
+ | Mr. Jones is a patient of Dr. Bob’s and has not been responding to his treatment. Dr. Bob decides to change Mr. Jones’ care plan and updates the plan in his medical record. | ||
+ | ===Post-Condition=== | ||
+ | Mr. Jones’ care plan is updated and his treatment is changed. | ||
+ | ===Analysis=== | ||
+ | Shady Grove’s security policy requires that in order to update a patient’s care plan a user must have the roles of both physician and of member of the hospital staff. Since Dr. Bob has been assigned both roles, he is able to change Mr. Jones’s care plan. | ||
+ | ===Alternative Scenario=== | ||
+ | Dr. Dan has treated Mr. Jones at a clinic and has noted that Mr. Jones has not been responding to treatment. Dr. Dan decides to change Mr. Jones’ care plan at Shady Grove hospital. He has access privileges at Shady Grove and can read Mr. Jones’ care plan. He attempts to change the care plan to reflect the desired changes but is denied the ability to make the changes. | ||
+ | ===Post-Condition=== | ||
+ | Mr. Jones’s care plan is not updated and his treatment remains unchanged. | ||
+ | ===Analysis=== | ||
+ | Dr. Dan is a physician at a clinic associated with Shady Grove hospital but is not on the staff at Shady Grove. Therefore he does not have the combination of both roles required to update a patient’s care plan at Shady Grove and is denied permission to do so. | ||
+ | |||
+ | |||
+ | =='''Enable Design of Access Control System'''== | ||
+ | This use case illustrates the activity of an EHR system security administrator in establishing access control policy rules. The security administrator converts the broad principles laid out by the hospital’s security policies into a set of well defined rules. These rules can then be used to configure the automated decision function (ADF) that can be used by the access control system (ACS) to make decisions on access requests at run time. The development of these rules is a manual engineering design activity that precedes other automated access control activities. Organizing vocabularies into structured hierarchies supports this activity by reducing ambiguity and time spent searching for terms. | ||
+ | ===Actors=== | ||
+ | <ul><li>Shady Grove Hospital – Provider Organization in which the use case takes place.</li> | ||
+ | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
+ | <li>Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.</li> | ||
+ | <li>Joe Smith – EHR system security administrator at Shady Grove Hospital.</li></ul> | ||
+ | |||
+ | ===Precondition=== | ||
+ | <p>Shady Grove hospital has developed a system to control access to information on their EHR system based on their security policies. Before the system is operational, Joe Smith, the system security administrator, must set up the access control policy rules in accordance with Shady Grove’s security policies. Part of this process is to allocate attribute values to the targets; the objects in the EHR-S. This will later be used by the automated decision function (ADF) to determine which requestors can access which targets when the system is operational. The operational use case is presented as Facilitate an Automated Decision Function.</p> | ||
+ | <p>To reduce the ambiguity in allocating attribute values to the targets, the objects have been categorized so that they can be more easily identified by Mr. Smith when making his designations.</p> | ||
+ | ===Basic Scenario=== | ||
+ | <p>Shady Grove’s security policy states that the role of physician can read all clinical objects on the hospital’s EHR-S. The list of objects that exist on Shady Grove’s EHR-S have been categorized into clinical and administrative types. Joe Smith designates a specific clinical object with the attribute name of Encounter Data in the EHR-S.</p> | ||
+ | ===Post-Condition=== | ||
+ | All objects with the attribute name of Encounter Data are categorized as clinical; the ADF will recognize those objects as clinical objects and apply the appropriate access controls to them. | ||
+ | ===Analysis=== | ||
+ | As a security administrator, Mr. Smith may not understand the purpose and differences between objects in the EHR. By providing an ontology which categorizes objects such that the categories correspond with Shady Grove’s security policy, there is no ambiguity in allocating the appropriate access control information to the specific object type. If an object is not correctly categorized, or is not categorized at all, this manual step will provide the opportunity to evaluate the attribute value of the object before it is entered in the access control system. | ||
+ | ===Alternative Scenario=== | ||
+ | Shady Grove’s security policy states that the role of physician can read all clinical objects on the hospital’s EHR-S. The list of objects that exist on Shady Grove’s EHR-S have been categorized alphabetically by name. Joe Smith locates a Blood Bank Order object under B and categorizes it as a type of clinical object in the ACS. Mr. Smith then locates Radiology Order object under R and categorizes it as a type of clinical object in the ACS. | ||
+ | ===Post-Condition=== | ||
+ | All objects with the attribute names of Blood Bank Order and Radiology Order in the EHR-S are categorized as clinical objects: the ADF will recognize those objects as clinical objects and apply the appropriate access controls to them. | ||
+ | ===Analysis=== | ||
+ | As the list of objects in the EHR-S grows, it may become unmanageable for browsing. Organizing objects alphabetically provides a more manageable list. The categories may not be relevant for security purposes, however, they are intended to enable the manual access control policy rules configuration activity but are not used in the actual rules that configure the ADF. If an object is not correctly categorized, or is not categorized at all, this may not be detrimental to the subsequent automated process since the categories are not intended to be used in that process. | ||
+ | ===Reference=== | ||
+ | ISO/IEC 10181-3 | ||
+ | |||
+ | |||
+ | =='''Facilitate an Automated Decision Function'''== | ||
+ | This use case illustrates the activity of an automated decision function (ADF) of an access control system (ACS) in making access control decisions. The ADF is provided with information on a request initiator, a requested target and an access request. The ADF has been configured with access control policy rules by the ADF’s authority; Shady Grove Hospital. The ADF is also provided with contextual information such as time of day and location of the request initiator. From this information the ADF is capable of automatically deciding whether to grant or deny an initiator’s request to access a target. Organizing vocabularies into structured hierarchies supports this activity by creating formal associations between terms. | ||
+ | ===Actors=== | ||
+ | <ul><li>Shady Grove Hospital – Provider Organization and ACS authority in which the use case takes place.</li> | ||
+ | <li>Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.</li> | ||
+ | <li>Shady Grove Hospital’s security policy – the policy that determines how the ACS is configured in the hospital’s EHR.</li> | ||
+ | <li>Sam Jones – Subject of care - Patient at Shady Grove Hospital.</li> | ||
+ | <li>Dr. Bob – physician at Shady Grove Hospital.</li> | ||
+ | <li>Joe Smith – EHR system security administrator at Shady Grove Hospital.</li></ul> | ||
+ | |||
+ | ===Precondition=== | ||
+ | Shady Grove hospital has developed a system to control access to information on their EHR system based on their security policies. Joe Smith, the system security administrator, has configured system targets (objects) and initiators (roles) with appropriate information and the ADF with rules so it can automatically make access control decisions when the system is operational. This use case is presented as Enable Design of Access Control System. | ||
+ | Shady Grove’s security policy states that the role of physician can read all clinical objects on the hospital’s EHR-S. Shady Grove’s security policy does not grant the role of physician the ability to read Billing Attachments. | ||
+ | ===Basic Scenario=== | ||
+ | Dr. Bob makes a request on the EHR-S to read Sam Jones’ Encounter Data from his last visit. The ADF evaluates all information required to make the decision against the policy rules and grants Dr. Bob permission to read Mr. Jones’ record. | ||
+ | ===Post-Condition=== | ||
+ | Dr. Bob has accessed Mr. Jones’s Encounter Data and can read it. Security policies at Shady Grove have been complied with. | ||
+ | ===Analysis=== | ||
+ | Dr. Bob had been assigned the structural role of physician at Shady Grove which allows him to read all clinical objects. Mr. Jones’ Encounter Data has been designated a clinical object. Dr. Bob is initially requesting read access to the Encounter Data, an operation permitted by the policy rules. The access control information on the initiator (Dr. Bob), the target (Encounter Data) and the access request (read) conform with an access control rule and therefore this request is permitted by the ADF. This decision has been reached automatically without human intervention. | ||
+ | ===Alternative Scenario=== | ||
+ | Dr. Bob makes a request on the EHR-S to read Sam Jones’ Billing Attachment from his last visit. The ADF evaluates all information required to make the decision against the policy rules and denies Dr. Bob permission to read Mr. Jones’ Billing Attachment. | ||
+ | ===Post-Condition=== | ||
+ | Dr. Bob cannot access Mr. Jones’s Billing Attachment without breaking a security policies at Shady Grove. The confidentiality of Mr. Jones’ billing information has been preserved. | ||
+ | ===Analysis=== | ||
+ | Dr. Bob’s structural role of physician does not allow him to read allow information within a patient’s record, in this case the Billing Attachment. The access control information on the initiator (Dr. Bob), the target (Billing Attachment) and the access request (read) did not conform with the access control rules and therefore this request was denied by the ADF. This decision was reached automatically without human intervention. | ||
+ | ===Reference=== | ||
+ | ISO/IEC 10181-3 |
Latest revision as of 20:36, 10 May 2010
Back to Security and Privacy Ontology Main Page
Contents
- 1 Access Control Based on Category of Action
- 2 Access Control Based on Category of Object
- 3 Access Control Based on Category of Structural Role
- 4 Access Control Based on Category of Functional Role
- 5 Access Control Based on Multiple Role Values
- 6 Enable Design of Access Control System
- 7 Facilitate an Automated Decision Function
Access Control Based on Category of Action
This use case illustrates an example of how an EHR system would control access to an object in a medical record based on the type of action to be performed on it. A number of access control actions are attempted on a medical record object for which the system grants or denies access privileges.
Actors
- Shady Grove Hospital – Provider Organization in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how objects are accessed in the hospital’s EHR.
- Sam Jones – Patient at Shady Grove Hospital.
- Dr. Bob – Physician at Shady Grove Hospital, primary physician for Sam Jones.
- Dr. Dan – Physician at Shady Grove Hospital, who also treats Sam Jones.
Precondition
Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to perform certain actions on objects in the system. The actions have been categorized hierarchically so that if a user has been granted access to a category of actions, he or she is granted access to all actions categorized by that action. The security policy grants the primary physician access to create and update a patient’s progress note. The system does not explicitly grant the primary physician the privilege to append a patient’s progress note, however, append is categorized as an access control action under update.
Basic Scenario
Dr. Bob examines Mr. Jones as part of an episode of care. Dr. Bob opens Mr. Jones’ medical record and reads his medical history. Dr. Bob notices a transcription error in a progress note he had made for Mr. Jones’ last hospital visit. Dr. Bob corrects the error and updates the progress note. Dr. Bob opens a new progress note, enters his observations of Mr. Jones’ condition and appends the results of a recent blood test to the progress note.
Post-Condition
A progress note regarding a past visit Mr. Jones’ made to the hospital has been updated and a new progress note has been created and appended to. This updated progress note becomes a part of his medical record.
Analysis
Shady Grove Hospital’s security policy grants the primary physician access to create and update a patient’s progress note. The append action is categorized by the system as an update operation thus granting the primary physician the privilege to append the object.
Alternative Scenario
Dr. Bob examines Mr. Jones as part of an episode of care. Dr. Bob opens Mr. Jones’ medical record and reads his medical history. Dr. Bob notices a transcription error in a progress note Dr. Dan had made for Mr. Jones’ last hospital visit. Dr. Bob attempts to correct the error but is denied this privilege by the EHR system.
Post-Condition
The progress note regarding Mr. Jones’ last hospital visit remains unchanged.
Analysis
Shady Grove Hospital’s security policy denies a physician the ability to update a progress note if he or she is not the author of that progress note without additional authority.
Access Control Based on Category of Object
This use case illustrates how an EHR system would control access to an object in a medical record based on the type of object it is. A user attempts to access a number of objects in a medical record for which the system grants or denies access privileges based on the category of object.
Actors
- Shady Grove Hospital – Provider Organization in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.
- Sam Jones – Patient at Shady Grove Hospital.
- Dr. Bob – Physician at Shady Grove Hospital, primary physician for Sam Jones.
- Dr. Dan – Physician at Shady Grove Hospital, who also treats Sam Jones.
Precondition
Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. The objects have been categorized hierarchically so that if a user has been granted access to a category of objects, he or she is granted access to all objects in that category. For example, an initial assessment is categorized as an assessment which in turn is categorized as a clinical report, while payment history is categorized as an administrative report.
The security policy grants the primary physician access to create and read a patient’s assessment. The system does not explicitly grant the primary physician the privilege to access a patient’s initial assessment, however, as initial assessment is categorized as an assessment, access to the initial assessment would be inherited from assessment. Dr. Bob has previously completed assessments of Mr. Jones’ health.
Basic Scenario
Dr. Bob interviews Mr. Jones upon his admission into the hospital. Dr. Bob creates an initial assessment on Mr. Jones’ health after the interview.
Post-Condition
An initial assessment on Mr. Jones’ health has been entered into the system.
Analysis
Shady Grove Hospital’s security policy grants the primary physician access to create a patient’s assessment. The initial assessment is categorized by the system as an assessment thus granting the primary physician the privilege to create an initial assessment on the patient.
Alternative Scenario
Dr. Bob interviews Mr. Jones upon his admission into the hospital. Dr. Bob reviews Mr. Jones’ medical history for relevant clinical information. Dr. Bob then attempts to access Mr. Jones’ payment history with Shady Grove Hospital and is denied access.
Post-Condition
Dr. Bob can read Mr. Jones’ medical history but he cannot access Mr. Jones’ payment history.
Analysis
Shady Grove Hospital’s security policy allows the primary physician the ability to access clinical reports. Medical history is categorized as a clinical report and thus Dr. Bob can access it. The security policy does not allow a primary physician access to administrative reports without additional authorization. Since a payment history is categorized under administrative reports, Dr. Bob is denied access to it.
Access Control Based on Category of Structural Role
This use case illustrates how an EHR system would control access to an object in a medical record based on the structural role assigned to the user requesting access. In this case a structural role reflects a human or organizational category. A user, with an assigned structural role, attempts to access a number of objects in a medical record for which the system grants or denies access privileges based on the category of the user’s structural role.
Actors
- Shady Grove Hospital – Provider Organization in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.
- Sam Jones – Subject of care - Patient at Shady Grove Hospital.
- Dr. Bob – regulated health professional – general practitioner at Shady Grove Hospital.
- Dr. Dan – regulated health professional - dermatologist at Shady Grove Hospital.
- Mark Clark – admissions clerk at Shady Grove Hospital.
Precondition
Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. Certain structural roles are assigned permission for certain types of access regardless of which user has been assigned to the structural role. Structural roles have been categorized hierarchically so that sub-roles of a structural role class are granted the same permissions as the parent roles. For example, a dermatologist is categorized as a physician who in turn is categorized as a regulated health professional. The security policy grants the structural role of physician the ability to read a patient’s progress note. The security policy does not specify the medical specialty of the physician role.
Basic Scenario
Dr. Bob examines Mr. Jones as part of an episode of care. Dr. Bob opens Mr. Jones’ medical record and reads his medical history. Dr. Bob’s initial assessment leads him to refer Mr. Jones to Dr. Dan. Dr. Dan opens Mr. Jones’ medical record and reads his medical history.
Post-Condition
Dr. Dan can access Mr. Jones’ medical records and proceeds to treat Mr. Jones for his condition.
Analysis
Both Dr. Bob and Dr. Dan have been assigned the structural role of physician at Shady Grove Hospital. As such, they have been given permission to read the medical records of all patients in the hospital. This is the default policy which may be constrained if other conditions, such as a patient’s consent directive, are present. Dr. Bob and Dr. Dan have different medical specialties, sub-roles of the physician role. Since the security policy grants the access permission to the structural role of physician, all sub-roles, i.e. medical specialties classified under physician, will receive the same access permissions.
Alternative Scenario
Dr. Bob examines Mr. Jones as part of an episode of care. Dr. Bob opens Mr. Jones’ medical record and reads his medical history. Mark Clark attempts to open Mr. Jones’ medical record but is denied access.
Post-Condition
Mr. Jones’ medical record is protected from unauthorized access.
Analysis
Mark Clark is assigned the structural role of admissions clerk at Shady Grove. Admissions clerk is not categorized as a physician role at Shady Grove and is not granted the same access permissions as physician and the security policy doesn’t explicitly grant these permissions to the admissions clerk role. Therefore, without additional authority, Mark Clark cannot access Mr. Jones’ medical record.
Access Control Based on Category of Functional Role
This use case illustrates how an EHR system would control access to an object in a medical record based on the functional role assigned to the user requesting access. Functional roles are bound to the performance of actions carried out by an entity. A user, with an assigned functional role, attempts to access a number of objects in a medical record for which the system grants or denies access privileges based on the category of user’s functional role.
Actors
- Shady Grove Hospital – Provider Organization in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.
- Sam Jones – Subject of care - Patient at Shady Grove Hospital.
- Dr. Bob – Privileged healthcare professional - Physician at Shady Grove Hospital, assigned to Sam Jones by Shady Grove to fill this functional role.
- Dr. Sue – Healthcare professional - Physician at Shady Grove Hospital, privileged healthcare professional to Sam Jones when Dr. Bob is not available.
- Dr. Dan – Health-related professional - Physician at Shady Grove Hospital, indirectly involved with the treatment of Sam Jones.
Precondition
Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. Certain functional roles are assigned permissions for certain types of access regardless of which user has been assigned to the functional role. Functional roles have been categorized hierarchically so that sub-roles of a functional role are granted the same permissions as the parent roles. For example, an alternate privileged healthcare professional, under certain conditions, is categorized as a privileged healthcare professional who in turn is categorized as a healthcare professional. The security policy grants the functional role of privileged healthcare professional the ability to access to all of a patient’s medical record, including sensitive medical records, while that healthcare professional is assigned to the patient. The period of the assignment is limited to the privileged access time interval. A sub-role of the privileged healthcare professional is the alternate privileged healthcare professional; a healthcare professional that fills the role of the privileged healthcare professional during periods when the primary is unavailable. Dr. Bob has taken a week off to go on vacation.
Basic Scenario
Mr. Jones enters the hospital with a medical complaint. Dr. Sue can access all of Mr. Jones’ medical record, including those which indicate Mr. Jones’ alcohol abuse condition.
Post-Condition
Dr. Sue has complete access to all of Mr. Jones’ medical record, including sensitive medical information, until Dr. Bob returns from vacation after which she has only limited access to Mr. Jones’ medical record without additional authorization.
Analysis
The time interval in which Dr. Sue is assigned the functional role of alternate privileged healthcare professional begins when Dr. Bob departs on vacation and ends when Dr. Bob returns. During this time period, Dr. Sue is the alternate privileged healthcare professional, a sub-role of the privileged healthcare professional, and is granted all the access privileges of the privileged healthcare professional.
Alternative Scenario
Mr. Jones enters the hospital with a medical complaint. Dr. Dan attempts to access Mr. Jones’ medical record but is denied access to objects within Mr. Jones’ record that are considered sensitive.
Post-Condition
The sensitive information within Mr. Jones’ medical record is kept confidential except to privileged healthcare professionals.
Analysis
Dr. Dan’s functional role of health-related professional is not a sub-role of privileged healthcare professional and thus he is not granted access to all of Mr. Jones’ medical record without additional authorization.
Access Control Based on Multiple Role Values
This use case illustrates how an EHR system would control access to an object in a medical record based on a user being assigned more than one role attribute value. A user, with one or more assigned roles, attempts to access an object in a medical record for which the system grants or denies access privileges based on the combination of the user’s roles.
Actors
- Shady Grove Hospital – Provider Organization in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.
- Sam Jones – Subject of care - Patient at Shady Grove Hospital.
- Dr. Bob –Physician on the staff at Shady Grove Hospital.
- Dr. Dan – Physician with access privileges at Shady Grove Hospital but not on the staff.
Precondition
Shady Grove hospital has developed an access control system that implements decisions made in its security policy on its EHR system. This access control system can grant or deny the ability to access certain objects in the system. Certain types of access require that a user be assigned to more than one role, i.e. that access is not assigned to a single role but a combination of roles.
The security policy grants the combination role of staff physician the ability to update a patient’s care plan.
Basic Scenario
Mr. Jones is a patient of Dr. Bob’s and has not been responding to his treatment. Dr. Bob decides to change Mr. Jones’ care plan and updates the plan in his medical record.
Post-Condition
Mr. Jones’ care plan is updated and his treatment is changed.
Analysis
Shady Grove’s security policy requires that in order to update a patient’s care plan a user must have the roles of both physician and of member of the hospital staff. Since Dr. Bob has been assigned both roles, he is able to change Mr. Jones’s care plan.
Alternative Scenario
Dr. Dan has treated Mr. Jones at a clinic and has noted that Mr. Jones has not been responding to treatment. Dr. Dan decides to change Mr. Jones’ care plan at Shady Grove hospital. He has access privileges at Shady Grove and can read Mr. Jones’ care plan. He attempts to change the care plan to reflect the desired changes but is denied the ability to make the changes.
Post-Condition
Mr. Jones’s care plan is not updated and his treatment remains unchanged.
Analysis
Dr. Dan is a physician at a clinic associated with Shady Grove hospital but is not on the staff at Shady Grove. Therefore he does not have the combination of both roles required to update a patient’s care plan at Shady Grove and is denied permission to do so.
Enable Design of Access Control System
This use case illustrates the activity of an EHR system security administrator in establishing access control policy rules. The security administrator converts the broad principles laid out by the hospital’s security policies into a set of well defined rules. These rules can then be used to configure the automated decision function (ADF) that can be used by the access control system (ACS) to make decisions on access requests at run time. The development of these rules is a manual engineering design activity that precedes other automated access control activities. Organizing vocabularies into structured hierarchies supports this activity by reducing ambiguity and time spent searching for terms.
Actors
- Shady Grove Hospital – Provider Organization in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how objects are allowed to be accessed in the hospital’s EHR.
- Joe Smith – EHR system security administrator at Shady Grove Hospital.
Precondition
Shady Grove hospital has developed a system to control access to information on their EHR system based on their security policies. Before the system is operational, Joe Smith, the system security administrator, must set up the access control policy rules in accordance with Shady Grove’s security policies. Part of this process is to allocate attribute values to the targets; the objects in the EHR-S. This will later be used by the automated decision function (ADF) to determine which requestors can access which targets when the system is operational. The operational use case is presented as Facilitate an Automated Decision Function.
To reduce the ambiguity in allocating attribute values to the targets, the objects have been categorized so that they can be more easily identified by Mr. Smith when making his designations.
Basic Scenario
Shady Grove’s security policy states that the role of physician can read all clinical objects on the hospital’s EHR-S. The list of objects that exist on Shady Grove’s EHR-S have been categorized into clinical and administrative types. Joe Smith designates a specific clinical object with the attribute name of Encounter Data in the EHR-S.
Post-Condition
All objects with the attribute name of Encounter Data are categorized as clinical; the ADF will recognize those objects as clinical objects and apply the appropriate access controls to them.
Analysis
As a security administrator, Mr. Smith may not understand the purpose and differences between objects in the EHR. By providing an ontology which categorizes objects such that the categories correspond with Shady Grove’s security policy, there is no ambiguity in allocating the appropriate access control information to the specific object type. If an object is not correctly categorized, or is not categorized at all, this manual step will provide the opportunity to evaluate the attribute value of the object before it is entered in the access control system.
Alternative Scenario
Shady Grove’s security policy states that the role of physician can read all clinical objects on the hospital’s EHR-S. The list of objects that exist on Shady Grove’s EHR-S have been categorized alphabetically by name. Joe Smith locates a Blood Bank Order object under B and categorizes it as a type of clinical object in the ACS. Mr. Smith then locates Radiology Order object under R and categorizes it as a type of clinical object in the ACS.
Post-Condition
All objects with the attribute names of Blood Bank Order and Radiology Order in the EHR-S are categorized as clinical objects: the ADF will recognize those objects as clinical objects and apply the appropriate access controls to them.
Analysis
As the list of objects in the EHR-S grows, it may become unmanageable for browsing. Organizing objects alphabetically provides a more manageable list. The categories may not be relevant for security purposes, however, they are intended to enable the manual access control policy rules configuration activity but are not used in the actual rules that configure the ADF. If an object is not correctly categorized, or is not categorized at all, this may not be detrimental to the subsequent automated process since the categories are not intended to be used in that process.
Reference
ISO/IEC 10181-3
Facilitate an Automated Decision Function
This use case illustrates the activity of an automated decision function (ADF) of an access control system (ACS) in making access control decisions. The ADF is provided with information on a request initiator, a requested target and an access request. The ADF has been configured with access control policy rules by the ADF’s authority; Shady Grove Hospital. The ADF is also provided with contextual information such as time of day and location of the request initiator. From this information the ADF is capable of automatically deciding whether to grant or deny an initiator’s request to access a target. Organizing vocabularies into structured hierarchies supports this activity by creating formal associations between terms.
Actors
- Shady Grove Hospital – Provider Organization and ACS authority in which the use case takes place.
- Shady Grove Hospital’s EHR System – the EHR system which is accessed in the use case.
- Shady Grove Hospital’s security policy – the policy that determines how the ACS is configured in the hospital’s EHR.
- Sam Jones – Subject of care - Patient at Shady Grove Hospital.
- Dr. Bob – physician at Shady Grove Hospital.
- Joe Smith – EHR system security administrator at Shady Grove Hospital.
Precondition
Shady Grove hospital has developed a system to control access to information on their EHR system based on their security policies. Joe Smith, the system security administrator, has configured system targets (objects) and initiators (roles) with appropriate information and the ADF with rules so it can automatically make access control decisions when the system is operational. This use case is presented as Enable Design of Access Control System. Shady Grove’s security policy states that the role of physician can read all clinical objects on the hospital’s EHR-S. Shady Grove’s security policy does not grant the role of physician the ability to read Billing Attachments.
Basic Scenario
Dr. Bob makes a request on the EHR-S to read Sam Jones’ Encounter Data from his last visit. The ADF evaluates all information required to make the decision against the policy rules and grants Dr. Bob permission to read Mr. Jones’ record.
Post-Condition
Dr. Bob has accessed Mr. Jones’s Encounter Data and can read it. Security policies at Shady Grove have been complied with.
Analysis
Dr. Bob had been assigned the structural role of physician at Shady Grove which allows him to read all clinical objects. Mr. Jones’ Encounter Data has been designated a clinical object. Dr. Bob is initially requesting read access to the Encounter Data, an operation permitted by the policy rules. The access control information on the initiator (Dr. Bob), the target (Encounter Data) and the access request (read) conform with an access control rule and therefore this request is permitted by the ADF. This decision has been reached automatically without human intervention.
Alternative Scenario
Dr. Bob makes a request on the EHR-S to read Sam Jones’ Billing Attachment from his last visit. The ADF evaluates all information required to make the decision against the policy rules and denies Dr. Bob permission to read Mr. Jones’ Billing Attachment.
Post-Condition
Dr. Bob cannot access Mr. Jones’s Billing Attachment without breaking a security policies at Shady Grove. The confidentiality of Mr. Jones’ billing information has been preserved.
Analysis
Dr. Bob’s structural role of physician does not allow him to read allow information within a patient’s record, in this case the Billing Attachment. The access control information on the initiator (Dr. Bob), the target (Billing Attachment) and the access request (read) did not conform with the access control rules and therefore this request was denied by the ADF. This decision was reached automatically without human intervention.
Reference
ISO/IEC 10181-3