In this chapter you will learn to:
How to use data access policies
Use data access policies to control users' access to patient and subject data in several ways:
Control access to Personally Identifiable Information (PII) attributes. Create data access policies that specify which Personally Identifiable Information (PII) attributes are visible for subjects in a particular study or patients in a particular patient group, to users assigned to the configuration. PII attributes that are not visible are obfuscated (masking values are displayed).
This functionality is always enabled so that anyone needing access to PII data must be assigned to a data access policy that grants the required access.
Control access to non-PII subject or patient information by enabling row-level filtering. This setting applies across all studies and patient groups.
If disabled (the default state), users can see all non-PII subject or patient data in any study or patient group.
If enabled, only users assigned to a data access policy that allows access to a study or patient group can see any non-PII subject or patient data in the study or patient group.
Allow access to all data by assigning a user to a global configuration that allows access to all subject and patient data, including PII data, in all studies and patient groups.
Control access to omics data stored in the Omics Data Bank Schema. Create data access policies containing attributes at the patient level that control whether the all patient omics results can be seen by users or not. The same model applies at a subject level. Data access policies can be created through patient groups for patients and through studies for subjects.
Moreover, an expiration date is introduced for the omics access attribute. Once the expiration date has passed, all access restrictions are removed automatically.
If a user has access to the same study or patient group through multiple data access policies, if any of the data access policies permits access to a particular subject or patient's data, it is visible to the user.
Note:
In previous versions of OHTR, data access policies were called VPD configurations.Specify a study or patient group and a set of personally identifiable information (PII) that should be visible to certain users. All users assigned to the data access policy have access to the specified PII data for the subjects or patients in the specified study or patient group. If some users should have access to a different set of PII data for the same study or patient group, create a different data access policy for them.
Note:
The same steps apply when creating a data access policy for the Omics Data Bank.To create a data access policy:
On the database server, log in to SQL*Plus as CDM.
Run VPD_UTIL.ADD_VPD_CONFIG, entering values as follows:
A unique name for the data access policy.
The name of one study or patient group whose data will be accessible through the data access policy.
A description of the data access policy.
A value for every attribute group parameter containing either subj or pt, depending on whether you specified a study or a patient group.
A value of Y allows access. N prevents access. For a description of each attribute group, see:
Table 2-1, "Omics Data Attributes"
Table 2-2, "Personally Identifiable Attribute Groups for Subjects"
Table 2-3, "Personally Identifiable Attribute Groups for Patients"
Optional! An expiration date for the data access policy in the format YYYY-MM-DD. On this date the data access policy will be automatically deactivated and any users assigned to it will no longer be able to access subject/patient data through it.
Note:
For data access policies for Omics Data Bank, the date applies only when I_PT_ODB or I_SUBJ_ODB are set to N (No). This means that the data access policy restricts access to omics data for users. In these cases, the date represents the last day of the restriction.Example 1 - Data access policy with some PII access to 'Study B' subjects
BEGIN
VPD_UTIL.ADD_VPD_CONFIG (I_CONFIG_NAME => 'STUDY_B_SUBJECTS_FULL_PII' ,
I_SUBJ_ADD => 'N' ,
I_SUBJ_CONSENT => 'Y' ,
I_SUBJ_DATE => 'Y' ,
I_SUBJ_DX => 'Y' ,
I_SUBJ_ENC => 'Y' ,
I_SUBJ_HIST => 'Y' ,
I_SUBJ_ID => 'Y' ,
I_SUBJ_MED => 'Y' ,
I_SUBJ_NAME => 'N' ,
I_SUBJ_OBSV => 'Y' ,
I_SUBJ_PROC => 'Y' ,
I_SUBJ_SPEC => 'Y' ,
I_DESCRIPTION => 'data access policy with access to all Study B subjects with all PII attributes except subject name and address',
I_SUBJECT_STUDY=>'Study B'
);
END;
/
Example 2 - Data access policy with full PII access to GROUP1 patients
BEGIN
VPD_UTIL.ADD_VPD_CONFIG (I_CONFIG_NAME => 'GROUP1_PATIENTS_ALL_PII' ,
I_PT_ADD => 'Y' ,
I_PT_CONSENT => 'Y' ,
I_PT_DATE => 'Y' ,
I_PT_DX => 'Y' ,
I_PT_ENC => 'Y' ,
I_PT_HIST => 'Y' ,
I_PT_ID => 'Y' ,
I_PT_MED => 'Y' ,
I_PT_NAME => 'Y' ,
I_PT_OBSV => 'Y' ,
I_PT_PROC => 'Y' ,
I_PT_SPEC => 'Y' ,
I_DESCRIPTION => 'data access policy with access to GROUP1 patients for all PII attributes',
I_PATIENT_GROUP =>'GROUP1',
I_EXPIRATION_DATE => date '2025-12-31'
);
END;
/
Example 3 - Data access policy with full PII access to Omics Data Bank
BEGIN
VPD_UTIL.ADD_VPD_CONFIG (I_CONFIG_NAME => 'GROUP1_PATIENTS_ALL_PII' ,
I_PT_ADD => 'Y' ,
I_PT_CONSENT => 'Y' ,
I_PT_DATE => 'Y' ,
I_PT_DX => 'Y' ,
I_PT_ENC => 'Y' ,
I_PT_HIST => 'Y' ,
I_PT_ID => 'Y' ,
I_PT_MED => 'Y' ,
I_PT_NAME => 'Y' ,
I_PT_OBSV => 'Y' ,
I_PT_PROC => 'Y' ,
I_PT_SPEC => 'Y' ,
I_PT_ODB => 'Y' ,
I_DESCRIPTION => 'data access policy with access to GROUP1 patients for all PII attributes and Omics Data Bank',
I_PATIENT_GROUP =>'GROUP1',
END;
/
Assign users to a data access policy to give them permission to see the specified PII for the specified subjects or patients. You can assign either WebLogic user accounts or database user accounts, one account at a time.
On the database server, log in to SQL*Plus as CDM.
Run VPD_UTIL.ADD_CONFIG_USER, entering values as follows:
The data access policy name.
The user's user name.
(Optional) An expiration date for the user assignment in the format YYYY-MM-DD. On this date the user will be automatically deassigned and will no longer be able to access subject/patient data through the data access policy.
For example:
BEGIN VPD_UTIL.ADD_CONFIG_USER (I_EXISTING_CONFIG_NAME => 'PATIENT_GROUP_1_ALL_ATTRIBUTES' , I_USER_NAME => 'TESTER' , I_EXPIRATION_DATE => DATE '2025-12-31' ); END;/
Deactivating a data access policy removes the specified data access from all the users assigned to it, though users may have access through a different data access policy.
On the database server, log in to SQL*Plus as CDM.
Run stored procedure VPD_UTIL.INACTIVATE_CONFIG, entering the data access policy name for I_EXISTING_CONFIG_NAME:
exec VPD_UTIL.INACTIVATE_CONFIG;
By default, any application user is permitted to access non-PII records for all patients and subjects. If required, the row-level filtering mode can be turned on at the system level, which limits user access to only a subset of patients or subjects. If this optional mode is turned on, only users explicitly assigned to a data access policy are granted access to the patients or subjects associated with the policy. A user can be assigned to any number of policies.
On the database server, log in to SQL*Plus as CDM.
Run stored procedure VPD_UTIL.ENABLE_ROW_FILTER_POLICIES:
To require that users must be assigned to a data access policy to see any subject or patient data for a particular study or patient group, enter a value of 1:
exec vpd_util.enable_row_filter_policies(1)
To enable all users to see non-PII data for any subject or patient, enter a value of 0. This is the default value.
exec vpd_util.enable_row_filter_policies(0)
A global data access policy permits access to all patients and subjects and all their PII attribute values. Users who are assigned to this data access policy do not need to be assigned to any other data access policy, even if row filtering is on. Its ID value is 1.
On the database server, log in to SQL*Plus as CDM.
Run stored procedure VPD_UTILADD_CONFIG_USER entering values as follows:
The configuration ID set to 1.
The user's user name.
(Optional) An expiration date for the user assignment in the format YYYY-MM-DD. On this date the user will be automatically deassigned and will no longer be able to access subject/patient data through the data access policy.
For example:
BEGIN VPD_UTIL.ADD_CONFIG_USER (I_EXISTING_CONFIG_ID => 1 , I_USER_NAME => 'JSMITH' , I_EXPIRATION_DATE => DATE '2025-12-31' ); END; /
Some data access policies grant data access to groups of attributes, while others can allow access only for certain attributes.
PII attributes are combined into PII attribute groups. For more information on attribute groups, see:
Table 2-2, "Personally Identifiable Attribute Groups for Subjects"
Table 2-3, "Personally Identifiable Attribute Groups for Patients"
For more information on individual Omics Attributes, see: Table 2-1, "Omics Data Attributes"
Table 2-1 Omics Data Attributes
| Subject and Patient Attributes | Description | Table | API Procedure Input Parameter |
|---|---|---|---|
|
SUBJ_ODB |
Defines whether patient omics data is granted (Y) or denied (N) in a configuration |
W_EHA_VPD_CONFIG |
I_SUBJ_ODB |
|
SUBJ_ODB_EXP_DT |
Defines expiration date for N value in SUBJ_ODB |
W_EHA_VPD_CONFIG |
I_SUBJ_ODB_EXP_DT |
|
PT_ODB |
Defines whether patient omics data is granted (Y) or denied (N) in a given configuration |
W_EHA_VPD_CONFIG |
I_PT_ODB |
|
PT_ODB_EXP_DT |
Defines expiration date for N value in PT_ODB |
W_EHA_VPD_CONFIG |
I_PT_ODB_EXP_DT |
Table 2-2 Personally Identifiable Attribute Groups for Subjects
| Subject Attribute Groups | Description | Table | Column(s) | API Procedure Input Parameter |
|---|---|---|---|---|
|
SUBJ_ADD |
Subject Address |
W_EHA_SUBJECT_D |
CITY, POSTAL_CODE, STREET_ADDRESS_1, STREET_ADDRESS_2, STREET_ADDRESS_3 |
I_SUBJ_ADD |
|
SUBJ_CONSENT |
Subject Consent Dates |
W_EHA_ENC_PATIENT_H |
CONSENT_START_DT, CONSENT_END_DT |
I_SUBJ_CONSENT |
|
SUBJ_DATE |
Subject Lifecycle Dates |
W_EHA_SUBJECT_D |
DOB, DECEASED_DT |
I_SUBJ_DATE |
|
SUBJ_DX |
Subject Diagnosis Dates |
W_EHA_DX_SUBJECT_H |
DIAGNOSIS_ONSET_DT, DIAGNOSIS_REPORTED_DT, DIAGNOSIS_END_DT, AGE_AT_FIRST_ONSET |
I_SUBJ_DX |
|
SUBJ_ENC |
Subject Encounter Dates |
W_EHA_ENC_SUBJECT_H |
ENCOUNTER_START_DT, ENCOUNTER_END_DT |
I_SUBJ_ENC |
|
SUBJ_HIST |
Subject History |
W_EHA_SBJ_HISTORY_SBJ_H |
SUBJECT_HISTORY_START_DT, SUBJECT_HISTORY_END_DT |
I_SUBJ_HIST |
|
SUBJ_ID |
Subject Identifier |
W_EHA_SUBJECT_D |
SUBJECT_IDENTIFIER |
I_SUBJ_ID |
|
SUBJ_MED |
Subject Medication Dates |
W_EHA_SUBADMN_SUBJECT_H |
SUBADMN_START_DT, SUBADMN_END_DT |
I_SUBJ_MED |
|
SUBJ_NAME |
Subject Name |
W_EHA_SUBJECT_D |
FIRST_NAME, MIDDLE_NAME, LAST_NAME |
I_SUBJ_NAME |
|
SUBJ_OBSV |
Subject Observation Dates |
W_EHA_OBSV_SUBJECT_H |
OBSV_DT |
I_SUBJ_OBSV |
|
SUBJ_PROC |
Subject Procedure Dates |
W_EHA_PROC_SUBJECT_H |
PROCEDURE_START_DT, PROCEDURE_END_DT |
I_SUBJ_PROC |
|
SUBJ_SPEC |
Subject Specimen Identifier and Collection Date |
W_EHA_SPECIMEN_SUBJECT_H |
SPECIMEN_COLLECTION_DT, SPECIMEN_NUMBER |
I_SUBJ_SPEC |
Table 2-3 Personally Identifiable Attribute Groups for Patients
| Patient Attribute Groups | Description | Table | Column(s) | API Procedure Input Parameter |
|---|---|---|---|---|
|
PT_ADD |
Patient Address |
W_EHA_RESEARCH_PATIENT_D |
CITY, POSTAL_CODE, STREET_ADDRESS_1, STREET_ADDRESS_2, STREET_ADDRESS_3 |
I_PT_ADD |
|
PT_CONSENT |
Patient Consent Dates |
W_EHA_CONSENT_PATIENT_H |
CONSENT_START_DT, CONSENT_END_DT |
I_PT_CONSENT |
|
PT_DATE |
Patient Lifecycle Dates |
W_EHA_RESEARCH_PATIENT_D |
DOB, DECEASED_DT |
I_PT_DATE |
|
PT_DX |
Patient Diagnosis Dates |
W_EHA_DX_PATIENT_H |
DIAGNOSIS_ONSET_DT, DIAGNOSIS_ REPORTED_DT, DIAGNOSIS_END_DT, AGE_AT_FIRST_ONSET |
I_PT_DX |
|
PT_ENC |
Patient Encounter Dates |
W_EHA_ENC_PATIENT_H |
ENCOUNTER_START_DT, ENCOUNTER_END_DT |
I_PT_ENC |
|
PT_HIST |
Patient History |
W_EHA_PT_HISTORY_PT_H |
PATIENT_HISTORY_START_DT, PATIENT_HISTORY_END_DT |
I_PT_HIST |
|
PT_ID |
Patient Identifier |
W_EHA_RESEARCH_PATIENT_D |
PATIENT_IDENTIFIER |
I_PT_ID |
|
PT_MED |
Patient Medication Dates |
W_EHA_SUBADMN_PATIENT_H |
SUBADMN_START_DT, SUBADMN_END_DT |
I_PT_MED |
|
PT_NAME |
Patient Name |
W_EHA_RESEARCH_PATIENT_D |
FIRST_NAME, MIDDLE_NAME, LAST_NAME |
I_PT_NAME |
|
PT_OBSV |
Patient Observation Dates |
W_EHA_OBSV_PATIENT_H |
OBSV_DT |
I_PT_OBSV |
|
PT_PROC |
Patient Procedure Dates |
W_EHA_PROC_PATIENT_H |
PROCEDURE_START_DT, PROCEDURE_END_DT |
I_PT_PROC |
|
PT_SPEC |
Patient Specimen Identifier and Collection Date |
W_EHA_SPECIMEN_PATIENT_H |
SPECIMEN_COLLECTION_DT, SPECIMEN_NUMBER |
I_PT_SPEC |
To make subject and patient data available in Oracle Healthcare Translational Research (OHTR):
Load the data into Oracle Healthcare Data Warehouse (HDM) using the Healthcare Data Interface tables (HDI).
Propagate the data to the Cohort Data Model (CDM) using either Informatica or Oracle Data Integrator (ODI) ETLs.
Instructions for loading data can be found in the Oracle Healthcare Foundation Administrator's Guide for Informatica and for Oracle Data Integrator. The guides are available in password-protected patch 22640545. To get the password, log a Service Request (SR) on My Oracle Support.
Note:
In the Single Patient Viewer screen, the consent records are displayed only if a valid Data Source Number is populated in the W_EHA_CONSENT_PATIENT_H.DATASOURCE_NUM_ID column. Make sure that the value populated in this column exists in the W_EHA_DATASOURCE_CDM.ROW_WID column, as well.Instructions for loading data can be found in the Oracle Healthcare Foundation Administrator's Guide for Informatica and for Oracle Data Integrator. The guides are available in password-protected patch 22640545. To get the password, log a Service Request (SR) on My Oracle Support.
Dr. Smith needs to view all patient and subject data with de-identified PII. She works in an environment where row-level filtering is disabled, meaning assignment to a data access policy is not required.
There is no need to explicitly assign a data access policy to Dr. Smith. In her environment, any user has access to non-PII data for all patients and subjects.
Dr. Chen needs to see patient data in Patient Group 1, including all PII values except patient name and address. She works in an environment where access to patient and subject records is controlled. To give her access:
Create a data access policy for the patient group that Dr. Chen has access to view. Set all patient attribute groups in the policy except Patient name and address to Y.
BEGIN
VPD_UTIL.ADD_VPD_CONFIG (I_CONFIG_NAME => 'GROUP1_PATIENTS_ALL_PII_EXCEPT_NAME_ADDRESS' ,
I_PT_ADD => 'N' ,
I_PT_CONSENT => 'Y' ,
I_PT_DATE => 'Y' ,
I_PT_DX => 'Y' ,
I_PT_ENC => 'Y' ,
I_PT_HIST => 'Y' ,
I_PT_ID => 'Y' ,
I_PT_MED => 'Y' ,
I_PT_NAME => 'N' ,
I_PT_OBSV => 'Y' ,
I_PT_PROC => 'Y' ,
I_PT_SPEC => 'Y' ,
I_DESCRIPTION => 'Configuration with access to GROUP1 patients with PII attributes except Name and Address',
I_PATIENT_GROUP =>'GROUP1',
I_EXPIRATION_DATE => date '2025-12-31'
);
END;
/
Assign Dr. Chen (jchen12) to the above data access policy.
BEGIN VPD_UTIL.ADD_CONFIG_USER (I_EXISTING_CONFIG_NAME => 'GROUP1_PATIENTS_ALL_PII_EXCEPT_NAME_ADDRESS' , I_USER_NAME => 'jchen12', I_EXPIRATION_DATE => date '2025-12-31'); END; /
Dr. Gupta is authorized to see all patient and subject data, including identifiable data.
BEGIN VPD_UTIL.ADD_CONFIG_USER (I_EXISTING_CONFIG_ID => 1, I_USER_NAME => 'kgupta', I_EXPIRATION_DATE => date '2025-12-31'); END; /
Dr. Black needs to see de-identified data in STUDY A and identified data in STUDY B.
Create a data access policy that grants access to de-identified PII data on subjects from STUDY A.
Note:
This step is optional when row-level filtering is disabled
BEGIN
VPD_UTIL.ADD_VPD_CONFIG (I_CONFIG_NAME => 'STUDY_A_SUBJECTS_NO_PII' ,
I_SUBJ_ADD => 'N' ,
I_SUBJ_CONSENT => 'N' ,
I_SUBJ_DATE => 'N' ,
I_SUBJ_DX => 'N' ,
I_SUBJ_ENC => 'N' ,
I_SUBJ_HIST => 'N' ,
I_SUBJ_ID => 'N' ,
I_SUBJ_MED => 'N' ,
I_SUBJ_NAME => 'N' ,
I_SUBJ_OBSV => 'N' ,
I_SUBJ_PROC => 'N' ,
I_SUBJ_SPEC => 'N' ,
I_DESCRIPTION => 'Configuration with access to Study A subjects with no PII attribute values',
I_SUBJECT_STUDY=>'Study A'
);
END;
/
Create a data access policy that grants access to subjects from STUDY B and their identifiable attribute values:
BEGIN
VPD_UTIL.ADD_VPD_CONFIG (I_CONFIG_NAME => 'STUDY_B_SUBJECTS_FULL_PII' ,
I_SUBJ_ADD => 'Y' ,
I_SUBJ_CONSENT => 'Y' ,
I_SUBJ_DATE => 'Y' ,
I_SUBJ_DX => 'Y' ,
I_SUBJ_ENC => 'Y' ,
I_SUBJ_HIST => 'Y' ,
I_SUBJ_ID => 'Y' ,
I_SUBJ_MED => 'Y' ,
I_SUBJ_NAME => 'Y' ,
I_SUBJ_OBSV => 'Y' ,
I_SUBJ_PROC => 'Y' ,
I_SUBJ_SPEC => 'Y' ,
I_DESCRIPTION => 'Configuration with access to Study B subjects with all PII attribute values',
I_SUBJECT_STUDY=>'Study B'
);
END;
/
Assign Dr. Black to these data access policies:
Note:
AssigningSTUDY_A_SUBJECTS_NO_PII configuration is optional if row-level filtering is disabled.BEGIN VPD_UTIL.ADD_CONFIG_USER (I_EXISTING_CONFIG_NAME => 'STUDY_A_SUBJECTS_NO_PII', I_USER_NAME => 'sblack', I_EXPIRATION_DATE => date '2025-12-31'); END; / BEGIN VPD_UTIL.ADD_CONFIG_USER (I_EXISTING_CONFIG_NAME => 'STUDY_B_SUBJECTS_FULL_PII', I_USER_NAME => 'sblack', I_EXPIRATION_DATE => date '2025-12-31'); END; /