View source for RPS: Life Cycle & Object State Transitions

'''1. Background'''

The background material for this topic can be found in section 1 of  [[Media:Life_Cycle_And_State_Transitions_in_RPS_v2.doc]]

Section 2 below was originally copied here from this document so that members of the working group may add comments, proposed answers to the questions and raise new questions related to the topic.

  * Section 2 has been updated to include the decisions made in the WG teleconference of 12 April.
    These updates are shown in the same format as this item.
    
    We only finished sections 2(a) and 2(b); (c) and (d) remain to be addressed. 

'''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?  

    It was agreed that a document object in RPS will use a simplified version of the MR/CDA
    document state machine, comprising only the states ACTIVE, NULLIFIED, OBSOLETE.
    
    A document object is created (initially submitted) in the ACTIVE state and remains so 
    until either:
    
    (a) it is 'deleted' as an error by the submission of a copy of the specific object    
        (i.e. with the same id value) and a status code of NULLIFIED; 
    or
    (b) it is 'replaced' by the submission of a new document object in the same set 
        (i.e. with the same set id value and a higher version number) that points 
        to the prior document object using its id value in the Related Document 
        attached by a sequel  to relationship of type 'replace'.
     
    If neither (a) nor (b) occurs, the document object remains ACTIVE in perpetuity.


(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.

    Members were agreed that the a document object should be made OBSOLETE when a new
    version (in the same set) was submitted, and that this should be done explicitly 
    using the repacement relationship between the new version and its predecesssor.
    
    Once made OBSOLETE a document object cannot be referenced by a compound document or
    CoU object submitted later; that would be an error.
    
    When a document object is made OBSOLETE other documents and CoU's with which it is 
    associated would usually need to be updated also.  However, since one document object 
    can be associated with multiple Cou objects (i.e. filed in multiple locations) care 
    must be taken to ensure that a new document is a replacement in ALL contexts of use.
    
    For example, a document D0 relating to manufacturing processes might be filed under 
    two different manufacturers Q and R (i.e. D0 would be associated with two different 
    CoU objects, CQ and CR, each version 1 in a different set). If the manufacturing 
    process changed at R but not at Q, the document D0 would NOT be replaced, sbut rather
    a new document DR would be created (as version 1 in a new set, not in the same set as 
    D0. DR would be submitted along with an updated CoU CR (version 2 in the same set, 
    replacing version 1).  Document D0 would remain active, as would CoU CQ. 
     
    It is expected that RPS management tools will provide their users with a 'used in' list
    showing the associated contexts of use for any document object (i.e. specific version).


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

    The rule agreed here is straight-forward: changes to a simple document affect that document
    and any documents of which it is a component (i.e. changes propagate up a compound document 
    structure tree) but a change to a compound document does not affect its components (i.e.
    changes do not propagate down a compound document structure tree). 


(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? 


   The regulators require that once a document is submitted its existence (i.e. its content)
   remains, though a submitter may be able to virtually 'delete' it from use by changing its 
   state to NULLIFIED.
   
   RPS will NOT provide a mechanism for a submitter to physically delete submitted content.

(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?

    It was agreed that the APPEND relationship between documents would not be supported.
    
    The functional equivalent in RPS is the following, given the need to append 
    information to and existing document:
    (i)   document object A already exists referencing file X
    (ii)  submit new document object B referencing file Y (the 'appendage')
    (iii) submit new document object C referencing component documents A and B
    (iv)  submit new CoU objects as required to replace association with document A 
          by association with document C.
     
    The viewing tools are expected to show the viewer the difference in the associated
    documents from a CoU derived from document A and its successor derived from document C.
 
    This means that the only type value allowed on the sequel to relationship between
    document objects is 'replace'.


(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?  

     No implied state changes will be allowed; all state changes must be made explicitly.
     
     Therefore, each new version in a set of document objects MUST explicitly replace its
     predecessor.


(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. 


     No regulator saw any business reason to record and communicate in RPS information 
     about branching (derivation, merge or split)life cycle relationships among documents.
     
     Therefore no provision for this will be included in this release of the standard.
 

'''''(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.

    No APPEND relationship will be allowed between CoU objects. 
    
    A CoU object will use a simplified version of the MR/CDA document state machine, 
    comprising only the states ACTIVE, NULLIFIED, OBSOLETE.
    
    A CoU object is created (initially submitted) in the ACTIVE state and remains so until either:
    
    (a) it is 'deleted' as an error by the submission of a copy of the specific object    
        (i.e. with the same id value) and a status code of NULLIFIED; 
    or
    (b) it is 'replaced' by the submission of a new CoU object in the same set 
        (i.e. with the same set id value and a higher version number) that points 
        to the prior CoU object using its id value in the Related CoU attached 
        by a sequel to relationship of type 'replace'.
  

(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.

     No implied state changes will be allowed; all state changes must be made explicitly.
     
     Therefore, each new version in a set of CoUs MUST explicitly replace its predecessor.


'''''(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.