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
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:
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. |
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. |
LOV |
persons |
persons |
LIST OF VALUES |
LOVs use the collection name as a page name |
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.
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:
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.
Template and Use Case | Context-Based Condition | Role-Based Condition | Tag | Evaluation | ||||
---|---|---|---|---|---|---|---|---|
List of Values |
Not Applicable |
Not Applicable |
Not Applicable |
|
||||
Search Object (List and Table) or View and Edit Object List Template |
Not Applicable |
Applicable |
Not Applicable |
|
||||
View and Edit - Recursive - create object from search object page |
Not Applicable |
Applicable |
Not Applicable |
|
||||
View and Edit - Recursive - view or edit object from search object page |
Applicable |
Applicable |
Not Applicable |
|
||||
View and Edit - Recursive - view or edit object detail from (tab) view and edit object page |
Applicable |
Applicable |
Applicable |
|
||||
View and Edit - Hierarchical Recursive Template - add object detail from (tab) view and edit object page |
Applicable |
Applicable |
Applicable |
|
||||
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 |
Applicable |
Applicable |
|
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
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.
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.
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 |