A form editor can show you how questions look. Choosing intake software requires a more specific answer: can the proposed setup support the exact form, version, language and response route your clinic needs?
For a Medical Director or assessment owner evaluating software with an Operations Director, the useful output is a record of requirements and evidence. Keep each demonstrated step separate from steps that were described or remain unverified. An editable form, a submitted response and a response reaching the right reviewer are different observations.
Key takeaways
- Define the exact form or measure before asking whether software supports “custom intake.”
- Record permission guidance and scoring-source identity separately from a demonstration of the interface.
- Give each unresolved substep an owner and a next check; avoid one blanket “demonstrated” label.
Featured image: AI-generated editorial illustration; not a product screen.
Evidence scope: This worksheet is an editorial purchasing aid, not a validated assessment, clinical-readiness score or regulatory checklist. HealthMeasures provides a source-specific implementation example below; its guidance does not establish rules for every questionnaire or imply an endorsement of HolistiCare. No instrument is recommended or reproduced here.
Define what “custom” means before the demo
Put these three requirements on separate lines:
- Clinic-authored administrative form: questions about appointment preparation or administrative preferences, with the form owner identified. Clinic authorship does not establish clinical validation.
- Unchanged standardized measure: an identified measure in a particular version and language, using a specified administration route.
- Proposed adaptation or translation: a request to change an existing measure or use a different language. Record the proposed change and the applicable guidance that still needs checking.
These distinctions give the presenter something concrete to address. A general answer about editing fields cannot establish availability of a named measure or permission to adapt it. Your assessment owner remains responsible for decisions about assessment use; the software evaluation asks whether a specified route can be supported and evidenced.
Write a requirement the presenter can test
Replace “we need custom questionnaires” with an exact requirement: identify the form or measure, version, language, intended respondent and administration mode. Then name the current source system, proposed collection route and destination where staff should review the response. Mark unknown values explicitly.
HealthMeasures separates measure selection, administration platform, translations and scoring in its Steps to License. Its How to Select guidance also explains that administration platforms may offer only a subset of its measures. For a HealthMeasures requirement, check the exact measure and route rather than assuming a general platform description covers it.
Use the same specificity for your own administrative forms. Ask which configuration the presenter is showing and which existing systems would remain involved. Include any proposed import, response display, review or export as its own testable substep. For a broader evaluation beyond intake, use the clinical operating-system demo checklist.
Check permission and scoring evidence separately
An interface demonstration answers an interface question. It does not establish permission to reproduce, translate or change a measure. Record the applicable guidance or permission evidence, its exact locator and the person responsible for resolving the requirement.
For example, the current HealthMeasures Services page describes a permission-letter and screenshot-review route for its HEAP static digital forms, and a licensing process for new translations. Its licensing guidance makes the implementation route and situation relevant. These are HealthMeasures examples, not a universal rule or a determination that your proposed use is permitted.
HealthMeasures’ Publication Checklist records measure identity and modifications for publications and presentations. The linked checklist PDF includes version, language, respondent, administration mode, collection tool and scoring method. We adapt these identifiers to a purchasing record below; the reporting checklist is not a mandate for clinic database fields or permission to edit a measure.
If scoring is part of your requirement, record the claimed scoring source or method identity and where its support can be inspected. This worksheet supplies no formula or score interpretation. For an administrative form with no score, write “Not applicable” and the reason. Keep any proposed measure change unresolved until the responsible assessment owner has checked the current applicable guidance.
Record evidence by substep
Use two records: a requirement register describing what you need, and an evidence matrix describing what you observed. One requirement may have several substeps with different evidence statuses.
Copy these fields into your working document:
Requirement register: ID; form or measure identity and type; version and language; respondent and mode; current source system and collection route; permission or implementation guidance locator; scoring-source identity or reasoned Not applicable; form or assessment owner.
Evidence matrix: requirement and substep; requested behavior; observation and evidence locator; status; configuration, manual or third-party dependencies; unresolved question; accountable owner and next check.
Use Shown only for the behavior actually demonstrated in the configuration observed. Use Described for an explanation without a demonstration, and Not verified where evidence is absent. Attach a screen reference, supplied document or another identifiable locator to the observation where available. A demonstration of one substep does not establish the remaining route.
The following filled sample illustrates field coverage and mixed statuses. It uses an invented administrative form and assumed observations solely to explain the worksheet. It is not a clinic story, customer experience, product demonstration or evidence of a HolistiCare feature. Every example evidence locator below refers only to this illustration.
| Register field | Illustrative value |
|---|---|
| Requirement ID; identity and type | R1: clinic-authored appointment-preparation form; no standardized measure. |
| Version and language | Form v0.1; English. |
| Respondent and mode | Member self-entry; web form. |
| Source system and collection route | Existing scheduling form; proposed replacement collection route to evaluate. |
| Permission or implementation guidance | Form owner to confirm authorship and rights; guidance locator not yet supplied. No instrument content copied. |
| Scoring source | Not applicable: administrative form without a clinical score. |
| Form owner | Operations lead. |
| Substep and request | Observation, status and locator | Dependency and unresolved question | Owner and next check |
|---|---|---|---|
| R1a: edit administrative fields. | Example shown: assumed editable mock. Locator: illustration R1a only; no product evidence. | Actual deployment configuration remains unverified. | Operations lead: request a current-product configuration demonstration. |
| R1b: identify form version with a submitted response. | Not verified: no response/version screen assumed shown. Locator: illustration R1b only. | Historic response/version handling is unconfirmed. | Implementation contact: submit synthetic administrative data and inspect version identity. |
| R1c: move response to the agreed staff review destination. | Described only: assumed verbal explanation. Locator: illustration R1c only. | Manual import or a connection may be needed; route and review ownership are unresolved. | Operations and technical leads: verify the route and assign the review owner. |
In the example, R1a remains a limited observation while R1b and R1c have open checks. Each requested fact has a field: identity and route in the register; behavior, observation, locator, status, dependency, unresolved question and follow-up in the matrix. Preserve that coverage when adapting the worksheet.
Leave with owners and next checks
Before closing the discussion, read each unresolved row back to the presenter. Confirm who will supply the missing evidence, what they will show and which configuration or third party it depends on. Distinguish a proposed manual workaround from a demonstrated connection, and a named review destination from an assigned review owner.
Keep the register alongside the evidence matrix so later answers refer to the same form version, language and route. If the requirement changes, identify the affected rows and ask for the relevant evidence again. The worksheet supports your clinic’s buying decision; it supplies no vendor ranking or clinical clearance.
Bring the requirements to a workflow discussion
The useful next step is a precise conversation about your intake requirements and existing systems. Bring the completed register, mixed evidence statuses and unresolved questions when you discuss your functional medicine workflow requirements with HolistiCare. Treat implementation fit as something to verify against those named requirements.
Clinical responsibility: HolistiCare provides clinical decision-support infrastructure; it is not a licensed medical provider or electronic health record. All diagnostics, care protocols, and clinical decisions remain exclusively the responsibility of qualified healthcare professionals. Insights generated by HolistiCare’s AI engine are for clinical and informational use only and do not constitute medical advice, diagnosis, or treatment.
References
Primary sources checked for this article on 5 October 2026. The HealthMeasures web pages below showed an update date of 14 September 2026. The PDF’s URL path is not used as a publication-date claim.
- HealthMeasures: Steps to License.
- HealthMeasures: Publication Checklist and its linked PDF.
- HealthMeasures: Services.
- HealthMeasures: How to Select.
