Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update IG configuration #96

Merged
merged 12 commits into from
May 10, 2024
6 changes: 3 additions & 3 deletions ig.ini
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
[IG]
ig = fsh-generated/resources/ImplementationGuide-who.fhir.smart-ig-starter-kit.json
#template = #local-template
template = who.template.root#current
ig = fsh-generated/resources/ImplementationGuide-smart.who.int.ig-starter-kit.json
template = #local-template
#template = who.template.root#current
#template = ihe.fhir.template#current
usage-stats-opt-out = false
fhir-version = 4.0.1
Expand Down
4 changes: 0 additions & 4 deletions input/pagecontent/assumptions.md

This file was deleted.

36 changes: 24 additions & 12 deletions input/pagecontent/authoring_artifacts.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
L3 authors are expected to create the necessary artifacts to cover the entire L2 specification and demonstrate a working SMART Guideline. This includes several types of artifacts and possibly narrative content.

L3 authors create the necessary artifacts to cover the entire L2 specification and demonstrate a working SMART Guideline. This includes several types of artifacts and possibly narrative content.

### Input: L2 artifacts

Expand Down Expand Up @@ -79,12 +78,7 @@ L3 authors are expected to create the necessary artifacts to cover the entire L2


### Result: L3 Artifacts
The diagram and table below shows the content types that are to be created as part of the L3 authoring process.


<img src="./l3_artifacts.png" style="width:80%; align:center"/>
<br clear="all"/>

The table and diagram below show the content types that are to be created as part of the L3 authoring process.

<table border="1">
<thead>
Expand Down Expand Up @@ -120,7 +114,7 @@ The diagram and table below shows the content types that are to be created as pa
<td><a href="l3_testing.html">Testing</a></td>
</tr>
<tr>
<td>TestScript??</td>
<td>TestScript</td>
<td>input/testing</td>
<td><a href="l3_testing.html">Testing</a></td>
</tr>
Expand Down Expand Up @@ -233,6 +227,13 @@ The diagram and table below shows the content types that are to be created as pa
</tbody>
</table>

This is an overview of these objects:

<img src="./l3_artifacts.png" style="width:60%; align:center"/>
<br clear="all"/>



### File locations

#### Narrative
Expand Down Expand Up @@ -288,17 +289,28 @@ Resource IDs
* **`Resource-id`** is also valid, although not preferred


<div class="info-box must">
<span class="info-title">Resource IDs can only use up to 64 letters,numbers, hyphens and periods.</span>
Resource Ids must be combination of letters, numbers, hyphens, and periods. Ensure that the name is at least 1 character long but does not exceed 64 characters in length. The expression is <pre>[A-Za-z0-9\-\.]{1,64}</pre>
</div>



## File Names

* Resource file names must match the resource id. For profiles, this means the profile id.
* Tools are case sensitive - file names shall not have overlapping names differing only in case
* Sushi / FSH Aliases should be stored in `fsh/Aliases.fsh`
* See [versioning](versioning.html)


<div class="info-box must">
<span class="info-title">Names must start with an uppercase character, and may contain letters, numbers or underscores</span>
Names must start with an uppercase letter followed by up to 254 characters that can be a mix of letters, numbers, or underscores. The expression is <pre>^[A-Z]([A-Za-z0-9_]){1,254}$</pre>
</div>


### Versioning
see also [versioning](versioning.html)


## Governance
<p class= "todo">TO DO: Adding artifacts, what goes into common-clinical, etc.</p>

2 changes: 1 addition & 1 deletion input/pagecontent/authoring_overview.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
Authoring L3 consists in creating, validating and publishing L3 FHIR artifacts that correspond to the L2 specifications.

<img src="./l3_authoring.png" style="width:80%; align:center"/>
<img src="./l3_authoring.png" style="width:60%; align:center"/>
<br clear="all"/>


Expand Down
161 changes: 77 additions & 84 deletions input/pagecontent/content_types.md
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)

19 changes: 8 additions & 11 deletions input/pagecontent/gov_overview.md
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
12 changes: 10 additions & 2 deletions input/pagecontent/ig_configuration.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
### **ImplementationGuide configuration**

