How to define a data type, control type and other options?

[xamelon]

Describe (write it douwn):

1. Form DSL describes in one place both the form controls, the data to be stored, and some validation rules.

2. There is a relationship between data type and the type of controls to input and render this data:
   Default control may be used to handle specific data types. For example, datepicker for dates.

3. Sometimes, both types could be deduced from other elements: CodeableConcept & concept from enum or valueset.

4. Sometimes, there are multiple controls for the same data type - basic input, textarea for the string elements.

5. There are items without visual, and there are items just for visual. That's probably why FHIR SDC calls it an item.
   What are examples?

• Group for only visual?!
• Calculated fields

7. FHIR SDC in addition to built-in FHIR datatypes has an extension to tell what type of control has particular item

Questions:

• What type is more important?
• Is there a many-to-many relationship between control type and data type?
• Could data and control types be deduced from other elements (like enum or valueset)?
• How is it related to pre-populate and extract?

Use cases

1. The user wants to enter only the data type and use default control on the form. Case of date and date picker.

Diagnose: How to define a data type, control type and other elements relationships?

Approaches:

• Both explicit
• One type is main - another optional and deducible
• Both implicit - deduce one from another in both directions

Aspects:

• less to write - intuitive
• no surprises for user vs
• Easy to implement in UI Designer
• Simplicity of implementation

Decision matrix

Design:

Name for control is control or input?

[xamelon]

Explicit data type + no widget type. In this case widget type is deduced from data type

VitalsDocument
{:fields [{:name "super"
           :type "string"}]}

Pros:

• need to know only type of data
• no need for additional widget type attribute
• data type is explicit

Cons:

• can't show different widget for same data type (short string, multiline string)

[xamelon]

Data and widget types can be inferred from context for complex values

1. "coding" and "dropdown" from options

VitalsForm
{:fields [{:title "choice"
           :options [{:display "HHH" :code "yes"}]}]}

2. "quantity" and "quantity input" from :unit attribute

VitalsForm
{:fields [{:title "weight"
	   :unit "kg"}]}

3. "integer" and "number input" from :min and :max attributes:

VitalsForm
{:fields [{:title "weight"
	   :min 100
           :max 200}]}

Pros:

• don't need to state data type and widget type for complex values

Cons:

• can't infer type when auxiliary attributes are not present for primitives (string, number, boolean)
• data type is not obvious from definition

[xamelon]

Explicit widget type + no data type. In this case data type is deduced from widget type

VitalsForm
{:fields [{:label "reason"
           :type "dropdown"
           :options []}
          {:name "large-text"
           :type "text"}
          {:label "large text"
           :type "textarea"}
          {:name "number"
           :type "number"}
          {:name "answer"
           :type "checkbox"}
          {:name "range"
           :type "range"
           :step 1}
          {:type "radiobutton"
           :options ["apple" "banana"]}
          ]}

Pros:

• widget type is explicit
• no need for additional data type attribute
• easy to extend widgets library

Cons:

• need to know which data type holds widget
• not obvious way to go from widget to data type
• some widgets can be used for different data types
  • switch, checkbox - both boolean
  • radiobutton, dropdown - can hold numbers, strings, coding, date, time

[xamelon]

Explicit data type + widget type (optional)

VitalsForm
{:fields [{:label "reason"
           :type "boolean"}
          {:name "boolean 2"
           :type "boolean"
           :widget "switch"}]}

Pros:

• obvious data and widget types
• easy to extend widget library

Cons:

• two additional attributes

[rublag]

What if we make some middle-ground for these:

{:name "consent"
 :widget "checkbox"}
{:name "category"
 :widget "choose"
 :options [:a :b :c]}
{:name "somecode"
 :widget "choose<string>"
 :options something-from-database}

i.e. infer type when possible, require annotation when not, and cramp type into widget string