Property
A property is a data structure that represents the most granular level in UI. A component consumes one or more properties. The usage of a property is within the context of the component, for example, the result component defines which properties are shown in 'set 1' or as a title. Similarly, for a quick search component a property forms a search criterion.
Properties have the following settings:
| Setting | Mandatory | Description |
|---|---|---|
name |
yes |
Name of the property. This needs to correspond the name of the field in Rest API on the resource |
sequence |
yes |
The order in which the property is applied in the component. Properties are applied in ascending order of the sequence |
display |
no |
Indicates when the property should be displayed |
label |
no |
key to boilerplate key, use to override the default boilerplate text |
mandatory |
no |
When set to true indicates the property should be treated as mandatory |
readonly |
no |
When set to true indicates the property is read only even in create mode. |
nonupdatable |
no |
When set to true indicates the property cannot be updated once saved |
default |
no |
Applicable for boolean, enum, string, numeric, and referenced property properties |
filter |
no |
Applicable for referenced property and enums |
refType |
no |
The LOV page to be used for-Selecting or changing values in Create and Edit mode -Displaying reference properties as descriptors in the View mode. |
displayType |
no |
Indicates how a property should be displayed. The following options exist per displayType
1. Object - This is applicable for special properties that have Object type as metadata and XML, JSON data
|
evaluateConditions |
no |
list of conditions that must be evaluated when the property value changes. |
setToNull |
no |
used along with conditional display. If the display is set to never, the system considers setToNull setting to determine if the value of the property should be set to null or not when the property is hidden in the UI. |
properties |
no |
To show additional descriptive columns, a property can refer to nested properties , e.g. multivalue list, reference properties. These reference properties will shown as separate fields in the page, separate from properties used by in the LOV |
"properties":[
{
"name": "name of the property",
"sequence":"",
"display":"",
"label": "",
"mandatory":""
"readonly":
"nonupdatable":
"default":
"properties":[]// Property can have nested properties e.g. multi value list, reference properties
}
]
| Nested properties must be defined as array of the top level property. That is a new array element from top level must not be created per nested property. |
Sequence
If more than one property is used, the sequence will determine the order in which the properties are displayed by the component.
"properties":[
{
"name":"benefitsInputDate",
"sequence":1,
..
},
{
"name":"benefitInputAmount",
"sequence":2,
..
}
]
The sequence attribute together with the type of the property (in relation to the resource) single value resource property, reference property, object, array determines the display of the property in the UI. Every property must specify a sequence attribute. Properties without a sequence number are given the lowest priority. The display order of the property can influence the label that is used in the UI. Refer to the section 'Boilerplate' for more details.
Display
For every property, the setting 'display' is available to indicate when the property should be displayed. This setting supports three options:
-
Always ("display":"always") - considered as default setting when this property is not specified
-
Never ("display":"never")
-
Only with value ("display":"notNull")
In the example below, field 'benefitsInputDate' is only displayed if the object has a value populated:
"properties":{
"benefitsInputDate":{
"display":"notNull"
...
}
}
Mandatory, Readonly, and Nonupdatable
These attributes facilitate customization of the property in a form (region component) or table (table component).
The readonly and non updatable setting can only be made more restrictive at floor plan level. e.g, a non restricted field can be set to be readonly or nonupdatable true. These settings do not override metadata information i.e. a readonly field (as per metadata) cannot be made editable by setting readonly as false.
The setting mandatory can be use to override behaviour of a field at UI level. A mandatory field can be made non-mandatory from UI or vice versa However please note that setting a mandatory field to be nonmandatory does not surpass any mandatory data check when data is stored in the database.
Default
A default value can be specified for string, number, boolean, enums, and referenced properties.
| Property Type | Sample configuration |
|---|---|
String |
"default":"mystringdata" |
Numeric |
"default":123.12 |
Enum |
"default":"code of the enumeration", so if an enum is defined as A-Active, I-Inactive; to set default as Active, the property must be configured as "default":"A" |
Boolean |
"default":true or false |
Referenced Property |
"default":"record id" |
Type of a Property
The rendering and behavior of a property in the UI is based on the field type in the REST API and the consuming component. For details on the property types refer to the Metadata (openAPI specification).
Every property supports view and edit. Depending on the state of the object and the consuming component, the property is rendered in the UI. Object state is driven by the user actions, for example, action 'Create' opens the object in the create state and all the object properties are thereby shown in the edit mode.
There is however an exception to this rule. Some of the object properties cannot be created by a user, such properties are rendered non editable within the component (example Region Component, Table Component) when the object is the 'Create' state. Likewise, some of the object properties are restricted for updates (example claim form on claim), and therefore cannot be updated by a user, such properties are displayed as read only when object is in 'Edit' state. Object metadata specifies which properties are editable and which are not for a given state of the object. Note that this exception does not apply to components that are used to filter and search object list. These components always show the properties in the edit mode.
Sort component, always displays the label of the property.
Single Value Properties
The single value fields are displayed with the attribute name and value within a component. Every record is displayed on a separate line.
| REST API Field Type | Read mode | Edit mode | Note |
|---|---|---|---|
Enum |
Text |
Radio buttons, checkbox or dropdown list based on display type |
Domain values are shown. In the region and filter component based on display type when specified (radiobutton, checkbox or dorpdown):
In the region and filter component, if the display type is not specified then the enum is displayed based on its nature (mandatory/optional).
When an enum is used in advanced search component it is shown as a drop down list with additional value null (no value), by default null (no value) is selected. When an enum is used in the table component it is always shown as a drop down list. If the enum is optional then an additional value null (no value) is available and is selected by default null (no value) if no default is specified in the floor plan. When an enum is used in the region, it is not possible to set display type as checkbox. For create form (create object mode) in region and table component, if a default is specified for the property in the floor plan then that is set. Note that domain code is set as default value and domain value is shown in the UI. |
String |
Text |
Textarea or input text box, along with a possiblity to open a editior for Xml, Json, or Groovy text. The editor can be specified by setting appropriate displayType |
If the size exceeds 100 characters it is recommended to use textarea as displayType allowing user to add multi-line text within the page i.e. without using the text editor In edit mode, the value entered is validated for maximum as specified by the metadata. For create form (create object mode) in region and table component, if a default is specified for the property in the floor plan then that is set. |
Integer |
Text |
Input number |
The value is restricted by the min/max range as specified by metadata. The format used for numbers is as specified by the numberFormat of the defaultCountry from userinformation IP. Example, if it metadata specifies the min/max range as -99.99 to 99.99, the the number value '8' is shown as '8.00'. In edit mode, the value is restricted by the min/max range as specified by the metadata. For create form (create object mode) in region and table component, if a default is specified for the property in the floor plan then that is set. |
Date |
Text |
Input date picker |
Date is formatted according to locale. The Date is formatted according to the primary date format of the default country. If the primary date format is not specified for teh default country, then the system defaults it to 'DD-MM-YYYY'. |
Date time |
Text |
Date time picker |
The Date is formatted according to the primary date format of the default country. If the primary date format is not specified for teh default country, then the system defaults it to 'DD-MM-YYYY:HH:MM:SS'. |
Boolean |
Checkbox |
Checkbox or Dropdown |
In advanced search, booleans are shown as drop down with values - Null (no value), Yes and No. By default Null (no value) is selected. For create form (create object mode) in region and table component, if a default is specified for the property in the floor plan then that is set. |
OHI Money |
Money |
Money |
The amount value is restricted by the min/max range as specified by the metadata with precision set to 4 decimal places. For example a currency field is displayed as - Currency Display Code + ",0.0000". |
Flex code definition based properties |
Text |
as Reference Property |
|
Single value dynamic fields |
Text |
Based on the type either textbox/textarea or inputnumber or date |
|
Single value non time valid dynamic record |
multivalue |
Single value dynamic record is considered as multi value property. Refer to the section on multi value properties for details. |
|
Ref |
RefType |
RefType |
See the section of reference properties. |
Money Properties
View Mode
A money object is displayed with its currency code and value displayed
on the same line. The amount is always right aligned. The currency is
displayed on the left side of the amount.
Edit Mode
The Currency field is non-editable if only one currency is configured, the amount field itself can be changed. If multiple currencies do exist, a drop down list is presented with the default currency preselected.
*Money Property in Table*
The money property is shown in the table view as depicted in the picture below:
View Mode
Edit Mode
XML, JSON, Groovy Editor
By setting appropriate display type, an XML, JSON or Text editor can be used to view or edit a string property or an object property that hold XML, JSON, so formatted string data e.g. CSV .
When a display type is set to file or composite or json or xml, next to the string text area, an notepad icon is shown. On clicking of the icon appropriate editor opens in a pop-up window. Button 'Apply', and 'Close' are show in the edit mode. Button 'Close' is shown in the view mode.
For more complex types, setting display type as composite makes it possible for a user to select appropriate editor (drop down - Text, XML, JSON) in the pop-up at the time of display. By default the data is displayed as Text.
Selecting action 'Apply' triggers data format validation for XML and JSON editors. If the data format is correct the pop-up closes and the property value is updated.
Reference Properties
Some properties are not a literal value, but are a reference to a another resource. These properties are called Reference properties
In the floorplan a reference property requires additional information on how it is to be displayed. This information can be provided by means of a reference type (refType). Within the Reference type you can provide the search properties, title properties and popup tail properties that the reference type will provide
The structure of a reference property is given below:
"properties": [
{
"name":"name of the reference property",
"sequence":1,
"display":"",
"default":"record id",
"properties":[
...
]
"refType":{
"criteriaMandatory":true|false
"type": "standard reference types e.g. person, provider, procedure etc.","filter":"",
"filter":"filter condition"
"deeplink": "pagename"
}
]
Specifying "criteriaMandatory" as true restricts a user from performing a blank search. When not specified system considers it to be false.
Structure of LOV floorplan template
{
"search":{
"propertySelection":"true|false"
"properties":[
...
]
},
"title":{
"properties":[
...
]
},
"popupTail":{
"properties":[
...
]
}
}
-
propertySelection - When set to true, only the first property (having the lowest sequence) will be enabled for search. The other properties can be 'Switched on' for search with the gear icon. When set to false or not specified, search is enabled on all the properties and no gear icon is shown.
-
search - List of all the properties that can be searched on in the LOV.
-
title - The fields that are shown in view mode, and in create/edit mode when the a value has been selected. The first property will be shown inside of the LOV box, the subsequent values will be shown after the LOV box concatenated by ',' commas.
-
popupTail - Additional properties that are required to be displayed for the selected record. Refer below image for an artist impression.
Results The search results show all the distinct Title and Search properties. The title property with sequence 1 and 2 are shown separated by a comma. If there are more properties with higher sequence, then they are shown in the subsequent row as Label - Value. Any search property that is not part of the title is also shown as Label - Value (after all the title properties).
Nested Properties
In addition, a reference property can define nested properties, these nested properties are displayed below the reference property as read only. The sequence attribute is used to determine the order of the property placement.
It is also possible to define a reference property with only nested properties. Consider the following example
"properties": [
{ "name":"" paymentReceiverProvider",
"sequence":1,
"display":"notNull",
"properties":[
{
"name":"code",
"sequence":1
}
]
}
]
Default
Default value can be set in region and table component for referenced fields. The system selects the record given by the record id as default value.
Deeplink
It is possible to create deeplinks to reference property detail page by setting the property "deeplink" and the pagename to deeplink it to. This property effects the referenced property view mode settings. In the view mode, when deeplink is configured the property value gets displayed clickable link. On click, it takes the user to 'View and Edit-Hierarchical' View as referenced by the pageName.
Note that floorplan conditional loading is applied in the selection of the most approiate floorplan.
Filter
The setting 'Filter' takes in criteria that is executed for all the searches as 'and' condition. This limits the result set on which the search is performed. The filter conditions can be set using HTTP Query API grammar.
Filters can be set on fixed values, example on function dynamic logic filter out only the signatures that have subtype 'COND' can be set up as signature.subtype.eq('COND'). Similarly, specifying filter as 'signature.name.eq('Classification Scheme (Claim)').and.signature.subtype.eq('COND')' will limit the LOV’s result set to the dynamic logic of type condition and name ''Classification Scheme (Claim)
Filters can also refer to information from the page’s parent (topmost level) resource. The page’s top level resource can be referenced using the keyword 'context'. While using context, a special construct $\{context.propertyName} must be used. This construct replaces the value of the property in the actual query. For Example, restricting the list of group accounts in an LOV on the group client bill allocation page so that the LOV shows only the group accounts are already attached to the group client can be specified as 'groupClient.code.eq($\{context .code}), in this case the context is groupclient
Example : Suppose the property servicedMember on the resource Claim is declared as :
{
"properties": [
{
"name":"servicedMember",
"sequence": 1,
"refType": {
"type":"person"
}
"properties": [
{ "name":"dateOfBirth",
"sequence": 1
},
{ "name":"gender",
"sequence": 2
}
]
}
]
}
In this case, the system displays LOV for serviced member as defined by reference type - person, system also shows additional attributes - date of birth and gender - for the serviced member.
Reference to a Reference Property
It is possible to search on or display attributes of another ‘reference property’ from a reference property, for example - showing ‘Bank Account Number’ for a Payment receiver (Provider) in details for object Claims requires LOV template to be set up as:
{
"search": {
"properties": [
{ "name":"code",
"sequence": 1
},
{
"name":"flexCodeDefinitionCode",
"sequence": 2
}
]
},
"title": {
"properties": [
{ "name":"code",
"sequence": 1
},
{ "name":"name",
"sequence": 2
}
]
},
"popupTail": {
"properties": [
{ "name":"flexCodeDefinitionCode",
"sequence": 1
},
{ "name":"bankAccountNumber",
"sequence": 2,
"properties": [
{ "name":"bankAccountNumber",
"sequence": 1
}
]
}
]
} }
| Above JSON is also an example when a reference implementation of 'provider' is not used. |
Along with the bank account number, if the bank name must be shown then the bankAccountNumber property must be declared as:
"popupTail": {
"properties": [
{ "name":"flexCodeDefinitionCode",
"sequence": 1
},
{ "name":"bankAccountNumber",
"sequence": 2,
"properties": [
{ "name":bankAccountNumber,
"sequence": 1
},
{ "name":bank",
"sequence": 2,
"properties": [
{ "name":"name",
"sequence:: 1
}
]
}
]
}
]
}
A reference property may also refer to a multi value property. It is possible to show the details of a multi value property. A multi value property is shown in the details as described in the section multi value property having display type as multi value.
Reference Property and Quick Search Component
It is necessary to specify the exact attribute of the reference property (nested property) on which the search must be performed. Quick search component therefore takes in only the nested property structure of the reference property
Reference Property and Advanced Search component
In advanced search, if a reference property included reftype, then it is always shown in the edit mode (LOV). It is also possible to add additional attributes of the reference property. Each attributes (nested properties) that are specified form separate search criterion and are shown based on their type. Refer single value property section for details.
For the LOV, the additional title properties are not shown next to the text area once the object is selected.
Reference Property in Table Component
The following applies to a reference property in the table:
-
The nested properties are shown under separate columns next to the LOV.
Consider the below JSON to clarify: resource tagTypeMessageList
{
"columns": {
"properties": [
{ "name":"message",
"sequence": 1,
"refType": {
"type":"messages"
},
"properties": [
{ "name": "message",
"sequence": 1
}
]
}
]
}
}
The message property will be displayed as shown in the image below:
Enable LOV on any String, Number and Date
To enable LOV on any string, number or date property, the refType setting must be used. The system selects the LOV floorplan based on refType type settings. The title property with sequence 1 gets persisted as value of the property on this LOV is enabled.
Note that, in the view mode, LOV gets the values by using query API on the resource as specified in the floorplan table. Additional properties and the pop-up tail are only possible if the title property with sequence 1 is also the unique key for the collection. That is, if only one record is returned is for the specified value then in the view mode (when configured) additional properties and the pop-up the tail are shown.
Example: To enable LOV on a dynamic field "field1" to show a list of persons, see JSON below.
{
"properties": [
{ "name":"field1",
"sequence": 1,
"refType": {
"type":"mypersonLOV"
}
}
]
}
The system selects the LOV floorplan based on refType type settings. Here the type "mypersonLOV" refers to the pagename in the floorplan table.
When "mypersonLOV" template gets configured as below, then the system persist the code of the person that is selected(from the list of value).
{
"search": {
"properties": [
{ "name":"code",
"sequence": 1
}
]
},
"title": {
"properties": [
{ "name":"code",
"sequence": 1
},
{ "name":"name",
"sequence": 2
}
]
}
}
Multi Value Properties
Multivalue properties are an array or object type of properties.
Display Type
A multi value property has an additional attribute, that specifies how a multi value list property will be rendered in the UI within a component. The following values are possible :
| Type | Description | Remarks |
|---|---|---|
combobox |
If a multi value list contains a single property of type referenced, it can be displayed in a combo box. |
Page specific implementation can specify if a certain field should be displayed using displayType as combobox |
multivalue |
To display list record with multiple attributes |
OHI default implementation for all multi value list fields within a component |
For combobox and multivalue display type, the list is sorted on the row id ascending.
Combo Box
If a multi value list contains only a single value of type referenced, it can be displayed in a combo box. Lists with a single attribute can also be displayed on separate lines (as multi value).
View Mode
Label and comma separated list of values.
Edit Mode
A multi select box is shown which allows the user to add multiple values. Every value that is added can be removed from the list using the delete button placed on the value.
In the edit mode a list of value is shown for multiple values to be selected. The property with the sequence 1 as defined in the refType search is used by the multi select box. This property is searched upon and is also displayed.
Example: consider the below json snippet to clarify
"properties": [
{ "name": "claimLineModifierList",
"sequence": 1,
"displayType": "combobox",
"properties": [
{ "name":"modifier",
"sequence": 1,
"refType":{
"type":"codeDescr"
}
]
}
]
This will show a combo box on to add modifiers as shown in the below image.
Note- It is not possible for a user to add values that are not part of the list.
In the view mode only the title property with sequence 1 is shown for each of the selected values.
Multi Value
View Mode
Individual attributes adhere to the single value/reference property design. These attributes are displayed horizontally on the same line. The labels are displayed as the first row in italics.
If the display width of the record attributes exceeds the width of the page real estate, the header displaying the labels is hidden (e.g. 'Amount Check Number Date Ban…'). Upon hovering over the value, the full list is displayed. The overflowing attributes are displayed on a new line thereby avoiding a horizontal scroll bar.
For a reference property, if there are any nested properties#, then they are not shown
Edit Mode
The list is displayed on separate lines. An empty row is shown by default in the edit mode. Subsequently, if a value is populated on the last row for at least one of the displayed attributes, an empty line is automatically added to the list and a delete button is placed next to the row that has just been populated. The delete button is never placed on the last (empty) list entry.
For a reference property, the title is not shown next to the selected value. Also, if there are any nested properties#, then they are not shown.
^#Presentation configuration will prevent such a configuration^
Example: claim diagnoses is a list record with multiple attributes. Therefore it can only be displayed on separate lines.
Example: Modifier as multivalue
Note that single value non time valid dynamic record is considered as multi value property. The following exception applies: new empty (additional) row is not available in edit mode .
The following example shows property representation for claim pend reasons for the object claim:
It is possible to create up to three columns when used with a record. Any additional columns will not be displayed in the UI.
"properties": [
{
"name":"claimPendReasonList",
"sequence": 1,
"properties": [
{
"name":"resolved",
"sequence": 1
},
{ "name":"pendReason",
"sequence": 2,
"refType:{
"type":"pendreasons"
}
}
]
}
]
View representation of this property will show the following:
Label for the property claim line pend reasons is followed by:
-
Label for the property resolve, followed by a checkbox (non-edible), checked if the value is true.
-
Label for the property pend reasons, followed by the value of pend reason code and a popup tail on code, which shows the description.
Multi Value Property and Quick Search Component
It is necessary to specify the exact attribute of the property (nested property) on which the search must be performed. Attribute "display type" is ignored by the quick search component.
Multi Value Property and Advanced Search Component
In advanced search, if multiple properties of a multi value property are included, then each property forms a search criterion and are shown based on their type. Refer single value property/reference property section for details.
Example:
{ "name":"claimPendReasonList",
"sequence": 5,
"properties": [
{ "name":"pendReason"
"sequence": 1,
"refType": "codeDescr"
},
{ "name":""resolved",
"sequence": 2,
"label": "GEN_RESOLVED"
}
]
}
This configuration will result into advanced search with two search criteria displayed as:
Label for pend reason in ClaimPendReason entity |
LOV on pend reason |
Label for Indicator resolve on pend reason |
Yes/No dropdown |
Properties and Validation
Field level validations are applicable in the edit mode when a property is a form field, for example when used in the Region Component. Field validations (client side) are triggered when a user action is performed e.g. action save. Messages resulting from field validation routines are shown directly on the associated form field. A validation can be placed on the attribute field giving immediate feedback to the user with a focus on the related attribute field. The message disappears when the user takes a action on the field - for example, adds a value to a mandatory field - or if the user executes an action in his current workflow (e.g. cancel, save).
Example:
Field validation is displayed when the user tries to save an object with one or more mandatory field values not being populated. Each of the mandatory attribute fields that do not have a value populated will raise an error.
== Boilerplate
This section describes how the properties are ordered and label are shown based on the sequence. The properties are displayed in a column layout, one underneath the other. They are ordered based on the sequence attribute. Consider the various scenarios described below to clarify the labels that are used to identify the properties and the order in which they are displayed.
A property can specify a label (boilerplate key), in that case the label is displayed as per the boilerplate value.
Scenario 1: 'Resource' level properties and Reference property with one nested 'resource' level property
The property start date, claim code, location provider code, service specialty code on the resource claims defined as:
{
...
"properties": [
{ "name":"code",
"sequence": 1
},
{ "name":"startDate",
"sequence": 2
},
{ "name":"locationProvider",
"sequence": 3,
"properties": [
{ "name":"code",
"sequence": 1
}
]
},
{ "name":"serviceSpecialty",
"sequence": 4,
"properties": [
{ "name":"code"
"sequence": 1
}
]
}
]
}
In this case the properties are displayed as specified below:
\{Label for the property Code as defined on the resource Claim} \{value of the code}
\{Label for the property Start Date as defined on the resource Claim} \{value of the start date}
\{Label for the property Location Provider as defined on the resource Claim} \{value of the location provider code}
\{Label for the property Service Specialty as defined on the resource Claim} \{value of the service specialty code}
The properties are ordered based on the sequence number.
View Mode
Edit Mode
Note - Location Provider and Service Specialty are not displayed as LOVs as only the nested properties are defined for them. For LOV to appear the refType type or the elements search and title must be defined.
Scenario 2: Reference property with multiple nested resource level properties
A reference property can refer to more than one properties. In the example below, along with the code, if the flexcode definition of the location provider is also desired, then the flexcode definition is displayed before the service specialty and after the location provider code. This is because, the top level property location provider has higher display order than service specialty. And the code has higher display order than the flexcode definition. The property flexcode definition is shown with the label as defined for it on the resource provider. The system uses label as specified for the reference property for the nested property that has the highest display order and for the other nested properties it uses labels as specified on the referenced resource.
{
"properties": [
{ "name":"code",
"sequence": 1
},
{ "name":"startDate",
"sequence": 2
},
{ "name":"locationProvider",
"sequence": 3,
"properties": [
{ "code":"code",
"sequence": 1
},
{ "name":"flexcodeDefinitionCode",
"sequence": 2
}
}
},
{ "name":"serviceSpecialty"
"sequence": 4,
"properties": [
{ "name":"code",
"sequence": 1
}
]
}
]
}
\{Label for the property Code as defined on the resource Claim} \{value of the code}
\{Label for the property Start Date as defined on the resource Claim} \{value of the start date}
\{Label for the property Location Provider as defined on the resource Claim} \{value of the location provider code}
\{Label for the property Flexcode Definition as defined on the resource Provider} \{value of the location provider flexcode definition}
\{Label for the property Service Specialty as defined on the resource Claim} \{value of the service specialty code}
View Mode
Scenario 3: Reference property with LOV
A reference property can be specified with LOV component. The LOV representation is always shown with the label (for the reference property) as defined on the resource and all the subsequent nested properties are shown with the labels as defined on the referenced. The LOV representation has a higher priority over the display order (as specified by the sequence). OHI recommends that the LOV representation is also given higher display priority over the non LOV representation.
{
"properties": [
{ "name":"servicedMember",
"sequence": 1,
"refType" :{
"type":"person"
},
"properties": [
{ "name":"dateOfBirth",
"sequence": 1
},
{ "name":"gender",
"sequence": 2
}
]
}
]
}
\{Label for the property Service Member as defined on the resource Claim} \{value based on LOV definition}
\{Label for the property Date of Birth as defined on the resource Person} \{value of the date of Birth}
\{Label for the property Gender as defined on the resource Person} \{value of the gender}
View Mode
Edit Mode
Scenario 4: Referenced to referenced
A reference property may refer another reference property, example bankAccountNumber is a reference property on providers. For a payment receiver provider on claim, bankAccountNumber is a reference to reference property.
{
"paymentRecieverProvider": {
"properties": [
{ "name":"code",
"sequence": 1
},
{ "name":"flexCodeDefinitionCode",
"sequence": 2
},
{ "name":"bankAccountNumber",
"sequence": 3,
"properties": [
{ "name": "bankAccountNumber"
"sequence": 1
}
]
}
]
}
}
\{Label for the property Payment Receiver Provider as defined on the resource Claim} \{value of the payment receiver provider code}
\{Label for the property Flexcode Definition as defined on the resource Provider} \{value of the location provider code}
\{Label for the property Bank Account Number as defined on the resource Provider} \{value of the bank account number}
A reference property from a reference property follows the same rules as described in the scenarios above.
Scenario 5: Multi Value (Array/Object) Properties
When an object refers to a property of type Array/Object, the nested properties of the Aarray/Object are shown based on the display type 'combobox' or 'multivalue'.