Negate the meaning of the concepts that inherit 'negation'. (Negation is not negated again.)

It is to the developers choice whether an element is probably not supported.

it is a recommendation NOT to take care of this element (for some reasons)

it is forbidden to handle this element

Conformant applications SHALL NOT populatae more data than is specified. The specification is closed.

Conformant applications SHALL NOT populate a reason for missing information.

mandatory in IHE V3

Conformant applications SHALL NOT cut off data.

Conformant applications SHALL NOT add this data to the narrative.

Conformant applications SHALL NOT process the data in some meaningful way.

Conformant applications SHALL NOT modiify the data in any way.

Conformant applications SHALL NOT reurn an erorr to the sender of the data.

forbidden in IHE V3

Conformant applications SHOULD NOT process the data in some meaningful way.

Conformant applications SHOULD NOT modiify the data in any way.

Conformant applications SHOULD NOT reurn an erorr to the sender of the data.

forbidden in v2

backwards use in v2 only

withdrawn use in v2 only

Conformant applications MAY NOT process data, aka of ignoring.

Conformance verbs are to be used to define the requirement level that is the foundation to indicate what has to be tested.

it is to the developers choice whether an element is supported or not

It is a recommendation to take care of this element

This verb denotes a testable requirement.

Conformant applications SHALL take data from a UI and provide it.

Conformant applications SHALL take data from a UI and bring it into the instance. It is allowed to provide more details then specified.

Conformant applications SHALL send the instance.

Conformant applications SHALL store the data in some way.

Conformant applications SHALL store the data in a way that the originally data from the instance can be reestablished.

Conformant applications SHALL print the data.

Conformant applications SHALL document the way the data is used in some (meaningful) way.

Conformant applications SHALL reject invalid data.

Conformant applications SHALL accept invalid data.

Conformant applications SHALL be able to receive the data.

required in v2.x

required but may be empty in v2.x

required in IHE V3

MUSS in xDT (unbedingtes Mussfeld)

muss in xDT (bedingtes Mussfeld)

KANN in xDT (unbedingts KANNfeld)

kann in xDT (bedingtes Kannfeld)

Conformant applications SHOULD take data from a UI and provide it.

Conformant applications are asked to store the data in a database.

Conformant applications SHOULD print the data.

Conformant applications SHOULD document the way the data is used in some (meaningful) way.

Conformant applications SHOULD display the data in some meaningful way.

Conformant applications SHALL display the data in some meaningful way.

Conformant applications SHOULD reject invalid data.

Conformant applications SHOULD accept invalid data.

Conformant applications SHOULD be able to receive the data.

Conformant applications MAY take and provide data.

Conformant applications MAY populate the element why the original data is missing.

Conformant applications SHOULD take and provide data.

Conformant applications MAY populate element into narrative text as well.

Conformant applications SHOULD populate element into narrative text as well.

Conformant applications SHALL populate element into narrative text as well.

Conformant applications SHOULD take and provide data.

R2 in IHE v2.x specs

Conformant applications MAY take data from a UI and provide it.

Conformant applications MAY store the data.

Conformant applications are allowed to populate the data with more structure. For example, to split an address line into streetname and house number.

Conformant applications MAY, i.e. are allowed to modify the data.

Conformant applications MAY print the data.

Conformant applications MAY process the data somehow.

Conformant applications SHOULD process the data in some meaningful way.

Conformant applications SHALL process the data in some meaningful way.

Functional Type of Requirement

functional requirement

function that operates on the internal data management

functional requirement on direct returns

functional requirement to prepare responses

functional requirement to forward data

data requirement

Type of Testing

requirement is testable

requirement is testable by a machine

requirement is testable by a human (inspection)

requirement is testable by using a checklist

requirement is not testable

An actor can operate in two ways: with the content itself, or as a manager of the instance.

handle the transport of data once the instance is available/accessible

sender (transmitter) of data

convey instance with values to somewhere

receiver of data

Obligation for Consumer

receive data form somewhere

handle data from instances as needed for general message consumption, store permitted.

what to do internally

present the data on a display

persist/store the data somewhere

persist/store the archive which ensures longlasting access

persist in a database

store in a file

print the data (somewhere)

consider the data in order to interpret other correctly

to UPDATE existing data by merging other data with the existing data in a controlled manner

what to respond

return possible warnings

return possible errors

reject if data is invalid

accept if data is invalid

router of data: shall be receiver and sender!

As a router, take data from input stream.

needs clarification ...

as a router forward to the next recipient

manage the data itself

creator of data

populate with values from somewhere

Take the data from UI, so that the user has the ability to enter it.

Take data from storage/persistence layer.

This data can be generated.

This data can be generated from other data.

added as constant to the data, no special treatment done internally

added to the narrative, no special treatment done internally

Data Obligations

data fits to expectations/specification

preserve what you get

exactly what is specified, nothing else

allow for modifications of the data

taken by association

in an equivalent way

Data received is preserved by 1:1 mapping/translation to an internal value that is semantically equivalent, that preserves the temporal aspect of the translation.

Two concepts are semantically equivalent if they can substitute for each other in the defined use case with no loss of information used to define the concept.

Two concepts are clinically equivalent if they can substitute for each other in the defined use case with no impact on clinical interpretation by a trained clinician. This may include further refinements based on the specific domain, e.g., for Lab use case, this would require interpretation that includes the impact of differences in normal ranges.

Use referenced data based on stored pointer; stored data is displayed by linking to the corresponding stored value most often the case for data elements that are STORED EXACT by ASSOCIATION.

cut off remaining characters from the data thereby shortening the data

extends the expected data with more/own information, e.g. appartment if street is specified

provides the data with more granular details, e.g. house number for an address line

provide a null-flavor/absent reason

this value has no valid representation or meaning in the sending application, it is just added because it is required to be there

how to manage unexpected data (as sender or receiver)

replaces the expected data by something else

take vare of values that are coming but not described/specified. Allows for warnings

Consumer of data

Actor, i.e. indirect direction of communication

both: sender+receiver resp. creator+consumer

Device to be used for the activity

screen/display

wide screen/display

screen/display capable of showing radiologic results

printer

laser printer

matrix printer

portable storage device

USB Stick

tape drive

different media to be used with specialised devices

paper

stick

disc

tape

On which level to apply this obligation: root, node, or leaf

apply obligation on root node only

apply on any node that is not root or leaf

apply on leaf node only

application on all levels possible

apply on non-root nodes only

apply on non-leaf nodes

Activities, aka of general obligation

Functional Obligation describing processsing functionalities

Other obligations beyond what has been described above.

provide an explanation in a capability statement how this element is handled

document the use of this element in a separate document

The children can be used to encode obligations for data elements. Terms in parenthesis are shown for readability. This list is not complete, and only provides some reasonable samples.

Conformant applications SHOULD NOT populate element into narrative text.

Conformant applications SHALL NOT populate element into narrative text.

Conformant applications SHOULD send the instance.

Conformant applications SHOULD store the data.

Other standards use specific terms for optionality/usage that should be conceptualized here.

optionality/usage codes from v2

optionality/usage codes from V3/CDA

optionality/usage codes from IHE

required in IHE v2.x specs

XX in IHE v2.x specs

The German xDT standard family has a very specific set of codes and is just presented here for completeness and demonstration purposes