OnBase Scope Statement - University of...

Program Management Office (PMO)____________________________________________________________

OnBaseDocument Scanning

&Image Management

ReplacementScope Statement

Document Version 5.0: DraftDocument Date: 2014-08-14


Revision HistoryRevision Date Revised By Changes Made – Reasons for the

Change1.0 2014-03-28 Steve Prevost Initial draft2.0 2014-04-09 Steve Prevost Incorporate updates from reviewers3.0 2014-04-18 Steve Prevost Incorporated updates from UPG4.0 2014-04-24 Steve Prevost Added text for batch scanning of

EOBs and Patient Correspondence Containing Multiple Patients

5.0 2014-08-14 Steve Prevost Added link to final version of the Solution Design document for Professional Billing. (p. 13)

OnBase Project Scope Page 2 of 282013-04-09 Draft


Table of ContentsRevision History..........................................................................................................................2

Project Scope Statement............................................................................................................4

Business Objectives....................................................................................................................5

Project Priority.............................................................................................................................6

High Level Project Scope............................................................................................................6Project 1 – Core Solution - Streamline Conversion and Replacement Solution for

Siemens, GE and Epic..............................................................................................6Project 1A – Registration Solution..................................................................6Project 1B – Charity Care Workflow...............................................................7Project 1C – Clinical Records Solution...........................................................9Project 1D – Billing Office Solution...............................................................11Project 1E – Disaster Recovery Consulting.................................................12Project 1F – Streamline Conversion.............................................................13

Project 2 – Pre-Arrival Services Solution.........................................................................15Project 3 – Revenue Cycle Management........................................................................17

Detailed Scope and Deliverables.............................................................................................18Registration and Clinical Record Solution........................................................................18Pre-Arrival Unit.................................................................................................................22Financial Screening.........................................................................................................23

Out of Scope..............................................................................................................................25

Project Assumptions.................................................................................................................25

Project Exclusions.....................................................................................................................25

Project Constraints....................................................................................................................25

Scope Sign-off...........................................................................................................................27



Project Scope StatementTo mitigate/resolve existing deficiencies, a new document scanning and image management solution must be installed in the UVA Health System (UVAHS). The existing Streamline Health workflow and reporting solutions are not robust and must be created and maintained by the vendor. With the ever-increasing complexity of financial regulations, a workflow solution that allows the automation of business processes by system administrators is critical to the continued success of the operation from registration to collections for both UPG and the Medical Center.

While the current system has standard reports, custom and ad hoc reporting capabilities do not exist for end-user creation and maintenance.

This project will: Implement a robust document scanning and image management solution with

significant workflow capabilities that will support/enhance business processes in both our current systems configuration as well as future state Epic.

Address the conversion to a new solution. Assure the accuracy of all converted images, data, and pointers. Convert 15 interface and integration processes. Remove existing pointers in the Epic Electronic Medical Record (EMR) and GE

Centricity Business repositories and add the new system pointers. Convert/create the Financial Screening and Correspondence workflows to the

new solution. Select workflow solutions for Denial Management, Pre-Arrival, Treasury/Cash

posting management, Registration check-in and other Revenue Cycle related work functions which are multidisciplinary across the patient continuum. Evaluate feasibility and determine prioritization of implementing these solutions in a controlled and mutually agreed upon timeline, and/or identify opportunities and apply necessary resources required to execute implementation plans, which result in improved net revenue and/or cash collections, and/or reductions in cost to collect.

Establish work queue controls and business owners that enable departmental management of key workflow drivers under pre-defined system guidelines, change management and process controls.

Ensure a build that allows additional phased work flows with minimal restructuring of initial phases.

Ensure similar change management processes are followed for work flow implementation.

Integrate the new system with Epic. Integrate the new system to Siemens Invision Resource Scheduling, Patient

Management and Patient Accounting. Integrate the new system to GE Centricity Business.



Integrate as needed workflow solutions between themselves; e.g. output from one workflow can be ingested as a work driver in another

Integrate with other scheduling systems, such as the Operating Room’s CPM. Establish a new process to archive insurance card images after 180 days and/or

a set configurable number of days by type of procedure and insurance with applicable prompts to the registration staff to request and scan new cards.

Possess the capability for decentralized registration staff to quickly and easily index images, such as insurance cards at the patient level without duplication of data entry for Medical Record Number (MRN), etc., with desk top imaging and workstation signature pads

Provide enhanced reporting capabilities. Establish protocols to permit utilization of document management/imaging

system by areas not currently using a similar solution.

Business ObjectivesThe University of Virginia Medical Center has been operating the Streamline Health AccessAnyWare, Folder View, RegScan, Data Manager, and Ultimus Workflow applications since August 2003. AccessAnyWare is deployed for document management within Health Information Services to keep patient data and documents online and secure to facilitate transactions and processes automatically from one user to the next. It is integrated with the Epic electronic health record. However, there are system deficiencies:

The system cannot provide offline access to documentation, forms scanning/completion, and subsequent database synchronization.

The system also cannot import from within Microsoft Word or Excel. The system cannot parse print streams and index documents in a single process.

Folder View allows the University Physicians Group (UPG) to manage documents from various departments across the enterprise. It also allows Patient Financial Services (PFS) to manage documents not associated with a specific patient record such as Explanation of Benefits (EOB) and cash posting batches. Drawbacks associated with Folder View:

Not integrated with the GE Centricity Business application maintained by UPG. Does not provide integration with Microsoft Outlook to allow users to import

emails and attach documents into the repository directly.

