Floor Plan Loading and Storage

Introduction

Presentation configuration refers to the feature that allows a customer to change certain aspects of a page or application such as the reordering of interface elements, adding new elements, removing or hiding existing elements, adding or removing search criteria and creating multiple views for a page.

The model uses the terms floor plan template and floor plan. Floor plan template is a term used to define a type of view such as Search Object. A floor plan is an instance of a floor plan template used to describe an actual page.

The following aspects of presentation configuration are explained in more detail:

Data model
API use cases
Linking floor plans
Conditional floor plan

Floor Plans

A floor plan contains the following fields

Table 1. Floor Plans
Column Name	Description
Code	The unique code of the floor plan
Description	The description of the floor plan
Page Name	The page name under which the floor plan can be accessed
Template	The template that is followed by the floor plan
Resource	The resource of the floor plan. This links the floor plan to a REST resource with which the floor plan interacts
Payload	The payload containing the JSON structure that described how the page described by the floor plan needs to be rendered
Context based Condition	The context object condition under which the floor plan is used
Role based Condition	The role condition under which the floor plan is used
Priority	The relative priority when evaluating the floor plan conditions (1 means the highest priority, null is least). Custom floorplans have higher priority over system fp irrespective of priority settings.
System ?	Is the floor plan delivered or installed?
Enabled?	Indicates if the plan is enabled or not
Enabled for Create?	Indicates if the plan is enabled for create or not
Auto Include Extensibility?	Indicates if the dynamic fields and record should be auto included or not.

The page name is used in page rendering to select the floor plans. It is important to have naming conventions in place, so the page name can be derived while rendering. The following rules are followed:

Table 2. Rules
Type	Page Name	Resource	Template	Comments
Fixed Page	contracts	contracts	VIEW AND EDIT - HIERARCHICAL RECURSIVE	The fixed page uses collection name as a page name. {object collection name} If a floor plan is used for subsections, the page name shall be: {child object collection name}
DynamicRecord	contracts-recordname	contracts	VIEW AND EDIT - HIERARCHICAL RECURSIVE	In case of dynamic records, page name is constructed based on the object collection name and dynamic field usage name. {object collection name}-{dynamic field usage name}
LOV	persons	persons	LIST OF VALUES	LOVs use the collection name as a page name {object collection name}. There are some exceptions to this rule, where a LOV is not dependent on a single object and represents a view that could be used for multiple objects, for example: CodeDescr

API Use Cases

There are two categories of use cases for the floor plan APIs.

API to get page floor plans: To allow modifications in floor plans, the user needs to fetch all the plans for a page. The generic API is used to get all the floor plans for a page. For example:

POST http://[hostName]:[portNumber]/[api-context-root]/generic/floorplans/search

{
  "resource": {
    "q": "pageName.eq('claims')"
  }
}

API to create new floor plan: This can be used to make a copy and change it or to create a new floor plan from scratch, for example, for dynamic records. Generic POST is used to create a new floor plan.
API to update floor plan: If a user wants to modify an existing floor plan, the update operation is used. Generic PUT or PATCH is used to update the floor plan. For system specific plan only the indicator enabled can be modified.
API to delete non-Oracle Health Insurance specific floor plan: If a user wants to delete a non system specific floor plan, the delete operation is used. Generic DELETE is used to delete the floor plan.

The API is protected by "floor plans API" access restriction. The user needs grants with Read, Create, Update and Delete flags.

Copy Floor Plan

The generic API can be used to copy the floor plan by following these steps:

Get the floor plan with the generic floor plan API.
Change the code, description, condition, system specific and make the JSON payload changes for the new floor plan. Business rules prevent creating, updating or deleting a system specific floor plan.
Send the post request with the above payload.

Page Rendering

Each JET page is based on a floor plan, so when a user opens a page, a floor plan is used to render the page. This use case only requires the read operation. To render a page the user needs to get all the floor plans. The generic query API is used to get all the floor for a page. For example,

POST {apiurl}/generic/floorplans/search
{
  "resource": {
    "q": "pageName.eq('claims').and.template.eq('SEARCH')"
  }
}

The API is protected by "floor plans API" access restriction. The user needs a grant with a Read flag.

