Managing Blinding Along the Data Flow

When a Load Set writes to a Table instance whose Blinding flag is set to Yes, the system changes the values available for the Blind Break system Parameter in the Execution Setup for the Load Set to Real (Blind Break) and Dummy instead of Not Applicable.

The same is true for any Program that reads data from that blinded Table instance and so on downstream in the data flow as Programs read from blinded or unblinded Table instances and write to other blinded or unblinded Table instances.

In each case, the person running the Program must set the Blind Break system Parameter in the Execution Setup.

• If it is set to Real (Blind Break), the system runs the Program on the data in the blinded partition of the source Table instance and writes to the blinded partition of the target Table instance.

• If it is set to Dummy, the system runs the Program on the data in the dummy partition of the source Table instance and writes to the dummy partition of the target Table instance.

• If you are using DMW and want to process masking values instead of the real data in LSH, use the Dummy Blind Break option. After program execution, DMW masking values are stored in the dummy partition of blinded target tables.

  Tip:

  Oracle recommends processing DMW data in DMW, not LSH. In particular, do not run DMW transformations and validation checks in LSH.

  The Dummy Blind Break option is not available if any of the source tables is blinded at the table level.

Special privileges are required to run a Load Set or Program that has one or more source or target Table instances with its Blinding flag set to Yes. For complete information on blinding-related privileges, see the chapter on security in the Oracle Life Sciences Data Hub Implementation Guide.

Normal Usage: Oracle LSH requires that downstream Table instances have the Blinding flag set to Yes, but you must set the flag manually. Oracle LSH enforces the rule at runtime. If you attempt to run a Program that writes real data from a Table instance whose Blinding flag is set to Yes (with a Blinding Status of either Blinded or Unblinded) into a nonblinded Table instance (with its Blinding flag set to No and its Blinding Status set to Not Applicable)) the submission fails.

Exception Authorization: There may be cases where you need to create a Program that reads from one or more blinded or unblinded Table instances and writes to one or more nonblinded Table instances; for examples, see Loading Real and Dummy Data and Figure 12-3 below.

In this case you must set the nonblinded target Table instance's Blinding flag to No and its Blinding Status to Authorized. The system then allows users with special privileges on the blinded or unblinded source Table instances to run the Program after confirming that it is safe.

Figure 12-3 Reading from a Blinded Table and Writing to a Nonblinded Table

Description of "Figure 12-3 Reading from a Blinded Table and Writing to a Nonblinded Table"

In this example, one source Table instance contains treatment codes and is blinded. The other contains patient data and is not blinded. A Program reads from both Table instances, transforms data, and writes to two Table instances. One target Table instance, VAD1, combines patient data with treatment codes and must be blinded. However, target Table instance VAD2 does not include any treatment code information and does not need to be blinded.

Only users with Blind Break privileges can run PROG_VAD on real data as long as either Table instance TRT or VAD1 has a Blinding Status of Blinded. If the Blinding Status of both of Table instances changes to Unblinded, then users with Read Unblind privileges as well as those with Blind Break privileges can run PROG_VAD.