The Ultimus workflow engine is installed and supports workflows within PFS for documents associated with both charity care application processing, as well as patient correspondence. Data Manager is utilized to scan and route documents to both workflows listed above.Drawbacks associated with the Ultimus and Data Manager workflow solutions:

Technical Support for workflow related issues System stability and downtime



Printing capabilities are limited within the workflow User changes to system settings (e.g. changing/adding queues, altering times)

are cumbersome Challenges automating document indexing Batch printing is not supported Reporting capabilities are weak Workflow steps associated with patient/insurance correspondence require

multiple user touches to drive workflow including assignment of work

RegScan is utilized by Patient Access for insurance card, photo IDs, long-term signature card, and other document scanning at the point of patient registration in over 200 locations.

Project Priority 1: A discretionary project that provides significant business value or one that is

highly aligned with the strategic direction for the organization. 2: A discretionary project that provides moderate business value or one that is

moderately aligned with the strategic direction for the organization. 3: A discretionary project that provides limited business value or one that is not

aligned with the strategic direction for the organization. Non-

Discretionary: The project fulfills a regulatory requirement, operational requirement or other reason for being mandatory.

Project BudgetThe approved capital budget for the project is $1,900.000.Hyland’s approved cost estimate as found in the Services Proposal document is as follows:

Estimate Type AmountCore Solution1A Registration Solution Time and

Materials

$ 252,306.00

1B Charity Care Workflow Solution

Time and Materials

1C Clinical Records Solution Time and Materials

1D Billing Office Solution Time and Materials

1E DR Consulting Time and Materials

1F Streamline Conversion Fixed Fee $ 306,000.00


http://hstsproject1/PMO/OnBase/Project%20Documents/SERVICES%20PROPOSAL.docx


Add-on Solutions2 Pre-Arrival Services Solution Time and

Materials $119,880.00

3 Revenue Cycle Time and Materials

$125,160.00

Total $803,346.00

High Level Project ScopeAfter significant review by key stakeholders within UVAHS, Hyland Software’s OnBase Software was selected to provide the following solutions as outlined in the Services Proposal:

Project 1 – Core Solution - Streamline Conversion and Replacement Solution for Siemens, GE and Epic

Project 1A – Registration SolutionScopeThe project will consist of initiation, discovery, build, testing, training, and project management services in association with linking captured registration documents to the registration system.

Content Capturea. Day-forward capture of registration documents such as insurance card, photo

identification, and consent form; b. Capture during registration will utilize the Front Office Scanning (“FOS”)

module of the Software; i. Indexing of registration documents using Application Enabler within

Siemens Invision. c. Batch Scanning – capture may also consist of Software batch scanning for

high page-count document volumes (e.g. over forty–five (45) pages per batch); and

d. Electronic completion and signing using a device such as a tablet PC (e.g. Panasonic H1 Health Toughbook or equivalent), interactive pen display (e.g. Wacom pen display) or signature pad (e.g. Topaz SignatureGem) capable of capturing “digital ink”. The estimate includes the creation of up to seven (7) Image Documents and up to two (2) E-Forms.

Interfaces





a. Incoming ADT interface from Siemens Invision (“SMS”) capture patient and account data for fast and accurate indexing of documents scanned in batch; and

b. (Optional) Outgoing MDM interface to Epic.

Content Deliverya. Document retrieval and viewing from within any Siemens Invision and GE

Centricity Business screen using Application Enabler; andb. Document retrieval using native client(s) of the Software.

Third-party Application Integrationa. Software will integrate with the following applications using Application

Enabler:i. Siemens Invision Patient Management; andii. GE Centricity Business.

Facilitiesa. The solution will be deployed at approximately three hundred (300)

registration points for one (1) hospital which includes the following: i. University Hospital

b. The solution will be deployed at the registration points throughout the Health System. Registration points to be identified by UVAHS.

Project 1B – Charity Care WorkflowScopeThe project will consist of initiation, discovery, build, testing, training, and project management services in association with the capture and management of financial assistance documentation.

Content Capturea. Day-forward capture of financial assistance application and supporting

documentation; andb. Batch Scanning for high page-count document volumes (e.g. over forty–five

(45) pages per batch). ADT interface will be leveraged for patient demographic information in order to facilitate indexing.

Content ManagementThe Financial Screening workflow is needed to facilitate the identification, application and follow up processes that relate to patients who might need financial assistance for their care but are not eligible for Medicaid.

The concept of a charity care workflow is focused on identifying patients who require financial assistance for medical care, collect pertinent documentation, make decisions for a level of assistance and, finally, to collect those funds.



The process is initiated by an application form filled out by the patient. This form will then be routed and evaluated by a clerk to determine qualification into the process. The initial decisions that can be made are:

1. Accepting the applicant2. Unqualified Applicant 3. Intake (Indigent Care)

If the clerk decides to accept the applicant (#1), work queues will be provided as necessary to support the processing of the application, as well as gathering other supporting documentation.

If the application evaluation determines this applicant to be unqualified (#2), work queues will be provided as necessary to support the processing of the application potentially for other charity funds.

If the applicant is an Intake for Indigent Care (#3), the application will need to route so that processing of the application for Intake to Indigent Care can take place.

The workflow will also provide exception handling for any application which might be denied, including the ability to capture comments and reasons for rejections, as well as alternate routing based on a denied status.

The document types used in support of this workflow may potentially need additional security as these may be considered sensitive financial documents.

Content Deliverya. Application Enabler retrieval within Siemens Invision; andb. Document retrieval using native client(s) of the Software.

Third-party Application Integrationa. Software will integrate with the following applications using Application Enabler:

i. Siemens Invision Patient Management

InterfacesIntentionally left blank

Facilitiesa. The solution will be deployed at Patient Financial Services which include the

following: i. University Hospital

Assumptions



a. Workflow distribution of applications is completed either by a FIFO method or by a manual assignment of items;

b. Unity Forms will be utilized for the development of the electronic application document;

c. Applications will be identified as unique based on a Patient ID;d. A method to withdraw applications will be provided;e. Time-sensitive items will be monitored by the system; andf. Any pre-populated information on applications will be supplied by UVAHS’s

LOB system.

Project 1C – Clinical Records SolutionScopeThe project will consist of initiation, discovery, build, testing, training and project management services in association with linking captured clinical documents to the Epic EMR.

Content Capturea. Day-forward capture of clinical documents such as history and physical,

discharge note, and referral; b. Batch Scanning – centralized, high volume, scanning of patient records post-

discharge/visit; andc. Integrated Scanning – distributed capture for designated document types

using the Software integrated scan control from the Epic scan acquisition launch points and Epic MediaManager as required.

d. Import capability from other scanning vendors as necessary, e.g., ImageX.

Content Managementa. Deficiency Analysis – analysis of scanned documents for missing signature

deficiency from Epic Health Information Management (“HIM”) Chart Deficiency. Notification of signature deficiencies to assigned physician in-basket;

b. Physician Completion – resolving deficiencies of scanned chart documents from Epic HIM Chart Deficiency and the electronic signing of a deficiency from the physician in-basket. Initial physician metadata load for Epic HIM Signature Deficiency integration with Software will be executed in a one-time bulk import with subsequent updates provided in the same format. UVAHS will provide the physician metadata from an Epic Clarity report which will be scheduled to automatically import into the Software;

c. Release of Information (“ROI”) - Software plug-in integration with Epic Print server for integrated printing of ROI requests from Epic’s ROI application. Software-stored documents must be linked to Epic in order to be included in the ROI print request;



d. Document Exception Process - misfile errors and duplicate scans will be managed using the Software Exceptions Workflow (“Workflow Solution”). Corrections made through the misfile process will be executed in the Software exceptions Workflow user interface; and

e. The Software will not systematically execute un-merging of patient information. Un-merging will be completed as a manual re-index.

Interfacesa. HL7 interfaces will be leveraged for both inbound and outbound data

communication with Software:ii. Incoming ADT interface to capture patient and encounter data from

Siemens Invision; andiii. Outbound MDM interface to link documents to the Epic EMR.

Content Deliverya. Document retrieval using native client(s) of the Software; b. Integrated single document retrieval from document hyperlinks within the

patient record in Epic’s Chart Review using the API integration between the Software and Epic; and

c. Patient Viewer from the Epic activity button.

Third-party Application Integrationsa. Software will integrate with the following applications:

i. GE Centricity Business;ii. EpicCare (ambulatory); iii. EpicCare (inpatient); andiv. Epic Health Information Management:

1. Chart Deficiencies (inpatient); and2. Release of Information.

Facilitiesa. The solution will be deployed at the centralized scanning points for one (1)

hospital which includes the following: i. University Hospital; and

b. The solution will be deployed at Health System clinics. Clinics to be identified by UVAHS.

Project 1D – Billing Office SolutionScopeThe project will consist of initiation, discovery build, testing, training, and project management services in association with the capture and retrieval of remittance and correspondence documents for the billing departments (Medical Center and UPG).



Correspondence and EOBs will be retrievable within the context of the patient account within the billing systems. Content Capture

a. Day-forward capture of billing office documents such as EOBs, correspondence, and UPG miscellaneous documents (like for like with current LanVision/Streamline Health solution);

b. Batch Scanning – centralized, high volume, scanning of paper EOBs, correspondence, and UPG miscellaneous documents;

c. 835 Import – schedule required imports of EDI 835 files using the 835 Processor module with the standard XML style sheet of the Software; and

d. Electronic lockbox images or index files as required, provided by the UVAHS or third party will be imported into the Software system leveraging the Document Import Processor (“DIP”) module. Any content, encrypted or proprietary, not readable by out-of-the-box (“OOTB”) DIP will require custom development and is not included in this estimate.

Content Managementa. Correspondence document routing and management will use out-of-the-box

(“OOTB”) functionality of purchased Software (i.e. custom queries or Workflow) to include the UPG miscellaneous documents. The services estimate includes up to the following functionality:

i. Five (5) custom queries; or ii. A single Workflow lifecycle of three (3) queues, six (6) ad-hoc or

system tasks, and two (2) notifications; andiii. The creation of Workflow E-forms (an electronic HTML form acting

as a document in Software) is not included in this estimate.b. Batch Scanning of EOBs and Patient Correspondence Containing Multiple

Patientsi. UVAHS receives EOBs and other miscellaneous billing

correspondence which may contain data for multiple patients. Documents that contain data for Multiple patients will be scanned to either EOB or Patient Correspondence with only Payor and Document Date for indexing values on the document. Once scanned, the batch will be processed with Autonomy Idol, converting the images to text based documents to facilitate full text searching.

ii. A Custom Query to search by Date and Payor will be used in addition to full text search.

InterfacesIntentionally left blank



Content Deliverya. Document retrieval using native client(s) of the Software; andb. Application Enabler document retrieval within Siemens Invision and GE

Image Broker for the retrieval of payment documents and correspondence associated to a patient account.

Third-party Application Integrationsa. Software will be configured for Application Enabler from up to four screens from

each of the following applications:i. GE Image Broker – Professional Billing; andii. Siemens Invision – Hospital Billing.

Facilitiesa. The solution will be deployed at two (2) billing offices for the Hospital and

Professional billing departments.

AssumptionsIntentionally left blank

Exclusions a. Custom XML style sheets for the display of EDI 835 data are not included in

this estimate; andb. UPG HR or other UPG departmental solution that is not like for like in today’s

use of LanVision/Streamline Health.

Note: Detailed deliverables for this solution may be found in the Solution Design Document stored in the OnBase Image Management project’s SharePoint folder: http://hscsproject1/PMO/OnBase/Project%20Documents/UVAHS%20PB%20-%20Solution%20Design%20FINAL.doc

Project 1E – Disaster Recovery ConsultingScopeDisaster Recovery (“DR”) is the process by which a UVAHS creates and maintains a redundant Software environment in which the Software can be made available and accessible after a systemic failure. DR may also include restoration of Software data to a primary production Software environment.

Collaborative effort between UVAHS and Hyland to identify UVAHS’s existing technology set(s) and resource capabilities to align a Software DR strategy that meets the UVAHS’s Recovery Point Objective (“RPO”) and Recovery Time Objective (“RTO”);

Hyland will review and contribute to the Software DR Strategy Document as needed. The Software DR strategy is a blueprint which outlines the


http://hstsproject1/PMO/OnBase/Project%20Documents/UVAHS%20PB%20-%20Solution%20Design%20FINAL.doc


technologies in the DR environment. The document will identify the mutually formulated DR strategy including technologies used and applicable Software components (e.g. database, web server, storage, etc.);

Hyland will review and contribute to the Software DR Plan as needed. The Software DR plan is a detailed procedure to be followed in the event of a disaster which articulates the roles and responsibilities of UVAHS; and

Training of the Software system administrator on the fail over procedures as it relates to Software.

AssumptionsUVAHS is responsible for the following:

a. Determine and document the Recovery Point Objective (“RPO”) and Recovery Time Objective (“RTO”) for Software DR;

b. Provide third-party vendors and/or subject and technical matter experts as required (e.g. Epic, Citrix, etc.);

c. Communicate to Hyland the Software production environment (e.g. RDBMS platform, support hardware, web and application servers, and integration with third party applications);

d. Develop and own the Software DR Strategy Document with contributions by Hyland;

e. Develop and own the Software DR Plan with contributions by Hyland; f. Setup, configuration, management, and support of hardware or technology

outside Software, as well as the Software itself, associated with the DR plan;

g. Implementation, testing, and maintenance of the DR plan;h. Management of the failover event which includes bringing the appropriate

systems on-line; andi. Copying of the Software database and Disk Groups to DR location(s).

Exclusionsa. DR Testing and/or Validation;b. High availability (“HA”) consulting services; andc. Installation and/or configuration (i.e. setup) of Software or third party

hardware and/or software to support the DR strategy.

Project 1F – Streamline Conversion Scope

a. Conversion of up to twenty-six million five hundred thousand documents (26,500,000) from Streamline Health (“Legacy System”) AccessAnyWare and FolderView repositories to the OnBase Software Solution/ integration to Epic;

b. Legacy System contains up to six thousand and two hundred (6,200) gigabytes of magnetic storage space in total amongst FolderView and AccessAnyWare;



c. Legacy System documents are categorized in up to two hundred and seventeen (217) document types across both FolderView and AccessAnyWare;

i. Mapping rules for both systems will be defined in the Conversion Specification document.

ii. Mapping of folders from FolderView to OnBase will be limited to up to two levels, as defined by UVAHS.

d. Estimate allows for up to ten percent (10%) of growth in document volume;e. Legacy System uses a standard relational database (Oracle 10gR2);f. All files that are part of converted documents will be imported into the

Software application in their current format:g. All documents are TIFF Images, ASCII text, PDF, or MS Office application

formats. h. The project will be performed in a single phase, comprised of two (2) bulk

loads of static documents (“Production Conversion”) from two sources, AccessAnyWare and FolderView repositories, and two (2) supplemental conversions of newly added and/or active documents occurring after an agreed upon cutoff date (“Delta Conversion”);

i. Hyland will integrate historical content for AccessAnyWare documents to UVAHS’s EMR as defined in the Functional Specification document resulting from the discovery project phase:

i. Historical chart records will be created within the Software to support Patient Viewer functionality;

ii. Provide an ASCII text translation file containing mappings between Legacy System document identifier and document identifier in the Software for the purpose of updating hyperlinks within the EPIC application, as defined in the Functional Specification Document; and

iii. Timeline for integration of content to EMR may or may not coincide with key project milestones/deliverables defined in this proposal, and will be mutually agreed-upon and documented in the project plan.

Assumptionsa. The linkage between the metadata in the legacy system database and the

physical files representing the pages of each document is identifiable within the Legacy System database;

b. Hyland will migrate a single copy of the latest revision of each document into the Software;

c. All physical files being migrated from the Legacy System to the Software are accessible on the UVAHS network by UNC path on magnetic storage for AccessAnyWare, but for FolderView this may not be possible and must be evaluated for Oracle data files; and

d. Conversion process will include migration of text-based annotations/signatures based on the business requirements gathered during



discovery. The approach will be documented in the Conversion Functional Specification Document:

i. Hyland will convert text-based annotations in accordance with mutually agreed upon and documented business requirements;

ii. Location or positional relevance to the document page will not be maintained during the conversion process; and

iii. The annotation text will be pulled directly from the database and will be placed in a Software sticky note.

Exclusions a. In cases where the legacy viewer manipulates the view of these files, it is

possible that they have a different visual representation within OnBase. Alteration of the physical format of the files for any purpose, including alteration to mimic legacy viewer logic, is not included within this proposal;

b. Hyland will not be responsible for verifying the correctness or integrity of document metadata, or the quality of image files associated with the Legacy System; and

c. Hyland will not be responsible for enhancing or modifying such documents or document metadata, (e.g., rotating documents, enhancing image quality, or correcting metadata), or for converting audit history metadata unless explicitly stated otherwise in the Conversion Specification Document.

d. Orphaned physical files with no associated database record will not be converted.

Project 2 – Pre-Arrival Services SolutionScopeHyland will provide services for the discovery and implementation of a Pre-Arrival Services solution for the UVAHS. The focus of this solution is on the generation of required checklists for the visibility and validation pre-arrival services which should occur in advance of a patient encounter. This includes validation of patient demographic information, insurance authorizations, payment information and appeals. The system will automatically escalate checklists with significant issues to those responsible for oversight of the process.

Checklists will be created on a daily basis driven by information gathered from the UVAHS’s various systems. This compilation of information will provide visibility to knowledge workers to determine that all patients which are due to be seen have been properly processed in advance of the encounter and are in compliance with not only the facilities requirements but also with any insurance requirements.

The checklist solution to be provided will encompass the following areas:a. Pre-Arrival Unit Activities: verification of patient demographic

information, patient contact, pre-payment requests, prior authorization;



b. Insurance Carrier Referrals: verification and/or determination of referral and authorization, patient notification of determination, denials, physician notification of determination;

c. Medicare Secondary Payor Questionnaire: obtain and validate secondary payer information; and

d. Appeals and Denials: manage review and notification of status of appeals and denials.

The checklist solution will additionally allow for visibility to management to ensure activities are completed in a timely manner through the managed distribution of work to the appropriate personnel, as well as the ability to report on key metrics to verify and improve performance.

AssumptionsThis proposal is based upon the below assumptions being true. If for some reason these assumptions prove not to be true, this could result in a scope change and may have an impact on the proposed cost and timeline to deliver.

a. UVAHS will commit a minimum of eight (8) working hours per day to testing the Solution during the UVAHS Testing Support phase, which may be performed by multiple UVAHS personnel;

b. Checklist solution will automatically ingest scheduling and registration information via real time HL7 messaging from UVAHS’s system;

c. Checklist solution will automatically ingest batch information from UVAHS’s eDischarge and ClearQuote systems;

d. Checklist solution will monitor time sensitive timeframes;e. Checklist solution will allow for identifying of priority items;f. HTML forms will be utilized for the checklist solution;g. Checklist solution will allow for the distribution of checklists according to

UVAHS’s defined rules, including manual assignment or reassignment;h. Checklist solution includes the ability to create standard composed letters;

Hyland will create up to ten (10) standard letter templates;i. Hyland will provide four (4) hours of train-the-trainer services to train on the

configuration of additional letter templates as required by the UVAHS;j. Checklist solution assumes patient chart structure already is configured and

in place;k. Hyland will create up to five (5) checklists with up to ten (10) checklist items;l. Hyland will provide four (4) hours of train-the-trainer services to train on the

configuration of additional checklists as required by the UVAHS;m. The email addresses of any business users who should receive emails should

be already compiled and readily available to the solution engineer;n. UVAHS should have a clear understanding of the roles and responsibilities of

the business process; and



o. UVAHS is expected to identify any exception processing during discovery sessions which are not already accounted for. Additional configuration effort will be required based on these requirements.

ExclusionsThe following areas are considered out of scope for the purposes of this estimate:

a. Patient Admission checklists such as IV Safety, Surgical Safety, Treatment Guidelines, etc.;

b. Case Management; andc. Discharge Planning.

Project 3 – Revenue Cycle ManagementScopeHyland will provide services for the discovery and implementation of a Hyland Software solution using the OnBase Revenue Cycle Management (“RCM”) integration for Siemens Invision and GE Centricity. The solution will provide the capabilities for automated payment processing for both systems, accounting treasury reconciliation with one bank, and receivables management used to adjudicate denials and accounts receivable patient accounts.

Content Capturea. Day-forward capture of billing office documents such as Explanation of

Benefits (“EOBs”) and correspondence;b. Batch Scanning – centralized, high volume, scanning of paper EOB’s and

correspondence;c. Advanced Capture (OCR) data lift for high-volume documents for up to six (6)

payers; andd. EDI electronic document high volume processing for up to four (4) payers.

Content Managementa. Paper and electronic (EDI) EOBs captured will be interfaced via ANSI 835 file

format export using the Software integration engine (Linker) into Siemens Invision and GE Centricity;

b. Scanned EOB’s will route for indexing and RCM processing based off of the barcode on the Batch ticket;

c. Electronic EOB’s will route through RCM processing via EDI Processor;d. Captured patient account data will display through the RCM Software’s

Report Manager and Data Analytics applications; ande. Patient accounts with outstanding balances will route to Software’s

Receivables Management workflow for account follow-up and disposition.

Interfacesa. RCM ANSI 835 file export interface to Siemens Invision and GE Centricity.



Content Deliverya. Document retrieval using native client(s) of the Software; andb. Data reporting and analytics using the Software Report Manager.

Third-party Application Integrationsa. Software will integrate with the following applications:

i. Siemens Invisionii. GE Centricity

Facilitiesa. The solution will be deployed at two (2) billing offices for the Hospital and

Professional billing departments.

AssumptionsThis proposal is based upon the below assumptions being true. If for some reason these assumptions prove not to be true, this could result in a scope change and may have an impact on the proposed cost and timeline to deliver.

a. UVAHS is responsible for identifying Software master tables, including but not limited to, PPRemarkReference, PPRemarkCodeMaster, PPTransactionConfig, PPPlanCode, PPActionCodeConfig, PPPayor, PPInsuranceCompany, PPPayorInsuranceCompanyXRef;

b. UVAHS is responsible for providing daily/weekly patient import demographics file from Siemens Invision and GE Centricity for account lookup and validation;

c. UVAHS will provide scanning hardware prior to services work performed on the EOBs for OCR processing by Hyland; and

d. UVAHS will provide sample EOB documents to be configured for all payers prior to services work performed by Hyland.

Exclusion Custom XML style sheets for the display of EDI 835 data are not included in this estimate.

Detailed Scope and DeliverablesNote: Unless otherwise stated, all scope and deliverables below will be implemented in Phase I to coincide with the opening of the Battle Building (approximately July 1, 2014).Phase II deliverables are noted text and will be detailed at a later date within this document.



Registration and Clinical Records Solution

The current version of the Registration and Clinical Records Solution may be found in the project’s SharePoint site: Registration and Clinical Records Solution

1) Business Requirement: Capture and Retrieval of Registration Documents from Siemens A2K3a) Registration users, from within Siemens A2K3 Registration System, will scan

non-clinical registration documents to their corresponding document types though the OnBase Front Office Scanning (FOS) module which will be initiated via Application Enabler.

2) Business Requirement: Disconnected Scanning for Mobile Mammography and Field Clinicsa) Mobile Mammography and Field Clinic end users capture Registration

