Requesting for a Proposal
The following are items that Cybersoft should be provided in order to fully understand the project and come up with an accurate methodology and price proposal:
Data Process Overview
In order for Cybersoft to create a data conversion proposal for a client, the first step is to provide an overview of the EXISTING process (if it is already being done by the client at their facility or is being outsourced elsewhere). For example,
- Where will the source documents come from?
- Do the documents come as paper or electronic files?
- What is the purpose of the data that is keyed?
The questionnaire provided with this documentation (please refer to the section below) can be used as a guide in providing an overview of the existing process.
Hardware / Software Requirements
In some instances, Cybersoft can evaluate from the DATA PROCESS OVERVIEW itself if there is a need to procure any special hardware or software in order to perform the data entry or to produce the output file. For example, if the existing methodology is to data enter medical bills into a HIPAA compliant software, Cybersoft will have to be given the name of this software (or even a copy of it) in order to evaluate if data entry can be done OFFLINE (without using the software) and then be imported later on into the software application.
Telecommunications Requirements
Does Cybersoft need to be connected into the client’s network in order to perform the data conversion activity? If so, please describe the existing infrastructure and where and how will Cybersoft be provided access.
General Assumptions
The general assumptions section will be main portion of the request for the proposal. This section will contain information from which Cybersoft will base the benchmarking procedures and price options. The "data conversion assumptions" section of the questionnaire that is included in this document (refer to the section below) contains the most common assumptions expected to be provided to Cybersoft.
Sample document
The MOST IMPORTANT thing in the request is to provide a sample or samples of documents that would most likely represent the general population of the documents. It is recommended that a sample of the easiest and the hardest document to key should be provided.
Statement of Security
Client has to inform Cybersoft the LEVEL of importance of the document security. For example, can the documents be replicated and then sent to Cybersoft? Does it need to be returned immediately after keying? If the source documents originally come as hard copies and are scanned as image files (e.g. TIF files), will there be a need to implement VERY HIGH LEVELS of data transfer security features? The client must be made aware that higher levels of security will entail additional costs.
Keying details
The keying details will be the "technical" portion of the request. It should give Cybersoft a complete picture of what is to be keyed. Typical information contained in this section should be:
What are the exact information that needs to be captured from the source document? A list of all the FIELDS should be given (e.g. Doctor’s name, Date, Patient Name, SSN, etc.).
WHERE in the source document can these FIELDS be found? The most common way of presenting this is to have a sample document MARKED with numbers corresponding to the actual FIELDS.
Are there special RULES in keying? For example,
do we need to convert certain information into codes
do we need to key ALL information in upper case
do we drop special characters on certain fields (e.g. comma, colons, periods, etc.)
Fields lengths: Do you want us to limit the maximum number of characters that will be keyed for each of the fields?
Training
This is where the client would state their preference on how they would want to train the Cybersoft operators in capturing the needed information. In most instances, if the keying details are self explanatory enough, training will no longer be necessary. Cybersoft can suggest various methods for the training if it is necessary.
Fee structure
The fee structure would inform Cybersoft of how the client prefers the output to be paid. In most occasions, these are based on the number of RECORDS that were produced (e.g. one output record is equivalent to one medical billing document). This is ideal when the same type of information will always be keyed for every document. If there is a large variance in the length of information keyed from every single document, the alternative pricing structure would be based on the OUTPUT CHARACTERS produced.