WHO SMART Trust
1.1.1 - CI Build

WHO SMART Trust, published by WHO. This guide is not an authorized publication; it is the continuous build for version 1.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/WorldHealthOrganization/smart-trust and changes regularly. See the Directory of published versions

## Checklist

The folowing sections provides a checklist to review to ensure that a SMART Guidelines Implmentation Guide has the expected content and level of quality. This checklist is broken up according four layers of knowledge representation.

### Checklist: L1 Content

Checklist for narrative content relating the guidance, guidelines, policies and recommendations underpinning this Implementation Guide.

Section in IG | Required | Description | Expected Artifacts | Acceptance Criteria
--- | --- | --- | --- | ---
Home Page.Summary | Yes | Linkage to the primary L1 and L2 content that underpins this Implementation Guide | URL links on the home page to relevant guidance documents and a brief description of the relevance of the document to this Implementation Guide | Links exist on the home page
Home Page.Providing Feedback | Yes | Instructions to describe how feedback can be shared for all knowledge layers in the Implementation Guide | At the minimum, an email address exists to send feedback, and/or a feature to provide feedback can be provided per section shall exist | Section exists on the home page
Home.Adapting Guidelines for Country use | Yes | Guidance to countries on adapting the Implementation Guide for making adaptations for country use | adapting_guidelines.xml | Page exists under the home dropdown menu

### Checklist: L2 Content

Checklist for semi-structure content relating to business requirements, definitions of key concepts, user personas, use cases, and data dictionaries underpinning the Implementation Guide.

Section in IG | Required | Description | Expected Artifacts | Acceptance Criteria
--- | --- | --- | --- | ---
Business Requirements.Concepts | Yes | A glossary of terms and key concepts introduced in the L2 or in the Implementation Guide | concepts.xml | A page for key concepts under business requirement exists
Business Requirements.Generic Personas | Yes | Depiction of end-users and related stakeholders as introduced in the L2 | Personas.xml | A page for Personas under business requirement exists
​Business Requirements.Use Cases | Yes | User scenarios depicting how different personas will interact in a typical workflow along with use cases listed as introduced in the L2 | usecases.xml | A page for User Scenarios and Use Cases under business requirement exists
Business Requirements.Business Processes | Yes | Depiction of business processes as visual workflows as introduced in the L2 | business_process.xml | A page for depicting the visual business processes exists
Business Requirements.Data Dictionary | Yes | Data dictionary with detailed data specifications as introduced in the L2 | dictionary.xml | A page for data dictionary under business requirements exists
Business Requirements.Decision-support Logic | Yes | Decision-support logic and algorithms as introduced in the L2 | decision_support.xml | A page for decision-support logic under business requirements exists
Business Requirements.Indicator and Performance Metrics | If indicators are defined | Core set of indicators and performance metrics as introduced in the L2 | indicators.xml | A page for the indicators table under business requirements exists
Business Requirements.Functional Requirements | Yes | List of core functions and capabilities the system must have to meet the end-users’ needs and achieve tasks within the business process. | functional.xml | A page for functional requirements under business requirements exists
Business Requirements.Non-functional Requirements | Yes | List of capabilities the system must have as introduced in the L2 | nonfunctional.xml | A page for non-functional requirements under business requirements exists

### Checklist: L3 Content

Checklist for structured content relating to data models, data exchange protocols with actors and transactions defined which are defined in the Implementation Guide.

