Document DSL
Document is schema for Questionnaire with questions and answers and types of values.
Document is used as source of meta-information by FormLayout
Document is used as source of meta-information by FormFinalize
Document resources stored in
SDCDocument
table.Document can define computed fields via rules.
Marking schema as SDC Document
entity
Document
entityDocument definition should be marked with aidbox.sdc/doc
tag, and also tagged as zen/schema
- because it's already schema.
And after that you can define your custom properties of the document and it's meta information (like source of the document)
Document source defined as fhir Coding
like structure, with :system
, :code
and :url
properties
To define document fields - you should add :type zen/map
property and put your fields under :keys
property.
Every document field should confirms aidbox.sdc/super-field
schema.
For details see Document fields definition section.
DB Storage & Common properties
To support document db-saving ability and support common fields for all documents such as:
:author
- Reference to user which create document,:encounter
- Reference to encounter,:unit-system
- What unit system was used in this document at launch,:patient
- Reference to patient:status
- Status of the document,:type
- Full name of document profile.:form
- Name/version of form, with which document was captured
You need to add :confirms #{aidbox.sdc/Document}
property
Rules
Rules used for computed properties. Properties schema and compute formula - defined separately.
To support rules definition you need to add tag aidbox.sdc/rules
and after that you can define caclulated properties and their formulas under :sdc/rules
property
name of the rule (
:loinc-39156-5
) should be matched with name of the field.If sdc-type inference can't recognize field as calculated - you can mark it manually - add
:sdc-type aidbox.sdc/calculated
to it
When form launched - Rules from Document
will be merged with rules from Layout
and placed under :rules
key in response.
Don't use same keys in Document rules and Layout rules
Rules logic defined via Embeddel lisp. See details in Lisp reference.
Aidbox Form UI has embedded lisp engine. If you use your custom ui - you should implement your lisp-engine, based on lisp reference.
Document Field definition
SDCDocument has several embedded field-types:
aidbox.sdc/text
- fields with multiline textaidbox.sdc/string
- fields with oneline textaidbox.sdc/number
- fields with numberaidbox.sdc/quantity
- fields with measurement unitsaidbox.sdc/choice
- fields with answers, located in valuesetsaidbox.sdc/calculated
- fields, which need to be calculated via rules engine
This field types inferred from Document field schemas. But you can overwrite that by specifying it directly via :sdc-type
key
super-field schema
Field-type definition.
Schema contains several aspects of Document (Field) lifecycle
how it stored in DB
how it validates
how it appeares in UI layout
what the possible options
what the source of the field
Can contain sub-fields or behaves like an array. Also has links to original sources of questions.
super-field schema has next keys:
property | description | type | required? |
---|---|---|---|
| Question text | string | yes |
| Question explanation or some hint - how to interpret it | string | no |
| zen/type of the value, which will be stored in DB | symbol | no |
| field meta-type - used for determine UI input type | symbol | no |
| additional schemas for stored value confirmation | set of symbols | no |
| Default field value (also for repeated fields) | zen/any | no |
| List of available values (used in choice) | zen/keyword | no |
| Alternative options source (used in choice) | zen/keyword | no |
| List of units (used for quantity fields) | vector of {:name string} | no |
| When field is complex object(map) - used for defining nested fields | map of super-fields | no |
| When field is coll (zen/vector) - used for defining coll-item schema | super-field | no |
| Min/max values for quantity fields (for different measurement units) | {:imperial MinMaxMap, :metric MinMaxMap} | no |
| Meta field - contains datetime of last changes | any | no |
| CodeSystem of the question (used in extractions) | Coding | no |
| Link to original questing (in questionnaire, used in converter to QR) | string | no |
quantity field-type
Quantity contains units of measurement
quantity schema has next additional keys:
property | description | type | required? |
---|---|---|---|
| List of units | vector of {:name string} | no |
Example:
choice field-type
Choise field - references valueset with answers
Choice fields should have these properties:
property | description | type | required? |
---|---|---|---|
| List of available values | zen/keyword | no |
| Alternative options source | zen/keyword | no |
By default choice field uses :enum
keyword for options definition.
Example:
If by some reason you can't use zen-defined :enum
keyword with options - you also have 2 alternative sources for retreiving them:
:aidbox.sdc.options/valueset
use valuset stored in aidbox db:aidbox.sdc.options/rpc
- use custom rpc
If you specify :sdc/options :aidbox.sdc.options/valueset
, then you also must specify :valueset
property.
property | description | type | required? |
---|---|---|---|
| ValueSet ID with list of choices | zen/string | yes |
If you specify :sdc/options :aidbox.sdc.options/rpc
, then you also must specify :rpc
property.
property | description | type | required? |
---|---|---|---|
| ValueSet ID with list of choices | zen/string | yes |
| rpc method invocation description | zen/map | yes |
RPC method invocations have next structure
property | description | type | required? |
---|---|---|---|
| ValueSet ID with list of choices | zen/string | yes |
| rpc method name | zen/symbol | yes |
| parameters map | zen/map | yes |
Each value of parameters-map should be valid lisp expression.
Example:
\
calculated field-type
Calculated field. Rule with same name should be used to calculate the result.
Calculated fields don't provide additional keys. Instead it depends on :sdc/rules
NOTE: we have one restriction - calculated fields can't be in nested fields.
QuestionnaireResponse convertions
If you need to convert SDCDocument to QuestionnaireResponse you need to specify additional field property
:linkId
- linkId of original Questionnaire (if not given key of the question will be taken)
SDCDocument extraction
If you need to extract some values to Observation you need specify additional field property
:code
- code/system of original Questionnaire question
Last updated