documents while working remotely and off line. To facilitate the secure capture of Registration Documents, these users will utilize the OnBase Disconnected Scanning Module.

3) Business Requirement: Viewing of Registration Documents from GE / Centricity Business System (UPG)a) Billing and Collections Staff from within GE / Centricity Business System will view

Registration Documents using Application Enabler.4) Management of Long Term Signature (LTS) Cards

a) The Long Term Signature Card (LTS) is pertinent to billing activities and is active for the life of the patient unless the card was signed by a parent or guardian for those patients under the age of 18. When the patient reaches the age of 18, a new LTS must be captured.

5) Mask Insurance Cards Greater than 180 Days Olda) UVAHS requires Registrars to scan insurance cards for all patients that don’t

have scans of current insurance cards. As a reminder to the Registrars, UVAHS would like to hide previously scanned insurance cards with a Scan Date greater than or equal to 180 days of age. A script will be used to hide previously scanned insurance cards.

6) Capture of Digital Photographsa) Photographs captured via digital cameras will be saved to a network file share

with restricted access. Photographers will delete images from the camera after the images are saved to the file share. OnBase will sweep the share file on a yet to be determined scheduled basis and bring the images into a scan queue for indexing. Upon import to OnBase, the images will be deleted from the file share. An HIS supervisor or an authorized representative with approved security rights will access the indexing queue and index the photographs to the appropriate patient encounter using the Encounter Reverse Auto-fill Look Up. Once the batch has been fully indexed, the batch will move to the waiting QA Queue. After


