Generated Narrative: StructureDefinition DAK Name Flags Card. Type Description & Constraints DAK 0..* Base Digital Adaptation Kit (DAK) #xD; id 1..1 string DAK ID #xD; name 1..1 string DAK Name #xD; title 1..1 string DAK Title #xD; description[x] 1..1 DAK Description #xD; descriptionString string #xD; descriptionUri uri #xD; version 1..1 string DAK Version #xD; status 1..1 code DAK Status #xD; publicationUrl 1..1 url Publication URL #xD; previewUrl 1..1 url Preview URL #xD; canonicalUrl 1..1 url Canonical URL #xD; license 1..1 code License #xD; copyrightYear 1..1 string Copyright Year #xD; publisher 1..1 BackboneElement Publisher #xD; name 1..1 string Publisher Name #xD; url 0..1 url Publisher URL #xD; translations 0..1 BackboneElement Translation configuration #xD; sourceLanguage 1..1 code Source language BCP-47 code #xD; languages 0..* BackboneElement Target language entries #xD; code 1..1 code BCP-47 / ISO 639-1 language code #xD; name 1..1 string Human-readable language name #xD; direction 1..1 code Text direction: ltr | rtl #xD; plural 0..1 string Gettext plural form expression #xD; services 0..1 BackboneElement Enabled translation services #xD; weblate 0..1 BackboneElement Weblate configuration #xD; enabled 1..1 boolean Is Weblate enabled? #xD; url 0..1 url Weblate base URL #xD; launchpad 0..1 BackboneElement Launchpad configuration #xD; enabled 1..1 boolean Is Launchpad enabled? #xD; crowdin 0..1 BackboneElement Crowdin configuration #xD; enabled 1..1 boolean Is Crowdin enabled? #xD; healthInterventions 0..* HealthInterventionsSource Health Interventions and Recommendations #xD; personas 0..* GenericPersonaSource Generic Personas #xD; userScenarios 0..* UserScenarioSource User Scenarios #xD; businessProcesses 0..* BusinessProcessWorkflowSource Generic Business Processes and Workflows #xD; dataElements 0..* CoreDataElementSource Core Data Elements #xD; decisionLogic 0..* DecisionSupportLogicSource Decision-Support Logic #xD; indicators 0..* ProgramIndicatorSource Program Indicators #xD; requirements 0..* RequirementsSource Functional and Non-Functional Requirements #xD; testScenarios 0..* TestScenarioSource Test Scenarios #xD; Documentation for this format
Logical Model for representing a complete Digital Adaptation Kit (DAK) with metadata and all 9 DAK components
Identifier for the DAK (e.g., smart.who.int.base)
Full title of the DAK (e.g., SMART Base)
Description of the DAK - either Markdown content or a URI to a Markdown file (absolute or relative to repository root)
Canonical URL for the published DAK (e.g., https://smart.who.int/base for WHO repositories)
Preview URL for the current CI build (e.g., https://worldhealthorganization.github.io/smart-base)
The canonical URL to use for this DAK instance - equals publicationUrl for release branches, previewUrl for development branches
License under which the DAK is published
Organization responsible for publishing the DAK
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
Extensions that cannot be ignored even if unrecognized
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R4/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them
Configuration for translation services and target languages
BCP-47 code of the source language (e.g. en)
List of target languages for translation
Plural form expression for the target language
Configuration for external translation platforms
Configuration for the Weblate translation service
Configuration for the Launchpad translation service
Configuration for the Crowdin translation service
Health Interventions and Recommendations
Overview of the health interventions and WHO, regional or national recommendations included within the DAK
Depiction of the human and system actors
Narratives that describe how the different personas may interact with each other
Generic Business Processes and Workflows
Business processes and workflows for achieving health programme objectives
Data elements required throughout the different points of a workflow
Decision-support logic and algorithms to support appropriate service delivery
Core set of indicators for decision-making, performance metrics and reporting
Functional and Non-Functional Requirements
High-level list of core functions and capabilities that the system must have
Set of test scenarios to validate an implementation of the DAK