{"text_format":"1","workbook":"xlsx","n_sheets":4,"sheets":["EHR & EPM Functionality to send","Validations","Data Conversion - Contracting","Scenarios"],"not_rendered":{"charts":0,"images":0,"macros":1,"external_links":0,"defined_names":106,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"EHR & EPM Functionality to send","index":0,"n_rows":983,"n_cols":7,"rows_kept":983,"cut":false,"hidden":false,"merged":[[0,0,0,4]]}
["ATTACHMENT H:  FUNCTIONALITY REQUIREMENTS"]
[null,"ID#","Requirement","Detailed Description","Feature Availability in Software",null,"Av"]
[null,"1.0","User Functions",null,null,null,"Fully meet and included with Cost"]
[null,1.1000000000000001,"General Requirements",null,null,null,"Can meet with modification or additional cost"]
[null,"1.1.1","System shall have the ability to auto-save documents","This would occur during the writing of the document or form without any action taken by the end user",null,null,"Cannot meet requirement"]
[null,"1.1.2","System shall allow providers to save incomplete/ work-in-progress documents that can be worked on later","They shall have the ability to save the document and then complete the transaction later.  ",null,null,"you believe this requirement is not applicable to your service delivery model"]
[null,"1.1.3","System shall support tracking of dates as a document completes different stages (i.e. draft created, updates, date finalized).","Tracking of dates should be available in the user interface or in an audit trail available for reporting."]
[null,"1.1.4","System shall support saving documents with required elements missing until finalization","If a staff has to follow up to determine the content of required fields, they should be able to save the document as a draft without the required values until the document is able to be finalized."]
[null,"1.1.5","System shall support rich text for open-ended clinical content","This should include the ability to create line breaks in notes"]
[null,"1.1.6","System shall support integrated spell check with autocorrect functionality"]
[null,"1.1.7","Spell check dictionary should include clinical/medical spelling and allow customization by user and/or administrator."]
[null,"1.1.8","Users should be able to enable/disable autocorrect","For integrated spellcheck solutions, there should be either system or individual user settings to specify whether or not spell check can autocorrect entries"]
[null,"1.1.9","System shall allow individual users to add and remove words to their dictionary without impacting the system dictionary used for spell check."]
[null,"1.1.10","System shall support integrated grammar check with autocorrect functionality"]
[null,"1.1.11","System shall support copying and pasting between the EHR and other applications and/or web pages.","There are instances where the  Center is required to enter data from the agency's EHR into another external system.  Additionally, there may be times where data needs to be copied from an external document into the EHR or between forms in the EHR where copy forward functionality would not be useable. "]
[null,"1.1.12","System shall have an on screen client header that identifies the client whose information is being accessed","On screen Header shall include both the name and ID#. The on screen header shall include basic data that is commonly accessed so that staff don't have to exit clinical document to search for information on the client. "]
[null,"1.1.13","System shall provide a means to track user to-dos ","The need is for a list of items that need to be taken care of by staff.  For example, these could include upcoming/overdue assessments, plans coming due/overdue, documents missing signatures, etc."]
[null,"1.1.14","System shall remove to-dos from user to-do list whether they are completed through the to-do list or directly in the system","Removing a to-do from the user's task list should not be a manual process, regardless of how the requirement is satisfied - for example, if there is a to-do for a draft clinical document and that document is finalized, that task should no longer show as outstanding."]
[null,"1.1.15","System shall allow for customizable sets of to-dos for different users","Different staff will have the need for different to-dos - for example, staff providing IDD services may have different tasks than staff providing BH services or a case manager may have different tasks than a supervisor"]
[null,"1.1.16","System shall take user directly from to-do item into the correct document/page in the client's chart","There shall be a link in the document to edit/add/update the item in question"]
[null,"1.1.17","System shall have the ability for supervisors to review the to-dos for their staff","The need is for supervisors to be able to see totals for their teams and drill down to information at the individual level"]
[null,"1.1.18","System shall track to-dos along with client","If client is assigned to different staff, then the to-dos need to follow or be able to be transferred to the new staff"]
[null,"1.1.19","System shall allow users to print clinical documents from the same screen where they view the document","The system shall allow staff to print clinical documents from the document screen instead of having to go to a separate area for printing"]
[null,"1.1.20","System shall allow multiple staff to access the same chart at the same time","There are some times when staff at multiple locations could be accessing a single client chart (scheduling, documenting, etc) and need the ability to do this simultaneously"]
[null,"1.1.21","System shall alert users if form is currently in use or being edited by another user"]
[null,"1.1.22","System shall support dual monitors"]
[null,"1.1.23","System shall support dual session login","For this purpose, dual session login refers to the user's ability to open an additional instance of the system without causing an error. The previous session would close saving changes"]
[null,"1.1.24","System shall allow a user to simultaneously access multiple documents for the same client within a single session","Certain work will be more efficient if user can view more than one document at a time"]
[null,"1.1.25","System shall highlight required fields on all documents","This could be asterisk, color coding, etc."]
[null,"1.1.26","System shall permit Center For Life Resources to define which fields are mandatory"]
[null,"1.1.27","System shall have ability for conditionally requiring or enabling fields","Mandatory fields shall be able to change based on factors such as funding source, program, a value in another field on the form, etc"]
[null,"1.1.28","System shall prevent user from creating out-of-sequence and duplicate documentation","For example, don't start a treatment plan before a comprehensive assessment has been signed. Don't allow service date before diagnosis date. Alert if document is dated for previous year."]
[null,"1.1.29","System shall have conditional logic for preventing out-of-sequence and duplicate documentation","Center for Life Resources should have control over when a user is prevented from creating a new client or an out-of-sequence document and when user is given warning of possible error"]
[null,"1.1.30","System shall have logic to alert/prevent time entry errors","System shall warn user if documentation for service violates specific parameters, such as it is longer than 13 hours or outside of business hours. "]
[null,"1.1.31","System shall support semi-auto-fill for service time and date","The system should support accuracy and ease of entry for date and time fields, including a built in calendar to select dates from and converting values entered into standard date/time format."]
[null,"1.1.32","System shall prevent future dating as defined by agency","There may be instances in which future dating is allowable, the Center should be able to define those conditions."]
[null,"1.1.33","System shall have the ability to track the amount of time taken to complete a specific task in the system","An internal timer to support efforts to conduct time studies related to task performance within the EHR "]
[null,"1.1.34","System shall provide a means to track internal meetings including documenting supervision events and team meeting notes separate from the medical record","System shall support tracking team meetings and clinical supervision of staff members including resident physicians, medical and nursing students and clinical psychology/social work interns and staff separate from the official medical record"]
[null,"1.1.35","System shall have the ability to send alerts/notifications","This shall include alerts triggered based on agency defined criteria or manually created"]
[null,"1.1.36","System shall maintain history of alerts and notifications sent","This should be reportable or accessible in the user interface"]
[null,"1.1.37","System shall have the ability to display links to regularly used external web resources","This could include state sites used to enroll clients, insurance verification websites, provider resources, etc."]
[null,"1.1.38","System shall support information pulling forward from previous documentation as defined by Center for Life Resources"]
[null,"1.1.39","System shall support expanding text boxes for narrative fields"]
[null,1.2,"Administrative Areas"]
[null,"1.2.1","Incident reporting (IR)"]
[null,"1.2.1.1","System shall have the ability to CRUD incident reports (IR)","This refers to unusual incidents such as medication errors, etc."]
[null,"1.2.1.2","System shall have the ability to automatically notify staff/staff groupings when an IR is created","Possibly use email and other messaging to notify staff "]
[null,"1.2.1.3","System shall have the ability to track IR's based on the type of incident"]
[null,"1.2.1.4","System shall have ability to generate reports of these incidents in specific format for specific requirements","Information should be able to be put into a custom format for ease of entry into external systems."]
[null,"1.2.1.5","System shall have the ability to track use of seclusion and restraints","Including date, type of containment, how much time, whether or not injured, how many contaminants per month"]
[null,"1.2.1.6","System shall have the ability to track death of a client","This requires a different time frame from other incidents. Must be able to report whether or not client passed away onsite. Should be able to document to-do to obtain death certifcate"]
[null,"1.2.1.7","System shall have the ability to document injuries on a Body Sheet","An outline that allows for an inventory of bodily injuries"]
[null,"1.2.1.8","System shall have ability to direct documents to staff for necessary signatures","Once an IR has been completed, the associated staff need to be notified electronically that an electronic signature is needed"]
[null,"1.2.1.9","System shall store IR's and data outside of the client record ","Report should open with auto-populated demographic information, but final report exists outside of the medical record"]
[null,"1.2.1.10","System shall have ability for Compliance/Quality staff to be able to record follow up on incidents","When the Compliance/Quality staff reviews an incident report, they shall be able to record the outcome and any necessary next steps"]
[null,"1.2.1.11","System shall support reporting on incident reports that are pending finalization"]
[null,"1.2.1.12","System shall support workflow requiring incident reports to be responded to within certain time frame"]
[null,"1.2.2","Chart Review"]
[null,"1.2.2.1","System shall have the ability to CRUD a clinical chart review","These are the reviews that are done on client charts to maintain quality of documentation. Data from the reviews needs to be separate from the medical record"]
[null,"1.2.2.2","System shall have the ability to trigger a chart review based on enrollment date and review frequency"]
[null,"1.2.2.3","System shall have the ability to randomly select a client record to be reviewed"]
[null,"1.2.2.4","System shall have the ability to exclude previously reviewed records based on a defined data range."]
[null,"1.2.2.5","System shall have the ability to filter out specific records by criteria (i.e. program, clients with no encounter in the past month, etc.)"]
[null,"1.2.2.6","The chart review documentation and notes shall be maintained outside of the formal clinical record."]
[null,"1.2.2.7","System shall support the ability to configure a questionnaire for use by the staff completing the chart review"]
[null,"1.2.2.8","System shall include reporting to allow monitoring of the chart review process by Compliance/Quality staff (number of chart reviews completed, outstanding and overdue, results, etc.)"]
[null,"1.2.3","Release of Information/ Disclosures"]
[null,"1.2.3.1","System shall have the ability to track all records requested and released by keeping required HIPAA disclosure log","Where, to whom, when. Shall include status of request, what has been done and by whom, method of release and confirmation of receipt"]
[null,"1.2.3.2","System shall be able to electronically capture the client's authorization (and/or client's representatives) to release information","Ideally this would be done with a fully electronic document."]
[null,"1.2.3.3","System shall support tracking of structured values for releases of information that are captured on paper","Need ability to have client sign a paper document that is scanned in later if client is not able to come to office. End dates, restrictions, type, and other structured values included on the release should be able to be entered so that releases captured on paper and those captured electronically can be reported on in the same way"]
[null,"1.2.3.4","System shall have the ability to choose files within the client record to disclose based on file type / date range / specific files","Ex: Print all clinical notes from 1/1/17 to 1/1/18.  Files shall be pulled together into a batch for output into an electronic format (pdf) Released information is retained in the clinical record."]
[null,"1.2.3.5","System shall allow the Release of Information to determine what is eligible for disclosure. Only approved information on the ROI can be released","Staff/client completing ROI should be able to electronically indicate which types of information they are releasing"]
[null,"1.2.3.6","System shall support exclusion of information not authorized to release in the ROI","For example, if the ROI indicates that substance use or HIV status cannot be released, but other information such as mental or physical health services can."]
[null,"1.2.3.7","System shall have the ability to print a disclosure packet","System should allow users to print them all together for release,"]
[null,"1.2.3.8","System shall have the ability to include a redacted version of the disclosure packet","If there are parts of a document that cannot be released, the system should support redacting that information and tracking what was actually disclosed"]
[null,"1.2.3.9","System shall have the ability to track contact information","System should capture the information of the person or organization being released to and have the ability to include that contact information in a cover page"]
[null,"1.2.3.10","System should have the ability to send the files to the requester ","Preferably an electronic mechanism to securely fax or e-mail the files"]
[null,"1.2.3.11","System shall provide a mechanism to notify or remind staff when a release of information is about to expire","This will allow staff to proactively renew the release.  Staff shall be reminded before the release is going to expire prior to the next scheduled or likely appointment.  "]
[null,"1.2.4","Productivity Management"]
[null,"1.2.4.1","System shall support assignment of productivity targets for hours, rates, revenue, and lag time","Tracked monthly, quarterly, and annually. Currently use national standard for billable hours and divide by 12, with option to adjust for vacations, sick days, holidays"]
[null,"1.2.4.2","System shall provide productivity reports comparing actual revenue, hours, and lag time to productivity targets"]
[null,"1.2.4.3","System shall support user defined productivity calculations"]
[null,"1.2.4.4","System shall provide the ability to calculate productivity by program and team based on staff information and targets"]
[null,"1.2.4.5","System shall allow for different productivity targets by staff role","For example, if a supervisor is expected to be .5 FTE billable but their staff is expected to be .8 FTE billable."]
[null,"1.2.4.6","System shall be capable of assigning productivity for groups and services with more than one facilitator or clinician","Need to be able to note that there is more than one staff participating (co-clinician) without billing for both"]
[null,"1.2.4.7","System shall have the ability to calculate productivity based on FTE and PTE"]
[null,"1.2.4.8","System shall allow the agency to define what services are \"counted\" toward staff (by role) productivity.","Some services are counted toward staff productivity that may not be billable services"]
[null,"1.2.5","Records Management"]
[null,"1.2.5.1","System shall have the ability to merge records of duplicate clients","System shall be able to cleanly and easily merge records into one, even if services have already been provided."]
[null,"1.2.5.2","System shall maintain reference to combined charts after merge is completed and only allow new data to be added to the successfully merged chart"]
[null,"1.2.5.3","System shall check multiple identifiers in order to prevent duplication of records","This should be a warning and not a hard stop preventing adding clients with the same name"]
[null,"1.2.5.4","System shall have the ability to move a single document or entire chart to another client record","System should allow designated Center for Life Resources staff to move records without voiding services."]
[null,"1.2.5.5","System shall have the ability to amend records/ documents as appropriate","Changes made to record need to be tracked by date and individual"]
[null,"1.2.5.6","System shall maintain original submission date for reporting","This helps to not skew reports on lag time based on update date rather than original submission"]
[null,"1.2.5.7","System shall have the capability to void documents as appropriate so that they are not part of legal medical record","Changes made to record need to be tracked by date and individual"]
[null,1.3,"Support Areas"]
[null,"1.3.1","Inquiries/Initial Referrals"]
[null,"1.3.1.1","System shall have the ability to CRUD individual contacts regardless of whether the individual becomes a formal referral and/or enrolls with the agency","When an individual contacts the agency with a general inquiry, staff shall be able to capture necessary information to track the ongoing contact and status of the individual before they are ever enrolled for services.  "]
[null,"1.3.1.2","System shall support the quick entry of such contacts with very limited information (ie anonymous callers, phone number, first name only, etc.","Staff must be able to create a call/contact record with very little information.  These contacts must be able to be documented quickly and easily while staff are take incoming calls."]
[null,"1.3.1.3","Documentation will support a brief note as well as structured values for reporting","In addition to an open narrative, each contact should have structured values to indicate elements such as disposition and type of contact."]
[null,"1.3.1.4","The system will support users having the ability to search previous contacts by elements of the limited data collected (i.e. phone number, nickname, etc.)"]
[null,"1.3.1.5","System shall allow users to link a new contact/call to previous call history with matching criteria (i.e. phone number, nickname, etc.)"]
[null,"1.3.1.6","The system shall support full duplicate name checking for contacts when the user initiates the collection of a full name (when possible).","The name checking process will link the call/contact to an existing client clinical record where one is present."]
[null,"1.3.1.7","The system shall support converting an active call/contact documentation into a full service/agency referral or intake."]
[null,"1.3.1.8","System shall have the ability to capture referral information for new Individuals referred to services from internal and external providers","Need to be able to accurately track the type of source (doctor's office, hospital, etc.), the specific organization, the potential client's demographic information,  presenting symptoms, etc."]
[null,"1.3.1.9","System shall have the ability to update referral categories and referring organizations","Center for Life Resources needs to have the ability to easily update the information about the organizations that are sending them referrals for coordination of care with community partners."]
[null,"1.3.1.10","System shall have the ability to track internal and external referrals status","If a referral is made, they need to know whether the person \"completed\" the referral"]
[null,"1.3.1.11","System shall be able to track attempts to contact individuals/clients for referrals from providers"]
[null,"1.3.1.12","System shall be able to upload and attach hard copy documentation supporting a referral to the electronic referral document","System should be able to support staff workflow regarding follow up on outstanding documents from external resources to support disability determination"]
[null,"1.3.1.13","System shall support the tracking of requirements to support program or team specific pre-enrollment workflows","System should be able to support staff workflow regarding follow up on outstanding documents from external resources to support disability determination, financial assessment, consent for treatment, etc"]
[null,"1.3.1.14","System shall have the ability to track documents sent","If documentation such as an intake packet or records request is sent (mail, fax, etc),  staff should be able to document what was sent, to whom, and when"]
[null,"1.3.1.15","System shall have the ability to report on status of documentation required/ requested from external sources for pending intakes","Prior to being assigned to a specific provider, staff may have to track that documents, such as disability verification from a primary care physician. Requirements for enrollment should be able to be tracked in the system so that a program admin can run a report to monitor pending intakes"]
[null,"1.3.1.16","System shall have the ability to support documentation of services during pre-enrollment workflow"]
[null,"1.3.1.17","System shall have the ability to support tracking required contacts during pre-enrollment workflow","For example, IDD Authority staff get audited to ensure they are making a certain number of successful contacts per week to clients on the interest (waiting) list"]
[null,"1.3.1.18","System shall have the ability to track reason if outside of required time frames for after care follow up","For hospital discharges, clients must be scheduled within 7 days. System should allow staff to note if client is scheduled outside of 7 days (client request, no appointments available, rescheduled, etc)"]
[null,"1.3.1.19","System shall have the ability to initialize individual/client referral information into the active client record","During the creation of a new active client, the information that was taken down from the referral should populate into the client record including demographics, reason for request, financial/insurance info, etc"]
[null,"1.3.1.20","System shall have the ability to document type/ mode of communication with client as a structured value  ","These could include informational call, face to face encounters, etc"]
[null,"1.3.1.22","System shall support tracking of different stages of potential clients","For example, clients are placed on an interest or waiting list,  application packet completed, clients assessed but not yet enrolled, etc."]
[null,"1.3.1.23","System should maintain separate wait lists for different services and programs"]
[null,"1.3.1.24","System shall have the ability for users to prioritize the wait list","Center for Life Resources must prioritize the waitlist based on factors including referral source, acuity, application status (eg date paperwork received), and/or funding source"]
[null,"1.3.1.25","System shall be able to track clients that are denied services after the initial inquiry","Need to be able to track all of the clients that are denied service and why that occurred (not meeting criteria, service not available, etc.)"]
[null,"1.3.1.26","System shall have the ability to search clients by alias","During an inquiry, caller may not give their legal name, but the system should be able to search them by the name provided"]
[null,"1.3.2","Initial Registration"]
[null,"1.3.2.1","System shall have the ability to CRUD new clients"]
[null,"1.3.2.2","System shall have a method to prevent creation of duplicate records","Method shall be customizable by Center - such as warning, soft stop or hard stop"]
[null,"1.3.2.3","System shall record standard demographics with a single source of truth","System shall be able to record all standard demographic information about a client.  This shall satisfy the meaningful use requirements and shall also only be maintained in one location."]
[null,"1.3.2.4","System shall have the ability to record last time demographics were checked and updated"]
[null,"1.3.2.5","System shall lock documents once they are finalized so that historical documents maintain demographic information that was accurate as of the time of documentation and not update when demographics change"]
[null,"1.3.2.6","System shall allow capture of multiple addresses","including but not limited to client residence, correspondence address and billing address"]
[null,"1.3.2.7","System shall not require an inquiry/referral in order to enroll new clients","A client should be able to be directly enrolled into the agency and/or program"]
[null,"1.3.2.8","System shall record data elements required for Federal, State, and local reporting.","There are mandatory data elements that are required to meet compliance requirements.  The system must allow adding this data elements into the registration process. "]
[null,"1.3.2.9","System shall be able to capture guardian/parent information","System shall allow for multiple guardian or legally authoized representative."]
[null,"1.3.2.10","System shall allow for the entry and tracking for legal custody of the client with associated effective dates and paperwork"]
[null,"1.3.2.11","System shall have the ability to determine mandatory registration data based on the client's program","There is a wide range of information that need to be documented on a client depending on the age and type of program that the client is being opened into"]
[null,"1.3.2.12","System shall have the ability to maintain multiple client identifiers","SSN, client ID, State ID, Medicaid ID, external system client identifiers (inmate ID number, etc)"]
[null,"1.3.2.13","System shall have the ability to track existing medical record number for clients","This will tie into state systems such as CARE as well as existing Center for Life Resources files"]
[null,"1.3.2.14","System shall have the ability to track address history "]
[null,"1.3.2.15","System shall have the ability to search for clients based on demographic info","SSN, birth date, last name, Medicaid ID, etc. "]
[null,"1.3.2.16","System shall allow for enrollment/discharge into the agency, and then into specific programs and units"]
[null,"1.3.2.17","System shall track episodes of care","Episode of care defined as client's first enrollment into any Center for Life Resources program until discharged from all Center for Life Resources programs. "]
[null,"1.3.2.18","System shall have the ability to track the primary worker/case manager by episode."]
[null,"1.3.2.19","System shall have the ability to alert staff when they have been assigned to a case","This should not be limited to primary clinician - currently IDD nurses don't always know right away when they've been assigned a case."]
[null,"1.3.2.20","System shall have the ability to track episodes/enrollments into the Center directly provided programs as well as contracted programs","The Center uses contracted service providers for some services.  The episode or enrollment history for a client should clearly show both directly provided and contracted provided services."]
[null,"1.3.2.21","System shall allow client chart to be viewed across the entire organization based on role-based security","Client should have one master record across agency. Need to allow appropriate staff to be able to see clients across the entire organization based on security"]
[null,"1.3.2.22","System shall permit users, based on role, to see all current and previous admissions to The  Center programs for client"]
[null,"1.3.2.23","System shall permit users to see all current and previous providers that have been assigned to work with client"]
[null,"1.3.2.26","System shall provide the ability to add/change client gender and maintain change history","Data shall be structured so that reports can be run for outcome tracking."]
[null,"1.3.2.27","Syste shall have the ability to track gender identities other than male/female","Values should be able to be mapped back to binary definitions for state reporting"]
[null,"1.3.2.28","System shall provide the ability to add/change client name and maintain change history","Data shall be structured so that reports can be run for outcome tracking."]
[null,"1.3.3","Scheduling"]
[null,"1.3.3.1","System shall have the ability to CRUD appointments "]
[null,"1.3.3.2","System shall allow overlapping appointments ","Allow various clinical staff (therapists, doctors, nurses, social workers) to overlap appointments with a warning that there is an overlap."]
[null,"1.3.3.3","System shall have the ability to CRUD group appointments","For group sessions, the staff shall be able to choose multiple clients for a single time slot "]
[null,"1.3.3.4","System shall provide the option of having multiple clinicians on group appointments","Groups may have multiple facilitators, each would need to be able to add to documentation for overall group and individual."]
[null,"1.3.3.5","System shall provide ability to enter attendance through group scheduling","Of the scheduled clients, mark the no-shows and late arrivals."]
[null,"1.3.3.6","System shall include basic group information as part of appointment","This shall include group name, type, etc. This shall be structured for reporting, not free text."]
[null,"1.3.3.7","System shall allow clients to be added to a group roster so that each occurrence does not have to be scheduled individually"]
[null,"1.3.3.8","System shall have the ability to CRUD recurring appointments for both individuals and groups.","The staff shall be able to define how many times the appointment occurs and whether it is weekly, monthly, day of the week, etc. "]
[null,"1.3.3.9","System shall allow for end dating recurring appointments so that each recurrence does not have to be cancelled individually"]
[null,"1.3.3.10","System shall allow staff to add available and unavailable time slots to the calendar","Staff should be able to create a schedule for when they are available and not available that can be recurring for each week"]
[null,"1.3.3.11","System shall support staff only appointments","Including travel time and supervision. May be billable or not depending on program and reason."]
[null,"1.3.3.12","System shall provide pertinent demographic and enrollment information about client when scheduling an appointment ","This should include a client header with identifying information such as name, client number, open programs, assigned staff"]
[null,"1.3.3.13","System shall allow staff to search for appointments based on client preferences","Preferred days of the week, location, primary language, etc"]
[null,"1.3.3.14","System shall provide pertinent insurance information when scheduling an appointment","Insurance verification, Medicaid status, etc"]
[null,"1.3.3.15","System shall provide patient responsibility information when scheduling an appointment","This includes current client statement balance and co-payments that will apply to service"]
[null,"1.3.3.16","System shall show all currently scheduled appointments for client when creating a new appointment","Staff shall be able to see current appointments for all Center for Life Resources programs on client calendar in order to better facilitate coordination of care"]
[null,"1.3.3.17","System shall allow external appointments to be added to the client calendar"]
[null,"1.3.3.18","System shall provide alerts/notifications for external appointments"]
[null,"1.3.3.19","System shall have the ability to show multiple staff schedules at once","Many times a client has to schedule multiple appointments with multiple clinicians and the staff need to be able to easily coordinate those times"]
[null,"1.3.3.20","System shall have the ability to show mutliple client schedules at once","For residential homes, staff need to see all appointments for residents of the home"]
[null,"1.3.3.21","System shall have the ability to show list of appointments for a client","This should include parameters such as date, provider, and program (but also be able to be run to show all)"]
[null,"1.3.3.22","System shall have the ability to show all agency appointments in a list, filtered by a specific time, range of time, location, group of providers, etc"]
[null,"1.3.3.23","System shall have the ability to allow providers to set up availability by program and location","For example, some medical providers rotate to different sites"]
[null,"1.3.3.24","System shall have the ability to record appointment status","The clinicians need to be able to mark down if the client showed or did not show for individual and group sessions.  They shall be able to mark this even after the scheduled time is over.  "]
[null,"1.3.3.25","System shall support reconciliation of appointments to documented services"]
[null,"1.3.3.26","System shall have the ability to track and report attendance, no-shows, and cancellations over time for clients"]
[null,"1.3.3.27","System shall be able to differentiate cancellations, reschedules, and no-shows for both individual and group appointments"]
[null,"1.3.3.28","System shall be able to differentiate various types of cancellations","Staff should be able to indicate type of cancellation or reschedule (ie cancelled by staff, cancelled by client, rescheduled due to staff illness, etc)"]
[null,"1.3.3.29","System shall have the ability to notify clinicians of client check-in","When the front desk staff update the record that the client has checked-in, the clinician shall be alerted in the system"]
[null,"1.3.3.30","System shall support notificaiton to nurse rather than prescriber when client checks in for a medical appointment"]
[null,"1.3.3.31","System shall have ability to direct the alert to specific or multiple staff of client check in","For example, a client who is scheduled to see a doctor may see the nurse first so alert shall go to nurse. "]
[null,"1.3.3.32","System shall display the check-in alert/notification in a prominent manner until clinician acknowledges","Alert/notification should not be hidden behind open application windows"]
[null,"1.3.3.33","System shall record client's check-in time for services"]
[null,"1.3.3.34","System shall have the ability to pre-populate a service note based on appointment details","Using the time, date, client and provider details that are already populated in the scheduled event"]
[null,"1.3.3.35","System shall not require a service note for each appointment","System shall allow Center for Life Resources to customize whether appointments such as \"No show\" or other disposition require a service note"]
[null,"1.3.3.36","System shall have ability to associate appointment on calendar with billable service"]
[null,"1.3.3.37","System shall have the ability to provide clinicians a list of appointments they have at the start of the day"]
[null,"1.3.3.38","System shall support appointment reminders","There should be a way to indicate on the appointment that someone has provided a reminder call"]
[null,"1.3.3.39","System shall have the ability to generate an appointment card or letter for the client","This would allow staff to schedule an appt. and then quickly generate a reminder card or letter for client from a template"]
[null,"1.3.3.40","System shall support automated phone, email and/or text appointment reminders to clients in primary language"]
[null,"1.3.3.41","System shall provide choice of client opt-in or client opt-out of each automated reminder","This should not be limited to removing contact information in order to keep the automated system from calling, as clinicians may need to be able to reach out to the client directly"]
[null,"1.3.3.42","System shall support scheduling of transportation to appointment","This includes pick up time, driver, and alternative phone and address to those in demographics"]
[null,"1.3.3.43","System shall be capable of limiting (hard or soft stop) scheduling to eligible clinicians based on insurance and authorization utilization","Staff's ability to schedule should be limited to eligible clinicians based on 1) insurance (based on credentials) 2) authorization (can be location, credential, or specific clinician)"]
[null,"1.3.3.44","System shall have ability to reassign clinician schedule ","In the case a clinician calls in sick or leaves the organization "]
[null,"1.3.3.45","System shall provide ability to reschedule appointments without the need to cancel and create a new one","System shall be able to track the number of times an appointment is rescheduled"]
[null,"1.3.3.46","System may have the ability to calculate Open Access wait times","This would allow staff to help clients know when to come in for Open Access"]
[null,"1.3.3.47","System shall allow clinician to change type of appointment without cancelling and rescheduling"]
[null,"1.3.3.48","System shall maintain alerts and notifications that can be seen at the time of scheduling","For example, if a client is on a Do Not Schedule list, or if they shouldn't be scheduled with certain staff"]
[null,"1.3.3.49","System shall support the capability to search for client's upcoming scheduled appointments by any user with appropriate access."]
[null,"1.3.3.50","System shall provide a means to reserve rooms for appointments"]
[null,"1.3.4","Financial Screening"]
[null,"1.3.4.1","System shall support the definition of a financial screening workflow (including steps such as income verification and creation of a client specific fee contract)","In some cases, all steps for financial screening are completed in a single encounter, in others, some steps may be completed over time."]
[null,"1.3.4.2","System shall have the ability  to record client monthly and annual income, allowed deductions an allowed adjusted income.","System shall calculate figures based on amounts entered"]
[null,"1.3.4.3","System shall allow the ability to document multiple incomes sources (employment income, welfare benefits, etc.)"]
[null,"1.3.4.4","System shall maintain effective and end dates for income sources."]
[null,"1.3.4.5","System shall support the recording of allowed deductions"]
[null,"1.3.4.6","System shall support calculation of an adjusted client income based on income reported less allowed deductions."]
[null,"1.3.4.7","System shall support the ability to recalculate adjusted income with data from late entered assessments"]
[null,"1.3.4.8","System shall have the ability to alert designated staff of a client's possible eligibility for other benefits based on family income thresholds.","i.e., alert staff that a client may be eligible for a federal entitlement program based on the income and family size reported."]
[null,"1.3.4.9","System shall maintain a history of completed financial screenings.","History should include effective and end dates, staff name who completed screening, and data entry date"]
[null,"1.3.4.10","System shall track open/incomplete financial assessments and keep them visible on the worker's to-do list."]
[null,"1.3.4.11","System shall support notifying the assigned worker that the financial assessment is outstanding based on configurable data parameters"]
[null,"1.3.4.12","System shall support notifying supervisors of outstanding financial assessments based on configurable data parameters"]
[null,"1.3.4.13","System shall support the creation of an Advanced Beneficiary Notice of Non-Coverage (ABN)."]
[null,"1.3.5","Insurance Verification"]
[null,"1.3.5.1","System shall perform electronic eligibility verification","System shall be able to verify insurance info in real time. "]
[null,"1.3.5.2","System shall allow insurance verification prior to enrollment","System shall allow staff to search for insurance status of individuals who are not yet open to Center for Life Resources by entering basic demographic information."]
[null,"1.3.5.3","System shall have ability to automatically verify insurance electronically on a regular basis","\"Regular basis\" might be daily, weekly or monthly depending on Center for Life Resources needs.  This provides a proactive understanding of whether the client is eligible before services are rendered."]
[null,"1.3.5.5","System shall support creation of insurance eligibility verifcation batches based on active program enrollment or sheduled services"]
[null,"1.3.5.6","System shall support real-time eligibility verification"]
[null,"1.3.5.7","System shall automatically update the client's benefits information with an indication of benefit status change indicated on their financial record"]
[null,"1.3.5.8","System shall have the ability to alert identified staff to lack of authorization or coverage.","If the eligibility verification check comes back and insurance has been lost, shall be able to alert designated user(s) of the change"]
[null,"1.3.5.9","For manually verified insurance, system shall timestamp the insurance verification and give a flexible reminder, as needed."]
[null,"1.3.5.10","System shall be able to scan or swipe identification and insurance cards for populating the record with the appropriate data or an image of the card."]
[null,"1.3.5.11","System shall flag clients with deductibles/ spend downs "]
[null,"1.3.5.12","System shall have the ability to notify staff (and be available in reports)when the deductible or spend down resets based on coverage"]
[null,"1.3.5.13","System will have the ability to determine eligibility for programs and services based on insurance information","Based on the type of insurance selected for the client, the system shall show only eligible services."]
[null,"1.3.6","Intake"]
[null,"1.3.6.1","System shall have ability to CRUD intake forms for different programs"]
[null,"1.3.6.2","System shall have the ability to drive the information collected in the Intake by the funding source or program that the client is in "]
[null,"1.3.6.3","System shall create sequence of work flow to guide staff through all required documentation (assessments, consent, etc.)","This shall be a configurable set of steps that guide staff through each stage of intake, assessments, etc. and provides flexibility to move throughout until finalized"]
[null,"1.3.6.4","System shall track that specific components of the intake process are complete"]
[null,"1.3.6.5","System shall have the ability to CRUD consent forms in multiple languages"]
[null,"1.3.6.6","System shall have the ability to capture electronically signed consent forms in multiple languages","Signature process should allow for multiple, staff defined signatures "]
[null,"1.3.6.7","System shall have the ability to notify staff when any consent form is about to expire (ie medication, treatment, ROI, etc)"]
[null,"1.3.6.8","System shall have the ability to capture pictures of clients","These pictures shall populate the client page so that they can easily see the picture of the client whose information they are looking at during the continuum of care. "]
[null,"1.3.6.9","System shall have the ability to manage advance directive/guardianship/conditional release information"]
[null,"1.3.6.10","System shall track that client has been given any necessary legal documentation "]
[null,"1.3.6.11","System shall be able to track family members associated with the client"]
[null,"1.3.6.12","System shall provide ability to indicate whether staff contact with family member is permitted"]
[null,"1.3.6.13","System shall have the ability to track the distribution to clients of various required notices (notice of privacy practices, client rights, voter registration information, records retention policy, etc.)"]
[null,"1.3.6.14","System shall support capturing an electronic signature from clients acknowledging acceptance of notices.","Notices to be presented in  client's primary language and allow multiple, staff defined signatures"]
[null,1.4,"Clinical Areas"]
[null,"1.4.1","General Clinical"]
[null,"1.4.1.1","System shall have the ability to assign a primary clinician for a client by treatment episode or program enrollment","The primary clinician is the person that is primarily responsible for coordinating care for the client. This may vary from program to program, so there should be the possibility of assigning a primary worker per program so that "]
[null,"1.4.1.2","System shall have the ability to transfer or modify the primary clinician for a client for a treatment episode and/or program enrollment","Within a program or single episode of care, a client may be transferred to a different clinician. The system should allow for modifying the record from the beginning of enrollment if a clinician was assigned in error or transferring to a new clinician"]
[null,"1.4.1.3","System shall track the history of clinicians assigned to a client for a treatment episode","Worker assignments should be effective dated so that a history is maintained of who was assigned to the client"]
[null,"1.4.1.4","System shall have up-to-date list of current or active diagnoses based on current DSM and ICD code sets","The system shall maintain an active and historical list of diagnoses and crosswalk to DSM V to ICD 10 specific values or groups of values as possible.\n\nMeaningful Use "]
[null,"1.4.1.5","System shall allow the entry of diagnoses received from an outside provider ","Clearly indicating who the external diagnosing provider is. For example, an IDD Authority psychologist doesn't assess CCA clients but does enter a diagnosis based on external documentation provided to support"]
[null,"1.4.1.6","System shall allow encounters to be attached to any applicable diagnosis, not just primary","Client encounters shall be attached to most appropriate diagnosis rather than just primary"]
[null,"1.4.1.7","System shall prevent clinician from selecting more than one diagnosis as primary"]
[null,"1.4.1.8","System shall have a single repository in the EHR for client diagnoses that could populate other forms and documents in the client record."]
[null,"1.4.1.9","System shall use this single repository to populate the diagnosis/diagnoses on all necessary forms and documents throughout the system","For example: on some forms, it is important to display the list of a client's active diagnoses for reference.  In other instances, the provider must be able to select the diagnosis being treated as part of a specific intervention (if not the primary diagnosis)."]
[null,"1.4.1.10","System shall pull the most recent, finalized diagnostic information into documents requiring a diagnosis"]
[null,"1.4.1.11","System shall be capable of triggering an alert upon entry of  diagnoses or event required to be reportable to outside agencies.","External agencies include but are not limited to the Centers for Disease Control and Prevention (CDC) and County/State Health departments."]
[null,"1.4.1.13","System shall have the ability to implement or integrate with clinical decision support modules ","This decision support shall help to align treatment to national standards of care based on diagnosis and/or symptoms, and will be fully defined by staff. Could use symptomology information collected during assessments. Could be used as justification for diagnosis, level of care, and/or interventions."]
[null,"1.4.1.14","System shall have the ability to implement or integrate with evidenced based screening and diagnostic tools "]
[null,"1.4.1.15","System shall send reminders to clients per client preference for preventive/ follow up care","Meaningful Use."]
[null,"1.4.1.16","System shall record how clients respond to reminders for preventative/follow up care"]
[null,"1.4.1.17","System shall have a client registry or have the ability to interface with a registry","The system shall provide registry functions to manage client outcomes and diseases with clinical reminders and notifications.\n\nMeaningful Use"]
[null,"1.4.1.18","System shall alert/prompt/notify appropriate staff (based on defined business rules) of situations related to clients and client services ","All alerts should be able to be adjusted by program as they may have different regulatory requirements that dictate the timelines"]
[null,"1.4.1.19","System shall prompt users of necessary clinical documentation that needs to be reviewed by a date","These can be different based on different programs.  For example a treatment plan may need to be reviewed every 60 days in one program and 90 days in the other.  "]
[null,"1.4.1.20","System shall prompt for appointments that have not been documented","If an appointment is not updated with whether the client showed, canceled or no showed and there is no note - notify the scheduled clinician so they know to go update the appointment with the proper status."]
[null,"1.4.1.21","System shall prompt programs that a new client is requesting services"]
[null,"1.4.1.22","System shall enforce routing requirements by service and role","For example, an intern or tech may require a supervisor to sign off on a service but not a licensed staff"]
[null,"1.4.1.23","System shall prompt providers when signatures are required ","Including non-finalized documentation and documents that have been routed to a cosigner"]
[null,"1.4.1.24","System shall prompt programs when client has been inactive for x days","System shall customize inactivity warnings so that programs can attempt to contact clients before 90 days expire.  After 90 days with no contact are expected to be closed."]
[null,"1.4.1.25","System shall prompt staff that client needs to be closed","Standard is to close after 90 days with no contact with the client, but this can be different based on program"]
[null,"1.4.1.26","System shall allow staff to enter client-related to-dos","These shall be put in by staff to assist clients in meeting goals (ie reminding case manager to assist client to apply for food stamps, to make a primary care appointment, etc)"]
[null,"1.4.1.27","System shall allow staff to assign client-related to-dos to other staff"]
[null,"1.4.1.28","System shall have an informal method to assign clinical tasks to staff. The assignment should be reportable and remain 'outside' of the official medical record"]
[null,"1.4.1.29","System shall have the ability to customize reminders/prompts/alerts/to-dos","Center for Life Resources shall be able to customize new prompts in the future whenever needed beyond those mentioned above"]
[null,"1.4.1.30","System shall allow users to enter an end date for a document that generates a reminder"]
[null,"1.4.1.31","System shall have the ability to CRUD letters to clients","The staff shall be able to create letters based on pre-defined templates or create a custom letter that is saved in the client chart.  These would include clinical, as well as financial, letters printed in the client's primary language."]
[null,"1.4.1.32","System shall trigger reminder to send letter based on predefined event","For example, staff should be notified to send letters to clients based on how long the client has been on the waiting list or when their financial information needs to be updated."]
[null,"1.4.1.33","System shall have the ability to pull predefined client information from the record into the letters","For example, service information, length of time since last contact, length of time on wait list, or primary worker assigned"]
[null,"1.4.1.34","System shall be able to track when a letter is sent ","There should be a structured date field where user can enter sent date if different from date generated within the system or scanned in"]
[null,"1.4.1.35","System shall have an internal messaging system to confidentially pass client information","This would provide secure way to notify other staff of any confidential client information to create a stronger continuum of care"]
[null,"1.4.1.36","System shall notify staff when they receive new messages"]
[null,"1.4.1.37","System shall have direct links into the client chart from within the messages"]
[null,"1.4.1.38","System shall have the ability to send a message to a single user or a group of users"]
[null,"1.4.1.39","System shall maintain staff messages separate from the client chart"]
[null,"1.4.1.40","System shall be able to utilize a dictation program to directly integrate talk to text into clinical notes","For example - Dragon Speak Medical"]
[null,"1.4.1.41","System shall support level of care tracking","Level of care (LOC) and changes to LOC should be able to be tracked and reported on. Some BH services are driven by LOC determination"]
[null,"1.4.1.42","System shall have the ability for staff to co-sign clinical documents"]
[null,"1.4.1.43","System shall restrict the ability for those who need a co-signer to be able to sign/submit notes"," So, if the user is not able to sign their own documents, the system shall enforce that a co-signature is needed.  A note shall not be considered signed until the co-signer has signed. "]
[null,"1.4.1.44","System shall determine the need for co-signature based on user profile"]
[null,"1.4.1.45","System shall require co-signature, but allow individual to choose supervisor for co-signature","System shall have option to have different supervisor co-sign if actual supervisor is not available"]
[null,"1.4.1.46","System shall display document author and co-signer on the final note"]
[null,"1.4.1.47","System shall allow document author to make edits and send notification to co-signer with edits/ comments"]
[null,"1.4.1.48","System shall have health and safety warnings","For clients with behavioral issues such as aggression, suicidal ideation, and risk of violence toward others. Also for health concerns or disabilities that staff should be aware of whenever they are in contact with client. "]
[null,"1.4.1.49","System shall be able to document drug and alcohol screening results","Data shall be structured so that reports can be run for outcome tracking."]
[null,"1.4.1.50","System shall track Mental Health Advance Directives"]
[null,"1.4.1.51","System shall restrict providers from editing date/time of clinical signature","Providers shall not be able to edit the date and time of when the clinical signature is added to a document, which can make documentation appear concurrent or within timeliness standards when it is not"]
[null,"1.4.1.52","System shall have the ability to track fidelity to treatment models","System shall track fidelity to treatment model by ensuring that proper documents are completed, that they are done on the specified time frames. Center for LIfe Resources should be able to run reports to show whether protocol and evidence-based practice are being followed."]
[null,"1.4.1.53","System shall allow users to customize the information displayed on a client's face sheet","System shall allow users to select whether to display demographic data, diagnosis, medications, scheduled services, authorizations, allergies, service plan, progress notes, assessments, and insurance coverage"]
[null,"1.4.1.54","System shall include functionality to facilitate tele psychiatry sessions. Functionality shall include automatic time stamp of sessions."]
[null,"1.4.1.55","System shall allow a keyword search for all clinical documentation","For example - staff could search for 'knife' and 'stab' prior to a given incident"]
[null,"1.4.1.56","System shall provide a means to track outreach activity","The system should provide a means to capture specific information such as prevention group activities as discreet, reportable services event when they are non-client specific or minimal identifying information is collected on participants"]
[null,"1.4.1.57","System shall support the import of clinical information/documents in a structured format (not as a scanned document)","For example, IDD Authority is required to keep track of the most recent contact which may not be Center for Life Resources so they have to manually enter it from a report out of the state system and do not have a good way to reconcile. Another example would be for residential and community programs, where it may be challenging to do concurrent documentation"]
[null,"1.4.1.58","System shall support creation of forms in languages other than English","This may include alternative versions of forms, special characters, or forms that include multiple languages"]
[null,"1.4.2","Assessments"]
[null,"1.4.2.1","System shall have the ability to conditionally require different information to be captured in an assessment","This could be based on age, reason for assessment, program enrollment, etc"]
[null,"1.4.2.2","System shall support advanced calculation logic to support user defined scored assessments","For example, a State defined assessment required for ECI calculates percent of delay but has variations in scoring based on age and certain questions that are an automatic fail"]
[null,"1.4.2.3","System shall support the configuration of decision support alerts based on the outcome/scored values of an assessment.","For example:  A risk assessment that results in a score value of over 7, High  alerts the user to create a risk management plan.  Center for Life Resources system admins should have the capability to configure these alerts"]
[null,"1.4.2.4","System shall have ability to 'copy forward' information from previous assessments as appropriate as defined by Center for Life Resources","Create a new assessment utilizing existing information from previous assessments. Center for Life Resources should have ability to define which fields pull forward."]
[null,"1.4.2.5","System shall indicate that data is pulled forward or newly authored in the existing document","Information pulled forward could be time stamped for original entry into document"]
[null,"1.4.2.6","System shall allow staff to switch between sections of the assessment without applying business rules","There shall be no prompting for required fields, etc, until the document is being signed. This will make it easier for staff to concurrently document assessments because they will be able to jump around from section to section of the assessment as topics change, and to collect the information as it comes if client doesn't follow exact flow of assessment."]
[null,"1.4.2.7","System shall pre-populate answers to questions that are repeated on multiple forms and/or assessments.","Essentially, the system shall not duplicate data.  Instead, client responses shall only be stored in one place in the system, even if it appears on multiple assessments/forms/etc, and information should be pulled forward as appropriate."]
[null,"1.4.2.8","System shall generate billing from assessment","Clinician shall not be required to copy assessment information into separate progress note to trigger billing."]
[null,"1.4.2.9","System shall accept multiple electronic signatures on assessments","Accept multiple electronic signatures, including approval by supervisor. "]
[null,"1.4.2.10","System shall have assessment of life transition goals and needs","Includes: handling finances, finding employment, education, housing, heath care, social support"]
[null,"1.4.2.11","System shall have a substance abuse assessment","Assessment must be a bio-psychosocial and use ASAM criteria decision engine to calculate Level of Care."]
[null,"1.4.2.12","System shall have medical assessment"]
[null,"1.4.2.13","System shall have nursing assessment"]
[null,"1.4.2.14","System shall have a psychiatric evaluation","Diagnositic evaluation will meet all Medicaid requirements and will follow DSM-V and ICD-10 coding."]
[null,"1.4.2.15","System shall have the AIMS assessment"]
[null,"1.4.2.16","System shall have alcohol and opiate withdrawal scales","Assessment will include the CAGE - Screening for excessive drinking and alcohol abuse and AUDIT C for the at risk drinkers."]
[null,"1.4.2.17","System shall have childhood development scales"]
[null,"1.4.2.18","System shall have risk assessment tools"]
[null,"1.4.2.19","System shall provide electronic versions of the Columbia Suicide  Severity Rating Scale (CSSRS)","C-SSRS with Safe-T Protocol"]
[null,"1.4.2.20","System shall have the Texas ANSA and CANS including ages 3-5 and ages 6 - 17.","System will connect to the web calculator for the ANSA and CANS to calculate Level of Care. The ANSA will have the following assocated scales embedded into the assessment:  Brief Bipolar Disorder Symptom Scale, 4 Item Positive and Negative Symptom Rating Scale, Quick Inventory of Depressive Symptomatology - Self-Report. Shall also include a question regarding military status, referral source, employment status, education status, housing status, children in the home, risk of placement outside of the home (CANS) and any other demographic information required by the State of Texas."]
[null,"1.4.2.21","System shall have a depression scale screening.","PHQ-9 and the MDI - Major Depressive Index"]
[null,"1.4.2.22","System will have a PTSD assessment ","PTSD Checklist - Self Report (PCL-S)"]
[null,"1.4.2.23","System will have anxiety disorder assessment","GAD-7 General Anxiety Disorder 7 and the Hamilton Anxiety Scale"]
[null,"1.4.2.24","System will have the PHQ-A Depressions screening for adolescents"]
[null,"1.4.3","Treatment Planning"]
[null,"1.4.3.1","System shall have the ability to CRUD a Treatment Plan"]
[null,"1.4.3.2","System shall have the ability to build multiple treatment plan templates based on program and regulatory requirements"]
[null,"1.4.3.3","System shall have the ability to route the Treatment Plan to staff for updates"]
[null,"1.4.3.4","System shall have the ability to route the Treatment Plan to staff for acknowledgement/ sign off"]
[null,"1.4.3.5","System shall allow providers from different programs to create separate treatment plans "]
[null,"1.4.3.6","System shall have the ability to capture transition and discharge criteria on the Treatment Plan"]
[null,"1.4.3.7","System shall have the ability to document whether or not client or their legally authorized representative has been offered a printed copy of the plan"]
[null,"1.4.3.8","System shall have the ability to define all staff that are part of the treatment of the client","Multiple can be assigned to a client within a program (ie case manager, nurse, psychiatrist, etc). A client may receive services from more than one program"]
[null,"1.4.3.9","System shall have the ability to define all participants in the treatment planning meeting","This includes client, Center staff, other members of the interdisciplinary team, collaterals, etc"]
[null,"1.4.3.10","System shall provide option for entry of client strengths as part of the treatment plan."]
[null,"1.4.3.11","System shall provide option for entry of barriers to treatment as part of the treatment plan."]
[null,"1.4.3.12","System shall have the ability to CRUD problems, goals, and objectives for the client","These are the specific goals and outcomes  that the services shall address and need to be updated frequently based on progress "]
[null,"1.4.3.14","System shall populate problems identified from comprehensive assessment as a starting point for treatment planning","This would ensure there is a direct correlation between the assessment and the treatment plan (and then ultimately, services). "]
[null,"1.4.3.15","System shall include problems associated with risk assessment data in treatment planning"]
[null,"1.4.3.16","System shall display Problem/ Goal / Objectives for a plan in a single view while CRUDing the plan","This will allow the user to make sure there is appropriate alignment from problems to goals, goals to objectives, and objectives to services - while adding them to the plan"]
[null,"1.4.3.17","System shall allow multiple Objectives, problems or Goals to be added in a single transaction","Multiple goals can be added to a single need, multiple objectives can be added to a goal, and multiple services shall be able to be added to a objective.  "]
[null,"1.4.3.18","System shall allow goals and objectives to be tied to more than one problem"]
[null,"1.4.3.19","System shall allow clients comments to be captured on a treatment plan","For example, for IDD Authority services the State requires that the Person Directed Plan  is from the perspective of the client"]
[null,"1.4.3.20","System shall allow length, frequency and duration of services to be added to the plan to address identified problems/goals/objectives","Services shall come from a configurable list tied to billing.   System shall allow providers to pick service, time/duration, frequency, and be able to write comments"]
[null,"1.4.3.21","System shall have the ability to direct the document to all staff on the Treatment Plan for their electronic signature","An electronic signature shall be obtained from all staff that will participate in treatment of that client.  "]
[null,"1.4.3.22","System shall allow Center for Life Resources to define the workflow routing for capturing all of the necessary signatures","Ability to define who signs first, second, etc.  "]
[null,"1.4.3.23","System shall allow for electronic capture of client signature on Treatment Plan","Touchscreen, signature pad or pin code.  "]
[null,"1.4.3.24","System shall allow parent/ guardian/ legally authorized representative to sign for client","If someone other than client is signing on client's behalf, the system should track who is signing and their relationship to client"]
[null,"1.4.3.25","System shall allow for electronic signature capture of family and/or collateral participants in treatment plan"]
[null,"1.4.3.26","System shall allow for printing of treatment plan from treatment planning page","This shall not be a separate report in a different part of the system.  Simply complete the plan and press the print button"]
[null,"1.4.3.27","System shall allow for reviews to the Treatment Plan whenever they are applicable","This includes mandatory reviews at certain intervals"]
[null,"1.4.3.28","System shall have ability to 'copy forward'  elements of the Treatment Plan so they can be directly reviewed"]
[null,"1.4.3.29","System shall allow system administrators to determine the content  that pulls into the review"]
[null,"1.4.3.30","System shall allow staff to indicate progress toward each Treatment Plan goals/objectives during treatment plan reviews."]
[null,"1.4.3.31","System shall allow providers to revise individual areas of treatment plan without recreating the plan","A part of the plan should be able to be revised without having to go through and review every single goal and objective in the plan"]
[null,"1.4.3.32","System shall have the ability to term goals and objectives when they are completed, keeping a historical reference to them"]
[null,"1.4.3.33","System shall provide sort/view capability for all active and inactive treatment plan elements."]
[null,"1.4.3.34","System shall allow early termination of Treatment Plan without requiring termination of each individual service/authorization separately.","Treatment Plan termination shall be done without requiring excessive clicks."]
[null,"1.4.3.35","System shall have the ability to create Program-specific treatment plans"]
[null,"1.4.3.36","System shall provide prompts/alerts/notifications related to treatment plans"]
[null,"1.4.3.37","System shall prompt providers when treatment plan is due","Customizable time frames depending on program. Prompts should go to primary case holder for that program."]
[null,"1.4.3.38","System shall notify client's providers that changes have been made in the client's treatment plan"]
[null,"1.4.3.39","System shall warn user if a service is entered that is required to be on a treatment plan and is not"]
[null,"1.4.4","Individual Service Notes"]
[null,"1.4.4.1","System shall flag services based on clinician credentials","System shall provide a warning when providers select a service that they are not credentialed to provide."]
[null,"1.4.4.2","System shall flag whether a chosen service is a service on the Treatment Plan as of date of service","Staff shall be able to see whether the service is billable while adding the service to the note so they know whether it is billable or not at the time of documenting the service. "]
[null,"1.4.4.3","System shall allow services to be documented for clients who are not currently enrolled in any team ","This allows documentation of post-services if any follow-up is needed."]
[null,"1.4.4.4","System shall detect and notify staff of conflicting Service Notes (i.e. entered for the same time for the same client) during entry of the note","This will prevent billing errors"]
[null,"1.4.4.5","System shall have different layouts for Service Notes driven by the type of service"]
[null,"1.4.4.6","System shall notify user when signing the note if there is no current Treatment Plan in effect."]
[null,"1.4.4.7","System shall display objectives from the Treatment Plan that were active on the date of service"]
[null,"1.4.4.8","System shall allow the clinician to choose the objective(s) that were worked on in the treatment session","In the Service Note, the clinician shall be able to choose the different goals and/or objectives from the Treatment Plan that they worked on in that session."]
[null,"1.4.4.9","System shall allow for reporting on the frequency of goals and objectives used in services"]
[null,"1.4.4.10","System shall allow the user to link to or launch a treatment plan update or review from a clinical note."]
[null,"1.4.4.11","System shall detect information that is missing/incorrect during entry of note","The note must be checked for critical items such as the existence of a service code, date, time, etc.  "]
[null,"1.4.4.12","System shall have the ability to create general notes for a client","These notes shall be able to be created by any staff with access to the client and shall be easily seen during scheduling, clinical appts, or financial administration of the client"]
[null,"1.4.4.13","System shall have the ability to create contact notes for a client","Depending on the situation these could be billable or non-billable and could include any interaction that a staff person has with a client face-to-face or otherwise"]
[null,"1.4.4.14","System should support pulling structured information related to service into service notes","In creating a progress note, staff should be able to pull structured event information from appointment, demographics, treatment plan etc - such as type of services, frequency, goal attainment, etc - to minimize the redundant data entry (in addition to narrative summary created by staff)"]
[null,"1.4.4.15","System shall support creation of a weekly progress note composed of information entered on a daily basis"]
[null,"1.4.4.16","System shall allow staff to correct mistakes in the service notes until they are signed","Staff can correct mistakes in time, service code, duration, date, note etc. as long as they do it before they sign the document.  "]
[null,"1.4.4.17","System shall have a chronological, filterable list view of all services for a client in a single area","Allows staff to see all historical services in chronological order"]
[null,"1.4.4.18","System shall have the ability to calculate \"lag time\"","Lag time is the time from the date of the service (as recorded on the note) to the time the requirement was signed (if amended and re-signed, it is the time to the most recent signature)."]
[null,"1.4.4.19","System shall provide prompts/alerts/notifications related to service notes","This includes notifications related to document routing, notes left in draft status, missing notes based on scheduled services, etc"]
[null,"1.4.4.20","System shall allow structured data elements within service note templates","There are certain data elements that are required to be collected by regulatory agencies. "]
[null,"1.4.4.21","System shall support documentation of progress towards goals/objectives in individual service notes"]
[null,"1.4.4.22","System shall support documentation of client satisfaction in individual service notes","This should include templated or structured values in addition to narrative in order to support ease of entry"]
[null,"1.4.5","Group Services","NOTE: Requirements for individual services apply in most cases to group services as well.  Only those requirements specific to group services are described below."]
[null,"1.4.5.1","System shall have the ability to create groups"]
[null,"1.4.5.2","System shall allow staff to identify multiple facilitators for a group note","Some groups have more than one facilitator, shall allow for more than one clinician to be listed and to provide documentation"]
[null,"1.4.5.3","System shall allow each facilitator to select which clients they will complete notes for as part of documenting the group service","Once co-facilitators are defined for a group, the system shall only allow the specific facilitators to document the clients' notes."]
[null,"1.4.5.4","Staff shall have ability to add or remove clients from the group","Staff should be able to do this within the note during a session without having to leave the note"]
[null,"1.4.5.5","System shall allow users to add non scheduled clients into scheduled group services"]
[null,"1.4.5.6","System shall track a \"group\" entity behind the scenes for reporting","This will allow Center for Life Resources to answer simple questions like \"How many groups did we do this year?\", or \"How many \"contact\" hours did a given staff have this month?\" The Center for Life Resources needs to track a variety of groups in their education and prevention programs including: demographics, program type and location separate from individual participants."]
[null,"1.4.5.7","System shall have the ability to CRUD group notes","Note: The same kinds of checks that are done for individual services around treatment plan, team, credential, etc need to be done for group services."]
[null,"1.4.5.8","System shall have the ability to create different group notes based on the type of service that is being provided"]
[null,"1.4.5.9","System shall have the ability to create a \"group note\" that populates to each client that attends the group session"]
[null,"1.4.5.10","System shall have the ability to capture individual information for each client involved in the group"]
[null,"1.4.5.11","System shall have the ability to track the status for each client in the group","Show, no show, cancel, etc."]
[null,"1.4.5.12","System shall have the ability for the clinician to choose each client's diagnosis treated during the session"]
[null,"1.4.5.13","System shall allow the staff to choose the individual client's goals and objectives from the Treatment Plan that were worked on during that session"]
[null,"1.4.5.14","System shall allow individualized notes to be entered for each attendee to the group"]
[null,"1.4.5.15","System shall pre-populate common information for each of the individualized notes in the group","All common information shall only be required once, such as group name, location, face-to-face, etc"]
[null,"1.4.5.16","System shall allow the individualized portion of the notes to be entered without navigating between client records","System shall allow completion of the individual notes from the group notes screen/form"]
[null,"1.4.5.17","System shall allow staff to edit the start and end times for each client in the group"]
[null,"1.4.5.18","System shall allow multiple start and end times for an attendee within a single group","This is required because a client may come and go from a group and there may be other services billed in those gaps.  For example, a client attends a group from 10:00-10:15 then has individual services from 10:15-10:30 and returns to the group from 10:30-11:00.  "]
[null,"1.4.5.20","System shall be able to track hours per group","Example:  For a 1 hour group with 5 people, the system should be able to track the 1 hour of service provided instead of 5 hours"]
[null,"1.4.5.21","System shall have ability to alert staff to the maximum number of participants in a group","System shall alert staff when adding additional members  once group maximum is met "]
[null,"1.4.6","Referrals/Transfers"]
[null,"1.4.6.1","System shall have the ability to CRUD referrals to internal programs or clinicians (including designated staff responsible for coordinating contracted services)"]
[null,"1.4.6.2","System shall structure the data entered for referrals to be available for reporting"]
[null,"1.4.6.3","System shall alert/notify staff that they have a referral to review"]
[null,"1.4.6.4","System shall have the ability for the receiving staff to either accept, deny or waitlist the referral"]
[null,"1.4.6.5","System shall display the status of a referral - received, accepted, waitlist, denied"]
[null,"1.4.6.6","System shall identify necessary forms that need to be completed during transfer to a different program or service area","These could include intake, admission, or release forms"]
[null,"1.4.6.7","System shall track that specific components of the referral process are complete"]
[null,"1.4.6.8","System shall be able to display referral metrics in a user's dashboard"]
[null,"1.4.6.9","System shall have the ability to create referrals for external service","These may be to physicians or other external providers outside of the agency system"]
[null,"1.4.6.11","System shall allow for the internal transfer of clients between clinicians and programs"]
[null,"1.4.6.12","System shall have the ability to generate transfer requests"]
[null,"1.4.6.13","System shall notify staff that they have a transfer request to review"]
[null,"1.4.6.14","System shall keep and be able to report a client specific history of internal and external referrals"]
[null,"1.4.6.15","System shall have the ability to CRUD a Continuity of Care Document","This document is a client health summary standard with the most relevant client information that can be sent to other health care providers.  For each transition of care or referral."]
[null,"1.4.7","Life Event Tracking"]
[null,"1.4.7.1","System shall have the ability to CRUD client life events","This would allow staff to track hospitalizations, incarcerations, changes in marital status, employment status, etc "]
[null,"1.4.7.2","System shall have the ability to alert staff based on event type","This would help staff know not to attempt to contact client if unavailable, ie not list as no-show for appt if hospitalized or incarcerated"]
[null,"1.4.7.3","System shall have the ability to flag recent life events for a client","This would allow staff to quickly identify any major events that have happened for a client when they open the client record, including milestones reached."]
[null,"1.4.7.4","System shall have the ability to to trigger workflow requirements based on life events","For example, if a hosptilzation life event is entered and client is in a residential program system should either prompt user to enter a leave of absence into bed management (or do it automatically)"]
[null,"1.4.8","Medical and Prescribing"]
[null,"1.4.8.1","System shall include a fully integrated ePrescribing module"]
[null,"1.4.8.2","System shall generate and transmit permissible prescriptions electronically (eRx)"]
[null,"1.4.8.3","System shall integrate with fax server to send prescriptions when unable to send to pharmacy with ePrescribing","Send a Fax to pharmacies that do not support ePrescribing"]
[null,"1.4.8.4","System shall support printing prescriptions when unable to transmit electronically"]
[null,"1.4.8.5","System shall be Surescripts Certified ","Surescripts certification will ensure that the system is able to electronically submit scripts to major pharmacies and via fax for smaller pharmacies.  Ideally, system will be certified in all major categories - Prescription Benefits (Eligibility/Formulary, Reporting), Medication History, Prescription Routing (Retail and Mail Order, New and Renewal)."]
[null,"1.4.8.6","System shall support direct communication of prescriptions to internal pharmacy","Currently prescriptions are not being sent electronically to the internal pharmacy because it would require a cost per prescription with Surescripts"]
[null,"1.4.8.7","System shall maintain an up-to-date listing of pharmacies with ability for users to manually add others","Staff shall have the ability to add additional pharmacies to the list as necessary.."]
[null,"1.4.8.8","System shall be able to track preferred pharmacy for a client"]
[null,"1.4.8.9","System shall be able to select alternate preferred pharmacy for each prescription"]
[null,"1.4.8.10","System shall have pharmacy search functionality that includes searching by name, zip code, city, address and phone number."]
[null,"1.4.8.11","System shall perform drug-drug interaction checks"]
[null,"1.4.8.12","System shall perform drug-allergy interaction checks"]
[null,"1.4.8.13","System shall require prescriber to acknowledge drug-drug/drug-allergy interaction alerts","This acknowledgement should be tracked in the database and be available for reporting/audits"]
[null,"1.4.8.14","System shall support drug/formulary checks"]
[null,"1.4.8.15","System shall support multiple formularies"]
[null,"1.4.8.16","System shall be capable of performing automatic cost analysis for courses of drug treatments."]
[null,"1.4.8.17","System shall have the ability to ePrescribe Schedule II, II, and IV medications (controlled substances)  within federal guidelines.","The system shall have the ability to electronically submit schedule II, II, and IV medications. "]
[null,"1.4.8.18","System shall have the ability to provide customized dosing and titration instructions for prescriptions","Detailed information about when to take medication, and how to break it up.  Example: 1/4 pill before breakfast, full pill at dinner, etc. This information shall be included for both printed and electronic prescriptions"]
[null,"1.4.8.19","System shall have the ability to search for medications by both brand and generic names","In searching for medications, the system should be able to support near matches for spelling as well as exact"]
[null,"1.4.8.20","System shall provide functionality for quick entry of frequently prescribed medications by provider/agency","This may include ability to save commonly used protocols or frequently prescribed medications"]
[null,"1.4.8.21","System shall support protocol for following up based on medication(s) prescribed","Texas Medical Board requires prescribers to get baseline then have protocol on how often to follow up based on medications"]
[null,"1.4.8.22","System shall allow nurse to enter verbal order"]
[null,"1.4.8.23","System shall be able to send notification for physician co-signature to acknowledge verbal orders"]
[null,"1.4.8.24","System shall enable physicians to approve pending prescriptions by nurses","System shall have physicians enter a password to do so"]
[null,"1.4.8.25","System shall have the ability to prescribe from mobile devices"]
[null,"1.4.8.26","System shall allow providers to make changes to prescribed medications"]
[null,"1.4.8.27","System shall allow providers to edit medication dosages for clients"]
[null,"1.4.8.28","System shall allow providers to change refill frequency","Providers may change number of refills if client is not coming in for appointments, for example. "]
[null,"1.4.8.29","System shall allow providers to discontinue refills","Discontinue medications and communicate that information to the pharmacy. "]
[null,"1.4.8.30","System shall receive messages from the pharmacy to track when prescription is filled","System should track date filled, which pharmacy, etc. for pharmacies that are able to send this information as structured data"]
[null,"1.4.8.31","System shall have the ability to re-send a prescription","If there was a problem filling a prescription for any reason, the  Center prescribers shall have the ability to be able to re-send the prescription information without having to create a new script"]
[null,"1.4.8.32","System shall accept and process refill requests","System shall have ability to accept and approve/deny refill requests"]
[null,"1.4.8.33","System shall maintain an active allergy list","This shall include both medication and general allergies. "]
[null,"1.4.8.34","System shall maintain a medication list"]
[null,"1.4.8.35","System shall maintain the medication list in chronological order","Providers shall be able to go through the medication history to see what has been prescribed and to be able to see the changes for a specific medication (i.e. dosage) over time"]
[null,"1.4.8.36","System shall be able to identify if the medication is active or inactive"]
[null,"1.4.8.37","System shall continue to show prescriptions that are out of refills on  medication list","Medications shall remain on active medication list until they are expired by the provider"]
[null,"1.4.8.38","System shall notify prescriber when prescriptions have upcoming need for refills","The Center should be able to define how long before refill is due prescriber is notified"]
[null,"1.4.8.39","System shall have the ability to track medications from external sources","System shall be able to give full medication reconciliation. This is required by Joint Commission."]
[null,"1.4.8.40","System shall allow users to view externally prescribed medications","System shall connect to exchange and retrieve medication history from community pharmacies, as well as client medication claims history from payers and pharmacy benefit managers."]
[null,"1.4.8.41","System shall have the ability to capture over-the-counter medications"]
[null,"1.4.8.42","System shall have the ability to print the med list"]
[null,"1.4.8.43","System shall provide an intuitive interface for prescribers to locate, monitor and use in clinical decisions. ","Interface should present current medication list (with past medications also accessible) prescribing data including: drug/allergy interaction list and acknowledged warnings, metabolic data, medical conditions and prescribing notes."]
[null,"1.4.8.44","System shall prevent the prescription and refill of medication(s) when medication consents are out of date."]
[null,"1.4.8.45","System shall have an override option to allow prescription in emergencies"]
[null,"1.4.8.46","System shall have the ability to require a document review when prescribing certain medication"]
[null,"1.4.8.47","System shall identify client-specific education resources and provide those resources to the client if appropriate"]
[null,"1.4.8.48","System shall have the ability to print out and email client specific education resources in client's primary language","Languages to include but not be limited to Spanish"]
[null,"1.4.8.49","System shall provide summary of care record for each transition of care or referral, or upon request"]
[null,"1.4.8.50","System shall allow prescribers to create a medical note that pulls information forward from demographics and previous visits","Included in the note shall be demographic information, diagnosis information, vitals, prescriptions, labs, etc.\nAll of the most recent information from the labs/prescription modules needs to match what is signed-off on in the note so there needs to be real-time communication between the modules."]
[null,"1.4.8.51","System shall be able to auto-populate client record/ notes with meds ordered/ changed in e-prescription system","See \"psych note\" in individual services for more details"]
[null,"1.4.8.52","System shall have an integrated E&M coding system that determines the level of visit and associated E&M code"]
[null,"1.4.8.53","System shall have medical note with narrative as well as structured options","For example, mental status exam and review of symptoms should include a text box in addition to the checkboxes"]
[null,"1.4.8.54","System shall support multiple medical note templates depending on population","For example, additional developmental information may be tracked for children that is not needed for adults"]
[null,"1.4.8.55","System shall have a electronic medication administration record (eMAR)","Meds are managed for clients throughout the day in specific programs and the eMAR modules will be needed to closely track the meds that are prescribed and administered to the clients each day"]
[null,"1.4.8.56","System shall have the ability to track medication administration and support medication monitoring","This would be the direct administration to a client or monitoring that they have taken their own meds"]
[null,"1.4.8.57","System shall maintain a log of when medication needs to be taken","Shall be able to track recurring and temporary medication schedules."]
[null,"1.4.8.58","System shall have eMAR that accurately displays times for medication to be dispensed"]
[null,"1.4.8.59","System shall have eMAR that includes PRN, over the counter and external medications and orders"]
[null,"1.4.8.60","System may utilize bar scanning technology for each administered medication"]
[null,"1.4.8.61","System shall support monitoring of side effects and health risks","Includes obesity risks, movement risks, etc. "]
[null,"1.4.8.62","System shall be able to track that medication safety/ side effects were explained to the client","Shall be able to easily show other physicians that provider has discussed med safety (side effect) with client"]
[null,"1.4.8.63","System shall be able to capture client signature to confirm med safety was conducted"]
[null,"1.4.8.64","System shall be able to track medical supply and inventory"]
[null,"1.4.8.65","System shall have ability to track daily medication count"]
[null,"1.4.8.66","System shall have an electronic medical log for samples"]
[null,"1.4.8.67","System shall provide a means to track client based inventory of medication"]
[null,"1.4.8.68","System shall provide a means for clients to affirm they received their medication"]
[null,"1.4.8.69","System shall have the ability to print out med administration instructions"]
[null,"1.4.8.70","System shall have the ability to print out med administration instructions in several languages","Languages to include but not be limited to Spanish"]
[null,"1.4.8.71","System shall allow staff to document services \"incident to\" a physician","This is for Medicare billing to allow full reimbursement for non-physician staff at physician rates. The  Center is not currently using \"incident to\" but may in the future."]
[null,"1.4.8.72","System shall allow online access to the National Drug Code Directory (NDC)."]
[null,"1.4.8.73","System shall support the tracking of most recent external medical appointments (PCP, vision, dental) and services for clients"]
[null,"1.4.8.74","System shall track the renewal dates for medical appointments based on state regulations and prompt staff of approaching dates."]
[null,"1.4.9","Orders and Vitals"]
[null,"1.4.9.1","System shall CRUD lab request forms"]
[null,"1.4.9.2","System shall incorporate clinical lab-test results into EHR as structured data.","Ideally lab information would be populated via an integration with a lab provider, otherwise shall be entered by staff manually as structured data"]
[null,"1.4.9.3","System shall include an intuitive, user customizable, lab-results entry screen linked to orders."]
[null,"1.4.9.4","System shall have the ability to allow providers to e-sign on lab results"]
[null,"1.4.9.5","System shall allow an interface with placing orders and receiving lab results"]
[null,"1.4.9.6","System shall have the ability to track injections and immunizations","Shall track both the injections that they've given and when others are coming due."]
[null,"1.4.9.7","System shall include the incorporation of immunization protocols Universal child,  Universal adult, Specific foreign travel"]
[null,"1.4.9.8","System shall track where on client the injections were administered"]
[null,"1.4.9.9","System shall have the ability to track when blood was drawn from a client to get labs"]
[null,"1.4.9.10","System shall allow providers to print multiple lab orders in a single transaction","Shall have a print page that a provider can go through and check off which lab results will be printed"]
[null,"1.4.9.11","System shall provide notifications regarding labs"]
[null,"1.4.9.12","System shall have the ability to notify staff that labs were ordered","When clients come in for an appointment, the system shall let the staff know labs were ordered on that client to improve follow-up"]
[null,"1.4.9.13","System shall notify providers of new or un-reviewed laboratory and imaging results as well as consultant's notes. "]
[null,"1.4.9.14","System shall have the ability to flag for abnormal lab results"]
[null,"1.4.9.15","System shall include configurable, visual cues to highlight abnormal metabolic results"]
[null,"1.4.9.16","System shall be able to track when a provider has reviewed lab results"]
[null,"1.4.9.17","System shall provide notifications to remind labs need to be reviewed or re-ordered"]
[null,"1.4.9.18","System shall have ability to track non-lab based orders/referrals","This could include referrals for EEGs, sleep studies, etc. "]
[null,"1.4.9.19","System shall allow nurse to enter verbal order and prompt prescriber to sign"]
[null,"1.4.9.20","System shall record and track vital signs","Including:  height, weight, pulse, blood pressure, BMI, growth charts for children"]
[null,"1.4.9.21","System shall maintain a history of each vital sign data point in the system"]
[null,"1.4.9.22","System shall be capable of graphic display and plotting of vital information"]
[null,"1.4.9.23","System shall be able to auto-populate med notes with vitals ","See \"psych note\" in individual services for more details"]
[null,"1.4.9.24","Vitals should be shared across agency regardless of program or staff recording them","For example, if vitals are taken at the crisis center they should still pull forward on the client's next visit to the medical clinic"]
[null,"1.4.9.25","System shall be able to display vitals and lab results on the same page","Prescribers should be able to view pertinent medical information on a dashboard or single document without having to click through multiple screens or tabs"]
[null,"1.4.9.26","System shall employ standard terminologies to ensure data correctness and enable consistent communication of orders and results","System shall utilize Logical Observation Identifiers Names and Codes (LOINC) - a database and universal standard for identifying medical laboratory observations"]
[null,"1.4.9.27","System shall support documentation of reason for visit (beyond service itself)","This should be able to be noted during scheduling and be able to pull into next medical note"]
[null,"1.4.10","Inpatient and Residential"]
[null,"1.4.10.1","System shall allow staff to manage bed census for inpatient and/or residential services","This shall include a view in the system off all beds and their current status"]
[null,"1.4.10.2","System shall allow staff to electronically sign to verify the bed census","Since bed days generate billing, staff should be able to verify who is in each bed daily in order to confirm the client spent the night in the home and generate charges"]
[null,"1.4.10.3","System shall have the ability to track leaves of absence","Including start/end date of leave and type of hold (furlough, hospital, vacation, etc)"]
[null,"1.4.10.4","System shall have the ability to have billing driven by length of leave","For example, for BTTC the client is still billable for the 1st 5 days of a leave of absence but is not after that (and clients are not discharged from their beds)"]
[null,"1.4.10.5","System shall be able to show a bed on hold ","System shall have the ability to put a bed on hold for a client that will be coming in for services shortly"]
[null,"1.4.10.6","System shall allow bed transfers and removals ","System shall allow client to be transferred to a different bed or removed from the bed"]
[null,"1.4.10.7","System shall track the list of upcoming admissions and discharges","Once a client has been approved for admission, the system should allow defining the future admission date.  Additionally, in the case of a planned discharge, the system should allow entry of the planned discharge date."]
[null,"1.4.10.8","System shall have the ability to keep a client from being assigned to two beds at once"]
[null,"1.4.10.9","System should maintain a wait list for beds by residential facility/provider","If no beds are available,  Center staff should be able to put the client on a wait list for the next available bed"]
[null,"1.4.10.10","System shall have the ability to track gender for bed assignments","In order to support assignments, it should be clear in the bed management view which beds are female and which are male, This should not be a fixed value assigned to the bed, it should be based on current occupants so that if there are more males than females (or vice versa) the system can accommodate fluidity in the number of male vs female beds."]
[null,"1.4.10.11","System shall provide quick access to critical information for residents","With minimal clicks to access, there should be a way for staff working in inpatient and residential programs to access a general overview whether client has medications to administer, alergies, dietary restrictions, likes and dislikes, if have seizures, etc."]
[null,"1.4.10.12","System shall track voluntary status","For Crisis Center, client may be admitted on an Emergency Detention Order (EDO) and held for up to 48 hours, so it's important to capture status and time frame"]
[null,"1.4.10.13","System shall have a white board","This includes information it would be important to see at a glance, including voluntary status and expected discharge"]
[null,"1.4.10.14","System shall support tracking of client specific menus and grocery lists"]
[null,"1.4.10.15","System shall support shift notes","This will not drive billing but should allow residential program staff to document details of shift - eg ate meals, attended to hygiene, etc"]
[null,"1.4.10.16","System shall support multiple inpaitent recovery plan templates","The Residential Unit  and Extended Observation Unit use different plans to track progress during inpatient services"]
[null,"1.4.10.17","System shall track need for recovery plan update","Recovery plan must be created within 24 hours of admission and reassessed weekly"]
[null,"1.4.10.18","System shall support client specific medical data collection sheets","Staff shall be able to track data such as blood pressure, seizure, blood sugar, menstrual cycles, exercises, bile & bowel, sleep, repositioning, etc. This informtation should be structured so that it can be pulled into notes as well\n"]
[null,"1.4.10.19","System shall be able to report when there is a bed day without the appropriate shift note(s)","When doing utilization reviews for IDD Provider Monitoring (which are done by HHS randomly), currently have to manually look through records to make sure shift notes are present as needed, spot checking randomly"]
[null,"1.4.10.20","System shall track when staff are trained on behavior or medical protocols for a specific client and when they are due for annual renewal"]
[null,"1.4.10.21","System shall support acknowledgement of client and non-client activities from previous shift","Staff sign off on house log from previous shift including summary of parent contacts, med admin, cleaning etc"]
[null,"1.4.10.22","System shall support tracking of house licensing/ safety requirements","For example, fire drills, severe weather drills, hot water assessment. This includes when they were last done and when they are due. This is tied to the home rather than an individual client chart"]
[null,"1.4.10.23","System shall support asset tracking","For residential and inpatient programs, system shall have a client property inventory and money log"]
[null,"1.4.10.24","System shall support client signature on money log"]
[null,"1.4.11","Discharge (Program and Organizational)"]
[null,"1.4.11.1","System shall require a discharge/transition plan to be completed before a discharge is completed","Need to have a discharge/transition plan in place before the discharge/transition is done. Should be able to be defined by program whether this is a requirement."]
[null,"1.4.11.2","System shall allow a transition/discharge document to contain structured data elements for reporting","Structured data elements for the transition/discharge document should include but not be limited to:  date of discharge, reason for discharge, "]
[null,"1.4.11.3","System shall have the ability to discharge client from a specific team/program and/or discharge from the agency","Since clients are participating in multiple programs, different programs shall be able to be closed while the other programs remain active. "]
[null,"1.4.11.4","System shall be able to pull client information to auto-fill closure documentation","System will pull info from comprehensive assessment, treatment plan, progress notes, info notes to fill out discharge"]
[null,"1.4.11.5","System shall have the ability to CRUD a discharge summary document","This document signals a termination of a treatment episode and shall also lead to discontinuation of treatment plans and track reasons for discharge.  This document shall contain information such as a clinical summary, current med list, discharge checklist, and the discharge suicide risk assessment.  "]
[null,"1.4.11.6","System shall have the ability to CRUD a discharge instruction document","This should be related to the discharge summary, but be able to be produced in a printer-friendly and easy to read format in order to be provided to the client"]
[null,"1.4.11.7","System shall have the ability to track that client or their legally authorized representative were informed of their fair hearing appeal rights","When a Medicaid client is discharged or denied, they must be provided with guidance regarding their rights and how to appeal the decision"]
[null,"1.4.11.8","System shall enforce discharge requirements based on program specific and agency business rules","This could be a prompt/alert/notification to users attempting to disenroll client from a program or the agency"]
[null,"1.4.11.9","System shall prompt providers to complete unsigned documentation when attempting to close client","For example, unsigned service notes"]
[null,"1.4.11.10","System shall alert staff performing an agency discharge if client still open to multiple programs","Since clients are in multiple programs, it is currently difficult for primary providers to look through client's treatment plan to ensure all other adjunct layers have been closed. Providers shall also be alerted if they are discharging client from more than one program by doing an agency discharge."]
[null,"1.4.11.11","System shall prompt all providers of teams from which the client is being discharged"]
[null,"1.4.11.12","System shall prompt provider to follow up with client after discharge at program-specific intervals","Some programs may require follow-up after discharge at pre-defined timelines"]
[null,"1.4.12","Client Access to their records"]
[null,"1.4.12.1","System shall be able to provide clients with an electronic copy of their health information (including diagnostic test results, identified needs, medication lists, allergies) through a Portal within 4 days of the information being available to provider"]
[null,"1.4.12.2","System shall have the ability to generate clinical summaries for clients for each office visit","Shall be available when client leaves appointment. shall include current medication list and treatment plan."]
[null,"1.4.12.3","System shall track client requests to amend their record.","Amendment must be keep separate from the original document, but stored with the original so amendment is available to be sent on releases."]
[null,"1.4.13","Community Supports/ Supported Employment/ Day Hab"]
[null,"1.4.13.1","System shall be able to track client employment information","At minimum, this should include employer, title, wage, schedule, hours worked"]
[null,"1.4.13.2","System shall track detailed client employment including: employer, position, effective and expiration dates, rate of pay and job type (i.e. competitive/non-competitive, sheltered, etc.)"]
[null,"1.4.13.3","System shall support tracking vocational hours worked and milestones"]
[null,"1.4.13.4","System shall support tracking non-client specific employment contacts","Vocational coordinators may reach out to employers for non-client specific contacts. System should be able to maintain log of contacts that can be pulled up easily for a specific employer"]
[null,"1.4.13.5","System shall support multiple staff documenting notes on segments of same day of service","If staff need to work a partial day, two separate staff may be required to write clinical documentation for one service."]
[null,"1.4.13.6","System shall record client's check-in and check-out times"]
[null,"1.4.13.7","System shall generate daily attendance reports from client check-in","In some programs in which billing is attendance based, it is the check-in and check-out that generates the service."]
[null,"1.4.13.8","System shall have ability to import check-in and check-out information using structured format","For services in the community or programs without easy access to a computer, start and end times for attendance programs may still need to be tracked on paper and then logged into the EHR. The system should support a process of adding that information without manually entering each line"]
[null,"1.4.13.9","System shall have ability to track arrival time separate from start of billable service and/or payroll","In day programs especially, it is helpful to have check-in time in addition to service start time"]
[null,"1.4.13.10","System shall allow multiple check-ins and check-outs for a client in the same day"]
[null,"1.4.13.11","System shall allow tracking of day program absences as well as reason for an absence"]
[null,"1.4.13.12","System shall support tracking of planned and unplanned absences and reason for absence"]
[null,"1.4.14","Behavior Supports"]
[null,"1.4.14.1","System shall support documentation of behavior support plan/protocol","Including different templates for partial interval vs specific duration and frequency * See comments 1.4.14.4.1"]
[null,"1.4.14.2","System shall be able to generate a printer friendly version of behavior support plan/protocol to provide to parents","Parents are provided copy of protocol for use at home and current protocol at discharge"]
[null,"1.4.14.3","System shall support client specific behavior tracking data collection sheets"]
[null,"1.4.14.3.1","System shall support a GUI to input behavior tracking data in real time"]
[null,"1.4.14.4","System shall support input of frequency data *see 1.4.14.4.1 - TB","Including behavior, observation duration, frequency"]
[null,"1.4.14.4.1","System shall support input of multiple forms of behavioral tracking data","Including: Frequency [episode], behavior duration, percent of opportunities, latency, interval recording, permanent product, rate, time sampling, and Antecedent-Behavior-Consequence data"]
[null,"1.4.14.5","System shall support graphing behavior trends. ","See comments 1.14.5.1"]
[null,"1.4.14.5.1","Graphs must display: Vertical axis labeled with quantitative measure and horizontal axis labeled with time unit; Vertical axis length has a 2:3 ratio to the horizontal axis; Tick marks point outward; a minimal number of evenly spaced tick marks; data paths, which should be selectable and clearly visible (if used); Condition labels (text overlay to indicate phase change and conditions); and figure captions. ","Graphs must be subject to changes to both the abscissa  and ordinate. Graphical display of data must be able to generated based on daily, weekly monthly, quarterly, biannual and/or annual behavior data, as well as by which staffperson took the data. Graphs must also be able to display in linear and/or cumulative formats with phase change lines and trend lines. Graphs must support breaks in data path and customizable data series points. Graphs must be able to support text overlay.  See1.4.14.5.2 and 1.4.14.5.3 for additional requirements. "]
[null,"1.4.14.5.2","Graphs must have selectable series to analyze single behaviors, or to compare/contast selected behaviors using unique series data points."]
[null,"1.4.14.5.3","Additional Request: System shall support input of support inclusion of phase change lines and trend lines, as well as data breaks in the series path and customizable data series points"]
[null,"1.4.14.6","System shall support tracking of parent behaviors Addition: With narrative notes, as needed. ","When parents are participating in session, system should have a way for clinician to track whether or not parents are attempting and/or successful in following defined interventions, as parent behavior and client behavior need to be separately tracked, with separate trends and analsis"]
[null,"1.4.14.7","Additional Request: System shall be able to generate daily behavior notes (see comments for required components)","Must contain: Client Name, Client ID, Date of Birth, Diagnosis, Supervisor, Person Delivering Service, Colatteral Contacts,  Date of Service, Service Code, Location of Service, Narrative of Services Provided, Session Behavior Data, Signature of Person Delivering Services and the Signature of the Supervisor. (Customizable fields for additional information is a preferable, but not necessarily mandatory, inclusion)"]
[null,"1.4.14.8","Additional Request: System shall support printer-friendly documentation of treatment plans and changes to the plan as needed, with narrative analysis (text field of 10000 characters at a minimum) ","This should include the ability to incorporate mastery and failure criteria, requests for behavioral treatment unit allotment, graphs, Baseline data and treatment data in order to track and justify program modifications. In addition, it must include information contained in the comment section of 1.4.14.7)"]
[null,"1.4.14.9","Additional Request: System shall be able to generate a printer-friendly treatment progress note (progress report) with narrative analysis ","This should be able to display, in a printer-friendly format, all specified components of 1.4.14.7 and 1.4.14.8)"]
[null,"1.4.14.10","Additional Request: System shall support input of and graphical representation of Inter-Observer Agreement Data. Interobserver data MUST NOT be graphed as an aggregate of behavioral responses intra-session (ie It MUST NOT duplicate behavior data by adding both provider's data together). ","This requires the system to track two sets of data within session in order to assess the accuracy of data between staff taking the data. "]
[null,"1.4.14.11","Additional Request: System shall allow Behavioral targets to be toggled between active and inactive status, and both must be available to incorporate into treatment plan notes"]
[null,"1.4.14.12","Additional Request: System shall allow unique mastery criteria to be keyed (associated with) to each specific target behavior in behavior plans, progress reports and daily behavior notes. "]
[null,1.5,"Billing/Financial"]
[null,"1.5.1","Billing Setup"]
[null,"1.5.1.1","System shall support multiple payer reimbursement structures (fee for service, capitation, case rate, etc)","The system needs to have a Payer Company structure that lets the different payers (or payer types) to be setup in a fashion to allow different billing options for reimbursement. These options include, but are not limited to, fee for service, capitation, case rate, group billings, etc. with all appropriate co-pay, co-insurance, and deductible options."]
[null,"1.5.1.2","System shall support standard fee schedules","All possible CPT, HCPCS, or other codes shall be associated with a program and a set of rates.  Fee schedules shall be modifiable by administrative staff."]
[null,"1.5.1.3","System shall support customizable / modifiable billing rules, including ability to delete/inactivate functionality","Billing rules shall be updatable by billing staff or vendor staff. "]
[null,"1.5.1.4","System shall support separate fee schedules for individual insurance policies.","The system shall allow customizable insurance companies that have plans and fee schedules that can be associated with policies for individual clients.  "]
[null,"1.5.1.5","System shall support per-diem and enrollment based billing","Allows staff to use a \"day of service\" to drive a per diem charge"]
[null,"1.5.1.6","System shall support tracking levels of care and billing associated rates."]
[null,"1.5.1.7","System shall support client specific rates","For example, when an enhanced rate is agreed upon due to challenging behaviors. This should be accomplished without having to document as a different service for each client with an individualized rate"]
[null,"1.5.1.8","System shall support billing (setups) rates for services by time/encounter, weekly or monthly amounts"]
[null,"1.5.1.9","System shall support multiple unit definitions, including by time, days, encounters, etc."]
[null,"1.5.1.10","System shall provide rounding for fee stratification","Rules for rounding service durations and code determination for billing. Ex: Medicaid has some in 15 minutes, some per encounter, some 60 minutes"]
[null,"1.5.1.11","System shall support the definition of rates based on time/encounters."]
[null,"1.5.1.12","System shall support billing for services charged on a weekly basis","Example: scenario where the weekly case management rate has been defined and only a weekly note is required to initiate the case management charge for a week "]
[null,"1.5.1.13","System shall support billing for services billed on a monthly basis","This includes services that are rolled up into a single claim and services that are billed based on monthly enrollment regardless of number of services or attendance (such as tuition for licensed child care)"]
[null,"1.5.1.14","System shall have the ability to bill contract funders different rates based on contract","Required functionality is ability to report and invoice services per contract"]
[null,"1.5.1.15","System to support billing for injectable medications"]
[null,"1.5.1.16","The system must be updated to maintain compliance with local, state, and federal billing standards. ","System must comply with current and adapt to future local, state and federal standards"]
[null,"1.5.1.17","System shall comply with billing and claims management standards (HIPAA, EDI, ERA, NPI)","System must comply with current and adapt to future local, state and federal standards"]
[null,"1.5.1.18","System shall include an automated process to update codes as needed ","(ICD-10, SNOMED, HCPCS, CPT, Claim Adjustment Group and Reason Codes, etc.). System must handle updates as needed."]
[null,"1.5.1.19","System shall support templates for billing setup","For example, if an additional commercial insurance payer is added that mirrors an existing one that setup should be able to be copied so that the new payer setup is not completely manual"]
[null,"1.5.1.20","System shall have the ability to efficiently do mass updates on billing/rate setup","For example, if a payer changes rates or acceptable credentials. This could be an import or a process within the user interface, but user should not have to click into each rate individually to make updates"]
[null,"1.5.1.21","System shall support tracking of billing setups (i.e. contracts, rates, and rules) by effective dates.","System will maintain the history of billing setups, changes, associated dates, and user making the change."]
[null,"1.5.1.22","System shall have the ability to run a detailed report of billing setup (i.e. rates, rules, and effective dates) by payer."]
[null,"1.5.2","Client Insurance & Self Pay"]
[null,"1.5.2.1","System shall have ability to track payer/funder (insurance) for each client"]
[null,"1.5.2.2","System shall allow the tracking of multiple client insurance policies with ability to set priorities","The system shall allow clients to enter discrete insurance policies for any number of policies they have. These policies shall be tracked with effective and expiration dates and not allow overlapping policies of the same type. The priority of each policy shall be configurable and not allow overlap."]
[null,"1.5.2.3","System shall support separate fee schedules for individual insurance policies.","The system shall allow customizable insurance companies that have plans and fee schedules that can be associated with policies for individual clients.  There must be a hierarchy that allows for billing services to the correct policy with waterfall billing."]
[null,"1.5.2.4","System shall support maximum ability to pay for self-pay","The Center has an ability to pay form for general revenue (GR) services that was developed internally but has elements that are required by the state. The system must support state requirements for ability to pay calculation"]
[null,"1.5.2.5","System will support a calculation of maximum ability to pay based on household income, household size, and other relevant financial circumstances.","The factors determining the ability to pay calculation should be user defined fee schedule"]
[null,"1.5.2.6","System will support separate ability to pay calculations/fee schedules for different programs","For example, ECI has a State defined formula for a family's ability to pay that is different that behaviroal health services  maximum ability to pay for other programs. Other programs are based on percentage of service fee"]
[null,"1.5.2.7","System will support family cost sharing when multiple family members are enrolled","For example, in ECI if a sibling is also receiving services the cost of service is based on one child. Typically factor into cost share which child will be higher cost and have to know when sibling ages out so that costs can be transferred to other child"]
[null,"1.5.2.8","System shall support associating family members","This would be helpful clinically as well as for billing in ECI (since only one child can be billed at a time for family)"]
[null,"1.5.2.9","System shall support applying client liability to services until maximum ability to pay is met","Once client has met their ability to pay, subsequent services for that period should be written off"]
[null,"1.5.2.10","System will support calculation of ability to pay based on date of service and not data entry","For example, if a May date of service is added in June that needs to count towards May's ability to pay and not June's (even if May statements have already been sent)"]
[null,"1.5.2.11","System shall support assigning hardship adjustments/charity care to a specific write-off's account for tracking","Hardship fee scales may apply to future services or services already provided (based on date range)"]
[null,"1.5.2.12","System shall support the creation of a payment plan for clients and the printing of that payment plan for distribution to clients."]
[null,"1.5.2.13","System shall track the terms of the payment plan including minimum amount, frequency, etc."]
[null,"1.5.2.14","System shall track credits against payment plan","When payments is received, the amount, the current balance, next due date, and how much is overdue."]
[null,"1.5.2.15","System shall have standard reports/dashboards or notification that show the status of payment plans, clients who are late on payments, etc.","Payment plan agreements and current balances should be easily accessible when client is checking in or out"]
[null,"1.5.2.16","System shall allow tracking of client Medicaid spend down information","System shall provide policies to track spend down information, including spend down amount and required policy numbers"]
[null,"1.5.2.17","System shall check for spend downs","System shall support processes that check on a daily basis to determine when spend down eligibility has been met"]
[null,"1.5.3","Charge Capture","Funder = Payer"]
[null,"1.5.3.1","System shall have the ability to translate services into billing codes based on funder","Different funders might have different billing codes.  Need to be able to translate selected service into appropriate billing codes."]
[null,"1.5.3.2","System shall have the ability to generate one or more billing codes for the same service depending on payer rules","For example, autism services currently translate to one billing code for some payers and one for the first 30 min and another for additional time. System should support clinician being able to enter a single service and have the billing engine translate into the appropriate number and type of claim lines"]
[null,"1.5.3.3","System shall have the ability to translate services into billing codes based on the time and length of service","System shall have rules that calculate the appropriate billing codes based on the start and end times of the service documented."]
[null,"1.5.3.4","System shall have the ability to translate services into billing codes based on staff credentials","System shall have rules that calculate the appropriate billing codes based on staff credential.  Some services are the same but have different billing codes by credential "]
[null,"1.5.3.5","System shall have the ability to translate services into billing codes based on place of service","System shall have rules that calculate the appropriate billing codes based on place of service - for example, onsite and offsite"]
[null,"1.5.3.6","System shall have the ability to translate services into billing codes based on mode of service","System shall have rules that calculate the appropriate billing codes based on mode of service - for example, face to face or collateral "]
[null,"1.5.3.7","System shall have the ability to translate services into billing codes based on client presence","System shall have rules that calculate the appropriate billing codes based on whether the client was present or not "]
[null,"1.5.3.8","System shall have ability to automatically mark services as \"non-billable\" if business rules not met","Including but not limited to: service must be on treatment plan on service date, service must be authorized on service date, service must be a duplicate in the same day, duplicate services, duration too long, insurance expired\n"]
[null,"1.5.3.9","System shall additionally flag these services as held/suspended for failing to meet business rules."]
[null,"1.5.3.10","System shall include reporting of all held/suspended services by multiple parameters (client, program, payer, dates, etc.). ","Reporting should be able to include reason for held claim"]
[null,"1.5.3.11","System shall allow users with the correct permissions to override a held/suspended service.","There are times when it is appropriate to override and bill a service that failed business rules"]
[null,"1.5.3.12","System shall allow staff to mark a charge as non-billable","This allows authorized staff to override the billable/non-billable determination from the system based on judgment.  For example, if a service note is poorly written a supervisor or quality/compliance may determine that the service shall not be billed."]
[null,"1.5.3.13","System shall support charge entry separate from service documentation","For example, for contract employees that do not have access to the record"]
[null,"1.5.3.14","System shall support import of charges","For charges being generated without a service document (such as for contracted providers), users should be able to import charges rather than manual entry when there is a large volumne of services"]
[null,"1.5.4","Authorizations"]
[null,"1.5.4.1","System shall have the ability to CRUD authorizations","Only authorized staff will have this ability. Example fields include - funder, date requested, services type requested, number of units, date range, etc"]
[null,"1.5.4.2","System shall allow authorizations to be tracked for a date range","For example - services can be provided between a given start and end date"]
[null,"1.5.4.3","System shall allow authorizations to be tracked for a specified number of units","Units may be hours, days, interventions, etc"]
[null,"1.5.4.4","System shall allow authorizations to be tracked for a specified number of dollars"]
[null,"1.5.4.5","System shall allow authorizations to be tracked for a client by by funder"]
[null,"1.5.4.6","System shall allow authorizations to be tracked by division","This can be user defined or based on agency setup in system"]
[null,"1.5.4.7","System shall allow definition of the services authorized by CPT code or group of CPT codes "]
[null,"1.5.4.8","System shall allow definition of the limitations per day/week/month/year for the duration of the authorization."]
[null,"1.5.4.9","System shall have threshold alerts for authorization usage","Shall be customizable to alert appropriate personnel"]
[null,"1.5.4.10","System shall have a configurable threshold for alerts based on utilization of services against the authorized budget"]
[null,"1.5.4.11","System shall track all edits of an Authorization","Audit all the changes, the time of the change and the user who made them"]
[null,"1.5.4.12","System shall track services when payer allows certain number of units or days of services with no auths before an auth is needed","Funders may allow a limited number of services before the first authorization is sent to the funder for approval.  Essentially the service is automatically authorized for the first x units or days.  The system needs to track, alert and report on progress toward the caps on those initial authorizations in order to make a request for an authorization when the initial authorization is used."]
[null,"1.5.4.13","System shall have the ability to have multiple authorizations for the same client","For example, if multiple payers for the client, each one may require auths"]
[null,"1.5.4.14","System shall allow users to request additional units for an auth","System shall allow the ability to request additional units before an authorization has expired with supporting documentation."]
[null,"1.5.4.15","System shall allow users to request a new authorization","Once an authorization has expired, a new request must be made"]
[null,"1.5.4.16","System shall track life cycle of authorization - requested, approved, denied exhausted, etc"]
[null,"1.5.4.17","System shall support peer to peer reviews related to authorization requests","There should be a place in the system (tied directly to the authorization request) that clinicians involved in peer to peer reviews can document interaction"]
[null,"1.5.4.18","System shall support the submission of the electronic 278 authorization file to funders.","System shall allow creating a 278 file for submission to payers from the new authorization request where funders support the 278."]
[null,"1.5.4.19","System shall support the processing of the 278 response, posting authorization details to the client's record."]
[null,"1.5.4.20","System shall support a process to notify defined staff (i.e. primary worker and/or financial staff) of the authorization response when a status is updated (approved, denied, etc.)","This should be if the status is updated manually or via 278 if that functionality is being used"]
[null,"1.5.4.21","System shall process a retroactive authorization","System shall allow an authorization to be back dated to cover services previously entered and not billed \nIf the  Center finds out that an auth is approved in the past, they shall be able to enter it historically and reapply services to it."]
[null,"1.5.4.22","System shall provide real time utilization of authorizations on the client chart","Support staff, clinicians, and billing staff shall be able to easily see authorization utilization and balances when scheduling appointments, delivery treatment, and sending out bills"]
[null,"1.5.4.23","System shall provide read only access to utilization information","All staff should be able to see authorization and utilization information, but security should be able to limit those who can make changes to authorizations"]
[null,"1.5.4.24","System shall track utilization of authorized units by those provided and billed, provided and not yet billed, and those scheduled.","Staff shall be able to see the current use and planned use of authorized units to aid in effective planning of services,"]
[null,"1.5.4.25","System shall support multiple methods to view active and historical authorizations"]
[null,"1.5.4.26","System shall support displaying authorizations by provider, location, client, type of service or CPT code.","Staff should have the ability to view authorizations using one or more of the filters identified.  For example:  Viewing all authorizations active for a consumer with a particular provider"]
[null,"1.5.4.27","System shall alert/prompt/notify staff for tasks related to authorizations"]
[null,"1.5.4.28","System shall provide notifications to appropriate staff when an Authorization is about to expire","The system shall notify (at customized intervals) billing staff and clinicians that an authorization will expire"]
[null,"1.5.4.29","System shall alert/prompt/notify staff when client data is changed related to authorizations","This includes funder and services on the treatment plan"]
[null,"1.5.4.30","System shall alert/prompt/notify billing staff when an authorization is backdated","This will allow billing to identify and process retroactive authorizations for services that may not have been billed at first but can now be billed"]
[null,"1.5.4.31","System shall track the status of an auth and associated dates (e.g. not just \"approved\")","Eg New, missing documents, to be requested, requested, Approved, Denied, Discontinued, Error, etc - along with necessary dates"]
[null,"1.5.4.32","System shall be able to report on services that are missing authorization where one is required"]
[null,"1.5.5","Claims Processing"]
[null,"1.5.5.1","System shall process Modifiers ","System shall be able to add modifiers based on the type of staff performing the service, type of client, or location. System shall also allow a modifier to be added to a service at the time of capture.  This allows the system to use the same code and charge different rates based on program or payer.  Example: automatically applying the billing modifier required for same day services."]
[null,"1.5.5.2","System shall be able to customize claim forms by insurance company"]
[null,"1.5.5.3","System shall be able to bill configurable/ different 837s based on every payer that has the ability to accept the files"]
[null,"1.5.5.4","System shall support configuration of the 837 for submission to a clearinghouse, with one file containing claims for multiple payers or one file per payer","i.e. ability to configure the system to include the payer specific ID for required by clearinghouses. Center currently uses ClaimMD"]
[null,"1.5.5.5","System shall have ability to generate electronic and paper claim forms","Create paper or printed billing claim forms when they can't submit electronically"]
[null,"1.5.5.6","System shall have the ability to group billing runs by division","Each division has different requirements"]
[null,"1.5.5.7","System shall provide functionality to attach claim information for manual submission","If claim can't be submitted electronically, the system shall support ability to attach supporting documentation that is saved in the system."]
[null,"1.5.5.8","System shall be able to pull service activity information into funder specific billing forms"]
[null,"1.5.5.9","System shall have the ability to maintain billable codes by program","This is to make sure that the appropriate codes are billed for the correct services. End users need the ability to maintain this area (with appropriate permissions based on role). Could have different codes/rates for programs or payers."]
[null,"1.5.5.10","System shall have a \"comment\" section that pertains specifically to a client's billing information","A client comment section would be a consistent area for general client information that would travel around with the client no matter where they are in the system."]
[null,"1.5.5.11","System shall track staff billing information (NPI, Professional Credentials, etc.)"]
[null,"1.5.5.12","System shall have the ability to set a billing supervisor that overrides rendering provider information on the claim based on payer requirements.","Whether or not the rendering provider is overridden should be able to be configured by payer and practitioner or practitioner type so that if one payer requires the override and another does not."]
[null,"1.5.5.13","System shall have the ability to assign the correct rate and modifiers based on the actual rendering provider when the payer requires a billing supervisor to override"]
[null,"1.5.5.14","System shall be able to automatically determine current service status: Open-Billed - Paid - Adjusted - Rebilled"]
[null,"1.5.5.15","System shall support creation of multi-line claims bundled by client, date, location, onsite/offsite, service, and modifier","Claims are not one for each service, they are bundled based on these items."]
[null,"1.5.5.16","System shall support claim consolidation/roll-up/aggregation process based on business rules","\n"]
[null,"1.5.5.17","System shall automatically \"roll up\" claims for the same day, same client for certain funders","Rolls up independent of service code and provider"]
[null,"1.5.5.18","System shall support creating claim batches by payer and by date ranges."]
[null,"1.5.5.19","Services will batch based on the billing rules defined.","i.e. case rate services that are billed based on a month in service will not be available to be batched until the month has completed."]
[null,"1.5.5.20","System shall have ability to override a claim before submission and track these situations","Manually fix errors in claims, such as incorrect rates."]
[null,"1.5.5.21","System shall have the ability to aggregate codes onto the same claim","Need the ability for the system to be able to consolidate different codes into different billing codes based on payer. For example, if someone is seen at 1pm and 4pm, the system should have the option to combine those together onto the same claim when they go out on a bill. Also, the State allows combination of services for the month for 8-15 minutes - 8 different days providing 1 minute service, can roll up into 1 8 minute service"]
[null,"1.5.5.22","System shall support, during the roll-up process, validation against business/billing rules to hold/suspend claims that fail rules due to exceeding daily allowed limits or overlapping services.","System shall also check that the daily limit of units is not being violated before sending. "]
[null,"1.5.5.23","System shall support calculation of charges based on factors including number of clients participating","For example, transportation accumulates within a day. Have to figure out total number of people and total amount of time group was being transported - total time by total number of clients, regardless of length of time for each individual client\nNeed to be able to exclude from duplicates report"]
[null,"1.5.5.24","System shall be able to hold services that require another service in order to bill until both are ready to be claimed","For example, support coordination cannot be billed until there is at least one face to face contact within same month"]
[null,"1.5.5.25","System shall have the ability to combine claims for some payers and separate the same claims for other payers","Staff shall enter their notes/services the same way regardless of payer and the system shall combine or separate on the backend."]
[null,"1.5.5.26","System shall track the status of a claim as it traverses from primary to secondary, and tertiary coverage","Need to submit to primary, receive EOB and payment, submit to Secondary, receive EOB and payment.  System shall flag the claim to easily show the status."]
[null,"1.5.5.27","System shall be able to create billing exceptions and rules (Skip Logic)","Want to be able to skip a payer if they don't pay for the service and move on to the next payer"]
[null,"1.5.5.28","System shall support both automated and manual transfer liability to another payer before and after claim creation","For example, if client's financial information has changed."]
[null,"1.5.5.29","System shall create a claim for secondary or tertiary coverage after primary and/or secondary EOB is processed (waterfall billing)","Automatically bill secondary and/or tertiary coverage for remaining balance until all possible payment has been received"]
[null,"1.5.5.30","System shall be able to report on clients whose financial information has been change since affected services were claimed"]
[null,"1.5.5.31","System shall support automatic adjustments based on case rate caps","For General Revenue services that are based on a case rate, the system should automatically adjust revenue down to amount expect to receive - eg if did 5 services totalling $400, may exceed amount of services should have provided (can spend hours but cap amount they can get credit for)\n"]
[null,"1.5.6","Denial Management"]
[null,"1.5.6.1","System shall verify billing requirements before submitting.  Including but not limited to: clinical requirements (notes, Tx plans, etc.) and billing requirements (same day services, missing authorizations, etc.)","Staff shall be able to run the rules before submitting to find errors so that they can be resolved before submitting to the state.  For example, the system shall check for a diagnosis, age, valid authorization, valid treatment plan, completed notes, for proper formatting of zip codes and other common errors.  While these edits are expected to be checked upfront (see service note requirements), the check on the backend will make 100% certain there are no errors and reduce rejected claims."]
[null,"1.5.6.2","System shall have claims work queues (i.e. denied claims by reason, payer, program, etc.)","These are built in processes to work claims and to understand outstanding issues with claims submissions and rejections"]
[null,"1.5.6.3","System shall have method to assign denied claims to the responsible staff and be visible through a report and/or dashboard to revenue staff and clinical supervisor.","i.e. denials for no authorization, incorrect diagnosis, non credentialed providers"]
[null,"1.5.7","Remittance and Payment Posting"]
[null,"1.5.7.1","System shall have ability to process electronic remittance imported in standard 835 format.","Process the payments automatically when the file is imported.  Remittance needs to be processed to perform waterfall billing."]
[null,"1.5.7.2","System shall have the ability to automatically post all information accurately to claims from the 835 including status (paid, denied, etc.) amount, adjustment codes, etc."]
[null,"1.5.7.3","System shall generate a human readable report of all payments and associated data for 835s"]
[null,"1.5.7.4","System shall have ability to process electronic remittance imported in customized 835 format."]
[null,"1.5.7.5","System shall have ability to process manual remittance"]
[null,"1.5.7.6","System shall have the ability of tracking both agency and expected rates"]
[null,"1.5.7.7","System shall have the ability to track expected amount based on contracted rate while billing out gross agency rate"]
[null,"1.5.7.8","System shall allow users to post directly against a specific service or to oldest balance"]
[null,"1.5.7.9","System shall allow users to post co-pays and deposits for services that have not happened yet"]
[null,"1.5.7.10","System shall track underpayments","Although the  Center bills at gross agency rate, the system should support reporting when less than the contracted rate is received"]
[null,"1.5.7.11","System shall bill remaining balances to secondary/tertiary/etc payers","System shall notify billing staff if waterfall of payment is not possible"]
[null,"1.5.7.12","System shall allow billing to transfer a service from one payer to another","If service was incorrectly billed to one payer, the system shall provide a mechanism to move that transaction to the correct payer. (ex: Billed Medicaid, but have to bill Private Insurance first)"]
[null,"1.5.7.13","System shall be compatible with CMS 5010 standards"]
[null,"1.5.7.14","System shall be able to automatically determine Adjustments by Adj Type, Date(s), Payer and Amount."]
[null,"1.5.7.15","System shall automatically set actions for claims based on  adjustment types, payer, etc. and client's billing setup.","Example: Auto write-off of partially paid Medicaid claims, waterfall to the next payer etc."]
[null,"1.5.7.16","System shall be able to automatically determine Paid Amounts  and Payment Dates by Payer  from Cash Applications Process"]
[null,"1.5.7.17","System shall be able to map denial codes and adjustments from 835s"]
[null,"1.5.7.18","System shall be able to process refunds to clients","Required when the client or funder was overbilled, the system will allow a user to enter a refund for a client.  This will clear the outstanding balance to $0. "]
[null,"1.5.7.19","System shall be able to process reversal claims"]
[null,"1.5.7.20","System should track take backs","Tracking of insurance recoveries (paid in error, wrong DOS void, etc.) is tracked on spreadsheet as payer want to apply payments rather than refund"]
[null,"1.5.7.21","System shall have the ability to generate claims for historical services (\"back bill\") based on a date range","If a client didn't have up-to-date insurance information, authorizations, spend-down, etc when a service was provided, and therefore the insurance was not  billed, and it is later determined that the client did have insurance/authorization/etc at the time, system shall allow the service to be billed.  "]
[null,"1.5.7.22","System shall have the capability to re-bill batches of clients if no payment is received within a customizable number of days","System shall create re-bill batches if no payment is received within a specified number of days based on insurance"]
[null,"1.5.7.23","System shall have the ability to re-bill if claim was incorrectly submitted.","System shall allow a claim to be re-billed  if rejected or submitted incorrectly. "]
[null,"1.5.7.24","System shall have ability to submit voided claims as a batch","Submit voided claims for correction as a batch"]
[null,"1.5.7.25","System shall have ability to re-submit claims after they are voided","Submit repaired claims in a batch"]
[null,"1.5.7.26","System shall clearly indicate the source of/reason for the rebilled claim (i.e. rejected claim, user action, etc.)","This should be available for running of reports on voided claims"]
[null,"1.5.8","Write-offs"]
[null,"1.5.8.1","System shall have ability to \"write-off\" claims after services are terminated"]
[null,"1.5.8.2","System shall have ability to \"write-off\" balances that are under collection limit","System shall support ability to write off client self pay or balances below a specific collection threshold"]
[null,"1.5.8.3","System shall have the ability to execute auto \"write-off\" rules (i.e. self-pay/sliding fee clients, Medicaid remainders, etc.)"]
[null,"1.5.8.4","System shall have ability to auto write-off outstanding amounts that fail configured timely filing rules"]
[null,"1.5.9","Collections"]
[null,"1.5.9.1","System shall have the ability to track a client's collection status","System shall track effective and expiration dates of collections with the ability indicate the disposition of the collection. E.g. paid in full or uncollected"]
[null,"1.5.9.2","System shall have the ability to generate collection letters based on defined parameters for the type of letter (i.e. NSF, first, second, and final notice)"]
[null,"1.5.9.3","System shall include the tracking and reporting of the number of pre-collection letters sent to an individual client."]
[null,"1.5.9.4","System shall report on the amounts outstanding by most current type of notice (NSF, first, third, and final notice)."]
[null,"1.5.9.5","System shall be able to send accurate, up-to-date statements to clients including all payments applied","Once a client or insurance makes a payment, that payment shall be applied to the client/claim balance immediately allowing the client statement to reflect accurate balance."]
[null,"1.5.9.6","System shall support printing client statements as a batch or individually"]
[null,"1.5.9.7","System shall support viewing and printing a client statement real-time or a by a date range","The Center must be able to run a client statement by request with that statement reflecting all transactions for the client included up to that point."]
[null,"1.5.9.8","System shall suppress creating a client statement when the mailing address for client or guardian is deemed invalid."]
[null,"1.5.9.9","System shall support electronically sending client statements via the client portal"]
[null,"1.5.9.10","System shall support the creation of a customizable client statement (similar to an insurance EOB), allowing the addition of other data elements including a billing note.","Provide documentation to support bill. "]
[null,"1.5.9.11","System shall support dunning messages on client statements","Messages should vary based on oldest aging balances in statement"]
[null,"1.5.9.12","System shall support clear definition of where and to whom client statements should be sent","For example, if the client is residing at BTTC and the statement should be sent to the parent at home"]
[null,"1.5.9.13","System shall show reconciliation at the end of each day to show money credited/collected","This should be able to be reconciled by site"]
[null,"1.5.9.14","System shall have the ability to track \"balance forward\" on invoices","This will allow the Center to track overdue balances and display on invoices"]
[null,"1.5.9.15","System shall accept client payments","This may be money that is owed from previous services or co-pays for that day's upcoming service.  System shall be able to enter client payments to go against the balance as a manual entry "]
[null,"1.5.9.16","System shall support tracking of payment location (i.e. phone payment, window payment, mail payment, etc.)"]
[null,"1.5.9.17","System shall associate client payment with provider team, and staff who collected the payment."]
[null,"1.5.9.18","System shall have the ability to process payments by credit card"]
[null,"1.5.9.19","System should record co-payments to client's account at the point of service","Currently, collected co-pays are unapplied until Accounting receives and posts."]
[null,"1.5.9.20","System should have the ability to write off co-pays for services by contracted providers","Contracted providers are responsible for billing and collecting self-pay"]
[null,"1.5.9.21","System shall support reversal of payments where the originating check has been returned as NSF"]
[null,"1.5.9.22","System shall automatically apply a new NSF charge to the client's account when this occurs."]
[null,"1.5.9.23","System shall track balance of the client's account","An accurate balance requires payments to be processed quickly and services to be added to account quickly and enables the payment request before the service is documented.  "]
[null,"1.5.9.24","System shall track client's billing status and recent contact dates"]
[null,"1.5.9.25","System shall have the ability to print payment receipts"]
[null,"1.5.9.26","System shall have the ability to support HIPAA compliance emailing of receipts (i.e. emailing receipts through a secure email service to a client's email address on file)."]
[null,"1.5.9.27","System shall have the ability to capture a client's signature on the electronic financial agreement"]
[null,"1.5.9.28","System shall have the ability to flag the client record for a client that is not paying (i.e. no payment on outstanding balance in 60 days as defined by the agency)"]
[null,"1.5.9.29","Flag will be visible to front desk staff and clinicians in the client record and client appointments)"]
[null,"1.5.9.30","System shall be able to report all client payments for the day"]
[null,"1.5.9.31","System may have ability to determine co-pays based on insurance coverage and services provided","System shall determine what the client owes at the time of visit based on the type of insurance and the service that is being provided  "]
[null,"1.5.9.32","System shall support tracking and application of expected co-pay based on specific services"]
[null,"1.5.9.33","System shall prevent bills from being sent to certain types of clients","This could be done with a flag or team membership or some other mechanism."]
[null,"1.5.10","Contract and Grant Management"]
[null,"1.5.10.1","System shall have the ability to generate an invoice to funders independent of client charges","This would allow Center for Life Resources to bill fixed-fee grants out of the system where they are paid 1/12 each month, etc."]
[null,"1.5.10.2","System shall have the ability to \"write-off\" fees when a contract or grant limit has been met","For example, services to a specific grant may draw down from the grant.  Once all the funds from the grant have been consumed, there shouldn't be any revenue booked for those services.  The services shall be adjusted down so there is $0 in revenue associated with them after the grant runes out."]
[null,"1.5.10.3","System shall allow services that are not claimed to a client or insurer to be marked as sent","There are certain services that have to be entered into a State portal manually and will not be pulled into a claim file. The system should allow services that aren't able to be traditionally claimed to be marked as sent in order to track what still needs to be entered into the State portal"]
[null,1.6,"System Administration"]
[null,"1.6.1","Document/Data Administration"]
[null,"1.6.1.1","System shall allow administrators to generate Word documents based on discrete data from the database","System shall allow mail merge to clients via templates"]
[null,"1.6.1.2","System shall allow administrators to CRUD new templates/forms/documents or this will provided by "]
[null,"1.6.1.3","System shall have an integrated form builder"]
[null,"1.6.1.4","System shall allow administrators to CRUD clinical assessment forms (for use in the system)","This would allow system administrators to create and maintain any type of future assessment that is required Custom forms would include  custom documents required by insurers"]
[null,"1.6.1.5","System shall support pulling information that was already entered into system into user defined templates/forms/documents and assessments","For example, demographics, medications, diagnosis, collateral contacts"]
[null,"1.6.1.6","System shall support conditional fields/section on forms/assessments","System shall support showing or hiding specific sections or fields based on the responses to other data fields or questions. (i.e. answer yes to drug use and now must answer question on drug of choice)."]
[null,"1.6.1.7","System will allow the entry of numerical values in assessments (+,-,%) as well as support assessment scoring."]
[null,"1.6.1.8","System shall allow administrators to create and change data fields including but not limited to free text, radio buttons and pick lists","Also include check boxes and ability to configure multiple and single responses"]
[null,"1.6.1.9","System shall provide access and ability for local administrators to define and configure system hierarchy to match agency's"]
[null,"1.6.1.10","System shall allow administrator level staff to temporarily or permanently sequester client records, limiting general access to the file","Sequestering should not impact claim generation"]
[null,"1.6.1.11","System shall allow administrator level staff to define new system workflows (creating step-by-step workflows through required forms)"]
[null,"1.6.1.12","System shall allow administrator level staff to define new business rules/alerts associated with clinical forms, requirements or processes","i.e. creating alerts/business rules to schedule a treatment plan review 30 days after intake and alert staff or place the \"to-do\" on their dashboard"]
[null,"1.6.1.13","System shall allow administrator level staff to add eSignature capability (one or more staff an/or client and client representatives) to any client specific form in the system."]
[null,"1.6.2","Roster and Program Administration"]
[null,"1.6.2.1","System shall have the ability to CRUD programs","This allows system administrators to change the structure of programs as programs are added and removed.  Programs should be able to be de-activated if they are no longer in use"]
[null,"1.6.2.2","System Administrators will have the ability to associate services/events/service codes by program"]
[null,"1.6.2.3","System shall support effective dating for association between services/events/service codes and programs"]
[null,"1.6.2.4","System shall have the ability to CRUD teams","In addition to treatment teams for a specific client, system shall support definition of teams within programs. System administrators shall be able to change the structure of teams as they are modified, added, and removed.  "]
[null,"1.6.2.5","System shall have the ability to CRUD staff","This includes adding, updating, and terminating staff in system"]
[null,"1.6.2.6","System shall have the ability to maintain the programs, codes, and locations associated with a staff","This association should limit staff options for what is available to be selected and documented in"]
[null,"1.6.2.7","System shall have the ability to maintain all credentials for each staff","This shall be associated to billing as well as informational"]
[null,"1.6.2.8","System shall have the ability to have effective dates for all credentials"]
[null,"1.6.2.9","System shall have the ability to track when credentials are going to expire","This should be for reporting only, separate from effective date of billing credentials in system"]
[null,"1.6.2.10","System shall have the ability to mark a staff as terminated","When a staff person leaves the agency, in addition to cutting off access to the EHR they should also be able to be marked as inactive to be slected going forward (while still able to bill for dates prior to termination)"]
[null,"1.6.2.11","System shall have the ability to track languages spoken by staff"]
[null,"1.6.2.12","System shall have the ability to track staff specialties","To support scheduling and case assigment. For example, autism staff may specialize in feeding support or working with aggressive clients"]
[null,"1.6.2.13","System shall support secure storage of staff social security numbers with limited access to view","Currently keep full social security numbers for employees in EHR, full view for those entering it and partial view for those that can access staff maintenance screen"]
[null,1.7,"Reporting"]
[null,"1.7.1","System shall have the ability for administrators to create customized reports and data sets","Reports should be able to run based on payer sources, clients, programs, employees, services, client activity, locally configured fields or any other data point."]
[null,"1.7.2","System shall pull all reports from the same source (i.e. reporting database vs. production system, etc.) with agreement of data parameters","This ensures the accuracy of data across reports - preventing issues where a reporting database may be delayed in it's refresh of data from production, etc."]
[null,"1.7.3","System shall be able to trend data longitudinally over time based on admission dates or other parameters","Includes graphs and other  analytical representation of : vital signs, metabolic monitoring, symptoms, housing status, behaviors, etc. "]
[null,"1.7.4","Systems shall be able to export reports in various formats including Excel and CSV"]
[null,"1.7.5","System shall present report information with the capability to drill down into displayed data"]
[null,"1.7.6","System shall have the ability for staff to create reports based on core data sets","This could be restricted to a small set of staff based on permissions, but shall not be restricted to only IT staff.  The idea is that administrators would create a core data set and that staff would be able to generate their custom reports from that data set by picking fields, summing/averaging/counting data, etc to make their own view of the data based on their needs."]
[null,"1.7.7","System shall have the ability to report data using configurable system dashboards","Client, staff, and supervisor dashboards that clearly display documents approaching / surpassing due dates; any pending documents, recent changes; etc."]
[null,"1.7.8","System shall show caseload counts for clinicians, teams, departments, divisions and agency on dashboard","There are different maximums for case load assignment by program, so supervisors will need to have easy access to see the caseloads for clinicians within their program in order to stay within requirements"]
[null,"1.7.9","System shall have a supervisor dashboard to see staff to-do items and other data associated with their subordinates or unit","Supervisor shall see information re: clinicians"]
[null,"1.7.10","System shall allow users to customize the information displayed on their dashboards/homepage within parameters set by administrators","System shall allow users to select whether to display caseload, diagnoses, progress notes, treatment plan, other clinical documentation, agency providers, scheduled services (for client), clinician's schedule, diagnoses, labs, continuity of care document, alerts and notifications, and secure messages received"]
[null,"1.7.11","System shall include dashboard functionality that allows the illustration of caseload data with graphical view options"," Display to be used to establish and compare trends, client progress/outcomes, and productivity using daily, weekly and monthly timeframes"]
[null,"1.7.12","System shall support record compliance reporting based on program requirements set by local administrator","For example, run a report of all clients without a face-to-face service in the past 90 days."]
[null,"1.7.13","System shall provide and/or interface with organizational data warehouse","The system shall provide a reporting solution that can become the basis of an organizational data warehouse or provide a mechanism to extract data on a regularly scheduled basis into a separate data warehouse"]
[null,"1.7.14","System shall have the ability to control access to reports based on role based security","The system shall use existing role based security structure to allow for the assignment of access to reports"]
[null,"1.7.15","System shall allow users to search for reports","If a user is not familiar with what reports are available, system should support an intuitve process for finding reports available (based on permissions)"]
[null,"1.7.16","System shall have the ability to schedule monitoring reports to run at regular intervals"]
[null,"1.7.17","System shall provide the following reports, at a minimum"]
[null,"1.7.18","Waiting List Report","Which clients are on wait list by program. Including length of time and priority"]
[null,"1.7.19","Denied/Ineligible Clients Report","Reports on the number and percent of clients who are denied for services because they do not meet criteria, have no funding, etc. Should be able to be run by service/program requested"]
[null,"1.7.20","Staff Productivity Report","Services provided based on CFLR's definition of productivity (which may vary between programs)"]
[null,"1.7.21","Staff Services Report","Event report that is able to be run for various parameters including but not limited to an individual staff, staff under a specific supervisor, or a team"]
[null,"1.7.22","Scheduled Services Report","By client, individual, team, or site"]
[null,"1.7.23","No Shows and Cancellation Report","Should be able to be run by client, program, team, clinician, etc"]
[null,"1.7.24","Scheduled services that are unresolved","Scheduled services where the date has passed and there is not change in status to define if the service occurred, the client no-showed, etc."]
[null,"1.7.25","Clinician Caseloads Report","Count of clients currently open to clinician, name of clients, etc. Should be able to be run by program, supervisor, team, etc"]
[null,"1.7.26","Suspended/Held Claims Report","System shall support reporting of all claims held or suspended based on billing edits (i.e. those claims that didn't meet clinical requirements and/or billing rules such as authorizations)"]
[null,"1.7.27","Rebilled Claims Report","Including reason for rebilling (not paid, correction, void, etc)"]
[null,"1.7.28","Write-off Report","Including reason for write-off, both internal and from payer (as applicable)"]
[null,"1.7.29","Missing Authorizations Report","Services provided with no auths"]
[null,"1.7.30","Aging Report","Aging report by funder, program, provider, etc. Aging by 0-30, 31-60, 61-90, 91-20 and 120+ days. Date parameters both by date of service and claim date"]
[null,"1.7.31","Unpaid Claims Report","Date parameters both by date of service and claim date"]
[null,"1.7.32","Unapplied Cash Report","By payer, by client, etc."]
[null,"1.7.33","Draft/Unsigned Documents Report","Documents (services, contacts, administrative, etc)  that have not been finalized, either by the clinician or if routed for signature"]
[null,"1.7.34","Client Transaction Reports","What services and treatments have the clients received while with the  Center, how many more sessions do they have left for specific services, etc."]
[null,"1.7.35","Authorization Report","Active, Expired, near expiration - with units requested, units used, units \"open\", etc"]
[null,"1.7.36","Life Event Report","An example would be listing or counting individuals incarcerated during a period, hospitalized, visiting ER,  number of days in hospital, etc."]
[null,"1.7.37","Client Payment Report","Client payment history and details by a defined timeframe, by payer, etc. "]
[null,"1.7.38","Census/Enrollment Report","For all clients enrolled in a program"]
[null,"1.7.39","Denied Claims Report","System shall be able to pull a report of any charges that were denied and the reason for denial"]
[null,"1.7.40","Unassigned Clients Report","Need to be able to run report for clients that have been opened administratively (either within a program or the agency) but not assigned to a program or provider"]
[null,"1.7.41","Inquiry/Referral Report","Including timeframes between major steps (i.e. screening to first offered intake, screening to actual intake, screening to first offered appointment and screening to first appointment)"]
[null,"1.7.42","Discharges Report","With program and date range parameters to see recent discharges"]
[null,"1.7.43","Utilization Management Report","Shall be able to identify services for high utilizers across agency programs to facilitate streamlined and strategic approach to coordination of care."]
[null,"1.7.44","Bed Utilization Report","For residential and inpatient programs using bed management"]
[null,"1.7.45","Lag Reports","Examples: Time from the start of a financial assessment to completion of the assessment, etc.), time from service provided to documentation finalized, time from service finalized to billed, etc"]
[null,"1.7.46","System shall support automated reporting for current and future national quality measures","Including Meaningful Use and MIPS and CCBHC"]
[null,"1.7.47","Unduplicated count of individuals served"]
[null,"1.7.48","Timeliness of documentation report"]
[null,"1.7.49","All reports required for justification of meeting CCBHC measures"]
[null,"1.7.50","Report of individuals by level of care"]
[null,"1.7.51","Report of individuals by diagnosis"]
[null,1.8,"Faxing/Scanning/Printing/Uploading"]
[null,"1.8.1","System shall have the ability to scan documents directly into client files with custom labels/tags","System shall be able to scan any type of paper and include it in the client's chart with custom tags for searching.  For example, this could include insurance card and ID, historical documents, non-discrete lab information, etc.  "]
[null,"1.8.2","System shall have the ability to upload documents into client files with custom labels/tags","System shall be able to upload pdf, Word, TIF and other files and include it in the client's chart with custom tags for searching.  For example, this could include Insurance Card and ID, historical documents, non discrete lab information, etc. "]
[null,"1.8.3","System shall support linking documents to relevant data in the system (i.e. pdf of a client's lab results attached to the same record where the structured lab results data is entered)"]
[null,"1.8.4","System shall track the user and date/ time stamp when uploading"]
[null,"1.8.5","System shall implement an incoming/outgoing fax server","Faxes sent directly from the system without printing and faxing.  Would be helpful for sending clinical documentation to external agencies. Shall include option to have disclaimers on the fax screen to remind staff to verify releases before sending."]
[null,"1.8.6","System shall accept incoming faxes as a scanned document using TIFF and PDF formats, and allow user to store appropriately","Shall be able to store in an internal database or an external storage device"]
[null,"1.8.7","System shall have a send/receive log for all incoming or outgoing faxes"]
[null,"1.8.8","System shall have the ability to capture discrete structured data from faxes and scanned documents","This could include lab data or any other discrete data that would need to be reviewed or reported on"]
[null,"1.8.9","System shall allow user to search for scanned/uploaded documents","System should allow users to filter scanned/uploaded documents by type and search for keywords in custom tags"]
[null,"1.8.10","System shall have the ability to show scanned and system created documents in one list "]
[null,"1.8.11","System shall allow agency to determine how credentials are displayed on printed documents"]
[null,1.9,"Help"]
[null,"1.9.1","System shall provide context sensitive help at the screen level ","This will provide users help content for the screen they are currently viewing "]
[null,"1.9.2","System shall have the ability to include field level help "]
[null,"1.9.3","System shall have tutorials and users guides that can be annotated to show specific instructions and workflows.","This should be configurable so that content can be added for support for custom forms and reports, etc."]
[null,"1.10","Client Portal"]
[null,"1.10.1","System shall have the ability for a client and/or guardian to view clinical and demographic information"]
[null,"1.10.2","System shall have the ability to limit clinical documentation to those documents that the Center deems appropriate for the client portal"]
[null,"1.10.3","System shall provide local administrator the ability to control configuration of client information and access within client portal"]
[null,"1.10.4","System shall have the ability for client and/or guardian to request appointments, cancellations and rescheduling via client portal"]
[null,"1.10.5","System shall allow clients to recieve alerts and notifications related to chart updates, upcoming appointments and test results."]
[null,"1.10.6","System shall allow system administrators to determine the content available in the client portal"]
[null,"1.10.7","System shall allow client to enter demographic, financial, and historical information via client portal","Including insurance, treatment history, medications, surgical, social, etc"]
[null,"1.10.8","System shall support online medication refill requests via client portal"]
[null,"1.10.9","System shall have the ability to allow clients to review accounts and pay bills ","Allow clients to make payments online"]
[null,"1.10.10","System shall be able to capture assessments or screenings that become part of the EHR data set"]
[null,"1.10.11","System shall have the ability to support secure messaging with client or guardian via the client portal"]
[null,"2.0","Interfaces"]
[null,2.1,"Data Exchange - (See Below as well as Interfaces tab)"]
[null,"2.1.1","System shall allow for future integrations using inbound web service calls using secured bi-directional communications reconciliation","This is the ability to interface with the system via web services. This means that the system shall expose core business functions that can be called via Web Services by external programs.  "]
[null,"2.1.2","System shall have the ability to make Web Service calls to other systems using secured bi-directional communications reconciliation","The system shall have the ability to call other systems via web services and incorporate the retrieved data into the system"]
[null,"2.1.3","System shall have ODBC connectivity"]
[null,"2.1.4","System shall interface with online content libraries","Access through EHR to online content libraries such as Wiley treatment plan dictionary"]
[null,"2.1.5","System shall interface with Outlook","Including appointments and reminders,"]
[null,"2.1.6","System shall support synchronization of appointment information from EHR scheduling calendar to Outlook","Data shall be stripped of PHI"]
[null,"2.1.7","System shall support synchronization of appointment information from Outlook to EHR scheduling calendar"]
[null,"2.1.8","System shall allow interface with placing orders and receiving lab results directly with individual labs and through lab networks (e.g. LabCorp)."]
[null,2.2000000000000002,"Data Migration ","Need last demographic, diagnosis, treatment plan, last assessment for Level of Care (ANSA, CANS,etc.)"]
[null,"3.0","Non-Functional"]
[null,3.1,"Performance"]
[null,"3.1.1","System shall support automatic page refreshes within 1.5 seconds on average"]
[null,"3.1.2","System shall be able to open large client records in a manner that staff experience minimum lag time"]
[null,"3.1.3","System shall have the ability to run reports and interfaces during normal on line transaction processing without throughput degradation."]
[null,"3.1.4","System shall support 50 concurrent users"]
[null,3.2,"Availability"]
[null,"3.2.1","System shall be available 99.9%","System shall be down for no more than 8 hours in a year"]
[null,"3.2.2","System shall be available within 1 hour of a complete system failure","Want to have cold spare or \"hot site\" that could be cutover within 1 hour.  "]
[null,"3.2.3","Data shall be restored to a data point no older than 1 hour","System shall be restored to a full copy of the entire database that is no older than 1 hour."]
[null,3.3,"Extensibility"]
[null,"3.3.1","System shall support the addition of new programs, locations, funding streams, etc within the context of the overall functionality contained in this matrix."]
[null,"3.3.2","System shall support the addition of new modules to support future lines of service"]
[null,"3.3.3","System shall support quality reporting standards"]
[null,3.4,"Scalability"]
[null,"3.4.1","System shall scale up to 50 concurrently signed-on users"]
[null,3.5,"Accessibility"]
[null,"3.5.1","System shall be web-based","The system shall be deployed in a manner that is accessible via a web-browser. The only requirement for client access shall be an internet connection with a web-browser."]
[null,"3.5.2","System shall be accessible through browser-independent, secure web access."]
[null,"3.5.3","System shall have test, development and training environments","No secondary SQL, application, or terminal servers should be required test and train environments"]
[null,"3.5.4","System shall have the ability to copy live information into test and training environments"]
[null,"3.5.5","System shall support touch screen data entry"]
[null,"3.5.6","System shall be available from mobile devices (including Microsoft, Apple, and Android based operating systems)"]
[null,"3.5.7","System shall have offline module for mobile documentation","When provider is in an isolated area or in a room that prevents a signal"]
[null,"3.5.8","System shall apply business rules even in offline modules ","This is so that staff don't conduct documentation offline only to find they have significant errors when they sync to the main system"]
[null,"3.5.9","System shall alert if records have been updated simultaneously while in offline mode ","Staff shall be able to determine how information shall be reconciled so that nothing is lost"]
[null,"3.5.10","System shall have ability to pre-load documentation onto encrypted device so that it can be accessed offline","Staff shall be able to carry information from system into court or community via encrypted mobile device."]
[null,"3.5.11","System shall include display options for visually and physically impaired users."]
[null,"3.5.12","System shall support industry standard electronic/digital signatures."]
[null,"3.5.13","System shall have ability to capture signatures on mobile devices without dedicated signature pads"]
[null,"3.5.14","System shall have the ability to control remote access to modules based on role based security, confidentiality and defined security procedures"]
[null,"3.5.15","System shall be capable of supporting alternative log in methods (other than passwords) to support ease of access","Such as biosensor or tap and go technology"]
[null,3.6,"Security"]
[null,"3.6.1","System shall have the ability to provide role-based security","Information other than basic demographics may require additional restrictions. System admin should be able to restrict or allow access at team, role, and individual levels."]
[null,"3.6.2","System shall have the ability to provide access to only certain clients depending on role","For example, an intake staff would need access to all clients but a house parent for a residential program would only need access to the chart for the clients in their home"]
[null,"3.6.3","System shall provide assignment of unique identifier to all staff"]
[null,"3.6.4","System shall support entry of existing staff identifiers in order to match staff to their HR profile"]
[null,"3.6.5","System shall support all current and future HIPAA and other legally mandated security requirements","Meaningful Use."]
[null,"3.6.6","System shall enforce industry standard encryption protocols for transmitting data across insecure communication channels","System shall use https:// encryption for any connections outside of secure physical connections, i.e. over the Internet"]
[null,"3.6.7","System shall provide an audit log to track access and changes to data elements by all users","Audit log refers to the user, date, time, and action (add, view, updated, delete) that was taken.  Audit log shall be accessible by users (at least administrators)."]
[null,"3.6.8","System shall provide an audit trail on data elements to keep a history of changes","Audit trail here refers to keeping historical data for a given data element.  Audit Trail shall be accessible by users (at least administrators). "]
[null,"3.6.9"," System shall be configurable to specify which data elements will have an audit trail."]
[null,"3.6.10","System shall allow a configurable user timeout for inactivity time period","For example, a system administrator shall be able to set a global user timeout to 30 minutes or 60 minutes"]
[null,"3.6.11","System shall allow a configurable password change frequency","System shall allow a system administrator to setup the frequency of when passwords must change"]
[null,"3.6.12","System shall remind users to change security password"]
[null,"3.6.13","System shall support automated reset of security password","Users should be able to submit a forgotten password request that allows them to change their password without manual intervention - for example by answering security questions or sending an email link"]
[null,"3.6.14","System shall allow a configurable lockout policy","System shall allow a system administrator to setup the number of times a user enters the incorrect password before they are locked out"]
[null,"3.6.15","System shall enforce a strong password policy","System shall enforce a password policy that shall include symbols, capital letters, and a specific length, the system shall also allow a configurable number of previous passwords that can be used"]
[null,"3.6.16","System shall have the ability to support a single sign on solution "]
[null,"3.6.17","System shall include functionality to lockout user(s) due to system security breaches, employee terminations, emergent sequestration,  etc."]
[null,"3.6.18","System shall have the capability for staff to access a record outside of their role by 'breaking the glass' in an emergency"]
[null,"3.6.19","System shall track incidents of emergency access of client records including time/date stamp of access"]
[null,"3.6.20","System shall track incidents of emergency access of client records and trigger an alert to compliance and IS staff"]
[null,3.7,"Manageability"]
[null,"3.7.1","System shall allow local IT administrators to setup users"]
[null,"3.7.3","System shall allow local IT administrators to configure/lookup code tables"]
[null,"3.7.4","System shall support version control according to customized polices to ensure maintenance of utilized standards.  ","This includes the ability to accommodate changes to terminology sets as source of terminology undergoes update processes (new codes, retired codes, redirected codes.) such changes need to be cascaded to clinical content embedded in templates, custom formularies, reports) as determined by local policy."]
[null,"3.7.5","System should ensure upward compatibility  with newer versions of the product"," configurations within the application must not be impacted by upgrades of the core application"]
[null,"3.7.6","Vendor shall identify and provide all software needed to run the system if not fully web based and browser neutral.","Includes all third-party software"]
["/"]
[]
[""]

{"sheet":"Validations","index":1,"n_rows":21,"n_cols":2,"rows_kept":21,"cut":false,"hidden":true,"merged":[]}
["P1 - Must have, essential to daily functioning","General Requirements"]
["P2 - Should have","Administrative Areas"]
["P3 - Nice to have, but not a requirement","Support Areas"]
["Remove - Not needed","Clinical Areas"]
[null,"Billing/Financial"]
[null,"System Administration"]
[null,"Reporting"]
[null,"Faxing/Scanning/Printing/Uploading"]
[null,"Help"]
[null,"Client Portal"]
[null,"Provider Portal/Contracted Provider Access"]
[null,"Data Exchange"]
[null,"Data Migration"]
[null,"Performance"]
[null,"Availability"]
[null,"Extensibility"]
[null,"Scalability"]
[null,"Accessibility"]
[null,"Security"]
[null,"Manageability"]
[null,"Other (please specify in comments)"]

{"sheet":"Data Conversion - Contracting","index":2,"n_rows":54,"n_cols":4,"rows_kept":54,"cut":false,"hidden":true,"merged":[]}
["Data","Description","Desired \nScope?","Vendor Comments"]
["Client Data"]
["Basic Demographics","Basics like ID, first name, last name, address, gender, phone number, SSN, ethnicity, language, marital status, etc","Yes"]
["Required data for funding sources","These are items that individual programs are tracking along with demographics (e.g. Client usage, military service, etc)","Yes"]
["State Reporting Data elements","Additional data elements required by the state","Yes"]
["Episode Admit/Transfer/Discharge dates","Episode history of when Clients were admitted/discharged from teams/programs/agency","Yes"]
["Enrollment History","History of teams /programs that the Client has worked with","Yes"]
["Basic Demographic history","Any previous details about Client's identity, such as changes in address","Yes"]
[]
["Business Administration Information"]
["Appointments","Scheduled appointments after Go Live","Yes"]
["Referrals","Referrals from internal and external sources","Yes"]
["Releases ","Documentation showing it is okay to release information to certain third parties","Yes"]
["Disclosures","A history of when Client information was released to third parties","Yes"]
["Groups","The template for a group including procedure, staff, members, etc","Yes"]
[]
["Financial/Billing Information"]
["Client Insurance Policies/Funders","Details about Client funding sources","Yes"]
["Charge/Adjustments/Payments History ","Previous claims data for Client (Charges,  adjustments, payments)","Yes"]
["Posting payments to claims",null,"Yes"]
["Client Balance","Any outstanding balance the Client has","Yes"]
["Authorizations",null,"Yes"]
["Payers and Payer Plans",null,"Yes"]
["Standard rates",null,"Yes"]
["Payer allowed amounts",null,"Yes"]
["Procedure Codes",null,"Yes"]
["Contracted Providers",null,"Yes"]
["Provider contracted rates/fee schedules",null,"Yes"]
["Provider authorizations (by client)",null,"Yes"]
["Procedure Modifiers",null,"Yes"]
["Diagnosis Codes (DSMV and ICD-10)",null,"Yes"]
[]
["Clinical Content"]
["Diagnosis","Client diagnosis","Yes"]
["Admit","Clinical admit documentation and planning for the Client.","Yes"]
["Transfer/Discharge documents","Clinical transfer/discharge documentation and planning for the Client","Yes"]
["Services","The list of services/procedures the Client has had in the past along with time in/time out, place of service, etc.","Yes"]
["Notes ","The service notes related to services/procedures the Client has had in the past.","Yes"]
["Assessments","Previous assessments","Yes"]
["Treatment Plans","Previous treatment plans","Yes"]
["Misc. images ","Any images in the Client's record","Yes"]
["Misc. documents","Any documents in the Client's record","Yes"]
["Allergies","Client allergies","Yes"]
["Medications","Medication data from ePrescribing software","Yes"]
["Immunizations","Immunization history","Yes"]
["Labs","Labs history","Yes"]
["Vitals","History of height, weight, etc","Yes"]
[]
["Miscellaneous"]
["Alerts","Todos/alerts from the previous system","Yes"]
["Users ","Staff profiles in the old system (including security/role assignments, program assignment, clinical supervisor, etc.)","Yes"]
["Teams/Programs etc","Details about teams and programs to group staff and Clients","Yes"]
["Scanned documents","Forms/documents that have been scanned into the County's document management system and associated to clients in the EHR","Yes"]
["Staff Certification/Billing Information",null,"Yes"]

{"sheet":"Scenarios","index":3,"n_rows":15,"n_cols":2,"rows_kept":15,"cut":false,"hidden":true,"merged":[]}
["IDD Authority","Need to track receipt of medical verification with signature from PCP"]
["IDD Authority","Calculate max ability to pay by program/service line"]
["IDD Authority","User defined forms with required values"]
["IDD Authority","Supervisor wants to see how many clients are on each clinician's caseload within a particular program for case assignment"]
["IDD Authority","A new client is added to the wait list as a referral from the state and prioritized above existing clients"]
["IDD Authority","PASARR clinicians required to assess within 72 hours of request, 4 days to enter into state portal, meeting with interdisciplinary team at 14 and 30 days, 45 days to make determination"]
["IDD Authority","Clients must receive a waiver service at least every 90 days or they become ineligible. For HCS this is services that would be tracked in EHR, for TxHL would be external"]
["Medical","Prescriptions are sent to internal pharmacy"]
["Billing, Clinical, IS","Service correction is needed after service is billed"]
["CCA","Supporting concurrent, client specific documentation for behavior tracking"]
["CCA","Time in/time out"]
["CCA","Track application materials due prior to adding client to wait list and assess prior to enrollment"]
["CCA","Service can translate to one CPT or multiple depending on duration and payer"]
["Medical","Structured and narrative medical note"]
["IDD Provider Planning/Monitoring","Enroll client in a bed and place on leave"]