Generated from smart-base/processes/content/smart-guideline-end-to-end.bpmn by gen-processes-viz.ts — do not edit here. All processes

SMART Guideline end to end

Process_SgEndToEnd · advisory · 18 step(s)

From a use case to a consuming application: identify the L1 guidelines, ingest them into an L1 knowledge graph, choose the L2 DAKs to build on, create or adapt the L2 assets, choose the L3 IGs to build on, produce the L3 assets, then build the L4 consuming application the requester describes. Adjudication follows every stage as QA, not as a gate (owner, 2026-10-14: “once agent produces L2 it can produce L3”), but the order is a rule (owner, 2026-10-15: “order strict, sign-off QA”): no L3 asset before the L1 extraction and L2 assets it derives from exist with their review requested (Gateway_L3Ready). Each stage forks into the next stage and its adjudication, and each adjudication has its own end event, so the instance completes only when all are recorded. Each stage runs one named skill with its own input and output contract, named in brackets on the task (l2-dak-authoring.bpmn for stage 4, dak-l3-ig.bpmn for stage 6), and each stage’s output is the next stage’s input; the smart-guideline-end-to-end skill is the orchestrator that says so, and who adjudicates each.

How it connects

• Called by: no call activity names this process
• Calls: Review task
• Presented on: no docs page section shows this diagram
• Skill: smart-guideline-end-to-end

Lanes — who acts

lane	role	what it does here
Requester (country team / implementer)	user	The person who wants the guideline and the application. Describes the use case (stage 0) and the consuming application (stage 7). The agent asks; it never invents either.
Authoring agent	authoring-agent	Runs every authoring stage with the skill named on each activity. Goes straight on to the next stage after each one, once that stage’s output exists and its review is requested: adjudication runs beside it, as QA, not as a gate (owner, 2026-10-14); the order is not optional (owner, 2026-10-15).
Human adjudicators	reviewer	Clinical SME, l1-extraction-reviewer, programme manager, business analyst, FHIR modeller, terminologist: which one signs each stage is in the smart-guideline-end-to-end skill. Each adjudication calls cat-harness’s generic review, Process_Review, on the staged preview (feature-staging, staging-review) and records a qa-review/v1 Decision (approve, request-changes, reject) with the adjudicator’s role id. Each adjudication ends in its own end event, so the instance is complete only when every adjudication is recorded. A rejection files a bean against the stage and marks every downstream asset derived from the rejected item rejected-upstream; it does not stop the agent.

Steps

Every one of the 18 step(s) is documented.

