state of south carolina electronic transcript...

Parchment, Inc. Hewlett-Packard

11/1/2012

State of South Carolina Electronic Transcript Services Parchment Technical Response to Solicitation # 5400004871

REDACTED

Parchment, Inc. 6263 N. Scottsdale Road, Suite 170, Scottsdale AZ 85250

11/1/2012

Corporate HQ

6263 N. Scottsdale Road Suite 330 Scottsdale, AZ 85250

Phone: 480.719.1646 Fax: 480.991.2333

November 1, 2012 Ron Conner Procurement Officer Information Technology Management Office (ITMO) 1201 Main Street, Suite 601 Columbia, SC 29201 Reference: Parchment Response to Solicitation # 5400004871

Dear Mr. Conner:

On behalf of Parchment, Inc., we are pleased to submit our response to the State of South Carolina for Electronic Transcript Services. Parchment’s response is in accordance with the instructions provided within the RFP. Parchment understands the organizational requirements for the project’s success and is experienced at implementing statewide initiatives along with individual institutions.

On October 3, 2012 Parchment acquired Avow Systems Inc. to merge the Docufide and Avow platforms, creating the largest and most secure eTranscript network. More than 9,000 high schools (over 30 percent of the U.S. secondary school market), 1,800 postsecondary institutions and seven statewide initiatives have exchanged 6 million transcripts using Docufide by Parchment™ and the Avow by Parchment™ SaaS platforms.

As the leader in electronic transcript (eTranscript) exchange our sole focus is on the exchange of education credentials and we understand the challenges and frustrations that SC students, alumni and administrators face with a manual request and fulfillment transcript process. Improved student service is a main reason why institutions adopt an electronic transcript service and as our response will show, the Parchment solutions offer not only improved service but will also streamline operational workflow. This will allow administrators to focus on other high priority functions within the Registrar’s office. Over the last nine years Parchment has earned its place in the market as the trusted intermediary delivering academic credentials through our FERPA compliant solutions. We believe herein we have provided a compliant and compelling solution to meet the needs of South Carolina higher education students, alumni and administrators now and well into the future.

Since 2008 we have been honored to work with the State of South Carolina Department of Education providing counselors and students a comprehensive, secure electronic transcript exchange service. We saw a 221% increase in usage during 2011 and are on track to increase that for 2012. Over the last 4 years we’ve expanded our network to include over 300 colleges, helping secure our place as a leader in the post-secondary market as well. Our focus has been to help institutions automate transcript workflows, improve student and alumni service and replace costly, time-consuming, paper-based processes.

We firmly believe that we can have immediate impact on the challenges that SC Colleges and Universities face regarding their transcript processing workflows. In addition, the majority of SC students have come to expect a certain level of automation and convenience when requesting transcripts as

Corporate HQ

6263 N. Scottsdale Road Suite 330 Scottsdale, AZ 85250

Phone: 480.719.1646 Fax: 480.991.2333

evident from our adoption and usage from the high schools. We want to bring this technology and service to Colleges so they may also meet these student and alumni needs.

Should you have any questions related to this formal response, please feel free to contact Melissa O’Connor at [email protected] or 972.672.6254.

Sincerely,

Mathew Pittinsky, CEO Parchment, Inc.

mailto:[email protected]

Electronic Transcript Services Solicitation # 5400004871 Technical Response November 1, 2012

1

Table of Contents

1.0 MINIMAL REQUIREMENTS ................................................................................................................. 2 1.1 Solution Architecture ........................................................................................................................................ 2 1.2 User Authentication ......................................................................................................................................... 3 1.3 Document Compliancy ..................................................................................................................................... 3 1.4 Output Formats ............................................................................................................................................... 4 1.5 Delivery Options ............................................................................................................................................. 5 1.6 Institution Customization .................................................................................................................................. 5 1.7 Student Transcript Request Process .................................................................................................................... 5 1.8 Student Transcript Receipt ................................................................................................................................ 6 1.9 Notification Process ......................................................................................................................................... 6 1.10 Reports………………………………………………………………………………………………………………….7 1.11 Value Added Services ....................................................................................................................................... 8 1.12 Acceptance ................................................................................................................................................... 10

2.0 TECHNICAL PROPOSAL ...................................................................................................................... 11

2.1 Solution Architecture ...................................................................................................................................... 11 2.2 System and Data Security ................................................................................................................................ 11 2.3 Integration .................................................................................................................................................... 25 2.4 Development Plans ........................................................................................................................................ 27 2.5 Implementation Process .................................................................................................................................. 29 2.6 Support and Service Level Agreements (SLAs) ................................................................................................... 40 2.7 Student Transcript Request and Processing the Request ....................................................................................... 45 2.8 Institution Delivery Process ............................................................................................................................. 56 2.9 Notification Process ....................................................................................................................................... 59 2.10 Reports………………………………………………………………………………………………………………...60 2.11 Training ........................................................................................................................................................ 64 2.12 Documentation .............................................................................................................................................. 65 2.13 Proposal and Solution Documentation .............................................................................................................. 66

3.0 MINORITY PARTICIPATION .............................................................................................................. 71

4.0 OFFSHORE CONTRACTING ............................................................................................................... 72

5.0 QUALIFICATIONS ................................................................................................................................. 73 5.1 History of the offeror's experience in providing work of similar size and scope. ...................................................... 73 5.2 Financial Statements. ...................................................................................................................................... 75 5.3 References .................................................................................................................................................... 76 5.4 Customer List ................................................................................................................................................ 80 5.5 List of failed projects, suspensions, debarments, and significant litigation. ............................................................... 86 5.6 List the development resources in place to maintain and enhance the electronic transcript solution. ........................... 86 5.7 Organizational Structure of Programs. ............................................................................................................... 87

6.0 Appendix I Docufide by Parchment Screenshots ..................................................................................... 89 6.1 Student Workflow Screenshots ......................................................................................................................... 89 6.2 Sender Administrator Screenshots .................................................................................................................... 97 6.3 Receiver Administrator Screenshots ................................................................................................................ 105

7.0 Appendix II Corporate Security Policy ................................................................................................... 108

8.0 Appendix III Service Levels ................................................................................................................... 118

9.0 Appendix IV IData Requirement and Design Document ...................................................................... 120

10.0 Appendix IV PESC Seal of Approval Notification .................................................................................. 139


2

1.0 MINIMAL REQUIREMENTS

1.1 Solution Architecture

1.1.1 The proposed solution must be web-based and vendor hosted. Parchment provides fully functioning, field proven Software as a Service (SaaS) offerings for the processing of electronic records across educational institutions globally. Parchment’s solutions are designed from the ground up to meet the needs of all participants (students, PK-12 schools, colleges and universities, professional associations, employers and other designated recipients).

1.1.2 The vendor’s solution must not require the purchase of dedicated servers or additional software to satisfy the installation and ongoing maintenance of the electronic transcript solution.

Parchment’s Docufide Platform does not require the purchase of dedicated servers or additional software.

1.1.3 The Offeror’s solution must be compliant with accessibility standards for electronic and information technology under Section 508 of the Rehabilitation Act, as amended.

Parchment’s Docufide Platform is compliant with current and emerging industry exchange standards including the Postsecondary Electronic Standards Council (PESC) high school and college XML transcript and SPEEDE/ExPRESS standard, as well as with Federal COPA and FERPA requirements. As the leader in the electronic transcript exchange industry Parchment is the first company to receive the official PESC Seal of Approval.

We are constantly making enhancements to our site to meet the technical and functional requirements of Section 508 of the Rehabilitation Act, and will continue to do so to ensure all constituencies have access to the Docufide.com and Parchment.com features and functionality. Our site can be viewed using a screen reader, and we continually work to optimize our site for screen readers and other accessibility tools.

1.1.4 Payment processors for the vendor solution must be Payment Card Industry (PCI) compliant.

As an online merchant, Parchment is in compliance with the Payment Card Industry Data Security Standards (PCI DSS). This compliance has been validated by Trustwave, a Qualified Security Assessor for PCI DSS compliance. The Docufide.com web site contains the Trustwave compliance seal, and users may click on this seal to obtain additional information regarding Parchment’s PCI DSS compliance.

https://www.section508.gov/index.cfm?fuseAction=stdsdoc


3

1.2 User Authentication

1.2.1 The solution must provide a way to authenticate enrolled students, former students, as well as registrars and transcript administrators at each institution.

Mechanisms are used to prove the identity of users, objects, and processes, usually as a prerequisite to granting access and applying access control restrictions. Authentication requirements specify attributes of the authentication mechanism and how the system will protect this information.

The system provides a mechanism to authenticate the claimed identity of a user. The system performs the entire user authentication procedure even if the user ID that

was entered was not valid. Error feedback shall contain no information regarding which part of the authentication information is incorrect.

The system provides a mechanism to support the initial entry or modification of authentication information.

The system incorporates alternative authentication mechanisms, such as token-based cards, biometrics, or trusted third-party techniques, in place of or in addition to the system-supplied authentication mechanism.

The system requires a privilege to access any internal storage of authentication data. The system supports an application program interface to an authentication mechanism. If the system provides network access (e.g., dial-in, X.25, or Internet), then it also

provides at least a Class 2 authentication mechanism (as defined in Draft International Standard 10181-2) that can be used at the customer's discretion. The networking software can be disabled or configured out of the system.

1.2.2 The solution must provide a way to pass authentication to an institution’s student portal and to the institution’s student information system (SIS), if required by the institution (LDAP authentication).

Parchment offers two single sign on methods, a proprietary Parchment API and Incommon Federation’s standard. When using either of these SSO options, Parchment utilizes the postsecondary institution’s existing authentication protocols to authenticate the student within Parchment.

Lastly, Parchment requests that secondary and postsecondary students and alumni electronically sign a FERPA compliant Transcript Authorization Form as part of the registration process. This electronic signature is kept on file and may be withdrawn by the student at any time.

1.3 Document Compliancy

1.3.1 All transcripts sent and received must be FERPA compliant.

The Parchment Docufide Platform is fully FERPA compliant. Once transcript data is processed from the sending institution to Docufide’s Secure Server, Parchment stores the records in standardized XML, allowing the system to then crosswalk to the recipient selected format for delivery (PESC XML, EDI, certified PDF and, when no electronic means are available, onto printed security paper). Parchment delivers records through a secure online download center that allows authorized recipients to login to their account, view student transcripts/records awaiting download; confirm download and real-time


4

have the records retrieved and processed for download to the recipients computer through the SSL encrypted internet connection. The Docufide delivery service supports all standard web browsers.

1.3.2 All transcript sending and receiving transactions (i.e. student extract file, transcripts, etc.) must be encrypted.

All data transmitted to the end user’s browser is encrypted via TLS with 128-bit SSL as a fall back only for older browsers. Web service API data transfer is authenticated via OAuth and transmitted with TLS security. SFTP traffic is encrypted using a shared private key.

1.3.3 All transcripts must be decrypted after the transcript has been retrieved by the intended recipient.

Through our Docufide Receiver Limited service transcripts are received through the Docufide secure download center in a pdf format. Alternatively, for institutions that elect to upgrade to the Docufide Receive Full, Parchment can establish a sFTP connection allowing the automatic download of pending records into a staging server at the receiving institution. This automated receipt to a staging area is an approach that is growing in popularity among postsecondary institutions receiving PDF and standards-based data transcript files from Parchment. Third parties are emailed a link where they proceed to our site for a secure download of the electronic transcript.

1.4 Output Formats

1.4.1 Output methods required to support the electronic transcript solution must include at a minimum

With the recent merger with AVOW Systems, Parchment will be able to offer institutions either a secure PDF or PESC XML delivery format.

a. Secure PDF (using the Adobe Secure Blue Ribbon Banner or equivalent)

Avow’s Document Authentication Service provides document security by applying a certifying digital

signature to the digital document. This module accepts the digital document (PDF), applies trusted

certification through a digital signature using an institution specific digital certificate, and passes to

other +ADDS™ components (i.e. Rights Management or Document Delivery). The result is a “certified”

PDF document that automatically indicates authenticity and integrity of the document to recipients

simply by viewing the document with Adobe® Reader® or Acrobat®.

b. PESC XML

Parchment provides comprehensive transcript services resulting in high quality deliveries of the complete academic student transcript as defined by the institutions current transcript file generated from their student information system. We fully support industry-standard transmissions of the transcript as data in one of two formats including PESC XML, and TS-130 EDI (SPEEDE). Parchment has worked with PESC for several years and was on the taskforce that defined the XML format. We continue to work actively with PESC today and we have been awarded PESC’s seal of approval


5

1.5 Delivery Options

1.5.1 The proposed solution must provide the ability to deliver transcripts in-state and globally in the following formats:

a) Secure download (Automated SFTP/WSDL or equivalent)

b) USPS and overnight delivery (or equivalent for international delivery)

Parchment allows the recipients of our network to choose their preferred delivery format to include secure download and USPS & overnight delivery. Parchment delivers transcripts as an electronic PDF document either to the secure Parchment download center or through a sFTP service. Over two thirds of all transcripts are now delivered by Parchment electronically. Through our Docufide Receiver Full service, institutions have the ability to receive transcripts via data, either XML or EDI. In addition, to address the need of 3rd party recipients and institutions that will not receive electronic transcripts, Parchment has also delivered hundreds of thousands of transcripts via first class mail on security paper from our secure transcript processing facility. The ability to send transcripts internationally and overnight via FedEx is also a standard feature of the Docufide Sender comprehensive service offering.

1.6 Institution Customization

1.6.1 The solution must allow document branding at no cost. The Parchment solution does allow document branding at no cost.

1.6.2 Branding must include the institution’s logo on all primary screens for the student request process as well as the transcript delivery process.

The institution’s logo can be placed on all primary screens through the student request and delivery process.

1.6.3 Branding must include the institutional logo on the transcript as well as an institutional watermark if the institution so requests.

The institution may include their logo/seal, digital signature and appended legend. If the institution requests the watermark be present they can choose the image delivery option.

1.6.4 The awarded vendor will not charge for configuration option changes. There is no cost for configuration options.

1.7 Student Transcript Request Process

1.7.1 The transcript request function must provide a transcript request portal for a currently or formerly enrolled student to request an institution to either send the transcript directly to the student or to send the transcript on to other institutions.

The Docufide Sender service allows for current or former students to request their transcript from the Parchment provided user interface or through a single sign-on integration (SSO). The SSO is a


6

documented web service that allows students to link from the secure college portal website directly to the transcript request workflow within a single session. Students and alumni can request transcripts to be sent to any institution or global destination, with real time online order status. Additionally, notifications will be provided throughout the request and delivery process, utilizing the user’s email verified during registration.

1.7.2 The student must be allowed to use a credit or debit card to process their transcript request.

Certain document request services offered through the Parchment application have associated fees, and users may pay these fees by using their credit or debit cards in an online transaction. As an online merchant, Parchment is in compliance with the Payment Card Industry Data Security Standards (PCI DSS). This compliance has been validated by Trustwave, a Qualified Security Assessor for PCI DSS compliance.

1.7.3 All credit card processing must be built into the electronic transcript solution and the vendor must specify their credit/debit card processing partner(s).

Parchment uses Authorize.net for all credit card processing and this is built seamlessly into the Docufide Sender service. Parchment does not store any credit card information.

1.7.4 The awardee will not hold the institution or the State of South Carolina, South Carolina Commission on Higher Education or any associated agencies or institutions responsible for any issues, collections or litigations that arise due to credit/debit card fraud or card default on the part of the student.

Parchment will not hold the institution, the State of South Carolina, the South Carolina Commission on Higher Education or any associated agencies or institutions responsible for any issues, collections or litigations that arise due to credit/debit card fraud or card default on the part of the student.

1.8 Student Transcript Receipt

1.8.1 The receipt to the student must show the detail associated with all fees and charges. Upon completion of a transcript request the user is presented with an onscreen receipt which may be printed, as well as an official copy of their receipt sent to the email account listed on their profile.

1.9 Notification Process

1.9.1 Email notification regarding the status of the transcript must be sent to the student and the delivering/receiving institutions throughout the transcript process.

Parchment has a number of notifications built-in to the system that communicate transcript transmission details to the requestor (when a request is received, when records are released by the school, and when the transcript is delivered), sender (when requests are waiting processing), and receiver (when transcripts are awaiting download).


7

Numerous escalation notifications are also built-into the system; ensuring requests are processed and received in a timely manner. No record or transcript goes undelivered. All system users (students, school admin. and receivers) have online web-based access to real-time transaction reporting, viewable from within the user account.

Confirmation, notification and escalation emails are triggered at a number of points throughout this process. Notifications include the following:

Sending Schools

Notification of outstanding transcripts pending approval

Escalation of transcripts pending approval

Escalation of transcript not received

Receiving Colleges

Notification of transcripts pending download

Escalation of outstanding transcripts pending download

Escalation of transcript not confirmed as received

To Students

Confirmation of transcript request

Notification of transcript placed on hold

Confirmation of transcript approval and delivery

Confirmation of electronic delivery

1.10 Reports

1.10.1 Standard reports and audit trails must be available with the proposed solution. The Docufide Platform includes built-in, comprehensive reports, accessible through the administrator’s Reports tab. This tab providing authorized users the ability to look-up individual student transcripts or run reports reflecting all transcripts requested, approved and/or delivered, by date. Additionally, reports can be filtered by order/processing status, with the ability to click on each active hyperlink to review the transcript file in its entirety as a PDF file. All queries run can be exported into Excel for further analysis.

Additional sending school reports information:

Reporting interface allows for look-up of student record and transcript transmission statistics against a number of parameters, including student name, unique document ID, date range, recipient, and order status. A screen viewable transcript/student record is available by clicking on the hyperlinked student name.

Authorized administrators can set preferences, track records/transcript delivery, run comprehensive reports, and access participating school/institution directory information all through any common web browser.

In addition to transactional reporting, Docufide provides dashboard reporting as a means to graphically represent a customizable view of a preconfigured dataset. Our user-defined dashboards present a real-time depiction of performance related to key business indicators.


8

1.11 Value Added Services

1.11.1 Offerors are encouraged to include any information or technical capabilities not required. This area will not be evaluated for scoring purposes.

Docufide Receiver:

Docufide Receiver connects Post-secondary Institutions to a broad network of Docufide Senders for streamlined electronic transcript exchange and direct transcript request (from students and other institutions). Docufide Receiver enables school administrators to translate credentials data into intelligence to improve recruitment and compare against peer institutions. Trusted by thousands of postsecondary institutions from small private colleges to large, multi-campus universities and career colleges, Docufide Receiver is the solution of choice for rapid, reliable receipt of online education credentials.

Receive automated data feeds: rather than manually downloading and scanning transcripts.

Reporting: Gain insight into transactional information such as number of transcripts

received over selected time periods.

Automated Workflows: Receive Index file(s) with prepared transcripts and admissions

documents for automated data import into your SIS or enterprise content management

system.

Manage Transcript Requests: Automate transcript collection and get applicant permission

to request on their behalf.

Multiple Data Formats: Take advantage of flexibility in receiving transcripts as PDF, TIF, or

data (PESC XML or SPEEDE EDI).

Secure Private Institutional Library: Easily retrieve and analyze all past transcripts via your

private archive library.

Auto Delivery (SFTP/Web Services): Auto-receive transcripts to an FTP location in place of

manual downloading.

Role-based Security: Control access by defining appropriate security levels by user groups.

Email Notifications: Inform system users when documents are available for download.

Analyze applicant and transcript data to continually improve student recruitment processes

and compare against peer institutions.

Eliminate costly and time-consuming processes by bringing the receipt and analysis of

transcripts completely online.

Each of the Higher Educational institutions that choose to participate within the Docufide Receiver network will be able to access Key Performance Indicators (KPI’s) allowing them real time insight their receiving network of schools. When the receiving institutions have transcripts to consume they will be notified via email and will be given a link within the “Items Needing Attention box”.


9

When a higher education receiver has transcripts ready to consume, they can choose to download those

transcripts in their preferred image format PDF TIF or if they prefer to consume a data version of the

transcript in PESC XML format. Accompanying the image or data file will be an index file with meta-data

to assist receiving school in integrating the transcript data with existing campus technologies.


10

1.12 Acceptance

1.12.1 Each institution and the awardee will define their acceptance criteria prior to the commencement of the implemented solution.

Upon completion of the agreement with the South Carolina Commission on Higher Education, Parchment staff will work with each institution within the State, that wishes to participate in the Electronic Transcript Services project to define the acceptance criteria prior to the implementation of the solution.


11

2.0 TECHNICAL PROPOSAL

2.1 Solution Architecture

2.1.1 The Offeror must validate compatibility of the proposed solution with the following:

2.1.1.1 Internet Explorer, Safari, Firefox and Chrome web browsers and the web browser versions supported;

Parchment’s transcript exchange system is a hosted SaaS application that has been designed to be secure and highly scalable. All of Parchment’s user interfaces are 100% web-based, support access across all common browsers and platforms, and have benefited from valuable user feedback and enhancements for over nine years of use. Browsers currently supported include Internet Explorer 7, 8 and 9, all major versions of Firefox, Chrome, and Safari. Our hosted SaaS platform is being continuously enhanced to support new browsers as they are released to the market by browser vendors.

2.1.1.2 Apple (MAC, iPhone, iPad), Microsoft (PC) and Android products Because we are as Software as a Service (SAAS) platform Docufide sender is available to any device that has access to the internet.

2.1.1.3 Windows operating system and indicate the versions supported No operating system requirements.

2.1.1.4 Microsoft products: Excel, PowerPoint and Word, as reports and screens are downloaded.

Parchment reports can be exported to Excel and that data can be used in any Microsoft Office products.

2.1.2 If any incompatibility exists, please describe the steps you will take to make your solution compatible.

No incompatibility exists.

2.2 System and Data Security

2.2.1 The offeror must describe:

2.2.1.1 The server environment that will support the proposed solution and must provide a diagram that shows evidence of system redundancy to ensure failover capacity, secure server and network environment, internet security. (i.e. standards such as ISO27001, ISO27002, ISO15408 and RSC2196).


12

Logical Network Diagram

