Data Access Restriction
Access to data in OHI Claims Adjudication and Pricing 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 OHI Claims Adjudication and Pricing 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 in the common features 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 OHI Claims Adjudication and Pricing 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. |
![Data Access Restriction](_images/data-access-restriction-1.jpg)
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 OHI 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 (e.g. 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, i.e. which type of records can be labeled with that access restriction.
The type attribute has a fixed list of values for each place in OHI Claims Adjudication and Pricingome where data access restriction is built in. See table below:
Type | Usage | Detailed in Section |
---|---|---|
Address contact detail |
Restrict access to a person address |
|
Approval limit |
Restrict adjudication of claims based on amount |
|
Brand claim access |
Restrict access to claims of a brand |
|
Claim line unlocking |
Restrict the ability to unlock locked claim lines |
|
Claim message group |
Restrict adding and removing of messages to a claim, bill or claim line |
|
Claim settlement |
Restrict settling and unsettling a claim |
|
Claim unfinalization |
Restrict the ability to unfinalize a claim |
|
Data access group claim & authorization access |
Restrict access to claims and authorizations of a data access group. |
|
Diagnosis display |
Restrict display of a diagnosis in a claims context |
|
Dynamic field usage |
Restrict access to dynamic field and record usages |
|
Financial hold |
Restrict the ability to record and release a financial hold |
|
Function (ADF) |
Restrict access to a UI page. |
|
Function (JET) |
Restrict access to a UI page. |
|
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 Integration Guide. |
Identifier Type |
Restrict access to Identifiers of a relation or a provider |
|
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. |
N.a. |
Non-address contact detail |
Restrict access to non-address contact details of a person |
|
Payer claim access |
Restrict access to claims of a payer |
|
Pend reason resolution |
Restrict resolution of configured pend reasons |
|
Person details |
Restrict access to a person |
|
Pricing Constructs |
Restrict access to entities that control pricing |
|
Procedure display |
Restrict display of a procedure in a claims context |
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 / 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:
-
( C )reate - 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.
-
( R )etrieve or Read - Records protected by the access restriction can be seen by users with the role.
-
(U)pdate - Records protected by the access restriction can be updated by the users with the role.
-
(D)elete - 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 & 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 |
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.
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:
-
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.
-
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 OHI Claims Adjudication and Pricing. 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.
Non-page functions
The data access restrictions do not apply to non-screen functionality. For example, batch jobs and web services by-pass access restriction. This functionality will normally be run using system user accounts. It is not necessary to give the system user accounts access to all access restrictions.
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.
OHI Claims pages that access the claims transaction repository
Data access restriction is also implemented in OHI Claims Adjudication and Pricing 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.
![Data Access Restriction](_images/enlarge-data-access-restriction-1.jpg)
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
Address Contact Detail Restrictions
This feature allows access to specific person addresses (of at risk individuals) to be restricted. For example, this would apply to individuals that have been granted the right to have their details to be kept secret by the government or otherwise have made such a request.
An access restriction can be applied to each individual address. An address with an access restriction applied can only be accessed by users that have been granted access to that access restriction. Addresses for which a user has no access, are not visible at all. There is no indication that there is a restricted address. It is possible that a person has multiple addresses, of which some are shown and some are not, depending on the access restrictions applied and the privileges of the user accessing them.
Example
User Bob is granted access restriction SECRET_ADDRESS. No access restrictions have been granted to user Pete. The following table shows which addresses they can access.
Person | Postal Code | Address Access Restriction | Accessible by Bob? | Accessible by Pete? |
---|---|---|---|---|
Mary |
1234 |
SECRET_ADDRESS |
yes |
no |
Jane |
1234 |
empty |
yes |
yes |
Susan |
1234 |
TOP_SECRET_ADDRESS |
no |
no |
Inference Prevention
When searching for relations/persons based on address, only addresses a user has access to are used:
-
When user Bob searches for persons with postal code 1234, only Mary and Jane are returned.
-
When user Pete searches for persons with postal code 1234, only Jane is returned.
These restrictions do not apply when relations/persons are searched for without any address search criteria.
Addresses of organizations are not protected. |
Non-Address Contact Detail Restrictions
This feature allows access to specific contact details (of at risk individuals) to be restricted.For example, this would apply to individuals that have been granted the right to have their details to be kept secret by the government or otherwise have made such a request.
A contact details access restriction can be applied to a person.Non-address contact details can only be accessed by users with a role that includes the restriction.Non-address contact details are: business phone number, private phone number, mobile phone number, fax number and e-mail addresses.
When a user views a person with non-address contact details that they are not allowed to see, these details will not be displayed.
Example
User Bob is granted access restriction SECRET_CONTACT_DETAIL. No access restrictions have been granted to user Pete.The following table shows which contact details they can access.
Person | Phone Number Business | Address Access Restriction | Accessible by Bob? | Accessible by Pete? |
---|---|---|---|---|
Mary |
123-456-789 |
SECRET_CONTACT_DETAIL |
yes |
no |
Jane |
123-456-789 |
empty |
yes |
yes |
Susan |
123-456-789 |
TOP_SECRET_CONTACT_DETAIL |
no |
no |
Inference Prevention
When searching for relations/persons, only contact details a user has access to are used:
-
When user Bob searches for persons with phone number business 123-456-789, only Mary and Jane are returned.
-
When user Pete searches for persons with phone number business 123-456-789, only Jane is returned.
These restrictions do not apply when relations/persons are searched for, without any contact detail search criteria.
Person Details Restriction
This feature allows access to details of persons who need special protection to be restricted.Examples for the use of this feature include protection of VIPs, celebrities, and at risk individuals.
It is possible to apply an access restriction to a person to indicate that the person can only be accessed by users with a role that includes the restriction.
When a user searches for relations, protected persons that they are not allowed to see will not be returned at all.
Claims and authorizations or other 'transaction' details related to persons are protected only by concealing the protected person attributes.For example, in the case of a claim for a protected person, the claim may be found by users who cannot see the person’s record but they will not be able to see the person’s relation code, name or any other details from the person record and its direct detail records.
Example
User Bob is granted access restriction SECRET_PERSON. No access restrictions have been granted to user Pete.The following table shows which persons they can access.
Person | Person Access Restriction | Accessible by Bob? | Accessible by Pete? |
---|---|---|---|
Mary |
SECRET_PERSON |
yes |
no |
Jane |
empty |
yes |
yes |
Susan |
TOP_SECRET_PERSON |
no |
no |
Inference Prevention
A restricted person is restricted throughout the whole OHI Claims as if that person does not exist.So if person P is restricted for a user, searching for claims of person P will not return any rows for that user.
Related Entities
When access to a person is restricted, the following details are also restricted:
-
Marital Statuses
-
Person Titles
-
Addresses
-
Relation Tags
-
Bank Account Numbers
-
Assigned Providers
-
Person Covered Services
Identifiers Type
This feature allows access to identifiers of a relation or a provider to be restricted.The identifiers can only be accessed by users with a role that includes the restriction.The identifier types can be of various types such as the social security number, drivers license number etc.
When a user views a relation or a provider with the identifiers that they are not allowed to see, the identifiers will be concealed.
-
Identifiers
When a user searches for the protected identifiers that they are not allowed to see, the identifier will not be returned at all.
Example
User Bob is granted access restriction SECRET_IDENTIFIER. No access restrictions have been granted to user Pete.The following table shows which contact details they can access.
Person | Identifier | Identifier Type | Identifier Access Restriction | Accessible by Bob? | Accessible by Pete? |
---|---|---|---|---|---|
Mary |
123-456-789 |
Social Security Number |
SECRET_IDENTIFIER |
yes |
no |
Jane |
289-68c-180D |
Pan Card Number |
empty |
yes |
yes |
Susan |
*-*-890E |
Driver’s License Number |
TOP_SECRET_IDENTIFIER |
no |
no |
Inference Prevention
When searching on an object with a restricted identifier as search criterion, the object is not returned when the user doesn’t have the appropriate access restrictions for that identifier type.
Related Entities
Not applicable.
Pricing Constructs
This feature allows access to pricing related entities.Access can be restricted on:
-
Bundled Amount
-
Charged Amount
-
Diminishing Rate
-
Fee Schedule
-
Payment Function
-
Pricing Rule
-
Adjustment Rule
-
Dynamic Field Rule
-
Encounter Rule
-
Inclusion Rule
-
Lower of Rule
-
Message Rule
-
Pricing External Intervention Rule
-
Provider Limit Rule
-
Replacement Rule
-
-
Pricing Option
-
Pricing Template
-
Pricing Worksheet
-
Provider Pricing Clause
-
Reference Sheet
When a user searches for one of these pricing elements that they are not allowed to see will not be returned at all.
Example
User Bob is granted access restriction FS_WEST. No access restrictions have been granted to user Pete.The following table shows which fee schedules they can access.
Fee Schedule | Pricing Constructs Access Restriction | Accessible by Bob? | Accessible by Pete? |
---|---|---|---|
FS_West |
FS_WEST |
yes |
no |
FS_General |
empty |
yes |
yes |
FS_East |
FS_EAST |
no |
no |
Inference Prevention
Not applicable.
Related Entities
Whenever a sub-entity is related to more than one parent entity, it is only restricted by the entity where it is listed as a restricted detail. |
When access to a bundled amount is restricted, the following details are also restricted:
-
Bundled Amount Category
When access to a charged amount is restricted, the following details are also restricted:
-
Charged Amount Classification
-
Charged Amount Modifier
When access to a diminishing rate is restricted, the following details are also restricted:
-
Diminishing Rate Block
-
Diminishing Rate Block Amount
-
Diminishing Rate Block Size
When access to a fee schedule is restricted, the following details are also restricted:
-
Fee Schedule Line
-
Fee Schedule Line Classification
-
Fee Schedule Line Modifier
-
Fee Schedule Modifier
When access to a pricing external intervention rule is restricted, the following details are also restricted:
-
Pricing External Intervention Rule Claim Form
When access to a pricing rule is restricted, the following details are also restricted:
-
Pricing Rule Classification
-
Pricing Rule Modifier
-
Pricing Rule Reimbursement Method Type
When access to a pricing worksheet is restricted, the following details are also restricted:
-
Draft Provider Pricing Clause
-
Draft Provider Pricing Clause Dynamic Logic
-
Draft Provider Pricing Clause Diminishing Rate
-
Draft Provider Pricing Clause Claim Classification
-
Draft Provider Pricing Clause Claim Line Classification
-
Draft Provider Pricing Clause Classification Scheme
-
Draft Provider Pricing Clause Restrict Reimbursement Method
When access to a pricing template is restricted, the following details are also restricted:
-
Pricing Section
-
Pricing Section Option
When access to a pricing option is restricted, the following details are also restricted:
-
Partial Provider Pricing Clause
-
Partial Provider Pricing Clause Claim Classification
-
Partial Provider Pricing Clause Claim Line Classification
-
Partial Provider Pricing Clause Dynamic Logic
-
Partial Provider Pricing Clause Restrict Reimbursement Method
-
Partial Provider Pricing Clause Classification Scheme
When access to a provider pricing clause is restricted, the following details are also restricted:
-
Provider Pricing Clause Claim Classification
-
Provider Pricing Clause Claim Line Classification
-
Provider Pricing Clause Classification Scheme
-
Provider Pricing Clause Dynamic Logic
-
Provider Pricing Clause Restrict Reimbursement Method
When access to a provider limit rule is restricted, the following details are also restricted:
-
Provider Limit Height
When access to a reference sheet is restricted, the following details are also restricted:
-
Reference Sheet Line
-
Dynamic Logic Reference Sheet
Sensitive Medical Information Restriction
This feature allows concealing of certain diagnoses and procedures that are considered to be 'sensitive'.Diagnoses and procedure definition records have 'claim display' access restrictions that restrict display of the diagnoses and procedures within the context of claims and authorizations to users with a role that includes the restriction.Note that both claims and authorizations are accessible, only the reference to diagnosis and/or procedure is concealed.
Diagnoses and procedure records in other contexts are not restricted by these restrictions.
Diagnoses and procedures that are configured as dynamic fields are restricted in all contexts in the UI for technical reasons. |
Example
User Bob is granted access restriction SENSITIVE_MED. No access restrictions have been granted to user Pete.The following table shows which diagnoses they can access.
Diagnosis | Display Access Restriction | Diagnosis in claim context accessible by Bob? | Diagnosis outside claim context accessible by Bob? | Diagnosis in claim context accessible by Pete? | Diagnosis outside claim context accessible by Pete? |
---|---|---|---|---|---|
D1 |
SENSITIVE_MED |
yes |
yes |
no |
yes |
D2 |
empty |
yes |
yes |
yes |
yes |
D3 |
TOP_SENSITIVE_MED |
no |
yes |
no |
yes |
For procedure the same example applies. |
A diagnosis is accessed in a claim context when referenced from the entities authorization diagnosis, claim diagnosis, claim line diagnosis and bill diagnosis, either as a fixed or dynamic attribute. |
A procedure is accessed in a claim context when referenced from the entities authorization line, authorization basket (through basket detail), claim line, claim sub line, fee schedule line and provider limit counter, either as a fixed or dynamic attribute. |
Inference Prevention
If procedure P is restricted for a user, searching for claims of procedure P will not return any rows for that user.The same applies to diagnoses.
Division of work / 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.
Brand Restriction
This feature allows access to claims of specific brands to be restricted.
It is possible to apply an access restriction to a brand to indicate that the claims of the brand can only be accessed by users with a role that includes the restriction.
Claims may span products in which case a claim could be of more than one brand.For the purpose of data access security, the claim 'brand code' will be the basis of security.The 'brand code' needs to be provided with claims when they are sent to OHI Claims if this level of protection is needed.
Example
User Bob is granted access restriction VIP_BRAND. No access restrictions have been granted to user Pete.The following table shows for which brands they can access the claims.
Brand | Brand Access Restriction | Claims for brand accessible by Bob? | Claims for brand accessible by Pete? |
---|---|---|---|
VIP Brand |
VIP_BRAND |
yes |
no |
Home Brand |
empty |
yes |
yes |
Some Brand |
SOME_BRAND |
no |
no |
empty |
n.a. |
yes |
yes |
Inference Prevention
When a user searches for claims, claims of brands that they are not allowed to see will not be returned at all.This also applies when searching for one of the related entities.
Related Entities
When access to a claim is restricted, the following details are restricted also:
-
Claim message
-
Claim line
-
Claim bill
-
Claim diagnosis
-
Claim line message
-
Claim sub line
-
Claim line diagnosis
-
Claim line modifier
-
Claim line rule coverage
-
Claim line coverage
-
Claim line benefit specification
-
Claim line provider pricing clause
-
Claims history in claims transaction repository
-
External claims data of both working copy claim and claim transaction
-
Note
-
Policy product
-
Policy family
-
Policy waiting period start date
Change Claim
This feature allows access 'to change' or in other words work on a claim in the status change.Only the users with this access grant can take actions (available for the change status) on the claim.
Data Access Group Restriction
This feature allows access to claims and authorizations of specific data access groups to be restricted.
It is possible to apply an access restriction to a data access group to indicate that the claims and authorizations of the data access group can only be accessed by users with a role that includes the restriction.The data access group needs to be provided with claims when they are sent to OHI Claims if this level of protection is needed.
In the case of authorizations, the data access group attribute is also used. Again, the data access group attribute needs to be provided with authorizations when they are sent to OHI Claims if this level of protection is needed.
Example
User Bob is granted access restriction VIP_GROUP1. No access restrictions have been granted to user Pete.The following table shows for which data access groups they can access the claims.
Data Access Group Restriction | Claims for group accessible by Bob? | Claims for group accessible by Pete? |
---|---|---|
VIP_GROUP1 |
yes |
no |
empty |
yes |
yes |
VIP_GROUP2 |
no |
no |
n.a. |
yes |
yes |
Inference Prevention
When a user searches for claims or authorizations, claims and authorizations of data access groups that they are not allowed to see will not be returned at all.
Related Entities
For claims, see the related entities for the Brand restriction.
When access to an authorization is restricted, the following details are restricted also:
-
Authorization diagnosis
-
Authorization message
-
Authorization line
-
Authorization basket
-
Authorization service type
Payer Restriction
This feature allows access to claims of specific payers to be restricted.
It is possible to select an access restriction for a payer to indicate that the claims of the payer can only be accessed by users with a role that includes the restriction.
The payer code attribute of the claim specifies the payer code. A payer code belongs to a payer.So when a user has access to a payer, this means access to claims of all payer codes of that payer. |
Example
User Bob is granted access restriction VIP_PAYER. No access restrictions have been granted to user Pete.The following table shows for which payers they can access the claims.
Payer | Payer Access Restriction | Claims for payer accessible by Bob? | Claims for payer accessible by Pete? |
---|---|---|---|
Vip payer |
VIP_PAYER |
yes |
no |
Home payer |
empty |
yes |
yes |
Some payer |
SOME_PAYER |
no |
no |
empty |
n.a. |
yes |
yes |
Inference Prevention
When a user searches for claims, claims of payers that they are not allowed to see will not be returned at all.
Related Entities
See the related entities for the Brand restriction.
User Clearance Level / 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.
Approval Limit Restriction
This feature covers restricting the ability of users to adjudicate claims based on the total covered amount in a specific currency.Claim access restrictions are the basis of this feature.Users may only adjudicate a claim if they have a role that includes a permission for a claim access restriction with a value greater than or equal to the total covered amount in a specific currency of the claim.Note that the claim line covered amounts within a claim can be in different currencies, so to adjudicate these kind of claims users need to have a role that includes multiple permissions (for all claim line covered amount currencies on the claim) for a claim access restriction with a value greater than or equal to the total covered amount in a specific currency.
Approval limits can depend on the claim form, so claim access restrictions claim forms can be defined.An approval limit applies for all claim forms defined for the claim access restriction.When no claim forms are defined for a claim access restriction, the approval limit applies to all claims irrespective of the claim form.
Example
Claim access restriction A100 gives rights to adjudicate claims of claim form UB/837I up to a value of 100 $.Access restriction A1000 gives rights to adjudicate claims of claim form UB/837I up to a value of 1000 $.
A100 is granted to Bob.A1000 is granted to Pete.John has no grants.
Approval Limit | Claim Form | Can Bob adjudicate? | Can Pete adjudicate? | Can John adjudicate? |
---|---|---|---|---|
10 $ |
UB/837I |
yes |
yes |
no |
100 $ |
UB/837I |
yes |
yes |
no |
101 $ |
UB/837I |
no |
yes |
no |
Adjudication is restricted by default.A user without any granted claim access restrictions, cannot adjudicate any claim.
Attention has to be paid when combining claim access restrictions without claim form with claim form specific claim access restriction.Take for example the following setup of claim access restrictions:
Access Restriction Code | Approval Limit | Claim Form |
---|---|---|
GEN_50000 |
50000 $ |
|
UB04_50000 |
50000 $ |
UB04 |
GEN_100000 |
100000 $ |
It makes no sense to grant both GEN_50000 and UB04_50000 to the same role, because GEN_50000 covers all claims and thus includes the right to adjudicate claims of claims form UB04.
The sames applies when granting both GEN_100000 and UB04_50000 to the same role. GEN_100000 gives the ability to adjudicate any claim up to 100000 $.This includes the right to adjudicate a 50000 $ claim for claim form UB04.
In other words: claim access restrictions are cumulative.When granting more claim access restrictions to a role, the role becomes more powerful.
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Claim Line Unlocking
This feature provides for restriction of unlocking locked claim lines.
Claim lines are locked when the claim they belong to is unfinalized using a specific unfinalize reason (with the Lock Claim Lines indicator checked).Locked claim lines will not be reprocessed when the claim is sent through the flow again; meaning that all results will be kept.The user can select the specific claim lines that are appealed and that have to be unlocked so they can be reprocessed.This way it is possible to handle appeals on the claim line level.
Claim lines are also locked when the claim or claim line is pended by a specific external intervention rule (with the Lock Claim Lines indicator checked).This way it is possible to gradually add new claim lines to an already processed claim and only process the new claim lines when reprocessing the claim.
The ability to unlock locked claim lines can be restricted to a select group of people.
Example
If a user has an access restriction of type 'UNLOCK' (Claim Line Unlocking), then he is authorized to unlock a claim line.
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Claim Message Group Restriction
This feature provides for restriction of addition and removal of claim-, bill- and claim line messages based on message group.Each message group can be restricted with an access restriction.Any message that is in a group that is not restricted can be added and removed by any user (even if the message is also in one or more restricted groups).Messages not in any group can be added and removed by any user.Users have access to a restricted group if they have a role that includes the restriction of the group.
Any message that is only in restricted groups can only be added to claims, bills, and claim lines by users that have a role with 'create' permission for at least one of the groups that contains the message.Likewise, any message that is only in restricted groups can only be removed by users that have a role with 'delete' permission for at least one of the groups that contains the message.
There are no restrictions on viewing messages.All users can see all messages of the claims that they are allowed to view.
Example
Message Group | Access Restriction | Messages in Group |
---|---|---|
G1 |
empty |
M1,M2 |
G2 |
NONCOVERED |
M2,M3 |
User Bob is granted access restriction NONCOVERED. No access restrictions have been granted to user Pete.The following table shows which messages they can access.
Message | Can Bob add/delete? | Viewable by Bob? | Can Pete add/delete? | Viewable by Pete? |
---|---|---|---|---|
M1 |
yes |
yes |
yes |
yes |
M2 |
yes |
yes |
yes |
yes |
M3 |
yes |
yes |
no |
yes |
M4 |
yes |
yes |
yes |
yes |
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Claim Settlement
This feature provides for restriction of settling and unsettling a claim. After a claim is finalized, a provider settlement may occur which means that a settlement with the provider has been agreed upon.As a consequence, the claim should be prevented from being manually adjusted or further processed.
Claims that are part of a provider settlement are flagged by a settlement reason on the working copy external claims data.The settlement reason can be specified only when the claim is finalized.If a settlement reason is specified, the claim cannot be unfinalized through either the UI or any integration point (Claims In, Claims Reprocessing and Claims Update).
Users who have an access restriction for Claim Settlement can add a settlement reason to finalized claims if at least one settlement reason exists that is linked to that access restriction.Users can remove the settlement reason on finalized claims if they have access to the settlement reason that was used to settle that claim.
Users without access cannot update the settlement reason.Of course, access restrictions for having access to the claims page and having access to a data access group are also evaluated (see example below).
There are no restrictions on viewing claims which are settled.All users can see all details of a claim including settlement information (in the title of the local area).
Example
User | Access to Claim Page? | Access to Data Access Group? | Access to Settlement Reason? | User is allowed to… |
---|---|---|---|---|
John |
yes |
yes |
yes |
John can see the claim and update the settlement reason |
Paul |
yes |
yes |
no |
Paul can see the claim and the settlement reason, but is not allowed to update the settlement reason. |
George |
yes |
no |
yes/no |
George can open the page but is unable to retrieve the claim. |
Ringo |
no |
yes/no |
yes/no |
Ringo cannot open the claims page. |
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Claim Unfinalization
This feature provides for restriction of unfinalizing a claim.After a claim is finalized, a provider may dispute the outcome and make an appeal.If such a appeal is granted, the claim needs to be unfinalized and reprocessed.The ability to unfinalize a claim with a specific unfinalize reason can be restricted to a select group of people.
Users who have an access restriction for Claim Unfinalization can unfinalize claims if at least one unfinalize reason exists that is linked to that access restriction.
Example
If a user has an access restriction of type 'UNFIN' (Claim Unfinalization), then he is authorized to unfinalize a claim using unfinalize reasons that are linked to that access restriction.
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Pend Reason Resolution
This feature provides for restriction of the resolution of configured pend reasons.Some pend reasons, like 'High Dollar Amount' and 'Fraud and Abuse' may only be resolved by a select group of operators.
If a pend reason is restricted, then only users with a role that has a grant for that access restriction can resolve the pend reason through the UI. If a pend reason is not restricted, then all users may resolve that pend reason through the UI. The access restriction has no impact whatsoever on the use of Integration Points, by means of which pend reasons can also be resolved.
There are no restrictions on viewing pend reasons or pend reason history.
Example
User Bob is granted access restriction FRAUD_ABUSE. No access restrictions have been granted to user Pete.The following table shows which pend reasons they can resolve.
Pend Reason | Pend Reason Access Restriction | Can pend reason be resolved by Bob? | Can pend reason be resolved by Pete? |
---|---|---|---|
FRAUD |
FRAUD_ABUSE |
yes |
no |
ABUSE |
FRAUD_ABUSE |
yes |
no |
DUPL |
empty |
yes |
yes |
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Financial Hold Restriction
This feature provides for restriction of recording or releasing financial holds.Financial holds can be recorded on several entities related to financial transactions (like claim or provider) to prevent the financial transactions from being included in financial messages and thus payment.
Example
If a user has an access restriction of type Financial hold, then he is authorized to record or release financial holds.All other users have the possibility to view financial holds.
Inference Prevention
Not applicable.
Related Entities
Not applicable.
Dynamic Field Usages
This feature provides restricting access to dynamic fields and records.If a user has an access restriction of type Dynamic Field Usage, then he is authorized to view and/or update non time valid dynamic fields of the restricted usage and, depending on the access rights, view/create/update/delete dynamic records of the restricted usage..
Example
If a user is authorized to view dynamic records defined on a claim with usage name 'Medical Data', these dynamic records are visible for the user.However, the user is not able to create new, delete or modify dynamic records with usage name 'Medical Data'.
Inference Prevention
When searching on an object (e.g. a claim) with a restricted dynamic field as search criterion, the object is not returned when the user doesn’t have the appropriate access restrictions for that dynamic field.
Related Entities
Not applicable.
In ADF pages, Dynamic field access restrictions are limited to create, update and delete dynamic records. |
Use Cases
This section describes a few end-to-end scenarios, combining several types of restrictions.
Use Case 1: Junior Claims Processor
Mary Smith is a junior claims processor. To be able to do her job, she needs the following capabilities in the system:
-
Inquiry access to all pages.
-
Update access to the manual benefits and manual adjudication pages.
-
Adjust claims.
-
Adjudicate claims up to an amount of 50K.
Because she is a junior, some restrictions are imposed:
-
She cannot see sensitive diagnoses and procedures.
-
She cannot access claims of her colleagues.
-
She cannot remove or add messages of message group ' FATAL'.
As access restrictions in OHI 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
Jane Book is a claims manager. To be able to do her job, she needs the following capabilities in OHI Claims:
-
Inquiry and update access to all pages.
-
View access to Claims Transaction Repository.
-
Adjudicate claims up to an amount of 100K.
-
Ability to see sensitive diagnoses and procedures.
-
Can access claims of colleagues.
-
Can add or remove messages of all message groups.
Jane faces only one restriction:
-
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 Claims 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. |