Linking Plans

It is possible to link object - object details plans based on 'View and edit Object - Hierarchical Recursive' by using tags.

Table 3. Linking Plans
Field	Description
Floor Plan	The floor plan
Tag	The tag associated to the floor plan
System?	Is the floor plan tag detail delivered on install?
Ind Enabled?	Is this enabled?

A plan can have multiple tags. Only the enabled floor plan tag details are considered for evaluation.

If in the context of an object a floor plan is loaded with an assigned tag, this tag is used to load other (detail objects) floor plans. If the object floor plan is tagged, then the system loads the object details floor plans that meet the tag. If there is no object detail floor plan that meets the tag, then the system selects all the enabled plans.

Similarly, when an object detail plan is loaded with an assigned tag, this tag is used to load its other details floor plan.

To clarify, if the claim object is loaded with a floor plan tagged as 'Professional', then system selects floor plan for the claim line with the same tag (if available). If there is no claim line floor plan with the tag 'Professional', then all the enabled claim line floor plans (irrespective of the tags) are selected. The tag assigned to the claim line floor plan is then used to load claim line messages (and not the tag assigned to the claim object floor plan).

Once the plans are selected, the system then evaluates the plans based on conditional floor plan loading as explained in the subsequent section Conditional Floor Plan Loading.

Conditional Floor Plan Loading

Two types of conditions are supported on the floor plans based on the View and Edit - Hierarchical recursive template

Context based Condition
Role based Condition

The system fetches all enabled floor plans for the specified page name and tag (when available). The floor plans are ordered on their priority ascending, with null values being the lowest priority. The system selects the first plan that satisfies the conditions.

Context based condition is not evaluated while loading plans for 'create object (or object detail)' use case.

Context based Condition: Conditions based on the context object, the context object is the data object that is currently being used or worked upon in the page.
The context based condition can be setup using characteristics of the context object. Oracle Health Insurance recommends to set up a context condition using the properties that are part of the context object state (that is, all the properties that are configured in the template) on the client.
It is also possible to access reference properties, if this information is not already available in the context object state, an additional GET request is used to get the information. The additional requests may add a performance overhead. To clarify, in the claims view-edit page, the claim is the context object and the condition can only be dependent on the claim object. The context based condition is evaluated while loading the plans for viewing the object (or object detail)

For example - If a context entity or object has the fields code, description, subtype. There can be two subtypes of entity TYPE1 and TYPE2. The following condition can be used to select the plan for TYPE1 subtype:

condition : context.subtype === 'TYPE1'
Role based Condition: Conditions based on user role. The user role details can be accessed by using the accessRoleList object.
For example accessRoleList.code === 'Admin' , this conditions returns true if the logged-in user has 'Admin' role.

Condition Grammar

Floor plan conditions can be specified using Javascript and supports the following operators:

Table 4. Condition Grammar
Operator	Description	Syntax
=== or ==	Equal comparison operator, checks if left operand is equal to right operand	context.code === 'PCP1'
!== or !=	Not equal comparison operator, checks if left operand is not equal to right operand	context.code !== 'PCP1'
>=	Greater than equal to operator, checks if left side operand is grater than equal to left side	context.sequence >= 10
>	Greater than operator, checks if left side operand is grater than left side	context.sequence > 10
<=	Less than equal to operator, checks if left side operand is less than equal to left side	context.sequence ⇐ 10
<	Less than operator, checks if left side operand is less than left side	context.sequence < 10
&&	And operator, Performs logical and operation between left and right side operand.	context.code === 'PCP1' && context.sequence >=10
Or operator	Performs logical or operation between left and right side operand.	context.code === 'PCP1' or context.sequence >=10

Linking and Loading of Floor Plans

The table below summarizes when and which conditions are evaluated and when the tags are applicable for floor plan selection.

For create object or object detail scenario all the evaluated floor plans are made available to the user for selection.
For the view and edit object or object detail scenario all the evaluated floor plans are ordered based on priority ^[1] and the system selects the first plan that satisfies the condition.

Table 5. Linking and Loading of Floor Plans

Template and Use Case

Context-Based Condition

Role-Based Condition

