catch up

input/pagecontent/authoring_overview.md

@@ -1,6 +1,5 @@
 {% include l2_l3_overview.md %}
 
-Authoring L3 consists in creating, validating and publishing L3 FHIR artifacts that correspond to the L2 specifications.
 
 #### Overview of Content types
 

input/pagecontent/content_types.md

@@ -1,7 +1,7 @@
 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:60%; align:center"/>
+<img src="./content_types.png" style="width:50%; align:center"/>
 <br clear="all"/>
 
 

input/pagecontent/diagram_legend.md

@@ -7,15 +7,15 @@ This specification uses:
 3. Representation of starting artifacts as technology artifacts (e.g., files or data objects).
 4. Display of processes within the application layer, illustrating how functional processes transform L2 inputs  into L3 outputs.
 
-## ArchiMate Notation Overview
+### ArchiMate Notation Overview
 
-### Layers:
+#### Layers:
 
 - **Application Layer**: Offers a functional description, typically illustrating processes, functions, and services. This is represented by blue elements.
 
 - **Technology Layer**: Represents actual artifacts, like files, resource instances, or other data objects. This is represented by green elements.
 
-### Relations :
+#### Relations :
 
 The relations are represented by arrows
 
@@ -34,7 +34,7 @@ The relations are represented by arrows
 </figure>
 
 
-### Example Diagram:
+#### Example Diagram:
 <img src="./l3_process_indicator.png" style="width:50%"/>
 <br clear="all"/>
 > The diagram above shows the process for creating an indicator: 
@@ -46,12 +46,12 @@ The relations are represented by arrows
 * The output of this is the L3 library that is referenced by the Measure resource
 
 
-## Artifact Authoring Processes
+### Artifact Authoring Processes
 
 The diagrams capture the essence of transforming an L2 input into the corresponding L3 artifacts through processes. These processes can use different tooling or technologies; however the criteria for output and for process are defined.
 
 
-## Data Object Details with PlantUML
+### Data Object Details with PlantUML
 
 To describe the content L3 authors are supposed to produce, the key content of the output artifacts is modeled with PlantUML diagrams. This discloses some of the intended structure, relationships, and attributes of the L3 artifacts.
 

input/pagecontent/l2_l3_overview.md

@@ -1,6 +1,8 @@
 
 
-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: 
+Authoring L3 means taking the L2 input, using the recommended processes and tools, and creating, validating and publishing publishing L3 FHIR artifacts that correspond to the L2 specifications.
+
+While the exact authoring steps depend on the inputs, the key sequence could normally consist of the following steps: 
 
 * [Logical Models](l3_logicalmodels.html)
 * [Profiles](l3_profiles.html)
@@ -21,7 +23,7 @@ Before that, the first step in L3 production is an input verification of the L2
 The L2 content is presented in the artifacts represented in the diagram below:  
 
 <br clear="all"/>
-<img src="./l2_artifacts.png" style="width:60%"/>
+<img src="./l2_artifacts.png" style="width:50%"/>
 <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.

input/pagecontent/l3_logicalmodels.md

@@ -1,12 +1,12 @@
 
 Logical models represent the data structures in the Digital Dictionary. This is a computable representation that is independent of any physical limitation like which FHIR Release or profile version is used. 
-The use of FHIR loogical models allows metadata to be structured, computable, and interoperable, for the purposes of governance and checking.
+The use of FHIR logical models allows metadata to be structured, computable, and interoperable, for the purposes of governance and checking.
 
 Creating a FHIR logical model entails capturing the elements in the Data Dictionary, with their description, terminology and cardinality constraints.
 
 Logical models relate to other models in 3 aspects:
 * Logical models can extend or constrain "parent" models - for example a Patient extending a Person
-* Logical models can "contain" other models as a data type - for example patient and practitioner containing "name" ddata structure
+* Logical models can "contain" other models as a data type - for example patient and practitioner containing "name" data structure
 * Logical models can refer to other models - for example a request referencing a product
 
 
