# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-24T13:07:06Z", "synthesisSha256": "91be367774d44beb291e9af7fbd5ca73707c173bd130791dd8643b80563fa2e3", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-REC-007", "registryId": "vr.wm-rec-007", "name": "Form / Submission", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.REC.FRM" ], "tags": [ "form", "submission", "inf.rec.frm" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-rec-007-form-submission/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-rec-007", "model": { "registry_id": "vr.wm-rec-007", "model_id": "WM-REC-007", "name": "Form / Submission", "entry_kind": "aggregate", "purpose": "Model the paired instrument definition and the completed, validated, transmitted response package so an agent can define a form, capture and constrain answers, submit them, and operate the resulting acceptance/rejection lifecycle with defensible provenance.", "scope_statement": "Covers (a) the form/instrument definition: identity, versioning, publication state, item tree, answer value domains, conditional logic and mandated respondent notices; and (b) the submission instance: answer payload, attachments, validation runs, status lifecycle, adjudication, attestation, audit trail, disposition and downstream extraction. Every authoritative source pairs the two (FHIR Questionnaire<->QuestionnaireResponse via linkId; XForms model/bind<->instance/submission; CDISC FormDef<->FormData; HTML form element<->entry list; ECF filing profile<->FilingMessage), and the binding contract only exists across the pair, so splitting them would orphan the contract. Format-neutral: JSON, XML, multipart, Markdown, Git, MCP and MongoDB are projections.", "in_scope": [ "Instrument definition: canonical identity, version lineage, publication state, effectivity, issuing authority", "Item tree: stable link identifiers, item types, ordering, nesting, repeats, required flags", "Answer value domains: datatypes, governed code lists, ranges, patterns, units, answer-constraint modes", "Conditional enablement, calculated/derived items and relevance-driven pruning", "Mandated respondent notices: legal authority, obligation, purpose, routine uses, control number and expiry, burden statement", "Submission instance identity and immutable binding to an exact instrument version", "Answer payload composition, repeats, ordering and missingness semantics", "Attachments and supporting evidence carried in or referenced by the package", "Constraint validation, validity states, validation tiers and authoritative revalidation on receipt", "Submission status model, permitted transitions and enforced step sequencing", "Review/adjudication outcomes, reason codes, amendment, withdrawal and resubmission", "Respondent/author/submitter roles, delegation and attestation with signature manifestation", "Time-stamped audit trail, reason for change, and the separation of event time from ingestion time", "Access control, field-level sensitivity, redaction and public release", "Retention, disposition, legal hold and erasure reconciliation", "Serialization profiles, canonical form for digesting, and downstream extraction mapping", "Acknowledgement/receipt, channel semantics and duplicate detection", "Accessible error communication, error prevention and respondent-burden quality metrics" ], "out_of_scope": [ "The generic records programme (registration, classification scheme, disposal authority as an instrument of governance) - belongs to WM-REC-001 Record", "Party/Agent identity as an entity (natural person, organisation, credential) - referenced only", "Binary document/file object modelling, format migration and rendition management - referenced only", "Cryptographic signature construction and trust-service levels (certificate chains, seal validation) - aligned, not restated", "Case, matter or business-process orchestration beyond the submission's own status", "Payment, fee assessment and financial transaction handling", "Consent as a standalone legal instrument with its own lifecycle", "Governed vocabulary/value-set registry management", "Survey methodology and statistical estimation (sampling frames, weighting, imputation)", "Message transport infrastructure, queuing and notification delivery guarantees", "User interface rendering, layout and theming" ], "boundary_notes": [ { "neighbor": "WM-REC-001 Record (parent)", "distinction": "Record governs registration, classification and disposal of any record. Form/Submission governs the pre-record surface: the instrument that elicits data, the validation and adjudication that decide whether a package becomes a record, and the answer<->question binding that Record does not carry. An accepted submission is declared into the Record model; a rejected or abandoned draft usually never becomes one.", "source_refs": [ "SRC-012", "SRC-008" ] }, { "neighbor": "Observation / semantic clinical or business record", "distinction": "QuestionnaireResponse deliberately preserves the specific phrasing and organisation of the questions; Observation preserves only the semantic meaning. Form/Submission is the wording-faithful artifact; extracted semantic records are separate downstream entities linked by item.definition.", "source_refs": [ "SRC-002", "SRC-003" ] }, { "neighbor": "Electronic Signature / Seal", "distinction": "This model records the signature manifestation and its binding to the payload (printed name, date and time, meaning of the signature, non-transferability). It does not model certificate chains, trust lists or validation algorithms.", "source_refs": [ "SRC-008", "SRC-006" ] }, { "neighbor": "Document / Attachment object", "distinction": "The model carries part-level metadata (field name, filename, media type, charset, role as lead vs connected document, digest, or a reference URI) but not the document's own lifecycle, renditions or format policy.", "source_refs": [ "SRC-005", "SRC-006" ] }, { "neighbor": "Case / Workflow", "distinction": "The submission has its own status and transitions. Downstream docketing, case assignment and business processing are separate; ECF separates filing review status from docketing status precisely because the two can disagree.", "source_refs": [ "SRC-006" ] }, { "neighbor": "Value set / code list registry", "distinction": "Items bind to governed answer value sets by reference. Curation, versioning and publication of those code lists is out of scope.", "source_refs": [ "SRC-003", "SRC-013" ] }, { "neighbor": "Instrument definition vs submission instance (internal boundary, review-required)", "distinction": "Some registries split these into two entries. This model keeps them together because the linkId/definition binding contract, version pinning and validation semantics span both and would be orphaned by a split. If the registry later splits them, the split line is: everything under bundle 'instrument-definition' moves out and bundles 2-7 stay, with the version-binding finding duplicated as a REFERENCE.", "source_refs": [ "SRC-003", "SRC-002", "SRC-013" ] } ] }, "sources": [ { "id": "SRC-001", "title": "HTML Standard - Form control infrastructure (form data set, constraint validation, form submission)", "organization": "WHATWG", "url": "https://html.spec.whatwg.org/multipage/form-control-infrastructure.html", "version_or_date": "Living Standard, 21 August 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Normative source for entry-list construction, enctype selection, constraint validation, validity states, barred-from-constraint-validation and novalidate." }, { "id": "SRC-002", "title": "QuestionnaireResponse - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/questionnaireresponse.html", "version_or_date": "FHIR R5 (5.0.0), Maturity Level 5", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Normative response-instance model: identifier, questionnaire 1..1 canonical binding, status value set, subject, authored, author vs source, item.linkId and nested answers." }, { "id": "SRC-003", "title": "Questionnaire - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/questionnaire.html", "version_or_date": "FHIR R5 (5.0.0)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Normative instrument-definition model: url, version, versionAlgorithm, status, effectivePeriod, approvalDate, item.type, enableWhen/enableBehavior, answerConstraint, answerValueSet, item.definition." }, { "id": "SRC-004", "title": "XForms 1.1", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/xforms11/", "version_or_date": "W3C Recommendation, 20 October 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Model/instance separation, model item properties (type, required, readonly, relevant, calculate, constraint), submission element attributes, submission events and relevance pruning at serialization." }, { "id": "SRC-005", "title": "RFC 7578: Returning Values from Forms: multipart/form-data", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7578.html", "version_or_date": "Standards Track, July 2015 (obsoletes RFC 2388)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Part-level name and filename parameters, per-part Content-Type, _charset_ convention, the rule that identically named parts MUST NOT be coalesced, ordering preservation and filename security." }, { "id": "SRC-006", "title": "Electronic Court Filing Version 5.01", "organization": "OASIS Open (LegalXML Electronic Court Filing TC)", "url": "https://docs.oasis-open.org/legalxml-courtfiling/ecf/v5.01/cs01/ecf-v5.01-cs01.html", "version_or_date": "Committee Specification 01, 29 September 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Submission-as-filing model: FilingMessage with lead and connected documents, ReviewFiling and RecordDocketing operations, separate review and docketing status code sets, synchronous MessageStatus, asynchronous review-complete callback, document signature profiles." }, { "id": "SRC-007", "title": "Web Content Accessibility Guidelines (WCAG) 2.2", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/WCAG22/", "version_or_date": "W3C Recommendation, 12 December 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Normative form-surface criteria: 1.3.5 Identify Input Purpose (AA), 3.3.1 Error Identification (A), 3.3.2 Labels or Instructions (A), 3.3.3 Error Suggestion (AA), 3.3.4 and 3.3.6 Error Prevention, 3.3.7 Redundant Entry (A), 4.1.3 Status Messages (AA)." }, { "id": "SRC-008", "title": "21 CFR Part 11 - Electronic Records; Electronic Signatures", "organization": "U.S. Food and Drug Administration / U.S. Government Publishing Office", "url": "https://www.govinfo.gov/content/pkg/CFR-2024-title21-vol1/xml/CFR-2024-title21-vol1-part11.xml", "version_or_date": "CFR revised as of 1 April 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "11.10(a) system validation; 11.10(b) accurate and complete copies; 11.10(c) retrieval throughout the retention period; 11.10(e) secure computer-generated time-stamped audit trails; 11.10(f) enforced sequencing of steps; 11.10(g) authority checks; 11.50 signature manifestation; 11.70 signature/record linking." }, { "id": "SRC-009", "title": "5 CFR Part 1320 - Controlling Paperwork Burdens on the Public", "organization": "U.S. Office of Management and Budget (OIRA) / U.S. Government Publishing Office", "url": "https://www.govinfo.gov/content/pkg/CFR-2024-title5-vol3/xml/CFR-2024-title5-vol3-part1320.xml", "version_or_date": "CFR revised as of 1 January 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Definitions of collection of information, burden and practical utility; 1320.5(b) display of a currently valid OMB control number and expiration; 1320.5(d)/1320.8(b)(3) required statements on purpose, use, burden estimate, obligation and confidentiality." }, { "id": "SRC-010", "title": "5 U.S.C. 552a - Records maintained on individuals (Privacy Act)", "organization": "U.S. Government Publishing Office (U.S. Code)", "url": "https://www.govinfo.gov/content/pkg/USCODE-2023-title5/html/USCODE-2023-title5-partI-chap5-subchapII-sec552a.htm", "version_or_date": "U.S. Code, 2023 edition", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "552a(e)(3) requires the collection form itself to state authorising authority, whether disclosure is mandatory or voluntary, principal purposes, routine uses and effects of not providing; (e)(1) relevance and necessity; (e)(5) accuracy, relevance, timeliness and completeness." }, { "id": "SRC-011", "title": "JSON Schema Validation: A Vocabulary for Structural Validation of JSON (draft 2020-12)", "organization": "JSON Schema Organization / IETF Internet-Draft (draft-bhutton-json-schema-validation-01)", "url": "https://json-schema.org/draft/2020-12/json-schema-validation", "version_or_date": "Internet-Draft, 16 June 2022 (Informational; not a ratified standard)", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Machine-checkable structural constraints (type, enum, const, numeric bounds, length, pattern, required, dependentRequired) and the normative distinction between the Format-Annotation and optional Format-Assertion vocabularies." }, { "id": "SRC-012", "title": "Universal Electronic Records Management (ERM) Requirements", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/policy/universalermrequirements", "version_or_date": "Version 3, June 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Lifecycle sections (Capture, Maintenance and Use, Disposal, Transfer, Metadata, Reporting) and the Must Have / Should Have classification used to bind retention and disposition obligations to a captured submission." }, { "id": "SRC-013", "title": "ODM v2.0 (Operational Data Model)", "organization": "CDISC", "url": "https://www.cdisc.org/standards/data-exchange/odm-xml/odm-v2-0", "version_or_date": "Version 2.0, published 23 August 2023", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Vendor-neutral separation of study metadata (FormDef/ItemGroupDef/ItemDef) from clinical data (FormData/ItemGroupData/ItemData) plus administrative, reference and audit information; multiple serializations (XML, JSON) over one abstract model." }, { "id": "SRC-014", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "Standards Track, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T00:00:00Z", "relevance": "Required date-time form with an explicit offset or Z, optional fractional seconds, and the -00:00 convention for a known UTC instant with unknown local offset." }, { "id": "SRC-015", "title": "XForms 1.1 W3C Recommendation", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/2009/REC-xforms-20091020/", "version_or_date": "W3C Recommendation 20 October 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:10:00Z", "relevance": "Normative split of form model, instance data, constraints, submission element, validation on submit, serialization methods, and events for submit, revalidate, reset, done and error." }, { "id": "SRC-016", "title": "HL7 FHIR R5 Resource Questionnaire", "organization": "Health Level Seven International", "url": "https://www.hl7.org/fhir/questionnaire.html", "version_or_date": "FHIR v5.0.0 (26 March 2023)", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:15:00Z", "relevance": "Canonical instrument identity (url, identifier, version), item tree, constraints on allowed answers, boundaries versus Observation, Composition and workflow, and the rule that results are communicated as QuestionnaireResponse." }, { "id": "SRC-017", "title": "HL7 FHIR R5 Resource QuestionnaireResponse", "organization": "Health Level Seven International", "url": "https://www.hl7.org/fhir/questionnaireresponse.html", "version_or_date": "FHIR v5.0.0 (26 March 2023)", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:20:00Z", "relevance": "Response identity, required questionnaire canonical, status lifecycle, subject, encounter, authored, author versus source, item answers, and validation of a response against its questionnaire." }, { "id": "SRC-018", "title": "5 CFR Part 1320 Controlling Paperwork Burdens on the Public", "organization": "United States Office of Management and Budget", "url": "https://www.ecfr.gov/current/title-5/chapter-III/subchapter-B/part-1320", "version_or_date": "eCFR current as of 2026-08-20; source 60 FR 44984 (29 August 1995)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:45:00Z", "relevance": "Legal definition of collection of information and form instruments, OMB control number and display, public protection, burden, practical utility, recordkeeping, confidentiality pledges, three-year approval limit, and prohibition on substantive modification without re-clearance." }, { "id": "SRC-019", "title": "PRA approval process", "organization": "U.S. General Services Administration / Office of Information and Regulatory Affairs", "url": "https://digital.gov/guides/pra/pra-approval-process", "version_or_date": "Guide maintained by OIRA; page accessed 2026-08-24", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T16:12:00Z", "relevance": "Clearance lifecycle (60- and 30-day notices, ICR package, Supporting Statement, ROCIS), control-number structure, de minimis versus non-substantive versus revision, generic and emergency clearance, and burden vocabulary." }, { "id": "SRC-020", "title": "TED eForms standards and eForms SDK", "organization": "Publications Office of the European Union", "url": "https://ted.europa.eu/en/simap/eforms", "version_or_date": "Page describing Implementing Regulation (EU) 2019/1780 and later amendments; eForms mandatory from October 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T16:50:00Z", "relevance": "Legislated form-type families, mandatory and conditionally mandatory fields, change notices that publish a new consolidated version, SDK versioning so historical notices remain interpretable, and the instrument-versus-instance split for procurement notices." }, { "id": "SRC-021", "title": "W3C WAI Tutorials — Validating Input", "organization": "World Wide Web Consortium Web Accessibility Initiative", "url": "https://www.w3.org/WAI/tutorials/forms/validation/", "version_or_date": "WAI forms tutorial combining WCAG 2.2 SC 3.3.1 and 3.3.4; accessed 2026-08-24", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T17:20:00Z", "relevance": "Required-field identification, client- versus server-side validation, accessible error identification, user review before submit, confirmation of irreversible acts, and stated windows in which a request may be amended or cancelled." }, { "id": "SRC-022", "title": "FHIR ValueSet Questionnaire Response Status", "organization": "Health Level Seven International", "url": "https://www.hl7.org/fhir/valueset-questionnaire-answers-status.html", "version_or_date": "FHIR v5.0.0, expansion 26 March 2023", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T17:22:00Z", "relevance": "Normative response lifecycle codes: in-progress, completed, amended, entered-in-error, stopped, with definitions for partial fill, definitive content, post-completion change, void and abandoned-with-no-further-change." }, { "id": "SRC-023", "title": "HL7 FHIR Structured Data Capture — Form Data Extraction", "organization": "Health Level Seven International", "url": "https://hl7.org/fhir/uv/sdc/extraction.html", "version_or_date": "SDC STU 4.0.0 based on FHIR R4", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T17:30:00Z", "relevance": "Populate of a QuestionnaireResponse from existing data and extract of submitted answers into other resources; filler remains responsible for validity after human review." } ], "structure": { "bundles": [ { "id": "instrument-definition", "name": "Instrument definition", "description": "The governed form definition: what is asked, how it is identified and versioned, what answers are permitted, what logic applies, and what notices it must carry.", "rationale": "Every authoritative pairing (FHIR Questionnaire, XForms model/bind, CDISC FormDef, HTML form element) treats the definition as a separately identified and versioned artifact that responses bind to. Without it the answer payload is uninterpretable.", "source_refs": [ "SRC-003", "SRC-004", "SRC-013", "SRC-001" ], "layers": [ { "id": "instrument-identity-and-publication", "name": "Instrument identity and publication", "description": "How a form definition is named, versioned and moved through publication states so a submission can pin an exact, immutable definition.", "source_refs": [ "SRC-003", "SRC-013", "SRC-009" ], "findings": [ { "id": "instrument-identity-versioning-and-publication-state", "name": "Instrument identity, version lineage and publication state", "description": "The instrument carries a canonical identifier plus business identifiers, an ordered version string with a declared ordering algorithm, a publication status, an experimental flag, an effective period and approval/review dates. Submissions bind to a specific version, so version identity is a correctness requirement, not metadata hygiene.", "source_refs": [ "SRC-003", "SRC-013", "SRC-009", "SRC-006" ], "questions": [ { "id": "which-instrument-identifier-is-authoritative", "text": "Which identifier is authoritative for this form definition: the issuing authority's official form number, a governed canonical URI, or a locally minted UUID?", "kind": "identity", "answer_data": [ "official form number or control number", "canonical URI", "identifier system URI", "locally assigned UUID/ULID and its minting authority" ] }, { "id": "how-are-versions-ordered-and-scoped", "text": "How is a substantive new version distinguished from an editorial correction, and which algorithm orders versions?", "kind": "lifecycle", "answer_data": [ "version string", "version ordering algorithm (semver, natural, integer, custom)", "change classification (breaking, minor, editorial)", "predecessor version reference" ] }, { "id": "when-may-the-instrument-accept-submissions", "text": "In which publication state is the instrument, and during exactly which period may it accept new submissions?", "kind": "state", "answer_data": [ "publication status code", "experimental flag", "effective period start and end", "control-number expiration date" ] }, { "id": "who-owns-and-approves-the-instrument", "text": "Which authority owns the instrument and may approve or retire a version?", "kind": "authority", "answer_data": [ "issuing/publishing authority reference", "steward role", "approval date", "last review date" ] } ], "data_elements": [ { "id": "instrument-canonical-uri", "name": "Instrument canonical URI", "description": "Globally governed identifier for the instrument independent of any storage location.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "instrument-business-identifier", "name": "Instrument business identifier", "description": "Identifier assigned by the issuing authority, such as an official form number or an OMB control number.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] }, { "id": "instrument-version", "name": "Instrument version", "description": "Version label for this definition, ordered by a declared version algorithm.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "instrument-publication-status", "name": "Instrument publication status", "description": "Coded publication state governing whether the instrument may be used.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "instrument-effective-period", "name": "Instrument effective period", "description": "Period during which the instrument version is valid for new submissions.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] } ], "artifacts": [ { "id": "instrument-version-manifest", "name": "Instrument version manifest", "description": "The immutable published definition of one instrument version, including its identity, item tree, constraints and notices, addressable by canonical URI plus version.", "media_or_form": [ "structured definition document", "published human-readable form template", "registry catalogue entry" ], "serial": true, "identity_strategy": "Canonical URI plus version string; where an issuing authority assigns a form/control number, that number is the authoritative business identifier and the URI is the resolvable alias.", "source_refs": [ "SRC-003", "SRC-009", "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "item-model-and-answer-constraints", "name": "Item model and answer constraints", "description": "The ordered item tree, the stable link identifiers that bind responses to questions, the permitted value domains, and the conditional and derived logic.", "source_refs": [ "SRC-003", "SRC-002", "SRC-004", "SRC-013", "SRC-011" ], "findings": [ { "id": "item-tree-and-linkid-contract", "name": "Item tree and link identifier contract", "description": "Items form an ordered, nestable tree of groups, display elements and answerable questions. Each item carries a link identifier that is the sole contract between definition and response; FHIR makes item.linkId mandatory on every response item and requires the response structure to stay consistent with the definition's grouping and nesting.", "source_refs": [ "SRC-003", "SRC-002", "SRC-013", "SRC-001" ], "questions": [ { "id": "is-linkid-unique-and-immutable", "text": "Is each item's link identifier unique within the instrument and immutable across the version lineage, and is reuse for a different question forbidden?", "kind": "identity", "answer_data": [ "item link identifier", "uniqueness scope", "reuse policy", "retired link identifier list" ] }, { "id": "how-are-item-kinds-distinguished", "text": "How are groups, repeating groups and display-only items distinguished from answerable questions?", "kind": "classification", "answer_data": [ "item type code", "group vs question flag", "display-only flag", "repeats flag" ] }, { "id": "must-response-mirror-definition-tree", "text": "Must the response tree mirror the definition tree exactly, including nesting and sibling order?", "kind": "composition", "answer_data": [ "structural consistency rule", "parent link identifier", "item ordinal", "tolerance for omitted disabled branches" ] }, { "id": "is-item-order-semantic", "text": "Is the presentation and transmission order of items semantically significant for interpretation or for legal completeness?", "kind": "constraint", "answer_data": [ "item prefix/numbering", "declared ordering rule", "order-preservation obligation on serialization" ] } ], "data_elements": [ { "id": "item-link-id", "name": "Item link identifier", "description": "Stable identifier for one item, used identically in the definition and in every response.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003", "SRC-002" ] }, { "id": "item-type", "name": "Item type", "description": "Coded kind of item (group, display, boolean, decimal, integer, date, dateTime, string, choice, attachment and so on).", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "item-parent-link-id", "name": "Parent item link identifier", "description": "Reference to the enclosing group item, expressing tree position.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-013" ] }, { "id": "item-repeats", "name": "Item repeats flag", "description": "Whether the item or group may occur more than once in a response.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "item-required", "name": "Item required flag", "description": "Whether an answer must be present for the response to be considered complete.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [ { "id": "item-outline", "name": "Item outline / instrument map", "description": "Flattened, ordered listing of every item with link identifier, type, parent, repeats and required flags, used to validate response structure and to drive rendering and extraction.", "media_or_form": [ "structured item table", "outline document", "generated index" ], "serial": false, "identity_strategy": "Derived artifact identified by instrument canonical URI plus version; not independently versioned.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "answer-datatypes-and-value-domains", "name": "Answer datatypes and value domains", "description": "Each answerable item declares a value type and a permitted value domain: a governed code list, an enumerated option set, numeric bounds, string length and pattern, or a unit-bearing quantity. Whether free text may accompany or replace coded options is itself a declared mode.", "source_refs": [ "SRC-003", "SRC-011", "SRC-004", "SRC-001", "SRC-013" ], "questions": [ { "id": "which-datatype-system-governs-answers", "text": "Which datatype system defines the permitted value type for each item, and is it declared in the instrument or inherited from a schema?", "kind": "definition", "answer_data": [ "answer value type code", "datatype system reference", "schema reference", "default value" ] }, { "id": "is-the-answer-restricted-to-a-code-list", "text": "Is the answer restricted to a governed value set, and may free text be supplied alongside or instead of a coded option?", "kind": "constraint", "answer_data": [ "answer value set reference", "inline answer option list", "answer constraint mode (options only, options or type, options or string)", "value set version" ] }, { "id": "what-unit-and-precision-apply", "text": "For quantity answers, which unit of measure and which precision or significant figures are required?", "kind": "measurement", "answer_data": [ "unit code and unit system", "precision or decimal places", "permitted range", "comparator handling" ] }, { "id": "declared-versus-enforced-value-rules", "text": "Which value-domain rules are declared in the instrument versus enforced only by the receiving system, and is any format keyword treated as an assertion rather than an annotation?", "kind": "validation", "answer_data": [ "declared constraint list", "receiver-only rule list", "format keyword treatment (annotation or assertion)" ] } ], "data_elements": [ { "id": "answer-value-type", "name": "Answer value type", "description": "Datatype permitted for the item's answer.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "answer-value-set-ref", "name": "Answer value set reference", "description": "Reference to the governed code list that constrains permitted coded answers.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "answer-constraint-mode", "name": "Answer constraint mode", "description": "Whether only listed options, options plus a typed value, or options plus free string are permitted.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "answer-bounds", "name": "Answer bounds and length limits", "description": "Numeric minimum/maximum, string maximum length and regular-expression pattern constraining the answer.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-001" ] }, { "id": "answer-unit", "name": "Answer unit of measure", "description": "Unit and unit system required for quantity answers.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "value-domain-binding-table", "name": "Value domain binding table", "description": "Per-item record of the value type, bound value set and version, option list, bounds and unit, used to reproduce validation independently of any runtime.", "media_or_form": [ "structured constraint table", "machine-readable schema projection" ], "serial": false, "identity_strategy": "Identified by instrument version plus item link identifier; value set bindings carry their own resolved version.", "source_refs": [ "SRC-003", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "conditional-enablement-and-derived-values", "name": "Conditional enablement and derived values", "description": "Items may be enabled by conditions over other answers with a declared combination behaviour, may be read-only or computed, and may be irrelevant. XForms prunes irrelevant nodes at serialization, so relevance directly changes what is transmitted and therefore what is validated and retained.", "source_refs": [ "SRC-003", "SRC-004", "SRC-013" ], "questions": [ { "id": "what-enables-each-item", "text": "Under what conditions is each item enabled, and how are multiple conditions combined?", "kind": "constraint", "answer_data": [ "enable-when condition set (question, operator, answer)", "enable behaviour (all or any)", "disabled display behaviour" ] }, { "id": "are-irrelevant-answers-pruned", "text": "Are values for disabled or irrelevant items pruned from the transmitted payload, retained as explicit nulls, or retained with a coded reason?", "kind": "composition", "answer_data": [ "pruning policy", "retained-null policy", "coded missingness value used for disabled items" ] }, { "id": "which-items-are-computed", "text": "Which items are computed rather than entered, and is the computation re-evaluated authoritatively by the receiver at submission time?", "kind": "process", "answer_data": [ "calculate expression", "expression language and version", "recomputation policy at receipt", "tolerance for client/receiver divergence" ] }, { "id": "how-are-dependency-cycles-handled", "text": "How are dependency cycles among conditional and calculated items detected, and is a cyclic instrument rejected at publication?", "kind": "exception", "answer_data": [ "dependency graph", "cycle detection outcome", "publication gate rule" ] } ], "data_elements": [ { "id": "enable-when-condition", "name": "Enablement condition", "description": "Condition over another item's answer that controls whether this item is enabled.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "enable-behavior", "name": "Enablement combination behaviour", "description": "Whether all or any conditions must hold for the item to be enabled.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "calculate-expression", "name": "Calculation expression", "description": "Expression producing a derived answer value for a computed item.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "relevance-pruning-policy", "name": "Relevance pruning policy", "description": "Declared rule for whether irrelevant nodes are removed before serialization.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "skip-logic-dependency-graph", "name": "Skip-logic dependency graph", "description": "Resolved graph of enablement and calculation dependencies among items, used to prove acyclicity and to reproduce which items were in scope for a given response.", "media_or_form": [ "directed graph export", "structured dependency listing" ], "serial": false, "identity_strategy": "Derived from and identified by the instrument version it was computed from.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "mandated-notices-and-respondent-burden", "name": "Mandated notices and respondent burden", "description": "Disclosures the instrument itself must carry before it may lawfully collect, and the burden and utility justification behind the collection.", "source_refs": [ "SRC-009", "SRC-010" ], "findings": [ { "id": "regulatory-notice-block-and-burden-statement", "name": "Regulatory notice block and burden statement", "description": "Where a collection is regulated, the instrument must display specified content on the form itself: the authorising authority, whether response is mandatory or voluntary, the principal purposes and routine uses, the effects of not responding, a currently valid control number with its expiration, and an estimated burden. These are properties of the instrument, and an expired control number invalidates the collection rather than merely the paperwork.", "source_refs": [ "SRC-009", "SRC-010" ], "questions": [ { "id": "what-authority-compels-this-collection", "text": "Which statutory or delegated authority permits or compels this collection, and is response mandatory, voluntary, or required to obtain a benefit?", "kind": "authority", "answer_data": [ "legal authority citation", "response obligation code", "consequences of non-response text" ] }, { "id": "what-control-number-and-expiry-are-displayed", "text": "What control number and expiration date are displayed, and how are submissions received after expiry handled?", "kind": "requirement", "answer_data": [ "control number", "control number expiration date", "post-expiry handling rule", "public protection statement text" ] }, { "id": "what-purposes-and-routine-uses-apply", "text": "What are the stated principal purposes and routine uses of the collected data, and where are they published?", "kind": "privacy", "answer_data": [ "purpose statement", "routine use list", "publication reference", "confidentiality assurance text" ] }, { "id": "what-burden-and-practical-utility-are-claimed", "text": "What per-respondent burden is estimated, how was it derived, and what evidence of practical utility supports the collection?", "kind": "measurement", "answer_data": [ "burden estimate per response", "estimation method", "respondent count estimate", "practical utility evidence" ] } ], "data_elements": [ { "id": "legal-authority-citation", "name": "Legal authority citation", "description": "Citation of the authority under which the information is solicited.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "response-obligation", "name": "Response obligation", "description": "Whether a response is mandatory, voluntary or required to obtain or retain a benefit.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "control-number", "name": "Collection control number", "description": "Currently valid control number that must be displayed on the collection instrument.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "control-number-expiry", "name": "Control number expiration date", "description": "Date after which the displayed control number is no longer valid.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "burden-estimate", "name": "Estimated respondent burden", "description": "Estimated time, effort or cost per response.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "notice-block", "name": "Notice and disclosure block", "description": "The exact rendered notice text carried on or with the instrument, retained as issued so that what a respondent was actually shown can be reproduced years later.", "media_or_form": [ "rendered notice text", "separate retainable notice sheet", "first-screen electronic notice" ], "serial": true, "identity_strategy": "Identified by instrument version plus notice revision; retained verbatim rather than regenerated.", "source_refs": [ "SRC-009", "SRC-010" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "submission-instance", "name": "Submission instance", "description": "The concrete response package: its identity, its immutable binding to an instrument version, its answer set and its attachments.", "rationale": "FHIR generates a distinct response per subject per occasion and requires a 1..1 canonical binding to the questionnaire; ECF treats the filing as a package of lead and connected documents. The instance is a first-class thing with its own identity, not a view over the definition.", "source_refs": [ "SRC-002", "SRC-006", "SRC-005", "SRC-013" ], "layers": [ { "id": "submission-identity-and-binding", "name": "Submission identity and instrument binding", "description": "How a submission is identified across parties and how it pins the exact definition it answers.", "source_refs": [ "SRC-002", "SRC-006" ], "findings": [ { "id": "submission-identity-and-instrument-version-binding", "name": "Submission identity and instrument version binding", "description": "A submission carries the receiving authority's identifier, the submitter's own reference and, where neither exists, a locally minted UUID/ULID. It binds to exactly one instrument version; FHIR makes that canonical reference mandatory. Drafts created against a version that is later superseded are the sharp edge: the binding must either be pinned or explicitly migrated with a recorded decision.", "source_refs": [ "SRC-002", "SRC-006", "SRC-003" ], "questions": [ { "id": "which-submission-identifier-is-authoritative", "text": "Which identifier is authoritative for this submission: the receiving authority's receipt or filing number, the submitter's own reference, or an internally minted UUID?", "kind": "identity", "answer_data": [ "receiving-authority submission identifier", "submitter reference identifier", "internal UUID/ULID", "identifier system and issuing party" ] }, { "id": "which-instrument-version-is-bound", "text": "To exactly which instrument version is this submission bound, and is that binding immutable once the submission leaves draft?", "kind": "relationship", "answer_data": [ "bound instrument canonical URI", "bound instrument version", "binding immutability rule", "binding recorded timestamp" ] }, { "id": "what-happens-when-the-instrument-is-superseded", "text": "What happens to an in-progress draft when the bound instrument version is superseded or retired?", "kind": "exception", "answer_data": [ "pin or migrate policy", "migration decision record", "answers invalidated by migration", "respondent re-consent requirement" ] }, { "id": "what-is-the-submission-about", "text": "What is this submission about, and which prior request, order or submission is it based on or part of?", "kind": "relationship", "answer_data": [ "subject reference", "based-on reference", "part-of reference", "encounter or occasion reference" ] } ], "data_elements": [ { "id": "submission-id", "name": "Submission identifier", "description": "Authoritative identifier for the submission instance.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "submitter-reference-id", "name": "Submitter's own reference", "description": "Identifier assigned by the submitting party for its own tracking.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "bound-instrument-ref", "name": "Bound instrument version reference", "description": "Canonical reference to the exact instrument version this submission answers.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "submission-subject-ref", "name": "Submission subject", "description": "The person, organisation or thing the answers are about, where distinct from the respondent.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "submission-based-on-ref", "name": "Based-on / part-of reference", "description": "Reference to the request, plan or larger package this submission fulfils or belongs to.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] } ], "artifacts": [ { "id": "submission-package-header", "name": "Submission package header", "description": "The identifying envelope of the package: identifiers, bound instrument version, subject, sender and receiver, and package composition, separable from the answer payload for routing and audit.", "media_or_form": [ "package manifest", "message header", "registry index entry" ], "serial": true, "identity_strategy": "Receiving-authority identifier first; submitter reference retained as a cross-reference; UUID/ULID only when neither is available.", "source_refs": [ "SRC-006", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "payload-answers-and-attachments", "name": "Answer payload and attachments", "description": "The answer set with its repetition, ordering and missingness semantics, plus attached supporting evidence.", "source_refs": [ "SRC-002", "SRC-005", "SRC-006", "SRC-001" ], "findings": [ { "id": "answer-set-composition-and-missingness", "name": "Answer set composition and missingness semantics", "description": "An item may carry several answers and groups may repeat, so the payload is a tree, not a map. RFC 7578 forbids coalescing identically named parts and asks that ordering be preserved. The hardest distinction is missingness: not asked, disabled by logic, asked and left blank, not applicable, and declined are five different facts that a single absent key cannot express.", "source_refs": [ "SRC-002", "SRC-005", "SRC-001", "SRC-004" ], "questions": [ { "id": "how-are-repeats-represented", "text": "How are multiple answers to one item and repeated groups represented so that duplicates are not collapsed and occurrence identity is preserved?", "kind": "composition", "answer_data": [ "answer occurrence index", "repeat group instance identifier", "no-coalescing rule", "nesting representation" ] }, { "id": "how-is-missingness-distinguished", "text": "How is not asked distinguished from disabled by logic, left blank, not applicable and declined to answer?", "kind": "definition", "answer_data": [ "coded missingness reason", "absent vs null vs empty-string convention", "disabled-item representation", "refusal code" ] }, { "id": "is-transmitted-order-significant", "text": "Is the transmitted order of answer entries semantically significant, and must it be preserved through every projection?", "kind": "constraint", "answer_data": [ "ordering obligation", "ordinal per entry", "stable sort key" ] }, { "id": "is-a-partial-payload-valid", "text": "Is a partial payload a valid instance, and which items may be absent while the package remains well-formed?", "kind": "state", "answer_data": [ "partial-instance rule", "required-item satisfaction status", "completeness percentage", "status value expressing partiality" ] } ], "data_elements": [ { "id": "answer-entry", "name": "Answer entry", "description": "One recorded answer bound to an item link identifier, with its value and occurrence position.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "answer-value", "name": "Answer value", "description": "The typed value supplied for an item, whose datatype is governed by the bound instrument item.", "value_kind": "other", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "answer-occurrence-index", "name": "Answer occurrence index", "description": "Ordinal distinguishing repeated answers or repeated group instances.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "missingness-reason", "name": "Missingness reason", "description": "Coded explanation for the absence of an answer.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [ { "id": "answer-payload", "name": "Answer payload", "description": "The complete answer tree as submitted, retained in canonical form so it can be revalidated, digested and signed independently of the transport encoding used.", "media_or_form": [ "structured answer tree", "entry list", "tabular item-data export" ], "serial": true, "identity_strategy": "Identified by submission identifier plus payload revision number; each revision is retained rather than overwritten.", "source_refs": [ "SRC-002", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "attachment-parts-and-supporting-evidence", "name": "Attachment parts and supporting evidence", "description": "Files accompanying the answers carry field name, filename, media type, character encoding and size. ECF distinguishes lead from connected documents and prefers a binary URI reference over inline base64; RFC 7578 requires receivers to validate filenames against traversal attacks.", "source_refs": [ "SRC-005", "SRC-006", "SRC-001", "SRC-008" ], "questions": [ { "id": "which-document-is-the-lead", "text": "Which attached document is the lead document and which are connected or supporting, and does that role affect adjudication?", "kind": "classification", "answer_data": [ "attachment role code", "lead document reference", "connected document references", "role effect on review" ] }, { "id": "what-file-constraints-apply", "text": "What filename, media type, character encoding and size limits apply, and how are unsafe or ambiguous filenames neutralised on receipt?", "kind": "security", "answer_data": [ "permitted media types", "maximum size", "charset declaration", "filename sanitisation rule", "malware scan outcome" ] }, { "id": "inline-or-referenced-attachment", "text": "Is the attachment carried inline in the package or referenced by URI, and which party guarantees its continued availability for the retention period?", "kind": "interoperability", "answer_data": [ "inline vs by-reference mode", "attachment URI", "availability guarantor", "dereference deadline" ] }, { "id": "how-is-attachment-integrity-proven", "text": "What integrity value is recorded so the attachment can later be proven unaltered and reproduced as an accurate and complete copy?", "kind": "evidence", "answer_data": [ "digest algorithm", "digest value", "copy reproduction format", "integrity check timestamp" ] } ], "data_elements": [ { "id": "attachment-filename", "name": "Attachment filename", "description": "Original filename supplied by the sender, retained as sent and separately as sanitised.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "attachment-media-type", "name": "Attachment media type", "description": "Declared media type of the attached part, with charset where textual.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "attachment-size-bytes", "name": "Attachment size", "description": "Octet length of the attached content.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "attachment-role", "name": "Attachment role", "description": "Whether the attachment is a lead document, a connected/supporting document or evidence for a specific item.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "attachment-digest", "name": "Attachment digest", "description": "Cryptographic digest and algorithm proving the attached content is unaltered.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-006" ] } ], "artifacts": [ { "id": "attached-document-part", "name": "Attached document part", "description": "One supporting file transmitted with or referenced by the submission, retained with its part metadata and digest.", "media_or_form": [ "binary file part", "referenced binary object", "rendered human-readable copy" ], "serial": true, "identity_strategy": "Submission identifier plus part name plus sequence; the digest is the integrity identity and the filename is never treated as an identifier.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "validation-and-lifecycle", "name": "Validation and lifecycle", "description": "How a submission is checked, what states it may occupy, which transitions are permitted, and how acceptance, rejection and correction are decided and recorded.", "rationale": "The registry purpose names a validation lifecycle. HTML/XForms supply the declarative constraint layer, ECF supplies review and docketing statuses that can disagree, FHIR supplies the response status value set, and 21 CFR 11.10(f) supplies the normative requirement to enforce step sequencing.", "source_refs": [ "SRC-001", "SRC-004", "SRC-002", "SRC-006", "SRC-008", "SRC-011" ], "layers": [ { "id": "constraint-validation", "name": "Constraint validation", "description": "The declared constraint set, the validity states failures produce, and which party's verdict is authoritative.", "source_refs": [ "SRC-001", "SRC-004", "SRC-011", "SRC-008" ], "findings": [ { "id": "constraint-model-and-validity-states", "name": "Constraint model and validity states", "description": "Constraints are declared on items and produce specific validity states on failure (value missing, type mismatch, pattern mismatch, too long, too short, range underflow/overflow, step mismatch, bad input, custom error). Crucially, elements can be barred from constraint validation - disabled, read-only or irrelevant items never block submission - and a novalidate/validate=false path exists by design for saving incomplete work.", "source_refs": [ "SRC-001", "SRC-004", "SRC-011", "SRC-003" ], "questions": [ { "id": "which-validity-state-does-each-failure-produce", "text": "Which constraint is declared on each item and which validity state does its failure produce?", "kind": "validation", "answer_data": [ "constraint identifier", "constraint expression or attribute", "validity state code", "severity (error, warning, information)" ] }, { "id": "which-items-are-barred-from-validation", "text": "Which items are barred from constraint validation because they are disabled, read-only or irrelevant, and therefore never block submission?", "kind": "exception", "answer_data": [ "barred item link identifiers", "barring reason code", "effect on required-item satisfaction" ] }, { "id": "is-format-an-assertion", "text": "Is a declared format treated as a non-blocking annotation or as an enforced assertion, and who made that choice?", "kind": "validation", "answer_data": [ "format keyword treatment", "vocabulary declaration", "enforcement owner" ] }, { "id": "may-validation-be-bypassed", "text": "May validation be deliberately bypassed to save an incomplete draft, and under whose authority is the bypass recorded?", "kind": "authority", "answer_data": [ "bypass permitted flag", "authorising role", "bypass reason", "resulting status restriction" ] } ], "data_elements": [ { "id": "constraint-id", "name": "Constraint identifier", "description": "Stable identifier for one declared constraint or edit check.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-013" ] }, { "id": "constraint-expression", "name": "Constraint expression", "description": "The declarative rule evaluated against the answer set.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "validity-state-code", "name": "Validity state code", "description": "Coded reason an answer fails its constraint.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "validation-bypass-flag", "name": "Validation bypass flag", "description": "Whether validation was intentionally suppressed for this evaluation.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [ { "id": "constraint-specification", "name": "Constraint / edit-check specification", "description": "The full set of declared checks for an instrument version, retained so a historical validation verdict can be reproduced exactly.", "media_or_form": [ "structured rule set", "schema projection", "edit-check specification document" ], "serial": true, "identity_strategy": "Instrument canonical URI plus version plus rule-set revision.", "source_refs": [ "SRC-004", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "validation-tiers-and-authoritative-revalidation", "name": "Validation tiers and authoritative revalidation", "description": "Validation occurs at several tiers: declarative in-form checks, receiver structural revalidation, and business or eligibility rules applied later. Only one tier can be authoritative. 21 CFR 11.10(a) requires validated systems able to discern invalid or altered records, and ECF has the court validate on receipt before docketing - so the receiver, not the client, decides.", "source_refs": [ "SRC-008", "SRC-006", "SRC-001", "SRC-004", "SRC-011" ], "questions": [ { "id": "whose-verdict-is-authoritative", "text": "When the sending and receiving systems disagree on validity, whose verdict is authoritative and how is the disagreement recorded?", "kind": "authority", "answer_data": [ "authoritative tier", "disagreement record", "escalation path" ] }, { "id": "is-the-full-constraint-set-re-evaluated", "text": "Is the full constraint set re-evaluated on receipt, and against which instrument version - the bound one or the current one?", "kind": "validation", "answer_data": [ "revalidation scope", "instrument version used for revalidation", "divergence handling" ] }, { "id": "how-is-a-verdict-made-replayable", "text": "How is a validation outcome recorded so it can be replayed and audited after rule sets have changed?", "kind": "evidence", "answer_data": [ "validation run identifier", "rule set version", "input payload digest", "issue list with item references", "run timestamp" ] }, { "id": "what-happens-on-business-rule-failure", "text": "What is the disposition of a payload that passes structural validation but fails a business or eligibility rule?", "kind": "decision", "answer_data": [ "structural outcome", "business outcome", "resulting status", "remediation instruction" ] } ], "data_elements": [ { "id": "validation-run-id", "name": "Validation run identifier", "description": "Identifier for one evaluation of a rule set against a payload revision.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "validation-tier", "name": "Validation tier", "description": "Which tier performed the evaluation: in-form, receiver structural, or business rule.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-001" ] }, { "id": "validation-outcome", "name": "Validation outcome", "description": "Coded overall result of the run.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "validation-issue", "name": "Validation issue", "description": "One failure with its item reference, validity state, severity and message.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "validation-timestamp", "name": "Validation timestamp", "description": "RFC 3339 instant at which the validation run completed.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-008" ] } ], "artifacts": [ { "id": "validation-report", "name": "Validation report", "description": "Immutable record of one validation run: rule set version, payload digest, outcome, issue list and timestamp, retained as the evidence behind an acceptance or rejection.", "media_or_form": [ "structured issue report", "human-readable validation summary", "machine-readable outcome message" ], "serial": true, "identity_strategy": "Submission identifier plus payload revision plus monotonic run sequence.", "source_refs": [ "SRC-006", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "state-and-transitions", "name": "Status model and transitions", "description": "The states a submission may occupy and the rules and authority checks governing movement between them.", "source_refs": [ "SRC-002", "SRC-006", "SRC-008" ], "findings": [ { "id": "submission-status-model", "name": "Submission status model", "description": "FHIR defines a required status value set (in-progress, completed, amended, entered-in-error, stopped) and marks status as a modifier element - status changes how the content may be interpreted, not merely how it is displayed. ECF tracks review status and docketing status separately, plus per-document statuses, precisely because a filing can be accepted for review yet fail to record.", "source_refs": [ "SRC-002", "SRC-006", "SRC-004" ], "questions": [ { "id": "what-is-the-current-status", "text": "What is the current status of the submission, and is status a modifier that changes how the payload may lawfully be used?", "kind": "state", "answer_data": [ "submission status code", "modifier semantics flag", "status changed timestamp", "status setting actor" ] }, { "id": "are-review-and-recording-status-separate", "text": "Are review status and recording or docketing status tracked separately, and what does it mean when they disagree?", "kind": "state", "answer_data": [ "review status code", "recording status code", "divergence handling rule" ] }, { "id": "is-status-tracked-per-part", "text": "Is status tracked per item or per document as well as per submission, and does a part-level rejection reject the whole?", "kind": "composition", "answer_data": [ "per-document status list", "per-item status list", "aggregation rule" ] }, { "id": "which-statuses-forbid-downstream-use", "text": "Which status values mean the content must not be used for clinical, legal, statistical or operational purposes?", "kind": "exception", "answer_data": [ "use-forbidding status list", "downstream suppression rule", "notification to prior consumers" ] } ], "data_elements": [ { "id": "submission-status", "name": "Submission status", "description": "Coded current state of the submission as a whole.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "review-status", "name": "Review status", "description": "Coded state of the receiving authority's review of the submission.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "recording-status", "name": "Recording / docketing status", "description": "Coded state of the submission's entry into the authoritative downstream record system.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "part-status", "name": "Part-level status", "description": "Status of an individual document or item within the package.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "status-history", "name": "Status history", "description": "Ordered, append-only record of every status the submission has held with actor, time and reason, used to answer what the status was at any past instant.", "media_or_form": [ "append-only status log", "lifecycle timeline export" ], "serial": true, "identity_strategy": "Submission identifier plus monotonic status sequence number.", "source_refs": [ "SRC-002", "SRC-006", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "transition-rules-and-sequencing-controls", "name": "Transition rules and sequencing controls", "description": "Not every status pair is a legal transition. 21 CFR 11.10(f) requires operational system checks that enforce permitted sequencing of steps and events, and 11.10(g) requires authority checks so only authorised individuals may perform an operation - together these make the transition table an enforced control, not documentation.", "source_refs": [ "SRC-008", "SRC-006", "SRC-002", "SRC-004" ], "questions": [ { "id": "which-transitions-are-permitted", "text": "Which status transitions are permitted, which are terminal, and what precondition guards each one?", "kind": "lifecycle", "answer_data": [ "from status", "to status", "guard precondition", "terminal flag" ] }, { "id": "what-enforces-step-order", "text": "What operational system check prevents steps from being performed out of order, for example signing before validation completes?", "kind": "process", "answer_data": [ "sequencing control description", "enforced step order", "bypass detection", "control test evidence" ] }, { "id": "who-may-trigger-each-transition", "text": "Which role is authorised to trigger each transition, and how is that authority checked at execution time?", "kind": "authority", "answer_data": [ "authorised role per transition", "authority check mechanism", "delegation permitted flag", "denied attempt log" ] }, { "id": "may-a-terminal-submission-reopen", "text": "May a submission in a terminal state be reopened, and what record must that create?", "kind": "exception", "answer_data": [ "reopen permitted flag", "authorising role", "reopen reason", "resulting audit entries" ] } ], "data_elements": [ { "id": "transition-from-status", "name": "Transition source status", "description": "Status the submission held before the transition.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "transition-to-status", "name": "Transition target status", "description": "Status the submission holds after the transition.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "transition-precondition", "name": "Transition precondition", "description": "Condition that must hold for the transition to be permitted.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "transition-authorised-role", "name": "Authorised role for transition", "description": "Role permitted to execute the transition.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "transition-event-time", "name": "Transition event time", "description": "RFC 3339 instant at which the transition occurred.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-008" ] } ], "artifacts": [ { "id": "state-transition-table", "name": "State transition table", "description": "Declared matrix of permitted transitions with guards and authorised roles, published per instrument or per collection programme so the enforced control can be inspected independently of code.", "media_or_form": [ "structured transition matrix", "state machine definition" ], "serial": true, "identity_strategy": "Owned by the collection programme; versioned independently of instrument versions and referenced by identifier plus version.", "source_refs": [ "SRC-008", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "adjudication-and-remedy", "name": "Adjudication and remedy", "description": "Human or automated decision on the submission, and the routes available to correct, replace or withdraw it.", "source_refs": [ "SRC-006", "SRC-002", "SRC-013", "SRC-008" ], "findings": [ { "id": "decision-outcome-and-reason-codes", "name": "Decision outcome and reason codes", "description": "An adjudication records who decided, under what authority, the coded outcome, a human-readable explanation and any remediation instruction. ECF returns an error code with zero meaning success and notifies review completion asynchronously. Whether acceptance backdates to original receipt is a substantive legal question, not a storage detail.", "source_refs": [ "SRC-006", "SRC-002", "SRC-008" ], "questions": [ { "id": "who-decided-and-under-what-authority", "text": "Who reviewed the submission and under what delegated authority did they accept, reject or return it?", "kind": "authority", "answer_data": [ "reviewer reference", "reviewing organisation", "delegation basis", "decision role" ] }, { "id": "what-reason-accompanies-rejection", "text": "Which coded reason and human-readable explanation accompany a rejection or return, and are they drawn from a governed code list?", "kind": "decision", "answer_data": [ "decision outcome code", "reason code and code system", "narrative explanation", "remediation instruction" ] }, { "id": "can-a-submission-be-partly-accepted", "text": "Can a submission be partly accepted, and what is the status and disposition of the unaccepted parts?", "kind": "exception", "answer_data": [ "partial acceptance permitted flag", "accepted part list", "rejected part list", "effect on the whole package" ] }, { "id": "which-time-governs-the-decision", "text": "Does acceptance take effect from the original receipt time or from the decision time, and which governs any deadline?", "kind": "temporal", "answer_data": [ "receipt timestamp", "decision timestamp", "effective filing timestamp", "backdating rule" ] } ], "data_elements": [ { "id": "decision-outcome", "name": "Decision outcome", "description": "Coded adjudication result for the submission or a part of it.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "decision-reason-code", "name": "Decision reason code", "description": "Governed code explaining the outcome, especially for rejection or return.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "reviewer-ref", "name": "Reviewer reference", "description": "The individual or automated agent that made the decision.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-008" ] }, { "id": "decision-time", "name": "Decision time", "description": "RFC 3339 instant at which the decision was made.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "effective-filing-time", "name": "Effective filing time", "description": "The time the submission is deemed to have been made for deadline purposes.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "adjudication-notice", "name": "Adjudication notice", "description": "The decision communicated to the submitter, carrying outcome, reason codes, explanation, remediation instruction and effective time; retained as the authoritative statement of what the submitter was told.", "media_or_form": [ "decision notice message", "human-readable notice", "callback notification payload" ], "serial": true, "identity_strategy": "Submission identifier plus monotonic decision sequence; supersession is expressed by reference, never by overwrite.", "source_refs": [ "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "amendment-withdrawal-and-resubmission", "name": "Amendment, withdrawal and resubmission", "description": "Corrections after submission are not edits. FHIR distinguishes amended from entered-in-error; CDISC requires an audit record with a reason for change on updates; 21 CFR 11 requires that changes not obscure previously recorded information. The choice between amending in place with version history and creating a superseding submission is a governance decision that must be declared.", "source_refs": [ "SRC-002", "SRC-013", "SRC-008", "SRC-006" ], "questions": [ { "id": "amend-in-place-or-supersede", "text": "Is a correction recorded as a new version of the same submission or as a new submission that supersedes the prior one, and who decided that convention?", "kind": "lifecycle", "answer_data": [ "correction convention", "amendment-of reference", "supersedes / superseded-by references", "convention owner" ] }, { "id": "how-is-a-resubmission-linked", "text": "What explicitly links a resubmission to the rejected or withdrawn submission it replaces?", "kind": "relationship", "answer_data": [ "replaces reference", "original submission identifier", "rejection decision reference", "link recorded timestamp" ] }, { "id": "is-superseded-content-retained", "text": "Is superseded or entered-in-error content retained and retrievable, and how is it excluded from downstream use without being destroyed?", "kind": "retention", "answer_data": [ "retention of superseded versions", "suppression flag", "downstream retraction notice", "retrieval role restriction" ] }, { "id": "who-may-withdraw-and-until-when", "text": "Who may withdraw a submission and up to which point in the lifecycle?", "kind": "authority", "answer_data": [ "withdrawal authorised roles", "withdrawal cut-off state", "withdrawal reason", "withdrawal timestamp" ] } ], "data_elements": [ { "id": "amendment-of-ref", "name": "Amendment-of reference", "description": "Reference from a corrected version to the version it amends.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "supersedes-ref", "name": "Supersedes / superseded-by reference", "description": "Bidirectional link between a replacing submission and the one it replaces.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-002" ] }, { "id": "correction-type", "name": "Correction type", "description": "Whether the change is an amendment, an entered-in-error retraction, a withdrawal or a resubmission after rejection.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-013" ] }, { "id": "change-reason", "name": "Reason for change", "description": "Recorded justification for the correction, mandatory where regulated.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-008" ] } ], "artifacts": [ { "id": "amendment-record", "name": "Amendment / retraction record", "description": "Record of one correction event: type, reason, affected items, actor, time and the links to prior and successor versions.", "media_or_form": [ "structured change record", "retraction notice", "version diff export" ], "serial": true, "identity_strategy": "Submission identifier plus monotonic amendment sequence; never overwrites the amended payload revision.", "source_refs": [ "SRC-013", "SRC-008", "SRC-002" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "provenance-authority-and-attestation", "name": "Provenance, authority and attestation", "description": "Who supplied, recorded, signed and transmitted the submission, under what authority, and the time-stamped trail that proves it.", "rationale": "FHIR separates subject, author and source as distinct elements; CDISC records user, location, timestamp and reason for change; 21 CFR 11.50 and 11.70 specify what a signature must manifest and how it must bind. Conflating these roles destroys the evidentiary value of the package.", "source_refs": [ "SRC-002", "SRC-013", "SRC-008", "SRC-006", "SRC-014" ], "layers": [ { "id": "actors-authority-and-attestation", "name": "Actors, authority and attestation", "description": "Role separation among respondent, recorder, submitter and subject, the basis for acting on another's behalf, and the signature that closes the package.", "source_refs": [ "SRC-002", "SRC-006", "SRC-008", "SRC-013" ], "findings": [ { "id": "respondent-author-and-submitter-roles", "name": "Respondent, author and submitter roles", "description": "FHIR keeps source (who answered), author (who recorded) and subject (who the answers are about) as three separate elements, and ECF adds a filer/sender distinct from all three. Assisted or proxy completion, interviewer-administered forms and agent-filed packages all produce different combinations, and the difference is legally material.", "source_refs": [ "SRC-002", "SRC-006", "SRC-013", "SRC-008" ], "questions": [ { "id": "who-answered-recorded-and-transmitted", "text": "Who supplied the answers, who recorded them and who transmitted the package, and are any of these the same party?", "kind": "ownership", "answer_data": [ "source/respondent reference", "author/recorder reference", "submitter reference", "role coincidence flags" ] }, { "id": "is-the-submission-made-on-behalf-of-another", "text": "Is the submission made on behalf of another party, and what evidence establishes that representation?", "kind": "authority", "answer_data": [ "on-behalf-of reference", "representation basis (power of attorney, licence, delegation record)", "evidence reference", "representation validity period" ] }, { "id": "where-was-the-data-captured", "text": "At which site, organisational unit or jurisdiction was the data captured, and does that affect which rules apply?", "kind": "spatial", "answer_data": [ "capture location reference", "jurisdiction code", "site identifier", "rule-set selection effect" ] }, { "id": "how-was-the-submitter-identified", "text": "What identity proofing or authentication was performed on the submitter before the package was accepted?", "kind": "security", "answer_data": [ "authentication method", "identity assurance level", "credential reference", "authentication timestamp" ] } ], "data_elements": [ { "id": "respondent-source-ref", "name": "Respondent / source reference", "description": "The party who supplied the answers.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "recorder-author-ref", "name": "Author / recorder reference", "description": "The party who entered or transcribed the answers.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "submitter-ref", "name": "Submitter reference", "description": "The party that transmitted the package to the receiving authority.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "on-behalf-of-ref", "name": "On-behalf-of reference", "description": "The party the submitter represents, where different from the submitter.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "capture-location-ref", "name": "Capture location reference", "description": "Site or organisational location where the answers were captured.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "role-assignment-record", "name": "Role assignment and representation record", "description": "Record binding each party to its role on this submission, with the evidence supporting any representation or delegation.", "media_or_form": [ "structured role record", "delegation evidence reference", "authentication assertion" ], "serial": false, "identity_strategy": "Keyed by submission identifier plus role code plus party reference.", "source_refs": [ "SRC-002", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "declaration-authority-and-signature-manifestation", "name": "Declaration and signature manifestation", "description": "21 CFR 11.50 requires a signed record to carry the printed name of the signer, the date and time of signing, and the meaning of the signature (review, approval, responsibility, authorship); 11.70 requires the signature be linked so it cannot be excised, copied or transferred. The declaration text the signer accepted must be retained verbatim, not regenerated from a current template.", "source_refs": [ "SRC-008", "SRC-006", "SRC-013", "SRC-002" ], "questions": [ { "id": "what-declaration-was-accepted", "text": "What exact declaration or certification text did the signer accept, and what meaning is attached to the signature?", "kind": "evidence", "answer_data": [ "declaration text as presented", "signature meaning code", "declaration version", "acceptance timestamp" ] }, { "id": "how-is-the-signature-bound", "text": "By what method was the record signed, and how is the signature bound to this exact payload so it cannot be excised or transferred to another record?", "kind": "security", "answer_data": [ "signature method", "signed payload digest and algorithm", "binding mechanism", "signature profile reference" ] }, { "id": "what-assurance-preceded-signing", "text": "What identity assurance and authority check were performed before the signature was accepted?", "kind": "security", "answer_data": [ "identity assurance level", "signature components used", "authority check outcome", "non-repudiation basis" ] }, { "id": "is-the-manifestation-reproducible", "text": "Is the signature manifestation reproducible in human-readable form on any export or printed copy?", "kind": "interoperability", "answer_data": [ "printed name of signer", "date and time of signing", "meaning text", "export rendering rule" ] } ], "data_elements": [ { "id": "signer-printed-name", "name": "Printed name of signer", "description": "Human-readable name of the signer as it must appear on the signed record.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "signature-time", "name": "Signature execution time", "description": "RFC 3339 instant at which the signature was executed.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-014" ] }, { "id": "signature-meaning", "name": "Meaning of signature", "description": "Coded meaning such as review, approval, responsibility or authorship.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "signed-payload-digest", "name": "Signed payload digest", "description": "Digest of the canonical payload the signature covers.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-006" ] }, { "id": "declaration-text", "name": "Declaration text as presented", "description": "Verbatim certification or attestation text shown to the signer.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "signature-block", "name": "Signature block", "description": "The signature and its manifestation bound to the canonical payload digest, retained with the declaration text so the act of signing can be reconstructed and defended.", "media_or_form": [ "detached or enveloped signature", "signature manifestation rendering", "signed manifest" ], "serial": true, "identity_strategy": "Submission identifier plus payload revision plus signer plus signature sequence; the payload digest is the binding key.", "source_refs": [ "SRC-008", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "audit-trail-and-temporal-record", "name": "Audit trail and temporal record", "description": "The independent, time-stamped record of every action on the submission, and the distinct time points that govern deadlines and timeliness.", "source_refs": [ "SRC-008", "SRC-013", "SRC-014", "SRC-012" ], "findings": [ { "id": "audit-record-and-change-reason", "name": "Audit record and reason for change", "description": "21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify or delete records, without obscuring prior values. CDISC pairs each change with user, location, timestamp, reason for change and source identifier, plus a transaction type distinguishing insert from update and removal.", "source_refs": [ "SRC-008", "SRC-013", "SRC-012" ], "questions": [ { "id": "what-audit-entry-is-generated", "text": "What audit entry is generated for each create, modify and delete action on the submission, and does it capture the prior value?", "kind": "provenance", "answer_data": [ "audit action code", "actor reference", "audit timestamp", "prior value", "new value", "transaction type" ] }, { "id": "when-is-a-change-reason-mandatory", "text": "For which classes of change is a reason for change mandatory, and is a free-text reason acceptable or must it be coded?", "kind": "requirement", "answer_data": [ "change classes requiring reason", "reason code system", "free-text permitted flag", "enforcement point" ] }, { "id": "is-the-audit-trail-independent", "text": "Is the audit trail generated independently of the operator and protected from modification or deletion by the parties it records?", "kind": "security", "answer_data": [ "generation mechanism", "tamper protection method", "operator write access", "integrity verification result" ] }, { "id": "how-long-is-the-audit-trail-kept", "text": "For how long is the audit trail retained relative to the submission itself, and is it disposed of together with the record?", "kind": "retention", "answer_data": [ "audit retention period", "linkage to submission retention", "disposition coupling rule" ] } ], "data_elements": [ { "id": "audit-entry-id", "name": "Audit entry identifier", "description": "Identifier of one immutable audit entry.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "audit-action", "name": "Audit action", "description": "Coded action recorded: create, read, update, delete, sign, transmit, decide, export or dispose.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-013" ] }, { "id": "audit-actor-ref", "name": "Audit actor reference", "description": "The individual or system agent that performed the action.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-013" ] }, { "id": "audit-timestamp", "name": "Audit timestamp", "description": "System-generated RFC 3339 instant of the action, independent of operator-supplied times.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-014" ] }, { "id": "audit-reason-for-change", "name": "Reason for change", "description": "Recorded justification accompanying a modification or deletion.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "audit-transaction-type", "name": "Transaction type", "description": "Whether the entry represents an insert, update, removal or upsert of data.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "audit-trail-log", "name": "Audit trail log", "description": "Append-only, tamper-evident sequence of audit entries for the submission, retrievable and exportable as an accurate and complete copy for inspection.", "media_or_form": [ "append-only log", "exportable audit report", "system-generated trail" ], "serial": true, "identity_strategy": "Submission identifier plus monotonic audit sequence; entries are never renumbered or reordered.", "source_refs": [ "SRC-008", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "temporal-model-deadlines-and-timeliness", "name": "Temporal model, deadlines and timeliness", "description": "A submission has many distinct times: started, last saved, authored, signed, transmitted, received, decided and disposed. RFC 3339 requires an explicit offset or Z on each, and reserves -00:00 for a known UTC instant with unknown local offset. Deadlines are evaluated in the receiving authority's timezone, which is frequently not the respondent's - and ECF requires submission date and time as filing metadata precisely because that instant has legal effect.", "source_refs": [ "SRC-014", "SRC-006", "SRC-002", "SRC-008", "SRC-010" ], "questions": [ { "id": "which-time-points-are-recorded", "text": "Which distinct time points are recorded for this submission: started, last saved, authored, signed, transmitted, received, decided and disposed?", "kind": "temporal", "answer_data": [ "started-at", "last-modified-at", "authored-at", "signed-at", "transmitted-at", "received-at", "decided-at" ] }, { "id": "how-is-event-time-separated-from-ingestion", "text": "How is event time (when the respondent answered or signed) kept separate from observation or ingestion time (when the receiver recorded it), and which is used for reporting?", "kind": "provenance", "answer_data": [ "event time field", "ingestion time field", "reporting time selection rule", "clock source and skew tolerance" ] }, { "id": "in-which-timezone-is-a-deadline-evaluated", "text": "In which timezone is a deadline evaluated, and is an explicit offset recorded with every stored timestamp?", "kind": "temporal", "answer_data": [ "deadline instant", "deadline timezone", "offset recording rule", "-00:00 usage policy" ] }, { "id": "which-time-counts-after-rejection", "text": "If a submission is rejected and corrected within a grace period, which time counts for deadline compliance?", "kind": "temporal", "answer_data": [ "original receipt time", "corrected receipt time", "grace period duration", "relation-back rule" ] }, { "id": "how-long-may-a-draft-persist", "text": "How long may a draft remain untouched before it expires, and is the respondent warned before expiry?", "kind": "lifecycle", "answer_data": [ "draft expiry duration", "inactivity trigger", "warning notice timing", "expiry disposition action" ] } ], "data_elements": [ { "id": "authored-at", "name": "Authored time", "description": "RFC 3339 instant when the answers were gathered or authored by the respondent.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-014" ] }, { "id": "received-at", "name": "Received time", "description": "RFC 3339 instant at which the receiving authority took delivery of the package.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-014" ] }, { "id": "deadline-at", "name": "Deadline instant", "description": "RFC 3339 instant by which the submission must be received, with the governing offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-006" ] }, { "id": "draft-expiry-duration", "name": "Draft expiry duration", "description": "Period of inactivity after which an unsubmitted draft expires.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "These are timestamp attributes carried on the submission header, status history, audit trail and decision notice rather than a separate retained object. Materialising a standalone time artifact would duplicate the audit trail log and create a second, divergent source of truth for legally operative instants." } ] } ] }, { "id": "governance-privacy-and-disposition", "name": "Governance, privacy and disposition", "description": "Who may see the submission and which parts, what is published or redacted, and how the package is ultimately retained, transferred or destroyed.", "rationale": "The Privacy Act constrains what may be collected and disclosed and requires accuracy and relevance; 21 CFR 11.10(c) and (g) require retrievability through the retention period and authority checks; NARA's Universal ERM Requirements structure capture, maintenance, disposal and transfer. These obligations attach to the submission before it is declared a record.", "source_refs": [ "SRC-010", "SRC-008", "SRC-012", "SRC-006" ], "layers": [ { "id": "access-confidentiality-and-disclosure", "name": "Access, confidentiality and disclosure", "description": "Authorisation to read and act on a submission, sensitivity at item level, and controlled release to third parties or the public.", "source_refs": [ "SRC-008", "SRC-010", "SRC-006", "SRC-012" ], "findings": [ { "id": "access-control-and-field-level-sensitivity", "name": "Access control and field-level sensitivity", "description": "Authority checks must ensure only authorised individuals can use the system, sign, access the operation or alter a record. Submissions are rarely uniformly sensitive: a single package can mix routine fields with identifiers, health data or protected identities, so authorisation granularity below the package is normal rather than exceptional.", "source_refs": [ "SRC-008", "SRC-010", "SRC-006" ], "questions": [ { "id": "which-roles-may-read-and-act", "text": "Which roles may read, amend, decide on or export the submission, and at what granularity is that authorisation expressed?", "kind": "access", "answer_data": [ "role to permission mapping", "granularity (package, document, item)", "access policy reference", "effective period of grant" ] }, { "id": "which-items-are-heightened-sensitivity", "text": "Which items carry heightened sensitivity requiring separate authorisation or separate storage?", "kind": "privacy", "answer_data": [ "sensitive item link identifiers", "sensitivity classification code", "separate authorisation requirement", "minimisation justification" ] }, { "id": "is-any-part-restricted-from-the-parties", "text": "Is any part of the submission sealed or restricted from the submitting or responding parties themselves?", "kind": "exception", "answer_data": [ "sealed flag", "restricted part list", "sealing authority", "unsealing conditions" ] }, { "id": "how-is-each-access-logged", "text": "How is each access to and export of a submission logged, and are denied attempts recorded too?", "kind": "security", "answer_data": [ "access log entry", "actor and role", "purpose of access", "denied attempt record" ] } ], "data_elements": [ { "id": "access-policy-ref", "name": "Access policy reference", "description": "Reference to the authorisation policy governing this submission.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "confidentiality-code", "name": "Confidentiality classification", "description": "Coded confidentiality level of the submission or of a part.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "sensitive-item-link-ids", "name": "Sensitive item link identifiers", "description": "Items requiring elevated authorisation or separate handling.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "access-log-entry", "name": "Access log entry", "description": "Record of one read, export or disclosure with actor, purpose and time.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] } ], "artifacts": [ { "id": "access-policy-binding", "name": "Access policy binding", "description": "The concrete grant set attached to this submission or instrument, resolvable to roles, scopes, item-level exceptions and effective periods.", "media_or_form": [ "structured policy binding", "access control list", "grant register entry" ], "serial": false, "identity_strategy": "Keyed by submission or instrument identifier plus policy identifier plus policy version.", "source_refs": [ "SRC-008", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "redaction-and-public-release", "name": "Redaction and public release", "description": "Some submissions are published - court filings, public comments, regulatory disclosures. Release produces a distinct derived artifact with its own identifier, its own integrity value and a recorded authorisation, and the redaction rule set applied must be retained so the release can be audited against what was actually withheld.", "source_refs": [ "SRC-006", "SRC-010", "SRC-012", "SRC-009" ], "questions": [ { "id": "is-any-version-published", "text": "Is any version of this submission published or disclosed beyond the receiving authority, and to whom?", "kind": "privacy", "answer_data": [ "publication status", "audience or recipient", "disclosure basis (routine use, statute, consent)", "publication channel" ] }, { "id": "which-fields-must-be-redacted", "text": "Which items or document regions must be redacted before release, and under which rule set?", "kind": "requirement", "answer_data": [ "redaction rule set reference and version", "redacted item link identifiers", "redaction method", "residual risk assessment" ] }, { "id": "who-authorises-release", "text": "Who authorises release, and is the authorisation recorded separately from the release itself?", "kind": "authority", "answer_data": [ "authorising role and party", "authorisation timestamp", "authorisation reference", "review evidence" ] }, { "id": "is-the-released-copy-a-distinct-artifact", "text": "Is the redacted release a distinct artifact with its own identifier and integrity value, so it is never confused with the original?", "kind": "identity", "answer_data": [ "released copy identifier", "derivation link to original", "released copy digest", "release timestamp" ] } ], "data_elements": [ { "id": "publication-status", "name": "Publication status", "description": "Whether and how the submission has been released beyond the receiving authority.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "redaction-rule-ref", "name": "Redaction rule set reference", "description": "The versioned rule set applied to produce the released copy.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "released-copy-id", "name": "Released copy identifier", "description": "Identifier of the derived, redacted artifact released to a third party or the public.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "release-authorised-by-ref", "name": "Release authorisation reference", "description": "Party and record authorising the release.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "redacted-public-copy", "name": "Redacted public copy", "description": "Derived release artifact carrying its own identifier, digest, derivation link and applied rule set version.", "media_or_form": [ "redacted document", "public docket entry", "de-identified export" ], "serial": true, "identity_strategy": "Own identifier in a release namespace, plus a derivation reference to the source submission revision; never reuses the submission identifier.", "source_refs": [ "SRC-006", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-and-disposition", "name": "Retention and disposition", "description": "How long the submission and its derivatives are kept, under whose authority they are destroyed or transferred, and how erasure requests are reconciled.", "source_refs": [ "SRC-012", "SRC-008", "SRC-010" ], "findings": [ { "id": "retention-disposition-and-erasure", "name": "Retention, disposition and erasure reconciliation", "description": "Records must remain accurately and readily retrievable throughout the retention period, and disposal or transfer happens under a named authority. Drafts and abandoned answers are the neglected case - they contain personal data but often no disposition instruction. Erasure requests and statutory retention genuinely conflict, and the model must record the outcome of that conflict rather than resolve it silently.", "source_refs": [ "SRC-012", "SRC-008", "SRC-010", "SRC-006" ], "questions": [ { "id": "what-starts-the-retention-clock", "text": "Which event starts the retention clock - receipt, final decision, or closure of the parent matter - and how long is the period?", "kind": "retention", "answer_data": [ "retention trigger event", "retention period", "retention schedule reference", "calculated disposition due date" ] }, { "id": "under-which-authority-is-disposal-made", "text": "Under which named disposition authority is the submission destroyed or transferred, and to which destination?", "kind": "authority", "answer_data": [ "disposition authority reference", "disposition action (destroy, transfer, permanent)", "transfer destination", "disposal certificate reference" ] }, { "id": "how-are-drafts-disposed-differently", "text": "How are abandoned drafts and never-submitted answers disposed of differently from accepted submissions?", "kind": "lifecycle", "answer_data": [ "draft disposition rule", "abandonment definition", "purge schedule", "purge audit entry" ] }, { "id": "how-is-erasure-reconciled-with-retention", "text": "How is an erasure or correction request from the respondent reconciled with a statutory retention obligation, and is a refusal recorded?", "kind": "exception", "answer_data": [ "request type and date", "conflicting obligation citation", "outcome (erased, restricted, refused)", "refusal reasons given to the requester" ] }, { "id": "is-a-legal-hold-in-force", "text": "Is a legal hold or preservation order in force that suspends the disposition schedule?", "kind": "constraint", "answer_data": [ "legal hold flag", "hold authority and reference", "hold start and expected release", "affected artifact scope" ] } ], "data_elements": [ { "id": "retention-trigger-event", "name": "Retention trigger event", "description": "The event from which the retention period is calculated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "retention-period", "name": "Retention period", "description": "Duration the submission and its audit trail must be kept.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-008" ] }, { "id": "disposition-action", "name": "Disposition action", "description": "Coded action to take at the end of retention: destroy, transfer or retain permanently.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "disposition-authority-ref", "name": "Disposition authority reference", "description": "The approved schedule or authority permitting the disposition action.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "legal-hold-flag", "name": "Legal hold flag", "description": "Whether disposition is suspended by a hold or preservation obligation.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "disposition-instruction", "name": "Disposition instruction and certificate", "description": "The binding instruction attached to the submission and, once executed, the certificate recording what was destroyed or transferred, by whom and when.", "media_or_form": [ "structured disposition instruction", "destruction or transfer certificate", "hold notice" ], "serial": true, "identity_strategy": "Submission identifier plus disposition event sequence, cross-referenced to the governing schedule identifier and version.", "source_refs": [ "SRC-012", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "interoperability-and-transport", "name": "Interoperability and transport", "description": "How the submission is serialised, digested, mapped downstream, transmitted and acknowledged without semantic loss.", "rationale": "CDISC keeps one abstract model across XML and JSON serializations; XForms declares serialization separately from the model; RFC 7578 and HTML define wire encodings; FHIR item.definition carries the mapping to downstream elements. Format neutrality is only real if the canonical form is named explicitly.", "source_refs": [ "SRC-013", "SRC-004", "SRC-005", "SRC-001", "SRC-003", "SRC-006" ], "layers": [ { "id": "serialization-mapping-and-extraction", "name": "Serialization and downstream mapping", "description": "The canonical abstract form, its wire projections, and the declared mapping from items to downstream data elements.", "source_refs": [ "SRC-013", "SRC-004", "SRC-005", "SRC-003", "SRC-011" ], "findings": [ { "id": "serialization-profile-and-format-neutrality", "name": "Serialization profile and format neutrality", "description": "The semantics live in the abstract answer tree; urlencoded pairs, multipart parts, XML and JSON are projections. This matters operationally because signatures and digests must cover a single named canonical form, and because flat name/value encodings cannot represent repeating nested groups without a declared convention.", "source_refs": [ "SRC-013", "SRC-004", "SRC-005", "SRC-001", "SRC-011" ], "questions": [ { "id": "which-form-is-canonical-for-digesting", "text": "Which serialization is the canonical form for digesting and signing, as distinct from the transport encodings permitted on the wire?", "kind": "interoperability", "answer_data": [ "canonical form identifier", "canonicalisation rules", "digest algorithm", "permitted transport encodings" ] }, { "id": "what-charset-is-asserted", "text": "What character encoding is asserted for text values, and how is it signalled when the transport cannot carry an explicit declaration?", "kind": "interoperability", "answer_data": [ "declared charset", "charset signalling mechanism", "fallback rule", "transcoding policy" ] }, { "id": "how-are-nested-repeats-flattened", "text": "How are hierarchical and repeating groups represented in a flat name/value encoding without loss of nesting or occurrence identity?", "kind": "composition", "answer_data": [ "flattening convention", "occurrence index encoding", "round-trip test evidence", "documented limitations" ] }, { "id": "which-encodings-are-permitted-per-channel", "text": "Which encodings are permitted for a given channel, and who decides when they diverge from the instrument's declared serialization?", "kind": "constraint", "answer_data": [ "channel to encoding mapping", "decision owner", "negotiation mechanism", "rejection behaviour on unsupported encoding" ] } ], "data_elements": [ { "id": "canonical-form-id", "name": "Canonical form identifier", "description": "Named canonical serialization used for digesting and signing.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "transport-encoding", "name": "Transport encoding", "description": "Encoding actually used on the wire for this transmission.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "payload-charset", "name": "Payload character encoding", "description": "Character encoding asserted for textual values in the payload.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "payload-digest", "name": "Canonical payload digest", "description": "Digest computed over the canonical form, used for integrity and signature binding.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-006" ] } ], "artifacts": [ { "id": "canonical-payload-serialization", "name": "Canonical payload serialization", "description": "The byte-exact canonical rendering of the answer payload retained alongside the abstract tree, so digests and signatures remain verifiable after any storage migration.", "media_or_form": [ "canonical byte stream", "normalised structured document" ], "serial": true, "identity_strategy": "Submission identifier plus payload revision plus canonicalisation profile version; the digest is the verification key.", "source_refs": [ "SRC-013", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "definition-binding-and-downstream-extraction", "name": "Definition binding and downstream extraction", "description": "Items may carry a definition URI pointing at a target data element, enabling answers to be extracted into semantic records. The boundary must be explicit: FHIR keeps the question-faithful response distinct from derived observations, so extraction produces new entities and does not displace the submission as source of truth.", "source_refs": [ "SRC-003", "SRC-002", "SRC-013", "SRC-011" ], "questions": [ { "id": "where-does-each-item-map", "text": "To which target data element does each item map, and is the mapping declared in the instrument or maintained externally?", "kind": "interoperability", "answer_data": [ "item definition URI", "target element reference", "mapping location (inline or external)", "mapping version" ] }, { "id": "is-the-extracted-record-authoritative", "text": "Once answers are extracted downstream, is the extracted record authoritative or does the submission remain the source of truth?", "kind": "provenance", "answer_data": [ "source-of-truth designation", "derivation link", "reconciliation rule on divergence" ] }, { "id": "is-question-wording-preserved", "text": "How is the exact question wording preserved when answers are extracted into semantically typed records that discard phrasing?", "kind": "evidence", "answer_data": [ "retained question text", "link back to instrument version and link identifier", "rendering of original wording in the derived record" ] }, { "id": "how-are-extraction-failures-surfaced", "text": "How are extraction failures surfaced without invalidating an otherwise accepted submission?", "kind": "exception", "answer_data": [ "extraction status", "failed item list", "failure reason", "remediation owner and queue" ] } ], "data_elements": [ { "id": "item-definition-uri", "name": "Item definition URI", "description": "Reference from an item to the formal definition of the data element it populates.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "extraction-target-ref", "name": "Extraction target reference", "description": "The downstream record or element populated from this item.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "extraction-status", "name": "Extraction status", "description": "Coded outcome of an extraction run for this submission.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "mapping-version", "name": "Mapping version", "description": "Version of the mapping applied, so a past extraction can be reproduced.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "extraction-manifest", "name": "Extraction mapping manifest", "description": "Record of one extraction run: mapping version, item-to-target pairs, produced record references, failures and timestamp.", "media_or_form": [ "structured mapping table", "transform run manifest", "lineage export" ], "serial": true, "identity_strategy": "Submission identifier plus mapping version plus monotonic extraction run sequence.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "pre-population-and-answer-provenance", "name": "Populate, extract and standard alignments", "description": "SDC populate builds an initial QuestionnaireResponse from existing data; after human review the filler must ensure validity. Extraction uses submitted answers to create or update other resources. Alignments to HTML, XForms, FHIR, PRA and eForms are not claims of joint conformance. Conflicts (R5 required questionnaire canonical versus older optional; XFA deprecated in PDF 2.0; eForms as notices not respondent forms) must be recorded.", "source_refs": [ "SRC-016", "SRC-023", "SRC-020" ], "questions": [ { "id": "pre-population-and-answer-provenance-q01", "text": "Was this response pre-populated, from which sources, and which answers were then edited by a human?", "kind": "provenance", "answer_data": [ "populated", "source_resource_refs", "edited_link_ids", "filler_validated_after_edit" ] }, { "id": "pre-population-and-answer-provenance-q02", "text": "Into which target records or resources were answers extracted after submit, and with what mapping?", "kind": "interoperability", "answer_data": [ "extract_targets", "mapping_ids", "extract_status" ] }, { "id": "pre-population-and-answer-provenance-q03", "text": "Which external standards is this instance aligned to, and which known conflicts or non-conformances apply?", "kind": "interoperability", "answer_data": [ "aligned_standards", "conflict_ids", "conformance_claimed" ] }, { "id": "pre-population-and-answer-provenance-q04", "text": "If this instrument is an eForms notice, what form type and subtype govern mandatory and conditionally mandatory fields?", "kind": "classification", "answer_data": [ "form_type", "notice_subtype", "sdk_version", "field_obligation_profile" ] } ], "data_elements": [ { "id": "pre-population-and-answer-provenance-data01", "name": "Populated", "description": "Whether initial answers were generated from existing data before human review.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-023" ] }, { "id": "pre-population-and-answer-provenance-data02", "name": "Extract target", "description": "Reference to a record or resource created or updated from this response.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "pre-population-and-answer-provenance-data03", "name": "Alignment", "description": "Named external standard this instance is aligned to, without implying certified conformance.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "pre-population-and-answer-provenance-data04", "name": "eForms notice subtype", "description": "Notice subtype from the eForms annex that determines field obligation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020" ] } ], "artifacts": [ { "id": "pre-population-and-answer-provenance-artifact01", "name": "Populate and extract log", "description": "Trace of pre-population sources, human edits, filler validation and downstream extract targets.", "media_or_form": [ "SDC extract bundle", "mapping trace" ], "serial": true, "identity_strategy": "Response identifier plus extract-run timestamp.", "source_refs": [ "SRC-023" ] } ], "inline_only_rationale": null } ] }, { "id": "channel-receipt-and-idempotency", "name": "Channel, receipt and duplicate handling", "description": "How the package travels, what acknowledgement the submitter receives, and how repeated deliveries are resolved.", "source_refs": [ "SRC-004", "SRC-001", "SRC-006", "SRC-002" ], "findings": [ { "id": "submission-channel-and-acknowledgement", "name": "Submission channel and acknowledgement", "description": "XForms names the endpoint, method and replace behaviour and raises distinct done and error events; ECF returns a synchronous message status with an error code where zero means success, and reports the review result asynchronously afterwards. Three failure classes must stay distinguishable: transport failure, structural rejection and business rejection.", "source_refs": [ "SRC-004", "SRC-001", "SRC-006", "SRC-002" ], "questions": [ { "id": "through-which-channel-was-it-sent", "text": "Through which channel and endpoint was the submission transmitted, and was acceptance acknowledged synchronously or asynchronously?", "kind": "process", "answer_data": [ "channel identifier", "endpoint reference", "method", "synchronous or asynchronous acknowledgement mode" ] }, { "id": "what-proves-receipt", "text": "What does the acknowledgement contain that lets the submitter prove the package was received at a particular instant?", "kind": "evidence", "answer_data": [ "acknowledgement identifier", "received timestamp", "payload digest echoed", "issuing authority and signature" ] }, { "id": "how-are-failure-classes-distinguished", "text": "How are transport errors distinguished from structural rejections and from business rejections in the response?", "kind": "exception", "answer_data": [ "error class code", "error code and text", "retryability indicator", "responsible party for remedy" ] }, { "id": "what-callback-is-owed", "text": "What subsequent notification is owed to the submitter, and within what interval must it arrive?", "kind": "requirement", "answer_data": [ "callback operation", "notification recipient", "service interval", "escalation on non-delivery" ] } ], "data_elements": [ { "id": "endpoint-uri", "name": "Submission endpoint reference", "description": "Address to which the package was transmitted.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-001" ] }, { "id": "acknowledgement-id", "name": "Acknowledgement identifier", "description": "Identifier of the receipt issued by the receiving authority.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "acknowledgement-time", "name": "Acknowledgement time", "description": "RFC 3339 instant at which receipt was acknowledged.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-014" ] }, { "id": "transport-error-code", "name": "Transport or processing error code", "description": "Coded error returned by the receiving service, distinguishing transport from processing failure.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-004" ] } ], "artifacts": [ { "id": "acknowledgement-receipt", "name": "Acknowledgement / receipt", "description": "The receiving authority's statement that a specific package digest arrived at a specific instant, retained by both parties as the primary evidence of timely submission.", "media_or_form": [ "receipt message", "human-readable confirmation", "signed acknowledgement" ], "serial": true, "identity_strategy": "Receiving-authority receipt identifier; cross-referenced to the submission identifier and the acknowledged payload digest.", "source_refs": [ "SRC-006", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "duplicate-detection-and-idempotency", "name": "Duplicate detection and idempotency", "description": "At-least-once delivery and impatient respondents both produce repeated transmissions. FHIR treats each completion for a different subject or time as a distinct response, and ECF carries sender/receiver identifiers with a submission date and time - together these give the keys for deciding sameness. Note that a normative idempotency-key mechanism is common practice rather than a requirement in the sources consulted.", "source_refs": [ "SRC-002", "SRC-006", "SRC-005" ], "questions": [ { "id": "what-key-determines-sameness", "text": "Which key determines that two received packages are the same submission rather than two legitimately distinct ones?", "kind": "identity", "answer_data": [ "idempotency or dedup key", "key components (submitter, instrument version, subject, payload digest)", "key issuing party" ] }, { "id": "what-is-the-dedup-window", "text": "Within what window is a repeated transmission treated as a retry rather than a new submission?", "kind": "temporal", "answer_data": [ "duplicate detection window", "window start reference", "behaviour after window expiry" ] }, { "id": "what-is-returned-on-duplicate", "text": "What is returned when a duplicate is detected - the original receipt, a conflict error, or a new receipt referencing the original?", "kind": "exception", "answer_data": [ "duplicate response behaviour", "returned receipt identifier", "duplicate-of reference", "respondent-facing message" ] } ], "data_elements": [ { "id": "idempotency-key", "name": "Idempotency / deduplication key", "description": "Key used to recognise a repeated delivery of the same logical submission.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-002" ] }, { "id": "duplicate-of-ref", "name": "Duplicate-of reference", "description": "Reference from a detected duplicate to the submission it repeats.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "duplicate-detection-window", "name": "Duplicate detection window", "description": "Period during which repeated deliveries are treated as retries.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Duplicate-resolution facts are control metadata on a single transport exchange and are recorded inside the acknowledgement receipt and the audit trail log. A separate retained artifact would fragment the receipt evidence that the submitter actually relies on, and the sources consulted define no independent duplicate-resolution record." } ] } ] }, { "id": "respondent-experience-and-quality", "name": "Respondent experience and quality", "description": "How errors are communicated and prevented for the person completing the form, and how the collection's real burden and quality are measured.", "rationale": "WCAG 2.2 makes error identification, labels, error suggestion, error prevention, redundant entry and status messages normative success criteria at specific conformance levels; 5 CFR 1320 makes burden estimation and practical utility conditions of the collection. Both are properties of the form/submission surface, not of a generic UI model.", "source_refs": [ "SRC-007", "SRC-009", "SRC-010", "SRC-001" ], "layers": [ { "id": "accessibility-and-error-communication", "name": "Accessibility and error communication", "description": "Normative requirements on how a form labels its inputs, reports failures and prevents costly mistakes.", "source_refs": [ "SRC-007", "SRC-001", "SRC-004" ], "findings": [ { "id": "error-identification-and-suggestion", "name": "Error identification and suggestion", "description": "WCAG 2.2 requires at Level A that input errors be automatically detected, the item identified and the error described in text (3.3.1), and that labels or instructions be provided where input is required (3.3.2); at Level AA it requires correction suggestions where known (3.3.3) and that status messages be programmatically determinable without receiving focus (4.1.3). These bind the shape of the validation issue objects, not just the styling.", "source_refs": [ "SRC-007", "SRC-001", "SRC-004" ], "questions": [ { "id": "is-each-failure-identified-in-text", "text": "For each failed constraint, is the erroneous item identified and the error described in text rather than by colour or position alone?", "kind": "quality", "answer_data": [ "error message text", "erroneous item link identifier", "identification mechanism", "conformance level claimed" ] }, { "id": "is-a-correction-suggested", "text": "Is a correction suggestion provided when one is known, and is it deliberately withheld where suggesting it would compromise security or purpose?", "kind": "exception", "answer_data": [ "suggestion text", "suggestion availability", "withholding justification", "affected item list" ] }, { "id": "are-status-messages-programmatic", "text": "Are validation results and progress exposed programmatically so assistive technology is notified without moving focus?", "kind": "access", "answer_data": [ "status message role", "announcement mechanism", "focus behaviour", "test evidence" ] }, { "id": "does-every-input-have-a-label", "text": "Does every item requiring input carry a label or instruction, and do headings and labels describe topic or purpose?", "kind": "requirement", "answer_data": [ "label text per item", "instruction text", "heading structure", "audit result against 3.3.2 and 2.4.6" ] } ], "data_elements": [ { "id": "error-message-text", "name": "Error message text", "description": "Human-readable description of one validation failure.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-001" ] }, { "id": "error-item-ref", "name": "Erroneous item reference", "description": "Link identifier of the item the error concerns.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "error-suggestion-text", "name": "Correction suggestion", "description": "Suggested correction offered to the respondent where one is known.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "item-label-text", "name": "Item label or instruction", "description": "Label or instruction presented with an item requiring input.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "error-message-catalogue", "name": "Error message catalogue", "description": "Governed set of message texts and suggestions keyed by constraint identifier and locale, retained per instrument version so the message a respondent actually saw can be reproduced.", "media_or_form": [ "message catalogue", "localisation resource", "structured message table" ], "serial": true, "identity_strategy": "Instrument version plus catalogue revision plus locale tag.", "source_refs": [ "SRC-007", "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "error-prevention-and-confirmation", "name": "Error prevention and confirmation", "description": "WCAG 2.2 requires at Level AA that submissions with legal or financial consequences, or that modify user-controlled data, be reversible, checked, or confirmed (3.3.4), and at Level A that previously entered information not be redundantly re-requested (3.3.7). Whether a submission is legally binding therefore changes the mandatory interaction design, so the classification must be recorded on the instrument.", "source_refs": [ "SRC-007", "SRC-001", "SRC-009" ], "questions": [ { "id": "is-this-submission-consequential", "text": "Is this submission legally binding, financial, or a modification of user-controlled data, and therefore subject to the reversible, checked or confirmed requirement?", "kind": "classification", "answer_data": [ "consequence classification", "applicable success criterion", "chosen mechanism (reversible, checked, confirmed)" ] }, { "id": "is-there-a-review-and-confirm-step", "text": "Is a review-and-confirm step presented before irreversible submission, and is the respondent's confirmation itself recorded?", "kind": "process", "answer_data": [ "confirmation step present flag", "summary content shown", "confirmation timestamp", "confirming actor" ] }, { "id": "is-information-re-requested", "text": "Is information the respondent already supplied in the same process re-requested, and if so on what justification?", "kind": "requirement", "answer_data": [ "prefilled item list", "re-requested item list", "justification (essential, security, invalidity)", "conformance assessment" ] }, { "id": "is-input-purpose-programmatic", "text": "Is the purpose of each personal-data input programmatically identified so autofill and personalisation can operate?", "kind": "interoperability", "answer_data": [ "input purpose token per item", "token vocabulary", "coverage of user-information fields" ] } ], "data_elements": [ { "id": "consequence-classification", "name": "Consequence classification", "description": "Whether the submission is legal, financial, data-modifying or routine, driving error-prevention obligations.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "confirmation-step-present", "name": "Confirmation step present", "description": "Whether a review-and-confirm step precedes irreversible submission.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "prefilled-item-link-ids", "name": "Prefilled item link identifiers", "description": "Items populated from previously supplied information rather than re-requested.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "input-purpose-token", "name": "Input purpose token", "description": "Programmatic purpose token for an input collecting information about the user.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-001" ] } ], "artifacts": [ { "id": "confirmation-summary", "name": "Confirmation summary presented to the respondent", "description": "The exact review summary shown before final submission, retained so a later dispute about what the respondent confirmed can be resolved from evidence.", "media_or_form": [ "rendered review summary", "confirmation snapshot", "printable summary" ], "serial": true, "identity_strategy": "Submission identifier plus payload revision at the moment of confirmation; digest-linked to the payload it summarised.", "source_refs": [ "SRC-007", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "quality-and-paradata", "name": "Quality and paradata", "description": "Observed evidence about how the collection actually performs against its claimed burden and utility.", "source_refs": [ "SRC-009", "SRC-010", "SRC-013", "SRC-006" ], "findings": [ { "id": "submission-quality-metrics-and-paradata", "name": "Submission quality metrics and paradata", "description": "Regulated collections must estimate burden and demonstrate practical utility that is actual rather than theoretical, and records must be accurate, relevant, timely and complete. Observed paradata - time to complete, abandonment point, item non-response, edit-check failure concentration and rejection rate - is the falsification test for those claims and the input to instrument revision.", "source_refs": [ "SRC-009", "SRC-010", "SRC-006", "SRC-013" ], "questions": [ { "id": "how-does-measured-burden-compare", "text": "What measured time to complete is observed, and how does it compare with the published burden estimate?", "kind": "measurement", "answer_data": [ "measured duration distribution", "published estimate", "measurement period", "sample size and method" ] }, { "id": "where-do-respondents-abandon", "text": "What proportion of started submissions are abandoned, and at which item does abandonment concentrate?", "kind": "measurement", "answer_data": [ "started count", "completed count", "abandonment rate", "abandonment point link identifiers" ] }, { "id": "which-items-fail-most", "text": "Which items generate the most validation failures or rejections, and has the instrument been revised in response?", "kind": "quality", "answer_data": [ "failure count per item", "rejection reason distribution", "revision decision", "revision instrument version" ] }, { "id": "what-evidences-practical-utility", "text": "What evidence shows the collected data is actually used, and which items have never been consumed downstream?", "kind": "evidence", "answer_data": [ "downstream consumption per item", "unused item list", "utility justification", "retirement recommendation" ] } ], "data_elements": [ { "id": "measured-duration", "name": "Measured completion duration", "description": "Observed time from start to submission.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "abandonment-rate", "name": "Abandonment rate", "description": "Proportion of started submissions never completed, with the concentrating item.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "item-nonresponse-rate", "name": "Item non-response rate", "description": "Proportion of submissions leaving a given item unanswered.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "rejection-rate", "name": "Rejection rate", "description": "Proportion of submissions rejected at review, by reason code.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "quality-paradata-report", "name": "Quality and paradata report", "description": "Periodic report on measured burden, abandonment, item non-response, failure concentration and downstream utilisation for one instrument version, feeding renewal and revision decisions.", "media_or_form": [ "periodic analytics report", "structured metrics export", "burden reassessment submission" ], "serial": true, "identity_strategy": "Instrument version plus reporting period; periods do not overlap and are never restated in place.", "source_refs": [ "SRC-009", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "publish-instrument-version", "name": "Publish instrument version", "description": "Promote a draft form definition to an immutable, bindable published version.", "inputs": [ "draft instrument definition", "issuing authority approval", "mandated notice block", "constraint and value-domain bindings" ], "outputs": [ "published instrument version with canonical URI and version", "publication status and effective period", "resolved value set version pins" ], "preconditions": [ "Instrument identity assigned under the declared identifier system", "Item link identifiers unique and no retired identifier reused", "Dependency graph acyclic", "Mandated notices present and control number not expired" ], "effects": [ "The version becomes bindable by new submissions", "Prior version is closed to new submissions but retained for existing bindings", "Publication event is written to the audit trail" ], "source_refs": [ "SRC-003", "SRC-009", "SRC-013" ] }, { "id": "open-submission-draft", "name": "Open submission draft", "description": "Create a draft submission pinned to an exact instrument version and mint its identifier.", "inputs": [ "instrument canonical URI and version", "respondent and subject references", "channel context" ], "outputs": [ "submission identifier", "pinned instrument version binding", "started-at timestamp", "initial status" ], "preconditions": [ "Instrument version resolvable and within its effective period", "Respondent authorised for this collection" ], "effects": [ "Draft becomes mutable and accrues audit entries", "Draft expiry clock starts" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-014" ] }, { "id": "capture-answer", "name": "Capture answer", "description": "Record or change an answer for one item, re-evaluating enablement and derived values.", "inputs": [ "submission identifier", "item link identifier", "answer value and occurrence index", "actor reference" ], "outputs": [ "updated answer entry", "recomputed enablement and calculated values", "audit entry" ], "preconditions": [ "Submission is in a mutable state", "Item is enabled and not read-only", "Actor authorised to enter data" ], "effects": [ "Answer set and derived values updated", "Audit entry written with actor, time and, where required, reason for change", "Downstream item relevance may change" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-013", "SRC-008" ] }, { "id": "attach-supporting-document", "name": "Attach supporting document", "description": "Add or reference a file part with its metadata, role and integrity value.", "inputs": [ "submission identifier", "file content or reference URI", "declared filename and media type", "attachment role" ], "outputs": [ "attachment part record with digest", "sanitised filename", "attachment role assignment" ], "preconditions": [ "Media type and size within declared limits", "Filename validated against traversal and injection", "Scan or inspection outcome recorded where required" ], "effects": [ "Package composition updated", "Digest recorded for later integrity proof" ], "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "validate-submission", "name": "Validate submission", "description": "Evaluate the declared constraint set against a payload revision and emit a replayable verdict.", "inputs": [ "submission identifier and payload revision", "instrument version and rule set version", "validation tier" ], "outputs": [ "validation run identifier", "overall outcome", "issue list with item references and validity states", "validation timestamp" ], "preconditions": [ "Payload revision immutable for the duration of the run", "Rule set version resolvable" ], "effects": [ "Validation report retained as evidence", "Items barred from validation are recorded as such rather than silently passing", "Failure blocks transitions that require a passing run" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-011", "SRC-008" ] }, { "id": "sign-and-declare", "name": "Sign and declare", "description": "Bind an attestation to a specific payload digest with a full signature manifestation.", "inputs": [ "submission identifier and payload revision", "declaration text as presented", "signer identity and authentication result", "signature meaning" ], "outputs": [ "signature block bound to the payload digest", "printed name, signing time and meaning", "retained declaration text" ], "preconditions": [ "Validation run passed or bypass explicitly authorised", "Signer identity assured and authority check passed", "Payload frozen at the digested revision" ], "effects": [ "Payload revision becomes immutable", "Signature cannot be excised or transferred without detection", "Signing event written to the audit trail" ], "source_refs": [ "SRC-008", "SRC-006", "SRC-013" ] }, { "id": "transmit-submission", "name": "Transmit submission", "description": "Serialise the package into a permitted transport encoding and deliver it to the receiving endpoint.", "inputs": [ "submission package", "canonical form and transport encoding", "endpoint and method", "idempotency key" ], "outputs": [ "transmitted package", "transmitted-at timestamp", "transport outcome or error class" ], "preconditions": [ "Required signatures present where mandated", "Encoding permitted for the channel", "Irrelevant-node pruning applied per declared policy" ], "effects": [ "Submission leaves the mutable state", "Digest of the canonical form is fixed for receipt matching" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-006" ] }, { "id": "acknowledge-receipt", "name": "Acknowledge receipt", "description": "Issue a receipt binding a payload digest to a received instant.", "inputs": [ "received package and its digest", "receiving authority context" ], "outputs": [ "acknowledgement identifier", "received-at timestamp with explicit offset", "echoed payload digest", "error code where applicable" ], "preconditions": [ "Package parsed and sender identified", "Duplicate check completed" ], "effects": [ "Submitter gains evidence of timely delivery", "Deadline evaluation is anchored to the received instant", "Duplicate deliveries resolve to the original receipt" ], "source_refs": [ "SRC-006", "SRC-014" ] }, { "id": "revalidate-on-receipt", "name": "Revalidate on receipt", "description": "Re-evaluate the full constraint set at the receiver against the bound instrument version, independently of any sender verdict.", "inputs": [ "received payload", "bound instrument version", "receiver rule set" ], "outputs": [ "authoritative validation report", "structural versus business outcome split", "divergence record where sender and receiver disagree" ], "preconditions": [ "Bound instrument version resolvable", "Receiver system validated for its intended use" ], "effects": [ "Sender verdict is superseded by the receiver verdict", "Structural rejection and business rejection are recorded as distinct classes" ], "source_refs": [ "SRC-008", "SRC-006", "SRC-001" ] }, { "id": "adjudicate-submission", "name": "Adjudicate submission", "description": "Record an accept, reject or return decision with reason codes and effective time.", "inputs": [ "submission identifier", "validation reports", "reviewer identity and delegated authority" ], "outputs": [ "decision outcome and reason codes", "narrative explanation and remediation instruction", "effective filing time", "adjudication notice" ], "preconditions": [ "Required validation runs complete", "Reviewer authorised for this transition", "Transition permitted by the state transition table" ], "effects": [ "Review status changes and may diverge from recording status", "Notice issued to the submitter", "Deadline consequences fixed by the effective filing time" ], "source_refs": [ "SRC-006", "SRC-002", "SRC-008" ] }, { "id": "amend-or-withdraw-submission", "name": "Amend or withdraw submission", "description": "Record a correction, retraction or withdrawal without destroying prior content.", "inputs": [ "submission identifier", "correction type", "reason for change", "actor reference" ], "outputs": [ "new payload revision or superseding submission", "supersedes and superseded-by links", "amendment record" ], "preconditions": [ "Actor authorised for the correction type", "Submission not blocked by a terminal state without a reopen authorisation" ], "effects": [ "Prior revision retained and remains retrievable", "Downstream consumers can be notified of retraction", "Audit entry with reason for change written" ], "source_refs": [ "SRC-002", "SRC-013", "SRC-008" ] }, { "id": "extract-to-downstream-record", "name": "Extract to downstream record", "description": "Populate semantically typed downstream records from mapped items while preserving question wording.", "inputs": [ "accepted submission", "item definition URIs and mapping version", "target system context" ], "outputs": [ "derived record references", "extraction run manifest", "failure list" ], "preconditions": [ "Submission in an accepted, non-retracted status", "Mapping version resolvable" ], "effects": [ "Derived records created with lineage back to the submission", "Submission remains the source of truth", "Extraction failures queued for remediation without invalidating acceptance" ], "source_refs": [ "SRC-003", "SRC-002", "SRC-013" ] }, { "id": "release-redacted-copy", "name": "Release redacted copy", "description": "Produce and authorise a derived, redacted artifact for disclosure or publication.", "inputs": [ "source submission revision", "redaction rule set and version", "release authorisation" ], "outputs": [ "released copy with its own identifier and digest", "derivation link to the source revision", "release record" ], "preconditions": [ "Disclosure basis identified and recorded", "Sealed or restricted parts excluded", "Authorising role verified" ], "effects": [ "Released artifact enters the public or third-party domain", "Original remains unmodified", "Release logged with actor, purpose and time" ], "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "apply-disposition", "name": "Apply disposition", "description": "Execute retention, hold, transfer or destruction under a named authority.", "inputs": [ "submission identifier and derived artifacts", "retention schedule and disposition authority", "hold status" ], "outputs": [ "disposition action executed", "destruction or transfer certificate", "updated disposition state" ], "preconditions": [ "Retention period elapsed from the declared trigger", "No legal hold in force", "Disposition authority current" ], "effects": [ "Package and its audit trail disposed of together per the schedule", "Certificate retained as evidence of lawful disposal", "Erasure refusals recorded with reasons where retention prevails" ], "source_refs": [ "SRC-012", "SRC-008", "SRC-010" ] }, { "id": "populate-response", "name": "Populate a response", "description": "Create an initial response package from an instrument and available source data, then present it for human review.", "inputs": [ "instrument canonical and version", "subject", "source records" ], "outputs": [ "in-progress response", "populate trace" ], "preconditions": [ "Instrument is identified", "Filler will require human review before treating answers as definitive" ], "effects": [ "Response exists in in-progress status", "Some answers may be pre-filled" ], "source_refs": [ "SRC-023", "SRC-017" ] }, { "id": "author-or-revise-instrument", "name": "Author or revise instrument", "description": "Create or version a form instrument with unique link ids, constraints, labels and submission parameters.", "inputs": [ "draft item tree", "constraint catalogue", "canonical URL policy", "prior version if any" ], "outputs": [ "instrument definition artefact", "item inventory", "constraint catalogue" ], "preconditions": [ "Author is the instrument steward", "Link ids will be unique within the instrument" ], "effects": [ "A new instrument version exists", "Prior version may be marked superseded" ], "source_refs": [ "SRC-015", "SRC-016" ] }, { "id": "obtain-or-renew-collection-authority", "name": "Clear an information collection", "description": "Obtain or extend authority to use an instrument as a collection of information, including burden, notices and control number.", "inputs": [ "instrument", "supporting statement", "burden estimate", "statutory authority" ], "outputs": [ "control number", "expiration date", "public-protection notice text", "clearance status" ], "preconditions": [ "Collection is in PRA coverage or an analogous regime", "Agency Senior Official or equivalent certifies necessity and practical utility" ], "effects": [ "Instrument may be displayed to ten or more persons", "Public-protection and display obligations attach" ], "source_refs": [ "SRC-018", "SRC-019" ] } ], "composition": [ { "target": "WM-REC-001 Record", "relation": "CHILD", "purpose": "Form/Submission is a specialisation of Record covering the pre-record elicitation and validation surface; an accepted submission is declared into Record for classification, registration and disposal, and inherits its records-programme obligations rather than restating them.", "required": true, "source_refs": [ "SRC-012", "SRC-008" ] }, { "target": "Party / Agent (respondent, author, submitter, reviewer, signer)", "relation": "REFERENCE", "purpose": "Every actor role on a submission resolves to an externally governed party identity; this model records the role and the evidence of authority, not the party's own attributes or credentials.", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] }, { "target": "Document / File object", "relation": "COMPOSE", "purpose": "Attachments are composed into the submission package with part-level metadata and digests, while the document's own lifecycle, renditions and format policy remain with the document model.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Electronic Signature / Seal", "relation": "REFERENCE", "purpose": "The signature manifestation and its binding digest are recorded here; certificate chains, trust lists and signature validation algorithms are resolved by the signature model.", "required": false, "source_refs": [ "SRC-008", "SRC-006" ] }, { "target": "Value set / code list registry", "relation": "REFERENCE", "purpose": "Items bind coded answer domains to governed value sets by canonical reference and pinned version; curation and publication of those vocabularies is out of scope.", "required": false, "source_refs": [ "SRC-003", "SRC-013" ] }, { "target": "Audit event / provenance log", "relation": "MIX-IN", "purpose": "Supplies the append-only, tamper-evident, time-stamped trail that every mutating function on this model must write to, including the reason-for-change discipline.", "required": true, "source_refs": [ "SRC-008", "SRC-013" ] }, { "target": "Access policy / authorization", "relation": "MIX-IN", "purpose": "Supplies the authority-check mechanism enforcing which roles may read, amend, sign, decide, export or dispose, at package, document and item granularity.", "required": true, "source_refs": [ "SRC-008", "SRC-010" ] }, { "target": "Retention schedule / disposition authority", "relation": "REFERENCE", "purpose": "Supplies the trigger, period and approved action that this model applies to the submission, its audit trail and its derived releases.", "required": true, "source_refs": [ "SRC-012" ] }, { "target": "Case / matter / workflow", "relation": "REFERENCE", "purpose": "Downstream docketing, assignment and business processing consume an accepted submission; the submission keeps its own review status separately because review and recording outcomes can diverge.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "Consent / authorization instrument", "relation": "REFERENCE", "purpose": "Where a submission relies on consent as its lawful basis, that consent is a separate instrument with its own lifecycle; this model records only the reference and the basis code.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "Payment / fee transaction", "relation": "REFERENCE", "purpose": "Filing fees and payment allowances accompany some submissions but are settled in a financial model; only the reference and its effect on acceptance belong here.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "HL7 FHIR Questionnaire and QuestionnaireResponse (R5)", "relation": "ALIGN", "purpose": "Alignment target for the definition/response pairing, the linkId binding contract, the response status value set and the author/source/subject role separation. Alignment only - no conformance is claimed.", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "target": "OASIS Electronic Court Filing 5.01 filing message", "relation": "ALIGN", "purpose": "Alignment target for submission-as-filing: lead and connected documents, separate review and docketing statuses, synchronous status plus asynchronous review-complete callback, and document signature profiles.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "CDISC ODM v2.0 FormDef / FormData", "relation": "ALIGN", "purpose": "Alignment target for metadata/clinical-data separation, audit records with reason for change, transaction types and one abstract model across multiple serializations.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "WHATWG HTML forms and IETF RFC 7578 multipart/form-data", "relation": "ALIGN", "purpose": "Alignment target for entry-list construction, enctype selection, constraint validation and validity states, and the no-coalescing and ordering rules for identically named parts.", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "target": "W3C WCAG 2.2 conformance profile", "relation": "ALIGN", "purpose": "Alignment target for the normative respondent-facing criteria on labels, error identification, error suggestion, error prevention, redundant entry and status messages, at declared conformance levels.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "W3C XForms 1.1 model / bind / submission", "relation": "ALIGN", "purpose": "Alignment target for model-item properties, the submission element's resource/method/replace/validate attributes, submission events and relevance pruning at serialization.", "required": false, "source_refs": [ "SRC-004" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name one accountable owner for the instrument catalogue (form definitions) and, where different, one for the submission store; both must be named before any instrument is published.", "Declare and register the identifier systems used for instruments, submissions, receipts and released copies before first use, with the issuing party for each.", "Bind a retention schedule, a disposition authority and an access policy to every instrument before it accepts a single submission; unbound instruments must not be publishable.", "Declare the jurisdictions and legal bases under which the collection operates, and the mandated notice content required in each, since notice obligations are jurisdiction-specific.", "Declare the canonical serialization profile and digest algorithm used for signing, separately from the transport encodings permitted on each channel." ], "namespace_guidance": "Instrument canonical URIs are minted under the owning Dimension's namespace as {dimension-ns}/instrument/{slug} and are version-qualified for binding. Submissions live in a separate {dimension-ns}/submission namespace and never reuse instrument identifiers. Released redacted copies take a third {dimension-ns}/release namespace so a published artifact can never be mistaken for the original. Item link identifiers are scoped to the instrument, immutable within a version lineage, and retired identifiers are permanently reserved rather than recycled. Where an external authority issues a form or control number, that number is the business identifier and the URI is a resolvable alias, not a replacement.", "registry_links": [ "Canonical registry entry vr.wm-rec-007 (WM-REC-007, Form / Submission)", "Parent WM-REC-001 Record - accepted submissions are declared into it", "Value set registry - resolves every answerValueSet reference with a pinned version", "Retention schedule register - resolves disposition authority references", "Party register - resolves respondent, author, submitter, reviewer and signer references" ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is the abstract answer tree keyed by item link identifier with explicit occurrence indices; urlencoded, multipart, XML and JSON renderings are projections and are never the basis for a digest.", "All time values are RFC 3339 with seconds and an explicit offset or Z; -00:00 is used only for a known UTC instant with an unknown local offset.", "Item order is preserved from the bound instrument version; identically keyed entries are never coalesced and their occurrence indices are part of the canonical content.", "Relevance-based pruning is applied deterministically and only per the instrument's declared pruning policy, before digesting; the applied policy identifier is recorded with the digest.", "Missingness is canonicalised as an explicit coded reason where one applies; absent, null and empty string are not treated as synonyms.", "Text values are canonicalised to a single declared Unicode normalisation form and encoding before digesting." ], "patch_rules": [ "Drafts are freely mutable, but every mutation writes an audit entry with actor and RFC 3339 timestamp, and a reason for change where the collection is regulated.", "After a submission leaves draft, content is append-only: a patch produces a new payload revision linked by supersedes/superseded-by, and never rewrites a revision that has been digested or signed.", "A signed revision is immutable; correcting signed content requires a new revision and a new signature, with the prior signature and revision retained.", "Retraction is expressed as a status change plus a retention-preserving marker, never as deletion of the payload.", "Instrument versions are immutable once published; corrections produce a new version, and existing submissions keep their original binding unless a recorded migration decision says otherwise." ], "compatibility_rules": [ "Adding an optional item, adding an answer option, or relaxing a bound are minor changes and take a new minor version.", "Changing an item's type, narrowing a value domain, changing required from false to true, reordering items where order is semantic, or removing an item are breaking changes and require a new major version.", "An item link identifier is never reused for a different question; retired identifiers are permanently reserved.", "Submissions remain bound to the instrument version they were created against; a receiver revalidates against the bound version, not the current one.", "A canonicalisation profile change is breaking for signature verification and requires the prior profile to remain resolvable for the full retention period." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the receiving authority or issuing body - receipt/filing number, official form number, or control number - used whenever one exists.", "Governed global identifier or canonical IRI for the instrument version or submission, minted in the registered namespace of the owning Dimension.", "UUID or ULID assigned by the adopting Dimension, used only when neither an authoritative nor a governed global identifier is available, and always recorded alongside any later-issued authoritative identifier rather than replaced by it." ], "timestamp_rule": "All time values are recorded as RFC 3339 date-times with seconds and an explicit numeric offset or Z. Event time (authored, signed, transmitted) and observation or ingestion time (received, recorded, validated, extracted) are stored in separate fields and never conflated; where a deadline applies, the governing timezone is recorded explicitly alongside the instant. -00:00 is used only when the UTC instant is known but the local offset is not.", "serial_naming_rule": "Serial artifacts - instrument versions, payload revisions, validation runs, status transitions, audit entries, decisions, amendments, extraction runs and disposition events - are named {artifact-type}-{parent-identifier}-{zero-padded sequence}. Sequences are monotonic within their parent, never reused and never renumbered; a human-facing version label may be added for display but the sequence remains authoritative for ordering.", "integrity_rule": "Every retained artifact records a digest over its canonical form together with the digest algorithm identifier and the canonicalisation profile version. Signatures bind to that digest so they cannot be excised, copied or transferred to another record. A digest mismatch marks the artifact unusable and raises an incident; it is never silently repaired, re-canonicalised or regenerated." }, "policies": [ "Client-side or in-form validation is never authoritative; the receiving authority revalidates against the bound instrument version before any status beyond received is assigned.", "A submission is never deleted in order to correct it; corrections are amendments or superseding submissions, and superseded content is retained for the full retention period.", "Mandated notices - legal authority, response obligation, purposes, routine uses, effects of non-response, control number and expiry, and burden estimate - must be present and current on an instrument before it accepts submissions, and are retained verbatim as issued.", "Personal data collected is limited to what is relevant and necessary for the declared purpose; items never consumed downstream are candidates for retirement at the next instrument revision.", "Every read, export, disclosure and denied access attempt on a submission containing personal data is logged with actor, role, purpose and RFC 3339 timestamp.", "The audit trail is generated by the system independently of the operator, is protected against modification by the parties it records, and is retained at least as long as the submission it describes.", "Signature and validation must not be performed out of order; sequencing is enforced by an operational system check, not by convention or user interface flow alone.", "Do not conduct a PRA-covered collection that lacks a currently valid displayed control number and public-protection notice.", "Always re-validate on the server even when the client reported valid.", "Do not treat a draft saved with novalidate as a captured record.", "Retain prior versions of amended or change-noticed packages; void via entered-in-error rather than silent delete while the schedule still applies.", "Identify required fields and errors in accessible text, and require review or confirmation before legal, financial or irreversible submits." ], "crud": { "read": [ "Read is denied by default and granted by an access policy bound to the instrument, at package, document or item granularity.", "Every read of a submission containing personal data is logged with actor, role, purpose, scope and RFC 3339 timestamp; denied attempts are logged too.", "Superseded and retracted revisions remain readable to authorised roles for the retention period, flagged so they cannot be mistaken for current content.", "Sealed or restricted parts are excluded from reads even for parties otherwise entitled to the package, until an unsealing authorisation is recorded." ], "create": [ "Creating a draft requires a resolvable instrument version within its effective period, and mints a submission identifier under the registered submission namespace.", "Creating a submitted package requires a passing receiver validation run - or an explicitly authorised and recorded bypass - and, where mandated, a signature manifestation bound to the payload digest.", "Creation records started-at and, on delivery, received-at as separate RFC 3339 instants with explicit offsets.", "A receipt is created for every accepted delivery and echoes the payload digest so the submitter can prove what arrived and when." ], "update": [ "Drafts are mutable; each change writes an audit entry with actor, timestamp and, for regulated collections, a reason for change.", "After submission, content changes only through an amendment that creates a new revision and preserves the prior one intact.", "Status changes only along transitions permitted by the published transition table, executed by an authorised role, with the authority check recorded.", "Published instrument versions are never updated in place; a correction is a new version and existing bindings are unaffected." ], "delete": [ "Accepted submissions are not deleted outside an executed disposition action under a named authority, and the action produces a retained certificate.", "Abandoned drafts may be purged after the declared expiry period; the purge itself is audited and the audit entry survives the purge.", "Erasure requests are evaluated against statutory retention and any legal hold; where retention prevails the request is recorded as refused with the reasons given to the requester.", "The audit trail is disposed of together with the submission it describes, never before it, and never selectively for individual entries." ] }, "roles": [ { "name": "Respondent / source", "responsibilities": [ "Supply the answers and any supporting evidence", "Accept the declaration text where attestation is required", "Receive and retain the acknowledgement and any adjudication notice", "Exercise access, correction and erasure requests" ] }, { "name": "Author / recorder", "responsibilities": [ "Enter or transcribe answers on behalf of a respondent in assisted or interviewer-administered collections", "Record the source of each answer where it differs from the recorder", "Supply a reason for change on corrections to previously recorded answers" ] }, { "name": "Submitter / filer of record", "responsibilities": [ "Transmit the package and hold the evidence of representation where filing on another's behalf", "Resolve transport failures and rejections and manage resubmission", "Retain the receipt as evidence of timely submission" ] }, { "name": "Instrument steward", "responsibilities": [ "Own the instrument catalogue, version lineage and publication decisions", "Keep mandated notices, control numbers and burden estimates current", "Maintain link identifier uniqueness and the retired-identifier reservation list", "Act on paradata evidence to revise or retire items" ] }, { "name": "Reviewer / adjudicator", "responsibilities": [ "Apply review criteria and record accept, reject or return decisions with governed reason codes", "Set the effective filing time and any remediation instruction", "Handle partial acceptance and part-level statuses", "Operate within delegated authority and permitted transitions" ] }, { "name": "Records custodian", "responsibilities": [ "Bind retention schedules and disposition authorities to instruments and submissions", "Apply and release legal holds", "Execute disposition and retain destruction or transfer certificates", "Ensure accurate and complete copies remain retrievable throughout retention" ] }, { "name": "Privacy and disclosure officer", "responsibilities": [ "Approve the notice block, purposes and routine uses before publication", "Authorise redacted releases against a versioned redaction rule set", "Adjudicate erasure and correction requests against retention obligations", "Review data minimisation at each instrument revision" ] }, { "name": "Validation and system assurance owner", "responsibilities": [ "Maintain and version the constraint and edit-check specification", "Validate the system so it can discern invalid or altered records", "Prove that sequencing and authority checks are enforced, not merely documented", "Preserve canonicalisation profiles and digest algorithms for the retention period" ] } ], "access": { "default_rule": "Deny by default. A submission is readable only by the respondent's party, the submitting party, roles the receiving authority has assigned to it, and roles explicitly granted by the access policy bound to the instrument; each grant carries a scope and an effective period.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Sealed or restricted parts are withheld even from parties otherwise entitled to the package, until an unsealing authorisation is recorded.", "A redacted copy may be released to the public or a third party under a recorded disclosure basis, as a distinct artifact with its own identifier and digest.", "Statutory or court-ordered disclosure overrides the default rule and is logged with the compelling instrument reference.", "Break-glass access for safety or continuity requires a recorded justification at the time of access and triggers post-hoc review.", "De-identified or aggregate release for quality and burden reporting is permitted without item-level authorisation, provided re-identification risk has been assessed.", "Systems processing the submission on the owner's behalf receive scoped, time-limited access that is logged identically to human access.", "PRA criminal, named-party administrative, or intelligence collections that the statute takes outside ordinary clearance still require access logging when stored in this Dimension.", "Public eForms notices are readable once published; unpublished drafts are not.", "entered-in-error packages remain readable to custodians for audit but are excluded from extract and analytics." ], "audit_requirements": [ "Log actor, role, scope, purpose and an RFC 3339 timestamp for every read, export, disclosure and status change.", "Log denied access attempts with the same fields, since denial patterns are themselves evidence.", "Generate the audit trail independently of the operator and protect it from modification by the parties it records.", "Retain the audit trail at least as long as the submission and dispose of the two together.", "Make the audit trail exportable as an accurate and complete copy in both human-readable and machine-readable form for inspection.", "Record which canonicalisation profile and digest algorithm were in force for each integrity assertion, so past verifications remain reproducible.", "Log populate, save-incomplete, validate, submit, amend, void, extract, access grants and disposal with actor, artefact id and RFC 3339 event time.", "Retain audit records at least as long as the response they describe." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Registry ID", "Owner", "Canonical identifier system", "Retention authority", "Canonicalisation profile and digest algorithm" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type, Model ID and Registry ID before any operation.", "Follow Specification URL to load the model scope, boundaries and the bundle/layer/finding structure, including what is explicitly out of scope.", "Follow Storage type URL to learn the projection in use (JSON, YAML, Markdown, Git, MongoDB or other) and confirm that projection details are never treated as semantics.", "Follow Interface URL to discover the access surface (MCP, HTTP, file system) and the authorisation model, and confirm deny-by-default before attempting reads.", "Follow Processes URL to load the permitted state transitions, authority checks, validation tiers and disposition procedures before attempting any mutation.", "Resolve the canonical identifier system and canonicalisation profile before minting identifiers or computing any digest, and never mint a UUID where an authoritative identifier exists." ] } }, "coverage": { "claim": "Merged model covers the instrument-definition and submission-instance surface supported by the base fourteen sources plus two carried-forward sources (HL7 SDC form data extraction; the OIRA/GSA PRA approval guide): instrument identity and version lineage, item tree and link-identifier contract, answer value domains and conditional logic, mandated collection notices and burden, submission identity and version binding, payload and attachment composition, multi-tier validation with receiver authority, status and transition control, adjudication and remedy, actor roles and attestation, audit and temporal record, access, redaction and disposition, serialization, pre-population and downstream extraction, channel and receipt, and accessibility and paradata. This is a defensible synthesis across the web-forms, clinical-capture, legal-filing, records-management and paperwork-burden traditions; it is not a claim of universal completeness, of coverage of every form regime, or of conformance to any cited standard. Idempotency semantics, localisation equivalence and offline capture remain declared gaps.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Instrument canonical URI plus version and business form/control number; submission receipt or filing number, submitter reference and fallback UUID/ULID; item link identifier as the definition-to-response contract with a no-reuse rule. Identity priority follows authoritative master-system identifier, then governed IRI, then UUID/ULID. Grounded in SRC-002, SRC-003, SRC-006, SRC-009." }, { "dimension": "lifecycle", "status": "covered", "notes": "Instrument publication states and effectivity; submission draft, submitted, under review, accepted, rejected, amended, entered-in-error, withdrawn and expired; explicit transition table with guards. FHIR supplies the response status value set, ECF supplies separate review and docketing statuses, 21 CFR 11.10(f) supplies the enforced sequencing requirement (SRC-002, SRC-006, SRC-008)." }, { "dimension": "relationships", "status": "covered", "notes": "Response-to-instrument version binding (1..1 canonical), subject, based-on and part-of links, supersedes/superseded-by, amendment-of, duplicate-of, derivation links to released copies and extracted records, and lead-versus-connected document roles (SRC-002, SRC-006)." }, { "dimension": "temporal", "status": "covered", "notes": "Distinct started, last-modified, authored, signed, transmitted, received, decided and disposed instants; RFC 3339 with explicit offset or Z; event time separated from ingestion time; deadline timezone recorded; draft expiry; relation-back after rejection (SRC-014, SRC-002, SRC-006, SRC-008)." }, { "dimension": "provenance", "status": "covered", "notes": "Source versus author versus submitter versus subject; capture location; secure computer-generated time-stamped audit trail with reason for change and transaction type; extraction lineage with mapping version (SRC-002, SRC-008, SRC-013)." }, { "dimension": "ownership", "status": "covered", "notes": "Issuing authority and instrument steward for the definition; respondent, submitter and on-behalf-of representation for the instance; records custodian for the retained package; owner-package requirements in the Dimension service layer (SRC-003, SRC-006, SRC-012)." }, { "dimension": "validation", "status": "covered", "notes": "Declared constraints and validity states, barred-from-validation cases, format-as-annotation versus assertion, multi-tier validation with receiver authority, replayable validation reports pinned to rule-set version and payload digest (SRC-001, SRC-004, SRC-011, SRC-008, SRC-006)." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with policy binding, item-level sensitivity, sealed parts, break-glass with justification, logging of reads and denials, authority checks at each transition (SRC-008, SRC-010, SRC-006)." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention trigger and period, disposition authority and action, legal hold, abandoned-draft purge as a distinct case, erasure-versus-retention conflict recorded rather than silently resolved, audit trail disposed with the record, retrievability throughout retention (SRC-012, SRC-008, SRC-010)." }, { "dimension": "interoperability", "status": "covered", "notes": "Named canonical form distinct from transport encodings, charset signalling, flat-versus-nested representation of repeats, item.definition mapping to downstream elements, alignment links to FHIR, ECF, ODM, HTML/RFC 7578, XForms and WCAG with no conformance claimed (SRC-013, SRC-005, SRC-003, SRC-001, SRC-004)." }, { "dimension": "privacy", "status": "covered", "notes": "Mandated collection notices (authority, obligation, purposes, routine uses, effects of non-response), relevance and necessity, field-level sensitivity, redaction before release, minimisation review at revision (SRC-010, SRC-009)." }, { "dimension": "accessibility", "status": "covered", "notes": "WCAG 2.2 criteria bound to concrete data elements: error identification and description, labels and instructions, correction suggestions, programmatic status messages, error prevention for consequential submissions, redundant entry, input purpose tokens (SRC-007)." }, { "dimension": "measurement", "status": "covered", "notes": "Burden estimate and practical utility as instrument obligations, measured against observed paradata: completion duration, abandonment point, item non-response, failure concentration and rejection rate (SRC-009, SRC-010, SRC-006)." }, { "dimension": "evidence and attestation", "status": "covered", "notes": "Signature manifestation with printed name, signing instant and meaning; signature-record linking preventing excision or transfer; verbatim declaration text; attachment digests; confirmation summary retained as shown (SRC-008, SRC-006, SRC-007)." }, { "dimension": "constraint and value domains", "status": "covered", "notes": "Datatypes, governed value sets with pinned versions, answer-constraint modes, bounds, patterns, units and precision, plus the declared-versus-receiver-enforced split (SRC-003, SRC-011, SRC-004)." }, { "dimension": "spatial", "status": "covered", "notes": "Treated narrowly and only where sources support it: capture site or organisational location as in ODM's LocationRef, and jurisdiction as a rule-selection factor. No geometry model is asserted; geospatial answers are ordinary typed answers governed by the value-domain finding (SRC-013, SRC-003)." }, { "dimension": "security", "status": "covered", "notes": "Filename validation against traversal, media-type and size limits, malware inspection outcome, authority checks, tamper-evident audit trail, digest-bound signatures, identity assurance before signing (SRC-005, SRC-008)." }, { "dimension": "exception handling", "status": "covered", "notes": "Barred-from-validation items, validation bypass with recorded authority, partial acceptance, terminal-state reopening, duplicate resolution, extraction failure without invalidating acceptance, erasure refusal (SRC-001, SRC-006, SRC-008, SRC-010)." }, { "dimension": "idempotency and delivery semantics", "status": "gap", "notes": "Duplicate detection is modelled but rests on thin normative support: ECF supplies sender/receiver identifiers and a submission instant, FHIR supplies distinctness-per-occasion, and RFC 7578 supplies no-coalescing, but none of the fourteen sources defines an idempotency key or a retry window. Presented as a candidate structure requiring first-party policy, not as canonical." }, { "dimension": "multilingual and localisation", "status": "gap", "notes": "Instrument item text, notices, error messages and declaration text are all locale-bearing, and a translated question is not self-evidently the same question for equivalence purposes. The error message catalogue artifact carries a locale tag, but no source consulted governs translation equivalence, so this is flagged rather than asserted." }, { "dimension": "offline and intermittent capture", "status": "gap", "notes": "Field capture with deferred transmission creates a real gap between authored time and received time and raises clock-trust questions. The temporal finding records both instants and RFC 3339 requires an explicit offset, but no source consulted governs trusted time or clock-skew tolerance for disconnected capture." } ], "known_omissions": [ "No trusted-timestamp or time-attestation mechanism is modelled; received-at is asserted by the receiving authority and its trustworthiness is assumed rather than proven.", "Instrument authoring, review and approval workflow is not modelled - only the resulting publication state and approval dates.", "Multi-party or sequential co-signing and countersigning of one submission is not modelled; the signature block supports multiple signers but no ordering or quorum semantics are asserted.", "Fee calculation, waiver and payment settlement are referenced but not modelled.", "Rendering, pagination, progressive disclosure and multi-page wizard state beyond draft persistence are out of scope.", "Anti-automation, rate limiting and bot detection on public submission endpoints are not modelled despite being operationally significant for open collections.", "Translation equivalence between localised instrument versions is not governed.", "Statistical treatment of item non-response (imputation, weighting) is deliberately excluded as survey methodology.", "Long-term signature validation and re-timestamping to survive algorithm obsolescence across a multi-decade retention period is acknowledged in the integrity rule but not modelled.", "ISO 15489 authenticity, reliability, integrity and usability principles were not retrieved as full text; record-capture therefore leans on PRA recordkeeping and the parent Record model.", "Regulation (EU) No 910/2014 eIDAS full text was not retrieved; qualified versus advanced signatures are an evidence gap and an alignment, not a native profile.", "ISO 32000 PDF AcroForm and deprecated XFA were discovered in secondary discussion and not fetched as primary text.", "ICH eCTD, national tax-return, court e-filing, ODK/XLSForm, JSON Forms and NIEM IEPD specializations were not modelled.", "GDPR erasure interaction with records schedules is only asked, not specified.", "Concurrent editing, autosave intervals, CAPTCHA and rate-limiting are operational controls not specified here.", "Multi-signer sequential routing and power-of-attorney to submit are likely omissions.", "Statistical Part B methods, sampling and statistical-disclosure control are out of scope and unmodelled." ], "conflicts": [ "Correction semantics diverge: FHIR amends a response in place with an amended status, while OASIS ECF and most filing regimes require a new superseding filing. Both are represented and the choice is forced into an explicit declared convention rather than silently defaulted.", "Relevance pruning conflicts with completeness evidence: XForms prunes irrelevant nodes at serialization, but records regimes and audit expectations often require proof of what was not asked. The model resolves this by requiring the pruning policy to be declared and recorded with the digest, but the two traditions genuinely disagree.", "Erasure rights conflict with statutory retention and with 21 CFR 11.10(c) retrievability; the model records the outcome of the conflict rather than asserting a resolution.", "Client-side constraint validation as specified by WHATWG produces a verdict that has no legal standing; ECF and 21 CFR 11 make the receiving system authoritative. The model subordinates the client verdict, which is common practice but is not itself stated as a normative rule in SRC-001.", "JSON Schema treats format as an annotation by default while HTML input types treat the equivalent checks as blocking constraints, so the same declared format can be enforcing or advisory depending on the projection.", "ECF separates review status from docketing status and allows them to disagree, while FHIR carries a single response status; a system aligned to both must maintain two status axes and define their aggregation.", "FHIR R5 QuestionnaireResponse.questionnaire is 1..1; earlier FHIR releases allowed responses without a formal Questionnaire, leaving link-id correctness undefined.", "HTML mixes presentation with submission semantics; XForms forbids that mix. Adopting both as alignments is intentional and must not be read as a single serialization.", "eForms are publication notices, not general respondent questionnaires; reusing their subtype codes for clinical or PRA forms would be a category error.", "XForms allows turning validation off to save unfinished data; FHIR completed means content is regarded as definitive. Save-incomplete must remain status in-progress.", "Client constraint validation can be bypassed; WAI requires server-side validation. Claiming a package valid because the browser checked it conflicts with the security rule.", "OMB will not ordinarily approve non-exempt recordkeeping beyond three years; many sector records schedules are longer. That conflict is resolved in the parent Record model, not here.", "XFA forms are incompatible with AcroForms and were deprecated in PDF 2.0; PDF is only a projection and XFA must not be treated as the ISO form model." ], "regional_assumptions": [ "Mandated-notice content is drawn from United States instruments (5 CFR 1320 control number, expiration and burden statement; 5 U.S.C. 552a(e)(3) authority, purposes, routine uses and effects of non-response). Other jurisdictions impose analogous but differently structured notice duties, and the notice block finding must be re-parameterised per jurisdiction rather than copied.", "21 CFR Part 11 controls are United States FDA-regulated-industry requirements. They are used here as an authoritative articulation of audit-trail, sequencing, authority-check and signature-manifestation practice, not as a claim that all submissions are subject to them.", "NARA Universal ERM Requirements are United States federal-agency requirements; the capture/maintenance/disposal/transfer structure generalises well but the Must Have classification does not bind outside that context.", "OASIS ECF reflects United States court filing practice; the review-versus-docketing status separation is a strong general pattern but the specific code sets are jurisdiction-bound.", "EU data-protection obligations (lawful basis, storage limitation, information-to-be-provided, automated decision-making) are structurally parallel to the Privacy Act provisions used here, but the EUR-Lex text could not be retrieved live during this research and is therefore not cited; a European adoption must re-derive the notice and retention findings from the regulation directly.", "WCAG 2.2 conformance levels are cited as the criteria themselves state them; whether Level A, AA or AAA is mandatory depends on the adopting jurisdiction's procurement or accessibility law, which is not modelled.", "OMB control numbers, public-protection statements and ICR processes apply to US federal collections, not to all jurisdictions.", "eForms obligation matrices and TED publication apply to EU public-procurement notices above threshold (mandatory from October 2023) and to listed voluntary subtypes.", "WCAG-based error-prevention is treated as the default accessibility floor for interactive web instruments; other modalities must still associate labels with controls as XForms requires.", "FHIR party compartments are healthcare-centric; other sectors map them to equivalent respondent, subject and recorder roles.", "Qualified electronic signature legal effect is EU-specific and unverified in this run." ], "adversarial_checks": [ "Is the instrument/submission pairing an unjustified merge? Tested against the alternative of two separate models. The linkId binding contract, version pinning, relevance pruning and revalidation semantics all span the pair and would be orphaned by a split, and every source consulted defines the two together. The registry's boundary-review-required flag is respected by recording an explicit split line in the boundary notes, so the merge is falsifiable rather than assumed.", "Is any structure attractive but unsupported? Idempotency and duplicate handling, multilingual equivalence and offline capture were each tested against the fourteen sources and none is normatively grounded; all three are marked as gaps in the checklist rather than presented as canonical, and the idempotency finding says so in its own description.", "Does the model duplicate the parent Record model? Registration, classification schemes, disposal authority as a governance instrument and record-series management are excluded and delegated to WM-REC-001. What remains here is the elicitation contract, the validation lifecycle and the acceptance decision - none of which the Record model carries.", "Does it silently claim conformance to external standards? No. All external standards appear as ALIGN links with alignment-only language, six substantive conflicts are recorded, and JSON Schema is tiered at 2 because it is an expired Internet-Draft rather than a ratified standard.", "Would a counterexample break it? Tested against a paper form scanned and keyed by a clerk: the instrument definition still applies, source and author separate cleanly, transport encoding is absent but the canonical form still exists, and authored-time versus received-time separation becomes essential. Tested against a machine-to-machine regulatory filing with no human respondent: accessibility findings become not-applicable in practice while identity, validation, attestation and disposition all hold. Neither counterexample requires structural change, though the accessibility bundle is inapplicable to the second.", "Are questions boilerplate? Each finding's questions were checked for discriminating power - they ask which party's verdict is authoritative, which of five missingness states applies, whether acceptance backdates, and whether pruned nodes are recoverable. Questions that would have the same answer for every model of this kind were removed.", "Is the identity rule actually followed everywhere? Checked across all artifacts: receipt and filing numbers take priority where a receiving authority issues them, canonical URIs govern instrument versions, UUID/ULID appears only as an explicit fallback, and no artifact uses a date or a filename as an identifier.", "Could instrument and response be two models? They could, and FHIR splits them; this aggregate keeps the split internally so validation and submission, which bind both, remain operable as one package.", "Could eForms swallow the generic model? No: change-notice and subtype rules are an alignment family, not identity.", "Does save-incomplete undermine validation? Only if status is allowed to become completed without a validate=true submit; the model forbids that.", "Is a date used as an identifier anywhere? Control-number expiration and authored timestamps are attributes; identity priority excludes them.", "Would claiming PRA plus eForms plus FHIR conformance be false? Yes; coverage records alignments and conflicts instead.", "Are drafts records? No; capture into WM-REC-001 happens after successful receive of a completed package unless a local records policy says otherwise, which would be a documented extension." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers independently reached entry_kind=aggregate for WM-REC-007 and both keep the instrument/response distinction internally rather than collapsing it. The binding contract (link identifiers, instrument-version pinning, relevance pruning, receiver revalidation) exists only across the pair and would be orphaned by a split, and every source consulted by either provider defines the two together. The base provider's explicit, falsifiable split line (bundle 'instrument-definition' moves out, bundles 2-7 stay, version-binding duplicated as a REFERENCE) is retained verbatim so the registry can re-review the merge later; the internal split stays visible as separate bundles. The upstream WM-REC-001 Record boundary is also concordant across providers: drafts and rejected packages are in this model and are not yet records." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude as base", "rationale": "Not chosen on size. The base carries complete, explicit boundaries the other lacks: a full out-of-scope list, eight neighbour distinctions with source refs, and an internal split line that makes the aggregate merge falsifiable. Its checklist also declares three gaps and six conflicts rather than asserting coverage, which is the safer substrate for a deterministic synthesizer." }, { "concept": "Entry kind and instrument/submission pairing", "disposition": "accepted as aggregate", "rationale": "Independent convergence by both providers, and both keep the definition/response split internally rather than collapsing it. The base's split line is retained so a later registry decision to separate the two entries does not require re-research." }, { "concept": "SDC pre-population (populate)", "disposition": "accepted as addition", "rationale": "Genuinely absent from the base, which models only outward extraction. Tier-1 primary evidence in the source provider, and it introduces a provenance distinction (machine-asserted versus human-confirmed answers) that the base's roles finding cannot currently express." }, { "concept": "Instrument authoring act", "disposition": "accepted as function only", "rationale": "Fills an operability hole between the base's in-scope instrument content and its publish function. Scoped deliberately to the authoring and versioning act so the base's declared omission of authoring/review/approval workflow is not silently reversed." }, { "concept": "Collection clearance act", "disposition": "accepted as function only", "rationale": "The base already states the legal consequence of an expired control number but models no act producing or renewing that authority. Both providers hold 5 CFR 1320, so the evidence is corroborated rather than single-sourced." }, { "concept": "PRA collection-control-number display finding", "disposition": "rejected as duplicative", "rationale": "The base's regulatory notice finding already carries authority, obligation, purposes, routine uses, control number and expiry, and burden, and its notice artifact already covers paper versus electronic first-screen placement. Only the clearance-type taxonomy is additive, and that is better folded into the existing finding on a later pass than materialised as a second notice finding." }, { "concept": "EU eForms notice family", "disposition": "rejected as native structure, deferred as profile", "rationale": "The source provider itself calls eForms an alignment family and warns that reusing its subtype codes elsewhere is a category error. Its evidence is a tier-2 portal page describing the regulation, not the regulation text, and the base already flags the EU profile as un-derived. Importing it would create jurisdiction-specific structure on secondary evidence." }, { "concept": "Client-versus-server validation and save-incomplete", "disposition": "rejected as duplicative", "rationale": "The base's validation-tiers finding already makes the receiver authoritative and records the disagreement, and its constraint finding already names the novalidate/validate=false path for saving incomplete work. The status model and transition guards already forbid an unvalidated package reaching a definitive status. No new fact remains." }, { "concept": "Save-incomplete as a distinct function", "disposition": "rejected as duplicative", "rationale": "Draft persistence is already reachable through the base's open-submission-draft and capture-answer functions, and the authority to bypass validation is already an explicit question on the constraint finding. A separate function would fragment draft handling across three acts." }, { "concept": "Amendment, change notice, stop and void", "disposition": "rejected as duplicative; retained as corroboration", "rationale": "The base already splits this across its status model and its amendment/withdrawal/resubmission finding, and already forces the amend-in-place versus supersede choice into a declared convention. The eForms restriction on change notices for structurally significant updates is kept as a third corroborating data point for that recorded conflict, not as new structure." }, { "concept": "XForms replace/targetref instance replacement", "disposition": "deferred", "rationale": "There is a real unanswered question underneath it - after receipt, whether the submitter's copy or the values returned by the receiving system are authoritative - but the source provider frames it as processing-model behaviour, and a whole finding is disproportionate. Recorded for a later pass rather than imported as transport implementation detail." }, { "concept": "Record-capture handoff to WM-REC-001", "disposition": "deferred", "rationale": "Both providers agree accepted submissions are declared into the parent Record model, but neither carries the linkage itself (record identifier plus capture instant), and the source provider concedes its record-capture reasoning leans on an unretrieved ISO 15489. Adding it now would be weakly supported and would cross the parent boundary." }, { "concept": "Localisation and translation equivalence", "disposition": "deferred", "rationale": "The base declares it a gap; the source provider carries language only as scattered question attributes with no governing finding, and neither pack contains a source governing translation equivalence between localised instrument versions. Nothing importable exists at finding granularity." }, { "concept": "Idempotency and duplicate detection", "disposition": "retained as candidate structure only", "rationale": "The base is explicit that no consulted source defines an idempotency key or retry window and marks the dimension a gap in the finding's own description. That labelling must survive synthesis; it may not be promoted to canonical because the merged pack adds no new evidence on it." }, { "concept": "Spatial dimension", "disposition": "base treatment retained", "rationale": "The base treats capture site and jurisdiction narrowly and refuses to assert a geometry model, routing geospatial answers through the value-domain finding. The source provider marks spatial a gap and offers only eForms place-of-performance codes, which is jurisdiction-bound. The narrower supported treatment is the safer merge." } ], "publicationHolds": [ "Source verification: re-resolve every base URL plus the two carried-forward sources and confirm exact version pins before publication. The two packs cite different snapshots of the same instrument - 5 CFR 1320 as govinfo CFR revised 1 January 2024 versus eCFR current as of 2026-08-20 - and the HTML Living Standard is cited with two different access dates. Pin one snapshot per source and record the retrieval date.", "Multi-profile validation: the merged model is validated mainly against United States instruments (5 CFR 1320, 5 U.S.C. 552a, 21 CFR 11, OASIS ECF, NARA ERM) plus healthcare and clinical-trial capture (FHIR, CDISC ODM). No EU obligation was derived from primary text - GDPR, eIDAS and Regulation (EU) 2019/1780 were all unretrieved or secondary in both packs. Hold publication until at least one non-US domain profile is re-derived from primary sources.", "Evidence-tier labelling: JSON Schema draft 2020-12 is an expired Internet-Draft, and the OIRA/GSA PRA approval guide and the TED eForms portal page are secondary descriptions of primary instruments. These must remain tier-2 alignment references and must not carry normative weight in the published draft.", "The duplicate-detection and idempotency finding must remain explicitly labelled as candidate structure requiring first-party policy; no source in either pack defines an idempotency key or a retry window.", "The instrument-definition versus submission-instance split line must remain recorded in the boundary notes and be re-reviewed by the registry before this entry is treated as final rather than as a public research draft." ], "deferredResearch": [ "Localisation and translation equivalence across instrument versions: whether a translated item is the same question for binding, validation and legal-completeness purposes, and how locale is carried on item text, notices, error messages and declaration text. Both providers carry language only as an attribute; neither has a governing source.", "EU profile re-derivation from primary text: Regulation (EU) 2019/1780 and the eForms SDK, GDPR erasure and storage-limitation duties, and eIDAS advanced versus qualified signature effect - all unretrieved or secondary in both packs and currently blocking any European adoption of the notice, retention and attestation findings.", "PRA clearance-authorization lifecycle taxonomy (standard, generic, emergency, extension, revision, reinstatement; approval not granted beyond three years) to be folded into the existing mandated-notice finding rather than materialised as a second finding, once the new obtain-or-renew-collection-authority function is in place.", "Offline and intermittent capture: trusted time, clock-skew tolerance and the gap between authored instant and received instant for disconnected field capture. No source in either pack governs trusted timestamping.", "Record-capture handoff to WM-REC-001: the linkage carrying record identifier and capture instant when an accepted submission is declared into the parent Record model, pending retrieval of ISO 15489 or an equivalent primary authority.", "Response-driven instance replacement (XForms replace and targetref): which copy is authoritative after the receiving system returns values that overwrite the submitter's instance, and how that interacts with the signed canonical form.", "Multi-party sequential co-signing, countersigning and power-of-attorney to submit: both providers flag this as an omission and the signature block supports multiple signers with no ordering or quorum semantics asserted." ] }, "statistics": { "sources": 23, "bundles": 7, "layers": 16, "findings": 29, "questions": 117, "artifacts": 27, "functions": 17 } }