OTH Public Software

Features, services and base configurations

Introduction

This document describes the configuration keys for the OTH platform. It contains 4 sections:

  • Base configuration
  • Feature toggles
  • Experimental/Customer-specific toggles
  • Services configuration.

Examples are provided for each, with a following description of the default value.

This document is meant as a reference on how each toggle/services can be configured.

We strongly encourage you to read through this document, before generating a configuration for your OTH platform - with the OTH web configurator.

 Notice

It is advisable to not enable features not needed for your particular use-case/clinical flows.

Base configuration

Purpose:

Configuration not related to a OTH platform service or feature, are configured as a part of the base configuration for an OTH installation.

deployment

Purpose:

The deployment configuration, specifies basic information for a deployment.

key configuration

deployment:config:

aws_access_key_id: AWS access key, provided per installation, to pull from OTHs ECR.

aws_secret_access_key: AWS secret access key, provided per installation, to pull from OTHs ECR.

deployment:proxy:

host: The fully qualified domain name, used to access the OTH platform.

port: This can be omitted and it defaults to 443

deployment:environment: Values can be [ production | demo ], if set to demo, a set of demo data will be bootstrapped to the platform after the installation on first startup.

deployment:othmonitoring:enabled: Enables OTH central monitoring, through Sensu. This should only be enabled for installations managed by OTH.

deployment:othlogcollection:enabled: Enables OTH central logging, through Promtail. This should only be enabled for installations managed by OTH.

Example configuration:

deployment:
  config:
    aws_access_key_id: ABCD1234
    aws_secret_access_key: 1234ABCD
  proxy:
    host: mytelehealth-test.oth.io
    port: 443
  environment: demo
  othmonitoring:
    enabled: false
  othlogcollection:
    enabled: false

Default:

deployment:
  config:
    aws_access_key_id: <must be filled>
    aws_secret_access_key: <must be filled>
  proxy:
    host: <must be filled>
    port: 443
  environment: production
  othmonitoring:
    enabled: false
  othlogcollection:
    enabled: false

database

Purpose:

The database: section configures the database backend.

key configuration

host: Hostname or IP address of the database server

port: Port the database listen on.

name: Name of the database to use

user: and pass: User name and password needed to access the database:name:

Example configuration:

database:
  host: oth-demo.f0wl5v4qw4qs.eu-north-1.rds.amazonaws.com
  port: 3306
  name: clinician
  user: oth
  pass: ABCDE12345

Default:

All keys are mandatory and must be configured. No defaults are set.

rabbitmq

Purpose:

The rabbitmq section configures the Message Queue broker backend.

key configuration

deploy: Values can be [ true | false ] - set to true to enabled deployment of a rabbitMQ service on the storageserver

host: Values can be [ IP | hostname ] - insert hostname or IP Address of your rabbitMQ host.

scheme: Values can be [ amqp | amqps ] - specify rabbitMQ protocol version.

port: Port that the MQ service listen on.

users:admin:username: and users:admin:password: a username and password to configure rabbitMQ vhost and bindings.

users:opentele:username: and users:opentele:password: a username and password for the OTH solution to use accessing the OTH rabbitMQ vhost and bindings.

 Notice

Avoid using special characters in the users:opentele:password.

Example configuration:

rabbitmq:
  deploy: true
  host: u-3k57135h-03rk-20na-ia02-9nw342jka8gw.mq.eu-north-1.amazonaws.com
  scheme: amqps
  port: 5671
  users:
    admin:
      username: admin
      password: poiuyt0987656
    opentele:
      username: opentele
      password: tyuiop67890

Default:

All keys are mandatory and must be configured. No defaults are set.

branding

Purpose:

The branding section, configures white label branding on your OTH solution. White label branding must be created by OTH - Customer must provide logo’s and styles matching the branding guidelines provided by OTH.

key configuration

branding:enabled: Values can be [ true | false ] - enables/disable white label branding for the clinician portal.

branding:enabled:name: whitelabel name, provided by OTH.

branding:clientcitizen:enabled: Values can be [ true | false ] - enables/disable white label branding for client-citizen portal and app.

branding:clientcitizen:name: white label name, provided by OTH.

