Data Access Restriction

Access to data in Claims needs to be restricted based on user authorizations for several reasons. These reasons include privacy (secret addresses), sensitive medical information (diagnoses and procedures) and user skill level (adjudicating high-value claims).

This document describes the features that are provided by the Claims data access restriction solution.

Concepts

This section describes general aspects of data access restrictions.

Data access restrictions are based on the use of access restrictions. An access restriction can be specified for a record or item of information to restrict access to it. Access restrictions behave as 'security labels' that can be attached to records. For example:

• The person record of Bob could be labeled with the 'SECRET' access restriction.

• The person record of Jane could be labeled with the 'TOP_SECRET' access restriction.

• The person record of John could have no access restriction specified.

When an access restriction is specified for a record or other information item, that record or information item is said to be restricted. So if records had access restrictions as indicated above, both Bob and Jane would be restricted while John would be unrestricted.

Access labels are implemented as access restrictions of a certain type. For example, for person records, access restrictions of type 'Person details' are used.

See "User Access Restriction Model" page in the User Access chapter of the Security Guide for a complete description of access restrictions and possible types.

A user can only access a restricted item when he has been granted access to the access restriction (via a role). For example, if only the 'SECRET' access restriction has been granted to user Philip, he can access the person record of Bob and John whereas he cannot access the person record of Jane.

The following diagram provides an overview of the end-to-end chain that gives a user access to a record of an Claims entity that is protected with an access restriction.

This diagram is not a data model, but an example of the relations between types of records and objects.

The diagram shows the following:

• The person record of Bob has access restriction SECRET attached. This means that this record is only accessible for users that have been granted access to this access restriction.

• Access restriction SECRET is granted to access role SECRET_ROLE.

• Access Role SECRET_ROLE is granted to user Philip, so Philip has access to records labeled with access restriction SECRET and thus can access the person record of Bob. Because only the Read? indicator is checked, Philip cannot change or remove the person record of Bob.

Related Entities

Records in Claims can be related to multiple detail records. For example: a person has attributes, but also has multiple addresses. In such a situation, the restrictions of the parent record cascade to the detail records; this also holds true for dynamic records: they behave as a child table. So when person Bob has access restriction 'SECRET', the restriction also applies to Bob’s addresses.

For each entity (record type) for which data access restriction is implemented, the restriction also applies to the related entities of that entity. Per restricted entity, the related entities are fixed. See the description of each restriction for its specific related entities.

Protected Items

Access restrictions can also be used to specify access to some groups of items (for example, several specific attributes of a record). An example is Non-Address Contact Detail Restrictions.

Setup of Access Restrictions

The type attribute of an access restriction defines where the access restriction can be used, that is, which type of records can be labeled with that access restriction.

The type attribute has a fixed list of values for each place in Claimsome where data access restriction is built in. See table below:

Type	Usage	Reference Links
Address contact detail	Restrict access to a person address	Address Contact Detail Restrictions
Approval limit	Restrict adjudication of claims based on amount	Approval Limit Restriction
Brand claim access	Restrict access to claims of a brand	Brand Restriction
Claim line unlocking	Restrict the ability to unlock locked claim lines in ADF pages	Claim Line Unlocking
Claim message group	Restrict adding and removing of messages to a claim, bill or claim line	Claim Message Group Restriction
Claim settlement	Restrict settling and unsettling a claim	Claim Settlement
Claim unfinalization	Restrict the ability to unfinalize a claim	Claim Un-finalization
Data access group claim and authorization access	Restrict access to claims and authorizations of a data access group.	Data Access Group Restriction
Diagnosis display	Restrict display of a diagnosis in a claims context	Sensitive Medical Information Restriction
Dynamic field usage	Restrict access to dynamic field and record usages	Dynamic Field Usages
Financial hold	Restrict the ability to record and release a financial hold	Financial Hold Restriction
Function (ADF)	Restrict access to a UI page.	Function Access Restriction
Function (JET)	Restrict access to a UI page.	Functional Access Restriction (JET)
HTTP	Restricts access to integration points and operations
HTTP API	Restricts access to generic api	For details refer to HTTP API Data Access Restrictions in the Security Guide.
Identifier Type	Restrict access to Identifiers of a relation or a provider	Identifiers Type
Item	Restrict access to an item (field or button). NOTE: Individual items do not support access restriction by default. Access restriction on item level has to be added using UI customization.
Non-address contact detail	Restrict access to non-address contact details of a person	Non-Address Contact Detail Restrictions
Payer claim access	Restrict access to claims of a payer	Payer Restriction
Pend reason resolution	Restrict resolution of configured pend reasons	Pend Reason Resolution
Person details	Restrict access to a person	Person Details Restriction
Pricing Constructs	Restrict access to entities that control pricing	Pricing Constructs
Procedure display	Restrict display of a procedure in a claims context	Sensitive Medical Information Restriction
User Credentials	Restrict retrieval of the userLogin and alternate_user_id in the context of a user.	User Credentials Restriction

