Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

What are Service Acceptance Criteria (SAC)?

Service Acceptance Criteria (SAC) are used to assure that authored SNOMED CT content meets specific quality measures before the content can be promoted. The purpose of this is to ensure a specific level of quality is met at each promotion level. This in turn assures the quality of the content that is eventually promoted to the code system branch, with the benefit of minimising the quality checks required at that level (in general, the later the stage of the content release process, the greater the amount of work needed to correct any issues, so catching issues earlier in the process has many benefits).

SAC may be defined as either automatic or manual. 

Automatic SAC are checks which the system can sign off automatically without user intervention.

Manual SAC are checks that require sign-off via a particular user interaction, with that interaction governed by role-based access controls. Some will apply only at task or project level. Some will be mandatory and some can be switched on for specific projects.

Service Acceptance Criteria and Authoring Acceptance Gateway Architecture (Authoring Platform)

Service Acceptance Criteria are components in a technical architecture solution which includes the Authoring Acceptance Gateway (AAG) and various data stores associated with acceptance and sign-off of content changes for promotion via AP tasks and projects, and also for the generation and packaging of SNOMED CT releases.

The following schematic illustrates the subset of this architecture directly related to AP features and their inter-relationships and dependencies (components relating to release preparation and packaging are omitted here for clarity, but are essential aspects of the overall technical architecture):

Service Architecture - AAG - SAC

SAC are presented in the AP as checklist items in either the task details (for task level SAC) or project page (for project level SAC).

SAC items are defined at the global level by users with the ADMIN role. This is currently constrained as a technical support feature.

Globally defined SAC items are then available as an options list to those with relevant permissions (set by RBAC role group definitions on the branch or its parents), to decide which to include in task-level or project-level gateway controls.

Some aspects of acceptance gateway controls are already implicit in the AP branch promotion process - for instance diverged content branches cannot be promoted: each branch must be rebased from its immediate parent branch with all merge conflicts resolved before the descendant branch can be promoted.

Authoring Acceptance Gateway 1: Task Level SAC examples

task-early-visibility
task-manual-spellcheck
task-review-changes

Authoring Acceptance Gateway 2: Project Level SAC examples

project-case-significance
project-documentation-completed
project-duplicate-terms
project-inactivations-associations
project-lead-signoff (typically requires PROJECT_LEAD role)
project-mrcm
project-new-descriptions
project-patterns-report
project-template-validation
project-validation-clean
project-whitelist-review

Authoring Acceptance Gateway 3: Release Level SAC examples

project-release-issues
project-release-validation-report-clean
project-final-signoff (typically requires RELEASE_LEAD role)

  • No labels