State of South Carolina
Electronic Transcript
Services
Parchment Technical Response to
Solicitation # 5400004871
REDACTED
Parchment, Inc.
Hewlett-Packard
11/1/2012
Parchment, Inc.
6263 N. Scottsdale Road, Suite 170, Scottsdale AZ 85250
11/1/2012
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 moconnor@parchment.com or 972.672.6254.
Sincerely,
Mathew Pittinsky, CEO
Parchment, Inc.
Corporate HQ
6263 N. Scottsdale Road Suite 330 Scottsdale, AZ 85250
Phone: 480.719.1646 Fax: 480.991.2333
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Table of Contents
1.0
MINIMAL REQUIREMENTS ................................................................................................................. 2
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
2.0
Solution Architecture ........................................................................................................................................2
User Authentication .........................................................................................................................................3
Document Compliancy .....................................................................................................................................3
Output Formats ...............................................................................................................................................4
Delivery Options .............................................................................................................................................5
Institution Customization ..................................................................................................................................5
Student Transcript Request Process ....................................................................................................................5
Student Transcript Receipt ................................................................................................................................ 6
Notification Process .........................................................................................................................................6
Reports………………………………………………………………………………………………………………….7
Value Added Services .......................................................................................................................................8
Acceptance ................................................................................................................................................... 10
TECHNICAL PROPOSAL ...................................................................................................................... 11
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
Solution Architecture ...................................................................................................................................... 11
System and Data Security ................................................................................................................................ 11
Integration .................................................................................................................................................... 25
Development Plans ........................................................................................................................................ 27
Implementation Process .................................................................................................................................. 29
Support and Service Level Agreements (SLAs) ................................................................................................... 40
Student Transcript Request and Processing the Request ....................................................................................... 45
Institution Delivery Process ............................................................................................................................. 56
Notification Process ....................................................................................................................................... 59
Reports………………………………………………………………………………………………………………...60
Training ........................................................................................................................................................ 64
Documentation .............................................................................................................................................. 65
Proposal and Solution Documentation .............................................................................................................. 66
3.0
MINORITY PARTICIPATION .............................................................................................................. 71
4.0
OFFSHORE CONTRACTING ............................................................................................................... 72
5.0
QUALIFICATIONS ................................................................................................................................. 73
5.1
5.2
5.3
5.4
5.5
5.6
5.7
6.0
History of the offeror's experience in providing work of similar size and scope. ...................................................... 73
Financial Statements. ...................................................................................................................................... 75
References .................................................................................................................................................... 76
Customer List ................................................................................................................................................ 80
List of failed projects, suspensions, debarments, and significant litigation. ............................................................... 86
List the development resources in place to maintain and enhance the electronic transcript solution. ........................... 86
Organizational Structure of Programs. ............................................................................................................... 87
Appendix I Docufide by Parchment Screenshots ..................................................................................... 89
6.1
6.2
6.3
Student Workflow Screenshots......................................................................................................................... 89
Sender Administrator Screenshots .................................................................................................................... 97
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
1
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
2
Electronic Transcript Services
Technical Response
1.2
Solicitation # 5400004871
November 1, 2012
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
3
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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 standardsbased 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
4
Electronic Transcript Services
Technical Response
1.5
Solicitation # 5400004871
November 1, 2012
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
5
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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).
6
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
7
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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”.
8
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
9
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
10
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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).
11
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Logical Network Diagram
Production
Internet
FTP Server
(Prod)
Web Services 01
(Prod)
Render Servers
Load Balancer 01
DB Servers
DB Replication
Web Services 02
(Prod)
Internal Firewall
Admin Servers
QA
Web Services 03
(QA)
Perimeter Firewall
Border Router
Load Balancer 02
Development
Web Services 04
(QA)
Render Servers
Render Servers
Web Service 05
(Dev)
DB Servers
DB Servers
Parchment
Logical Network
Diagram
8/31/2012
A 01.00
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
12
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
13
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012

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:
14
Electronic Transcript Services
Technical Response







Solicitation # 5400004871
November 1, 2012
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 Parchmentassigned 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
15
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
16
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
17
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
18
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
19
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
20
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
21
Electronic Transcript Services
Technical Response



Solicitation # 5400004871
November 1, 2012
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.
22
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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 webbased format and as downloadable documents through the Parchment website. Including:

Web-based end-user tutorials and subject references
23
Electronic Transcript Services
Technical Response





Solicitation # 5400004871
November 1, 2012
“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
24
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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:
25
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
26
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
27
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
28
Electronic Transcript Services
Technical Response
2.5
Solicitation # 5400004871
November 1, 2012
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
29
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
30
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Estimated resources to implement the SIS integration include:
ACTION
Environment Setup
Implementation Design
Transcript Output Preparation
Single Sign-On Integration
Testing
Service Launch Planning
Training
PERSONEL
REQUIRED
LEVEL OF EFFORT
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.
31
Electronic Transcript Services
Technical Response
Areas
of
Responsibility
Solicitation # 5400004871
November 1, 2012
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:
32
Electronic Transcript Services
Technical Response




Solicitation # 5400004871
November 1, 2012
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
Docufide Sender
Implementation
60 days
Mon
1/14/13
Mon
1 day
1/14/13
Mon
19 days
1/14/13
15 days Mon
Fri
4/5/13
Mon
1/14/13
Thu
2
2/7/13
Fri
2FS+5 days
Launch Call
Test Environment Setup
Setup Remote Access / ERP
Predecessors
Resource Names
Institution,IData,Parchment
Institution,Parchment,IData
Institution
Institution
33
Electronic Transcript Services
Technical Response
Development Environment
Submit Institution Request
Form
Solicitation # 5400004871
November 1, 2012
1/14/13
Mon
1/14/13
Wed
1/30/13
Thu
1/31/13
Fri
2/1/13
Fri
2/1/13
2/1/13
Tue
1/15/13
Wed
1/30/13
Thu
1/31/13
Fri
2/1/13
Fri
2/1/13
Thu
2/7/13
Thu
2/7/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
1 day
Mon
2/4/13
1 day
Mon
2/4/13
2 days
Register for BlazerID
1 day
Sumbit BlazerID
1 day
Provision Access to BlazerID
1 day
Create IDataHub Test Server
1 day
Establish Test Server
Connectivity from IDataHub to
ERP Test Environment
Establish Test Server
Connectivity to Parchment
Open TCP traffic to
207.178.213.163:443
Open TCP traffic to
207.178.213.180:22
Open TCP traffic to
207.178.213.176:443
Establish File Retrieval Access
from Test Server to ERP Test
Environment
Establish Access to IDataHub
Resolution Screen on Test
Server
1 day
1 day
1 day
1 day
1 day
Mon
2/4/13
Integration Design and
128
Mon
Customization
days
1/21/13
Mon
ERP Process Walk Through
1 day
1/21/13
Design Document Customized
Mon
4 days
for ERP
1/28/13
Design Document Review
Fri
1 day
Meeting
2/1/13
Mon
Design Document Approval
5 days
2/4/13
Sweep Process to run
Tue
5 days
transcripts
1/22/13
Transcript Output Preparation 18 days Tue
Install IDataHub on Test Server 1 day
2
IData
5FS+10 days
IData
6
IData
7
Institution
7
Institution
8FS+3 days
Institution
2FS+5 days
Institution
9
Institution
9
Institution
9
Institution
Mon
2/4/13
9
Institution
Mon
2/4/13
9
Institution
9
IData
2
Institution,IData,Parchment
2FS+7 days
Institution,Parchment,IData
19
IData
20
Institution,Parchment,IData
21
Institution
2FS+5 days
Institution
2
Institution,IData,Parchment
Mon
2/4/13
Wed
7/17/13
Mon
1/21/13
Thu
1/31/13
Fri
2/1/13
Fri
2/8/13
Mon
1/28/13
Thu
34
Electronic Transcript Services
Technical Response
1/22/13
Submit Transcript Branding
Tue
1 day
Files
1/29/13
Tue
Submit Signature
1 day
1/29/13
Tue
Submit Seal
1 day
1/29/13
Tue
Submit Legend
1 day
1/29/13
Create plaintext transcript
Tue
8 days
Output
1/22/13
Mon
Submit Test Transcript Files
9 days
2/4/13
Determine Initial Test Student
Mon
1 day
Records List
2/4/13
International Student
Mon
1 day
Addresses
2/4/13
Mon
Graduated Students
1 day
2/4/13
Mon
Graduate Degrees
1 day
2/4/13
Mon
Undergraduate Degrees
1 day
2/4/13
Send Test Transcripts to
Tue
2 days
Parchment
2/5/13
Prepare Transcript Template
Thu
1 day
from Test Transcripts
2/7/13
Submit Sample Outputs for
Tue
2 days
Review
2/5/13
Thu
Review Sample Transcripts
5 days
2/7/13
Approve Sample Transcript
Thu
1 day
Output
2/14/13
Integration Development and
Thu
51 days
Testing
1/31/13
SSO Integration Development
Thu
48 days
and Testing
1/31/13
Thu
SSO Launch Meeting
1 day
1/31/13
Develop Portal Code to Call
Fri
5 days
Docufide SSO Web service
2/1/13
Fri
Test Use Cases
1 day
2/8/13
Solicitation # 5400004871
November 1, 2012
2/14/13
Tue
1/29/13
Tue
1/29/13
Tue
1/29/13
Tue
1/29/13
Thu
1/31/13
Thu
2/14/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Mon
2/4/13
Wed
2/6/13
Thu
2/7/13
Wed
2/6/13
Wed
2/13/13
Thu
2/14/13
Thu
4/11/13
Mon
4/8/13
Thu
1/31/13
Thu
2/7/13
Fri
2/8/13
2FS+10 days
Institution
Institution
Institution
Institution
2FS+5 days
Institution
IData
4
Institution,IData
Institution
Institution
Institution
Institution
31
IData,Institution
36
Parchment
26,27,28,31,15 Parchment
38
Institution
39
Institution
Institution,IData,Parchment
Institution,Parchment
2FS+12 days
Institution,Parchment
43
Institution
44
Institution
35
Electronic Transcript Services
Technical Response
Student First Pass from Portal
to Docufide, Completes
Registration
Student First Pass from Portal
to Docufide, Signs In to Existing
Account
Student Second Pass from
Portal to Docufide,
Automatically Signed In
Deploy Portal Code to
Production
Submit Production Test
Confirm Production Test
Solicitation # 5400004871
November 1, 2012
1 day
Fri
2/8/13
Fri
2/8/13
44
Institution
1 day
Fri
2/8/13
Fri
2/8/13
44
Institution
1 day
Fri
2/8/13
Fri
2/8/13
44
Institution
90FS-2 days
Institution
49
Institution
50
Institution
22
Institution,IData,Parchment
9FS+5 days
IData
Thu
4/4/13
Fri
1 day
4/5/13
Mon
1 day
4/8/13
Mon
44 days
2/11/13
Mon
3 days
2/11/13
1 day
IDataHub Development and
Testing
Create Hub task to pull in
Transcript Requests
Create Hub Procedure to
Schedule and Initiate Call to
3 days
Retrieve and Queue Requests
Create Hub Procedure to
Process a Single Request from 3 days
the Queue
Create Hub Task for
Sending/Holding the Transcript 2 days
File
Create ERP Call for Matching
Create ERP Call for Hold
Checking
Create ERP Call for Request
Creation
Create Hub Procedure to
Monitor for Completed
Transcripts and Respond to
Parchment
Create Parameter Screen and
Configuration Values for the
ERP options
Create Custom Student
Matching API
Create Custom Hold validation
Thu
4/4/13
Fri
4/5/13
Mon
4/8/13
Thu
4/11/13
Wed
2/13/13
Thu
Mon
53
2/14/13 2/18/13
IData
Tue
Thu
54
2/19/13 2/21/13
IData
Fri
Mon
55
2/22/13 2/25/13
IData
Tue
2/26/13
Thu
2/28/13
Tue
3/5/13
Wed
56
2/27/13
Mon
57
3/4/13
Thu
58
3/7/13
2 days
Fri
3/8/13
Mon
59
3/11/13
IData
2 days
Tue
Wed
60
3/12/13 3/13/13
IData
2 days
3 days
3 days
2 days
2 days
Thu
Fri
61
3/14/13 3/15/13
Mon
Tue
62
IData
IData
IData
IData
IData
36
Electronic Transcript Services
Technical Response
API
Create Custom Request
Creation API
Create Custom Table to Store
Index for Transcript Table
3/18/13
Wed
2 days
3/20/13
Fri
2 days
3/22/13
Tue
Integration Testing
2 days
3/26/13
Thu
Integration Walk Through
1 day
3/28/13
Data Verification and Handling
Thu
2 days
Confirmation
3/28/13
Fri
Acceptance Testing
10 days
3/29/13
Mon
Code Rework
2 days
4/1/13
Wed
Deploy IDataHub to Production 1 day
4/3/13
Deliver IDataHub
Mon
Documentation and Install
1 day
3/11/13
Guide
Tue
Production Environment Setup 6 days
2/5/13
Create IDataHub Production
Tue
1 day
Server
2/5/13
Establish Production Server
Tue
Connectivity from IDataHub to 1 day
2/5/13
ERP
Establish Production Server
Tue
1 day
Connectivity to Parchment
2/5/13
Establish File Retrieval Access
Wed
1 day
from Production Server to ERP
2/6/13
Install IDataHub on Production
Wed
1 day
Server
2/6/13
Migrate Test Configuration to
Thu
2 days
Production Server
2/7/13
Mon
Production Test
2 days
2/11/13
Mon
Service Launch Planning
60 days
1/14/13
Schedule Service Adoption
Tue
Meeting with Account
10 days
1/15/13
Executive
Attend Service Adoption
1 day Tue
Solicitation # 5400004871
November 1, 2012
3/19/13
Thu
3/21/13
Mon
3/25/13
Wed
3/27/13
Thu
3/28/13
Fri
3/29/13
Thu
4/11/13
Tue
4/2/13
Wed
4/3/13
63
IData
64
IData
65
IData,Institution,Parchment
66
IData,Institution,Parchment
66
IData
67
Institution
68
IData
70
Institution,IData
Mon
90FS-20 days
3/11/13
Tue
17
2/12/13
Tue
17
2/5/13
Tue
2/5/13
Tue
2/5/13
Wed
2/6/13
Wed
2/6/13
Fri
2/8/13
Tue
2/12/13
Fri
4/5/13
IData
Institution
Institution
17
Institution
17
Institution
74
Institution
74
IData
78
IData,Institution
79
Institution
Institution,IData,Parchment
Mon
2
1/28/13
Institution
Tue
Institution,Parchment
82
37
Electronic Transcript Services
Technical Response
Meeting
Develop Student
Communication Plan
1/29/13
Mon
10 days
1/14/13
Thu
Schedule Staff Training
1 day
3/28/13
Fri
Staff Training
1 day
3/29/13
Thu
Select go-live Date
1 day
3/28/13
Deliver IDataHub
Thu
1 day
Documentation
4/4/13
Thu
Technical Handoff of IDataHub 1 day
4/4/13
Fri
Go-live with Docufide Sender 1 day
4/5/13
Solicitation # 5400004871
November 1, 2012
1/29/13
Fri
1/25/13
Thu
3/28/13
Fri
3/29/13
Thu
3/28/13
Thu
4/4/13
Thu
4/4/13
Fri
4/5/13
90FS-60 days
Institution
66
Institution
85
Institution,Parchment
66
Institution
71
IData
71
Institution,IData,Parchment
89
Institution,Parchment
2.5.1.4 The software development methodology utilized to support the project
Software Development




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.
38
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
39
Electronic Transcript Services
Technical Response
2.6
Solicitation # 5400004871
November 1, 2012
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.
40
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
41
Electronic Transcript Services
Technical Response

