As long as the concepts espoused in the GC RMAP are represented in an electronic or hybrid records management environment, institutions are free to implement those concepts in whichever way that satisfies local requirements. Some points though are worth noting.
As stated previously, the GC RMAP is independent of implementation considerations related to applications, systems or technical platforms. But the functionality of an EDRMS can complement greatly the roll-out of the GC RMAP. Although the GC RMAP contains 50 elements, many can be auto-populated by an EDRMS. For example, the "From", "To", "Cc" and subject line of an email message can be captured automatically into the appropriate metadata elements without manual intervention by an end-user. Other metadata values, especially those related to retention and disposition, will be entered once by a Records Manager or other authorized official and will be "hidden" from the end-user. In essence, only a minor number of elements will require direct input from an end-user.
The GC RMAP is independent of implementation considerations related to applications, systems or technical platforms.
Similarly, an EDRMS can promote the use of linkages or inheritance to minimize user input and the writing of metadata to all levels of aggregation. Implementers must take into account however, the importance of persistent linkages if that route is taken. Information held outside an EDRMS (e.g. about an agent) but linked to an element within an EDRMS has the potential to be lost, especially if it needs to be retained for a considerable length of time. Implementers may wish to import such information into an EDRMS at which point it can either be written to the appropriate level of aggregation (i.e. record or file) or held in a separate database within the EDRMS that is linked to the record or file.
Some information, e.g. about an agent who has performed an action on a resource, must be logged as a "snapshot in time." If an implementer chooses to maintain links to information about an agent held either outside the EDRMS or within the EDRMS in a separate database, the information about the agent at any point in time must be kept in order to prove in what capacity the agent was acting when performing an action on a resource. Links to databases that are dynamic in nature and retain only current information about an agent do not satisfy the requirements of a management and event history log for the resource.