For each restriction type, multiple access restrictions can be defined. It is not possible to define an access restriction that applies to multiple restriction types. So when the Address restriction type and the Person restriction type both should have an access restriction 'Secret', two different access restrictions need to be defined. See the following table for an example:

Restriction	Access Restriction Code
Address Contact Detail	ADSECRET
Person Details	PERSECRET
Person Details	VIP

Granting Access Restriction or CRUD Matrix

Access restrictions are assigned to roles using an access restriction grant. In an access restriction grant, Create, Retrieve, Update and Delete (CRUD) indicators can be set. The CRUD indicators in general have the following meaning:

• Create - Records protected by the access restriction can be created by the users with the role. In addition, existing records can have the access restriction applied to them by the users with the role.

• Retrieve or Read - Records protected by the access restriction can be seen by users with the role.

• Update - Records protected by the access restriction can be updated by the users with the role.

• Delete - Records protected by the access restriction can be deleted by the users with the role.

Granting of create, update and/or delete rights without retrieve rights is not allowed. If none of the CRUD rights are selected, the grant on this Access Restriction is effectively disabled.

The record to which the access restriction is directly linked is not always part of the records protected by the access restriction. In particular in setup pages, users with the right to create or update records in that page will also have the right to link an access restriction, without explicit CRUD grants on that access restriction. For operational data like Persons and Addresses, stricter rules apply.

The following table (the "CRUD Matrix") lists per access restriction type what the CRUD indicators mean, for several types it deviates from or extends the general meaning:

