The purpose of the DDI4 Data Capture Instrument View is to describe the processes of developing- and collect data from a questionnaire instrument, as well as to describe the capture or acquiring of measurements from various sources, like databases, registries, administrative data, bio-medical devices, environmental sensors, or any other source or instrument. The focus on measurement is new in DDI4 compared to earlier versions of the standard.

Use Cases:

Document the development process for a conceptual questionnaire of an international survey

Design an implemented questionnaire in a specific mode and for a specific population

View how a measurement has been captured or how a survey question has been asked

Reuse of instrument components developed for a different study

Export instrument related metadata between applications

Design a measurement

Describe a measurement instrument

Target Audiences:

Developers of conceptual instruments, for example for an international survey.

Designers of implemented instruments for surveys and measurements.

Designers and developers of data capture tools.

Researchers wishing to understand how a measurement has been captured or how a survey question was asked or how it was developed.

DDI4 users in general.

Restricted Classes:

WorkflowStepSequence is extended by StructuredWorkflowSteps.

RepresentedVariable is extended by InstanceVariable.

CodeList is extended by GeographicUnitClassification, GeographicUnitTypeClassification and StatisticalClassification.

ConceptualVariable is extended by InstanceVariable

Concept is extended by InstanceVariable, Population and UnitType;

ExternalMaterial is extended by ExternalAid.

Code is extended by ClassificationItem.

General Documentation:


The goal of questionnaire design is to develop an ImplementedInstrument from which data can be captured when put in field. The first step in a questionnaire design process is often to select or define the topics and the Concepts to be measured by the questions in the instrument. The concepts are then operationalized into RepresentedQuestions that contains the more reusable components of a question that can be reused among different surveys, studies and modes of collection. InstanceQuestions realize the represented questions in an instrument. It connects to other InstrumentComponents like for example a showcard or other ExternalAid and Instructions, and links the question to the flow logic of the questionnaire. The ConceptualInstrument represents the instrument independent of mode. It organizes the instrument by connecting the instrument components to WorkflowStepSequence that realizes the flow of a questionnaire sequence, including conditions IfThenElse, Loop etc. The ImplementedInstrument has a specific mode and is designed or adapted for a specific sample or population. Two different implemented instruments may use the same conceptual instrument.


Measurements are non-question based data captures like for example blood pressure measurements, MRI images, thermometer, web-service, and experimental observations. Measurements often involve the use of specific machines or protocols to ensure consistency and comparability of the measure. The RepresentedMeasurement is a description of the components of a measurement, that can be reused by multiple or repeated studies. The ImplementedMeasurement initiates the represented measurement so that it can be used in the data capture process. Other InstrumentComponents like Instructions and ExternalAids associated with the measurement can be linked to the implemented instrument.
The ConceptualInstrument represents the reusable components of the instrument that can have different concrete implementations. It connects to the WorkflowStepSequence that realizes the instrument flow. A WorkflowStep can be linked to a WorkflowService that involves agents and services involved in the process step. The ImplementedInstrument is a specific implementation of a conceptual instrument.

Include in build?: 


Redid Instrument View to reflect changes in ProcessPattern and to conform to FV creation rules.

The following changes were made to classes related to the Process Pattern which effect the function of Instrument View. These changes were made in response to issues raised early in the Q2 review and addressed by the Modeling Team (see for diagrams and discussion of changes)

Removed circular references from Process (retained relationship to ProcessStep and Algorithm)
Moved Process form MethodologyPattern to ProcessPattern
Changed the following to isProperty="true": OrderedPair, UnorderedPair, OrderedTuple, UnorderedTuple
Changed contains from Relationship to property: AsymmetricBinaryRelation, SymmetricBinaryRelation, SemetricRelation, AsymmetricRelation, ProcessStep, ImmediatePrecedenceRelation, OrderRelation, StrictOrderRelation, AcyclicPrecedenceRelation, EquivalenceRelation, InformationFlow
Parameters: change name to ParametersDELETE and move to Deleted; remove from InstrumentView
InputParameter: change name to WorkflowParameter; change extension base to Identifiable; edited definition;
OutputParameter: change name ro OutputParameterDELETE and move to Deleted
Binding: change to no extension base, change source and target targets to WorkflowParameter; removed properties
ElseIf: changed to property no extension base, condition type="command code"
WorkflowStep: removed hasParameters and added input target WorkflowParameter 0..n and output target WorkflowParameter 0..n; added realizes Interface
WorkflowSequence: changed name to WorkflowStepCollection; added contains WorkflowStep; renamed type of Sequence to typeOfWorkflowStepCollection; removed constructSequence and this no longer makes sense with specific sequencing. Alternate sequences such as randomization can be defined using conditional control constructs.
ConditionalControlConstruct: change extension base to WorkflowStep;
SplitJoin: changed extension base to WorkflowStep
Split: changed extension base to WorkflowStep
ControlContruct: changed name to ControlConstructDELETE and moved to Deleted

Graph for view