Proposed Obligation Codes - Obligation Discussion v0.5.1

Obligation Discussion, published by . This guide is not an authorized publication; it is the continuous build for version 0.5.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/frankoemig/obligation/ and changes regularly. See the Directory of published versions

CodeSystem: Proposed Obligation Codes (Experimental)

Official URL: http://v2.hl7.org/fhir/CodeSystem/obligationProposed				Version: 0.1.0
Draft as of 2026-03-26				Computable Name: ObligationProposedCodes
Copyright/Legal: Conformance WG

This codesystem is a proposal for obligation codes in response to Grahame's codesystem for obligations. It represents an ontology that not only combines the other three codesystems (verb, obligation, data expectation), but also introduces some more axes/dimensions to better explain the meaning of the codes.

This Codesystem has originally been derived from 3 individual codesystems that were the basis for discussion in Conformance WG:

verbs, aka of reqquirement level
obligation, aka of functional requirements, and
data expectation, aka of data requirements

During the course of discussion Conformance WG members became aware that due to the overarching complex structure of obligations the maintenance as individual and independent codesystems seems inappropriate. It is also unnecessary complex to instantiate them in form of reasonable combinations when taking them from different CS. Instead, it appears much better to combine them as an ontology in form of a single codesystem and to introduce the meaning by properties and polyhierarchies. This way, complex obligations can be expressed. Consequently, those properties (where indicated) are inherited downwards.

As a result from the discussion, borrowing from the codesystem currently bound to the obligation extension led to an improved and enhanced codesystem. It has multiple axes to separate concerns. It is designed as follows:

Following a short intro into the different axes. The purely definitional ones are marked in red, supporting the foundation for precoordination in yellow. The green will contain precoordinated and defined concepts that can be instantiated and used in combination with profiles. Due to their ontological definition, their meaning should be clear:

definition/qualification:
- Negation: to tag the inverse of a statement or to express the explicit negation
- Conformance verbs to denote the requirement level
- Actor, i.e. indirect direction (of communication)
- Actor Type, i.e transport or data management
- Functional Type
- Element Level for application, i.e. at root, on a node, or just at leafs
for precoordination:
- Activities, aka of base obligations
  - Functional Requirements, i.e. data management and transport
    - as producer
    - as consumer
    - (at single point in time one is either producer or consumer)
    - other?
  - Data Managment, aka creation/consumption
  - Data Obligation, aka expectation

Axis to be instantiated:

combined obligations (shown at the end)

Some remarks:

Some requirements are only interpretable in combination with minimum cardinality:
- For example, "SHALL:populate" does not imply that a value is always present. Otherwise we have side-effects in interpreting the concepts.

Interactions

Following, some interactions should help to understand where specific activities take place so that it becomes easier to align with obligations. The drawings should be taken as abstract examples and may of course vary to reality.

Simple Receiver

In the following, a component - the receiver - is taking the data, parse it, and maintains the data in a central space - the "parsed data". The consumer actor in return is triggered, takes the data, and starts some kind of processing with it. It may result in any kind of modification which is shown as simple interactions with the storage (database). As a response to this internal processing, some data is provided for preparing a response to the originator. (It should be noted that this drawing abstracts from a transport vs. application acknowledgement.)

Router/Forwarder

The other drawing examines what happens if data is routed to another party.

This Code system is referenced in the content logical definition of the following value sets:

Language: en

Properties

This code system defines the following properties for its concepts

Name

Code

URI

Type

Description

Parent

parent

http://hl7.org/fhir/concept-properties#parent

code

Who is the parent element of this concept? Multiple parents are possible.

negation

boolean

Negating the underlying combination of concepts.

Not Selectable

abstract

http://hl7.org/fhir/concept-properties#notSelectable

boolean

Is this an abstract concept, ie. defined to establish the ontology, so that it cannot be used directly. (only valid for the concept where it is defined)

testable

code

Is this a testable requirement?

Comment

comment

http://hl7.org/fhir/concept-properties#comment

string

Comment from Conformance WG

converse

code

What is the opposite item

constrainTo

code

What is a possible constraint? This can be done with the hierarchy, or, in case of conformance verbs, explicitly following this option, although this is not recommended.

applyOn

code

Apply on which element level: root, node, leaf, all, notRoot, notLeaf

actor

code

Actor

Concepts

This case-sensitive code system http://v2.hl7.org/fhir/CodeSystem/obligationProposed defines the following codes in a Is-A hierarchy:

