Introduction	Top

To comply with PII, PHI, HIPAA, and Safe Harbor requirements, and to protect the privacy of individuals, you may need to hide or mask sensitive information from unauthorized Users within LabVantage. Data Masking is a highly configurable solution that automatically determines who is authorized to view sensitive information and who should be shown masked information (based on existing Security measures and policy decisions).

When an unauthorized User is presented sensitive information, LabVantage determines how the information should be displayed to that User.

The example below illustrates a typical Data Masking strategy.

Before you configure Data Masking, consider the following for your organization:

What information is sensitive

Identify the SDCs (such as Subject) that contain sensitive information. Within that SDC, which columns are sensitive (such as birthdt).

How should sensitive information be masked

When presented to unauthorized Users, how should sensitive information be masked. Define different masking techniques (such as ***-**-1234) for each column. Optionally, define different levels or degrees of masking. These Levels can be specified at the SDC or SDI level (such as during Study creation on a Study by Study basis) and therefore determine how Data Masking is applied for each SDI.

OOB, LabVantage provides masking templates you can customize according to your preferences.

Who has the authority to view sensitive information (Un-Mask)

Identify the Users or JobTypes authorized to view sensitive information, and under what circumstances. Visibility Rules identify authorized Users using one of the following methods:

To configure Data Masking within LabVantage you will need to:

Enable Data Masking for an SDC	Top

Before defining Data Masking policy you must first decide which SDCs contain sensitive information. Once decided, you will need to enable Data Masking for those SDCs. Doing so makes the SDCs available in the Masking Policy where you will define Masking Levels, Masking Rules (techniques) and Visibility Rules.

Navigate to System Admin → Configuration → SDCs. The SDC List Page displays. Select an SDC and click "Edit" to open the Edit SDC page.

In the Definition Options detail you will find the "Contains Sensitive Data?" and "Can be Masked?" fields. These are used to enable Data Masking.

Define Masking Policy	Top

Use the MaskingPolicy to configure your Data Masking strategy. Determine the fields within an SDC that contain sensitive information, the techniques for masking that information, and how LabVantage will determine authorized Users (those Users for whom sensitive information will be un-masked).

To define the Masking Policy, navigate to System Admin → Configuration → Policies and choose "MaskingPolicy".

The Global Settings Properties of the Masking Policy determine how Data Masking is implemented throughout LabVantage. These settings determine whether or not sensitive information will be masked, and to whom.

To define a more complex, SDC specific, Data Masking plan choose one of the SDC Visibility Rules and define a Visibility Rule at the SDC level. See SDC Level Data Masking for more information.

Optionally, pre-define different levels of Data Masking (such as highly restricted or minimally restricted) using the Masking Level field. The value selected in this field identifies the level for which the displayed Masking Rules are defined. If no Masking Level is defined (blank), the defined rules are the default, or global Masking Rules. See Define Masking Rules for more detailed information.

These Levels are available when creating SDCs and SDIs, providing the ability to define a different level of Data Masking for an SDC, or on an SDI by SDI basis. For example:

To accomplish this, you will need to define different sets of Data Masking Rules and techniques for each defined level. These levels can then be specified for an SDC (and will default to the SDI), or specifically for an SDI (override the default). LabVantage determines which Masking Level to apply in the following order:

When not defined at the SDC or SDI level, settings defined in the Masking Policy (Sapphire Custom node) are applied.

If you do not intend to define Masking Levels skip to Masking Rules for details about defining Masking Rules and techniques.

Masking Level values (such as High, Medium or Low) are defined as values in the Masking Level Reference Type. High, Medium and Low are provided OOB however you can establish your own Masking Level values.

Each Reference Type links to one Node in the Masking Policy. For each Masking Level (Node) define a different set of Data Masking Rules. See Node Hierarchy for information about defining Nodes.

In the Masking Policy, choose a Masking Level Node (such as High, Medium or Low), and then the SDC and Column. Define the Masking Rules associated with that Masking Level, SDC, and column combination. Leaving the Masking Level blank defines Global Masking Rules.

Select the Node (as defined by the Reference Type Values). Note that the Masking Level field fills with the corresponding Level.

This example defines a High Masking Level for the Subject SDC, "birthdt" column. See Define Masking Rules below for more information about defining Masking Rules.

In the following examples, the Medium and Low Masking Levels are defined for the Subject SDC, "birthdt" column.

Medium Masking Level

Low Masking Level

The Default Masking Level defined for an SDC, determines which Masking Rules to apply when displaying masked data for this SDC. Masking Levels specified at the SDC level default to SDIs.

Optionally, specify a Masking Level on an SDI by SDI basis.

In the example below, each Subject was assigned a different Masking Level. Data is Masked accordingly to unauthorized Users. Note that "Subject 4" was not assigned a specific Masking Level and uses the global settings.

Masking Rules define how data will be masked when presented to unauthorized Users. You might choose to replace all but the last 4 digits of a Social Security Number with an asterisk, or display an age range rather than an individuals actual age.

Masking Rules can be defined in the Masking Policy for each SDC (having the "Contains Sensitive Information?" option checked).

Select the SDC for which you want to define Masking Rules, then "Add" the columns you have identified as containing sensitive information.

Define the following for each column.

All supported Elements will honor the columns configured in the MaskingPolicy.
The following column formats are supported for List and Maintenance Elements:

Field values can be treated as either Text, a Number, or a Date. For each Data Type several Masking Logic templates have been provided OOB. Use the properties below to further define each template. If no Masking Logic properties are defined, sensitive data is masked entirely, with asterisks.

Choose the type of data you are Masking. Masking Properties can be defined for each of the following Data Types:

Determine how Alias data will display when Data Masking is enabled. Field values are treated as Text.

Context specific masking lets you define a column as sensitive when viewed from a specific context. For example, a User with access to the Subject List page should be authorized to see all sensitive information. However, when that User accesses Subject information from a Participant list page (and context specific masking is defined), sensitive information is masked according to the Masking Rules defined for the Participant SDC.

In the Masking Policy select the SDC for which you want to create context specific visibility.

"Add" the Column you want to mask from the associated SDC. In this example, the Subject's Description field (subjectid.subjectdesc) will be masked when Subject information is displayed on the Participant List or Maintenance pages. The Subject's Name is masked using the "ONLY_INITIALS" Masking Logic, defined for the subjectid.subjectdesc column on the Participant SDC. The Subject's name (Subject 3) is displayed as S3.

Note that the Birth Date is masked according to the global masking level, for the Subject SDC.

Define a Visibility Rule	Top

With sensitive information identified, and Masking techniques in place, you can now establish the Visibility Rules to "un-mask" sensitive information for authorized Users.

This section describes how to configure LabVantage to automatically determine which Users are authorized to view sensitive information.

Visibility Rules can be defined at a Global level and applied to all Users, Job Types or Departments, or specifically for an SDC. The Visibility Rule uses the existing Security structure (such as Role, Department Security or SDI Security) to authorize visibility by individuals or groups of Users.

Visibility Rules defined Globally (in the Global Settings properties of the Masking Policy) apply to all Users and SDCs within LabVantage. These rules determine visibility when SDC specific Visibility Rules are not defined.

SDC specific Visibility Rules determine whether or not the current User is authorized to view sensitive information for a specific SDC.

The Access Control field (and associated Security definitions such as SDC Access and Security Sets), combined with the Visibility Rule field, determine which Users can view sensitive information for this SDC.

To configure SDC specific Visibility Rules navigate to System Admin → Configuration → SDCs.

SDC Visibility Rules are defined in the Security/Update Options detail of the SDC maintenance page. When an SDC is marked as Maskable (by checking "Can be Masked?" in the Definition Options detail of the SDC) additional fields become available.

Upon checking the "Can be Masked?" field in the SDC Definition Options detail, the "ViewMaskedData" Operation is automatically added.

When defining Security Sets or SDC Access for this SDC (or a specific SDI) use this Operation to give Users or Job Types the authority to view sensitive information.

Generally, organizations have 2 types of Users. Users who can see sensitive information and users who can not. Access to sensitive information for external Users can differ from Study to Study. As a physician, the same individual could have access to sensitive information in Study A, but as a Research Coordinator, would not have access in Study B. This would require granting that individual a different kind of access for each Study.

