DRAFT OUTLINE v.1.3.5
Topic / Editor / Date Received / Date ReviewedReceipting / Doug Allen / 1/8/2015 / 1/27/2015
Scanning / Scott Malfitano / 1/8/2015 / 1/13/2015
Internet Availability / Scott Malfitano / 1/8/2015 / 1/13/2015
Data Entry / Nancy Sotomayor / 1/27/2015
Redaction of PII / Nancy Sotomayor / 1/27/2015 / 3/10/2015
Searching and Printing / Karl Trottnow / 1/12/2015 / 2/10/2015
Quality Control / Karl Trottnow / 1/12/2015 / 2/10/2015
Accounting / Larry Burtness / 1/7/2015 / 1/27/2015
Preservation / Larry Burtness / 1/7/2015 / 2/10/2015
Reports / Nancy Becker / 1/13/2015 / 2/24/2015
System Performance & Reliability / Nancy Becker / 1/13/2015 / 2/24/2015
eRecording / Vicki DiPasquale / 1/7/2015 / 1/13/2015
New Functionality Wish List / Vicki DiPasquale / 1/7/2015 / 1/13/2015
Integrations/Interfaces / Vicki DiPasquale / 1/7/2015 / 1/13/2015
Conversions / Ann Richards / 1/7/2015 / 1/13/2015
Workflow / Ann Richards / 1/8/2015 / 1/13/2015
Document Management / Kathy Taylor / 1/7/2015 / 1/13/2015
Security / Mihir Shah / 1/9/2015
Infrastructure (proprietary v. open software) / Doug Allen / 1/12/2015 / 3/10/2015
Disaster Recovery / Mark Wingfield / 1/9/2015
Most recent outline submissions received have been appended to the end…
eRecording (Vicki DiPasquale)
· Flexible workflow
o Receive/edit fees
o Receive/edit index data
o Change document types
· Minimum indexing requirements (standardizing formats)
· Robust reporting for batch payments (ACH)
· Safeguards to prevent duplicate recordings
· Standardized rejection reasons
· Compare fees – submitters calculations versus county calculations
· Consistent procedures for handling fee discrepancies
· View Notes from submitter (nuances related to the document or package)
· Accept and process helper documents (not recordable, but needed to communicate recording expectations)
· Receive/track electronic package identifiers
· Standardized document types (generic by state where possible)
· Limited document types- generic categories (ease of use by submitter)
· Standardization of requirements and workflow by state not by county
· Ease of adding new submitters
· Produce a daily report indicating documents submitted, recorded, rejected
New Functionality Wish List (Vicki DiPasquale)
· Flexible workflow
o Receive/edit index data
o Change document types
o Fee calculation review and changes
o Communications between parties
· API/Web services capable
· Real time post for public access to indexes and images
· Robust searching capabilities
· Built-in automated indexing rules
· Auto populate indexes with common names/phrases
· Standardized document types
· Flexible accounting and reporting
Integrations/Interfaces (Vicki DiPasquale)
· Standardized
o API/web services calls
o Field names
o Index formats
o Communication protocols
· Receive/track electronic package identifiers
· Automated notifications/trouble reporting
· Exports and imports
· Batch requests/bulk extracts
Accounting (Larry Burtness)
· Overview of accounting best practices for recording jurisdictions – 30,000 ft. level
· Balancing across multiple workstations, cash drawers, or tills at any time during the day
o All tender types
· Reporting of daily transactions
o Canned reports, modification of reports and custom reports
· Weekly, monthly, quarterly and annual reports, with focus on fees collected
· Ability by supervisory staff to resolve any out of balance condition
· Account management; draw-down, billing accounts
o Includes ability to make adjustments to accounts
· Payment process management
o Draw-down, billing, credit card, ACH
· Invoicing process and statements for users with accounts
· Ability to facilitate refund process for overpayments
· Timely upload automated integration of accounting data to county accounting system or commercial accounting package
· Ability by supervisor to closeout all work stations, cash drawers or tills
· Cashiering verification
Preservation (Larry Burtness)
· Overview of preservation as records management tool – 30,000 ft. level
o Digital, microfilm, or both
o State and local records retention requirements
· Extract functionality and flexibility
o Images
o Data
· Images
o Format - variety
o DPI
o other
· Data
o Format - variety
o Required fields
§ Grantee/grantor
§ Recording number
§ Recording date
o Optional fields
§ APN – required instead of optional?
§ Legal description
Document Management (Kathy Taylor)
I. DMS definition:
As it applies to LRMS systems
II. Typical DMS Components:
A. Capture
Scanners, multi-function devices, import, ‘send to’, ‘print to’, download
Tiff, PDF, jpeg, grayscale, native Windows format
B. Search/retrieval
Seamless integration with OR database
C. Output
View, print, email, fax, reports
D. Routing
To supervisor, work queue etc.
E. Storage/Archival
Permanent image storage, backup
III. Basics:
A. Seamless interface to Cashiering/Recording
B. Configurable
C. Scalable/expandable
D. Append, insert, replace, annotation & image enhancement
E. Easy to use and administer
F. Non proprietary-industry standards with regular program upgrades
G. Import/Export capability
H. Audit Trails
I. Remote capture
J. E-Recording interfaces
K. Compliant with local mandates, regulations, customs
L. Backup
M. Ability to assign county file number and/or print labels
IV. Features based on size/need of county:
A. Barcode
B. Redaction
C. Email management
D. Full text search
E. Auto indexing
F. API option and/or interfaces to other software programs
G. Offsite backup/Image Storage
H. Web interface
I. Support local doc type needs (passports, marriage licenses, applications, confidential)
J. Hosted/cloud option
K. Custom programming availability
Conversions (Ann Richards)
1. Amount of data and images to be converted.
There are multiple options for a Recording Jurisdiction when choosing the number of years and the amount of data and images to be converted from a legacy system. Cost and frequency of use may be factors that would limit a full and complete conversion.
BP: LRMS should have the capability to accomplish a full data conversion when implemented, as well as offering the Recorder the ability to convert historical files incrementally as needed.
2. Location of data and images when converted.
Legacy systems may have images stored inside or outside the database.
BP: Storing images outside the data base and using pointers within the application from the data to the images will allow for a much cleaner and easier conversion process in the future. When a new LRMS is required, the images can remain intact with only the data needing to be converted.
3. Images with no data.
Historical files may have images with very little associated data, such as only book and page.
BP: LRMS with database image pointers will allow historical images to be viewed so that complete data information can be entered into database.
4. Database Key Values
Database key values are important to maintain from the legacy system to a new LRMS.
BP: To enable verification of data from one system to another, the document key values in the database need to be carried forward or maintained in such a way that information can be easily validated from the legacy system to the new LRMS, especially if a conflict surfaces after implementation at a future date.
5. Conversion Plan (All of these items need to be fleshed out.)
LRMS should have a documented, detailed plan for conversion of legacy data. Setting a PRIA standard – if moving from one system to another, this is how the data should align.
a. Conversion Site
i. Recording Jurisdiction
ii. Vendor Site
b. Conversion Cycle
i. Initial Phase (70% - 85% complete)
ii. Weekly Phase (80% - 90% complete)
iii. Daily Phase (90% – 100% complete)
c. Conversion Tools
i. SQL Server 2008 Migration Assistant for Oracle
ii. SQL Server Integration Services
iii. Custom Scripting
d. Data Anomalies
i. Corrective steps
ii. Remedial interaction
iii. Redaction
e. Data Validation
i. Record count comparisons
ii. Report reconciliations
iii. System configuration comparisons
iv. Sampling use cases
v. User feedback
vi. Parallel testing
Workflow (Ann Richards)
I. Workflow
A. Full Service (over the counter)
B. Centralized queues
a. Functionality
b. Sample listing
i. Index Queue
ii. Verify Queue
iii. Suspense Queue
iv. eRecording
v. etc. etc.
C. Document Return
a. Courier
b. Express Mail
c. Regular Mail
D. Processes
a. Indexing
b. Scanning
i. Up-front
ii. Centralized
c. Verifying
i. Key Verify
ii. Sight Verify
d. eRecording
i. Into queue for verification
ii. Transparent / “Lights out”
e. Additional Processes
i. Marriage Licenses
ii. Passports
iii. Birth/Death Certificates
iv. Back Post Import
v. Back Post Index
vi. Back Post Verify
vii. Export
Scanning (Scott Malfitano)
1. Functionality (purpose)
2. Scanner Requirements
a. OCR (Optical Character Recognition)
i. Software or hardware component required?
ii. Software - no special requirements
iii. Hardware - limitation with the type of scanner
3. Requirements
a. Black & white or color?
i. Black & white preferred, color creates files 10x the size of normal files
b. PDF or Tiff (both)
i. Tiff format group four fax
ii. PDF standard
c. Size Legal, or letter or oversized?
i. Some counties only accept one
ii. Compression of legal documents
d. DPI Printing resolution? 240 and 300 DPI is preferred
i. Submitters scan at one DPI
ii. eRecording delivery agents deliver it in the specific county requirement
e. PRIA create universal DPI standards
4. Ownership of equipment
5. System Training
6. Future Technology
7. Accessibility
a. Accessibility by those with disabilities
b. Option to save as PDFA or PDFUA for accessibility
Internet Availability (Scott Malfitano)
1. Connectivity requirements
2. Type of connectivity - ISDN, dial up, business cable, etc.
3. Standard Procedures when internet is down
a. Queuing of documents from eDelivery agents
4. Notifications
a. to LRMS
b. to eDelivery agents
c. to submitters
5. Establish a universal notification language
a. If PRIA compliant, a notification is sent to recording vendors which is then sent to their submitters
b. Require a smooth transition between both system
6. Duplicate Recording notification
a. Often uncovered with a submissions when a county is offline
b. Notification protection procedures
c. Standardization of paper vs. electronic (voids)
d. Time out error is kicked back, a system slow down or temporary disruption of service
i. Ensure docs have not been previously submitted
ii. Check ID or Document comparison of what's been previously submitted
e. Timing Alerts
i. What's the estimated time you will be back online?
ii. Pro-active alerts or notifications
Receipting (Doug Allen)
(1) Review of documents for “recordability”
(2) Calculation of fees due based on document type, page count, and specific factors like number of names, etc.
(3) Suspension of receipting for single transaction or entire batch
(43) Rejection of certain documents based on recordability and fee criteria
(54) Collection of fees – based on multiple “tender” or payment types including: cash, check, draw-down account, credit account, ACH, credit card
(65) Overrides – as authorized by a supervisor
(76) Adjusting receipts – as authorized by a supervisor
(87) Voiding receipts – as authorized by a supervisor
(98) Closing a receipting workstation, cash drawer or till
(109) Balancing the receipting workstation, cash drawer or till (individual workstation level)
(110) Establishing fees for new document types (under supervisory control)
(121) Updating fees for existing document types (under supervisory control)
(13) Finding, reprinting and forwarding receipts to submitting entity
(14) Ability to receipt miscellaneous items along with a recorded document
Security (Mihir Shah)
Security is an essential part of any software evaluation. There are many of layers of security which must be considered in relation to a Land Records Management System. These guidelines can vary drastically based on the type of products a developer offers which could be one of the following:
- Private Cloud
- Public Cloud
- Thick Client
- Mobile
o Tablet
o Smartphones
Each approach above will have specific security requirements in the technology stack.
1) Database
a. Access
b. Encryption
2) Application Server
a. Services
b. Communication
c. Access
3) File Servers(SAN/NAS)
a. Access
b. Communication
4) Web Servers
a. Communication
b. Intranet Security
c. Internet Security
d. Services
5) Desktop
a. Access
b. Permissions
6) Application
a. Authentication
i. AD
ii. Custom
iii. Open Auth
iv. Federated Auth
b. Authorization
i. User Roles
ii. User Permissions
Disaster Recovery (Mark Wingfield)
I. Onsite Disaster Recovery
A. Describe how your system provides image and data
redundancy onsite for disaster recovery.
B. Describe what your contact and escalation process is when
a disaster occurs at a clients site.
C. Please describe your hardware and server configurations to implement an onsite disaster recovery plan. Indicate your preferred backup media types.
II. Offsite Disaster Recovery
A. Please describe any type of service you provide for managing the customers
database and image repository offsite.
B. Describe your method of transferring the images and data back to a county site from
a secondary backup site.
C. Describe how we would be able to access our images and data during the recovery
III. Disaster Recovery Process
A. List the personnel to be contacted in the event of a local disaster.
B. Describe your system testing process after a disaster recovery has occurred.
C. Describe your offsite data center and list the industry security certifications for that center.
D. Describe any other disaster recovery services your company can provide
E. Describe how your organization will interface and integrate the system to work with the County’s current Disaster Recovery architecture.
IV Disaster Recovery Manuals and Documentation
A. Provide backup and disaster recovery procedure manuals for each system proposed
Searching and Printing (Karl Trottnow)
· Available online?
· Fields available for searching
· Images available?
· Should there be a cost for searching/printing?
· State/county requirements and limitations