Family Health Centers, Inc. Request for Proposal (RFP) for ...Family Health Centers, Inc. (FHC) is an independent, not-for-profit (501C3), Federally Qualified Community Health Center

1

Family Health Centers, Inc.

Request for Proposal (RFP)

for

Electronic Health Records and Practice Management System with Integrated Electronic Dental

Health Records

Date Issued: 03/01/2019

Date Due: 03/15/2019

RFP for EHR and Practice Management System with Integrated Electronic Dental Records 2


Table of Contents I. Introduction ................................................................................................................................. 4 II. RFP Instructions .......................................................................................................................... 6

A. Completing the RFP .................................................................................................. 6 B. Format, Due Date ..................................................................................................... 7 C. Contract .................................................................................................................... 7 D. Confidentiality .......................................................................................................... 7 E. Selection Process ...................................................................................................... 8 F. Disclaimer ................................................................................................................. 8 G. Conflict of Interest .................................................................................................... 8 H. RFP Related Questions ............................................................................................. 9

III. Vendor Background ................................................................................................................. 10 A. Company Information ............................................................................................ 10 B. References .............................................................................................................. 12

IV. System Requirements & Specifications .......................................................................... 13 A. Background and General Project Requirements .................................................... 13 B. Current & Proposed System General Workflow, Configuration, and Capabilities 13 C. System Profile and General Capabilities ................................................................ 16 D. EHR System Capabilities ......................................................................................... 33 E. PM System Capabilities .......................................................................................... 60 F. EDR System Capabilities ....................................................................................... 115 G. Reporting System Capabilities .............................................................................. 121 H. Population Health System Capabilities ................................................................ 123 I. Integrated EHR System Minimum Technical Specifications and Functional

Requirements ....................................................................................................... 126 J. Customer Supplied Hardware & Software Options ............................................. 127 K. Internal Interface Capabilities .............................................................................. 130 L. External Interface Capabilities ............................................................................. 134 M. Data Conversion Capabilities ................................................................................ 137 N. Qualifications & Equivalencies ............................................................................. 138

V. Installation, Professional Services, & Support ................................................................ 139 A. Installation & Professional Services ..................................................................... 139 B. Warranty Maintenance & Post Warranty Support .............................................. 140 C. Technical Training ................................................................................................. 144

VI. Pricing & Terms .............................................................................................................. 145 A. Equipment & Delivery .......................................................................................... 145 B. Pricing ................................................................................................................... 145 C. Terms .................................................................................................................... 145 D. Default .................................................................................................................. 146


I. Introduction Family Health Centers, Inc. (FHC) is an independent, not-for-profit (501C3), Federally Qualified Community Health Center located in Louisville, Kentucky. FHC has been in business for over 43 years and operates eight clinical sites in the Louisville/Jefferson County metropolitan area. FHC currently employs in excess of 450 full, part time, and contract employees and operates on a 42 million dollar annual budget that includes federal, local, and state public funding sources. FHC is committed to ensuring that goods and services are purchased in an effective and efficient manner that provides, to the maximum extent practicable, open and free competition that is in compliance with the provisions applicable to federal, state, and local statutes. FHC has established and maintains appropriate procedures addressing the procurement of goods and services to accomplish this objective. In accordance with standards set by the federal government, grant recipients and vendors receiving grant funds must comply with these applicable federal standards and regulations:

• Equal Employment Opportunity, as amended (E.O. 11246) • Copeland “Anti-Kickback” Act (18 U.S. C. 874 and 40 U.S.C. 276c) • Davis Bacon Act, as amended (40 U.S.C. 276a to a-7) • Contract Work Hours and Safety Standards Act (40 U.S.C. 327-333) • Rights to Inventions Made Under a Contract or Agreement (37 CFR Part 401) • Clean Air Act (42 U.S.C. 7401 et seq.) and the Federal Water Pollution Control Act, as

amended (33 U.S.C. 1251 et seq.) • Byrd Anti-Lobbying Amendment (31 U.S.C. 1352) • Debarment and Suspension (E. O. 12549 and 12689) • OMB Supercircular Guidance (section 200.320)

The percentage of the total costs of the program or project which will be financed with Federal money is 0%, thus one hundred percent (100%) of this project will be funded with nongovernmental sources. FHC is currently soliciting bids for an “Electronic Health Records and Practice Management System with Integrated Electronic Dental Health Records”. The project parameters include replacing FHC’s current Greenway Intergy Electronic Health Records (EHR) and Practice Management (PM) System, and Greenway MediaDent Electronic Dental Health Records (EDR) System with a fully integrated Electronic Health Records (EHR), Practice Management (PM), and Electronic Dental Health Records (EDR) System. The new system must be capable of replicating and improving upon current FHC workflows, be expandable to meet future FHC needs. The proposed system must also have an up to date certification by an agency with current ONC-ATL and ONC-ACL authorizations, and be capable of capturing and reporting Federal Promoting Interoperability (formerly Meaningful Use), MIPS, and UDS data.


To support this project FHC will purchase the system, installation, training and other professional services necessary to implement a fully functional integrated system. FHC is soliciting bids from factory authorized dealers of these products who have a well-established support program in the Louisville/Jefferson County market and are able to meet the minimum requirements defined in this document. Vendors responding to this RFP will be responsible for the timely acquisition and delivery of all related software, hardware, professional services, installation services and training detailed in this document. In addition, respondents must have the necessary expertise and staff required to provide a turnkey implementation of this project. Vendors are also required to submit firm timetables for delivery, implementation, and any required training denoted in the RFP response in the form of a “Project Scope and Design Document” detailed in (section II-A). In addition, a list detailing all software, professional services, installation services and training must be provided with the RFP response including any shipping and/or delivery charges. The selected vendor will be responsible for providing the following:

• Project related software, hardware, and accessories. Feature requirements and system capabilities as defined in (section IV).

• Installation, configuration, and post installation certification of equipment as defined in (section V).

• Warranty support as defined in (section V).

• Extended warranty and maintenance support of purchased equipment and software as defined in (section V).

• Technical training as defined in (section V).

• Timely delivery and implementation of the specified equipment as defined in (section V

& VI).

• Upgrades to the systems as necessary.


II. RFP Instructions

A. Completing the RFP

Provide a complete description of the equipment and services included in your bid response as well as a project scope and estimated timeline. A separate equipment list of vendor supplied hardware and software is required. Any non-vendor supplied software, hardware and/or professional services required to complete the project are to be specifically noted. Furthermore, all required software, hardware, and professional services must be listed in the bid. The bid response must also include a complete “Project Scope and Design Document” explaining the proposed implementation and specific details and timelines of the project. No verbal agreements will be considered during the bid process. The quality of the response to the RFP will be viewed as an example of the vendor’s capabilities. Only current production software and hardware will be considered. Software or hardware under development, in planning, or at beta test will not be considered. Discontinued or outdated software and hardware, demos, refurbished, and/or used equipment will only be considered if it is clearly denoted in the RFP response and has been mutually agreed upon by FHC and the vendor; otherwise this equipment will not be considered for the bid process and use of such will result in disqualification of the submitted bid. If the software revision or model is replaced or updated between the bid process and equipment delivery, an equivalent updated or upgraded model can be submitted for approval with supporting manufacturer data. Vendors can also include additional information about future developments or plans under separate attachment if applicable. FHC expects this to be a “TURN KEY” project, meaning that any and all items or services required to complete the project are to be included in the bid, or specifically noted if not. FHC’s expectation is that upon project completion, all hardware, software, and professional services required to implement the “Electronic Health Records and Practice Management System with Integrated Electronic Dental Health Records” will have been provided. FHC also expects that this system will meet or exceed the bid specifications. It is the prospective vendors’ responsibility to ensure that all software, hardware, labor, and necessary engineering time are included in the submitted bid to cover the stated project scope. If you require any clarification, provide the questions via email or phone to Larry Owen (section II-H). Quoted prices and discounts are to be guaranteed for at least 60 days from the bid close date.


B. Format, Due Date

BIDS: Hardcopy bids for the Family Health Centers, “Electronic Health Records and Practice Management System with Integrated Electronic Dental Health Records” will be received in the office of Family Health Center-Portland, Room 419 at 2215 Portland Avenue until 2:00 P.M., E.D.T., Friday March 15th, 2019. Electronic bids may also be submitted via email to [email protected]. No late bids will be accepted and this bid opening is public. All submitted bids will be considered the property of FHC. All proposals should include copies of product descriptions for the proposed equipment. Name one person to be the coordinator for your RFP response, this individual will be the point of contact for any necessary clarification.

Contact Name: Company: Title: Physical Address: Phone: Fax: Email:

C. Contract

The bid should include a contract for all proposed equipment and services. If the vendor does not wish to submit an actual contract with the bid, due to alternatives proposed and pending choices from those alternatives, a sample contract should be submitted with the bid.

D. Confidentiality

Information submitted will be used by FHC for the sole purpose of evaluating vendor responses. However, since FHC’s receives public funds the bids are subject to open records requests. Because of these provisions, contents of the bid can be viewed by government entities or other bidders upon the opening date and all bids will be tabulated during the public bid opening.

mailto:[email protected]


E. Selection Process

Several factors will influence FHC’s decision in selecting the vendor and the product line they represent. In addition to cost considerations, proposals will be evaluated on the basis of the following factors: • Functionality of proposed solution and ability to meet the project’s specific needs • Availability of optional components and capabilities • System growth and expansion • Product quality, reliability, and warranty plan • Ease of configuration and administration • A credible commitment by the vendor/manufacturer to the product and the ongoing

enhancement of future capabilities and service • Vendor qualifications including:

o Overall experience and reputation in the industry o Experience with the proposed system(s) o Service and support resources, including overall skill level of technical

personnel o Verifiable quality of services provided by vendor to area customers

In addition, vendors submitting a bid must be recognized as a current Authorized Dealer of the equipment and/or software quoted, and has proven regional service and support systems in place prior to submitting the bid.

F. Disclaimer Note that FHC will select the vendor based upon the best overall solution and value and is not obligated to select the low bid. Furthermore, this RFP does not commit FHC to any specific course of action. FHC reserves the right to purchase all or selected components defined in the RFP, or to not select any vendor or purchase any goods and services resulting from this RFP.

G. Conflict of Interest

No public official, Family Health Centers board member, or Family Health Centers employee, shall participate in any decision related to the award of this contract, which affects their personal or financial interest, directly or indirectly, in this contract or the proceeds thereof.


H. RFP Related Questions

Submit any RFP related questions to:

Larry Owen – Chief Information Officer Family Health Centers 2215 Portland Avenue Louisville, Kentucky 40212 Phone: 502-773-3810 Fax: 502-772-3489 Email: [email protected]


III. Vendor Background

A. Company Information

Provide a brief description of the company including:

• Identify the company name, physical address, city, state, zip code, telephone, fax number, and website.

• Provide a brief company history.

• Provide a brief profile of your company and business division:

o Current size of company o Do you have a parent company?

If so, provide name of parent company. o Is the company private, public, owned by private equity, etc? Explain. o Company location(s) o Length of time in business o Length of time providing the software solutions and services requested in the

RFP: • When was the first EHR/PM System installed by your company?

• When was the first integrated EHR/PM/EDR System installed by your company?

• Qualifications of the company to respond to the RFP, generally and including:

o Provide the number and type of EHR and PM System solutions you have implemented. How many of these included an EDR How many of these were at FQHCs

o How many employees are dedicated to the support and implementation of the proposed system(s)? Where are the support personnel located?

o How many employees are dedicated to the development of the proposed system(s)? Where are the development staff located?

• For the systems that you are proposing, answer the following based on total number

of sales in the last three years: o Percentage that are currently implementing. o Percentage which have finished implementation. o Percentage delayed or canceled implementation and reason for same.


• How many NEW customers acquired and installed the proposed system within the last year?

o How many new customers were FQHCs?

• Has your company, its owners, managers, employees and/or contractors been excluded from participation in Medicare, Medicaid, State Child Health Insurance Program or other health care programs? Provide an explanation for the exclusion.

• Legal Actions: o Have any customers filed legal action claiming breach of contract or otherwise

seeking remedies through such action? Provide brief description. o Is your company now involved in any litigation with a customer or other

entity? Provide a brief description. • Financial Stability:

o Provide an annual report if responding vendor is listed on the stock market; basic financial report if your organization does not produce an annual report.

o Provide an up to date financial profile of your company including Dunn & Bradstreet information on separate corporate letterhead.

• How are customer requests for enhancements and customizations handled?

• Are software updates and full version upgrades included in the maintenance

agreement? o What types of requests are included with the maintenance agreement? o What types of requests are chargeable? (describe any associated charges) o Describe the recent history of system enhancements. o Describe new features released within the past year.

• Describe the company’s policy regarding the source code.

• If your company relies on contractual agreements with outside service organizations

to provide support for the system defined in your RFP response, explain the nature of the agreement and give name(s) and contact information for the service provider(s).


B. References

Provide a minimum of five (5) reference customers that have purchased products and services similar to that being proposed in the RFP. All references should be similar in size and complexity to FHC, at least three should be an FQHC and utilize internal RCM services, and at least two should be self-hosted. Include contact names, telephone numbers, email, and physical addresses.


IV. System Requirements & Specifications

A. Background and General Project Requirements

As stated in (section I), FHC is seeking to implement an “Electronic Health Records and Practice Management System with Integrated Electronic Dental Health Records”. To support this project FHC will purchase a fully integrated Electronic Health Records (EHR), Practice Management (PM), and Electronic Dental Health Records (EDR) System (hereafter referred to as Integrated EHR). The new system must be capable of replicating and improving upon current FHC workflows, be expandable to meet future FHC needs. The proposed system must also have a current certification by an agency with current ONC-ATL and ONC-ACL authorizations, and be capable of capturing and reporting Federal Promoting Interoperability (formerly Meaningful Use), MIPS, and UDS data. Refer to tables IV-B through IV-H for detailed software specifications.

B. Current & Proposed System General Workflow, Configuration, and Capabilities

1. Current Systems Workflow, Configuration, and Capabilities

FHC performs in excess of 160,000 medical, behavioral health, and dental visits per year utilizing a self-hosted health information technology (HIT) platform, the Greenway Intergy CHC and MediaDent systems. The Intergy system is a single database design with integrated EHR and PM components. The Intergy PM system is utilized for standard PM functions including patient scheduling, registration, billing, health information management (HIM), imaging, and general reporting functions. Currently all FHC scheduling, check-in, workflow, demographics, and document imaging functions are performed utilizing the Intergy PM. The Intergy PM also provides automated generation of paper registrations, encounters, and lab forms, as well as patient eligibility checking and centralized billing functions. The Intergy PM is specifically configured to collect, track, and report all CHC specific patient data required to provide UDS reporting. The Intergy EHR is used to perform all standard EHR functions including medical charting, procedures, coding, electronic order entry, electronic prescribing (e-prescribing), and charge entry required to complete the patients’ medical visit. The EHR is utilized to input all medical and behavioral health data into the Intergy database. The EHR also populates clinical measures required to submit UDS and Promoting Interoperability (Meaningful Use) reports. The PM and EHR share common tasking, scheduling, demographic, and other basic functions. The Intergy system is interfaced to the MediaDent EDR via an enhanced HL7 and ADT interface. The Intergy system serves as the master patient database, and is utilized for all scheduling, billing, and reporting functions. The EDR resides on a separate server and


database and is used primarily for dental specific charting. The current dental chart is split between the EHR and EDR systems. Imaging is studies are performed utilizing an integrated imaging module and image capture devices including Vatech digital sensors and PANs. The EDR database stores image files in addition to standard chart data. Patient portal services are provided by an interfaced web based Greenway patient portal. Portal services include predefined access to patient medical and financial records, and a secure patient provider messaging system. Reporting is provided by a combination of Intergy PM and EHR predefined reports and a custom Practice Analytics (PA) reporting system. FHC heavily utilizes the capabilities of the PA system and frequently utilizes dozens of in house created custom reports to produce an array of mission critical data. These reports include financial, productivity, clinical, UDS, Promoting Interoperability, HEDIS, and program related information. The PA system also provides graphical dashboard reports for a broad spectrum of reporting purposes.

2. Proposed System Workflow, Configuration and Capabilities

(Respond with a detailed description of the proposed solution capabilities and configuration)

Upon project completion FHC expects to utilize the newly acquired Integrated EHR System as a direct replacement for the existing Greenway Intergy PM, EHR and MediaDent EDR system(s). FHC also expects to utilize current and enhanced workflows defined in section (IV-B-1) where necessary, and make specific process improvements through the use of the new system. The proposed system will facilitate the conversion to a fully integrated patient health record, and provide substantial workflow, process, interoperability, security, and reporting improvements. The proposed system must also replicate and enhance the existing reporting processes, while integrating effectively with FHC’s current ancillary clinical, and GL systems. Once installed and fully integrated the proposed system will provide a centralized method of electronic scheduling, charting, imaging, billing, and reporting for all medical, behavioral health, and dental patient visits. The new system will utilize an intelligent design enabling the integration with existing FHC HIT systems, utilizing the best suited components from each system to provide a high degree of integration, operational efficiency, and centralized reporting. The proposed system must have the capability to convert and maintain all historical account, patient, and chart numbers from the legacy system. The system must be also be capable of importing at least two years of demographic, clinical, and financial data as required. The conversion must be inclusive of both systems that are being replaced and be included in the response as a dedicated line item.


The system must have the capacity to support four hundred and fifty connections to the system utilizing EHR, PM, and EDR clients, across a twelve location fiber MPLS WAN network, and have the ability to provide secure remote access to the EHR. The system should also integrate with a state of the art Patient Portal and provide secure user defined connectivity to outside health registries and exchanges. In addition the new integrated EHR must have the capacity to expand and support future FHC services and have the ability to accommodate additional devices, users, and data without major reconfiguration. This capacity should be clearly denoted in the response as well as any related future licensing, modules, setup, and costs.

Provide a detailed overview of the proposed integrated EHR specific to the application listed above. In the overview focus on the usability, simplified workflow, and flexibility of the proposed system.


C. System Profile and General Capabilities (Respond with answer and a description of the proposed solution in the comments section when applicable, * denotes additional cost)

Product Information Product name and version#

When is your next version release?

Single Database for scheduling, billing, EHR, and EDR?

Is it a Client Server, ASP or Hosted model?

Was the product (or any of its significant functionality) acquired from another company?

If yes, answer the following: − What was the original company’s name that developed the

product or functionality? − What was the original product’s name? − What version did you purchase?

Does the product include a patient portal and/or does it allow integration with 3rd party patient portals?

Is the product comprehensive or modular?

Modular − List all modules available, their current version, and

provide additional documents with all technical specifications, requirements, and dependencies for each module to operate fully with the "core" product.

− Which modules are necessary in order to meet Promoting Interoperability criteria?

− Are additional or multiple modules required to meet post-2019 Promoting Interoperability guidelines?

Comprehensive − Does the product meet Promoting Interoperability

guidelines?

− Will the product continue to meet Promoting Interoperability guidelines through 2020 without significant changes?

Will there ever be a charge to copy, move, or retrieve patient data from the product should a customer decide to change vendors or a provider leave the customer?

List all ways that a practitioner could import a patient’s data into the product:

• CD/DVD • Flash Drive • PDF Format • Paper Copies • Clinical Exchange Document

Reporting Capabilities Does the product allow custom reports to be created?

Ad hoc reporting by users an option?

Provide a list of standard reports (no customization) which the customer may run at Go Live to meet Promoting Interoperability and/or HIPAA requirements.


Can this report information be exported to CD/DVD in CSV or comma text delimited format?

ONC-ATCB Certification Is the product ONC-ATCB certified?

Version and Year of Certification

Certified as Comprehensive or Modular?

Promoting Interoperability Yes Yes* No Comments/Clarifications Are the modules necessary to meet each of the menu set objectives included in the attached pricing, or are they sold separately at an additional cost?

☐ ☐ ☐

Do you have a guarantee the product will meet the current standards and future standards?

☐ ☐ ☐

The system has a bi-directional lab component. ☐ ☐ ☐

The system can check insurance eligibility electronically from public and private payers. List clearinghouses with which this functionality exists.

☐ ☐ ☐

The system can submit claims electronically to public and private payers.

☐ ☐ ☐

The system can provide patients with timely electronic access to their health information.

☐ ☐ ☐

The system can provide clinical summaries to patients for each visit.

☐ ☐ ☐

The system can provide a summary care record for each transition of care and referral visit.

☐ ☐ ☐

The system can exchange key clinical information among providers of care and patient authorized entities electronically.

☐ ☐ ☐

The system can submit immunization data electronically to the Kentucky immunization registry.

☐ ☐ ☐

The system can provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice.

☐ ☐ ☐

Additional Information Timeframe to receive demonstration of product

Is a demo copy available prior to purchasing?

Onsite implementation or remote?

Training sites

