-
Notifications
You must be signed in to change notification settings - Fork 14
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #96 from WorldHealthOrganization/update-ig-setup
update IG configuration
- Loading branch information
Showing
15 changed files
with
208 additions
and
143 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,91 +1,84 @@ | ||
| The SMART Guidelines define the provision of guidance and monitoring using a structured, standardized representation of knowledge of different types: | ||
| The SMART Guidelines define the provision of guidance and monitoring using a structured, standardized representation of knowledge of different types, which are represented in L2 and L3. The L3 authoring process consists of creating the L3 artifacts from the corresponding L2 artifact (and its adjacent artifacts) - for example creating PlanDefinitions from a Decision Table. | ||
|
|
||
| <img src="./content_types.png" style="width:80%; align:center"/> | ||
| <br clear="all"/> | ||
|
|
||
|
|
||
|
|
||
|
|
||
| ### User Scenario | ||
| A narrative or situation where users interact with a system, environment, or service. User scenarios guide many subsequent knowledge representation processes to ensure coverage and focus. | ||
| * L2: []() | ||
| * L3: [Scenarios](l3_scenarios.html) | ||
|
|
||
|
|
||
| ### Generic Persona | ||
| An archetype representing a person interacting with the system. This aids in understanding the motivations and potential actions of users within scenarios. | ||
| * L2: []() | ||
| * L3: [Personas](l3_personas.html | ||
|
|
||
| ### Health Intervention | ||
| Initiatives about prevention, monitoring or addressing medical conditions. | ||
| * L2: []() | ||
|
|
||
|
|
||
| ### Business Process | ||
| A collection of related tasks or activities that achieve a specific organizational goal. Business processes often encompass or give rise to multiple user scenarios, especially in complex systems. | ||
| * L2: []() | ||
| * L3: [Business Processes](l3_processes.html) | ||
|
|
||
|
|
||
| ### Requirement | ||
| A detailed specification of a system's needs, derived from user scenarios, personas, and business processes. It forms the foundation for system design and testing. | ||
| * L2: []() | ||
| * L3: [Requirements](l3_requirements.html) | ||
|
|
||
| ### Decision Table | ||
| A structured method for representing complex decision logic. This is a basis for developing business processes and transformation logic. | ||
| * L2: []() | ||
| * L3: [Decision Tables](l3_decisiontables.html) | ||
|
|
||
| ### Scheduling Logic | ||
| The rules used to schedule tasks and interventions. | ||
| * L2: []() | ||
| * L3: [Scheduling Logic](l3_schedulinglogic.html) | ||
|
|
||
| ### Indicators | ||
| Metrics used to measure the performance or outcomes of business processes and health interventions, and guide decision-making. | ||
| * L2: []() | ||
| * L3: [Indicators](l3_indicators.html) | ||
|
|
||
| ### Data Object | ||
| A comprehensive representation of information, often deriving from business processes or requirements. They encapsulate multiple data elements. | ||
| * L2: []() | ||
| * L3: [Logical Models](l3_logicalmodels.html) | ||
|
|
||
| ### Data Element | ||
| An atomic piece of data, often a part of data objects. Elements get transformed, coded, or mapped as per transformation logic or coding systems. | ||
| * L2: DAK - This information is in the data dictionary - each data element | ||
| * L3: [Logical Models](l3_logicalmodels.html) | ||
|
|
||
| ### Coding | ||
| The assignment of codes to data elements, where applicable, using standard terminologies and mapped to other codes as needed. Coding aids in ensuring that data elements are universally understood and interpretable. | ||
| * L2: DAK - This information is in the data dictionary - each coded value in coded data elements | ||
| * L3: [ValueSets](l3_valuesets.html), [CodeSystems](l3_codesystems.html) | ||
|
|
||
| ### Mapping | ||
| Mapping the codes from one system to another, ensuring that multiple representations, when possible, are documented and accessible. | ||
| * L2:DAK - the mapping is obtained from the maps in the DAK (to LOINC, ICD-11, etc.) | ||
| * L3: [Mapping](l3_conceptmaps.html) | ||
|
|
||
| <img src="./content_types.png" style="width:60%; align:center"/> | ||
| <br clear="all"/> | ||
|
|
||
| ### Form | ||
| A tool for data collection, often driven by the requirements of business processes or the need to collect specific data. | ||
| * L2: (This is derived from the data dictonary - each activity tab) | ||
| * L3: [Questionnaires](l3_forms.html) | ||
|
|
||
| ### Transformation Logic | ||
| The rules applied to change data from one format or structure to another. Often influenced by decision tables, coding, and mapping to ensure data integrity. | ||
| * L2: []() | ||
| * L3: [Structure Maps](l3_structuremaps.html) | ||
|
|
||
| ### Test Case | ||
| A set of conditions under which a system is assessed, often derived from requirements and user scenarios. They ensure the system performs as expected. | ||
| * L2: []() | ||
| * L3: [Test Data](l3_testing.html) | ||
| <table border="1"> | ||
| <thead> | ||
| <tr> | ||
| <th>Content Type</th> | ||
| <th>Description</th> | ||
| </tr> | ||
| </thead> | ||
| <tbody> | ||
| <tr> | ||
| <td>Health Interventions</td> | ||
| <td>Initiatives about prevention, monitoring or addressing medical conditions.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Generic Personas</td> | ||
| <td>An archetype representing a person interacting with the system. This aids in understanding the motivations and potential actions of users within scenarios.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>User Scenarios</td> | ||
| <td>A narrative or situation where users interact with a system, environment, or service. User scenarios guide many subsequent knowledge representation processes to ensure coverage and focus.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Business Process</td> | ||
| <td>A collection of related tasks or activities that achieve a specific organizational goal. Business processes often encompass or give rise to multiple user scenarios, especially in complex systems.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Requirement</td> | ||
| <td>A detailed specification of a system’s needs, derived from user scenarios, personas, and business processes. It forms the foundation for system design and testing.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Decision Table</td> | ||
| <td>A structured method for representing complex decision logic. This is a basis for developing business processes and transformation logic.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Scheduling Logic</td> | ||
| <td>The rules used to schedule tasks and interventions</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Indicators</td> | ||
| <td>Metrics used to measure the performance or outcomes of business processes and health interventions, and guide decision-making.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Data Object</td> | ||
| <td>A comprehensive representation of information, often deriving from business processes or requirements. They encapsulate multiple data elements.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Data Element</td> | ||
| <td>An atomic piece of data, often a part of data objects. Elements get transformed, coded, or mapped as per transformation logic or coding systems.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Coding</td> | ||
| <td>The assignment of codes to data elements, where applicable, using standard terminologies and mapped to other codes as needed. Coding aids in ensuring that data elements are universally understood and interpretable.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Code Mapping</td> | ||
| <td>Mapping the codes from one system to another, ensuring that multiple representations, when possible, are documented and accessible.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Forms</td> | ||
| <td>A tool for data collection, often driven by the requirements of business processes or the need to collect specific data.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Transformation logic</td> | ||
| <td>The rules applied to change data from one format or structure to another. Often influenced by decision tables, coding, and mapping to ensure data integrity.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Test Case</td> | ||
| <td>A set of conditions for which a system is assessed, often derived from requirements and user scenarios. They ensure the system performs as expected.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Test Data</td> | ||
| <td>Specific data used to execute test cases, often derived from data objects and elements, ensuring testing of system functionalities.</td> | ||
| </tr> | ||
| </tbody> | ||
| </table> | ||
|
|
||
| ### Test Data | ||
| Specific data used to execute test cases, often derived from data objects and elements, ensuring testing of system functionalities. | ||
| * L2: []() | ||
| * L3: [Test Data](l3_testing.html) | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,16 +1,13 @@ | ||
| To ensure consistency and reusability, several outcomes can be transversal across several SMART Guidelines. | ||
| SMART Guidelines L3 artifacts can be shared. This means that they can be maintained and possibly reused and referenced across Guidelines. | ||
|
|
||
| #### | ||
| The authoring process currently identifies some artifacts that are subject to "common" governance i.e. being maintained not within one single guideline, but as possibly reusable artifacts: | ||
|
|
||
| The following repositories are governed by functional / L2 people/groups - with transversal assignments: | ||
| * Glossary - (Terminology and) Information Board | ||
| * Business Processes - Architecture? | ||
| * ValueSets and CodeSystems - Terminology (and Information) Board | ||
| * Glossary - Data Elements may be defined in a common base - for example "Patient given name" and "Pregnancy status" are definitions that should be common across SMART Guidelines | ||
| * Business Processes, Personas - several of such artifacts can be used when building up an architecture from the modular components, aiming at reuse or consistency | ||
| * ValueSets and CodeSystems - Terminology assets are inherently reusable across specifications. | ||
| * CQL Common Libraries - code libraries can be maintained for reuse | ||
| * Common profiles - Reusing technical parts of the specification allows further technical interoperability. | ||
|
|
||
| #### | ||
|
|
||
| Reusable artifacts would be managed not only by their immediate author, but would have a different governance process - as an example, A central Glossary, hosted on a repository, may contain commonly agreed definitions. Authors are then encouraged to use terms from that glossary, instead of recreating definitions. | ||
|
|
||
| L3 Governance: | ||
| * CQL Common Libraries | ||
| * Common profiles | ||
| * Artifacts repository |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6 changes: 6 additions & 0 deletions
6
local-template/package/content/assets/css/font-awesome-all.min.css
Large diffs are not rendered by default.
Oops, something went wrong.
Oops, something went wrong.