RPS: Life Cycle & Object State Transitions

1. Background

The background material for this topic can be found in section 1 or Life Cycle And Object State Transitions In RPS v2.

2. Life Cycle Questions For RPS

(a) RPS Document Objects

We seem to have been operating as though the state machine for medical records documents should apply to our classes of type document:

The definitions established for Medical Records and CDA apply to records for individual patients and thus have an essentially linear life cycle, with single document objects evolving through their defined states and occasionally being replaced by a new version. Once a document object under these rules has been replaced (made obsolete) it is considered unavailable except for historical or auditing purposes, therefore any attempt to reuse the document should be considered an error.

Reuse is important to RPS but not to Medical Records, where in fact it would be considered inappropriate.

The Medical Records domain model does not explicitly mention hierarchically structured or compound documents, and the CDA document model specifies recursively defined sections as components of individual documents, but does not discuss the possibility of recursively nested documents, as we have defined in the current RPS model.

RPS documents are obviously not the same as Medical Records or CDA documents, so we are not obliged to follow the same life cycle rules; however, if we are not adopting the MR domain rules in their entirety, we need to specify our rules unambiguously.

Under the document construct as now defined in RPS, all versions of a given document are members of the same set (as defined by set id). A new version in the set will be submitted for the following reasons, individually or in any combination;

• The content of the document object has changed; in the case of a simple document, if a new version of the associated file has been submitted, and in the case of a compound document, if a component (anywhere in the document tree) has been added, dropped or itself updated to a new version.
• An attribute of the document object (e.g. title or code) or of any component object thereof has changed; or,
• One or more keywords associated with the document object or any of its component objects has been added, changed or dropped.

There is also a special case in which a document object is appended to an existing document object. In this case a new document, with a different set id, is associated on submission with an existing document.

Questions for RPS:

(1) Does the MR/CDA document state machine represent what we need/want in RPS?

(2) Do we need/want to explicitly record that one version of a document in a set replaces its predecessor and change the state of the predecessor to “obsolete” as required by the MR/CDA rules?

One case of interest that occurs to me is that of a sequence of labeling documents in one set. Suppose labeling document version N is sent in for review, replacing N-1 which is then made “obsolete”. My reading of the MR/CDA rules is that an obsolete document cannot participate in a new association, though existing associations appear to stand unless explicitly changed. Now suppose that document N-1 was the last approved labeling, and N is the candidate labeling for approval. If we accept the MR/CDA rules the change of state applied to N-1 rendering it obsolete prevents a new reference to the latest version of approved labeling after an update has been submitted. We could ignore that aspect of the rules, but what is the point of recording the change of state if it has no effect?

The case may sound a bit contrived, after all, we could have different compound documents for the same content, representing different regulatory statuses; however, there may be other cases where new references need to be made to documents that have technically be made obsolete.

(3) Does the change of state on a compound document affect the states of its components?

(4) I assume that a document, once submitted, can be withdrawn by the submitter. If a document is submitted in the active state, withdrawal would involve nullifying its state. At this time I see nothing in the model that would do this by reference, so a copy of the document object (i.e. having the same id value) would have to be submitted with the code “obsolete”. However, under MR/CDA rules the document would not be deleted (under MR/CDA rules document objects can be created but not destroyed). Do we need to provide a means for a submitter to retract a document such that it is deleted from the receiver's system?

(5) Do we actually need an append relationship between documents?

If we have one file represented by document A, and a new file to be appended to A, represented as document B, why not simply create a new compound document C, that includes A and B as components, and replace references to A with references to C. The tools will show the viewer that the document now filed where A was filed consists of A and B; do they need to be shown explicitly that B was appended to A?

(6) Since the sequence of versions within a set of document objects (as defined by set id), each associated with a sequence number identifying its place in the temporal evolution of a submission (or reviewable unit) provides a complete record of the history of the set do we need to explicitly make prior versions obsolete or otherwise record a specific relationship between instances for such a linear life cycle?

(7) Do we need to provide any mechanism to record branching and merging life cycles? The MR/CDA rules provide for excerpt and transformation relationships between a new document (new set, new version number) and an existing document, but do not provide for derivation relationships, or explicit split or merge relationships.