Training options (train-the-trainer, # hours all staff)

Has your company acquired, been acquired, merged with other organizations, or had any "change in control" events within the last five (5) years? (If yes, provide details.)

Is your company planning to acquire, be acquired, merge with other organizations, or have any "change in control" events within the next five (5) years? (If yes, provide details.)


Does your company use resellers to distribute your product(s)? If yes, answer the following: − What is your reseller structure? − Who are your resellers who are authorized to sell within

Kentucky? If no, answer the following: − What is your distribution and sales structure?

Provide information on any outstanding lawsuits or judgments within the last five (5) years. Indicate any cases that you cannot respond to as they were settled with a non-disclosure clause.

Security and Security Features Describe how the product meets all HIPAA, HITECH, and other security requirements.

Does the product provide different levels of security based on User Role, Site, and/or Enterprise settings? Provide detail.

Does the product provide different levels of security based on type of patient (Employee vs. VIP)?

• Employee

• VIP

• Other (list)

Does the product provide levels of security to allow secure third party access for HEDIS and other types of audit activity? Including:

• User ID

• Carrier (Insurance)

• Time of day

• Date Range

• Service Location

• Department

• Other (list)

Does the product provide different levels of security based on encounter type, program, medical chart classification, or other sensitive criteria to restrict access? Including:

• Department

• Visit type

• Program

• Behavioral Health or Psychotherapy

• Substance Abuse

• Specific part of chart or note

• Pediatric Family Planning

• Other


Describe the audit trail and security reporting process within the product.

List the security reports the product provides at Go-Live to meet all auditing and HIPAA reporting needs.

Describe any remote tools you offer the provider to access patient data (e.g. iPhone) and how these devices/data may be secured if the provider loses their device or a breach is suspected.

Describe the product's ability to terminate user connections/sessions by an administrator (remotely) if a breach is suspected.

Describe the product's ability to lockout users (for upgrades, security breaches, employee terminations, etc).

Describe the product's ability to create new security rights/roles based on new workflows or enhancements (e.g., customer-developed content such as Psych notes or departmental flowsheets).

Describe the products ability to provide automated outbound data filtering for HIE, registry, and other external data connections such as CommonWell, CareQuality, and the Kentucky Health Information Exchange.

Automated outbound data filters include: • Patient

• Encounter

• Provider

• Service Location

• Visit Type

• Department

• Diagnosis

• Procedure

• Lab

• Program

• Chart Section

• Other


Data Protection Describe how the patient’s data is secured at all times and in all modules of the product (e.g., strong password protection or other user authentication, data encrypted at rest, data encrypted in motion).

Describe how the patient’s data is secured when accessed via handheld devices (e.g., secured through SSL web sites, iPhone apps, etc).

Licensing How is the product licensed?

Are licenses purchased per user?

Define ‘user’ if it relates to the licensing model (i.e., FTE MD, all clinical staff, etc).

− How does the system licensing account for residents, part time clinicians, and midlevel providers?

− Can user licenses be reassigned when a workforce member leaves?

If licensing is determined per workstation, do handheld devices count towards this licensing?

Is system access based on individual licensing, concurrent, or both?

What does each license actually provide?

For modular systems, does each module require a unique license?

In concurrent licensing systems, when are licenses released by the system (i.e., when the workstation is idle, locked, or only when user logs off)?


Computerized Physician Order Entry (CPOE) Is CPOE part of the core product or a separate module?

Is CPOE customizable per provider or are templates available?

− Does the system allow for custom Order Sets to be built?

− Does the system allow multiple Resultable Items to be mapped to a single Orderable Item? (e.g., Skin tests have multiple antigens (resultables) which must map to a single Orderable item code).

Does the system allow free text ordering?

Does the system provide the end user the ability to cancel pending orders?

− If so, does an outbound interface message result, sending the cancellation message to 3rd party systems?

Does the system utilize ICD9 or ICD10 coding?

− Are codes pre-loaded?

− Are future code updates vendor or user applied?

Does the system allow custom questions per order to be developed?

− If so, describe how these items are built and managed by the customer.

− Can these items be classified as "required" or "optional" to complete?

Does the product support recurring orders?

− If so, describe how the system accommodates this workflow.

Does the product support Orderable Favorites per user and/or per specialty?

How does the product support ordering for off-site (non-integrated/interfaced) orders?

Are there Reporting tools available to monitor all CPOE steps? (e.g., unsigned orders, overdue orders, etc.)

Which LIS vendors currently interface "out of the box" with CPOE?

Which RIS/PACS systems interface "out of the box" with CPOE?


E-Prescribing Is E-Prescribing part of the core product or a separate module?

Is E-Prescribing customizable per provider and/or at the enterprise level?

What are the E-Signature Requirements for E-Prescribing?

− What is required of the customer in order to set this up?

Which local or national pharmacies interface with the EHR?

− How are these updated and with what frequency?

Is there an extra expense required for local pharmacies to be set up for E-Prescribing?

− Rate per transmission?

− What form of transmission is required?

Is there a fax server incorporated in the EHR?

− If so, does it require a separate server?

− If not, are 3rd party vendor fax servers supported?

− Which vendors are supported?

Can Rx faxes be configured to use a separate fax queue from other faxed documents within the system?

Is there a functional limit to the number of fax lines supported by the system?

Can active faxes be cancelled during transmission by user or by system administrators?

What security settings are available in the product to govern who can E-Prescribe?

Are medication updates performed regularly?

− Which vendor(s) does the product support?

− Does it include Drug Contraindications?

− Does it include Drug Interactions?

− Does it include Drug Warnings received?

Are reporting tools for E-Prescribing available?

Describe how new medications are displayed in the system if added by:

• MD • RN • MA • PA/NP • Residents

Where is E-Prescription information housed in the EHR?

Describe the audit features for E-Prescribing.

Does the system keep a running history of Rx renewal changes?

Does the system have an integrated method of notifying prescribing providers and support staff of rejected prescriptions? (explain)


Infrastructure and Technology If product is a client/server model, respond to questions below: What type of hardware is required?

What are the recommended workstation requirements?

What are the recommended server specifications?

Recommended Manufacturer/Model?

How many servers and server roles?

• Application Server

• Web Server − IIS (version) − Apache (version)

• Other

• Database Server

• MS SQL (version)

• Oracle (version)

• Other

• HL7 Interface System

• Test Server

• E-mail Server

• Others (Fax, Print, Dictation, etc)

• Operating system (Windows, Unix/Linux, Other)

• Processor (number of processors and processor speed)?

• Memory/RAM requirements?

• Storage Space Requirements?

• SANs Connectivity (Yes/No)

− If yes, SANs requirements?

• Network Card Speeds

Dual NICs required?

Other Components Required?

What other applications are required for server?

• Server Management Tools

• Bandwidth Monitors

• Database Management Suite

Can systems be virtualized?

− Will the product run on virtualized servers?

− If yes, what virtualization software is required on server?

• VMWare (version) o Supports VMW

• Citrix (version)

• Microsoft (version)

• Other (version)

− If no, are you moving toward certifying virtualized environments?


− Will the product run on remote and/or virtualized desktops?

− If yes, what virtualization and remote access software is required on server and client computers?

• VMWare

• Citrix

• Microsoft (version)

• Other (version)

− If no, are you moving toward certifying virtualized environments?

Are we required to purchase hardware from your company?

Do you provide hardware or have a relationship with a hardware vendor?

If working with a hardware vendor do you have negotiated pricing with them?

Do you have a recommended vendor with discount pricing to purchase equipment?

What type of support is available if equipment purchased from your company?

What are the recommended printer manufacturers/models?

− What type(s) of printers are recommended? (Laser, Inkjet, Thermal)

What are the recommended scanner manufacturers/models?

Do you require Internet access for your product?

− For remote connection/maintenance?

− If so, detail security setup required for this access. If Delta processes are initiated and data is downloaded into the system automatically, detail that information here.

− Remote Support?

− If so, detail security setup and access rules governing when connections are created and what type of work can be performed on the live system during normal business hours.

− Access System/Application Remotely?

− Are there any Delta processes that run nightly/weekly/etc. and if so, what data is collected and how is it used?

What are the minimum network infrastructure requirements?

− Firewall/VPN Appliance?

− Switches/Routers

− Other Devices

Will your product operate efficiently on Windows Terminal Services or Citrix?

− If no, are there plans to certify in these environments?

What are the backup requirements?

− Do you require a separate server for backup services? (Tape, SANs)

Are 3rd party backup solutions supported?

Does product provide database software (Yes/No)?


− If no, what database application is required? (MS SQL, Oracle, MySQL, Other)

Can data be exported?

− What format? (CSV, Text/Comma delimited, Other)

Does product allow for ad hoc reporting against the database by customer using standard reporting software (Crystal Reports) or standard database queries?

If product is an ASP model, respond to questions below: Do you provide ASP solutions or require 3rd party vendor participation?

What is the 3rd party vendor’s involvement?

How are support issues handled?

Does the ASP model require a server at the customer location?

− If yes, what are the system requirements?

• Number of Server(s)?

• Processor

• Storage and Fault Tolerance Requirements?

• Memory? − <25 concurrent users − >25 concurrent users

• Bandwidth Requirements?

• System Backup Requirements?

− Types of Server(s)

• Database Servers

• Web Servers

• Interface Servers

• Scanning Servers

• Messaging (Fax, E-Prescribing, Print) Servers − If fax from server, what fax cards are supported? − Is separate fax software needed?

Is virtualization supported or required (VMWare, XenApp, etc.)?

− If so, on which servers and in what configuration?

Are Citrix and/or Terminal Services supported?

− If so, are there any application modules not supported or recommended for use in a virtualized environment?

Does your product require or recommend a firewall?

− If yes, what is the recommended manufacturer/model?

− Do you recommend VPN access?

Do you provide all CALs (client access licenses) for database and system access or does the customer purchase these?

− If customer must purchase, how many need to be purchased based on expected number of users on the product?

List all security enhancements which must be accommodated on workstations (e.g., Internet sites trusted, active x controls enabled, Dot Net versions supported, registry modifications, etc).


Does the product support any of the following external devices: • USB devices • Scanners (manufacturer/model) • Flatbed • Handheld (i.e., Barcode, PDA, BlackBerry Devices, etc.) • Card Readers (i.e. smart card, security • Other Input Devices

What are the bandwidth requirements per user?

What are the workstation requirements?

Manufacturer/Model • Processor • Storage • Memory • Operating System

Does the product require any type of client (i.e. Citrix, clientware, Cisco VPN, etc.)?

What applications are supported and/or need to be installed on the workstation?

• Java • Flash • Adobe Reader • Microsoft Office (i.e., Word, Excel, etc.) • Antivirus • Which folders/files must be excluded from active

scanning? • Crystal Reports • Open Office • Remote Access Software (WinVNC, RDP, GoToMyPC,

etc.) for support

Require ODBC driver or SQL application on workstations?

Any other applications required?

Can the product be securely accessed from any location with an Internet/broadband connection?

How is data saved at the ASP location?

How often is routine maintenance performed on remote system? • Backups? • Updates? • Performance Monitoring and Enhancements

Since we would be dependent on Internet connection, what is our strategy if the Internet connection goes down and cannot use your system?

How will the customer be able to download and distribute the patient’s health record to meet Promoting Interoperability?

How will the customer be able to upload patient-provided records (either paper or electronic format (radiology, medical records, lab data, etc.))?

If product is a SaaS model, respond to questions below: Do you provide direct SaaS solutions or require 3rd party vendor participation?

How are support issues handled?

Does a 3rd party vendor host any part of your product and/or data?


Does your product require or recommend a firewall on the client side?

− If yes, what is the recommended manufacturer/model?

Can the product be securely accessed from any location with an Internet/broadband connection?

− What are the security requirements for remote users (non-office users)?

What are the minimum bandwidth requirements?

List all security enhancements which must be accommodated on client workstations (e.g., Internet sites trusted, active x controls enabled, Dot Net versions supported, registry modifications, etc.).

Does the product support any of the following external devices: • USB Devices • Scanners (Manufacturer/Model) • Flatbed • Handheld (i.e., Barcode, PDA, BlackBerry Devices, etc.) • Card Readers (i.e., Smart Card, Security) • Other Input Devices

What are the workstation requirements?

Manufacturer/Model • Processor • Storage • Memory • Operating System

Does the product require any type of client (i.e. Citrix, clientware, Cisco VPN, etc.)?

What applications are supported and/or need to be installed on the workstations?

• Java • Flash • Adobe Reader • Microsoft Office (i.e., Word, Excel, etc.) • Antivirus • Which folders/files must be excluded from active

scanning? • Crystal Reports • Open Office • Remote Access Software (WinVNC, RDP, GoToMyPC,

etc.) for support

Require ODBC driver or SQL application on workstations?

Any other applications required?

How is data saved and stored?

How will the customer be able to download and distribute the patient’s health record to meet Promoting Interoperability?

How will the customer be able to upload patient-provided records (either paper or electronic format (radiology, medical records, lab data, etc.))?

Can information be exported to CD/DVD in CSV or comma text delimited format?

Does product allow reports be created?

− Ad hoc reporting option?


− Provide a list of standard reports (no customization) which the customer may run to meet Promoting Interoperability requirements.

How often is routine maintenance performed on remote system? • Backups? • Updates? • Performance Monitoring and Enhancements

Can you provide a contingency strategy or disaster recovery plan in the event Internet service is lost and customer is unable to access your system and application?

Do you have normal ‘downtime’ windows for system backup and maintenance?

− Does this affect access to the product?

How is data gathered during Internet outages?

Is it uploaded into the system when Internet restored? • Is this process done manually or automatically? • How do we verify information has been uploaded?

In the event access to your site is unavailable, what steps will you take to notify the customer of progress towards resolving the issue?

− What steps should the customer take during this time?

In the past two (2) years, how many outages have you experienced due to your own infrastructure problems?

Do you have redundant Internet providers?

Is there a test environment for the customer to use?

What are the network infrastructure requirements?

What are your security requirements and recommendations for client workstations?

Is your site secured with encryption and antivirus?

− How often is access audited and by whom?

− Is there an off-site disaster recovery location for your server farm?

− How often is this tested?

Training/Testing – All Phases (Selection through Post Go-Live) Provide a detailed explanation of the typical Development/Training Environment

Will the vendor setup and support a local Training Server containing a frequently updated mirror image of the production system? If so what costs are associated?

− If so what costs are associated?

− Will access be granted to development/training environment for testing during upgrades and during training processes?

What types of online training are available?

Videos • Recorded Modules/Workflow Training Courses • Recorded Interactive "Many-to-One" Training Sessions • Quick Reference or Tips & Tricks Videos • Trial Demonstration of EHR


Web Based Training • Interactive training activity with screenshots & instructions

to give clinic exposure of EHR selected before core training

Facilitator/Consultant Led Training Sessions • Module Training Sessions • Workflow Training Sessions (Nurse, Provider, Front Office,

etc.) • One-on-One Training Sessions with Consultant • Describe your training personnel (i.e., background,

position, medical credentials). • Vendor-Directed Demo (i.e., Web Ex Training, On-Site,

etc.)

Training Documents (Identify format of documentation) • Training Manuals • Quick reference guides that focus on specific tasks • On-line Printable Training Documentation • Upgraded Training Guide • Describe when these documents are modified and how

quickly they are made available to the customer after product changes occur.

Is Practice/Specialty Specific Training Offered?

What is created by vendor vs. customer? − Creating specialized templates for efficient documentation − Creating favorites/shortcuts within the product − Does the product have customizable preferences?

Will a workflow assessment be completed by the vendor? − Will a document be sent to be completed by clinic? − Will vendor complete on-site workflow assessment? − Is there an additional cost for workflow assessment?

Will recommendations be provided for abstracting or bulk loading data from paper charts into the EHR?

Contractually, can users access the live EMR system prior to Go-Live for build or ‘pilot’ purposes?

Super User Training − Will super users be trained by vendor? − Remote or on-site training provided?

Cost of Training − Describe training options included in contract agreement. − Will additional costs be incurred on clinic for training?

On-Site Training − How many days does EHR vendor provide for on-site

training? − Will Go-Live be scheduled shortly after initial staff training? − What is the consultant/provider ratio during training? − Will trainers complete a readiness assessment before Go-

Live? − Will vendor provide clinic with on-site demos before and

after contract is signed? − Will office be trained on hardware if purchased through the

vendor before Go-Live training?

Go-Live Will vendor staff be on-site during ‘Go Live’ timeframe?


What will be their role during ‘Go Live’? − Trainer − Technical

Post Go-Live Training and Support

After ‘Go-Live’, who (i.e., support team, implementation manager, etc.) will be available to answer questions, issues, and/or training requests?

− If original implementation team, how long before this level of service is transferred to "normal" support team?

Will a post Go-Live assessment be completed after a specified amount of time by the vendor?

How will clinic be notified of upgrades when they are released and who is responsible for installing these updates (dates, training, documentation, etc.)?

The system provides a training database/system for training new staff and recertifying existing staff.

• The training database can be routinely updated to reflect configuration changes on the live data set.

• The training database/system will not require additional user licenses or take existing concurrent licenses from the live data set.

• The training data set/system will be supported on client provided hardware.

• The system allows the users to maintain a “training account” on the live database for the purposes of training new staff?

Software Upgrades & Updates Upgrade Process: (provide a detailed explanation for each)

• Will customer get to choose which upgrades they want?

• How often do you distribute updates and/or do upgrades to the system?

• How long can a customer delay an upgrade without losing support?

• Are future software updates a part of regular software maintenance fees? If not, explain.

• How are updates distributed?

• Is ongoing training provided for updates to the system? Describe this training.

• Testing: (provide a detailed explanation for each)

• Will customer get a chance to test the product in a test environment?

• Will customer get access to test scripts from vendor?

• Will customer have an opportunity to parallel test with vendor or conduct Acceptance Testing?

• End to End Testing?

How do upgrades affect software customizations? Explain the server upgrade process in detail.

• What triggers the server upgrade?


• What process is utilized to obtain the software upgrade package?

• Explain the pre upgrade certification process required to schedule an upgrade.

• What afterhours vendor support options are available to assist with an upgrade process?

Explain the client upgrade process in detail. • What triggers the client upgrade? • Explain the upgrade process for web clients. o How do operating system and browser updates and

patches affect the web client?

o What browsers does the web client support? • Explain the upgrade process for thin clients. o List the fully supported thin client solutions. (i.e. Citrix,

VMware, Microsoft Terminal Services)

• Explain the upgrade process for fat clients. o What automation methods exist for the fat client upgrade

process?

o What delivery methods are available to ensure that the upgrade/update software package exists on the local client computer prior to the server upgrade and/or first post upgrade logon?

o What automation methods exist for the client software delivery?

o Explain other methods utilized to minimize the upgrade impact to the network, IT staff, and clinic workflow.

o What vendor supported third party solutions are available to automate the fat client upgrade process and the associated costs?

• How does the service patch process differ from full upgrade process and how does it affect each process listed in this section above?

What is the current upgrade schedule? What is the current service patch schedule? Are all upgrades and patches included in the maintenance agreement?

Contract Terms and Vendor Guarantees Will the customer be allowed to perform acceptance testing of this product prior to "Go-Live"?

Will the customer be allowed to make payments based upon milestones with a significant portion of the fees not payable until "Go-Live"?


What is the vendor’s responsibility when: − Problem resolution is not met by a certain time based on

severity level of the problem or issue? − Promoting Interoperability criteria are not met as

promised? − Upgrades cause problems (causes Promoting

Interoperability criteria to no longer be met or critical workflows to break)?

− Training is not conducted in agreed upon timeframe and/or the training materials are not adequate or delivered per contract deliverables?

− Implementation is not completed by vendor in the agreed upon timeframe due to issues related to the vendor (staffing conflicts, software problems, etc.)?

− Incompatibility issues arise between hardware (which meets agreed upon specifications) and approved software?

− Promised product functionality does not exist at time of Implementation?

− Damages to hardware during transport if purchased through vendor or while vendor is on-site during installation?

− Data is corrupted during the course of normal use and operation of the product?

− SLAs are not met?

Will you allow the representations made in your response to this RFI to be incorporated into the contract?

Will you agree to a cap on price increases? For how long?

How long will you guarantee to provide maintenance (or other support) on this product?

What is the process that you will follow when "sunsetting" this product?

Will you escrow the source code for this product?

Will you agree to the contract being governed by Kentucky law (including the applicable provisions of the UCC)?

Will you agree to negotiate a standard form contract for use by [REC] clients?

Other Vendor Services Offered What other companies have you partnered with to provide services on your behalf and what are their contact information?

If their work is done on your behalf (implementation, upgrades, etc.), do you warranty their work as if it was your own?


D. EHR System Capabilities (Respond with answer and a description of the proposed solution in the comments section when applicable, * denotes additional cost)

1. General Yes Yes* No Comments / Clarifications 1.1 The system supports both a total paperless function and a

hybrid function, where the contents of the electronic record can be printed for inclusion in the paper chart.

☐ ☐ ☐

1.2 The system includes automatic translation of codes to data.

☐ ☐ ☐

1.3 The system includes support and updates for the above vocabularies.

☐ ☐ ☐

1.4 The system includes SNOMED CT as the integrated standard nomenclature of clinical terms.

☐ ☐ ☐

1.5 Your company provides after-hours call center support for the system.

☐ ☐ ☐

2. Demographics / Care Management Yes Yes* No Comments / Clarifications 2.1 The system supports the Continuity of Care Document

(CCD) and CCD-A as the harmonized format for the exchange of clinical information including patient demographics, medications and allergies.

☐ ☐ ☐

2.2 The system has the capability to record demographics including:

☐ ☐ ☐

2.2.1 Preferred language ☐ ☐ ☐

2.2.2 Insurance type ☐ ☐ ☐

2.2.3 Gender ☐ ☐ ☐

2.2.4 Race ☐ ☐ ☐

2.2.5 Ethnicity ☐ ☐ ☐

2.2.6 Date of birth. ☐ ☐ ☐

2.3 The system supports the Continuity of Care Document Continuity of Care Record, HITSP standard.

☐ ☐ ☐

2.4 The system has the capability of importing patient demographic data via HL7 interface from an existing Practice Management System, Patient Registration System, or any such system used for patient registration and/or scheduling.

☐ ☐ ☐

2.5 The system identifies and maintains a single patient record for each patient.

☐ ☐ ☐

2.6 The system supports a user verifiable record merge function.

☐ ☐ ☐

2.7 The system supports purging of incomplete or partial records (i.e. those created by auto population from the practice management system but for which no clinical data exists).

☐ ☐ ☐

2.8 The system captures and maintains demographic information. Where appropriate, the data should be clinically relevant, reportable, and traceable over time.

☐ ☐ ☐

2.9 The system creates and maintains patient-specific summary lists that are structured and coded where appropriate.

☐ ☐ ☐

2.10 The system captures patient and family care preferences at the point of care.

☐ ☐ ☐


2. Demographics / Care Management Yes Yes* No Comments / Clarifications 2.10.1 Collect Race data with categories as specified by OMB ☐ ☐ ☐

2.10.2 Collect Ethnic Group as defined by IOM ☐ ☐ ☐

2.10.3 Housing Status including effective dates ☐ ☐ ☐

2.10.4 Migrant Farm Worker Status including effective dates ☐ ☐ ☐

2.11 The system has the capability to import/create, review, update, and hide patient demographic information as well as other non-clinical information from the patient record in both PMS and EMR.

☐ ☐ ☐

2.12 The system captures permanent patient address. ☐ ☐ ☐

2.13 The system captures temporary patient addresses. ☐ ☐ ☐

2.14 Preferred spoken language ☐ ☐ ☐

2.15 Preferred written language ☐ ☐ ☐

2.16 Translator needed ☐ ☐ ☐

2.17 The system has the ability to identify duplicate accounts ☐ ☐ ☐

2.18 The system has a look-up mechanism based on multiple criteria including “sounds-like”

☐ ☐ ☐

2.19 The system has the capability to have hyphen last names ☐ ☐ ☐

2.20 The system has the ability to use aliases ☐ ☐ ☐

2.21 Track more than one PCP ☐ ☐ ☐

2.22 Track referring providers ☐ ☐ ☐

2.23 Capture guardian information ☐ ☐ ☐

2.24 Set specific alerts around age of consent laws ☐ ☐ ☐

2.25 Collect cellular phone number ☐ ☐ ☐

3. Patient History Yes Yes* No Comments / Clarifications 3.1 The system has the capability to import patient health

history data, including obstetrical history data, from an existing system.

☐ ☐ ☐

3.2 The system presents a chronological, filterable, and comprehensive review of patient’s EHR, which may be summarized and printed, subject to privacy and confidentiality requirements.

☐ ☐ ☐

3.3 The system allows the capture, review, and management of medical procedural/OB/surgical, oral health, social, and family history, including the capture and linking of pertinent positive and negative histories, and patient-reported or externally available patient clinical history (includes birth history, dietary/nutrition history, immunization history, allergy and developmental history for children and behavioral health history). Additionally, scanned documents are processed with OCR to allow text-based searches of all imported documents.

☐ ☐ ☐

3.4 For each new patient, the system captures and stores risk factors and highlights missing data to alert users to complete. For example:

☐ ☐ ☐

3.4.1 History of STDs or STIs ☐ ☐ ☐

3.4.2 Sickle cell status ☐ ☐ ☐


3. Patient History Yes Yes* No Comments / Clarifications 3.4.3 TB Status ☐ ☐ ☐

3.4.4 Tobacco use and history including number of years and packs per day (PPD). In addition the system allows the capture of Plans and reminders

☐ ☐ ☐

3.4.5 Alcohol use, history ☐ ☐ ☐

3.4.6 Drug use, history ☐ ☐ ☐

3.4.7 Occupational Environment ☐ ☐ ☐

3.4.8 Living/Residential Environment ☐ ☐ ☐

3.5 For each new patient, the system captures and stores the following social history elements, also indicate how the system captures each element:

☐ ☐ ☐

3.5.1 The system allows the tracking of domestic partners as well as married couples.

☐ ☐ ☐

3.5.2 Occupation ☐ ☐ ☐

3.5.3 Religious preference ☐ ☐ ☐

3.5.4 Socioeconomic status ☐ ☐ ☐

3.5.5 Education ☐ ☐ ☐

3.5.6 Housing Status ☐ ☐ ☐

3.5.7 Disabilities ☐ ☐ ☐

3.6 The system has the capability to import patient health history data, including obstetrical history data, from an existing system.

☐ ☐ ☐

3.7 The system documents and links hospitalization and emergency department data including:

☐ ☐ ☐

3.7.1 Admission and Discharge dates for all type of hospitalizations (i.e. behavioral health, substance abuse, physical rehabilitation, ER, etc.)

☐ ☐ ☐

3.7.2 Chief complaint ☐ ☐ ☐

3.7.3 Admitting diagnosis / Other diagnoses ☐ ☐ ☐

3.7.4 Procedures performed ☐ ☐ ☐

3.7.5 Discharge summary ☐ ☐ ☐

3.7.6 Discharge disposition ☐ ☐ ☐

3.7.7 Emergency room visit and discharge date(s) ☐ ☐ ☐

3.8 The system documents all existing allergies, interactions and adverse reactions such as:

☐ ☐ ☐

3.8.1 Drug ☐ ☐ ☐

3.8.2 Food ☐ ☐ ☐

3.8.3 Drug-food plus other (e.g. bee sting, environmental allergies)

☐ ☐ ☐

3.9 The system captures history of received immunizations. ☐ ☐ ☐

3.10 Alternative and herbal medications, OTC medications, and supplements

☐ ☐ ☐

3.11 The system has the capability of linking or grouping records of other family members on file.

☐ ☐ ☐

3.12 The system has the capability to capture and store genograms

☐ ☐ ☐


3. Patient History Yes Yes* No Comments / Clarifications 3.13 The system collects and stores family history, including,

but not limited to: ☐ ☐ ☐

3.13.1 History of chronic diseases, including date of diagnosis ☐ ☐ ☐

3.13.2 Disease status ☐ ☐ ☐

3.13.3 Family member functional status ☐ ☐ ☐

3.13.4 If deceased: date and cause of death ☐ ☐ ☐

3.14 The system presents a chronological, filterable, and comprehensive review of patient’s EMR, which may be summarized, subject to privacy and confidentiality requirements.

☐ ☐ ☐

3.15 The system captures and explicitly labels patient-provided and patient-entered (and/or parent-, family member-, or guardian-provided or -entered) clinical data and supports provider authentication for inclusion in patient history.

☐ ☐ ☐

4. Current Health Data, Encounters, Health Risk Assessment Yes Yes* No Comments / Clarifications 4.1 The system includes a combination of system default,

provider customizable, and provider-defined and reusable templates for data capture.

☐ ☐ ☐

4.2 The system obtains test results via standard HL7 interface from:

☐ ☐ ☐

4.3 Laboratory ☐ ☐ ☐

4.3.1 Radiology/ Imaging ☐ ☐ ☐

4.3.2 Other equipment such as Vitals, ECG, Holter, Glucometer

☐ ☐ ☐

4.3.3 The system has the capability to capture and monitor patient health risk factors in a standard format.

☐ ☐ ☐

4.4 The system provides a flexible, user modifiable, search mechanism for retrieval of information captured during encounter documentation.

☐ ☐ ☐

4.5 The system provides a mechanism to capture, review, or amend history of current illness.

☐ ☐ ☐

4.6 The system enables the origination, documentation, and tracking of referrals between care providers or healthcare organizations, including clinical and administrative details of the referral.

☐ ☐ ☐

4.7 The system tracks consultations and referrals. ☐ ☐ ☐

4.8 The system has the capability to incorporate clinical documentation from external sources.

☐ ☐ ☐

4.9 The system has the capability to capture and monitor patient health risk factors in a standard format and label risk patients OB and non-OB.

☐ ☐ ☐

4.10 The system shall display encounter data using a problem-oriented format.

☐ ☐ ☐

4.11 The system supports online completion of the Health Survey (SF-36 – Health Status Measures) or similar measure for measuring health status and outcomes.

☐ ☐ ☐

4.12 List all of the systems graphical representation abilities such as (graphic display and plotting of forms requiring graphic representation)

☐ ☐ ☐


4.13 The system has the capability of reproducing and displaying a variety of end user patient and treatment forms.

☐ ☐ ☐

4.14 The system has the capability to update other portions of the record with captured vital signs data. At minimum, the system collects:

☐ ☐ ☐

4.15 Height ☐ ☐ ☐

4.15.1 Weight ☐ ☐ ☐

4.15.2 Pulse ☐ ☐ ☐

4.15.3 Respiratory rate ☐ ☐ ☐

4.15.4 Blood pressure (including multiples) ☐ ☐ ☐

4.15.5 Different position blood pressure ☐ ☐ ☐

4.15.6 Oximetry (with FiO2 identifier) ☐ ☐ ☐

4.15.7 Pain ☐ ☐ ☐

4.15.8 BMI (calculated) ☐ ☐ ☐

4.15.9 Visual Acuity (corrected / uncorrected) ☐ ☐ ☐

4.15.10 Audiology screening ☐ ☐ ☐

4.15.11 Last menstrual period ☐ ☐ ☐

4.15.12 Head circumference (pediatrics) ☐ ☐ ☐

4.15.13 Temperature ☐ ☐ ☐

4.15.14 They system has ability to make certain data capture mandatory based on demographic and patient condition criteria.

☐ ☐ ☐

4.15.15 The system incorporates one or more accepted measure of functional level, e.g. the GAF.

☐ ☐ ☐

4.16 The system has the capability to import/create, review, update, and amend health data (objective and subjective) regarding the patient’s current health status, including (as applicable):

☐ ☐ ☐

4.17 Chief complaint ☐ ☐ ☐

4.17.1 Onset of symptoms ☐ ☐ ☐

4.17.2 Injury mechanism ☐ ☐ ☐

4.17.3 Physical examination findings ☐ ☐ ☐

4.17.4 Psychological and social assessment findings with built in screening tools.

☐ ☐ ☐

4.17.5 The system provides a flexible mechanism for retrieval of encounter information “patient search” that can be organized in variety of ‘views’. For example:

☐ ☐ ☐

4.18 By name (last, first; first, last; etc.) ☐ ☐ ☐

4.18.1 By date of birth ☐ ☐ ☐

4.18.2 Chronological by encounter date ☐ ☐ ☐

4.18.3 By diagnosis ☐ ☐ ☐

4.18.4 By diagnosis type ☐ ☐ ☐

4.18.5 By chart number ☐ ☐ ☐

4.18.6 By family group / linkage ☐ ☐ ☐


4.18.7 The system provides a flexible, user modifiable, search mechanism for retrieval of information captured during encounter documentation.

☐ ☐ ☐

4.19 The system provides a mechanism to capture, review, or amend history of current illness.

☐ ☐ ☐

4.20 The system ensures dynamic documentation during the encounter complying with all standard coding rules.

☐ ☐ ☐

4.21 The system enables the origination, documentation, and tracking of referrals between care providers or healthcare organizations, including clinical and administrative details of the referral.

☐ ☐ ☐

4.22 The system has the capability to evaluate referrals within the context of the patient’s clinical data and automatically close the loop once the referral is in the system.

☐ ☐ ☐

4.23 The system is capable of providing a summary of care record for each referral, when a patient is referred to another provider of care.

☐ ☐ ☐

4.24 The system captures the following referral information: ☐ ☐ ☐

4.25 Referral type (Reason for referral) ☐ ☐ ☐

4.25.1 Date ☐ ☐ ☐

4.25.2 Reason ☐ ☐ ☐

4.25.3 Referring Provider ☐ ☐ ☐

4.25.4 Referred to Provider ☐ ☐ ☐

4.25.5 Referral diagnosis codes (ICD9 and ICD10) ☐ ☐ ☐

4.25.6 Payer ☐ ☐ ☐

4.25.7 The system tracks consultations and referrals. ☐ ☐ ☐

4.26 The system has the capability of printing consultations / referrals forms.

☐ ☐ ☐

4.27 The system provides a mechanism to capture, review, track (assign a number), and print a specific consultation or specialist report.

☐ ☐ ☐

4.28

5. Encounter – Progress Notes Yes Yes* No Comments / Clarifications 5.1 The system records progress notes utilizing a combination

of system default, provider customizable, and provider-defined templates.

☐ ☐ ☐

5.2 The system includes a progress note template that is problem oriented and can, at the user’s option be linked to either a diagnosis or problem number.

☐ ☐ ☐

5.3 The system has the capability to automatically update other sections of the record with data entered in the progress note. Specify what sections this includes: (Meds, allergies, FHx, Social Hx, etc.)

☐ ☐ ☐

5.3.1 The encounter - progress note template includes space for entering performed and planned procedures. It also includes:

☐ ☐ ☐

5.3.2 Performed/planned Laboratory procedures and/or a link to LAB OE that automatically updates the problem list

☐ ☐ ☐

5.3.3 Diagnosis ☐ ☐ ☐


5.3.4 Goals (provider’s and patient’s) and follow-up plans including next visit which includes a search functionality.

☐ ☐ ☐

5.3.5 “Living” care plan that is updated from visit to visit but does not get closed

☐ ☐ ☐

5.3.6 Medications prescribed ☐ ☐ ☐

5.3.7 Non-drug prescriptions (e.g. exercise, dietary recommendations/complementary and alternative therapies including massage)

☐ ☐ ☐

5.3.8 Patient education materials are culturally and linguistically appropriate and are written at an appropriate health literacy level

☐ ☐ ☐

5.3.9 Consultation/referrals ☐ ☐ ☐

5.3.10 Patient condition or status ☐ ☐ ☐

5.4 The system has the capability of retrieving encounters by a variety of user-defined parameters.

☐ ☐ ☐

5.5 The system enables standard phrases to be defined/contained in tables and used as pull down menus to reduce the key entry effort.

☐ ☐ ☐

5.6 The system enables progress notes to be sorted for viewing in chronological or reverse chronological order by encounter date in relation to the active care plan.

☐ ☐ ☐

5.7 The system applies security controls to progress notes to ensure that data cannot be deleted or altered except within the current session and by an authorized user.

☐ ☐ ☐

5.8 The system includes a medical terminology dictionary and a spell checker within the progress notes data entry module.

☐ ☐ ☐

5.9 The system supports the capability to automatically collect the data elements defined by the associated clinical practice guideline or order.

☐ ☐ ☐

5.10 The system is able to pull the problem list into the notes in the visit assessment section.

☐ ☐ ☐

6. Problem Lists Yes Yes* No Comments / Clarifications 6.1 The system creates and maintains patient-specific

problem lists and allows the designation and separation of chronic and temporary/acute problems.

☐ ☐ ☐

6.2 The system creates and maintains patient-specific problem lists.

☐ ☐ ☐

6.3 For each problem, the systems has the capability to create, review, or amend information regarding a change on the status of a problem to include, but not be limited to, the date the change was first noticed or diagnosed.

☐ ☐ ☐

6.4 The system provides a problem status (active, inactive) for each shown problem.

☐ ☐ ☐

6.5 The system organizes applicable patient data into comprehensive problem summary lists.

☐ ☐ ☐

6.6 The system provides problem descriptions based on the SNOMED CT standard controlled vocabulary

☐ ☐ ☐

6.7 The system allows clinicians to identify and record new patient problems as well as the current status of existing problems during visit documentation.

☐ ☐ ☐


6.8 The system expands the problem summary list on demand.

☐ ☐ ☐

6.9 The system updates the active problem list from relevant data in the progress note with appropriate end-user confirmation and allows use of the problem list to generate visit diagnoses during progress note and charge slip generation.

☐ ☐ ☐

6.10 When capturing problem information, the system captures: ☐ ☐ ☐

6.10.1 Diagnosis / problem date(s) ☐ ☐ ☐

6.10.2 Severity of illness (or acute/chronic) ☐ ☐ ☐

6.11 For each problem, the systems has the capability to create, review, or amend information regarding a change on the status of a problem to include, but not be limited to, the date the change was first noticed or diagnosed. Also indicate what the character limit restrictions might be for each problem.

☐ ☐ ☐

6.12 The system has the capability of allowing the display of past interventions, hospitalizations, diagnostic procedures, and therapies for review at the option of the provider.

☐ ☐ ☐

6.13 The system has the functionality to update the problem list from the clinical encounter as well as from Order Entry (OE) and Charge Capture (CC).

☐ ☐ ☐

7. Clinical Practice Guidelines (CPG) Yes Yes* No Comments / Clarifications 7.1 The system includes and maintains evidence-based

Clinical Practice Guidelines (CPGs) published and maintained by nationally recognized authoritative sources (e.g. U.S. Preventive Services Task Force (USPSTF) or others). The guidelines incorporate patient education and actionable alerts and reminders. Indicate what groups their CPGs apply to and whether or not they are customizable.

☐ ☐ ☐

7.2 The system includes and maintains evidence-based Clinical Practice Guidelines (CPGs) published and maintained by credible sources such as the American Heart Association (AHA), U.S. Preventive Services Task Force (USPSTF), American College of Cardiologists (ACC), American College of Physicians (ACP) and other groups. The guidelines incorporate patient education and actionable alerts and reminders.

☐ ☐ ☐

7.3 The system allows reporting and analysis of any / all components included in the CPG.

☐ ☐ ☐

7.4 Included in each CPG, the system has the capability to create, review, and update information about:

☐ ☐ ☐

7.4.1 The performance measures that will be used to monitor the attainment of objectives.

☐ ☐ ☐

7.4.2 The quantitative and qualitative data to be collected. ☐ ☐ ☐

7.4.3 Performance metrics: CPG shall allow for decision support based on standardized discrete data to be used to calculate clinical performance measures.

☐ ☐ ☐

7.4.4 Collection means and origin of data to be evaluated. ☐ ☐ ☐


7.5 The system allows the provider or other authorized user to override any or all parts of the guideline. The system is able to collect exceptions for NOT following the CPG.

☐ ☐ ☐

7.6 At minimum the system includes CPGs for the following: ☐ ☐ ☐

7.6.1 Asthma ☐ ☐ ☐

7.6.2 Colorectal Cancer Screening ☐ ☐ ☐

7.6.3 Congestive Heart Failure ☐ ☐ ☐

7.6.4 Depression ☐ ☐ ☐

7.6.5 Diabetes ☐ ☐ ☐

7.6.6 Coronary Artery Disease ☐ ☐ ☐

7.6.7 Hyperlipidemia ☐ ☐ ☐

7.6.8 COPD ☐ ☐ ☐

7.6.9 HIV/AIDS ☐ ☐ ☐

7.6.10 Cervical Cancer ☐ ☐ ☐

7.6.11 Breast Cancer ☐ ☐ ☐

7.6.12 Hypertension ☐ ☐ ☐

7.6.13 Developmental Delay ☐ ☐ ☐

7.7 The system has the capability of allowing initial authoring and revising of clinical practice guidelines.

☐ ☐ ☐

7.8 The system allows linkages from the CPG to other system modules such as CDS.

☐ ☐ ☐

7.9 The CPG module imports/creates the facility for rapid documentation of the patient’s progress along the CPG phases.

☐ ☐ ☐

7.10 The format utilized by the guideline for documenting is intuitive, easy to use, and user customizable.

☐ ☐ ☐

7.11 The CPG module utilizes pull down menus and check boxes to speed up data entry.

☐ ☐ ☐

7.12 The system allows reporting and analysis of any / all components included in the CPG.

☐ ☐ ☐

7.13 Included in each CPG, the system has the capability to create, review, and update information about:

☐ ☐ ☐

7.13.1 The performance measures that will be used to monitor the attainment of objectives

☐ ☐ ☐

7.13.2 The quantitative and qualitative data to be collected ☐ ☐ ☐

7.13.3 Performance metrics: CPG shall allow for decision support based on standardized discrete data to be used to calculate clinical performance measures

☐ ☐ ☐

7.13.4 Collection means and origin of data to be evaluated ☐ ☐ ☐

7.14 The system links customizable order sets to the CPGs ☐ ☐ ☐

8. Care Plans Yes Yes* No Comments / Clarifications 8.1 The system provides administrative tools for organizations

to build care plans, guidelines, and protocols for use during patient care planning and care.

☐ ☐ ☐

8.2 The system generates and automatically records in the care plan document, patient-specific instructions related to pre- and post-procedural and post-discharge requirements. The instructions must be simple to access.

☐ ☐ ☐


8.3 The system is capable of providing a summary of care record for each transition of care or referral, when a patient is transitioned to another setting of care or provider of care or is referred to another provider of care.

☐ ☐ ☐

8.4 The system identifies and presents the appropriate care plans, guidelines, and/or protocols for the management of specific conditions that are patient-specific.

☐ ☐ ☐

8.5 The system has the capability to import/create, review, and amend information about the desired single or multi-disciplinary long / short term goals and objectives that will be accompanied by the care plan.

☐ ☐ ☐

8.6 The system has the capability to import/create, review, and amend information about the proposed set of single or multi-disciplinary care plan options that are based upon expected outcomes.

☐ ☐ ☐

8.7 The system generates and automatically records in the final document, patient-specific instructions related to pre- and post-procedural and post-discharge requirements. The instructions must be simple to access.

☐ ☐ ☐

8.7.1 The system can generate and automatically record in the final document "Time Out" was done prior to the procedure - to include:

☐ ☐ ☐

8.7.1.1 Correct patient identified ☐ ☐ ☐

8.7.1.2 Correct procedure confirmed ☐ ☐ ☐

8.7.1.3 Procedure and risk were explained ☐ ☐ ☐

8.7.1.4 Correct side and site confirmed ☐ ☐ ☐

8.7.1.5 Questions were answered and patient agrees to procedure

☐ ☐ ☐

8.7.1.6 Accurate consent obtained (including that ability to obtain real time signatures from necessary staff as well as patients)

☐ ☐ ☐

8.7.1.7 Consents are customizable to reflect the age laws of Kentucky.

☐ ☐ ☐

8.7.2 The system can generate and automatically record patient - specific educational instruction related to their medical condition

☐ ☐ ☐

8.8 The system has the capability to import/create, review, and amend information about:

☐ ☐ ☐

8.8.1 The provider’s explanation and the patient or patient representative’s understanding of the recommended and/or alternative care plan options

☐ ☐ ☐

8.8.2 The medical orders, which authorize the execution of the selected, care plan

☐ ☐ ☐

8.8.3 The collection of specimens (body fluids, tissue, etc.) from the patient to be used for diagnostic or treatment purposes

☐ ☐ ☐

8.8.4 The actions taken to safeguard the patient to avert the occurrence of morbidity, trauma, infection, or condition deterioration

☐ ☐ ☐

8.8.5 The provider's explanation and the patient or patient representative's understanding of health proxy and DNR consent

☐ ☐ ☐

8.8.6 Describe the system capability for documenting AD and POLST

☐ ☐ ☐


9. Prevention Yes Yes* No Comments / Clarifications 9.1 The system has the capability to display health prevention

prompts on the summary display. The prompts must be dynamic and take into account sex, age, and chronic conditions.

☐ ☐ ☐

9.2 The system includes user-modifiable health maintenance templates.

☐ ☐ ☐

9.3 The system includes a patient tracking and reminder capability (patient follow-up) updatable by the user at the time an event is set or complied with.

☐ ☐ ☐

9.4 The system allows interactive prevention status documentation. At minimum:

☐ ☐ ☐

9.4.1 Date addressed ☐ ☐ ☐

9.4.2 Result ☐ ☐ ☐

9.4.3 Reason not performed ☐ ☐ ☐

9.4.4 Where performed ☐ ☐ ☐

9.4.5 The system allows the preventive measures done on the visit to automatically populate the health maintenance summary template

☐ ☐ ☐

9.5 The system includes a patient tracking and reminder capability (patient follow-up) updatable by the user at the time an event is set or complied with and can be assigned to designated staff based on needs.

☐ ☐ ☐

9.6 The system allows the graphing of pertinent data into flow sheets for presentation/display.

☐ ☐ ☐

9.7 The system is able to capture results and procedures that that took place at a different facility.

☐ ☐ ☐

9.8 The system includes the incorporation of immunization protocols:

☐ ☐ ☐

9.8.1 Universal child ☐ ☐ ☐

9.8.2 Universal adult ☐ ☐ ☐

9.8.3 Specific foreign travel ☐ ☐ ☐

9.8.4 The system includes immunization forecasting and notifies the user of vaccines that are past due and of due dates for upcoming due vaccines, and is capable of documenting vaccine refusal

☐ ☐ ☐

9.8.5 The system allows providers to order appropriate vaccines, with staff having access to those ordered on a separate computer (tablet), on which they can record data including:

☐ ☐ ☐

9.8.5.1 Specific manufacturers/lots used (drop-down lists) ☐ ☐ ☐

9.8.5.2 Site of administration ☐ ☐ ☐

9.8.5.3 Route of administration ☐ ☐ ☐

9.8.5.4 Amount administered ☐ ☐ ☐

9.8.5.5 Units ☐ ☐ ☐

9.8.5.6 Vaccine expiration date ☐ ☐ ☐

9.8.5.7 VIS publication date(s) and/or date(s) provided ☐ ☐ ☐

9.8.5.8 Funding source ☐ ☐ ☐


9.8.5.8.1 Drop-down lists will display only vaccine lots – private vs. state – appropriate to patient’s status as private insured, Medicaid, uninsured, underinsured, etc.

☐ ☐ ☐

9.8.6 The system displays a “Vaccine Administration Record” (informed consent) type form, which displays the above information and is electronically signed by the party responsible for granting consent and the person administering the vaccines

☐ ☐ ☐

9.8.7 The system allows for printing an updated “shot record” (perhaps also height, weight, etc. information) at the end of each visit

☐ ☐ ☐

9.8.8 The system updates the practice inventory of available vaccines each time one is recorded as having been administered; a report on private and public funded vaccine inventories can be displayed or printed at any time

☐ ☐ ☐

9.8.9 The system will send and receive information from Kentucky State Department of Health’s Immunization Information System, including vaccine inventories, individual patient vaccine administration histories and updated demographics

☐ ☐ ☐

9.8.10 The system is capable of reporting to VAERS to report reactions to vaccinations

☐ ☐ ☐

9.8.11 The system is capable of printing a valid Kentucky State immunization certificate that includes administered and historical immunization data

☐ ☐ ☐

10. Children’s Health Yes Yes* No Comments / Clarifications 10.1 The system displays the age of a child in appropriate units

as specified by CCHIT Child Health Criteria. ☐ ☐ ☐

10.2 Height (children) English/metric – Calculated percentile ☐ ☐ ☐

10.3 Weight (children) English/metric – Calculated percentile ☐ ☐ ☐

10.4 Head circumference (children) English/metric – Calculated percentile

☐ ☐ ☐

10.5 Body mass index (children) English/metric – Calculated percentile

☐ ☐ ☐

10.6 The system displays growth charts showing plotted values of height, weight, head circumference and BMI against age and sex normed data

☐ ☐ ☐

10.7 The system suggests appropriate drug dose in volume/dose when given a drug formulation specifying concentration and mg/mL, a patient’s weight (in lb. or kg), a dose in mg/kg and a frequency (e.g. given a 250mg/ml formulation, a 12 lb. child, and planned dose of 80 mg/kg/day divided twice daily, suggests mL/dose).

☐ ☐ ☐

10.8 Newborn screening results (including sickle cell status) ☐ ☐ ☐

10.9 Stage of sexual maturity (e.g., Tanner stages) ☐ ☐ ☐

10.10 Developmental Status (based on standardized screening tool – list and describe)

☐ ☐ ☐

11. Pregnancy Care Yes Yes* No Comments / Clarifications


11.1 The system accepts coded input for historical items that are asked at each pregnancy visit (could include, but not limited to key symptoms e.g. loss of fluid, fetal movement, etc.)

☐ ☐ ☐

11.2 The system makes pregnancy past history available to the provider for future pregnancies and displayed separate from past medical history.

☐ ☐ ☐

11.3 The system creates a separate problem list pertaining to patient’s current pregnancy.

☐ ☐ ☐

11.4 The system records fetal heart rate, fetal position, fundal height, weight, urine analysis and blood pressure at each visit.

☐ ☐ ☐

11.5 The system provides for a flexible configuration for dates or time since a specified event to be used for notification and alerts modifiable at the provider level.

☐ ☐ ☐

11.6 The system displays the estimated date of delivery (EDD) given the patient’s last menstrual period (LMP). The system will calculate an EDDF given an ultrasound date and the estimated gestational date (EGA) given by the ultrasound. The provider must specify which of the above methods will be used to calculate the patient’s final due date. The EGA (based on the method specified by the provider) is widely visible at each visit.

☐ ☐ ☐

11.7 The system flags when EDD from last menstrual period is different than OB Ultrasound date and requires acknowledgment.

☐ ☐ ☐

11.8 The system will prompt the provider about care that is due at each visit based on the EGA(calculated using the specified method above) utilizing a planned care approach.

☐ ☐ ☐

11.9 The system creates a printable view of all visits, labs, due date, ultrasound, problem list and plans which can be given to a patient for purposes of communicating with providers on a Labor and Delivery floor, ideally in ACOG format.

☐ ☐ ☐

11.10 The system can exchange data about the current pregnancy with hospital and/or health information exchange systems; should be in ACOG format.

☐ ☐ ☐

11.11 The system captures PN risk factors for stratification of pregnancy risk.

☐ ☐ ☐

11.12 The system has a separate PN problem list ☐ ☐ ☐

11.13 Describe other PN features ☐ ☐ ☐

12. Dental Yes Yes* No Comments / Clarifications 12.1 The system exchanges patient demographic data

(personal, billing) with a dental HIT system. ☐ ☐ ☐

12.2 The system allows medications to be viewed in both the dental HIT system and the EMR and these lists are integrated.

☐ ☐ ☐

12.3 The system has the ability to exchange health history (e.g. allergies, labs, problem list) with the dental HIT system.

☐ ☐ ☐


13. Behavioral Health Yes Yes* No Comments / Clarifications 13.1 The system shares the medication list across the entire

system. ☐ ☐ ☐

13.2 The system includes a single medication module shared by both the primary care and the behavioral health module.

☐ ☐ ☐

13.3 The system includes an integrated diagnostic module shared with BH.

☐ ☐ ☐

13.4 The system can limit the sharing of behavioral health diagnoses and medications if configured this way by the organization.

☐ ☐ ☐

13.5 For Behavioral Health in addition to primary care, the system requires a treatment plan.

☐ ☐ ☐

13.6 The system prevents an encounter be dropped for billing without a diagnosis code on it?

☐ ☐ ☐ Click here to enter text.

13.6.1 If not, is there a way we can put a safeguard to stop this from happening?


13.7 How do the system handle non-billable encounters so they do not go in as part of the batch for claims?

Click here to enter text.

13.8 How does the system handle it if a PCP still has an open encounter but Behavioral Health Professional wants to document on the same patient and close their encounter instead of putting it on hold?


13.9 Is there a way to make it a requirement in your system that encounters are to be closed in 36 hours?


13.10 If another provider has not sent through a medication to the pharmacy does this stop another provider from sending their medication through? (Same question is requested for FP as well)


13.11 The system has the ability to electronically prescribe narcotics. Explain.


13.11.1 Areas covered: 13.11.1.1 Mental Health ☐ ☐ ☐ Click here to enter text. 13.11.1.2 Addiction ☐ ☐ ☐ Click here to enter text. 13.11.1.3 Family Case Management ☐ ☐ ☐ Click here to enter text. 13.11.1.4 Prevention Services ☐ ☐ ☐ Click here to enter text. 13.11.1.5 MAT: Medication Assisted Treatment ☐ ☐ ☐ Click here to enter text. 13.11.1.5.1 Methadone & Vivitrol ☐ ☐ ☐ Click here to enter text. 13.11.1.5.2 Suboxone ☐ ☐ ☐ Click here to enter text. 13.12 The system has the ability to flag patients at risk for

suicide ☐ ☐ ☐ Click here to enter text.

13.13 The system provides embedded auto calculating PHQ 2 and 9, plus other mental health and substance use screeners (list)


13.14 The system provides access to patient registries ☐ ☐ ☐ Click here to enter text. 13.15 The system provides a way to sequester substance use

documentation ☐ ☐ ☐ Click here to enter text.


14. Patient Education Yes Yes* No Comments / Clarifications 14.1 The system has the capability to create, review, update, or

delete patient education materials. The materials must originate from a credible source and be maintained by the vendor as frequently as necessary and may be user defined.

☐ ☐ ☐

14.2 The system has the capability of providing printed patient education materials in culturally appropriate languages on demand or automatically at the end of the encounter. At minimum, the materials must be provided in English and Spanish as applicable.

☐ ☐ ☐

14.3 The system has the capability of providing printed or electronic patient-specific education materials or resources to the patient on demand or automatically at the end of the encounter which comply with MU stage 2 and 3.

☐ ☐ ☐

14.4 The system is capable of providing the materials or resources indicated in 14.2, in the patient’s preferred language. At minimum, the materials must be provided in English and Spanish as applicable.

☐ ☐ ☐

14.5 The system has the capability to produce patient education materials at the appropriate reading level and is customizable to accommodate cultural differences.

☐ ☐ ☐

14.6 The system includes or the capability to develop patient instructions in English and in the patient’s preferred language (refer so section 3 for YVFWC demographic information), at the appropriate reading level and adjusted for cultural differences, for a broad range of treatments and services delivered by providers. Examples (list others):

☐ ☐ ☐

14.6.1 Care of wound ☐ ☐ ☐

14.6.2 Exercise regimen ☐ ☐ ☐

14.6.3 Diet guidelines ☐ ☐ ☐

14.6.4 Oral Health ☐ ☐ ☐

14.6.5 Behavioral Health ☐ ☐ ☐

14.7 Administration and care of medications: ☐ ☐ ☐

14.7.1 The system allows patient instructions to be selected from a pull down list.

☐ ☐ ☐

14.7.2 The system allows user modifications to instructions to suit individual patient needs without altering the original content.

☐ ☐ ☐

14.7.3 The system enables the linkage of patient instructions to care plans/care maps/ practice guidelines/orders, enabling automatic printing.

☐ ☐ ☐

14.8 The system allows patient instructions to be printed on demand independent of care plans/care maps/guidelines/orders.

☐ ☐ ☐

14.9 The system includes the facility to create a directory of information for patient support groups and to include any applicable support group information in the instructions.

☐ ☐ ☐

14.10 The system is capable of listing the educational materials printed for the patient on the final document.

☐ ☐ ☐


15. Alerts / Reminders Yes Yes* No Comments / Clarifications 15.1 The system includes user customizable alert screens /

messages, enabling capture of alert details. ☐ ☐ ☐

15.2 The system includes user customizable alert screens / messages, enabling capture of alert details, including, but not being limited to:

☐ ☐ ☐

15.2.1 Text describing the alert ☐ ☐ ☐

15.2.2 Date and time of the alert (and ability to set future alerts as care reminders)

☐ ☐ ☐

15.2.3 The system prints the alert on demand. ☐ ☐ ☐

15.3 The system has the capability of forwarding the alert to a specific provider(s) or other authorized users via secure electronic mail or by other means of secure electronic communications.

☐ ☐ ☐

15.4 The system allows for patient specific and provider defined alerts.

☐ ☐ ☐

15.5 The system tracks the user’s response to an alert. ☐ ☐ ☐

15.6 The system allows the user to document rationale for following/not following an alert.

☐ ☐ ☐

15.7 Relevant Reminders/Alerts are displayed when a patient chart is opened.

☐ ☐ ☐

15.8 The system includes an internal “notes” function that clinicians can use to remind themselves of non-alert/reminder issues. The items should be easily removed when complete.

☐ ☐ ☐

15.9 The system is capable of utilizing alerts to facilitate sending of reminders to patients per patient preference for preventive or follow up care; and to track that status of such reminders.

☐ ☐ ☐

15.10 Practice would prefer not to have pop-up alerts, instead the system would ideally have icons to label patients. Describe alert functions and customizability.

☐ ☐ ☐

16. Orders Yes Yes* No Comments / Clarifications 16.1 The system includes an electronic Order Entry module

that has the capability to be interfaced with a number of key systems depending on the health center’s existing and future systems as well as external linkages, through a standard, real time, HL7 bidirectional interface.

☐ ☐ ☐

16.2 The system displays order summaries on demand to allow the clinician to review/correct all orders prior to transmitting/printing the orders for processing by the receiving entity.

☐ ☐ ☐

16.3 The system captures and tracks orders based on input from specific care providers.

☐ ☐ ☐

16.4 The system has the capability to submit diagnostic test orders based on input from specific care providers.

☐ ☐ ☐

16.5 The system has the capability to print orders for manual transmission.

☐ ☐ ☐

16.6 The system has the capability to fax orders. When faxing orders, the system shall determine and report whether the transmission was successful (i.e. received at destination).

☐ ☐ ☐


16.7 The system has the capability to require that all orders be digitally signed at the completion of each order. This includes verbal orders, and the system must produce statistics regarding order completion.

☐ ☐ ☐

16.8 The system accepts orders from multiple locations. ☐ ☐ ☐

16.9 The system has the capability to assign and display an order number for active, hold, and pending orders.

☐ ☐ ☐

16.10 During the order entry process, the system has the capability to require the user to acknowledge an error message prior to being allowed to continue with the data entry function.

☐ ☐ ☐

16.11 The system allows the user to amend, accept, override, or cancel an order.

☐ ☐ ☐

16.12 The system requires the user to enter a justification for overriding, changing, or canceling an order prior to be allowed to continue.

☐ ☐ ☐

16.13 The system includes the visual indication of orders in need of review.

☐ ☐ ☐

16.14 The system detects and displays duplicate orders issuing visual and auditory warnings, and allows the user to override the warning after entering a justification for the override.

☐ ☐ ☐

16.15 The system includes the capability to: ☐ ☐ ☐

16.16 Define order sets, based on provider input or system prompt, for each provider or service department

☐ ☐ ☐

16.17 Contain all information specific to one order in one display screen

☐ ☐ ☐

16.18 Include a pull-down list of all order departments to enable multiple orders

☐ ☐ ☐

16.19 Include a user-configurable / customizable pull-down list of tests and services from which to place one or more orders

☐ ☐ ☐

16.20 The system has the ability to interface with an outside lab system and can search that system for the appropriate order.

☐ ☐ ☐

16.21 The system allows the provider to create/modify the most commonly used orders to assist in order placement

☐ ☐ ☐

16.22 The system can display all order sets including components, by any of the following:

☐ ☐ ☐

16.22.1 By procedure ☐ ☐ ☐

16.22.2 By provider ☐ ☐ ☐

16.22.3 By diagnosis ☐ ☐ ☐

16.22.4 By date ☐ ☐ ☐

16.23 The system has the capability to specify/display exploding orders to see greater detail.

☐ ☐ ☐

16.24 The system has the capability to enable selected orders to be standing orders.

☐ ☐ ☐

16.25 The system includes an order inquiry mechanism to allow providers to inquire on the details of an order.

☐ ☐ ☐

16.26 The order inquiry function is accessible within the order entry flow before the session is terminated.

☐ ☐ ☐


16.27 An order, at the user’s option, displays all the detail data associated with the order, including demographics, order parameters, electronic signatures, and order status.

☐ ☐ ☐

16.28 The system displays order summaries on demand to allow the clinician to review/correct all orders prior to transmitting/printing the orders for processing by the receiving entity.

☐ ☐ ☐

16.29 The system is capable of reporting/listing all orders which have not been completed or received.

☐ ☐ ☐

17. Results Yes Yes* No Comments / Clarifications 17.1 The system has the capability to route, manage, and

present current and historical test results to appropriate clinical personnel for review, with the ability to filter and compare results.

☐ ☐ ☐

17.1.1 Results can be easily viewed in a flow sheet as well as graph format.

☐ ☐ ☐

17.2 The system accepts results via two way standard interface from all standard interface compliant / capable entities or through direct data entry. Specifically – Laboratory, Radiology, and Pharmacy information systems. Attach list of currently available interfaces, if available

☐ ☐ ☐

17.3 The system includes an intuitive, user customizable results entry screen linked to orders.

☐ ☐ ☐

17.4 The system has the capability to evaluate results and notify the provider.

☐ ☐ ☐

17.5 The system allows timely notification of lab results to appropriate staff as well as easy routing and tracking of results.

☐ ☐ ☐

17.6 The system flags lab results that are abnormal or that have not been received.

☐ ☐ ☐

17.7 The system should be able to identify/sort by acuity and have the ability to require review of incoming results.

☐ ☐ ☐

17.8 The system accepts results via bidirectional standard interface from all standard interface compliant / capable entities or through direct data entry. Specifically – Laboratory (clinical and anatomic pathology), Radiology, and Pharmacy information systems; clinical laboratory test results are incorporated into the EMR as structured data.

☐ ☐ ☐

17.9 The system includes an intuitive, user customizable results entry screen linked to orders.

☐ ☐ ☐

17.10 The system utilizes items like trend lines and side by side charting to facilitate patient’s understanding

☐ ☐ ☐

17.11 The system allows authorized users to copy selected results into a note

☐ ☐ ☐

17.12 When displaying results, the system, at a minimum, displays the patient name, date and time of order, date and time results were last updated, as well as any alerts identifying changes/amendments to the test or procedure, the test name to include source of results (i.e. PHR, hospital, etc.) and normal ranges of results.

☐ ☐ ☐

17.13 The system is capable of providing on-demand to the patient an electronic copy of their health information (including diagnostic test results, problem list, mediation lists, and medication allergies).

☐ ☐ ☐


17.14 The system is capable of providing clinical summaries for patients for each office visit

☐ ☐ ☐

17.15 The system has the capability to evaluate results against normal values and notify the provider.

☐ ☐ ☐

17.16 The system uses visual cues to highlight abnormal results. ☐ ☐ ☐

17.17 The system allows reporting of relevant electronic laboratory results for reportable conditions to appropriate public health authorities.

☐ ☐ ☐

17.18 The system is capable of exchanging key clinical information (e.g., problem list, medication list, medication allergies, diagnostic test results), among providers of care and patient authorized entities electronically.

☐ ☐ ☐

17.19 The system allows the provider to signoff and comment on received lab results.

☐ ☐ ☐

17.20 The system must allow canceled orders, including reason for cancelation, to be easily identified by staff.

☐ ☐ ☐

17.21 The system allows tracking when patient was contacted with critical lab results.

☐ ☐ ☐

18. Medication and Immunization Management Yes Yes* No Comments / Clarifications 18.1 The system displays and alert to providers and nursing

staff to recognize when the patient is overdue for an age-specific immunization, as recommended by ACIP.

☐ ☐ ☐

18.2 The system identifies drug interaction warnings (prescription, over the counter) at the point of medication ordering. Interactions include: drug to drug, drug to allergy, drug to disease, and drug to pregnancy.

☐ ☐ ☐

18.3 The system alerts providers to potential administration errors for both adults and children, such as wrong patient, wrong drug, wrong dose, wrong route, and wrong time in support of medication administration or pharmacy dispense/supply management and workflow.

☐ ☐ ☐

18.4 The system supports multiple drug formularies and prescribing guidelines.

☐ ☐ ☐

18.5 The system provides the capability for electronic transfer of prescription information to a patient or organization selected pharmacy for dispensing.

☐ ☐ ☐

18.6 The system creates e-prescriptions or other medication/immunization orders, including herbal medications and orders for durable goods, with detail adequate for correct filling and administration.

☐ ☐ ☐

18.7 The system provides information regarding compliance of medication orders with formularies.

☐ ☐ ☐

18.8 The system presents to appropriate clinicians the list of medications/immunizations that are to be administered to a patient, under what circumstances, and captures administration details.

☐ ☐ ☐

18.9 The system identifies patient drug allergy, drug - drug interaction and drug – disease severity of interaction warnings (prescription, over the counter) at the point of medication ordering. Clinical Decision Support (CDS) include drug-drug, drug-allergy and drug-formulary as stated in MU Reg.

☐ ☐ ☐


18.10 The system alerts providers to potential administration errors for both adults and children, such as incorrect patient, incorrect drug, incorrect dose, incorrect route, and incorrect time in support of medication administration or pharmacy dispense/supply management and workflow.

☐ ☐ ☐

18.11 The system works with Up-To-Date to support evidence-based practice initiatives.

☐ ☐ ☐

18.12 The medication module includes access to the National Drug Classification (NDC) database.

☐ ☐ ☐

18.13 The system stores common prescriptions/immunizations for quick entry (and allows customizable lists by providers)

☐ ☐ ☐

18.14 The system supports multiple drug formularies and prescribing guidelines.

☐ ☐ ☐

18.15 The system provides the capability to select both the patient and the drug in an intuitive, easy to manage user interface

☐ ☐ ☐

18.16 The system has the capability of displaying medications/immunizations prescribed both before and after the visit, of creating and maintaining a current medication list for each patient and updating the progress note with prescription information as necessary, and verification of medications.

☐ ☐ ☐

18.17 The system has capability to perform medication/immunization reconciliation.

☐ ☐ ☐

18.18 At the provider’s option the system has the capability of selecting drugs to be prescribed from the patient’s medication list.

☐ ☐ ☐

18.19 The system allows the provider the ability to document the effectiveness or ineffectiveness of a medication.

☐ ☐ ☐

18.20 The system stores refill and repeat prescription information.

☐ ☐ ☐

18.21 The system allows storage of prescription/immunization data for retrieval by any or the following:

☐ ☐ ☐

18.22 Drug name ☐ ☐ ☐

18.23 Drug code number (NDC) ☐ ☐ ☐

18.24 Dosage prescribed ☐ ☐ ☐

18.25 Schedule, including formulary management ☐ ☐ ☐

18.26 Other user defined selection criteria(e.g. route of administration)

☐ ☐ ☐

18.27 The system provides the following drug/prescription order information:

☐ ☐ ☐

18.28 Drug contraindication ☐ ☐ ☐

18.29 Active problem interactions ☐ ☐ ☐

18.30 Check that appropriate laboratory monitoring has been obtained (for example, the system can generate reminders of needed laboratory monitoring for high risk medications)

☐ ☐ ☐

18.31 The system provides extensive drug interaction information.

☐ ☐ ☐

18.32 The system creates and maintains an active patient-specific drug allergy and adverse reaction lists and allows on demand or scheduled reporting from such lists.

☐ ☐ ☐


18.33 The system generates alerts if attempts are made to prescribe drugs that exist on allergy list or failed medication list.

☐ ☐ ☐

18.34 The system includes clinician-modifiable therapeutic guidelines.

☐ ☐ ☐

18.35 The system maintains a history of all prescribed medications including those prescribed elsewhere and/or by outside physicians; and OTC medications, supplements, alternative or herbal remedies as reported by the patient. The history segment contains space for appropriate comments.

☐ ☐ ☐

18.36 The system fully complies with existing regulations and restrictions applicable to the prescription of dangerous or regulated drugs.

☐ ☐ ☐

18.37 The system alerts providers to potential misuse of controlled substances by reference to a public health controlled substance database

☐ ☐ ☐

18.38 The system provides the capability for e-prescribing to a pharmacy or organization selected pharmacy for dispensing.

☐ ☐ ☐

18.39 The system allows creation of customizable pharmacy lists which can vary by site.

☐ ☐ ☐

18.40 The system allows faxing when e-prescribing is not available.

☐ ☐ ☐

18.41 The system includes other methods of prescribing when those above are not available.

☐ ☐ ☐

18.42 The system has the capability to capture sample medications including lot number and expiration date.

☐ ☐ ☐

18.43 The system is capable of submitting electronic data to immunization registries or Immunization Information Systems in accordance with applicable law and practice.

☐ ☐ ☐

18.44 The system allows customizable quick pick med list with dosages defaulted to the provider level.

☐ ☐ ☐

19. Confidentiality and Security Yes Yes* No Comments / Clarifications 19.1 The system protects electronic health information created

or maintained by the certified EMR technology through the implementation of appropriate technical capabilities (based on a risk analysis per 45 CFR 164.308 (a)(1)).

☐ ☐ ☐

19.2 The system provides privacy and security components that follow national standards such as HIPAA.

☐ ☐ ☐

19.3 The system provides privacy and security components that follow Kentucky state-specific laws and regulations.

☐ ☐ ☐

19.4 The system hardware recommendations meet national security guidelines.

☐ ☐ ☐

19.5 The system has hardware recommendations for disaster recovery and backup.

☐ ☐ ☐

19.6 The system supports biosensor and RFID card technology for logon.

☐ ☐ ☐

19.7 Supports industry standard electronic signatures. ☐ ☐ ☐


19.8 The system controls access to and within the system at multiple levels (e.g. per user, per user role, per area, per section of the chart) through a consistent mechanism of identification and authentication of all users in accordance with the ‘Role Based Access Control’ (RBAC) standard.

☐ ☐ ☐

19.9 The system verifies and enforces control to all EMR components, information and functions for end users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

☐ ☐ ☐

19.10 Non Repudiation – The system limits a user’s ability to deny (repudiate) an electronic data exchange originated, received, or authorized by that user.

☐ ☐ ☐

19.11 The system secures all modes of EMR data exchange through the use of data obfuscation and destination and source authentication and other standard security methods used to ensure appropriate security and privacy considerations.

☐ ☐ ☐

19.12 The system manages attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with incoming or outgoing information.

☐ ☐ ☐

19.13 The system enforces the applicable jurisdiction’s patient privacy rules as they apply to various parts of the EMR through the implementation of standard security mechanisms.

☐ ☐ ☐

19.14 The system establishes patient/physician data element confidentiality.

☐ ☐ ☐

19.15 The system allows access to its modules regardless of location based on confidentiality and security procedures.

☐ ☐ ☐

19.16 The system incorporates audit trails of each access to specific data.

☐ ☐ ☐

19.17 The system incorporates an audit trail for all system transactions including look-ups of patient data.

☐ ☐ ☐

19.18 Provides automatic analysis of audit trails and unauthorized access attempts.

☐ ☐ ☐

19.19 The operating systems required for the product, server and related systems operated hardware are B-2 or above rated.

☐ ☐ ☐

20. Clinical Decision Support Yes Yes* No Comments / Clarifications 20.1 CDS is built using National clinical data standards

(LOINC, SNOMED, CPT, ICD9, ICD10 etc.). ☐ ☐ ☐

20.2 The system triggers alerts to providers when individual documented data indicates that critical interventions may be required.

☐ ☐ ☐

20.3 The system offers prompts to support the adherence to care plans, guidelines, and protocols at the point of information capture and is capable of tracking compliance to such care plans, guidelines, and protocols (rules).

☐ ☐ ☐

20.4 The system identifies trends that may lead to significant problems and provide prompts for consideration.

☐ ☐ ☐

20.5 The system supports the integration of patient and family preferences into clinical decision support at all appropriate opportunities.

☐ ☐ ☐


20.6 The system includes access to up to date medical research and literature databases such as MEDLINE, JAMA, UpToDate and others without logging out of the system. Also elaborate if the system allows other outside links.

☐ ☐ ☐

20.7 The system utilizes health data from all sections of the chart to provide decision support to providers.

☐ ☐ ☐

20.8 The system automatically triggers an alert upon documentation of a diagnoses or event that requires reporting to outside agencies or public health authority, including the Centers for Disease Control and Prevention (CDC), State health and mental hygiene departments, and state cancer registries

☐ ☐ ☐

20.9 The system automatically triggers an alert upon documentation of patient health data for a member of an existing medical registry or disease management program.

☐ ☐ ☐

20.10 The system’s alert/reminder functions are driven by appropriate multi-disciplinary clinical guidelines.

☐ ☐ ☐

20.11 The system incorporates preventive medicine questionnaires to be completed by clinicians and if applicable, patients, during the encounter.

☐ ☐ ☐

21. Cost Measuring / Quality Improvement / Reporting Yes Yes* No Comments / Clarifications 21.1 The system has built-in mechanism/access to other

systems to capture cost information. ☐ ☐ ☐

21.2 Are standard clinical reports built into the system for the user to query aggregate patient population numbers?

☐ ☐ ☐

21.3 The system can generate lists of patients by specific conditions to use for quality improvement.

☐ ☐ ☐

21.4 The system has the capability to report ambulatory quality measures to CMS for PQRI.

☐ ☐ ☐

21.5 The system can generate patient reminder letters for preventive services or follow-up care.

☐ ☐ ☐

21.6 The system supports disease management registries by: ☐ ☐ ☐

21.6.1 Allowing patient tracking and follow-up based on user defined diagnoses.

☐ ☐ ☐

21.6.2 Providing a longitudinal view of the patient medical history.

☐ ☐ ☐

21.6.3 Providing intuitive access to patient treatments and outcomes.

☐ ☐ ☐

21.7 What reporting engine is utilized within the software? (ex. Crystal Reports, Excel, proprietary).

☐ ☐ ☐

21.7.1 If utilizing Crystal Reports do you provide a listing of all reportable data elements?

☐ ☐ ☐

21.8 Does the end user have the ability to create custom reports?

☐ ☐ ☐

21.9 Can reports be run on-demand during the course of the day?

☐ ☐ ☐

21.10 Can reports be set up to run automatically as well as routed to a specific person with in the office?

☐ ☐ ☐

21.11 The system generates an evaluation survey (scheduled, on-demand or randomly selected) that will record patient satisfaction.

☐ ☐ ☐


21.12 The system supports real-time or retrospective trending, analysis, and reporting of clinical, operational, demographic, or other user-specified data including current and future UDS reports and reporting requirements relating to PCMH and MU.

☐ ☐ ☐

21.13 When producing aggregate level reports, the system has the capability to drill down to the provider level and the patient level

☐ ☐ ☐

21.14 The system is capable of generating lists of patients by specific conditions to use for quality improvement, reduction of disparities, research or outreach.

☐ ☐ ☐

21.15 The system produces clinician productivity/workload measures including RVU.

☐ ☐ ☐

21.16 The system has the capability to perform automatic cost analysis for courses of drug/medication treatments.

☐ ☐ ☐

21.17 The system provides the capability for authorized users to develop volume statistics reports on user determined data fields.

☐ ☐ ☐

21.18 The system has the capability to produce population-based reports or studies based on flexible, end user modifiable criteria.

☐ ☐ ☐

21.19 The system has the capability to produce point-of-care reports to identify chronic and preventive service needs for that specific patient and whether or not those needs have been met

☐ ☐ ☐

21.20 The system has the capability of producing scheduled and on demand case mix reports.

☐ ☐ ☐

21.21 The system allows customized reports or studies to be performed utilizing individual and group health data from the electronic record.

☐ ☐ ☐

21.22 The system is capable of generating clinical reports or letters for schools, camps, sports physicals, other providers, or other entities requiring such reports/letters; and is capable of maintaining such a report/letter in the patient records

☐ ☐ ☐

21.23 The system will provide support for third-party report writing products.

☐ ☐ ☐

21.24 The system supports real-time or retrospective trending, analysis, and reporting of aggregate numerator and denominator of clinical quality measures, including the CQMs of meaningful use (MU) to CMS, the States, or other regulatory entities, through means that they require (e.g., attestation, electronic submission).

☐ ☐ ☐

22. Consents, Authorizations, and Directives Yes Yes* No Comments / Clarifications 22.1 The system allows for or provides a mechanism for

patients to electronically access their health information (including lab results, problem list, medication lists, and medication allergies) within four business days of the information being available to the EP, subject to the EP’s discretion to withhold certain information.

☐ ☐ ☐

22.2 The system complies with all requirements of HIPAA, HITECH, and The Omnibus Rule, The Joint Commission requirements, requirements of Kentucky State, and other appropriate regulatory bodies for which YVFWC is subject.

☐ ☐ ☐


22.3 The system supports three-factor authentication methods including biosensor technology and/or RFID cards. The system then supports the use of these methods for expedited authentication to the system for the next X hours (where X is configurable).

☐ ☐ ☐

22.4 The system has the capability to restrict access or sharing data electronically with other systems based on consents/authorizations provided by patient or guardian subject to national or jurisdictional requirements.

☐ ☐ ☐

22.5 The system has the capability for the user to create and maintain consents and authorizations when required in the patient’s preferred language, reading level.

☐ ☐ ☐

22.6 The systems captures, maintains, and provides access to and print a copy of patient advance directives.

☐ ☐ ☐

23. Technical Underpinnings Yes Yes* No Comments / Clarifications 23.1 The system auto-populates user defined data fields with

patient demographics at the time of order or request. ☐ ☐ ☐

23.2 The system is scalable (i.e. has the capability to support additional storage requirements without major investments in hardware other than disk space)

☐ ☐ ☐

23.3 The system incorporates a consistent user interface for data entry independent of the platform.

☐ ☐ ☐

23.4 The system supports indexed document scanning. ☐ ☐ ☐

23.5 The system operates on a single 64 bit ODBC compliant database to support the EHR, PM, and EDR.

☐ ☐ ☐

23.6 The vendor will provide the optimum specifications (giving preference to VMWare virtual environments) to ensure 99.8% uptime of the system, including provisions for high-availability (100% availability goal) and disaster recovery with an RPO of 5 minutes and an RTO of 1 hour when failing over to the DR site. DR site specifications must also be included.

☐ ☐ ☐

23.7 The system supports an immediate response time (0.5 – 1.0) seconds 90% of the time.

☐ ☐ ☐

23.8 The system supports an instantaneous response time (0.1 – 0.2 seconds 80% of the time.

☐ ☐ ☐

23.9 The system supports remote system monitoring technology.

☐ ☐ ☐

23.10 The system incorporates extensive, secure telecommunications capabilities that link staff and clinicians from remote locations to the central site including the ability to connect to the system on computing resources at hospital or other locations where the user is not an administrator and cannot make changes to the device.

☐ ☐ ☐

23.11 The system supports an industry standard locking mechanism to prevent unauthorized updates.

☐ ☐ ☐

23.12 The system logs all transactions processing and archiving. ☐ ☐ ☐

23.13 The system date and time stamps all entries. ☐ ☐ ☐


23.14 The system must log all user activity (sign in/off, screens viewed, additions, deletions, modifications) transactions processed, security settings changes, and archiving of data with a date/time stamp and source identification (IP address, etc.). This information must be tracked for all access methods (onsite, remote, mobile, etc.). Audit logs are maintained for 6 years.

☐ ☐ ☐

24. Clinical IT Data Dictionary Yes Yes* No Comments / Clarifications 24.1 The system is structured to an expandable EMR through

the use of user defined fields. ☐ ☐ ☐

24.2 Provides attributes for each data element; supports all data types.

☐ ☐ ☐

24.3 Supports static/dynamic data element relationship. ☐ ☐ ☐

24.4 The system documentation includes a list of all data elements contained within the system along with their characteristics and pertinent information needed for use by ad-hoc report writing and/or for mapping to third party report writing software

☐ ☐ ☐

25. Input Mechanisms Yes Yes* No Comments / Clarifications 25.1 The system supports a full range of input technologies. ☐ ☐ ☐

25.2 Input protocol is easy/fast, intuitive input interface. ☐ ☐ ☐

25.3 The system allows easy access to existing, previously captured data for informative or copying and editing data to help reduce time spent entering information

☐ ☐ ☐

25.4 The system has the ability to allow inclusion of free text as well as the capture of discrete data in accordance with site preferences and site-specific system configuration.

☐ ☐ ☐

25.5 For a patient participating in a group visit, the system has the ability to create a note that is shared by all patients in the group.

☐ ☐ ☐

26. Ergonomic Presentation Yes Yes* No Comments / Clarifications 26.1 The system places emphasis on user friendliness and

intuitiveness. ☐ ☐ ☐

26.2 The system incorporates a consistent presentation of information across the entire system.

☐ ☐ ☐

26.3 The system incorporates visual cues. ☐ ☐ ☐

26.4 The system provides consistent formatting to aid users in finding information.

☐ ☐ ☐

26.5 The system allows users to change the layout of their open and close screens and to move sections around as necessary.

☐ ☐ ☐

27. Billing Yes Yes* No Comments / Clarifications 27.1 The system meets RBRVS/E&M documentation and

coding guidelines. ☐ ☐ ☐

27.2 The system provides a bidirectional interface a variety of information systems such as practice management, laboratory, state immunization registry, etc.

☐ ☐ ☐


27.3 The system provides support to the provider on E & M coding based on documentation from the current visit.

☐ ☐ ☐

28. Practice Specific EHR Capabilities Yes Yes* No Comments / Clarifications 1.1 The system provides full CHC Functionality and

integration within the entire PM and EHR platform ☐ ☐ ☐ Click here to enter text.

1.2 The system has the ability to easily track and report workflow during the entire patient visit process utilizing an integrated Patient Flow Tracking and Reporting module. Explain.


28.1 The system incorporates extensive, secure telecommunications capabilities that link staff and clinicians from remote locations to the data center, including:

☐ ☐ ☐

28.1.1 Secure remote EHR access via a notebook computer and full EHR client without the need for a VPN

☐ ☐ ☐

28.1.2 Mobile device access including smartphone and tablet ☐ ☐ ☐

28.2 The system includes or is integrated with a robust telehealth application features include:

☐ ☐ ☐

28.2.1 Teleconferencing ☐ ☐ ☐

28.2.2 Videoconferencing ☐ ☐ ☐

28.2.3 Other (list) ☐ ☐ ☐

28.2.4 Voice to text (electronic scribe) ☐ ☐ ☐

28.3 The EHR offers computer assisted coding, features include:

☐ ☐ ☐

28.3.1 The system recommends appropriate level of EM service.

☐ ☐ ☐

28.3.2 The system recommends the appropriate Diagnosis coding.

☐ ☐ ☐

28.4 Integrated electronic order entry with internal HIM systems, including:

☐ ☐ ☐

28.4.1 Orchard Harvest Lab Information System ☐ ☐ ☐

28.4.2 GE Centricity Universal Viewer with PACS-IWPACS ☐ ☐ ☐

28.5 Case management capabilities ☐ ☐ ☐

28.6 Immunization ordering by payor source and predictive functionality for due vaccines

☐ ☐ ☐

28.7 System content in available Spanish and the ability to add content in other languages

☐ ☐ ☐

28.8 The system contains security features to protect teen confidentiality for family planning and other types of sensitive visits

☐ ☐ ☐

28.9 The system has the capability to support independent nurse visits- triage, nursing follow up visits

☐ ☐ ☐

28.10 The system provides a direct interface for electronic medical devices including:

☐ ☐ ☐

28.10.1 Electronic blood pressure cuff ☐ ☐ ☐

28.10.2 Pulse oximeter ☐ ☐ ☐

28.10.3 EKG/ECG ☐ ☐ ☐

28.10.4 Other (list) ☐ ☐ ☐


E. PM System Capabilities (Respond with answer and a description of the proposed solution in the comments section when applicable, * denotes additional cost)

1. Appointment Scheduling Yes Yes* No Comments / Clarifications Booking Appointments 1.1 Selection of appointment slot can be done by: 1.1.1 Particular date (all providers or group of providers; e.g.

Pediatrics, Primary Care, Women’s Health, Dentistry, etc.)


1.1.2 Next available appointment on a particular of the week (add: for group of providers; e.g. Pediatrics, Primary Care, Women’s Health, etc.)


1.1.3 Next occurrence of a particular day of the week (add: for group of providers; e.g. Pediatrics, Primary Care, Women’s Health, etc.)


1.1.4 By provider panel (service type and clinic) ☐ ☐ ☐ Click here to enter text. 1.2 The user is able to select an appointment slot on a specified provider’s/clinic’s schedule by requesting any one of the following: 1.2.1 A particular date. ☐ ☐ ☐ Click here to enter text. 1.2.2 Next available appointment after a particular date. ☐ ☐ ☐ Click here to enter text. 1.2.3 Next available appointment on a particular day of the

week. ☐ ☐ ☐ Click here to enter text.

1.2.4 Next occurrence of a particular day of the week. ☐ ☐ ☐ Click here to enter text. 1.2.5 By time of day. The system will select the next time

available. ☐ ☐ ☐ Click here to enter text.

1.2.6 By type of visit (e.g., obstetric, well child care, pap smear, dental amalgam restoration, other categories established by the user


1.2.7 By provider panel ☐ ☐ ☐ Click here to enter text. 1.2.8 By case manager or primary provider ☐ ☐ ☐ Click here to enter text. 1.2.9 By clinic room or special equipment ☐ ☐ ☐ Click here to enter text. 1.3 The user is able to enter a comment when booking an

appointment. This comment is printed on all schedule module outputs, if desired by the clinic.


1.4 The user is able to enter the patient’s complaint (60 characters minimum) when scheduling an appointment.


1.5 The user is able to book one or multiple appointments into an appointment slot. The user can define the multiple/overbooking limits. The system warns the user when the expected maximum number of patients has been appointed to the slot, and allows overbooking.


1.6 The user is able to modify an appointment to change the required amount of time allotted. This change affects only the particular day’s schedule for the specified provider/clinic.


1.7 The system informs user of conflicting appointments on the schedule for a specified patient (e.g. scheduling a child for sick visit, but has a future appointment for a physical or a female patient is scheduled for breast exam and mammogram on the same day or female pediatric patient is scheduled for a Family Planning appointment on the same day that the patient is to see a pediatrician for a well-child checkup)



1.8 The system will not allow two users to place more than one patient in a single slot simultaneously.


1.9 The system allows the user to create, modify, or delete types of appointments and allocate an estimated amount of provider/clinic time needed for each appointment time (e.g. 5 min, 10 min, 15 min, 20 min, 30 min, etc.)


1.10 The system allows the user to view scheduled, canceled, and no-show appointments by scrolling backwards as well as forward through scheduled appointments


1.11 System will maintain historical schedules for a period no less than 30 days


1.12 The system will alert the scheduling staff when a patient is due for renewal of their account at the time of scheduling their appointment.


1.13 The system will automatically indicate that a patient was a no-show if the patient did not register for their appointment within a 2 hour period after their scheduled appointment.


1.14 The system will automatically indicate (by color) when a patient has not registered (or signed in) within 10 minutes after their scheduled appointment.


1.15 The system will alert the user that a patient is a DO NOT contact.


1.16 The system allows the user to create, modify, or delete types of appointments and to allocate an estimated amount of provider/clinic time needed for each appointment type.


1.17 The system allows the user to designate timeframes during which individual providers or clinic resources are not available.


1.18 The system allows the user to book an appointment or generate a reminder for an appointment one year in the future.


1.19 The system allows the user to view scheduled appointments by scrolling backwards as well as forwards through scheduled appointments.


1.20 The system assists the user in coordinating appointments with multiple providers addressing multiple problems during one visit.


1.21 The system will alert the user of patients waiting for an appointment when a slot becomes available.


Canceling Appointments 1.22 The user is able to cancel a specified appointment that

has been booked and to specify a reason for the cancellation. The system makes this appointment slot free for rescheduling immediately upon the cancellation.


1.23 The user is able to cancel all appointments scheduled for a provider in a selected timeframe and to print a report with contact information for all patients affected by the cancellation.


1.24 The user is able to generate mailing labels and reminder letters to patients for missed, cancelled, scheduled, or rescheduled appointments.


1.25 When a patient misses or cancels the first of a series of appointments, the system allows the user to view, cancel, and reschedule all appointments for the patient.



1.26 The system will keep a log of canceled appointments for historical purposes.


1.27 The user can block the schedule for canceled clinics to prevent further scheduling, but will also allow for the schedule to be printed after the schedule is blocked.


1.28 The system will alert the scheduler if the patient has missed/canceled three consecutive appointments.


1.29 The system will alert the scheduler if patient is restricted to same day appointments due to the number of cancelations.


1.30 The user is able to set parameters for the cancelation/missed appointment alerts (start and end events)


1.31 The system will allow the user to set re-set events for the cancelation/missed appointment alerts.


1.32 The system will automatically mark an appointment slot a no-show if the scheduled patient does not register within 1 hour of the appointment time.


Displaying Patient Appointments 1.33 The user is able to request a display of all future appointments for a given patient or group of patients. For each appointment, this

display shows, at a minimum, the following: 1.33.1 Provider/clinic ☐ ☐ ☐ Click here to enter text. 1.33.1.1 Appointment date ☐ ☐ ☐ Click here to enter text. 1.33.1.2 Appointment time ☐ ☐ ☐ Click here to enter text. 1.33.1.3 Appointment duration ☐ ☐ ☐ Click here to enter text. 1.33.1.4 Appointment comment (30 characters minimum) ☐ ☐ ☐ Click here to enter text. 1.33.2 Patient’s complaint ☐ ☐ ☐ Click here to enter text. 1.33.3 Type of visit ☐ ☐ ☐ Click here to enter text. 1.33.4 Special equipment or room required ☐ ☐ ☐ Click here to enter text. 1.33.5 Patient’s account balance ☐ ☐ ☐ Click here to enter text. 1.33.5.1 The system indicates that the patient has a payment

plan in place with the billing office ☐ ☐ ☐ Click here to enter text.

1.33.6 Patient’s insurance plan ☐ ☐ ☐ Click here to enter text. Displaying or Printing a Provider’s/Clinic’s Schedule 1.34 The user is able to view a provider’s/clinic’s schedule

either as a display or in hardcopy form. This output shows one day at a time, week-at-a-glance, or month-at-a-glance.


1.35 The user is able to view a schedule of clinic resource requirements on demand.


1.36 The user will be able to view all providers’ schedule at a particular clinic either as a display or in hardcopy form. This is output will show multiple providers scheduled for the day, week, and/or month.


Printing a Site’s Schedule 1.37 The user is able to print the day's schedule for a specified site, in sequence by appointment time. This output shows at least the

following data for each appointment: 1.37.1 Patient name ☐ ☐ ☐ Click here to enter text. 1.37.2 Patient Account Number ☐ ☐ ☐ Click here to enter text. 1.37.3 List of names for group visit ☐ ☐ ☐ Click here to enter text.


1.37.4 Patient chart number(s) ☐ ☐ ☐ Click here to enter text. 1.37.5 Guarantor name and relationship ☐ ☐ ☐ Click here to enter text. 1.37.6 Patient(s) phone number(s) ☐ ☐ ☐ Click here to enter text. 1.37.7 Appointment time ☐ ☐ ☐ Click here to enter text. 1.37.8 Type of visit ☐ ☐ ☐ Click here to enter text. 1.37.9 Appointment duration ☐ ☐ ☐ Click here to enter text. 1.37.10 Appointment comment ☐ ☐ ☐ Click here to enter text. 1.37.11 Patient’s complaint ☐ ☐ ☐ Click here to enter text. 1.37.12 Provider name(s) ☐ ☐ ☐ Click here to enter text. 1.37.13 Patient account status indicator or code ☐ ☐ ☐ Click here to enter text. 1.37.14 Patient account balance ☐ ☐ ☐ Click here to enter text. 1.37.15 Date of last payment ☐ ☐ ☐ Click here to enter text. 1.37.16 New patient indicator ☐ ☐ ☐ Click here to enter text. 1.37.17 “Active Insurance Plan” on Provider/Clinic Schedule ☐ ☐ ☐ Click here to enter text. 1.38 A schedule list can be sequenced by Patient Name for a

user-selected date range. ☐ ☐ ☐ Click here to enter text.

1.39 A schedule list can be sequenced by provider for a user-selected date range.


1.40 A schedule list can be produced showing new patients with scheduled appointments, walk-ins, and same day appointments for a user-selected date range.


1.41 The system will indicate whether the patient has a payment plan in place.


1.42 A schedule list can be sequenced by clinic and services (e.g. East Broadway, Women’s Health; Portland, Pediatrics; etc.)


Creating a Blank Schedule 1.43 For each provider/clinic that will be scheduled, the system

manager is able to specify and the system maintain a schedule template which outlines the typical week’s available appointment slots and specifies a visit type, duration, and expected maximum number of patients for each slot. Slots are available for same-day visits.


1.44 The system manager is able to enter and edit a list of holidays in the system and thereby remove these days from all available schedules.


1.45 The system manager is able to enter and edit a list of leave days during which a particular provider will not be available for appointments.


1.46 The system manager is able to create a “standard template” for different types of providers and specialties. E.g. Women’s Health – ARNP; Women’s Health – MD; Primary care – Internist; Primary Care – Family Practice; Primary Care – ARNP; etc.


1.47 The system manager is able to create a “temporary template” for a user designated amount of time.


1.48 The system manager is able to use a copy paste feature when opening a schedule. E.g. Copy main/temporary template and copy to specific time frame (days, week, month)



1.49 The system manager is able to instantly add and apply to current open schedules, any changes to a template due to unscheduled events (block schedule, add slots, etc.)


Encounter Forms/Labels 1.50 The system allows the user to design labels for printing

patient scheduling and registration information. ☐ ☐ ☐ Click here to enter text.

1.51 The system can produce an encounter label or “superbill”/encounter form for scheduled appointments that includes the following information:

1.51.1 Patient name ☐ ☐ ☐ Click here to enter text. 1.51.2 Patient Account Number ☐ ☐ ☐ Click here to enter text. 1.51.3 Patient address ☐ ☐ ☐ Click here to enter text. 1.51.4 Patient chart number ☐ ☐ ☐ Click here to enter text. 1.51.5 Patient date of birth ☐ ☐ ☐ Click here to enter text. 1.51.6 Patient gender ☐ ☐ ☐ Click here to enter text. 1.51.7 Patient phone number ☐ ☐ ☐ Click here to enter text. 1.51.8 Patient social security number ☐ ☐ ☐ Click here to enter text. 1.51.9 Date of service ☐ ☐ ☐ Click here to enter text. 1.51.10 Responsible party/guarantor ☐ ☐ ☐ Click here to enter text. 1.51.11 Patient account status indicator/flag/code ☐ ☐ ☐ Click here to enter text. 1.51.12 Appointment time ☐ ☐ ☐ Click here to enter text. 1.51.13 Date label printed ☐ ☐ ☐ Click here to enter text. 1.51.14 Migrant/seasonal/other status ☐ ☐ ☐ Click here to enter text. 1.51.15 Primary insurance carrier and expiration date ☐ ☐ ☐ Click here to enter text. 1.51.16 Secondary insurance carrier ☐ ☐ ☐ Click here to enter text. 1.51.17 Patient Primary Language ☐ ☐ ☐ Click here to enter text. 1.51.18 Operator ID# ☐ ☐ ☐ Click here to enter text. 1.52 The system can produce an encounter form that includes last visit information for disease specific care (see types of data listed

below): 1.52.1 Patient demographics (name, address, migrant status,

homeless status, primary language, date of birth, gender, etc.)


1.52.2 Problem list (diagnoses, dates of diagnoses) ☐ ☐ ☐ Click here to enter text. 1.52.3 Patient assessment (feet, eyes, etc.) ☐ ☐ ☐ Click here to enter text. 1.52.4 Patient test results and dates ☐ ☐ ☐ Click here to enter text. 1.52.5 Patient referrals and dates ☐ ☐ ☐ Click here to enter text. 1.52.6 Objective findings (weight, BP, etc.) ☐ ☐ ☐ Click here to enter text. 1.52.7 Patient medications ☐ ☐ ☐ Click here to enter text. 1.52.8 Patient health profile ☐ ☐ ☐ Click here to enter text. 1.52.9 Patient behavioral and lifestyle issues ☐ ☐ ☐ Click here to enter text. 1.52.10 Patient self-management goals ☐ ☐ ☐ Click here to enter text. 1.52.11 SOAP notes ☐ ☐ ☐ Click here to enter text. 1.52.12 Date of visit ☐ ☐ ☐ Click here to enter text. 1.52.13 Responsible party/guarantor ☐ ☐ ☐ Click here to enter text. 1.52.14 Migrant/seasonal/other status ☐ ☐ ☐ Click here to enter text.


1.52.15 Provider(s) name(s) ☐ ☐ ☐ Click here to enter text. 1.52.16 Primary insurance carrier and expiration date ☐ ☐ ☐ Click here to enter text. 1.52.17 Tickler information that is appropriate for the patient’s

age and medical history ☐ ☐ ☐ Click here to enter text.

1.53 The system can print order labels/requisitions in the laboratory for scheduled lab tests.


1.54 The system can generate labels for off-site reference laboratory tests including the following patient-related data: 1.54.1 Medicare number ☐ ☐ ☐ Click here to enter text. 1.54.2 Medicaid number ☐ ☐ ☐ Click here to enter text. 1.54.3 Insurance plan and number ☐ ☐ ☐ Click here to enter text. 1.54.4 Social security number ☐ ☐ ☐ Click here to enter text. 1.54.5 Patient name ☐ ☐ ☐ Click here to enter text. 1.54.6 Patient address ☐ ☐ ☐ Click here to enter text. 1.54.7 Diagnosis code (ICD9) ☐ ☐ ☐ Click here to enter text. 1.54.8 Patient gender ☐ ☐ ☐ Click here to enter text. 1.54.9 Patient date of birth ☐ ☐ ☐ Click here to enter text. 1.54.10 Chart number ☐ ☐ ☐ Click here to enter text. 1.54.11 Appointment date ☐ ☐ ☐ Click here to enter text. 1.54.12 Provider number ☐ ☐ ☐ Click here to enter text. 1.54.13 Clinic site ☐ ☐ ☐ Click here to enter text. 1.54.14 Calculated Sliding Fee Level ☐ ☐ ☐ Click here to enter text. 1.55 The system prints laser jet labels. ☐ ☐ ☐ Click here to enter text. 1.56 The system will allow the user to print labels on demand

or at the time of registration. ☐ ☐ ☐ Click here to enter text.

1.57 The system will allow the user to select the number of labels printed each time.


1.58 The system allows a user to run a list of patients who did not register for their appointment.


Interfaces to Other Modules 1.59 The user is able to partially register a patient or change

existing registration information for a patient during the process of booking an appointment from the scheduling screen(s). For a new patient registration, the system allows the assignment of a unique temporary record number. Remove after 6 months inactive.


1.60 The list of patients on the pull list for each site is available to other modules of the system for the printing of selected reports, e.g., patient medical record summaries, for these patients.


1.61 The system will allow the ability to force fields at time of registration, but allowing a temp account to be created without forcing the field.


1.62 The system registers attendance for the scheduled appointment when the patient’s visit to the clinic is entered, including a date and time stamp of the arrival.


1.63 The system can produce follow-up laser generated address labels for user-selected patients.



1.64 The system can produce a report of patients who missed appointments (a “no show” report) in a user-selected date/time period.


1.65 1The system maintains a history of patients that miss and cancel appointments and can produce a report of contact information for these patients including reasons for cancellations.


1.66 The system can generate letters to patients reminding them of their scheduled appointments.


1.67 The system can print out a charge ticket (superbill) before the appointment or when the patient arrives and checks in.


1.68 The system allows the user to create or edit multiple reminder and/or follow-up letters generated by the scheduling module so that Spanish or English language letters can be produced for selected patients.


1.69 Language of the letter will be determined by the Primary Language field selected.


1.70 The system produces a report showing route slips that were printed but had no charges posted.


2. Registration Yes Yes* No Comments / Clarifications Registering New Patients or Changing Existing Accounts 2.1 The system maintains a unique patient identification

number for each patient. ☐ ☐ ☐ Click here to enter text.

2.2 The system is able to automatically assign patient identification numbers in a user-specified format and range, or allows the user to assign a patient identification number to a patient.


2.3 The system accommodates at least one historical medical record/chart number for tracking back to legacy systems.


2.4 The user can record the patient’s medical record number at registration.


2.5 The system maintains a master directory or index of patient names.


2.6 The user is able to record the maiden surname of the patient to help in patient identification and record correlation.


2.7 The user is able to register individuals by family. ☐ ☐ ☐ Click here to enter text. 2.8 Patients associated with a family or guarantor can have

surnames and addresses that differ from the head of household or guarantor.


2.9 The system is able to differentiate between patients and guarantors (patients or non-patients who agree to pay the patient’s bill if no one else does).


2.10 The system allows a patient to have more than one guarantor without requiring the patient to have more than one account.


2.11 The system supports recording both a permanent and local address for the patient and retains any old address and date of change to new address.


2.11.1 If a change to an address is made a way to quickly identify other family member’s accounts and update their information at the same time is available.



2.12 At registration, the user is able to categorize the patient as homeless, migrant, seasonal, or other for Federal reporting.


2.13 At registration, the system will establish a patient account status indicator or code that reflects the payment status of the patient’s account


2.13.1 The account status indicator or code will change automatically as the account status changes.


2.13.2 Users will have the ability to change this account status indicator or code.


2.13.3 An account status indicator value or code will be reserved to indicate that no bill should be sent out.


2.13.4 Users will have the ability to see past the status code. ☐ ☐ ☐ Click here to enter text. 2.14 The user is able to record information for identifying and

locating the patient’s employer. ☐ ☐ ☐ Click here to enter text.

2.14.1 The user can print patient registration information by employer.


2.15 The registration module records geographical information associated with the patient and guarantor’s residence (e.g., neighborhood or census track).


2.16 The system provides a free text comment field associated with the patient’s registration record.


2.17 For name and address data items that are maintained, the system allows the user to specify “same as patient,” or “same as guarantor” or automatically copies previously entered data to reduce the amount of duplicate data entry.


2.18 Each family can have an unlimited number of insurance policies covering members of the family. Users should have the ability to flag Inactive Insurance Plans to avoid errors.


2.19 The user is able to specify which members in the family are covered by each insurance policy.


2.20 Subscribers (e.g., employers) may be different than the patient or the guarantor; if so, appropriate demographic data can be collected on the subscribers.


2.21 The system records patient’s ethnicity using values in a user-defined table.


2.22 The system allows the user to record chronic diagnoses for the patient and the associated dates of the chronic diagnoses.


2.23 The user can assign the patient to a sliding fee scale and record an associated date for re-certifying the patient’s sliding fee scale eligibility.


2.23.1 Users have the ability to maintain previous income information and dates on previous income information.


2.24 The system provides at least two free text fields that can be used to categorize the patient for reporting. These fields are accessible via the report writing tool.


2.25 The system automatically assigns the city and state based on the zip code.


2.26 The user is able to record name changes to help in the identification and record correlation.



2.27 The system is able to retain the previous name for historical and identification purposes. (e.g. Child last name is Smith when the child became a patient, 2 years later, step-dad adopts child and the child has a new name. The new name is documented, but the old name can be kept in a different field).


2.28 The system will allow the user to enter comments, such as, (adopted 2012) or (divorced 2018), etc.


2.29 The user is able to apply the sliding fee for all family members.


2.30 The system will support two addresses to represent physical address and mailing address.


2.31 The system has an alert that will pop up asking the user to confirm the change in the status.


2.32 The system will allow user to view past notes for historical purposes. (Unlimited amount of free text?)


2.33 The system will allow the user to record subscriber demographics including:


2.33.1 Name ☐ ☐ ☐ Click here to enter text. 2.33.2 SS# ☐ ☐ ☐ Click here to enter text. 2.33.3 DOB ☐ ☐ ☐ Click here to enter text. 2.33.4 Mailing address ☐ ☐ ☐ Click here to enter text. 2.34 The system allows the user to record race codes separate

from ethnicity using user-defined values ☐ ☐ ☐ Click here to enter text.

2.35 The system allows the user to enter free text for Race and Ethnicity field up to 15 characters.


2.36 The system allows the user to record primary language using user predefined values.


2.37 The system allows the user to record free text for Primary Language up to 15 characters.


2.38 The system will automatically assign an account renewal date (CHC) of 1 year when the patient’s account is updated.


2.39 The user is able to change the account renewal date. ☐ ☐ ☐ Click here to enter text. 2.40 The user can designate the patient or the patient visit type

as a DO NOT CONTACT. ☐ ☐ ☐ Click here to enter text.

2.41 The system has an integrated camera system that will allow a webcam photo to be taken and converted to a jpeg file and attached to the patients PMS account.


2.42 The system will allow the user to verify insurance eligibility for Commercial, Kentucky State Medicaid, Passport, SCHIP, and Medicare programs.


2.42.1 The insurance eligibility check will allow verification against a predefined list of regional plans without the specific coverage preexisting in the patient account.


2.43 The system allows for electronic check transfer, credit card processing, debit card processing, and cash receipts.


2.44 The system allows the user to print two receipts with a signature line for the electronic check transfer and the credit card.


2.45 The system has an integrated document scanning system that allows the user to scan photo id, insurance cards, documents of various sizes up to 8 ½ x 11.



2.46 The system can utilize desktop scanning hardware. ☐ ☐ ☐ Click here to enter text. 2.47 The system allows the user to create temporary accounts

allowing the user to enter a user-predefined minimum demographic information to establish an appointment.


2.48 The user is able to convert the temporary account to a permanent account upon registration.


2.49 The system is able to support “wet signatures” for consents, attestations, and electronic funds transfers/credit card payments.


2.50 The system has the ability to set Required fields in the Patient Registration Process.


2.51 The system has the ability to have “help” windows on individual fields to explain the available options and user define notes for help.


2.52 The system is capable of printing a customizable patient ID cards with user-predefined patient demographic information.


2.53 The system is capable of producing alerts (to billing staff) if changes are made on to an account that effect pending charges. (i.e.. income class was changed and is retro 30 days and the Billing staff need to make changes to the prior charges).


2.54 The system has the ability to require forms to be completed based on the Claim Center. (i.e. A patient has a work comp and it alerts the registration clerk we need additional information).


2.55 What is the length of the patient name field(s)? Click here to enter text. 2.56 What options are available to identify patients in the

system? Click here to enter text.

2.57 What safeguards are in place to alert the user if the patient has a possible duplicate account?


2.58 Explain what options are available to locate and merge duplicate accounts?


2.59 Explain how front desk receptionists would handle new insurance plans not already loaded in the system.


2.60 Income verification: 2.60.1 The system retains prior income/slide/class information

to allow the billing staff to properly process prior claims/charges.


2.60.2 The system retains income verification of other family members.


2.61 If income is updated, how can any other family members be quickly identified and updated at the same time?


Updating Data on Existing Patients 2.62 The user is able to change any user entered data field at

any time. Certain data fields can have security protection restricting access to specific users.


2.63 An on-line data edit function is available. ☐ ☐ ☐ Click here to enter text. 2.64 For data items selected by the clinic, the system is able to

maintain an audit trail record of the changes made to the data items over time.



2.65 The system allows the user to change a patient’s name or patient registration number without having to re-register the patient.


2.66 If a patient’s registration record is in use, the system identifies which user/workstation has the record locked.


2.67 The system provides on-line (24x7) access to Medicaid eligibility information. The system will provide the option to update the patient’s records based on the eligibility information.


2.68 The system maintains an inactive/active status on each patient that can be used for scheduling reminders and reporting.


2.69 The system will allow the user to replace jpeg photos of patient.


2.70 The system will allow the user to verify insurance eligibility for commercial, Kentucky State Medicaid, Passport, Kchip, and Medicare programs.


Displaying and Printing Registration Data 2.71 The user is able to display the following types of

registration data: ☐ ☐ ☐ Click here to enter text.

2.71.1 Family rosters ☐ ☐ ☐ Click here to enter text. 2.71.2 All demographic data for each registered family

member ☐ ☐ ☐ Click here to enter text.

2.71.3 A patient’s socio-economic, demographic, and identification number data


2.71.4 Guarantor’s name and patient account number ☐ ☐ ☐ Click here to enter text. 2.71.5 Insurance policy and coverage data on each patient ☐ ☐ ☐ Click here to enter text. 2.71.6 Patient employer information ☐ ☐ ☐ Click here to enter text. 2.71.7 The primary site at which the patient receives care ☐ ☐ ☐ Click here to enter text. 2.72 The system displays comments or flags indicating special

conditions associated with the patient or his/her account. ☐ ☐ ☐ Click here to enter text.

2.73 The system displays account status information (from the Accounts Receivable module) via an account status indicator or code on the patient registration screens.


2.74 The system allows the user to select subsets of patient information (registration and/or clinical) (e.g., patient age range and gender, patients or guarantors in a geographical area, guarantors of patients in selected age and gender group) to produce mail merge files, print form letters, or generate reports.


Global patient identification features are incorporated throughout the modules of the system including the following: 2.75 The user is able to uniquely identify a patient by a current

or former medical record number. ☐ ☐ ☐ Click here to enter text.

2.76 An alternative method of identifying a patient is entry of the patient’s full or partial name.


2.77 When using the name identifier, the user is able to enter the patient’s gender, social security number, and/or date of birth to limit the number of matches found in the system.


2.78 The full and partial name lookup routines searches for exact matches to the entered spelling and also for phonetic comparables of the entered name or partial name (e.g., soundex).



2.79 When age or date of birth is entered, the system locates all patients who acceptably match the name (and optionally gender) specified, and whose age is within a specified number of years of the data entered.


2.80 A patient can be identified by his or her prior name (e.g., maiden name) or alternate name (e.g., alias) previously entered into the system.


2.81 All patients associated with a given family unit or guarantor can be displayed under the head of household or guarantor.


2.82 The system allows the user to interrupt an incomplete patient registration process, switch to another module such as scheduling or accounts receivable, perform activities in the active module, and return to the registration module at the point in the registration process when interrupted.


2.83 The system allows the user to print the registration screen via a screen dump to a local printer.


2.84 The registration module allows the user to register multiple patients without returning to select a registration menu option between each patient.


2.85 The registration module allows the user to specify whether updated information (e.g., address changes, new guarantor) is applied to all or individual patients under the guarantor or family account.


2.86 The registration module records the initials of the data entry operator and the date of changes made to patient registration information.


2.87 The system will retain registration initials of the data entry operator, date, and time of changes for a user-defined timeline.


3. Medical and Dental Data Yes Yes* No Comments / Clarifications 3.1 Input Processes 3.1.1 Formatted encounter forms are used for capturing

medical and dental data that occurs during an encounter.


3.1.2 There are no restrictions on the number of different encounter forms that can be used.


3.1.3 It is possible to alter the layout of small portions of an encounter form without having to reprogram the system.


3.1.4 The user can design/define data entry screens that are specific to a health care provider or clinical function.


3.1.5 It is possible to indicate that a data value previously entered was in error.


3.1.6 The system prints a copy of the encounter form(s). ☐ ☐ ☐ Click here to enter text. 3.1.7 The system supports recording specific chronic care

diagnosis codes that can be used to establish evidence-based care guidelines for patient scheduling and visits (e.g., diabetes, asthma, etc.). These codes can be used to specify the encounter form to be used with this patient.



3.1.8 The system can produce an encounter form that includes past data on the patient (e.g., vitals, observations, special education sessions, co-morbidities, lab results, referrals, etc.).


3.1.9 The system supports data entry by optical scanner. ☐ ☐ ☐ Click here to enter text. 3.1.10 The system can display/print care ticklers specific to

the patient’s chronic disease, age, gender, etc. ☐ ☐ ☐ Click here to enter text.

3.2 There is a capability for an Electronic Health Record, to store the following information: 3.2.1 Physical examination and assessment data are stored

by body system, e.g., eyes, ears, head, etc. Allowable entries for each body system must be, at a minimum, WNL (within normal limits), problem, and problem under management.


3.2.2 Vital sign data, i.e., height, weight, blood pressure, and date/time are stored.


3.2.3 The dates, and where necessary, the series of each immunization are stored.


3.2.4 Coded description of intervention activities, for each relevant data type (e.g., teach, demonstrate, refer, etc.) are stored.


3.2.5 Symptom/diagnostic terms are stored. It is possible to amplify the meaning of diagnostic terms by appending a status field to the term. Status field entries are to include, at a minimum, acute and chronic.


3.2.6 Additional status fields, such as history of, status post, and rule out, are available.


3.2.7 Procedure codes are stored. ☐ ☐ ☐ Click here to enter text. 3.2.8 Laboratory test data are stored. The data indicates

tests ordered, results, and the associated dates. ☐ ☐ ☐ Click here to enter text.

3.2.9 Medication data are stored and sorted by date prescribed. The data indicate when the medication was ordered and for what reason.


3.2.10 Referral data are stored. The data indicate to whom the referral was made, the date of the referral, and whether or not the referral visit occurred.


3.2.11 Any other medical or non-medical therapy not cited above are stored.


3.2.12 Allergies/sensitivities data are stored (including medication allergies).


3.2.13 Unlimited amounts of narrative data can be stored for each physical assessment, diagnostic procedure, and laboratory test.


3.2.14 Chronic and acute problem lists are stored. ☐ ☐ ☐ Click here to enter text. 3.2.15 There are no restrictions on the number of encounters

that can be stored in a patient’s automated medical record.


3.2.16 There are no restrictions on the number of terms that can be stored on each visit.


3.2.17 There are no restrictions on the number of terms that can be stored in the patient’s automated medical or dental record.


3.2.18 Subjective-Objective-Assessment-Plan (SOAP) notes and progress note formats are supported.



3.2.19 The system includes a health maintenance feature that compares a patient’s history with user-defined and/or industry standard treatment protocols/guidelines and identifies areas needing attention to satisfy protocols.


3.2.20 Risk profiles (e.g., tobacco use, alcohol use, illicit drug use) are stored.


3.3 Outputs 3.3.1 A report that shows all of the data that was captured on

one encounter is available. ☐ ☐ ☐ Click here to enter text.

3.3.2 A list of all encounters that have occurred on the patient is available. The following data items appear on each entry on the list: date of encounter, type of visit, provider, and location.


3.3.3 The system is able to graph a patient’s weight, blood pressure, or laboratory test result, or other numeric material data value over time.


3.3.4 It is possible to display as well as print medical and dental reports.


3.3.5 It is possible to create a list of patients for whom medical or dental reports are desired, and to have the system generate the medical or dental reports beginning at a time of day specified by the user.


3.3.6 The header section of medical or dental reports contain the patient’s name, address, home and work telephone numbers, age, gender, sliding scale payment category, insurance coverage, and “home” clinic (the clinic where the patient receives most of his or her care).


3.3.7 A summarized medical report is available. It consists of the following sections: 3.3.7.1 Header ☐ ☐ ☐ Click here to enter text. 3.3.7.2 Acute problem list ☐ ☐ ☐ Click here to enter text. 3.3.7.3 Chronic problem list ☐ ☐ ☐ Click here to enter text. 3.3.7.4 Allergies/sensitivities ☐ ☐ ☐ Click here to enter text. 3.3.7.5 Immunization summary ☐ ☐ ☐ Click here to enter text. 3.3.7.6 Physical assessment results ☐ ☐ ☐ Click here to enter text. 3.3.7.7 Referral history ☐ ☐ ☐ Click here to enter text. 3.3.7.8 Medication history ☐ ☐ ☐ Click here to enter text. 3.3.7.9 Procedure history ☐ ☐ ☐ Click here to enter text. 3.3.7.10 Laboratory test order history ☐ ☐ ☐ Click here to enter text. 3.3.7.11 Laboratory test results history ☐ ☐ ☐ Click here to enter text. 3.3.7.12 Other therapies history ☐ ☐ ☐ Click here to enter text. 3.3.8 A summarized medical record report is available in

Subjective, Objective, Assessment, and Plan (SOAP) format.


3.3.9 Flowsheets that show the changes of selected data items from encounter to encounter shall be available for all patients.


3.3.10 The system allows the user to create new flowsheet routines; these routines are stored in a library and invoked under user control.



3.3.11 The system allows the user to select medical records for review based on combinations of diagnosis codes and patient demographic information.


3.3.12 The system produces the forms necessary to submit samples and test orders to commercial reference laboratories.


3.3.13 The system is capable of producing an historical perspective report to be given to the patient. At a minimum, it will include past lab results (graphs), vitals, referrals, education, goals, medications (dates and doses).


3.4 Interface to Other Modules 3.4.1 Patient identification, demographic and financial data

appearing in the header of medical reports is retrieved from data stored by the Patient Registration process.


3.4.2 The medical/dental data module can be linked to external reference databases supporting diagnosis, protocols, drug interactions, physician desk reference information, others.


3.4.3 This medical/dental data module supports industry standard linkages (e.g., Health Level 7) and data integration with off-site laboratory systems.


3.4.4 This module supports electronic data interchange with hospitals, other physician offices, and provider residences.


3.4.5 The data in this module is accessible by third party report writer software.


3.5 Medical Records Tracking 3.5.1 The system supports tracking of patient charts using

bar code technology. ☐ ☐ ☐ Click here to enter text.

3.5.2 The system produces labels for patient charts, medications, lab slips, and supplies.


3.5.3 The system supports quality assurance audits against clinic-established protocols.


3.5.4 The system generates laser jet labels. ☐ ☐ ☐ Click here to enter text. 3.5.5 The system allows the user to control/manage forms by

barcode ☐ ☐ ☐ Click here to enter text.

3.6 The system suggests patient education materials based on the patient’s diagnosis.


3.7 Disease Management 3.7.1 The system provides the ability to create user

developed treatment protocols and to generate disease-specific guidance (e.g., flow charts) that integrates patient-specific data.


3.7.2 The system generates prompts for intervention based on the user developed treatment protocols (e.g., appropriate lab tests at indicated intervals, referrals for screening, etc.).


3.7.3 The system flags outliers where case management is inconsistent with the indicated disease management protocols.


3.7.4 The system supports disease management tracking keyed to patient registries to allow automatic tracking of care specific performance measures.



3.7.5 The system provides tools for defining and developing disease-specific patient registries for tracking disease management information (e.g., clinical outcomes, complications, health care utilization, patient satisfaction, patient self-management, adherence to guidelines, percent of patients using self-monitoring, other data elements specific to the disease being managed).


3.7.6 The system has the capability to collate, correlate, and report individual and aggregate clinical data over time.


3.7.7 The system supports time sensitive, system produced mailers or letters to alert patients of their need for follow-up care.


3.7.8 The system tracks over-the-counter and prescribed patient medication and supplements including the name of the medication, dosage, route, initial order, and renewal dates.


3.7.9 The system maintains patients’ medication allergies and displays this information as appropriate.


3.7.10 The system supports creation of a “visit day form”/encounter form that:


3.7.10.1 Can be customized to specific evidence-based care guidelines


3.7.10.2 Includes last visit information (test results, provider observations, referral plans and results, lifestyles and self-management data)


3.7.10.3 Has space to collect current information on the same categories, demographics, and SOAP notes


3.7.10.4 Fits on one page and replaces other documents in the patient chart


3.7.11 The system allows adding and changing chronic care diagnosis codes.


3.7.12 The system supports a comprehensive user-defined patient follow-up function generating letters to physicians, clinics, hospitals, etc., for the purpose of collecting disease-specific patient data from external sources.


3.8 Prenatal Tracking and Reporting 3.8.1 The Practice Management System is capable of

tracking and reporting prenatal patient data. ☐ ☐ ☐ Click here to enter text.

3.8.2 Prenatal data collected and tracked: 3.8.2.1 Did patient began care at the Health Center ☐ ☐ ☐ Click here to enter text. 3.8.2.2 Beginning trimester of care ☐ ☐ ☐ Click here to enter text. 3.8.2.3 Tracking status code (user defined) ☐ ☐ ☐ Click here to enter text. 3.8.2.4 Report year ☐ ☐ ☐ Click here to enter text. 3.8.2.5 Estimated date of confinement ☐ ☐ ☐ Click here to enter text. 3.8.2.6 Patient care transferred out ☐ ☐ ☐ Click here to enter text. 3.8.2.7 Date of last prenatal visit ☐ ☐ ☐ Click here to enter text. 3.8.2.8 Date of return visit ☐ ☐ ☐ Click here to enter text. 3.8.2.9 Patient enrolled in WIC (Prenatal) ☐ ☐ ☐ Click here to enter text. 3.8.2.10 Delivery Date or ☐ ☐ ☐ Click here to enter text.


3.8.2.11 Date ended prenatal care ☐ ☐ ☐ Click here to enter text. 3.8.2.12 PP visit within 8 weeks of delivery ☐ ☐ ☐ Click here to enter text. 3.8.2.13 Comments ☐ ☐ ☐ Click here to enter text. 3.8.2.14 Location (Site of care) ☐ ☐ ☐ Click here to enter text. 3.8.2.15 Infant name ☐ ☐ ☐ Click here to enter text. 3.8.2.16 Infant birth weight in grams ☐ ☐ ☐ Click here to enter text. 3.8.2.17 Infant sex/gender ☐ ☐ ☐ Click here to enter text. 3.8.2.18 Infant enrolled in WIC ☐ ☐ ☐ Click here to enter text. 3.8.2.19 Newborn visit date at FHC ☐ ☐ ☐ Click here to enter text. 3.8.2.20 Newborn visit within for weeks ☐ ☐ ☐ Click here to enter text. 3.8.2.21 Must be able to repeat infant data to accommodate

multiple births ☐ ☐ ☐ Click here to enter text.

4. Patient Follow-Up Monitoring/Tracking Yes Yes* No Comments / Clarifications 4.1 Input Process 4.1.1 The user can enter a follow-up date for the patient

when entering the patient’s encounter data. ☐ ☐ ☐ Click here to enter text.

4.1.2 The user can enter the date of the next compliance protocol issue for any number of wellness and chronic care guidelines when entering patient encounter data.


4.1.3 The system calculates the date of the next compliance protocol issue for any number of wellness and chronic care guidelines when entering patient encounter data.


4.1.4 The system provides case management features allowing the user to define and track multiple patient registries.


4.1.5 The system allows the user to define, track, and report on any data element or combination of data elements associated with patients. This tracking can be over an arbitrary length of time and can be plotted over time.


4.1.6 The system allows the user to create data files that supplement patient registration and encounter information and to link these files to the patient’s registration record for retrieval and reporting.


4.1.7 All patients associated with a specific chronic care condition can be listed and sub-grouped by other identifiers (e.g., last visit date, last lab test results and dates, etc.).


4.1.8 The system calculates the date of the next follow-up action based on the date of the last information on file (user-defined).


4.2 Output Reports 4.2.1 Unless otherwise specified, all output reports list

patients by home clinic (the clinic where the patient usually receives care).


4.2.2 Patients are identified by name and identification number on the reports.


4.2.3 The system can produce mailing labels for a user-selected group of patients.



4.2.4 The system can produce groupings of patients on any data parameter (and on collections of data parameters) using Boolean logic. Selection is available using the following operators:


4.2.4.1 Equals, less than, greater than, greater than or equal, less than or equal, not equal


4.2.4.2 Within a range ☐ ☐ ☐ Click here to enter text. 4.2.4.3 First, last occurrence ☐ ☐ ☐ Click here to enter text. 4.2.4.4 Nth occurrence ☐ ☐ ☐ Click here to enter text. 4.2.4.5 NOT, AND, OR, with nesting to five (5) levels ☐ ☐ ☐ Click here to enter text. 4.2.5 On a periodic basis, the system generates a Missed

Referral report of all patients who had been referred to another section of the clinic and (n) days after the referred date had not yet been seen by the other section. The user can set the value of “n.”


4.2.6 The system generates the Missed Referral report per the specifications cited above, but lists the patients by provider or section to which the patient was referred.


4.2.7 Under user control, the system generates a report of all patients who are delinquent in any evidence-based care guidelines or standardized wellness procedures (e.g., immunizations, HbA1c tests for diabetics, PAP smears, mammograms, and well-baby checks). The needed procedures are listed on the report.


4.2.8 Under user control, the system generates reminder letters for all patients who are delinquent in their scheduled treatments, tests, or consultations (e.g., immunizations, HbA1c test, etc.).


4.2.9 The user may edit the reminder letter. ☐ ☐ ☐ Click here to enter text. 4.2.10 If the Scheduling module is not used, on a periodic

basis the system generates a Missed Appointment report of all patients who have not returned for a follow-up visit within “n” days or weeks or the visit date. The value of “n” can be set by the user.


4.2.11 Under user control, the system generates a report of all patients who have abnormal laboratory results.


4.2.12 Under user control, the system generates a report on all patients who have been identified as having a high risk medical condition.


4.2.13 The system produces a “report” for the patient to bring them into their own care and to let them know how they are doing. The report includes pertinent test results, referrals, self-management goals, educational sessions, etc.


5. Billing Yes Yes* No Comments / Clarifications 5.1 Standard Third-Party Billing 5.1.1 The system automatically populates the correct values

in the claim form boxes (HCFA 1500) or loops (electronic) according to federal, state, and private payor guidelines, as well as carrier specific guidelines when necessary. i.e. NPI, Taxonomy.



5.1.2 The Health Insurance Claim Form (AMA Form 1500) can be printed for bills sent to commercial insurance companies.


5.1.3 Medicare claims can be submitted and processed electronically (electronic submission and electronic remittance mandatory).


5.1.4 The standard American Dental Association (ADA) can be submitted processed electronically (electronic submission and electronic remittance mandatory).


5.1.5 State Medicaid claims can be submitted and processed electronically (electronic submission and electronic remittance mandatory).


5.1.6 Bills can be generated and transmitted at any time during the month.


5.1.7 The system can automatically generate third-party bills for all visits identified as billable to third-party carriers that have not yet been billed to these carriers.


5.1.8 The system can generate and “Air Bill” (fulfills the requirement of a claim to be “billed” before it can have a payment applied. Also necessary to generate bill date for claim where plans are submitted via spreadsheets to certain payors, i.e. State Family Planning)


5.1.9 The system maintains and can print an audit trail of all transactions associated with a patient’s bill.


5.1.10 The history of patient bills satisfying user-specified selection criteria can be purged at the user’s option.


5.1.11 The system shall have the capability to transmit claims electronically to all major carriers including, but not limited to, Medicaid and Medicare carriers.


5.1.12 The system supports automatic translation of entered diagnosis and procedure codes (e.g., revenue codes for Medare, ADA codes for dental claims) to alternative state and third-party payer-mandated coding schemes for reimbursement claim forms.


5.1.13 The system allows for refiling unpaid claims to third-party carriers based on a carrier code, date of service range, and provider.


5.1.14 The system provides the ability to record the payment schedule by procedure code by insurance plan.


5.1.15 NDC codes can be submitted on paper and electronic claims according to industry standard guidelines as well as carrier specific guidelines.


5.1.15.1 Explain how they are managed by DOS, when stock is changed from one NDC to another for the same procedure code.


5.2 CPT and ICD Management 5.2.1 The system has the ability to accommodate both ICD-9

and ICD-10 code sets, both code sets are mapped to plans as required.


5.2.2 Explain the process to update and maintain updates to CPT Codes and ICD Codes. Also explain how the system handles codes that have changes or are no longer valid.


5.2.3 The system has the ability to place flags on ICD Codes that require 4th, 5th, 6th or 7th digits.



5.2.4 The system has the ability to place Codes non-covered by various Insurance Plans. The ability to stop the use of invalid codes being posted.


5.2.5 The system has the ability to flag CPT codes that require documentation for use.


5.2.6 The system has the ability to have (,) comma extension on CPT Codes to track special programs, events, fees, etc.


5.2.7 CPT maintenance includes note field, alternate codes, start date, end date and alerts


5.2.8 Diagnosis maintenance includes note field, start date, end date and alerts


5.2.9 Alerts and Rules can be set by specific carriers, specific insurance plans, uninsured (no insurance), all carriers, all insurance plans, all charges, etc. as they relate to CPTs and Diagnosis codes.


5.2.10 The system has the ability to load Macro CPT sets to facilitate the posting of multiple CPTs that are posted together routinely as a set.


5.2.11 CPT maintenance includes option for Alternate Codes to be assigned. I.e. CPT for commercial payer converts to HCPCS code for Medicare.


5.2.12 Ability to submit 12 ICD codes per claim either via paper or electronic submission.


5.2.13 Procedure codes have ability to be assigned to Carrier Groups/Classes.


5.3 Payments Postings and Adjustments 5.3.1 The system has the ability to process Electronic

Remittance for Medicare, Medicaid, and Third Party payors and break out the process by user. (Be very specific in what is necessary in the maintenance files to accomplish ERA).


5.3.1.1 The system has the ability to track and report in detail claims that are paid less than a dollar value from the payer approved allowance.


5.3.1.2 The system has the ability to “require” balancing to close a batch.


5.3.1.3 Explain how the system tracks and handles Insurance Re-coupments from the Carrier.


5.3.1.4 Explain how the system handles unapplied/overpaid money. Does the system have a tracking on funds placed into the accounts unapplied status? Explain the ability to report on the unapplied/overpaid funds.


5.3.1.5 Explain how the system handles credit line on an individual basis.


5.3.1.6 What safeguards are in place to prevent misapplied payments and the ability to locate misapplied payments?


5.3.1.7 The system has the ability to track credit card payments separate from checks and cash?


5.3.1.8 Explain how the system handles “refund” transactions.


5.3.1.9 Explain how the system handles returned checks. ☐ ☐ ☐ Click here to enter text.


5.3.1.10 Explain how co-payments taken prior to the visit are posted and then reconciled with the appropriate visit once the charge is posted.


5.3.1.11 The system has the ability to track denial/rejected claims by reason for the denial.


5.3.1.12 The system has the ability to have unlimited number of adjustment types. The ability to track adjustments/write offs by user.


5.3.2 System has ability to post payment, contractual adjustment and withhold or separate adjustment in a single transaction with two separate adjustment codes for contractual and withhold. i.e. Medicare Part B and State Family Planning which will always be nonERA.


5.4 Insurance Carrier Maintenance 5.4.1 The system has the ability to Inactivate an invalid

Claims Center. Inactive is the ability to track historical transactions and continue to work any unpaid claims while not allowing registration to add an invalid Claim Centers to the patient’s account.


5.4.2 The system has the ability to place comments in each Claims Center to designate user defined notes and comments specific to only that Claim Center.


5.4.3 The system has the ability to flag a Provider that is not participating / credentialed with a particular Claims Center and hold the claim for all providers or a specific provider until the claim/s can be released for filing.


5.4.4 System has the ability to place Start Date and End Date on each Insurance Plan.


5.4.5 Insurance Plans can have ability to be assigned to Classes / Groups.


5.5 Provider File Maintenance 5.5.1 The doctor’s file must be able to hold multiple Medicare

ID numbers and tie the ID numbers to the date of service and location of the service.


5.5.2 The system has the ability to track a Locums start and end dates within the system.


5.5.3 The system has the ability to track which Carriers a provider is credentialed/contracted. The ability to pull reports to manage this process.


5.5.4 The system has the ability to assign “supervising” Providers.


5.5.5 The system has the ability to place State Date and End Date on each Provider File.


5.5.6 The system has the ability to assign a Participation Effective/State Date and Termination/End Date to each insurance Carrier and/or plan.


5.5.7 The system has the ability to allow the Performing Provider or the Supervising Provider to receive credit for the services performed.


5.5.8 System has the ability to allow the use of the supervising provider at the time of charge posting in the following options: always, optional or never.


5.5.9 Provider File Maintenance includes an assigned Position, Class and Department.



5.5.10 Practice can initiate the setup of a new provider file as well as modify provider files.


5.6 Working Unpaid Claims 5.6.1 The system has the ability to design when a claim is

deemed late by Carrier/Insurance Plan and show up on a user’s task list to work.


5.6.2 The system has the ability to track and pull reports on clean claims not paid in 30 days.


5.6.3 The system has the ability to assign a Claim Center or Group of Claim Centers to individual users or groups of users.


5.6.4 The system has the ability to keep notes per claim on actions taken.


5.7 Split Billing/Proration 5.7.1 Can the system take Charges posted to a single Claim

Center and break out which CPT codes are to be filed electronic to Medicare Part A (UB4) and which are to be sent electronic to Medicare Part B (1500)?


5.7.2 The billing function allows for guarantors and third-party payers to be billed at the same time for the same patient visit.


5.7.3 The billing function allows the user to suspend billing the guarantor and continue aging the guarantor’s balance for a particular visit until such time as a response from the third-party payer has been received. A notation field indicating the reason for the suspension is provided. The account status indicator or code shall be changed by the system or user to indicate suspension of guarantor billing.


5.7.4 Separate Dates – system has ability to limit only one DOS per claim (i.e. Kentucky Medicaid) and force one DOS per claim or splits three DOS to three separate claims.


5.8 Transfers/Crossovers 5.8.1 How does the system handle the Pay Class/Slide.

Does it track it as an Insurance Payment or a Patient Payment?


5.8.2 The responsibility for payment on a claim can be transferred from the guarantor to a third-party payer, from a third-party payer to the guarantor, and from one third-party payer to another.


5.8.3 The system shall have the ability to transfer unpaid balances and co-payments to secondary insurance carriers (including Medicaid) and issue a bill to the secondary carrier detailing all the information necessary for payment via both paper and electronic submission.


5.8.4 The system shall have the ability to transfer unpaid insurance balances and co-payments to the patient’s guarantor after a user-specified period of time.


5.8.5 The system shall have the ability to transfer balances remaining after receiving payments from eligible insurance carrier(s) to the patient’s account and to issue a bill to the guarantor for this balance.



5.8.6 The system shall have the ability to reassign charges previously entered to another carrier. Adjustments must be backed out and reapplied based on the new insurance carrier.


5.8.7 The system shall have the ability to merge duplicate patient accounts.


5.8.8 The system shall have the ability to split family members and reassign to appropriate accounts (mandatory with family billing).


5.9 Insurance Forms and Claims Processing 5.9.1 The system allows the system manager to initially

define all of the possible third party payers that the system will use.


5.9.2 This file of payers can be modified over time as deemed necessary by the system manager. “Modified” here involves the user having the ability to add, edit, or delete (within certain limits) third-party payers.


5.9.3 Since different payers have different information requirements, the system shall allow the system manager to define all pertinent questions to be asked at the time the patient is registered, at the time the provider and his/her insurance/ID numbers are added to the system, and other questions to be asked in the course of inputting the billable items for a patient visit.


5.9.4 The system can file all claims in an electronic format and provide reports back to the individual user who submitted the electronic batch vs. all reports coming back as one single group.


5.9.5 The system has the ability to place a Hold on Claims based on Provider, Claim Center by Provider, CPT Codes, and Diagnosis codes? This is the ability to hold charges on an individual provider for a single Carrier group pending the Provider’s credentialing or contracting. Once the provider has been credentialed/contracted the ability to do a mass release of claims for processing. Explain how this could be accomplished. The ability to report and identify claims holding for Provider Credentialing problems.


5.9.6 The system has the ability to set which Claim Centers are accepting ICD-9 vs. ICD-10 codes.


5.9.7 The system has the ability to quickly identify pre-cert numbers and attach to the appropriate claim.


5.9.8 The system has the ability for the system to alert a charge poster if a charge is entered on the same account of the same day to prevent duplicate charge entry.


5.9.9 The system has the ability to set rules for third party payers on CPT codes and Diagnosis codes.


5.9.10 Describe in detail the system Claim scrubbing process. Failed claims list prior to transmission to clearinghouse.


5.9.11 The system has EPSDT forms capable of auto filling from directly from the system.


5.9.12 The system has the ability to place a single claim on hold and run report to identify and locate claims on hold.

☐ ☐ ☐ ☐


5.10 Fee Schedule Maintenance 5.10.1 The system maintains fees for all items which the user

identifies as billable. This fee schedule has restricted access and can be updated by the system manager when necessary.


5.10.2 The system has the ability to identify all procedures which are covered by FQHC rates.


5.10.3 The system has ability to maintain multiple standard fee schedules while still maintaining the ability to track third party payment profiles. Profiles must be able to tie to each third party plan. Unlimited number of profiles. Additionally, the ability to inactivate the profile.


5.10.4 The system has the ability to set fee to RBRVS system and track Provider and report on an RBRVS production


5.10.5 The system has the ability to maintain historical fee schedule amounts with effective dates related to Date of Service.


5.10.6 The system has the ability to mark procedure codes individually in a profile as usable or non-usable as it relates to the insurance plan the procedure code is attached to, to allow lockdown and usage of the procedure codes for specific plans.


5.10.7 Effective Dates assigned to Fee Schedule Amounts are recognized by Date of Service.


5.10.8 The system has the ability to “copy” profiles. ☐ ☐ ☐ Click here to enter text. 5.10.9 Explain the process when you want to perform

standard fee increases. Click here to enter text.

5.10.10 Explain process to update fee schedules when new fee schedules are received from the carriers. i.e. import excel file with updated fees.


5.11 Collection Management 5.11.1 The system tracks the status of each outstanding

guarantor balance by the age of the balance (in intervals of 30 days up to 150 days) and by whether or not a minimum payment (percentage basis), a full payment, or no payment has been made against the outstanding balance.


5.11.2 The system tracks the status of each outstanding third-party payer by the age of the balance due on each account.


5.11.3 The system supports the development of budget plans and bills guarantors according to the budget plan agreement.


5.11.4 The system provides a “tickler system” for tracking the activities associated with managing collection accounts.


5.11.5 The system produces a report of accounts with credit balances.


5.11.6 How does the system handle late charge posting prior to fee schedule change?


5.11.7 Does it change the fee base on date of service or Calendar date?


5.11.8 The collections module allows the user to flag accounts for follow-up and to add special collection accounts.



5.11.9 The system maintains a history of statements mailed to patients (required to file for Medicaid bad debts). The history records the date and type of statement sent.


5.11.10 The system has the ability to generate reminder notices to patients with expired sliding fee review dates.


5.11.11 The system has the ability to change the sliding fee type of patients with expired sliding fee coverage (temporary category).


5.11.12 The system has the ability to have system auto transfer accounts into the collection module. The ability to have various collection letters based on Class Code, Slides, Programs, Carriers


5.11.13 Explain how the system handles and manages Payment Arrangements and the ability to send separate bills on balances that have payment arrangements vs. balances that do not within the same account.


5.11.14 The system has the ability to be notified of accounts that have missed payments and the ability to auto transfer balances to an outside collection agency. Explain the various options to manage large volumes of accounts.


5.12 On-Demand Bill and Bill Types 5.12.1 A demand bill can be generated by the system when

the patient’s visit is complete. ☐ ☐ ☐ Click here to enter text.

5.12.2 The demand bill includes the following data elements: 5.12.2.1 Patient’s name and address ☐ ☐ ☐ Click here to enter text. 5.12.2.2 Patient’s account number ☐ ☐ ☐ Click here to enter text. 5.12.2.3 Billing facility’s name and address ☐ ☐ ☐ Click here to enter text. 5.12.2.4 Billing facility’s taxpayer ID number ☐ ☐ ☐ Click here to enter text. 5.12.2.5 Place of service ☐ ☐ ☐ Click here to enter text. 5.12.2.6 Detail for each line item includes: ☐ ☐ ☐ Click here to enter text. 5.12.2.6.1 Date of service ☐ ☐ ☐ Click here to enter text. 5.12.2.6.2 Procedure code(s) ☐ ☐ ☐ Click here to enter text. 5.12.2.6.3 Service/supply item ☐ ☐ ☐ Click here to enter text. 5.12.2.6.4 Fee ☐ ☐ ☐ Click here to enter text. 5.12.2.7 Balance prior to this visit ☐ ☐ ☐ Click here to enter text. 5.12.2.8 Total amount due this visit ☐ ☐ ☐ Click here to enter text. 5.12.2.9 Adjustments (discounts, etc.) ☐ ☐ ☐ Click here to enter text. 5.12.2.10 Method of payment ☐ ☐ ☐ Click here to enter text. 5.12.2.11 Amount of payment ☐ ☐ ☐ Click here to enter text. 5.12.2.12 Net balance due ☐ ☐ ☐ Click here to enter text. 5.12.3 The system has the ability to print a generic service

description for user-selected procedures that may be considered confidential (e.g., STD/AIDS test).


5.12.4 Demand bills are generated by a printer associated with the cashier’s CRT and capable of printing at least 80 columns.



5.12.5 If the patient has been identified as eligible for a certain discount percentage, the demand bills will automatically include the credit adjustment for the discount and the reversing debit adjustment for the discount.


5.12.6 If a fixed (minimum) co-payment is specified for the system as a whole or for particular accounts (Medicaid indigents), the demand bill will reflect the associated adjustments.


5.12.7 The balance and aging of an account are updated at the time the demand bill is generated and is not delayed until the end of the accounting period.


5.12.8 The system tracks the status of each outstanding third-party payer by the age of the balance due on each account.


5.12.9 The system supports billing by family where all bills associated with members of a family are summarized in a single family account balance.


5.12.10 The system allows the system manager to modify the format of the patient or family statement/bill without vendor intervention.


5.12.11 The system automatically determines the sliding fee category based on the family size and income.


5.12.12 The system has the ability to reprint a day bill on demand.


5.12.13 The system has the ability to reprint patient statements using a date range to include multiple dates of service on demand.


5.12.14 The system has the ability to have multiple bill types on one account. The ability to not include claims pending due to a liability (e.g. work comp, MVA) on show up on the patient’s bill. The ability to exclude by CPT Code or Diagnosis to not bill the Patient.


5.12.15 The system has the ability to have “do not Contact” on an account based on the diagnosis and/or CPT vs. the entire account.


5.12.16 The system has the ability to have different statement designs base on Class Codes or Program Codes if desired.


5.13 Charge Entry 5.13.1 The system supports both real-time and batch entry of

patient service charges. ☐ ☐ ☐ Click here to enter text.

5.13.2 The system defaults the visit diagnosis to the last or the chronic diagnosis based on the preference set by the user.


5.13.3 The system shows the primary, secondary, and tertiary insurance for selection during charge entry (defaults to primary) and allows changing insurance assignments as necessary.


5.13.4 The system prompts the user with the codes and fees associated with the selected insurance carrier.


5.13.5 The system supports splitting global fees into user-defined components.



5.13.6 The system prevents users from entering procedures to incorrect sites, departments, or providers (e.g., dental codes cannot be entered in the department of Pediatrics).


5.13.7 The system has the ability to alert the user when a CPT Code is included or not included in a Capitation Plan?


5.13.8 The system has the ability to alert the user if a CPT code requires an ABN.


5.13.9 The system has the ability to alert the user if a CPT code requires chart notes to be sent with the Claim.


5.13.10 The system has the ability to attach chart notes/documentation with an electronic claim.


5.13.11 The system has the ability to refile unpaid claims to third party carriers based on a carrier code, insurance plan, CPT codes, CPT code groups, diagnosis, individual account, by date or range of date, and provider.


5.13.12 The system has ability to post lab panels and have the detail of the labs performed within the standard panel listed in a detail. The ability to track and report on a panel or the individual test within the panel.


5.13.13 The system identifies labs “ordered and NOT performed” as NONBILLABLE and does NOT forward to Billing until the lab is actually drawn and performed.


5.13.14 The system has capability to advise Billing when a test has been forwarded to an outside reference lab that has NOT been performed and should not be billed, i.e. lost specimen, damaged specimen.


5.13.15 Explain how the system identifies Reflex labs including how and when the information is sent to Billing.


5.13.16 The system has the ability to sort claims from the EHR system by payer type and disburse to multiple users task list for billing process


5.13.17 The system has the ability to inactive invalid CPT Codes and to notify the charge entry processors that an invalid code is being used.


5.13.18 The system has the ability to check Eligibility at the charge entry process.


5.14 The system has the ability to print a patient or guarantor’s private statement containing a record of patient/guarantor billings, payments on account, insurance filings, and insurance payments received.


5.15 The system has the ability to print a day-log of all transactions processed by staff member to facilitate cash drawer reconciliation and encounter form tracking.


5.16 The system allows the user to define at least 100 site-program codes to distinguish revenue categories by clinic site and reimbursement source.


5.17 The system shall issue monthly mailing statements that will conform to the specifications of the U.S. Postal Service including printing of ZIP+4 and bar coding requirements.


5.18 The system provides the ability to establish and have bills adjust to a center-specific sliding fee scale policy including:



5.18.1 Minimum fee by procedure code ☐ ☐ ☐ Click here to enter text. 5.18.2 Minimum fee by visit ☐ ☐ ☐ Click here to enter text. 5.18.3 Minimum fee by department ☐ ☐ ☐ Click here to enter text. 5.18.4 Combination of above ☐ ☐ ☐ Click here to enter text. 5.18.5 Sliding fee by percentage of full charge ☐ ☐ ☐ Click here to enter text. 5.18.6 Ability to identify procedures ineligible for slide ☐ ☐ ☐ Click here to enter text. 5.19 The system allows the user to set Medicare Clinic rates,

including PPS rate and enhanced rate. Explain ☐ ☐ ☐ Click here to enter text.

5.20 The system provides several customer-defined bill hold criteria by patient type and insurance type including number of days after discharge, missing data, diagnosis.

☐ ☐ ☐

5.21 The system provides a flexible schedule for the generation of patient bills based on patient type and payer/payer healthplan or medical service.

☐ ☐ ☐

5.22 The system provides a bidirectional interface with the PM, EHR, and EDR systems. Explain


6. Coding Yes Yes* No Comments / Clarifications 6.1 The system supports both ICD-9-CM and ICD-10-CM. ☐ ☐ ☐ Click here to enter text. 6.2 The system provides a cross walk between ICD-9-CM to

ICD-10-CM and between ICD-10-CM to ICD-9-CM. ☐ ☐ ☐ Click here to enter text.

6.3 The system allows the user to code both ICD-9-CM and ICD-10-CM.


6.4 The system offer computer assisted coding. ☐ ☐ ☐ Click here to enter text. 6.4.1 The system recommends appropriate level of EM

service. ☐ ☐ ☐ Click here to enter text.

6.4.2 The system recommends the appropriate Diagnosis coding.


6.4.2.1 ICD-9-CM ☐ ☐ ☐ Click here to enter text. 6.4.2.2 ICD-10-CM ☐ ☐ ☐ Click here to enter text. 6.5 The system will be capable of utilizing 5010 Transaction

Code Sets prior to January 1, 2012. ☐ ☐ ☐ Click here to enter text.

6.6 The system will be capable of utilizing ICD-10 Code Sets prior to October 1, 2013.


6.6.1 The system will be capable of managing ICD9/ICD10 translation tables


6.6.2 The system will be capable of managing the ICD9/ICD10 transition period with third party payers accepting both standards.


6.7 The system includes automatic translation of codes to data. For example:


6.7.1 ICD-9-CM ☐ ☐ ☐ Click here to enter text. 6.7.2 DSM-IV ☐ ☐ ☐ Click here to enter text. 6.7.3 CDT ☐ ☐ ☐ Click here to enter text. 6.7.4 CPT (4 and 5) ☐ ☐ ☐ Click here to enter text. 6.7.5 ICD-10 ☐ ☐ ☐ Click here to enter text. 6.7.6 SNOMED CT ☐ ☐ ☐ Click here to enter text. 6.7.7 APC ☐ ☐ ☐ Click here to enter text.


6.7.8 NDC ☐ ☐ ☐ Click here to enter text. 6.7.9 HCPCS ☐ ☐ ☐ Click here to enter text. 6.8 The system includes support and updates for the above

vocabularies. ☐ ☐ ☐ Click here to enter text.

6.8.1 Who is responsible for the updates? ☐ ☐ ☐ Click here to enter text. 6.9 The system supports user defined vocabularies, and

allows for updates and enhancements of such vocabularies.


6.10 The system supports the integration of third party coding programs.


6.11 The system includes extensive error checking of all user input data, including, but not limited to: 6.11.1 ICD-10 (Check diagnosis against gender, age, other

as necessary) ☐ ☐ ☐ Click here to enter text.

6.11.2 CPT procedure checking against diagnosis ☐ ☐ ☐ Click here to enter text. 6.11.3 Extensive date checking for validity as well as ensuring

a valid chronological order of events (dx before treatment, scheduling after birth, etc.).


6.11.4 Explain systems ability to check and send alerts on NCD and LCD coding.


6.12 The system includes SNOMED CT as the integrated standard nomenclature of clinical terms.


7. Accounts Receivable Yes Yes* No Comments / Clarifications 7.1 Interfaces with Other Functional Areas 7.1.1 The A/R functions must interface with the Registration functions so that at the initial patient contact the system can display: 7.1.1.1 The account to which the patient belongs ☐ ☐ ☐ Click here to enter text. 7.1.1.2 The sources of payment available to the patient ☐ ☐ ☐ Click here to enter text. 7.1.2 Accounting data (transactions) and medical/nursing

data are entered via the same input stream in order to eliminate redundancy and to ensure that services billed match services provided.


7.1.3 The system interfaces the A/R function with the Scheduling function so that the status of a patient’s account is available: 7.1.3.1 At the time the appointment is made ☐ ☐ ☐ Click here to enter text. 7.1.3.2 When the patient checks in ☐ ☐ ☐ Click here to enter text. 7.1.4 The system interfaces the A/R function with the

Registration and Scheduling modules so that comments and an account status indicator/code associated with the patient or his/her account are displayed.


7.1.5 All changes to patient registration information are immediately reflected in the A/R data.


7.2 A/R Account Inquiry 7.2.1 There is an inquiry capability that enables the user to view the following elements of an account: 7.2.1.1 Accounting data (transactions) ☐ ☐ ☐ Click here to enter text. 7.2.1.2 Guarantor’s name ☐ ☐ ☐ Click here to enter text. 7.2.1.3 Guarantor’s account number ☐ ☐ ☐ Click here to enter text. 7.2.1.4 Guarantor’s full billing address ☐ ☐ ☐ Click here to enter text. 7.2.1.5 Guarantor’s phone ☐ ☐ ☐ Click here to enter text.


7.2.1.6 Names and medical record numbers of account members


7.2.1.7 Patient account status indicator/code ☐ ☐ ☐ Click here to enter text. 7.2.1.8 Guarantor balance with aging in intervals of 30 days

up to 150 days ☐ ☐ ☐ Click here to enter text.

7.2.1.9 Other payers’ balances with the following insurance policy information:


Payer’s name ☐ ☐ ☐ Click here to enter text. Policy number ☐ ☐ ☐ Click here to enter text. Group number ☐ ☐ ☐ Click here to enter text. Policy expiration date ☐ ☐ ☐ Click here to enter text. Accept assignment arrangement ☐ ☐ ☐ Click here to enter text. Other user-defined data elements ☐ ☐ ☐ Click here to enter text. Aging in intervals of 30 days up to 150 days ☐ ☐ ☐ Click here to enter text.

7.2.1.10 Detailed transactions are in chronological order by posting date and include: Date of service ☐ ☐ ☐ Click here to enter text. Member of account receiving care ☐ ☐ ☐ Click here to enter text. Posting date ☐ ☐ ☐ Click here to enter text. Provider’s name ☐ ☐ ☐ Click here to enter text. Site of service ☐ ☐ ☐ Click here to enter text. Visit line items including:

Transaction type ☐ ☐ ☐ Click here to enter text. Line item description ☐ ☐ ☐ Click here to enter text. Dollar amount ☐ ☐ ☐ Click here to enter text. If a payment, payment’s source ☐ ☐ ☐ Click here to enter text.

Aggregation of line items billed via third-party payer claim forms:


Claim number ☐ ☐ ☐ Click here to enter text. Name of payer ☐ ☐ ☐ Click here to enter text. Date of service ☐ ☐ ☐ Click here to enter text. Status of claim (i.e., “paid” or “not

paid”) ☐ ☐ ☐ Click here to enter text.

7.2.2 The system provides the ability to sort and print to any printer a patient’s account information sorted by pay code (charges, discounts, and payments)


7.2.3 A summary report is available that shows the last payment date, last payment amount, and credit balance for a patient’s account associated with any payer.


7.3 Organization of Account Function/Feature 7.3.1 Accounts are organized by the guarantor of the

household (who is clearly identified). Individual family members associated with the account are uniquely identified.



7.3.2 Special group accounts are available to handle the situation in which services provided to a large group (100+) of patients are billed to a single third-party payer and should not or cannot be billed to the patient’s guarantor.


7.3.3 Accounts can be identified by supplying the system with the patient’s name, the guarantor’s name, or the account number.


7.3.4 Accounts can be sorted by guarantor name (in alphabetical order) or by account number (ascending, numeric) on reports.


7.4 Posting Transactions/Audit Trail 7.4.1 The method of posting transactions is double-entry

accounting. ☐ ☐ ☐ Click here to enter text.

7.4.2 In addition to double-entry posting, debit adjustments and credit adjustments are distinguished from debits and credits.


7.4.3 Data entry can be either on-line or batched. Batched transactions may be optionally edited on-line (additions, changes, deletions) prior to posting transactions to the accounts.


7.4.4 All transactions are associated with the patient, the account, the name of the person who posted the transaction, the posting date, the name of the transaction, the dollar amount of the transaction, and the transaction type.


7.4.5 In addition, each charge item includes the following data: 7.4.5.1 Date of service ☐ ☐ ☐ Click here to enter text. 7.4.5.2 Payer ☐ ☐ ☐ Click here to enter text. 7.4.5.3 Provider ☐ ☐ ☐ Click here to enter text. 7.4.5.4 Department/program ☐ ☐ ☐ Click here to enter text. 7.4.5.5 Procedure code ☐ ☐ ☐ Click here to enter text. 7.4.5.6 Revenue-producing cost center ☐ ☐ ☐ Click here to enter text. 7.4.5.7 Site of service ☐ ☐ ☐ Click here to enter text. 7.4.5.8 Type of service ☐ ☐ ☐ Click here to enter text. 7.4.5.9 A flag identifying a non-standard fee amount (an

override fee) ☐ ☐ ☐ Click here to enter text.

7.4.5.10 User-defined comment field ☐ ☐ ☐ Click here to enter text. 7.4.6 Whether or not related to medical/nursing service, each financial transaction is associated with the: 7.4.6.1 Date of the service (mandatory for third-party

payer/optional for payments applied to guarantor balance)


7.4.6.2 Payer ☐ ☐ ☐ Click here to enter text. 7.4.6.3 Provider ☐ ☐ ☐ Click here to enter text. 7.4.6.4 Department/program ☐ ☐ ☐ Click here to enter text. 7.4.6.5 Revenue-producing cost center ☐ ☐ ☐ Click here to enter text. 7.4.6.6 Charges to which the payment is applied ☐ ☐ ☐ Click here to enter text. 7.4.6.7 If a payment is by check, bank number and check

number ☐ ☐ ☐ Click here to enter text.


7.4.7 Each adjustment is associated with the: 7.4.7.1 Date of the service ☐ ☐ ☐ Click here to enter text. 7.4.7.2 Provider ☐ ☐ ☐ Click here to enter text. 7.4.7.3 Department/program ☐ ☐ ☐ Click here to enter text. 7.4.7.4 Revenue-producing cost center ☐ ☐ ☐ Click here to enter text. 7.4.7.5 Insurance Plan (Carrier) ☐ ☐ ☐ Click here to enter text. 7.4.7.6 The type of adjustment, either debit adjustment or

credit adjustment ☐ ☐ ☐ Click here to enter text.

7.4.7.7 A comment/notation area ☐ ☐ ☐ Click here to enter text. 7.4.8 Third-party payments can be posted to particular visits

designated by the payer as well as to the outstanding balance (as a unit).


7.4.9 The system shall provide a journal entry for the general ledger detailing revenue, adjustments, payments, bad debts, refunds by account number (segmented by site and department). This entry must reflect the exact changes in the AR report by payer category. The GL entry and AR reports can be run at any time after the close of the period and will not have changed.


7.4.10 The system shall provide the capability to automatically write-off accounts based on insurance plan, date of service, and threshold balance.


7.4.11 The system shall provide the capability to post denials with codes into the system electronically.


7.4.12 The system provides a report to reconcile amounts written off to bad debt.


7.4.13 The system provides a report to reconcile amounts refunded to patients.


7.5 Daily Reports 7.5.1 There is a daily transaction log that details all the

transactions entered each day. ☐ ☐ ☐ Click here to enter text.

7.5.2 This daily transaction log includes the date and time each transaction is generated.


7.5.3 This daily transaction log is organized by patient name in alphabetical order or by account number; the order is user-defined and may be changed from one accounting period to the next.


7.5.4 The daily transaction log also includes the following detail within each account: 7.5.4.1 Date of the service ☐ ☐ ☐ Click here to enter text. 7.5.4.2 Posting date ☐ ☐ ☐ Click here to enter text. 7.5.4.3 Provider’s name ☐ ☐ ☐ Click here to enter text. 7.5.4.4 Each transaction includes:

Transaction description ☐ ☐ ☐ Click here to enter text. Transaction type (debit, etc.) ☐ ☐ ☐ Click here to enter text. Dollar amount ☐ ☐ ☐ Click here to enter text.

7.5.5 The system generates a bank deposit sheet listing all checks (with bank and check numbers), their dollar amounts, and the total amount for deposit.



7.5.6 The system generates a cash receipt log (cash and checks) broken out by facility or by program, and/or by provider.


7.6 Receivables Management Reports 7.6.1 There is an Aged Trial Balance (ATB) report, provided

in alphabetical order by guarantor name that shows all outstanding receivables on all non-zero balance accounts. Aging is presented in 30-day intervals up to 120 days. This report can be run at the user’s option in a user-selected date of service range (i.e., not mandatory to run each month).


7.6.2 On the ATB, all accounts with charges in suspense show aging of the suspense amounts by insurer and by site.


7.6.3 Each account description includes: 7.6.3.1 The guarantor’s name ☐ ☐ ☐ Click here to enter text. 7.6.3.2 Account number ☐ ☐ ☐ Click here to enter text. 7.6.3.3 Telephone number(s) ☐ ☐ ☐ Click here to enter text. 7.6.4 The ATB report includes totals for the entire practice by

age category for guarantor responsibility and for each third-party payer with suspended amounts.


7.6.5 The ATB report can be generated by insurance, days outstanding, sliding fee type, or credit code.


7.6.6 There is a monthly Outstanding Third-Party Charges report that shows aged totals for all third-party payers. It includes all claims currently in suspense by account.


7.6.7 The Outstanding Third-Party Charges report can also be broken out by site, by program, and/or by payer.


7.6.8 The system produces both detail and summary receivables reports by patient financial status, by age and amount due, by location, by provider, accounts with credit balances, and overdue accounts that are candidates for collection.


7.6.9 The A/R Ledger is subdivided into non-zero balance and zero-balance accounts; the non-zero balance accounts are shown with the date and/or number of days since the last payment/activity.


7.6.10 The Revenue Analysis report(s) break(s) out revenue or gross charges by: 7.6.10.1 The system as a whole ☐ ☐ ☐ Click here to enter text. 7.6.10.2 Provider ☐ ☐ ☐ Click here to enter text. 7.6.10.3 Site ☐ ☐ ☐ Click here to enter text. 7.6.10.4 Program ☐ ☐ ☐ Click here to enter text. 7.6.10.5 Payer ☐ ☐ ☐ Click here to enter text. 7.6.10.6 Or by any combination of the above ☐ ☐ ☐ Click here to enter text. 7.6.10.7 Cost Center ☐ ☐ ☐ Click here to enter text. 7.6.11 A Detail Revenue Analysis report must show Adjusted

Gross Charges by applying contractual adjustments to Gross Charges. Charge Adjustments are subtracted from Adjusted Gross Charges to arrive at Net Billable Amounts. Adjustments to Gross Charges include Reversal of Charges.



7.6.12 The Revenue Analysis Report(s), if run on a cash basis, shows the charges, adjustments, and payments at the time the report is run.


7.6.13 The Revenue Analysis Report(s), if run on an accrual basis, can be run any time, but the specific accounting period, or range of periods, must be identified.


7.6.14 On an accrual basis, the Revenue Analysis Report(s) show(s): 7.6.14.1 Charges for one or more periods this fiscal/calendar

year ☐ ☐ ☐ Click here to enter text.

7.6.14.2 Charges for prior periods this fiscal year ☐ ☐ ☐ Click here to enter text. 7.6.14.3 Adjustments posted against dates of service in prior

periods this fiscal/calendar year ☐ ☐ ☐ Click here to enter text.

7.6.14.4 Net this (or selected) period(s) this fiscal year (charges less adjustments)


7.6.14.5 Net prior periods this fiscal/calendar year ☐ ☐ ☐ Click here to enter text. 7.6.14.6 Payments posted against dates of service in this (or

selected) period(s) this fiscal/calendar year ☐ ☐ ☐ Click here to enter text.

7.6.14.7 Payments posted against dates of service in prior periods this fiscal/calendar year


7.6.15 The system produces a Capitated Patient List that shows insurance information for all patients under capitation.


7.6.16 The system produces Encounters for Patients Without Third Party Coverage report that lists patients’ full names, their social security numbers, and all encounters and their associated charges within a user-specified date range for patients that show no insurance coverage on their accounts. This report can be used to check eligibility for Medical reimbursement.


8. EDI Services Yes Yes* No Comments/Clarifications 8.1 The PMS provides comprehensive EDI services ☐ ☐ ☐ Click here to enter text. 8.1.1 EDI Services include: 8.1.1.1 Electronic Billing Services ☐ ☐ ☐ Click here to enter text. 8.1.1.2 Electronic to paper conversion of unsupported

formats or carriers ☐ ☐ ☐ Click here to enter text.

8.1.1.3 Electronic Format Management ☐ ☐ ☐ Click here to enter text. 8.1.1.4 Electronic Claims Scrubbing ☐ ☐ ☐ Click here to enter text. 8.1.1.5 Electronic Patient Statements ☐ ☐ ☐ Click here to enter text. 8.1.1.5.1 Custom formatting available and associated costs 8.1.1.5.2 Costs for 1st and 2nd page patient statements 8.1.1.6 Electronic Remittance Advice (ERA) ☐ ☐ ☐ Click here to enter text. 8.1.1.6.1 Support for automated posting of ERA files ☐ ☐ ☐ Click here to enter text. 8.1.1.7 On-Line or real time lookup of claims data (claims

tracking) ☐ ☐ ☐ Click here to enter text.

8.1.1.8 Insurance eligibility lookup and verification ☐ ☐ ☐ Click here to enter text. Real-time ☐ ☐ ☐ Click here to enter text. Batch ☐ ☐ ☐ Click here to enter text.

8.2 EDI Services are provided directly by your company ☐ ☐ ☐ Click here to enter text.


8.2.1 If so, what EDI Services are offered by your company? Click here to enter text. 8.2.2 What are the associated costs of the direct EDI

Services? Click here to enter text.

8.2.3 What clearing house(s) are utilized by your EDI services?


8.3 EDI Services are provided by a third party clearinghouse. ☐ ☐ ☐ Click here to enter text. 8.3.1 What third party clearinghouse(s) does your company

currently contract with for EDI Services? Click here to enter text.

8.3.2 Explain the contractual arrangements. Click here to enter text. 8.3.3 What EDI Services are contracted to third party

clearinghouses? Click here to enter text.

8.3.4 What are the associated costs of the contracted EDI Services?


8.4 How direct billing formats are handled by your system? Explain.


8.4.1 Provide list of associated costs. Click here to enter text. 8.5 Are Medicaid and Medicare claims charged at the same

rate as commercial insurance claims? ☐ ☐ ☐ Click here to enter text.

8.5.1 Provide an explanation. Click here to enter text. 8.6 Clients are given a choice in the selection of

clearinghouse(s). ☐ ☐ ☐ Click here to enter text.

8.6.1 Provide an explanation. Click here to enter text. 8.7 The system is capable of generating EDI reports by: user

not a full batch made Click here to enter text.

8.7.1 User(s) ☐ ☐ ☐ Click here to enter text. 8.7.2 Batch ☐ ☐ ☐ Click here to enter text. 8.7.3 Insurance Carrier Name ☐ ☐ ☐ Click here to enter text. 8.7.4 Insurance Carrier Type ☐ ☐ ☐ Click here to enter text. 8.7.5 Clearinghouse ☐ ☐ ☐ Click here to enter text. 8.7.6 Date ☐ ☐ ☐ Click here to enter text. 8.8 What is the turnaround time for claims corrections from

the clearinghouse? Click here to enter text.

8.9 What charges are associated for editing a claim and resubmitting?


8.10 Who is responsible for formatting, clearinghouse or vendor?


8.11 Describe the support availability and process for EDI related issues.


8.12 When there are EDI problems on the clearinghouse end how do you notify clients?


8.13 What is the turnaround time when a call is made for formatting changes or software questions?


8.14 End user can contact the clearinghouse directly for questions & support issues


8.15 Comprehensive reporting is available for all EDI services ☐ ☐ ☐ Click here to enter text.

9. Management Support: Reporting Yes Yes* No Comments / Clarifications 9.1 The system contains an integrated report writer. ☐ ☐ ☐ Click here to enter text. 9.1.1 Explain the capabilities of the integrated report writer in

detail. ☐ ☐ ☐ Click here to enter text.


9.1.2 The integrated report writer has the ability to create customized reports.


9.1.3 The integrated report writer can generate reports at the enterprise level. (including a number of practices)


9.1.4 The integrated report writer allows ad hoc reporting at the user level.


9.1.5 The integrated report writer allows reports to be exported to different formats such as Excel, HTML, PDF or ASCII.


9.1.6 The integrated report writer allows summary reports to be created for the comparison of specific data to each other.


9.1.7 The integrated report writer allows reports to be saved for future use, allowing the use of run time variables.


9.1.8 The integrated report writer allows previously created reports be imported/exported between different practices to prevent having to re-write/re-run the report.


9.1.9 The integrated report writers saved reports can be scheduled to generate automatically at a specific time by the practice.


9.1.10 All of the data within the system be searched, sorted, reported and analyzed by the integrated report writer. Explain.


9.1.11 The integrated report writer is delivered with Health Disparities Collaborative (HDC) reports. Explain.


9.1.12 The integrated report writer has the ability to provide UDS reports. Explain.


9.1.13 The integrated report writer can report data for items such as:


9.1.13.1 Pay-for-performance programs ☐ ☐ ☐ Click here to enter text. 9.1.13.2 Disease registries ☐ ☐ ☐ Click here to enter text. 9.1.13.3 HCQR ☐ ☐ ☐ Click here to enter text. 9.1.13.4 FPAR ☐ ☐ ☐ Click here to enter text. 9.1.13.5 Other quality initiatives ☐ ☐ ☐ Click here to enter text. 9.2 The system has an independent full feature ad-hoc report

writer. ☐ ☐ ☐ Click here to enter text.

9.2.1 Explain the capabilities of the independent report writer in detail. 9.2.2 The independent report writer has the ability to create

customized reports. ☐ ☐ ☐ Click here to enter text.

9.2.3 The independent report writer can generate reports at the enterprise level. (including a number of practices)


9.2.4 The independent report writer allows ad hoc reporting at the user level.


9.2.5 The independent report writer allows reports to be exported to different formats such as Excel, HTML, PDF or ASCII.


9.2.6 The independent report writer allows summary reports to be created for the comparison of specific data to each other.


9.2.7 The independent report writer allows reports to be saved for future use, allowing the use of run time variables.


9.2.8 The independent report writer allows previously created reports be imported/exported between different practices to prevent having to re-write/re-run the report.


9.2.9 The independent report writer saved reports can be scheduled to generate automatically at a specific time by the practice.


9.2.10 All of the data within the system be searched, sorted, reported and analyzed by the independent report writer. Explain.


9.2.11 The independent report writer is delivered with Health Disparities Collaborative (HDC) reports. Explain.


9.2.12 The independent report writer has the ability to provide UDS reports. Explain.


9.2.13 The independent report writer can report data for items such as:


9.2.13.1 Pay-for-performance programs ☐ ☐ ☐ Click here to enter text. 9.2.13.2 Disease registries ☐ ☐ ☐ Click here to enter text. 9.2.13.3 HCQR ☐ ☐ ☐ Click here to enter text. 9.2.13.4 FPAR ☐ ☐ ☐ Click here to enter text. 9.2.13.5 Other quality initiatives ☐ ☐ ☐ Click here to enter text. 9.3 Can your system use third-party software for advanced

reporting? (i.e. SQL queries, Crystal Reports, Report Smith, etc.…)


9.4 The system generates the Bureau of Primary Health Care’s Uniform Data System (UDS) reports.


9.4.1 The system provides the ability to run all or selected UDS tables.


9.4.2 The system provides the ability to run UDS reports for all or selected locations (sites).


9.4.3 The system provides the ability to run detail data reports to verify the data shown on the UDS tables.


9.4.4 The system shall be able to compute and print all UDS reports within 2 hours.


9.4.5 The system provides the ability to complete optional fields on the UDS tables.


9.4.6 Are the UDS reports developed, maintained and implemented by your company?


9.5 The system generates the Bureau of Primary Health Care’s National Goals for Chronic Care Conditions reports.


9.5.1 The system provides the ability to run all or selected National Goals.


9.5.2 The system provides the ability to run National Goals reports for all or selected locations (sites).


9.5.3 The system provides the ability to run detail data reports to verify the data shown on the National Goals reports.


9.5.4 The system shall be able to compute and print all National Goals reports within 2 hours.


9.6 The system will produce a revenue analysis report that summarizes for a user-specified date range, cost center, site, department, and/or provider:

9.6.1 Total fees charged ☐ ☐ ☐ Click here to enter text. 9.6.2 Total adjustments (by type) ☐ ☐ ☐ Click here to enter text.


9.6.3 Total revenue generated ☐ ☐ ☐ Click here to enter text. 9.6.4 Total procedures by procedure code ☐ ☐ ☐ Click here to enter text. 9.7 The system will produce productivity trend reports including the following ratios by cost center, department, and/or site for a user

specified date range: 9.7.1 Average charge per visit ☐ ☐ ☐ Click here to enter text. 9.7.2 Average charge per diagnosis ☐ ☐ ☐ Click here to enter text. 9.7.3 Average charge per procedure ☐ ☐ ☐ Click here to enter text. 9.7.4 Average revenue per visit ☐ ☐ ☐ Click here to enter text. 9.7.5 Average cost per visit ☐ ☐ ☐ Click here to enter text. 9.7.6 Number of encounters per diagnosis and procedure ☐ ☐ ☐ Click here to enter text. 9.7.7 Collection ratios ☐ ☐ ☐ Click here to enter text. 9.7.8 Accounts receivable ratios ☐ ☐ ☐ Click here to enter text. 9.7.9 Net worth, current ratio ☐ ☐ ☐ Click here to enter text. 9.8 A report generator is integrated with the other system

modules so that the user need not be concerned about job control language.


9.9 Subsets of patient, encounters, clinical, or account records can be selected using Boolean logic. The logic can be applied to any and all data fields in a patient’s record (e.g., laboratory results, health profile status, medications, and other objective findings, lifestyle issues, financial/billing/accounts receivable information, etc.). Selection can be composed of the following operators:

9.9.1 Equals, less than, greater than, greater than or equal, less than or equal, not equal


9.9.2 Within a range ☐ ☐ ☐ Click here to enter text. 9.9.3 First, last occurrence ☐ ☐ ☐ Click here to enter text. 9.9.4 nth occurrence ☐ ☐ ☐ Click here to enter text. 9.9.5 NOT, AND, OR, with nesting to five (5) levels ☐ ☐ ☐ Click here to enter text. 9.10 Up to ten (10) fields from each selected record can be

listed. ☐ ☐ ☐ Click here to enter text.

9.11 Two (2) dimensional tables from the selected records can be generated.


9.12 The user is able to store report programs in a report library, and execute these programs under user control.


9.13 The user is able to edit the parameters of a report program, and refine the revised parameters into the program library.


9.14 The system manager is able to queue report programs that are to be executed, and to request that the system execute the programs when the computer is unattended.


9.15 Report files created by the report generator can be analyzed and presented via a statistical package. The following capabilities are desired:

9.15.1 Frequency counts ☐ ☐ ☐ Click here to enter text. 9.15.2 Mean ☐ ☐ ☐ Click here to enter text. 9.15.3 Median ☐ ☐ ☐ Click here to enter text. 9.15.4 Standard deviation ☐ ☐ ☐ Click here to enter text. 9.15.5 Cross tabulation ☐ ☐ ☐ Click here to enter text. 9.15.6 Histograms ☐ ☐ ☐ Click here to enter text. 9.15.7 Scatterplot ☐ ☐ ☐ Click here to enter text. 9.15.8 Chi-square ☐ ☐ ☐ Click here to enter text.


9.15.9 Random sample ☐ ☐ ☐ Click here to enter text. 9.15.10 Run plots of patient data (and aggregated patient

data—counts, averages, etc.) over time. The timeframe can be set by the user.


9.16 The system provides a capability to chart both raw and summarized data.


9.17 The charting capability allows multiple graphs (up to 5) per page aligned by their X-axis.


9.18 The user is able to create new data fields and data files that supplement the patient registration and encounter records in the system.


9.19 User-created supplemental data fields and files can be linked to patient registration and encounter data. Data in these supplemental data fields and files can be used in patient data inquiries and reports.


9.20 The system includes indexed key fields that reduce the time required to generate reports. Indexed fields include:


9.20.1 Date of service ☐ ☐ ☐ Click here to enter text. 9.20.2 Account number ☐ ☐ ☐ Click here to enter text. 9.20.3 Date of posting ☐ ☐ ☐ Click here to enter text. 9.20.4 Date of deposit ☐ ☐ ☐ Click here to enter text. 9.20.5 Appointment date ☐ ☐ ☐ Click here to enter text. 9.20.6 Provider ☐ ☐ ☐ Click here to enter text. 9.20.7 Site ☐ ☐ ☐ Click here to enter text. 9.20.8 Department ☐ ☐ ☐ Click here to enter text. 9.20.9 Insurance Plan ☐ ☐ ☐ Click here to enter text. 9.21 The system includes electronic mail capabilities (both

internal and Internet). ☐ ☐ ☐ Click here to enter text.

9.22 The system allows the user to use third party report writing tools to access the data.


9.23 The system provides a data warehouse in a Standardized Query Language (SQL) environment.


9.24 The system provides the capability to export all data as comma-delimited text, in MS Excel spreadsheet format, or in open database compliant (ODBC) databases.


9.25 The system is certified for the Physician Services Practice Analysis (PSPA) program.


9.26 The system provides query capabilities that allow “drill down” capabilities (e.g., user can view the detailed data supporting a summary down to an individual record).


9.27 The system can be configured to automatically run nightly closes and month end reports.


9.28 The system has the ability to track billing system users and measure staff productivity. (for example, how many claims did a biller process and the average time to process?)


9.29 The system has the ability to create billing productivity exception reports (for example, if a biller processes less that a predetermined amount of claims, the system will automatically add the user to an exception report)


9.30 The system is capable of producing standard management reports measuring productivity by provider using:


9.30.1 Productivity by encounters ☐ ☐ ☐ Click here to enter text. 9.30.2 Productivity by RVU ☐ ☐ ☐ Click here to enter text. 9.30.3 CPT coding “curve” report card ☐ ☐ ☐ Click here to enter text. 9.31 Cost Measuring / Quality Assurance / Reporting 9.31.1 The system has built-in mechanism/access to other

systems to capture cost information. ☐ ☐ ☐ Click here to enter text.

9.31.2 The system supports real-time or retrospective trending, analysis, and reporting of clinical, operational, demographic, or other user-specified data including current and future UDS reports.


9.31.3 The system allows customized reports or studies to be performed utilizing individual and group health data from the electronic record.


9.31.4 The system will provide support for third-party report writing products.


10. Systems Management Yes Yes* No Comments / Clarifications 10.1 Security features are incorporated within the system. These shall provide for: 10.1.1 Positive identification of authorized users and

terminals. ☐ ☐ ☐ Click here to enter text.

10.1.2 Control of the functions authorized for a user or category of users (e.g., registration, cashier, biller, etc.).


10.1.3 Control of the menu options authorized for a user or category of users.


10.1.4 Ability to drop inactive users off the system after a specified interval of inactivity.


10.1.5 Ability to clear automatically the screens of video display terminals after a specified interval of inactivity.


10.1.6 The system allows at least 99 groups or categories of users to be defined for security.


10.1.7 The system provides the ability to restrict user access to files by read, write, and modify categories.


10.2 The system can provide context sensitive on-line help messages for each data prompt at the request of the user, or automatically if an erroneous response is entered and the help facility is enable by the user.


10.3 The system manager is able to change help messages or add new messages.


10.4 Selection of functions of the system is through the use of menus, via graphical user interface mouse selections, or via typed commands available as “shortcuts” to traversing menu trees or mouse clicks.


10.5 The system is designed to protect against simultaneous update of the same data field(s) by more than one user.


10.6 The system will have means for recovering systems data from an earlier version of the master files.


10.6.1 Data is stored on mirrored disk drives. ☐ ☐ ☐ Click here to enter text. 10.6.2 Data can be backed up on an incremental basis. ☐ ☐ ☐ Click here to enter text. 10.6.3 Data backup operations can be scheduled for off-hours

and will operate unattended. ☐ ☐ ☐ Click here to enter text.


10.7 Data entry is on-line. The system checks data items upon entry for validity and consistency with other data and warns the user of erroneous entries in time for the user to correct the data before it is filed in the database.


10.8 The user is able to edit any data item as soon as the error is detected.


10.9 The system contains a master directory of all terms that will be input as part of the patient registration, encounter data entry, and accounts receivable/billing data entry process.


10.10 The system manager is able to add, delete, or modify entries in the master directory without programmer intervention.


10.11 Numerous users can simultaneously use each module, (i.e., a multi-user system). The system will ensure data integrity in the multi-user environment.


10.12 Large volume updates to static files, e.g., fee changes, can be scheduled for a given effective date.


10.13 System can be configured to support mirrored or striped disk drives to improve fault tolerance and system recovery.


10.14 System error messages are clearly explained on the user’s screen.


10.15 Significant system error messages are logged to a file for later review.


10.16 A list of all error messages with clear explanation and recommended response is documented in an operator’s manual.


10.17 The system allows archiving of inactive patient records (e.g., patients with no accounting activity for two years) onto disk or tape and purging these records from the active patient data files.


10.18 The system has a restore capability to recall inactive patient data from the archive and transfer this data back into the active files.


10.19 Zero balance charges can be periodically purged. ☐ ☐ ☐ Click here to enter text. 10.20 The system provides system status reports that indicate

the utilization of computer resources (e.g., disk space used/remaining, date/time of last full system backup, terminal/user activity).


10.21 The system maintains a detailed audit trail that includes user number, date changed, old and new value for all registration and transaction fields. Users must be able to easily generate reports to research audit issues.


10.22 The software system supports at least 999 system printers.


10.23 The software system supports at least the minimum numbers of items listed in the following fields:


10.23.1 Account number -- 999,999 ☐ ☐ ☐ Click here to enter text. 10.23.2 Insurance plans – 9999 ☐ ☐ ☐ Click here to enter text. 10.23.3 Locations – 999 ☐ ☐ ☐ Click here to enter text. 10.23.4 Departments – 99 ☐ ☐ ☐ Click here to enter text. 10.23.5 Providers – 999 ☐ ☐ ☐ Click here to enter text.


10.23.6 Dependents – 99 ☐ ☐ ☐ Click here to enter text. 10.23.7 Medical record number – 999999999999 (12 digits or

characters) ☐ ☐ ☐ Click here to enter text.

10.23.8 Visit number – 9,999,999 ☐ ☐ ☐ Click here to enter text. 10.24 The system supports running reports in the background

while allowing the user to perform other tasks. ☐ ☐ ☐ Click here to enter text.

10.25 The system has the ability to manage multiple organizations with multiple sites on a single or set of networked servers (integrated delivery system model).


10.26 The system supports standards for interfacing to other laboratory, clinical, and business data systems (e.g., Health Level 7 coding, Electronic Data Interchange messages).


11. Consents, Authorizations, and Directives Yes Yes* No Comments/Clarifications 11.1 The system has the capability for a patient to sign consent

electronically. ☐ ☐ ☐

11.2 The system has the capability to create, maintain, and verify patient treatment decisions in the form of consents and authorizations when required.

☐ ☐ ☐

11.3 The systems captures, maintains, and provides access to patient advance directives.

☐ ☐ ☐

12. Confidentiality and Security Yes Yes* No Comments / Clarifications 12.1 The system provides fully HIPAA compliant encryption. ☐ ☐ ☐ Click here to enter text. 12.2 The system is capable of meeting the most current HIPAA

Standards and is guaranteed to meet future changes as applicable.


12.3 The system provides an operational environment which will ensure the security and integrity of the database.


12.4 The software segments the security setup sections. ☐ ☐ ☐ Click here to enter text. 12.5 The software restricts a user's access to specific areas of

the application based on the user’s responsibilities. ☐ ☐ ☐ Click here to enter text.

12.6 The software restricts a user's access to specific patient records based on security roles.


12.7 The software restricts access to configuration tables, profile indexes, etc. to designated health center personnel via security controls.


12.8 The software provides multi-level security to ensure the confidentiality of all patient-related information and to control access to outreach functions and features.


12.9 The software provides the identification of the individual who made changes to the patient clinical or financial record, including the date and time of these occurrences, so that this information is accessible throughout the process.


12.10 What safeguards (e.g. fault tolerance, hardware redundancy) are included in the system to eliminate unplanned downtime?


12.11 The system supports biosensor technology for logon. ☐ ☐ ☐ Click here to enter text. 12.12 Supports industry standard electronic signatures. ☐ ☐ ☐ Click here to enter text.


12.13 The system controls access to and within the system at multiple levels (e.g. per user, per user role, per area, per section of the chart) through a consistent mechanism of identification and authentication of all users in accordance with the ‘Role Based Access Control’ (RBAC) standard.


12.14 The system verifies and enforces control to all PMS components, information and functions for end users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.


12.15 Non Repudiation – The system limits a user’s ability to deny (repudiate) an electronic data exchange originated, received, or authorized by that user.


12.16 The system secures all modes of PMS data exchange through the use of data obfuscation and destination and source authentication and other standard security methods used to ensure appropriate security and privacy considerations.


12.17 The system manages attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with incoming or outgoing information.


12.18 The system enforces the applicable jurisdiction’s patient privacy rules as they apply to various parts of the PMS through the implementation of standard security mechanisms.


12.19 The system establishes patient/physician data element confidentiality.


12.20 The system allows access to its modules regardless of location based on confidentiality and security procedures.


12.21 The system incorporates audit trails of each access to specific data.


12.22 The system incorporates an audit trail for all system transactions including look-ups of patient data.


12.23 Provides automatic analysis of audit trails and unauthorized access attempts.


12.24 Runs under B-2 or above rated operating system. ☐ ☐ ☐ Click here to enter text. 12.25 The system allows the user to produce a disclosure log

using the audit data for the purposes of treatment, payment, and healthcare operations.


12.26 The system allows the user to restrict portions of the clinical record.


12.27 The system allows the user to restrict individual user access to the clinical/financial information.


12.28 The system allows the user to run a report identifying each individual who has accessed the record (clinical or financial) including date and time. This report can be saved in a disclosure log.


12.29 The system allows the user to add disclosures to third parties.


12.30 The system will not allow the user to edit audit information that was exported onto the disclosure log.


12.31 The system will allow the user to edit user entered data into the disclosure log.



13. Managed Care Yes Yes* No Comments / Clarifications 13.1 Enrollment, Eligibility, and Benefits 13.1.1 The system supports entry and management of

managed care plan membership lists with member demographics, benefits eligibility, allowed services, and effective dates.


13.1.2 The system supports electronic downloading of managed care plan eligibility rosters via direct connection to managed care plan computer systems.


13.1.3 The system supports electronic downloading of managed care plan eligibility rosters via diskette or magnetic tape.


13.1.4 The system maintains a history of the eligibility of patients associated with managed care plans showing patient demographics and effective dates of enrollment or disenrollment.


13.1.5 The system clearly identifies and provides a report of new members that have enrolled in the managed care plan with patient demographics and effective dates.


13.1.6 The system provides a report that matches clinic patients with managed care plan membership rolls.


13.1.7 Registration of managed care plan members is integrated into the normal patient registration process (e.g., registration of managed care plan members as patients do not require entry in a separate, stand-alone microcomputer system).


13.1.8 The system offers on-line eligibility checking via electronic data interchange or demand dial to managed care plan computer systems.


13.1.9 The system provides on-line descriptions of the benefits, service limits, deductibles, and co-payments associated with each managed care contract.


13.1.10 The system provides member profile reports that show cumulative member months, prior period members, member additions, and member termination’s for a user-selected reporting period. The report includes actual, budgeted, and variance statistics.


13.1.11 The system provides reports that profile the demographics of managed care plan members by age, gender, geographical location, Medicaid eligibility, Medicare eligibility, benefit program, and insurance coverage.


13.2 Primary Care Physician (PCP) Tracking and Reporting 13.2.1 The system tracks the assignment of patients to

primary care providers and the transfer of patients between primary care providers by date.


13.2.2 The system is able to track all services, including those provided by referral providers, to the patient’s PCP.


13.3 Referral Tracking and Reporting 13.3.1 The system tracks the authorization, diagnosis, visit

limits, payment liability, and patient stop loss balance, authorizing PCP, referral provider, and payment status of referrals to outside health care providers.



13.3.2 The system supports on-line authorization of referrals for managed care plan members.


13.3.3 For hospital admissions, the system tracks precertification information, the authorization, the patient, the authorizing PCP, the admitting physician, the attending physician, the health care institution, the admission date, the bed type (i.e., private, semi-private), the approved limits on service, the estimated discharge date, the diagnoses, the procedures, other insurance coverage, the actual discharge date, and the discharge outcome.


13.3.4 The system maintains licensing and credentialing information on referral providers.


13.3.5 The system integrates referral tracking information (e.g., referral number, plan, and authorization code, referring physician, number of visits, maximum charge limits, service period, diagnosis, and comments) with the scheduling module for patients referred into the clinic.


13.3.6 The system prints referral forms. ☐ ☐ ☐ Click here to enter text. 13.3.7 The system provides referral analysis reports including

referring provider, referral provider, referral voucher number, maximum number of visits authorized, reason for referral, diagnosis, pending referrals, completed referrals, costs for referrals to outside providers, authorized reimbursement rates, and cost variance.


13.3.8 The system provides a report of Incurred But Not Reported (IBNR) liabilities for referrals to outside providers if the clinic is at risk for these payments.


13.3.9 The system produces a patient limits summary report that shows the status of patient dollar and visit limits so that PCPs are aware of referrals that exceed established thresholds.

13.3.10 The system produces a list of referrals to specialists that will expire within a user-selected number of days so that the patients can be contacted for follow-up.


13.4 Utilization Management 13.4.1 The system provides inpatient utilization reports by

plan, hospital, provider, diagnosis, patient, and procedure. The report includes length of stay, member months per year, actuals, budget, and prior year statistics.


13.4.2 The system provides utilization reports by physician, department, clinic site, patient, and plan for a user-entered date range.


13.4.3 The system highlights large case management cases and tracks the utilization management coordinator assigned.


13.4.4 The system provides utilization reports showing the number of referral visits and costs by specialty, the average cost per visit, and the per member per month cost by specialty.


13.4.5 The system provides utilization reports showing the cost per referral by PCP, the plan average, and specialty.



13.4.6 The system provides utilization reports showing the referral rate per 1,000 members per year.


13.5 Billing and Accounts Receivable 13.5.1 The system automatically distributes the costs

associated with the services rendered during a visit and calculates the co-payment required from the patient.


13.5.2 For billing, the system automatically separates services allowed under the managed care plan from those not covered.


13.5.3 The system automatically tracks changes, adjustments, co-payments, coordination of benefits, units of service, diagnosis codes, procedure codes, modifier codes, place of service, and dates of service.


13.5.4 The system produces a Stop Loss report for cases exceeding a user-established maximum cost or user-entered percentage of the maximum cost threshold for a user-entered data range.


13.5.5 The system produces a detailed Stop Loss report that lists all the services performed under capitation for patients that exceed the user-established maximum cost or a user-entered percentage of that maximum cost threshold.


13.6 Management Reports 13.6.1 The system produces the critical performance

measures reports described in Community and Migrant Health Centers, Critical Performance Measures for Prepayment, U.S. Department of Health and Human Services, Public Health Service, Health Resources and Services Administration, Bureau of Health Care Delivery and Assistance, Rockville, MD, June 1989.


13.6.2 The system produces health services performance reports that show actual, budgeted, and variance statistics for primary care including visits per member per year (PMPY), cost per visit, cost per member per month (PMPM), capitation PMPM and gain/loss PMPM.


13.6.3 The system produces health services performance reports that show actual, budgeted, and variance statistics for specialty care including referrals PMPY, services per referral, cost per service, cost per referral, cost PMPM, capitation PMPM, and gain/loss PMPM.


13.6.4 The system produces health services performance reports that show actual, budgeted, and variance statistics for ancillary care including visits per member per year, cost per visit, cost PMPM, capitation PMPM, and gain/loss PMPM.


13.6.5 The system produces health services performance reports that show actual, budgeted, and variance statistics for inpatient care including days per 1,000 per year, admissions per 1,000 per year, average length of stay, cost per day, cost per admission, cost PMPM, capitation PMPM, and gain/loss PMPM.



13.6.6 The system produces financial analysis reports that show actual, budgeted, and variance statistics for capitation revenue PMPM, co-payment revenue PMPM, other member revenue PMPM, administration costs PMPM, health services costs PMPM, and gain/loss PMPM.


13.6.7 The system is able to present management summary statistics as bar, pie, or run charts.


13.6.8 The system produces productivity analysis reports for non-capitated plans and fee for service plans that price services using the Medicare Resource Based Relative Value Scale and the McGraw-Hill Relative Value Scale.


13.6.9 The system produces an Analysis of Visits report that provides a profile of managed care plan patients seen by the practice for a user-selected period of time. This report profiles patients by geographic area, financial class, age, gender, primary diagnosis, primary care physician (PCP), and referral providers. It provides a count of patients and visits for each category with percentages of the totals.


13.6.10 The system produces a Fee Comparison report that enables the practice to compare its reimbursements from insurance carriers for service procedures to Medicare and McGraw-Hill relative value units. This report allows the practice to evaluate the profitability of participation in the managed care plan.


13.6.11 The system produces a Services Summary report that lists service procedures performed in a user-selected date range by site, provider, and plan. The report calculates the expected payments based on the Medicare Resource Based Relative Value Units and the count of service procedures.


13.6.12 The system produces a Capitation analysis report by doctor and plan summarized by month for the current fiscal year. The report shows total members seen per month, total visits by patient per month, the standard fee, the average fee per visit, the co-pay amounts paid by patients, the capitation payment, the total payment, the average net revenue per visit, the collection rate, the average number of visits per member, and the year-to-date average for each category.


13.6.13 The system produces a Capitation Payment by Provider Report that shows the income expected from a plan based on the number of members enrolled in the plan assigned to the provider and the capitation rate.


13.6.14 The system produces a Capitation Plan Analysis report that compares standard charges for service procedures against co-pay charges and payments and billable charges, payments, and adjustments in a user-specified visit date range. The report is selectable by plan, site, and doctor and lists patients, their visit dates and procedures, the service procedure standard charge, the co-payment, the co-payment paid by the patient, the amount charged to the plan, the amount the plan paid, and any adjustments.



14. Scanning and Image Storage Yes Yes* No Comments / Clarifications 14.1 The system includes an integrated scanning solution to

manage old charts and incoming paper documents. ☐ ☐ ☐

14.2 Scanned documents are readily available within the patients chart.

☐ ☐ ☐

14.3 Scanned documents can be attached to intra office communication and tracked.

☐ ☐ ☐

14.4 The system has the ability to bulk scan and easily sort old patient charts for easy reference later.

☐ ☐ ☐

14.5 Images and wave files can also be saved and stored in the document management system.

☐ ☐ ☐

14.6 Insurance cards and driver’s license can be scanned and stored in patient demographics.

☐ ☐ ☐

14.7 Scanned documents can be attached to visit notes. ☐ ☐ ☐

14.8 In a multiple location environment can each office scan in the same manner?

☐ ☐ ☐

14.9 The system supports the scanning and retrieval of patient IDs, insurance cards, income verification documents, and EOB’s.


14.10 The system allows the user to attach the document(s) to the patients account.


14.11 The system retains all scanned documents. ☐ ☐ ☐ Click here to enter text. 14.12 The scanned documents are stored with the user id

(initials) and date and time. ☐ ☐ ☐ Click here to enter text.

14.13 The system allows the user to review past scanned documents and retrieve by date.


14.14 The system has user defined security controls to allow specific user types to view the scanned financial data.


14.15 The system allows the user to scan different sized documents into a graphical format and automatically integrate into the patient’s record.


14.16 If so what document sizes are supported: 14.16.1 ADF minimum 2 in x 3 in (52 mm x 74 mm) ☐ ☐ ☐ Click here to enter text. 14.16.2 ADF maximum 8.5 in x 14 in (legal) ☐ ☐ ☐ Click here to enter text. 14.17 Your company sells and supports scanning hardware. ☐ ☐ ☐ Click here to enter text. 14.18 Scanners sold and supported:

• Compact ADF Desktop ☐ ☐ ☐ Click here to enter text.

• Desktop High Volume ☐ ☐ ☐ Click here to enter text.

• Stand Alone High Volume ☐ ☐ ☐ Click here to enter text. • Third party scanning hardware is supported by

the system. ☐ ☐ ☐ Click here to enter text.

14.19 The scanning solution integrates with existing multi-function copier/scanners


14.20 The system has desktop scanners available that allow scanning of Photo Ids, Insurance cards, and income verification documents.


14.21 If so what document weights and sizes are supported: 14.21.1 Normal 11 to 56.2 lb. (41 to 210g/m2) ☐ ☐ ☐ Click here to enter text. 14.21.2 A8 sheets 34 to 56.2 lb. (127 to 210g/m2) ☐ ☐ ☐ Click here to enter text.


14.21.3 Card – (1.4 mm) – Portrait and landscape feeding ☐ ☐ ☐ Click here to enter text. 14.21.4 Document size – 2 in x 3 in (52 mmx 74 mm) ☐ ☐ ☐ Click here to enter text. 14.21.5 Document size – 8.5 in x 14 in (legal) ☐ ☐ ☐ Click here to enter text. 14.21.6 Document size – 8.4 in x 122 in (10 ft.) ☐ ☐ ☐ Click here to enter text.

15. Electronic (Wet) Signatures Yes Yes* No Comments/Clarifications 15.1 The system provides the capability to use wet electronic

signatures for electronic forms. Explain. ☐ ☐ ☐

15.2 The system provides the capability to use biometric wet electronic signatures for authentication.

☐ ☐ ☐

15.3 The hardware for electronic signatures and biometric wet signatures is available with the system.

☐ ☐ ☐

15.4 Third party hardware for electronic wet signatures is supported.

☐ ☐ ☐

15.5 The system allows encryption keys for biometric wet electronic signatures.

☐ ☐ ☐

15.6 The system retains biometric wet electronic signatures for historical purposes.

☐ ☐ ☐

15.7 Electronic wet signatures can be used for multiple form types.

☐ ☐ ☐

15.7.1 Consent and registration forms ☐ ☐ ☐

15.7.2 Credit Card authorizations ☐ ☐ ☐

15.7.3 Electronic Funds Transfer authorizations ☐ ☐ ☐

15.7.4 History and physical forms ☐ ☐ ☐

16. Patient Kiosk Yes Yes* No Comments / Clarifications 16.1 The system provides an interface for a supported patient kiosk system. 16.1.1 Which kiosk(s) are supported? Click here to enter text. 16.1.2 Is the kiosk(s) sold and supported by your company? ☐ ☐ ☐ Click here to enter text. 16.1.3 If so what is the cost of the kiosk? Click here to enter text. 16.1.4 What cost of the interface? Click here to enter text. 16.2 Kiosk supported features: 16.2.1 Patient Registration and check-in ☐ ☐ ☐ Click here to enter text. 16.2.2 Patient Payment Processing ☐ ☐ ☐ Click here to enter text. 16.2.3 Account Status Lookup ☐ ☐ ☐ Click here to enter text. 16.2.4 Medical Summary, Labs, etc… ☐ ☐ ☐ Click here to enter text. 16.2.5 New Patient Enrollment ☐ ☐ ☐ Click here to enter text. 16.2.6 Patient Appointment Request ☐ ☐ ☐ Click here to enter text. 16.2.7 Patient Payments ☐ ☐ ☐ Click here to enter text. 16.3 The kiosk is tightly integrated with the EHR and PM

system (explain) ☐ ☐ ☐ Click here to enter text.

16.4 The kiosk is integrated with the patient portal system ☐ ☐ ☐ Click here to enter text. 16.5 The kiosk is patient friendly and offers a high degree of

usability (explain) ☐ ☐ ☐ Click here to enter text.

16.6 The kiosk is fully HIPAA compliant ☐ ☐ ☐ Click here to enter text.


16.7 The fax server API interface is robust and configurable (explain)


16.8 The kiosk has the ability to electronically capture and transfer Community Health specific information to PM as discrete data and eliminate the need for duplicate keying

16.8.1 Income verification documentation ☐ ☐ ☐ Click here to enter text. 16.8.2 Sliding Fee Calculation ☐ ☐ ☐ Click here to enter text. 16.8.3 Sliding Fee Expiration ☐ ☐ ☐ Click here to enter text. 16.8.4 Other CHC specific data ☐ ☐ ☐ Click here to enter text.

17. Patient Portal Yes Yes* No Comments / Clarifications 17.1 The system provides a direct interface for a supported

patient portal that is fully integrated with the EHR and PM system.


17.2 The patient portal is owned by your company. ☐ ☐ ☐ Click here to enter text. 17.2.1 If not then who is the 3rd party integration partner and

what methods are utilized to integrate? Click here to enter text.

17.3 All aspects of the Patient Portal accommodate the patients preferred language, reading level and cultural differences.


17.4 Patient Portal training materials are available for patients ☐ ☐ ☐ Click here to enter text. 17.5 Patient Portal allows single sign-on access, facilitated

through a single url, with seamless integration of all services provided by YVFWC. (i.e. Medical, Dental, Mental Health, etc.)


17.6 Patient Portal allows patients to grant other authorized users (i.e. family members) access to the patient’s record.


17.7 Providers can control what information is shared and can be viewed in the Patient Portal. This includes the ability to exclude certain information, as well as ability to control access to information about minors as specified in age of consent laws.


17.8 The system can be configured to automatically share results within certain lab ranges.


17.9 Allergies, past medical history, family history, etc. can be reviewed and updated by the patient in the portal and imported into the EHR as structured data (in addition this information can be highlighted and reviewed by clinical staff).


17.10 Clinical Summaries are displayed in the portal. ☐ ☐ ☐ Click here to enter text. 17.11 Test and lab results are displayed in patient portal. ☐ ☐ ☐ Click here to enter text. 17.12 Patient orders are displayed in the portal. ☐ ☐ ☐ Click here to enter text. 17.13 Patient education materials can be accessed in the portal. ☐ ☐ ☐ Click here to enter text. 17.14 Patients can print information from the Patient Portal. ☐ ☐ ☐ Click here to enter text. 17.15 Patients can conduct secure communications with

providers and clinical staff via the Patient Portal. Elaborate on this process.


17.16 Providers can see if a patient has read a message sent via the Patient Portal.


17.17 Patients can be sent notifications of treatments or procedures that are due.


17.18 Patients can schedule, re-schedule, or cancel appointments via the portal.



17.19 Patients can be sent reminders of scheduled appointments.


17.20 Medication refills can be requested in patient portal. ☐ ☐ ☐ Click here to enter text. 17.21 Medical Records can be requested in the patient portal. ☐ ☐ ☐ Click here to enter text. 17.22 Patient demographic and insurance information can be

entered by patient into portal and imported into the EHR as structured data.


17.23 Allow automatic cancelation of accounts for pediatric patients that reach 16 years.


17.24 Patient Portal activities are archived and can be reported on.


17.25 The portal has a full feature report generator, reports include: (list)


17.26 The portal is patient friendly and offers a high degree of usability (explain)


17.27 The patient portal is fully HIPAA compliant ☐ ☐ ☐ Click here to enter text. 17.28 The patient portal fulfills the stage 3 “Promoting

Interoperability” reporting requirements when properly interfaced with the Integrated EHR solution


17.29 The portal API interface is robust and configurable (explain)


17.30 Patient Portal supported features: 17.30.1 Secure Messaging ☐ ☐ ☐ Click here to enter text. 17.30.2 Integration with PMS ☐ ☐ ☐ Click here to enter text. 17.30.3 Integration with EHR System ☐ ☐ ☐ Click here to enter text. 17.30.4 Personal Health Records ☐ ☐ ☐ Click here to enter text. 17.30.5 Online Medical Summary, Labs, etc… ☐ ☐ ☐ Click here to enter text. 17.30.6 Integrated Online Patient Forms ☐ ☐ ☐ Click here to enter text. 17.30.7 Online Patient Services ☐ ☐ ☐ Click here to enter text. 17.30.8 New Patient Enrollment ☐ ☐ ☐ Click here to enter text. 17.30.9 Patient Appointment Request ☐ ☐ ☐ Click here to enter text. 17.30.10 Marketing and Communications Tools ☐ ☐ ☐ Click here to enter text.

18. Fax Server Yes Yes* No Comments / Clarifications 18.1 The system provides an interface for a supported fax server. 18.1.1 Which fax server(s) are supported? Click here to enter text. 18.2 Is the fax server(s) sold and supported by your company? ☐ ☐ ☐ Click here to enter text. 18.2.1 If so what is the cost of the fax server? Click here to enter text. 18.3 What cost of the fax server interface? Click here to enter text. 18.4 The fax server can support multiple staff simultaneously

working the fax queue(s) without noticeable performance degradation (explain)


18.5 The fax server provides reliable operation and a high degree of interface stability (explain)


18.6 The fax server API interface is robust and configurable (explain)


18.7 The fax server provides a fully integrated streamlined faxing process (explain)



18.8 Fax server supported features: 18.8.1 Securely fax physician notes and referrals directly from

the Integrated EHR ☐ ☐ ☐ Click here to enter text.

18.8.2 Securely fax prescriptions directly from order entry within the Integrated EHR


18.8.3 Securely fax lab results from ☐ ☐ ☐ Click here to enter text. 18.8.4 Securely fax patient health information (PHI) from the

Integrated EHR ☐ ☐ ☐ Click here to enter text.

18.8.5 Securely receive faxes and route them into the Integrated EHR or another document management solution


18.8.6 Achieve compliance by securely distributing PHI in digital form with delivery confirmation and auditing


18.8.7 Notifications of fax delivery and fax receipt, with customization options available


18.8.8 MFP (multi-function printer) integrations ☐ ☐ ☐ Click here to enter text. 18.8.9 Multi-layer encryption to protect PHI and other sensitive

information ☐ ☐ ☐ Click here to enter text.

18.8.10 Complete audit trail of sent and received faxes ☐ ☐ ☐ Click here to enter text. 18.8.11 Other features (list) ☐ ☐ ☐ Click here to enter text. 18.9 The fax server is tightly integrated with the EHR and PM

system (explain) ☐ ☐ ☐ Click here to enter text.

19. Practice Specific PM Extended Requirements Yes Yes* No Comments / Clarifications 19.1 The system provides full CHC Functionality and

integration within the entire PM and EHR platform ☐ ☐ ☐ Click here to enter text.

19.2 The system has the ability to easily track and report workflow during the entire patient visit process utilizing an integrated Patient Flow Tracking and Reporting module. Explain.


19.3 Health Information Management 19.3.1 Release of information ☐ ☐ ☐ Click here to enter text. 19.3.1.1 The system provides comprehensive tracking for the

release of patient information to all sources ☐ ☐ ☐ Click here to enter text.

19.3.1.2 The system allows administrators to define and customize categories of releases


19.3.1.3 The system provides on demand reporting of the release of information


19.3.1.4 The system provides granular security to restrict the release of PHI by user, user security classification, and patient


19.3.2 Imaging System ☐ ☐ ☐ Click here to enter text. 19.3.2.1 The system allows administrators to define and

customize imaging categories ☐ ☐ ☐ Click here to enter text.

19.3.2.2 The system allows the import of multiple types of image and document formats into the imaging system


19.3.2.3 The system allows users to view multiple image and document types within the application


19.3.2.4 The system provides granular security to restrict access to imaging categories by user, user security classification, and patient



19.4 Referrals 19.4.1 The referrals system is fully integrated between the PM

and EHR ☐ ☐ ☐ Click here to enter text.

19.4.2 The referral system provides the ability to issue, view, verify the status, or work a referral on both the PM and EHR interfaces


19.4.3 The referral system provides a comprehensive tracking mechanism to follow the status of a referral throughout its lifecycle


19.4.4 The referral system provides a comprehensive reporting tool to provide the status of all referrals in the tracking system


19.5 Billing 19.5.1 Pending Charges 19.5.1.1 Ability to pass critical information directly from the

EHR into the PM pending charges window to allow efficient paperless billing, including:


19.5.1.1.1 Location ☐ ☐ ☐ Click here to enter text. 19.5.1.1.2 Department ☐ ☐ ☐ Click here to enter text. 19.5.1.1.3 Program ☐ ☐ ☐ Click here to enter text. 19.5.1.1.4 Sliding fee level ☐ ☐ ☐ Click here to enter text. 19.5.1.1.5 Other ☐ ☐ ☐ Click here to enter text. 19.5.2 Billing Sorting and Tasking 19.5.2.1 Ability to sort and task billing by: ☐ ☐ ☐ Click here to enter text. 19.5.2.1.1 Carrier and carrier class ☐ ☐ ☐ Click here to enter text. 19.5.2.1.2 Sliding fee ☐ ☐ ☐ Click here to enter text. 19.5.2.1.3 Department ☐ ☐ ☐ Click here to enter text. 19.5.2.1.4 Location ☐ ☐ ☐ Click here to enter text. 19.5.2.1.5 Program ☐ ☐ ☐ Click here to enter text. 19.5.2.1.6 Other ☐ ☐ ☐ Click here to enter text. 19.5.3 Provide a detailed description of the Claims and Claims

tracking processes as the information flows through the PM billing system, to the preferred clearinghouse, and back into the system.


19.5.4 Provide a detailed description of the ERA process related to the information flow from the clearinghouse back into the PM billing system, posting to the carrier, and ultimately the patient account.


19.5.5 PPS Rate 19.5.5.1 Medicare PPS 19.5.5.1.1 System facilitates the posting of charges, including

calculations of PPS rates, enhanced rates, identification of qualifying visit, preventive exclusions, patient coinsurance, and adjustments under the Prospective Payment System (PPS) federal regulation methodology for FQHC’s under the Final Rule (79 FR 25436) for Centers for Medicare & Medicaid Services (CMS).



19.5.5.1.2 System provides a Medicare PPS Maintenance File to store present date and historical dated PPS rates and enhanced rates as well as facilitate procedure codes accepted for PPS methodology billing.


19.5.5.2 Medicaid PPS 19.5.5.2.1 System facilitates the posting of charges, including

calculations of PPS rate, identification of qualifying visit, and adjustments under the Prospective Payment System (PPS) federal regulation methodology for FQHCS.


19.5.5.2.2 System provides a Medicaid PPS Maintenance File to store present date and historical dated PPS rates as well as facilitate procedures codes accepted for PPS methodology billing.


19.5.6 Wrap Payments 19.5.6.1 Medicare Wrap Payments 19.5.6.1.1 Provide a detailed description of how the system

facilitates billing for supplemental payments (WRAP) for Medicare FQHCs under the industry standard PPS methodology. For example, Revenue code 519 on all charges, FQHC visit code auto loads with WRAP rate due from Medicare Part A, ALL CPTs submitted to Medicare Advantage plan also mirrored on Medicare Wrap claim with accompanying FQHC visit code and WRAP Rate is the balance due on the FQHC visit code. Additionally, mirrored/duplicated charges are NOT included in the financial records.


19.5.6.1.2 Does the Medicare WRAP utilize/share the original procedure code lines submitted to the Medicare Advantage plan or does the system create new procedure codes for the Medicare WRAP claim?


19.5.6.1.3 System provides a Medicare WRAP Maintenance File, unique to each Contractor ID, to store present date and historical dated WRAP rates as well as identify visit codes accepted for PPS methodology billing.


19.5.6.2 Medicaid Wrap Payments 19.5.6.2.1 Provide a detailed description of how the system

facilitates billing for the WRAP for State Medicaid FQHCs under the PPS methodology.


19.5.6.2.2 For example, MCO pays claim at Fee For Service rate (FFS) and Medicaid is responsible for the Medicaid PPS rate minus the MCO FFS rate and patient copay. Initial claim submitted to MCO for all services performed, WRAP RATE charge posted automatically to system (at time of MCO payment posting) for KY Medicaid responsible amount. Separate A/R’s accumulate for MCO and KY Medicaid.



19.5.6.2.3 Does the Medicaid WRAP utilize/share the original procedure code lines submitted to the Medicaid MCO or does the system create new procedure codes for the Medicaid WRAP claim?


19.5.6.2.4 System provides a Medicaid WRAP Maintenance File to store present date and historical dated WRAP rates as well as identify visit codes accepted for PPS methodology billing.


19.5.7 Clearinghouse Services 19.5.7.1 Are clearinghouse services provided by the system

vendor or negotiated independently with the clearinghouse service provider?


19.5.7.2 Explain the integration of clearinghouse services in detail


19.5.7.3 Are there choices of fully integrated clearinghouse vendors available?


19.5.7.4 Explain how remittance advice is integrated ☐ ☐ ☐ Click here to enter text. 19.5.7.5 Explain the automated posting process ☐ ☐ ☐ Click here to enter text. 19.5.7.6 Explain the claims scrubbing process ☐ ☐ ☐ Click here to enter text. 19.5.7.7 Patient Statements ☐ ☐ ☐ Click here to enter text. 19.5.7.7.1 Cost for first page? ☐ ☐ ☐ Click here to enter text. 19.5.7.7.2 Cost for second page? ☐ ☐ ☐ Click here to enter text. 19.5.7.7.3 Are there alternative electronic methods to provide

patient statements? Provide methods and a cost associated with each.


19.5.7.8 Explain in detail the integrated and independent clearinghouse reporting capabilities


19.5.7.9 Can the end user contact both the clearinghouse and the system vendor directly for support issues?


19.5.8 Labs - The system has the ability to allow same diagnosis on multiple lab procedure codes on the same date of service.


19.5.9 Zero Dollar Charges – How does the system submit procedure codes assigned a $0.00 standard fee, i.e. HCPCS reporting codes such as BMI and Vaccine for Children (VFC) Immunizations?


19.5.10 Dropping of charges – Explain in detail when a charge is dropped to Billing, i.e. Lab charges (order vs performed) and Chart Notes that have not been signed off on and are still in process but not complete.


19.5.11 Explain the process of noting and tracking Lot # of IUDs/Implants (Procedure Note vs Drug List)


19.5.12 The system has the ability to sort and reorder the “Inactive Insurance Plans” for viewing on the patient account.


19.5.13 The system has the ability pull more than first three plans loaded in set coverage for reporting. (i.e. Medicaid numbers when patient is enrolled in MCO. Medicaid is not active plan, MCO is active plan.)



F. EDR System Capabilities (Respond with answer and a description of the proposed solution in the comments section when applicable, * denotes additional cost)

1. Diagnosis and Treatment Planning Yes Yes* No Comments / Clarifications 1.1 Comprehensive display of treatment, both planned and

completed can be displayed. ☐ ☐ ☐

1.2 Treatment plans can be constructed in phases and sequences.

☐ ☐ ☐

1.3 Onscreen treatment planning is available. ☐ ☐ ☐

1.4 Ability to maintain a real-time list of pending treatment plans is available to query for scheduling purposes.

☐ ☐ ☐

1.5 Pending and performed procedures are tracked; reports can be produced.

☐ ☐ ☐

1.6 Treatment plan can be divided into specific visits with financial requirements, timeline, and notes.

☐ ☐ ☐

1.7 Multiple treatment plans can be stored and generated for one patient.

☐ ☐ ☐

1.8 Deleted and/or changed treatment plan items are identified and retained.

☐ ☐ ☐

1.9 Printed treatment plans indicate date, time, and user printing the treatment plan.

☐ ☐ ☐

1.10 Explanatory/progress notes can be stored with individual treatment plan items.

☐ ☐ ☐

1.11 Treatment plans can be deleted, or can be identified and retained.

☐ ☐ ☐

1.12 Treatment plans are customizable based on clinical findings.

☐ ☐ ☐

1.13 The system automatically calculates insurance benefits and patient financial liability when entering procedures on a treatment plan.

☐ ☐ ☐

1.14 Treatment plans can be monitored by medical diagnosis. ☐ ☐ ☐

1.15 Treatment plans can be tracked from any computer for all locations and or specific criteria on screen.

☐ ☐ ☐

1.16 Lab tracking is integrated into EDR allowing labs to be checked in and on screen reporting indicating lab work in house for scheduled patients.

☐ ☐ ☐

1.17 The system allows charting by exception. ☐ ☐ ☐

1.18 The system can generate next appointment information and multi-lingual patient reminders. List available languages.

☐ ☐ ☐

1.19 Treatment plan provides relevant information to Dental PM to aid in next appointment scheduling.

☐ ☐ ☐

1.20 Existing treatment plans can be re-prioritized. ☐ ☐ ☐

1.21 Users can create treatment plan templates. ☐ ☐ ☐

1.22 Ability to treat certain categories of patients without a treatment plan, e.g., emergencies.

☐ ☐ ☐

1.23 Existing treatment plans can be altered to add other treatment and to re- sequence visits.

☐ ☐ ☐

1.24 Electronic signature capture ability for treatment plans. ☐ ☐ ☐

1.25 Ability to incorporate treatment plans/Digital images into provider notes and save into EHR record.

☐ ☐ ☐

1.26 Ability to submit treatment plans to insurance companies for pre-authorization.

☐ ☐ ☐


1.27 Ability to submit corresponding x-ray and attachments with pre-authorizations.

☐ ☐ ☐

2. Charting Ability Yes Yes* No Comments / Clarifications 2.1 Supernumerary teeth in primary and permanent dentitions. ☐ ☐ ☐

2.2 Chart clearly displays crowns, bridges, root canals, posts and pins.

☐ ☐ ☐

2.3 Ability to view radiographs on the same screen as the area being charted and associate to a specific encounter.

☐ ☐ ☐

2.4 Ability to see date of exam on tooth charting and periodontal charting.

☐ ☐ ☐

2.5 Ability to conduct a periodontal screening and recording (PSR) independent of a full mouth periodontal exam.

☐ ☐ ☐

2.6 Allows all treatment progress notes to be shared with the Intergy EHR.

☐ ☐ ☐

2.7 Customizable practice defined full mouth periodontal exam templates.

☐ ☐ ☐

2.8 Allows concurrent access to patient charts and images by dental staff in multiple geographic locations is supported.

☐ ☐ ☐

2.9 EDR displays simultaneous views of gingival and periodontal pockets over time.

☐ ☐ ☐

2.10 “Watch” area may be viewed and marked on a specific tooth.

☐ ☐ ☐

2.11 Tooth anomalies/conditions can be created and charted. ☐ ☐ ☐

2.12 Ability to include restorative, periodontal and PSR charts in treatment notes.

☐ ☐ ☐

3. Patient History Yes Yes* No Comments / Clarifications 3.1 Multiple users without regard to location can view

radiographs or intraoral images simultaneously in EDR ☐ ☐ ☐

3.2 Ability to view series of radiograph “thumb nail” views with option to “zoom preview” the details of a selected image.

☐ ☐ ☐

3.3 The EDR System is integrated with radiographic module to provide x-ray mount views and individual PA or panoramic images available in charting screen with zoom and image manipulation capability.

☐ ☐ ☐

3.4 The imaging system supports multiple types of radiographic devices including Sensors, Panoramic units and intraoral cameras.

☐ ☐ ☐

3.5 The EDR system allows for encrypted transmittal of any images or treatment notes from EDR to outside entities.

☐ ☐ ☐

3.6 The EDR and Digital Imaging System utilize a single database that records all x-rays; there is no requirement to install or maintain separate servers for each dental clinic.

☐ ☐ ☐

3.7 Image capture software will be provided and maintained by same vendor as EDR/EHR software.

☐ ☐ ☐

3.8 Ability to submit x-rays to NEA for claims without using 3rd party NEA application.

☐ ☐ ☐

3.9 Ability to include x-rays in treatment notes in EDR and EHR if desired.

☐ ☐ ☐

3.10 Password credentials pass from either Practice Management, or EDR charting module to digital radiography database.

☐ ☐ ☐


3.11 System is fully integrated with radiographic software to access image from EDR without logging into radiograph application.

☐ ☐ ☐

3.12 Supports hyperlink/connection between EDR and EHR. ☐ ☐ ☐

3.13 Supports radiographic history review to allow users compare images.

☐ ☐ ☐

4. Document Scanning Yes Yes* No Comments / Clarifications 4.1 Module is compatible with duplex scanner software

allowing scanning of two sides of documents at once. ☐ ☐ ☐

4.2 Compatible with a wide variety of commercially available scanners.

☐ ☐ ☐

5. Peripheral Device Connectivity Yes Yes* No Comments / Clarifications 5.1 Compatible with commercially available electronic probing

system for periodontal charting. ☐ ☐ ☐

5.2 Supports electronic signature devices for registration and consent forms.

☐ ☐ ☐

5.3 Supports point of care documentation through mobile technology, e.g., handhelds, tablets, etc. List types of mobile technology currently compatible with system.

☐ ☐ ☐

5.4 Compatible with a wide variety of commercially available printers.

☐ ☐ ☐

6. Productivity Management Yes Yes* No Comments / Clarifications 6.1 System tracks and reports canceled and broken

appointments. ☐ ☐ ☐

6.2 Automatic calculation of patient’s no show rate generates “No Show Message” and blocks new appointment scheduling.

☐ ☐ ☐

6.3 Shows lost productivity caused by broken appointments. ☐ ☐ ☐

6.4 Calculates average production and collection per patient over a date range by provider.

☐ ☐ ☐

6.5 Allows appointment rescheduling for same provider on a different date/time or rescheduling to a different provider schedule.

☐ ☐ ☐

6.6 Tracks number of vacation, sick, personal, education and holiday time taken by providers.

☐ ☐ ☐

6.7 Patient tracking can be enabled to identify when a patient has progressed through phases of the treatment by color coding the dental schedule.

☐ ☐ ☐

6.8 Patient tracking summary can show number of patients: ☐ ☐ ☐

6.8.1 In waiting room. ☐ ☐ ☐

6.8.2 Waiting to be seen by dentist. ☐ ☐ ☐

6.8.3 Waiting to be seen by hygienist. ☐ ☐ ☐

6.8.4 Waiting to be seen by dental assistant. ☐ ☐ ☐

6.8.5 Waiting for check-out.

☐ ☐ ☐


7. Billing Yes Yes* No Comments / Clarifications 7.1 Supports FQHC/Medicaid bill by encounter rate

requirement. ☐ ☐ ☐

7.2 Calculates sliding scale fee for service based on federal poverty lines.

☐ ☐ ☐

7.3 Supports secure electronic billing to government payers. ☐ ☐ ☐

7.4 Prints insurance forms for completed and planned services.

☐ ☐ ☐

7.5 Generates day sheets for balancing daily deposits and billing.

☐ ☐ ☐

7.6 Account aging reports by 30-day increments. ☐ ☐ ☐

7.7 Changes estimated insurance portion when entering charges.

☐ ☐ ☐

7.8 Supports electronic remittance posting. ☐ ☐ ☐

7.9 Ability to transfer old balances to another responsible party.

☐ ☐ ☐

7.10 Open item accounting for insurance billing and tracking. ☐ ☐ ☐

7.11 Secondary insurance processing generated by primary insurance response.

☐ ☐ ☐

7.12 Ability to check insurance eligibility and insurer coverage for proposed treatment in real time.

☐ ☐ ☐

7.13 Account balance separated into previous balance, current day fees, third party coverage information, deductible, co-payment owed and remaining coverage.

☐ ☐ ☐

7.14 Statements can be printed for a single patient and reflect estimated insurance benefit and patient balance.

☐ ☐ ☐

7.15 Financial arrangements appear on the statement. ☐ ☐ ☐

8. Record Integration Across Geographically Disparate Sites Yes Yes* No Comments / Clarifications 8.1 All patient EDR records are immediately available to

properly authorized staff from any computer at any site. ☐ ☐ ☐

8.2 Can schedule a provider at multiple locations using the same provider number while alerting of scheduling conflicts.

☐ ☐ ☐

8.3 Online patient profile inquiry screen available at all sites. ☐ ☐ ☐

8.4 The system utilizes a single database to link geographically disparate sites.

☐ ☐ ☐

8.5 The system utilizes a single database for all EDR records including radiographs.

☐ ☐ ☐

9. Certification Standards Yes Yes* No Comments / Clarifications 9.1 Facilitates Joint Commission (JCAHO) medication

reconciliation between health records. ☐ ☐ ☐

9.2 Meets Joint Commission (JCAHO) standards for documenting time-out and final verification.

☐ ☐ ☐

9.3 The system meets Promoting Interoperability 2015 Certification standards via either Certified Health IT/ONC/CCHIT (list all certifications).

☐ ☐ ☐


10. Interface Capabilities Yes Yes* No Comments / Clarifications 10.1 The system supports the real time integration of patient

demographic information from the PM Management System

☐ ☐ ☐

10.2 The system supports the automatic transfer of dental procedure information from the EDR to the Intergy Practice Management Billing System via an HL7interface. This information includes specific procedure and diagnostic data, required to perform billing in Intergy.

☐ ☐ ☐

10.3 The system supports the automatic transfer of appointment information from the Intergy PM scheduling system to the EDR via an HL7 interface. This information includes specific appointment type and codes, provider, and related patient information required to create an identical appointment within the EDR scheduling system.

☐ ☐ ☐

10.4 The system exports required clinical findings to Intergy EHR to support unified health record reporting through the Greenway Practice Analytics Reporting system.

☐ ☐ ☐

10.5 The system supports a unified user login and security database with the Intergy Practice Management/EHR system.

☐ ☐ ☐

10.6 The system supports the independent order of patient labs and e-prescribing through the Intergy Practice Management and EHR system, providing more accurate prescription and lab data reconciliation.

☐ ☐ ☐

11. Practice Specific EDR Capabilities Yes Yes* No Comments / Clarifications 11.1 The EDR is fully integrated with the EHR and PM system ☐ ☐ ☐

11.2 The EDR provides a single patient health record containing all prescription, health history, diagnosis, allergies, demographic, and billing data.

☐ ☐ ☐

11.3 The images from the Digital Imaging System are fully integrated within the patient’s chart.

☐ ☐ ☐

11.4 The EDR provides a full integration with the Digital Imaging System.

☐ ☐ ☐

11.4.1 The EDR includes an integrated Digital Imaging System. ☐ ☐ ☐

11.4.2 The EDR provides integration, support, and full compatibility for third party Digital Imaging Systems including:

☐ ☐ ☐

11.4.2.1 Vatech (list) ☐ ☐ ☐

11.4.2.2 Other (list) ☐ ☐ ☐

11.5 The EDR supports fully integrated USB plug and play Dental Digital Imaging Sensor(s)

☐ ☐ ☐

11.6 The EDR supports customer owned signature capture and Digital Imaging hardware including:

☐ ☐ ☐

11.6.1 Vatech Intraoral Sensors (list models) ☐ ☐ ☐

11.6.2 Vatech Digital Network PANO (list models) ☐ ☐ ☐

11.6.3 Topaz Digital Signature Pads (list models) ☐ ☐ ☐

11.7 The system provides full function EDR and Digital Imaging System Workstation license(s); including but not limited to full EDR client and diagnostic quality image viewer. qty. 35

☐ ☐ ☐


11.8 The system provides capability to support multiple clinical locations across a wide area network.

☐ ☐ ☐

11.9 Capability to import existing scanned clinical and film study data.

☐ ☐ ☐

11.10 Capability to retain historical account, patient, and dental chart numbers from the legacy system(s).

☐ ☐ ☐

11.11 Capability to track and report Promoting Interoperability and UDS statistics

☐ ☐ ☐

11.12 Capability to support current FHC Dental Department workflows as required.

☐ ☐ ☐

11.13 Must be scalable based on number of exams ☐ ☐ ☐

11.14 Fully HL7 and DICOM Compliant ☐ ☐ ☐

11.15 Provides ability to scan documents ☐ ☐ ☐

11.16 Provides Image Import from CD/DVD, USB storage device, DICOM, and Non-DICOM formats

☐ ☐ ☐

11.17 Provides customer controlled DICOM Field remapping ☐ ☐ ☐

11.18 Provides capability to burn images to a CD/DVD, or USB storage device for patient referrals

☐ ☐ ☐

11.19 Accepts plug and play storage upgrades ☐ ☐ ☐

11.20 Supports HIPAA compliant encryption ☐ ☐ ☐

11.21 The systems allows multiple users be logged and documenting different parts of the same patient chart simultaneously.

☐ ☐ ☐

11.22 The system provides electronic recall functionality. ☐ ☐ ☐

11.23 The system is capable of importing existing radiographic images and odontogram chart information from the practices MediaDent EDR.

☐ ☐ ☐


G. Reporting System Capabilities (Respond with answer and a description of the proposed solution in the comments section when applicable, * denotes additional cost)

1. Reporting System Yes Yes* No Comments / Clarifications 1.1 Predefined Reports 1.1.1 CHC (list) ☐ ☐ ☐ Click here to enter text. 1.1.2 Financial (list) ☐ ☐ ☐ Click here to enter text. 1.1.3 Provider (list) ☐ ☐ ☐ Click here to enter text. 1.1.4 Site specific (list) ☐ ☐ ☐ Click here to enter text. 1.1.5 Department specific (list) ☐ ☐ ☐ Click here to enter text. 1.1.6 Program specific (list) ☐ ☐ ☐ Click here to enter text. 1.1.7 Carrier class specific (list) ☐ ☐ ☐ Click here to enter text. 1.1.8 Program (list) ☐ ☐ ☐ Click here to enter text. 1.1.9 Other (list) ☐ ☐ ☐ Click here to enter text. 1.2 Specialty Reports 1.2.1 UDS (list) ☐ ☐ ☐ Click here to enter text. 1.2.2 Promoting Interoperability (Meaningful Use) ☐ ☐ ☐ Click here to enter text. 1.2.3 MIPS ☐ ☐ ☐ Click here to enter text. 1.2.4 PCMH ☐ ☐ ☐ Click here to enter text. 1.2.4.1 Joint Commission ☐ ☐ ☐ Click here to enter text. 1.2.4.2 NCQA ☐ ☐ ☐ Click here to enter text. 1.2.5 PRAPARE ☐ ☐ ☐ Click here to enter text. 1.2.6 Family Planning (FPAR) 1.2.7 Other ☐ ☐ ☐ Click here to enter text. 1.3 Dashboard Reports 1.3.1 Productivity (list) ☐ ☐ ☐ Click here to enter text. 1.3.2 Financial (list) ☐ ☐ ☐ Click here to enter text. 1.3.3 UDS (list) ☐ ☐ ☐ Click here to enter text. 1.3.4 Promoting Interoperability (Meaningful Use) ☐ ☐ ☐ Click here to enter text. 1.3.5 MIPS ☐ ☐ ☐ Click here to enter text. 1.3.6 PCMH ☐ ☐ ☐ Click here to enter text. 1.3.6.1 Joint Commission ☐ ☐ ☐ Click here to enter text. 1.3.6.2 NCQA ☐ ☐ ☐ Click here to enter text. 1.3.7 Clinical Quality Measures (CQM) 1.3.7.1 Health outcomes (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.2 Clinical processes (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.3 Patient safety (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.4 Efficient use of health care resources (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.5 Care coordination (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.6 Patient engagement (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.7 Population and public health (list) ☐ ☐ ☐ Click here to enter text. 1.3.7.8 Adherence to clinical guidelines (list) ☐ ☐ ☐ Click here to enter text.


1.4 Custom Reporting 1.4.1 Integrated internal report writer ☐ ☐ ☐ Click here to enter text. 1.4.1.1 System design and function Click here to enter text. 1.4.1.2 System capabilities Click here to enter text. 1.4.1.3 Data mapping and integration with Integrated EHR

database Click here to enter text.

1.4.1.4 Ability to create, save, and distribute custom reports Click here to enter text. 1.4.1.5 Method of developing detailed reporting processes

not included in default report tools (Cognos, Crystal, BI, integrated external generator, other) (list)


1.4.1.6 Vendor support and training for report tools ☐ ☐ ☐ Click here to enter text. 1.4.2 Integrated external reporting system ☐ ☐ ☐ Click here to enter text. 1.4.2.1 System design and function Click here to enter text. 1.4.2.2 System capabilities Click here to enter text. 1.4.2.3 Data mapping and integration with Integrated EHR

database Click here to enter text.

1.4.2.4 Ability to create, save, and distribute custom reports ☐ ☐ ☐ Click here to enter text. 1.4.2.5 Method of developing detailed reporting processes

not included in default report tools (Cognos, Crystal, BI, integrated external generator, other) (list)


1.4.2.6 Vendor support and training for custom report tools ☐ ☐ ☐ Click here to enter text. 1.4.3 Vendors capability to replicate existing mission critical

reports prior to go live ☐ ☐ ☐ Click here to enter text.

1.4.4 Cost and method to acquire vendor supplied custom reports


1.4.5 The system has the ability to schedule and run reports automatically.


1.4.6 The system has the ability to query either “Real Time” and/or “Mirrored” datasets for specific reporting purposes. (explain)



H. Population Health System Capabilities (Respond with answer and a description of the proposed solution in the comments section when applicable, * denotes additional cost)

1. Population Health/Chronic Disease Management Yes Yes* No Comments / Clarifications 1.1 The system includes a fully integrated and full feature

Population Health System. ☐ ☐ ☐

1.2 The Population Health System is fully integrated with the EHR and reporting system.

1.3 The Population Health System pulls data from multiple sources of data within the EHR, EDR, and PM system database, including:

☐ ☐ ☐

1.3.1 CCDA ☐ ☐ ☐

1.3.2 Diagnosis Codes ☐ ☐ ☐

1.3.3 Procedure Codes ☐ ☐ ☐

1.3.4 Charge Data (Billing System) ☐ ☐ ☐

1.3.5 Other EHR/PM/EDR internal data sources (list) ☐ ☐ ☐

1.4 The Population Health System has the ability to integrate with third party data sources, including:

☐ ☐ ☐

1.4.1 Third party payors ☐ ☐ ☐

1.4.2 CommonWell ☐ ☐ ☐

1.4.3 CareQuality ☐ ☐ ☐

1.4.4 Health Information Registry(s) ☐ ☐ ☐

1.4.5 Other external health registry data sources (list) ☐ ☐ ☐

1.5 The system provides support for the management of populations of patients that share diagnoses, problems, demographic characteristics, etc.

☐ ☐ ☐

1.6 The system supports disease management registries by: 1.6.1 Allowing patient tracking and follow-up based on user

defined diagnoses ☐ ☐ ☐

1.6.2 Integrating all patient information within the system ☐ ☐ ☐

1.6.3 Providing a longitudinal view of the patient medical history

☐ ☐ ☐

1.6.4 Providing a longitudinal view of the patient’s demographic and social history, including occupation, industry worked in, and residential address

☐ ☐ ☐

1.7 The Population Health component is integrated with all patient information within the system

☐ ☐ ☐

1.8 The system is capable of submitting electronically syndromic surveillance data to public health agencies in accordance with applicable law and practice.

☐ ☐ ☐

1.9 The system can differentiate between currently active and historical/inactive providers and can readily accommodate and designate providers who have left clinical practices.

☐ ☐ ☐

1.10 The system automatically identifies all high-risk patients, including high risk OB, and notifies clinical staff for preventive care.

☐ ☐ ☐

1.11 The system utilizes user authored and/or third party developed clinical guidelines for disease and registry management.

☐ ☐ ☐

1.12 The system tracks / provides reminders and validates care process against clinical practice guidelines.

☐ ☐ ☐


1. Population Health/Chronic Disease Management Yes Yes* No Comments / Clarifications 1.13 The system generates follow-up letters to physicians,

consultants, external sources, and patients based on a variety of parameters such as date, time since last event, etc. for collecting health data and functional status for updating the patient’s record.

☐ ☐ ☐

1.14 Reporting 1.14.1 The system includes integrated population health

reports dashboard reports (list) ☐ ☐ ☐

1.14.1.1 Dashboard reports are user definable ☐ ☐ ☐

1.14.2 At minimum, the system is able to generate a variety of reports based on performance measures identified by: {Information on these measures can be found at: http://www.ama-assn.org/ama/pub/category/4837.html. The system follows measures approved by NQF (national quality form) and prompted by the AQA (ambulatory quality alliance) as well as those identified by the HRSA’s Health Disparities Collaborative, see http://www.healthdisparities.net/ } 1.14.2.1 Physician Consortium for Performance Improvement

(AMA/Consortium) ☐ ☐ ☐

1.14.2.2 Centers for Medicare & Medicaid Services (CMS) ☐ ☐ ☐

1.14.2.3 National Committee for Quality Assurance (NCQA) chronic diseases including:

☐ ☐ ☐

1.14.2.3.1 diabetes ☐ ☐ ☐

1.14.2.3.2 coronary artery disease ☐ ☐ ☐

1.14.2.3.3 heart failure ☐ ☐ ☐

1.14.2.3.4 behavioral health ☐ ☐ ☐

1.14.2.3.5 hypertension ☐ ☐ ☐

1.14.2.3.6 childhood developmental delay ☐ ☐ ☐

1.14.2.3.7 osteoarthritis ☐ ☐ ☐

1.14.2.3.8 asthma ☐ ☐ ☐

1.14.2.3.9 prenatal care ☐ ☐ ☐

1.14.2.3.10 immunizations ☐ ☐ ☐

1.14.2.3.11 colorectal cancer screening ☐ ☐ ☐

1.14.2.3.12 cervical cancer screening ☐ ☐ ☐

1.14.2.3.13 breast cancer screening ☐ ☐ ☐

1.14.2.3.14 lead testing ☐ ☐ ☐

1.14.2.3.15 tobacco use cessation ☐ ☐ ☐

1.14.2.3.16 problem drinking ☐ ☐ ☐

1.15 The system links Disease Management functions to all other sections of the EHR.

☐ ☐ ☐

1.16 The Population Health System is certified or accredited by a qualified certification agency. (i.e. NCQA, PHAB, etc.)

☐ ☐ ☐

http://www.ama-assn.org/ama/pub/category/4837.html

http://www.healthdisparities.net/



I. Integrated EHR System Minimum Technical Specifications and Functional Requirements

(Respond with proposed solution capabilities and configuration)

• Supports Microsoft Windows Server 2016 (or higher) compliant operating system • Supports Microsoft SQL 2016 (or higher) database or full ODBC compliant substitute • Supports Microsoft Active Directory and/or LDAP Integration • Supports Local Client Server Architecture • Supports Web Client Architecture • Supports Microsoft Terminal Server and/or Citrix Server

o Published Application o Published Desktop

• Supports VMware virtualization 6.7 or higher • Provides automated backup of all data to NAS, or SAN • Support for Wide Area Network • Vendors to provide 24/7, 365 emergency support • Vendors to guarantee a maximum response time of 4 hours for critical issues

Specifications listed above are recommended minimums, provide a full list of specifications, and features in your response. If the minimum specifications are not met in the response, explain why and what alternate solution is being proposed.


J. Customer Supplied Hardware & Software Options (Provide a detailed response for each proposed option)

1. Server Hardware (General)

FHC has elected to provide the required server components independent of the integrated EHR system contract and has elected to utilize virtualization. The systems virtual severs will be installed in a VMWare VSphere Enterprise Plus 6.7 virtual environment supported by a substantial Dell Server and Dell EMC SANS infrastructure. The servers will be installed and configured by FHC IS personnel utilizing Microsoft licensing procured by FHC independent of the contract. The servers will be built to vendor supplied hardware and software specifications. If compatibility issues exists or customer provided virtualization is not supported by the vendor, it must be specifically stated in the RFP response. An addendum detailing the required changes and/or costs must also be listed. FHC will work collaboratively with the selected vendor to ensure that minimum specifications for the components are met or exceeded. FHC will be responsible for procuring all Microsoft Server and SQL licensing, as well as building the virtual server(s) to meet the potential vendor’s specifications. FHC also accepts responsibility to add to, replace, or upgrade the existing workstations to meet vendor specifications.

2. Microsoft Server and Database Software

FHC has elected to provide the Microsoft Server and Microsoft SQL database software required to implement the Integrated EHR, independent of the contract. Since FHC participates in Microsoft’s charity pricing program and has the ability to purchase these items at a greatly reduced cost; allowing FHC to supply these components may directly affect a vendor’s ability to provide a competitive price. The prospective vendor is required to list all necessary Microsoft server and/or database software requirements separately in the RFP and clearly denote which components are and are not included in the RFP response. If the vendor elects to provide the server and database components as part of the contract, or uses an alternate server or database architecture this must also be clearly denoted in the RFP response. FHC will work collaboratively with the selected vendor to ensure that all minimum specifications for software components are met or exceeded.

3. Virtual Environment Support

FHC has an established VMware virtual environment; if applicable FHC desires to leverage the substantial infrastructure already in place. Any compatibility or support issues regarding FHC’s existing “VMware VSphere Enterprise Plus version 6.7” environment should be outlined in the proposal. The virtual environment utilizes 6 Dell


PowerEdge R630 ESXi host servers and a Dell SANS infrastructure (detailed below). The virtual environment is maintained by the FHC Information Systems (IS) department and has should have ample capacity and performance to support the proposed system and processes. If implementing any or all of the proposed system on a VMware platform is a supported option these processes should be specifically identified in the RFP response.

4. SANS Environment Support

FHC has an established SANS environment; when applicable FHC wants to leverage the substantial infrastructure already in place. Any compatibility or support issues regarding FHC’s existing enterprise SANS infrastructure (4 - Dell EqualLogic PS6210 – 10 GB iSCSI SANS, 1 - Dell EMC SCv3020 – 10 GB iSCSI SANS) should be outlined in the proposal. The virtual environment is maintained by the FHC Information Systems (IS) department and will have ample capacity and performance to support the proposed system and processes.

If implementing any or all of the proposed system on the existing SANS platform is a supported option these processes should be specifically identified in the RFP response.

5. Computer Workstation and Notebook Hardware Support

FHC has elected to provide the required computer workstations and notebooks independent of the Integrated EHR System contract. Most of notebooks and workstations are already in operation in the clinic, and will be upgraded or replaced by FHC IS personnel as required. Additional notebook and desktop computers will be added to meet the vendor’s specifications as system design requires. The workstations will meet vendor supplied hardware and software minimum specifications. If a compatibility issue exists or customer provided computers are not supported by the vendor, it must be specifically stated in the RFP response. An addendum detailing the required changes and/or costs must also be listed. FHC will work collaboratively with the selected vendor to ensure that minimum specifications for the components are met or exceeded.

6. Printer, Scanner, and Signature Pad Hardware Support

FHC has elected to provide the required printer, scanner, and signature pad hardware independent of the Integrated EHR System contract. Most of required peripherals are already in operation in the clinic, and will be upgraded or replaced by FHC IS personnel as required. Additional hardware will be added to meet the vendor’s specifications as system design requires. Provide a hardware compatibility list for printer, scanner, and signature pad requirements. For reference FHC has standardized on the following hardware platforms:


o Printers Kyocera and HP

o Scanners Fujitsu

o Signature Pads Topaz

All hardware will meet vendor supplied minimum specifications. If a compatibility issue exists or customer provided hardware is not supported by the vendor, it must be specifically stated in the RFP response. An addendum detailing the required changes and/or costs must also be listed. FHC will work collaboratively with the selected vendor to ensure that minimum specifications for the components are met or exceeded.


K. Internal Interface Capabilities As detailed in section (IV-B-2), FHC currently utilizes the Greenway Intergy EHR and Practice Management (PM) system for scheduling, billing, demographics, scanning, and reporting functions for the organization. The MediaDent EDR is used specifically for dental charting and imaging and is integrated with Intergy. This method allows FHC to centrally gather and report data for the Federal UDS and Promoting Interoperability requirements. FHC also routinely produces multiple financial and productivity the organization, all of which are generated by the Greenway Practice Analytics report generator. The proposed solution must provide the same method of central data warehousing and reporting. Furthermore, the Intergy database is utilized as the master patient record and is synchronized to multiple clinical systems within the organization. It is critical that any replacement solution serve the same role and become the master patient record for all related clinical systems. Unless otherwise defined and agreed upon, all of the functions described in this section will be integrated with the new EHR. It is vital that a well-developed interface exist between the Integrated EHR and all existing FHC clinical IT systems. Provide a written explanation of how the proposed solution will provide comparable functionality and respond in detail to the specific interface questions below.

1. Lab Information System (LIS) Interface - HL7/ADT FHC currently utilizes the Intergy EHR to place lab orders to the in-house Orchard Harvest LIS through the Clinician Labs Interface. All orders are received in the LIS and are either performed and resulted in house or sent to an outside lab for resulting and returned to the in-house LIS. Once the lab results are finalized within LIS the results are forwarded to the Clinician Labs Interface and are received in the Intergy EHR for final review. Define how the existing in-house LIS will interface with the proposed solution. Provide a detailed workflow and data mapping related for the integrated lab interface. Interface examples:

• LIS ADT Interfaces: o Demographic (PM to LIS) o Insurance (PM to LIS) o Sliding Fee Level (PM to LIS)

• LIS Lab Order Functions:

o Order and transmit (EHR to LIS) o Resulting and receive (LIS to EHR)


o Review and chart (EHR) o Billing (EHR to PM)

List all required professional services, software, and equipment required to accomplish the interface and be specific on which items are and are not covered in the RFP response. Give specific examples and provide references of how other clients using the same systems have performed integration in the RFP response. Costs associated with this interface must be clearly defined in the RFP response. Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include an explanation of which processes are automated and which are manual.

2. PACS System Interface – ADT/HL7/DICOM

FHC currently utilizes the Intergy EHR to order PACS studies in the in-house GE Centricity Universal Viewer with PACS-IWPACS. The orders are placed in the Intergy EHR electronically, printed on paper, and presented in radiology at the time of the study. When a patient arrives in radiology, a member of the radiology staff creates a modified appointment in the Intergy PM, which automatically populates a worklist entry in the CR modality. The CR modality is directly interfaced to the PACS system and when completed the image study is transmitted to the PACS. When reviewed the radiology staff transmits the DICOM images to an offsite radiologist for reading via an integrated VPN connection. When the studies are finalized by the offsite radiologist a report is sent back to the FHC PACS system from the remote PACS through the same VPN connection. The electronic result is stored in PACS system along with the original study as a DICOM image. A copy of the final report is also forwarded to the FHC HIM department for scanning into the EHR and to create a review task for the ordering provider. Define how FHC’s existing PACS will interface with the proposed solution. Provide a detailed workflow and data mapping related for the integrated lab interface. Interface examples:

• PACS - ADT/HL7 Interfaces: o Demographic (PM to PACS) o Scheduling (PM to CR Modality) o Orders* (EHR to PACS) o Billing (EHR to PM)

• PACS – DICOM Interfaces:

o Reports (PACS to EHR) o Images (PACS to EHR)



3. Retail Pharmacy System Interface – ADT/HL7

FHC operates three retail pharmacies at the Portland, East Broadway, and Phoenix locations. FHC pharmacies utilize only 340B drugs and fill prescriptions for FHC patients exclusively. The three pharmacy locations utilize a single Liberty Retail Pharmacy System to perform all retail pharmacy functions including RX receive, transmit, check, fill, and reporting functions. Currently the Liberty Retail Pharmacy server resides in the FHC Data Center and receives electronic prescriptions via SureScripts but is not interfaced with the Intergy EHR in any other way. FHC desires to interface the Liberty Retail Pharmacy server to the proposed Integrated EHR as part of the overall project. The requirements are to synchronize the two similar but unique demographic databases and create a real time ADT and HL7 interface. Examples of data to be synchronized with the new interface:

• Pharmacy - ADT/HL7 Interfaces: o Demographic (PM to Pharmacy) o Sliding Fee Level (PM to Pharmacy)


4. Digital Dental Imaging System


Digital images will be captured and stored within the Dental Digital Imaging System and be transferred to the EDR through the use of an HL7/DICOM interface. Define how this interface operates in detail; include the method of generating a new study, how demographic and clinical information is reconciled, define where and when the images are stored, define how images are captured via modalities such as digital sensors and PANOs and how studies are marked complete and images are sent to the EDR. Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include an explanation of which processes are automated and which are manual.

5. Dental Intraoral Digital Sensors

Intraoral x-ray images are captured utilizing Vatech Digital Dental Sensors. Define how the images will be captured and transmitted to the Digital Imaging and EDR System(s) and be imported into the appropriate patient’s dental record. Denote the use of HL7, DICOM, or other standards in the process and how a new study is created in the EDR and Digital Imaging System(s). Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include an explanation of which processes are automated and which are manual.

6. Dental Digital Panoramic X-Ray (PAN) X-ray images will be captured utilizing Vatech Digital Panoramic Dental X-Ray machines. Define how a worklist will be developed for the PAN and how the images will be transmitted to the Digital Imaging and EDR System(s) and be imported into the appropriate patient’s dental record. Denote the use of HL7, DICOM, or other standards in the process and how a new study is created in the EDR and Digital Imaging System(s). Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include an explanation of which processes are automated and which are manual. Any costs and/or professional services associated with the defined interface capabilities must be clearly defined in the RFP response.


L. External Interface Capabilities The proposed solution must provide a secure and reliable method to connect to outside health organizations, registries, and data sources within the standard EHR workflow. The integration of patient data from outside sources is a critical component to ensure that a medical provider make the most knowledgeable medical decisions, and deliver the highest quality patient care. The integration of data from outside resources is also required to complete care gaps and provide the organization with a more complete map of the patient’s medical history. Provide a complete description of how the proposed solution is integrated with the external data sources listed below. Be specific and detail the workflow, contractual agreements, and technical components required to complete each interface and how the external data can be imported into the patients electronic chart. Provide a detailed security matrix of how sensitive patient information can be excluded or filtered from being sent to outside of the EHR. List methods of tagging PHI and patients as confidential and excluding from external transmission. Methods include:

• Patient • Encounter • Provider • Service Location • Visit Type • Department • Diagnosis • Procedure • Lab • Program • Section of Chart • Other

1. CareQuality

Utilizing the parameters defined above, provide a detailed description of the proposed systems capabilities to integrate with CareQuality.

List all required professional services, software, and equipment required to accomplish the integration and be specific on which items are and are not covered in the RFP response. Give specific examples and provide references of how other clients using the same systems have performed integration in the RFP response. Costs associated with this interface must be clearly defined in the RFP response.


Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include specific security protocols and an explanation of which processes are automated and which are manual.

2. CommonWell Utilizing the parameters defined above, provide a detailed description of the proposed systems capabilities to integrate with CommonWell. List all required professional services, software, and equipment required to accomplish the integration and be specific on which items are and are not covered in the RFP response. Give specific examples and provide references of how other clients using the same systems have performed integration in the RFP response. Costs associated with this interface must be clearly defined in the RFP response. Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include specific security protocols and an explanation of which processes are automated and which are manual.

3. Kentucky Health Information Exchange (KHIE) Utilizing the parameters defined above, provide a detailed description of the proposed systems capabilities to integrate with the KHIE. List all required professional services, software, and equipment required to accomplish the integration and be specific on which items are and are not covered in the RFP response. Give specific examples and provide references of how other clients using the same systems have performed integration in the RFP response. Costs associated with this interface must be clearly defined in the RFP response. Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include specific security protocols and an explanation of which processes are automated and which are manual.


4. Kentucky Health Information Exchange (KHIE) – Vaccine Registry Utilizing the parameters defined above, provide a detailed description of the proposed systems capabilities to integrate with the KHIE Vaccine Registry. List all required professional services, software, and equipment required to accomplish the integration and be specific on which items are and are not covered in the RFP response. Give specific examples and provide references of how other clients using the same systems have performed integration in the RFP response. Costs associated with this interface must be clearly defined in the RFP response. Explain using industry standard terminology how this interface will work in a step by step method and where and when each step of the process will be performed. Include specific security protocols and an explanation of which processes are automated and which are manual.


M. Data Conversion Capabilities As detailed in section (IV-B-1), FHC currently utilizes the Greenway Intergy EHR and Practice Management (PM) system for scheduling, billing, demographics, scanning, HIM, and reporting functions. The Greenway MediaDent system is used for dental specific charting and imaging. Both of these systems contain vital patient data that needs to be converted into the new system. As a defined part of the Integrated EHR project FHC needs to import the following information for patients seen in the last two years:

• Intergy Patient Number • Intergy Chart Number • Intergy Account Number • Patient Demographics • Sliding Fee Classification • Sliding Fee Expiration • Images from PM Imaging System • Visit Data • Appointments • EHR Visit Notes • Problem Lists • Immunizations • Allergies • Labs • Medications • Dental

o Periodontal Charting o Treatment Plan o Progress Notes o Images o Odontograms

• Exclude Deceased and Not Fully Registered Patients • Other Related PHI (to be discussed with vendor)

FHC will assist in this process by providing a CSV data export from the Greenway Practice Analytics System. Explain using industry standard terminology how this process will work in a step by step method and where and when each step of the process will be performed and how the resulting record(s) will appear in the proposed Integrated EHR.


Any costs and/or professional services associated with the defined import/conversion must be clearly defined in the RFP response.

N. Qualifications & Equivalencies

Specifications listed above are defined as minimum required, and must be met before submitting an RFP response. Referenced specifications can be met with equivalent standards where applicable or exceeded without authorization by FHC. If the system to be provided that doesn’t meet the standards, an equivalency where applicable, must be agreed upon by FHC and the vendor prior to the RFP submission. Failure to meet the required minimums or propose alternate system configuration or equipment without prior approval by FHC will result in the disqualification of the bid. If a vendor chooses to submit a bid proposing equipment that exceeds the bid specifications either as a primary or optional bid, clearly denote the differences in the submitted bid. In addition, only authorized dealers of the quoted systems or equipment will be permitted to participate in the RFP process. Wholesalers or liquidators who are not factory authorized or do not have the required support channels will have their bids disqualified.


V. Installation, Professional Services, & Support

A. Installation & Professional Services

1. Project Scope and Responsibilities

FHC responsibilities: • FHC assumes responsibility for providing the necessary power, local area network

ports, WAN and VPN connectivity, CAT 5/6 cabling, and in house technical support as required to complete the project.

• FHC assumes responsibility for providing all virtual servers, workstations, Microsoft Server and SQL software licensing, and initial setup of these devices.

• FHC assumes the responsibility for providing any non-RFP covered printers, scanners, signature pads, and/or other third party hardware peripherals defined and associated with the project.

• FHC assumes the responsibility for providing any non-RFP covered X-Ray imaging equipment and hardware including the Digital Image Sensors, Panoramic X-Rays, and X-Ray generators & arms.

Vendor responsibilities: • Vendors responding to the RFP will provide all RFP defined “Integrated EHR System”

hardware, software, licensing, support contracts, and professional services required to meet the specifications listed in section IV.

• The vendor will provide hardware and software compatibility lists and specifications to assist FHC in the utilization of existing, or the purchase of new components required to implement the “Integrated EHR System”, including:

o Software o Server(s), Computer Workstation(s), and Notebook Computer(s) o Other hardware peripherals specified in the RFP response.

• The vendor will provide hardware and software compatibility lists and specifications to assist FHC in the utilization of existing, or the purchase of new Digital Imaging software and hardware not specified in the RFP response.

• The vendor will provide all technical and administrative aspects required to plan, configure, and integrate the proposed “Integrated EHR System” as defined in section IV.

• The vendor will provide technical training to FHC staff for the configuration, implementation, and ongoing support of the proposed “Integrated EHR System”.

• The vendor will provide warranty and post warranty support for the products and services defined within the RFP response.

Failure to adhere to these directives will result in the disqualification of the bid.


2. Professional Services

• Responding vendors must have the available technical expertise, either directly employed or contracted, to plan, configure and implement the proposed “Integrated EHR System”. These services must be included in the RFP response and be clearly denoted. Examples of the required professional services are:

o Technical support and guidance to the FHC staff for the “Integrated EHR System” design and best practices.

o System configuration and implementation including in depth “train the trainer” build and implementation training for the FHC core implementation team.

o Technical support for the integration with existing and RFP defined Health Information Technology (HIT) systems.

o User training for the FHC staff for the “Integrated EHR System”. o Technical training for the FHC staff for the “Integrated EHR System”.

This list of proposed professional services should be used as a reference to formulate an RFP response. Additional professional services may be required to complete this project. It is the prospective bidder’s responsibility to account for and provide additional services as required to complete the project as defined.

3. Implementation & Training Schedule

A proposed delivery and installation schedule must be included in the “Project Scope and Design Document” (section II-A). It is the prospective vendor’s responsibility to ensure the timely acquisition, delivery, and installation of the proposed equipment. It is also incumbent that potential vendors be prepared to facilitate a timely project completion.

B. Warranty Maintenance & Post Warranty Support Provide a complete description of the manufacturer and/or vendor supplied warranty and support included in the RFP response (section V-B-1). If no warranty or supplemental support is documented in the response then “no warranty” is assumed by FHC for the vendor’s response. If warranty or support services are to be provided by an entity other than the equipment manufacturer or the RFP respondent, list the organization and its affiliation to the respondent. If optional or upgraded warranty and support programs exist for the equipment listed in the RFP response then the vendor is required to list the information as an optional cost or in an addendum.


1. Warranty & Support Detail (Respond with answer and a description of the proposed solution in the comments section when applicable)

Warranty and Support Does the purchase price include system support and warranty for the first year (12 full months from go-live)? (ref. section V-B)

• Explain in detail the warranty support contract.

Do you offer multiple post warranty support programs (annual maintenance agreement)? Provide a detailed list of each with your standard SLA for each support program. (ref. section V-B)

Discuss items which may be included within your annual maintenance agreement. (ref. section V-B)

Explain in detail how additional options added to the basic system will increase maintenance costs. (ref. section V-B)

What are your support statistics (# of Support Calls to the % of resolutions at each severity level)?

When and how is customer support available? (Provide a detailed explanation for each) • What are your normal hours of support?

• How is after hours support handled?

• Will someone be on-call at all times?

• Preferred method of contact (Phone call, e-mail, etc.)?

• Describe the ways in which customers can submit service requests?

• Are technical support calls answered by system technicians/engineers?

• What kind of response time can be expected when calling in for technical support?

• How are support calls triaged, logged, and assigned?

• How does your company handle urgent calls?

• Do you have electronic ticketing for non-emergent technical support?

• Is remote assistance an option for workstation and server issues?

• Is your support staff certified (i.e., HDI, SCP)?

• Are all support calls handled by personnel located in the United States or Canada?

Problem/Resolution Process (Provide a detailed explanation for each) • Response time expectations for all levels of severity

• Average time to close tickets by severity level

• Escalation Process

• Severity Level System

• Issue/Resolution Tracking System

• Test System vs. Live System

Explain in detail your support capabilities for a: • Minor failure (as defined above)

• Critical failure (as defined above)

Who has ownership of the following: (Provide a detailed explanation for each) • Data


• Software

• Enhancements or Customizations Paid for by Customer

• Hardware

• Servers

• Workstations

On Site Support: (Provide a detailed explanation for each) • Does your company offer on-site support?

• Where is your local support dispatched from?

• How many “factory authorized” engineers/support personnel are located within the local area?

• What local support services are offered?

Support Options - Break down support costs as follows: • Annual Maintenance Agreement (quote should be for the

year(s) immediately following expiration of the specified support contract)

• Per call basis (emergency support calls without Maintenance Agreement)

• Per call basis (changes and/or technical assistance without Maintenance Agreement)

• Additional fees for support after hours, holidays, and weekend (emergency support calls without Maintenance Agreement)

• Additional fees for support after hours, holidays, and weekend (emergency support calls with Maintenance Agreement)

• Optional maintenance plans

Product Enhancement Requests (Provide a detailed explanation for each) • If customer wants to add an enhancement, what is the

process?

• Are there additional costs for an enhancement?

• Describe Enhancement Request Model

• How soon will customer be able to view, test, and use enhancement?

• How will upgrades work with new enhancement?

• Will all other customers get the enhancement one company has paid for?

• How will the company stay up-to-date on required Promoting Interoperability definition changes?

How and when are known software problems (e.g. bugs, errors) resolved?

Are support issues utilized in the creation of future releases?

Do you have online support (Knowledgebase, InfoCenter, etc.)?

Do you have a user forum for practices to seek help from peers and share ideas?

Do you have regional and national user conferences?

Do you have a user forum for practices to seek help from peers and share ideas?


Define the Support Structure (Tiered Approach, Client assigned 1 point of contact, etc.)

What is your availability to the practice for meetings to discuss EHR issues and concerns?

Will your company assume primary responsibility for all aspects of software implementation and validation of customer supplied hardware and operating systems?

Will your company assume primary responsibility for the “Integrated EHR” if our facility provides the hardware or virtual environment?


C. Technical Training

Provide a detailed training plan, number of hours required, and cost to bring FHC’s “Trainers” and Information Systems staff up to speed on the proposed solution. In addition, provide optional factory authorized training classes or software as required.


VI. Pricing & Terms A. Equipment & Delivery

(as stated in section I)

Vendors responding to the bid process will be responsible for the timely acquisition and delivery of all hardware, software, services, and accessories listed in this document. Provide a complete description of the equipment and services included in your bid response as well as an estimated timeline for delivery as defined in the RFP details. A separate equipment list of vendor supplied equipment and software is required. Any non-vendor supplied equipment and/or services required to complete the project must be specifically noted. All proposed equipment, software, and services must be included in writing with the bid.

B. Pricing

When submitting the RFP response, include a detailed line item description including a unit price and any applicable shipping and/or delivery charges. Any proposed professional services should also be itemized and priced separately. No verbal agreements will be considered during the bid process. The quality of the response to the RFP will be viewed as an example of the vendor’s capabilities. Quoted prices and discounts are to be guaranteed for at least 60 days from the bid close date. Upon request, prospective bidders will be supplied with a copy of FHC’s 2018 UDS Table 5 staffing chart to establish accurate pricing consistent with FTE license utilization in a FQHC setting.

C. Terms

The payment terms must be clearly stated in the bid specifications. Payment terms should be structured using a milestone based payment schedule. The schedule should start with contract signing, following a logical progression of system delivery and installation, then conclude with the final system acceptance.


D. Default

1. Family Health Centers may, subject to the provisions of (section VI-D-3) below, by written notice of default to the contractor; terminate the whole, or any part, of this contract in any of the following circumstances:

a. If the contractors fails to make delivery of the supplies or to perform the services

within the time specified.

b. If the contractor fails to perform any of the provisions of the contract, or fails to make progress as to endanger performance of this contract in accordance with its terms, or in either of these two circumstances does not cure such failure within a period of 30 days after receipt of notice from the department specifying such failure.

2. In the event FHC terminates this contract completely or in part as provided in (section

VI-D-1), FHC may procure, upon such terms and in such manner that is deemed appropriate by FHC, supplies or services similar to those terminated. In this circumstance, the contractor shall be liable to FHC for any excess costs for such similar supplies or services, subject to the provisions of (section VI-D-3).

3. The contractor shall not be liable for any excess of costs if acceptable evidence has

been submitted to FHC that failure to perform the contract was not due to negligence of the contractor.