Type \ CRUD indicator	Create grant on access restriction	Retrieve/read grant on access restriction	Update grant on access restriction	Delete grant on access restriction
Address contact detail NOTE: only applies to Addresses of Persons, not of Organizations	may link an access restriction of this type to an Address	can query Addresses with this access restriction	may update Addresses with this access restriction, including the access restriction itself (may change it to another access restriction if create rights on that access restriction)	may delete Addresses with this access restriction
Approval limit	not used	not used (but has to be set to make this grant apply)	may adjudicate Claims whose total covered amount in the specific currency and claim form fit with the setup of a Claim Access Restriction with this access restriction	not used
Brand claim access	may link a Brand with this access restriction to a Claim	can query Claims that are linked to Brands with this access restriction	may update Claims that are linked to Brands with this access restriction, including insert/update/delete of (grand)child entities shown in the Claims page	may delete Claims that are linked to Brands with this access restriction
Claim line unlocking	not used	not used (but has to be set to make this grant apply)	may unlock Claim Lines (if there is at least one access restriction of this type for which the user has an update grant)	not used
Claim message group	may link a Message of a Message Group with this access restriction to a Claim, Bill or Claim Line	not used (but has to be set to make this grant apply)	not used	may remove Messages of Message Groups with this access restriction from a Claim, Bill or Claim Line
Claim settlement	not used	not used (but has to be set to make this grant apply)	may settle a Claim if there is at least one Settlement Reason linked to this access restriction and can query Settlement Reasons with this access restriction when settling a claim may unsettle a Claim if the settlement reason on the External Claims Data of the Claim is linked to this access restriction	not used
Claim unfinalization	not used	not used (but has to be set to make this grant apply)	may unfinalize a Claim if there is at least one Unfinalize Reason linked to this access restriction and can query Unfinalize Reasons with this access restriction when unfinalizing a claim	not used
Change Claim	not used	not used (but has to be set to make this grant apply)	may update the claim in the status 'Change'.	not used
Data access group claim and authorization access	may link a Data Access Group with this access restriction to a Claim or to an Authorization	can query Claims and Authorizations that are linked to Data Access Groups with this access restriction	may update Claims and Authorizations that are linked to a Data Access Group (old Data Access Group in case that field is being updated) with this access restriction, including insert/update/delete of (grand)child entities shown in the Claims or Authorizations page	may delete Claims and Authorizations that are linked to Data Access Groups with this access restriction
Diagnosis display	not used	no concealing of Diagnoses with this access restriction in the Claims pages	not used	not used
Dynamic Field Usage	may create dynamic records of the specified usage	no concealing of non time valid dynamic fields of the specified usage. time valid dynamic fields and dynamic records of the specified usage are shown	contents of dynamic fields and records of the specified usage may be updated.	may delete dynamic records of the specified usage
Financial hold	may record a financial hold on an entity	not used, all users may read financial holds (but flag has to be set to make this grant apply)	may release a financial hold from an entity	not used, financial holds are never deleted
Function (ADF)	may create new rows in the page linked to this access restriction (regardless of the entity for which a new row is created)	can access the page linked to this access restriction	may update rows in the page linked to this access restriction	may delete rows in the page linked to this access restriction (regardless of the entity for which a row is deleted)
Function (JET)	may create new records in the page linked to this access restriction (regardless of the entity for which a new row is created)	can access the page linked to this access restriction	may update existing record, may create/update/remove rows of the subresource(s) in the page, linked to this access restriction	may delete an existing record (with subresources)
HTTP	may access the integration point. Note - In order to provide access grant, all flags must be set to true
Identifiers Type	may create identifiers of the specified usage	may query restricted identifiers	identifiers may be updated	may delete identifiers
Item	reserved for site level UI customizations	reserved for site level UI customizations	reserved for site level UI customizations	reserved for site level UI customizations
Non-address contact detail	may link an access restriction of this type to a Person	can see non-address contact attributes of Persons with this access restriction	may update non-address contact attributes of Persons with this access restriction and may remove the link of a Person to this access restriction (may change it to another access restriction if create rights on that access restriction)	not used
Payer claim access	may link a Payer Code linked to a Payer with this access restriction to a Claim	can query Claims that are linked to Payer Codes linked to Payers with this access restriction	may update Claims that are linked to Payer Codes linked to Payers with this access restriction, including insert/update/delete of (grand)child entities shown in the Claims page	may delete Claims that are linked to Payers with this access restriction
Pend reason resolution	not used	not used (but has to be set to make this grant apply)	may resolve Pend Reasons with this access restriction	not used
Person details	may link an access restriction of this type to a Person	can query Persons with this access restriction and no concealing of Persons with this access restriction in the Claims pages	may update Persons with this access restriction, including insert/update/delete of child entities shown in the Persons page, and including the access restriction itself (may change it to another access restriction if create rights on that access restriction)	may delete Persons with this access restriction
Pricing Constructs	not used	can query restricted pricing construct elements	may update restricted pricing construct elements	may delete restricted pricing construct elements
Procedure display	not used	no concealing of Procedures with this access restriction in the Claims pages	not used	not used
User Credentials	not used	concealing of LoginName and alternate_user_id in generic users http API	not used	not used

The following table gives an example setup for two Address access restrictions: SECRET and TOP_SECRET and how the CRUD indicators are set for three different roles.

Address Access Restriction	Role 'Secret Read Only'	Role 'Secret'	Role 'Top Secret'
SECRET	R	CRUD	CRUD
TOP_SECRET	not granted	RUD	CRUD

Based on this example setup, the following table shows the different actions these roles can perform using these access restrictions:

