WHO SMART Trust
1.0.0 - 1.0.0 International flag

This page is part of the Trust (v1.0.0: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, 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