Do the following to configure this option:

Example Configuration	Top

The following sections provide example Data Masking strategies and their configuration.

Two Users within the same department work with Subjects. One User is authorized to view and manage sensitive Subject information, the other can see limited Subject information. The following example describes the necessary steps to achieve this scenario.

User 1 is authorized to view sensitive Subject information. He is given this authority by checking the Role "ViewMaskedData" for his User. As an authorized User he can see all sensitive information.

User 2 is not authorized to view sensitive information and is presented limited Subject information.

Configure the following to achieve this simple Masking strategy.

Define the Subject SDC

Since we are viewing the Subject List page in this example, the Subject SDC is configured as follows:

In the Definitions detail define the following:

In the Security/Update Options detail specify the following:

Define the Masking Policy

The Masking Policy is defined with a Global "Role Only" Visibility Rule, "ViewMaskedData" is the defined Role.

Note that the Medium Masking Level for the Subject SDC specifies that the "birthdt" column should display a 10 year age range in place of the Subject's birth date. The "Date" Data Type is used to define the Masking Logic.

In Biobanking, Users within different Departments or organizations might share Participants for use in a Study. Users are authorized to view Participant records for each other's Studies, but are only authorized to view sensitive information within their own Studies.

In the following example, Users 1 and 2 are members of Department 1, and Users 3 and 4 are members of Department 2.

User 1 created Study D1 and enrolled a Participant.

User 3 created Study D2 and enrolled a Participant.

When User 1 is the current User, and views the Participant List page, he is authorized to view sensitive information on the Participant record for Study D1 (Department 1), but shown masked Subject information for the Participant of Study D2 (Department 2).

Configure the following to achieve this Masking strategy.

Define the Participant SDC

Since we are trying to control the visibility of sensitive information when viewing Participants, we will define a Visibility Rule for the Participant SDC.

In the Definitions detail define the following:

In the Security/Update Options detail specify the following:

Define Study Access

During Study creation, each Study Coordinator will determine who can view Masked Data for their Study.

Using the Manage Security Set option (Study List page, Manage Security Set button), for each associated SDC, give each User the authority to view Study, Participant and Sample List pages for this Study. For each User authorized to view sensitive information, also check the ViewMaskedData operation.

User 3 defined the Security Set for Study D2 as follows:

Users 3 and 4 (Users within Department D2) are authorized to "ViewMaskedData". Users 1 and 2 are not (ViewMaskedData operation is not checked).

Define the Masking Policy

The Global Visibility Rule is defined as "SDC Visibility Rule Only". This defers the visibility decision to the SDC.

Since a Masking Level was not defined at the SDC or SDI level the Global Masking Rules are applied.

Advanced Considerations	Top

Before enabling Data Masking review and consider the following:

Data Masking adds the following API processing:

DataSet.getValue:

DataSet.sort:

DataAccessService.createRSetQ

GetSDI[String/Data/Number] actions:

PHI via REST

The LabVantage REST API supports PHI data masking for GET method calls:

Creating Queries that search on columns defined as sensitive in the MaskingPolicy is not recommended. However, if necessary, pre-existing Role based Security can be used to enforce Query access.

Any OOB Queries that allow searching on OOB sensitive columns will be marked with the ViewMaskedData Role. If Data Masking is implemented, simply enable Role based Security on Queries to hide those Queries that search on sensitive columns.

Adhoc Queries

The "Apply Role to Adhoc Queries" property in the Masking Policy will determine visibility in Adhoc Queries. If the current User does not have the appropriate Role (as defined in the "Role" field), the Ad-hoc query tree will disable all those columns marked as sensitive in the MaskingPolicy (Sapphire Custom node). The system will be restrictive in the sense that if a column's maskability is Groovy-based, then Adhoc Query will not allow unauthorized Users to search/display that field.

Global Search

Similar to Adhoc query, Global Search will not index those columns defined as sensitive in the MaskingPolicy (Sapphire Custom node). This is Global and not User-specific. The "Index Sensitive Data" property in the SearchPolicy will be set to "No" OOB, but can be overridden.

Before Enabling Data Masking be sure none of the following applies to fields defined as sensitive: