v2+ Details - Local Development build (v0.3.2). See the Directory of published versions

Conditions

How to handle conditions? What are conditions? What do they provide?

In v2.x the conditions are hidden in the explanatory text, i.e. the field description. Currently there is no separate way to make them explicitly visible. Therefore, they must be extracted manually. Conditions are simple statements that can be evaluated to true or false.

Therefore, conditions consist of three aspects:

• the condition (statement) itself, resulting in true/false
• the dependency on another element
• the desired behavior according to the result of the evaluation

The only aspect that can be converted directly into v2+ is to add a flag denoting that there is a condition: C. It would be good to have this statement also in a computable expression. But because it is hidden in normal text that is a manual process.

The dependency to another element is always easy to detect, whether it is in the same segment or to somewhere else in the message.

The statement itself can be evaluated into a true or false. But the question who has to evaluate this statement, and when it must be evaluated is unclear.

The problem with a correct interpretation of optionality/usage in v2.x respectively implement in v2+ is that implementers/developers can either consider something or not, but not both at the same time!

The thing with conditions is that there are some dependencies that have an impact on what can be expected. In the first example below, it should be expressed that an identifier must be provided for update mode. But how to express that correctly and completely?

Condition Expressions on the standard

Within the v2.x standard the following condition indications occur:

Indication	Explanation
C	common 1, the meaning is as “C(R/X)”
CE	common 2, the meaning is as “C(RE/X)”
C(a/b)	standard pattern, “a” and “b” to be replaced with one if the optionality flags
C(R/X)
C(RE/X)

C / CE

The standard only uses “C” and “CE”. Erronously this is taken or interpreted as C(a/b) is not allowed. However, this is really caused by the fact that the responsible workgroups did not react to the request to specify the real meaning of C respectivley CE. Intentionally, all occurrences should have been replaced by the correct pattern. For example, C(R/O) or C(X/O) could have been reasonable combinations as well.

The default explanation according to the standard itself is:

• C = C(R/X)
• CE = C(RE/X)

Consequently, in case of false the value is not allowed. But there are some good reasons not to be so strict. In other words, why forbidding an element?

C(R/X)

This is the first common interpretation. In the true case, a value must be provided, otherwise it is prohibited.

This construct results from the early days where an appropriate understanding wasn’t established or developed. The original intent was to make an element required/present if the condition is true. No one has ever deeply thought about what should happen in the false case, nor to really prohibit an element. It can be assumed that a present data would also add some value.

C(RE/X)

This is the second common interpretation, where a value must be provided if known.

In principle, the same comments like before apply.

Example 1: Action Code

Let’s try to examine some examples. The first snippet provides some relevant fields for a segment that can repeat and that will contain data in update or snapshot mode. Therefore it will either provide all data that is valid at a certain point in time, or just the data that should be updated. In the latter case, an identifier referencing the wrong data must be provided.

The condition should enforce that the identifier is provided in case the action code does not equal “S” (snapshot).

In v2.x the attribute table would look like:

No.	Field	Optionality	Repetition	Explanation
1	Sequence Number	O
2	Action Code	R		values = { S, A, D, U, X }
3	Identifier	C
..	..	..	..

In this example snippet of a segment the action code is made required so that it will always be present. That repesents the intent, and it makes it easy to examine in which way this segment is used.

But how to express that in v2+ (condition: #2==”S” )? (Note: “MAY” for implement is the default and can be left out.) A rough first idea would introduce:

No.	Field	Implement	Cardinality	Explanation
1	Sequence Number		0..1
2	Action Code	SHALL	1..1	values = { S, A, D, U, X }
3	Identifier	MAY	T: 0..1
		SHALL	F: 1..1
..	..	..

(Note: This example does not consider correctly that some of the values for action code are mutually exclusive in the same message! That provides a hint already how it must be solved correctly.)

The problem is that a field cannot be implemented and not implemented at the same time! In addition, a guidance in form of “(not) implement” cannot be reduced anymore in derived profiles! Also, some remarks like “a fixed value does not represent an implementation” is not helpful because even then the sender has to fill it in, and the receiver has to evaluate in some way that it does not vary.

Consequently, a translation into v2+ base framework must be, i.e. leaving the implement indication empty (=MAY):

No.	Field	Implement	Cardinality	Explanation
1	Sequence Number		0..1
2	Action Code	SHALL	1..1	values = { S, A, D, U, X }
3	Identifier		T: 0..1
			F: 1..1
..	..	..	..

Within an implementation guide, that will be derived from this base specification, one can either further constrain it:

a) for snapshot mode only:

No.	Field	Implement	Cardinality	Explanation
1	Sequence Number		0..1
2	Action Code	SHALL	1..1	'’value = S’’
3	Identifier	MAY	0..1	use is up to the implementer
..	..	..	..

b) for update mode:

No.	Field	Implement	Cardinality	Explanation
1	Sequence Number		0..1
2	Action Code	SHALL	1..1	values = { A, D, U, X }
3	Identifier	SHALL	1..1	must be handled correctly
..	..	..	..

Example 2: RXA-9 Interpretation

The notion behind the specification in v2.x is: both elements must be implemented/supported and at least 1 note sent if TXA-20 is in {„CP“, „PA“}. Therefore, the condition should be expressed as C(R/O) in v2.x:

No	Data Element	Usage	Cardinality	Condition
9	Administration Notes	C(R/O)	0..*	TXA-20 is in {„CP“, „PA“}
20	Completion Status	RE	0..1

Therefore, the translation into v2+ is easy, because RXA-9 must be implmented. In the true case, there must be at least a single value. In the false case there can be any number of values:

No.	Data Element	Implement	Flag	Cardinality	Condition
9	Administration Notes	SHALL	C	T: 1..*	TXA-20 is in {„CP“, „PA“}
				F: 0..*
20	Completion Status	SHALL		0..1

Example 3: RXA-16 Substance Expiration Date

The definition of RXA-16 in the v2.5 LRI profile (US realm) seems to be incorrect and does not reflect the intent:

No	Data Element	Usage	Cardinality	Condition
16	Substance Expiration Date	C(RE/O)	0..1	if RXA-15 (lot number) is valued.

The intent is that the expiration date is provided if the lot number (RXA-15) is given. Therefore, the usage should be C(R/RE) or C(R/O).

There, the correct representation in v2.x should be:

No	Data Element	Usage	Cardinality	Condition
16	Substance Expiration Date	C(RE/O)	T: 1..1	if RXA-15 (lot number) is valued.
			F: 0..1

Translated into v2+:

No	Data Element	Implement	Flag	Cardinality	Condition
16	Substance Expiration Date	SHALL	C	T: 1..1	if RXA-15 (lot number) is valued.
				F: 0..1

Dependencies

Demonstrating dependencies within conditions makes it easier to decide how they should be handled:

All conditions occuring in a dependency do not make sense if they are not evaluated and handled correctly. This can only be achieved by implementing them: SHALL.

Resumee

There must be a clear indication whether a specific data element is to be implemented or not.