Issue 14131: We must state that a hold on record attributes must disallow changes or updates of any sort. (rms-ftf) Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com) Nature: Uncategorized Issue Severity: Summary: We must state that a hold on record attributes must disallow changes or updates of any sort, or enumerate the specific changes that are allowed, if any. [JRMS Remaining Issue] Resolution: Revised Text: Actions taken: July 28, 2009: received issue Discussion: End of Annotations:===== s is issue # 14131 We must state that a hold on record attributes must disallow changes or updates of any sort. We must state that a hold on record attributes must disallow changes or updates of any sort, or enumerate the specific changes that are allowed, if any. From: "PrescottD" To: "'RMS-FTF@omg.org'" Subject: Issue 14131 Date: Sat, 6 Mar 2010 13:39:51 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-03-06_02:2010-02-06,2010-03-05,2010-03-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003060180 "We must state that a hold on record attributes must disallow changes or updates of any sort. " From the document: : Maybe this needs to be explicitly stated that all attributes cannot be overwritten or deleted, but can be updated with a more current one, this would include .incorrect information. or some such that indicates the previous information was improperly assigned to a particular attribute . of course I would do that and use annotation to describe what was going on and why the attribute was updated to reflect incorrect information was entered, of course there would be an authority with this annotation. COMMENT on my comment. Maybe the resolution here is that a hold order (from any legitimate authority) freezes the record and all its management attributes at that time. The outcome or objective of what I am going to type is that of staying away from making huge repositories of copies. That is, this would allow for you not have to do that but wouldn't preclude you from doing. it. RECOMMENDATION. If somehow the managed record could have some type of something-or-other that would allow the managed record (case file) to be continued to be managed but that you could present the record as it existed at the time of the hold order this is what needs to happen. This would require over-riding business rules that allowed for the deletion of annotations, since the chronicled ones aren't affected because those data are kept. Other information currently in the document that I believe I address above. The other statement is that only those attributes explicitly designated by the organizations rules that apply to annotations can be allowed to not have a history for the annotation of the managed record. All other attributes if populated, must be maintained. Add: Case File Parts are either history kept or not according to the policy by the organization that creates, maintains and manages a case file. See ISSUE 12 for Use Cases for Case files. [JRMS Remaining Issue]