Action	Possible for Role 'Secret read only'?	Possible for Role 'Secret'?	Possible for Role 'Top Secret'?	Possible for Other Role?
Create address without access restriction	yes	yes	yes	yes
Retrieve address without access restriction	yes	yes	yes	yes
Update/Delete address without access restriction	yes	yes	yes	yes
Create address with access restriction SECRET	no	yes	yes	no
Retrieve address with access restriction SECRET	yes	yes	yes	no
Update/Delete address with access restriction SECRET	no	yes	yes	no
Create address with access restriction TOP_SECRET	no	no	yes	no
Retrieve address with access restriction TOP_SECRET	no	yes	yes	no
Update/Delete address with access restriction TOP_SECRET	no	yes	yes	no

The access restrictions on Claim Unfinalization and Claim Settlement are of such a nature that the CRUD indicators have no clear meaning. To apply these restrictions, the read and update indicators need to be checked.

Implementation in Entities

Access restrictions are implemented as standard single value attributes.

Usage in Pages and Interfaces

Because access restrictions are implemented as standard attributes, they can be set by interfaces and regular screens like any other standard attribute. In screens, users can only save an access restriction for an access restriction attribute if they have one or more roles that gives them 'Create' access rights for that access restriction. In other words, to be able to label a new or existing record with a specific restriction, a user must have 'Create rights' for the restriction. Through interfaces, no such restrictions apply, interfaces don’t need 'Create' access rights to set an access restriction.

When a record with an access restriction is accessed via a screen, the name of the current access restriction is shown in the inline overflow to inform the user of the security level of the record. In addition, a security indicator is shown in the table row to indicate the presence of an access restriction.

Implementation

For restriction types that restrict access to the whole record, restriction of access is implemented in two different ways, depending on the type of access:

1. Restricted records may be completely hidden from users without read access. This implementation applies when the restricted records are accessed directly. For example, person records can not be seen at all by users without access to them from person search functions.

2. The attributes of restricted records may be concealed. This implementation applies when the restricted records are accessed indirectly as in when they are referred to from other records. For example, claims of these restricted persons could be visible to users who cannot find the person directly; in this case the relation details would be concealed. Non time valid dynamic fields are concealed when access is restricted for the user with access to the record but without access to the dynamic field.

The restriction not only applies to the entity itself, but also to the related detail entities. For example: a reference to a bank account number of a restricted person is also concealed.

The restrictions are implemented consistently throughout the whole Claims. For example, LOV’s are also restricted.

A restriction also applies to the dynamic fields defined for that entity. So when access to a record is restricted, access to the dynamic fields of that record is also restricted.

An attribute is concealed by displaying '**' in the field.

For restriction types that restrict access to a subset of attributes of the restricted record (like Non-Address Contact Detail restrictions), restricted attributes also display '**' in the field. This is done whether or not the attribute actually has a value. Therefore, users will not know if a value is actually present or not.

Inference Prevention

It should not be possible to infer concealed values. For example, if Person Bob has a restricted address with postal code 1234, this address is not to be shown to users that do not have rights for the address. This also applies indirectly, for example, when searching for relations with postal code 1234. Bob must not be found as this would reveal Bobs address. The prevention of inference differs per restriction and is indicated in the 'Inference Prevention' part of the description of each restriction.

Claims Transaction Repository

Data access restrictions are not a factor in determining which details are transferred to the claims transaction repository. Access restriction attributes are included in the repository, giving downstream systems the possibility to choose to impose restrictions. It would be entirely up to downstream systems to implement security based on the access restrictions. In effect, the interfaces between the repository and downstream systems are trusted and it is up to downstream systems to provide protection before giving access to details or passing them on.

Claims pages that access the claims transaction repository

Data access restriction is also implemented in Claims pages that access the Claims Transaction Repository. Exactly the same restrictions that apply when accessing the current version of a claim, apply when accessing past versions of a claim in the Claims Transaction Repository.

Restriction Type Specific Aspects

This paragraph describes each specific restriction type. The following diagram gives an overview of all places where access restrictions are used. Each usage type is described below in a sub-paragraph.

The arrows in this diagram define the 'effect' of access restrictions. For example, an access restriction in a payer restricts the access to claims and related entities. Note that an entity can be subject to multiple restrictions. For example claim is subject to restrictions imposed by the access restrictions defined in data access group, payer and brand (access restrictions defined in diagnosis and procedure play a different role, see sub-paragraph below). When an entity is subject to multiple restrictions, all involved access restrictions must be granted to a user to gain access to that entity.