http://hstsproject1/PMO/OnBase/Project%20Documents/UVAHS%20Solution%20Design%20Reg%20and%20Clinical%20Record%20Solution%20Final.docx


the batch has been QA’d the batch will commit and an MDM^T02 will be sent to Epic to create a link in Epic to the scanned image.

7) Psychology and Neuropsychology Access to Sensitive Documents via OnBase Patient Viewera) The OnBase Patient Viewer allows HIS departments, physicians, and clinical

staff to view all medical documents associated with a client’s MRN or MPI (Master Patient Index). When integrated with an electronic medical record (EMR) system, the OnBase Patient Viewer retrieves medical records from OnBase using client information provided in the third-party system. Users with appropriate privileges also can search for client records from within the OnBase Client when the EMR system is unavailable.

b) The OnBase Patient Viewer directly accessed in OnBase will be primarily utilized by Psychology and Neuropsychology end users to facilitate the viewing of sensitive documents not linked to Epic.

c) The OnBase Patient Viewer (chart) configuration includes customizable folder tabs that will each be mapped to include the applicable document types as determined UVAHS.

8) Capture and Indexing of Documents by Health Information Systems and Culpeper Medical Associatesa) Documents with Patient Labels

i) Indexing of documents with patient labels will be facilitated by Automated Indexing using Advanced Capture. Predefined forms and rules, combined with a powerful processing engine, make it possible to quickly classify and index scanned documents. Automating document indexing eliminates the bottleneck associated with manually indexing high volumes of structured business documents. Advanced Capture processing can be more accurate and much faster than manual data entry. Employees spend their time more effectively, validating or correcting questionable values only when needed, while letting the Advanced Capture processor perform the mundane task of document indexing.