Firewall - Our network is protected by state-of-the-art redundant Sonicwalls, filtering traffic from the Internet. Attacks are intercepted and rejected at the network edge, keeping our clients' data secure while providing high performance to the traffic that does need to get through. This includes segmenting the network to provide zones of security for our client-facing services, our partners, and our internal services and back-end components.

Load Balancer - We utilize high performance commercial load balancing products from A10 networks to evenly distribute load among our application farms to ensure that there is always reliable access to our three main application areas – CMS, Parchment.com Portal, and Docufide® by Parchment™.

Web Service Tier - Our web tier provides our main site (http://www.parchment.com), our Parchment.com consumer portal (http://www.parchment.com/c/), our Docufide® by Parchment™ portal (http://www.parchment.com/p/ or http://www.docufide.com) and our Docufide® by Parchment™ application (https://securetranscript.docufide.com/admin/). The web cluster is composed of a number

Perimeter Firewall

DB Servers

FTP Server

(Prod)

Web Services 02

(Prod)

Render Servers

Render Servers

DB Servers

Render Servers

DB Servers

Internal Firewall Border Router

Load Balancer 01

Web Services 01

(Prod)

Web Services 03

(QA)

Web Services 04

(QA)

DB Replication

Admin Servers

Web Service 05

(Dev)

Load Balancer 02

Internet

Production

QA Development

8/31/2012Logical Network

DiagramA 01.00

Parchment


13

of virtual machines running on high-end Dell hardware deployed as load balanced groups (at least two), which are supported by Dell’s 4-hour onsite support service.

CMS Servers - The CMS servers service requests for the static web pages associated with Parchment’s corporate presence. The content is maintained and served up by the Drupal open source content management system. The servers run Apache and PHP and interact with a PosgreSQL database co-located with our transactional database in the DB tier.

Parchment.com servers - The Parchment.com servers run and execute a combination of Apache and PHP and serve as both the web service and application service for the Parchment.com consumer portal. The servers are load balanced in a pair of virtual servers.

Docufide by Parchment Servers - The above diagram is conceptual to the extent that the Docufide by Parchment servers are further subdivided into three main server sets – Client traffic (proddfc), web traffic (prodweb), and web services traffic (prodws). It is worth nothing that the bulk of Docufide Sender traffic comes through the client servers; the bulk of Docufide Receiver traffic comes through as web traffic; and the bulk of our Naviance partner traffic comes through prodws.

Docufide® by Parchment™ application tier – This tier represents the set of servers dedicated to providing the functionality of all Parchment services. Each set of services is scalable and capacity can be increased by adding new resources, generally in the form of new virtual machines, to a given cluster.

Production Web Cluster (ProdWeb) – The prodweb cluster acts as both the main receiver / responder for customer web interactions.

Web Services Cluster (ProdWS) – This cluster of machines handles the web requests from our integrated partners, and provides a programmatic interface to Parchment.

Parser Cluster - The parser component handles breaking out the data in transcripts and other documents uploaded to the web server from record holding institutions (RHs). Data extracted from uploaded files is stored in the Secure Transcript records database.

Render Cluster - The render component handles building a Docufide® by Parchment(tm) transcript out of the data from the database and producing the PDF, either for viewing through the web or for secure document delivery to a receiving institution (RI).

Back End Processing (BP) Cluster – This cluster handles the entire back end processing, whether this be SFTP, secure download, printing for physical mailing, etc.

Database Tier - We currently have five deployed database servers that provide all of our components with fast and reliable access to all of our student and client data.

Data DB (Postgres 9.0): This database server provides two databases. One serves as the main transactional database server for the Docufide® by Parchment™ application and the Parchment Discover application. The second serves as the repository for static web page content.

o Data DB replica (Postgres 9.0): This database server is a read-only replica of the main DataDB. One of the main benefits to our deployment of PostgreSQL 9.0 in August of 2011 was the ability to leverage binary replication for HA purposes.


14

Binary DB (Postgres 9.0): This database server provides the physical storage for the actual transcript files in binary (BLOB) XML form. While quite large, it does not receive a lot of load.

o BinaryDB replica (Postgres 9.0): This database server is a read-only replica of the main BinaryDB. One of the main benefits to our deployment of PostgreSQL 9.0 in August of 2011 was the ability to leverage binary replication for HA purposes.

Data DB (MySql 5.1): This database serves as the transactional database for the Parchment.com™ consumer portal. It is currently backed up on a production schedule (nightly full, hourly partial), but is currently not operating in an HA mode.

NAS/SAN Storage - We have highly available and high performance storage on our network that provides disk based storage to our systems individually or as a cluster, depending on needs.

Our storage environment consists of a mixture of technology, utilizing Dell PowerVault for caching of backups; Compellent storage for high transaction production databases and NetApp for Virtual machine shared storage. Each of these technologies has been selected and tuned for the specific application for which it has been deployed allowing us to leverage the strengths of each technology in the area where it provides the maximum value for the least cost.

2.2.1.2 How the following system and data security processes will be accomplished for:

2.2.1.2.1 Processing payment for the transcript request As an online merchant, Parchment is in compliance with the Payment Card Industry Data Security Standards (PCI DSS). This compliance has been validated by Trustwave, a Qualified Security Assessor for PCI DSS compliance. The Docufide.com web site contains the Trustwave compliance seal, and users may click on this seal to obtain additional information regarding Parchment’s PCI DSS compliance.

2.2.1.2.2 Registrar’s office accessing and processing request resends or internal requests at no cost

With Parchment’s secure network, recipients have registered to receive a transcript in their preferred electronic format. Because this is an end to end closed electronic transcript solution, we are able to pinpoint when the transcript was delivered and who it was delivered to. If for some reason there was a download error we would make that transcript available for download again to the recipient at no

charge to the requestor or institution.

2.2.1.2.3 Securing transcript data during transmission and preventing unauthorized online viewing, printing, or modification of protected and confidential information

Information security is core to Parchment’s mission. Parchment maintains high security standards throughout its architecture, maintaining data integrity and protecting student and other personally identifiable data from unauthorized access throughout the data capture, storage and delivery cycle. Electronic Data Transmission Security – Student record data can be uploaded to Parchment servers from record holder institutions through one of the following methods:


15

Docufide Client Application – This Parchment-developed software application is installed on the

institution’s computer where transcripts and other student records are normally printed.

Through a proprietary print driver component, student record data is captured as a print file,

tagged with metadata, and transmitted to Parchment servers through a secure Internet

connection using Secure Sockets Layer (SSL) protocol. This provides both authentications for the

communication process as well as strong encryption for the transmitted data. As an additional

security safeguard, all data files sent from record holder institutions contain a unique institution

identification number that identifies the sender of the files to the Parchment datacenter

servers.

Web Browser Upload – Transcripts and other student records can be uploaded by the sending

institution through a web browser interface. As with the Docufide Client Application, SSL

protocol is used to provide encryption and authentication for the connection, and the sending

institution is required to log in to the document upload service by providing a Parchment-

assigned username and password.

Web Service / Secure FTP – Parchment also provides both Web Service and secure FTP (SFTP)

connection options for uploading student record files. In both cases, the internet connection is

based on the use of certificates and Public Key Infrastructure (PKI) encryption, in addition to the

use of username and password login credentials.

Record Holder (RH) Transmission Authentication – As part of the Parchment Client Application software installation at the record holder’s site, Parchment provides the installing institution with a school identifier code that is entered into the computer during the installation process. This identifier code is transmitted from the sending computer at the RH institution when transcripts or other student records are uploaded to Parchment for processing. This code is used to identify and authenticate the sending institution and should be treated as confidential by the sending institution. In the event that it is suspected or confirmed that this code has been communicated to unauthorized personnel, or used in an attempt to circumvent the authentication process, the sending institution’s account will be deactivated until a new identifier code can be issued.

Electronic Transcript Delivery Security - Student record data can be delivered to receivers through the following secure options:

Web download – Receiving institutions that receive student records through the Docufide web download interface must first register as an authorized receiver with Parchment. This registration process verifies the receiver’s identity and provides login credentials that allow the receiver to sign in to the secure Docufide download site. A transcript in electronic format is downloaded to the receiver through a secure HTTPS internet connection that provides authentication of both sender and receiver and encrypts the data en route.

Automated Data Delivery – Student records in electronic format (PDF, XML, EDI) may be optionally delivered through automated interfaces such as SFTP and Web Services. These delivery methods require the use of certificates and PKI infrastructure to authenticate the data sender and receiver and provide strong encryption.

Paper Transcript Delivery Security– If a receiving institution has not registered with Parchment, the default delivery method for that institution is via first class mail and transcripts are delivered through


16

the United States Postal Service (or overnight delivery, when requested by the student/parent). Unregistered receiving institutions must be identified as authorized accredited receiving institutions in Parchment’s database. Registered institutions can also elect to receive paper transcripts by mail. Transcripts are printed on security paper (to prevent copying or modification of data) and barcode scanned prior to mailing to initiate notification of delivery back to the requestor. Printed transcripts remain under the control and supervision of operations level or above personnel at all times and are never left unattended. The sealed “no-peek” transcript envelopes are delivered directly to a USPS facility for mailing. Each transcript is assigned a unique ID number (printed on the transcript) that enables students and administrators to track the status of the transcript through the web sites reports interface.

2.2.1.2.4 How the proposed solution monitors overall system usage (number of transcripts transmitted per institution, etc.)

The Docufide Platform includes built-in, comprehensive reports, accessible through the administrator’s Reports tab. This tab provides institutions the ability to look-up individual student transcripts or run reports reflecting all transcripts requested, approved and/or delivered, by date. Additionally reports can be filtered by order/processing status, with the ability to click on each active hyperlink to review the transcript file in its entirety as a PDF file. All queries run can be exported into Excel for further analysis. Additional sending school reports information:

Reporting interface allows for look-up of student record and transcript transmission statistics against a number of parameters, including student name, unique document ID, date range, recipient, and order status. A screen viewable transcript/student record is available by clicking on the hyperlinked student name.

Authorized administrators can set preferences, track records/transcript delivery, run comprehensive reports, and access participating school/institution directory information all through any common web browser.

In addition to transactional reporting, Parchment provides dashboard reporting as a means to graphically represent a customizable view of a preconfigured dataset. Our user-defined dashboards present a real-time depiction of performance related to key business indicators.


17

Dashboard shows overall system usage.

2.2.1.2.5 How the proposed solution will handle multiple student records requests appearing at a single institution for records from multiple institutions;

Each request is given its own unique identifying number (DID#) within a multiple order request. This information is available to the requestor within their status and history page. Here they can see the status of their current requests as well as any former request sent through the Docufide platform.


18

The administrator will run reports based off student name, unique id or recipient information in order to determine status or find more information about each request.

2.2.1.2.6 The features built into the system to maintain control by the sending institution of its student records;

Within the administrative preferences console under Transcript Approval Settings, individual institutions can make the determination if they want to have auto approval of each request or if they want approve each request individually.


19

2.2.1.2.7 How the proposed solution checks for duplicate records and must describe how duplicate records are reported through the proposed solution;

Parchment developed integration of the Docufide Sender platform with institutional systems will consist of two main components, the IDataHub integration tool and enhancements to the Student Information System (SIS). The IDataHub, a stand-alone Java-based integration tool, will periodically poll the Docufide system for pending transcript requests using existing Docufide APIs. Upon receiving a transcript request, the IDataHub will locate the requesting student in the SSI SIS and will produce a transcript using the details provided by Docufide.

If the requesting student cannot be found within the SIS the IDataHub will return a hold to Parchment and the school will be notified using a daily digest. In the event that multiple students are found within the SIS, a user will need to manually determine which, if any, of the found students matches the request. The matching criteria used to determine a potential duplicate record is based off of the matching methodology each campus currently has in place within the individual campus SIS. The IDataHub will contain a student resolution form to aide with identifying the matching student.

This page will hold the students with duplicates that need to be manually resolved.


20

This table is used to store student information while the request is pending because duplicates have been found. This table will reside in the IDataHub H2 database, not in the school’s database.

Field Notes

ID Internal ID used to match to the Request Holding Table

LAST_NAME

FIRST_NAME

MI

ERP_ID Banner ID or Colleague ID if the request has been entered using the school’s portal

STREET_LINE1

CITY

STAT_CODE

ZIP

NATN_CODE

CNTY_CODE

PHONE_AREA

PHONE_NUMBER

SSN

BIRTH_DAY

BIRTH_MONTH

BIRTH_YEAR

GENDER

EMAIL_ADDRESS


21

2.2.1.2.8 How the proposed solution responds when transaction limits or file limitations are reached. The proposal will explain the type of notification that is sent to the sending or receiving institution to alert them that certain limitations have been reached in the system

Parchment’s systems have been designed, built, and enhanced to be scalable and well performing. Parchment understands the importance of performance and scalability as proven by its success with state-wide deployments in Illinois, Indiana, Michigan, Kansas, Ohio, Pennsylvania and South Carolina large scale implementations with state college systems in Arizona and Alaska, and direct high school and college installations nationwide. In the event that notifications need to be expressed to our customers, the system has capability of producing notification messaging directly within the user’s administrative console.

We plan to be in a position to handle at least 3-4x of potential peak volume. Our business (and load) has historically been growing at about 2-3 times a year, so we are thinking at least a year in advance. We have two major transaction volume peaks during the year and constantly monitor web server, database and Internet connection load. After each peak we analyze whether we will be able to handle 3-4x next year and if not – properly improve the software and scale the system.

Performance and Scalability are achieved using the following approaches:

The building blocks upon which the solution is based have proven security, reliability, performance, and scalability. Red Hat Linux Enterprise (64 bit), Apache (mod_php), Java 6, Tomcat 6, JBoss 4, PHP 5.3 (w/ APC update cache), Postgres SQL 9.0, MySQL 5.1. These building blocks are utilized in thousands of web sites and web applications, some of which are the largest in the world.

Each component of the system can be scaled. For example, utilizing our front-end Load Balancer (LB) additional front-end web servers can be deployed as system load increases, additional and larger database servers and SAN’s can be deployed as required. This is a proven and battle tested methodology to achieve scale.

The system is built in a multi-tier configuration with separation of user presentation, business logic, and data access. Currently these are deployed together on the web servers.

Performance is achieved through careful application of industry best practices for performance (http://developer.yahoo.com/performance) use of an ADC (compression, tcp/ip optimization, etc), database tuning, and code profiling and optimization.

System load, performance, responsiveness, etc., are monitored and actively managed across a growing infrastructure landscape consisting of the following:

o 38 production systems o 152 CPU cores o 288GB of RAM storage o 16TB of useable storage

In practice, the primary scaling strategy is to use our A10 Load Balancer in combination with VMWARE virtual servers to distribute load to various system components, scaling those components as needed:

The web-tier & application tier (ST Application) is load balanced and additional servers can be added.


22

The parsing farm is load balanced and additional servers can be added.

The producer farm is load balanced and additional servers can be added.

The rendering farm is load balanced and additional servers can be added.

System performance and throughput are monitored through the use of the Zabbix (http://www.zabbix.com) and enterprise class open-source monitoring tools. The screens configured in Zabbix provide our team with the ability to make the determination of either normal operations or when we may need to potentially reduce load on the system in one of several ways:

Shut down background maintenance tasks

Limit the number and types of internal reports. (Becomes moot in Dec with movement to replica DB)

Set a limiter on the number of available threads dedicated to upload processing

Slow down or turn off the producer thus reducing the demand on the delivery part of the system.

While these tuning parameters are present, our goal is to never have to use them.

Backup and Disaster Plan

Parchment’s disaster recovery and business continuance plan is made up of redundancy on the server level, the datacenter level, and the business office level.

Within the individual datacenters (ISWest in Agoura Hills California, and Raging Wire in Natomas, California) Servers are set up in a high availability model within VMWare’s VSphere software and attached to a redundant set of network attached storage. This allows the environment to absorb a hardware failure of a physical server with a minimum of downtime; virtual servers are simply re-started on another physical host.

Regionally, the datacenter in Agoura Hills has server images and data replicated in the Natomas California datacenter (regionally separated by > 400 Miles). This allows production to be resumed in the Natomas datacenter should the primary datacenter in Agoura Hills become a total loss. Failing over regionally is accomplished through re-routing network addresses to the fail-over site, requiring moderate downtime.

Should the primary office location in Scottsdale Arizona become unavailable, Parchment maintains a software development office location in Roseville California with sufficient space and connectivity where business operations could be resumed. Network connectivity between Scottsdale, Roseville, Natomas, and Agoura Hills is maintained over a Virtual Private Network allowing business to resume immediately in the Roseville Office in the event of a disaster in Scottsdale.

Parchment utilizes a two stage backup process that involves current backups being sent to a raid 5 redundant disk array on site which both improves speed of backup and recovery as well as eliminating the need to recall tapes for short term restoration. The raid array is then nightly sent to tape which is rotated off site providing for a disaster resistant recovery model. In addition, backups of both virtual machines and databases are replicated in the backup datacenter in Natomas, CA.


23

2.2.1.2.9 The application development and coding business practices, tools and techniques employed to ensure quality and security of the code associated with the proposed solution.

The overall methodology we employ is an agile approach with reduced requirements documentation, collaborative design, and iterative development and test cycles. With the recent hiring of more developers in Scottsdale, AZ. and Roseville, CA,, and the incorporation of Release Engineering, we have made a few adjustments:

We have moved to a feature branch release model that ensures that trunk (the main code branch) remains stable. We focus on developing all new functionality in feature branches. The features are fully developed and tested in the feature branch in their own QA environment, and once they have passed Product Management acceptance and QA iterative acceptance, they are then merged back into trunk for release. The merged code is then fully tested by QA using feature and regression test plans. When Quality Assurance has signed off on the Release, a Go / No Go Meeting is held with the stakeholders.

The agile methodology is supported by the Rally SaaS software solution. The goal of moving to a SCRUM based approach is to build strong participation from product management, QA, development, and other resources, following scrum techniques, to better meet the business needs. We currently practice story creation, capture (backlog), Sprint planning, 3-week iterations (Sprints), Sprint reviews, Sprint retrospectives, and daily standups activities for current projects.

Parchment’s Quality Assurance Department is responsible for ensuring that all software is thoroughly tested and that it meets the functional and performance requirements set forth in the requirements specifications. The quality assurance process also verifies the accuracy and compliance with appropriate legislative and regulatory requirements of all documentation, reports, and file exports.

Parchment software is designed to facilitate both ease of learning and ease of use for the user communities: college and high school administrators, students and parents. Internet user interfaces are designed to guide users through the common activities that are performed, and minimize the amount of training required to exercise system functionality.

As Parchment provides a vendor-hosted solution, and all system maintenance and administration will be performed by Parchment, no technical, software, or maintenance documentation is required by the customer for maintenance and support of the system. For informational purposes, Parchment will provide documentation that describes the technical and operational characteristics of the system, including the installation of Parchment’s Client software and related system requirements. Parchment maintains an extensive online library of technical and operational documents that will be made available as requested.

To date, Parchment has developed a range of documentation and training materials. Parchment will provide user guides and reference documentation for end-users: students, parents, and secondary and postsecondary administrators. This documentation will be made available in both an interactive web-based format and as downloadable documents through the Parchment website. Including:

Web-based end-user tutorials and subject references


24

“Frequently Asked Questions” documents and web pages targeted to user categories

Technical and operations documentation

Online and PC-based demos

End-user Startup Guides

Promotional materials for use by school administrators to introduce and promote usage of the Parchment services by staff and students

Parchment continuously provides updated versions of deliverable documentation that reflect any system updates or enhancements that have been made.

The Director of Engineering Operations, who in turn reports to the CTO, manages all QA activities at Parchment. The QA test team works independently, but also works in collaboration with customer testing personnel to support the final acceptance testing process where joint development has taken place. QA test planning and execution are coordinated through the use of industry-standard methodologies and established QA documentation standards:

Updates on the internal wiki, meetings, and other methods are used to track and report on QA testing progress.

QA test plans define testing objectives, specific system functionality and user interface areas to be tested, and for each test to be performed: test action, test data (if applicable), expected and actual results. All QA test plans and artifacts are available on the internal wiki.

The testing techniques that are employed in the quality assurance program include: o Unit testing at the engineering development level, followed by integration testing by the

Parchment QA test team. o Iterative testing o White and black-box testing. o Volume/load testing as deemed appropriate. o Final acceptance and regression testing.

Parchment Quality Assurance Reporting

Each release is tracked using a Test Status Report detailing the original tickets approved to be worked, the additional tickets opened, fixed by Development, and tested by Quality Assurance. These TSR’s are sent out regularly throughout the release cycle to the stakeholders, ensuring transparency into the effort and status of the release.

Release Planning

Releases are planned starting with the Product Roadmap and the projected time frames for delivering to market. Once a set of features is aggregated, any important bug fixes that need to reach Production are also identified and added to the collection. The Product team meets with the Development and QA teams to determine how much of their Roadmap can be delivered within the time frame requested and a final list is prepared and distributed via email and posted to the wiki.

Release Management

When the deliverables and schedule are known, a Checklist is prepared with all of the due dates for each area to keep everyone on track from the first iteration through to the release post-mortem. This


25

Checklist is kept on the wiki for easy reference. In addition to the Checklist, a normal Project Management effort is maintained to guide the effort and provide transparency of the status.

Release Engineering

Releases are handled in a structured manner that includes:

Fully documented release plans with expected and actual timings, included components, required personnel, and relevant notes.

Release walkthroughs to make sure each group understands their roles

Structured mechanisms to move the code artifacts to the production systems in an orderly manner allowing for easy rollbacks if necessary

2.2.2 The Offeror must validate whether the transcript data is stored (once processing of the transcript is complete) in a vendor specific database:

The storage of transcripts within the Parchment database is a configurable option that many clients take advantage of to allow for more expedited processing of future requests. If a campus chooses to not have the transcript stored by Parchment, the transcript can be purged after a period of time upon completion of the transaction.

2.2.2.1 That is accessible by the vendor or participating third-parties Data access to completed transcripts is only allowed by specific employees for the express purpose of providing support. All access is logged and periodically audited by the CTO office to insure compliance with our employee security policies.

2.2.2.2 Is used for additional reporting Completed transcripts are not used for any reporting purposes unless specifically required as part of a contracted offering.

2.2.3 The Offeror must describe their data deletion/purge process and retention policy and whether the timing for deletion/purge is customizable.

Currently, data is retained as per contract terms on a contract by contract basis. At times, a completed transcript may be delivered to a student user of our Parchment.com service. At this time, the "ownership" of that delivered transcript transfers to the student and the transcript will be retained until such time as the student instructs us to purge their account.

2.3 Integration

2.3.1 The Offeror must describe their approach for integrating data from the electronic transcript to the student information system (SIS) at the receiving institutions and show evidence of where their integrated solution has been implemented (naming the state and institution) for the student information systems listed below:


26

Required Sungard Banner (now Ellucian) Datatel Collegue (now Ellucian)

Optional PeopleSoft PowerCAMPUS (Ellucian) Jenzabar Homegrown Solutions

Parchment offers a fully integrated transcript request and fulfillment workflow through the utilization of an institutionally deployed middleware solution. By implementing a stand-alone technology solution, the Parchment offering requires minimal institutional resources to achieve full integration between the Docufide by Parchment transcript request interface and the institutional SIS. The middleware enterprise integration creates a fully automated workflow from the transcript request process through the approval, fulfillment and delivery functions, while maintaining the integrity of the institution’s defined business logic. Current Ellucian Implementations nearing deployment: College of Charleston (Banner) University of Alabama – Birmingham (Banner) Kansas City Kansas Community College (Datatel/Colleague) College of the Desert (Datatel/Colleague) Bucks County Community College (Datatel/Colleague)

2.3.2 The Offeror must describe how the integration solution connectors, or APIs, developed for the proposed solution are able to connect with and pass data to and pull transcript data from the following student information systems: Required Sungard Banner (now Ellucian) Datatel Collegue (now Ellucian) Optional PeopleSoft PowerCAMPUS (Ellucian) Jenzabar Homegrown Solutions

Full integration through the Parchment solution is accomplished by the utilization of a series of web service API call and response methods between the Docufide platform and the middleware. Periodic calls are made from the middleware to Docufide, which returns pending transcript requests placed through the student interface. Once the request is passed to the middleware, existing SIS matching logic is evoked to ensure adherence with institutional student matching procedures. Requests that do not match to a student person record within the SIS are presented within the middleware for further resolution by institutional staff. A confirmed student person record match will populate the SIS


27

transcript request table and initiate an evaluation of the institution’s transcript approval logic. If the logic prevents a transcript from being produced, the middleware returns a hold to Docufide. This is communicated to the student via email. If no hold is present, an approved request will generate a transcript output file, utilizing the existing SIS functionality. Fulfillment of the transcript request occurs as the transcript output file is passed from the SIS, through the middleware, then back to Docufide, where it is processed for delivery to the receiving institution, in their desired format

2.3.3 The Offeror must describe how the integration solution connectors, or APIs, developed for the proposed solution are able to connect and pass data to the institution’s student portal and list the portals which you support.

The Parchment solution allows institutions to optionally pass students from an institutional portal into the students Docufide account through Single Sign On. Parchment provides APIs to support both Docufide proprietary Single Sign On protocol as well as inCommon Federation SSO protocols.

Once a student has authenticated in the institutional portal, they select an institutionally defined link to request transcripts. This triggers a web service call to Docufide with a unique student identifier, as well as optional student account registration data. Docufide returns a single use, time-limited, token. The institution passes the student to a landing page, and includes the token. On the first visit, the student must sign into an existing Docufide account, or register for a new account. If registering, any registration data passed is prepopulated for expediency. Upon sign in, or registration, the Docufide account is linked to the unique student identifier. In subsequent visits, this linkage allows the portal authenticated student to pass directly to the Transcript Ordering workflow, without resubmitting their Docufide credentials.

Docufide supports several Single Sign On configurations to allow institutions to define with great control the channels through which both current and former students can enter the Transcript Request workflow

2.4 Development Plans

2.4.1 The Offeror must describe their process for:

2.4.1.1 Determining enhancements and new development. New enhancements are determined by working with members of the Parchment Advisory Board, which is made of up 20 current clients representing a cross section of our overall installation base. We work with these individuals identifying functionality that represents a general market need that can be improved or solved through development. First, a round of discovery (qualitative research) is performed, generally through discussion with current or potential customers. Next, Product Management performs research to identify if this issue is a general market need, by discussion with a wider audience or by performing other research methods to determine if the need is pervasive. If the issue is determined to be general and can be solved by development, the enhancement is eligible for development. Items that are found to not be a pervasive market need can still be identified as necessary and included in the roadmap and are handled on a case-by-case basis. Beyond these scenarios, development opportunities can be incorporated into the roadmap dependent on evaluation of cost of development relative to size of contract.


28

2.4.1.2 Releasing system enhancements and a release schedule.

The overall methodology we began using in late 2011 as a beta, and across the board in 2012, is an agile approach with reduced requirements documentation, collaborative design, and iterative development and test cycles.

We use a branch release model that ensures that trunk (the main code branch) remains stable. We focus on developing all new functionality in feature branches. The features are fully developed and tested in the feature branch in their own QA environment, and once they have passed Product Management acceptance and QA iterative acceptance, they are then merged back into trunk for release. The merged code is then fully tested by QA using feature and regression test plans. When Quality Assurance has signed off on the Release, a Go / No Go Meeting is held with the stakeholders.

The agile methodology is supported by the Rally SaaS software solution. The goal of moving to a SCRUM based approach is to build strong participation from product management, QA, development, and other resources, following scrum techniques, to better meet the business needs. We currently practice story creation, capture (backlog), Sprint planning, 3-week iterations (Sprints), Sprint reviews, Sprint retrospectives, and daily standups activities for current projects.

Customers are notified in advance of a release, and when the development for a release has been completed, passes QA and exists in a stable state, the release can be pushed to production.

2.4.1.3 Distributing release notes to the institutions. Parchment provides release notes to member institutions based on license type. Ten business days prior to a scheduled release, Parchment will provide release notes via email to all accounts registered to each member institution with licenses impacted by the release. Additionally, release notes can be shared in advance with State project sponsor(s). This process would be defined as part of the initial relationship launch with the sponsor.

2.4.2 The Offeror must provide a planned list of enhancements and/or future releases, with proposed dates for each.

The following information is confidential and exempt from public disclosure.


29

2.5 Implementation Process

2.5.1 Related to implementation of the proposed solution, the Offeror must describe:

2.5.1.1 The staffing planned for the installation and deployment of the proposed solution with the level of effort typically required by Offeror, third-party partner, and institution to install, configure and integrate the proposed solution; and estimated


30

for an institution that implements both receiving and delivering functions as well as integration to an Ellucian student information system

For the duration of the project, Parchment will assign a dedicated Project Manager to oversee all objectives and deliverables. This individual will act as the primary point of contact for the SC CHE and each institution as they go live. The Project Manager also allocates all resources dedicated to school and student support. The Project Manager and additional assigned human resources span all US time zones.

These additional human resources include Account Managers, a Training Specialist, Technical Rollout Specialists and Customer Service Representatives. The Account Managers are responsible for supporting schools through the initial deployment and use of the software. The Account Manager will be available between the hours of 9 and 6 Eastern Standard Time, Monday through Friday and provides a response time of 24 hours or less. Customer Support representatives provide timely support in response to inbound web-form support requests. This support is provided both via phone and email and the Customer Support department maintains a 1 business day response time.

Additionally, end-user training is provided to all customers. Parchment offers two types of trainings: hosted training sessions and self-paced tutorials. Hosted training sessions are offered Monday through Friday and are typically 1 hour in length and cover the following topics: signing in to Docufide, approving and sending transcripts, updating school profile information, editing and updating sending services options, and finally, managing user access to Docufide. The self-paced tutorials are available for the end-user on demand, and 24 hours a day. The self-paced modules can either be used as the primary training source or as a refresher.

The level of effort required by the individual institutions will depend on which service each institutions wishes to deploy.

Docufide Client Print Driver:

Most institutions begin with the Docufide Client print driver while working towards a full integration implementation. Parchment’s standard Docufide Sender proprietary client installation will require less than 2 hours to install. We recommend the staff attend a one hour training session before go live. There is little to no technical involvement for this standard print driver implementation.

Student Information System Integration:

Parchment’s Professional Services team, led by a dedicated Implementation Project Manager, will create a customized integration plan for each institution.

This custom project plan will pinpoint major milestones, dates, and owners of tasks that are critical to ensuring a rapid deployment. The estimated time to implement this integration after project launch is approximately 8 – 12 weeks. Resources required from each institution will include representation from Registrar staff, IT infrastructure, DBA, and SIS development and administration.


31

Estimated resources to implement the SIS integration include:

ACTION LEVEL OF EFFORT PERSONEL REQUIRED

Environment Setup Implementation Design Transcript Output Preparation Single Sign-On Integration Testing Service Launch Planning Training

20 work hours 40 work hours 10 work hours 30 work hours 30 work hours 30 work hours 20 work hours

IT, DBA, SIS Administrator, Registrar IT, DBA, SIS Administrator SIS Administrator, Registrar IT, DBA, SIS Administrator IT, DBA, SIS Administrator , Registrar SIS Administrator , Registrar Registrar

Single Sign on Portal Integration

Schools that wish to link the order process to an existing portal should estimate the below level of effort associated with an SSO implementation.

Task Description Estimated Time

Create Code to call the SSO

Generate Stubs 2 hours

Connect to database Connect to database to provide the web service parameters and student information

1 day

Execute Web Service Run the web service with all parameters

2 hours

Handle Exceptions Receive an exception and update users

5 hours

Internal Testing Unit tests, code review, QA 3 days

Generate link in student portal Implement link in the student portal

1 day

Docufide Receiver Limited Service:

All of South Carolina Institutions are currently registered to receive transcripts electronically so there would be no level of effort to employ for our Receiver Limited service.

2.5.1.2 The certification of personnel assigned to this project Parchment’s implementation methodology consists of a team approach aligned to the client’s key performance metrics. The below matrix provides a summary of those areas of responsibility.


32

Areas of

Responsibility

Project Manager

Project Director

Software Development

Manager

Director of Services

Transcript Services

Sr. Project Manager

Account Manager

Project Management A R R I I I I

Systems Deliverables Administration

R R A R I I I

Services Rollout Administration R R I I I R I

Quality Assurance R C R R R R I

End-User Training R C I I R A R

Rollout and Ongoing Support R C I I A R R

Adoption R R I I I I A

Matrix Key: A = Accountable R = Responsible C = Consulted I = Informed

Rachel Stamm, VP of Programs: Ms. Stamm, Parchment’s VP of Program Management and Customer Services, brings over 10 years of experience managing school-based rollouts of state and federally funded projects for Extreme Learning. She joined Parchment in 2008 to take a lead project management position on the South Carolina e-Transcript Initiative; as well as other states launching through the region-wide e-Transcript Initiative awarded to Parchment by the Midwestern Higher Education Compact in August 2006 (12 state compact). Ms. Stamm is based in our corporate headquarters in Scottsdale, Arizona.

Mike Caruso, Associate Product Manager: Mike is a University of Arizona graduate and native of Sonoma, California, now living and working in Scottsdale. He is a product management professional with years of experience. He brings a focus on simplicity and user experience to every project he interacts with.

Jason Weaver, Director, Services: Mr. Weaver, Parchment’s Director of Services, brings over three years of experience managing school-based rollouts of state and federally funded projects for Parchment. Jason joined Parchment in 2010 and immediately assumed a lead position on Parchment state initiatives for Michigan, Kansas, Illinois, South Carolina, and Ohio. Mr. Weaver will lead all Project Management and Implementation activities, will manage all staff assigned to the project and will work closely with the Parchment team to ensure comprehensive management of deliverables. Mr. Weaver is a graduate of Penn State with a degree in Information Sciences and Technology. He is currently based in Omaha, Nebraska.

Matt Sink, Sr. Project Manager: Mr. Sink brings fourteen years of experience within Higher Education. Much of that time, Matt spent working with technology solutions for Sallie Mae and Datatel. Matt also spent 4 years as Director of Admissions and Financial Aid at Calvin College in Grand Rapids, Michigan, prior to joining Parchment in 2012. Matt manages all implementation details of the Docufide solution for newly partnering institutions. Matt Sink is based in Grand Rapids, Michigan.

Beverly Rusk, Account Executive: Ms. Rusk is Parchment’s Account Executive, managing/providing support for Parchment’s post-secondary college and university client-base. She is located in the Cincinnati, Ohio area.

Core responsibilities include:


33

Partnering with our client-base as well Parchment’s internal organization to ensure a smooth transition through all cycles of the implementation process.

Monitoring usage while developing “best practices” to drive adoption once the implementation process has been completed, enabling schools to send/receive electronic transcripts and student records.

Monthly Outreach to encourage an open dialogue and provide ongoing feedback, both internally and externally, to drive continuous improvement to meet/exceed customer satisfaction and securing contract renewals.

Works very closely with the Parchment Customer Support, Sales, Service, and Technical Teams to ensure client issues/concerns are addressed and/or escalated in a timely fashion.

Mike Cuthriell Director, Transcript Services & Support: Mr. Cuthriell's has 9 years’ experience in Education, focused on providing business consulting, technology and services to both secondary and post-secondary institutions. At Parchment, Mr. Cuthriell works on the Programs team and is responsible for the successful sending and delivery of all transcripts in all formats. This includes both paper and electronic, with the added component of extracting transcript data to be delivered to Parchment's receiving institutions. This operation is complimented by the Customer Service team which provides a direct channel for all students and faculty to obtain support at any point in the transaction lifecycle. Chris Kaschmitter, Director of Engineering: Chris was the CTO of Avow Systems and brings over 6 years’ experience in Higher Education Transcript services. While at Avow, Chris was responsible for leading the software development team, managing the system administrators and overseeing the client on boarding activities. Chris was also the chief technical architect of the Parchment by Avow platform. Chris will be moving to the VP of Services for Parchment after January 1, 2013.

Full Parchment Resume’s Available upon request.

2.5.1.3 The project plan development tool that will be used to develop each institution’s implementation schedule and project (along with a sample project plan that will be used as an example for each institution and is based on an institution that implements both receiving and delivering functions as well as integration to an Ellucian student information system)

The dedicated Parchment project management team will work with the state to formulate a registration and implementation plan for participating schools. Both summative and individual institutional project plans will be maintained for the duration of the project and provided during regular status meetings. The following is a sample project plan for a Docufide Sender SIS Integrated implementation.

Task Name Duration Start Finish Predecessors Resource Names

Docufide Sender Implementation

60 days Mon 1/14/13

Fri 4/5/13

Institution,IData,Parchment

Launch Call 1 day Mon 1/14/13

Mon 1/14/13

Institution,Parchment,IData

Test Environment Setup 19 days Mon 1/14/13

Thu 2/7/13

2 Institution

Setup Remote Access / ERP 15 days Mon Fri 2FS+5 days Institution


34

Development Environment 1/14/13 2/1/13

Submit Institution Request Form

2 days Mon 1/14/13

Tue 1/15/13

2 IData

Register for BlazerID 1 day Wed 1/30/13

Wed 1/30/13

5FS+10 days IData

Sumbit BlazerID 1 day Thu 1/31/13

Thu 1/31/13

6 IData

Provision Access to BlazerID 1 day Fri 2/1/13

Fri 2/1/13

7 Institution

Create IDataHub Test Server 1 day Fri 2/1/13

Fri 2/1/13

7 Institution

Establish Test Server Connectivity from IDataHub to ERP Test Environment

1 day Thu 2/7/13

Thu 2/7/13

8FS+3 days Institution

Establish Test Server Connectivity to Parchment

1 day Mon 2/4/13

Mon 2/4/13


Open TCP traffic to 207.178.213.163:443

1 day Mon 2/4/13

Mon 2/4/13

9 Institution


1 day Mon 2/4/13

Mon 2/4/13

9 Institution


1 day Mon 2/4/13

Mon 2/4/13

9 Institution

Establish File Retrieval Access from Test Server to ERP Test Environment

1 day Mon 2/4/13

Mon 2/4/13

9 Institution

Establish Access to IDataHub Resolution Screen on Test Server

1 day Mon 2/4/13

Mon 2/4/13

9 Institution

Install IDataHub on Test Server 1 day Mon 2/4/13

Mon 2/4/13

9 IData

Integration Design and Customization

128 days

Mon 1/21/13

Wed 7/17/13

2 Institution,IData,Parchment

ERP Process Walk Through 1 day Mon 1/21/13

Mon 1/21/13

2FS+7 days Institution,Parchment,IData

Design Document Customized for ERP

4 days Mon 1/28/13

Thu 1/31/13

19 IData

Design Document Review Meeting

1 day Fri 2/1/13

Fri 2/1/13

20 Institution,Parchment,IData

Design Document Approval 5 days Mon 2/4/13

Fri 2/8/13

21 Institution

Sweep Process to run transcripts

5 days Tue 1/22/13

Mon 1/28/13


Transcript Output Preparation 18 days Tue Thu 2 Institution,IData,Parchment


35

1/22/13 2/14/13

Submit Transcript Branding Files

1 day Tue 1/29/13

Tue 1/29/13


Submit Signature 1 day Tue 1/29/13

Tue 1/29/13

Institution

Submit Seal 1 day Tue 1/29/13

Tue 1/29/13

Institution

Submit Legend 1 day Tue 1/29/13

Tue 1/29/13

Institution

Create plaintext transcript Output

8 days Tue 1/22/13

Thu 1/31/13


Submit Test Transcript Files 9 days Mon 2/4/13

Thu 2/14/13

IData

Determine Initial Test Student Records List

1 day Mon 2/4/13

Mon 2/4/13

4 Institution,IData

International Student Addresses

1 day Mon 2/4/13

Mon 2/4/13

Institution

Graduated Students 1 day Mon 2/4/13

Mon 2/4/13

Institution

Graduate Degrees 1 day Mon 2/4/13

Mon 2/4/13

Institution

Undergraduate Degrees 1 day Mon 2/4/13

Mon 2/4/13

Institution

Send Test Transcripts to Parchment

2 days Tue 2/5/13

Wed 2/6/13

31 IData,Institution

Prepare Transcript Template from Test Transcripts

1 day Thu 2/7/13

Thu 2/7/13

36 Parchment

Submit Sample Outputs for Review

2 days Tue 2/5/13

Wed 2/6/13

26,27,28,31,15 Parchment

Review Sample Transcripts 5 days Thu 2/7/13

Wed 2/13/13

38 Institution

Approve Sample Transcript Output

1 day Thu 2/14/13

Thu 2/14/13

39 Institution

Integration Development and Testing

51 days Thu 1/31/13

Thu 4/11/13


SSO Integration Development and Testing

48 days Thu 1/31/13

Mon 4/8/13

Institution,Parchment

SSO Launch Meeting 1 day Thu 1/31/13

Thu 1/31/13

2FS+12 days Institution,Parchment

Develop Portal Code to Call Docufide SSO Web service

5 days Fri 2/1/13

Thu 2/7/13

43 Institution

Test Use Cases 1 day Fri 2/8/13

Fri 2/8/13

44 Institution


36

Student First Pass from Portal to Docufide, Completes Registration

1 day Fri 2/8/13

Fri 2/8/13

44 Institution

Student First Pass from Portal to Docufide, Signs In to Existing Account

1 day Fri 2/8/13

Fri 2/8/13

44 Institution

Student Second Pass from Portal to Docufide, Automatically Signed In

1 day Fri 2/8/13

Fri 2/8/13

44 Institution

Deploy Portal Code to Production

1 day Thu 4/4/13

Thu 4/4/13

90FS-2 days Institution

Submit Production Test 1 day Fri 4/5/13

Fri 4/5/13

49 Institution

Confirm Production Test 1 day Mon 4/8/13

Mon 4/8/13

50 Institution

IDataHub Development and Testing

44 days Mon 2/11/13

Thu 4/11/13


Create Hub task to pull in Transcript Requests

3 days Mon 2/11/13

Wed 2/13/13

9FS+5 days IData

Create Hub Procedure to Schedule and Initiate Call to Retrieve and Queue Requests

3 days Thu 2/14/13

Mon 2/18/13

53 IData

Create Hub Procedure to Process a Single Request from the Queue

3 days Tue 2/19/13

Thu 2/21/13

54 IData

Create Hub Task for Sending/Holding the Transcript File

2 days Fri 2/22/13

Mon 2/25/13

55 IData

Create ERP Call for Matching 2 days Tue 2/26/13

Wed 2/27/13

56 IData

Create ERP Call for Hold Checking

3 days Thu 2/28/13

Mon 3/4/13

57 IData

Create ERP Call for Request Creation

3 days Tue 3/5/13

Thu 3/7/13

58 IData

Create Hub Procedure to Monitor for Completed Transcripts and Respond to Parchment

2 days Fri 3/8/13

Mon 3/11/13

59 IData

Create Parameter Screen and Configuration Values for the ERP options

2 days Tue 3/12/13

Wed 3/13/13

60 IData

Create Custom Student Matching API

2 days Thu 3/14/13

Fri 3/15/13

61 IData

Create Custom Hold validation 2 days Mon Tue 62 IData


37

API 3/18/13 3/19/13

Create Custom Request Creation API

2 days Wed 3/20/13

Thu 3/21/13

63 IData

Create Custom Table to Store Index for Transcript Table

2 days Fri 3/22/13

Mon 3/25/13

64 IData

Integration Testing 2 days Tue 3/26/13

Wed 3/27/13

65 IData,Institution,Parchment

Integration Walk Through 1 day Thu 3/28/13

Thu 3/28/13

66 IData,Institution,Parchment

Data Verification and Handling Confirmation

2 days Thu 3/28/13

Fri 3/29/13

66 IData

Acceptance Testing 10 days Fri 3/29/13

Thu 4/11/13

67 Institution

Code Rework 2 days Mon 4/1/13

Tue 4/2/13

68 IData

Deploy IDataHub to Production 1 day Wed 4/3/13

Wed 4/3/13

70 Institution,IData

Deliver IDataHub Documentation and Install Guide

1 day Mon 3/11/13

Mon 3/11/13

90FS-20 days IData

Production Environment Setup 6 days Tue 2/5/13

Tue 2/12/13

17 Institution

Create IDataHub Production Server

1 day Tue 2/5/13

Tue 2/5/13

17 Institution

Establish Production Server Connectivity from IDataHub to ERP

1 day Tue 2/5/13

Tue 2/5/13

17 Institution

Establish Production Server Connectivity to Parchment

1 day Tue 2/5/13

Tue 2/5/13

17 Institution

Establish File Retrieval Access from Production Server to ERP

1 day Wed 2/6/13

Wed 2/6/13

74 Institution

Install IDataHub on Production Server

1 day Wed 2/6/13

Wed 2/6/13

74 IData

Migrate Test Configuration to Production Server

2 days Thu 2/7/13

Fri 2/8/13

78 IData,Institution

Production Test 2 days Mon 2/11/13

Tue 2/12/13

79 Institution

Service Launch Planning 60 days Mon 1/14/13

Fri 4/5/13


Schedule Service Adoption Meeting with Account Executive

10 days Tue 1/15/13

Mon 1/28/13

2 Institution

Attend Service Adoption 1 day Tue Tue 82 Institution,Parchment


38

Meeting 1/29/13 1/29/13

Develop Student Communication Plan

10 days Mon 1/14/13

Fri 1/25/13

90FS-60 days Institution

Schedule Staff Training 1 day Thu 3/28/13

Thu 3/28/13

66 Institution

Staff Training 1 day Fri 3/29/13

Fri 3/29/13

85 Institution,Parchment

Select go-live Date 1 day Thu 3/28/13

Thu 3/28/13

66 Institution

Deliver IDataHub Documentation

1 day Thu 4/4/13

Thu 4/4/13

71 IData

Technical Handoff of IDataHub 1 day Thu 4/4/13

Thu 4/4/13


Go-live with Docufide Sender 1 day Fri 4/5/13

Fri 4/5/13

89 Institution,Parchment

2.5.1.4 The software development methodology utilized to support the project


A formal patch management process must be documented that ensures that critical patches to system software are installed within one month of release.

A process must exist to identify newly identified security vulnerabilities and update systems and configuration standards if necessary. Quarterly vulnerability scans/penetration tests performed by third party service organizations are recommended. Web application security reconnaissance tools such as SkipFish or W3af should also be used on a periodic basis.

Incorporate the secure development guidelines from the OWASP Guide into the software development process. Both internal and external (contractor) development personnel should be trained in secure coding techniques, such as those defined in the OWASP guide.

Documented software change management policies should include procedures for: o Documentation of impact o Management of sign-off by appropriate parties o Testing of operational functionality o Back-out procedures

Software Quality Assurance Testing

QA testing of major software releases shall employ testing techniques that use input validation frameworks to reduce risks such as cross-site scripting.

Access to the bug tracking database, Jira, must be limited on a need to know basis to authorized software developers and QA testers.

When actual student records are used for testing purposes, they must be disposed of when testing is completed, unless they are needed for subsequent testing activities. Electronic records must be securely deleted; paper records must be shredded. Any maintained records must be stored securely.


39

2.5.1.5 The process planned for reporting, communicating and managing project progress There are several phases to a project implementation. The Project Director will be in charge of managing the project’s progress and communicating to the institution and stakeholders the tasks and deliverables associated with each phase of the implementation.


40

2.6 Support and Service Level Agreements (SLAs)

2.6.1 The Offeror must describe: 2.6.1.1 The hours of operation for phone and on-line support Parchment provides technical and customer support services that are available from the hours of 9am –

6pm EST. Trained support specialist are available by telephone and email, and respond to web form

information requests made through the Parchment’s website. Parchment maintains a high standard for

support service levels with a maximum telephone or email response time of one business day.

2.6.1.2 Scheduled downtimes Parchment’s customers benefit from a system that has seen nine years of operational run time. Maintenance and support are a regular part of Parchment’s operations. All updates are conducted between midnight and 4am PST. Updates are scheduled at least 48 hours in advance and can occur on any day of the week. Major maintenance projects are usually scheduled during weekends.

2.6.1.3 Disaster recovery plan

Parchment’s disaster recovery and business continuance plan is made up of redundancy on the server level, the datacenter level, and the business office level.

Within the individual datacenters (ISWest in Agoura Hills California, and Raging Wire in Natomas, California) Servers are set up in a high availability model within VMWare’s VSphere software and attached to a redundant set of network attached storage. This allows the environment to absorb a hardware failure of a physical server with a minimum of downtime; virtual servers are simply re-started on another physical host.

Regionally, the datacenter in Agoura Hills has server images and data replicated in the Natomas California datacenter (regionally separated by > 400 Miles). This allows production to be resumed in the Natomas datacenter should the primary datacenter in Agoura Hills become a total loss. Failing over regionally is accomplished through re-routing network addresses to the fail-over site, requiring moderate downtime.

Should the primary office location in Scottsdale Arizona become unavailable, Parchment maintains a software development office location in Roseville California with sufficient space and connectivity where business operations could be resumed. Network connectivity between Scottsdale, Roseville, Natomas, and Agoura Hills is maintained over a Virtual Private Network allowing business to resume immediately in the Roseville Office in the event of a disaster in Scottsdale.

Parchment utilizes a two stage backup process that involves current backups being sent to a raid 5 redundant disk array on site which both improves speed of backup and recovery as well as eliminating the need to recall tapes for short term restoration. The raid array is then nightly sent to tape which is rotated off site providing for a disaster resistant recovery model. In addition, backups of both virtual machines and databases are replicated in the backup datacenter in Natomas, CA.


41

2.6.1.4 The service level agreements in place to show how issues will be addressed based on priority

Event/Incident Management

Parchment has developed a Security Incident Response Plan that documents the policies and procedures related to the incident response process. The main features of this plan are as follows:

Accountability – The CISO reports to the CTO and is responsible for coordinating activities related to security incidents or events. The primary responsibilities of this position include:

Identifying and managing incident response resources.

Developing a work plan that defines tasks outstanding and completed.

Determining the incident severity level.

Maintaining communication with the CTO.

Implementing/enforcing communication policies regarding sensitive issues.

Collaborating with technology services managers on the formation of an IRT.

Providing necessary information to the IRT regarding the incident and establishing the

communication policies (use of Jira, Confluence, email, IM, etc.) and meeting/reporting

schedules.

Establish a case file for the incident. Use to ensure that information is properly collected and

documented.

Developing containment procedures.

Establish a post-mortem team to determine the root cause and net effect of the incident.

Managing the incident work plan(s) and task assignments.

Certifying that all systems are returned to operational quality with the cause rectified.

The secure destruction/retention of all materials at the conclusion of an incident.

Identifying external personnel/resources when required.

Incident Response Team (IRT) - During an incident, the CISO will designate a team. Members will vary, depending on the skill sets required to support incident response activities. The IRT will remain active until the incident is closed, and be responsible for both response and recovery. The response duties of the team are to conduct triage of the incident, assist in containment of the incident, collect evidence for the post mortem report and if requested, conduct or assist in a forensic investigation.

Assisting in the collection of evidence during an incident investigation.

Removing virus, malware, or other injected software from the system.

Closing/disabling entry points used to gain unauthorized access by updating or deleting login

credentials, updating firewall configurations, closing ports, etc.

Making recommendations to the CISO on remedial action on affected systems.

The IRT may be called up 24 hours a day, 7 days a week, 365 days a year during a critical

incident.

The recovery aspects of the team are centered on damage assessment, return to normal operations, rebuilding serves and systems, etc


42

Determining, if necessary, whether affected systems can be restored from backup tapes, or

must be reinstalled

o Scrubbing all data before making it ready for reinstall.

o Determining what data is lost and cannot be recovered or restored.

o Reloading data and/or application code on affected systems.

o Restoring normal operations.

The follow-up phase involves:

Sending final incident reports to parties with a need-to-know.

Discussing procedural changes and updates.

Discussing configuration issues.

Deciding whether to conduct an investigation to determine what the root cause and root effects

of the incident.

Discussing any task that was not completed.

Incident Definition

An information security incident is any adverse event that threatens the confidentiality, integrity, or availability of Parchment information assets, information systems, and the networks that deliver the information. Any violation of computer security policies, acceptable use policies, or standard computer security practices is an incident.

Adverse events may include denial-of-service attacks, loss of accountability, unauthorized access to database information, or damage to any part of the system. Examples include the insertion of malicious code (e.g. viruses, Trojan horses, or backdoors), unauthorized scans or probes, successful and unsuccessful intrusions, and insider attacks.

Incident Levels

An actual or suspected security incident should be reported immediately to the Parchment Security Incident Response Team (IRT). The IRT will (1) determine whether an incident has occurred and, if so, (2) will assess the incident’s impact, and (3) take the appropriate action to address the incident. Security incident levels will generally be classified according to the definitions in the table below and the following section:

Criticality Definition Examples

High

Incidents having a high/critical and immediate impact on Parchment’s business or service to customers

Malicious code attacks, including Trojan horse programs and virus infestations that materially impact Parchment operations

Unauthorized system access resulting in significant loss of confidential data or compromise of mission-critical systems or applications

Denial of Service (DoS) attacks that have significant impact on operations


43

Medium

Incidents having significant impact, or the potential to have critical impact on Parchment’s business or service to customers

Password cracking attempts

Malware/virus infestations that have moderate impact on systems or operations, but don’t threaten the loss of confidential data or block system or application functionality

Penetration or DoS attacks with limited impact on operations

Low

Incidents having potential to have a significant impact on Parchment’s business or service to customers

Penetration or DoS attacks attempted with no impact on operations.

Isolated instances of malware/viruses that are not effectively handled by deployed antivirus software

A Security Incident is defined as any unexpected or unauthorized change, disclosure or interruption to Parchment’s information resources that could be damaging to students, administrative staff, customer institutions, and/or the company’s reputation.

As part of the initial incident response process, the CISO will make an assessment of the incident’s impact and assign an appropriate severity level. This severity level will be based upon the potential impact to the company’s operations or reputation, and/or its student customers, administrative staff, and/or institutional customers. An information security incident’s severity level dictates the initial response and management activities associated with the event. As incident management activities continue, further assessment may effect a reassignment to a lower severity level.

High Level: Successful penetration or denial-of-service attack(s) detected with significant impact on operations: very successful, difficult to control or counteract, large number of systems compromised, significant loss of confidential data, loss of mission-critical systems or applications, admin/root compromise, user account compromise, illegal file server share access, significant risk of negative financial or public relations impact.

Medium Level: Penetration or denial-of-service attack(s) detected with limited impact on operations. Minimally successful, easy to control or counteract, small number of systems compromised, little or no loss of confidential data, no loss of mission-critical systems or applications. Widespread instance of a new computer virus and/or worm that cannot be handled by deployed anti-virus software that may require corporate-wide activations by IRT and/or site administrators. Illegal mirrored and unapproved content (e.g. games, porn, multi-media servers on corporate networks). Small risk of negative financial or public relations impact.

Low Level: Significant level of network probed scans and similar activities detected indicating a pattern of concentrated reconnaissance. Intelligence received concerning threats to which systems may be vulnerable. Penetration or DoS attacks attempted with no impact on operations. Isolated instances of a new computer virus or work that cannot be handled by deployed anti-virus software.

Incident Reporting - All security incidents are reported to the CISO, who will make a determination regarding the incident level and take appropriate action. If the incident reporter either knows or suspects the incident may be of a critical nature, it should be reported immediately by phone. If the


44

reporter is reasonably certain that the incident is not critical, but likely a medium or low level incident, it can be reported by email to [email protected].

A Parchment Incident Reporting Procedure document is made available to all Parchment employees; it describes the reporting process in detail and identifies the individuals and their respective contact information for reporting incidents via phone and/or email.

Incident Reporting Workflow

Beginning with the incident report, the following steps are performed:

1. The CISO determines the severity level of the incident. 2. Depending on the severity level and the type of incident, the CISO sends notifications to

one or more of the following stakeholders as necessary:

CTO

CEO

VP of Engineering

System Administrator

Director of Software Development

Corporate Communications/PR

VP Programs

VP Sales

Corporate Counsel

Human Resources

Impacted individuals and/or institutions 3. CISO identifies IRT and team leader 4. Response action is initiated 5. Incident Log entry is created 6. When containment and threat removal is complete, log details. send notifications 7. Perform post-incident analysis, document findings 8. Update Policies & Procedures

2.6.1.5 The type of system performance that can be expected

Parchment’s maintenance and support include the following already implemented and functioning items:

Major updates are scheduled on a quarterly basis with minor updates on an as needed basis

Maintenance and support of the system is included in the system at no additional charge

Assurance that the system provides effective and efficient operations for all users on a

continuous basis.

Assurance that all physical systems and logical systems – including data, files and programs- are

properly maintained updated and patched including file maintenance activities for updates to

files (as required). Updates will include all operating system patches, system

modules/components, third party libraries, licensed software, etc.

Review, resolution and reduction of errors through Parchment’s continuous monitoring of both

physical and logical components of the system.



45

Assurance that physical subsystems will meet the capacity needs as system usage, files,

memory, etc. grow.

Regular and ongoing review of all monitoring and system data and on-going tasks to ensure the

system is tuned, performing, responding correctly, has database stability, is meeting system

demands, etc.

Prompt correction of deficiencies found before or after implementation.

2.6.1.6 Other SLAs developed to support the proposed solution. Please see Appendix III for a copy of our standard Service Level Agreement.

2.7 Student Transcript Request and Processing the Request

2.7.1 The Offeror must validate the functionality and describe the process for:

2.7.1.1 A student to select the destination institution(s) for their transcript request A student can send a transcript to any destination worldwide! To ensure the student or alumni a simple and intuitive experience, and to ensure the Receiver receives the transcript in the preferred format, Parchment maintains a database for all Academic institutions. Over 1800 Academic Institutions and Scholarship funds have registered to receive transcripts electronically from Parchment. All other Academic institutions are maintained in the Parchment database as paper destinations. Parchment uses the National Center for Educational Statistics (NCES) and the College Board (CEEB) code database as sources for these academic institutions.

The requestor can search our list of Academic destinations by State or Institution name. They may also search by separate departments on Campus for example Undergraduate vs. Graduate Admissions.


46

2.7.1.2 Selecting multiple destination institutions for a transcript request Requestors have the ability to request multiple destinations within their transcript request. They may choose from Academic Destinations, Myself or Other Destinations such as an employer.


47

2.7.1.3 Capturing a digital signature from the student both for the consent form and for the transcript request. If a digital signature is not used, the Offeror must describe the alternate method used to ensure the credibility and authenticity of the student

Parchment uses a FERPA compliant and AACRAO approved digital signature process for our Transcript Authorization Form.


48

2.7.1.4 How a student attaches other documents that the students wishes to be added to the transcript

After the student or alumni has chosen or entered in their destination, they will be able to Review the destination information, choose the transcript type and upload any attachments that they would like to send along with their electronic transcript.

Student or Alumni click this link and browse their computer to upload an attachment to be delivered along with their electronic transcript.


49

2.7.1.5 Providing a notice of liability for student personally identifiable information (PII) and FERPA when additional documents are requested

Pursuant to FERPA, the system requires the student to provide an electronically signed written consent before the system will transfer personally identifiable information from the student’s education records.

2.7.1.6 Activating the additional document feature This is a global setting for all electronic destinations and cannot be turned off at the institution level.

2.7.1.7 Making changes to transcript charges and fees Parchment provides a robust administrator console that has several ecommerce features which allow institutions to effectively manage their transcript charges and fees. Every authorized administrator will have the ability to make these updates at any time.


50

2.7.1.8 Where date and time stamps appear on documents associated with the transcript requesting, sending and receiving functions to ensure full audit capabilities exist within the proposed solution

Transcripts are date stamped in the header. Our transaction reporting that is available for all administrators also shows date stamps which will facilitate auditing capabilities.

2.7.1.9 How an institution processes transcript requests individually or in batch For an institution that chooses to integrate their SIS with Docufide Sender, transcripts will automatically be processed in batches on a system defined schedule. Any institution that chooses to use the Docufide Client (print driver option) will have the ability to process transcripts individually or in batch, using the Docufide Client.

Docufide Sender Client Capture (transcripts)

The Docufide Sender non-invasive capture Client is used by Docufide Sender postsecondary clients nationwide. This self-installing client application allows for capture of transcripts individually or in batches. This approach has proven effective in school installations across more than 90 different SIS platforms and is well adopted by administrators as it works with their current SIS and their established transcript processing workflow (Schools ‘print’ to the Docufide Sender printer rather than a physical printer). The system is designed to be easy to use, requiring the administrator to simply print the student’s transcript file (or batch of files) to the Docufide Sender printer with no additional steps required on their behalf.

The Docufide Sender Client application software is normally installed on the computer (or computers) where transcripts are printed. Alternatively, the software can be installed on a network print server, where the installed Docufide Sender logical printer can be accessed as a shared network printer.

The installed Docufide client consists of three components:

1. Docufide Virtual Print Driver – This is a Microsoft Windows®-compliant and certified print driver that is designed to be used with the sending school’s student information system and is currently functioning in over 90 unique SIS environments among other Docufide Sender customers. The driver installs and functions as a standard Windows print driver. Instead of printing the transcript to a physical printer, the user prints to the “Docufide Sender” printer. The Docufide print driver performs a “print to file” operation, which passes transcript data to the Docufide Sender Client application. The installation automatically installs the print driver and creates a logical printer that uses the Docufide PostScript Printer driver.

2. Docufide Communications Component – This application performs the following functions:

Accepts transcript data from the Docufide Sender print driver.

Creates a filename for the transcript data that includes the school id number, date and file creation time.

Periodically (the default is every 15 seconds), sends queued transcript files to the Parchment Data Center over a secure Internet link.


51

Alternatively the Docufide Sender client software can be used to securely upload transcript files to Parchment that have bypassed the print driver and has been saved as extract files from the SIS (as individual or batched files) using a mutually agreed upon file format including standards compliant X.12 TS130 EDI, PESC XML, or a CSV or flat file format using a consistent data structure.

3. General User Interface (GUI) Component – GUI that is used for configuration settings

Easy to use installation for broad range of operating systems

Customization of key client settings

2.7.1.10 How the registrar views detail student information when processing the transcript request

The registrar can click on the student name and view detailed information when processing the transcript request.


52

2.7.1.11 Handling a transcript request when the student account has been placed on hold, detailing whether the request is allowed and if so, what takes place with request charges

If an institution is using the standard Docufide Client print driver the administrator can place a transcript request on hold and either choose hold reasons from a drop down box or provide detailed information for the hold reason. Holds generated from integrated systems will be displayed in the Docufide web interface, as well as in the integration system logs. At any time the administrator can click on the Request on Hold tab to see all of the requests that are on hold. The request charges are captured at the time of request.

2.7.1.12 Whether reason codes can be associated with a transcript that has been placed on hold

If a transcript hold exists for a student in the SIS, the transcript hold will be recognized by the integration and the student will be notified through Docufide. Student holds honored by the integration will include any holds that prevent transcripts from being produced through the normal SIS transcript request process. For example, if a hold is located for a requesting student in SPRHOLD in Banner. The hold returned to Docufide includes a hold message as listed in the SPRHOLD (or the STVHLDD) table. Those messages can be configure by the institution in Banner INB at any time.


53

Docufide will continue to send the request for checking for a period set in our Transaction Policy (currently, thirty days) and the hold will be checked each on each processing cycle of the integrations. If the hold is removed, the transcript request will be automatically processed, until such a time as the request expires.

2.7.1.13 Informing a registrar if the student account is on hold and what happens once the hold has been lifted

For the Docufide Client print driver option the Registrar will know all requests that are on hold by visiting that tab within the administrator interface. The Registrar would manually approve this request once the hold has been lifted.

For the SIS integrated option the transcript request will be automatically processed if the hold is released within a certain timeframe established by the Docufide system. Docufide will continue to send the request for a set period of time and the hold will be checked each time.

2.7.1.14 How an institution selects multiple final destinations for one transcript request An Administrator can request transcripts on behalf of students by going to the Request Transcripts tab in the administrative console. The administrator can search for recipients by looking in the Docufide Database, entering in the CEEB Code for Recipients or manually adding recipient information.


54

Administrators are able to review students and recipients for each transcript request.


55

2.7.1.15 How an administrator at the institution is able to receive transcripts individually or in batch.

Institutions that receive transcripts from the secure Docufide Download Center can select documents before they download to receive individual documents or receive them in batch.


56

2.8 Institution Delivery Process

2.8.1 The Offeror must describe: 2.8.1.1 How entities other than institutions such as Employers, State Agencies, and

Educational Organizations can be selected as final destinations for a transcript request and whether or not this capability is at the discretion of the institution

Students or alumni may request to send their transcript to an entity other than an institution through the standard request process workflow. The transcript can be delivered either electronically or via paper to any employer, scholarship fund, professional organizations or other 3rd party destinations. This is not a feature that is at the discretion of the institution. However, the institution can choose to have Parchment deliver electronic transcripts only and continue to print and mail all of those that can’t be delivered electronically.

2.8.1.2 How an institution is able to select multiple destinations for a single transcript request

An Administrator can request transcripts on behalf of students by going to the Request Transcripts tab in the administrative console. The administrator can search for recipients by looking in the Docufide Database, entering in the CEEB Code for Recipients or manually adding recipient information.


57

2.8.1.3 How the sending/delivering institution is authenticated on the transcript request Sender and Receiver Authentication All sending and receiving schools are verified before being added to the system. New institutions are registered and added to the system only after being verified by Parchment personnel. Record Holder (RH) Authentication As part of the Parchment Client Application software installation at the record holder’s site, Parchment assigns the sending school a unique identifier that is links the client application and the school in the Parchment database. This code is transmitted from the sending computer at the RH institution when transcripts or other student records are uploaded to Parchment for processing. This code is used to identify and authenticate the sending institution and should be treated as confidential by the sending institution. In the event that it is suspected or confirmed that this code has been communicated to unauthorized personnel, or used in an attempt to circumvent the authentication process, the sending institution’s account will be deactivated until a new identifier code can be issued.

2.8.1.4 How the proposed solution allows the institution to attach other documents that the institution is passing on to the destination institution per the student’s request

Within the administrator interface administrators are able to attach documents that may need to be sent along with the electronic transcript. This is a simple upload attachment link that allows the user to browse for the saved document and upload the attachment. The document image will be passed on along with the electronic transcript. This is only allowed for the electronic transcripts


58

2.8.1.5 Whether the institution is allowed to select those document types from a drop-down box and whether or not a notice of liability for student personally identifiable information (PII) and FERPA will be posted on the screen where additional documents are requested

This is not a function of the Docufide Sender service; however, the Institution does have the ability to provide customized message within the overall student experience that could provide such notice.

2.8.1.6 How transcript requests and transcript deliveries can be aborted per institution or at the request of the student

Students/Alumni can cancel any destination or request before the transaction is completed. Once the transaction is completed the school administrator has the ability to put on hold or not fulfill any request that a student wishes not to send.

2.8.1.7 How an institution’s specific transcript format can be supported (institution specific layout, headings, data elements, etc.)

Institutions that would prefer that Parchment deliver their transcript in an image only (not covert to data) will be able to submit the PDF image transcript to Parchment for electronic delivery.

2.8.1.8 Where the transcript is saved once the transcript has been created and processed

Once a transcript has been uploaded and processed by the administrator, that transcript is held within the Parchment database. The storage of transcripts within the Parchment database is a configurable option that many clients take advantage of to allow for more expedited processing of future requests. If a campus chooses to not have the transcript stored by Parchment, the transcript can be purged after a period of time upon completion of the transaction.

2.8.1.9 Whether the proposed solution allows retrieval of a completed transcript for viewing at a later date and for easier processing the next time the student submits a request

Students have indefinite access to ordered self-view transcripts from within their Parchment account. Administrators can see a record of completed transcripts in reports. In some cases, like alumni, the same transcript can be used to automatically fulfill incoming requests since we know that the transcript uploaded for that alumnus is the final version of the transcript.

2.8.1.10 How an institution is able to add specific messages to the transcript request screen such as the dates the institution will be closed for the holidays, etc.

An institution can add specific messages through administrator console under Manage Sender Preferences. The Student Setting Tab allows the institution the ability to control the specific message presented to the student or alumni requesting a transcript.


59

2.9 Notification Process

2.9.1 The Offeror must describe:

2.9.1.1 How the email notification process can be deactivated and replaced by a batch notification process by institution

The email notification process cannot be deactivated.

2.9.1.2 All options associated with other transmission notification processes and configuration options (SMS, etc.).

Currently email is the only option associated with notification processes. As part of the future direction of the product we are evaluating the expansion of other messaging notifications, such as SMS.


60

2.10 Reports

2.10.1 The Offeror must provide examples of standard reports and audit trails. Examples are to include but not be limited to the list below and are to identify how the data is sorted (i.e. by institution, student type, etc.):

1. A list of transcripts that have successfully transmitted to a receiving institution

2. A list of transcripts that were requested but did not successfully transmit

Transcripts that were not successfully delivered will not say Complete: Delivered in the Receiver Document Status Tab:

3. A list of transcripts that the institution has charged for

All transcripts that have been order and processed through the Docufide Sender Platform would have had charges associated with the order. The report output will be visually represented in the same format previous provided for the answer to question 1.


61

4. A list of transcripts sent to multiple institutions

5. A list of transcripts where miss-matches have occurred (with the on-line capability to resolve the matches)

With the integration between Docufide Sender and the campus SIS, this report of transcripts where there are uncertain matches will be available within the IData Hub interface.


62

6. A list of transcripts that failed due to incomplete data, errors or corrupted data

With the integration between Docufide Sender and the campus SIS, this report of uncertain matches is in a status of CONFLICT. Held and sent requests as well as submitted files can be found here.

7. A fee reconciliation report

Within the Administrator interface, Parchment offers a status screen that shows summary information of fee reconciliation.


63

If an institution needs a detailed report, the Account Management team can provide the following sample report.

8. Transmission histories including dates and times when events occurred

Parchment’s standard report includes transmission history information

9. Fee maintenance report

This report is not currently available within the Docufide Sender Platform.

10. System configuration changes audit trail.

This report is not currently available within the Docufide Sender Platform.

2.10.2 The Offeror must validate that all reports are sub-totaled.


64


2.10.3.1 The frequency, or frequency options, for producing each report The Docufide Sender Platform allows for users based on their security rights and access to run reports on demand.

2.10.3.2 How the reports will be provided to each institution (printable, sent to each institution from the host system, developed through queries, able to download to Excel, etc.).

Each of the reports that are available within the Docufide Sender Platform is available for on screen viewing, printing and are available for download to Excel.

2.11 Training


2.11.1.1 The type of training available for specific audiences (student, registrar, application administrator, functional users, etc.)

End-user training is provided to all customers. Parchment offers two types of trainings: hosted training sessions and self-paced tutorials. Hosted training sessions are offered Monday through Friday and are typically 1 hour in length and cover the following topics: signing in to Docufide, approving and sending transcripts, updating school profile information, editing and updating sending services options, and


65

finally, managing user access to Docufide. The self-paced tutorials are available for the end-user on demand, and 24 hours a day. The self-paced modules can either be used as the primary training source or as a refresher.

2.11.1.2 Whether the training documentation is available on-line, hardcopy or both Training documentation is available online and in hardcopy.

2.11.1.3 How and where training will be provided for each institution. Training is provided after implementation either through a hosted webinar or self-paced tutorial. If additional onsite training is required Parchment will work will the individual institution to accommodate.

2.12 Documentation

2.12.1 The Offeror must validate whether the proposed solution includes:

2.12.1.1 Online documentation relative to hover-overs There are hovers associated with critical processes within Docufide Sender, placed in an effort to empower users to utilize the product in a self-service model. Further, for those institutions which select to take the manual implementation approach within the To Do List, hover overs exist to alert administrators to high-attention orders such as overnight requests.

2.12.1.2 Online help There is an extensive online help section within Docufide, where users can find answers to commonly asked questions.


66

2.12.1.3 Action bar drop-downs The Docufide user interface consists of top-layer action bars used to easily navigate the system. The administrator has a clear idea of where each of the tools necessary to see student requests, as well as upload and send transcripts are located.

2.12.1.4 Other system help features Additionally, there is a page created and administered by the Parchment marketing department, and updated by the Parchment Product team, which includes helpful guidance documentation, video tutorials, and more located here: http://info.docufide.com/4.5K12LaunchWebinar_OnDemand.html

2.13 Proposal and Solution Documentation

2.13.1 The vendor proposal must provide the following documentation:

2.13.1.1 Flowcharts and explanations for each process associated with the electronic transcript solution (set-up, request, payment, receiving, delivery, payment reconciliation, reporting and notification and monitoring)

Complete screenshots for the Docufide by Parchment solution are included in Appendix I.

2.13.1.2 All steps for managing and maintaining configurable parameters and data sets Below are steps for managing and maintaining configurable parameters and data sets

Applying Surcharges 1. Log into Docufide 2. Click “Preferences” 3. Choose “Manage Sender Preferences” 4. Select the “eCommerce” tab on the main screen 5. The school may choose to apply surcharges to current students, alumni (if the school

elects to facilitate alumni requests), or both. a. The school may choose an amount they deem necessary b. The school may elect to facilitate x requests per student/alumni before a

surcharge is encountered by that student/alumni c. Parchment will collect surcharges on the school’s behalf and remit fees monthly

if a minimum of $500 has been collected d. A report can be run showing surcharge amounts collected over user-selected

time periods

Administrator rights The school may designate specific administrators who have access to Docufide. Further, the school may choose specific roles for each administrator, which will or will not give each administrator access to specific functionality. Role-specific information can be found within the “Manage Administrators” page. The roles available:

General Administrator Recruiter

http://info.docufide.com/4.5K12LaunchWebinar_OnDemand.html


67

Sender Advisor Receiver IT/Webmaster Site Administrator

Adding Administrators 1. Log into Docufide 2. Click “Preferences” 3. Click “Manage Administrators” 4. Click “Add Administrator” 5. Enter the administrators professional contact information, and select the appropriate

role for the administrator from the list below

Queue Assignments o Once administrators have been added and their roles selected, the school will have the

opportunity to assign student queues to each administrator. A queue assignment for an administrator responsible for sending transcripts assigns a portion of the student base to that administrator. This is helpful to manage administrator workload.

1. Click “preferences” 2. Click “Manage Sender Preferences” 3. Select the “Queue Assignments” tab on the main screen 4. Choose whether an assignment is being made for transcript or document

request workflows 5. Select the administrator for whom the queue is being created 6. Assign a portion of the alphabet to that administrator. Students with last

names falling inside of the selection will appear on the administrators To Do List to be fulfilled.

Setting a Welcome Message 1. To provide a personalized welcome message seen by students when they log in, click

“Preferences.” 2. Click “Manage Sender Preferences” 3. Choose the “Student Settings” tab on the main screen 4. Enter the desired message in the “Welcome Message” text entry field. 5. Click “Save” when finished

2.13.1.3 Data definitions, data formats and change management requests EDI and PESC XML are the data formats supported by the Docufide by Parchment platform. Parchment is an active member of the PESC community and has received the PESC Seal of Approval. The PESC Seal of Approval Program is a voluntary service offered by PESC for implementers of PESC Approved Standards to indicate a uniform level of implementation. For users, a product or service with a PESC Seal of Approval indicates that the product or service is in alignment and uniform with the original intent of the PESC Approved Standard. For providers of products and services, a PESC Seal of Approval indicates value in that the product or service was reviewed, analyzed and confirmed to be in alignment and uniform with the original intent of the PESC Approved Standard. For PESC, ensuring that products and services are in alignment and uniform with the original intent of PESC Approved Standards fulfills its mission and


68

improves the level of awareness and need for interoperability across the education landscape. See full press release from PESC in Appendix IV.

2.13.1.4 Definitions and diagram of the vendor’s server

Logical Network Diagram

Firewall - Our network is protected by state-of-the-art redundant Sonicwalls, filtering traffic from the Internet. Attacks are intercepted and rejected at the network edge, keeping our clients' data secure

Perimeter Firewall

DB Servers

FTP Server

(Prod)

Web Services 02

(Prod)

Render Servers

Render Servers

DB Servers

Render Servers

DB Servers

Internal Firewall Border Router

Load Balancer 01

Web Services 01

(Prod)

Web Services 03

(QA)

Web Services 04

(QA)

DB Replication

Admin Servers

Web Service 05

(Dev)

Load Balancer 02

Internet

Production

QA Development

8/31/2012Logical Network

DiagramA 01.00

Parchment


69

while providing high performance to the traffic that does need to get through. This includes segmenting the network to provide zones of security for our client-facing services, our partners, and our internal services and back-end components.

Load Balancer - We utilize high performance commercial load balancing products from A10 networks to evenly distribute load among our application farms to ensure that there is always reliable access to our three main application areas – CMS, Parchment.com Portal, and Docufide® by Parchment™.

Web Service Tier - Our web tier provides our main site (http://www.parchment.com), our Parchment.com consumer portal (http://www.parchment.com/c/), our Docufide® by Parchment™ portal (http://www.parchment.com/p/ or http://www.docufide.com) and our Docufide® by Parchment™ application (https://securetranscript.docufide.com/admin/). The web cluster is composed of a number of virtual machines running on high-end Dell hardware deployed as load balanced groups (at least two), which are supported by Dell’s 4-hour onsite support service.

CMS Servers - The CMS servers service requests for the static web pages associated with Parchment’s corporate presence. The content is maintained and served up by the Drupal open source content management system. The servers run Apache and PHP and interact with a PosgreSQL database co-located with our transactional database in the DB tier.

Parchment.com servers - The Parchment.com servers run and execute a combination of Apache and PHP and serve as both the web service and application service for the Parchment.com consumer portal. The servers are load balanced in a pair of virtual servers.

Docufide by Parchment Servers - The above diagram is conceptual to the extent that the Docufide by Parchment servers are further subdivided into three main server sets – Client traffic (proddfc), web traffic (prodweb), and web services traffic (prodws). It is worth nothing that the bulk of Docufide Sender traffic comes through the client servers; the bulk of Docufide Receiver traffic comes through as web traffic; and the bulk of our Naviance partner traffic comes through prodws.

Docufide® by Parchment™ application tier – This tier represents the set of servers dedicated to providing the functionality of all Parachment services. Each set of services is scalable and capacity can be increased by adding new resources, generally in the form of new virtual machines, to a given cluster.

Production Web Cluster (ProdWeb) – The prodweb cluster acts as both the main receiver / responder for customer web interactions.:

Web Services Cluster (ProdWS) – This cluster of machines handles the web requests from our integrated partners, and provides a programmatic interface to Parchment.

Parser Cluster - The parser component handles breaking out the data in transcripts and other documents uploaded to the web server from record holding institutions (RHs). Data extracted from uploaded files is stored in the Secure Transcript records database.

Render Cluster - The render component handles building a Docufide® by Parchment(tm) transcript out of the data from the database and producing the PDF, either for viewing through the web or for secure document delivery to a receiving institution (RI).

Back End Processing (BP) Cluster – This cluster handles all of the back end processing, whether this be SFTP, secure download, printing for physical mailing, etc


70

Database Tier - We currently have five deployed database servers that provide all of our components with fast and reliable access to all of our student and client data.

Data DB (Postgres 9.0): This database server provides two databases. One serves as the main transactional database server for the Docufide® by Parchment™ application and the Parchment Discover application. The second serves as the repository for static web page content.

o Data DB replica (Postgres 9.0): This database server is a read-only replica of the main DataDB. One of the main benefits to our deployment of PostgreSQL 9.0 in August of 2011 was the ability to leverage binary replication for HA purposes.

Binary DB (Postgres 9.0): This database server provides the physical storage for the actual transcript files in binary (BLOB) XML form. While quite large, it does not receive a lot of load.

o BinaryDB replica (Postgres 9.0): This database server is a read-only replica of the main BinaryDB. One of the main benefits to our deployment of PostgreSQL 9.0 in August of 2011 was the ability to leverage binary replication for HA purposes.

Data DB (MySql 5.1): This database serves as the transactional database for the Parchment.com™ consumer portal. It is currently backed up on a production schedule (nightly full, hourly partial), but is currently not operating in an HA mode

NAS/SAN Storage - We have highly available and high performance storage on our network that provides disk based storage to our systems individually or as a cluster, depending on needs.

Our storage environment consists of a mixture of technology, utilizing Dell PowerVault for caching of backups; Compellent storage for high transaction production databases, and NetApp for Virtual machine shared storage. Each of these technologies has been selected and tuned for the specific application for which it has been deployed allowing us to leverage the strengths of each technology in the area where it provides the maximum value for the least cost.

2.13.1.5 Information and steps for printing transcript style sheets, reports and audit trails Transcript style sheets are not needed because of the nature of the integration between Parchment and the individual Student Information Systems (SIS). The Parchment integration pulls the transcript data directly from the SIS which enables Parchment to produce the electronic transcript in the receivers desired format. Parchment report can be printed using any web-browsers built in print functionality.


71

3.0 MINORITY PARTICIPATION Is the bidder a South Carolina Certified Minority Business? [ ] Yes [x ] No Is the bidder a Minority Business certified by another governmental entity? [ ] Yes [ x] No If so, please list the certifying governmental entity: _________________________ Will any of the work under this contract be performed by a SC certified Minority Business as a subcontractor? [ ] Yes [ x ] No If so, what percentage of the total value of the contract will be performed by a SC certified Minority Business as a subcontractor? _____________ Will any of the work under this contract be performed by a minority business certified by another governmental entity as a subcontractor? [ ] Yes [ x ] No If so, what percentage of the total value of the contract will be performed by a minority business certified by another governmental entity as a subcontractor? _____________ If a certified Minority Business is participating in this contract, please indicate all categories for which the Business is certified: [ ] Traditional minority [ ] Traditional minority, but female [ ] Women (Caucasian females) [ ] Hispanic minorities [ ] DOT referral (Traditional minority) [ ] DOT referral (Caucasian female) [ ] Temporary certification [ ] SBA 8 (a) certification referral [ ] Other minorities (Native American, Asian, etc.)


72

4.0 OFFSHORE CONTRACTING Work that will be performed offshore by the Offeror and/or its subcontractors must be identified in the Offeror's response. For the purpose of this solicitation, offshore is defined as outside the 50 States and US territories. Offeror is to include an explanation for the following:

(a) What type of work is being contracted offshore? Parchment has been effectively using Murano Software to assist in its development of the parsing software used to capture, upload, and extract transcript data from various Student Information Systems.

Murano Software, headquartered at 21323 Dumetz Road, Woodland Hills, CA 91364 has been formally working with Parchment since August, 2004. Murano Software specializes in providing outsource professional software development services. They have four software development centers in Eastern Europe. They excel in designing, developing and rapidly delivering cost effective high quality custom software

Parchment uses Murano’s services in the following services and technologies:

Services: Web-based applications, XML and SOAP-based web services, Workflow systems, E-Commerce solutions, Desktop applications

Technologies: Windows, UNIX Server, .NET, J2EE, COM+, , SQL Server, Oracle, PostgreSQL, etc.

(b) What percentage (%) of the total work is being contracted offshore?

Less than twenty percent of the effort for this project will be contracted offshore. This work is related to software development activities. All project management, implementation, training, quality assurance, and other non-software development work is performed within the 50 states and territories.

(c) What percentage (%) of the total value of the contract is being contracted offshore? Approximately five percent of the total value of this project effort is being contracted offshore.

(d) Provide a Service Level Agreement (SLA) demonstrating the arrangement between the off-shore contactor and the Offeror. Attach Service Level Agreement to this document or paste here. Data provided by the Offeror in regards to this clause is for information only and will not be used in the evaluation and determination of an award.

Parchment has an extensive contract that governs the business relationship with Murano, and also policies and procedures that govern project work. The specific terms of our contract are confidential and not publicly disclosed; however they can be made available.


73

5.0 QUALIFICATIONS

5.1 Include a brief history of the offeror's experience in providing work of similar size and scope.

As of January 2011, Docufide, Inc. has rebranded its corporate identity as Parchment, Inc® (www.parchment.com). The name Docufide is being retained for our transcript exchange platforms: Docufide Sender and Docufide Receiver. On October 3, 2012 Parchment acquired Avow Systems Inc. to merge the Docufide and Avow platforms, creating the largest and most secure eTranscript network. More than 9,000 high schools (over 30 percent of the U.S. secondary school market), 1,800 postsecondary institutions and seven statewide initiatives have exchanged 6 million transcripts using Docufide by Parchment™ and the Avow by Parchment™ SaaS platforms. Throughout this proposal, Parchment represents our corporate organization and Docufide Sender represents our fully automated sender service. Parchment is a Delaware Corporation with offices in Scottsdale, AZ, Roseville, CA, Washington D.C., and Denver, CO. Parchment currently has 115 employees. Since inception in 2003, the sole focus of Parchment has been the electronic delivery, management, and analysis of student academic records. The company established itself as the nation’s leading trusted intermediary delivering student transcript records from schools in forty seven states to any destination worldwide including colleges, universities and third party destinations. For over nine years, Parchment has provided electronic records management services to record owners (students), record holders (schools) and recipients of all kinds. Parchment has developed the infrastructure and knowledge required to rapidly and efficiently design, develop and operate full service solutions for educational institutions. Years of operational experience has afforded us the feedback from our customers necessary to best understand and incorporate the nuanced features that are often critical to broad user acceptance. The core of what is proposed herein describes our fully deployed solutions. Over the course of nearly ten years of service to the academic community, Parchment continually expands our service offerings in addition to scope and scale of the exchange network. Parchment is the largest core focused eTranscript provider, with $6 million annual investment in research and development. We have the focus, dedication and resources to ensure the credential exchange needs of the higher education market today and well into the future. For your consideration, we present the following as cornerstones of our company and the criteria for a successful comprehensive automated transcript processing solution, as defined by many institutions that have partnered with Parchment.

Security

Automation

Technology experience

User experience

Parchment believes that these are essential for a robust, scalable, and successful automated transcript processing service. It is these core principles that are prevalent throughout our platform and will ultimately be the keys to a successful service.


74

In addition to the cornerstones of our platform, Parchment aligns the following prior experience to the goals of South Carolina CHE and post-secondary institutions:

1. 7 Statewide Initiatives: (IL, OH, MI, IN, PA, KS, SC),: Parchment has unmatched experience and success deploying and operating statewide initiatives, as evident from our first statewide implementation in Indiana, where over 340 Indiana schools (96%) have chosen to participate, and all of the state’s 77 colleges are receiving e-transcripts from Parchment. This is also evident in one of our longest relationships with the SC Department of Education, where just in the last year we have increased high school usage by 221% and all 59 colleges and universities are receiving electronic transcripts from Parchment. The most recent statewide initiative (PA) will include statewide K-12 service along with post-secondary service. Within weeks of the PA announcement three PA Community Colleges have signed up for the Parchment sending platform.

2. Ability to work with any SIS: In addition to our standard solution that works with any SIS, Parchment currently has several large and medium size Ellucian (Colleague and Banner) institutions utilizing our integration option. This deployment will automate all transcript checks and workflow so little to no manual intervention is necessary to fulfill a transcript request.

3. Ability to process both paper and electronic transcripts: Parchment provides a full service solution that allows our customers to order and send transcripts both electronically and as paper. We adhere to the strictest security standards for both electronic and paper delivery. For example, we are a trusted intermediary for electronic delivery and use the highest level security paper.

4. Proven Postsecondary Receiver Platform: Deployed at over 1,800 institutions, enabling the option to receive data, (PDF, PESC XML, and SPEEDE EDI), conduct trending analysis, along with integration into Enterprise Content Management Systems or Student Information Systems.

5. Core Competency: Parchment focuses solely on developing and maintaining the largest, most scalable education credentials data and intelligence platform. Since 2003, the Docufide by Parchment platform has enabled institutions and individuals to more easily and effectively exchange online transcripts and other admissions-based documents.

6. Professional Services and Customer Support: Parchment’s professional services methodology and dedicated team ensure successful implementation and training of new customers. In turn, Docufide users quickly adopt the solution with ease, maximizing its capabilities and generating ROI for your institution. Parchment’s customer support team has built a reputation for nearly ten years of going far above and beyond what’s necessary to resolve any client challenge.

7. Security: Parchment maintains the highest security standards in the industry. The Docufide by Parchment architecture protects student and other personally identifiable data from unauthorized access throughout the entire capture, store, and deliver lifecycle. You can trust our commitment to data integrity and the fact that we use the industry’s most stringent safeguards to ensure the security of data.

8. Ease of Use: Fully secure and FERPA-compliant, the solution enables easy-to-use document transmission from the Docufide web interface to any destination worldwide, including employers, colleges, universities, and public and private institutions


75

5.2 Your most current financial statement, financial statements for your last two fiscal years, and information reflecting your current financial position. If you have audited financial statements meeting these requirements, you must provide those statements.

The following information is confidential and exempt from public disclosure.


76

5.3 A detailed, narrative statement listing the three most recent, comparable contracts (including contact information) which you have performed and the general history and experience of your organization and references.

Parchment is the eTranscript leader among Statewide Initiatives and individual institutions. We have successfully deployed our platform with 7 states and over 300 colleges. Parchment is solely committed to building the most comprehensive eTranscript exchange network in the world. The growth of our platform is largely impacted by feedback and system enhancement requests captured from existing customers and the Parchment Advisory Board (PAB), which meets monthly. PAB members represent academic institutions large and small, private, and public. In addition to the three most recent new or renewed contracts for our state wide initiatives listed here, Parchment offers the following individual institutions as references. Each reference represents a specific institution type and has fully deployed and utilized a Parchment solution.

California Polytechnic State University – SLO: Parchment worked closed with Cal Poly in order to adapt

the Docufide by Parchment solution to work with the InCommon Federation.

Cem Sunata, Registrar [email protected] 805-756-6014

Tidewater Community College: Through a competitive RFP process the Virginia Community College System chose Parchment to provide services to their 23 community colleges. Tidewater Community College is the 2nd largest institution with 32,000 students.

Christine Damrose-Mahlmann [email protected] 757-822-1919

Western Michigan University: As part of Michigan’s statewide initiative, Western Michigan University utilizes our full service Docufide Sender solution for student request, approval and delivery (electronic and print).

Carrie Cumming, Registrar [email protected] 269- 387-1000




77

Name of Client & Project Title

PA eStars e-Transcript Statewide Initiative

Nature and Scope of Project:

The Pennsylvania Department of Education issued a statewide announcement and press release on September 12, 2012 that they chose Parchment through a competitive bid process to implement the Pennsylvania Electronic Student Transcripts And Records System (PA eSTARS), a statewide network that will enable Commonwealth schools and IHE’s to quickly and securely exchange student records and transcripts. A federal grant awarded to PDE will be used to underwrite the initial implementation costs for entities signing on prior to July 1, 2013. The system allows for the exchange of student transcript records among high schools and to any college in PA as well as nationwide in recipient selected formats, including PESC XML, SPEEDE EDI, and PDF’s.

Project Duration: Start Date Year: [2012] End Date Year: July 1, 2013

Nature of the Client:

The PA eStars project is being run out of the offices of Postsecondary Education and Elementary/Secondary Education. The mission of the Pennsylvania Department of Education is to assist the General Assembly, the Governor, the Secretary of Education and Pennsylvania educators in providing for the maintenance and support of a thorough and efficient system of education.

Nature of Client Audience:

PA eStars e-Transcript initiative is a P-20 transcript exchange among for PA students to send their transcripts to schools and into postsecondary nationwide.

Number of Users: 694 Secondary Schools; 1.8 Million Students

135 IHE’s; 757,843 Students

# & Composition of Vendor Employees & Consultants Assigned:

1 Project Director

1 Project Manager

1 Account Manger

1 Data Engineer

Client Contact Information:

Reference Contacts:

Name: Julie Kane Title: Coordinator of Transfer and Articulation, Office of Postsecondary and Higher Education

Department: Pennsylvania Department of Education

Full Address: 333 Market Street, Harrisburg, PA 17126

Telephone: 717-772-3643 E-mail: [email protected]

Relation/Role to Project: PDE e-Transcript Project Higher Education Contact



78


South Carolina Department of Education


Through a competitive bid process, Parchment was awarded a contract from the SC DOE in March of 2008 to deliver a statewide K12 student record exchange and e-transcript system for all high schools throughout the state. This contract was renewed in April of 2012.

Project Duration: Start Date Year: [2008] End Date Year: [on-going]


The mission of the Data Management and Analysis is to provide accurate, reliable, and timely data services for the South Carolina Department of Education and its constituent communities to enable well-informed decisions related to policy and practice. The office provides ad hoc research services for the Department and other constituents and produces school and district report cards for the accountability system.


State Project Managers, Data Analysts, Principals, Guidance Counselors, System Administrators, Students, Parents

Number of Users: 142 High Schools

46,012 transcripts sent from 1/1/2012 – 10/19/2012


1 Project Manager

1 Account Manager

1 Data Engineer

6 Customer Support Representatives

1 Project Director


Reference Contact:

South Carolina Department of Education

Tom Olson

Information Technology Manager

Office of Data Management and Analysis

1429 Senate St. Room 410

Columbia, SC 29201

803-734-8174

[email protected]

Relation/Role to Project – SC DOE e-Transcript project contact



79


Indiana e-Transcript Statewide Initiative


Indiana’s Commission for Higher Education (ICHE) and the Indiana Department of Education issued a Broad Agency Announcement on March 22, 2005 for a statewide E-Transcript Initiative. The system allows for the exchange of student transcript records among high schools and to any college nationwide in recipient selected formats, including PESC XML, SPEEDE EDI, and PDF’s. Within one year of project announcement, Docufide had implemented services in over 280 schools accounting for over 80% of public school districts (and over 60% of privates) statewide.

Project Duration: Start Date Year: [2005] End Date Year: [on-going]


The Indiana Commission for Higher Education is a fourteen-member public body created in 1971 to provide the following functions. Define the educational missions of public colleges and universities. Plan and coordinate Indiana’s state-supported system of postsecondary education. Review budget requests from public institutions and the State Student Assistance Commission. Approve or disapprove for public institutions the establishment of new programs or expansion of campuses


Indiana E-Transcript initiative is for K12 transcript exchange among fellow IN high schools and into postsecondary nationwide.

Number of Users: 390 High Schools; 72,655 students; 200,000+ transcripts


1 Project Manager

1 Account Manager

1 Data Engineer

6 Customer Support Representatives

1 Project Director


Reference Contacts:

Name: Dr. Ken Sauer Title: Associate Commissioner for Research and Academic Affairs

Department: Indiana Commission for Higher Education

Full Address: 101 W. Ohio Street, Suite 550

Telephone: (317) 464-4400 ext. 21 E-mail: [email protected] Relation/Role to Project: Indiana e-Transcript Project Contact



80

5.4 A list of every business for which offeror has performed, at any time during the past three year(s), services substantially similar to those sought with this solicitation. Err on the side of inclusion; by submitting an offer, offeror represents that the list is complete.

Institution Name (Docufide by Parchment Platform)

Academy of Art University

Alpena Community College

American InterContinental University - Atlanta

American InterContinental University - Houston

American InterContinental University - Los Angeles

American Intercontinental University - Online

American InterContinental University - South Florida

American InterContinental University - Study Abroad

Arizona Bible College

Arizona Christian University

Atlantic Culinary Academy

Barton Community College

Bethel College (IN)

Bethel College (KS)

Blue Ridge Community College (VA)

Briarcliffe College

Briarcliffe College - Online

Briarcliffe College - Patchogue

Broadview University - Layton Campus

Broadview University - Online

Broadview University - Orem

Broadview University - West Jordan

Brooks College - Long Beach

Brooks College - Sunnyvale

Brooks Institute

Brown College - Brooklyn Center

Brown College - Mendota Heights

Bucks County Community College

California Culinary Academy

California Polytechnic State Univ - SLO

Capella University

Carteret Community College

Carthage College

Chowan University

City Colleges of Chicago - Harold Washington College

City Colleges of Chicago - Kennedy-King College

City Colleges of Chicago - Malcolm X College


81

City Colleges of Chicago - Military Transcripts Only (processed at Harold Washington College)

City Colleges of Chicago - Olive Harvey College

City Colleges of Chicago - Richard J Daley College

City Colleges of Chicago - Truman College

City Colleges of Chicago - Wilbur Wright College

Cleary University

Cloud County Community College

Coffeyville Community College

Colby Community College

College for Creative Studies

College of Charleston

Collins College

Colorado Technical University - Colorado Springs

Colorado Technical University - Denver

Colorado Technical University - North Kansas City

Colorado Technical University - Online

Colorado Technical University - Pueblo

Colorado Technical University - Sioux Falls

Colorado Technical University - Westminster

Columbia Basin College

Compton College

Cowley County Community College

Davidson County Community College

Delaware County Community College

Dodge City Community College

Donnelly College

Erikson Institute

Flint Hills Technical College

Fort Scott Community College

Francis Marion University

Friends University

Full Sail University

Garden City Community College

Gibbs College - Livingston

Gibbs College - Norwalk

Goshen College

Harrington College of Design

Husson University

Illinois College

Imperial Valley College

Independence Community College

International Academy of Design & Technology - Chicago


82

International Academy of Design & Technology - Detroit

International Academy of Design & Technology - Fairmont

International Academy of Design & Technology - Las Vegas

International Academy of Design & Technology - Nashville

International Academy of Design & Technology - Orlando

International Academy of Design & Technology - Pittsburgh

International Academy of Design & Technology - Sacramento

International Academy of Design & Technology - San Antonio

International Academy of Design & Technology - Schaumburg

International Academy of Design & Technology - Seattle

International Academy of Design & Technology - Tampa

International Academy of Design & Technology - Tampa Online International Culinary Academy – Pittsburgh John Tyler Community College

Johnson County Community College

Johnston Community College

Judson Baptist College

Kansas City Kansas Community College

Kansas Wesleyan University

Kaplan University Online

Katharine Gibbs School - New York

Katharine Gibbs School - Philadelphia

Katharine Gibbs School - Piscataway

Le Cordon Bleu at Brown College

Le Cordon Bleu College of Culinary Arts - Atlanta

Le Cordon Bleu College of Culinary Arts - Austin

Le Cordon Bleu College of Culinary Arts - Boston

Le Cordon Bleu College of Culinary Arts - Chicago

Le Cordon Bleu College of Culinary Arts - Dallas

Le Cordon Bleu College of Culinary Arts - Las Vegas

Le Cordon Bleu College of Culinary Arts - Los Angeles

Le Cordon Bleu College of Culinary Arts - Miami

Le Cordon Bleu College of Culinary Arts - Minneapolis

Le Cordon Bleu College of Culinary Arts - Online

Le Cordon Bleu College of Culinary Arts - Orlando

Le Cordon Bleu College of Culinary Arts - Portland

Le Cordon Bleu College of Culinary Arts - Sacramento

Le Cordon Bleu College of Culinary Arts - Scottsdale

Le Cordon Bleu College of Culinary Arts - Seattle

Le Cordon Bleu College of Culinary Arts - St. Louis

Le Cordon Bleu Institute of Culinary Arts - Pittsburgh

Lehigh Valley College

Marygrove College


83

Marymount University

McIntosh College

McPherson College

Metropolitan Community College

Mid-Plains Community College - McCook, North Platte, and Extended Campuses Missouri College Montgomery County Community College

Naval Postgraduate School

Nicolet Area Technical College

Northampton County Area Community College

Patrick Henry Community College

Piedmont College

Pittsburg State University

Richland Community College (IL)

Salem College

Sanford-Brown College - Atlanta

Sanford Brown College - Boston

Sanford-Brown College - Cleveland

Sanford-Brown College - Collinsville

Sanford-Brown College - Dallas

Sanford Brown College - Dearborn

Sanford Brown College - Farmington

Sanford Brown College - Fenton

Sanford Brown College - Grand Rapids

Sanford Brown College - Hazelwood

Sanford Brown College - Hillside

Sanford Brown College - Houston

Sanford Brown College - Indianapolis

Sanford Brown College - Milwaukee

Sanford Brown College - North Kansas City

Sanford Brown College - Phoenix

Sanford Brown College - Portland

Sanford Brown College - San Antonio

Sanford Brown College - Skokie

Sanford Brown College - St. Peters

Sanford Brown College - Tinley Park

Sanford-Brown College - Vienna

Sanford Brown Institute - Austin

Sanford Brown Institute - Cranston

Sanford Brown Institute - Ft. Lauderdale

Sanford Brown Institute - Iselin

Sanford-Brown Institute - Jacksonville

Sanford Brown Institute - Landover


84

Sanford Brown Institute - Orlando

Sanford Brown Institute - Pittsburgh

Sanford Brown Institute - Tampa

Sanford Brown Institute - Trevose

Sanford Brown Institute - Wilkins Township

Sanford Brown - Northloop West

Sawyer School

SBI Campus- an affiliate of Sanford-Brown

Schoolcraft College

Siena Heights University

Southern California Institute of Architecture

Southwestern College St. John's College (MD) St. John’s College (NM)

St. Louis College of Pharmacy

Tabor College Tidewater Community College University of Alabama - Birmingham

University of Mary Hardin-Baylor

University of Virginia - Wise

Wesleyan College

Western Michigan University

Western Nebraska Community College Area

West Shore Community College

Institution Name (Avow by Parchment Platform)

Abraham Baldwin Agricultural College

American Public University System

Bellevue University

Brigham Young University

Case Western University

Central Carolina Community College

Colorado Christian University

Colorado School of Mines

Concordia University

Cornell University

Dartmouth College

DePaul University

DePauw University

East Carolina University

Elmhurst College

Emory University


85

Florida International University

Fresno Pacific University

Furman University

Georgia Institute of Technology

Georgia State University

Hamline University

Hardin Simmons University

Hawaii Pacific University

Holy Family University

Indiana State University

Indiana University

Institute for the Int'l Education of Students

Kansas State University

Lehigh University

Lipscomb University

Marian University

Massachusetts Institute of Technology

McKendree University

Moravian College

National-Louis University

New Mexico State University

North Carolina State University

North Georgia College & State University

Northwestern University

Northwestern University - School of Continuing Studies

Oklahoma State University

Pennsylvania State University

Polk State College

Princeton University

Salisbury University

San Diego State University

Southern New Hampshire University

Stanford University

Texas A&M University Corpus Christi

Texas Weslyan University

The University of Texas at Dallas

University of Alaska

University of Chicago

University of Colorado Boulder

University of Georgia

University of Illinois at Chicago

University of Kansas

University of Maryland Baltimore County


86

University of Michigan

University of Minnesota

University of Nebraska at Kearney

University of Nebraska at Omaha

University of North Carolina at Greensboro

University of Oregon

University of Pennsylvania

University of Pittsburgh

University of San Diego

University of South Carolina

University of Southern California

University of Tennessee

Vanderbilt University

West Chester University of Pennsylvania

West Texas A&M University

Wilmington University

5.5 List of failed projects, suspensions, debarments, and significant litigation. Parchment has not had any suspensions, debarments or litigation.

Failed projects: Nebraska (NE) Statewide Initiative

Although Parchment considers NE a failed project because the state did not renew their Statewide initiative, we did have several high schools and Colleges contract with us directly as a result of our work in NE.

Initiative summary

Nebraska (NE) was a multi-year, fully funded state wide initiative which included Docufide Sender High School and College and free receiver network within MHEC.

The renewal came in the same year as a major leadership change in NE and Parchment was unable to secure a renewal or an endorsement from our new state contacts.

Participating High Schools were extended initiative pricing for 6 months after the initiative ended and were then converted to direct sales. Drop off in HS participation was minimal.

5.6 List the development resources in place to maintain and enhance the electronic transcript solution.

Parchment has the below number of development resources on staff to maintain and enhance the electronic transcript solution.

System Architects: 3

DBAs: 3


87

Software Engineers: 14

QA Engineers: 5

Release Engineers: 2

5.7 A business plan that shows how the offeror plans to recruit and retain sufficiently qualified people to maintain necessary performance levels in the event resources are no longer available within the company.

Parchment has invested extensively in qualified human capital over the last 2 years, growing our team to records numbers. We feel the Programs department is the backbone of our organization and this section will outline its organizational structure.

The Programs department’s evolution and investment is the result of considerable 2011 growth and a long term vision for our customers' success. The mission is to drive customer and student success at every touch point beginning when an institution joins the Parchment family.

Programs consists of 4 components:

Services – This team owns our new client implementation engagements and is divided into three focused areas for Secondary, Post-Secondary, and State Initiatives.

Account Development- This team is responsible for the success of the partnerships with our clients and making sure the institutions and their students are getting the maximum value from our products. This team is divided by Secondary and Post-Secondary.

Transcript Services – This team owns the entire transcript data parsing process as well as operates a secure enterprise print and mail service.

Customer Service – This team is the front facing end user support for both consumers and institutional administrators.

Programs Management Organizational Chart


88

Programs Account Development Organizational Chart

Programs Transcript and Support Services Organizational Chart

Programs Services Organizational Chart


89

6.0 Appendix I Docufide by Parchment Screenshots

6.1 Student Workflow Screenshots Student and alumni encounter a simple account creation process.

Accounts can be prepopulated with information passed from the college portal. This account creation is only required once and subsequent requests will begin directly on the order page.


90

Students and Alumni Confirm Enrollment Information


91

Students and Alumni complete FERPA Compliant electronic signature for authorization form. Account creation process is complete.

This FERPA compliant AACRAO approved student electronic authorization functionality is compatible with any computer and web browser. Students and alumni are not required to print and mail authorization forms back to the institution..


92

Parchment provides a database where students and alumni can select their transcript destination.

Students and alumni select their destinations from our extensive database of Academic institutions populated using the National Center for Educational Statistics. The requestor can also enter an electronic or paper delivery for other destinations.


93

Students and Alumni are able to send transcripts to Other Destinations outside of higher education institutions. They may choose to deliver electronically or via paper. If we are mailing the Official transcript the student/alumni may choose a USPS or FedEx delivery.


94

Students and Alumni have the ability to Review all destinations prior to completing the order. During this part of the order process transcript type is determine and additional documentation can be uploaded for delivery with any electronic transcript.

Prior to completing the order the student or alumni has the opportunity to select their transcript type, review their order and make any changes. There is also the opportunity to upload an attachment to all electronic orders that can be delivered with the transcript.

The unique Hold-for -Degree functionality enables the student or alumni to conduct

early ordering.


95

Once the student or alumni has completed the online PCI compliant payment of their transcript request, they will receive a confirmation page with details regarding the request, destination and delivery and fee summary.

o

The order confirmation summarizes the destination, fees and delivery method. The student or alumni will also receive an email notifying them the request has been made.


96

The student or alumni can log into their account 24/7 and check Status/History to have real time access to their request details.


97

6.2 Sender Administrator Screenshots When College administrators log into Docufide, they see a dashboard. This graphically represents a customizable view of a preconfigured dataset. Our dashboards present a real-time depiction of performance related to key business indicators.


98


99

Parchment’s manual transcript approval interface allows administrators to 1.) control the entire transcript approval process 2.) process exceptions that would not flow through the standard SIS integration or 3.) process historical transcripts that you have the image available but they are not in your

current SIS database This transcript approval option can be used in addition to the SIS integration to allow for greater number of electronic deliveries.


100

The built in reporting engine enables the administrator to create reports based on requested dates, student, destination, etc.


101

The Docufide Sender Solution is a SaaS solution that allows for administrator control over several user preferences presented in the screenshots below.


102


103

Provide a personalized welcome message to students and alumni and upload your logo for additional customization.


104

Flexible ecommerce options that will allow SC Institutions to manage and define a variety of ecommerce settings.


105

6.3 Receiver Administrator Screenshots Dashboard for Receivers show items needing attention, quick links and vital statistics.


106


107

Parchment has over 1800 colleges and universities that have registered to receive transcripts and other admissions documents electronically at no cost through our secure download center. These documents can be downloaded in a pdf format. Alternatively, our Full Receiver service allows institutions to receive transcripts through an auto delivery format in PDF, XML or EDI.


108

7.0 Appendix II Corporate Security Policy The purpose of the Corporate Security Policy is to specify requirements and set direction for the organization's security from the high-level perspective of senior management. The primary audience of this policy is department managers, while the secondary audience is all other employees of the organization.

General Security Objectives and Guidelines

Parchment’s security policies

Information security is everyone's responsibility.

All access to corporate resources and information should be on a 'Need to Know' basis.

The Corporate Information Security Officer is responsible for coordinating the implementation of all security policies. At a later stage, an “Information Security Committee” may be formed, if required.

Information should be protected in terms of Confidentiality, Integrity and Availability (CIA) when it is stored, processed or transmitted; regardless of the storage medium and mode of transmission.

All of the organization’s critical assets (e.g. hardware, software, equipment and data) should be identified and appropriately protected.

Resource rights, which are not explicitly assigned, should be assumed to be denied.

When information is transmitted outside the organization, appropriate measures should be taken to secure it.

The perimeter network should be appropriately protected with proper hardware and software.

Proper monitoring of the perimeter network and internal network should be performed on a regular basis.

To provide protection against common threats to the organization, appropriate safeguards should be in place, including anti-virus programs, firewalls and other sensors.

Regular checks on network, servers and other equipment should be conducted in order to make sure that the network is properly secure.

All information abuses and security breaches should be reported to the Corporate Information Security Officer.

Business Continuity of the organization should be ensured with proper measures.

The organization resources should be used for management-approved purposes only.

Proper detailed procedures should be developed for business critical areas.

Disciplinary action, ranging from verbal reprimand to termination of employment, depending on the severity of the violation, may be taken.

Proper procedures for “Incident Handling” should be in place.

All security incidents, weaknesses and malfunctions should be reported to the Corporate Information Security Officer. The CISO will ensure that the issue is addressed and will devise a mechanism to prevent recurrence in the future.

The proper skills should be developed to address any security-related incidents.

Proper checking for vulnerability with the help of a penetration test should be carried out on a regular basis.

All systems, especially the operating systems, should be hardened to an acceptable level.


109

Physical security is of prime importance. All efforts should be made to secure the physical perimeter, physical entry points, office rooms and print operations areas.

Proper measures should be taken for securing all equipment, power supplies and cables.

Security of equipment while being maintained off-premises should be assured.

Discussion of confidential company business information in public places such as elevators or cafés is prohibited.

All advertisements for jobs and help should be reviewed thoroughly and should not disclose any sensitive information or future company plans.

If a company employee is presenting a paper, giving a presentation or delivering a speech in a public forum or conference, all material must be reviewed by his/her immediate manager prior to presentation.

Disciplinary action will be taken for non-compliance with a security policy.

Security Requirements

Identification

Identification is the process that enables recognition of a user. User access to system resources requires the use of an individual’s email address as a user name in conjunction with a password as login credentials. User names and password as also used to identify objects or processes. Identification requirements specify how the system should identify the users.

The user ID shall be unique and not shared with others.

The system shall always require unique Identification and Authentication during the logon process.

The system shall internally maintain the identity of all active users.

The system shall provide a mechanism to administratively disable user IDs and a mechanism for re-enabling after a specified period of time. The use of this mechanism shall be privileged and applies to all users.

The system shall automatically disable a personal identifier after a period of time during which the user ID has not been used to log onto the system. The default time for customer users shall be ninety days; the default time for Parchment employees and contractors may be configured separately as required.

The system shall provide a mechanism to administratively re-enable or delete disabled user IDs.

The system shall provide a mechanism to obtain the status of any user ID.

The system shall provide a mechanism that allows a collection of user IDs to be referenced together as a group.

Because the Docufide application architecture supports multiple logons per user ID, the system shall provide a mechanism that limits the number of multiple logon sessions for the same user ID. The mechanism shall allow limits for user IDs and groups to be specified. The system default shall limit each user ID to one simultaneous logon session.

The system shall provide a mechanism to associate specified information (e.g., user name and school affiliation) with each user ID.

Procedures for user account management should define the naming convention for user IDs and the operations practices for provisioning and removing these user IDs.


110

Authentication

Mechanisms are used to prove the identity of users, objects, and processes, usually as a prerequisite to granting access and applying access control restrictions. Authentication requirements specify attributes of the authentication mechanism and how the system will protect this information.

The system shall provide a mechanism to authenticate the claimed identity of a user.

The system shall appear to perform the entire user authentication procedure even if the user ID that was entered was not valid. Error feedback shall contain no information regarding which part of the authentication information is incorrect.

The system shall provide a mechanism to support the initial entry or modification of authentication information.

The system shall be able to incorporate alternative authentication mechanisms, such as token-based cards, biometrics, or trusted third-party techniques, in place of or in addition to the system-supplied authentication mechanism.

The system shall require a privilege to access any internal storage of authentication data.

The system shall support an application program interface to an authentication mechanism.

If the system provides network access (e.g., dial-in, X.25, or Internet), then it shall also provide at least a Class 2 authentication mechanism (as defined in Draft International Standard 10181-2) that can be used at the customer's discretion. The networking software shall be able to be disabled or configured out of the system.

The sharing of login IDs is not permitted.

Password Requirements

The system shall provide no mechanism whereby a single stored user name and password entry is explicitly shared by multiple user IDs. The system shall provide no means to facilitate the sharing of user name and password credentials by multiple users.

The system shall allow a user to choose a password that is already associated with another user ID. The system shall provide no indication that a password is already associated with another user ID.

The system shall store passwords in a one-way encrypted form.

The system shall automatically suppress or fully blot out the clear-text representation of the password on the data entry/display device.

The system shall, by default, prohibit the use of null passwords during normal operation.

The system shall provide a mechanism to allow a user to change his or her password. This mechanism shall require re-authentication of the user identity. The system shall provide a mechanism to set or initialize passwords for users.

The system shall enforce password aging on a per-user ID or per-group basis. Default for all non-privileged users shall be 90 days.

The system shall provide a mechanism to notify users in advance of requiring them to change their passwords.

Passwords shall not be reusable by the same user ID for a specified period of time. The system-supplied default shall be six months.

The system shall provide an algorithm for ensuring the complexity of user-entered passwords.


111

Access control

Access control provides a means to determine who is authorized to perform a requested activity and to grant or deny such request. Access control requirements address network access, system access, and resource access. Access control bases its decisions upon a user's or object's identity, and therefore is dependent upon identification and authentication mechanisms to be effective.

Network Security Technology

The network must be protected by a firewall at its Internet-facing IP address to prevent unauthorized or malicious intrusion.

Firewalls and routers shall be configured to strictly limit inbound and outbound traffic to that which is necessary for the operation of the company’s Internet applications.

The company shall maintain documented firewall and router configuration standards that include a formal process of approval and testing of all external network connections and changes to firewall and router configurations.

The company shall maintain a network diagram, the format of which conforms to industry followed practice, and which shall be reviewed and updated on a regular basis to reflect changes to the network.

The firewall and router configuration rule sets shall be reviewed at a minimum of every six months.

The web application servers shall be maintained in a DMZ in the network

Documentation shall be maintained that defines business justification for all services, protocols, and ports which are available on the application network, including the SFTP services.

Antivirus software must be implemented on all Parchment application servers and updated automatically. Antivirus scans must be performed on a weekly basis and audit logs captured.

Perform quarterly internal network vulnerability scan and yearly internal and external network and application-level penetration testing, and define management policies that address critical vulnerabilities on the basis of severity.

Network User Access Requirements

The identity of all users shall be authenticated before access is granted to any resources or system on the network.

Access from any public network must be authenticated with a stronger authentication method than a password.

Internet access connections to the internal network must be approved and managed by the CSO and corporate system administrator.

With the exception the customer-facing Internet interface, all access from the Internet must be controlled with a virtual private network (VPN) system or similar mechanism that can make decisions based on service requested, user identity, network address source and destination, and time of day.


112

System User Access Requirements

The identity of all users shall be authenticated before access is granted to any resources or system information.

The system shall provide a mechanism to authorize users to access the system, revoke users from accessing the system, and modify the security information associated with users.

For interactive sessions, the system shall lock the session after a specified period of user inactivity.

The system logon procedure shall exit and end the attempted session if the user authentication procedure is incorrectly performed a specified number of times. The system supplied default shall be six times. The lockout duration will be a minimum of thirty minutes, or until an administrator unlocks the account.

The system shall provide a mechanism to allow or deny specified user IDs to access the system based on means of access or port of entry.

If the system provides network access, then it shall also provide a mechanism to end an abnormally terminated session such that a new user does not have access to a previous user's session.

Upon a user's successful access to the system, the system shall display exit information.

An authorization form must be signed by management (CSO or sysadmin) granting an employee access to IT systems or changing an employee’s level of access. These authorization forms will be maintained so that they are available for auditing employee access privileges.

Operator Profiles

Operator profiles contain parameters that define the access privileges granted to each operator. The following parameters are recommended for operator profiles:

Login times - These may be set for a span of hours for a given day of the week. Multiple spans of login times may be set for any given day. Certain days may also be locked out altogether.

Time-out - Will log a user out of the application if the workstation is idle for a given amount of time. (The system provides a standard time-out that applies to all users; time-outs need to be extended to group profiles.)

Menus - Users can be limited to the menus and/or tools setup in their profile.

Screens - Specific screens in a menu may be removed or added to a person’s operator profile.

Actions - Users may be limited to update display or add mode only for specified menus.

Self-aware - A user can be identified to an employee on the database. This option makes sure no user can change his or her own information on any application screen.

Operator Class

Operator Classes reduce the effort required to maintain individual profile securities. For example, the System Administrator could prevent all users belonging to a single Operator Class from accessing the system on weekends by adjusting the security profile information for that specific Operator Class. Only the Operator Class would need to be adjusted; Operator IDs tied to these classes would then reflect the changes. Recommended Operator Classes include the following:


113

Student

Record Holder Administrator

Secondary District Administrator

Receiving Institution Administrator

Software engineer

Operations Staff

Operations Supervisor

System Administrator

User

Account Manager

Technical Support Agent

Customer Service Agent

Web Designer

Parchment Executive Management

Corporate Security Officer

Security Levels

Security levels must be defined for access to all Parchment corporate office facilities, offsite data centers, remote systems, and all activities associated with sensitive data and critical system functions. Proposed security levels and examples of their scope are shown in the table below.

Name Type Description

Security Admin

(CSO)

Operations, IT, Engineering (all)

Administer passwords, keys, security privileges for company

System Admin

IT Application Servers

Databases (App & source code)

Executive

Application, Operations

DF Admin access

Opns facilities, reports

Docufide Platform system reports

Supervisor

Operations, Engineering,

Acct Mgmt

Ops only

TOC print server


114

Transcript materials

Postage meter

IT system reports

Engr only

Dev, test systems

Acct Mgmt only

Customer (RI, RH) data

Operations

(TPO staff)

Operations Transcript materials

User Application To be defined by the Security Admin or System Admin

Guest Application To be defined by the Security Admin or System Admin

Resource Access Requirements

The system shall control access to all resources.

The system shall control access to resources based on authenticated user IDs.

For each resource, the system shall provide a mechanism to specify a list of user IDs or groups with their specific access rights to that resource (i.e., an access control list).

A user ID's access rights to a resource shall be checked, at a minimum, when access to that resource is initiated.

The system shall provide a mechanism to specify the owner of the resource.

The system shall provide a mechanism to modify the contents of a resource's access control list.

The system shall provide a mechanism to identify all resources in the system that are owned by a specified user ID, the resources to which that user ID is allowed access, and the specific access rights for each resource.

The system shall provide a mechanism to deny specific access rights to all resources for specified user IDs or groups. This mechanism shall override resource access control mechanisms.

Each resource delivered with the system shall have the most restrictive access rights possible to permit the intended use of that resource.

The system shall protect all information used for resource access control decisions (e.g., access control lists, groups’ lists, system date and time).


115

Document Handling

Transcript Paper

When not in use, transcript paper is stored in a locked room or cabinet. Key access to the area is controlled at the supervisor level. During normal operations, only TPO supervisory and operations personnel will have physical access to this paper. Transcript paper is never to be left unattended.

Printed Transcripts

Printed transcripts remain under the control of Transcript Print Operation (TPO) level or above personnel at all times; printed transcripts are never to be left unattended, either within the TPO facility or in a vehicle transporting the transcripts to a postal facility. Control of printed transcripts is relinquished only when the sealed transcript envelopes are either (a) deposited in a US Postal Service mailbox or (b) delivered directly to a USPS employee for mailing.

Any printed transcripts that are determined to be damaged or unfit for delivery in some way are to be shredded. Any transcripts that are printed for test or sample purposes will have the student’s name, address, and other identifying information blocked out. Transcripts printed for QA testing purposes are the only exemption under this requirement, but must also be shredded when their use is complete. Transcripts must never be discarded without being shredded first.

System Reports

All system reports, whether produced from the Docufide Platform administrative interface or the Operations Dashboard Reports application, are to be considered Company Confidential and handled accordingly, unless explicitly identified otherwise.

Software Development and Testing


A formal patch management process must be documented that ensures that critical patches to system software are installed within one month of release.

A process must exist to identify newly identified security vulnerabilities and update systems and configuration standards if necessary. Quarterly vulnerability scans/penetration tests performed by third party service organizations are recommended. Web application security reconnaissance tools such as SkipFish or W3af should also be used on a periodic basis.

Incorporate the secure development guidelines from the OWASP Guide into the software development process. Both internal and external (contractor) development personnel should be trained in secure coding techniques, such as those defined in the OWASP guide.

Documented software change management policies should include procedures for: o Documentation of impact o Management of sign-off by appropriate parties o Testing of operational functionality o Back-out procedures

Software Quality Assurance Testing

QA testing of major software releases shall employ testing techniques that use input validation frameworks to reduce risks such as cross-site scripting.


116

Access to the bug tracking database, Jira, must be limited on a need to know basis to authorized software developers and QA testers.

When actual student records are used for testing purposes, they must be disposed of when testing is completed, unless they are needed for subsequent testing activities. Electronic records must be securely deleted; paper records must be shredded. Any maintained records must be stored securely.

Physical Security

Access to Development Facilities

Access to the all Parchment engineering, production, and other data/system environments is restricted to Parchment engineers and management, and engineers and management of subcontractor development organizations. Other visitors to the facility must be escorted by Parchment personnel having supervisor or above security level. Parchment development facilities are secured by locked doors.

Data Center Security

This policy is applicable to all physical areas of the office/s of the organization, including the current production servers hosting facility and those which are available now and those which may be added in the future.

Access to the computer and transcript printing rooms will be restricted to organization authorized persons only. No public visits or tours of the server facility are permitted.

Vendor and third party representatives, if they visit the server facility, must be escorted.

A time-in and time-out register shall be maintained for the server facility.

The Corporate Security Officer will coordinate the development of server facility standards.

The server facility must maintain a reliable power supply and ensure that adequate safeguards are in place to protect the equipment.

No smoking is permitted in the server facility.

Access to Docufide Print Operations Facilities

Access to Parchment print operations facilities is restricted to Parchment management and print operations staff personnel. The Parchment Transcript Print Operations Center is housed within the Parchment West Los Angeles office in a secure area, with access limited by locked doors.

Record Holder (RH) Site Security

As part of the Docufide Client Application software installation at the record holder’s site, Parchment provides the installing institution with a school identifier code that is entered into the computer during the installation process. This identifier code is transmitted from the sending computer at the RH institution when transcripts or other student records are uploaded to Parchment for processing. This code is used to identify and authenticate the sending institution and should be treated as confidential by the sending institution. In the event that it is suspected or confirmed that this code has been communicated to unauthorized personnel, or used in an attempt to circumvent the authentication process, the sending institution’s account should be deactivated until a new identifier code can be issued.


117

Employee Home Office Facilities

Since it is not practical to require physical access restrictions in a home office environment, it is necessary for employees working in a home environment to adhere to practices that promote reasonable security for sensitive and proprietary company materials. In no case, however, should transcript data or transcript copies be maintained in hard copy or electronic form in a home office environment. When it is necessary to work with such materials in the home office environment, they should be sourced from a secure Parchment server and, when work is finished, deleted from the local PC memory and hard disk drives.

Home office PCs must be secured with logon names and strong passwords.

Users must shut down the machine or log off when not physically present.

Home office networks must be protected with a commercially available SOHO firewall (for example Linksys). Such firewalls must be configured with a documented standard that cannot be altered by employees. Computer and IT systems must never be directly accessible on the internet.

From any public or home network, a VPN must be used to access all corporate resources.

Employees must shred any hard copy transcripts they have after use and delete transcripts from their computer when no longer needed.

Home office computers will be furnished, at the discretion of the company, to certain employees. These computers are to be used for company-related activities only, and will be configured in such a way as to limit their use to company-related activities.


118

8.0 Appendix III Service Levels

1. Parchment will use commercially reasonable efforts, commensurate with the severity of the error, to correct any malfunction, defect, or non-conformity in the operation of the Parchment services to substantially perform in accordance with the Documentation. Licensee shall be responsible for conducting adequate research with respect to a Defect or related issue prior to contacting Parchment for assistance. Licensee is obligated to respond promptly to all reasonable Parchment requests for pertinent information, documentation, technical and other assistance to assist Parchment with problem resolution. A reported issue shall be logged and tracked by Parchment, and assigned a unique identifier that can be used by Licensee to refer to the reported issue, and will remain open until the issue is resolved. Reported issues will be assigned a severity level that is mutually agreed upon by Licensee and Parchment.

2. Parchment will employ commercially reasonable efforts to correct, or address with an action

plan, issues reported by Licensee as follows: a. Severity 1: Within four (4) business hours of receipt of the reported issue or its

detection by Parchment. Level 1 is defined as a condition in which all or a critical function within the Parchment services is unavailable to Licensee.

b. Severity 2: Within two (2) business days of receipt of the reported error. Level 2 is defined as a condition in which the Parchment services is not fully performing, but is still able to operate at a reduced capacity.

c. Severity 3: Within five (5) business days of receipt of the reported error. Severity 3 is defined as a condition where the Licensee is experiencing a non-critical loss of function.

3. System Enhancements and Functionality Improvements.

a. Parchment shall respond to requests for enhancements or upgraded workflow functionality within thirty (30) business days. The response shall include a valuation of the request and whether it was an item for inclusion within the product roadmap or would be considered a client specific customization. Enhancements and improvements cover a desire to change either the look and feel or workflow of a feature or function within the Parchment services. Any enhancements, modifications or improvements to the Parchment services will be considered part of the Parchment services.

b. Parchment may perform maintenance to the Parchment services during its preexisting maintenance schedule (currently 11 p.m. – 2 a.m. Pacific Time daily) hardware, or infrastructure necessary for the proper operation of the Parchment services. During these periods, the Service may be unavailable to Licensee. Parchment will notify Licensee at least two (2) business days in advance of any planned maintenance. Parchment may change planned maintenance windows at its sole discretion and will notify Licensee of any such changes that affect previously notified plans, provided such maintenance is done during low-volume times. Parchment shall also post notifications on both the Parchment services and Parchment Site notifying interested parties of any planned service outages.

4. Parchment shall use reasonable commercial efforts to make the Parchment services available

ninety-nine and one-half percent (99.5%) of the time, measured monthly, exclusive of planned


119

maintenance and any of the following events that will not be considered downtime for the purposes of such measurement:

a. Any outage lasting less than five (5) minutes; b. Any outage determined to be a result of Licensee’s breach of the Agreement or other

acts or omissions of Licensee; c. Any outage determined to be a result of a failure of outside services or equipment not

within the control of Parchment, including Licensee’s hardware and software; or d. Any outage determined to be beyond the reasonable control of Parchment, its

subcontractors and/or business partners, including a force majeure event.

5. Licensee is responsible for (i) maintenance and management of its computer network(s), servers, software, and any equipment or services related to maintenance and management of the foregoing; and (ii) correctly configuring its systems in accordance with the documentation. Licensee will promptly notify Parchment in the event any downtime occurs. Downtime will be deemed to begin when Parchment receives accurate notification thereof from Licensee, or when Parchment first becomes aware of such downtime, whichever first occurs. The obligations of Parchment set forth in this Exhibit B will be excused to the extent any failures to meet such obligations result in whole or in part from Licensee’s failure(s) to meet the foregoing requirements.

6. Parchment will use reasonable commercial efforts to respond to any email inquiries through the

Parchment Site by Record Owners within two (2) business days.

7. Licensee’s sole and exclusive remedy, and Parchment’s sole and exclusive liability, for Parchment’s breach of this Exhibit B will be the following credits. If Parchment fails to meet the service level in Section 4 in any month for a specific Parchment service, Parchment shall credit to Licensee one percent (1%) of the monthly subscription fee paid by Licensee (i.e., the prorated annual subscription fee) for such Parchment service for each cumulative hour, or portion thereof, of unavailability of such Parchment service in that month, up to a maximum of fifty percent (50%) the prorated monthly subscription fee paid by Licensee.


120

9.0 Appendix IV IData Requirement and Design Document Requirements and Design Document: Transcript Request – Parchment

1.0 Introduction

1.1 Purpose of this document

This document contains the business and functional requirements and the high-level design for the Parchment Docufide Sender integration to the Ellucian Banner student information system. The document is intended to be a vehicle through which the technical details of the integration solution can be recorded and shared with developers, implementers, and project stakeholders. Details in this document may change as the project progresses.

1.2 Background

Parchment, Inc. offers a transcript request and delivery service called Docufide Sender. Parchment has requested IData implement a standard interface between Docufide and any institutional SIS. The functional goal of the integrations will be to create transcript requests in the SIS and return either an exception (hold), the actual transcript in PESC XML, or print the report at the school.

2.0 General Description

2.1 Overview

The goal of the project is to implement an integration solution that can be easily deployed at any institution. To accomplish this goal, development in the Banner system will be minimal.

The Banner integration will consist of two main components, the IDataHub integration tool and enhancements to the Banner SIS. The IDataHub, a stand-alone Java-based integration tool, will periodically poll the Docufide system for pending transcript requests using existing Docufide APIs. Upon receiving a transcript request, the IDataHub will locate the requesting student in Banner and will produce a transcript using the details provided by Docufide.

If the requesting student cannot be found within Banner, the IDataHub will return a hold to Parchment and the school will be notified using a daily digest. In the event that multiple students are found within Banner, a user will need to manually determine which, if any, of the found students matches the request. The IDataHub will contain a student resolution form to aide with identifying the matching student.

If the requesting student has an active hold in the Banner system preventing the transcript from being printed, the IDataHub will cancel the request and return an error response back to Docufide and the school will be notified using a daily digest. The request will remain active in the Docufide system for up to thirty days and will be reprocessed by the IDataHub in subsequent runs until the request is successfully processed or is purged from Docufide.


121

2.2 User Characteristics

Users of the Docufide Sender integration can be categorized into three main groups described below. Any single person may fit into more than one category, but the categories describe the way in which the users will use the system.

Students - Students and former students will request transcripts through the Docufide Student User Interface. These users are expected to be knowledgeable in basic web application usage and will access Docufide from the institution’s website or portal or at www.docufide.com.

Registrar Office Staff - Members of the registrar’s office staff will manage the transcript request process in Banner and within the IDataHub. Staff members will review details of completed transcript requests in the Banner transcript queue and will be responsible for identifying unresolved student matches through the student resolution form within the IDataHub. These users are expected to have access to Banner and have experience using Banner screens and forms. These users are also expected to be knowledgeable in basic web application usage.

System Administrators - System administrators will be responsible for configuring and maintaining the IDataHub as well as reviewing logs of IDataHub transactions. These users are expected to be knowledgeable in general system administration practices and techniques and will access the IDataHub through the web interface as well as the operating system command line.

Docufide Sender Banner Integration Use Cases


122

3.0 Functional Requirements

The Docufide Banner connector will contain the following features and functions described below to meet the business needs of the integration:

Receive and Process Transcript Requests from Docufide - The integration will allow Banner to receive and process transcript requests made through the Docufide system. Transcripts will be requested by former or current students via the Docufide Student User Interface. The integration must receive the transcript requests and process them in a timely manner.

Find Requesting Student in Banner - The integration must find the requesting student within the Banner system using identifying information provided by Docufide. Identifying information could include first name, last name, date of birth, portion of social security number, and/or unique student ID. Once the requesting student is identified within the Banner system, the transcript will be produced for that student.

Resolve Multiple Student Matches - If multiple students are found within Banner using the identifying information provided by Docufide, the integration must allow and facilitate manual intervention to resolve the student match. The integration must provide enough information to the user to enable them to successfully identify the requesting student among the list of potential matches.

Transcript Request Queue - All successful transcript requests originating from Docufide must be logged in the Banner transcript request queue when processed. This will provide users with the ability to review Docufide transcript requests in the same manner and place as other transcript requests made through the existing Banner processes.

Transcript Format - The interface must support producing transcripts in either a standard PESC XML data file format or printed copies. The interface will rely on existing Banner processes to produce transcripts and will not in any way alter the format of the transcripts produced.

Deliver Transcripts to Docufide - Upon generating the transcript, the integration must send the resulting data file to Docufide. The delivered transcript must be matched back to the requesting student.

Student Holds - If a transcript hold exists for a student in Banner, the transcript hold must be honored and the student will be notified through the Docufide system. Student holds honored by the integration will include any holds that prevent transcripts from being produced through the normal Banner transcript request process. The transcript request will be automatically processed if the hold is released within a certain timeframe established by the Docufide system. Note: Docufide will continue to send the request for a set period of time and the hold will be checked each time.

Notification - Certain events occurring within the transcript request process must trigger notification to appropriate recipients. In the event of an unresolved student match, the integration must notify one or more registrar staff members of the pending student request requiring manual resolution. In the event of a student hold, the requesting student will be notified via email through the Docufide system.


123

4.0 Business Processes

The integration between Parchment and the ERP follows the following flow:

IDataHub calls Parchment to get pending Transcript Requests

IDataHub calls ERP common matching or duplicate checking API

o If the student is not found, a hold message will be sent to Parchment.

o If the student is put in suspend, the record is put on a temporary table for manual resolution

Once the student is matched, it will continue with the normal processing

If the student is not match, Parchment gets a hold message

Once the student is matched, holds are checked

o If holds are found, the record may be returned to Parchment or it may still allow for transcript printing

Request is added to request queue

o Paper Delivery it’s added to regular SHRTRTC processing

Request may be executed directly from queue or wait until sleep/wake finishes

o Electronic Delivery will execute SHRPESE logic directly

A cron procedure in the IDataHub gets generated transcripts

o If transcript is for an existing Docufide request it is sent to Docufide

A cron procedure in the IDataHub that sends a daily digest to a list of users based on configuration

4.1 Retrieve Pending Requests from Parchment

IData uses AXIS and WSDL2Java to create the necessary Java objects for the IDataHub tasks.

The Parchment task in the IDataHub will call the getPendingTranscriptRequestsForSenderByCeebCode.

public PendingTranscriptsResponse getPendingTranscriptRequestsForSenderByCeebCode( String ceebCode ) throws ApiFault;

4.1.1 Holds

A service at Parchment can be used to put the request on hold. This service will be used in two cases: If the student cannot be matched at all, and if the student can be matched but a hold is found.

public TranscriptActionResponse holdTranscriptRequest(TranscriptRequest transcriptRequest) throws ApiFault;

This method can be called after the initial common matching process or after the manual duplicate resolution process.

4.2 Common Matching API

Banner Common Matching API will be used in order to match the requester of a transcript to students in Banner. IData will not create a new rule. An existing rule in GORCMRL will be provided by the school


124

for the IDataHub to use. The rule name will be a parameter in the Hub so it can be changed in the future.

The API GP_COMMON_MATCHING has three steps:

Inserting record to match

Executing Matching process

Retrieving Potentials

4.2.1 Step 1

GP_COMMON_MATCHING process starts by inserting the available data of the record to match into gotcmme using the following procedure:

Procedure p_insert_gotcmme ( p_last_name IN gotcmme.gotcmme_last_name%TYPE,

p_entity_cde IN gotcmme.gotcmme_entity_cde%TYPE,

p_first_name IN gotcmme.gotcmme_first_name%TYPE DEFAULT NULL,

p_mi IN gotcmme.gotcmme_mi%TYPE DEFAULT NULL,

p_id IN gotcmme.gotcmme_id%TYPE DEFAULT NULL,

p_street_line1 IN gotcmme.gotcmme_street_line1%TYPE DEFAULT NULL,

p_city IN gotcmme.gotcmme_city%TYPE DEFAULT NULL,

p_stat_code IN gotcmme.gotcmme_stat_code%TYPE DEFAULT NULL,

p_zip IN gotcmme.gotcmme_zip%TYPE DEFAULT NULL,

p_natn_code IN gotcmme.gotcmme_natn_code%TYPE DEFAULT NULL,

p_cnty_code IN gotcmme.gotcmme_cnty_code%TYPE DEFAULT NULL,

p_phone_area IN gotcmme.gotcmme_phone_area%TYPE DEFAULT NULL,

p_phone_number IN gotcmme.gotcmme_phone_number%TYPE DEFAULT NULL,

p_ssn IN gotcmme.gotcmme_ssn%TYPE DEFAULT NULL,

p_birth_day IN gotcmme.gotcmme_birth_day%TYPE DEFAULT NULL,

p_birth_mon IN gotcmme.gotcmme_birth_mon%TYPE DEFAULT NULL,

p_birth_year IN gotcmme.gotcmme_birth_year%TYPE DEFAULT NULL,

p_sex IN gotcmme.gotcmme_sex%TYPE DEFAULT NULL,

p_email_address IN gotcmme.gotcmme_email_address%TYPE DEFAULT NULL

4.2.2 Step 2

The matching rule is executed. CMSC_CODE is the common matching rule provided by the school. If match_status is (N)ew, the record could not be found and a hold will need to be returned to Docufide immediately. If the record is (M)atched, the pidm is returned and we can now check for holds for this student. If the record is (S)uspended, the record needs to be added to a table in the Hub for later manual resolution.

Procedure p_common_matching ( p_cmsc_code IN gorcmsr.gorcmsr_cmsc_code%TYPE,

p_match_status_out OUT gotcmrt.gotcmrt_result_ind%TYPE,

p_match_pidm_out OUT gotcmrt.gotcmrt_pidm%TYPE )


125

4.2.3 Step 3

This step will not be executed as part of the initial matching. This step will only be executed from the resolution screen. If the record has been put in suspend, a query to GOTCMRT will return the data about the potential matches for reporting. This information is not permanently stored anywhere, and the table gets purged after the session is closed.

COLUMN_NAME TYPE COMMENTS Parchment

GOTCMRT_CMSC_CODE VARCHAR80

SOURCE CODE: The source code used by the Common Matching process.

GOTCMRT_CMSR_PRIORITY_NO NUMBER22,2

PRIORITY NUMBER: Priority number of rule to be processed.

GOTCMRT_PIDM NUMBER22,8

PIDM: The pidm returned as matched or suspense for the rule as a result of the Common Matching process.

GOTCMRT_RESULT_TYPE VARCHAR4

RESULT TYPE: Primary match that generated the result.

GOTCMRT_MATCH_COUNT NUMBER22,2 MATCH COUNT: Internal use only.

GOTCMRT_MISSING_COUNT NUMBER22,2 MISSING COUNT: Internal use only.

GOTCMRT_UNMATCH_COUNT NUMBER22,2 UNMATCH COUNT: Internal use only.

GOTCMRT_MESSAGE VARCHAR1000

MESSAGE: The results of the Common Matching identifying match conditions that are met or unmet.

GOTCMRT_RESULT_IND VARCHAR4 RESULT INDICATOR: Match result for the row.

GOTCMRT_SPRIDEN_ID_ROWID VARCHAR72

ID ROWID: The rowid of the spriden record returned for the ID match.

GOTCMRT_SPRIDEN_NAME_ROWID VARCHAR72 NAME ROWID: The rowid of


126

the spriden record returned for the NAME match.

GOTCMRT_SPRADDR_ROWID VARCHAR72

ADDRESS ROWID: The rowid of the spraddr record returned for an address match.

GOTCMRT_SPRTELE_ROWID VARCHAR72

TELEPHONE ROWID: The rowid of the sprtele record returned for a telephone match.

GOTCMRT_GOREMAL_ROWID VARCHAR72

E-MAIL ROWID: The rowid of the goremal record returned for an e-mail match.


127

4.3 Holds verification API

SPRHOLD holds hold information by student and date. STVHLDD indicates which holds prevent transcript printing (STVHLDD_TRANS_HOLD_IND).

The API GB_HOLD has a function that returns if a hold exists on a particular date. We are going to use this function with the p_trans_hold = ‘Y’ in order to get holds that prevent transcript printing.

FUNCTION f_hold_exists(p_pidm sprhold.sprhold_pidm%TYPE,

p_reg_hold stvhldd.stvhldd_reg_hold_ind%TYPE DEFAULT NULL,

p_trans_hold stvhldd.stvhldd_trans_hold_ind%TYPE DEFAULT NULL,

p_grad_hold stvhldd.stvhldd_grad_hold_ind%TYPE DEFAULT NULL,

p_grade_hold stvhldd.stvhldd_grade_hold_ind%TYPE DEFAULT NULL,

p_ar_hold stvhldd.stvhldd_ar_hold_ind%TYPE DEFAULT NULL,

p_env_hold stvhldd.stvhldd_env_hold_ind%TYPE DEFAULT NULL,

p_app_hold stvhldd.stvhldd_application_hold_ind%TYPE DEFAULT NULL,

p_compl_hold stvhldd.stvhldd_compliance_hold_ind%TYPE DEFAULT NULL,

p_date DATE DEFAULT SYSDATE) RETURN VARCHAR2;

If a hold exists, we can still enter the request in the transcript queue for processing (override the hold), or we can use holdTranscriptRequest via Docufide so the student is informed about the situation.

4.3.1 Holds

A service at Parchment can be used to put the request on hold.

public TranscriptActionResponse holdTranscriptRequest(TranscriptRequest transcriptRequest) throws ApiFault;

This method can be called after the initial common matching process or after the manual duplicate resolution process.

4.4 Transcript Request API

This process needs to duplicate the logic from SHARTQC. The ID of the student would be known since the matching process has already been resolved. We would also know that the student does not have holds that prevent the transcript generation.


128

Insert the request into SHTTRAN. SHTTRAN has a HOLD_GRDE_IND and HOLD_DEGR_IND fields to hold for grades and hold for degrees that we could use in order to not have to manage the holds in the IDataHub.

COLUMN_NAME TYPE COMMENTS Parchment

SHTTRAN_USER varchar30

Transcript Request User. Identifies the user who entered a transcript request to cause this temporary table to be built to store the information about the transcript.

PARCHMENT

SHTTRAN_PIDM number8 Internal Identification of Student with transcript request.

Based on duplicate checking

SHTTRAN_SEQ_NO number3 Sequence Number of the transcript request for the student.

Increase from previous request

SHTTRAN_ID varchar9 Students Identification Number. Banner ID

SHTTRAN_TYPE varchar1

Transcript Send Type. Indicates if the transcript is to be sent via EDI or printed on paper. Valid values are: E - EDI. P - PESC/XML, blank or Null - printed transcript.

P for PESC/XML for electronic delivery and null for mail delivery

SHTTRAN_TERM varchar6 Term Code. Identifies the term the transcript was requested.

Current term: As defined by the term with the greatest start date that has not already ended (using STVTERM dates)

SHTTRAN_LEVL_CODE varchar2

Level Code. Identifies the level (Undergraduate, Graduate, etc.) the transcript was requested for.

Use AL for all levels

SHTTRAN_COLL_CODE varchar6 Use all colleges

SHTTRAN_ADDR_NAME varchar185

Address Name. Identifies the recipient of the transcript.

As provided by Parchment

SHTTRAN_STREET1 varchar75 Street Address Line 1 of transcript address.





129



SHTTRAN_CITY varchar50 City of transcript address. As provided by Parchment

SHTTRAN_STAT_CODE varchar3 State Code of transcript address. As provided by Parchment

SHTTRAN_ZIP varchar30 Zip Code of transcript address. As provided by Parchment

SHTTRAN_DETC_DETAIL_CODE varchar4

Detail Code. Identifies charge detail code to be placed on the students account in billing for requesting a transcript.

Null since the school will not bill for the transcript

SHTTRAN_DETC_AMOUNT number12,2

Detail Code Amount. Identifies the amount to be charged for the transcript request.

0

SHTTRAN_DETC_DESC varchar30

Detail Code Description. Identifies the description of the charge detail code if it differs from the default on the Detail Code Control Form.

Null

SHTTRAN_REQUEST_DATE date Request Date. Identifies the date the transcript was requested.

Date of the request on Parchment

SHTTRAN_PRINT_DATE date Print Date. Identifies the date the transcript request was printed.

Automatic

SHTTRAN_ACTIVITY_DATE date Activity Date. Specifies the date record was created or updated.

Sysdate

SHTTRAN_ERROR_IND varchar1 This field is currently not used.

SHTTRAN_PRINTER varchar30 Printer which was designated at sign on time.

IDataHub configuration

SHTTRAN_SESSIONID varchar30 Sessionid at signon time. Null

SHTTRAN_TPRT_CODE varchar4 Transcript type which is to be used for this transcript request

PARCHMENT or a type defined at the school

SHTTRAN_NO_COPIES number Number of copies of this transcript requested

1


130

SHTTRAN_OFFICIAL_IND varchar1

Indicator denoting whether the transcript is official/unofficial. Y=yes, N=no.

Y

SHTTRAN_TERM_CODE_DETC varchar6 Billing detail code. Null

SHTTRAN_TERM_CODE_IN_PRG varchar6 Cutoff term for in-progress reporting.

Current term

SHTTRAN_NATN_CODE varchar5

Code which has been set up to represent designated nation. Valid codes on nation system table.

SHTTRAN_EDI_SENT_DATE date EDI Sent Date. Identifies the date the transcript was generated for EDI.

Automatic

SHTTRAN_EDI_STATUS_DATE date

EDI Status Date. Identifies the date the EDI status was received through the reconciliation process.

Automatic

SHTTRAN_EDIS_CODE varchar2

EDI Status. Indicates the status of the transfer of the transcript to the receiving institution. Updated by the reconciliation program SHREDIR. Valid values are in table STVEDIS.

Automatic

SHTTRAN_EDI_REQUEST_NUM number

EDI Request Number. A sequential number assigned to each EDI transcript request, used for matching in the EDI reconciliation process.

Automatic

SHTTRAN_SBGI_CODE varchar2

Source/Background Institution Code. Identifies the institution the student wants the transcript sent to.

PARCHMENT or the SBGI if the CEEB is provided and can be matched

SHTTRAN_HOLD_GRDE_IND varchar1

Transcript Request Temporary Table indicator field for holding grades until after end of term processing.

As provided by parchment

SHTTRAN_HOLD_DEGR_IND varchar1

Transcript Request Temporary Table indicator field for holding grades until after degree processing.

As provided by parchment

SHTTRAN_WSSO_CODE varchar4

Transcript Request Temporary Table web self-services option for the request.


131

SHTTRAN_WPYO_CODE varchar4 Transcript Request Temporary Table web payment option for the request.

SHTTRAN_SENT_DATE date Transcript Request Temporary Table sent date for the request.

SHTTRAN_WPYO_RECEIPT_NUMBER number8

Transcript Request Temporary Table receipt number for the request.

SHTTRAN_PHONE_AREA varchar12 Transcript Request Temporary Table area code for recipient of request.

SHTTRAN_PHONE_NUMBER varchar10

Transcript Request Temporary Table phone number for recipient of request.

SHTTRAN_PHONE_EXT varchar16

Transcript Request Temporary Table phone extension for recipient of request.

SHTTRAN_INTL_ACCESS varchar16

Transcript Request Temporary Table international access number for recipient of request.

SHTTRAN_CTRY_CODE_PHONE varchar4

COUNTRY CODE: Telephone code that designates the region and country.

SHTTRAN_STREET_LINE4 varchar75 STREET LINE4: This field maintains line four of the street address.

SHTTRAN_HOUSE_NUMBER varchar10 HOUSE NUMBER: Building number in a street or area.

* NOTE: This is a Banner table and will not be modified


132

The submission of the job SHRTRTC will print the requested transcript immediately. The job can be initiated as a regular job submission automatically from the Hub, or the same logic used in the job can be used on an API without creating a job.

SHRPESE will be used for electronic requests. The banner package sb_pesc_status_export provides the Common Business Interface for the PESC Status Export API (sb_pesc_status_export). This API is responsible for accessing the SHREPTD table, which holds export records for the XML transcript. SHRPESE, run in sleep/wake or on demand, returns the XML transcripts:

April 11, 2012 11:30:00 AM Parchment PESC/XML Export Process SHRPESE Page 1

Student SBGI Seq Message

ID Code No

--------- ------ ---- --------------------------------------------------------------------------------

Carrion 111 1 Transcript Successfully Sent. File is:

/u01/jobsub/pescxmlexport_12345_1.xml

12345 is the actual pidm of the student. This information may be used in the following step.

4.5 Send Generated Transcript to Parchment

An IDataHub file sweeper will be sweeping the configured folder (/u01/jobsub/ in the example) in order to get pescxmlexport_pidm_#.xml files. The pidm information will be used to match to a pending request in the Hub tables. If the pending request is found, the file will be sent to parchment using approveTranscriptRequest() and the file will be moved to a processed folder.

public TranscriptActionResponse approveTranscriptRequest(TranscriptRequest transcriptRequest) throws ApiFault;

Transcripts delivered by mail (using SHRTRTC) will send a different message to Parchment:

public TranscriptActionResponse transcriptRequestPrinted(TranscriptRequest transcriptRequest) throws ApiFault;

4.6 Daily Digest

A procedure will be setup in the Hub to read the pending transcripts table and it will send an email to the list of users configured in the Hub with a list of transcript requests that were returned to Parchment because the student record was not found or because of a hold; the list of students in the matching table; and the list of transcripts that were successfully loaded into the system. This job will be configured to run early in the morning and return this information for the transcripts requests for the previous day.

5.0 Delivered IDataHub Components

5.1 IDataHub Procedure to Read Pending Requests

This procedure can be executed as frequently as desired. It will be configured by default to run every 15 minutes. The following tasks are executed:

Call Docufide and pull pending requests

Run Common Matching for each request received


133

If a student is set to suspend, insert into transcript request table and into duplicate holding table

If a student is not matched, send holdTranscriptRequest to Docufide

If a student is matched, check holds. If holds exist, send holdTranscriptRequest to Docufide

If a student is matched and there are no holds, insert into SHTTRAN

If delivery method of the request is configured for immediate delivery (electronic), run the process to generate this transcript (not used)


134

5.2 IDataHub Procedure to send Generated Transcripts

This procedure can be executed as frequently as desired. It will be configured by default to run every 15 minutes. The following tasks are executed:

Select pending request from transcripts request table (only electronic transfers, printed ones will managed entirely in the ERP)

For each request look for a file (with the name template defined) that contains the .xml for that request

Call Docufide approveTranscriptRequest


135

5.3 IDataHub Procedure for daily digest

This procedure will be run daily. It will select from the duplicate holding and the transcript request tables and send an email to users

5.4 Duplicate Resolution Screen

This page that will hold the students with duplicates that needs to be manually resolved.


136

5.4.1 Duplicate Holding table

This table is used to store student information while the request is pending because duplicates have been found. This table will reside in the IDataHub H2 database, not in the school’s database.

Field Notes

ID Internal ID used to match to the Request Holding Table

LAST_NAME

FIRST_NAME

MI Banner ID or Colleague ID if the request has been entered using the school’s portal

ERP_ID

STREET_LINE1

CITY

STAT_CODE

ZIP

NATN_CODE

CNTY_CODE

PHONE_AREA

PHONE_NUMBER

SSN

BIRTH_DAY

BIRTH_MONTH

BIRTH_YEAR

GENDER

EMAIL_ADDRESS


137

5.5 Transcript Request table

This table is used in order to store the basic information about the request for three purposes:

1. Populate SHTTRAN to start the request in Banner

2. Match the transcripts created in Banner with the requests in order to send the transcript back to Parchment

3. Used by the daily digest to select records to send by email

Field Notes

ERP_ID

LAST_NAME

DUP_ID ID of the duplicate holding table in case this id is not yet resolved

HOLD_FOR_DEGREE

HOLD_FOR_GRADE

DELIVERY_METHOD

ATTENTION

CITY

COUNTRY

COUNTY

LINE1

LINE2

STATE

ZIP

DOCUMENT_ID

STATUS

STATUS_DATE

DATE_SENT


138

IDataHub Hardware & Software Requirements

SERVER REQUIREMENTS

The IDataHub will require 1 GB of available disk space per installation. Depending on services provided by the IDataHub, additional disk space may be needed for logging data.

The IDataHub will require at least 1 GB of available RAM per active installation. Actual RAM usage may vary depending on the services provided by the IDataHub. Specific memory requirements for your implementation can be provided by IData upon request.

The DB size in the file system can be reduced regularly by deleting logs at debug level older than 30 days and by running a command to free empty space (these scripts will be provided to the client and scheduled by default).

OS REQUIREMENTS

Linux

Windows

Unix

SOFTWARE REQUIREMENTS

Java 1.6 ( or above )

The IDataHub ships with a Tomcat6 instance and an H2 DB (100% Java). If the institution wishes to use an existing Webserver or existing JDBC Databases, the IDataHub would need to be reconfigured.

FIREWALLS AND SECURITY

A port needs to be open for the UI to access the WS. This port may be restricted to IDataHub UI’s IP.

Institutions have the option to deploy the UI locally in order not to open the firewall. In this case the UI will be given to the school, but changes will not be supported.

SSL certificate from a valid CA in order to enable HTTPS

ERP ACCESS

The IDataHub needs to communicate with the institution ERP. o The IDataHub uses an unprivileged user defined in the ERP. The name of the user can

be decided by the institution following their naming conventions.

SSH account in the ERP server to transfer files (configured with Public/Private Key for non-interactive login).

Shared folders (Some implementations shared folders may be used to transfer files from the IDataHub to the ERP).


139

10.0 Appendix IV PESC Seal of Approval Notification

state of south carolina electronic transcript...

Documents