step	lane	skill / sub-process	what it does
0 · Describe the use case Task_DescribeUseCase	Requester (country team / implementer)	guideline-use-case	Population, setting, jurisdiction, interventions in scope. The user’s own words; the agent asks a numbered question if the request did not say.
1 · Identify L1 guidelines and recommendations Task_IdentifyL1	Authoring agent	dak-l1-library	Component 1 sources of any DAK already in scope first, then WHO IRIS and the jurisdiction’s own guidelines. Each candidate marked in-library / in-KG / not yet.
Adjudicate the L1 source list Task_AdjL1	Human adjudicators	calls Review task content-review	Clinical SME: each source with why it was included or left out.
2 · Ingest into the L1 KG Task_IngestKg	Authoring agent	recommendation-extraction dak-l1-library	Per source not yet extracted: cat ingest into library/, the generic-document layer (l1-library), then the L1 layer (recommendations, remarks, practices, scenario candidates) into library//l1-extraction/.
Adjudicate the L1 KG Task_AdjKg	Human adjudicators	calls Review task content-review recommendation-extraction	l1-extraction-reviewer signs exclusions and coverage; Clinical SME reviews recommendations beside the printed page.
3 · Choose L2 dependencies (WHO / jurisdiction DAKs) Task_DepsL2	Authoring agent	l2-dependency-choice smart-base-tools decision-comparison	From the L1 KG: which existing DAKs to reuse, adapt, extend or reject, each with evidence and reason. Reuse first; prefer the jurisdiction’s adaptation, recording the WHO original as its upstream. For each component kept, record its toolchain: how the candidate produces it (the tools graph, the candidate repository’s own source spreadsheets and converters, WHO’s DAK toolchain), which stage 4 then uses.
Adjudicate L2 dependencies Task_AdjDepsL2	Human adjudicators	calls Review task content-review decision-audit	Programme manager and business analyst: one row per candidate DAK, rejected ones included.
4 · Create / adapt L2 DAK assets Task_L2	Authoring agent	l2-dak-authoring smart-base-tools dak-preprocessing dak-postprocessing wireframe-design-review feature-staging	The authoring steps of l2-dak-authoring.bpmn (personas and scenarios, BPMN, DMN, data dictionary, indicators and requirements, terminology), plus the design of each data-entry form as wireframe candidates (wireframe-design-review, design use) from the persona, the user scenario and the core data elements. Its clinical validation is this stage’s adjudication and does not hold up stage 5. The IG is built through fhir-harness’s AST cache lifecycle (ig-ast-refresh.yml), with the DAK pre-processing as smart-base’s pre-export overlay (dak-preprocessing, dak-pre-export.sh) and the DAK sidecars made from the AST (dak-postprocessing).
Review each L2 asset (before / after if adapted) Task_AdjL2	Human adjudicators	calls Review task content-review staging-review visual-diff wireframe-design-review	One review item per created or changed asset, shown as its reviewer reads it (diagram, table, data-dictionary rows); each form’s wireframe candidates are reviewed blind and one is chosen (Process_Adjudication, Process_OptionsAnalysis); an adapted asset as a diff against its pinned upstream. For each L2 component this is the review that forks inside its own edit-and-review subprocess (l2-component-edit-review.bpmn, called by every l2-dak-authoring.bpmn track), with the renderer, checker and reviewing role that skill tables.
5 · Choose L3 dependencies (WHO / jurisdiction IGs) Task_DepsL3	Authoring agent	l3-dependency-choice ig-artifact-ingestion smart-base-tools decision-comparison	Index each candidate IG, then match the L1 KG and the L2 assets against it: reuse, adapt, extend or reject per IG, and record per artefact type the candidate’s toolchain (CQL refresh, test-case format, example generator), which stage 6 then uses.
Adjudicate L3 dependencies Task_AdjDepsL3	Human adjudicators	calls Review task content-review decision-audit	FHIR modeller and terminologist: one row per candidate IG, rejected ones included.
Check L3 readiness Task_L3Ready	Authoring agent	l3-readiness	The order rule as a check with its own contract (owner, 2026-10-16: its own skill). Every source has its L1 extraction, every L2 asset names an L1 node, every L3 artefact about to be written names its L2 asset, and the review of each extraction and L2 asset has been requested. Returns ready and the findings, each with the stage that fixes it; Gateway_L3Ready decides on ready.
6 · Produce L3 assets Task_L3	Authoring agent	l3-fhir-authoring l2-dak-authoring smart-base-tools feature-staging	The mapping and pipeline of dak-l3-ig.bpmn, up to a clean IG build. Every L3 asset names the L2 asset it implements in wasDerivedFrom, with that edge’s adjudication state. Each Questionnaire is derived from the chosen L2 wireframe of its form. Publication continues in that process and is not on the path to stage 8.
Review each L3 asset (before / after if adapted) Task_AdjL3	Human adjudicators	calls Review task content-review staging-review ig-ast-delta wireframe-design-review fhir-questionnaire-wireframe	One review item per created or changed resource: differential, each Questionnaire against the L2 wireframe it was derived from (field to item: fhir-harness fhir-questionnaire-wireframe, whose check is check-wireframe-questionnaire), CQL beside its DMN rule with test results, terminology expansions.
7 · L4: describe the consuming application Task_DescribeApp	Requester (country team / implementer)	l4-application-brief	Who uses it, on what device, which L2 processes and L3 resources it covers, connectivity, the systems it talks to. The agent offers options drawn from the L2 personas and processes. This is the written intent wireframe-design-review starts from.
8a · L4: wireframe the application Task_WireframeApp	Authoring agent	wireframe-design-review	To-be mode, from the stage-7 intent: two or more candidates, web and mobile, with real content from the L2 personas and scenarios. The agent goes on with its recommended candidate; the requester may choose another during adjudication.
8b · L4: build the consuming application Task_BuildApp	Authoring agent	l4-application-build	Against the stage-6 IG build, with conformance tests from the IG’s examples and test cases.
Adjudicate the L4 wireframes and application Task_AdjApp	Human adjudicators	calls Review task content-review staging-review wireframe-design-review	Business analyst and clinical SME walk it through each L2 user scenario; FHIR modeller checks L3 conformance.

Decisions

1 of 2 decision(s) carry no documentation — gateway-documented lists them.

decision	what decides it	branches
All sources in an L1 KG? Gateway_InKg	—	no → 2 · Ingest into the L1 KG yes → Gateway_KgMerge
L1 extraction and L2 assets exist, review requested? Gateway_L3Ready	The order rule (owner, 2026-10-15: “order strict, sign-off QA”), decided on Task_L3Ready’s ready (skill l3-readiness). Yes only when every L3 asset about to be written has an L2 asset upstream, every L2 asset an L1 node, and the review of each has been requested (opened and staged, verdict not awaited). No goes back to stage 4; a missing L1 extraction is stage 4’s input gap, filled from stage 2.	yes → 6 · Produce L3 assets no → 4 · Create / adapt L2 DAK assets