Labeling is an interesting case because in the case of a Prior Approval Supplement a labeling document will ‘branch off’ (i.e. be derived from) the latest approved labeling at the time the submission begins its life. After perhaps several versions of the labeling document within a submission, its content will merge with the then latest version of approved labeling to create a new version of approved labeling. This gets even more complicated in the case of two parallel PAS submissions. Each branch would no doubt be started as a new document set, but at present there is no means in the model to indicate the specific document from which the ne document was derived. Do we need this? Similarly the version sequence of approved labeling is likely to be independent of the life of the branches which merge back into it, but again there is no way at present of showing that one document was made by merging the logical content of two or more other documents.

(b) RPS CoU Object

RPS CoU objects are of type document. Now that we can express the life cycle of content objects in rps document objects, life cycle of the CoU object can probably be made simpler.

Once a CoU object has been submitted, it remains in effect until a new version in its set is submitted . A new version in the set will be submitted for the following reasons, individually or in any combination:

• There is a new version of the document associated with the CoU, or a new document replacing the one previously filed under the code (perhaps in error);
• The CoU code is changed (i.e. the document was filed in the wrong place); or,
• One or more keywords associated with the CoU object has been added, changed or dropped.

When a document is to be removed completely, not replaced or filed under a different code, (i.e. the set is being terminated) a new version of the CoU could be submitted to reflect this or the state of the last version in the set could be changed; see (2) below.

Questions for RPS:

(1) Since we can express an append relationship at the document level, do we need to also allow appends at the CoU level?

If we do not allow appends, then a CoU object is never referenced by any other object, except for the next version in its set if we choose to do that.

(2) Since the sequence of versions within a set of CoU objects (as defined by set id), each associated with a sequence number identifying its place in the temporal evolution of a submission (or reviewable unit) provides a complete record of the history of the set do we need to explicitly make prior versions obsolete, or otherwise record a specific relationship between instances?

We could leave each CoU object in a set in an explicit or implicit active state permanently, but how do we indicate that the set has been terminated (perhaps only temporarily)? We could submit a copy of the latest version (with the same id) with the status explicitly set to obsolete, or we could submit a new version with no code and no associated document to indicate termination. If we use the latte then there is no need to have a status code on CoU.

(c) RPS Submission Subdivision Classes

Those RPS classes that represent the administrative divisions and subdivisions of regulatory submissions may also have life cycles.

Questions for RPS:

(1) What states need to be recorded for the submission unit, which is of type act? Objects of this class appear to have a very simple life cycle, being submitted in the “active” state and never taking on a meaningful new state unless withdrawn by its submitter, in which case its state should will become “nullified”.

(2) When a submission unit is nullified are all its contents and the updates attendant thereon also nullified?

(3) Can a submission, reviewable unit or application be withdrawn by the submitter? If so, under what conditions and with what results?

(4) How is regulatory state (status) related to object state (status) for submission, reviewable unit or application, if at all? (The states, transitions and state machine applicable to these classes are those of the act class.)

There are several alternative answers to this question;

• Map regulatory states and transitions to the act states and transitions. The regulator would set the appropriate status in a copy of the object and return it with a submission unit.

• Limit the states of these classes to “new”, “active”, “nullified” and “completed” to be set according to the definitions for act, and leave the explicit regulatory status to be conveyed by the regulator in a submission unit in some other manner, such as in a document or in a separate regulatory status object (to be defined).

• Limit the states of these classes to “new”, “active”, “nullified” or “completed” and use the document class completion code to carry the regulator’s specific status indication drawn from a controlled vocabulary representing the states and terminology meaningful for the type of submission/application and regulatory realm. Again, except for nullified, the state and completion code would be set by the regulator and communicated in a copy of the object sent in a submission unit.

Note that the status “new” might be a better way than mood code for a submitter to indicate that an application (or submission or reviewable unit) is provisional and does not yet carry a regulator assigned id. When the number is assigned, the object can then become “active”.

(d) Other RPS Classes To Which Life Cycles May Apply

The following other RPS classes have or may need life cycle management:

• keyword definition,
• application reference,
• review procedure,
• submission group,
• mode,
• review,
• manufactured product,
• product,
• dedicated service location,
• product category,
• territorial authority.

These also need to be defined, but can wait until we have the rest done.

The life cycle of the use a keyword on a CoU or document object can only be recorded by a supplying a new version of the CoU or document object with its full complement of keywords because the keyword class does not carry an id to identify an instance of itself; its id always refers to a keyword definition. A similar condition applies to application reference as it is now defined.