Configuration phase 2 (Client Registers configuration implementation)

[dubdabasoduba]

What is the vision of the configuration?

• We would like to achieve a configurable register flow that starts from the Navigation drawer to the Client profile.
• This will enable us to configure the following
  • The menu item for a register and when it's displayed on the navigation drawer.
  • The register that opens after the menu above is clicked, the configuration of the data to be displayed on the register.
  • The profile that is opened after the register row is clicked, should also define what is displayed on the profile and the menu actions to be performed on the profile.
• • Previous steps --> Configuration phase 2 (Navigation drawer configuration implementation)

Client Registers configuration

What we want to achieve

• To create a configuration that allows us to define registers using a configuration file. Defining the following attributes are key
  • The main resources the register will display.
  • The accompanying resources for the register e.g for us to show the number of people in a family then we need to also pull the family members tied to the family. This means the Group is the main resource and the Patient is the accompanying resource.
    • We can have multiple accompanying resources.
  • Defining the expressions to filter/aggregate the data for display on the registers

How to achieve the configuration

• This configuration is using the following mock up as the source of truth for the Registers.

1. UI Items Identification

   • Column 1
     • Row 1 (always shown)
       • Sample items
         • Name
         • gender
         • Age
     • Row 2 (can be hidden)
       • Partition1
         • Row 1
           • Sample Items
             • Location/Village
             • Unique Id
         • Row 2
           • Sample Items
             • Last visited dates
             • Service status (Only shown when the button in Row 2 --> Partition 2 is hidden)
       • partition 2
         • sample items
           • Service icons
   • Column 2 (can be hidden)
     • Service count and status button

2. Data load specification

   • Register main resource definition.
     • Here we define the main resource to be fetched and displayed on the register. e.g Patient for anything that displays patients in any health verticals.
   • Register additional resources definition.
     • Here we define the additional resources used to get other information i.e the Column2 --> Service count and status button needs a calculation of tasks. So the Task resource would be part of the other resources list.
   • Register columns definition
     • Column 1 --> Row 1: This is a full-width row that will hold demographic data for the resources in question. Most of the data here come from the main resource mentioned above.
       • This will always be shown.
       • In case this row is showing a combination of attributes then the code has to be able to concatenate it. e.g if the row is showing the Name, Age & gender then the code should be able to combine them as follows "Name-Age-Gender" e.g " John Doe - 32 - Male"
       • The data config pieces should reference the resource --> attribute to fetch.
         • It should also describe the separator for the concatenated data. This is optional since we will have a default separator set up.
     • Column 1 --> Row 2 --> Partition 1 --> Row 1: This is to display additional metadata on the demographics or services
       • This row can be hidden.
       • In case this row is showing a combination of attributes then the code has to be able to concatenate it. e.g if the row is showing the Location & Patient ID then the code should be able to combine them as follows " Location - Patient ID" e.g " Nimba - HH001"
       • The data config pieces should reference the resource --> attribute to fetch.
         • It should also describe the separator for the concatenated data. This is optional since we will have a default separator set up.
     • Column 1 --> Row 2 --> Partition 1 --> Row 2: This is to display additional metadata on the services.
       • This row can be hidden
       • In case this row is showing a combination of attributes then the code has to be able to concatenate it. e.g if the row is showing the Location & Patient ID then the code should be able to combine them as follows " Location - Patient ID" e.g " Nimba - HH001"
       • The data config pieces should reference the resource --> attribute to fetch.
         • It should also describe the separator for the concatenated data. This is optional since we will have a default separator set up.
     • Column 1 --> Row 2 --> Partition 2: This will be used to show the service icons.
       • This partition can be hidden.
       • Service icons will need to be added to the res folder on the flavour.
       • Then we will need to define a config for each service and define whether or not to show it on the register.
     • Column 2: This will show the services status and due services, count.
       • We need to configure the following this for this column
         • Whether to hide or show the column
         • The resource to use for the services reference.
         • Formula to count the services i.e combine services for family registers or just get individual

Configuration JSON Sample