Lvl	Code	Display	Definition	Parent	negation	Not Selectable	testable	Comment	converse	constrainTo	applyOn
1	Negation	Negation	Negate the meaning of the concepts that inherit 'negation'. (Negation is not negated again.)		true	true		In principle, negation is to be inherited from concepts that are negated already. Therefore, a negation shall only take effect once, and not negate a negation.
1	Verbs	conformance verbs	Conformance verbs are to be used to define the requirement level that is the foundation to indicate what has to be tested.			true		Conformance verbs are primarily interesting for testing, i.e. to indicate what has to be tested. The other concepts can be taken as hints to a developer.
2	MAY	MAY	it is to the developers choice whether an element is supported or not	Verbs			notTestable	MAY primarily provides additional general information, but is still for the discretion of the implementer/developer.	MAYNOT	SHOULD, SHOULDNOT
3	SHOULD	SHOULD	It is a recommendation to take care of this element	MAY				Just a hint.		SHALL, SHOULDNOT, SHALLNOT
4	SHALL	SHALL	This verb denotes a testable requirement.	SHOULD			testable
2	MAYNOT	MAYNOT	It is to the developers choice whether an element is probably not supported.	Verbs, Negation		true	notTestable	MAYNOT is no reasonable option. It is mentioned though to complete the hierarchy.	MAY
3	SHOULDNOT	SHOULD NOT	it is a recommendation NOT to take care of this element (for some reasons)	MAYNOT	true				SHOULD	SHALLNOT, SHOULD, SHALL
4	SHALLNOT	SHALL NOT	it is forbidden to handle this element	SHOULDNOT	true		testable	It may happen for some elements, eg. due to security reasons, not to handle (provided/store/etc.) this element.	SHALL
1	FunctionalType	Functional Type of Requirement	Functional Type of Requirement			true
2	functional	functional	functional requirement	FunctionalType
3	internal	internal functional	function that operates on the internal data management	functional
3	return	return functional	functional requirement on direct returns	functional
3	response	response function	functional requirement to prepare responses	functional
3	forward	forwarding function	functional requirement to forward data	functional
2	data	data	data requirement	FunctionalType
1	Testable	Type of Testing	Type of Testing			true
2	testable	testable	requirement is testable	Testable
3	testableByMachine	machine testable	requirement is testable by a machine	testable
3	testableByHuman	human testable	requirement is testable by a human (inspection)	testable
4	withChecklist	checklist	requirement is testable by using a checklist	testableByHuman
2	notTestable	testable	requirement is not testable	Testable	true
1	ActorType	Type of Actor	An actor can operate in two ways: with the content itself, or as a manager of the instance.			true
2	transport	transport	handle the transport of data once the instance is available/accessible	ActorType				not sure whether this (and everything related) has to be taken out of this spec?
2	content	content mngmt	manage the data itself	ActorType
1	Actor	Actor of Communication	Actor, i.e. indirect direction of communication			true
2	both	sender and/or receiver	both: sender+receiver resp. creator+consumer	Actor		true		an actor can only do one thing at a certain point in time. Therefore, both is not allowed and only listed for documentation.
2	sender	sender	sender (transmitter) of data	Actor, transport				Sender does not necessarily need to create the instance.
2	receiver	receiver	receiver of data	Actor, transport
2	creator	creator	creator of data	Actor, content				Creator does not necessarily need to send the instance.
2	consumer	consumer	Consumer of data	Actor, content
2	router	router	router of data: shall be receiver and sender!	Actor, transport		true		A router is in principle a combination of receiver and sender, w/ possible changes on the data in between. It should be described as such.
1	Device	Device for Activity	Device to be used for the activity			true
2	screen	screen	screen/display	Device
3	wideScreen	wide screen	wide screen/display	screen
3	radScreen	radiologic screen	screen/display capable of showing radiologic results	screen
2	printer	printer	printer	Device
3	laserPrinter	laser printer	laser printer	printer
3	matrixPrinter	matrix printer	matrix printer	printer				Sometimes it is important to use a matrix printer, esp. for creating carbon copies.
2	portableStorage	portable storage device	portable storage device	Device
3	usbStick	usb stick	USB Stick	portableStorage
3	tapeDrive	tape drive	tape drive	portableStorage
1	Media	Media	different media to be used with specialised devices			true
2	paper	paper	paper	Media
2	stick	stick	stick	Media
2	disc	disc	disc	Media
2	tape	tape	tape	Media
1	ElementLevel	Level of Application	On which level to apply this obligation: root, node, or leaf			true
2	root	on root node	apply obligation on root node only	ElementLevel					notRoot
2	node	on any node	apply on any node that is not root or leaf	ElementLevel
2	leaf	on leaf node	apply on leaf node only	ElementLevel
2	all	on all levels	application on all levels possible	ElementLevel
2	notRoot	all but root	apply on non-root nodes only	ElementLevel					root
2	notLeaf	all but leaf	apply on non-leaf nodes	ElementLevel
1	Activity	Activity	Activities, aka of general obligation			true
2	FunctionalObligations	Functional Obligations	Functional Obligation describing processsing functionalities	Activity		true
3	ProducerObligations	Resource Producer Obligations		FunctionalObligations		true
4	send	send	convey instance with values to somewhere	ProducerObligations, sender							root
4	populate	populate	populate with values from somewhere	ProducerObligations, creator				prohibited elements can be expressed by 'SHALL NOT send'.
5	from-ui	from UI	Take the data from UI, so that the user has the ability to enter it.	populate
5	from-store	from persistence layer	Take data from storage/persistence layer.	populate
5	generate	generate this data	This data can be generated.	populate
6	from-other	generate from other values	This data can be generated from other data.	generate
6	sequence	generate a sequence number		generate
5	from-input	from input stream	As a router, take data from input stream.	populate, router
5	as-constant	constant	added as constant to the data, no special treatment done internally	populate
5	into-narrative	narrative	added to the narrative, no special treatment done internally	populate
3	ConsumerObligations	Resource Consumer Obligations	Obligation for Consumer	FunctionalObligations, receiver		true
4	receive	receive	receive data form somewhere	ConsumerObligations, receiver							root
4	process	process	handle data from instances as needed for general message consumption, store permitted.	ConsumerObligations, consumer				elements that are to be ignored can be expressed by 'SHALL NOT process'.
5	follow-up	follow-up activity	what to do internally	process
6	display	display/present (UI)	present the data on a display	follow-up
6	persist	persist	persist/store the data somewhere	router, follow-up
7	archive	archive	persist/store the archive which ensures longlasting access	persist
7	in-database	persist in a database	persist in a database	persist				too explicit/dedicated, concerns application details
7	in-file	store in a file	store in a file	persist				too explicit/dedicated, concerns application details
6	print	print	print the data (somewhere)	follow-up
6	eval	evaluate	consider the data in order to interpret other correctly	follow-up
6	integrate	integrate into data	to UPDATE existing data by merging other data with the existing data in a controlled manner	follow-up
5	respond	activity as response	what to respond	process
6	warning	return warnings	return possible warnings	respond
7	error	return error	return possible errors	warning
7	reject-invalid	reject invalid data	reject if data is invalid	warning
6	accept-invalid	accept invalid data	accept if data is invalid	respond
3	ExchangerObligations	Resource Exchanger Obligations	needs clarification ...	FunctionalObligations, both, router		true
4	route	route forward	as a router forward to the next recipient	ExchangerObligations		false
3	OtherObligations	Resource Other Obligations	Other obligations beyond what has been described above.	FunctionalObligations		true
4	explain	explain	provide an explanation in a capability statement how this element is handled	OtherObligations
4	document	document	document the use of this element in a separate document	OtherObligations
2	DataObligation	Obligations on Data	Data Obligations	Activity, creator, consumer		true		The following codes may apply to creator and consumer. For example 'do not modify from UI'.
3	expected	expected	data fits to expectations/specification	DataObligation				This applies to recipients and denotes that the data should be present according to the specification, i.e. is specified.
4	unaltered	preserve	preserve what you get	expected				That may also be used to take data from UI without any modifications.
5	exactly	exactly	exactly what is specified, nothing else	unaltered				not sure whether 'unaltered' is sufficient so that we can drop that!?
4	modify	modify	allow for modifications of the data	expected, consumer				Covers all types of modifications to data.
5	assocation	assocation	taken by association	modify
5	equivalent	equivalent	in an equivalent way	modify
5	translate	translate	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.	modify
6	semantically	translate semantically	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.	translate
6	clinically	translate clinically	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.	translate
5	reference	reference	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.	modify
5	truncate	cut off data	cut off remaining characters from the data thereby shortening the data	modify
5	more-details	additional details/values	extends the expected data with more/own information, e.g. appartment if street is specified	modify, creator				This is in principle not a modification...
5	more-structure	additional substructures	provides the data with more granular details, e.g. house number for an address line	modify, creator				This is in principle not a modification...
5	missing	data is missing/not available	provide a null-flavor/absent reason	modify, creator				In FHIR this is the permission/indication for a data-absent-reason or something similar. In V3 it is null-flavor.
5	constant	added as a constant	this value has no valid representation or meaning in the sending application, it is just added because it is required to be there	modify
3	unexpected	unexpected values	how to manage unexpected data (as sender or receiver)	DataObligation
4	replaces	new/other values	replaces the expected data by something else	unexpected
4	consider	consider unexpected values	take vare of values that are coming but not described/specified. Allows for warnings	unexpected
1	CombinedObligations	combined obligations	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.			true		The following list is just a snippet and should be enhanced during the discussion..., The hierarchy has to discarded because not everything is explicitly modelled.
1	MAY:populate	MAY populate with data	Conformant applications MAY take and provide data.	CombinedObligations, MAY, populate				is this a useful combination?
1	MAY:populate:missing	MAY populate data element with why orig data is missing	Conformant applications MAY populate the element why the original data is missing.	MAY:populate, missing
1	MAY:(populate)from-ui	MAY populate with data taken from ui	Conformant applications MAY take data from a UI and provide it.	CombinedObligations, MAY, from-ui
1	SHOULD:populate	SHOULD populate with data	Conformant applications SHOULD take and provide data.	CombinedObligations, MAY:populate
1	MAY:(populate)into-narrative	MAY populate into-narrative	Conformant applications MAY populate element into narrative text as well.	CombinedObligations, SHOULD:populate				discuss whether other representation forms are better
1	SHOULD:(populate)into-narrative	SHOULD populate into-narrative	Conformant applications SHOULD populate element into narrative text as well.	CombinedObligations, MAY:(populate)into-narrative				discuss whether other representation forms are better
1	SHALL:(populate)into-narrative	SHALL populate into-narrative	Conformant applications SHALL populate element into narrative text as well.	CombinedObligations, SHOULD:(populate)into-narrative				discuss whether other representation forms are better
1	SHOULDNOT:(populate)into-narrative	SHOULD NOT populate into-narrative	Conformant applications SHOULD NOT populate element into narrative text.	CombinedObligations					SHOULD:(populate)into-narrative
1	SHALLNOT:(populate)into-narrative	SHALL NOT populate into-narrative	Conformant applications SHALL NOT populate element into narrative text.	CombinedObligations, SHOULDNOT:(populate)into-narrative					SHALL:(populate)into-narrative
1	SHALL:populate	SHALL populate with data	Conformant applications SHOULD take and provide data.	SHOULD:populate
1	SHOULD:(populate)from-ui	SHOULD populate with data taken from ui	Conformant applications SHOULD take data from a UI and provide it.	CombinedObligations, SHOULD, from-ui, creator
1	SHALL:(populate)from-ui	SHALL populate data taken from ui	Conformant applications SHALL take data from a UI and provide it.	SHOULD:(populate)from-ui, SHALL, from-ui			testableByHuman
1	SHALL:(populate)from-ui:more-details	SHALL populate with data taken from ui perhaps with more details	Conformant applications SHALL take data from a UI and bring it into the instance. It is allowed to provide more details then specified.	SHALL:(populate)from-ui, more-details
1	SHOULD:send	SHOULD send the instance	Conformant applications SHOULD send the instance.	CombinedObligations
2	SHALL:send	SHALL send the instance	Conformant applications SHALL send the instance.	CombinedObligations, SHALL, send, sender			testableByMachine				root
1	MAY:persist	MAY store the data	Conformant applications MAY store the data.	CombinedObligations, MAY, persist
1	SHOULD:persist	SHOULD store the data	Conformant applications SHOULD store the data.	CombinedObligations
2	SHALL:persist	SHALL store the data somewhere	Conformant applications SHALL store the data in some way.	CombinedObligations, SHALL, persist			testableByHuman
3	SHALL:persist:exactly	SHALL store the data somewhere, but exactly as is sent	Conformant applications SHALL store the data in a way that the originally data from the instance can be reestablished.	CombinedObligations, SHALL, persist, exactly			testableByHuman
2	SHOULD:(persist)in-database	SHOULD store the data in a database	Conformant applications are asked to store the data in a database.	CombinedObligations, SHOULD, persist, in-database
2	SHALLNOT:populate:more-details	SHALL NOT populate more data than is specified	Conformant applications SHALL NOT populatae more data than is specified. The specification is closed.	CombinedObligations, SHALLNOT, populate, more-details, creator	true		testableByMachine
2	SHALLNOT:populate:missing	SHALL NOT populate info about missing data, ie. data absent reasons	Conformant applications SHALL NOT populate a reason for missing information.	CombinedObligations, SHALLNOT, populate, missing, creator	true
2	MAY:populate:more-structure	MAY populate the data in more structured way	Conformant applications are allowed to populate the data with more structure. For example, to split an address line into streetname and house number.	CombinedObligations, MAY, populate, more-structure
2	SHALLNOT:follow-up:truncate	SHALL NOT truncate data	Conformant applications SHALL NOT cut off data.	CombinedObligations, SHALLNOT, follow-up, truncate, consumer	true		testableByHuman
2	MAY:modify	MAY modify the data	Conformant applications MAY, i.e. are allowed to modify the data.	CombinedObligations, MAY, modify				nice hint
2	MAY:print	MAY print data	Conformant applications MAY print the data.	CombinedObligations, MAY, print
2	SHOULD:print	SHOULD print data	Conformant applications SHOULD print the data.	CombinedObligations, SHOULD, print
2	SHALL:print	SHALL print data	Conformant applications SHALL print the data.	CombinedObligations, SHALL, print, consumer			testableByHuman
1	SHALLNOT:(populate):in-narrative	SHALL NOT add to narrative	Conformant applications SHALL NOT add this data to the narrative.	CombinedObligations, SHALLNOT, populate, into-narrative, creator			testableByHuman
1	MAY:process	MAY process the data	Conformant applications MAY process the data somehow.	CombinedObligations, MAY, process				There is no further specification in which way the data can be processed.
1	SHOULD:process	SHOULD process the data	Conformant applications SHOULD process the data in some meaningful way.	CombinedObligations, MAY:process
1	SHALL:process	SHALL process the data	Conformant applications SHALL process the data in some meaningful way.	CombinedObligations, SHOULD:process
1	SHOULDNOT:process	SHOULD NOT process the data	Conformant applications SHOULD NOT process the data in some meaningful way.	CombinedObligations, SHOULDNOT, process
1	SHALLNOT:process	SHALL NOT process the data	Conformant applications SHALL NOT process the data in some meaningful way.	SHOULDNOT:process, SHALLNOT, process
1	SHOULD:document	SHOULD document how the data is used	Conformant applications SHOULD document the way the data is used in some (meaningful) way.	CombinedObligations, SHOULD, document
1	SHALL:document	SHALL document how the data is used	Conformant applications SHALL document the way the data is used in some (meaningful) way.	SHOULD:document, SHALL, document
1	SHOULD:display	SHOULD display the data	Conformant applications SHOULD display the data in some meaningful way.	CombinedObligations, SHOULD, display
1	SHALL:display	SHALL display the data	Conformant applications SHALL display the data in some meaningful way.	CombinedObligations, SHOULD:display
1	SHOULDNOT:modify	SHOULD NOT modify the data	Conformant applications SHOULD NOT modiify the data in any way.	CombinedObligations, SHOULDNOT, modify
1	SHALLNOT:modify	SHALL NOT modify the data	Conformant applications SHALL NOT modiify the data in any way.	CombinedObligations, SHALLNOT, modify
1	MAYNOT:process	MAY NOT process data	Conformant applications MAY NOT process data, aka of ignoring.	CombinedObligations, MAYNOT, process				this is equivalent to MAY:ignore.
1	SHOULD:reject-invalid	SHOULD reject invalid data	Conformant applications SHOULD reject invalid data.	CombinedObligations, SHOULD, reject-invalid
1	SHALL:reject-invalid	SHALL reject invalid data	Conformant applications SHALL reject invalid data.	CombinedObligations, SHALL, reject-invalid
1	SHOULD:accept-invalid	SHOULD accept invalid data	Conformant applications SHOULD accept invalid data.	CombinedObligations, SHOULD, accept-invalid
1	SHALL:accept-invalid	SHALL accept invalid data	Conformant applications SHALL accept invalid data.	CombinedObligations, SHALL, accept-invalid
1	SHOULD:receive	SHOULD be able to receive the data	Conformant applications SHOULD be able to receive the data.	CombinedObligations, SHOULD, receive
1	SHALL:receive	SHALL be able to receive the data	Conformant applications SHALL be able to receive the data.	CombinedObligations, SHALL, receive
1	SHOULDNOT:error	SHOULD NOT return an error to the sender of the data	Conformant applications SHOULD NOT reurn an erorr to the sender of the data.	CombinedObligations, SHOULDNOT, error
1	SHALLNOT:error	SHALL NOT return an error to the sender of the data	Conformant applications SHALL NOT reurn an erorr to the sender of the data.	CombinedObligations, SHALLNOT, error
1	ForeignStandards	concept codes from other standards	Other standards use specific terms for optionality/usage that should be conceptualized here.	CombinedObligations		true
1	v2	v2 concept codes	optionality/usage codes from v2	ForeignStandards		true
2	v2-r	v2: R	required in v2.x	v2, SHALL, populate				minCard = 1
2	v2-re	v2: RE	required but may be empty in v2.x	v2, SHALL, populate				minCard = 0
2	v2-x	v2: X	forbidden in v2	v2, SHOULDNOT, populate, process
2	v2-b	v2: B	backwards use in v2 only	v2, SHOULDNOT
2	v2-w	v2: W	withdrawn use in v2 only	v2, SHOULDNOT, populate, process
1	v3	V3 concept codes	optionality/usage codes from V3/CDA	ForeignStandards		true
2	v3-m	v3: M	mandatory in HL7 V3	v3, SHALL, populate, exactly, SHALLNOT:populate:missing				A value must be present and null-flavors are not allowed; to be combined with minCard = 1
2	v3-r	v3: R	required in HL7 V3	v3, SHALL, populate, MAY:populate:missing				A value must be present but it can be a null-flavors
2	v3-x	v3: X	forbidden in HL7 V3	v3, SHALLNOT, populate
1	ihe	IHE concept codes	optionality/usage codes from IHE	ForeignStandards		true
2	ihe-r	IHE: R	required in IHE v2.x specs	ihe
2	ihe-r2	IHE: R2	R2 in IHE v2.x specs	ihe, SHALL:process, SHOULD:populate				This is interpreted as the receiver has to support it, but when becoming the sender it is not really necessary to return it again
2	ihe-x	IHE: X	X in IHE v2.x specs	ihe				forbidden?
1	xDT	German xDT standards	The German xDT standard family has a very specific set of codes and is just presented here for completeness and demonstration purposes	ForeignStandards		true		all concept codes are to processed by the receiver; different requirements for sender
2	xDT-M	xDT: M	MUSS in xDT (unbedingtes Mussfeld)	xDT, SHALL, SHALL:process, SHALL:populate				minCard=1
2	xDT-m	xDT: m	muss in xDT (bedingtes Mussfeld)	xDT, SHALL, SHALL:process, SHALL:populate				depends on the value of another field
2	xDT-K	xDT: K	KANN in xDT (unbedingts KANNfeld)	xDT, SHALL, SHALL:process, SHALL:populate
2	xDT-k	xDT: k	kann in xDT (bedingtes Kannfeld)	xDT, SHALL, SHALL:process, SHALL:populate				depends on the value of another field

Notes:

Please consider that the hierarchy levels are only introduced for convenience when reading the codesystem. It can be used to identify the primary axes. In total it is in principle a poly-hierarchy that is established using the parent relationship, thereby introducing multiple parents from the different axes, each starting with level 1.

There are several topics open for discussion. Those are indicated in the comments.

Any other issues?

Examples / Explanations / Comments

Some examples may help to understand how this codesystem is to be used. In general, only values below the "green concept" in the mindmap in the introduction can be instantiated. All others are for definitional purposes.

The following table may help to understand some examples and common use cases:

Code	Explanation
SHALL:populate	The system SHALL be capable of providing data for the instance and populating this element accordingly.
SHOULD:send	In double contrast to the previous code, the system is neither required to do something in general, nor especially to create the instance. It is asked for sending the data instance. It is common or good practice, in other words there is some incidence to implement it, but a vendor can also decide not to do so.
.:populate:.	Does not denote that the created artifact has to be sent over the wire. Instead, the creation itself is indicated.
.:missing	The system can use information why requested details are missing. This is aka of null-flavor or data-abstent-reason.

Combining Elements

Another outstanding question is the combination of elements like "either A or B must …". Can this be solved with invariants? Or are other type of constructs necessary?