Tag

Evaluation

List of Values

Not Applicable

From the enabled plan, plan with the highest priority is selected

Search Object (List and Table) or View and Edit Object List Template

Not Applicable

Applicable

Not Applicable

The enabled plans, ordered by priority are selected
Role based conditions are evaluated
List of all the applicable floor plans are made available to the user for selection

View and Edit - Recursive - create object from search object page

Not Applicable

Applicable

Not Applicable

All enabled floor plans having indicator enabled for create set to true are selected
Role based conditions are evaluated
List of all the applicable floor plans are made available to the user for selection

View and Edit - Recursive - view or edit object from search object page

Applicable

Not Applicable

Select all the enabled floor plans
Selected floor plans are ordered based on priority
For each floor plan context condition and role condition are evaluated
From the evaluated floor plan’s, the one with the highest priority is selected

View and Edit - Recursive - view or edit object detail from (tab) view and edit object page

Applicable

All enabled floor plans for the object detail page with the same tag as on the object page are selected
If the object page is not tagged, then all enabled floor plans for the object detail page are selected
For each floor plan context condition and role condition are evaluated
From the evaluated floor plan’s, the one with the highest priority is selected

View and Edit - Hierarchical Recursive Template - add object detail from (tab) view and edit object page

Applicable

All enabled floor plans having indicator enabled for create set to true for the object detail page with the same tag as on the object page are selected
If object page is tagged but there is no tag entry for detail object page, then all enabled floor plans having indicator enabled for create set to true for the object detail page are selected
If the object page is not tagged, then select all enabled floor plans having indicator enabled for create set to true for the object detail page
Selected floor plans are ordered based on priority
For each floor plan context condition and role condition is evaluated
List of all the applicable floor plans are made available to the user for selection

Search Page (list or table) from View and Edit object page (HR or through object navigation links)

View and Edit - Recursive - create object detail from search (detailobject) page, for example, going to group account create page from group client or going to create group account product page from group account

For object navigation links based pages the tag associated with the top level object is propagated to other links.

Applicable

All enabled floor plans for the object detail page with the same tag as on the object page are selected
If object page is tagged but there is no tag entry for detail object page, then all enabled floor plans for the object detail page are selected
If the object page is not tagged, then all enabled floor plans for the object detail page are selected
Selected floor plans are ordered based on priority
For each floor plan context condition and role condition is evaluated
List of all applicable floor plans are made available to the user for selection

For create or add mode additional filtering on the field "Enabled for Create?" applies.

Tagging information of Policy is used to select "Policy Notes" floor plan

Use Case 1: Linking of Related Plans

Consider the following setup to better understand the concept of linking related plans and selecting which plans to apply based on condition evaluation:

The Claim page is configured with an Institutional and a Dental view - two different floor plans, tagged as Institutional and Dental respectively
The Claim Line page is configured with an Institutional and a Dental view- two different floor plans, tagged as Institutional and Dental respectively
The Claim Messages page is configured with a common view - one plan - applicable to both Institutional and Dental claim views

Table 6. Use Case 1: Linking of Related Plans
Code	Resource	Template	Context based Condition	Tags ^[2]
SEARCH_CLAIMS	claims	Search Object	Not Applicable	Not Applicable
INSTITUTIONAL_CLAIM	claims	View and Edit	context.claimForm.code='INST"	Institutional
DENTAL_CLAIM	claims	View and Edit	context.claimForm.code='DENTAL'	Dental
INSTITUTIONAL_CLAIM_LINE	claimlines	View and Edit	-	Institutional
DENTAL_CLAIM_LINE	claimlines	View and Edit	-	Dental
CLAIM_MESSAGE	claimmessages	View and Edit	-	-

A typical entry point for a user to navigate to a claim is claims search page, from the search page, user then selects a claim to view (or edit). At this instance, system selects all the enabled floor plans for the claim object. The selection is then ordered based on the priority and the conditions are evaluated. The first floor plan that meets the condition is applied. In this case, Institutional Claim and Dental Claim are selected. One plan is selected after condition evaluation and the claim is displayed accordingly.

