Req _

Document Sample
Req _ Powered By Docstoc
					                                                                                        Attachment G: System Requirements Matrix

Req #                                                                                                                            Agree to meet through                        Proposal Section for
                                                                               Agree/not Agree to meet           Existing                                Propose Alternate
         Requirement                                                                                                              System Modification                        description of proposed
                                                                                  as Stated Yes/No           Capability Yes/No                            Process Yes/No
                                                                                                                                        Yes/No                                 solution capability
         Technical Requirements

1        Service Oriented Architecture (SOA)

SOA #1   Technology Independence

SOA #2   Standards-based Interoperability

SOA#3    Life-cycle Independence

SOA#4    Loose Coupling

SOA#5    Invokable interfaces

SOA#6    Communication Protocol

SOA#7    Flexible:
               a.   Ability to adapt applications
               b.   Easily integrate applications
               c.   Leverage existing investments
               d.   Quickly and easily create business process from existing
SOA#8    Metadata Management
              a. Separation of data and structures and conversion to
                    data layer within SOA
              b. Development of Common Data Model and Metadata
                    using MITA HL7 methodology o Separation of data layer
                    from application layer
SOA#9    Enterprise Service Bus (ESB):
              a. Message Management
              b. Data Management
              c. Service Coordination
SOA#10   MITA Alignment:
              a. Map business processes to MITA business processes
              b. Alignment of business processes to MITA maturity level
                    and capabilities
              c. Use of MITA standard interface definitions and
              d. Use of MITA/HL7 methodology for defining information
                    model and messages
              e. Adherence to MITA governance process for new
                    interfaces and messages
         Programming Language Requirements

SOA#11   All software must be written in languages approved by the State
         and compatible with the State computing environment.
SOA#12   The State will approve industry-standard languages appropriate to
         the task that operate without additional add-on licenses.
SOA#13   The Contractor will stay current with all software and language
         updates and versions.
         Data Quality Control

SOA#14   A modern relational database management system must be used.

SOA#15   Tables must be properly normalized or de-normalized for efficient
SOA#16   Relations between tables within databases must be properly set
         and controlled.
SOA#17   Database integrity features (such as primary keys, foreign keys,
         unique constraints) must be used to enforce field and relationship
SOA#18   Controls must be in place to prevent duplicate or orphan records.

SOA#19   Transactions must provide for error recovery, i.e., if the entire
         transaction does not process completely, the entire transaction is
         rolled back.
SOA#20   Communications routines must use checksums or other tools to
         assure accuracy of a file before it is processed.
SOA#21   HIPAA transaction processing must be tested and validated
         according to guidelines developed by the Strategic National
         Implementation Process:
               a. Test for integrity and syntax
               b. Test for adherence to national implementation guides
               c. Test for balancing
               d. Test for situational elements in the State implementation
               e. Test for code set conformance
               f.     Test for each specialty, line of business, or provider
SOA#22   Mirror all programs in production including reports and financial
SOA#23   Include a complete online MMIS test system, including a test
         version of all batch and online programs and files to be used for
         testing releases and non-release changes.
SOA#24   Provide a repository of non-technical project artifacts including
         requirements, use cases, storyboards, supplemental specifications,
         test cases, and test scripts that is regularly maintained. This
         repository will allow users to view and modify an artifact as needed

         to support requirements gathering or testing. This repository must
         have search capability and all of the requirements should be cross
         referenced to maintain the requirements traceability throughout all
SOA#25   Provide the ability to execute impact analysis testing of any
         proposed change.
SOA#26   Provide the ability to create “what-if” scenarios and compare results
         between scenarios in a test environment.
SOA#27   Provide the ability to estimate what changes would need to take
         place in benefit plans (service limitations, aggregate dollar ceilings,
         provider payment rates, or other combinations) to control State
         Medicaid expenditures to a specified growth rate from one State
         fiscal year to the next.
SOA#28   Provide State, Contractor and IV&V staff a minimum of read only
         access to all environments.
SOA#29   Provide the ability to maintain regression test cases to support
         regression testing.
SOA#30   Provide the ability to save and reuse test cases without the need to
         re-enter the data.
SOA#31   Allow testing of separate business area s concurrently and allow
         concurrent use of any environment by State, Contractor and IV&V
SOA#32   Provide for testing of all Customer Service Requests (CSRs) before
SOA#33   Allow users to create and edit provider, client, and health plan
         records for testing.
SOA#33   Provide support for multiple payers in the areas of, but not limited
         to, reimbursement methodologies, provider contracting, and client
         eligibility within a single installed instance of the solution.
         Defect/Issue Tracking Tool

SOA#34   Defect/Issue identification

SOA#35   Status of defect/issue

SOA#36   Results of correction efforts

SOA#37   Prioritization of defects/issues

SOA#38   Documentation of correction efforts

SOA#39   Final disposition of defect/issue

SOA#40   Defect cross reference to the technical and nontechnical artifact

SOA#41   Integration with technical and non-technical artifact management
         DDI Application Environments

SOA#42   Provide Prototype Environment

SOA#43   Provide System Test Environment

SOA#44   Provide User Acceptance Test Environment

SOA#45   Provide Impact Analysis Environment

SOA#46   Provide Training Environment

SOA#47   Provide Conversion Test Environment

         Production Application Environments

SOA#48   Provide Production Environment

SOA#49   Provide Test Environment

SOA#50   Provide Training Environment

SOA#51   Provide Impact Analysis Environment

2        System Architecture Requirements

SAR#1    Utilize web-based systems with n-tier architecture that is thin client
         and browser independent, a relational database and Graphical user
         Interface(s) (GUI), for subsystems and functions accessed by
SAR#2    Provide easy navigation to include the following:
               a. Drop-down menus
               b. Application-specific toolbars
               c. Auto population of persistent data
               d. Direct links to help, reference information, manuals, and
               e. Short-cut and function key functionality
               f.    Mouse-over captions for all icons and data elements
               g. Navigation menus, fields, and page tabs
               h. Auto skips from field to field so that the cursor moves
                     automatically to the next field as soon as the last
                    character in the previous field is completely filled
              i.    “Forward” and “Back” navigation
              j.    The ability to have multiple screens open and link from
                    one screen to another without cutting and pasting data.
                    For an example, if a user is on a client screen and wants
                    to look at the provider data, the user should be able to
                    link to the provider information by clicking on the
                    provider number and then return to the original client
                    screen without having to cut-and-paste the provider
                    number in the provider screen.
               k. Provide a single log-on that allows for user specific
                    security down to the individual data fields.
SAR#3    Provide systems access for the State regional and local offices,
         designated Contractor at various locations, and headquarters staff
         designated by the State.
SAR#4    Provide browser-based web capabilities for all authorized users,
         including providers and clients by configurable search criteria.
SAR#5    Allow one-click access to online context-sensitive Help screens and
         resources via hyperlinks. The Help menu will be accessible from all
         subsystems, windows, tabs, and frames, and will include access to
         the following components:
               a. General information
               b. Electronic Data Management System (EDMS) User
                     Manuals (context specific navigation)
               c. EDMS System documentation (context specific
               d. Data Element Dictionary
               e. Provider Handbooks and other Department defined
SAR#6    Employ the best available tools and support open architecture
         software that is flexible and cost effective to modify and maintain.
SAR#7    Automate current manual or inefficient processes.

SAR#8    Provide version upgrade(s) to the MMIS/PBM/DSS at no additional
         cost to the State including expanding system capacity. Provide the
         ability to seamlessly integrate with installed COTS product
         components through a single MMIS user interface and maintain the
         most current updated version of the product(s).
SAR#9    Provide Enterprise Application Integration (EAI) to include web
         services technology and standards to promote web-based and
         backend MMIS applications integration including an enterprise
         service bus for interfaces.
SAR#10   Flexibility to support multiple payers in the areas of, but not limited
         to, reimbursement methodologies, provider contracting and client
         eligibility within a single installed instance of the solution. Such
         functionality must also include the ability to model plans of benefits
         based on the specific business rules and requirements of each
         individual payer entity utilizing the MMIS/PBM/DSS.
SAR#11   Facilitate implementation of ICD-10 procedure and diagnosis
         codes, HL7 Reference Information Model (RIM)” and/or LOINC

         functionality , new HIPAA transaction including, but not limited to,
         attachments (275/277), and the Unsolicited 277, Prior Authorization
         278, and electronic health record and RHIOS.
SAR#12   Ensure full HIPAA compliance.

SAR#13   Align with MITA standards

SAR#14   Provide functionality to interface with multiple entities outside of the
         MMIS for exchange of information such as eligibility determination
         systems, prior authorization entities, and Immunization and Death
SAR#15   One-click access to online context-sensitive Help screens and
         resources. All key fields need to be linked, so clicking it opens
         another screen. The Help menu will be accessible through the
         system, windows, tabs, and frames, and will include at least the
         following components:
                a. General information
                b. User Manuals link
                c. System documentation link
                d. Data Element Dictionary
                e.    Provider Handbooks
                f.   Other Department defined resources.
SAR#16   Provide metadata management that is accessible by State staff.
         Metadata management refers to the activities associated with
         ensuring that metadata is created/captured at the point of file
         creation and that the broadest possible portfolio of meta information
         is collected, stored in a repository for use by multiple applications,
         and controlled to remove inconsistencies and redundancies. Within
         the context of storage management, metadata provides the linkage
         between the business need or policy and the information or
         infrastructure (object). The effective management of metadata is
         therefore critical to information lifecycle management.
SAR#17   Utilize open architecture standards and scalability to promote
         integration throughout all MMIS business processes and sub-
         MMIS and PBM Architecture Requirements

SAR#18   Provide web-based MMIS/PBM/DSS access that requires no
         desktop software except the State standard version of Windows™
         Internet Explorer.
SAR#19   Provide system screens that are easy to read, user friendly and
         display all data elements necessary for a user to perform his/her
         job function.
SAR#20   Design all screens with input from State users and subject to State
         approval during the Design and Development Phase of the
SAR#21   Provide system availability twenty-four (24) hours per day and
         seven (7) days per week, other than for scheduled maintenance.

SAR#22   Ensure that document images are quickly available to users at their
         desktop; desktop (3 seconds or less) (wall clock time).
SAR#23   Return standard screen inquiries within three (3) seconds (wall
         clock time).
SAR#24   Provide online functionality including:
                 a. Online, context-sensitive help
                 b. Hovering
                 c. Drop down lists and menus
                 d. Point and click
                 e. Cut and paste
SAR#25   Provide search capability based on wild cards or any combination
         of fields. For web portals, provide site-wide search capabilities for
         all documents within the web portal.
SAR#26   Provide field level and role-based security that allows only
         authorized users to see the information necessary to perform their
         job efficiently. Role based security must also be available that
         allows a level of security to be applied to a specific job category.
SAR#27   Provide searchable screens that are applicable to specific business
         areas including but not limited to: client, provider, benefits,
         reference data, claims processing, prior authorization, third party
         liability (TPL), and financial- an individual user may be associated
         with multiple job categories.
SAR#28   Provide an audit trail for each transaction on the screen identifying
         who made the change, what change was made, date/time the
         change was made, why the change was made and provide a record
         of the data prior to the time the change was made.
SAR#29   Provide the functionality display all data elements contained on
         each data record.
SAR#30   Provide a “Screen Print” function button that will create a user
         friendly formatted print of screens applicable to their specific
         business area (for example, client, provider, benefits, reference
         data, claim types, prior authorization, TPL and financial). The layout
         for these formatted prints will be determined during the Design and
         Development Phase subject to approval by the State.
         Data Warehouse and Decision Support System (DSS)
         Architecture Requirements
SAR#31   Maintain data sets approved by the State for all tables, including
         provider, client, claims, encounters, and reference. The Contractor
               a. Implement a data model that is flexible and allows for
                      the addition of new data elements with minimal effort
                      Include all necessary data elements to perform all
                      business functions described in this RFP.
               b. Maintain the most recent ten (10) years and one (1)
                      rolling year of paid and denied claims and encounter
               c. Maintain all purged prior years‟ claim and encounter
                      data in a separate file or files for ad-hoc reporting. Each
                      year must be maintained on a separate file to allow the
                      query of the data as it was at the end of the reporting
               d.    Maintain a minimum of ten (10) years of client historical
                      eligibility and claim information in order to track changes
                      in a client‟s health status over time.
                e. Maintain risk-adjusted data based on the most recent
                      two years of eligibility and paid claims.
SAR#32   Integrate robust user-friendly query, analysis, and reporting tools
         and functionality including:
               a. Provide sufficient processing/storage for the creation of
                     reports and statistics by State staff, increasing each year
                     if necessary based on utilization statistics
               b. Support a variety of output capabilities including CD,
                     DVD, tape, FTP and other methods as determined by
                     the State
               c.     Provide the functionality to allow authorized State users
                     the ability to link between Contractor tables and user-
                     defined tables as necessary
               d. Provide the ability for specified State users to retrieve
                     data from any DW/DSS table via Open Database
                     Connectivity (ODBC) and other available database
               e. Provide web-based access to DSS functionality
                     Provide reliability, stability, and recoverability
               f.    Provide Geographic Information Systems (GIS) and
                     mapping functionality
               g. Provide already created (canned) queries and reports
                     that can be easily selected from a menu
SAR#33   Support all users authorized by the State including:
               a. All named users of the DSS
               b.     Users at regional offices, local offices, other State
                     agencies, and other locations authorized by the State
SAR#34   Provide Management and Administrative Reporting Subsystem
         (MARS) functionality.
SAR#35   Provide Surveillance and Utilization Review Subsystem (SURS)
         DSS Information Processing Requirements

SAR#36   Provide web-based query applications, requiring no desktop
         software except the State-standard version of Windows™ Internet
         Explorer. DW/DSS statistical, GIS, reporting and analysis functions
         may require COTS software to be supplied by the Contractor.
SAR#37   Allow authorized internal and external users to download and sort
         report information on user PCs in a variety of formats such as
         Excel, DBF, TXT, CSV, PDF, HTML, character delimited or flat
SAR#38   Provide both column- and row-level security access for enhanced
         HIPAA security on a need-to-know basis.
SAR#39   Meet the following performance requirements:
              a. Queries against single, indexed files must be returned
                    within ten (10) seconds.
              b.  Queries returning more than one-hundred (100) rows
                  may be paged for immediate query, with the first one-
                  hundred (100) rows being returned within ten (10)
             c. Queries and reports relating two or more files or on
                  fields not indexed must be returned in a time frame
                  acceptable to the State, comparable to the performance
                  of the State‟s existing system.
3        Workflow and Electronic Document Management

EDM#1    Provide an integrated Electronic Document Management System
         (EDMS) to control, manage, and access all documents.
EDM#2    Provide an automated letter generation system available to State
         and fiscal agent staff from the desktop.
EDM#3    Provide a document imaging system to image all paper documents
         received from external sources.
EDM#4    Provide an automated workflow management system centric and
         non-document centric workflow to control, track, and manage
         workflow through the system.
EDM#5    Provide convenient, instant access to current and historical
         information without requiring a separate sign on beyond the initial
         MMIS/DSS sign on.
EDM#6    Employ a security approach that integrates with other MMIS
         components to provide role-based access with a single log-on.
EDM#7    Integrate with and provide support to other MMIS components such
         as the web portal.
EDM#8    Produce status reports and processing statistics.

EDM#9    Ensure that all content and activity is date-stamped.

         Electronic Document Management System

EDM#10   Accept documents through various input methods including but not
         limited to:
               a. Web Portal
               b. E-mail
               c. FAX
               d. Internal creation from Personal Computers (PCs)
               e. Imaging
               f.    System generated
               g. Mailroom.
EDM#11   Store both electronic and imaged paper documents and make them
         available on-line through a single user interface to promote a total
         view of current and historical information.
EDM#12   Store reports generated by the MMIS/PBM/DSS.

EDM#13   Provide for on-line retrieval and access to documents and files for
         up to ten (10) years rolling.
EDM#14        a.     Index all documents using parameters such as but not
                     limited to: Document type
               b. Document format
               c. Storage location
               d. Barcode formats
               e. Security levels
               f.    Size
               g. Field validation.
EDM#15   Provide multiple search options (e.g., Structured Query Language
         (SQL), various index search options, content based searches, etc.)
         to view contents.
EDM#16   Track all versions of each document.

EDM#17   Provide the ability to view related images from MMIS screens. The
         State will determine the subset of images that will be displayed on
         each screen.
EDM#18   Present users with the latest revision of a document with the option
         to view previous versions.
EDM#19   Manage document content and configuration across the DPHHS
         enterprise and, with suitable role based permissions.
EDM#20   Support the management of documents created in the following
               a. Microsoft Word
               b. Microsoft Excel
               c. Microsoft PowerPoint
               d. Microsoft Project
               e. Text
               f. Tag Image
               g. File formant TIF.
EDM#21   Allow drag-and-drop functionality to be used when creating or
         editing a document.
EDM#22   Provide the ability to print or fax one or more selected images from
         image search.
EDM#23   Include at a minimum the following document management
               a. Concurrent retrieval functions to publications and other
                     stored documents
               b. Automated inventory control for all forms, letters,
                     publications and other DPHHS- designated documents
               c.      Storage of documents and files
               d. Ability to generate documents in both hard copy and
                     electronic format including forms and letters.
EDM#24   Convert documents to a format as defined by the State.

EDM#25   Utilize document management capabilities for scanning and routing
         documents between regional offices and the state office.

EDM#26   Provide the ability to associate related documents such as claims
         and supporting attachments, including the ability to accept more
         than one attachment for a claim and identify the
         primary/correct/current attachment to be used for processing.
EDM#27   Allow for storage and retrieval of all documents (e.g., fax, letters,
         reports, cash receipts and claims).
EDM#28   Provide backup and storage of documents as defined by DPHHS.

EDM#29   Destroy source documents according to procedures defined by the
EDM#30   Provide the ability to relate separate documents to a common case
         type and case number either at the time the documents are
         scanned or at a later date from the image search results screen.
EDM#31   Provide conversion of all documents identified by the State.

         Automated Letter Generation System

EDM#32   Provide the capability to create letter templates and forms including
         but not limited to the following:
               a. Provider certification materials
               b. Provider recertification letters
               c. General correspondence/notices for providers and
               d. Financial letters
               e. Coordination of Benefits (COB) letters
               f.    Passport materials
               g. Service authorization letters
               h. Service denials
               i.    Premium notices as required by DPHHS
               j.    Special payments
EDM#33   Allow for specific information on the letter templates such as:
               a. Name and address
               b. Date
               c. Salutation
               d. Free form text block
               e. Signature block
               f.    Electronic signature capability
               g.     Revision date
               h.     Phone number
               i.    Department letterhead
EDM#34   Store letter templates and forms within the system with the
         following attributes assigned to each letter template at a minimum:
                a. Letter template/form name
                b. DPHHS letter template/form number
                c. Letter template/form unit owner (e.g., provider services)
                d.     Contact position/location for updates
                e. Last revision date (archived letter/form must be
                f. Letterhead type used (not applicable to forms)

               g.     Whether DPHHS administrator signature is contained on
                       the letter template (not applicable to forms)
                h. Whether the letter requires a handwritten signature (e.g.,
                       for legal purposes, some letters may require a hand-
                       written signature)
                i. Canned language/standardized paragraphs
                j. Allow for multiple versions of the template including a
                       revision log.
EDM#35   Provide a method of automatically generating letters to providers,
         clients, and other stakeholders. The automated letter generator
                a. Provide the functionality to send letters by mail, email or
                b. Provide the ability to trigger letters automatically based
                       on processing, such as provider enrollment
                c. Initiate system-generated letters to clients and providers
                       based on status in the workflow management queue.
                       For example, the system would generate second
                       notices to providers who have not returned the required
                d. Allow user to generate a single letter immediately
                e. Allow user to designate address to be used
                f. Support the generation of letters for mass mailings
                g. Allow users to insert free form text as necessary. Free
                       form text should not be limited in size
                h. Allow imposition of security rules to control who may
                       issue each kind of letter, and to designate and enforce a
                       chain of review for certain letters
EDM#36   Allow for the retrieval and reproduction of all generated letters,
         including the address to which the letter was sent and the date the
         original letter was generated.
EDM#37   Print letter templates to networked, individual, or high volume
         centralized production printers.
EDM#38   Provide the capability to print letters on a State-approved schedule
         for direct mailing or route letters to a user for a signature before
EDM#39   Generate pre-populated forms on a schedule approved by the
EDM#40   Update letter templates and forms as requested by DPHHS.

EDM#41   Retain letter templates and forms for a time period defined by State
         and Federal guidelines.
         Document Imaging

EDM#42   Support cataloging/indexing of all imaged documents.

EDM#43   Include industry standard Optical Character Recognition (OCR/ICR)
         technology that minimizes manual indexing and automates the
         retrieval of scanned documents.
EDM#44   Utilize bar code technology that minimizes manual indexing and
         automates the retrieval of scanned documents.
EDM#45   Provide backup capability for manually indexed scanned
EDM#46   Provide the capability to adjust scan preferences for each
         document type to include at a minimum:
                a. Resolution
                b. File numbering
                c. Storage location
EDM#47   Include at a minimum the following imaging and document
         management capabilities:
               a. Scan both single and double sided documents
               b. Scan complete or scraped documents
               c. Scan color, black and white, and grayscale images
               d.    Provide capability to handle special characters
               e. Support a wide range of compression methods
               f.    Retrieve images through the use of the use of any
                     OCR/ICR field search
               g. Retrieve images by ICN/TCN
               h. Retrieve images by provider number
               i.    Retrieve images by client ID number
EDM#48   Provide the capability to manipulate images to include:
               a. Rotation
               b. Inversion
               c. Zoom
               d. Brightness/contrast
               e. Crop/Cut/Copy a portion of the image
EDM#49   Use imaging/document management technology that handles
         multiple types of letters, forms, publications, and other State
         designated documents, files and automates workflow processing to
         include but not limited to:
               a. Provider enrollment materials
               b. Claim forms and attachments
               c. PA forms and attachments
               d. Coordination of Benefits (including casualty)
               e.    Estate recovery
               f.    Provider correspondence
               g. Client correspondence
               h. Web Portal correspondence
               i.    Client enrollment materials
               j.    Notices
               k.    Letters
               l.    Audit materials
               m. Other documents as defined by the State
EDM#50   Automate batch scanning with user-defined document separators to
         expedite the imaging and validation process.
EDM#51   Provide the capability for documents to be scanned and batched
         based on date of receipt.

EDM#52   Allow manual data entry from scanned documents if they cannot be
         read and transmitted electronically from an image to MMIS.
EDM#53   Transmit scanned document data to MMIS.

         Workflow Management

EDM#54   Support the following functions:
              a. Definition and modeling of workflow processes and their
                    constituent activities
              b. Run-time control functions for managing the workflow
                    process in the MMIS/PBM/DSS operational environment
                    and sequencing the various activities to be handled as
                    part of each process
              c. Run-time interactions with users and Information
                    Technology (IT) application tools for processing the
                    operational activity steps
              d.     Provide configurable work distribution and re-
                    distribution based on work type, worker skill, priority, and
                    age of work
              e. Provide configurable work distribution rules using
                    configuration tables managed by the State
              f.    Provide production reports for both open and closed
                    work items by type, by user as defined by the State.
EDM#55   Provide a user-friendly GUI for process definition, execution,
         monitoring, and management. Support a role-based interface for
         process definition that leads the user through the steps of defining
         the workflow associated with a business process including
         processes that are managed by DPHHS staff only, and that
         captures all the information needed by the workflow engine to
         execute that process to include:
              a. Start and completion conditions
              b. Activities and rules for navigation between processes
              c. Tasks to be undertaken by DPHHS staff involved in the
              d. Authorized approvers
              e. References to applications which may need to be
              f.    Definition of other workflow-relevant data.
EDM#56   Provide the ability to incorporate simple low-level workflow
         processes into more complex higher-level workflow processes.
EDM#57   Provide a workflow tracking process to track and control time-
         sensitive activities, including but not limited to:
              a. Complaints
              b. Administrative reviews
              c. Fair hearings.
EDM#58   Provide a rules-based workflow engine that supports workflow
         access, assignments, and execution.
EDM#59   Support and assist DPHHS in mapping all business processes and
         sub-processes to the workflow application and in transitioning from

         manual to automated process execution.
EDM#60   Support workflow management for multiple simultaneous
         processes, each with multiple simultaneous instances of execution.
EDM#61   Provide a method to track the provider application process.

EDM#62   Assign tasks to State and Fiscal Agent staff.

EDM#63   Utilize automated workflow to transfer documents to DPHHS for
         review, editing, and approval, and back to external stakeholders for
         re-writes and production.
EDM#64   Forward completed tasks to next responsible party(ies) when
         multiple levels of effort are required for resolution.
EDM#65   Provide the capability for the workflow processor to route and
         assign cases to the appropriate State and county staff and offices.
EDM#66   Provide an automatic update process as tasks are completed.

EDM#67   Provide an alert function for assignments.

EDM#68   Provide the ability for a user to set a reminder.

EDM#69   Provide the ability for a user to view all their reminders

EDM#70   Provide the ability for a user to reserve a work item for their
         exclusive use.
EDM#71   Provide the ability for a user to view all their reserved work items.

EDM#72   Create work items in workflow as a result of alerts from the web
         portal when changes occur.
EDM#73   Allow the process definition to be specified in terms of
         organizations and roles with later linkage to specific participants.
EDM#74   Coordinate interactions between the workflow engine and
         participating DPHHS staff to manage the work required to execute
         a process including but not limited to:
               a. Work queues for each participating staff member
               b. Alerts to the presence of work
               c. Other triggers, timers, and alerts to support workflow
               d.     Status indicators to mark work in progress or
EDM#75   Provide a tickler and/or To-Do-List function.

EDM#76   Log all instances of workflows that are executed throughout the
         DPHHS enterprise.
EDM#77   Identify key interfaces to support integration with a variety of best-
         in-class applications to support process execution.

EDM#78   Ensure security limits to certain data.

EDM#79   Provide supporting supervisory operations for the management of
         workflow including but not limited to:
                a. Assignments/re-assignments and priorities
                b. Status querying and monitoring of individual documents
                     and other work steps or products
                c. Work allocation and load balancing
                d.    Approval for work assignments and work deliverables
                     via a tiered approach
                e. Ability to take necessary action or provide notification
                     when corrective action is needed, including the ability to
                     modify or abort a workflow process
                f.   Monitoring of key information regarding a process in
                     execution, including but not limited to: i. Estimated time
                     to completion ii. Staff assigned to various process
                     activities iii. Any error conditions.
                g. Overall monitoring of workflow indicators and statistics
                     by sub-process, organization, or individual staff
                     members including but not limited to: i. Work in queue
                     by priority ii. Throughput iii. Individual and organizational
                     productivity iv. Current activity by individual staff
EDM#80   Provide a reporting component to monitor operational activities,
                a. Status of operational activities
                b. Statistical reporting of receipts and completed activities
                     by process
                c. Reports of current inventories
                d. Reports by unit and worker where appropriate
EDM#81   Intelligent work distribution and re-distribution based on work type,
         worker skill, priority, and age of work.
EDM#82   Configurable work distribution rules managed by the State.

4        Rules Engine

RE#1     Allow for rules to be implemented in a real-time environment and
         applied immediately upon approval, if desired.
RE#2     Provide a graphical front-end to the Rules Engine enabling users to
         easily connect and apply rules.
RE#3     Provide a modular structure so that the same Rules Engine can be
         used by different services or be called as a service itself.
RE#4     Provide a debugging process that automatically analyzes and
         identifies logical errors (i.e., conflict, redundancy and
         incompleteness) across business rules.
RE#5     Allow for rules to be tested against production data prior to

RE#6    Contain a process for a built-in multi-level rule review and approval
        process that will identify any conflicts in business rules as they are
        being developed.
RE#7    Provide the capability to manage implementation timing.

RE#8    Allow for the tracking and reporting of rules engine.

RE#9    Produce documentation regarding all business rules.

RE#10   Integrate with other components in the systems.

RE#11   Allow for rules to be date specific, including date added, date
        modified, start date, end date, and effective date.
5       Benefit Plan Administration

BPA#1   Provide a rules-based Benefit Plan Administration system that
        allows flexible definition for the creation and operation of each
        Benefit Plan, including the ability to:
              a. Base the rules on any client or provider information
              b. Define payment methodologies
              c. Allow payments to the same provider to be different
                    based on the Benefit Plan of the client at the time of
BPA#2   Provide date-specific benefit plans and associated rules so that
        rules for enrollment and operation of a benefit plan may change
        over time (Specific begin and optional end dates. When a benefit
        plan is created it may not have a defined end date. Once the end
        date is determined the benefit plan can be updated to reflect the
        benefit plan end date)
BPA#3   Maintain a system to uniquely identify each benefit plan

BPA#4   Maintain user-defined plan characteristics that define:
             a. Clients who may be enrolled into a plan
             b. Services provided in the plan
             c. Service and benefit restrictions and limitations
             d. Service authorization requirements
             e. Inclusions and exclusions
             f.    Payment methodologies.
BPA#5   Allow authorized Contractor and State staff to:
             a. Modify requirements for Benefit Plans based on date
             b. Set plan hierarchy as to which benefit plan pays first if
                   the client has active eligibility spans for more than one
                   benefit plan
             c. Define services specific to unique benefit plans
             d. Specify limitations at both the service and monetary
                   levels relative to benefit plans and service categories
             e. Apply effective and end-date range parameters to

                    benefit plans
              f.    Define different service limits for each benefit plan
              g. Define payment methodologies for each benefit plan.
BPA#6    Allow the systems to adjudicate claims against more than one
         benefit plan if a client has multiple active eligibility spans.
6        Web Portal

WPA#1    Provide a navigation portal that all authorized users can easily
         understand. The portal must be secure but not complicated to use,
         and not require multiple sign-in steps.
WPA#2    Allow for easy navigation between screens through Help menus.
         For instance, when a user is inquiring on service limits, instructions
         must be provided to point the user to the appropriate handbook
         containing this type of information.
WPA#3    Support the ability to receive and respond to secure emails and
         HIPAA compliant transactions from providers, clients, other
         contractors and State staff.
WPA#4    Be browser-independent and operate for most functions regardless
         of browser brand, as long as the browser has broad usage (at least
         500,000 users nationally) and the version is recent in publication
         (within the last four years). Web-based claims submission,
         correction, and void and replace may require use of the State-
         standard version of Internet Explorer ™. At a minimum, the web
         portal must be compatible with standard browser technology,
         including Internet Explorer or Netscape Navigator. Firefox Mozilla.
WPA#5    Provide Contractor and State staff contact information and offer
         interactive online support. This will allow the Contractor and State
         staff the capability to respond to provider questions that are
         submitted online.
WPA#6    Provide the ability to post announcements or alerts that are
         displayed at user sign-on. Users should be required to
         acknowledge the announcement so that it is not repeatedly
         displayed at subsequent sign-on . The announcements should be
         specific to the customer type (State, provider, client), the specific
         benefit plan, and user role.
WPA#7    Maintain archives of posted announcements and alerts that may be
         general or provider specific, including the date and message.
WPA#8    Provide for the creation and processing of online surveys by the
         State or the Contractor, store survey results collected from the
         customer in the imaging repository indexed by survey number,
         customer number, date received, etc.
WPA#9    Provide hotlinks to frequently visited areas of the fiscal agent web
         site at the State‟s request.
WPA#10   Provide browser-based screens with point and click and „hover‟
WPA#11   Provide smart links on State, provider, and customer home pages
         that provide a single client navigation to tasks that need to be
         completed by that specific customer.

WPA#12   Provide online tutorial functionality.

WPA#13   Provide for Computer Based Training (CBT) course presentation
         and record-keeping.
WPA#14   Post Frequently Asked Questions (FAQ) online organized by topic.

WPA#15   Maintain version history for use by State legal staff of previous
         forms and handbooks.
WPA#16   Support prior authorization management.

WPA#17   Support provider relations management.

WPA#18   Provide secure access to client data.

WPA#19   Provide the capability to accept all claim types, corrections and void
         and replacement claims through direct data entry on the web portal.
WPA#20   Be accessible using TCP/IP protocol through various connection
         methods that include broadband, DSL, point-to-point, satellite,
         cable, and dial-up.
WPA#21   Be operational and accessible, 24/7, except for DPHHS approved
         scheduled downtime.
WPA#22   Allow users to view and copy provider manuals, instructions,
         bulletins, program descriptions, eligibility criteria, and forms,
         descriptions, eligibility criteria, and forms.
WPA#23   Provide links to other State and federal websites and external
         entities, including certifying agencies, SSA, public health care and
         nutritional programs, and other programs determined by DPHHS to
         be appropriate for portal access.
WPA#24   Allow providers, clients, trading partners, the State and the State‟s
         designees to register online for access to the secure areas of the
         portal based on security rules defined by the State.
WPA#25   Provide a transaction component of the portal that allows at
                a. Authorized trading partners to submit EDI files for
                      immediate processing and retrieval of the corresponding
                      response acknowledgement
                b.     Authorized trading partners to retrieve RAs and claims
                c. Providers to initiate enrollment using an online
                      application process
                d. Providers and other entities to enroll as EDI trading
                      partners using an online application process Providers
                      to view claim status information, payment history, client
                      eligibility and benefit information
                e. Providers to submit requests for prior authorization or
                      updates to client insurance coverage, and view existing
                      prior authorization information

              f.    Provide interactive fee schedule functionality to allow
                    providers to look-up procedure rates
WPA#26   Provide low bandwidth versions of State-specified pages for easy
         access by providers with mobile, wireless web access.
WPA#27   Maintain HIPAA compliance and support the access, privacy, and
         security requirements.
WPA#28   Provide multiple levels of security as designated by the State

WPA#29   Provide authorized providers web access to forms for direct data
         entry of e-mail, claims submission, prior authorization submission,
         eligibility verification, claims status, payment status, program
         announcements, bulletin download, training schedules, training
         material, receive remittance advice, provider network information
         and complaint submission.
WPA#30   Support web functionality and a self-service process to handle
         applications for provider enrollment including pharmacies.
WPA#31   Provide web functionality to support the capability for providers to
         verify their current information and update as needed.
WPA#32   Provide the capability to have a tracking number emailed to both
         the provider and contractor when new or updated information is
         created to the provider file.
WPA#33   Provide an authentication routine to allow providers to change their
         provider record through direct data entry via the web based on
         selected criteria.
WPA#34   Process direct data entry claims real-time via the Web Portal and
         reject claims that fail front-end edits.
WPA#35   Produce a remittance advice than can be viewed on-line and sorted
         by various parameters (EFT, date, NPI, etc.).
WPA#36   Provide ability to create, modify, access and store treatment plans
         by providers via the web portal.
WPA#37   Support Web submissions of prior authorization requests and
         support delivery of the approved request notification from the
         Authorizing Entity to the provider.
WPA#38   Support real time verification of eligibility through the Web Portal
         and provide eligibility information including benefit plan enrollment
         and TPL information on the web portal to providers and other users
         authorized by the State.
WPA#39   Provide the ability for authorized users to create and view an
         Individual Cost Plan (ICP) on the Web Portal.
WPA#40   Post and provide access to remittance advice through web portal
         for viewing by the provider after the adjudication cycle has been
         completed. Remittance advice must be in PDF format and indicate
         all reason and remark codes causing denial.
WPA#41   Allow drug manufacturer access to invoices and supporting data via
         the Web Portal.

WPA#42   Provide online access to authorized users to client, provider,
         claims, and reference data related to Waivers.
WPA#43   Provide the ability for authorized entities (e.g., case managers,
         MPQH) to do online PA through the web-portal.
WPA#44   Provide online access to authorized users to client, provider,
         claims, and reference data related to care management and
         managed Care.
WPA#45   Maintain a secure link between the DPHHS Web site and the
         Contractor‟s Web site.
WPA#46   Review the Frequently Asked Questions (FAQ) section of the Web
         Portal weekly and update the FAQs within two (2) days of receipt of
         new questions.
WPA#47   Implement a Medical History portion of the Web Portal to assist
         hospitals, physicians, and mid-level practitioners in the treatment of
         Montana Health Care Program patients by allowing them to access
         a client‟s medical histories interactively. For example, a primary
         care provider can view information related to emergency room visits
         for their Passport clients, providers can inquire on up to three years
         of patient history. The information returned is from claims data
         processed by Montana Health Care Programs and should include
         the name of the provider who rendered the service, diagnosis
         codes(s), service(s) delivered by procedure/revenue/NDC code,
         service description(s) (office visit, lab, etc.), and prescribed drug
WPA#48   Allow client access to choose a Care Management Care/Lock-In
         provider through the web portal.
WPA#49   Allow client access to utilize a provider locator to find State
         designated providers through the web portal.
7        Call Center Management System

CCM#1    Provide the capability to answer calls in sequence, record and print
         statistics, and indicate calls that have been placed on hold for a
         specific time limit.
CCM#2    Provide the ability to integrate voice and electronic transactions into
         a single workflow with integrated queues that allow work blending
         and load balancing.
CCM#3    Provide the ability to link contact information and processes from
         the Internet with processes, contact management systems and
         databases in the toll-free call center to ensure timely and
         synchronized data access.
CCM#4    Provide for email and text chat as a reliable transaction channel in
         addition to inbound and outbound voice calls.
CCM#5    Provide a reader board to visually display call center statistics to
         staff. The information reported on the board must also be available
         to Contractor and State management personnel via the
         Performance Reporting System.
CCM#6    Provide Computer Telephone Integration (CTI) to provide
         personalized routing and work-object handling based upon

         identifiers received from the caller regarding language and inquiry
         area and to produce reports on both electronic and voice
CCM#7    Provide automatic screen presentation of client/provider data when
         the call arrives at the call center staff.
CCM#8    Provide multiple language options (English and Spanish) and
         services for the hearing impaired (TTY/TTD).
CCM#9    Provide quality monitoring tools and processes to enable a
         continuous improvement process for toll-free call center services
         that include:
                a. Plug-in/double-jack monitoring
                b. Silent monitoring
                c. Record and review
                d. Voice and screen/multi-media monitoring.
CCM#10   Provide real-time monitoring, reporting and forecasting software for:
                a. Abandon Rate
                b. Availability and Agent Utilization
                c. Average Speed of Answer (ASA)
                d. Call length
                e. Contact Volume
                f. Customer Satisfaction
                g. Handle Time
                h. One Call Resolution Rate
                i. Peak hour statistics
                j. Identification of historical trends
                k. Other areas as defined by the State.
8        Automated Voice Response System (AVRS) Capability

AVR#1    Maintain a state-of-the-art, secure, and user friendly automated
         voice response (AVR) capability. Providers will use an Contractor-
         supplied toll-free telephone number, accessible by touch-tone
         telephones for all authorized users.
AVR#2    Provide a menu-driven design that allows for the use of short-cut
         key sequences and the ability to support call center integration
         during call center hours.
AVR#3    Provide intelligent menus driven by the application and only provide
         the specified client/provider with the valid options based on the
         status of their account and our recent interactions with them.
AVR#4    Monitor provider feedback to menus and options and make
         continuous improvements based on State and provider feedback.
AVR#5    Support call center integration as follows:
             a. Provide an up-front message in the AVRS to inform
                   users when the system is down or experiencing
                   difficulties including an indication of when the system is
                   expected to be operational
             b. Roll incoming calls to the fiscal agent call center staff
                   during those times when the system is unavailable
                   during the hours that the call center/help desk is staffed
             c. Provide a straightforward menu option to allow callers to
                   select an option to reach live call center staff/operator
                    during hours that call center/help desk is staffed.
AVR#6    Provide the capability to make changes to reprogram AVR recorded
         voice messages/responses/prompts at any time upon request from
AVR#7    Provide sufficient in-bound access lines.

AVR#8    Apply appropriate security in responding to eligibility inquiries,
         regardless of their source and/or mode of request. Appropriate
         security includes:
               a. The requestor must be or represent an authorized
                     Montana Health Care Program provider or other
                     authorized entity at the time the inquiry is made.
               b. The request must be for a specific provider‟s or client‟s
                     data and must be based on positive identification of
                     provider and/or client (i.e., by knowledge of the client‟s
                     name and Medicaid ID number, the client‟s name and
                     date of birth, or the client‟s name and social security
               c. The response must be in a format approved by the
                     State. Responses through AVRS and call centers must
                     meet standards approved by the State.
AVR#9    Provide the capability to restrict access to AVRS information to
         specific provider queries and according to minimum federal and
         State-defined security protocols including requiring that a valid
         provider ID number and pass code be provided before responding
         to any queries.
               a. Verify requestor identity and determine requestor‟s
                     permission to receive data (i.e., that the requestor is an
                     authorized user) according to State criteria
               b. Assign and track login parameters for authorized users,
                     including login ID, password, PIN, etc in compliance with
                     federal and departmental security standards
AVR#10   Provide appropriate safeguards to protect confidentiality of all
         information in compliance with federal, State, and department
         confidentiality laws, including HIPAA and State data security
AVR#11   Allow all providers to verify eligibility through AVRS.

AVR#12   Provide for automated logging of all transactions and maintain an
         audit trail of all inquiries and responses.
AVR#13   Produce reports as required by DPHHS.

AVR#14   Ensure that the AVRS/EVS accesses and reports current, updated,
         accurate information from eligibility files and other MMIS data files.
AVR#15   Provide access to eighteen (18) months of data based on the
         following client eligibility and benefit information:
               a. Verification of client via name and date of birth, social
                     security number and date of birth, and/or Medicaid ID

               b.    Benefit plan enrollment eligibility inquiry and status for
                     multiple programs for the date queried
               c. Benefits available, including current utilization
                     information (used and remaining) on limited benefits
               d. Current patient liability, cost of care, spend-down, and/or
                     premium information‟
               e. Status in managed care, lock-in, case management,
                     disease management, and/or other programs
               f.    Prior resource information (third-party liability).
AVR#16   Provide access to provider enrollment and coverage information,
               a. Verification of provider enrollment status in health
                     benefit programs
               b. Benefit coverage inquiry (i.e., procedure coverage)
               c. Claim inquiry and status, including the number of and
                     amount billed associated with in-process and/or
                     suspended claims
               d. Remittance advice inquiry and status information,
                     including warrant and EFT status, amounts, dates, and
                     warrant numbers; prior authorization inquiry and status
               e. Resetting, ending, and adding user password/PIN
               f.    Requesting AVRS and EVS user guide(s).
AVR#17   Provide training to providers in the use of AVRS options and
         respond to questions via a toll-free line. Contractor will provide
         special training to providers serving remote populations, FQHC,
         IHS clinics, and other safety-net providers or providers with special
9        Fax Back Capability

FB#1     Verification of client via name and date of birth, social security
         number and date of birth, and/or Medicaid number.
FB#2     Benefit plan enrollment eligibility inquiry and status for multiple
         programs for the date queried.
FB#3     Benefits available, including current utilization information (used
         and remaining) on limited benefits.
FB#4     Current patient liability, cost of care, spend-down, and/or premium
FB#5     Status in managed care, lock-in, case management, disease
         management, and/or other programs.
FB#6     Prior resource information (third-party liability).

10       Translator

TC#1     Provide translator and integrated mapping software that::
              a. Offers flexible mapping functionality supporting all
                    required formats and transactions
              b. Allows for both structure and information to be extracted
                    directly from database tables
             c.    Provides the ability to assemble, validate, encrypt, and
                  transport batches of data to and from providers and
                  other interface partners
             d. Accepts, codes, decodes and transmits all mandated
                  HIPAA healthcare transactions
             e. Provides support for automatically resubmitting the
                  transaction in the event that it encounters an error (State
                  will define the number of attempts that the system will
                  process before the transaction is considered failed)
             f.   Captures any errors that results during transmission,
                  stores this information and notifies the application that
                  the transaction failed
             g. Analyzes and rejects improperly formatted HIPAA
                  healthcare transactions
             h. Allows for the quick implementation of new transactions.
TC#2    Produce custom reports regarding:
             a. Transactions submitted by transaction type
             b.    Transactions received by transaction type
             c.    Cumulative reports over time to support forecasting.
TC#3    Track and balance transactions.

TC#4    Retain and attach information as required by HIPAA.

11      Desktop Publishing System

DPS#1   Provide for formatting and stylistic consistency including:
             a. Allow control of format, font, graphics, layout, and page
             b. Allow creation of master pages and style sheets to
                   automate and structure documents
             c. Utilize industry standard tools to assure proper spelling,
                   punctuation, grammar, capitalization, and checks for
                   technical compliance with printing industry standards
                   before publication.
DPS#2   Provide support for multi-chapter publications and large technical
        documents, including the ability to:
             a. Generate and insert footnotes and endnotes
             b. Generate table of contents
             c. Generate indices
             d. Include appendices
             e. Manage chapter files
             f.    Manage centralized style sheets
             g. Manage tabular material
             h. Import tables from various data sources into controlled
                   table structures.
TCS#3   Support distribution through printing and various electronic file
        formats, including Microsoft ™ Word, Adobe PDF, and HTML.
TCS#4   Support WYSIWYG (What you see is what you get) features
        allowing for display screen review of documents.

TCS#5   Allow for control over typographical characteristics, such as leading
        and kerning, and support for full color output.
TCS#6   Allow for output to be printed on site or support the production of
        PostScript files for printing at an outsourced print Contractor.
TCS#7   All materials will be stored in a version controlled repository
        accessible to the State.
TCS#8   Provide access for use by Contractor and State-approved staff.

12      Computer Based Training or Learning Management System

LMS#1   Provide for easy creation of computer-based courses that include
        the following:
              a. Allow upload of courses from any word processor that
                    can generate HTML formatting
              b. Allow display of HTML-formatted text, graphics, sounds
                    and audio-visual presentations
              c. Allow multiple-choice quizzes at regular intervals, and
                    provide feedback based on user responses
              d. Allow graded testing for all courses
              e. Give instructions and help to users taking the CBT
LMS#2   Provide for enrollment of individuals in computer-based courses as
              a. Allow self-enrollment for CBT courses
              b. Track each person‟s enrollment in one or more courses
              c. Allow for enrollment in one course based on other
                    courses as a prerequisite
              d. Allow secure and unique entry of users into their
                    prescribed courses
              e. Allow users to take courses more than once; to review
                    sections of a course, and to stop and start, picking up at
                    the place where they left off.
LMS#3   Provide progressive questioning capability and provide support so
        that the State staff can create and maintain the questions,
        dependent subsequent questions, and overall structure of the
LMS#4   Provide reporting on test questions, course progress and
        completion, including:
              a. Allow those completing a course to print a certificate of
              b. Allow training managers to view reports that show
                    overall course status, who has passed, who has failed,
                    who has started but not finished, and who has not
                    started a course
              c. Allow reports on individual test questions to determine
                    validity and reliability and to help improve course
LMS#5   Provide for the addition of training modules as defined by the State.

13      Web-based Survey Tools

WBS#1   Provide for the easy creation of web-based surveys:
             a. Allow easy creation of surveys by State or Contractor
             b. Allow for user-defined styles for the look of a survey.
WBS#2   Provide for ease of deployment of surveys and acceptance of
        responses as authorized by the State:
             a. Allow for email responses
             b. Provide secure “Once-only” responses
             c. Provide security for the survey and responses.
WBS#3   Provide survey results and feedback to the State:
             a. Tabulate the results of each survey and present the
                   results in chart or graph format
             b. Provide access to response data as a file that may be
                   imported to Excel or other applications
             c. Allow for responses to be viewed using pie charts, bar
                   graphs, and tabular reports
             d. Support reporting features that will allow for response
                   data to be tabulated by total number of completed
                   surveys, and number completed by county, district, or
                   other parameters in the survey.
        Financial Management Application

FMA#1   Support accounts payable and accounts receivable functions that
        are compliant with Generally Accepted Accounting Principles
        (GAAP) and facilitate Federal financial reporting.
FMA#2   This application must be capable of meeting State financial and
        data exchange requirements, now and in the future.
FMA#3   The financial package must provide meaningful and actionable
        information for program management, policy development and
        improved financial accountability.
14      Client Management

EE#1    Support the assignment of clients to Montana Health Care Program
        benefit plans based on rules in the rules engine.
        Support a client data set that contains all required data element.
        Maintain current and historical date sensitive information on other
        special benefit plan indicators attached to baseline eligibility that
        indicate different limits/services including but not limited to:
                          a. Program codes
                          b. Eligibility codes
                          c. Medicaid Waivers
                          d. Cash grant
                          e. Beginning and ending dates of coverage
                          f.     Categorical program indicator
                          g. Location indicator
                          h. Other plans as identified by state
EE#3   Support a client data set that contains all required data elements.

       Maintain current and historical date sensitive information on other
       special benefit plan indicators attached to baseline eligibility that
       indicate different limits/services including but not limited to:
                   a. Care Management
                   b. HMK extended mental health benefits for children
                         with a serious emotional disturbance (SED)
                   c. HMK extended dental plan (EDP)
                   d. Other plans as identified by the State
EE#4   Allow for day-specific eligibility on the MMIS eligibility module, and
       process claims against day-specific eligibility (e.g. one day
       authorization, 72 hour crisis).
EE#5   Maintain client identification data including but not limited to:
             a. Client ID number
             b. Universal identifier – the MMIS number to which all other
                   identifiers will be linked
             c. Name
             d. Social security number
             e. Case identification number
             f.    Aliases
             g. ID type
             h. Name source

EE#6   Maintain client demographic data including but not limited to:
            a. Mailing address
            b. Residential address
            c. Region code assignment(s), e.g. county or other
            d. Guardian, custodian, representative payee name and
            e. Date of birth
            f.    Date of death
            g. Pregnancy date of delivery
            h. Race(s)
            i.    Sex
            j.    Marital status
            k. Ethnicity or tribal designation if carried by CHIMES
            l.    Emancipated youth indicator
            m. Deprivation code
            n. Primary language spoken
            o. Primary language for correspondence
            p. Benefit address
            q. Custody status
            r.    Telephone numbers – i.e. home, cell, work, guardian and
                  individual ownership of phone
            s. Email address – attach e-mail address to client
            t.    Text number or pager number
            u. Others as determined by the state.

EE#7   For each address maintained in the client module, provide an
       address type and effective dates, and provide the capability to
        select the type of address when mailings are prepared for clients
        (e.g., TPL, EOMBs, EPSDT letters, prior authorization
EE#8    Maintain insurance coverage data in the client eligibility module
               a. Carrier
               b. Policy number
               c. Group number
               d. Pharmacy Benefit Manager (PBM) ID and client
                     identification number
               e. Sponsor, subscriber, or policy holder name/identification
               f.    Type(s) of coverage
               g. Dates of coverage
               h. Date the coverage was added to the module
               i.    Date the coverage was updated
               j.    Court order including date ranges and responsible payer
               k. Part D Enrollment Indicator.” The record should indicate
                     the member is enrolled in Medicare Part D and identify
                     the plan the recipient is enrolled in.
               l.    Allow for multiple insurance policies
EE#9    Process all transactions that update the client data set as daily
        batches or on a timely basis as determined by the State, edit fields
        for reasonableness, control and account for transactions with errors.
EE#10   Support management of client information, including archiving on a
        schedule approved by the State, with reports, transaction tracking
        and transaction error tracking.
EE#11   Archive client data sets and update transactions according to State
        provided parameters.
EE#12   Provide an indicator to suppress generation of documents
        containing client identification for confidential services or other
        reasons specified by the State.
EE#13   Maintain clinical, utilization and other indicators of special
        populations and special needs status for such programs as lock-in,
        disease management, outcomes, and high dollar case management
        files and/or future programs developed by the state.
EE#14   Maintain a record/audit trail of a client‟s requests for copies of
        personal records (including time/date of the request, source, type,
        and status of request.
EE#15   Maintain a record/audit trail of errors encountered during update
        processes, accounting for originating source and user.
EE#16   Receive and process client eligibility information from external
        sources (such as through the State‟s Eligibility System) on a
        periodic basis, including:
               a.     Produce total and detailed information that supports
                     error correction and synchronization.
               b. Apply reconciliation changes to the master client module.
EE#17   Support and track the identification of duplicate client records based
        on State-defined criteria. The MMIS should accept and cross
        reference all identification numbers assigned to a client by any State
        Eligibility System.
EE#18   Cross-reference all client ID information and utilize the data to
        collectively identify all information concerning a single client to
        prevent duplication of benefits and/or services.
EE#19   Process eligibility file updates provided on a daily basis by the
        State. This file update will include data elements necessary for the
        maintenance of client eligibility files and will return error notification
        to appropriate source.
EE#20   Accept one day authorizations for medically needy individuals
        having an incurment (spend-down) and utilize third party liability
        insurance information
EE#21   Display the name of the provider(s) used for incurment for spend
        down cases on the member file.
EE#22   Provide a robust search capability with minimal steps and
        keystrokes in the client module using all available client data
EE#23   On a daily basis reconcile the MMIS client module to a master
        eligibility file provided by the State. The Contractor will identify
        errors in the eligibility data and report these to the State with
        recommendations for corrective action.
EE#24   Allow read, write, edit, and delete client file access granted
        according to established principles related to and governed by
        privacy and security standards.
EE#25   Support a universal identifier for clients across all benefit plans and
        cross reference that identifier with all prior established benefit plan
EE#26   Provide a universal member client file with a flexible design and
        modification capabilities, including the ability to see if client is in
        multiple programs Examples include HMK and Children‟s Mental
EE#27   Provide the ability to determine if a client is enrolled in multiple
        Benefit Plans (i.e. Medicaid and HMK and distinguish which Benefit
        Plan will fund the service based on the hierarchy as established by
        the State.
EE#28   Automatically update service limits used when claims are
        adjudicated, voided or replaced. The client file must reflect changes
        in units when a void/replacement is made. Service limits must be
        updated for void/replace claims and be easily accessible to State
        staff to determine the correct number of service units used by or
        available to the client. Service limit units must link to the client (e.g.
        HMK extended dental plan).
EE#29   Allow client file to be searched by all available data elements
EE#30   Provide eligibility information available on the web portal to
        providers and other users authorized by the State.
EE#31   Store separate indicators for language spoken and correspondence
        language (client).
EE#32   Provide the ability to view a single eligibility episode that is
        comprised of multiple eligibility segments. (i.e., see the begin and
        end date for all contiguous eligibility segments).
EE#33   Produce daily audit trail reports, and allow inquiries showing all
        client data updates applied to the client master data.
EE#34   Produce system and user-generated client mailing labels, reports,
        and files, including generation of labels for only selected clients,

        e.g., by Benefit Plan, zip code, etc.
EE#35   Cross-reference all members of a case to a case number and
        provide the capability to identify all members of a case, and identify
        and link parent and children for other MMIS processes.
EE#36   Post retroactive eligibility sequentially.
EE#37   Maintain a historical record of benefit assignment(s) for a client
        including identifying dual-eligibility spans.
EE#38   Apply appropriate benefit limitations for client based on Federal
        and/or State-specific criteria.
EE#39   Maintain records of client benefit limitation information.

EE#40   Calculate and apply client cost-sharing (including premiums and co-
        pays) for specified benefits based on Federal and/or State-specific
EE#41   Maintain a record of client co-pays (cost-sharing). Co-pays must
        follow benefit plan spans.

EE#42   Maintain a record/audit trail of any client correspondence (including
        time/date sent or received, user/source, and reason for notice). All
        information must be able to be viewed and printed by State staff.
EE#43   Retain co-pay and cost sharing amounts as reported on claims,
        encounters or other sources.
EE#44   Provide the capability to exempt services (e.g. ER) and/or groups of
        individuals (e.g. pregnant women, Native Americans) from cost
EE#45   Provide the capability to limit out-of-pocket expenses at individual
        service and client levels.
EE#46   Provide the capability to recognize new limits in co-pay, and retain
        "to date" accumulations if a client moves between benefit plans.
EE#47   Provide the capability to accumulate co-pay amounts at the
        individual client level for defined periods of time. Co-pay
        accumulation may or may not continue with enrollment in a new
EE#48   Maintain a record/audit trail of responses to eligibility inquiries,
        whether by voice, fax, email, or written correspondence. If eligibility
        inquiry is done by written correspondence, the original document
        must be maintained for fair hearing concerns and State staff is able
        to easily view and print all documents.
EE#49   Include spend down requirements on 271 eligibility response.
EE#50   Accept electronic updates from all sources identified by the State.
EE#51   Provide a date/time stamp and the user ID of the person who
        accessed and/or updated the client record.
EE#52   Provide a mass adjustment capability for client information such as
        Care management provider and expiration dates.
EE#53   Identify clients who are eligible for premium payments, such as Big
        Sky Rx.
EE#54   Provide for the generation of client reports on media and in formats
        as identified by the State.
EE#55   Provide the capability to flag clients who have been placed in Lock-
EE#56   Provide the capability to identify the name(s) of the provider(s) that
        the client is locked-in to.
EE#57   Control client lock-in by date segments (e.g., prevent claim
        payments to unauthorized providers during lock-in periods).
EE#58   Provide the capability to report on the number of clients in lock-in
        status, the reason for the lock-in, and the number of unauthorized
        providers billing for services during lock-in time periods.
EE#59   Provide for multiple addresses for a client (i.e., residence,
        correspondence) and identify and generate letters to one or both
        mailing addresses. System must also have the capability to flag
        those clients who have requested correspondence not be sent to
        any addresses entered onto their record.
EE#60   Provide links to all services for a client regardless of the number of
        historical changes in client ID.
EE#61   Identify and report data exchange transactions that fail either fatal
        and/or non-fatal update edits back to the originating system and
        user area.
EE#62   Identify duplicate eligibility records in the same eligibility system
        (e.g. alias) through specified business rules and specialized
        software (e.g., mnemonic applications) and notify the originating
        system so that the issue may be resolved. Assure that the same
        client could potentially show in multiple systems with different IDs
        that all link back to one universal identifier.
EE#63   Accept and send data using various media options, such as online,
        Internet DDE, EDI, and reports to other State agencies and other
        external sources in the format required by the MMIS or device.
EE#64   Generate and produce reports as defined by the State, including but
        not limited to control reports on input and output activity.
EE#65   Provide audit trails to allow information on all client update source
        transactions to be traced through the processing stages to the point
        where the information is finally recorded, regardless of the method
        used to update. The ability to trace data from the final place of
        recording back to its source must also be provided.
EE#66   Provide the capability to compare multiple transactions processed in
        the same cycle for individuals and update according to MMIS
        defined hierarchy or priority.
EE#67   Log a date that the record is sent to any external source.
EE#68   Identify individuals with multiple program eligibility.
EE#69   Provide the capability to display and report eligibility at any point in
EE#70   Provide scheduled and ad hoc reports to meet all federal and State
        reporting requirements in all Montana Healthcare Programs.
EE#71   Track disclosure of PHI and have the capability to indicate persons
        authorized to discuss PHI for a client.
EE#72   Receive and process weekly updates for client nursing home
        authorization data.
EE#73   Maintain a module of client eligibility to support provider inquiry and
        billing (e.g., eligibility voice response, dial-up eligibility verification
        inquiries, or point -of-service).
EE#74   Provide the capability to process premium receipts for all MMIS
        health care programs to include but not be limited to:

               a. Client
               b. Month owed,
               c. Amount owed
               d. Date payment received
               e. Payment method
               f.    Primary payer
               g. Outstanding payments
               h. Payment discrepancy reports
               i.    Program for which premium is owed
EE#75   Provide authorized users with online access to premium
        determination data for all MMIS health care programs.
EE#76   Provide the capability to set the effective date of enrollment in a
        Benefit Plan on the date of enrollment, a default date or any State
        defined date (based on security access).
EE#77   Provide alerts three months prior to age 65 and again at 45 days
        prior to eligibility if the client record does not indicate Medicare TPL
        (e.g. to client, worker, TPL group, etc).
EE#78   Generate Medicare eligibility files for the Medicare claims processor
        to use in processing crossover claims.
EE#79   Provide a monthly extract of clients that are dually eligible for
        Medicare and Medicaid to the Medicare Part A, Part B, and Part D
        carriers or coordination of benefits carrier and CMS.
EE#80   Maintain current and historical information on Medicare Part
        A,B,C,D, including but not limited to
               a. Effective dates
               b. Termination dates
               c. Medicare identification number
               d. Medicare advantage plan information
               e. Part D PBM information
               f.    Other health plan information
               g. Medicare buy-in information
               h. Part D subsidy information
               i.    Part C information
               j.    Other information as defined by the State
EE#81   Capture and/or reference different types of maintenance records
        and co-pays records

15      Early and Periodic Screening Diagnosis and Treatment
EP#1    Create systems and data relationships within the MMIS to meet the
        business requirements of EPSDT.
EP#2    Provide capability to track screenings, referrals, and treatments for
        EPSDT clients.
EP#3    Provide a means within the Benefit Plan Administration Rules
        Engine to identify all clients eligible for EPSDT services:
             a. Allow entry of rules by State staff
             b. Enter rules into the Rules Engine supplied by State staff
                   as an alternative

EP#4    Identify eligible EPSDT clients according to rules established under
        Benefit Plan Administration:

             a. Identify those newly eligible
             b. Identify those who have regained eligibility
EP#5    Provide a means for recording all case activity, including:
             a. Logs of notices
             b. Recommended dates of service from the Periodicity table
             c. Actual dates of services
             d. State and Contractor contacts
             e. Case notes
        Provide Web-based query and management screens to make it
        easy for State and Contractor staff to know the next steps due
        according to the workflow.
EP#6    Use the workflow management engine to provide and log
        notices, track services provided, and enter case notes for
        each EPSDT-eligible client:
              a. Automatically generate EPSDT notification letters
                    according to specifications set by the State.
              b. Identify the family head of household or foster care
                    worker and generate EPSDT screenings letters to this
                    individual even if the child resides at a different address.
              c. Retrieve data from the MMIS claims and encounter data
                    to compare to services recommended from the
                    Periodicity Table.
              d. Provide for the inclusion of claims attachments with links
                    from EPSDT well child screens.
              e. Automatically compare and report claims to the
                    periodicity table to determine if the child received the
                    health checkup examination and related services at the
                    recommended intervals.

EP#7    Include ESPSDT information on the Web portal and
        allow clients to submit EPSDT questions:
              a. Provide program awareness and general information
              b. Provide copies of all notices.
              c. Route questions by email according to the workflow rules
                    approved by the State.

EP#8    Allow flexible sorting within EPSDT reports, for example,
        by Benefit Plan, by provider type, and by diagnosis and
        allow authorized users the flexibility to identify new data
        elements to be contained in the reports.
EP#9    Provide an indicator to denote that EPSDT screening letters are to
        be sent to a foster care worker rather than the head of household.
EP#10   Create systems and data relationships within the MMIS to meet the
        business requirements of EPSDT

16      Provider Management

        Provider System Requirements (PR)
PR#1    Provide secure access to provider applications.
PR#2    Provide notices to applicants of pending status, approval, or
        rejection of their applications.
PR#3    Require, capture and maintain the 10-digit National Provider
        Identifier (NPI) for all health care providers. Map NPI identifiers to
        historically assigned numbers and provide the capability to add NPI
        without requiring re-enrollment.
PR#4    Assign unique provider numbers for atypical providers and map to
        historically assigned numbers.
PR#5    Accept NPI in all standard transactions mandated by HIPAA.
PR#6    Interface with NPPES to verify NPI on provider applications.
PR#7    Assign provider identifiers to atypical providers that do not duplicate
        any number assigned by the NPPES.
PR#8    Provide the capability to process on NPI, taxonomy and other fields
        as specified by the state.
PR#9    Flag and route records for action if multiple internal State assigned
        provider numbers are assigned to a single atypical provider.
PR#10   Provide for date-specific provider enrollment and demographic data.
PR#11   Provide for the generation of information requests, correspondence,
        or notifications based on the status of the Provider application for
PR#12   Provide for responses to requests/inquiries on the adequacy of the
        Montana Health Care Programs provider network based on
        provider/client ratios by geographic region, provider type, etc.
PR#13   Provide for consistent provider naming conventions to differentiate
        between first names, last names, and business or corporate names
        and to allow flexible searches based on the provider name.
PR#14   Allow access to provider data to all State authorized users.
PR#15   Link the unique MMIS provider number to all source provider IDs
        such as from SABHRS or State Eligibility Systems.
PR#16   Provide for the collection and maintenance of additional data
        availability related to provider management:
              a. Sanction information
              b. Accreditation information
              c. Provider links to TIN and parent organizations
              d. Inactive/active filter
              e. Care management/Lock in restrictions
              f.     Case load assignments
              g. Field representative visits
              h. Training information
              i.     License number and licensure status
              j.     Phone logs of provider calls and communications
              k. Audit information and status of administrative reviews
                     and fair hearings
              l.     Recoveries from providers that link to the Program
                     Integrity function and SURS recovery module to create a
                     global summary of whether a recovery was made
              m. Interface with PA contractor
              n. Minimum Data Set (MDS) information from Nursing
                     Facilities (NF)
              o. Pay for performance (P4P) indicator from Medicare
              p. Endorsements
              q. Restrictions for payments (no payment for surgeries)
              r.     Verification of malpractice insurance

               s. Flag for EFT information
               t.    Flag for Electronic claim submission
PR#17   Provide the following provider search functionality on the provider
               a. Navigate through provider module by clicking data
               b. List providers by benefit plan
               c. Navigate between client and provider modules without
                     leaving program
               d. Other fields defined during the design phase
PR#18   Provide drill down capability within the provider module to view
        claims included with each payment cycle amount.
PR#19   Provide for a simplified enrollment process or use of the national
        enrollment module(e.g. Provider Enrollment Chain Owner System
        (PECOS)) for all providers.
PR#20   Provide for standardized W-9 information to reflect the owner of the
        EIN not the Doing Business As (DBA) name.
PR#21   Provide an automated comparison of the provider module against
        taxonomy or death registry.
PR#22   Provide the capability for automated disenrollment procedures
        according to State defined criteria. For example, disenroll providers
        who are sanctioned or those who have not received 1099s in two
PR#23   Provide the capability to match the data received from the death
        registry interface and create an alert when there is a match with an
        active provider name. Verify the match and disenroll the provider if
        match is accurate.
PR#24   Update any name changes (or other information specified by the
        State such as changes in licensure) with licensure database from
        Department of Labor and Industry (DOLI), other licensing agency, or
        other sources.
PR#25   Provide the capability to reactivate a previously enrolled provider
        without complete reenrollment.
PR#26   Provide a comments field on the provider module for entry of
        standardized comments.
PR#27   Verify provider enrollment in support of other system processes, i.e.,
        payment of claims.
PR#28   Provide edits in the provider enrollment and update process to track
        and identify errors and inconsistencies.
PR#29   Provide the capability to identify providers whose licenses,
        certifications, Montana Health Care Programs agreements, and
        permits are set to expire ninety (90) days prior to the end date of the
        current certification, licensing, or permit period and notify the
        Contractor of the pending expiration.
PR#30   Accept, validate, and process transactions or user entries to update
        and maintain provider information.
PR#31   Provide online user access, as defined by the State, to provider
        data and allow extraction of information. The extracts or reports
        could include such items as:
               a. The current status of providers‟ records
               b. An alphabetical provider listing

              c. A numeric provider listing
              d. A provider rate table listing
              e. An annual re-certification notice
              f.      A provider “group affiliation” listing
              g. A provider specialty listing
              h. A provider listing by category of service
PR#32   Provide current and historical multiple address capabilities for
PR#33   Provide an audit trail of all updates to the provider data, in a format
        and time period approved by the State.
PR#34   Maintain providers‟ Drug Enforcement Administration (DEA)
PR#35   Update and maintain financial data including current and prior year
        1099 reported amounts.
PR#36   Capture and maintain provider business relationships, such as,
        ownerships and partnerships.
PR#37   Provide the capability to do mass updates to provider information
        based on flexible selection criteria.
PR#38   Provide indicators to identify providers that are Fee-for-Service
        (FFS), Managed Care Organization (MCO) network only, and other
        State health care program participants, and to identify the provider‟s
        eligibility for the Montana Benefit Plans.
PR#39   Provide the ability to link and de-link to other Montana Health Care
        Programs provider IDs for the same provider, e.g., numbers used
        before the NPI was established, erroneously issued prior numbers,
        multiple NPIs for different subparts, etc.
PR#40   Provide the capability to capture and crosswalk subpart NPIs used
        by Medicare (but not Medicaid) to facilitate COB claims processing.
PR#41   Accept electronic signature on enrollment without hard copy as
        allowed by State and Federal regulations.
PR#42   Allow providers to validate provider record data through a self-
        service feature that promotes provider participation.
PR#43   Support provider contracts with multiple business associations. For
        example, the provider may be FFS Medicaid and participating in or
        associated with one or more groups of FFS providers.
PR#44   Maintains multiple provider specific reimbursement rates with
        begin/end dates, consistent with State policy, i.e.
              a. Per diem
              b. Percentage of charges
              c. FFS
              d. APR-DRG
              e. Other
PR#45   Identify provider participation by any and all variables that may
        affect claim adjudication.
PR#46   Apply provider data validity edits during the provider enrollment
        process. Screens should be auto-populated with valid data to the
        extent possible.
PR#47   Link supporting paper documents to the related systems data and
        have these imaged documents available on the user‟s desktop.
PR#48   Enable different business rule definitions by provider, provider type,
        program and geographic area.

PR#49   Link provider notifications to any and all related imaged
PR#50   Support different notifications to be sent to providers by program
        area or benefit plan.
PR#51    Allow for narrative fields to be included within the provider data
        base as defined by the State.
PR#52   Support and display office hours, accessibility, alternative language
        and alternative format indicators for provider locations.
PR#53   Enable provider application processing statistics by type, month,
        year, and processor.
PR#54   Enable manual provider look-up by name (including phonetic
        search) and ID numbers.
PR#55   Ensure the billing provider is enrolled and has a provider number.
        Individual practitioners associated with the billing provider will be
        linked to the billing provider ID. The system must have the capability
        to unlink a provider from a unique ID when two providers are
        inappropriately tied together.
PR#56   Perform automated checks of national databases and bulletin
        boards for sanctions or license revocation in other states.
PR#57   Support automated criminal background checks for all providers as
        specified by the State.
PR#58   Capture Clinical Laboratory Improvement Amendments (CLIA)
        certification information and the specific procedures each laboratory
        is authorized to cover. Link the information for use in claims
PR#59   Use CLIA information from the national data site in the certification
        process. The system must have an automated process that verifies
        CLIA numbers (i.e., interface with the federal agency that monitors
PR#60   Maintain the individual CLIA number and level for each laboratory
        site in the provider module and edit claims against this information.
PR#61   Support updates of CLIA information from the Online Survey,
        Certification and Reporting (OSCAR) interface.
PR#62   Provide the capability to disenroll providers for electronic
        submission at the provider and / or submitter levels.
PR#63   Allow a single provider to have more than one electronic submitter
        and designate to which biller the 835 will be sent.
PR#64   Enable enrollment of claims submitters (e.g. billing agents), as all
        entities that submit claims will be required to be enrolled in the
PR#65   Enable multiple provider contacts, including the contact name, title,
        telephone number and email address.
PR#66   Enable a process to suspend, terminate or withhold payments from
        providers under investigation.
PR#67   Ensure all provider significant data, including demographic data and
        data that affects or reports payment, is viewable online and directly
        updateable with appropriate authority.
PR#68   Accept retroactive changes to the provider module including who
        entered the change, when the change was made, and why the
        change was made.
PR#69   Enable mass rate changes by provider type.

PR#70   Store geographic codes for provider locations.
PR#71   Provide the capability to determine if a pharmacy claim has been
        previously paid for a drug that is included on a new claim for the
        same client from another provider type (e.g., physician).
PR#72   Edit for address standardization according to United States Postal
        Service (USPS) standardization.
PR#73   Provide for a provider type table that allows an unlimited number of
        valid provider types in the system.
PR#74   Enable specialty services capacity monitoring (e.g. to determine if
        there are sufficient providers of a given specialty in a particular area
        or if those providers have capacity to manage the numbers of
        clients within that area.)
PR#75   Provide an authentication routine to allow active and inactive
        providers ability to change their provider record through direct data
        entry via the web, based on selected criteria.
PR#76   Provide the capability of matching providers based on a file of
        sanctioned providers received from the State Board of Medical
        Examiners and the CMS sanction file, as well as other licensing and
        certification boards and flagging the provider‟s record for
PR#77   The system must store provider returned warrant information at the
        provider level.
PR#78   Produce provider mailing labels, using selection criteria such as
        individual providers, provider specialty, provider groups, provider
        type, or by a global selection.
PR#79   Allow authorized users restricted access from remote locations.
PR#80   Provide for the storage of provider- training records and reports for
        quality review and provider performance measurements.
PR#81   Provide support for online registration for provider training seminars.
PR#82   Provide for the capability to generate news alerts to authorized
        users at sign-on to the web page.
PR#83   Withhold and document provider payments as directed, establish
        offset procedures for suspended, terminated or overpaid providers,
        and establish methods for reinstating providers and resuming
PR#84   Provide a note capability for tracking provider providing care.
PR#85   Provide a repository to maintain provider complaints, administrative
        review information and fair hearing tracking.

        Operations Management

17                 Reference Data Management (RF)
RF#1    Provide a reliable and flexible system to maintain the reference data
        required for Montana DPHHS claims processing. The system should
        be configurable to adapt to changes in Montana DPHHS and CMS
        policies and services and must allow for centralized control over
        data modifications.
RF#2    Accept updates from a variety of software programs, i.e., Excel,
        Access, etc.

RF#3   Provide for role-based security to limit access to reference tables to
       State specified staff.
RF#4   Provide for usual and customary charge information for Medicaid
       and Medicare to support claims processing:
            a. Reimbursement under the Medicaid program for other
                  than outpatient drugs, Federally Qualified Health Center
                  (FQHC), Rural Health Clinic (RHC), Indian Health
                  Services (IHS) and hospital inpatient and outpatient
                  reimbursement is to be the lower of the provider‟s “usual
                  and customary” charge, the rate established by the
                  State, or the amount that is allowed under the Medicaid
                  program. “Usual and customary” charges are calculated
                  from the actual charges submitted on provider claims for
                  Medicaid payment.
            b. Reimbursement for prescription drugs is calculated as
                  the lesser of:
                  i.    Federal Upper Limit (FUL) or Maximum Allowable
                        Cost (MAC) plus a dispensing fee
                  ii. Estimated Acquisition Cost (EAC), which is defined
                        by the Average Wholesale Price (AWP) less 15 to
                        20 % plus a dispensing fee (ranging anywhere from
                        $2.00 to $4.86.
                  iii. The provider‟s usual and customary charge
RF#5   Provide for the capability to apply the following pricing
       methodologies or claim pricing functionality as specified by the
            a. DRG with multiple base rates
            b. APC with multiple conversion factors
            c. Sole-community
            d. Lab Panel vs. Automated Test Panel (ATP)
            e. Edits/limits
            f.    All-inclusive rates
            g. Negotiated rate
            h. Geographic rate
            i.    Waiver rates
            j.    RBRVS with multiple conversion factors
            k. Provider type
            l.    Bundling/unbundling
            m. Pharmacy pricing as defined by the State
            n. Pay for performance
            o. Funding source
            p. Per diem
            q. Fee schedule pricing as determined by the State
            r.    Present on Admission (POA)
            s. Medicare Fees
            t.    By Report
            u. ASP
            v. Cut Back
            w. 340B pricing
            x.     RVD (Relative Value Dental)
            y. Other
RF#6   Provide the capability to accommodate variable date-sensitive
        pricing methodologies for identical procedure codes based on
        modifiers, benefit plans, recipient data, provider types and
        specialties, provider specific data, and other criteria defined by the
RF#7    Provide the capability to support payment for services by providing
        reference data, including procedure, diagnosis, and formulary codes
        (42 CFR447).
RF#8    Provide and maintain online access to all reference tables with
        inquiry by the appropriate code.
RF#9    Provide the capability to maintain and update edits, limits, and
        restrictions to all codes that are included in any standard HIPAA
        transaction (e.g. procedure codes, discharge status codes, NDC);
        provide online update and inquiry access, including but not limited
              a. Coverage information
              b. Restrictions
              c. Service limitations
              d. Automatic error codes
              e. Pricing data
              f.      Effective dates for all items
              g. Fund code or benefit plan (POB) code
              h. Other, as defined by the State
RF#10   Provide and maintain an audit trail of all information changes,
        including errors in changes.
RF#11   For audit purposes provide and maintain the following data for all
        reference codes:
              a. Effective date
              b. End date
              c. Date when last changed
              d. Who changed it
RF#12   Provide and maintain date sensitive parameters for all Reference
        Data Management data.
RF#13   Provide and maintain the trauma indicators to identify potential Third
        Party Liability (TPL) cases.
RF#14   Accommodate retroactive rate changes as they relate to medical
        procedures and limitations.
RF#15   Apply updates to all codes upon new releases (e.g. quarterly or
        annually) or when requested by the State.
RF#16   Provide and maintain narrative descriptions of each code contained
        in the files.
RF#17   Capture and use/store all available claim data (e.g. condition codes,
        occurrence codes, etc.).
RF#18   Provide the ability to inquire on all code sets.
RF#19   Support code sets for the payment of any Montana Health Care
        Programs that are non-health care services (e.g. waiver services).
RF#20   Provide and maintain the drug-pricing file, updating it at State
        specified scheduled cycle.
RF#21   Provide, allow inquiry status and maintain current and historical
        coverage status and pricing information on legend drugs, Over The
        Counter (OTC) items, and injection codes.
RF#22   Accommodate weekly updates of NDC drug file.

RF#23    Update reason and remark codes as requested by the State.
RF#24    Support code sets for account coding and Federal Report coding
         based on business rules provided by the State.
RF#25    Provide the capability to store archives of all versions of reference
         information and update transactions.
RF#26    Provide the capability to easily retrieve, as needed, archived
         reference data for processing of outdated claims or for duplicate
         claims detection.
RF#27    Provide current and historical reference data used in claims
         processing and stored by activation and deactivation date.
RF#28    Provide and maintain a complete history of previous fee schedules.
RF#29    Provide, allow inquiry status and maintain current and 10 years of
         historical date-sensitive NDC Drug Code information.
RF#30    Maintain seven (7) years of history for all code sets (reference
         information) online for inquiry.
RF#31    Provide capability to allow multiple data elements to apply to all
         codes (e.g. multiple age spans).
RF #32   Provide capability to support all procedure code sets as mandated
         by HIPAA (e.g. CPT-4, HCPCS, CDT, etc.).
RF #33   Provide capability to support ICD-9 and ICD-10 diagnosis and
         procedure code sets as mandated by HIPAA.
               Claim Receipts Management

CR#1     Provide the capability to capture and accurately input all claims into
         the system at the earliest possible time.
CR#2     Provide the capability to incorporate eligibility verification of clients,
         claims data capture, prospective drug utilization review (ProDUR),
         claims adjudication, and receipt of ANSI X12N transactions.
CR#3     Assign each claim a unique identifier upon its entering the system.
CR#4     Provide the capability to accept and use the institutional paper
         billing form developed by the National Uniform Billing Committee
         (NUBC), for non-electronic claims.
CR#5     Provide the capability to accept and use the common non-
         institutional paper claim form developed by the National Uniform
         Claim Committee (NUCC), for non-electronic claims.
CR#6     Provide the capability to accept and use the common dental paper
         billing form developed by the American Dental Association (ADA),
         for non-electronic claims.
CR#7     Provide the capability to accept and use a paper pharmacy claim
CR#8     Control, track, and reconcile captured claims to validate that all
         claims received are processed.
CR#9     Provide the ability to identify claims input for control and balancing
         (hardcopy and electronic media).
CR#10    Receive standardized encounters in 837 format.
CR#11    Provide and maintain a data entry system that includes, but is not
         limited to, hardcopy claims and claim adjustment/voids which
         provides for field validity edits and pre-editing for including but not
         limited to:
                a. Provider number
              b. Provider type
              c. Specialty
              d. Sub-specialty
              e. Client ID number
              f.     Client age/gender restrictions
              g. PA SA required
              h. Modifiers
              i.     Place of service
              j.     EPSDT
              k. Co-Payment indicators (overrides)
              l.     Eligibility aid category
              m. Family Planning indicator
              n. Claim type
              o. Procedure codes
              p. Diagnosis codes
              q. Emergency indicator
              r.     Units of service
              s. Tooth number or letter and/or quadrant
              t.     National Billing uniform editor code set
              u. Care management authorization number
CR#12   Produce an electronic image of hardcopy claims and claims-related
        documents, and perform quality control procedures to verify that the
        electronic image is legible and meets quality standards.
CR#13   Provide the ability to screen and capture electronic images, date-
        stamp, assign unique control numbers and batch hardcopy claim
        forms and attachments, and adjustment/void forms.
CR#14   Provide the capability to receive and store more than one version of
        an attachment while validating and marking which version is the
        correct version.
CR#15   Capture and process the attachment indicator field on all electronic
        media claims to identify claims for which attachments are being
        submitted separately.
CR#16   Accept, process, store and provide access to Medicare, or other
        carrier, crossover claims (for coinsurance and deductible) for
        Medicare or other carrier Explanation of Benefits (EOB) claims
CR#17   Provide the ability to tie the electronic claim to all related paper
        claim images, attachments and adjustments that are submitted for
        the claim.
CR#18   Receive and process electronic attachments and apply them to one
        or more claims.
CR#19   Provide the capability to accept attachments to any transactions
        (claim, SA, Eligibility) and apply an attachment indicator in the MMIS
        and DSS.
CR#20   Accept attachments as part of treatment plans.
CR#21   Process attachments of TPL denial and verification of TPL payment
        as required by State policy and Federal regulations, and carry
        sufficient information to properly adjudicate claims, to flag for TPL
        pay-and-chase programs, and to report.
CR#22   Assign the appropriate attachment code or other indicator to the
        hard copy claim to ensure proper association with the TPL edits in
        the claims payment process and to ensure proper reporting.
CR#23   Log each batch into an automated batch control system.
CR#24   Provide the ability to identify and report claim entry statistics to
        assess performance compliance.
CR#25   Provide for a unique submitter number for each billing service or
        submitter that transmits electronic or paper claims to the MMIS for a
        single provider or multiple providers.
CR#26   Provide the capability to edit check for correct provider number
        when the provider submits the claim (at the front end). Example:
        The NPI check sum is correct and matches the first three letters of
        the provider‟s last name.
CR#27   Provide and maintain a Web portal for providers to directly and
        efficiently enter claims and transactions with a direct data entry
        (DDE) capability.
CR#28   Provide the ability to support testing of new provider claims
        submission systems by allowing providers to submit electronic
        claims test files that are processed through the adjudication cycle
        without impact on production system data.
CR#29   Identify and correct any incomplete claim batches that fail to
        balance to control counts.
CR#30   Provide an electronic acknowledgment and balance for receipt of
        electronically submitted claims as required by the State.
CR#31   Provide and maintain the capability to process standard financial
        transactions including recoupments and payouts which cover more
        than one claim/service.
CR#32   At a minimum, accept the following types of electronic claims:
        electronic batch, individual electronic (e.g. POS), Direct Data Entry
        (DDE) and paper claims converted to electronic by an imaging
CR#33   Provide the capability to accept and process Medicare and other
        carrier crossovers electronically at the claim and line level.
CR#34   Provide the capability to edit for potential duplicate services across
        all claim types as defined by the state when claims are submitted by
CR#35   Accept, record, store, and retrieve freeform or HIPAA attachment
        documents submitted with or in reference to claim submission
        activity, such as, but not limited to:
               a. Operative reports
               b. Occupational, physical, and speech therapy reports
               c. Durable Medical Equipment (DME) serial number, cost,
                     description of miscellaneous code, and warranty data
               d. Manufacturer‟s tracking data for implants
               e. Waivers and demonstration specific requirements
CR#36   Accept, process, store and provide access to prior authorization
        attachments These attachments may be housed in the Electronic
        Document Management System (EDMS) such as:
               a. Surgical/anesthesia reports
               b. Medical records
               c. X-rays/images
               d. Orthodontic study models
               e. SLTC (Senior and Long Term Care) prior authorizations
               f.    Certain prescription drugs as required

               g. Other items required by State or Federal rules
CR#37   Interface with an EDMS to verify other claim related inputs to the
        MMIS, including but not limited to:
               a. Sterilization, abortion, and hysterectomy consent forms
               b. Manual or automated medical expenditure transactions
                     which have been processed outside of the MMIS (e.g.,
               c. Non claim-specific financial transactions such as fraud
                     and abuse settlements, insurance recoveries, and cash
               d. Electronic cost reports
               e. Disproportionate share reports
               f.    Drug rebate
               g. Any other inputs required for services under the State‟s
                     approved plan
CR#38   Provide the capability to accept and process detailed line level
        claims processing for specified services on all claims types.
CR#39   Accept and process any standard data that can be submitted on any
        claim or claim type.
CR#40   Provide the capability and system support for sending and receiving
        electronic claims transactions, containing valid codes, required by
        45 CFR Parts 160 and 162, as follows:
               a. Retail pharmacy drug claims (NCPDP)
               b. Dental health care claims (X12N 837D)
               c. Professional health care claims (X12N 837P)
               d. Institutional health care claims (X12N 837I)
               e. Coordination of benefits data, when applicable
               f.    The X12N 270/271, X12N 276/277, X12N278 and
               g. All future EDI transactions required under HIPAA.
CR#41   Provide secure, HIPAA compliant software and documentation for
        use by and at no cost to, providers to submit electronic claims.
CR#42   Process batch 837 claims, rejecting only individual claims with
        errors and accepting all others.
CR#43   Provide an electronic tracking mechanism to locate archived source
        documents or to purge source documents in accordance with
        HIPAA security provisions and State requirements.
CR#44   Perform front-end edits to claims prior to acceptance with user
        defined edits that include checking the provider contract balances,
        provider enrollment, client enrollment, revenue codes, prior
        authorization number, procedure codes, and diagnosis codes and
        send rejection notification to the provider if the claim fails these
CR#45   Provide the ability to reject claims based on an individual claim
        basis, utilizing front-end edits as specified by the State (e.g., claims
        that fail front-editing rules will not get into the system), and maintain
        a log of all rejected claims.
CR#46   Accept and process roster billed services at the direction of the

19           Claim Adjudication

CA#1    Process claims when clients have multiple benefit plans according
        to the hierarchy determined by the State.
CA#2    Provide the ability to track and report on all claims within the
        processing period (e.g. paid, suspended, rejected or denied).
CA#3    Allow a line item on a claim to be denied or pended while allowing
        the remaining line items on a claim to be processed as specified by
        the State.
CA#4    Flag and route for manual review claims with individual procedures
        and combinations of procedures which require manual pricing in
        accordance with State parameters.
CA#5    Flag and route for manual intervention claims that fail State-defined
        service limitations including once-in-a-lifetime procedures and other
        frequency, periodicity, and dollar limitations as specified by the
CA#6    Provide the capability to pend for review claims or claim types that
        are identified by the State.
CA#7    Verify that suspended transactions have valid error/exception
CA#8    Suspend claims with exceptions/errors and route for correction to
        the organizational entity that will resolve the exception/error, unless
        automatically resolved. The organizational entity will resolve the
        claim based upon the State‟s criteria.
CA#9    Track claims flagged for investigative follow-up because of third
        party discrepancies.
CA#10   Generate and maintain audit trails for all claims activity.
CA#11   Verify that all claims for services approved or disallowed are
        properly flagged as paid or denied.
CA#12   Document and report on the time lapse of claims payment, flagging
        or otherwise noting clean claims (error free) that are delayed over
        30 days.
CA#13   Provide prompt response to inquiries regarding the status of any
        claim through a variety of appropriate technologies, and track and
        monitor responses to the inquiries. Processes electronic claim
        status request and response transactions (ASC X12N 276/277)
        required by 45 CFR Part 16
CA#14   Provide access to claims history for use by Program Management
        and Program Integrity.
CA#15   Assign claim status (i.e., approved, denied, pended) based on the
        State‟s criteria.
CA#16   Identify and hierarchically assign status and disposition of claims
        (suspend or deny) that fail edits based on the edit disposition
CA#17   Identify and track all edits and audits posted to the claim in a
        processing period.
CA#18   Provide and maintain, for each error code, a resolution code, an
        override, and force or deny indicator, and the date that the error was
        resolved, forced, or denied as directed by the State. Verify that
        claim correction activities have entered only valid override code(s)
        or manual prices.
CA#19   Process automatic bundling and unbundling of claim lines based on
        rules established by the State.

CA#20    Provide the capability to enable a bed hold process between
         nursing facilities and hospitals according to rules established by the
CA# 21   Provide the capability to enable retainer days between waiver
         services, nursing facilities and hospitals according to rules
         established by the State.
CA#22    Allow valuation and reporting of standardized encounters without
         payment in 837 format.
CA#23    Automatically check all claims, across all claim types (i.e.
         institutional, professional, dental, pharmacy), for duplicates
         according to rules established by the State.
CA#24    Validate annual or lifetime limits across transaction types
         (institutional, professional, dental, prior authorization, eligibility) and
         apply rules for adjudication.
CA#25    Provide the capability to configure edits and audits in a rules engine.
CA#26    Allow up to 100 edits to any claim as defined by the State. Provide
         the capability to limit the number of errors on a single claim before
         denying the claim.
CA#27    Provide the capability to establish a prioritization of edits, as defined
         by the State, so that major edits process first.
CA#28    Provide the capability to capture and process the number of claim
         lines specified in the HIPAA named transactions at a minimum.
CA#29    Specify the century in all dates wherever they are used, (e.g. within
         the Internal Claim Number (ICN) or prior authorization numbers
         assigned in a format defined by the State).assigned to incoming
CA#30    Provide the capability to process according to multiple eligibility date
         spans as specified by the State.
CA#31    Maintain 60 months of claims history online.
CA#32    Maintain historical reference to any claims with lifetime limits for a
         period of time defined by the State.
CA#33    Provide the capability to process Medicare, and any other carrier,
         crossovers electronically.
CA#34    Provide the capability to account for cost recovery at either the claim
         or line level as specified by the State.
CA#35    Edit, validate, and/or verify that all claims data meets or exceeds
         state requirements for validity including, but not limited to:
                a. All fields defined as numeric contain only numeric data.
                b. All fields defined as alphabetic contain only alphabetic
                c. All dates are valid and reasonable.
                d. All data items which can be obtained by mathematical
                      manipulation of other data items, agree with the results
                      of that manipulation.
                e. All coded data items consist of valid codes, (e.g.,
                      procedure codes, diagnosis codes, service codes, state
                      specific modifiers, etc.) are within the valid HIPAA
                      Transactions and Code Sets (TCS) code set and are
                      covered by the State Plan.
                f.    Any data item that contains self-checking digits (e.g.,
                      Client I.D. Number) passes the specified check-digit test.

             g.     Numeric items with definitive upper and/or lower bounds
                    are within the proper range.
               h. Required data items are present and retained including
                    all data needed for State or Federal reporting
                    requirements (see SMM 11375).
               i.   Date of service is within the allowable time frame for
               j.   Procedure is consistent with the diagnosis as specified
                    by the State.
               k. Procedure is consistent with the client‟s age as specified
                    by the State.
               l.   Procedure is consistent with the client‟s sex as specified
                    by the State.
               m. Procedure is consistent with the place of service as
                    specified by the State.
               n. Procedure is consistent with the category of service as
                    specified by the State.
               o. Billed amount is within reasonable and acceptable limits
                    or if it differs from the allowable fee schedule amount by
                    more than a certain percentage (either above or below),
                    then the claim is flagged and routed for manual review
                     i. Possible incorrect procedure
                     ii. Possible incorrect billed amount
               p. Claim is not a duplicate of a previously paid claim
                    (including a prior one in the current processing period).
               q. Dates of service of an institutional claim do not overlap
                    with the dates of service of an institutional claim from a
                    different institution for the same client.
               r.   Dates of service for a practitioner claim do not overlap
                    with the dates of service for another claim from the same
                    practitioner for a single client unless the additional
                    services are appropriate for the same date of service.
               s. Provider is eligible to render service(s) during the period
                    covered by the claim.
               t.   Provider is eligible to render the specific service covered
                    by the claim
               u. Provider is eligible to provide the specific service covered
                    by the benefit plan to the specific client
               v. Client is eligible for the particular category of service at
                    the time it was rendered.
               w. Edit using National uniform editor guidelines
               x. Benefit plans.
CA#36   Edit claims for consistency and payment limitations using the
        Medicare Correct Coding Initiative and OPPS or similar editing
        criteria, based upon the State Plan for all claim types.
CA#37   Provide the ability to create client contract (e.g. pain management):
               a. Include a claim indictor showing treatment plan or
               b. Provide access to/from SA contractor database(s) as
                    specified by the State.
               c. Provide access to treatment plans by providers via the

                      web portal.
              d.      Verify eligibility when contract/treatment plan indicator is
CA# 38   Provide the ability to use treatment plans for comprehensive care
         management, Plans of Care and in the processing of claims.
CA#39    Provide capability to generate an EOB to every client or a selected
         group of clients based on requirements as defined by the State.
CA#40    Provide the capability to pay claims per capita, from encounter data
         or fee-for-service (e.g. PACE).
CA#41    Provide the capability to price out-of-State claims according to State
         policy (i.e., at the local rate, at the other State‟s rate, or flag and
         route for manual pricing).
CA#42    Record and edit to ensure that all required attachments, per the
         reference records or edits, have been received and maintained for
         audit purposes.
CA#43    Price claims according to pricing data and reimbursement
         methodologies and benefit plans applicable on the date(s) of service
         on the claim.
CA#44    Deduct Third Party Liability (TPL) paid amounts and Medicare paid
         amounts, at the claim level or line level, as defined in the State
         Plan, when pricing claims.
CA#45    Price Medicare coinsurance, deductible, or co-pay (Part C) for
         crossover claims, depending on State policy, at the lower of the
         Medicaid or Medicare allowed amount. Provider types affected will
         be determined by the State.
CA#46    Provide the capability to price services billed with procedure codes
         with multiple modifiers.
CA#47    Price claims according to the policies of the program the client is
         enrolled in at the time of service and edit for concurrent program
CA#48    Provide and maintain test claim processing capabilities with
         providers at provider‟s request.
CA#49    Provide the capability to process claims based on pricing logic as
         listed in the Reference Data Management Section.
CA#50    Provide the capability to pay different rates for the same service
         based on the program or benefit plan as specified by the State.
CA#51    Establish a mechanism to pay other types of contracts, (e.g. PCCM,
         Disease Management, etc.
CA#52    Provide the capability to process and track alien and prisoner claims
         as indicated by the client file in TEAMS/CHIMES.
CA#53    Provide the capability to validate disease/care management
         eligibility against MMIS eligibility.
CA#54    Provide the ability to apply edits related to Montana Health Care
         Programs responsibility for nursing facility payments for a Medicare
         client (days 21-100) as defined by the State.
CA#55    Provide the capability to perform clinical appropriateness reviews
         prior to payment as defined by the State.
CA#56    Provide the capability to perform prepayment reviews on providers
         as defined by the State.
CA#57    Provide the capability to adjudicate claims based on criteria
         established in treatment plans, including attachments to those

        treatment plans as defined by the State.
CA#58   Adjudicate the Disability Services Division HCBS claims based on
        the rate structure and Individual Cost Plan (ICP) as defined by the
CA#59   Provide the capability adjudicate using the National Provider
        Identifier (NPI) and taxonomy if the provider is required to have an
CA#60   Provide the capability to stamp the date, report code and account
        code at the claim and line level of each claim.
CA#61   Provide the capability to create financial transactions to make
        payments to clients, providers and other entities such as Big Sky
        Rx, foster care, or non-emergency transportation, or ESRD.
CA#62   Make payments from multiple benefit plans and track such
        payments for reporting using the account code stamped on each
        claim line and financial transaction.
CA#63   Account for personal resources for nursing facility residents before
CA#64   Enable the use of personal trust for Disability Services Division
        individuals as personal resource before paying claims. Personal
        trusts will function similar to spend down to meet personal
        responsibility before the State payment.
CA#65   Flag for review claims for the same client with a diagnosis and
        procedure which indicate an emergency that occurs within one day
        of a similar claim from the same provider in accordance with the
        State requirements for each benefit plan.
CA#66   Route and report on claims that are processed on or after the
        client‟s date of death for follow-up by client eligibility or Third Party
        Liability (TPL) personnel.
CA#67   Provide and maintain the capability to monitor services for
        suspected abusers using a “pay and report”, lock-in, or some
        equivalent system function that will provide reports of the claim
        activity for these clients as scheduled or requested.
CA#68   Provide and maintain the capability to pend or deny claims for
        clients assigned to the client lock-in program based on State
CA#69   Provide and maintain the capability to edit claims for clients in long
        term care (LTC) facilities and psychiatric residential treatment
        facilities (PRTF) to ensure that services included in the payment
        rate are not billed separately by individual practitioners or other
        providers across all claim types.
CA#70   Provide and maintain the capability to process client cost sharing
        (e.g., co-payments, LTC patient liability) on any service specified by
        the state using a fixed amount or percent of charges.
CA#71   Edit claims for newborn eligibility based upon State-defined
        newborn enrollment policies and procedures.
CA#72   Edit for client participation in special programs (i.e. waivers) against
        program services and restrictions.
CA#73   Limit benefits payable by client eligibility category or other client
CA#74   Receive and store a care plan or treatment plan tied to a client and
        allow modifications by authorized users.

CA#75   Provide capability to generate EOBs that relate to NPI at pay to,
        attending or rendering level and obtain all claims for that NPI.
CA#76   Determine the extent to which authorized benefits are payable
        under Title XIX using Medicare, QI1, SLMB and/or QMB guidelines
        and procedures, from the appropriate Medicare fiscal intermediary
        or carrier both in-state and out-of-state.
CA#77   Provide the flexibility to close a benefit plan per program or client
        based on budget.
CA#78   Provide the capability to allow groups/clinics to bill more than one
        rendering provider on a paper or electronic claim without splitting
        the claim.
CA#79   Support payment activities for Developmentally Disabled Services
        (DDS) plans of care within the MMIS.
CA#80   Support online testing of a claim (to see how it is going to process)
        through the system, and return processing and error messages to
        the submitter as they would appear in production.
CA#81   Track accountability of all changes to a claim by user, date and type
        of change.
CA#82   Support online viewing to users determined by the State of the
        following consolidated payment history:
               a. Claims
               b. Payment
               c. Client direct payments
               d. Medicare buy-in payments imported from the Eligibility
CA#83   Ensure that all electronic claim submitters are enrolled within the
        system, and every provider for whom claims are submitted is
        registered as having an agreement with the submitter.
CA#84   Allow for the user defined suspension of claims by variable
        parameters (e.g. client, provider, date range, procedure, benefit
        limits, benefit plans, etc.).
CA#85   Provide the ability to retain claims, using user-defined criteria, in an
        unpaid status that are fully adjudicated until released or voided.
CA#86   Allow for resubmission of rejected and denied claims on a self-
        service basis through the web portal.
CA#87   Pend claims for a designated period of time as defined by the State.
CA#88   Accumulate and report statistics on why claims are denied.
CA#89   Accumulate and report statistics on why claims edits are overridden.
CA#90   Support multiple claims status, to include denied, paid, suspend
        with / without notification to providers.
CA#91   Utilize edits in the claims process to track out-of-pocket limits and
        benefit limits.
CA#92   Adjudicate claims based on HIPAA standard code sets in effect on
        the date of service.
CA#93   Support claim adjudication based on HIPAA procedure modifiers in
        effect on the date of service,(i.e. the ability to bring in all modifiers
        and use a hierarchy defined by the State).
CA#94   Allow for interim billing in accordance with user defined criteria.
CA#95   Support claims edits by benefit plan, age limitations, gender
        limitations and service limitations.
CA#96   Support claims edits that are date sensitive and retain the date

         parameters for historical reference.
CA#97    Provide the ability to replace or add codes and have existing edits
         apply to the new codes using a rules engine.
CA#98    Allow edit rules to vary by, but not limited to, benefit plan, service
         and claim type.
CA#99    Determine the deductible, coinsurance, allowed, and adjusted
         amounts applied for each line on a claim.
CA#100   Support an edit structure that will include at a minimum: definition,
         description (long & short), instruction, description to send in 835
         transactions, description mapped to reason/remark code, and edit
         criteria (including unit‟s definition, periodic financial limit, etc.).
CA#101   Provide the capability to match bundled services edits (panels, all
         inclusive) to unbundled service edits and the reverse.
CA#102   Allow claims specified by the State to be forced (i.e., bypass certain
         edits). However, those claims will still require a minimum set of
         complete data.
CA#103   Support an online process to view every edit that applies to a data
         element (e.g., stand alone entry of client, procedure, etc.) or a
         combination of elements.
CA#104   Allow user to define through the rules engine the fields that apply to
         all claim edits.
CA#105   Provide the capability to send client notices concerning claim
         adjudication based on user-specified criteria by an authorized
         person, (claim edits and/or exceptions).
CA#106   Maintain an audit trail of the matching line number from the client
         plan of care list, and store it in the claim record.
CA#107   Allow all activities tracked for a claim to be reported to a group of
         assigned users as well as individual users.
CA#108   Pay the remainder of the claim beyond the spend-down amount
         based on spend-down information received from CHIMES.
CA#109   Provide the ability to reduce or increase the amount allowed by a
         specified amount or percentage defined by the State at the time a
         claim is priced by benefit plan or as defined by the State.
CA#110   Report all claim lines billed by a provider as a single claim or HIPAA
         transaction by a provider as a single claim document to users and
CA#111   Allow, as directed by the State, payment of co-pay on behalf of the
         client when Montana Health Care Programs is not the primary
         payer, if co-pay is less than Montana Health Care Programs allowed
         amount and client has other insurance (including Medicare).
CA#112   Provide an online process to manually suspend claims.
CA#113   After corrections are applied to a rejected claim, re-process the
         corrected claim through all edits and audits.
CA#114   Price claims that successfully passed edits and audits.
CA#115   Continue to adjudicate claim lines on a valid claim, even though
         other lines may be denied as specified by the State.
CA#116   Use the CLIA data in claims processing.
CA#117   Adjudicate any file size or number of claims submitted electronically.
CA#118   Provide the ability to store claims processed through the Point of
         Sale capability of PBM.
CA#119   Support a customized (reduced data requirements) online claim

         submission feature for wavered services, transportation brokers,
         and other entities not covered by HIPAA.
CA#120   Support soft claims edits to send warnings and alerts, but not deny
         or suspend the claim line.
CA#121   Support claims adjudication based on provider taxonomy codes.
CA#122   Accept electronic claim data from providers who meet HIPAA
         electronic claims submission standards.
CA#123   Store information regarding all payments generated for the clients.
CA#124   Provide the ability to process a claims payment file daily and weekly
         as specified by the state.
CA#125   Ensure that replacement warrant numbers are reflected in claims
CA#126   Store information about possible accidents as obtained from claims
         submission, self report or other sources.

CA#127   Recognize code sets, limits, duplicates, etc. regardless of the type
         of bill (Point of Sale, dental, UB/837I vs. 1500/837P).
CA#128   Process and adjudicate all Medicare crossover claims received from
         the Medicare Coordination of Benefits Contractor (COBC), ensuring
         that all Medicare benefits are expended before Medicaid payment is
CA#129   Provide the ability to inquire on payment status of claim lines,
         associated voids, adjustments and payments (by provider and
         authorized user).
CA#130   Allow authorized users to override the system edits to pay a claim
         per business rules. Track and report all overrides.
CA#131   Provide the capability to generate payments on demand.
CA#132   Store information from State Eligibility Systems on the claims that
         have been used to meet spenddown amount and, therefore, are not
         paid by the MMIS.
CA#133   Provide the capability to pay claims for spend down clients upon
         notice from the Eligibility System that spend down requirements
         have been met either through payment of health care claims by the
         client or by the cash option under which the client pays the spend
         down amount to DPHHS
CA#134   Provide the ability to process for outlier payments.
CA#135   Provide the capability to show all denied claims, including edits,
         showing all of the denial reasons on the RA.
CA#136   Allow void and replace claims for the period of time specified by the
         State. Claims must meet timely filing requirements.
CA#137   Automatically update service limits for clients when claims are
         voided or replaced and allow online access to client service limit
CA#138   Assign account coding on all transactions processed through an
         adjudication cycle based on State provided business rules. The
         account coding must be stamped on each claim line during the
         adjudication process
CA#139   Assign a federal report code on all transactions processed through
         an adjudication cycle based on State provided business rules. The
         federal report code must cross walk to the correct report, report
         page, report line and report column

CA#140   Provide capability to process claims against different monthly and
         annual maximum service amounts for service with each benefit

         Remittance Advice
CA#141   Provide the capability to produce an accurate and timely remittance
CA#142   Provide the capability to use NPIs so remittance advices can include
         claims from more than one program.
CA#143   Produce a remittance advice than can be downloaded as a PDF
         version from the web portal.
CA#144   Assure that the remittance advice contains accurate information
         related to bundling and unbundling of services
CA#145   Provide the capability to capture denial path of claims, including
         edits, showing all of the denial reasons on the RA.
CA#146   Meet the requirements for production of RAs as specified in the.
         State Medicaid Manual Part 11, Federal Regulations 42 CFR
         433.116, 42 CFR 455.20.
CA#147   Generate an electronic 835 RA that enables providers to
         electronically download and/or view the remittance.
CA#148   Support the creation of an 835 and paper remittance advice for
         claims including claims processed through the Point of Sale
CA#149   Allow the ability to cutback the amount to be paid on a claim based
         on criteria set by the State. When line cutback occurs, claims history
         and the remittance advice for claims that were cutback will include
         the following data:
               a. Date billed
               b. Units
               c. Original payment calculation
               d. Amount of cut back
               e. Actual payment amount
               f.    Other criteria as defined by the State
CA#150   Provide the ability to produce paper RA and/or electronic RA, driven
         by provider module, including sorting options.

         Mass Void and Replacements
CA#151   Provide a test environment that enables modeling of mass void and
         replace impacts through adjudication before running the void and
         replacements in a production cycle.
CA#152   Track and reference any void and replacements (paper or
         electronic) to original claims.
CA#153   Record and date any claims adjusted so they can be viewed by the
         State along with reasons for adjustments.
CA#154   Allow mass void and replacements for any period of time specified
         by the state.
CA#155   In claims history, show the original claim control numbers as well as
         the claim control number assigned to the adjustment. All void and
         replacements shall contain an entry identifying the reason for the
         void and replace.

CA#156   Reflect all void and replacements on the claims history file.
CA#157   Support claim adjustments and recoupments through a void and
         replace process.
CA#158   Provide the ability to reprocess denied and paid claims, i.e. mass
         adjustment through a void and replace process.
CA#159   Provide the ability to allow voids and replacements to update an
         accounts receivable.
CA#160   Determine the retroactive change effect when pricing methodology
         or amount changes are enacted. The system must allow the user to
         determine whether or not to run the re-pricing.
CA#161   Notify provider of all voids, replacements and recoupments in a
         manner that provides the details of the recoupments (e.g. amounts,
         links to specific clients and transactions), claims involved in the
         voided and replaced claims and flags detailed claims with the fact of
         void and replacement.
CA#162   Automatically take appropriate action to adjust claim lines, based on
         criteria specified by the State, on adjustments from Medicare and
         other payers.
CA#163   Allow all designated users to perform the following mass void and
         replace actions:
                a. Select and review
                b. Release all
                c. Release selected claims
                d. Start over
                e. Cancel
CA#164   Allow selection criteria for, and mass void and replacements to be
         applied by, at least the following:
                a. ICN
                b.    Codes
                c.    Provider number or name
                d.    Provider type
                e. Provider specialty
                f.   Date(s)
                g. Client
                h. Other criteria as defined by the State.
CA#165   Provide the capability to model mass void and replace impacts prior
         to releasing into production to assist State staff in determining how
         claims will be paid and fiscal impacts that may result.
CA#166   Support a mass void and replace process that will allow adjustments
         by a specified amount or a percentage (e.g., based on an audit
         result from a sample of claims).
CA#167   Provide the capability void claims using the mass functionality (i.e.,
         not replace the voids).
CA#168   Provide a mass void and replace process when third party resource
         is recognized retroactively.
CA#169   Support online void and replacements to previously adjudicated
CA#170   Allow claims void and replacements that do not affect payments.
CA#171   Provide the capability to create financial transactions for the
         purpose of making non-claim based payments and recoveries from
         providers, clients and other entities and provide the ability to

         indicate whether the payment is subject to offset against
         outstanding accounts receivable balances.
CA#172   Provide the capability to manually or automatically adjust an entire
         claim, individual line items, or both based on business rules
         established in the rules engine.
CA#173   Provide the ability to indicate whether the recovery is to be offset
         against claims or financial transaction payments
CA#174   Allow multiple lines on a financial transaction with account and
         federal report coding at the line level.
CA#175   Automatically create financial transactions and apply correct
         account and federal report coding based on:
               a. Data entered by a user in system screens
               b. Data uploaded to the system from EXCEL spreadsheets
                     or other software
               c. Enrollment of a client into Care management, TEAMS,
                     PACE or another benefit plan that requires single or
                     recurring capitation payments, premium or management
               d. Business rules for creation of hospital disproportionate
                     share payments.

CA#176   Provide the ability to input manually or from an EXCEL spreadsheet,
         or other software, the maximum payment amount allowed under a
         provider contract, along with identifiers such as procedure codes
         that will be used to link each specific claim or financial transaction to
         the limits being established for the provider contract.
               a. Track the amount of each payment made that matches
                      the specific claim identifiers and contract time period.
               b. Notify the provider that the total amount authorized is
                      nearing exhaustion based on criteria designated by the
               c. Notify the contracting entity (program) that payment
                      could not be made because the contract limits had been
               d. Reject the claim if the maximum payment amount
                      allowed under a provider contract is less than the amount
                      of the claim and notify the provider of the reason for the
               e. Send an alert to the designated State staff when the total
                      amount authorized is nearing exhaustion and whenever
                      a claim is rejected due to the contract limitation.
CA#177   Enable a mass history only void and replacement to change
         account coding and/or federal report coding on claims that does not
         affect payment to providers.
CA#178   Enable a mass adjustment process that will void and replace
         selected claims to change account coding and/or federal report
         coding on claims that does not affect payment to providers.

20       Prior Authorization (PA)
PA#1     Provide an automated prior authorization system to enter prior
         authorization information, edit claims against prior authorization

        data, and track activity against approved prior authorizations.
PA#2    Flag and route for manual intervention claims that do not contain a
        service/prior authorization if the services require service/prior
        authorization or require service/prior authorization after State-
        defined thresholds are met.
PA#3    Provide the ability to identify the requirement for a prior
        authorization if a hospital stay exceeds a specified number of days.
PA#4    Ensure that there is a field for authorization or identification when an
        override indicator (force code) is used to override a PA limit.
PA#5    Support receiving, processing and sending electronic health care
        service review, request for review, and response transactions
        required by 45 CFR Part 162, as follows:
              a. Retain pharmacy drug referral certification and
              b. Retain dental, professional and institutional referral
                    certification and authorization (ASC X12N 278).
              c. Support Web or Internet submissions of prior
                    authorization requests and support delivery of the
                    request to the appropriate contractor in both real time
                    and batch modes.
PA#6    Provide access to State staff and authorized contractors to the prior
        authorization system to create, edit and delete prior authorization
        information. System must track changes and users who complete
        the change.
PA#7    Provide the capability for the service/prior authorization staff to send
        requests for additional information on paper or electronically.
PA#8    Maintain all data element fields associated with the authorization
        request/response and claims adjudication rules necessary to
        enforce prior authorization requirements including, but not limited to,
        the following:
              a. Provider
              b. Client
              c. Code sets
              d. Date of service

PA#9    Support retroactive entry of service/prior authorization requests.
PA#10   Assign a unique prior authorization number, as defined by the State,
        to identify each service/prior authorization request approved by the
        Fiscal Agent or the State.
PA#11   Enable edits to prior authorization requests that mirror the
        applicable claims processing edits.
PA#12   Provide the capability to authorize services for a specific recipient by
        various data elements, such as procedure codes, diagnosis codes,
        provider types or time periods.

PA#13   Provide on-line inquiry access to the prior authorization file
        information using any data elements contained in the file.

PA#14   Ensure that only valid data is entered on the service/prior
        authorization record, and deny duplicate requests or requests that
        contain invalid data.

PA#15   Capture and maintain both the requested service amount (units
        and/or dollars) and authorized service amount (units and/or dollars)
        on the service/prior authorization record and notify the designated
        State entity of the outcome.
PA#16   Provide and maintain the capability to create, edit and delete the
        services authorized and to extend or limit the effective dates of the
        authorization. Maintain the original and the change data in the
        service/prior authorization record.
PA#17    Update prior authorization records based upon claims processing
         results indicating that the authorization has been partially used or
         completely used. These activities include processing of original
         claims, adjustments, and voids that “draw down” (decrement)
         and/or “add back” authorized services (units, dollars, authorized
         dollar amount per unit, etc.).
PA#18   Generate automatic approval and denial notices for service/prior
        authorizations to requesting and assigned providers, case
        managers, and clients for service/prior authorizations. Denial
        notices to clients must include the reason for the denial and
        notification of the client‟s right to an administrative review/fair
PA#19   Support a service/prior authorization process that is flexible across
        numerous programs, benefit plans and claim types.
PA#20   Provide the capability to perform mass updates of prior authorization
        records, for example, globally change provider ID numbers or
        procedure codes/modifiers for pending or approved but unutilized
PA#21   Allow a cutback on payment amounts instead of a denial and allow
        a prior authorization to override the edit (e.g., Bundled Services).
PA#22   Track and update any claim limits, as well as prior authorized limits,
        with any claim adjustments (i.e., replace limits when adjustments
        result in subsequent claims).
PA#23   Provide the capability for providers to check the status of PA
        requests on-line via the Web portal.
PA#24   Identify services that have different procedure codes but that are
        subject to the same PA limitation and accumulate all like services
        against the PA.
PA#25    Provide the capability to reserve authorized services to a specific
        provider pending receipt of the claim.
PA#26   Maintain electronic copies of the notification letters and provide a
        hyperlink from the PA file/record in the MMIS to the associated
PA#27   Maintain an audit trail of PA file updates, accessible through on-line
        inquiry. Maintain control totals and provide balance information in
        response to on-line requests.
PA#28   Maintain 60 months of on-line prior authorization history.
        Processing Requests Authorized by Other Authorization
PA#29   Accept hardcopy prior authorization requests as directed by the
        State and develop an electronic interchange process to accept
        electronic prior authorization requests that may be provided by
        authorization entities.

PA#30   Produce control and balancing reports for prior authorization
        requests received from authorization entities, and provide the
        reports to the State accessible on-line and in hardcopy upon State
PA#31   Interface with authorization entities to resolve any problems
        regarding authorizations submitted by the Contractors or other
        agencies. For authorizations which are incomplete or which contain
        invalid data, add the PA to the module in a suspended status and
        return the request to the Contractor or authorizing agency for
PA#32   Provide the capability to adjust prior authorizations for modifications.
PA#33   Add prior authorization requests received through the batch process
        to the on-line prior authorization file.
PA#34   If a provider submits a PA request that should be processed by
        authorization entities, add the request to the PA module in a
        suspense status and notify the authorization entity that the
        suspense transaction is on the file for review and approval or denial
        as directed by the State.
21      Pharmacy Benefit Management
        Point of Sale (POS)
PB#1    Provide real-time access to client eligibility.
PB#2    Provide real-time access to provider enrollment, including the
        pharmacy and prescriber National Provider Identifier (NPI) and
        authorization IDs for electronic submission of claims and taxonomy.
PB#3    Stamp the account code(s) and federal report code on each claim
PB#4    Provide real-time and historical access to the State‟s drug and
        formulary file and maintain an up-to-date copy for PBM use.
PB#5    Provide real-time access to benefit plan business rules.
PB#6    Provide real-time access to drug file and POS claims history.
PB#7    Assign a unique identification number to each claim upon entering
        the system.
PB#8    Provide interface with the MMIS or other payment systems to
        maintain records of time of claims payment in order for the payment
        systems to pay error free claims. Indicate actual MMIS paid date on
        pharmacy claims data as well as adjudication date.
PB#9    Provide for batch updating of the drug file with information received
        from the drug pricing file vendor approved by the State prior to
PB#10   Provide the capability for online updating of the drug file in real time.
PB#11   Transfer fully adjudicated POS claims, including National Council of
        Prescription Drug Pricing (NCPDP) reject/payment codes, into the
        MMIS nightly by 8:00 PM Mountain Time.
PB#12   Perform online real-time capture and adjudication of POS claims
        submitted by providers.
PB#13   Accept the most recent NCPDP Telecommunications Standard
        (e.g., reject, duplicate, paid, approved) and generate the
        appropriate response transaction, as required by 45 CFR Part 162.
PB#14   Verify the Drug Efficacy Study Implementation (DESI) status of the
        drug claimed from information from CMS and the CMS tape.
PB#15   Return to the provider, the status of the claim and any errors or

        alerts associated with the processing, such as:
              a. Edit failures
              b. Prospective Drug Utilization Review (Pro-DUR) alerts
              c. Client or coverage restrictions to include quantity limits.
              d. Prior authorization missing
              e. Required coordination of benefits Must bill third party
              f.    Refill too soon
              g. Requires generic substitution
              h. Deny experimental/non-covered drugs
              i.    Requires unit dose unit dose not allowed
              j.    Package size not approved
              k. Deny any claims deemed DESI “less than effective”
              l.    NCPDP fields as required by the State
              m. DOB edits
              n. Client specific edits
              o. Termed NDCs from the CMS tape
PB#16   Verify that the client is eligible on the date of service and not
        otherwise restricted, e.g. enrolled in a Lock-In Program.
PB#17   Verify that the provider is enrolled on the date of service.
PB#18   Verify that all fields defined as numeric contain only numeric data.
PB#19   Verify that all fields defined as alphabetic contain only alphabetic
PB#20   Verify that all dates are valid and reasonable.
PB#21   Verify that all data items which can be obtained by mathematical
        manipulation of other data items agree with the results of that
PB#22   Verify that all coded data items consist of valid codes, including
PB#23   Verify that any data item that contains self-checking digits (e.g.,
        DEA/NPI) pass the specified check-digit test.
PB#24   Verify that required data items are present and retained including all
        data needed for State or federal reporting. (See SMM 11375.)
PB#25   Verify that the date of service is within the allowable time frame for
PB#26   Verify that the claim is not a duplicate of a previously paid claim.
PB#27   Process electronic void and replacement of paid claims submitted
        through the POS system.
PB#28   Provide a field for authorization or identification when an override
        indicator (force code) is used.
PB#29   Perform the appropriate edits to ensure that a prior authorization is
        present when required.
PB#30   Check against disease states from claims history to see that they
        have the supporting medications and materials. An electronic
        prospective prior authorization system which interfaces with MMIS
        claims based data shall be used as approved by the State.
PB#31   Compare the claim against client history and benefit rules to
        determine if the new claim complies with State standards to include:
              a. Therapeutic appropriateness
              b. Over Utilization
              c. Underutilization
              d. Appropriate use of generic products

              e. Therapeutic duplication
              f.     Drug-disease contraindications
              g. Drug-pregnancy contraindications
              h. Drug-drug interactions
              i.     Incorrect drug dosage or duration of drug treatment
              j.     Clinical abuse or misuse
              k. Consistent with patient age
              l.     Consistent with patient gender
              m. Consistent with refill policy
              n. Others as defined by the state
PB#32   Maintain State controlled parameters for all standards and
PB#33   Identify claims that are appropriate for pay and chase. If the claim is
        designated as “pay and chase”, it should be processed and paid (if
        it meets all other criteria), and reported for follow up activities.
PB#34   Update client eligibility data in the PBM system at least daily from
        the MMIS client files. If client eligibility is shown through the PBM
        system and all other criteria are met for claim payment, the claim
        should be processed on-line and adjudicated.
PB#35   Allow direct data entry of prior authorization requests online, real-
        time, including approval status, diagnosis, units of service, and
        inclusive dates. There must be a prior authorization subsystem to
        track the approval, denial, or pend status, length of review, changes
        from non-preferred to preferred drugs, and requests for non-
        preferred drugs versus clinical exceptions.
PB#36   Adjudicate drug claims online real-time to pay or deny the claim
        based on State-defined criteria and PA status.
PB#37   Track and report on the number of prior authorization requests
        submitted for controlled substances by drug pricing file vendor and
        therapeutic drug classification.
PB#38   Provide the capacity to handle multiple prior authorization requests
        from individual prescribers and pharmacies for different clients and
        multiple drugs per individual
PB#39   Provide inquiry capability on the NDC file so that a provider may
        determine if an NDC is covered, requires prior authorization or is
PB#40   Allow online real-time Direct Data Entry (DDE) of drug claims.
PB#41   Allow voids and replacements to be submitted in electronic format or
        through manually keying.
PB#42   Accept and process X12N 278 authorization requests and send the
        appropriate responses.
PB#43   Capture the prescriber‟s DEA and NPI number on all drug claims
        and provide the ability to edit against.
PB#44   Validate prescribing and dispensing providers prior to adjudicating a
PB#45   Indicate in the response to a provider whether the client has current
        third party insurance coverage and coordinate benefits with the
        client‟s third party insurance.
PB#46   Accept billing for compound drugs (those with multiple NDC codes
        up to 25 ingredients) online.
PB#47   Be able to identify clients with Medicare coverage and Medicare

         payable drugs and deny the claim as Medicare primary. Adjudicate
         Part D eligible client claims in accordance with State and CMS
PB#48    Preserve the originally received content of the NCPDP 5.1 and
         NCPDP 1.1 claim transactions.
PB#49    Record the date and time when the response transaction was sent
         to the entity that originally submitted the claim. For claims with more
         than one prescription per claim transaction, record the response
         parameters at the transaction level, not at the prescription level.
PB#50    Adjudicate claims at the line level for compound drugs. Provide the
         capability to ensure that ingredients used in compound drugs are
         validated through all claims and ProDUR edits and audits.
PB#51    Issue NCPDP standard duplicate response records as appropriate
         (e.g., for denial of a duplicate claim transaction).
PB#52    Verify that the drug claimed has not already been paid for in any
         other claim type.
PB#53    Provide the capability to prevent payment on drug claims if there is
         an adjudicated professional, dental or institutional claim with the
         same drug and same client, within a time frame defined by the
PB#54    Apply limits on utilization per day (e.g., maximum number
         prescription, maximum dollars, maximum limits).
PB#55    Use the drug pricing file vendor approved by the State for pricing
         and edit criteria for processing claims. The Contractor is
         responsible for acquiring the First Data Bank or equivalent drug
         pricing file, if approved by the State, and any associated licensing
PB#56    Provide the capability to pay at benefit plan-specific rates (e.g.,
         different than Montana Health Care Programs).
PB #57   Provide on line access to claims history of 60 months.
         Allowed Amounts for Drugs - Dispensing Fees and Co-
PB#58    Utilize data elements and algorithms to compute claim
         reimbursement for claims that is consistent with 42 CFR 447.
PB#59    Edit claims against state-defined service limitations.
PB#60    Edit claims to ensure that all required attachments, per the
         reference records or edits, have been received and maintained for
         audit purposes or have been submitted prior to the claim being
         adjudicated and a prior authorization has been established if
PB#61    Calculate and deduct client co-payment amounts, as appropriate,
         when pricing claims.
PB#62    Deduct TPL amounts, as appropriate, when pricing claims. If the
         provider indicates no TPL and the client record indicates there is
         TPL, the claim must be denied. State defined overrides will apply.
PB#63    Verify that the claim is for services covered by the appropriate
         Benefit Plan.
PB#64    Verify that all data necessary for legal requirements are retained.
PB#65    Maintain reimbursement methodologies as directed by the State and
         pay the lesser of:
                a. Federal Upper Limit or Maximum Allowable Cost (MAC)

                      associated with some drugs plus a provider specific
                      dispensing fee, or
              b. State defined Estimated Acquisition Cost (EAC) which is
                      currently defined as the Average Wholesale Price (AWP)
                      less 15% plus a provider specific dispensing fee, or
              c. Provider's usual and customary charge
PB#66   Provide the capability to accommodate existing and future NCPDP
PB#67   Provide the capability to receive all NCPDP data fields as defined by
        the State approved payer sheet. Must have capability for future
        inclusion or exclusion of NCPDP data fields as directed by the
PB#68   Provide the capability to provide client eligibility verification using
        NCPDP standards.
PB#69   Provide the capability to utilize a preferred drug list, as defined by
        the State, and support a grandfather policy for non-preferred drugs.
PB#70   Provide both adjudicated and in process claims accessible via the
        Web for authorized users.
PB#71   Provide the capability to override edit checks based on the
        existence of a pharmacy prior authorization on file.
PB#72   Provide the capability to apply and select from multiple pricing
        methodologies/algorithms to determine drug payment.
PB#73   Provide the capability to handle exception processing.
PB#74   Provide capability to cross-reference manufacturers approved by
        CMS and by the State with the drug coverage extract to ensure that
        the State does not make payments for non-rebateable drugs. The
        State has the authority to override this requirement.
PB#75   Interface with the MMIS to accept and transfer claims data, client
        eligibility information, provider eligibility, reference/formulary, prior
        authorization, claims pricing, and other MMIS data needed for POS
        claims adjudication and rebate invoicing.
        Pharmacy Reference Edits and Audits
PB#76   Provide editing capabilities, including:
              a. Accept and automatically conduct drug updates for
                      multiple formularies.
              b. Provide the capability to institute drug-specific variable
                      rates (e.g., percent of prescription utilization threshold)
                      for determining how soon a refill can occur.
              c. Provide capability to link various edits/audits for
                      formulary prior authorization or benefit restriction to
                      relevant demographic information (e.g., age, gender).
              d. Provide full audit capabilities.
              e. Provide the capability to view and make online real-time
                      changes to the system edit and audit criteria to include
                      State driven overrides, (e.g. Lock-in)..
              f.      Provide custom messaging as required by the State to
                      enhance NCPCP 5.1 messages are used.
              g. Provide the capability to edit for drugs that are covered
                      by Medicare and ensure Medicaid is the payer of last
              h. Provide the capability to allow authorized users to make
                      manual adjustments to the drug maintenance file for the
                     State to respond quickly to changes in coverage. This
                     helps the state to avoid delays in implementing policy
                     due to the drug information database file vendor‟s
                     updating processes.
               i.    Maintain an audit trail of all changes to the drug file
                     showing all additions and deletions, and showing before
                     and after images of records that have been changed.
               j.    State access to test environment
               k. All edits and valid values defined on payer sheet
                     approved by the State
        Prospective Drug Utilization Review
PB#77   Provide an automated, integrated online real-time ProDUR system.
PB#78   Provide a prospective and concurrent review of prescription
        practices at the pharmacy and client level.
PB#79   Verify that services are medically appropriate, conform to Federal
        and State policies, and result in the maintenance or improvement of
        patient health.
PB#80   Provide the capability to user define an unlimited number of edits
        and business rules for POS claim rejection that can be tied to
        standard NCPDP DUR reject codes for claim denial and/or ProDUR.
PB#81   Provide the capability to produce reports that identify providers with
        high use of pharmacy DUR edit override codes.
PB#82   Perform an edit to ensure that the prescription refill date is within the
        State defined parameters.
PB#83   Provide the capability to build client profiles that include medical
        history. This information is used for diagnostic purposes, as well as
        for historical reference in the interaction review process.
PB#84   Provide the capability to of instituting drug-specific variable rates on
        how soon a refill can occur (e.g., percentage of prescription
        utilization threshold).
PB#85   Allow customization of ProDUR criteria that are received from the
        state‟s Drug pricing file vendor (e.g., First DataBank or similar) and
        possible criteria that DPHHS may develop but ensure that any
        modified criteria are not overwritten by subsequent updates from the
        drug pricing file vendor.
PB#86   Provide the capability to institute ProDUR screening for any benefit
        plans administered through the PBM and MMIS systems.
PB#87   Provide the capability to compare a prescription claim against client
        claims history and explicit predetermined standards, including
        monitoring for, but not limited to:
               a. Therapeutic appropriateness
               b. Over-utilization
               c. Underutilization
               d. Therapeutic duplication
               e. Drug-disease contraindications
               f.    Drug-pregnancy contraindications
               g. Drug-drug interactions
               h. Incorrect drug dosage or duration of drug treatment
               i.    Clinical abuse or misuse
               j.    Ingredient duplication, Benefit Plan level edits (e.g., ulcer
                     edit) and use of certain medications before another is
                     dispensed (e.g. Singulair).
               k. Other standards as identified by the State.
PB#88    Customize ProDUR editing developed by the State.
PB#89    Generate alerts based on clinical or program compliance issues
         associated with the client‟s prescription for a pharmacist to evaluate.
PB#90    Generate alerts (messages) to providers as required by State policy.
PB#91    Provide the capability to allow the provider to override an alert as
         allowed by state policy.
PB#92    Maintain flexible, user-controlled parameters to adapt to situations in
         which particular online ProDUR messages will be generated.
PB#93    Allow providers to cancel or override a ProDUR message in
         accordance with State defined criteria.
PB#94    Produce the necessary ProDUR information to support the State in
         completing the CMS Annual Drug Utilization Review (DUR) report,
         as described in Section 1927(g)(3)(D) of the Social Security Act.
         Retrospective Drug Utilization Review
PB#95    Prepare extracts of POS claims history (or access to the claims
         history) for purposes of Retrospective Drug Utilization Review
         (RetroDUR), prescriber and provider profiling, management
         reporting, and other decision support functions.
PB#96    Use all of the common industry RetroDUR edit definitions, where
PB#97    Provide capability to operate the RetroDUR system as a standalone
         from the POS in the event that the POS is replaced in the future.
PB#98    Provide the capability to perform cost/benefit calculations for
         individual drugs, drug classes, therapeutic equivalents, and other
         similar groupings.
PB#99    Provide the capability to track prescribing patterns for previously
         identified high-cost or high-utilization cases.
PB#100   Provide the capability to accommodate RetroDUR screening for any
         other benefit program administered through the PBM and MMIS
PB#101   Provide the capability to support analysis of prescription patterns by
         physician, by drug category, individual drug, geographic parameter,
         and client demographics.
PB#102   Provide the capability to develop Provider profiles that offer
         comparisons to peers.
PB#103   Provide the capability to support analysis of client utilization patterns
         by drug category, individual drug, geographic parameter, and client
PB#104   Provide the capability to develop client profiles with comparisons to
         peer groups (e.g., diagnosis, procedures, age, gender, and other
         demographic criteria).
PB#105   Maintain a DUR criteria module to identify clients and their
         prescribers whose drug claims history indicates a potential for an
         adverse drug effect or negative therapeutic outcome in order to
         educate the prescriber and prevent future occurrences of adverse
         effects, such as:
               a. Underutilization – Failure to use medication in sufficient
                      quantities or at appropriate intervals will not provide the
                      desired health outcome for which it was intended and
                      may have adverse effects.

              b.     Over-utilization – Medication used in excessive
                     quantities or at inappropriate intervals will not provide the
                     desired health outcome for which it was intended and
                     may have adverse effects.
                c. Iatrogenic Effects and Adverse Reactions – The
                     induction of any adverse effect by the extended use of a
                     drug beyond medically acceptable duration of therapy.
                d. Drug-Drug Interactions – The combined use of two or
                     more drugs, which produces an undesirable effect.
                e. Drug Therapy Contraindicated by Diagnosis – The
                     use of a drug when a condition or disease exists that
                     precludes the use and may exacerbate the condition or
PB#106   Produce the necessary RetroDUR information to support the
         DPHHS in completing the CMS Annual Drug Utilization Review
         (DUR) report, as described in Section 1927(g)(3)(D) of the Social
         Security Act, or any changes defined by CMS in the future to allow
         the DPHHS to remain compliant with State and Federal reporting
PB#107   Maintain an online audit trail of all updates to DUR criteria.
PB#108   Identify any clients or providers who need to be referred to Program
PB#109   Provide flexibility to design or manipulate RetroDUR report elements
         for incorporation into a standard report or ad hoc reports requested
         by the Department, P&T Committee or DUR Board.
PB#110   Provide the capability to conduct data analyses as required by the
PB#111   Make RetroDUR reports available online as specified by DPHHS.
         Drug Rebate
PB#112   Maintain a drug manufacturer module with all data necessary for
         managing drug rebates for all benefit plans.
PB#113   Update the module quarterly with information supplied by CMS and
         other State designated sources.
PB#114   Provide the capability to receive CMS participating drug rebate data,
         including but not limited to: manufacturer and contact information to
         include historical changes.
PB#115   Maintain multiple manufacturer enrollment dates, termination dates,
         and address changes that are provided by CMS.
PB#116   Maintain historical drug rebate rates for prior quarters, from 1991
PB#117   Provide the capability for the State to claim manufacturers‟ rebate
         on drugs billed to Montana Health Care Programs through the PBM.
         In addition, provide the capability to claim rebates on drugs billed by
         medical providers as required by CMS. These providers include
         physicians, hospital outpatient departments, and other providers
         that are neither retail pharmacies nor inpatient providers. These
         drugs are typically billed on professional or outpatient institutional
         bills using HCPCS/CPT codes.
PB#118   Provide capability to identify rebate-eligible claims.
PB#119   Provide the capability to calculate, bill and collect rebates for
         durable medical equipment (DME) and supplies.

PB#120   Prepare extracts of PBM claims history required by the drug
         manufacturer rebate process. Claims must include all NDC and
         other data needed to support the rebate process, as follows:
               a) Date of Service
               b) NDC number (NDC 11)
               c) Total units paid
               d) Product names
               e) Unit Rebate Amount (URA) based on the CMS approved
               f) Provider number
               g) Prescription number
               h) Number of prescriptions paid
               i)    TPL
               j)    Co-payment
               k) Amount paid
               l)    Other data determined by the state
PB#121   Provide the capability to exclude certain providers and/or certain
         claims from the extract based on state criteria.
PB#122   Provide additional contact fields in the rebate module that will be
         updatable by the State and not overwritten by the quarterly CMS
         update information
PB#123   Provide the capability to collect supplemental rebates, with separate
         invoicing and separate accounting and capability to manage and
         collect rebates for the Montana Health Care Programs.
PB#124   Ensure that all drug rebate data are available for query and
         reporting via the DSS by the users.
PB#125   Maintain appropriate and accurate information pertaining to unit
         rebate amounts (URA), as well as other data elements necessary
         for the generation of accurate rebate invoices, including data
         required under the Veterans Health Act of 1993.
PB#126   Provide on-line access to a minimum of ten (10) years of drug
         rebate data on-line, with data over ten years old archived and
         retrievable within twenty-four (24) hours of a request.
PB#127   Synchronize NDC termination dates and DESI flags on the drug
         module from data supplied by CMS with the point of sale system
         and MMIS.
PB#128   Identify those public health services providers, reported by the
         HRSA Office of Drug Pricing, that have separate drug rebate
         agreements with manufacturers under the Veterans Health Act of
         1993 Section 340(b), with effective dates.
PB#129   Provide capability to perform screen prints to be transmitted to other
         software or email to aid in trouble shooting or showing examples of
         issues found in the system.
         Drug Rebate Invoicing
PB#130   Identify and flag claims for Drug Rebate processing.
PB#131   Calculate and generate quarterly invoices for amounts owed by
PB#132   Provide electronic invoicing to manufacturers and the capability for
         electronic dispute resolutions, in which manufacturers/labelers can
         only see their own claim-level detail for rebates.
PB#133   Provide drug rebate invoicing processes for any applicable Montana

         Health Care Programs.
PB#134   Provide the capability to calculate and invoice supplemental rebates
         separately based upon State supplemental drug rebate agreements.
PB#135   Provide flexible capability to accrue drug rebate invoices if amount
         to be invoiced is below a threshold defined by the State.
PB#136   Provide capability for State to assign NDC to a different labeler (in
         the event of a sale or transfer of an NDC from one pharmaceutical
         manufacturer to another).
PB#137   Provide the capability to run drug rebate invoice cycles on an ad
         hoc basis at the program-specific level.
PB#138   Allow manual adjustment to rebate invoice amounts in the event of
         disputes from manufacturers and similar scenarios.
PB#139   Capture and retain mailing date for all invoices.
PB#140   For accounts receivable subject to interest charges, accommodate
         account balance updates for applying Treasury bill (T-Bill) rates to
         overdue balances.
PB#141   Accommodate exclusion of certain classes of drugs from rebate
         participation per State or Federal mandate (e.g., 340B Program).
PB#142   Generate outlier or anomaly reports that identify potential decimal
         quantity errors or unit of measure errors.
PB#143   Maintain confidentiality of labeler and State information in
         accordance with all Federal and State confidentiality statues,
         regulations, and requirements.
PB#144   Provide the capability to apply credit balances from previous
         quarters to amounts due from the current quarter prior to the
         invoicing process.
PB#145   Process CMS URA data immediately upon receipt.
         Drug Rebate Tracking
PB#146   Identify and flag claims for Drug Rebate processing.
PB#147   Provide a drug rebate tracking system/dispute resolution module to
         track all invoices sent, payments received, accounts receivable, and
         disputes for all drug rebates.
PB#148   Provide a drug rebate Accounts Receivable reporting module to
         include but not limited to:
               1. Accounts receivable report
               2. Provide research report capability within the AR module
                      to include, but not limited to:
               a.      Claim Audits
               b.      CMS / ROSI discrepancies
               c.      CMS / drug file discrepancies
               d.      CMS / mismatches
               e.      Labeler differences
               f.     Contact anomalies
               g. Drug (invoice) audits
               h. Under threshold invoices
               i.     Suspended checks
               j.     ROSI /PQAS inconsistencies

PB#149   Provide a drug rebate Summary reporting module to include:
         a) Payment Summary
         b) Rebate Summary (payment received, invoiced amount &

         disputed amount by quarter)
         c) Quarterly Payments
         d) Dispute code report
         e) Dispute activity
         f) Invoice register
         g) Invoices for quarter not paid
         h) CMS64 (must match AR report ending balance)
         i) Top 10 balances
         j) Drug type Summary

PB#150   Provide a drug rebate Detailed reporting module to include:
         a) NDC details
         b) NDC history
         c) Manufacturer summary
         d) ROSI / PQAS
         e) Unallocated Balance
         f) Adjusted Claims
         g) Check/Allocation comparisons
         h) HCPCS code claims paid
         i) Interest Override
         j) Dispute recapitulation

PB#151   Provide the capability to track Unit Rebate Amounts (URAs) for all
         items administered through the POS and MMIS systems.
PB#152   Provide the capability to track drug rebates for the Supplemental
         Drug Rebate Program.
PB#153   Provide the capability to track drug rebates for Montana Health Care
PB#154   Provide the capability to enter and retain drug rebate amounts that
         are negotiated separately by the State with manufacturers.
PB#155   Provide separate fields in the Drug Rebate tracking functionality to
         identify including, but not limited to manufacturer, quarter, NDC, and
         programs as defined by the state.
PB#156   Provide the capability to record drug rebate payments at the NDC,
         federal report code and account code level.
PB#157   Generate paper and electronic notices of late payment at intervals
         designated by the State (e.g., 38-day, 60-day, and 90-day intervals).
PB#158   Provide the capability to automatically generate internal notices for
         accounts receivable in conjunction with reports generated in
PB#159   Provide capability to produce a report on “zero dollar” Unit Rebate
PB#160   Provide the capability to maintain complete and accurate records of
         all checks received, units adjustments, write-offs, resolutions,
         interest paid, original and corrected units, outstanding balances and
         contacts with manufacturers on current and prior drug rebate/invoice
         information in compliance with all federal and State reporting
PB#161   Provide the capability to maintain an audit trail of transactions
         related to the drug rebate invoices and provide the capability to
         display original and all revised invoice records.

PB#162   Provide the capability to maintain drug rebate invoice and
         correspondence history for up to 10 years, or at other intervals
         designated by State and Federal requirements.
         Drug Rebate Payments
PB#163   Provide an accounts receivable module in the Drug Rebate system
         to be approved by the State.
PB#164   Provide the capability to receive, record, and process all drug rebate
         payments in accordance with State-approved procedures.
PB#165   Provide the capability to interface with SABHRS for accounts
         receivable and cash receipt data nightly by 8:00 PM Mountain Time.
PB#166   Provide the capability to process drug rebate payments for Montana
         Health Care Programs.
PB#167   Provide the capability to process drug rebate payments for the
         Supplemental Drug Rebate Program.
PB#168   Accommodate Electronic Funds Transfer (EFT) for drug rebate
         payments by manufacturers.
PB#169   Accommodate receipt of current quarter drug rebate payment
         details through other electronic forms, as defined by the State.
PB#170   Provide the capability to accept Prior Quarter Adjustment
         Summaries (PQAS) electronically.
PB#171   Provide the capability to capture State defined fields to include, but
         not be limited to: payment dates, check issuer, check amount and
         check numbers.
PB#172   Provide the capability to record Unit Rebate Amounts (URAs) from
         manufacturers and correlate with the URA on the file from CMS.
         Generate reports identifying discrepancies.
PB#173   Provide reports to reconcile payments received from manufacturers.
PB#174   Maintain historical dispute resolution data for multiple rebate
22       Third Party Liability Management
         Coordination of Benefits
TP#1     Edit TPL data updates for validity and for consistency with existing
         TPL data.
TP#2     Edit additions and updates to the client insurance information to
         prevent the addition of duplicates.
TP#3     Provide a mechanism to correct outdated TPL information.
TP#4     Generate and maintain an audit trail of all updates to the client
         insurance data, including those updates that were not applied due
         to errors.
TP#5     Allow only authorized staff members to do manual deletes and
         overrides of alerts/edits.
TP#6     Screen claims to determine if claims are for clients with TPL and
         Medicare coverage, if the service is covered and if the date of
         service is within the coverage period. Deny or suspend or mark the
         claim for “pay and chase”, as provided in State rules, claims that are
         for products or services that are covered. Notify the provider of
         claims denied because of TPL coverage.
TP#7     Track and report cost avoidance dollars based on business rules
         provided by the State.
TP#8     Pay claims that would have been rejected due to TPL and Medicare
         coverage if the provider includes override codes that indicate

        benefits are not payable by the other liable party.
TP#9    Support electronic billing to Medicare and automatically void
        previously paid claims when the claims are billed to Medicare.
        Pay and Chase

TP#10   Generate eligibility matches with other payers using the HIPAA
        270/271 transactions or proprietary format if needed.

TP#11   Implement the X12 269 Health Care Benefit Coordination
        Verification Request and Response transaction. Negotiate and
        secure trading partner agreements with major insurance carriers
        and health plans to perform TPL/COB verification as reported in
        these transactions.
TP#12   Generate ANSI X12 837 or an electronic payer subrogation claim
        transaction for billing Medicare or other insurance carriers when a
        determination is made that the client was eligible for coverage
        under another plan including Medicare when the claims were paid.

TP#13   Automatically re-bill insurance companies if a response (payment or
        denial) is not received within State-specified guidelines.
TP#14   Identify, at the claim line level, the amount paid by the third party
        and the reason for adjustments applied by the third party. If the
        claim is not adjudicated at the line level, identify the amount paid by
        the third party and the reason for adjustments applied by the third
        party at the header level.
TP#15   Apply TPL recoveries at the line level unless the claim is paid at the
        header level.

TP#16   Interface with accounts receivable to post TPL recoveries.

TP#17   Provide drill down capability to see amounts recovered through pay
        and chase or any other TPL information on claim on line.
TP#18   Produce reports to support recovery from an estate or designated
TP#19   Maintain a post payment billing module, including monthly reports
        by carrier, of amount billed, amount re-billed, amount purged, and
        amount outstanding, for sources within the approved "pay and
        chase" category and retroactive for claims when insurance is added
        to the file, and where liability is indicated on the TPL Resource file
        cost avoidance matrix.
        Maintain TPL Data
TP#20   Provide client eligibility information, including TPL coverage
        information, on the web portal to providers and other authorized
TP#21   Maintain all third party resource information at the client–specific
        level including, but not limited to:
               a. Name of insurance company including long term care
               b. Address of insurance company
               c. Policy number
               d. Group number

              e. Name of policyholder
              f.     Relationship to Montana Healthcare program client
              g. Services covered
              h. Policy period
              i.     Employer of policy holder
              j.     Multiple resources under one client
              k. Group health plan participants
              l.     Health Insurance Premium Payment (HIPP) participant.
TP#22   Produce letters and track original and follow-up letters to employers,
        insurers, clients and others to verify health coverage.
TP#23   Accept and process verification data from employers, insurance
        companies (including long term care insurance), providers, clients,
        attorneys and others. Verification data should include the type of
        insurance coverage for each policy (e.g., inpatient, outpatient,
        physician, pharmacy, dental, nursing homes, etc).
TP#24   Maintain multiple third party coverage information for individual
        clients for all of their periods of eligibility.
TP#25   Provide an indicator to identify the source of TPL information (e.g.,
        X12N 270 eligibility determination, insurance company).
TP#26   Identify claims designated as “mandatory pay and chase”, make
        appropriate payments and flag such claims for future recovery (e.g.,
        identify services provided to children who are under a medical child
        support order, and flag diagnosis information to identify prenatal
        care services provided to pregnant women and preventive pediatric
        services provided to children).
TP#27   Receive, process, and update medical support information received
        from the State‟s child support enforcement agency.
TP#28   Maintain employer data that identifies employers and the health
        care plans they provide to employees.
TP#29   Provide the ability to designate TPL amounts collected in excess of
        paid claims amounts and generate payment to the client if the
        recovery is in excess to what is owed on the claim.

TP#30   Produce files to send to all Montana Health Care Program eligibility
        systems for TPL coverage identified by the Contractor.
TP#31   Prepare retroactive reports (reverse crossover) to Medicare Part A
        or B or the provider, as appropriate, for all claims paid by Medicaid
        that should have been paid by Medicare Part A or B.
TP#32   Provide for the storage and retrieval of Medicare information for the
        proper administration of Medicare crossover claims and ensure
        maximum cost avoidance when Medicare is available.
TP#33   Transmit the appropriate information to Medicare for the efficient
        and effective administration of Medicare Part D.
TP#34   Screen and evaluate verified TPL resources against paid claims
        history retroactively for three years to identify recoverable funds.
TP#35   Identify claims with trauma diagnosis codes, accident codes and
        indicators and flags them for follow-up to see if there is TPL
TP#36   Automatically generate casualty-related follow-up to clients,
        attorneys, motor vehicle department, insurance companies, Workers
        Comp and other potentially liable third parties according to State-
        specified criteria.

TP#37   Provide for the storage and retrieval of casualty-related information
        (e.g., motor vehicle accident and workers‟ compensation

TP#38   Allow for online entry of TPL and COB rules by State staff or
        Contractor staff as defined by the State,
TP#39   Provide the State with the capability to update client TPL Resource
        files by tape, batch interface or on-line real time.
TP#40   Generate alerts to DPHHS recovery units and others designated by
        the State when retroactive third party coverage has been identified.
TP#41   Provide the capability to accommodate different claim resolutions for
        different Montana Healthcare program services and different policy
        limits, for claims pended for TPL review.
TP#42   Provide the capability to receive and process electronic TPL claim
        attachments as standard transactions are implemented.
TP#43   Provide an online notes capability for narrative about each collection
        Program Management

23      Financial Systems Requirement (FP)
FP#1    Implement and maintain a single payment and receivable system to
        support all benefit plans. This application must be capable of
        meeting State financial and data exchange requirements, now and
        in the future. The financial package must provide meaningful and
        actionable information for program management, policy
        development and improved financial accountability.
FP#2     Provide integration between the MMIS and SABHRS, The system
        must transmit data to and receive date from the State SABHRS.
        There are numerous processes that have manual intervention at
        some point in the data exchange between information systems.
        Processes that currently involve manual intervention at some point
        include but are not limited to; preparing the payment file for
        transmission to SABHRS, entering and recording repayments from
        Medicaid providers, recording stale dated warrants, and reissuing
FP#3    Provide a full audit trail to the source of general ledger transactions
        generated by the MMIS or other supporting financial packages.
FP#4    Provide an accounts payable module to manage payments to
        providers, clients and other entities.
FP#5    Provide an accounts receivable module to manage receivables from
        providers, clients and other entities.
FP#6    Provide remittance processing capabilities to account for both
        payment offsets and cash receipts.
FP#7    Maintain a history of claim recovery payments in excess of
        expenditures and allow distribution to the appropriate parties,
        including providers, clients, or insurers.
FP#8    Provide a follow-up process to ensure that required changes to
        account coding and financial management business rules are
FP#9    Support automated retroactive changes that are user driven (e.g.
        changes in account coding). Retroactive changes will not change

        closed totals but will retain them and reflect revised totals.
FP#10   Allow authorized users to make changes and updates to the
        financial structures as required by the business.
FP#11   Provide the ability to easily navigate between accounts payable and
        accounts receivable.
        Accounts Payable
FP#12   Process accurate and timely payments from the MMIS to SABHRS
        for providers, clients, and other payees. Payments are to be
        grouped into provider or other payee batches to reduce the number
        of warrants or EFT transactions issued. Selected payments may be
        held or netted against the outstanding accounts receivable balance
        for the payee.
FP#13   Provide accurate and flexible payment processing.
FP#14   Process payments for multiple benefit plans.
FP#15   Summarize payment cycle transactions by account coding.
FP#16   Create a payment processing summary file for upload to SABHRS.
FP#17   Provide financial audit controls meeting generally accepted
        accounting principles (GAAP).
FP#18   Perform internal balancing activities to ensure accurate
        disbursement of payments.
FP#19   Balance all payment cycle processing, including balancing a Claims
        Payment Summary Report to a Remittance Advice Report.
FP#20   Produce payment cycle reports including the Claims Payment
        Summary Report in a format defined by the State.
FP#21   Support all MMIS financial data in the same account code format
        and structure as SABHRS. SABHRS includes six chart fields:
        account, fund, program, subclass, organization, and project.
FP#22   Allow authorized users to make changes and updates to the
        financial structures as required by the State.
FP#23   Provide the capability to reduce a provider payment by a
        percentage or hold an entire payment by provider type or other
        selection criteria designated by the State.
FP#24   Provide the ability to produce an electronic file of all transactions
        processed in the payment cycle for transfer to the SABHRS.
FP#25   Provide edits to prevent duplicate payments.
FP#26   Support the calculation of disproportionate share payments, per
        business rules provided by the State.
FP#27   Produce the 1099 file as directed by the State using Accounts
        Receivable data to appropriately adjust providers‟ earnings for
FP#28   Maintain financial transactions in sufficient detail to support W-2 and
        FICA reporting requirements for personal service care providers and
        providers of services under self-directed care initiatives should the
        State elect to implement a payroll system for personal care workers.
FP#29   Produce payment files on a weekly and expedited basis. Expedited
        payments are to be sent to SABHRS by 8 p.m. on the day of claims
        adjudication or creation of the financial transaction.
FP#31   Net provider payments against credit balances and accounts
        receivable and outstanding interest amounts due in the payment
        cycle in determining the payment due the provider.
FP#32   Account for interest owed separately by account code and federal

        report code.
FP#33   Generate payment cycle reports on the first working day after each
        payment cycle.
FP#34   Provide full accountability and control of all claims processed
        through the system until final dispositions including full
        documentation and audit trails to support the claims payment
FP#35   Update claims and online financial files with the payment
        identification (EFT number, warrant number, or other), date of
        payment, and amount paid after the claims payment cycle.
FP#36   Process voids and replacements for incorrect payments and create
        accounts receivable where appropriate.
FP#37   Update and track information necessary to support a reconciliation
        of cancelled and/or replaced warrants
FP#38   Support stop payment processes for lost, stolen, or destroyed
FP#39   Allow for withholding of payments in cases of fraud or willful
        misrepresentation without first notifying the provider of the intention
        to withhold such payment.
FP#40   Balance payment, receivable and cash receipt data in Financial
        Management to SABHRS daily and reconcile payments by account
        code at periodic intervals as defined by the State.
FP#41   Manage provider IDs so remittance advices can include claims from
        more than one benefit plan.
FP#42   Generate one payment for all claims with same NPI or PID for
        atypical providers.
FP#43   Link financial data back to the source claim line or system
        generated payment transaction.
FP#44   Perform all internal balancing activities to ensure accurate
        disbursement of payment files.
FP#45   Allow for limiting payment amounts per business rules.
FP#46   Generate replacement payments per business rules.
FP#47   Stamp account code and federal report code at the line level of
        claim and financial transactions.
         Accounts Receivable
FP#48   Provide the ability to record debts and process accurate and timely
        cash receipts from debtors. The Accounts Receivable function
        must, at a minimum have the following functionality:
FP#49   Allow for the creation of multiple categories of accounts receivable
        (audit, overpayments, fraud, etc) at the claim line level.
FP#50   Automatically create accounts receivable based on claim voids,
        recoupments, settlements, and receipt of unsolicited refunds from
        providers. Stamp account code and federal report code on each
        accounts receivable based on the codes stamped on the claim lines
        or business rules as defined by the State.
FP#51   Automatically apply an unsolicited payment to the accounts
        receivable balance created for this purpose.
FP#52   Automatically create a receivable collectable in thirty (30) days
        whenever a provider advance is created.
FP#53   Provide the capability to manually create a receivable and stamp
        account code and federal report code on based on direction from

        the State.
FP#54   Provide the ability to create a payment plan for manual and
        automatically created accounts receivable.
FP#55   Provide online viewing of all transactions and provider balances.
FP#56   Generate monthly statements to debtors on receivables reflecting
        claim specific and non-claims specific receivables and payments
        made, and claim payments used to satisfy receivables.
FP#57   Calculate and charge interest on unpaid accounts receivable
        balances with the flexibility to waive interest or change the start date
        on a case by case basis.
FP#58   Stamp account code and federal report code on interest
        transactions based on direction from the State.
FP#59   Allow claim payments to satisfy an outstanding accounts receivable
        balance including payment of interest.
FP#60   Generate alerts when accounts receivable have an overdue
FP#61   Generate notices to the debtor when accounts receivable have an
        overdue balance.
FP#62   Generate notices to providers per business requirements prior to
        referring accounts for collection. System must issue increasing
        demand letters when accounts receivable are not satisfied.
FP#63   Prepare an electronic file of overdue accounts receivables for
        transmission to the State offset program or other collection agent as
        directed by the State.
FP#64   Generate a file to the designated State agency when there is an
        outstanding accounts receivable for a provider and a notification of
        bankruptcy is entered on the provider file.
FP#65   Allow for collection of individual receivables to be suspended but still
FP#66   Support multiple accounts receivable for a given provider to include
        a prioritization of satisfaction of the outstanding balances that may
        be overridden.
FP#67   Provide online inquiry access to the accounts receivable module.
        This module must retain all key data fields including but not limited
              a. Financial control numbers
              b. Provider id and name
              c. Type of receivable (created by a claim transaction or by
                     a financial transaction)
              d. Collection code
              e. Original balance
              f.     Prior balance
              g. Current activity
              h. Balance forward
              i.     Claim control number that generated the receivable (if
                     the receivable was generated as a result of a claim
              j.     Reason code
              k. Cycle date
              l.     Schedule of future payments
              m. Age of receivable in days

             n.      Dates Associated with each action on the receivable
                     (e.g., date established, date of each payment)
        Search criteria (the key inquiry data elements) for access to this
        module will be defined by the State.
FP#68   Identify and report providers‟ accounts receivable when no claim
        activity has occurred during a State-specified number of months.
FP#69   Refund the Federal share of provider overpayments within sixty (60)
        days from discovery of an overpayment for Medicaid services.
FP#70   Account for recovery payment adjustments received from third
        parties that do not affect the provider‟s 1099/W-2.
FP#71   Withhold the Federal share of payments to Medicaid providers to
        recover Medicare overpayments by establishing a receivable for
        each Medicare overpayment identified to the State.
FP#72   Automatically mark accounts receivable with a status of „Pending
        Due Process‟ to stop offset against accounts payable and interest
FP#73   Create a letter to the provider notifying the provider of the creation
        of the account receivable and of due process rights.
FP#74   Automatically change accounts receivable status to allow offset
        against accounts payable and interest calculation based on
        business rules established by the State.
FP#75   Support the ability to recover receivables from another NPI/PID with
        the same TIN.
FP#76   Produce accounts receivable aging reports and provide work
        queues for the different aging levels (e.g., 30-60-90 day).
FP#77   Provide the capability to identify the State and Federal fiscal year in
        which an accounts receivable was created.
         Cash Receipt Function
FP#78   Support accounts receivable collection by receipt of payment from
        the debtor and offset of payments.
FP#79   Apply cash receipts against accounts receivable and interest based
        on business rules provided by the State.
FP#80   Process unsolicited provider refunds.
FP#81   Designate the financial status of all cash receipt transactions
        including the date of record creation, updates, comments, financial
        coding and attach any supporting documentation.
FP#82   Update MMIS financial claims history to reflect cash receipts.
FP#83   Report on the remittance advice and the ANSI X12 835 any
        payment amounts applied to an accounts receivable or interest
FP#84   Produce deposit cycle reports including summary and detailed
        deposit tickets.
FP#85   Produce deposit files on a daily basis by 8 p.m. each day.
FP#86   Support drill down capability for accounts receivable and cash
FP#87   Produce reports and notices/letters in Microsoft Office compatible
        files for use in spreadsheets and emailing of reports.
FP#88   Allow for export of financial management reports to Excel based on
        user-defined parameters.
FP#89   Allow for beginning and end dates on reports.
FP#90    Provide the following reports:
               a. Monthly report for return of federal funds for accounts
               b. Collection activity for all accounts receivable by category
                     (Summary and Detail)
               c. Collection activity of accounts receivable that are
                     federally funded
               d. Accounts receivable balances by category (Summary
                     and Detail)
               e. Cash Receipts report
               f.    Claim payments used to satisfy receivables
               g. Accounts receivable aging report (Summary and Detail)
               h. Provider earnings report
               i.    Collection notices/letters for accounts receivables
                     available in multiple user-defined formats
               j.    Providers receiving collection notices/letters
               k. Providers referred to the State or other collection agent
                     for collection
               l.    Accounts receivable related to bankrupt providers
               m. Accounts receivable by Account Number (parameter of
                     last activity date within the current fiscal year)
               n. Deposit reports including summary and detailed deposit
FP#91    Produce exportable monthly receivable statements reflecting claim
         specific and non-claim specific receivables and payments made
         along with clam payments used to satisfy receivables.
FP#92    Support generation of statistically valid random sampling selection.
FP#93    Support a variety of financial, utilization, and eligibility reports for all
         types of transactions needed to adequately support quality
         assurance activities within the Department.
FP#94    Report and pay withholding tax in accordance with federal and State
FP#95    Verify the accuracy of 1099/W-2 information prior to issuing the
FP#96    Generate provider 1099/W 2 earnings reports annually.
FP#97    Generate federal and state provider earnings reports for the IRS
         and Montana Department of Administration in accordance with
         federal and state regulations.
FP#98    Generate a snapshot file that lists the activity in each provider's year
         to date earnings at the time the 1099/W-2 is created. A copy of each
         provider's 1099/W-2 form for the year shall be maintained for seven
         (7) years.
FP#99    Process and track provider change requests for 1099/W-2s.
FP#100   Process the annual IRS “no match” provider file and generate a
         report defined by the State.
FP#101   Test changes to 1099/W-2 processing report and submit the
         changes for review by the State.
FP#102   Report the amounts to be charged to each account code for each
FP#103   Report outstanding and historical accounts payable transactions.
FP#104   Generate and provide online detailed claims payment data reports

         by warrant number, EFT number, and claim type including type of
         financial transaction, provider numbers, client ID, account coding,
         and other criteria defined by the state.
FP#105   Create a variety of financial reports required for monitoring state
         programs (e.g., MHSP), backed up by levels of summarization that
         make up a report of total program expenditures on each report.
         Organization of the summarization must be such that it allows
         tracking back to the level of the detailed claim.
FP#106   Provide the ability to remotely view and update financial information
         (e.g. A/R and Revenue), online and in detail, and do comparisons
         on a year to year basis.
FP#107   Provide the ability to report prior periods, with comparisons to
         current periods, in order to support expense projections.
FP#108   Create subsets, internally generate norms, and produce statistically
         valid random samples for studies and audits. The system must have
         the capability to randomly select samples of claims for audits and to
         identify and extrapolate overpayments.
FP#109   Provide the ability to regularly examine financial data to determine
         expenses reported as paid and subsequent adjustments. The
         system must provide the flexibility to revise selection criteria, pull
         history data and download data for analysis.
FP#110   Balance MMIS to SABHRS daily.
24       DSS/DW Systems Requirement (DS)
DS#1     The data warehouse and decision system shall be a relational
         database that includes the full claim record for adjudicated and
         other claim, provider, reference, prior authorization, pricing tables,
         and financial transaction from MMIS; provide line level and header
         level data; and include a database of selected data elements for
         information retrieval data analysis. The following data is included
         (but is not all inclusive) in the DSS/Data warehouse:
             a. Client data containing selected client demographic, eligibility
                  and TPL coverage data reflecting the client‟s enrollment.
             b. Data containing selected provider information such as
                  provider specialty, address, enrollment, facility and group
             c. Claims data including Prescription Point of Sale (POS) data
                  containing all of claims history including paid and denied
                  claims; encounter claims; gross adjustments, claim
                  exceptions; as well as aggregated claims information.
             d. Financial data containing all financial transactions including
                  recurring payments, payouts, receivables, refunds and
             e. Reference data including prior authorization, service limit
                  procedure formulary as well as the Explanation of Benefits
                  (EOB) text component.
             f. Data from other MMIS modules as approved by the state

DS#2     Provide and maintain a data warehouse (DW) that contains all
         MMIS subsystem data files, including ten years of Claims History

        data with a rolling eleventh year based on the State fiscal year claim
        date of payment (DOP). The DW will also contain all life time claims.
        Other external systems history data in the DSS will also contain ten
        years of data with a rolling eleventh year based on the State fiscal
        year claim DOP: If 10 years of data is not available, then the
        system will include as many years available up to 10.
DS#3    Update the DSS/DW daily, and provide control and balancing
        procedures and reports to ensure that all data has been correctly
DS#4    Provide a database of all data sets from the MMIS, POS, and
        selected external data systems for information retrieval and data
        analysis as required by the State. External data systems may
        include but not be limited to AWACS, Immunization Registry, Death
        Registry, Blue Cross Blue Shield payment system, Big Sky Rx,
        SACWIS, KIDS, TEAMS, CHIMES, Disease Management and
        Member Month.
DS#5    Archive data older than 11 years with ability to retrieve data for ad-
        hoc reports as required by the State.
DS#6    All unstructured informational extracts on any variables in the
        system and be able to handle data filtering and multiple source data
        filtering (multiple filters.
DS#7    Enable queries, or other methods defined by the State, that run
        logic statements to extract information (e.g. if, then, else logic
DS#8    Incorporate a highly adaptable fraud and abuse detection
        subsystem and SURS component for the ongoing, retrospective,
        comprehensive analysis of MMIS data for the detection of potential
        provider and client fraud, abuse, or aberrant utilization of the
        Montana Health Care Program.
DS#9    Support a variety of formats and output options as specified by the
        State or further defined by national data standards (e.g., Word,
        Excel, HTML, Access database, PDF, XML, Statistical package,
        Text, or GUI format).
DS#10   Support standard summarized data to be accessed by State
        executives (e.g., Executive Information System or dashboards).
DS#11   Include the ability to calculate the budget impact of proposed rate
        changes and rebasing
DS#12   Associate clinical data (e.g., claims attachment) with the claim
DS#13   Automate calculation of rebates and reports.
DS#14   Provide a standardized data dictionary (with data source and
        definition) that is updated on a schedule approved by and
        accessible to the State. The data dictionary must be (1) updated
        each time a data element is changed or its business rule, (2) be
        accessible by the State online, (3) have an online search and review
        function, (4) incorporate the MMIS and DSS data elements, (5)
        include data element description fields as specified by the state, for
        example, but not limited to Date of creation, Origin of data, Business
        definition of the data element, Business rule used to create the data
        element, and Business rules that modify and maintain the data

DS#15   Provide the flexibility to meet both current requirements and
        proposed changes in the format and data requirements of Federal
        statistical, audit, and financial reporting (i.e. PERM) without major
        reprogramming expense. The reports must be in a format
        acceptable to the State.
DS#16   Provide a single data warehouse, unless prior approval is given by
        the State, from which all the data management tools must be run to
        produce Federal and State mandated reports
DS#17   Stamp all the records in the DSS/DW with date and source.
DS#18   Include claim records that contain the accounting codes and federal
        report codes established when the claim was adjudicated.
DS#19   Meet HIPAA standards and guidelines.
DS#20   Support simple queries and preformatted reports that are easy to
        access, follow a user-friendly protocol, and produce responses
        immediately. Criteria used for queries and preformatted reports
        must be easily accessible.
DS#21   Provide ad hoc reporting capability that presents summarized
        information on key factors (e.g., number of enrollees, total dollars
        paid) to executive staff upon request. Criteria used for queries and
        preformatted reports must be easily accessible.
DS#22   Provide ad hoc query capability for retrieval of data relevant to
        specific operational units, e.g., claims resolution, prior authorization,
        and medical necessity review.
DS#23   Support retrieval and presentation of data associated with
        geographic indicators such as by state, by county, by zip code, by
        peer group, or other geographical indicators specified by the State.
DS#24   Support Federal reporting requirements when these requirements
        are met through the DSS.
DS#25   Extend system flexibility by adding enhanced reporting above and
        beyond what is available through other MMIS functions. For
        example, provide a Geographic Information System (GIS) to display
        program population in a zip code.
DS#26   Include the ability to run “What if” scenarios related to rates,
        coverage and budget.
DS#27   Include a modeling tool for conversion factor changes or provider
        rate changes and budget process to determine impacts of funding
DS#28   Include the ability to integrate external data files that can be used as
        study groups or additional databases that can be joined or linked to
        the DSS.
DS#29   Support a range of analysis actions and supply appropriate
        predictive modeling tools, including but not limited to:
              a. Benefit modeling
              b. Utilization management
              c. Care management profiling
              d. Program planning, forecasting
              e. Program assessment
              f.     Provider or contractor performance
              g. Quality assurance
              h. Fraud detection
              i.     Comparison of fee-for-service and PCCM care

               j.    Other functions as defined by the state.
DS#30   Report program limits and other indicators, such as:
               a. Lifetime
               b. 5 year
               c. Gender specific
               d. Age specific
               e. Per year
               f.    Number of hours
               g. Underutilization
               h. Diagnosis (procedures limited to specific diagnoses
               i.    Support HEDIS (or similar measures)
               j.    Numbers of providers enrolled
               k. Pay for Performance
               l.    Hospital efficiency from cost reports
               m. Per member/per month report
               n. In patient stay table
               o. Transplant
               p. Emergency
               q. Prenatal
DS#31   Provide reports that allow users to drill down from summarized data
        to detailed data.
DS#32   Include the ability for end users to establish, maintain, manage, and
        run their own queries, 24 hours a day, seven days a week except
        for scheduled DSS/DW down time. Users will also have the
        capability to schedule reports with a broadcast agent included to
        alert the user when the report has been created/completed. Users
        will also have the capability to share reports with other users.
DS#33   Broadcast agent or query tool will allow scheduled reports and
        queries to be automatically updated and run on the basis of
        timeframe. (Examples: 1) scheduled quarterly reports will run on the
        basis of most recent quarter; 2) scheduled reports will automatically
        run on a specific date and will include most up-to-date information.
DS#34   Provide electronic access to standard reports with units of service
        and dollars.
DS#35   Include the flexibility to change dates to run reports (e.g., over fiscal
        year end). Include ability to create ad-hoc reports for any specific
DS#36   Generate reconciliation reports to balance and validate data
        between the MMIS and DSS.
DS#37   Produce the CMS 2082 in Federal and State formats as defined by
        the State for verification and State use and in Federal Medicaid
        Statistical Information System (MSIS) electronic format for
        submission to CMS.
DS#38   Provide the flexibility to report financial and statistical data on the
        Montana Health Care Program by various reporting periods
        designated by the State, including Federal fiscal year, state fiscal
        year, calendar year, waiver span and waiver year.
DS#39   Maintain the integrity of data element sources used by the
        subsystem and integrate the necessary data element to generate
        MARS reports on monthly, quarterly, annual, semi-annual, bi-
        annual, etc., basis. The State specifies the time period covered by
        each MARS report.
DS#40   Maintain the uniformity and comparability of data through the MARS
        reports and between MARS and other subsystem reports, including
        reconciliation of all financial reports with claims processing reports
        on provider reimbursement.
DS#41   Provide scheduled and ad hoc reports to meet all Federal and State
        reporting requirements.
DS#42   Maintain easy access to data relevant to the needs of staff, e.g.,
        claims adjudication, prior authorization, medical review, utilization
        review, and analysis of specific payment areas (pharmacy, dental,
        inpatient, etc.).
DS#43   Support analytical staff through sophisticated analytical tools that
        perform specific analytical functions, e.g., statistical analysis,
        comparative analysis, financial trends, case-mix adjustments within
        time ranges specified by the State.
DS#44   Collect and summarizes data for specific user communities (e.g.,
        data marts or cubes) such as program analysis staff, research
        group, and financial management unit.
DS#45   Generate required reports, e.g. 301 (monthly/date of payment),
        701/901 (date of service), CMS372, CMS64, CMS21 and other
        State and federal reports as defined by the State. Reconcile the
        301 and 701/901 reports through drill down capability. Upon State‟s
        request, must modify or update required reports in a short
        timeframe, and run historical information on new or updated report
DS#46   Provide queries to state personnel to reconcile the 301, 701/901,
        CMS372, CMS64, CMS21 and other state and federal reports to the
DS#47   Include all Fraud Detection functions as detailed in the Program
        Integrity section.
DS#48   Include information in addition to defined MMIS data such as:
                a. MDS
                b. HIPP
                c. Buy-in
                d. Others as defined by the State.
DS#49   Provide for automated cost settlement functionality for nursing
        facilities and hospitals.
DS#50   Provide cost reports in Excel, XML, text or other format determined
        by state.
DS#51   Provide for detail to be used to prepare cost settlement summary
        available from MMIS.
DS#52   Provide drill down capability in payment file.
DS#53   Store HIPP, buy-in, and clawback data in the DW for reporting
DS#54   Build cost settlement spreadsheets from claims history.
DS#55   Generate settlement notices to the provider and apply adjustments
        to claim/encounter history.
DS#56   Produce standard reports of claims for providers (e.g. hospitals,
        FQHC, and RHC) which can be used in support of cost settlements.
DS#57   Provide ability to add any requested field or calculated field into the
        DSS / DW in a timeframe specified by the State. Any new field must
        be continually populated, populated retroactively, and updated into

        the future unless specifically noted by the State.
DS#58   Support multiple variable (number to be defined by state) aggregate
        data functions (Sum, Count, Count Distinct, Etc.)

DS#59   Provide ability for user to create their own fields or subfields when
        querying system. For example age brackets or specific groupings
        based on like characteristics
DS#60   Ability to save query language or criteria in user specific folders to
        both an online server and / or local servers. Saved queries will
        show when they were last updated and should not be affected by
        system changes.

DS#61   In addition to the federal reports and the „301‟ and „701/901‟reports,
        the DSS must produce a minimum of 100 reports based on
        specifications provided by the State.

25      Federal Reporting Systems Requirement (FR)
FR#1    Support on-demand and scheduled generation of information for all
        Federal reports and supporting data required by CMS, within time
        frames and formats required by the State, including but not limited
              a. CMS 21 report -- Quarterly State Children‟s Health
                   Insurance Program (SCHIP) statement of expenditures
                   for Title XXI
                          i.    CMS 21B
                          ii. CMS21E statistical report
                          iii. Quarterly ethnicity report
              b. CMS 64 report - Quarterly Medicaid statement of
                   expenditures for the Medical Assistance Program
              c. CMS 64 report on Uncollectible Overpayments Report
                   and the report on Non-collection write-off transactions
                   applied to cash accounts receivable during the reporting
                   period and not previously refunded to CMS as
              d. CMS 64 Public provider payouts by State category of
              e. Report of checks that were voided and applied to
                   overpayment accounts receivable records
              f.   Medicaid Statistical Information System (MSIS) Data
                   according to CMS media requirements and timeframes
                   and submit a copy to DPHHS on specified media for
                   review and filing
              g. CMS 372 (Cost Neutrality Assessment for Waivers) and
                   other specified waiver reports.
              h. CMS 416 report information in accordance with the
                   Federal specifications and DPHHS specifications.
              i.   MSIS/CMS Tapes according to CMS timeframes. Media
                   may change based on CMS and State approval
              j.   SF269 Federal Financial Status Report
FR#2    Synchronize daily, the MMIS, SABHRS and the data warehouse to
        support the ability to generate reports that align paid claim detail
        with warrant and other payment information by specific accounting
        element and relative to all categories of service and spending that
        must be reported in all the Federal reports.
FR#3    Report drug rebate collections on the CMS 64 and CMS 21 as
FR#4    Report the top ten manufacturers with outstanding drug rebate
        invoices on quarterly CMS 64 data.
FR#5    Support payment error rate measurement (PERM) processing. In
        compliance with CMS quarterly claims sample frequency
        requirements, send the required data to the Statistical Contractor
        (SC) according to the claims extract approach using CMS-approved
        formats, media, and security procedures.
FR#6    Produce CMS 64 variance and CMS 21 variance reports as
        specified by the State for the current and three prior quarters. The
        variance reports must be made available within time frames and
        formats required by the State.
FR#7    Provide a full audit trail as defined by the State to support all
        transactions used to generate any and all federal reports.
26      Program Integrity Systems Requirements (PI)
PI#1    Produce an industry standard SURS product.
PI#2    Produce comprehensive statistical profiles of provider health care
        practices by peer groups for all categories of service(s) authorized
        under the Montana Health Care Programs.
PI#3    Produce Provider profiling and Fraud and Abuse Detection reports
        including but not limited to:
              a. Rendering provider;
              b. Pay-to provider;
              c. Referring provider;
              d. Primary care Provider;
              e. Group provider number;
              f.    National Provider Identifier (NPI);
              g. Prescribing provider; and
              h. Billing services or other non-traditional providers
PI#4    Produce client profiling and Fraud and Abuse Detection reports
        including but not limited to:
              a. Client ID
              b. Client case number
              c. Enrollment waiver program
              d. Eligibility programs/benefit plans
              e. Waiver service.
PI#5    Produce a system alert if one program (i.e., HMK, Medicare,
        Medicaid, etc.) terminates a provider.
PI#6    Produce automatic over-utilization alerts based on State established
PI#7    Provide a Payment Error Rate Measurement (PERM) process.
PI#8    Automatically identify deficiencies and generate reports on levels of
        care and quality of care by provider type or taxonomy.
PI#9    Automatically identify exceptions to norms of utilization or quality of
        care standards established by the State for any type of client
        covered by the State plan.
PI#10   Automatically identify exceptions to norms of practice established by
        the agency for any type of provider covered by the State plan.

PI#11   Automatically report on the details of the practice of providers
        identified as exceptions or outliers.
PI#12   Identify clients who exceed program norms, ranked in order of
PI#13   Identify services received by clients who have specified diagnoses.
PI#14   Identify services received by clients who are enrolled in selected
        programs of care.
PI#15   Generate reports as needed from a common data mart.
PI#16   Provide the capability to profile provider groups and individual
        providers within group practices.
PI#17   Generate early warning reports of high-cost services, high length of
        stay, and service misutilization based on current payment data to
        quickly identify high volume practices.
PI#18   Produce reports or display all data by National Provider Identifier
        (NPI), proprietary ID, or by a subset of the provider‟s practice or
PI#19   Profile primary care case managers, including all referrals and other
        services received by their clients.
PI#20   Perform analysis of rendering, ordering, and billing practices to
        generate reports of aberrant utilization and/or billing patterns.
PI#21   Apply clinically approved guidelines against episodes of care to
        identify instances of treatment inconsistent with guidelines.
PI#22   Link/interface with a set of measurable, clinical indicators, as well as
        diagnostic and therapeutic services, that reflect a patient‟s need for
PI#23   Provide standards of care that can be used as comparative analysis
        with updates.
PI#24   Produce HEDIS or similar measurements in the DSS/DW, as
        specified by the State.
PI#25   Track Federally-assisted program participants separately from other
        categories of assistance that integrates with the accounts receivable
        module. Provide all applicable state and federal reporting.
PI#26   Integrate with AR module in the DSS.
PI#27   Provide all applicable State and federal reports.
PI#28   Track all open and closed audit cases.
PI#29   Track compliance with plans of care.
PI#30   Profile all services provided to a client during a single episode of
PI#31   Develop provider, physician, and client profiles sufficient to provide
        specific information as to the use of covered types of services and
        items, including prescribed drugs.
PI#32   Provide a methodology and generate a report to classify treatment
        modalities into peer group categories, by diagnosis or range of
        diagnosis codes.
PI#33   Generate reports of individual clients by peer group.
PI#34   Minimize the level of manual clerical effort required to provide
        information that reveals potential defects in level of care and quality
        of service.
PI#35   Provide detection capability to determine Provider Passport ID used
        incorrectly/fraudulently on referral claims.
PI#36   Provide the ability to perform analyses and produce reports
        responsive to requests from QAD/SURS, federal oversight, OIG and
        State Medicaid Fraud Control Units by means of computerized
        exception processing techniques.
PI#37   Produce claim and encounter detail and special reports by provider-
        type, taxonomy, and client classification (e.g., category of service-
        COS) and other key variables (e.g., Group Practice, Case).
PI#38   Provide the ability to perform focused review and to generate
        reports of all reviews undertaken
PI#39   Provide access to all data elements as required by State and
        federal regulations.
PI#40   Develop test criteria and algorithms for expected outcomes prior to
        production of reports.
PI#41   Facilitate export of claims-based class groupings such that data can
        be used by spreadsheet or database software.
PI#42   Support pattern recognition and provide an automated fraud and
        abuse profiling system for the ongoing monitoring of provider and
        client claims to detect patterns of potential fraud, abuse and
        excessive billing.
PI#43   Provide and store all utilization reports in the medium designated by
        the State.
PI#44   Select claims and encounter data dating back to a time period
        appropriate for the specific research.
PI#45   Provide the flexibility to vary time periods for reporting purposes and
        to produce reports on daily, monthly, quarterly, or other frequency
        specified by the State.
PI#46   Maintain a process to apply weighting and ranking of exception
        report items to facilitate identifying the highest deviators.
PI#47   Support the capability to suppress processing on an individual
        within specified categories on a run-to-run basis.
PI#48   Provide the ability to sanitize or redact specific information on data
        extracts or reports, such as SSN.
PI#49   Perform detection of potential fraud or abuse by:
             a.    Providing a proven statistical methodology to classify
                   clients into peer groups using user-defined criteria such
                   as age, sex, race, ethnicity, living arrangement,
                   geographic region, program, aid category, and special
                   program indicator (or any combination thereof) for
                   purposes of developing statistical profiles
             b.    Providing a proven statistical methodology to classify
                   private/public providers into peer groups using user
                   defined criteria such as program, category of service,
                   provider type, multiple specialties, multiple sub-
                   specialties, type of practice/organization, enrollment
                   status, facility type, geographic location, billing versus
                   performing providers, and size or any combinations
                   thereof, for the purpose of developing statistical profiles
             c.    Providing a proven statistical methodology to classify and
                   reclassify treatment into user defined groups, by
                   diagnosis code, drug code, procedure code, episode of
                   care, groups or ranges of codes, geographical region, or
                   combination thereof, for the purpose of developing
                    statistical profiles
            d.      Generating random sampling using a State-approved
                    methodology, including stratified random sampling, with
                    associated statistics (for example: universe statistics and
                    confidence levels) Document the random sampling
                    methodology for use in court hearings. Provide the
                    option to preserve the random seed to reproduce the
                    random sample or to generate a new seed to produce a
                    new random sample
             e. Generating statistical norms and statistical samples, by
                    peer or treatment group, for each indicator contained
                    within each statistical profile by using averages and
                    standard deviations or percentiles
             f.     Extrapolating sample results using generally accepted
                    statistical techniques; this capability must include the
                    ability to extrapolate, at various levels of confidence,
                    instances of attributes or occurrences in the sample
                    (number of claims with errors) and value of variables in
                    the sample (dollar overpayments)
             g. Comparing claims to parameters approved by the State.
27     Security and Privacy Systems Requirements (SP)
SP#1   Provide a physical and electronic environment that verifies the
       identity of all users and denies access to unauthorized users. For
             a. Require unique sign-on (ID and password)
             b. Require authentication of the receiving entity prior to a
                    system-initiated session, such as transmitting responses
                    to eligibility inquiries.
SP#2   Provide a single sign-on for the MMIS, POS, and DSS (all
SP#3   Enforce password policies for length, character requirements, and
       updates as approved by the State.
SP#4   Support a user security profile that controls user access rights to
       data categories and system functions.
SP#5   Create a data classification schema with data items flagged to link
       them to a classification category with an access privilege scheme
       for each user that limits the user‟s access to one or more data
       classification categories.
SP#6   Provide an initial layout for approval by the State, for the Designated
       Record Set (DRS) that allows it to be included in responses to
       inquiries and report requests. The DRS must be HIPAA compliant.
SP#7   Ensure data integrity through system controls for software program
       changes and promotion to production.
SP#8   Provide online inquiry and report(s) that include all of the current
       and historical information about access and rights provided to State
       and Contractor staff. The report should be standardized as to the
       data it will contain, but allow user input of run criteria such as ID #,
       access, timeframes, etc. The inquiry and report must be able to be
       produced by authorized State and/or Contractor staff at any point in
SP#9   Verify authenticating authority (as well as identify) for the use or
       disclosure requested. For example:
             a.     Deny general practitioner inquiry for client eligibility for
                    mental health services.
              b. Permit inquiries on claim status only for claims submitted
                    by the inquiring provider.
              c. Include State defined reports that show who has access
                    to what information for audit purposes. Ex. Which
                    provider inquired on what claims. This is for medical
                    history inquiry.
              d. Generate reports related to the claims medical history on
                    the web portal specifying the user who accessed, what
                    client was queried upon and what claims were queried.
SP#10   Provide encryption and decryption of stored ePHI or an equivalent
        alternative protection mechanism.
SP#11   Provide encryption of ePHI that is being transmitted, as appropriate.
SP#12   Provide integrity controls to guarantee that transmitted ePHI is not
        improperly modified without detection (e.g., provide secure claims
SP#13   Provide data integrity of ePHI by preventing and detecting improper
        alteration or destruction (e.g., double keying, message
        authentication, digital signature, check sums etc.)
SP#14   Provide secure and confidential data requirements for data
SP#15   Provide the capability to trace all system activity to a specific user.
SP#16   Generate alerts for conditions that violate security rules, for
              a. Attempts to access unauthorized data and system
              b. Logon attempts that exceed the maximum allowed
              c. Termination of authorized sessions after a specified time
                    of no activity
SP#17   Provide security incident reporting and mitigation mechanisms, such
              a. Generate warning or report on system activity based on
                    security parameters established by the State.
              b. Terminate access and/or generate report when potential
                    security violation detected.
              c. Terminate access as directed by the State when State
                    and Contractor employees are terminated.
              d. Preserve and report specified audit data when potential
                    security violations are detected.
              e. Supports procedures for guarding, monitoring, and
                    detecting malicious software (e.g., viruses, worms,
                    malicious code, etc.).
SP#18   Implement a security system that will allow only authorized inquiry
        access to designated personnel. Update capabilities shall be
        allowed to designated personnel. Security must be imposed at
        various levels as deemed necessary by DPHHS (i.e., operator,
        screen or data element). Audit trail reports must be produced for all
        batch and online update transactions. The online audit trail report
        must include a record of the date, time and operator ID of the
        person making the update as well as a before and after image of the
        record or field updated. The DPHHS must approve and designate
        personnel access to MMIS, POS and DSS data.
SP#19   Ensure that the system facilitates auditing of individual claims.
        Adequate audit trails must be provided throughout the system and
        the conversion programs. Where override codes are permitted, the
        use of such codes must be reported. Changes to prices, provider
        data and client eligibility must each be highly controlled and
        reported and must create appropriate audit trails and reports.
SP#20   Ensure that an appropriate security system is in place to prevent
        inappropriate or unauthorized updating of the MMIS or PBM files.
SP#21   Provide the ability to respond to an authorized request to provide a
        report containing the Designated Record Set (DRS) for a given
SP#22   Set indicators that can restrict distribution of ePHI in situations
        where it would normally be distributed.
SP#23   Track disclosures of ePHI and provide reports to authorized users
        and access to the disclosures.
SP#24   Identify and note amendments to the Designated Record Set (DRS)
        for a given individual.
SP#25   Meet all Federal regulations regarding standards for privacy,
        security, and individually identifiable health information as identified
        in the Health Insurance Portability and Accountability Act (HIPAA) of
        1996 and other federal laws.
SP#26   Meet all State regulations regarding standards for privacy, security,
        and Protected Health Information as defined by the State.
28      Immunization Registry System Requirements (IR)
IR#1    Update information from the IR to the MMIS daily.
IR#2    Hot link Immunization Registry data to the correct client, provider,
        and claims data if a Montana Health Care Program client, without
        requiring an additional log in
IR#3    Collect and maintain claims history for vaccinations at the client-
        specific level as specified as the State.
IR#4    Measure immunization coverage for the Montana Health Care
        Program population using the current EPSDT periodicity schedule.
IR#5    Enable analysis through Geographic Information Systems (GIS).
IR#6    Meet or exceed the Federal EPSDT reporting requirements.

29      Waiver Systems Requirement (HB)
HB#1    Provide the ability to add/change/delete a waiver service from a
        waiver program and from an individual‟s plan of care.
HB#2    Generate payments to waiver providers and clients up to a specific
        dollar amount or number of units.
HB#3    Provide the ability to automatically approve prior authorizations for
        waiver services up to a specific dollar amount.
HB#4    Accumulate member months based on waiver type and per specific
        population. (For example, we will have 5 separate “populations” for
        the HIFA waiver and we will need to count member months
        separately for each population and for the waiver.)
HB#5    Accumulate member days based on waiver type and per specific
HB#6    Generate notices or alerts to the State if the number of unduplicated
        clients enrolled in a waiver program reaches a level specified by the

        State, before the number of clients in the waiver application
        exceeds maximum enrollment.
HB#7    Provide the ability to accept different start and end dates for
        different waiver programs for an individual client.
HB#8    Store the date that a Client‟s plan of care (POC), (levels of care,
        PASARR, screening records, clinical assessment, and other
        required documents) is initially completed and let the worker update
        the date of the next document re-evaluation if applicable. Provide
        the capability of an alert in the Workflow management that the
        document is due
HB#9    Process waiver provider and client claims and make timely and
        accurate payments.
HB#10   Store the plan of care and make it available for viewing according to
        rules determined by the State.
HB#11   Provide the ability to identify and extract services approved as
        exceptions to certain waiver programs/POC.
30      Current Care Management Requirements (MP)
MP#1    Support state approved processes for Care Management programs.
MP#2    Identify clients eligible for Care Management programs daily using
        state defined criteria.
MP#3    Allow for a "lock-in" enrollment indicator identifying how a client was
        referred to the program.
MP#4    Provide capability to capture and display enrollee choice of PCP
        and/or Pharmacy on client record.
MP#5    Capture and display on client record the origination of PCP
MP#6    Capture and display on client record Care Management plan code.
MP#7    Allow and support "opt in" for specific Care Management plan
MP#8    Provide capability to auto assign Care Management enrollees who
        fail to choose a PCP to a PCP using state approved assignment
MP#9    Automatically assign "lock-in" enrollees daily or as necessary to a
        PCP and/or pharmacy using state approved assignment algorithm.
MP#10   Provide for “client not allowed to change” indicator on "lock-in"
MP#11   Provide the capability for each Care Management client in the
        household to be enrolled with a different PCP and/or Pharmacy.
MP#12   Capability to capture, track, and display a choice/assignment
        indicator on client file including the method a client was assigned.
MP#13   Provide capability for "lock-in" clients to be locked into PCP,
        Pharmacy, or both.
MP#14   Provide capability to identify clients daily who are reinstated to Care
        Management programs after temporarily losing Medicaid or Care
        Management eligibility.
MP#15   Automatically disensrolls Care Management enrollees if
        PCP/Pharmacy number is terminated.
MP#16   Provide capability to disenroll a client when the PCP or Pharmacy
        requests the removal of a client from their caseload.
MP#17   Perform mass reassignment of enrollees when clients have been
        disenrolled by a PCP or Pharmacy.

MP#18   Identify clients exempt from care management enrollment, subject
        to mandatory enrollment, or free to voluntarily enroll in PCP.
MP#19   Automatically identify clients exempted from Care Management
        enrollment based on state provided algorithms.
MP#20   Allow for manual exemptions to be added and removed when
MP#21   Capability to capture, track, maintain, and display exemption
        reasons codes.
MP#22   Support the ability to set a "yes or no" indicator based on the PCP's
        evaluation of a client's suitability for "lock-in".
MP#23   Provide utilization report to identify clients who use excessive
        services as defined by the state.
MP#24   Provide capability to track, calculate, and report months of client
        enrollment and eligibility in the "lock-in" program.
MP#25   Support the ability to audit enrollment numbers for accuracy to
        ensure enrollment problems are reported timely.
MP#26   Display enrollees associated each level of Care Management Plan.
MP#27   Capability to transmit Care Management data for clients and
        provider to data warehouse.
MP#28   Capability to support and manage a tiered evidence based Care
        Management plan
MP#29   Identify physicians who have agreed to provide gatekeeper
        services, geographic location(s), number of assigned clients, and
        capacity to accept additional patients.
MP#30   Maintain provider/pharmacy exclusion lists when a client is
        dismissed from a provider‟s caseload based on behaviors and non
MP#31   Display enrollees associated with PCP or Pharmacy.
MP#32   Accept and process updates to information about the PCP or
        pharmacy as changes are reported.
MP#33   Maintain cross reference to clients enrolled with each PCP to
        ensure the maximum enrollment is not exceeded
MP#34   Provider file must include maximum enrollment for Care
        Management and indicators for limitations on client types.
MP#35   Allow for clients to be placed in a pending provider approval status
        when a PCP has reached maximum enrollment and generate a
        monthly list of pending clients to each limited provider to allow the
        provider to approve/decline clients.
MP#36   Capability to track clients in pending provider approval status.
MP#37   Capture termination information when a PCP provider contract is
MP#38   Capability of interfacing with PCP / Pharmacy licensure boards to
        proactively disenroll clients from providers or pharmacies when
MP#39   Calculate case management fee based on the number of clients for
        Care Management per client per month for primary care providers in
        Care Management services
MP#40   Edit and deny claims for services without PCP referral.
MP#41   Allow payment to providers for services carved out of the PCP
        benefit packages
MP#42   Allow payment for emergency medical condition without
        authorization from PCP
MP#43   Edit and deny claims from referral providers if service is not
        authorized by a PCP gatekeeper.
MP#44   Allow payment for fee for service providers for services rendered in
        pre enrollment periods or other periods of transition.
MP#45   Provide for data elements to support primary care case
MP#46   Provide the capability to calculate member months per PCP by age
        groups and other demographics as defined by the state.
MP#47   Provide capability to maintain an online audit trail of all updates to
        Care Management data.
MP#48   Capability to allow authorized state users to enter new lock-in
        enrollee information via secure site.
MP#49   Capability for call center counselors to log incoming calls with call
        reason codes to track client help line usage.
MP#50   Provide capability for outbound call reason codes to track the type
        of outgoing calls initiated by call center counselors.
MP#51   Provide the capability for call center staff to enter provider choices
        for an entire case/family on one screen.
MP#52   Capability to log, track, and maintain complaints log for client
        complaints received.
MP#53   Provide capability of an indicator to be used for health surveys.
MP#54   Capture survey responses and provide to department in a readable
        and transferable format
MP#55   Identify individuals/enrollees who have lost eligibility and exclude
        those individuals from the monthly capitation payment
MP#56   Capability to adjust capitation payment based on reconciliation of
        errors or corrections.
MP#57   Provide for a monthly enrollment reconciliation process to quickly
        identify possible enrollment issues and report the results to the
MP#58   Provide capability to track the utilization rates and costs for program
        enrollees and to compare such utilization rates and costs to
        comparable groups of non- care management clients and across
        different care management programs to assure sufficient savings
        are achieved.
MP#59   Provide capability to track outbound call outcomes when indicated
        through telephone or web outreach functions such as phone busy,
        no answer, phone disconnected, wrong number, enrollment
        complete, education complete.
MP#60   Allow for address update field to capture client driven information
        updates. Capability to forward updated address information to OPA
        offices or other state approved entities.
MP#61   Capability to accommodate alternative client/provider
MP#62   Generate all communication materials for Care Management
        programs as defined in Care Management section 5.3.2,

        attachment F.
MP#63   Calculate, select, and invoice (notice) premium amounts as
        appropriate and specified by the state; process premium notices.
MP#64   Process premium receipts from clients
MP#65   Support premium inquiries
MP#66   Support premium collection reports.
MP#67   Support multiple care management plans (i.e. MHIP)
MP#68   Provide a "PACE" indicator on client file when a client is enrolled in
        the PACE benefit plan.
MP#69   Prevent payment of any claim billed by a provider that is not the
        PACE provider, including Medicare cross-over claims, if the client is
        enrolled in the PACE benefit plan.
MP#70   Generate a capitation payment for clients enrolled in the PACE
        benefit plan based on the rate for the provider.
MP#71   Provide capability to adjust the PACE provider payment for client
        spend down as well as the post eligibility treatment of income
MP#72   Provide capability to assure the PACE program does not co-exist
        with any other benefit plan.
MP#73   Provide the capability to notify PCCM of the authorized specialty
        providers per enrollee and their automatic authorization to serve the
MP#74   Capability to provide ad hoc and other system generated reports
        daily, weekly, monthly, and quarterly. A list of the current care
        management reports is included in the Procurement Library and will
        be a requirement in the design document.
31      State Reports

RPT#1   The MMIS and PBM generate data for production reports and
        produce a minimum of five hundred such reports based on
        specifications provided by the State.

RPT#2   Provide easy and quick access to production reports from users‟
        workstations on
        the State‟s LAN/WAN, including the following capabilities:
        (a) Query all MMIS modules.
        (b) Build and run queries from their desktops.
        (c) Traverse and drill down the data.
        (d) View all MMIS reports on-line.
        (e) Export data and reports to desktop packages such as Excel,
        Word, ACCESS, text files, and other software packages available
        on the State LAN/WAN.
        (f) Develop and save queries for future use
        (g) View on-line documentation, including dictionary of data and
        data fields for each report.

RPT#3   Provide for on-line viewing of all production reports with the
        capability to print the report or selected portions of the report from

        the users desktop. b) On-line reports will be available on request by
        the State in the media specified by the user (e.g., downloadable file,
        optical storage, or hard copy).
RPT#4   All MMIS production reports must be archived for permanent
        storage in electronic media approved by the State.
32      Managed Care Requirements(MC)
MC#1    Provide the ability to capture enrollee choice of MCO and enter into
        client record.
MC#2    Provide the ability to assign enrollees to MCOs based on factors
        such as client age, sex, geographic location, MCO capitation rate,
        and location.
MC#3    Provide the ability to display enrollees associated with an MCO.
MC#4    Provide the ability to disenroll clients from an MCO.
MC#5    Provide the ability to allow a client to disenroll without cause during
        a period to be defined by the State following the date of the
        enrollee‟s initial enrollment.
MC#6    Provide the ability to automatically disenroll and re-enroll clients in
        new plans during periods of open enrollment or when an MCO
        leaves the program.
MC#7    Provide the ability to automatically disenroll a client from a
        terminated MCO and place the client in regular fee-for-service
MC#8    Provide the ability to generate notices to clients of assignment to or
        disenrollment from an MCO.
MC#9    Provide the ability to identify clients excluded from enrollment,
        subject to mandatory enrollment, or free to voluntarily enroll in an
MC#10   Provide the ability to prioritize enrollment for clients to continue
        enrollment if the MCO does not have the capacity to accept all
        those seeking enrollment under the program.
MC#11   Provide a default enrollment process for those clients who do not
        choose an MCO.
MC#12   Provide the ability to automatically re-enroll a client who is
        disenrolled solely because he or she loses Medicaid eligibility for a
        period of two months or less (optional if the State Plan so specifies).
MC#13   Support ANSI X12N 834 transaction as required by the Health
        Insurance Portability and Accountability Act (HIPAA).
MC#14   Receive MCO contract information from the contract data store
        (e.g., address, covered services, rates).
MC#15   Provide the ability to receive and process PCP registry data from
MC#16   Provide the ability to calculate or select premium payment amount
        and generate per member/per month (PMPM) payment (capitation,
        premium, case management fee).
MC#17   Provide the capability to generate regular capitation payments to
        MCOs, at least on a monthly basis in compliance with HIPAA-
        standard X12 820 Premium Payment transaction where applicable.
MC#18   Provide the ability to transmit enrollment and PMPM payment data
        to the MMIS and data warehouse.
MC#19   Provide the ability to transmit enrollment records and PMPM
        payments to MCOs.

MC#20   Provide the ability to calculate and generate premium notices to
MC#21   Provide the ability to process premium receipts from clients.
MC#22   Support inquiries regarding premium collections.
MC#23   Produce premium collection reports from the DSS.
MC#24   Provide the capability to support multiple Managed Care benefit
MC#25   Provide the capability to maintain Managed Care capitation rates for
        specific groups of clients
MC#26   Capture information on contracted MCOs, including geographic
        locations, capitation rates, and organization type.
MC#27   Capture information identifying contracted providers within the MCO
        network, including PCPs.
MC#28   Accept and process update information as changes are reported.
MC#29   Capture termination information when an MCO contract is
MC#30   Provide information to support assessment of adequacy of provider
        networks. This includes identifying and collecting data on the
        number and types of providers and provider locations.
MC#31   Provide information to support review of new enrollments and to
        prohibit affiliations with individuals debarred by Federal Agencies.
MC#32   Provide the capability to calculate per-member per-month (PMPM)
        capitation payments based on State-defined rate factors such as
        age, sex, category of eligibility, health status, geographic location,
        and other.
MC#33   Compute capitation payment for the actual number of days of
        eligibility in a month (i.e., enrollee may not be enrolled for a full
MC#34   Identify individuals/enrollees who have terminated enrollment,
        disenrolled, or are deceased, and exclude those individuals from the
        monthly MCO capitation payment.
MC#35   Provide the capability to adjust capitation payment based on
        reconciliation of errors or corrections (e.g., retroactive adjustments
        to a particular capitation payment based on more accurate data that
        the MMIS obtains retroactively on client enrollments, disenrollments,
        and terminations).
MC#36   Provide the capability to perform mass void and replacements to
        rates according to State policy (e.g., annual adjustment, negotiated
        rate change, court settlement).
MC#37   Provide the capability to perform periodic reconciliations of State
        client records with MCO enrollment records.
MC#38   Provide the capability to verify correct transfer of capitation payment
        when a client disenrolls from one MCO and enrolls in another plan.
MC#39   Provide the capability to track the utilization rates and costs for
        program enrollees and to compare such utilization rates and costs
        to comparable groups of non-Managed Care clients and across
        different managed Care plans to assure sufficient savings are
MC#40   Provide the capability to collect and store encounter data on a
        periodic basis.
MC#41   Provide the capability to apply key edits to encounter data, e.g.,

        MCO, physician, client ID numbers, diagnosis and procedure codes.
        (Note: the encounter record edits can be different from claims edits.)
MC#42   Provide the capability to return erroneous encounter data for
MC#43   Provide the capability to perform adjustments to encounter data.
MC#44   Provide the capability to periodically produce reports for audits on
        accuracy and timeliness of encounter data, including matching
        encounter records to MCO paid claims and to the provider‟s billing.
MC#45   Provide the capability to calculate the “Encounter Cost Value,” or
        the cost of services reported on the encounter claim had they been
        paid on a fee-for-service basis
MC#46   Provide the capability to accept and processes encounter claims in
        formats as mandated by HIPAA, e.g., X12N 837.
MC#47   Provide the capability to access and report on encounter data for
        the purpose of monitoring appropriateness of care.
MC#48   Provide the capability to access and report on encounter data for
        use in the determination of re-insurance to calculate true out-of-
        pocket costs.
MC#49   Provide the capability to access and report on encounter data for
        use in profiling MCOs and comparing utilization statistics.
MC#50   Provide the capability to collect and sort encounter data for use in
        completing MSIS reports.
MC#51   Provide the capability to collect and sort encounter data for use in
        determining capitation rates.
MC#52   Provide the capability to process encounter data to detect
        underutilization of services by enrollees of the MCO.
MC#53   Provide the capability to match capitation summary data and fee-for-
        service (FFS) claims data to verify that the MCO payments do not
        exceed FFS upper limits.
MC#54   Provide the capability to compare FFS claims statistics and
        encounter data, regarding cost of care, timeliness of care, quality of
        care, and outcomes.
MC#55   Provide the capability to access encounter data to identify persons
        with special health care needs, as specified by the State.
MC#56   Provide the capability to produce reports to identify network
        providers and assess enrollee access to services.
MC#57   Provide the capability to produce managed care program reports by
        category of service, category of eligibility, and by provider type.
MC#58   Provide the capability to periodically generate client satisfaction
MC#59   Provide the capability to block payment to fee-for-service (FFS)
        providers for services included in the MCO benefit package, with the
        exceptions stated per the State Plan.
MC#60   Provide the capability to allow fee-for-service (FFS) payment to
        providers for services carved out of the MCO benefit package.
        (These services are usually delivered by providers external to the
MC#61   Provide the capability to allow payment to fee-for-service (FFS)
        providers for services rendered in pre-enrollment periods or other
        periods of transition.
MC#62   Provide the capability to allow payment for treatment obtained by an

        enrollee for an emergency medical condition without prior
MC#63   Provide the capability to collect basic administrative information, for
              a. Identification of an MCO
              b. Contract start and end dates
              c. Contract period/year
              d. Capitation effective date
              e. Maximum enrollment threshold
              f.    Enrollee count
              g. Member month
              h. Re-insurance threshold

MC#64   Enhance the Web Portal to provide online access to all client,
        provider, claims, and reference data related to Managed Care.
MC#65   Capture enrollee participation in Medicaid Health Improvement Plan
        and enter into client record.
MC#66   Display enrollees associated with Medicaid Health Improvement
MC#67   Disenroll clients from Medicaid Health Improvement Plan
MC#68   Display disenrolled clients with disenrollment reasons
MC#69   Generate notices to enrolled and disenrolled clients
MC#70   Identify excluded and disenrolled clients

MC#71   Support transactions required by HIPAA
MC#72   Transmit Medical Health Improvement Plan data for clients and
        providers to data warehouse.
MC#73   Track utilization rates and costs for clients; compare costs across
        program enrollees and non-enrollees.
33      Electronic Health Records / Medicaid Provider Incentive
EHR#1   The system shall provide a beneficiary electronic health record
        based the requirements set forth in WPA#47and the requirements
        set forth in this section.
EHR#2   The system shall provide all access via a web portal.
EHR#3   The system shall identify each data element by its source.
EHR#4   The system shall sort or filter information in the electronic health
        record according to user-defined criteria, such as diagnosis or
        service location.
EHR#5   The system shall retain three years of MMIS and PBM claims line
        history per beneficiary and shall permanently retain all lifetime
EHR#6   The system shall provide an „opt-out‟ function to limit or prohibit the
        exchange of restricted data based on patient request (e.g.,
        psychiatric data).
EHR#7   The system shall implement “opt-out” as part of the interface with a
        source system so that the release of information from the EHR can
        be controlled by the source system.
EHR#8   The system shall permit searching across the entire record, both
        structured (i.e., field-constrained text) and non-structured data (i.e.,
         free text).
EHR#9    The system shall provide the ability to incorporate narratives from
         external clinical information as free text.
EHR#10   The system shall present data captured externally, such as on-line
         provider entry and notes, wherever appropriate. The system will
         also indicate who entered the information.
EHR#11   The system shall capture laboratory results together with normal
         reference ranges, if available.
EHR#12   The system shall capture radiology reports together with the
         associated clinical quality images, if available.
EHR#13   The electronic health record shall display immunization data from
         immunization registry.
EHR#14   The system shall provide “drill-down” capability starting at the
         beneficiary summary profile to the detailed claim line level data.
EHR#15   The system shall retain key dates that are related to beneficiary‟s
         history and physical, such as date of diagnosis for a chronic disease
         (i.e., diabetes) or life-changing operational procedures (i.e.,
EHR#16   The system shall include external clinical information such as image
         documents and other clinically relevant data, identifying the source
         of that information, if available.
EHR#17   The system shall present immunization data captured from MMIS
         claims as part of the display of the beneficiary summary.
EHR#18   The system shall maintain all beneficiary information, identified by
         information source, regarding allergies, medical conditions, and
         drug intolerances.
EHR#19   The system shall have the capability to summarize, filter, and
         facilitate searching through large amounts of data, including claims
         data, data entered by a provider, and data entered by a beneficiary
         during the delivery of beneficiary care.
EHR#20   The system shall present beneficiary data in chronological order as
         the default, since much of this data is date or date-range specific.
EHR#21   The system shall provide access for providers to obtain hospital
         discharge information based on Medicaid claims.
EHR#22   The system shall capture beneficiary vital signs through direct
         provider input to include height/weight, blood type, blood pressure,
         pulse, and oxygen level.
EHR#23   The system shall maintain a history of each vital sign according to
         date of service, or date of data entry.
EHR#24   The system shall provide a medication profile for each beneficiary.
EHR#25   The system shall populate the medication profile from the following
         sources, maintaining a record of the source: claim at the service
         line level, patient attestation, provider/pharmacist order (i.e., e-
EHR#26   The system shall originate, document, and track referrals between
         care providers including emergency room, specialty referrals and
         source for the coordinating of care.

EHR#27   The system shall calculate Body Mass Index (BMI) from provider-
         entered height and weight.
EHR#28   The system should have the capability to link to external Prior
         Authorization portal sources.
EHR#29   The system shall generate alerts and flags using evidence-based
         guidelines focusing on chronic disease, as well as on prevention.
EHR#30   At a minimum, the system shall include Medicaid specific quality
         indicator (QI) measures for diabetes and asthma, EPSDT screening
         guidelines, and depression screening guidelines.
EHR#31   The system must be modifiable to add new alerts/flags for additional
         QI measures or changes to existing measures.
EHR#32   The system shall include preloaded, evidence-based guidelines
         from approved official sources, and approved by the Department,
         with measures appropriate to the State. (Note: The Contractor
         shall provide the sources of evidence-based guidelines that it has
         incorporated into the proposed system.).
EHR#33   The system shall limit the results of the search/query according to
         the role of the user.
EHR#34   The system shall generate automated alerts for abnormal clinical
         values, practice-specific alerts, and follow up reminders, and ensure
         alerts are routed appropriately and can be sent via email, printer,
         fax, or pager.
EHR#35   The system shall control access to data elements of the EHR by
         each user role.
EHR#36   The system shall prohibit unauthorized users from accessing certain
         beneficiary information according to State and Federal
         confidentiality rules.
EHR#37   In the case of a disaster, the system shall allow access to
         beneficiary medical records to approved RHIO‟s, or any other
         source, as directed by the State.
EHR#38   The system shall allow beneficiaries and their legal representatives,
         if applicable, access to view their own health records or a subset, as
         approved by DPHHS.
EHR#39   The system shall allow beneficiaries to input information into their
         own health records or a subset, as approved by DPHHS.
EHR#40   The system shall provide DPHHS formulary information for all drugs
         in the drug reference file.
EHR#41   The system shall update the drug reference file from the Fiscal
         Agent on a daily basis, or as directed by the State.
EHR#42   The system shall include Preferred Drug List (PDL) information,
         maximum units, override and prior authorization requirements,
         generic and therapeutic alternatives, drug monographs and
         prescribing information at point of prescribing. Changes must be
         updated within one business day of the request.
EHR#43   The system shall maintain at least three years of pharmacy claims
EHR#44   The system shall provide Part D plan information.
EHR#45   The system shall utilize a Provider lock-in indicator. This data shall
         be displayed in the Beneficiary summary view.
EHR#46   The system shall limit access to the e-prescribing capability to
         providers with prescriptive authority.
EHR#47   The system shall display monthly script limits, number of scripts
         used, and monetary limitations based on the program, as obtained
         from the PBM nightly extract.
EHR#48   The system shall check for dose range based on predetermined
         characteristics, including age, height, weight and additional
         attributes, such as pregnancy, gender, and BMI calculation (derived
         from height and weight).
EHR#49   The system shall perform Drug Utilization Review (pro-DUR) and
         generate alerts such as:
                     drug-to-drug compatibility
                     drug to allergy
                     drug interaction
                     therapeutic duplication
                     low and high dose
                     drug-condition
EHR#50   The system shall support multiple medication benefit plans with
         different formularies to accurately display each formulary based on
         the beneficiary‟s benefit plan.
EHR#51   The system shall facilitate the submission of electronic
         prescriptions, new and refills, to a pharmacy in multiple formats
         (e.g., fax, printable for signature, etc.) approved by DPHHS.
EHR#52   The system shall produce alerts based on preferred vs. non-
         preferred usage criteria set by the State.
EHR#53   The system shall provide a means for prescribers to enter
         medications currently being taken by patients that have not been
         prescribed through the system and/or are not available through
         external interfaces/sources.
EHR#54   The system shall, at a minimum, provide/report the following
         Provider Usage Statistics, including Scripts Written, Adopter Status
         (Adopter, User, Registrant), Number of patient lookups, as well as
         Provider Rate of Generics vs. Brand, and Provider Formulary
EHR#55   The system shall report to prescribers when their patients have filled
         the prescriptions they have written and flag those prescriptions not
EHR#56   The Contractor shall provide support of a Master Patient Index
         (MPI) to track a client across an integrated or disparate group of
         health providers and clinics and provide a description to
         demonstrate the mapping methodology.
EHR#57   The system shall have the ability to capture and update beneficiary
         information and will support standard demographic information, as
         well as user-defined fields.
EHR#58   The system shall have the ability to generate and send faxes.
EHR#59   The Contractor shall ensure System Performance uptime as 24/7
         with a minimum of 99% uptime.
EHR#60   The system shall perform preventative maintenance and
         updates/uploads without user interruption.
EHR#61   The system shall have no single point of failure.
EHR#62   The system shall have the ability to identify Primary Care
EHR#63   The system shall archive the 37th month of claims history at the end
         of each operational month, ensuring at least 36 months of online
         claims data.
EHR#64   The system shall allow users to create rules based alerts, as long as
         it does not override or conflict with rules based guidelines.
EHR#65   The system shall generate DPHHS-specified disclaimers with an
         automated alert according to the business rules that have been
         established for that alert.
EHR#66   In accordance with Federal regulation 42 CFR Section 455.14, if the
         Contractor or any of their agents, identify any questionable practice
         or pattern or receive any complaint regarding allegations of provider,
         enrollee, supplier or contractor fraud and/or provider, supplier or
         contractor abuse from any source, the Contractor shall immediately
         initiate an inquiry into whether sufficient basis exists to warrant
         further investigation by any agency. If further investigation is
         indicated and/or initiated, a written referral of the case, including all
         pertinent information available, shall be forwarded to the DPHHS
         within 30 days of the close of the initial inquiry.
EHR#67   The application must be accessible via Internet Explorer 7.0, Firefox
         2.0,and Mozilla 5.0, at a minimum.
EHR#68   The Demographics exchange standard shall be HL7 2.4 or higher.
EHR#69   The Medications exchange standard shall be HL7 2.4 or higher and
         the standard for vocabulary used shall be NCPDP (retail pharmacy),
         NDF-RT, RxNorm (inpatient pharmacy), AHFS, FDB and NDC.
EHR#70   The Problem/Symptom exchange standard shall be HL7 2.4 or
         higher and the standard for vocabulary used shall be ICD-9-CM,
         SNOMED CT.
EHR#71   The Major Procedures exchange standard shall be HL7 2.4 or
         higher and the standard for vocabulary used shall be CPT-4,
         HCPCS, SNOMED CT.
EHR#72   The Allergies exchange standard shall be HL7 2.4 or higher and the
         standard for vocabulary used shall be Free text, SNOMED CT
         (reaction), Medications (see above), Unique Ingredient Identifier
         (UNII) for environment/food.
EHR#73   The Hospital/Physician Visits exchange standard shall be HL7 2.4
         or higher and the standard for vocabulary used shall be ICD-10-CM
         (physician), HL7 2.4 (hospital).
EHR#74   The Laboratory/Micro/Radiology exchange standard shall be HL7
         2.4 or higher and the standard for vocabulary used shall be CPT-4,
         LOINC (lab/micro order names), SNOMED CT (lab/micro results),
         DICOM (images, faxes).
EHR#75   The Contractor shall comply with State guidelines and standards
         related to Substance Abuse/Mental Health--State Plan for Mental

         Health Services.
EHR#76   The Contractor shall comply with State guidelines and standards
         related to State Board of Pharmacy.
EHR#77   The Contractor shall comply with State guidelines and standards
         related to State Board of Medical Examiners.
EHR#78   Migrate Medicaid Provider Incentive Program (MPIP) Data
EHR#79   Provide MPIP Registration Functionality
EHR#80   Provide MPIP provider attestation Functionality
EHR#81   Provide MPIP Bi-direction NLR Interfaces Functionality
EHR#82   Provide Payment Calculation Functionality
EHR#83   Provide Payment Distribution Functionality
EHR#84   Provide Audit Functionality
EHR#85   Provide Appeals Functionality
EHR#86   Provide Provider Messaging Functionality
EHR#87   Provide EHR Incentive Program Workflow
EHR#88   Provide Quality Reporting Functionality
EHR#89   Migrate Medicaid Provider Incentive Program (MPIP) Data
34       ICD-10 to ICD-9 Translation Process
ICD#1    The State is required to be compliant with ICD-10 by October 1,
         2013. The Contractor must provide the State with an ICD-10 to
         ICD-9 translation process that will be used from October 1, 2013
         until the new MMIS is implemented.
ICD#2    The translator will receive an inbound 5010 837containing ICD-10
         diagnosis and procedure codes from the current fiscal agent
ICD#3    Translate the ICD-10 codes to ICD-9 codes.
ICD#4    Output a 5010 837 containing only ICD-9 diagnosis and procedure
         codes to be sent to the current fiscal agent.


Shared By: