Questions about OpenMETRIC's Regulatory Requirements
1.
Regulatory Requirements
|
Is your system compliant to ANSI/ISO/IEC 17025:2000? If not, describe the gaps and your corrective action plan. |
|||
|
Yes.
We have utilized our involvement in NCSLI to maintain
visibility and understanding of impending regulations and
regulatory changes. Accordingly,
we have typically incorporated compliance with new regulations
before they have become fully adopted or mandatory.
We acknowledge, however, that with all new regulations
there are areas of ambiguity and issues subject to interpretation.
In these areas, we incorporate compliance consistent with
the predominant best guidance with continual attention to
evolution and clarification as they emerge. |
|||
|
1.2 |
Is your system compliant to Food and Drug Administration Quality System Regulation 21 CFR Part 820 Medical Devices; Current Good Manufacturing Practice; Final Rule? If not, describe the gaps and your corrective action plan. |
||
|
Yes, to the best
of our current knowledge and understanding, bolstered by the
guidance and feedback of NCSLI and our current clients and
prospects. |
|||
|
Is your system compliant to FDA Title 21 Code of Federal Regulations (21 CFR Part 11) Electronic Records; Electronic Signatures; March 2000? If not, describe the gaps and your corrective action plan. |
|||
|
Yes.
Our implementation of 21 CFR Part 11 compliance has been
successfully implemented, reviewed and confirmed. |
|||
|
How do you support the validation of your software? |
|||
|
As our
FDA-regulated clients prepare their IQ/OQ/PQ documents, we provide
supporting documentation and material as required.
Since we offer a COTS (commercial off-the-shelf) solution,
we have the proven track record of numerous clients and users to
verify the correct performance of our product. In addition, we
are extremely knowledgeable and have been a significant
contributor to the establishment of software development and
quality control guidelines and standards as espoused by the
Congressionally-established Software Engineering Institute (SEI)
and their Capability Maturity Model (CMM) as well as other
software assessment methodologies. |
|||
|
1.5 |
How will you support future revisions of regulatory documents? |
||
|
We intend to
remain fully compliant with regulatory documents in the future.
We have an outstanding track record of regulatory
compliance and audit success in metrology for over 17 years.
Our involvement in NCSLI provides us considerable advance
notice of proposed or anticipated regulatory changes, and we
usually incorporate compliant software before the new regulations
actually become effective. |
|||
|
1.6 |
How do you support assistance to your customers regarding audit findings due to system software gaps? |
||
|
No DDS client has
ever had an audit finding due to our software or software gaps.
If such an unlikely event were to occur, however, we would
accept the responsibility to supplement OpenMETRIC in whatever
manner is necessary to achieve full regulatory compliance. Our legal
department insists, however, that we clearly delineate the
difference between SOFTWARE and DATA.
We do NOT accept responsibility for missing, incorrect, or
inconsistent data which is the responsibility of the client.
Nor do we accept responsibility for misuse of OpenMETRIC. |
|||
|
1.7 |
What is your method for handling customer recommendations for software system improvements or enhancements? |
||
|
We welcome
suggestions for improvements and enhancements to OpenMETRIC.
We maintain a comprehensive catalog of all such requests,
which we then evaluate, prioritize, implement, and incorporate in
future releases of OpenMETRIC. If the customer
requires priorities or implementation approaches different than we
intend for our own internal development, the customer may request
that we provide a proposal or quotation permitting the customer to
select enhancements for immediate inclusion by funding the
development. |
|||
|
How does your system handle data validation? |
|
||
OpenMETRIC
performs extensive validation on data as it is entered to minimize errors.
OpenMETRIC makes every effort to catch probable errors at the point
of entry so the errors can be corrected quickly, easily, and timely.
OpenMETRIC
data validations can be classified into the following types.
Note:
Sample formats indicate possible formats for the type of message,
but additional formats may also be used.
1.
Required
A.
The field must be entered.
B.
Add, Update, Copy functions
C.
The screen key is required on every
screen. The number of
additional required fields varies from screen to screen.
D.
Sample message format:
1)
[fieldname] required
2.
Contingent Required and Contingent
Not Allowed
A.
If one field is entered, another
must also be entered (Contingent Required).
If one field is not entered, another cannot be entered (Contingent
Not Allowed).
B.
Add, Update, Copy functions
C.
Performed on only a few screens
D.
Sample message formats:
1)
[fieldname] required
2)
[fieldname] required for
[fieldname]
3)
[fieldnames] are only for
[fieldname]
3.
Exist (if entered)
A.
The field must exist on a table if
it is entered. A field on one
screen on a tab must already have been entered as the screen key on
another tab. For example, the
Owning and Using Customers on the Item tab main screen must already have
been entered on the Customer tab before they can be entered on the Item
tab main screen.
B.
Add, Update, Copy functions
C.
On standard screens, these fields
will have binocular (plb) buttons next to them.
On multi-line (grid) screens, right-click while in update mode.
These fields are identified if the drop down box displays “Lookup
[fieldname]”.
D.
Sample message formats:
1)
Standard screens: for the most
part, the fields are protected and the only way entry can be made is by
selecting from valid entries on the plb.
In the instances where the field can be typed in, a sample message
format is “[fieldname] does not exist on [tablename]”.
2)
Multi-line (Grid) screens: This is
not a valid [fieldname]
4.
Not Exist
A.
A record on a tab cannot be deleted
if its key is referenced on another tab.
For example, a Vendor record cannot be deleted if its key (Vendor
ID) appears in any of the vendor fields on the Item tab.
B.
Delete functions
C.
The delete function on almost all
of the Setup tabs performs this type of validation.
D.
Sample message format:
1)
There are [other tab key fieldname]
with this [key fieldname].
5.
Valid & Not Future Dates (if
entered)
A.
To be valid, a month must be
between 1 and 12 and a day between 1 and 28-31 (depending on the month and
leap year considerations). Years
that are entered without a century are converted to contain a century.
Not Future means a date cannot be greater than today.
B.
Add, Update, Copy functions
C.
All dates entered into the systems
must be valid. Most dates are
also checked for Not Future. Due,
scheduled and warranty expiration dates are among the dates that may be in
the future.
D.
Sample message formats:
1)
[fieldname] is invalid
2)
[fieldname] is in the future.
6.
Numeric Comparisons
A.
A numeric field cannot be greater
than another numeric field. Other
comparisons include greater than or equal to, less than, or less than or
equal to. For example, the
Used Date on the Standards screen cannot be greater than the Cal Date on
the Calibration screen. Another
example is the interval on the Item screen cannot be less than the Minimum
Interval or greater than the Maximum Interval.
B.
Add, Update, Copy functions
C.
Comparisons are made among related
numeric fields, usually on the same screen.
D.
Sample message formats:
1)
[date fieldname] cannot precede
[date fieldname]
2)
[date fieldname] is after [date
fieldname]
3)
[fieldname] is greater than
[fieldname]
7.
Table (file) handling
A.
For each table in the system, there
is a set of messages relating to problems accessing the table such as no
more records, record not found and duplicate key.
B.
Some messages apply to only one
type of function; others apply to multiple functions.
C.
Performed throughout the systems.
In some instances, these messages are overlaid by messages from a
specific program.
D.
Sample message formats:
1)
These messages are 3 lines long.
They fall into 2 categories: less
serious and more serious.
a)
The less serious errors are
generally caused by user error and can be rectified by the user.
This includes attempting to enter a record that already exists,
attempting to find a record that does not exist because the key was typed
incorrectly or attempting to browse beyond the end of a table.
The less serious messages are structured as follows.
The first line indicates the name of the table being accessed and
the function being performed. The
second line indicates the key of the record.
The third line indicates the condition encountered.
Conditions encountered include the following.
"End
of File".
"Record
Not Found".
"Duplicate
Key".
"Duplicate
Alternate Key".
b)
The more serious errors are usually
system errors and require notification of the IS department and/or DDS.
The more serious messages are structured as follows.
The first line indicates the condition encountered.
The second line indicates the key of the record.
The third line provides error codes that may be helpful in tracking
down the problem. Conditions
encountered include the following.
"Opt
file missing: EXTEND/DELETE".
"Disk
full for indexed file".
"Permanent
host O/S error".
"Disk
full for sequential file".
"File
not found (OPEN/SORT)".
"Can't
open: No access (network down?) ".
"Previously
closed with lock".
"Incorrect
file description".
"File
already open".
"File
not open (CLOSE/UNLOCK)".
"No
current record (seq REWRITE/DELETE)".
"Record
size doesn't match file".
"No
current record (READ NEXT/PREV)".
"File
not open for read".
"File
not open for write".
"File
not open for update".
"Broken
file/index corrupt".
"Record
locked by another user".
"Inadequate
memory (sort)".
"Read
previous not supported".
"Lock
tables are full".
"Internal
host system error".
"Transaction
unit error".
"Consult
Manual".
"ROLLBACK
failed: external routine".
"Can't
open log: max files exceeded".
"Can't
open log: path invalid".
"Can't
open log: no access privilege".
"Operating
system error".
"Log
file is corrupt".
"Can't
open log: it's locked".
"Insufficient
dynamic memory".
"Can't
write log: disk is full".
"No
LOG-DIR config variable specified".
"Unexpected
log eof during ROLLBACK".
"Last
transaction is not complete".
"File
wasn't opened in this trans unit".
"Non-standard
file-system error".
"Can't
open remote file: (network down?)".
"Finish
current transaction first".
"Host
file system doesn't support trans".
2)
[tablename] Write | Key=[record
key] | Duplicate Key (This occurs when the user attempts to add a record
that already exists to a table.)
3)
[tablename] Read Next | Key=[record
key] | End of File (This occurs when the user attempts to access a record
beyond the last record on the table.)
8.
Other errors
A.
There are numerous other error
conditions that do not fit any of the classifications above.
B.
Add, Update, Copy functions
C.
Performed throughout the systems.
D.
No sample message format is shown
because each error is different.
9.
Warnings
A.
All the above are error conditions
that prevent processing from proceeding.
Warnings, on the other hand, allow processing to continue.
They are a means of alerting users to certain conditions they may
want to change. The title in
the message box is “Warning”.
B.
Add, Update, Copy, Delete functions
C.
Performed sparingly throughout the
systems.
D.
No sample message format is shown
because each warning is different.
10.
To Do Lists and Button Protection
A.
Clicking on a To Do button provides
a list of requirements that must be met before an associated function can
be performed. As each
requirement is met, it is removed from the list.
The associated function button is disabled until the list is empty.
B.
Function button protection that is
controlled by To Do lists: Complete
(Calibration, Repair, PM, Other), Close (Tracking), WonderWriter Add and
Update (Define Report)
11.
Other Contingent Button Protection
A.
Certain buttons are enabled and
disabled based on certain criteria. The
following are examples of this protection.
1)
In Calibration the Approve and
Sticker buttons are disabled until the cal is complete.
2)
In Calibration the Approve All
button is disabled until at least one item has been added to the basket.
3)
In Tracking the Close All button is
disabled until at least one item has been added to the basket.
4)
In Tracking, the three Replicate
Service buttons are contingent upon each other.
|
|
|
|
|
How does your system handle audit trails and activity logs of all data changes |
||
|
There are
approximately 176 tables (files) in the OpenMETRIC application.
Every time any change is made to any of the tables for any
reason, OpenMETRIC records the user that made the change, the date
and time that the change was made, and the function that was used
to make the change. These
“stamps” are typically displayed on the lower left portion of
each screen. These
“stamps” can be searched, retrieved, and reported. In addition, for
35 of the most critical of the “setup” tables, OpenMETRIC
automatically records an entire image of the record as each change
is posted. These
“history” tables can be viewed, searched, retrieved, and
reported. Finally,
OpenMETRIC utilizes the latest technology for Transaction
Management, whereby, each database change is logged and from which
the database can be rolled back and/or restored. |