Difference between revisions of "SAMHSA-RBAC flow"
Line 1: | Line 1: | ||
[[Image:SAMHSA-RBAC flow.gif]] | [[Image:SAMHSA-RBAC flow.gif]] | ||
− | This is what I use to follow a use case from start to finish. If you follow the bright green arrows, you will see that | + | This is what I use to follow a use case from start to finish. If you follow the bright green arrows, you will see a use case that identifies how a User picks a Provider, assigns some Permissions to this Provider, the User selected Permissions are normalized to a Standard Terminology on Confidentiality and Privacy, the Provider has privleges at a Hospital, the Hospital has Role Based Access and the Provider has a Role assigned by the Hospital, there are specific data access permissions based on the Provider's Role, which allows access to specific medical data, which is displayed or hidden based on the Patient's decision. So even though the Hospital allows access to a record this access is limited by the overaching decision of the patient. |
The way I use this diagram and the rationale for the model is as follows: | The way I use this diagram and the rationale for the model is as follows: | ||
Line 11: | Line 11: | ||
One of the roles to be chosen are pass through licenses. Others to be added as necessary. | One of the roles to be chosen are pass through licenses. Others to be added as necessary. | ||
<li> The "P_data_consent" box contains the types of permissions that the Patient wants to allow (This is an opt in approach). Since the patient will pick these, the choices are to be written and defined in a patient friendly language. The can be sub-categorized by types of data, so no substance abuse records could be a choice. Population of this box is the responsibility of SAMHSA and other privacy focused stakeholders. | <li> The "P_data_consent" box contains the types of permissions that the Patient wants to allow (This is an opt in approach). Since the patient will pick these, the choices are to be written and defined in a patient friendly language. The can be sub-categorized by types of data, so no substance abuse records could be a choice. Population of this box is the responsibility of SAMHSA and other privacy focused stakeholders. | ||
− | <li> The "confidentiality code" box that is ABOVE the horizontal border contains the standardized privacy terminology (the current SAMHSA work on creating a terminology to ehance RBAC which is consistent with HL7 constructs). | + | <li> The "confidentiality code" box that is ABOVE the horizontal border contains the standardized privacy terminology <b>(the current SAMHSA work on creating a terminology to ehance RBAC which is consistent with HL7 constructs).</b> |
− | <li> The "confidentiality code" box that is BELOW the horizontal border contains the standardized privacy terminology (the current SAMHSA work on creating a terminology to ehance RBAC which is consistent with HL7 constructs). This one is used by the institution to inform the final data extract. Since this is identical to the "confidentiality code" box above the line, this can be a common resource for the patient and the institution. The large bidirectional arrow indicates this singularity. | + | <li> The "confidentiality code" box that is BELOW the horizontal border contains the standardized privacy terminology <b>(the current SAMHSA work on creating a terminology to ehance RBAC which is consistent with HL7 constructs).</b> This one is used by the institution to inform the final data extract. Since this is identical to the "confidentiality code" box above the line, this can be a common resource for the patient and the institution. The large bidirectional arrow indicates this singularity. |
<li> The "Hospital_roles" are institution specific roles used within the institution to determine Role Based Access permissions. Each practitioner within the institution has a role. In this case, there is a dircet link between the hospital role (physician) and the provider selected by the patient (see P_doctor_2). | <li> The "Hospital_roles" are institution specific roles used within the institution to determine Role Based Access permissions. Each practitioner within the institution has a role. In this case, there is a dircet link between the hospital role (physician) and the provider selected by the patient (see P_doctor_2). | ||
<li> The "RBAC_objects" box are permissions assigned to each role. | <li> The "RBAC_objects" box are permissions assigned to each role. |
Latest revision as of 21:43, 25 August 2008
This is what I use to follow a use case from start to finish. If you follow the bright green arrows, you will see a use case that identifies how a User picks a Provider, assigns some Permissions to this Provider, the User selected Permissions are normalized to a Standard Terminology on Confidentiality and Privacy, the Provider has privleges at a Hospital, the Hospital has Role Based Access and the Provider has a Role assigned by the Hospital, there are specific data access permissions based on the Provider's Role, which allows access to specific medical data, which is displayed or hidden based on the Patient's decision. So even though the Hospital allows access to a record this access is limited by the overaching decision of the patient.
The way I use this diagram and the rationale for the model is as follows:
- All privacy issue start at the patient. Thus the beginning box "User".
- First and easiest decision for a patient to make is his/her regular physician(s). Thus the direct link to the "P_provider" box. The contents of the "P_provider" box are the patient's doctor's name and unique ID. This box can also classify the doctor's role, like primary care physician.
- Provider roles at this level can be standardized against the NUCC Provider taxonomy or a similar provider classification scheme.
- The "P_data_consent" box contains the types of permissions that the Patient wants to allow (This is an opt in approach). Since the patient will pick these, the choices are to be written and defined in a patient friendly language. The can be sub-categorized by types of data, so no substance abuse records could be a choice. Population of this box is the responsibility of SAMHSA and other privacy focused stakeholders.
- The "confidentiality code" box that is ABOVE the horizontal border contains the standardized privacy terminology (the current SAMHSA work on creating a terminology to ehance RBAC which is consistent with HL7 constructs).
- The "confidentiality code" box that is BELOW the horizontal border contains the standardized privacy terminology (the current SAMHSA work on creating a terminology to ehance RBAC which is consistent with HL7 constructs). This one is used by the institution to inform the final data extract. Since this is identical to the "confidentiality code" box above the line, this can be a common resource for the patient and the institution. The large bidirectional arrow indicates this singularity.
- The "Hospital_roles" are institution specific roles used within the institution to determine Role Based Access permissions. Each practitioner within the institution has a role. In this case, there is a dircet link between the hospital role (physician) and the provider selected by the patient (see P_doctor_2).
- The "RBAC_objects" box are permissions assigned to each role.
- The "EMR_data_objects" box are the actual data types which may or may not be exposed to the provider.
- The directional arrow coming from the "confidentiality code" box applies the patient privacy filter to block the release of certain "EMR_data_objects".
Legend:
- User = patient or authourized representative, etc.
- P_provider = Provider(s) identified by the User. Includes Providers and Institutions with a personal healthcare relationship to the User as well as potential Providers, like potential referrals to specialist.
- P_data_consent = Type of medical data (all mental health records) or instances of specific data (no HIV tests) that the User wishes to mask. Presented in a form which is understandable at a high school education level in plain English. Probably keep at a general level, assuming htat patients will not want to be too specific in their data masking decisions.
- Confidentiality Codes = a standard set of data restriction concepts and codes that extend across all biomedical domains. These apply to the P_data_consent restraints and should be used as a value pair with P_data_consent. For instance, {P_no_SAMHSA, restricted} in the form of {p_data_consent, confidentiality codes}
- Confidentiality codes are used to limit the type of data displayed to the Provider / Institution.
- Hospital roles = Standardized Provider roles applicable to the local environment. For example, there are no geriatric physician role in a pediatrics office. P_provider maps to these as a value pair. For example in the above graph {P_docotr_2, physician}
- RBAC_objects = current and extended RBAC objects. These are the types of health data available.
- EMR Data Object = the actual data stored in and delivered from the EMR.