Meeting Minutes 12 April 2011

Notes from RPS WG Teleconference 5 April 2011

1. NOTES ON PREVIOUS MEETING

Jason pointed out that the third bulet in item 2 should be two bullets reading:

• Jason will draft the XML examples as part of the IG.

• Joe will reach out to EU representatives to see if we can get someone to contribte to a better description of the new EU requirements.

2. OUTSTANDING REVIEW ITEMS

Item 2.1, the document RPS: Life Cycle And State Transitions (posted on the wiki and distributed by email via the list server at 7:48 4 April) was discussed. The questions in sections 2(a) and 2(b) were resolved.

The decisions have been posted in line on the version posted on the wiki, but since that may be edited, they are reproduced below with question and decision but without editorial comment from the original:

From section 2(a) The RPS Document Object

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

[...]

  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) [...] 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?

[...]

  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.

[...]

   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.

From Section 2(b) RPS CoU Object

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

[...]

  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?

[...]

   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.

3. NEXT WEEK

Jason will prepare drafs of the revised state machine diagrams for discussion.