Floorplan 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 floorplan can contain 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 floorplan will interact
Payload	The payload containing the JSON structure that described how the page described by the floorplan 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)
System ?	Is the floor plan delivered on install?
Enabled?	Indicates if the plan is enabled or not
Enabled for Create?	Indicates if the plan is enabled for create or not

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 floorplan will interact

Payload

The payload containing the JSON structure that described how the page described by the floorplan 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)

System ?

Is the floor plan delivered on install?

Enabled?

Indicates if the plan is enabled or not

Enabled for Create?

Indicates if the plan is enabled for create 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 the collection name as a page name. \{object collection name} If a floor plan is used for sub sections, the page name will 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, e.g.: CodeDescr

Type

Page Name

Resource

Template

Comments

Fixed Page

contracts

VIEW AND EDIT - HIERARCHICAL RECURSIVE

The fixed page uses the collection name as a page name.
\{object collection name}
If a floor plan is used for sub sections, the page name will 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

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, e.g.: 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. e.g. /generic/floorplans?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, e.g. 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/PATCH is used to update the floor plan. Note for system specific plan only the indicator enabled can be modified.
API to delete non OHI 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 "floorplans 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:

Step-1: Get the floor plan with the generic floor plan API.
Step-2: 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.
Step-3: 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, e.g. /generic/floorplans?q=pageName.eq('claims').and.template.eq('SEARCH')

The API is protected by "floorplans 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?

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 use to load claim line messages ( and not the tag assigned to the claim object floor plan).

Once the plans are selected, the system then evaluated 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 lowest priority. The system selects the first plan that satisfies the conditions. Note - 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. OHI recommends to setup a context condition using the properties that are part of the context object state (i.e. 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)

Example - If a context entity/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 accessed by using the accessRoleList object. e.g.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'

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'

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 the 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/object detail scenario all the evaluated floor plans are ordered based on priority and the system selects the first plan that satisfies the condition.

Template and Usecase	Context based Condition	Role based Condition	Tag	Evaluation
List of Values	Not Applicable	Not Applicable	Not Applicable	From the enabled plan, plan with the highest priority is selected
Search Object (List and Table) / 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 is made available to the user for selection
View and Edit - Recursive - create object from search object page	Not Applicable	Applicable	Not Applicable	All the 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 is made available to the user for selection
View and Edit - Recursive - view or edit object from search object page	Not Applicable	Applicable	Not Applicable	All the enabled floor plans are selected Selected floor plans are ordered based on priority For each floor plan context condition and role condition is evaluated The first floor plan that satisfies the condition is selected
View and Edit - Recursive - view or edit object detail from (tab) view and edit object page	Applicable	Applicable	Applicable	All the 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 the enabled floor plans for the object detail page are selected Role based conditions 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	Applicable	Applicable	All the 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 the 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 all the enabled floor plans having indicator enabled for create set to true 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 the applicable floor plans is made available to the user for selection
Search Page (list/table) from View and Edit object page (HR or through object navigation links) View and Edit - Recursive - create object detail from search (detail object) page e.g. going to group account create page from group client or going to create group account product page from group account Note that in case of object navigation links based pages the tag associated with the top level object is propagated to other links	Not Applicable	Applicable	Applicable	All the 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 the enabled floor plans for the object detail page are selected If the object page is not tagged, then all the 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 the applicable floor plans is made available to the user for selection Note: For create/add mode additional filtering on teh field "Enabled for Create?" applies.

Template and Usecase

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) / 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 is made available to the user for selection

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

Not Applicable

Applicable

Not Applicable

All the 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 is made available to the user for selection

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

Not Applicable

Applicable

Not Applicable

All the enabled floor plans are selected
Selected floor plans are ordered based on priority
For each floor plan context condition and role condition is evaluated
The first floor plan that satisfies the condition is selected

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

Applicable

All the 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 the enabled floor plans for the object detail page are selected
Role based conditions 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 the 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 the 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 all the enabled floor plans having indicator enabled for create set to true 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 the applicable floor plans is made available to the user for selection

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

View and Edit - Recursive - create object detail from search (detail object) page e.g. going to group account create page from group client or going to create group account product page from group account

Note that in case of object navigation links based pages the tag associated with the top level object is propagated to other links

Not Applicable

Applicable

All the 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 the enabled floor plans for the object detail page are selected
If the object page is not tagged, then all the 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 the applicable floor plans is made available to the user for selection

Note: For create/add mode additional filtering on teh field "Enabled for Create?" applies.

Use case 1 # Linking of related plans

Consider the following setup to better understating 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**
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	-	-

Code

Resource

Template

Context based Condition

Tags**

SEARCH_CLAIMS

claims

Search Object

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

~**Tags are stored in a separate detail table.~

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 of the plan gets selected after the condition evaluation and the claim is displayed accordingly.

If a user navigates to an object detail such as a claim line, all the floor plans with a tag matching the already selected tag (i.e. 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' will be 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 as well as 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 gets applied.

Code	Resource	Template	Context based Condition	Role based Condition	Tags**
SEARCH_CLAIMS	claims	Search Object	Not Applicable	Not Applicable	Not Applicable
CLAIM_OPERATOR	claims	View and Edit	-	user is not super admin	Operator
CLAIM_SUPERUSER	claims	View and Edit	-	user is super admin	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

Code

Resource

Template

Context based Condition

Role based Condition

Tags**

SEARCH_CLAIMS

claims

Search Object

Not Applicable

CLAIM_OPERATOR

claims

View and Edit

user is not super admin

Operator

CLAIM_SUPERUSER

claims

View and Edit

user is super admin

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

^**Tags are stored in a separate detail table.^

From search claims, two claims floor plans are evaluated, deepening on the user role only one of them will apply 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 tag(s). No additional conditions are required to be setup on the detail object plans.

*Scenario 3 : Multiple detail object plans
*
When user selects to view (edit) or create claim line for a hospital claim, the system selects all the 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 the three options - surgery claim Line, pharmacy claim line and physiotherapy claim line are available.

Code	Resource	Template	Context based Condition	Tags**
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# >= 5000 && context.procedure.coderange ⇐ 8000)	Hospital
PHARMACY_CLAIM_LINE	claimlines	View and Edit	context.procedure.flexCodeDefinitionCode=='PHARMACY' && (context.procedure.coderange >= 4000 && context.procedure.coderange ⇐ 6000)	Hospital
PHYSIOTHERAPY_CLAIM_LINE	claimlines	View and Edit	context.procedure.flexCodeDefinitionCode=='PHYSIOTHERAPY' && (context.procedure.coderange >= 2000 && context.procedure.coderange ⇐ 4000)	Hospital

Code

Resource

Template

Context based Condition

Tags**

SEARCH_CLAIMS

claims

Search Object

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# >= 5000 && context.procedure.coderange ⇐ 8000)

Hospital

PHARMACY_CLAIM_LINE

claimlines

View and Edit

context.procedure.flexCodeDefinitionCode=='PHARMACY' && (context.procedure.coderange >= 4000 && context.procedure.coderange ⇐ 6000)

Hospital

PHYSIOTHERAPY_CLAIM_LINE

claimlines

View and Edit

context.procedure.flexCodeDefinitionCode=='PHYSIOTHERAPY' && (context.procedure.coderange >= 2000 && context.procedure.coderange ⇐ 4000)

Hospital

~**Tags are stored in a separate detail table.
#codeRange is a dynamic numeric field on the procedure~