Section in IG | Required | Description | Expected Artifacts | Acceptance Criteria
--- | --- | --- | --- | ---
Data Models and Exchange.System Actors | Yes | List and description of software or human entities that interact with the system derived from business requirements defined in L2.Actors and Transactions should be defined for a general systems architecture that applies over multiple country implementations and leverages OpenHIE architecture concepts.Systems managing clinical and patient information shall be expected to interact with a shared health record, laboratory information system or a longitudinal health record as appropriate and be expected to synchronize with data collected in a clincal encounter | Actors | Actors defined are tied to and derived from L2, with a definition of who the actor is and what they do in the system at a minimum
​Data Models and Exchange.Sequence Diagram | Yes | A sequence diagram depicting the interactions between system actors in sequence derived from business process in L2 | sequence_diagram.xml | A sequence diagram exists that shows the system interactions
Data Models and Exchange.Transactions | Yes | Defined list of system transactions at an atomic level for each actor along with narrative, capability statements, structure definition, questionnaires, document bundles and composition. It can also refer to transactions in other Implementation Guides | Capability Statement, Structure Definitions, Questionnaires, Document Bundles and Composition | Artifacts exist and are defined for each actor in terms of their roles and responsibilities
Indices.Artifacts Summary.Structures:Logical Models | Yes | Structure Definition resource describing data element definitions and their associated rules of usage derived from data dictionary in L2 | Structure Definition | A logical model for each core data set/data dictionary asset mentioned in the L2 exists
Data Models and Exchange.Indicators and Measures | If indicators are defined | Thematic list of indicators defined in the IG that link to L1 and L2 guidance documents. The IG shall maintain the reference numbers as defined in the L1 and L2 for the indicators. | Measures, Value Sets | Measure is defined according to the Data Sharing Specification (DSS) described in the IHE White Paper for EXtracting Indicators from Person Level Data. The Mobile Aggregate Data Exchange (mADX) profile is leveraged.
Indices.Mappings | Yes | Relationship to IPS: The logical model defined in the IG shall be mapped to the IPS data set. | Structure Maps | For each data set defined in the IG there shall be a related mapping which uses IPS as source and the data set as target in the structure map
QA Report | Yes | Artifact ProfilesAll artifacts defined in the IG shall conform to the Shareable, Publishable and Computable profile. | StructureDefinition, ValueSet, CodeSystem, Library, ActivityDefinition, PlanDefinition, Measure, Questionnaire, GraphDefition, Metric, ImplementationGuide | QA report shows no errors for artifacts missing shareable, publishable or Computable profile conformance
QA Report | Yes | Artifact ProfilesValueSet and Library artifacts if defined shall conform to the Executable profile | ValueSet, Library | QA report shows no errors for ValueSet and Library artifacts missing executable profile conformance
Data Models and Exchange.Codings | Yes | ValueSets defined shall map to ICD-11 or one of the WHO Family of International Classifications (FIC), if the content exists. If not an openly available reference vocabulary such as LOINC shall be used | ValueSet, ConceptMaps, CodeSystems | QA report shows no errors for ValueSet and Library artifacts missing executable profile conformance

### Checklist: L4 Content

Checklist for executable content supporting guidance for adaptation to local contexts in the Implementation Guide.

Section in IG | Required | Description | Expected Artifacts | Acceptance Criteria
--- | --- | --- | --- | ---
Deployment.Testing | Yes | Example Data shall be represented via example resources for each of the UN Languages | FSH files or FHIR Resources, and examples listed under the example tab of resourcesQA Report | For every non abstract profile there should be an example resource for each of the UN Languages
Deployment.Testing | No | Test Definitions are written along with brief description of the scope of testing covered. | Gherkin .feature files | Acceptance Criteria is written for each test definition.All PlanDefinitions and Measures should have defined Test Cases
Deployment.Testing | No | Test data represented as resources for the test definitions | Synthea scripts of FSH files | All CQL libraries have associated test libraries
Deployment.Reference Implementations | No | Links to list of reference implementations | Links to software download, source code, install documentation, user manuals and such |
Downloads | ? | All IG Content shall be available to download as zip or npm package | Zip, npm package | Links to npm package are available

### Checklist: Global

Checklist applicable for the Implementation Guide in general.

Section in IG | Required | Description | Expected Artifacts | Acceptance Criteria
--- | --- | --- | --- | ---
Home Page | Yes | Status and maturity level of the Implementation Guide is based on the CMM (Capability Maturity Model) framework and the intention is to give implementers a sense of how mature the Implementation Guide is.TODO: define maturity levels such as 'draft', 'candidate recommendation/STU', 'published/recommendation/normative'. | Disclaimer notice indicating the maturity level of the implemenation guide | Maturity level is indicated in the 'STU Note' block quote on the home page of the Implementation Guide.
Home Page and Footer | Yes | Versioning policy of the Implementation Guide is based on FHIR versioning and Semantic versioning. Each IG version s hall be identified by a string composed from 4 parts: major.minor.patch-label. | STU Note and the footer display the versiono of the IG | Criteria#1: If any artifact under the IG undergoes a change, then the IG must undergo a version update that follows semantic versioning. Criteria#2: If the IG version is updated then all the artifacts under it inherit the version number and get updated as well.
| Yes | Shall follow all HL7 FHIR Implementation Guide Publishing Requirements |  |
Footer | Yes | The IG publisher reports many errors in the file qa.html. This shall be published so that any reviewer of the specification can check the status of the IG. | qa.html | QA Report has no errors or unsuppressed warnings. All suppressed warnings must have a reasonable explanation for suppression
Home.Changes | Yes | A page that describes all version releases with a brief description of major changes | changes.xml | A page for versioning and release notes exist