Defining Actions, Eligibility, and Documentation in a Delphi Study
A panel can support an activity while remaining divided about who should receive it. Separate linked questions make that distinction visible and help a team define what can proceed and what still needs resolution.
Agreement on practice can coexist with uncertainty about recipients
A Finnish medication-optimization Delphi study, published October 30, 2026, used two rounds with 20 experts: five physicians, five nurses, and ten pharmacists. With a predefined 80% threshold, the panel agreed 147 items about practice and documentation. The authors observed more variation over which patient groups should receive the interventions.
The study covered one wellbeing-services county and called for evaluation of implementation and effects on medication safety and effectiveness. The publisher currently identifies the article as an early version of peer-reviewed, accepted research.
The linked-decision workflow below is Calibrum’s original extension of that methodological lesson. The fictional community-service examples illustrate questionnaire design; they are independent of the clinical study.
Give each decision a clear question and an explicit link
A statement such as “offer an introductory session to every new service user and record completion” combines an action, an eligible group, and a documentation requirement. A participant might support the session but question universal eligibility or the meaning of completion. One rating makes that reason difficult to recover.
Break the proposal into linked decisions when the research question requires separate judgments. Keep the action, eligible recipients, timing or trigger, exceptions, and recording requirement visible. Use identifiers to show which decisions form one proposed operational package.
Make each item understandable on its own by carrying the necessary context. For example, an eligibility item can refer to a defined introductory session and ask whether every new service user should be offered it. This preserves the connection without asking participants to endorse several propositions in one answer.
Plan the dependency rule before results are available. Specify which components must meet their criteria before the package can be recommended and what happens if one remains unresolved. A collection of individually accepted items still needs a coherent, approved combination.
A supported action can still have an unresolved eligibility rule
In this original fictional example, the same 20 panelists provide valid ratings on three linked items. The illustrative protocol requires at least 80% support for each required component, so at least 16 of 20 must support an item. Every component shown is required for the proposed package.
| Item and question | Support | Result under the example rule |
|---|---|---|
| A14 — Include an offer of the defined introductory session in the service. | 18/20 = 90% | Meets the action criterion. |
| E14 — Offer that session to every new service user. | 13/20 = 65% | Eligibility remains unresolved. |
| D14 — Record the offer, date, and outcome for that session. | 17/20 = 85% | Meets the documentation criterion. |
The complete package has not met the example protocol’s requirements. Report the accepted action and documentation items alongside the unresolved eligibility item. Review comments about eligibility and use the planned revision or further-rating process to assess any narrower proposal.
A revised E14 needs its own wording version and result. Keep the original universal-eligibility finding in the record. Explain whether linked action or documentation items also need reassessment because their intended scope has changed.
Plan whose judgment is needed for each part
Recruit the expertise and lived experience needed to assess the action, recipient group, delivery setting, and documentation burden. Define panel eligibility and describe stakeholder representation. Expertise in performing an activity and knowledge of access barriers may come from different contributors.
Where the protocol requires agreement within particular stakeholder groups, define that condition in advance and report the group results alongside the pooled finding. A group’s size affects its contribution to a pooled percentage; record the response counts and relevant attrition. See stakeholder balance in Delphi results.
Provide an appropriate option for participants unable to assess a particular proposition and explain how it will be analyzed. Separate those responses from disagreement and missing answers. If a whole component lacks enough informed ratings, resolve that evidence gap under the planned participation and continuation rules.
Ask comments to identify the contested condition: which group, setting, trigger, exception, or information requirement needs revision? Specific explanations give the research team a more useful basis for the next wording version.
Define what a recorded event actually means
Agree the event before specifying its data fields. In the fictional service example, an offer can be made without a session being completed. Define statuses such as offered, accepted, declined, completed, and unknown, together with the events that justify each status.
Specify the minimum information needed: item and version, relevant person or case identifier under the approved privacy design, event date, status, responsible role, and permitted exception reason. Make missing information distinguishable from an event that did not occur.
A blank record should retain its meaning as missing or unknown under the data dictionary. A completion measure needs evidence that the defined completion event occurred. Pilot the form with realistic cases to check whether staff interpret the fields and exceptions consistently.
If the documentation later supports an audit, define the eligible denominator, required event, timing, exclusions, and data source. The audit standards guide explains the next step from agreed content to a measurable indicator.
Publish the linked result and evaluate its use
For each operational package, report the component identifiers, wording versions, rating rules, supporting and valid counts, classifications, and unresolved dependencies. Attribute any later eligibility or documentation decisions to the people and process that made them.
Surveylet can collect separate ratings and item-linked comments and provide exports for analysis. Plan the identifiers, dependency crosswalk, and final package-level interpretation with the study team. These reporting decisions should be specified for the project.
After consensus, evaluate whether the package is understandable, workable, and accessible in its intended setting. Choose measures for reach, delivery, burden, data completeness, and relevant outcomes. Link this work to a reviewable implementation plan and report what the evaluation actually establishes.
Source and scope
Lindholm T, Sulkava-Kuusisto SS, Airaksinen M, et al. Aligning regional medication optimization practices and documentation with the national patient information documentation guideline in Finland: a Delphi study. BMC Health Services Research. Published October 30, 2026; peer-reviewed, accepted early version checked October 31, 2026.
The source provides the introductory research example. The three-component model, 20-person calculation, and community-service recording suggestions are original Calibrum illustrations, not an account of the paper’s questionnaire structure. The paper is cited for methodology and does not identify Surveylet use.
Define the complete decision your study needs
Plan linked questions, eligible groups, documentation requirements, and the outputs needed to explain the final result.