branding:clientclinician:enabled: Values can be [ true | false ] - enables/disable white label branding for client-clinician app.

branding:clientclinician:name: white label name, provided by OTH.

Example configuration:

branding:
  enabled: false
  name: mytelehealth
  clientcitizen:
    enabled: true
    name: mytelehealth
  clientclinician:
    enabled: true
    name: oth

Default:

branding:
  enabled: false
  name: oth
  clientcitizen:
    enabled: true
    name: oth
  clientclinician:
    enabled: true
    name: oth

minio

Purpose:

The Minio service offers a AWS S3 compatible object storage. This should only be configured if you as a customer wish to keep data internally and are not able to provide your own drop in replacement AWS object-storage service or do not wish to store data in a AWS S3 bucket. The measurements and objectstorage S3 buckets should point to the Minio service instead of a external S3 bucket.

key configuration

deploy: Values can be [ true | false ]

access_key:, secret_key: Access key and Secret needed to access the Minio service

audit_host:, audit_port: host and port to access the audit Minio log.

Example configuration:

minio:
  deploy: true
  access_key: minio_key
  secret_key: minio_secret
  audit_host: localhost
  audit_port: 10000

Default:

No defaults are configured.


Feature toggles

Purpose:

Feature toggles, enables and configure optional features on the OTH platform. Each feature toggle section should be an indented block under the features: or the relevant service (e.g. clinician:) section.

If not specified, it should always be configured under the feature: section.

Example:

features:
  virtual_ward:
    enabled: true
  ecg:
    enabled: false
    api_secret: thisissomesecretdonttellanyone

clinician:
  config:
    closure_notes:
      enabled: true

If a given feature toggle is not configured, it defaults to a default described below for each toggle (usually false).

auto_refresh

Purpose:

Server side setting interval_minutes defines how often the patient overview should be refreshed automatically. However in order to enable this you would need to have the permission: ROLE_READ_AUTO_REFRESH

Example configuration:

clinician:
  config:
    auto_refresh:
      interval_minutes: 10

Default:

auto_refresh:interval_minutes defaults to 10 minutes.

blue_alarm

Purpose:

A property for customizing the grace period (called slack) between a questionnaire deadline and a blue alarm being triggered. The slack value needs to be an integer between 0-30. An additional property cron_minutes has been added to configure when the blue alarms job should run, the value is a cron string for which minutes the job should be executed. e.g. “16” for the minute every hour or “16,46” or every 16 and 46 minute every hour.

Example configuration:

clinician:
  config:
    blue_alarm: 
      slack: 15
      cron_minutes: "16,46"

Default:

minutes are set to 16,46 and slack to 15 if blue_alarm is not configured in che clinician:config section.

clientclinician

Purpose:

The clientclinician: feature provides a basic android APK to the clinicians, enabling them to login on behalf of their patients.

Example configuration:

features:
  clientclinician:
    enabled: true

Default:

enabled: false

closures_notes

Purpose:

The closure_notes: feature adds support for adding a closure note when acknowledging a completed questionnaire in the clinician portal. The templates: value must be one unbroken line, with each note separated with the | (pipe) character.

This should always be configured as a part of the clinician:config: section.

Example configuration:

clinician:
  config:
    closure_notes:
      enabled: true
      mandatory: true
      templates: |
                Hospital admission avoidance|Emergency antibiotics administered, emergency steroids|Visited by clinician|Hospital admission

Default:

closure_notes:
  enabled: false
  mandatory: false

cors

Purpose:

The cors: feature whitelists a list of domains, allowing outside origins (browser based apps) loading resources from the OTH platform APIs. A CORS origin consist of scheme, domain and port.

Example configuration:

features:
  cors:
    whitelist:
      - http://localhost:4200
      - https://myhealthappp.example

Default:

cors: not configured.

courses

Purpose:

The courses: feature adds the possibility to enrolling patients in a course running over several weeks spread across a series of patient groups and questionnaire schedules.

Example configuration:

features:
  courses:
    enabled: false
    scheduler:
      timing: "0 * * * *"

Default:

enabled: false
scheduler:
  timing: "0 * * * *"