ii) These documents will be scanned into a predefined Automated Indexing scan queue where the documents will be processed and indexed by the values read from the data on the documents.Documents with Document Type Barcodes

b) Documents with Document Type Barcodes i) Indexing of document with a Document Type barcode will be scanned into a

Barcode Processing Scan queue. Document type values will be read from the barcode and applied to the document.

c) Loose Documentsi) Documents without Document Type Barcode labels or those without uniformly

placed Patient Data will be scanned to a general Scan Queue from which end users will manually select the Document Type and then utilize the MRN and CSN auto-fill keyword sets to fully index the documents.



ii) External records will be indexed to a static value of “0000” with corresponding patient level keyword values. Upon receipt of the MDM in Bridges, the static CSN / Account Number will trigger the creation of a scan only encounter.

d) Viewing of Scanned Documents in Epici) Once the documents have been indexed and QA’d, the documents will enter

an OnBase workflow. On a scheduled, yet to be determined basis, workflow will generate and send an HL7 MDM^T02 message through the interface engine to Epic Bridges where a hypertext link will be generated in the patient record.

9) Document Correctionsa) The Document Correction Workflow Process utilizes various functions of OnBase

Workflow and relies on actions performed by the end user. Any user who can view a document may trigger a document to be sent to the Document Correction Workflow by clicking the button appearing in OnBase viewer. The HIS user may perform various actions, based on the corrections process which needs to take place. During this process, documents will be corrected within OnBase, and the corrections will be reflected within Epic.

