SAMHSA-RBAC flow

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 the path identifies how a User can limit a physician's access to his substance abuse records and that this will inform and override any instituion-based role access.

The way I use this diagram and the rationale for the model is as follows:

1. All privacy issue start at the patient. Thus the beginning box "User".
2. 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.

   One of the roles to be chosen are pass through licenses. Others to be added as necessary.
3. 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.
4. 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).
5. 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.
6. 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).
7. The "RBAC_objects" box are permissions assigned to each role.
8. The "EMR_data_objects" box are the actual data types which may or may not be exposed to the provider.
9. 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.

FDin