{
  "appId": "ecbis-saa",
  "id": "all_household_register",
  "filter": {
    "visible": true,
    "display": "Show overdue",
    "rules": [
      {
        "name": "filter",
        "condition": "",
        "action": [
          ""
        ]
      }
    ]
  },
  "dataFilters": [
    {
      "id": "family",
      "filterType": "TOKEN",
      "key": "code",
      "valueType": "CODEABLECONCEPT",
      "valueCoding": {
        "system": "https://www.snomed.org",
        "code": "35359004"
      }
    }
  ],
  "searchBar": {
    "visible": true,
    "display": "Search name or ID",
    "rules": [
      {
        "name": "searchBar",
        "condition": "",
        "action": [
          ""
        ]
      }
    ]
  },
  "registerCard": {
    "columnOne": {
      "rowOne": {
        "separator": "-",
        "rules": [
          {
            "name": "filter",
            "condition": "",
            "action": [
              ""
            ]
          }
        ]
      },
      "rowTwo": {
        "visible": true,
        "columnOne": {
          "visible": true,
          "rowOne": {
            "visible": true,
            "rules": [
              {
                "name": "filter",
                "condition": "",
                "action": [
                  ""
                ]
              }
            ]
          },
          "rowTwo": {
            "visible": true,
            "rules": [
              {
                "name": "filter",
                "condition": "",
                "action": [
                  ""
                ]
              }
            ]
          }
        },
        "columnTwo": {
          "visible": true,
          "rules": [
            {
              "name": "filter",
              "condition": "",
              "action": [
                "filterValue = fhirpath.excute('expression')",
                ""
              ]
            }
          ]
        }
      }
    },
    "divider": {
      "visible": false
    },
    "columnTwo": {
      "visible": true,
      "rules": [
        {
          "name": "count",
          "condition": "",
          "action": [
            ""
          ]
        },
        {
          "name": "status",
          "condition": "",
          "action": [
            ""
          ]
        }
      ]
    }
  }
}

Next steps --> Configuration phase 2 (Client Profile configuration implementation)

[pld]

Seeing that mock-up I better understand how to think about this I think I steered us in the wrong direction by talking about columns and rows. I was thinking columns and rows in the context of a table, like a spreadsheet or DB table, where you're defining a matrix, this is not that. This is more like a card with content components. And I think that language makes more sense, because this is a list of cards not a table with columns and rows. That said, I suppose we can think of this as a matrix layout within a card? And we're using columns/rows in that context, each card is a mini-table.

Also, to be explicit, the UI items ident and data load spec you describe is an example of the data load for eCBIS, but the user when they're defining the card can include only a single column and row, and how many max rows and columns in a single card, could they have 20 rows in their config? Maybe that's fine, but they couldn't have more than... 5 columns, 3?

Finally, because we're not showing a table, and we need the associated resource content, do we need to define the resources needed at all? That feels like it would be explicit in the definition of the card content, like you'd say, Col 1 Row 1, patient.name, Col 1 Row 2, patient.group.name. It's unclear to me why/what we get from explicitly defining the resource separately from through the search queries in the card content definition.

[dubdabasoduba]

We are defining the resources needed for sync. I think we can combine it with one of our sync configs. The idea is to make sure all the resources required for a certain register are downloaded.

I think we can decouple the resource definition. When the resources are defined centrally we can use the remote sync functionality to sync resources in batches.

The definition of the card content will help in fetching the content from the local SQLite DB.

Not sure if I make sense

[dubdabasoduba]

Right now the UI only allows for 2 columns. The first column has 3 rows. The second column will always show the status & due service count.

[pld]

Having 2 as the max columns seems fine, but we need to handle 1 column to cover the examples in the design, and we can't hard code the content of the 2nd column to cover the examples. Or, from the designs it looks like you could have the 2nd column present but with no content, but seems better to be able to only have 1 column.

On rows, from the UI, looks like the icons span rows 2 and 3 in column 1. To cover the examples we'd need to accommodate only having 2 rows.

[dubdabasoduba]

I see... Yes, we have the same idea on not having the rows hardcoded. I think the description on doesn't capture that.

On the icons, I think we can divide rows 2 & 3 to have 2 partitions. Let me re-phrase and update the description to make it a bit clear and generic.

[pld]

Yea the eCBIS layout is rather complex, I think if we can handle this card layout we'll be able to handle most

[pld]

dataFilters contains the information used to define a query to retrieve what will be shown in the register, I think we should rename it to dataQuery?

[ellykits]

dataQueries will do as this is a list

[ellykits]