ecg

Purpose:

The ecg: service provides support for taking ECG measurements as a patient. If enabled, a sufficient long api_secret (32 characters or longer are recommended) needs to be provide for internal communication.

Example configuration:

features:
  ecg:
    enabled: true
    api_secret: <ecg_api_secret>

Default:

enabled: false

excluded_meter_types

Purpose:

The excluded_meter_types: feature makes it possible to excluded specific meter types and their corresponding measurement types from various drop downs in the UI.

Effectively this limits the set of measurements a given installation shows to clinicians when creating questionnaires, entering manual measurements etc.

Used when a customer only wants to see the meter/measurement types they actually support for their clinical use cases.

Example configuration:

features:
  excluded_meter_types:
    - bloodsugar_mg_dl
    - weight_pound
    - temperature_fahrenheit

Default:

excluded_meter_types:
  - bloodsugar_mg_dl
  - weight_pound
  - temperature_fahrenheit

external_app

Purpose:

The external_app: feature adds support for linking to an external web app from inside the clinician portal either in the patient menu or main menu.

This should always be configured as a part of the clinician:config: section.

A menu point can be configured with a title, icon, URL, and optional authentication data such as a shared secret.

When a user clicks on a custom menu a POST request is made to the configured URL. The request contains the following form data: URL of the current clinician, URL of the current patient (if any), and the optional data used for authentication.

The icon value used in the configuration can be any valid font awesome v5 ID. Reference : https://fontawesome.com/v5/search

The external app now support three different methods: redirect (GET), form (POST), plugin (web component).

Example configuration:

clinician:
  config:
    external_app:
      patient_menu:
        app1:
          title: 3rd Party 1
          icon: pipe
          method: redirect
          description: "Clicking on this link will redirect you to a fancy page!"
          includeContext: false
          url: "http://127.0.0.1/some-website"
        app2:
          title: 3rd Party 2
          icon: pen
          method: form
          description: "Clicking on this link will post a form"
          url: "http://127.0.0.1:6789/endpoint"
          data:
            accessToken: something-very-secret
            someKey: some-value
        app3:
          title: 3rd Party 3
          icon: camera
          method: plugin
          url: "http://127.0.0.1/static/js/my-component.js"
          tag: my-component
      main_menu:
        app1:
          title: 3rd Party 1
          icon: arrow-alt-circle-right
          method: form
          url: "http://127.0.0.1:7898/endpoint"
          data:
            someParam: foobar

Default:

external_app: not configured.

manual

Purpose:

The manual: feature adds support for customer to create their own help website by using a URL template where language and version of the product can be used. Furthermore the context (clinician or administrator) can be used as a parameter as well. This link is opened in a new tab.

This URL is a URL template where additional parameters can be inserted based on the context:

  • context - Will be “clinician“ or “administrator“, depending on the user logged in.
  • lang - The current portal language used.
    • Only supported languages are : en, da or de. The default language is en.
  • version - the current version of the platform.
    • eg. 2.82.0

A URL template could look like:

https://manuals.mytelehealth.org/{version}/{lang}/manual-{context}.pdf

Where the parameters in {} will be replaced based on the context.

Example configuration:

features:
  manual:
    url: "https://myhealthmanuals.org/{version}/my-{context}-manual.doc"

Default:

manual:
  url: "https://oth-manuals.s3.eu-west-1.amazonaws.com/{version}/{lang}/manual-{context}.pdf"

mfa (Multi-Factor Authentication) - DEPRECATED

Purpose:

The features:mfa: is no longer used in settings.yml and can safely be removed. If features:oidc:citizen_login:enabled: is true, mfa will be set to UserPinCode, otherwise it will be set to None.

mixpanel

Purpose:

A property for setting up Mixpanel analytics (https://mixpanel.com) for a given installation.

Example configuration:

clinician:
  config:
    mixpanel: 
      token: "server-specific-mixpanel-token"

Default:

Not configured.

oidc (client citizen)

Purpose:

The oidc: feature adds support for 3rd party integrators and the client-citizen to use the idp2 to verify OIDC id tokens and login using the id token and get back normal OTH tokens.

The oidc: configuration is due to its complexity described in full in OTH’s OIDC guides, that can be requested from OTH’s technical support.

features:oidc:verify:jwks_options: is now hardcoded to RS256 and can safely be removed from settings.yml.

Example configuration:

features:
  oidc:
    verify:
      enabled: true
      client_id: myclientid-xxxx
      oth_mapping_claim: email
      issuer: https://myhealth-test.eu.auth0.com/
      jwks_url: https://myhealth-test.eu.auth0.com/.well-known/jwks.json
    citizen_login:
      enabled: true
      scopes: "openid profile email"
      # the running config should only have one of the two line below, depending on the supported options from your OIDC provider.
      authorization_endpoint: "https://myhealth-test.eu.auth0.com"
      custom_logout_url_template: "https://myhealth-test.eu.auth0.com/v2/logout?client_id={clientId}&returnTo={postLogoutRedirectUri}"

Default:

features:
  oidc:
    verify:
      enabled: false
    citizen_login:
      enabled: false

oidc (clinician)

Purpose:

The oidc: feature adds support for clinicians logging in using OIDC in the clinician portal.

This should always be configured as a part of the clinician:config: section.

The oidc: configuration is due to its complexity described in full in OTH’s OIDC guides, that can be requested from OTH’s technical support.

Example configuration:

clinician:
  config:
    oidc:
      enabled: false
      clinician_id_claim_name: "email"
      issuer: "https://oth-prod.eu.auth0.com/"
      client_id: "some_client_id"
      client_secret: "some_client_secret"
      scopes: "openid profile email"
      custom_logout_url_template: "https://oth-prod.eu.auth0.com/v2/logout?client_id={clientId}&returnTo={postLogoutRedirectUri}"

Default:

oidc:
  enabled: false

patient_overview

Purpose:

The patient_overview: feature toggles whether to sort the patient overview by first name or last name as the secondary sorting criteria after severity.

This should always be configured as a part of the clinician:config: section.

Example configuration:

clinician:
  config:
    patient_overview:
      sort_by_last_name: true

Default:

patient_overview:
  sort_by_last_name: false

poolsize for clinician DB

Purpose:

Flags for managing poolsize for clinician DB.

Documentation can be found here : https://github.com/brettwooldridge/HikariCP#gear-configuration-knobs-baby

  • pool_size is maximumPoolSize in documentation
  • max_lifetime is maxLifetime in documentation
  • min_idle is minimumIdle in documentation
  • idle_timeout is idleTimeout in documentation

Example configuration:

clinician:
  config:
    db:
      pool_size: 10 # This is the default if not configured
      max_lifetime: 3540000 # This is the default if not configured
      min_idle: 10 # Default is pool_size
      idle_timeout: 3540000 # This is the default if not configured

show_severity (client citizen and client clinician)

Purpose:

The show_severity: adds support for showing measurement severity in the patient app under ‘My results’.

This should always be configured as a part of the clientcitizen:config: section.

Example configuration:

clientcitizen:
  config:
    show_severity:
      enabled: true

Default:

clientcitizen:
  config:
    show_severity:
      enabled: false

show_replies (client citizen and client clinician)

Purpose:

The show_replies: adds a ‘My replies’ menu in the patient app that shows recent questionnaire results submitted by the patient.

This should always be configured as a part of the clientcitizen:config: section.

Example configuration:

clientcitizen:
  config:
    show_replies:
      enabled: true

Default:

clientcitizen:
  config:
    show_replies:
      enabled: false

timeout (client citizen and client clinician)

Purpose: The timeout is the number of seconds the patient is given before an idle dialog is shown. If the countdown gets completed the user will be logged out.

Example configuration:

clientcitizen:
  config:
    timeout: 600 # 10 minutes before idling

timeout_warning (client citizen and client clinician)

Purpose: timeout_warning is the countdown in seconds of the Idle dialog. If 0, the dialog is skipped. The configuration is optional and if not set the default is 0 seconds of warning.

Example configuration:

clientcitizen:
  config:
    timeout_warning: 30

terms_and_conditions (client citizen and client clinician)

Purpose: The terms_and_conditions does not need to be specified but if it is a non empty base64 encoded string this will be shown in the patient app as a dialog. The app cannot be used before accepting this dialog. Using\n in the string before base64 encoding will provide a new line. The un-encoded string should not exceed 200 characters.

Example configuration: the string :

“Please read and accept our Terms and Conditions\nbefore proceeding\nhttps://linktoourterms.org”

should be base64 encoded and added as a value to the clientcitizen:config:terms_and_conditions: key

clientcitizen:
  config:
    terms_and_conditions: UGxlYXNlIHJlYWQgYW5kIGFjY2VwdCBvdXIgVGVybXMgYW5kIENvbmRpdGlvbnMKYmVmb3JlIHByb2NlZWRpbmcKaHR0cHM6Ly9saW5rdG9vdXJ0ZXJtcy5vcmc=

info_url (client citizen and client clinician)

Purpose: The info_url does not need to be specified but if it is a non empty string people will be able to visit this url when clicking on the provided logo in the app.

Example configuration:

clientcitizen:
  config:
    info_url: "https://oth.io"

smsgw

Purpose:

The smsgw: feature adds support for sending SMS messages to patients, through the twilio API. A set of twilio credentials are required to use this service.

key configuration

account_sid: your twilio account sid

auth_token: your twilio authentication token

sender: the name of the sender of the SMS. It should be no longer than 11 characters long, for readability.

country_code: should reflect the international calling code of your country.

Example configuration:

features:
  smsgw:
    enabled: true
    app:
      twilio:
        account_sid: <your twilio account sid>
        auth_token: <your twilio authentication token >
        sender: OTH
        country_code: 45

Default:

features:
  smsgw:
    enabled: false

video

Purpose:

The video: feature adds support for performing video conferences between clinicians and patients, through the VidyoPlatform service. A Vidyo account and credentials is required to use this service.

key configuration

version: Should be set to 4

calendar_enabled: Values can be [ true | false ] - set this to false to disable the calendar view in the menu.

vidyo_credentials:host: The URL for your VidyoPlatform

vidyo_credentials:extension: The extension for your VidyoPlatform

vidyo_credentials:username: The operator username for your VidyoPlatform

vidyo_credentials:password: The operator password for your VidyoPlatform

Example configuration:

features:
  video:
    enabled: true
    calendar_enabled: false
    version: 4
    vidyo_credentials:
      host: "<your vidyo host URL>"
      extension: "<your vidyo extension>"
      username: "<your vidyo operator username>"
      password: "<your vidyo operator password>"

Default:

features:
  video:
    enabled: false

Experiemental/Customer-specific toggles

Purpose:

These feature toggles are mainly developed for specific use-cases and are usually targeting a very specific customer use-cases. They are not meant to be enabled in general, but can be used as-is.

copd_prediction

Purpose:

The copd_prediction: feature adds experimental support for evaluating a machine learning model to predict COPD patient exacerbation.

This should always be configured as a part of the clinician:config: section.

Example configuration:

clinician:
  config:
    copd_prediction:
      enabled: true

Default:

copd_prediction:
  enabled: false

cpr

Purpose:

The cpr: feature adds support for looking up a patient’s CPR number in the Danish CPR register. This feature requires credentials for accessing the Danish national external CPR-lookup web service.

Keys will not be described in details, since this service has a very narrow use-case.

Example configuration:

features:
  cpr:
    enabled: true
    service:
      host: <URL to your service>
      uri: <specifies URI as needed. This key can be omitted>
    sosi:
      cvr: <cvr number>
      sts:
        url: <URL to external STS web service>:<PORT><URI>
      system_name: <Name of your Lookup Service>
      federation_type: <test|production>
      vault:
        password: <secret>

Default:

cpr:
  enabled: false

femom

Purpose:

The femom: feature adds support for creating questionnaires with the “FeMom ECG” measurement type in the questionnaire editor. This feature requires access to a configured Objectstorage bucket (e.g. AWS S3, minio or similar), for storing the FeMom measurements.

This should be configured both as a feature: toggle and under the measurements: service.

key configuration

measurements:config:

max_allowed_body_size: set max allowed upload size in bytes.

s3:scheme: allowed values are http|https

s3:bucket: hostname or IP address for bucket.

s3:region: buckets region

s3:port: network port for bucket

Example configuration:

features:
  femom:
    enabled: true

measurements:
  config:
    max_allowed_body_size: 30_000_000
    s3:
      scheme: "https://"
      bucket: oth-io-oth-demo-measurements
      region: eu-west-1
      port: 443

Default:

features:
  femom:
    enabled: false

lifelight

Purpose:

The lifelight: feature adds support for creating questionnaires with the “Lifelight” measurement type in the questionnaire editor. This feature toggle affects the config files of clinician and client-{citizen,clinician}. No credentials for authenticating with Lifelight SDK as these have already been handled by the build pipelines for the Android/iOS components.

Example configuration:

features:
  lifelight:
    enabled: true

hl7

Purpose:

The hl7: feature adds support for parsing HL7 messages (ADT A01 and A08) for creating and updating patients in OTH.

dependencies

  • Cron job for calling the HL7 API triggering the file processing job.
  • A 3rd party service writing HL7 files to a local folder accessible from the hl7 service.

key configuration

hl7:input_folder: Folder on the local file-system where the hl7 service expect to find hl7 files to process.

hl7:error_folder: Folder on the local file system where all processed hl7 files that fails will be moved to. These failed files should be investigated manually for further processing.

hl7:max_error_folder_size: Number of allowed failed files. The hl7 service will report error if failed files exceed this threshold.

hl7:default_patient_data_value: Set a default value for patient data.

hl7:default_patient_group_id: Set the default patient group id to assign the patient to. This must be a valid and existing patient group.

hl7:message_template: Define a message template with information about username and password. Valid variables are {USERNAME} and {PASSWORD}.

Example configuration:

features:
  hl7:
    enabled: true
    input_folder: "/srv/hl7/hl7_input_files/"
    error_folder: "/srv/hl7/hl7_failed_files/"
    max_error_folder_size: 10
    default_patient_data_value: "Unknown"
    default_patient_group_id: 5
    message_template: |
      Your user account for the OpenTeleHealth platform has now been created!

      Your access data is the following:

      Username: {USERNAME}

      Password: {PASSWORD}      

Default:

features:
  hl7:
    enabled: false

virtual_ward

Purpose:

The virtual_ward: feature adds support for continuous monitoring of patient vital signs using a dedicated dashboard for alarms and graphs for each patient. The virtual ward data is feed through the OTH streaming measurements API from a external source.

Example configuration:

features:
  virtual_ward:
    enabled: true

Default:

features:
  virtual_ward:
    enabled: false

Services configuration

Services configuration describes the configuration for all relevant configuration keys for a given OTH service, not considered a feature toggle. Some feature toggles are part of this configuration but are described in the feature toggle section above.

authentication

Purpose:

The authentication: configuration sets up key/secret pair for each micro-service that needs to validate authenticity for access through the IDP service.

key configuration

The form for each service needing it, is :

authentication:<servicename>:key: key (32 characters)

authentication:<servicename>:secret: secret (64 characters)

The following services are valid: audit,idp,clinician,results,chat,calendar,meetings,measurements,objectstorage,organizations,questionnaires,notifications,guidance,thresholds,logging,smsgw,ecg,hl7,courses,clientcitizen

Only running services needs to have a defined key/secret.

Example configuration:

authentication:
  idp:
    key: GieXein5naim4Ashoofairoh1jeepoo6
    secret: iz7cai1ahghaht0zahj6ixoongai1ag1ooNo9aesie4veevaiPh4joojeeChee8l
  audit:
    key: aeng1Eeph7eGo7iemai2shee8EiHethe
    secret: Xap1aiseeth9eiyiel7soepikoch3ielaidihoo0epus0ow1kaqueicoogieg5uF
  clinician:
    key: Eije6Nothaingoo3aachah0pae1quewo
    secret: Eanah3shuov0tohlai9xai1tapoo8oov9esha6In6shae9Toum9eliere4thaif6
  results:
    key: ahphee0eife6phooL2kai1heowagouxu
    secret: YuPai1kahrohfah5aaPoosheasooquuequaiCuphoo2Woh1Eij1uif3gahtemiaT
  chat:
    key: Phe2Aroophaen3oowoh2Ju9aifeeFani
    secret: gudu3ooc3beireejoiJ8xae1aexaxoo1soo6riXae8Iesaeli0Yahgaeweik9moh
  calendar:
    key: Gah7haeshaot4beJa9oowoojood8gaet
    secret: quoh8foh0chaiphohthei5keG7ig9bee6oh4xe2podahgah4AeG9aengeeng5ohZ
  ..
  ..

measurements

Purpose:

The measurements: service adds support for uploading large measurements to a object-storage bucket like S3. This service must be configured.

 Notice

The measurements:config:s3: section is deprecated.

New installation from 2.78.0 and onward should not configure this section, but make sure that the equivalent section in objectstorage: is configured.

For continued legacy support of buckets used pre-release 2.78.0, the bucket should be configured in full. This service now use the objectstorage bucket configuration for storing large measurements.

key configuration

config:max_allowed_body_size: Sets a limit in bytes of how large a measurement is accepted.

config:s3:scheme: Values can be [http | https] - set which protocol used for access.

config:s3:bucket: Name of the bucket to store measurements in.

config:s3:region: Name of the buckets region.

config:s3:host: Hostname or IP of bucket host.

config:s3:port: Port to access service.

Example configuration:

measurements:
  config:
    max_allowed_body_size: 30_000_000
    s3:
      scheme: "https://"
      bucket: oth-io-oth-prod-measurements
      region: eu-west-1
      host: "s3.eu-west-1.amazonaws.com"
      port: 443

Default:

All measurements: key must be configured.

objectstorage

Purpose:

The objectstorage: service, stores persistent objects not suited for storing in the database.

key configuration

config:s3:scheme: Values can be [http | https] - set which protocol used for access.

config:s3:bucket: Name of bucket.

config:s3:region: Name of bucket region.

config:s3:host: Hostname or IP of bucket host.

config:s3:port: Port to access service.

config:max_object_size: set the maximum size of objects saved in S3 via the object-storage service. The default value is 20000000 (20mb).

Example configuration:

objectstorage:
  config:
    max_object_size: 10000000
    s3:
      scheme: "https"
      bucket: "oth-io-oth-prod-objectstorage"
      region: "eu-west-1"
      host: "s3.eu-west-1.amazonaws.com"
      port: 443

Default:

All objectstorage: keys must be configured.

If the OTH minio service is used as object-storage service, scheme: must be set to http.

guidance

Purpose:

The guidance: service allows setting up references to guides and other informational documents by referring to it by a HTTP link.

If upload is enabled, a S3 bucket needs to be configured and allow “list” from world.

No sensitive documents should be referred/uploaded by this service.

If the OTH minio service is used as object-storage service, upload: of files is not supported.

key configuration

config:upload:enabled: Values can be [ true | false ] - set to true to enable upload to S3 bucket support.

config:upload:s3bucket: Name of the S3 bucket to store files in.

Example configuration:

guidance:
  config:
    upload:
      enabled: false
      s3bucket: oth-io-oth-prod-guidance

Default:

config:upload:enabled: false

notifications

Purpose:

Adds configuration for push notification support for Android and iOS mobile devices.

key configuration

config:job:schedule: how often updated questionnaire schedules should be pushed out to patient mobile devices. Defined in standard linux crontab time format.

config:fcm:key: config:fcm:email:, config:fcm:project_id google firebase credentials. Provided by OTH if the default OTH apk/aab is used.

config:apns:key:, config:apns:key_identifier: apple appstoreconnect key and key identifier.

config:apns:team_id:, config:apns:bundle_id: team and bundle id.

Example configuration:

notifications:
  config:
    job:
      schedule: "0 * * * *"
    fcm:
      key: "my fcm_key"
      email: "my fcm_email"
      project_id: "my fcm_project_id"
    apns:
      key: "my apns_key"
      key_identifier: "my apns_key_id"
      team_id: "my apns_team_id"
      bundle_id: "my apns_bundle_id"

Default:

notifications: no default is set, fcm key and apns info is provided by OTH if default app is used.