Solicitation # 5400004871
November 1, 2012
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
Incidents having a high/critical and

immediate impact on Parchment’s
business or service to customers
High


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
42
Electronic Transcript Services
Technical Response
Medium
Solicitation # 5400004871
November 1, 2012
Incidents having significant impact, or

the potential to have critical impact

on Parchment’s business or service to
customers

Low
Incidents having potential to have a

significant 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
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
43
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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 security@parchment.com.
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.
44
Electronic Transcript Services
Technical Response



Solicitation # 5400004871
November 1, 2012
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.
45
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
46
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
47
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
48
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
49
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
50
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
51
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
52
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
53
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Administrators are able to review students and recipients for each transcript request.
54
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
55
Electronic Transcript Services
Technical Response
2.8
Solicitation # 5400004871
November 1, 2012
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.
56
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
57
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
58
Electronic Transcript Services
Technical Response
2.9
Solicitation # 5400004871
November 1, 2012
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.
59
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
60
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
61
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
62
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
63
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
2.10.3 The Offeror must describe:
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 The Offeror must describe:
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
64
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
65
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
66
Electronic Transcript Services
Technical Response



Solicitation # 5400004871
November 1, 2012
 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
67
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
Production
Internet
FTP Server
(Prod)
Web Services 01
(Prod)
Render Servers
Load Balancer 01
DB Servers
DB Replication
Web Services 02
(Prod)
Internal Firewall
Admin Servers
QA
Web Services 03
(QA)
Perimeter Firewall
Border Router
Load Balancer 02
Development
Web Services 04
(QA)
Render Servers
Render Servers
Web Service 05
(Dev)
DB Servers
DB Servers
Parchment
Logical Network
Diagram
8/31/2012
A 01.00
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
68
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
69
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
70
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.)
71
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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, ECommerce 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 offshore 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.
72
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
73
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
74
Electronic Transcript Services
Technical Response
5.2
Solicitation # 5400004871
November 1, 2012
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.
75
Electronic Transcript Services
Technical Response
5.3
Solicitation # 5400004871
November 1, 2012
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
csunata@calpoly.edu
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
cmahlmann@tcc.edu
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
Carrie.cumming@wmich.edu
269- 387-1000
76
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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]
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: jukane@pa.gov
Relation/Role to Project: PDE e-Transcript Project Higher Education Contact
End Date Year: July 1, 2013
77
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Name of Client &
Project Title
South Carolina Department of Education
Nature and Scope of
Project:
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]
Nature of the Client:
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.
End Date Year: [on-going]
The office provides ad hoc research services for the Department and other
constituents and produces school and district report cards for the
accountability system.
Nature of Client
Audience:
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
# & Composition of
Vendor Employees &
Consultants Assigned:
1 Project Manager
1 Account Manager
1 Data Engineer
6 Customer Support Representatives
1 Project Director
Client Contact
Information:
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
tolson@ed.sc.gov
Relation/Role to Project – SC DOE e-Transcript project contact
78
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Name of Client &
Project Title
Indiana e-Transcript Statewide Initiative
Nature and Scope of
Project:
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]
Nature of Client
Audience:
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
# & Composition of
Vendor Employees &
Consultants Assigned:
1 Project Manager
1 Account Manager
1 Data Engineer
6 Customer Support Representatives
1 Project Director
Client Contact
Information:
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: kens@che.state.in.us
Relation/Role to Project: Indiana e-Transcript Project Contact
Nature of the Client:
79
Electronic Transcript Services
Technical Response
5.4
Solicitation # 5400004871
November 1, 2012
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
80
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
81
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
82
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
83
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
84
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
85
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
86
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
87
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Programs Account Development Organizational Chart
Programs Transcript and Support Services Organizational Chart
Programs Services Organizational Chart
88
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
89
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Students and Alumni Confirm Enrollment Information
90
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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..
91
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
92
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
93
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
94
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
95
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
The student or alumni can log into their account 24/7 and check Status/History to have real time
access to their request details.
96
Electronic Transcript Services
Technical Response
6.2
Solicitation # 5400004871
November 1, 2012
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.
97
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
98
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
99
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
The built in reporting engine enables the administrator to create reports based on requested dates,
student, destination, etc.
100
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
The Docufide Sender Solution is a SaaS solution that allows for administrator control over several user
preferences presented in the screenshots below.
101
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
102
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Provide a personalized welcome
message to students and alumni and
upload your logo for additional
customization.
103
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Flexible ecommerce options that will allow SC Institutions to manage and define a variety of
ecommerce settings.
104
Electronic Transcript Services
Technical Response
6.3
Solicitation # 5400004871
November 1, 2012
Receiver Administrator Screenshots
Dashboard for Receivers show items needing attention, quick links and vital statistics.
105
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
106
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
107
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
108
Electronic Transcript Services
Technical Response







