ActRelationship priorityNumber and other sequencing

NOTE: Harmonization proposal on public display here for the purpose of commenting and collaborative editing. All your edits are tracked and nothing gets lost. FEEL FREE to improve the proposal and to add any question you want to raise in the discussion. Thanks!

Recommendation for HL7 RIM Change	RECOMMENDATION ID:
Submitted by: Gunther Schadow	Revision (# and date): 2
Date submitted: 20050212	Committee status: open
Submitted by: Gunther Schadow
NAME: ActRelationship.priorityNumber (and other numbers)

Stewards Position

REQUIRED - This table should contain one row for each Steward Committee affected by the recommendation.

TC	RECOMMENDATION APPROVAL STATUS	AFFECTED ENTITIES OF INTEREST TO TC (responsibility level: S=Steward; I=Interested)
O&O	Unknown	I
RCRIM	Unknown	I
PC	Unknown	I

Issue

It is impossible to interpolate a new act-relationship with a different priorityNumber without requiring renumbering of all other relationships in that group.

Current State

Currently priorityNumbers is an INT.

Recommendation(s)

Change ActRelationship.priorityNumber to REAL

Rationale

Allows insertion of acts, reordering of priorities without requiring renumbering all the relationships. Priority numbers are often considered fractional, for example, in XSLT they are real numbers, and it is very useful.

Alternatives/Workarounds Considered

Currently workaround is to assign priorityNumbers in larger increments (e.g., 1000) which should leave enough room for insertions, but that would not represent the intent of priorityNumbers.

Discussion

May need to revise definition of priorityNumber and sequenceNumber to clarify the meaning and use of either. According to this proposal, sequenceNumber would stay INT

As long as there isn't a strong use case of "inserting" something with an existing sequence without sending the entire list of things in the sequence, sequenceNumber would have to stay INT IMHO. Suggest that clarifying wording to differentiate the usage of priorityNumber and sequenceNumber be added to this proposal (i.e. to its recommendations, not just as part of the discussion) Rene spronk 01:25, 17 Feb 2006 (CST)

Agree that sequenceNumber would stay INT. Gunther Schadow

In the discussion we have created some background and guidelines for the possible clarification of both the priorityNumber and the sequenceNumber attributes.

SequenceNumber orders the actions, the labor, the things that are done, describing in which order they are done. Notably, two relationships can have the same sequenceNumber which has a very specific meaning, i.e., that the two actions could be carried out in either order or in parallel (concurrently.)

PriorityNumber on the other hand specifies in which order the relationships are being considered, looked at, etc. So, those orderings that are display-oriented and that can be re-ordered after the fact should be considered priorities, while those that are fixed by how the acts were done should be sequences.

These attributes have been specifically defined for constructing workflow plans. In that case, the elationships are component relationships and the sequenceNumber tells the sequencing of the workflow plan steps. If two steps have the same sequence number, they are unordered, concurrent. Priority is for priority of consideration in the group of the same sequence numbers or priority of consideration if sequenceNumbers aren't there. PriorityNumber is also used on conditional relationships to suggest in which order conditions might be evaluated.

relationship type	sequence number	priority number
component	order of steps to perform (!)	order of steps of same sequence number to look at or consider
precondition	N/A	order of preconditions to consider
occurrence of	sequence number of the instance in the group of instances spawned from the repeating target act	?

There may not be too many more use cases for these ordering attributes. But think we need something like this table to get a sense of what we really need.

To me it seems that when we talk about display order, order of consideration, any order that is not given by the physical events but by the arguably best ordering of presenting or considering things should be the priority number.

For instance, if you have sections in a document, you may start writing: abstract, methods, results, conclusion then introduction. But it's presented as abstract, introduction, methods, results, discussion, conclusion. Hardly anyone would consider the order of *writing* of the sections anything to be captured. Instead we capture the order of display. That would be priorityNumber.

I am hesitant to make sequenceNumber REAL because the absolute equality of the sequenceNumber of two steps is relevant, and with REALs and equality it's a bit of a problem. Also, I don't think you can go a half step. But you can fine-tune priority. Priority is relative only. Steps can be considered absolute such that 1 - 3 - 4 would actually mean, that there is a step 2 which you are not talking about.

Recommended Action Items

• Implement the proposed solution

Resolution

The change was approved, but required an updated definitions too. Which is presented here, and has not been voted on.

Update Definition of ActRelationship.priorityNumber

Old Definition

Definition: An integer specifying the relative preference for considering this relationship before other like-typed relationships having the same source Act. Relationships with lower priorityNumber values are considered before and above those with higher values.

Examples: For multiple criteria specifies which criteria are considered before others. For components with the same sequence number, specifies which ones are considered before others. Among alternatives or options that are being chosen by humans, the priorityNumber specifies preference.

Discussion: The ordering may be a total ordering in which all priority numbers are unique or a partial ordering, which assigns the same priority to more than one relationship.

New Definition

Definition: A number specifying the relative preference for considering this relationship before other like-typed relationships having the same source Act. Relationships with lower priorityNumber values are considered before and above those with higher values.

Examples: For multiple criteria specifies which criteria are considered before others. For components with the same sequence number, specifies which ones are considered before others. Among alternatives or options that are being chosen by humans, the priorityNumber specifies preference.

Discussion: The ordering may be a total ordering in which all priority numbers are unique or a partial ordering, which assigns the same priority to more than one relationship. In contrast with the sequenceNumber, the priorityNumber specifies the order for considering, displaying, etc, whereas the sequenceNumber specifies explicitly the order of performance of the related Act.

Update Definition of ActRelationship.sequenceNumber

Old Definition

Definition: An integer specifying the relative sequential or temporal ordering of this relationship among other like-types relationships having the same source Act.

Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Multiple components with the same sequenceNumber make a branch. Branches can be exclusive (case-switch) or can indicate parallel processes indicated by the splitCode.

If value is null, the relative position of the target Act is unspecified. (i.e. it may occur anywhere.)

Use the 'priorityNumber' attribute to indicate relative preference instead of order of occurrence.

New Definition

Definition: An integer specifying the relative sequential or temporal ordering of this relationship among other like-types relationships having the same source Act.

Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Multiple components with the same sequenceNumber make a branch. Branches can be exclusive (case-switch) or can indicate parallel processes indicated by the splitCode.

If value is null, the relative position of the target Act is unspecified. (i.e. it may occur anywhere.)

Use the 'priorityNumber' attribute to indicate relative preference, order of consideration or display instead of order of occurrence performance of the Acts..