**Actor**: L3 Author
The L3 Author needs to configure the Implementation Guide:

For WHO-authored Guidelines (i.e. not for adaptations), the configuration includes:

* Canonical url: http://worldhealthorganization.github.io/smart-ig-starter-kit
* Package id: who.fhir.???? Or who.fhir.smart.??? Or who.smart.fhir.?
Expand All @@ -10,4 +12,10 @@
- If there is no affiliate or the affiliate declines, other organizations should step in…


L3 authors should ensure that the content has some feedback mechanism.

For National adaptations:
- If the country or region has an an HL7 affiliate, the HL7 affiliate can include the smart guidelines in their publication process and use the defined conventions
- Package id convention is defined locally, e.g. `hl7.fhir.country.smart.xxx`
- If there is no affiliate or the affiliate declines, other organizations

* L3 authors should ensure that the content has some feedback mechanism.
10 changes: 1 addition & 9 deletions input/pagecontent/ig_setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,15 +47,7 @@ The default branch is expected to build with the empty default content. Until a



The default branch is expected to build with the empty default content. Until a release is published, it SHOULD always clearly indicate it is not a published release - or in the README or in the IG itself, an indication that the work may be followed in another location (pointing to the branch)


### ImplementationGuide Configuration

After initializing the IG, it must be configured:

* Canonical url: `http://worldhealthorganization.github.io/smart-ig-starter-kit`
* Package id: `who.fhir.????` Or `who.fhir.smart.???` `Or who.smart.fhir.?`

* L3 authors should ensure that the content has some feedback mechanism.

The Implementation Guide must be configured. See [ImplementationGuide Configuration](ig_configuration.html)
25 changes: 14 additions & 11 deletions input/pagecontent/l2_l3_overview.md
Original file line number Diff line number Diff line change
@@ -1,15 +1,6 @@
The first step in L3 production is an input verification of the L2 content.

The L2 content is presented in the artifacts represented in the diagram below:

<br clear="all"/>
<img src="./l2_artifacts.png" style="width:80%"/>
<br clear="all"/>


* It is important to track the versions of L2 content, especially when adapting L2 or L3 to a local implementation, in order to track changes and assess impact of those changes.For this same reason, there's a versioning and change management section in this document.

Authoring Steps:
Authoring L3 means taking the L2 input and, using the recommended processes and tools, create the L3 artifacts. While the exact authoring steps depend on the inputs, the key sequence could normally consist of the following steps:

* Logical Models
* Profiles
Expand All @@ -23,4 +14,16 @@ Authoring Steps:
* Scenarios
* Processes
* Requirements
* Examples
* Examples

Before that, the first step in L3 production is an input verification of the L2 content.

The L2 content is presented in the artifacts represented in the diagram below:

<br clear="all"/>
<img src="./l2_artifacts.png" style="width:60%"/>
<br clear="all"/>


Authoring presumes the L2 content is available and consistent. It is possible that the L2 content gets changed, notably due to input from L3 authoring. It is important to track the versions of L2 content, especially when adapting L2 or L3 to a local implementation, in order to track changes and assess impact of those changes.For this same reason, there's a versioning and change management section in this document.

7 changes: 6 additions & 1 deletion input/pagecontent/narrative.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,12 @@ General authoring guidance:

* Pages should only contain headings of level 3 and above - 1 or 2 are not supported.
* [PlantUML diagrams](http://build.fhir.org/ig/FHIR/ig-guidance/diagrams.html) can be added
* To be shown, the pages must also be listed in the ImplementationGuide resource (or equivalently in the sushi-config.yaml).
* All narrative pages must be listed in the ImplementationGuide resource (or equivalently in the sushi-config.yaml).

<div class="info-box must">
<span class="info-title">Narrative pages must be listed in the ImplementationGuide</span>
All narrative pages must be listed in the ImplementationGuide resource (or equivalently in the sushi-config.yaml). Narrative files that are not listed will not be processed or displayed.
</div>

### XHTML
The tooling supports [xhtml](https://www.w3.org/TR/xhtml1/) pages. The file extension is `.xhtml`.
Expand Down

Large diffs are not rendered by default.

Loading
Loading