DRAFT SMART Guidelines L3 SOP
0.2.1 - CI Build International flag

DRAFT SMART Guidelines L3 SOP, published by TBD. This is not an authorized publication; it is the continuous build for version 0.2.1). This version is based on the current content of https://github.com/DigitalSQR/smart-ig-starter-kit and changes regularly. See the Directory of published versions

Requirements

Requirements - functional or non-functional - are captured as L3 artifacts for the purposes of:

  • Reusability across SMART Guidelines
  • Adaptability to jurisdiction-specific guidelines
  • Traceability - for example to Testing

The L3 author is expected to capture the requirements in a Requirements resource.

The requirements capture the following data:

Requirement Setidentifier[SG] 1..*status 1..1name 1..1title 1..1description 1..1activityId 1..1category 0..* Requirementidentifier[SG] 1..*category 0..*strength 0..1 FunctionalRequirementprocess 1..*persona 1..*description 1..1text 1..1functionality 1..1goal 1..1 Non-FunctionalRequirementdescription 1..1text 1..1

Inputs:

  • Personas, Processes and Requirements from L2
  • Personas and Processes from L3

Outputs:

  • Requirements resources for all functional and non-functional requirements
  • TO DO: Minimal testing expectations for all requirements?</p> ### **Activities:** The L3 author takes the L2 requirements and expresses those as FHIR Requirements. In FHIR, the resource used is a Requirements - which is a set of requirement statements. So, each requirement in the L2 group will normally be one of the statements included in a Requirements resource. The Requirements resource identifies the Business Process for which the requirements are being expressed e.g "Register Client". The Requirements will capture the following elements: * id: the unique id of the requiremetn set, using the convention `-

    -fxnreq`, where `` is the abbreviation of the SMART guideline (e.g. `immz`) and `

    ` is the letter of the functional process e.g. `e` corresponding to "Register Client". * title: * status * statement: one statement for each requirement, e.g. * key: the unique id of the requirement e.g. `IMMZ.FXNREQ.087` * label: an optional short label for the requirement * conformance: the optional strength of the requirement * requirement: The actual text, as a Scrum-like description: * *"As a "* ... [Persona] * *"I want"* ... [Functionality/activity] * *"So that"* ... [Functional goal] ### **Output Criteria / Definition of Done:** * Each requirement shall be associated with a Persona. * Each Functional requirement shall have a link to a business [Process] that it is associated with * Each Functional requirement should have an Activity ID * Each requirement shall have a unique id, a title, and the Scrum-like description. ### **Change tracking** * Requirements are essential traceable artifacts. Every time a requirement changes, the change history shall be appended. ### **Tooling:** | Tool | Usage | Doc | | --- | ---| ---| | Sushi | Requirements can be authored in FSH syntax | [HL7 Spec](https://build.fhir.org/ig/HL7/fhir-shorthand/reference.html)
    [Sushi Documentation](https://fshschool.org) | {:.table-bordered.full-width} ### **Informative examples** ### **Known issues and dependencies:**