Generated from smart-base/processes/content/l2-dak-authoring.bpmn by gen-processes-viz.ts — do not edit here. All processes

L2 DAK authoring

Process_L2Dak · advisory · 11 step(s)

How a WHO SMART Guidelines L2 Digital Adaptation Kit is authored by a business analyst, a terminologist and a clinical SME under a programme manager. folio-assistant — authoring a WHO SMART Guidelines L2 Digital Adaptation Kit. Source of truth: this file. Open it in bpmn.io, Camunda Modeler, or any other BPMN 2.0 tool. The SVG under docs/assets/img/workflows/ is generated from it by bun run cat render:bpmn — never hand-edit the SVG. The extension on an activity names the folio-assistant skill that implements it; marks a step that reads or writes the shared work plan in beans/. Each of the six authoring tracks is a call into l2-component-edit-review.bpmn (Process_L2ComponentEditReview): the agent edits the component, checks, renders and stages it, and hands it on, while a person in the component's reviewing role reviews it alongside, never as a gate. The track's renderer, checker and reviewer are tabled in the skill l2-component-edit-review.

How it connects

• Called by: no call activity names this process
• Calls: L2 component edit and review
• Names the l2-dak-authoring skill without calling this process: L2 DAK to L3 FHIR IG, SMART Guideline end to end — activity-calls-skill-process asks whether each should be a call activity.
• Presented on: WHO SMART Guidelines content types — WHO SMART Guidelines DAKs (L2), Authoring a WHO SMART DAK (L2) — The L2 artifacts
• Skill: l2-dak-authoring

Lanes — who acts

lane	role	what it does here
Programme manager / technical officer	programme-manager	Sets the scope once, before the fork into six parallel authoring tracks. The actors and processes enumerated here are what everything downstream, including the terminology and clinical lanes, is scoped against, and nothing later in this diagram revisits that boundary.
Work plan — beans (shared by humans and agents)	work-plan	A single claim made once, right after scoping and before the parallel fork. Unlike the per-edit lifecycle in editing-hci-validation, this diagram seeds one bean for the whole DAK and never returns here to log or resolve it, so tracking any one track’s own progress is not this lane’s concern.
Business analyst	business-analyst	Opens the parallel fork into six authoring tracks — five landing here, the sixth (terminology) crossing into a separate lane — and re-enters that same fork whenever clinical validation sends work back, so a fix after Gateway_Accurate revisits every track it is entangled with rather than patching only the one SME flagged. Performs the assemble-and-validate in parallel with clinical validation, not after it (owner, 2026-10-14: adjudication is QA, not a gate), and again after any rework. Before any of that, and before the work plan is seeded, builds the DAK’s L1 library from what its Component 1 cites, so every track starts with the guidance it operationalises already in the library and in the L1 graph.
Terminologist	terminologist	One parallel branch of the fork, producing bindings the other five tracks cite rather than author themselves, and calling the same edit-and-review subprocess as they do, with a different terminologist as its reviewer. Kept a separate lane rather than folded into the analyst’s because governance of a code binding is deliberately independent of the artefact that cites it.
Clinical SME	clinical-sme	Clinical validation runs beside assembly, not before it: it is QA, not a gate (owner, 2026-10-14). A “no” here does not return to the specific task that erred but loops back through Gateway_AuthorMerge into the fork itself, so this lane’s judgement — not the analyst’s — decides whether personas, BPMN, DMN, data dictionary and indicators all get revisited together.

Steps

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

step	lane	skill / sub-process	what it does
Scope the DAK Task_ScopeDak	Programme manager / technical officer	content-plan	Enumerate the processes, decisions and data elements the guideline implies; identify the actors.
Build the L1 library from Component 1 Task_L1Library	Business analyst	dak-l1-library	Ingest the DAK into the library; it is L2, so it gets no L1 graph. Read Component 1 §1.2 for the sources it draws on (extract-dak-l1-references.ts –context-only), then fetch each L1 source on its own — fetch-dspace-item.ts for an IRIS handle, fetch-who-publication.ts for a who.int item page — and ingest it. Record whether each is L1 on its intake (declared > context > inferred; –record-context writes §1.2’s context). For each L1 source, run l1-specialise.ts: its publication, sections and elements as specialisations of its library nodes, since the library is upstream of L1. Validate with the smart-base Zod validator. Fidelity — does each citation name the source it resolves to — and a cited edition older than the one fetched are left to a person, never passed automatically.
Seed the work plan Task_SeedBeans	Work plan — beans (shared by humans and agents)	todo-manager	Turn the scope into beans on the shared work plan — one per DAK component, since a DAK is completed component by component. beans create is not idempotent: check for an existing bean before every create, or a re-run duplicates the plan.
Personas and scenarios Task_Personas	Business analyst	calls L2 component edit and review l2-dak-authoring l2-component-edit-review	Author the DAK’s personas and the user journeys (scenarios) they appear in, then have them reviewed: calls Process_L2ComponentEditReview with the personas-and-scenarios inputs of the skill l2-component-edit-review (checker: dak-swimlanes.ts and traceability to L1 recommendations; renderer: the persona card and a prose diff; reviewer: clinical SME). These are the DAK’s own actors, not this harness’s scenarios/roles.json — the two vocabularies must not be conflated.
Business processes · BPMN 2.0 Task_Bpmn	Business analyst	calls L2 component edit and review bpmn-authoring l2-component-edit-review	Author the DAK’s L2 business processes as BPMN 2.0, with Diagram Interchange: a .bpmn with no x/y on its shapes parses and renders blank. Stay at L2 — reviewable by a clinician, not FHIR. Calls Process_L2ComponentEditReview with the BPMN inputs of the skill l2-component-edit-review (checker: bpmn-js import with no warnings, dak-swimlanes.ts, artefact-reachability; renderer: render:bpmn with a visual-diff before/after; reviewer: clinical SME).
Decision logic · DMN tables Task_Dmn	Business analyst	calls L2 component edit and review dmn-authoring l2-component-edit-review	Author the decision and scheduling logic as DMN tables, within the FEEL subset the interpreter implements (any, literals, comparisons, one-of). Ranges, not() and function calls are refused at load, so write inside the subset. Calls Process_L2ComponentEditReview with the DMN inputs of the skill l2-component-edit-review (checker: load, reachability, test cases; renderer: dmn2html table before/after, each rule beside its L1 citation; reviewer: clinical SME).
Data dictionary and core data elements Task_DataDict	Business analyst	calls L2 component edit and review l2-dak-authoring l2-component-edit-review	Author the data dictionary and core data elements for this component. Stay structured but not FHIR: a data element a clinician can review, from which L3 can later be derived rather than written twice. Calls Process_L2ComponentEditReview with the glossary inputs of the skill l2-component-edit-review (checker: check-dak-annexes.ts; renderer: the term diff from dak-data-dictionary-diff.ts and each form’s chosen wireframe; reviewer: clinical SME, terminologist for codes).
Indicators and requirements Task_Indicators	Business analyst	calls L2 component edit and review l2-dak-authoring l2-component-edit-review	Author the component’s indicators and its functional and non-functional requirements. These are the DAK’s requirements, distinct from skills/requirements/*.json, which are this harness’s own conformance obligations. Calls Process_L2ComponentEditReview with the indicators-and-requirements inputs of the skill l2-component-edit-review (checker: each names the persona and process it serves and traces to L1; renderer: prose diff; reviewer: business analyst with the programme manager).
Terminology bindings Task_Terminology	Terminologist	calls L2 component edit and review terminology-management l2-component-edit-review	ICD-11, SNOMED CT, LOINC bindings — governed separately from the artifacts that cite them. Calls Process_L2ComponentEditReview with the terminology inputs of the skill l2-component-edit-review (checker: bindings resolve and unmappedConcepts is reported; renderer: the term diff on the code columns; reviewer: a terminologist other than the one who bound it).
Clinical validation Task_SmeValidate	Clinical SME	content-review	Ground truth: does the DAK say what the guideline says? This is the whole-DAK reading, across components: whether the personas, processes, decisions, data elements and indicators tell one consistent story. Each component has already had its own review, forking off inside its track (Process_L2ComponentEditReview, skill l2-component-edit-review), so this step does not repeat those per-component reviews.
Assemble and validate the DAK Task_AssembleDak	Business analyst	content-validate	Assemble the validated components and run content validation: schemas, cross-component consistency and terminology bindings. The smart-base extractors read the authored artefacts; with SMART_BASE_HOME unset they report skip, never a clean run.

Decisions

Every one of the 1 decision(s) is documented.

decision	what decides it	branches
Clinically accurate? Gateway_Accurate	The clinical validator’s result. changes needed goes back to the author, and the reworked DAK is assembled again; validated records the adjudication. Assembly does not wait for this decision.	changes needed → Gateway_AuthorMerge validated → Clinically validated