Example: Claim 1234 has access brand code 'VIP Brand' and access data access group code 'Company ABC'. The brand 'VIP Brand' has access restriction 'VIP_BRAND'. The data access group 'Company ABC' has access restriction 'SECURED_COMPANY'. For a user to be able to access claim 1234, both access restrictions 'VIP_BRAND' and 'SECURED_COMPANY' must be granted.

• Protecting Sensitive Information

• Division of Work or Need to Know (General): These features cover broad filtering of data from users that simply don’t need access to it. For example, this could apply where a separate group of users works on claims of specific data access groups and they have no need to access claims from additional data access groups.

• User Clearance Level or Specialization: These features cover restriction of access to specific information based on the user having a specific clearance level or specific skills. For example, adjudicating claims above a certain amount or other actions that require specific training or clearance.

Use Cases

This section describes a few end-to-end scenarios, combining several types of restrictions.

Use Case 1: Junior Claims Processor (ADF)

Mary Smith is a junior claims processor. To be able to do her job, she needs the following capabilities in the system:

1. Inquiry access to all pages.

2. Update access to the manual benefits and manual adjudication pages.

3. Adjust claims.

4. Adjudicate claims up to an amount of 50K.

Because she is a junior, some restrictions are imposed:

1. She cannot see sensitive diagnoses and procedures.

2. She cannot access claims of her colleagues.

3. She cannot remove or add messages of message group ' FATAL'.

As access restrictions in Claims are role based, one or more roles need to be created. Using the Provisioning Integration Point, these roles are granted to Mary Smith.

Following sections describe the setup needed for the roles.

Access restriction names might be slightly different in the real system.

Inquiry Access to All Pages

Access to a page is given by granting the access restriction of the page to the role. Upon installation, for every page an access restriction is seeded in the system. Read only access can be achieved by only setting the 'Retrieve' indicator. Inquiry access to all pages can be achieved by granting all access restrictions of type 'Function' to a role. However, it is better to create more fine grained roles, to facilitate reuse. So in this example, a role is created per subsystem that gives access to all pages of that subsystem. See table below:

Role	Access Restriction (type=function)	CRUD	Remark
RELATION PAGES READONLY	RelationService	Retrieve	Gives access to the relations menu.
RELATION PAGES READONLY	Persons	Retrieve	Gives read only access to the persons page.
RELATION PAGES READONLY	Organizations	Retrieve	Gives read only access to the organizations page.
RELATION PAGES READONLY	…​	Retrieve	Repeat this for all other relation pages.
CLAIM PAGES READONLY	ClaimService	Retrieve	Gives access to the claims menu.
CLAIM PAGES READONLY	SearchClaim	Retrieve	Gives read only access to the search claims page
CLAIM PAGES READONLY	EnterClaim	Retrieve	Gives read only access to the enter claims page
CLAIM PAGES READONLY	ChangeClaim	Retrieve	Gives read only access to the change claims page
CLAIM PAGES READONLY	ViewClaim	Retrieve	Gives read only access to the view claim page.
CLAIM PAGES READONLY	AdjudicateClaim	Retrieve	Gives read only access to the adjudicate claims page.
CLAIM PAGES READONLY	…​	Retrieve	Repeat this for all other claim pages.
…​			Repeat this for all other sub systems like Foundation, Claims Setup

Both RELATION PAGES READONLY and CLAIM PAGES READONLY need to be granted to Mary Smith.

This more fine grained setup facilitates reuse. For example role RELATION PAGES READONLY can be granted to users that only need access to relations pages.

Update Access to Manual Benefits and Manual Adjudication Page

Two additional roles need to be created, see table below:

Role	Access Restriction (type=function)	CRUD	Remark
MANUAL BENEFITS	ManualBenefits	Create, Retrieve, Update, Delete	Gives update access to the manual benefits page.
MANUAL ADJUDICATE	AdjudicateClaim	Create, Retrieve, Update, Delete	Gives update access to the adjudicate claims page.