@@ -60,9 +60,9 @@ This is the "atomic" unit of exchange or use in the L3. Some factors may influen
 The logical model name has the name of the tab.
 Logical model should conform to the [SGLogical](http://build.fhir.org/ig/WorldHealthOrganization/smart-base/StructureDefinition-SGLogicalModel.html) model profile.
 
-Creating the logical model from a DAK consists in creating the data structure, linking the elements to the common concept identifiers or, if that is not possible, to the internal unique concept identifiers (e.g. `DE1`, etc.). Additionally, assigning valuesets (creating them when needed), and capturing any constraints that are persent in the L2.
+Creating the logical model from a DAK consists in creating the data structure, linking the elements to the common concept identifiers or, if that is not possible, to the internal unique concept identifiers (e.g. `DE1`, etc.). Additionally, assigning valuesets (creating them when needed), and capturing any constraints that are present in the L2.
 
-To start creating the logical model, an intake validation is useful, although it can be done simultaneouslty done with the editing of the logical model:
+To start creating the logical model, an intake validation is useful, although it can be done simultaneously done with the editing of the logical model:
 1.  Verify that each data element needed exists in the common Glossary
     1.  If not, create and provisionally use a draft concept, and
         request that concept to be added to the common glossary.
@@ -82,7 +82,7 @@ The hierarchical naming will depend on several factors and is best addressed by
     -   DE.1 Do you have measles?
     -   Yes → C.1 Yes
     -   No → C.2 No
-    -   Unknow → C.3 Unknown  
+    -   Unknown → C.3 Unknown  
 
 *   Data Element Label is captured in 2 places:
     -   Element short description (`differential.element[*].short`): same as element label

input/pagecontent/versioning.md

@@ -1,4 +1,4 @@
-## Versioning
+### Versioning
 
 Versioning is critical to ensuring that consumers of the SMART guideline can understand when changes occur how those changes impact their implementations. For this reason, SMART guidelines SHALL follow semantic versioning as prescribed in the [Artifact Versioning]({{site.data.fhir.ver.crmi}}/artifact-lifecycle.html#artifact-versioning) topic of the Canonical Resource Management Infrastructure IG.
 
@@ -14,7 +14,7 @@ This process repeats for each release of the implementation guide.
 
 Note that the FHIR publication tooling uses the `version` of the implementation guide overall to set the `version` element of all the canonical resources in the implementation guide (i.e. all the Library, CodeSystem, ValueSet, StructureDefinition, etc.,.). As such, the `version` element of individual resources in the implementation guide should not be set, allowing the publisher to set the versions appropriately.
 
-## History
+### History
 After [publication](ig_publication.html), any changes to the L3 resources should be tracked. 
 
 Tracking changes should include:
@@ -23,15 +23,15 @@ Tracking changes should include:
 * Differencing between different versions of a publication
 * Release Notes
 
-### Github Issues
+#### Github Issues
 * Every change should be traceable to a GitHub issue. This allows tracking the change and any approvals/discussions, as well as assisting in creating release notes.
 
 * State of each issue: GitHub issues should not be considered "done" when the change is agreed, but only when the change is effectively implemented and tested and the respective criteria is met.
 
 
-### Change History and Release Notes
+#### Change History and Release Notes
 
 See the [publication]ig_publication.html) topic for a detailed discussion of how to create change history and release notes (including known issues).
 
-### Version Difference
+#### Version Difference
 For some artifacts, the FHIR ImplementationGuide tooling may highlight the differences in the content of the artifacts between two versions. This can be used to track and demonstrate the detailed artifact changes.

sushi-config.yaml

@@ -104,8 +104,7 @@ menu:
   Validating IG:
     QA Check: 'qa_check.html'
   Indices:
-    Artifacts:
-      Extensions: 'artifacts.html'
+    Artifacts: 'artifacts.html'
 
 pages: 
   index.md: