Generated from fhir-harness/processes/content/questionnaire-wireframe-review.bpmn by gen-processes-viz.ts — do not edit here. All processes

Questionnaire wireframe review

Process_QuestionnaireWireframeReview · advisory · 10 step(s)

A built FHIR Questionnaire shown the way a person will meet it — a mid-fidelity wireframe at web and mobile width, and a live LHC-Forms form view — checked field for field against the L2 wireframe it was derived from, reviewed as a design, staged with deep links, and changed through requests that say which side was edited. Operating skill: fhir-questionnaire-wireframe. Owner decisions, 2026-10-14: LHC-Forms, vendored; the checker lives in this layer; either the Questionnaire or the wireframe may be the source of a change, and the request says which.

WHERE IT SITS. After SUSHI has compiled the Questionnaire to JSON (l3-fhir-pipeline, Task_Sushi), and wherever a layer above reviews a Questionnaire’s fidelity to its wireframe. It reads JSON only, so it can run on any IG that produces a Questionnaire.

WHAT IT DOES NOT CLAIM. A faithful Questionnaire is not therefore a good form, and an accepted form is not therefore conformant: wireframe-design-review judges the first and fhir-validation the second.

How it connects

• Called by: no call activity names this process
• Calls: Wireframe design review
• Presented on: no docs page section shows this diagram

Lanes — who acts

lane	role	what it does here
FHIR modeller	fhir-modeller	Owns the Questionnaire end to end: reads the BUILT JSON, draws the wireframe and the form view, asks for review with deep links, triages the change requests that come back and applies each to the side the request did not touch, so the Questionnaire and its L2 wireframe agree again. It is also the only lane with a path back to the start: every accepted change re-enters at Task_Read, so a change is rendered, checked and reviewed exactly as the first version was.
Build pipeline — rendering, screenshots, fidelity	build-pipeline	The mechanical steps, none of which decides anything a person has to own: screenshots at both viewports (wireframe-check), the field-for-field fidelity check against the L2 wireframe when there is one, and the staging build. A fidelity finding does not stop the run here; it travels into the review as evidence, because whether a mismatch is the wireframe’s fault or the Questionnaire’s is the change request’s call, not the checker’s.
Business analyst — design review	business-analyst	Reviews the rendered form as a design against the workflow it serves, through wireframe-design-review: blind, per criterion, at web and mobile width, adjudicated where reviewers disagree. Here because the question is whether the form lets its user do the task, which is the business analyst’s to answer rather than the modeller’s, who drew it.
Clinical reviewer — the staged form	clinical-sme	Reads the staged form view and wireframe at the deep links Task_AskReview sent, and judges what the form asks and in what order. The only lane that can send the Questionnaire back: a change is requested through ✍ suggest or the questionnaire-change issue form, on either side, and nothing else re-opens the loop.

Steps

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

step	lane	skill / sub-process	what it does
Read the built Questionnaire JSON Task_Read	FHIR modeller	fhir-questionnaire-wireframe	fsh-generated/resources/Questionnaire-.json, or the IG's published Questionnaire-.json — never FSH. The JSON is what every renderer and reader receives, so it is what is judged.
Render the wireframe and the LHC-Forms view Task_Render	FHIR modeller	fhir-questionnaire-wireframe	A mid-fidelity wireframe with one field per answerable item, each carrying data-element and sitting in a data-layout web or mobile subtree; and the form view, the same JSON in the vendored web component on the IG site's form page. Never a CDN at runtime (owner, 2026-10-14).
Screenshots, web and mobile Task_Screens	Build pipeline — rendering, screenshots, fidelity	wireframe-design-review	cat-harness Tool wireframe-check: 1280×800 and 390×844; renders, no-overflow and no-placeholder, each a script entry. A rendering missing either viewport does not enter review.
Check field for field Task_Fidelity	Build pipeline — rendering, screenshots, fidelity	fhir-questionnaire-wireframe	fhir-harness/scripts/check-wireframe-questionnaire.ts , per layout. Exit 0 faithful, 1 a finding, 2 cannot tell, which is never a pass. The findings become the output's fidelity[] and are shown to the reviewers.
Design review Call_Review	Business analyst — design review	calls Wireframe design review wireframe-design-review	cat-harness Process_WireframeDesignReview: as-is use for a form that exists, design use for one being designed. This process does not restate the method.
Stage the renderings Task_Stage	Build pipeline — rendering, screenshots, fidelity	feature-staging	The branch’s wireframes and form pages published under STAGING// by feature-staging.
Ask for review with deep links Task_AskReview	FHIR modeller	staging-review	One deep link per rendered Questionnaire and wireframe, before and after. Where the request goes — the conversation, an issue, the pull request — is a judgement, and more than one may be right: staging-review’s deep-link rule, point 5.
Review the staged form and wireframe Task_ReviewStaged	Clinical reviewer — the staged form	fhir-questionnaire-wireframe	At the deep links. A change is requested through ✍ suggest in its Questionnaire mode, or the questionnaire-change issue form, and says which side was edited: the Questionnaire or the wireframe.
Triage the change request Task_Triage	FHIR modeller	content-feedback	content-feedback triages the issue; when a review round is open it joins a change-set through public-comment instead.
Apply it, bring the other side in line Task_Apply	FHIR modeller	l3-fhir-authoring	The side the request edited is the source of the change (owner, 2026-10-14). An edited Questionnaire is applied as an FSH edit and the wireframe is redrawn to match; an edited wireframe is kept and the Questionnaire re-derived from it. Then back to Task_Read.

Decisions

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

decision	what decides it	branches
L2 wireframe exists? GW_L2	Answered by the input: was this Questionnaire derived from an L2 wireframe (a chosen wireframe-design-review candidate)? yes runs the fidelity check; no goes straight to review.	yes → Check field for field no → Design review
Change requested? GW_Change	Answered by whether a change request (an issue) was opened against this Questionnaire during the review. no accepts; yes goes to triage.	no → Form accepted yes → Triage the change request