Skip to main content

Krane Subscriptions and Licensing Entities

  • Status: Accepted
  • Deciders: Andres, Kamil, Artur, Marcin, Anton

Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

Decision Drivers

  • We want a flexible subscriptions and licensing setup
  • Flexible billing and contracts
  • License renewal
  • Needs to be scalable
  • Support suborganizations

Considered Options

Licenses per Project

erDiagram
Organization {
string name
string department
string address
string coc_number
}
Subscription {
date start_date
date end_date
enum renewal_period "yearly/monthly"
enum billing_period "yearly/monthly: billing per period (at the start of the period with a fixed number of licenses)"
bool auto_renewal "Automatic renewal of subscription or not"
enum subscription_type "Fixed Fee / Usage Based"
number fixed_fee_price "Price per billing (renewal?) period"
bool allow_sub_organizations
list modules "Enabled modules"
list module_pricing "Custom module pricing"
}
Project {
date start_date
date end_date
enum default_license_renewal_period "yearly/monthly, automatically set start_date and end_date of patient licenses"
bool default_license_auto_renewal "automatically set auto_renewal of patient licenses"
list modules "Enabled modules"
}
Consent {

}
Patient {

}
License {
enum module "the module this license is for"
date start_date
date end_date
enum renewal_period "Override Project renewal period"
enum auto_renewal "Override Project auto_renewal"
}

Organization ||--|| Subscription : has
Subscription ||--|{ Project: contains
Subscription ||--o{ Organization: has-suborganization
Project ||--|{ Consent: has
Project ||..|{ Patient: has
Patient ||--|{ License: has
License }o..|| Module: lincenses
Subscription ||..|{ Module: has-access
Project ||..|{ Module: has-access

Due to MongoDBs non-relational structure it's probably best to store Licenses in the Patient/User document as a list. Each license only applies to one module (biomarker). This has the advantage that in the case of joining multiple Projects the licenses for the same modules are reused.

For top-level organizations billing is done by orikami based on the subscription of the organizations. For sub-organizations, the parent (top-level) organization will bill the sub-organizations.

Licenses per Module

erDiagram
Organization {
string name
string department
string address
string coc_number
}
Subscription {
date start_date
date end_date
enum renewal_period "yearly/monthly"
enum billing_period "yearly/monthly: billing per period (at the start of the period with a fixed number of licenses)"
bool auto_renewal "Automatic renewal of subscription or not"
enum subscription_type "Fixed Fee / Usage Based"
number fixed_fee_price "Price per billing (renewal?) period"
bool allow_sub_organizations
list modules "Enabled modules"
list module_pricing "Custom module pricing"
}
Project {
date start_date
date end_date
enum default_license_renewal_period "yearly/monthly, automatically set start_date and end_date of patient licenses"
bool default_license_auto_renewal "automatically set auto_renewal of patient licenses"
list modules "Enabled modules"
}
Consent {

}
Patient {

}
License {
date start_date
date end_date
enum renewal_period "Override Project renewal period"
enum auto_renewal "Override Project auto_renewal"
}

Organization ||--|| Subscription : has
Subscription ||--|{ Project: contains
Subscription ||--o{ Organization: has-suborganization
Project ||--|{ Consent: has
Project ||..|{ Patient: has
Project ||--|| License: defines
Patient ||--|{ License: has
Subscription ||..|{ Module: has-access
Project ||..|{ Module: has-access

The only difference with the previous option is that instead of a license for each module, one license is used per project. This has as a consequence that if a Patient joins more than 1 Project, duplicate licenses for certain modules can be licensed.

Decision Outcome

Chosen option: Licenses per Module KRN-69

Requirements:

  • 1 license per module per patient
  • Support (and enforce) 1 active study per patient
  • Only support monthly license renewal
  • If a patient is assigned to a new study with a module/feature for which they already have a license, the license end_date will be updated to the latest date (from each project the patient is part of). Auto renewal will be OR (if any project enables auto renewal it is enabled for the license).
  • Support (and enforce) 1 Subscription per organization

Positive Consequences

  • Flexibility
  • No double billing of modules when part of multiple projects
  • Better handling of multiple projects (even when there is only one active project)

Negative Consequences

  • Modules vs Features need to be figured out.