10)Billing Correspondence Document Capturea) EOBs with checks are scanned by Bank of America and forwarded to PFS for

posting. These are currently scanned to folder view in Streamline. This process will be defined in Phase 2.

11) Quality Assurancea) Scanned and indexed batches will enter the ‘Awaiting QA Review’ queue for

verification of image quality and validation of keyword values. This step could potentially be eliminated after a period of time if a sufficient level quality is present in the batches being presented for QA review.

12)Hospital Billing Correspondence Workflowa) Billing correspondence including but not limited to Denials, Authorizations,

Attorney Letters, etc. unrelated to patient payments arrive in the Financial Services Office and are researched for Patient Name, MRN and name of Representative to work the document, which is hand written on the documents.

13)Outpatient Pharmacy Document Capture and Retrieval a) UVAHS Outpatient Pharmacies assist patients (and non-patients) with obtaining

discounted prescription medication through Pharmaceutical Assistance Programs provided by various Pharmaceutical Companies. Application forms and supporting documentation are scanned and indexed to the patient level, and are not linked to Epic. Pharmacy users also reference some (but not all) existing supporting documentation already captured through the UVAHS Financial Screening Process.

b) Future state will include the capture of Mail Order documents to support Medicare Audits.

c) Pharmacy users will scan to a specific Pharmacy Indexing Queue in OnBase. Once the documents have been scanned, the batch will move to an Awaiting



Indexing Queue. The user will then access the queue and index the individual documents in the batch to a Document Type. To apply patient level keyword values to the document, the user will use the reverse Patient Auto-fill Keyword look up. Once the batch has been fully indexed the batch will move to QA. After completion of QA, the document will be committed to the OnBase database. No HL7 MDM^T02 message will be sent to Epic. If Pharmacy agrees to the recommended Document Type changes, the scan queue can be configured to default the document type, eliminating the need for the user to manually select the document type.

d) To facilitate the retrieval of Pharmaceutical Assistance Applications and supporting documentation, a custom Query will be built to return all documents for a specific patient within a specific date range.

14) OnBase Solution Configurationa) The following OnBase environments will be implemented to synchronize with

analogous environments for Epic:i) OnBase Production (OnBasePRD)ii) OnBase Test (OnBaseTST)

b) Additional environments, such as training environments, that are to utilize scanning and viewing should be attached to TST.

c) An AutoFill Keyword Set is a configuration of Keyword Types that includes a Primary Keyword Type and one or more secondary Keyword Types. A value entered into the Primary Keyword Type field during indexing of a Document triggers the population of the remaining secondary Keyword Values. The auto-fill tables will be populated by information sent via ADT HL7 messages from A2K3/ADT. The table will consist of patient level and encounter level information with the MRN and (Account) CSN as the primary keywords respectively.i) MR – Patient AFKSii) MR – Encounter AFKSiii) PAU Checklist AFKSiv) Billing

Pre-Arrival Unit

The current version of the Solution Requirements Document for the Pre-Arrival Unit may be found in the project’s SharePoint site: Solution Requirements Document - PAU

1) Solution Summarya) The Pre-Arrival Unit at UVAHS works within the system to verify insurance

eligibility and benefits, obtain pre-authorizations and referrals, validate patient demographic information prior to a patient receiving service. The solution provides the software to support the PAU process and meet the following goals:i) reduce printing and administration efforts by interfacing with A2K3 using HL7


http://hstsproject1/PMO/OnBase/Project%20Documents/UVAHS%20Solution%20Requirements%20Document%20PAU%20Final.docx


ii) reduce sorting time and work prioritization by establishing business rules for electronic work balancing

iii) provide increased visibility into the PAU process at a given point in timeiv) reduce insurance payment denials by reducing information loss (losing paper

or checklists)v) ability to evaluate process effectiveness and provide information needed to

make process improvement decisionsvi) provide information that allows financial risk to be assessed by process

participantsvii) provide method to communicate more efficiently and effectively to the front

desk2) Capture/Import

a) For the PAU process data is captured from HL7 message that are sent from A2K3. The messages are processed into electronic forms that are evaluated by business rules.

3) Electronic forms are used to take the HL7 data that is messaged from A2K3 to OnBase and allows the data to be processed by Workflow. Workflow will translate the data into objects that are presented to users for processing. Users will not interact with this form.

4) PAU Process Summarya) The Pre-Arrival Unit at UVAHS works within the system to verify insurance

eligibility and benefits, obtain pre-authorizations and referrals, validate patient demographic information prior to a patient receiving service. Appointments are scheduled in A2K3 and an HL7 message is sent to the system. The system receives scheduled appointment information and determines if the appointment needs to be processed through the concierge PAU model*. Appointments that need to be processed through the workflow will be presented to PAU Coordinator with a corresponding checklist related to the service level. The PAU coordinator will complete all assigned tasks and the Sr. PAU Coordinator will complete all authorization tasks.

b) Once all tasks are completed for a checklist, the checklist is complete and the appointment processing for the PAU is complete. A summary document is generated containing the result of PAU processing. The appointment is archived.