Solicitation # 5400004871
November 1, 2012
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.
109
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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 tokenbased 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 nonprivileged 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 systemsupplied default shall be six months.
The system shall provide an algorithm for ensuring the complexity of user-entered passwords.
110
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
111
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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:
112
Electronic Transcript Services
Technical Response















Solicitation # 5400004871
November 1, 2012
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
Security Admin
Type
Description
(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,
Ops only
TOC print server
Acct Mgmt
113
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Transcript materials
Postage meter
IT system reports
Engr only
Dev, test systems
Acct Mgmt only
Customer (RI, RH) data
Operations
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
(TPO staff)
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).
114
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
Software Development




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.
115
Electronic Transcript Services
Technical Response


Solicitation # 5400004871
November 1, 2012
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.
116
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
117
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
118
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
119
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
120
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
121
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
122
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
123
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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 )
124
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
VARCHAR80
SOURCE CODE: The source
code used by the Common
Matching process.
NUMBER22,2
PRIORITY NUMBER: Priority
number of rule to be
processed.
NUMBER22,8
PIDM: The pidm returned as
matched or suspense for the
rule as a result of the
Common Matching process.
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.
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
GOTCMRT_CMSC_CODE
GOTCMRT_CMSR_PRIORITY_NO
GOTCMRT_PIDM
GOTCMRT_RESULT_TYPE
GOTCMRT_UNMATCH_COUNT
Parchment
NAME ROWID: The rowid of
125
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
the spriden record returned
for the NAME match.
GOTCMRT_SPRADDR_ROWID
GOTCMRT_SPRTELE_ROWID
GOTCMRT_GOREMAL_ROWID
VARCHAR72
ADDRESS ROWID: The rowid
of the spraddr record
returned for an address
match.
VARCHAR72
TELEPHONE ROWID: The
rowid of the sprtele record
returned for a telephone
match.
VARCHAR72
E-MAIL ROWID: The rowid
of the goremal record
returned for an e-mail
match.
126
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
127
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
varchar30
Transcript Request User. Identifies the PARCHMENT
user who entered a transcript request
to cause this temporary table to be
built to store the information about
the transcript.
SHTTRAN_PIDM
number8
Internal Identification of Student with Based on duplicate
transcript request.
checking
SHTTRAN_SEQ_NO
number3
Sequence Number of the transcript Increase
from
request for the student.
previous request
SHTTRAN_ID
varchar9
Students Identification Number.
Banner ID
P for PESC/XML for
electronic delivery
and null for mail
delivery
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.
varchar6
Current term: As
defined by the term
with the greatest
start date that has
not already ended
Term Code. Identifies the term the (using
STVTERM
transcript was requested.
dates)
SHTTRAN_LEVL_CODE
varchar2
Level Code. Identifies the level Use AL for all levels
(Undergraduate, Graduate, etc.) the
transcript was requested for.
SHTTRAN_COLL_CODE
varchar6
varchar18
5
Address Name. Identifies the recipient As provided
of the transcript.
Parchment
by
SHTTRAN_ADDR_NAME
varchar75
Street Address Line 1 of transcript As provided
address.
Parchment
by
SHTTRAN_STREET1
by
varchar75
Street Address Line 2 of transcript As provided
address.
Parchment
SHTTRAN_USER
SHTTRAN_TYPE
SHTTRAN_TERM
SHTTRAN_STREET2
Parchment
Use all colleges
128
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
Street Address Line 3 of transcript As provided
address.
Parchment
by
varchar75
by
SHTTRAN_CITY
varchar50
City of transcript address.
As provided
Parchment
varchar3
State Code of transcript address.
As provided
Parchment
by
SHTTRAN_STAT_CODE
varchar30
Zip Code of transcript address.
As provided
Parchment
by
SHTTRAN_ZIP
SHTTRAN_DETC_DETAIL_COD
E
varchar4
Detail Code. Identifies charge detail Null since the school
code to be placed on the students will not bill for the
account in billing for requesting a transcript
transcript.
SHTTRAN_DETC_AMOUNT
number12
,2
Detail Code Amount. Identifies the 0
amount to be charged for the
transcript request.
varchar30
Detail Code Description. Identifies the Null
description of the charge detail code if
it differs from the default on the Detail
Code Control Form.
SHTTRAN_REQUEST_DATE
date
Request Date. Identifies the date the Date of the request
transcript was requested.
on Parchment
SHTTRAN_PRINT_DATE
date
Print Date. Identifies the date the Automatic
transcript request was printed.
SHTTRAN_ACTIVITY_DATE
date
Activity Date. Specifies the date record Sysdate
was created or updated.
SHTTRAN_ERROR_IND
varchar1
This field is currently not used.
SHTTRAN_PRINTER
varchar30
Printer which was designated at sign IDataHub
on time.
configuration
SHTTRAN_SESSIONID
varchar30
Sessionid at signon time.
SHTTRAN_TPRT_CODE
varchar4
PARCHMENT or a
Transcript type which is to be used for type defined at the
this transcript request
school
SHTTRAN_NO_COPIES
number
Number of copies of this transcript 1
requested
SHTTRAN_STREET3
SHTTRAN_DETC_DESC
Null
129
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
SHTTRAN_OFFICIAL_IND
varchar1
Indicator denoting whether the Y
transcript is official/unofficial. Y=yes,
N=no.
SHTTRAN_TERM_CODE_DETC
varchar6
Billing detail code.
SHTTRAN_TERM_CODE_IN_P
RG
varchar6
Cutoff term for in-progress reporting.
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 Automatic
transcript was generated for EDI.
date
EDI Status Date. Identifies the date Automatic
the EDI status was received through
the reconciliation process.
varchar2
EDI Status. Indicates the status of the Automatic
transfer of the transcript to the
receiving institution. Updated by the
reconciliation program SHREDIR. Valid
values are in table STVEDIS.
number
EDI Request Number. A sequential Automatic
number assigned to each EDI
transcript request, used for matching
in the EDI reconciliation process.
varchar2
PARCHMENT or the
Source/Background Institution Code. SBGI if the CEEB is
Identifies the institution the student provided and can be
wants the transcript sent to.
matched
by
varchar1
Transcript Request Temporary Table As provided
indicator field for holding grades until parchment
after end of term processing.
by
varchar1
Transcript Request Temporary Table As provided
indicator field for holding grades until parchment
after degree processing.
varchar4
Transcript Request Temporary Table
web self-services option for the
request.
SHTTRAN_EDI_STATUS_DATE
SHTTRAN_EDIS_CODE
SHTTRAN_EDI_REQUEST_NU
M
SHTTRAN_SBGI_CODE
SHTTRAN_HOLD_GRDE_IND
SHTTRAN_HOLD_DEGR_IND
SHTTRAN_WSSO_CODE
Null
Current term
130
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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_N
UMBER
number8
Transcript Request Temporary Table
receipt number for the request.
SHTTRAN_PHONE_AREA
varchar12
Transcript Request Temporary Table
area code for recipient of request.
varchar10
Transcript Request Temporary Table
phone number for recipient of
request.
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_PHON
E
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.
SHTTRAN_WPYO_CODE
SHTTRAN_PHONE_NUMBER
SHTTRAN_PHONE_EXT
* NOTE: This is a Banner table and will not be modified
131
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
throws ApiFault;
approveTranscriptRequest(TranscriptRequest
transcriptRequest)
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
132
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012

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)
133
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
134
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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.
135
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
5.4.1Duplicate 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
136
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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
137
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
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 noninteractive login).
Shared folders (Some implementations shared folders may be used to transfer files from
the IDataHub to the ERP).
138
Electronic Transcript Services
Technical Response
Solicitation # 5400004871
November 1, 2012
10.0 Appendix IV PESC Seal of Approval Notification
139