If a user navigates to an object detail such as a claim line, all floor plans with a tag matching the already selected tag (that is, for the claim) are considered. In this example, if a claim is displayed with floor plan 'Dental', the system selects claim line floor plan that is tagged 'Dental'. Similarly, floor plan 'Institutional Claim Line' is selected if the claim is displayed using 'Institutional claim' floor plan.

At the same time notice how there are no tagged floor plans for the claim line messages. In this scenario the generic floor plan 'Claim Message' is selected for both an institutional and a dental claim.

The key points from this example are:

When opening a page the context and role conditions are evaluated to determine the floor plan to be used
When opening a detail of an object the tagged object detail plans are selected (when available ) otherwise all the (enabled) plans are considered and then the context and role conditions are evaluated.

Use Case 2: Role Based Condition and Linked Plans

Consider the following setup in which there are two floor plans for claim - view and edit are configured. For View and Edit Claim and Create Claim system selects Claim Operator and Claim Superuser floor plan, depending on user role either the super admin or operator plan is applied.

Table 7. Use Case 2: Role Based Condition and Linked Plans
Code	Resource	Template	Context-Based Condition	Role-Based Condition	Tags ^[2]
SEARCH_CLAIMS	claims	Search Object	Not Applicable	Not Applicable	Not Applicable
CLAIM_OPERATOR	claims	View and Edit	-	A role condition can be checked using accessRoleList.code != 'SUPER_ADMIN' && accessRoleList.code == 'CLAIMS_OPERATOR'	Operator
CLAIM_SUPERUSER	claims	View and Edit	-	accessRoleList.code == 'SUPER_ADMIN' && accessRoleList.code == 'CLAIMS_OPERATOR'	Admin
CLAIM_LINE_OPERATOR	claimlines	View and Edit	-	-	Operator
CLAIM_LINE_SUPERUSER	claimlines	View and Edit	-	-	Admin
CLAIM_MESSAGE_OPERATOR	claimmessages	View and Edit	-	-	Operator
CLAIM_MESSAGE_SUPERUSER	claimmessages	View and Edit	-	-	Admin

From search claims, two claims floor plans are evaluated, depending on the user role only one of them applies and is selected, depending on the floor plan that is selected to view the claim object, the detail objects - claim line, claim message floor plans are selected.

The key points from this example are:

While opening a page to create an object, role based conditions are evaluated to filter out the applicable floor plans
Once a role based condition is evaluated for the top level object, subsequent detail object plans can be configured for selection based on tags. No additional conditions are required to be setup on the detail object plans.

Use Case 3 : Multiple detail object plans

When user selects to view (edit) or create claim line for a hospital claim, the system selects all three floor plans - surgery claim Line, pharmacy claim line and physiotherapy claim line. For view and edit use case depending on the procedure code and flexCodeDefinitionCode, the claim line view is applied. For add claim line use case, all three options - surgery claim Line, pharmacy claim line and physiotherapy claim line are available.

Table 8. Use Case 3 : Multiple Detail Object Plans
Code	Resource	Template	Context-Based Condition	Tags ^[2]
SEARCH_CLAIMS	claims	Search Object	Not Applicable	Not Applicable
HOSPITAL_CLAIM	claims	View and Edit	context.claimForm.code=="HOS"	Hospital
SURGERY_CLAIM_LINE	claimlines	View and Edit	context.procedure.flexCodeDefinitionCode=="SURGERY" && (context.procedure.coderange ^[3] >= 5000 && context.procedure.coderange <= 8000)	Hospital
PHARMACY_CLAIM_LINE	claimlines	View and Edit	context.procedure.flexCodeDefinitionCode=="PHARMACY" && (context.procedure.coderange ^[3] >= 4000 && context.procedure.coderange <= 6000)	Hospital
PHYSIOTHERAPY_CLAIM_LINE	claimlines	View and Edit	context.procedure.flexCodeDefinitionCode=="PHYSIOTHERAPY" && (context.procedure.coderange^[3] >= 2000 && context.procedure.coderange <= 4000)	Hospital

1. A lower value is a higher priority, an empty priority is the lowest priority, 0 is the highest priority

2. Tags are stored in a separate detail table.

3. coderange is a dynamic numeric field on the procedure