.. _rmdc-proc: Records and Document Management Procedure ========================================= This procedure governs the creation, intake, maintenance, authorization, distribution, and retention of :term:`Records ` and :term:`Documents `. Purpose ------- Systematic management of Records and Documents helps teams execute large, long-term, and complex projects in a coordinated fashion. Furthermore, management of quality-related documents is required by regulations. This procedure implements the following requirements: .. impl:: Define processes for lifetime records :links: R_GDC_01_04 .. impl:: Define processes for Document Control :links: R_APPB_45 .. impl:: Define processes for Quality Records :links: R_APPB_79 Roles ----- Roles involved in this procedure include: Originator Person who authors a new or revised document Reviewer Person who is assigned to review a submitted document, checking for quality and content Approver Person in the releasing organization who is authorized to mark a document as Approved, thereby enabling its use across the project. Manager Person in any organization who is authorized to request document reservations RMDC Staff Person responsible for receiving documents and administering :term:`RMDC` IT systems such as the :term:`EDMS` Staff Person in any organization who is authorized to access or submit project documents/records Procedure --------- .. _rmdc-access: Accessing a document/record ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Internal project staff shall follow these steps when seeking documents or records to perform project work. * **Staff** navigates to the project :term:`EDMS` as defined in :ref:`rmdc-systems` * **Staff** searches EDMS for desired document/record by number, title, and/or other fields * **Staff** checks ``status`` field and ensures they choose a revision that is approved for their current work task (generally this requires an APPROVED status). * **Staff** checks the ``usage`` field and ensures to choose a revision with a usage marking that is appropriate for their current work task. * **Staff** accesses the file(s) via the EDMS download or access feature * If an expected Document/Record cannot be found, appears to have erroneous data, or is not accessible, **Staff** contacts **RMDC Staff** for assistance .. _rmdc-origination: Originating a new document/record ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ New records and new or revised documents are originated as invoked by other procedures and processes, or by third parties. The following steps shall be taken whenever a new document or record or document reservation is requested, created, or received: * **Staff** shall specify document data defining the new record/document in accordance with the content rules listed in :py:class:`nrsk.models.Document` * Required: * Title --- a single-line description of what the record/document is * Record/document type --- This determines template, review, and retention rules. Should be from :ref:`rmdc-doctypes` * Originating organization --- the organization or group assigned primary authorship. Internally-generated records/documents shall be contained on the :ref:`org-chart`, while others should be the name and department of external entities. * Optional * Keywords --- words or phrases to assist in future searches/lookups .. impl:: Require document index to be updated upon origination of any new document or record :links: R_APPB_83 Updating the index at the point of creation is a robust way to ensure compliance that each document/record will always be discoverable and retrievable. Intake ^^^^^^ Upon receipt of Document/Records from an external party, the following process shall occur: * **Receiver** determines whether the Document/Record is eligible for entry into the Document Index. * **Receiver** inspects Document Index to ensure consistency with the Index and the received Document * If the received document/record is not already listed in the Document Index, then **Receiver** takes on the role of **Originator** and follows the process in :ref:`rmdc-origination`. * If the data is incorrect or outdated, **Receiver** updates the data * **Receiver** uploads the received file(s) to the EDMS. * **Receiver** updates metadata in the Document Index, including the latest revision number, authors, received date, and location/URL in the EDMS * **Receiver** assigns acceptance review task to appropriate person based on the work breakdown structure that the document was produced under. * **Reviewer** views Document Index and downloads file(s) as listed * **Reviewer** inspects files and performs acceptance review as appropriate, potentially generating a Review Record * **Reviewer** updates Document Index acceptance metadata field according to review * If the document/records are not accepted, **Reviewer** informs originating institution of deficiencies and requests update Document/Record data management ------------------------------- .. _rmdc-doctypes: Record/Document Types ^^^^^^^^^^^^^^^^^^^^^ One of the following record/document types should be assigned to each record/document. The types are generally associated with specific forms or templates that include the expected content/sections, and are often created to satisfy the needs of a lower-level procedure. .. impl:: Define numerous Record/Document types There is a timeless debate about having too many vs. too few doc types. Additional types are added to support more mature procedure sets, but then people start to struggle to know what type they should use, leading to cleanup efforts, followed by management declarations to reduce the number of types. A good solution to this problem is to be very explicit in your procedural culture. Ensure that whenever a record or document is being originated, that each staff member has the relevant procedure open and is following it precisely. Ensure that the procedures are rigorous and precise about which record/document types should be generated in each scenario. When a procedure is written, ensure that any new record/document types are added to the list of known types. .. warning:: Don't make one rec/doc type for each individual checklist or form in each procedure though. Those can all be forms. Or maybe do make them all form subtypes? Could be nice to really have specific evidence. Need easy way to make auto-generated forms per procedure then. .. datatemplate:yaml:: :source: /_data/doc-types.yaml {{ make_list_table_from_mappings( [('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use_cases'), ('Record', 'record'), ('Retention', 'retention')], data, title='Record/Document types', ) }} Document Numbering ^^^^^^^^^^^^^^^^^^ Document numbers (or IDs) are human-usable codes that uniquely identify the document/record for purposes of cross-referencing and discussion. All projects may use |inst| corporate-level document numbering as appropriate in addition to the project-specific policies. Corporate number shall For corporate-level documents/records not associated with any specific project or system, the document numbers shall be of the form: ``AMS-{type}-00000``, where {type} is the document type abbreviation in all CAPS, and the number starts at 00001 and increments from there. When 100,000 or more numbers are needed, the number continues increasing. For project-level documents/records not associated with any specific system, numbers shall be of the same form, but with ``{AMS}}`` replaced with the project abbreviation, e.g. ``TTP``. Documents/records associated with a specific project and system shall have document numbers of the form: ``{proj}-{sys}-{type}-00000`` where `{sys}` is the system abbreviation in all CAPS. Active projects and their abbreviations may be found in :ref:`projects`. .. _rmdc-doc-status: Document Statuses ^^^^^^^^^^^^^^^^^ Document Status indicates where a document or record is in its lifecycle, and determines if and how it may be used in design or operation. Statuses fall into three top-level categories. These statuses are derived from :cite:p:`cloverDocumentControlRecords2010`. .. autoclass:: nrsk.models.Document.STATUS :no-index: :no-members: * **Not Yet Approved** --- The following statuses apply to Documents that generally shall not be used to support plant design or operations: .. autoattribute:: nrsk.models.Document.STATUS.RESERVED :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.IN_PROGRESS :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.IN_REVIEW :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.REJECTED :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.REFERENCE :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.NATIVE :no-index: :no-value: * **Approved** --- The following statuses apply to active documents that allow plant design or operations: .. autoattribute:: nrsk.models.Document.STATUS.APPROVED :no-index: :no-value: * **No Longer Approved** --- The following statuses apply to documents that are no longer approved for use other than reference: .. autoattribute:: nrsk.models.Document.STATUS.QUARANTINED :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.SUPERSEDED :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.REVISED :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.VOIDED :no-index: :no-value: .. autoattribute:: nrsk.models.Document.STATUS.CLOSED :no-index: :no-value: .. note:: These statuses are validated in the data dictionary in :py:class:`~nrsk.models.Document` .. _rmdc-systems: Document/Record Management Systems ---------------------------------- Documents and records are managed in the following systems. .. datatemplate:yaml:: :source: /_data/it-systems.yaml {{ make_list_table_from_mappings( [('Name', 'name'), ('Use case(s)', 'use_cases'), ('Location', 'location')], data['RMDC'], title='RMDC Systems', ) }} See Also --------