c) An HL7 message from A2K3 is received to update the Date of Service on an appointment. The message updates the archived appointment record.

d) *Additional models may be added. The solution will provide the ability to scale to other model types and will allow for checklist/task administration.

Financial Screening

The current version of the Solution Requirements Document for Financial Screening may be found in the project’s SharePoint site: Solutions Requirements Document - Financial Screening


http://hstsproject1/PMO/OnBase/Project%20Documents/UVAHS%20Solution%20Requirements%20Document%20Financial%20Screening%20Final.docx

http://hstsproject1/PMO/OnBase/Project%20Documents/UVAHS%20Solution%20Requirements%20Document%20Financial%20Screening%20Final.docx


1) Financial Screening Process

a) University of Virginia Health System (UVAHS) patient’s deliver Financial Assistance applications and supporting documents to Patient Financial Services (PFS) representatives via email, fax or in physical paper form. The PFS Assistant or Eligibility Specialist scans or imports the patients’ Financial Assistance application and/or supporting documents into the system. The system links the application and/or supporting documents to an application instance associated by MRN. The PFS Supervisor assigns the application and/or supporting documents to an Eligibility Specialist for review. When necessary, the PFS Supervisor reassigns the application and/or supporting documents to an Eligibility Specialist for review.

b) Capture/Importi) Patient Financial Services receives financial assistance applications and/or

supporting documents via email, fax or physical paper. Applications and/or supporting documents are scanned into the system and identified using barcode technology. Applications and/or supporting documents that are imported into the system are pre-indexed by the PFS Assistant or Eligibility Specialist for identification purposes. The PFS Supervisor and Eligibility Specialist may also manually import and index miscellaneous documents, applications and/or supporting documents.

c) Managementi) The system must log and track the activities and actions that are taken on

applications and/or supporting documents in the financial screening process. The original create date drives the timeline and the new supporting document create/scan date drives how documents are prioritized in the financial screening process.

2) Financial Screening Process – Admit Patient Processa) A University of Virginia Health System (UVAHS) patient is admitted and applies

for financial assistance. The UVAHS Admit Representative enters the application and/or supporting documentation information into the UVAHS Patient Financial Services (PFS) line-of-business system. The UVAHS Admit Representative sends the admit application and/or supporting documents to the PFS Assistant. The PFS Assistant scans the admit application and/or supporting documents into the system. The system sends the admit application and/or supporting documents to an Eligibility Specialist for review. The admit application and/or supporting documents follow the standard financial screening process. The admit application and/or supporting documents are managed by the Eligibility Specialist and system based on discharge date since the patient was admitted to a UVAHS facility. The admit applications are removed from the financial screening process 90 days past the discharge date. The admit applications are stored in the system archive.

b) Capture/Import



i) Patient Financial Services receives admit financial assistance applications and/or supporting documents in physical paper form, email or fax. Applications and/or supporting documents are scanned into the system and identified using barcode technology. Applications and/or supporting documents that are imported into the system are pre-indexed by the PFS Assistant or Eligibility Specialist for identification purposes.

ii) The applications and/or supporting documents are indexed by the PFS Assistant or Eligibility Specialist upon import into the system. The PFS Supervisor and Eligibility Specialist may also manually import and index miscellaneous documents, applications and/or supporting documents.

Phase IILock box – scanning operations, Bank of America, EOB, patient payments

Out of ScopeOut of Scope items are items that will not be implemented during either Phase I or Phase II of the UVAHS implementation.

Signature Pad Interface Signature Deficiencies for Epic Integration with Esker Fax Server

Project AssumptionsNo workflow changes in Phase IAccessAnyWare pointers to Epic will not changeSolutions developed by Hyland Systems and implemented at UVAHS will be compatible with any future implementations of Epic applications; e.g., Resolute and Cadence.

Exclusions System will not perform any duplicate checking for applications.

Project ExclusionsFax server

UPG Human Resources – workflow changes are out of scope

Configuration of Software modules not required to meet the solution requirements scoped herein and are slated for a future project, include but are not limited to: Advanced Capture, Autonomy Idol, Business Rules Engine, Business Activity Monitoring, Workview, Document Composition, Records Management, and, Document Retention;



Back file data load (e.g. EMPI, encounter) or imaging services from legacy system(s) or file storage location(s);

Workflow solutions unless otherwise described in the Project Areas section;

Generation of custom reports using the Report Services module; and

High availability Software consultation, configuration, or testing.

Project ConstraintsList specific project constraints associated with the project scope that limits the team’s options; i.e., predefined budget, imposed date or schedule milestones that are issued by the UVAHS or performing organization.

The Phase I Go Live date is to be completed no later than the opening of the Battle Building (currently scheduled for July 1, 2014). The Go Live will ideally coincide with the Epic 2014 Upgrade scheduled for June 28, 2014

The Phase II implementation is to be completed no later than December 31, 2014 to coincide with the end of maintenance support for Streamline Health AccessAnyWare enterprise content management solution.



Scope Sign-off

Don DeMarco, Program Management Office Director Date

Scottie Frey, Administrator, Health Information Services Date

Sean Jackson, UPG Chief Information Officer Date

Keith Perry, Administrator, Health System Technology Services Date

Richard Pott, UPG Director of Information Technology Date

Mark Pulczinski, Associate Chief, Revenue Cycle Date

Rick Skinner, Chief Information and Technology Officer Date

Benton Turner, Administrator, Ambulatory Services Date


Date post:	30-Jan-2018
Category:	Documents
Upload:	vuonglien
View:	213 times
Download:	0 times