Attachment B - Forms Solution - FUNCTIONAL REQUIREMENTS
QUESTION RESPONSE CODES
The standard system provides this feature. This requirement can be demonstrated at an installed client site in general release. Indicate the version
number in the comment field.
B This requirement is currently in beta testing. Indicate beta site and expected general release date in the comment field.
A This requirement is currently under development or is in alpha testing. Indicate general release date in the comment field.
This requirement is not in the standard system, but there is no charge for a change to meet this specification. Indicate the date of availability to M. D.
Anderson in the comment field.
This feature is available at cost additional to that specified in Pricing Schedule . Indicate the cost in the comment field. Also indicate the estimated tim
F This feature can be configured at no additional cost, using the standard system.
N This requirement is not available.
This requirement is available through a third party software or hardware supplier. Indicate the supplier in the comment field. Is there additional cost o
the cost included in the pricing schedule? Indicate in comment field.
No Response will be scored as a "0"
ID REQUIREMENT S B A M C
1.0 User Access to Application
System must be easy to understand to minimize staff training time; the fewer keystrokes to
1.1 select/print a form, the better.
Users can access the [Forms Application] via a link on the Clinic Portal website, i.e., a web-based
1.2 viewer accessible within the MD Anderson Cancer Center (MDACC) network.
1.3 A userid and valid password will be required to log on to the [Forms Application].
2.0 Patient Selection
2.1 User can enter any of the following to search for the correct patient:
Exact 6-digit Medical Record Number (MRN) (Field should accommodate minimally 10
2.1.2 Full name, including first and last name
2.1.3 Entire last name
2.1.4 Beginning of last name such as "S" or "Smit"
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 1 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
2.1.5 Beginning of first and last name
2.1.6 Soundex name search
User can limit the number of search results returned or retrieve all records based on the criteria
2.2 entered (e.g., return all found in cases of common names like Smith, Gonzalez, etc.)
2.3 Information will be displayed for the user to verify the correct patient:
2.3.1 Medical Record Number (MRN)
2.3.2 Patient Account Number
2.3.3 Patient Name
2.3.4 Date of Birth
Ability to add a patient to the database when an ADT transaction is not expected. Special Case:
Very early MDACC MRN# were not 6 digits (i.e., they have a leading zero such as 004565 or
012348). MDACC may still receive correspondence on these patients which needs to be scanned
in, but we never received an ADT transaction to "load" the patient in the [Form Application]'s
Ability to change the patient's status to "Discharged" in the case when we somehow did not get the
interface discharge transaction; sometimes patients' forms continue to print out on the unit even
2.5 though they are officially discharged in CARE.
3.0 Ad hoc Printing
3.1 Forms can be printed for both Inpatient and Outpatient areas.
3.2 System will allow for "print on demand" functionality for blank forms.
3.2.1 User can print individual blank forms (i.e. no MRN/Visit Date).
3.2.2 User can print packets of blank forms (i.e. no MRN/Visit Date).
User can select ALL documents in a group to be printed. This function is normally used to
3.2.3 prepare downtime manuals.
3.3 System will allow for "print on demand" functionality for patient-specific forms.
3.3.1 User can print individual forms for a single patient (contains MRN/Visit Date)
3.3.2 User can print form packets for a single patient (contains MRN/Visit Date)
User should NOT be allowed to print ALL documents in a group for forms that have patient-
3.3.3 specific data on them.
Patient information (e.g., patient name, MRN (sometimes called MDA#), date of birth, financial
class, sex, and print date) will print at the top of every page of a form. Additional data from CARE
may occasionally be required to print on a form, e.g. Coordinating Attending Physician or State of
3.5 User can select a printer. Only printers that the user has access to will display.
3.6 User can designate a default printer.
User can print to the default printer, i.e. the default printer as set in the Windows Print Manager on
3.7 the user's workstation.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 2 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
3.8 User can enter the quantity of printouts needed (default = 1, max = 10)
User can VPN into system and print forms to a locally attached printer to the workstation. (user
3.9 could be at home).
4.0 Scheduled Batch Printing (Preprint)
System will allow for scheduled batch print functionality for both Inpatient areas (census) and
4.1 Outpatient areas (appointments).
4.1.1 Explanation specific to MDACC:
Outpatient print jobs are based on CARE Resource Group (Urology, Leukemia, etc) and CARE
4.1.2 Appointment Type (proc code) (FU-Follow Up, NV-New Visit, etc)
Inpatient print jobs are based on CARE Resource Group (Urology, Leukemia, etc), Inpatient
Status, and Patient Location. Since inpatients do not have appointments, the CARE
4.1.3 Appointment Type is not used.
4.2 Printers will be associated with scheduled print jobs.
Ability to reprint a scheduled print job; this should be assigned to only certain roles within the
Ability to reprint a subset of a print job (e.g., a certain physician's appointments for the day
(resource code - not currently used) or a certain appointment type (procedure code)); this should
4.4 be assigned to only certain roles within the system..
Report : Scheduled Batch Job Listing for both inpatient and outpatient areas; what preprint group is
to print to what area at what time; report to include resource group, procedure code, printer and
4.5 packet(s), sorted by preprint group, resource group or procedure codes.
Report: Scheduled Batch Job Report for both inpatient and outpatient areas; what scheduled print
4.6 jobs actually printed, including printer location and date/time printed.
5.0 Non-Scheduled Batch Printing (based on appointments)
5.1 System will allow for ad hoc batch print functionality for Outpatient areas only.
5.2 Users can select an appointment date (up to 6 days in advance)
User has the option to (1) print all appointments for that date (even if the job was previously run) or
(2) just appointments that were added since the job was run. (The system sets a "printed" flag in the
5.3 database when a scheduled print job is run to mark the patients who were already printed.)
If a user tries to print a job that was already run, system must display a message that the job was
5.4 already run. The message should include the user and date/time of the previously-run print job.
Once a batch is printed, the user has the option to select another appointment date or return to the
5.5 patient selection screen.
Report: Non-Scheduled Batch Job Report - what non-scheduled print jobs actually printed,
5.6 including printer location, date/time printed, and user who requested the print job to be run.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 3 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
6.1 System is compatible with CARE ADT
6.2 System is compatible with CARE Resource Scheduling
6.3 System is compatible with CARE Inpatient Census (ADT)
System is compatible with CARE Print Capture (Data entered on the CARE system for several
forms (Consents, Advanced Directives, Face Sheets, Admission Forms) can be sent to the [Forms
6.4 Application] to be merged with the form and printed.)
System should allow for easy additions to the forms of any data element received from CARE, e.g.
the need to add the "Coordinating Attending Physician" (CAP) or the patient's "State of Origin" to a
7.0 User Administration Functions
7.1 Users can be added, edited, deleted or given "inactive" status.
7.2 User list can be sorted by user last name or userid.
System has enhanced search functionality so that the HIM user can type in as many letters as
7.3 necessary of the user's name to locate the user in the list.
The userid may be the user's 6-digit employee ID#, the physician's ID#, or another unique number
7.4 (contract workers), but it must be unique in the system.
System has audit functionality so that changes to all users are documented including the user who
7.5 made the change, what was changed, and the date/time stamp of the change.
System provides templates for building user functions in the system. For example, nurses can be
assigned to an Inpatient Nursing Resource Pool group, which includes Inpatient menus and
Inpatient printers, etc. This would allow for more "global" edits of user functions rather than having
7.6 to change each individual user.
7.7 Report : Current User Report; to include user name, user ID, level of access
7.8 Report : Expired User Report; to include user name, user ID, level of access
7.9 Report : Users by Group Report (which users are associated with what groups)
7.10 Report : Users by Printer Report (which users have access to which printers)
Report : User Update Report; to include admin user name, user ID, date/time, explanation of what
7.11 data was modified/deleted.
Security levels need to be more granular, so that different groups of users have access to different
8.1.1 Non-Scheduled Batch Printing ( Appointments )
8.1.2 Print-on-Demand ( Blank Forms )
8.1.3 Print-on-Demand ( Patient Forms )
8.1.4 User Administration
8.1.5 Document Administration
8.1.6 Reset Passwords
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 4 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
8.2 Only Admin users have the ability to change security levels.
9.0 Form Repository
9.1 System will contain a form repository for end users to access forms. (~2000 forms)
End user can easily search for a form or form packet, entering search criteria for any field of
9.2 metadata associated with the form (e.g., doc type, description, etc.)
End user can easily view a form before printing it, using a "print preview" type of functionality. Form
9.3 should be locked from modification by end users.
9.4 End user can easily view the forms in a packet before printing the packet.
Forms with medical record attributes (3-barcoded forms) in repository are automatically uploaded to
9.5 Captiva for indexing. Non-medical record forms do not need to be available for indexing in Captiva.
Sometimes forms are created that are almost identical, but they don't want to assign a new doc type
to each one. These forms are given a special designation as BC= (barcode equals) to identify them
as being the same type of form. The barcode used on them is identical for all of them, and they will
all have the same description in Clinic Station, but they are saved in the form repository as separate
9.6 forms, since they are different. The Form Repository must be able to distinguish these forms.
10.0 Document Administration Functions
10.1 Document Hierarchy - System must allow all types
10.1.1 Form - an individual form; may be a single page or a multiple page form.
10.1.2 Packet - made up of more than one form.
Group - made up of one or more packet. Groups are set up to facilitate access to forms based on
specific user roles, e.g. users in the Leukemia Center will only see a subset of packets because
10.1.3 only one of more group(s) of packets have been placed on their menu.
System must allow for the set up of preprint groups. A preprint group is a group that is set up for
10.1.4 scheduled batch printing.
11.0 Form Administration
11.1 Forms can be added, edited, deleted or given "inactive" status.
Forms can have a variety of properties, including security view levels, rotation angle, image, single-
sided/duplex, date/time created, created by, date/time modified, modified by, comments section,
11.2 document type, description and category.
11.2.1 Explanation specific to MDACC:
For medical record forms, the "document type" = form number = form filename = barcode.
(Exception, for the forms using the BC= designation, the barcode does not equal the form
number). For non-medical record forms, there is no barcode since they will not be scanned into
11.2.2 the medical record. Non-medical record forms are used mainly for workflow.
11.2.3 The form "Description" is equivalent to the "Document Name" in Clinic Station.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 5 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
The form "Category" is equivalent to the "Document Category" in Clinic Station. Categories
include Administrative/HIPAA, Advanced Directives, Allergies and Current Medications, Allied
Health and Collaborative, Cardiology, Consents, Correspondence, CSR, Diagnostic Imaging and
Nuclear, Discharge/IPOCTR, Flow Sheets, Laboratory, Nursing, Other Diagnostic Reports,
Pathology, Patient History Database, Peri-Operative/Anesthesia Reports, Photographs,
11.2.4 Physicians Orders, and Progress Notes.
11.3 System will allow versioning of forms, with each version of a form having its own properties.
The form list can be sorted by form number (doc type), form description, permissions, creation
11.4 date/time, modified date/time or other pieces of metadata associated with the form..
HIM user can easily search for a form, entering search criteria for any field of metadata associated
with the form (e.g., category, doc type, description, permissions, creation date/time, modified
11.5 date/time, etc.)
11.6 Forms can be set to be available globally (i.e. for every user) or individually set for certain users.
Report : Forms Listing Report; to include form description, form number/doc type (which may not
be the same in all cases due to BC= forms), creation date/time, created by, modified date/time,
modified by, what was modified. Would like the option to display all fields associated with all forms,
11.7 or to select a subset of forms based on form properties.
12.0 Packet Administration
12.1 Packets can be added, edited, deleted or given "inactive" status.
User can easily search for a packet, entering search criteria for the full packet name or partial
12.2 packet name.
12.3 Packets can be one of 3 print types :
12.3.1 Scheduled -- associated with Inpatient Census or Outpatient Appointments
12.3.2 On Demand -- able to be printed on demand
12.3.3 All Print Types -- either scheduled or on demand
12.4 Forms can be added to the packet individually or as a group.
12.5 Forms can be removed from the packet individually or as a group.
A packet can contain duplicate identical forms. (Some areas need more than one of a certain form
12.6 printed in their packets.)
Forms can be placed in a specified print order within the packet by moving individual forms up or
12.7 down in the list.
When selecting the forms to be added to the packet, the HIM user can easily search for a form,
entering search criteria for any field of metadata associated with the form (e.g., category, doc type,
12.8 description, permissions, creation date/time, etc.)
12.9 Packets can be set to be available globally (i.e. for every user) or individually set for certain users.
12.10 Packets can be globally edited, e.g. the addition of a new institutional form to every packet.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 6 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
Ability to easily identify where a form appears in all packets and menus. This will help when a form
12.11 is retired or modified.
Report : Packet Listing (which forms are associated with which packet); to include form names and
12.12 form numbers.
13.0 Group Administration
13.1 Groups can be added, edited, deleted, or given "inactive" status.
User can easily search for a group, entering search criteria for the full group name or partial group
When selecting the packets/forms to be added to the group, the user can easily search for a
13.3 packet/form, entering search criteria for the full packet name or partial packet name.
13.4 Packets/forms can be added to the group individually or as a group.
13.5 Packets/forms can be removed from the group individually or as a group.
Groups can be set to be available globally (i.e. for every user) or individually set for certain users.
13.6 (Current functionality is that a new group must be added to each user.)
Groups can be edited globally, e.g. when a new form or packet needs to be added to each group it
13.7 can be entered just once instead of to each group individually.
13.8 Preprint Group Administration (subset of Group Administration)
13.8.1 Groups that need to be scheduled for preprinting will be defined as a preprint group.
13.8.2 Preprint Groups can be added, edited, deleted or given "inactive" status.
13.8.3 Preprint Print Jobs should be based on the following:
13.8.4 CARE Resource Group (e.g., 740 - Thoracic Surgery)
13.8.5 CARE Appointment Type for outpatients or Inpatient Status for inpatients
13.8.6 Packet(s)/Form(s) to be printed
13.8.8 HIM user can easily view the list of Preprint Print Jobs for a preprint group.
13.8.9 HIM user can preview the contents of a packet when adding the packet to the preprint group.
The specific time for the scheduled Preprint Print Job to run can be selected for the preprint
The number of days in advance can be selected for the preprint group. Allowable choices are 0-6
13.8.11 (0=current date, 1=next day, etc.)
HIM user can add a preprint group before actually scheduling it. A checkbox for "Scheduled" will
be checked when the job is ready to go into production. This preprint group would essentially be
13.8.12 inactive until the "Scheduled" checkbox is checked.
Report : Packet vs Group Listing (which groups, both Inpatient and Outpatient, are associated with
13.9 which packets)
Report : Preprint Schedule Listing, to include schedules for both Inpatient and Outpatient areas.
Example: Listing should include what packets/forms print for Sarcoma, when the job is scheduled,
13.10 and what printer is used for the output.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 7 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
14.0 User Menus
14.1 System is customizable to allow for specialized menus based on different staff roles and/or areas.
15.1 Ability to customize reports.
Ability to run reports on all fields, values and attributes; includes users, security, printers, forms,
15.2 packets, groups.
15.3 Date/timestamps for all fields available to be included in all reports if needed.
15.4 Reports include "who created", "who modified" where appropriate.
16.0 Audit Trails
System contains audit trails that record information of requested print jobs which can be used for
16.1 troubleshooting print problems with either scheduled or on-demand print jobs.
Report : Forms Usage Report, the quantity of each form that has been printed on a certain date or
16.2 date range, to include the form description, doc type, date/time printed, printer, user.
Report : Inactive Forms Tracking Report; what forms have not been printed over a specified date
16.3 range. This will help HIM clean out inactive forms from the form repository.
17.0 Printer Administration
17.1 Ability to assign a default printer to a Preprint Group (scheduled printing).
17.2 Ability to assign a default printer to a user, with a choice of other printers available.
17.3 Ability to create/modify printer profiles.
17.4 Require an activity log for each service (e.g., a listing of print jobs that were processed).
17.5 Require an error log for each service (e.g., a listing of print jobs that were NOT processed.)
17.6 Require an audit trail to help troubleshoot print jobs; to include requestor and location.
Ability to cancel print jobs (current and in queue); intercede for large print files holding up the print
Ability to designate primary job type (would like for on-demand printouts to come out ahead of larger
17.8 batch jobs, so that on-demand users do not have to wait as long.)
Ability to designate high/low capacity printers so that certain print jobs can only be sent to high
17.9 capacity printers.
Report : Printer Listing Report; to include PID, IP Address, with what groups the printer is
17.10 associated, modified date/time and modified by user.
18.0 Form Creation
A designated location on the network server is required to store all forms for use. Read-write
18.1 access is required.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 8 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
Access to production forms must be restricted by password protected access to the form
18.2 files/server. Only certain HIM personnel should be able to create or modify forms.
18.3 [Form Design Tool] must be Windows based.
18.4 [Form Design Tool] may be a 3rd party vendor application.
Creation/modification of forms should be quick and easy. Drawing tools and form templates should
18.5 be available to assist with form creation using a graphical user interface (GUI).
[Form Design Tool] must have the ability to configure barcodes to specific specs (alphanumeric, no
18.6 special characters; 3 of 9 small, 2 dimensional barcodes preferred.)
Global edits for barcodes. If 3 of 9 small barcodes are replaced by 2 dimensional barcodes, this
18.6.1 should be accomplished with a global edit. No need to correct each individual form.
18.7 [Form Design Tool] must contain a "find and replace" feature for text.
Ability to configure the form template so that patient information fed from the CARE system (MRN,
18.8 Name, DOB, FC, Sex, CAP, Acct, etc.) can be merged with the form.
18.9 Patient information must print on every page of the form.
18.10 Forms need to be uploaded to the [Form Application] for printing.
18.11 Medical Records forms have 3 barcodes: Date, MRN, Doc Type
Barcodes are not required on all forms in the repository. Non-medical record forms (used
primarily for clinic workflows) have no barcodes, but still need to be able to be printed from the
18.11.1 [Forms Application].
In general, the document type is located at the lower right corner of the form; MRN is at top
center, and Date is at top right. Ideally, each barcode would include a 3-character prefix (e.g.,
DOC,MRN,DAT) that would identify the data element it refers to so that the barcodes could be
18.11.2 placed anywhere on the page.
18.12 Form layout should be in inches and picas (centimeters not needed).
18.13 Ability to alter leading and kerning. (leading = line spacing; kerning = space betw letters)
18.14 Ability to open multiple occurrences of the form design software.
Ability to convert all existing JetForm Designer forms (.IFD format) to other file formats (e.g., Word,
18.15 PowerPoint, Adobe) so that they will be usable/modifiable for the new system.
18.16 Ability to archive forms that are no longer used.
Ability to make global edits in forms (ability to make massive changes vs. making single changes to
individual documents, e.g., addition of a new logo on all forms or a new demographic field on all
Ability to "lock" a form proof while it is going through the approval process so that users can't
18.18 change it.
Abilty to identify and merge similar forms (based on content/metadata) without having to recreate
18.19 them from scratch.
19.0 MDACC-Specific Workflow for Forms Approval
Form requestor needs the ability to complete the form request and send (fax, mail, etc.) to the
19.1 Forms Analyst. Request should include a sample/draft of desired form.
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 9 of 20 1/7/2011, 8:35 AM
ID REQUIREMENT S B A M C
Forms Analyst needs the ability to check the request/form against existing list of forms (currently the
19.2 Forms Mgmt Access Database). Search can be by title or keywords.
Forms Analyst needs an easy system for assigning the document type. Currently, they compare the
Forms Mgmt Access Db with the AccessANYware doc type list to get the next number in line. They
reserve the number in the database until the form is done and approved. An automated form
19.3 numbering system would be better.
The Forms Analyst needs the ability to route the form to the IDC Chairperson for approval. New
19.4 forms and major revisions must go to the IDC for final approval.
The Forms Analyst needs the ability to route the form back to the requestor for approval to upload
19.5 into the [Forms Application].
When the form is uploaded to the Forms Application it should automatically be sent to
19.6 Documentum. The [Forms Application] and Documentum must be kept in sync.
Yellow-highlighted cells indicate workflow/notes that are not considered true requirements,
but are kept as a part of this document as background information.
Clinic Portal = Web Page on MDACC website with links to medical staff tools/resources
Clinic Station = Web application which is being developed to become MDACC's EMR; contains
folders of information from various computer systems at MDACC (e.g. Lab, Radiology, Critical Care,
etc.); the Scanned Documents folder contains all documents that are scanned into Clinic Station by
CARE = computer system used within MDACC for patient registration and scheduling of patient
activities and appointments (historical names = Siemens, Invision, SMS)
BC= "barcode equals"; used when several forms are submitted that are similar, but they don't want
to create a separate document type for each. Example:
INS999003 - Patient Needs Assessment (file under Pt Hx Db)
BC=INS999015 (Patient History Database)
INS999003 - Patient Needs Self Assessment (file under Discharge)
Doc Type Numbering Schema - Current MDACC 9-character document types (There are many
historical doc types which do not follow this schema, and can not be converted.)
3 digit Center (Alpha)
3 digit Resource Group (Numeric)
3 digit Numeric (for the number of the forms created for this Resource Group)
Local Printer = Physical printer attached to workstation.
Default Printer = default network or local printer on workstation as defined by Windows Print
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 10 of 20 1/7/2011, 8:35 AM
te the version
ilability to M. D.
he estimated time
dditional cost or is
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 11 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 12 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 13 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 14 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 15 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 16 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 17 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 18 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 19 of 20 1/7/2011, 8:35 AM
2af79ee8-5756-43dc-b3b9-75934d99c937.xls: Functional Tab Page 20 of 20 1/7/2011, 8:35 AM