@dubdabasoduba For the properties columnOne, rowTwo etc I think we can use Google's convention of naming positions for elements e.g. paddingStart, marginEnd, marginTop, paddingBottom etc. For instance rowTop, rowBottom instead of rowOne and rowTwo; columnStart, columnEnd instead of columnOne, columnTwo

[pld]

What if we have only 1 or more than 2 rows or columns? Do any of the UIs require that?

[ellykits]

Oh I see. Its possible to have a single row in some situations.

[ellykits]

Actually using the numbers will give us more flexibility in future in case we want to a third or forth row on the UI.

[ellykits]

While refactoring the usage of the register card configurations on the UI I thought about using two possible approaches:

1. Implementing a solution with the configuration informing what views to be created and how they are positioned dynamically. What I mean by this is for the register card we implement a Composable UI renderer based on JSON configuration. For instance a column widget in the config will map to a Column view in compose. This will result to updating the current register card model to use a widget style format. The advantage here is that if in future we introduce a third column we will not need to make any UI updates in the code.

2. The other approach is to implement reusable view components but tightly couple the configuration properties to the views. The disadvantage to this approach is that when in future we introduce new configuration to render say a third column or row then we will also need to update the UI code.

@pld @dubdabasoduba

[ellykits]

Here is a sample of the needed adjustment on the register config card JSON.

"registerCard": {
    "rules": [
      {
        "name": "patientName",
        "condition": "true",
        "actions": [
          "data.put('patientName', fhirPath.extractValue(Patient, 'Patient.name.given'))"
        ]
      }
    ],
    "views": [
      {
        "viewType": "COLUMN",
        "children": [
          {
            "viewType": "COMPOUND_TEXT",
            "properties": {
              "primaryText": "Example of concatenated text: {$patientName}"
              "primaryTextColor": "#000000",
              "secondaryText": "{$g6pdStatus}"
            }
          },
          {
            "viewType": "ROW",
            "children": [
             // follows the same pattern
            ]
          }
        ]
      }
    ]
  }

[ellykits]

Instead of creating configuration for every view component we can share the configs instead where sensible. An example is the COMPOUND_TEXT which has two properties. primaryText and secondaryText this will correspond to the UI component used to render Last visited - G6PD Status on figma.

[ellykits]

The rules have been isolated so we have a central place for retrieving the rules. We will pre-compute the rules when data is paginated, the results saved in a map that can be accessed any time via string interpolation.

The views will be ordered in the columns/rows as they are declared in the config. The views can additionally define an optional layout weight property that will be used to calculate it's position in the parents layout hierarchy.

[ellykits]

For the interpolation I think we may need a new format so as not to conflict with the Kotlin format.

[pld]

k, so the rules are separate so that if we reuse the value of a rule in multiple places in the layout we don't need to recalculate it?

[ellykits]

Exactly.

…

On Wed, Jul 13, 2022, 15:34 Peter Lubell-Doughtie ***@***.***> wrote: k, so the rules are separate so that if we reuse the value of a rule in multiple places in the layout we don't need to recalculate it? — Reply to this email directly, view it on GitHub <#1340 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGM667EXEADONALZF53LHM3VT2ZVDANCNFSM5X7RQHNA> . You are receiving this because you commented.Message ID: ***@***.***>

[roywanyaga]

@dubdabasoduba @ellykits
Currently, the filter functionality enabled by the dataQuery entries will fetch resources that fit all the filter criteria specified by the multiple entries. (more like having AND logic for the different search parameters).
It would be ideal also to include functionality to fetch resources that fit either of the dataQuery entries. (more like having OR logic for the different search parameters)

An example would be to fetch Group resources that have two or more possible values for the code element.

"code": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "763158003",
          "display": "Medicinal product"
        }
      ]
    }

"code": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "49062001",
          "display": "Device (physical object)"
        }
      ]
    }

[pld]

do you have a use case for this?

[dubdabasoduba]

@roywanyaga I might be a little confused but correct me if I am wrong.

"searchBar": {
    "visible": true,
    "display": "{{ search.by.name }}",
    "computedRules": [
      "patientName",
      "patientId"
    ]
  },

Defines the search parameters on the search bar. I updated your comment to say filter. My understanding is we are trying to specify what kinda data to display on the views.

Search is trying to get a specific item through the already filtered data set.

[dubdabasoduba]

@pld We are marking the commodities with different codes but, when displaying them on the register, we want to show all the commodities on the same register.