|Oracle E-Records Implementation Guide|
Part Number E13700-04
This chapter covers the following topics:
Organizations that want to maintain electronic documents must have systems that support the ability to electronically sign those documents, ensuring that the appropriate personnel have reviewed and approved them.
Good Manufacturing Practices (GMP) generally requires signatures on transactions which affect product quality. Companies can also require signatures when moving the custody of goods from one department to another, or when moving responsibility for manufacture from one department to another. So, wherever a signature is needed on a paper document, a signature is needed on the electronic document that replaces it. These electronic signatures or e-signatures can be done either through forms or through the online mode. A new feature, one-step e-signature, further simplifies the e-signature process in the online mode. This document addresses the enabling of electronic signatures in OPM for static (setup), as well as transaction data.
21CFR Part 11 describes the requirements for companies wanting to move from paper based record keeping to electronic record keeping. GMP describes where it is appropriate to keep electronic records and capture electronic signatures.
This document details all areas in OPM that GMP explicitly or implicitly states are important for capturing e-signatures and e-records. There are also events where data is captured that are industry standard, or dictated by other authorities (like the DEA) that are not mentioned by GMP.
Since electronic signatures are a legal and binding equivalent to handwritten signatures, it is important to review the data you are responsible for signing. The pertinent data displays at the time of e-signature capture, rather than having to review it using the transaction windows.
When a notification is sent for approval, the following information displays in the header:
Subject is the full subject of that e-record.
Sent displays the date and time the notification was sent.
To displays the name of the recipient of the notification.
Style Name displays the style sheet name.
Version displays the style sheet version.
The name of the e-record attachments.
The one-step e-signature functionality lets you combine the several pages that a normal signing process takes, into a single page where all signers can complete their approvals. This is an online process, not deferred, and is set based on a profile option.
Approver count and approver list in one-step signature process
Approvers for a transaction are often set at the Approval Management (AME) level, where the set of approvers required for a business event are defined.
Approver count feature provides product teams the capability to enable the ERES framework to allow any number of valid application users as ERES Approvers during the signature process, as opposed to mandating pre-defined AME approvers. In this feature, product teams can set the number of application users for signatures. An approver count is set while raising an ERES event raise and the Signature page is displayed with those many rows. Any valid application user can sign-off the E-record.the transaction.
The Approver Lists feature allows product teams to send approver lists to E-signature framework. This list can have application users or responsibility. If it is a responsibility, any user who has the responsibility can do the sign-off. This also supports multiple counts for responsibility level approvals.
Approver list and approval count are available only in the Simplified Signature process (Einitials), and not available in the regular signature process.
Support of the above two features is primarily driven by the fact that the originating transaction systems may have their own way of defining the approvers and need not duplicate the same in AME.
Based on Good Manufacturing Practices and customer requirements, the following application windows are configured to capture e-records or e-signatures, or both.
Application windows, along with their associated programs, must be enhanced to call the data capture framework. Events are defined within the framework. An event consists of an event name, the tables, the columns, and the data values.
If an event exists, but is disabled for e-records or e-signatures, then the window behaves as expected. If an event exists and is enabled for e-records or e-signatures, then the framework reacts accordingly:
If e-signatures are enabled, then the e-signature window displays, requiring entry from the appropriate user.
If e-records are enabled, then a snapshot of the event takes place at the appropriate time:
If you have existing workflows, you can enable Oracle E-Records on these workflows using the components of the ERES framework. Refer to the Oracle E-Records Developer's Cookbook for details.
The framework consists of the flowing components:
Workflow Business Event system is used to define an e-signature event and associate synchronous e-signature subscription to the event.
XML Gateway is used for mapping definition and generation of XML for an e-record. Individual product teams define XML maps and DTDs for e-record and e-signature events supported by them. These maps and DTDs are loaded into the database and source controlled under the respective product tops. The e-record stylesheet is also defined as part of XML Gateway.
This component is used to define conditions, rules, and approval hierarchy. It stores rule specific attributes such as electronic recording required or electronic signature is required, and what type of style sheet needs to be applied for this rule. These rules are evaluated at runtime based on the transaction ID, which is the primary key for the transaction.
A generic call is available, which is called to raise an event from the window.
Notification subsystem is used to generate the signature user interface and control the flow of the user interface and return a status back to the application.
The Oracle Workflow Automatic Notification Processing automatically forwards your notifications to another role or responds to incoming notifications with a predefined response when you are not available to manage your notifications directly. This can be done on either an online or a deferred event.
The Notification Routing Rules let you define the rules for automatic notification processing. Each rule is specific to a role and can apply to any or all messages of a specific item type or message name. A rule can result in one of the following actions: reassigning the notification to another user, responding to or closing the notification, or delivering the notification to the original recipient with no further action.
When an event is signed with an overriding approver, the following happens:
The Evidence Store contains the original approver as well as the overriding approver details with proper comments.
The Signers list page shows the original approver as well as the overriding approver.
The E-records Query shows the original approver as well as the overriding approver.
XML Publisher provides a new approach to the customization of report publishing by integrating familiar desktop word processing tools with existing Oracle E–Business Suite data reporting.
Use the full range of your word processing application's formatting features to create rich report layout designs, or simply modify the ordering of report data to better suit your needs. XML Publisher transforms your document to XSL and PDF, letting you leverage your existing desktop application as an XSL editor.
The Evidence Store is used for storing electronic signatures. The e-records stored in the evidence store can be queried for, printed and audited.
When windows require an e-signature, there are two methods of capturing this data. The signature can be captured in process (online) or asynchronously (deferred) through workflow notifications.
Transaction windows (e.g., Batches, Inventory Quantities, Quality Results) require you to enter all signatures online only. If the signatures cannot be fulfilled in that session, then the new or updated transaction data is not committed to the database.
For those objects where a status or active/inactive column exists (e.g., Items, Lots, Formulas, Recipes, etc.), a generic workflow notification exists to enable deferred mode signatures. In these cases, windows prompt you for an e-signature when appropriate. If an e-signature is not entered online, then a notification is automatically sent to the user responsible for signing that record. Once all signatures have been fulfilled, the pending rows are updated to the appropriate status (active, approved, etc.). While signatures are in progress, the OPM window prevents any updates from being made to the pending data.
Online signatures are beneficial for those real-time processes that cannot proceed without immediate authorization.
Deferred mode signatures are useful when the signature does not need to occur immediately, the signers are not typically in the same physical location or are otherwise not immediately available at the time of the signature request, or if there are several items that the signers must verify prior to signing, thus creating a time lag between receipt of the e-signature request and the response.
Workflow notifications can be accessed through Oracle Applications. The use of Oracle Workflow provides an additional level of auditing - Workflow keeps an electronic history of when parties were notified and when they completed their signoff.
In order to ensure the proper signatures are captured for each document or event within each internal organization, part of the Electronic Record Framework enables secured users to associate the appropriate Users with each event.
An e-record contains a defined set of data from a moment in time captured by the software. This set of data is unique for each application, and each event within that application. For organizations capturing e-signatures with e-records, the intent is to present the e-record to the application user and let them approve or reject the data along with their signature. For those not using e-signatures, e-records are captured as a background process. Layouts for all OPM e-records are contained within this document and is further explored within the detail designs to follow.
E-records are captured in an XML format. XML provides portability, ultimately enabling the delivery of e-records to the FDA electronically. XML also provides longevity of the data. This helps eliminate the need to keep old versions of programs available just to read the documents. The e-records are generated using the XML data with related XSL or RTF templates.
The e-records are stored in an evidence store. The evidence store is a secure storage location and has links from the transaction windows.
Oracle Process Manufacturing provides support for touch screen devices. The touch screen display monitors offer shop floor operators a user interface that requires minimal training and that minimizes the use of keyboard and pointing devices.
The Operator Workbench is equipped with touch screen user interface to perform batch transactions and execute process instructions, or to perform dispensing and reverse dispensing operations.
For more information, refer to: Using the Touch Screen User Interface, Oracle Manufacturing Execution System for Process Manufacturing User's Guide.
Copyright © 2002, 2010, Oracle and/or its affiliates. All rights reserved.