Again, these roles need to be granted to Mary Smith.

When manual benefits and manual adjudication are always granted together, one role might be created to reduce the provisioning effort a bit. See alternative setup below:

Role	Access Restriction (type=function)	CRUD	Remark
MANUAL BEN AND ADJ	ManualBenefits	Create, Retrieve, Update, Delete	Gives update access to the manual benefits page.
MANUAL BEN AND ADJ	AdjudicateClaim	Create, Retrieve, Update, Delete	Gives update access to the adjudicate claims page.

Adjust Claims

Claims can be adjusted using the enter claim and the change claim pages. So a new role gives access to this page using the following setup:

Role	Access Restriction (type=unction)	CRUD	Remark
ADJUST CLAIM	EnterClaim	Create, Retrieve, Update, Delete	Gives update access to the enter claim page.
ADJUST CLAIM	ChangeClaim	Create, Retrieve, Update, Delete	Gives update access to the change claim page.

And again this role is granted to Mary Smith.

Adjudicate Claims Up to 50K

To be able to complete an adjudicate action, not only update access to the relevant page is needed, but also the right to adjudicate up to a certain amount. These limits are defined as claim access restrictions:

Role	Claim Access Restriction	Claim Form	Approval Limit	CRUD	Remark
ADJUDICATE_50K	Adjudicate50K_UB	UB	50000	Update	Adjudicate UB claims
ADJUDICATE_50K	Adjudicate50K_ADA	ADA	50000	Update	Adjudicate ADA claims
ADJUDICATE_50K	Adjudicate50K_CMS	CMS	50000	Update	Adjudicate CMS claims
ADJUDICATE_50K	…​			Update	Repeat for all other claim forms.

The preceding sections describe a possible setup to give Mary the required capabilities to do her job. However, she can do more than is allowed, because the restrictions are not implemented. The next three sections describe the setup needed to implement the restrictions.

Restrict Access to Sensitive Diagnoses and Procedures

Access to diagnoses and procedures can be restricted by assigning an access restriction to them:

• The diagnosis 'Drug abuse' has access restriction SENS_DIAG assigned.

• The procedure 'Abortion' has access restriction SENS_PROC assigned.

Only users with a role that includes the access restrictions SENS_DIAG and SENS_PROC can see the sensitive diagnoses and procedures. So the access restriction for Mary can be imposed by not giving such a role to Mary.

Restrict Access to Claims of Colleagues

This restriction can be implemented by creating a data access group and assigning a restriction to it: data access group Employees has access restriction Employees assigned.

When sending claims of own employees to the claims in integration point, the data access group should be set to Employees. Only users with a role that has been granted access to access restriction Employees can access these claims. So the access restriction for Mary can be imposed by not giving such a role to Mary.

Restrict Ability to Remove or Add Messages of Message Group FATAL

Ability to add and remove messages from a group can be restricted by assigning an access restriction to the message group:

• The message group FATAL has access restriction FATAL_MESSAGE assigned.

Only users with a role that includes the access restriction FATAL_MESSAGE can add or delete messages of this group to claims. So the access restriction for Mary can be imposed by not giving such a role to Mary.

Use Case 2: Claims Manager (ADF)

Jane Book is a claims manager. To be able to do her job, she needs the following capabilities in Claims:

1. Inquiry and update access to all pages.

2. View access to Claims Transaction Repository.

3. Adjudicate claims up to an amount of 100K.

4. Ability to see sensitive diagnoses and procedures.

5. Can access claims of colleagues.

6. Can add or remove messages of all message groups.

Jane faces only one restriction:

1. She cannot process claims of colleagues.

The next sections explain the setup needed to support this use case. It is assumed that the setup for use case 1 is also in place.

Inquiry and Update Access to All Pages

Update access can be granted by creating update roles per subsystem, similar to RELATION PAGES READONLY, CLAIM PAGES READONLY. See table below:

Role	Access Restriction (type=function)	CRUD	Remark
RELATION PAGES UPDATE	Persons	Create, Retrieve, Update, Delete	Gives update access to the persons page.
RELATION PAGES UPDATE	Organizations	Create, Retrieve, Update, Delete	Gives update access to the organizations page.
RELATION PAGES UPDATE	…​	Create, Retrieve, Update, Delete	Repeat this for all other updateable relation pages.
CLAIM PAGES UPDATE	EnterClaim	Create, Retrieve, Update, Delete	Gives update access to the enter claims page
CLAIM PAGES UPDATE	ChangeClaim	Create, Retrieve, Update, Delete	Gives update access to the change claims page
CLAIM PAGES UPDATE	AdjudicateClaim	Create, Retrieve, Update, Delete	Gives update access to the adjudicate claims page.
CLAIM PAGES UPDATE	…​	Create, Retrieve, Update, Delete	Repeat this for all other updateable claim pages.
…​			Repeat this for all other sub systems like Foundation, Claims Setup

These new roles should be granted to Jane Book in addition to RELATION PAGES READONLY and CLAIM PAGES READONLY.

View Access to Claim Transaction Repository

One additional role needs to be created, see table below:

Role	Access Restriction (type=function)	CRUD	Remark
VIEW_CTR	ClaimsHistory	Retrieve	Gives read only access to the claims history stored in the claims transaction repository.

Again, this role need to be granted to Jane Book.

Adjudicate Claims Up to 100K

A new role ADJUDICATE_100K needs to be created, similar to ADJUDICATE_50K, and granted to Jane Book. See table below:

Role	Claim Access Restriction	Claim Form	Approval Limit	CRUD	Remark
ADJUDICATE_100K	Adjudicate100K_UB	UB	100000	Update	Adjudicate UB claims
ADJUDICATE_100K	Adjudicate100K_ADA	ADA	100000	Update	Adjudicate ADA claims
ADJUDICATE_100K	Adjudicate100K_CMS	CMS	100000	Update	Adjudicate CMS claims
ADJUDICATE_100K	…​				Repeat for all other claim forms.

Ability to See Sensitive Diagnoses and Procedures

Access to diagnoses and procedures can be restricted by assigning an access restriction to them:

• The diagnosis Drug abuse has access restriction SENS_DIAG assigned.

• The procedure Abortion has access restriction SENS_PROC assigned.

Only users with a role that includes these access restrictions can see the sensitive diagnoses and procedures. So a new role should be created that includes the access restrictions SENS_DIAG and SENS_PROC, and assigned to Jane.

Role	Access Restriction	CRUD	Remark
SENS_MED	SENS_DIAG	Retrieve	Gives access to sensitive diagnoses
SENS_MED	SENS_PROC	Retrieve	Gives access to sensitive procedures

Can Access Claims of Colleagues

Access to claims of colleagues can be implemented by creating a data access group and assigning a restriction to it: data access group Employees has access restriction 'Employees' assigned.

When sending claims of own employees to the claims in integration point, the data access group should be set to Employees. Only users with a role that has been granted access to access restriction Employees can access these claims. See table below for the definition of such a role:

Role	Access Restriction	CRUD	Remark
EMPLOYEE_CLAIM_ACCESS	Employees	Retrieve	Gives read only access to claims of colleagues

Note that only the Retrieve indicator is used. So Jane can see claims of colleagues, but cannot process them.

Can Add or Remove Messages of All Message Groups

Ability to add and remove messages from a group can be restricted by assigning an access restriction to the message group:

• The message group 'FATAL' has access restriction 'FATAL_MESSAGE' assigned.

Only users with a role that includes the access restriction 'FATAL_MESSAGE' can add or delete messages of this group to claims. See table below for the definition of such a role:

Role	Access Restriction	CRUD	Remark
OVERRIDE_ALL_MESSAGES	FATAL_MESSAGE	Create, Retrieve, Update, Delete	All messages in a group labeled with access restriction FATAL_MESSAGE can be added or removed from a claim.

JET

JET application has one function for claims page. To be able to work on a claim (edits) in the status Change, Manual Pricing, Manual Pricing Adjudication, Manual Benefits, and Manual Adjudication the user must have access to operation 'Submit Claim' for a respective status or for 'all' statuses and function access update grant to 'CL0172'. For details refer to Access Restriction for Claims Jet Pages